commit 3207316b3beec7e38e5dbe2f463df0cec71e0b97
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 30 11:26:18 2020 +0100

    Linux 4.19.164
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Link: https://lore.kernel.org/r/20201228124919.745526410@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7638a4949a8e8a9d21cbb063f006c0830bb87d1
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 3 23:30:56 2020 +0100

    platform/x86: mlx-platform: remove an unused variable
    
    commit eca6ba20f38cfa2f148d7bd13db7ccd19e88635b upstream.
    
    The only reference to the mlxplat_mlxcpld_psu[] array got removed,
    so there is now a warning from clang:
    
    drivers/platform/x86/mlx-platform.c:322:30: error: variable 'mlxplat_mlxcpld_psu' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
    static struct i2c_board_info mlxplat_mlxcpld_psu[] = {
    
    Remove the array as well and adapt the ARRAY_SIZE() call
    accordingly.
    
    Fixes: 912b341585e3 ("platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Vadim Pasternak <vadimp@nvidia.com>
    Link: https://lore.kernel.org/r/20201203223105.1195709-1-arnd@kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Cc: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b20e285bb9b20dda3d046b1b1e7131c3839869c
Author: Jubin Zhong <zhongjubin@huawei.com>
Date:   Wed Dec 2 10:33:42 2020 +0800

    PCI: Fix pci_slot_release() NULL pointer dereference
    
    commit 4684709bf81a2d98152ed6b610e3d5c403f9bced upstream.
    
    If kobject_init_and_add() fails, pci_slot_release() is called to delete
    slot->list from parent->slots.  But slot->list hasn't been initialized
    yet, so we dereference a NULL pointer:
    
      Unable to handle kernel NULL pointer dereference at virtual address
    00000000
      ...
      CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197
      task: ffffeb398a45ef10 task.stack: ffffeb398a470000
      PC is at __list_del_entry_valid+0x5c/0xb0
      LR is at pci_slot_release+0x84/0xe4
      ...
      __list_del_entry_valid+0x5c/0xb0
      pci_slot_release+0x84/0xe4
      kobject_put+0x184/0x1c4
      pci_create_slot+0x17c/0x1b4
      __pci_hp_initialize+0x68/0xa4
      pciehp_probe+0x1a4/0x2fc
      pcie_port_probe_service+0x58/0x84
      driver_probe_device+0x320/0x470
    
    Initialize slot->list before calling kobject_init_and_add() to avoid this.
    
    Fixes: 8a94644b440e ("PCI: Fix pci_create_slot() reference count leak")
    Link: https://lore.kernel.org/r/1606876422-117457-1-git-send-email-zhongjubin@huawei.com
    Signed-off-by: Jubin Zhong <zhongjubin@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org      # v5.9+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bf21ccefe99250ef2bb8c17528557570a6a0904
Author: Carlos Garnacho <carlosg@gnome.org>
Date:   Tue Dec 1 14:57:27 2020 +0100

    platform/x86: intel-vbtn: Allow switch events on Acer Switch Alpha 12
    
    commit fe6000990394639ed374cb76c313be3640714f47 upstream.
    
    This 2-in-1 model (Product name: Switch SA5-271) features a SW_TABLET_MODE
    that works as it would be expected, both when detaching the keyboard and
    when folding it behind the tablet body.
    
    It used to work until the introduction of the allow list at
    commit 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list
    for SW_TABLET_MODE reporting"). Add this model to it, so that the Virtual
    Buttons device announces the EV_SW features again.
    
    Fixes: 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
    Cc: stable@vger.kernel.org
    Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
    Link: https://lore.kernel.org/r/20201201135727.212917-1-carlosg@gnome.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8d635ad52fcfec37b5e0e6aeeb3ff7bf6c902f6
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Nov 20 08:50:07 2020 -0800

    libnvdimm/namespace: Fix reaping of invalidated block-window-namespace labels
    
    commit 2dd2a1740ee19cd2636d247276cf27bfa434b0e2 upstream.
    
    A recent change to ndctl to attempt to reconfigure namespaces in place
    uncovered a label accounting problem in block-window-type namespaces.
    The ndctl "create.sh" test is able to trigger this signature:
    
     WARNING: CPU: 34 PID: 9167 at drivers/nvdimm/label.c:1100 __blk_label_update+0x9a3/0xbc0 [libnvdimm]
     [..]
     RIP: 0010:__blk_label_update+0x9a3/0xbc0 [libnvdimm]
     [..]
     Call Trace:
      uuid_store+0x21b/0x2f0 [libnvdimm]
      kernfs_fop_write+0xcf/0x1c0
      vfs_write+0xcc/0x380
      ksys_write+0x68/0xe0
    
    When allocated capacity for a namespace is renamed (new UUID) the labels
    with the old UUID need to be deleted. The ndctl behavior to always
    destroy namespaces on reconfiguration hid this problem.
    
    The immediate impact of this bug is limited since block-window-type
    namespaces only seem to exist in the specification and not in any
    shipping products. However, the label handling code is being reused for
    other technologies like CXL region labels, so there is a benefit to
    making sure both vertical labels sets (block-window) and horizontal
    label sets (pmem) have a functional reference implementation in
    libnvdimm.
    
    Fixes: c4703ce11c23 ("libnvdimm/namespace: Fix label tracking error")
    Cc: <stable@vger.kernel.org>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be19047894c3715a7ef974849f36cdb5083c4034
Author: SeongJae Park <sjpark@amazon.de>
Date:   Mon Dec 14 10:08:40 2020 +0100

    xenbus/xenbus_backend: Disallow pending watch messages
    
    commit 9996bd494794a2fe393e97e7a982388c6249aa76 upstream.
    
    'xenbus_backend' watches 'state' of devices, which is writable by
    guests.  Hence, if guests intensively updates it, dom0 will have lots of
    pending events that exhausting memory of dom0.  In other words, guests
    can trigger dom0 memory pressure.  This is known as XSA-349.  However,
    the watch callback of it, 'frontend_changed()', reads only 'state', so
    doesn't need to have the pending events.
    
    To avoid the problem, this commit disallows pending watch messages for
    'xenbus_backend' using the 'will_handle()' watch callback.
    
    This is part of XSA-349
    
    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park <sjpark@amazon.de>
    Reported-by: Michael Kurth <mku@amazon.de>
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85597c4369c9941dd38e47176ff8b540b2b583a3
Author: SeongJae Park <sjpark@amazon.de>
Date:   Mon Dec 14 10:07:13 2020 +0100

    xen/xenbus: Count pending messages for each watch
    
    commit 3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc upstream.
    
    This commit adds a counter of pending messages for each watch in the
    struct.  It is used to skip unnecessary pending messages lookup in
    'unregister_xenbus_watch()'.  It could also be used in 'will_handle'
    callback.
    
    This is part of XSA-349
    
    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park <sjpark@amazon.de>
    Reported-by: Michael Kurth <mku@amazon.de>
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b88c52d02e16cd02e51987646bb662a81f8687a6
Author: SeongJae Park <sjpark@amazon.de>
Date:   Mon Dec 14 10:05:47 2020 +0100

    xen/xenbus/xen_bus_type: Support will_handle watch callback
    
    commit be987200fbaceaef340872841d4f7af2c5ee8dc3 upstream.
    
    This commit adds support of the 'will_handle' watch callback for
    'xen_bus_type' users.
    
    This is part of XSA-349
    
    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park <sjpark@amazon.de>
    Reported-by: Michael Kurth <mku@amazon.de>
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a36e4af694a082ed4273c9e15062677be542a0a
Author: SeongJae Park <sjpark@amazon.de>
Date:   Mon Dec 14 10:04:18 2020 +0100

    xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path()
    
    commit 2e85d32b1c865bec703ce0c962221a5e955c52c2 upstream.
    
    Some code does not directly make 'xenbus_watch' object and call
    'register_xenbus_watch()' but use 'xenbus_watch_path()' instead.  This
    commit adds support of 'will_handle' callback in the
    'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.
    
    This is part of XSA-349
    
    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park <sjpark@amazon.de>
    Reported-by: Michael Kurth <mku@amazon.de>
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9039eb22f99545fa80a5897496452cf9962e3289
Author: SeongJae Park <sjpark@amazon.de>
Date:   Mon Dec 14 10:02:45 2020 +0100

    xen/xenbus: Allow watches discard events before queueing
    
    commit fed1755b118147721f2c87b37b9d66e62c39b668 upstream.
    
    If handling logics of watch events are slower than the events enqueue
    logic and the events can be created from the guests, the guests could
    trigger memory pressure by intensively inducing the events, because it
    will create a huge number of pending events that exhausting the memory.
    
    Fortunately, some watch events could be ignored, depending on its
    handler callback.  For example, if the callback has interest in only one
    single path, the watch wouldn't want multiple pending events.  Or, some
    watches could ignore events to same path.
    
    To let such watches to volutarily help avoiding the memory pressure
    situation, this commit introduces new watch callback, 'will_handle'.  If
    it is not NULL, it will be called for each new event just before
    enqueuing it.  Then, if the callback returns false, the event will be
    discarded.  No watch is using the callback for now, though.
    
    This is part of XSA-349
    
    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park <sjpark@amazon.de>
    Reported-by: Michael Kurth <mku@amazon.de>
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 014ee1c7d184acb8986152014a570ba7c69d3616
Author: Pawel Wieczorkiewicz <wipawel@amazon.de>
Date:   Mon Dec 14 10:25:57 2020 +0100

    xen-blkback: set ring->xenblkd to NULL after kthread_stop()
    
    commit 1c728719a4da6e654afb9cc047164755072ed7c9 upstream.
    
    When xen_blkif_disconnect() is called, the kernel thread behind the
    block interface is stopped by calling kthread_stop(ring->xenblkd).
    The ring->xenblkd thread pointer being non-NULL determines if the
    thread has been already stopped.
    Normally, the thread's function xen_blkif_schedule() sets the
    ring->xenblkd to NULL, when the thread's main loop ends.
    
    However, when the thread has not been started yet (i.e.
    wake_up_process() has not been called on it), the xen_blkif_schedule()
    function would not be called yet.
    
    In such case the kthread_stop() call returns -EINTR and the
    ring->xenblkd remains dangling.
    When this happens, any consecutive call to xen_blkif_disconnect (for
    example in frontend_changed() callback) leads to a kernel crash in
    kthread_stop() (e.g. NULL pointer dereference in exit_creds()).
    
    This is XSA-350.
    
    Cc: <stable@vger.kernel.org> # 4.12
    Fixes: a24fa22ce22a ("xen/blkback: don't use xen_blkif_get() in xen-blkback kthread")
    Reported-by: Olivier Benjamin <oliben@amazon.com>
    Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
    Reviewed-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1028639219393ff8a7866f3f9d337e5f380d5e1a
Author: Terry Zhou <bjzhou@marvell.com>
Date:   Fri Nov 6 11:00:39 2020 +0100

    clk: mvebu: a3700: fix the XTAL MODE pin to MPP1_9
    
    commit 6f37689cf6b38fff96de52e7f0d3e78f22803ba0 upstream.
    
    There is an error in the current code that the XTAL MODE
    pin was set to NB MPP1_31 which should be NB MPP1_9.
    The latch register of NB MPP1_9 has different offset of 0x8.
    
    Signed-off-by: Terry Zhou <bjzhou@marvell.com>
    [pali: Fix pin name in commit message]
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: 7ea8250406a6 ("clk: mvebu: Add the xtal clock for Armada 3700 SoC")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201106100039.11385-1-pali@kernel.org
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7790c43ac24d339bf0468a1b071d5ed23cad5e3a
Author: Yangtao Li <frank@allwinnertech.com>
Date:   Tue Nov 10 14:24:40 2020 +0800

    pinctrl: sunxi: Always call chained_irq_{enter, exit} in sunxi_pinctrl_irq_handler
    
    commit a1158e36f876f6269978a4176e3a1d48d27fe7a1 upstream.
    
    It is found on many allwinner soc that there is a low probability that
    the interrupt status cannot be read in sunxi_pinctrl_irq_handler. This
    will cause the interrupt status of a gpio bank to always be active on
    gic, preventing gic from responding to other spi interrupts correctly.
    
    So we should call the chained_irq_* each time enter sunxi_pinctrl_irq_handler().
    
    Signed-off-by: Yangtao Li <frank@allwinnertech.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/85263ce8b058e80cea25c6ad6383eb256ce96cc8.1604988979.git.frank@allwinnertech.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05cafe5ad8a2e4644469ee5991560f615181e520
Author: Zhao Heming <heming.zhao@suse.com>
Date:   Thu Nov 19 19:41:34 2020 +0800

    md/cluster: fix deadlock when node is doing resync job
    
    commit bca5b0658020be90b6b504ca514fd80110204f71 upstream.
    
    md-cluster uses MD_CLUSTER_SEND_LOCK to make node can exclusively send msg.
    During sending msg, node can concurrently receive msg from another node.
    When node does resync job, grab token_lockres:EX may trigger a deadlock:
    ```
    nodeA                       nodeB
    --------------------     --------------------
    a.
    send METADATA_UPDATED
    held token_lockres:EX
                             b.
                             md_do_sync
                              resync_info_update
                                send RESYNCING
                                 + set MD_CLUSTER_SEND_LOCK
                                 + wait for holding token_lockres:EX
    
                             c.
                             mdadm /dev/md0 --remove /dev/sdg
                              + held reconfig_mutex
                              + send REMOVE
                                 + wait_event(MD_CLUSTER_SEND_LOCK)
    
                             d.
                             recv_daemon //METADATA_UPDATED from A
                              process_metadata_update
                               + (mddev_trylock(mddev) ||
                                  MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD)
                                 //this time, both return false forever
    ```
    Explaination:
    a. A send METADATA_UPDATED
       This will block another node to send msg
    
    b. B does sync jobs, which will send RESYNCING at intervals.
       This will be block for holding token_lockres:EX lock.
    
    c. B do "mdadm --remove", which will send REMOVE.
       This will be blocked by step <b>: MD_CLUSTER_SEND_LOCK is 1.
    
    d. B recv METADATA_UPDATED msg, which send from A in step <a>.
       This will be blocked by step <c>: holding mddev lock, it makes
       wait_event can't hold mddev lock. (btw,
       MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD keep ZERO in this scenario.)
    
    There is a similar deadlock in commit 0ba959774e93
    ("md-cluster: use sync way to handle METADATA_UPDATED msg")
    In that commit, step c is "update sb". This patch step c is
    "mdadm --remove".
    
    For fixing this issue, we can refer the solution of function:
    metadata_update_start. Which does the same grab lock_token action.
    lock_comm can use the same steps to avoid deadlock. By moving
    MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD from lock_token to lock_comm.
    It enlarge a little bit window of MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD,
    but it is safe & can break deadlock.
    
    Repro steps (I only triggered 3 times with hundreds tests):
    
    two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB.
    ```
    ssh root@node2 "mdadm -S --scan"
    mdadm -S --scan
    for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \
    count=20; done
    
    mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh \
     --bitmap-chunk=1M
    ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh"
    
    sleep 5
    
    mkfs.xfs /dev/md0
    mdadm --manage --add /dev/md0 /dev/sdi
    mdadm --wait /dev/md0
    mdadm --grow --raid-devices=3 /dev/md0
    
    mdadm /dev/md0 --fail /dev/sdg
    mdadm /dev/md0 --remove /dev/sdg
    mdadm --grow --raid-devices=2 /dev/md0
    ```
    
    test script will hung when executing "mdadm --remove".
    
    ```
     # dump stacks by "echo t > /proc/sysrq-trigger"
    md0_cluster_rec D    0  5329      2 0x80004000
    Call Trace:
     __schedule+0x1f6/0x560
     ? _cond_resched+0x2d/0x40
     ? schedule+0x4a/0xb0
     ? process_metadata_update.isra.0+0xdb/0x140 [md_cluster]
     ? wait_woken+0x80/0x80
     ? process_recvd_msg+0x113/0x1d0 [md_cluster]
     ? recv_daemon+0x9e/0x120 [md_cluster]
     ? md_thread+0x94/0x160 [md_mod]
     ? wait_woken+0x80/0x80
     ? md_congested+0x30/0x30 [md_mod]
     ? kthread+0x115/0x140
     ? __kthread_bind_mask+0x60/0x60
     ? ret_from_fork+0x1f/0x40
    
    mdadm           D    0  5423      1 0x00004004
    Call Trace:
     __schedule+0x1f6/0x560
     ? __schedule+0x1fe/0x560
     ? schedule+0x4a/0xb0
     ? lock_comm.isra.0+0x7b/0xb0 [md_cluster]
     ? wait_woken+0x80/0x80
     ? remove_disk+0x4f/0x90 [md_cluster]
     ? hot_remove_disk+0xb1/0x1b0 [md_mod]
     ? md_ioctl+0x50c/0xba0 [md_mod]
     ? wait_woken+0x80/0x80
     ? blkdev_ioctl+0xa2/0x2a0
     ? block_ioctl+0x39/0x40
     ? ksys_ioctl+0x82/0xc0
     ? __x64_sys_ioctl+0x16/0x20
     ? do_syscall_64+0x5f/0x150
     ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    md0_resync      D    0  5425      2 0x80004000
    Call Trace:
     __schedule+0x1f6/0x560
     ? schedule+0x4a/0xb0
     ? dlm_lock_sync+0xa1/0xd0 [md_cluster]
     ? wait_woken+0x80/0x80
     ? lock_token+0x2d/0x90 [md_cluster]
     ? resync_info_update+0x95/0x100 [md_cluster]
     ? raid1_sync_request+0x7d3/0xa40 [raid1]
     ? md_do_sync.cold+0x737/0xc8f [md_mod]
     ? md_thread+0x94/0x160 [md_mod]
     ? md_congested+0x30/0x30 [md_mod]
     ? kthread+0x115/0x140
     ? __kthread_bind_mask+0x60/0x60
     ? ret_from_fork+0x1f/0x40
    ```
    
    At last, thanks for Xiao's solution.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhao Heming <heming.zhao@suse.com>
    Suggested-by: Xiao Ni <xni@redhat.com>
    Reviewed-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5149da7860b222bbf2b19561de669c5a4f397783
Author: Zhao Heming <heming.zhao@suse.com>
Date:   Thu Nov 19 19:41:33 2020 +0800

    md/cluster: block reshape with remote resync job
    
    commit a8da01f79c89755fad55ed0ea96e8d2103242a72 upstream.
    
    Reshape request should be blocked with ongoing resync job. In cluster
    env, a node can start resync job even if the resync cmd isn't executed
    on it, e.g., user executes "mdadm --grow" on node A, sometimes node B
    will start resync job. However, current update_raid_disks() only check
    local recovery status, which is incomplete. As a result, we see user will
    execute "mdadm --grow" successfully on local, while the remote node deny
    to do reshape job when it doing resync job. The inconsistent handling
    cause array enter unexpected status. If user doesn't observe this issue
    and continue executing mdadm cmd, the array doesn't work at last.
    
    Fix this issue by blocking reshape request. When node executes "--grow"
    and detects ongoing resync, it should stop and report error to user.
    
    The following script reproduces the issue with ~100% probability.
    (two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB)
    ```
     # on node1, node2 is the remote node.
    ssh root@node2 "mdadm -S --scan"
    mdadm -S --scan
    for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \
    count=20; done
    
    mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh
    ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh"
    
    sleep 5
    
    mdadm --manage --add /dev/md0 /dev/sdi
    mdadm --wait /dev/md0
    mdadm --grow --raid-devices=3 /dev/md0
    
    mdadm /dev/md0 --fail /dev/sdg
    mdadm /dev/md0 --remove /dev/sdg
    mdadm --grow --raid-devices=2 /dev/md0
    ```
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhao Heming <heming.zhao@suse.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4911cdcd3576089d874b11040320e05071e57d6
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Sep 20 12:27:38 2020 +0100

    iio:imu:bmi160: Fix too large a buffer.
    
    commit dc7de42d6b50a07b37feeba4c6b5136290fcee81 upstream.
    
    The comment implies this device has 3 sensor types, but it only
    has an accelerometer and a gyroscope (both 3D).  As such the
    buffer does not need to be as long as stated.
    
    Note I've separated this from the following patch which fixes
    the alignment for passing to iio_push_to_buffers_with_timestamp()
    as they are different issues even if they affect the same line
    of code.
    
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4c3573b76a2665f4a09447e7f58125292ed3768
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Sep 20 12:27:40 2020 +0100

    iio:pressure:mpl3115: Force alignment of buffer
    
    commit 198cf32f0503d2ad60d320b95ef6fb8243db857f upstream.
    
    Whilst this is another case of the issue Lars reported with
    an array of elements of smaller than 8 bytes being passed
    to iio_push_to_buffers_with_timestamp(), the solution here is
    a bit different from the other cases and relies on __aligned
    working on the stack (true since 4.6?)
    
    This one is unusual.  We have to do an explicit memset() each time
    as we are reading 3 bytes into a potential 4 byte channel which
    may sometimes be a 2 byte channel depending on what is enabled.
    As such, moving the buffer to the heap in the iio_priv structure
    doesn't save us much.  We can't use a nice explicit structure
    on the stack either as the data channels have different storage
    sizes and are all separately controlled.
    
    Fixes: cc26ad455f57 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver")
    Reported-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: Peter Meerwald <pmeerw@pmeerw.net>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-7-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 866042480722bf95e0cba5afaae92ac8013f90f7
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Sep 20 12:27:36 2020 +0100

    iio:light:st_uvis25: Fix timestamp alignment and prevent data leak.
    
    commit d837a996f57c29a985177bc03b0e599082047f27 upstream.
    
    One of a class of bugs pointed out by Lars in a recent review.
    iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
    to the size of the timestamp (8 bytes).  This is not guaranteed in
    this driver which uses an array of smaller elements on the stack.
    As Lars also noted this anti pattern can involve a leak of data to
    userspace and that indeed can happen here.  We close both issues by
    moving to a suitable structure in the iio_priv()
    
    This data is allocated with kzalloc() so no data can leak apart
    from previous readings.
    
    A local unsigned int variable is used for the regmap call so it
    is clear there is no potential issue with writing into the padding
    of the structure.
    
    Fixes: 3025c8688c1e ("iio: light: add support for UVIS25 sensor")
    Reported-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0d48a11c4210a3efdab371677c3986c00a7a680
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Sep 20 12:27:35 2020 +0100

    iio:light:rpr0521: Fix timestamp alignment and prevent data leak.
    
    commit a61817216bcc755eabbcb1cf281d84ccad267ed1 upstream.
    
    One of a class of bugs pointed out by Lars in a recent review.
    iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
    to the size of the timestamp (8 bytes).  This is not guaranteed in
    this driver which uses an array of smaller elements on the stack.
    As Lars also noted this anti pattern can involve a leak of data to
    userspace and that indeed can happen here.  We close both issues by
    moving to a suitable structure in the iio_priv().
    This data is allocated with kzalloc() so no data can leak apart
    from previous readings and in this case the status byte from the device.
    
    The forced alignment of ts is not necessary in this case but it
    potentially makes the code less fragile.
    
    >From personal communications with Mikko:
    
    We could probably split the reading of the int register, but it
    would mean a significant performance cost of 20 i2c clock cycles.
    
    Fixes: e12ffd241c00 ("iio: light: rpr0521 triggered buffer")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: Mikko Koivunen <mikko.koivunen@fi.rohmeurope.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-2-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c472f0a8beb5cf334888db5c3566d9a4b3dea5e
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Tue Nov 3 20:07:43 2020 +0800

    iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in rockchip_saradc_resume
    
    commit 560c6b914c6ec7d9d9a69fddbb5bf3bf71433e8b upstream.
    
    Fix the missing clk_disable_unprepare() of info->pclk
    before return from rockchip_saradc_resume in the error
    handling case when fails to prepare and enable info->clk.
    
    Suggested-by: Robin Murphy <robin.murphy@arm.com>
    Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc")
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201103120743.110662-1-miaoqinglang@huawei.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de1174bfe154c6e0bb817c7ce79d988049672a76
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Thu Nov 12 15:43:22 2020 +0100

    iio: buffer: Fix demux update
    
    commit 19ef7b70ca9487773c29b449adf0c70f540a0aab upstream.
    
    When updating the buffer demux, we will skip a scan element from the
    device in the case `in_ind != out_ind` and we enter the while loop.
    in_ind should only be refreshed with `find_next_bit()` in the end of the
    loop.
    
    Note, to cause problems we need a situation where we are skippig over
    an element (channel not enabled) that happens to not have the same size
    as the next element.   Whilst this is a possible situation we haven't
    actually identified any cases in mainline where it happens as most drivers
    have consistent channel storage sizes with the exception of the timestamp
    which is the last element and hence never skipped over.
    
    Fixes: 5ada4ea9be16 ("staging:iio: add demux optionally to path from device to buffer")
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20201112144323.28887-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 af5f1402b52be4d4b7b627f865e1d6b9fddc2f7d
Author: James Smart <james.smart@broadcom.com>
Date:   Tue Oct 20 13:27:13 2020 -0700

    scsi: lpfc: Re-fix use after free in lpfc_rq_buf_free()
    
    commit e5785d3ec32f5f44dd88cd7b398e496742630469 upstream.
    
    Commit 9816ef6ecbc1 ("scsi: lpfc: Use after free in lpfc_rq_buf_free()")
    was made to correct a use after free condition in lpfc_rq_buf_free().
    Unfortunately, a subsequent patch cut on a tree without the fix
    inadvertently reverted the fix.
    
    Put the fix back: Move the freeing of the rqb_entry to after the print
    function that references it.
    
    Link: https://lore.kernel.org/r/20201020202719.54726-4-james.smart@broadcom.com
    Fixes: 411de511c694 ("scsi: lpfc: Fix RQ empty firmware trap")
    Cc: <stable@vger.kernel.org> # v4.17+
    Signed-off-by: James Smart <james.smart@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5ba762be4355d044948f0e27da240a7affcc6d4
Author: James Smart <james.smart@broadcom.com>
Date:   Tue Oct 20 13:27:11 2020 -0700

    scsi: lpfc: Fix invalid sleeping context in lpfc_sli4_nvmet_alloc()
    
    commit 62e3a931db60daf94fdb3159d685a5bc6ad4d0cf upstream.
    
    The following calltrace was seen:
    
    BUG: sleeping function called from invalid context at mm/slab.h:494
    ...
    Call Trace:
     dump_stack+0x9a/0xf0
     ___might_sleep.cold.63+0x13d/0x178
     slab_pre_alloc_hook+0x6a/0x90
     kmem_cache_alloc_trace+0x3a/0x2d0
     lpfc_sli4_nvmet_alloc+0x4c/0x280 [lpfc]
     lpfc_post_rq_buffer+0x2e7/0xa60 [lpfc]
     lpfc_sli4_hba_setup+0x6b4c/0xa4b0 [lpfc]
     lpfc_pci_probe_one_s4.isra.15+0x14f8/0x2280 [lpfc]
     lpfc_pci_probe_one+0x260/0x2880 [lpfc]
     local_pci_probe+0xd4/0x180
     work_for_cpu_fn+0x51/0xa0
     process_one_work+0x8f0/0x17b0
     worker_thread+0x536/0xb50
     kthread+0x30c/0x3d0
     ret_from_fork+0x3a/0x50
    
    A prior patch introduced a spin_lock_irqsave(hbalock) in the
    lpfc_post_rq_buffer() routine. Call trace is seen as the hbalock is held
    with interrupts disabled during a GFP_KERNEL allocation in
    lpfc_sli4_nvmet_alloc().
    
    Fix by reordering locking so that hbalock not held when calling
    sli4_nvmet_alloc() (aka rqb_buf_list()).
    
    Link: https://lore.kernel.org/r/20201020202719.54726-2-james.smart@broadcom.com
    Fixes: 411de511c694 ("scsi: lpfc: Fix RQ empty firmware trap")
    Cc: <stable@vger.kernel.org> # v4.17+
    Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <james.smart@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f51592b237edb3cdd24cde4d97e65f9656794a2d
Author: Praveenkumar I <ipkumar@codeaurora.org>
Date:   Fri Oct 9 13:37:52 2020 +0530

    mtd: rawnand: qcom: Fix DMA sync on FLASH_STATUS register read
    
    commit bc3686021122de953858a5be4cbf6e3f1d821e79 upstream.
    
    After each codeword NAND_FLASH_STATUS is read for possible operational
    failures. But there is no DMA sync for CPU operation before reading it
    and this leads to incorrect or older copy of DMA buffer in reg_read_buf.
    
    This patch adds the DMA sync on reg_read_buf for CPU before reading it.
    
    Fixes: 5bc36b2bf6e2 ("mtd: rawnand: qcom: check for operation errors in case of raw read")
    Cc: stable@vger.kernel.org
    Signed-off-by: Praveenkumar I <ipkumar@codeaurora.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/1602230872-25616-1-git-send-email-ipkumar@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2b3692be5627a669eb106620fd66f9eadba36a2
Author: Sven Eckelmann <sven@narfation.org>
Date:   Tue Nov 24 07:25:06 2020 +0100

    mtd: parser: cmdline: Fix parsing of part-names with colons
    
    commit 639a82434f16a6df0ce0e7c8595976f1293940fd upstream.
    
    Some devices (especially QCA ones) are already using hardcoded partition
    names with colons in it. The OpenMesh A62 for example provides following
    mtd relevant information via cmdline:
    
      root=31:11 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(custom),64k(0:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) rootfsname=rootfs rootwait
    
    The change to split only on the last colon between mtd-id and partitions
    will cause newpart to see following string for the first partition:
    
      KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive)
    
    Such a partition list cannot be parsed and thus the device fails to boot.
    
    Avoid this behavior by making sure that the start of the first part-name
    ("(") will also be the last byte the mtd-id split algorithm is using for
    its colon search.
    
    Fixes: eb13fa022741 ("mtd: parser: cmdline: Support MTD names containing one or more colons")
    Cc: stable@vger.kernel.org
    Cc: Ron Minnich <rminnich@google.com>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20201124062506.185392-1-sven@narfation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 835c72e1d27773b22f62a8429125fea912698425
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Thu Oct 1 12:20:13 2020 +0200

    mtd: spinand: Fix OOB read
    
    commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 upstream.
    
    So far OOB have never been used in SPI-NAND, add the missing memcpy to
    make it work properly.
    
    Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-6-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72dc14a94cf61cc6a84f276d31ee1c03527d4215
Author: Evan Green <evgreen@chromium.org>
Date:   Tue Sep 29 13:30:57 2020 -0700

    soc: qcom: smp2p: Safely acquire spinlock without IRQs
    
    commit fc3e62e25c3896855b7c3d72df19ca6be3459c9f upstream.
    
    smp2p_update_bits() should disable interrupts when it acquires its
    spinlock. This is important because without the _irqsave, a priority
    inversion can occur.
    
    This function is called both with interrupts enabled in
    qcom_q6v5_request_stop(), and with interrupts disabled in
    ipa_smp2p_panic_notifier(). IRQ handling of spinlocks should be
    consistent to avoid the panic notifier deadlocking because it's
    sitting on the thread that's already got the lock via _request_stop().
    
    Found via lockdep.
    
    Cc: stable@vger.kernel.org
    Fixes: 50e99641413e7 ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point")
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Evan Green <evgreen@chromium.org>
    Link: https://lore.kernel.org/r/20200929133040.RESEND.1.Ideabf6dcdfc577cf39ce3d95b0e4aa1ac8b38f0c@changeid
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb55f4f5601cfb558ad59e703a819605ddc590f8
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Tue Nov 3 15:49:12 2020 +0800

    spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe
    
    commit 702b15cb97123cedcec56a39d9a21c5288eb9ae1 upstream.
    
    Fix the missing clk_disable_unprepare() before return
    from mt7621_spi_probe in the error handling case.
    
    Fixes: cbd66c626e16 ("spi: mt7621: Move SPI driver out of staging")
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Link: https://lore.kernel.org/r/20201103074912.195576-1-miaoqinglang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66f3bc09918d97d24908a81ac313ae660a7864fd
Author: Lukas Wunner <lukas@wunner.de>
Date:   Sun Nov 8 23:41:00 2020 +0100

    spi: st-ssc4: Fix unbalanced pm_runtime_disable() in probe error path
    
    commit 5ef76dac0f2c26aeae4ee79eb830280f16d5aceb upstream.
    
    If the calls to devm_platform_ioremap_resource(), irq_of_parse_and_map()
    or devm_request_irq() fail on probe of the ST SSC4 SPI driver, the
    runtime PM disable depth is incremented even though it was not
    decremented before.  Fix it.
    
    Fixes: cd050abeba2a ("spi: st-ssc4: add missed pm_runtime_disable")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.5+
    Cc: Chuhong Yuan <hslester96@gmail.com>
    Link: https://lore.kernel.org/r/fbe8768c30dc829e2d77eabe7be062ca22f84024.1604874488.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a33642f95269d9390d38d699a7e458dade819fc6
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:11 2020 +0100

    spi: sc18is602: Don't leak SPI master in probe error path
    
    commit 5b8c88462d83331dacb48aeaec8388117fef82e0 upstream.
    
    If the call to devm_gpiod_get_optional() fails on probe of the NXP
    SC18IS602/603 SPI driver, the spi_master struct is erroneously not freed.
    
    Fix by switching over to the new devm_spi_alloc_master() helper.
    
    Fixes: f99008013e19 ("spi: sc18is602: Add reset control via gpio pin.")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v4.9+
    Cc: Phil Reid <preid@electromag.com.au>
    Link: https://lore.kernel.org/r/d5f715527b894b91d530fe11a86f51b3184a4e1a.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9a04636e8058c055a73cf5e0028e0614f74286d
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:10 2020 +0100

    spi: rb4xx: Don't leak SPI master in probe error path
    
    commit a4729c3506c3eb1a6ca5c0289f4e7cafa4115065 upstream.
    
    If the calls to devm_clk_get(), devm_spi_register_master() or
    clk_prepare_enable() fail on probe of the Mikrotik RB4xx SPI driver,
    the spi_master struct is erroneously not freed.
    
    Fix by switching over to the new devm_spi_alloc_master() helper.
    
    Fixes: 05aec357871f ("spi: Add SPI driver for Mikrotik RB4xx series boards")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.2+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v4.2+
    Cc: Bert Vermeulen <bert@biot.com>
    Link: https://lore.kernel.org/r/369bf26d71927f60943b1d9d8f51810f00b0237d.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba02e029449fbb7aad9daa3d7778d1e824cf9b17
Author: Lukas Wunner <lukas@wunner.de>
Date:   Sun Nov 8 23:41:00 2020 +0100

    spi: pic32: Don't leak DMA channels in probe error path
    
    commit c575e9113bff5e024d75481613faed5ef9d465b2 upstream.
    
    If the calls to devm_request_irq() or devm_spi_register_master() fail
    on probe of the PIC32 SPI driver, the DMA channels requested by
    pic32_spi_dma_prep() are erroneously not released.  Plug the leak.
    
    Fixes: 1bcb9f8ceb67 ("spi: spi-pic32: Add PIC32 SPI master driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.7+
    Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
    Link: https://lore.kernel.org/r/9624250e3a7aa61274b38219a62375bac1def637.1604874488.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c8ef3bfd1245f9aa56f471fc906e5ad275a01dd
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:01 2020 +0100

    spi: davinci: Fix use-after-free on unbind
    
    commit 373afef350a93519b4b8d636b0895da8650b714b upstream.
    
    davinci_spi_remove() accesses the driver's private data after it's been
    freed with spi_master_put().
    
    Fix by moving the spi_master_put() to the end of the function.
    
    Fixes: fe5fd2540947 ("spi: davinci: Use dma_request_chan() for requesting DMA channel")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Cc: <stable@vger.kernel.org> # v4.7+
    Link: https://lore.kernel.org/r/412f7eb1cf8990e0a3a2153f4c577298deab623e.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9433449a7e4d15b581e939af6469866b8c459cc
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:04 2020 +0100

    spi: spi-sh: Fix use-after-free on unbind
    
    commit e77df3eca12be4b17f13cf9f215cff248c57d98f upstream.
    
    spi_sh_remove() accesses the driver's private data after calling
    spi_unregister_master() even though that function releases the last
    reference on the spi_master and thereby frees the private data.
    
    Fix by switching over to the new devm_spi_alloc_master() helper which
    keeps the private data accessible until the driver has unbound.
    
    Fixes: 680c1305e259 ("spi/spi_sh: use spi_unregister_master instead of spi_master_put in remove path")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v3.0+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v3.0+
    Cc: Axel Lin <axel.lin@ingics.com>
    Link: https://lore.kernel.org/r/6d97628b536baf01d5e3e39db61108f84d44c8b2.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 031ac02811bb34428f5d6c66a406657bd591acbb
Author: Zwane Mwaikambo <zwane@yosper.io>
Date:   Mon Oct 12 22:59:14 2020 -0700

    drm/dp_aux_dev: check aux_dev before use in drm_dp_aux_dev_get_by_minor()
    
    commit 73b62cdb93b68d7e2c1d373c6a411bc00c53e702 upstream.
    
    I observed this when unplugging a DP monitor whilst a computer is asleep
    and then waking it up. This left DP chardev nodes still being present on
    the filesystem and accessing these device nodes caused an oops because
    drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened.
    This can also be reproduced by creating a device node with mknod(1) and
    issuing an open(2)
    
    [166164.933198] BUG: kernel NULL pointer dereference, address: 0000000000000018
    [166164.933202] #PF: supervisor read access in kernel mode
    [166164.933204] #PF: error_code(0x0000) - not-present page
    [166164.933205] PGD 0 P4D 0
    [166164.933208] Oops: 0000 [#1] PREEMPT SMP NOPTI
    [166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: G        W
    5.8.0-rc6+ #1
    [166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W
    (1.11 ) 04/21/2020
    [166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70
    [drm_kms_helper]
    [166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7
    c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6
    <8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1
    [166164.933236] RSP: 0018:ffffb7d7c41cbbf0 EFLAGS: 00010246
    [166164.933237] RAX: 0000000000000000 RBX: ffff8a90001fe900 RCX: 0000000000000000
    [166164.933238] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffffc0a40180
    [166164.933239] RBP: ffffb7d7c41cbbf8 R08: 0000000000000000 R09: ffff8a93e157d6d0
    [166164.933240] R10: 0000000000000000 R11: ffffffffc0a40188 R12: 0000000000000003
    [166164.933241] R13: ffff8a9402200e80 R14: ffff8a90001fe900 R15: 0000000000000000
    [166164.933244] FS:  00007f7fb041eb00(0000) GS:ffff8a9411500000(0000)
    knlGS:0000000000000000
    [166164.933245] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [166164.933246] CR2: 0000000000000018 CR3: 00000000352c2003 CR4: 00000000003606e0
    [166164.933247] Call Trace:
    [166164.933264]  auxdev_open+0x1b/0x40 [drm_kms_helper]
    [166164.933278]  chrdev_open+0xa7/0x1c0
    [166164.933282]  ? cdev_put.part.0+0x20/0x20
    [166164.933287]  do_dentry_open+0x161/0x3c0
    [166164.933291]  vfs_open+0x2d/0x30
    [166164.933297]  path_openat+0xb27/0x10e0
    [166164.933306]  ? atime_needs_update+0x73/0xd0
    [166164.933309]  do_filp_open+0x91/0x100
    [166164.933313]  ? __alloc_fd+0xb2/0x150
    [166164.933316]  do_sys_openat2+0x210/0x2d0
    [166164.933318]  do_sys_open+0x46/0x80
    [166164.933320]  __x64_sys_openat+0x20/0x30
    [166164.933328]  do_syscall_64+0x52/0xc0
    [166164.933336]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    (gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29
    Dump of assembler code for function drm_dp_aux_dev_get_by_minor:
       0x0000000000017b10 <+0>:     callq  0x17b15 <drm_dp_aux_dev_get_by_minor+5>
       0x0000000000017b15 <+5>:     push   %rbp
       0x0000000000017b16 <+6>:     mov    %rsp,%rbp
       0x0000000000017b19 <+9>:     push   %r12
       0x0000000000017b1b <+11>:    mov    %edi,%r12d
       0x0000000000017b1e <+14>:    mov    $0x0,%rdi
       0x0000000000017b25 <+21>:    callq  0x17b2a <drm_dp_aux_dev_get_by_minor+26>
       0x0000000000017b2a <+26>:    mov    %r12d,%esi
       0x0000000000017b2d <+29>:    mov    $0x0,%rdi
       0x0000000000017b34 <+36>:    callq  0x17b39 <drm_dp_aux_dev_get_by_minor+41>
       0x0000000000017b39 <+41>:    mov    0x18(%rax),%edx <=========
       0x0000000000017b3c <+44>:    mov    %rax,%r12
       0x0000000000017b3f <+47>:    lea    0x18(%rax),%rdi
       0x0000000000017b43 <+51>:    test   %edx,%edx
       0x0000000000017b45 <+53>:    je     0x17b7a <drm_dp_aux_dev_get_by_minor+106>
       0x0000000000017b47 <+55>:    lea    0x1(%rdx),%ecx
       0x0000000000017b4a <+58>:    mov    %edx,%eax
       0x0000000000017b4c <+60>:    lock cmpxchg %ecx,(%rdi)
       0x0000000000017b50 <+64>:    jne    0x17b76 <drm_dp_aux_dev_get_by_minor+102>
       0x0000000000017b52 <+66>:    test   %edx,%edx
       0x0000000000017b54 <+68>:    js     0x17b6d <drm_dp_aux_dev_get_by_minor+93>
       0x0000000000017b56 <+70>:    test   %ecx,%ecx
       0x0000000000017b58 <+72>:    js     0x17b6d <drm_dp_aux_dev_get_by_minor+93>
       0x0000000000017b5a <+74>:    mov    $0x0,%rdi
       0x0000000000017b61 <+81>:    callq  0x17b66 <drm_dp_aux_dev_get_by_minor+86>
       0x0000000000017b66 <+86>:    mov    %r12,%rax
       0x0000000000017b69 <+89>:    pop    %r12
       0x0000000000017b6b <+91>:    pop    %rbp
       0x0000000000017b6c <+92>:    retq
       0x0000000000017b6d <+93>:    xor    %esi,%esi
       0x0000000000017b6f <+95>:    callq  0x17b74 <drm_dp_aux_dev_get_by_minor+100>
       0x0000000000017b74 <+100>:   jmp    0x17b5a <drm_dp_aux_dev_get_by_minor+74>
       0x0000000000017b76 <+102>:   mov    %eax,%edx
       0x0000000000017b78 <+104>:   jmp    0x17b43 <drm_dp_aux_dev_get_by_minor+51>
       0x0000000000017b7a <+106>:   xor    %r12d,%r12d
       0x0000000000017b7d <+109>:   jmp    0x17b5a <drm_dp_aux_dev_get_by_minor+74>
    End of assembler dump.
    
    (gdb) list *drm_dp_aux_dev_get_by_minor+0x29
    0x17b39 is in drm_dp_aux_dev_get_by_minor (drivers/gpu/drm/drm_dp_aux_dev.c:65).
    60      static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index)
    61      {
    62              struct drm_dp_aux_dev *aux_dev = NULL;
    63
    64              mutex_lock(&aux_idr_mutex);
    65              aux_dev = idr_find(&aux_idr, index);
    66              if (!kref_get_unless_zero(&aux_dev->refcount))
    67                      aux_dev = NULL;
    68              mutex_unlock(&aux_idr_mutex);
    69
    (gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount
    $8 = 0x18
    
    Looking at the caller, checks on the minor are pushed down to
    drm_dp_aux_dev_get_by_minor()
    
    static int auxdev_open(struct inode *inode, struct file *file)
    {
        unsigned int minor = iminor(inode);
        struct drm_dp_aux_dev *aux_dev;
    
        aux_dev = drm_dp_aux_dev_get_by_minor(minor); <====
        if (!aux_dev)
            return -ENODEV;
    
        file->private_data = aux_dev;
        return 0;
    }
    
    Fixes: e94cb37b34eb ("drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.")
    Cc: <stable@vger.kernel.org> # v4.6+
    Signed-off-by: Zwane Mwaikambo <zwane@yosper.io>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    [added Cc to stable]
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/alpine.DEB.2.21.2010122231070.38717@montezuma.home
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7e31b2fecfe0ebd5bd6a8274b2fbfb9c9401738
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Fri Nov 13 14:58:46 2020 -0600

    jfs: Fix array index bounds check in dbAdjTree
    
    commit c61b3e4839007668360ed8b87d7da96d2e59fc6c upstream.
    
    Bounds checking tools can flag a bug in dbAdjTree() for an array index
    out of bounds in dmt_stree. Since dmt_stree can refer to the stree in
    both structures dmaptree and dmapctl, use the larger array to eliminate
    the false positive.
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b18d841b81fc1e5f964ae1458b5a43af41c3c243
Author: Zhe Li <lizhe67@huawei.com>
Date:   Fri May 29 11:37:11 2020 +0800

    jffs2: Fix GC exit abnormally
    
    commit 9afc9a8a4909fece0e911e72b1060614ba2f7969 upstream.
    
    The log of this problem is:
    jffs2: Error garbage collecting node at 0x***!
    jffs2: No space for garbage collection. Aborting GC thread
    
    This is because GC believe that it do nothing, so it abort.
    
    After going over the image of jffs2, I find a scene that
    can trigger this problem stably.
    The scene is: there is a normal dirent node at summary-area,
    but abnormal at corresponding not-summary-area with error
    name_crc.
    
    The reason that GC exit abnormally is because it find that
    abnormal dirent node to GC, but when it goes to function
    jffs2_add_fd_to_list, it cannot meet the condition listed
    below:
    
    if ((*prev)->nhash == new->nhash && !strcmp((*prev)->name, new->name))
    
    So no node is marked obsolete, statistical information of
    erase_block do not change, which cause GC exit abnormally.
    
    The root cause of this problem is: we do not check the
    name_crc of the abnormal dirent node with summary is enabled.
    
    Noticed that in function jffs2_scan_dirent_node, we use
    function jffs2_scan_dirty_space to deal with the dirent
    node with error name_crc. So this patch add a checking
    code in function read_direntry to ensure the correctness
    of dirent node. If checked failed, the dirent node will
    be marked obsolete so GC will pass this node and this
    problem will be fixed.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Zhe Li <lizhe67@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1343995da97ef18c818537676392bf619b88c284
Author: Richard Weinberger <richard@nod.at>
Date:   Mon Nov 16 22:05:30 2020 +0100

    ubifs: wbuf: Don't leak kernel memory to flash
    
    commit 20f1431160c6b590cdc269a846fc5a448abf5b98 upstream.
    
    Write buffers use a kmalloc()'ed buffer, they can leak
    up to seven bytes of kernel memory to flash if writes are not
    aligned.
    So use ubifs_pad() to fill these gaps with padding bytes.
    This was never a problem while scanning because the scanner logic
    manually aligns node lengths and skips over these gaps.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ee56388802a703fd93ef6aaa4547a5407048a4e
Author: Steve French <stfrench@microsoft.com>
Date:   Wed Dec 9 22:19:00 2020 -0600

    SMB3.1.1: do not log warning message if server doesn't populate salt
    
    commit 7955f105afb6034af344038d663bc98809483cdd upstream.
    
    In the negotiate protocol preauth context, the server is not required
    to populate the salt (although it is done by most servers) so do
    not warn on mount.
    
    We retain the checks (warn) that the preauth context is the minimum
    size and that the salt does not exceed DataLength of the SMB response.
    Although we use the defaults in the case that the preauth context
    response is invalid, these checks may be useful in the future
    as servers add support for additional mechanisms.
    
    CC: Stable <stable@vger.kernel.org>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75bf69c42fa1e92e231fd30522846c879a628262
Author: Steve French <stfrench@microsoft.com>
Date:   Tue Dec 8 21:13:31 2020 -0600

    SMB3: avoid confusing warning message on mount to Azure
    
    commit ebcd6de98754d9b6a5f89d7835864b1c365d432f upstream.
    
    Mounts to Azure cause an unneeded warning message in dmesg
       "CIFS: VFS: parse_server_interfaces: incomplete interface info"
    
    Azure rounds up the size (by 8 additional bytes, to a
    16 byte boundary) of the structure returned on the query
    of the server interfaces at mount time.  This is permissible
    even though different than other servers so do not log a warning
    if query network interfaces response is only rounded up by 8
    bytes or fewer.
    
    CC: Stable <stable@vger.kernel.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53a27c6fafb916030e0e57a62e1c3af0194a449c
Author: Luis Henriques <lhenriques@suse.de>
Date:   Thu Nov 12 10:45:12 2020 +0000

    ceph: fix race in concurrent __ceph_remove_cap invocations
    
    commit e5cafce3ad0f8652d6849314d951459c2bff7233 upstream.
    
    A NULL pointer dereference may occur in __ceph_remove_cap with some of the
    callbacks used in ceph_iterate_session_caps, namely trim_caps_cb and
    remove_session_caps_cb. Those callers hold the session->s_mutex, so they
    are prevented from concurrent execution, but ceph_evict_inode does not.
    
    Since the callers of this function hold the i_ceph_lock, the fix is simply
    a matter of returning immediately if caps->ci is NULL.
    
    Cc: stable@vger.kernel.org
    URL: https://tracker.ceph.com/issues/43272
    Suggested-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Luis Henriques <lhenriques@suse.de>
    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 709ed96f6ef2b040a0ea9274b4d67ce61a095eb3
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Thu Nov 26 11:34:56 2020 +0100

    ima: Don't modify file descriptor mode on the fly
    
    commit 207cdd565dfc95a0a5185263a567817b7ebf5467 upstream.
    
    Commit a408e4a86b36b ("ima: open a new file instance if no read
    permissions") already introduced a second open to measure a file when the
    original file descriptor does not allow it. However, it didn't remove the
    existing method of changing the mode of the original file descriptor, which
    is still necessary if the current process does not have enough privileges
    to open a new one.
    
    Changing the mode isn't really an option, as the filesystem might need to
    do preliminary steps to make the read possible. Thus, this patch removes
    the code and keeps the second open as the only option to measure a file
    when it is unreadable with the original file descriptor.
    
    Cc: <stable@vger.kernel.org> # 4.20.x: 0014cc04e8ec0 ima: Set file->f_mode
    Fixes: 2fe5d6def1672 ("ima: integrity appraisal extension")
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96ffece6c6ddd6a6ac57216a0078071cf7a32fec
Author: David Hildenbrand <david@redhat.com>
Date:   Wed Nov 11 15:53:16 2020 +0100

    powerpc/powernv/memtrace: Fix crashing the kernel when enabling concurrently
    
    commit d6718941a2767fb383e105d257d2105fe4f15f0e upstream.
    
    It's very easy to crash the kernel right now by simply trying to
    enable memtrace concurrently, hammering on the "enable" interface
    
    loop.sh:
      #!/bin/bash
    
      dmesg --console-off
    
      while true; do
              echo 0x40000000 > /sys/kernel/debug/powerpc/memtrace/enable
      done
    
    [root@localhost ~]# loop.sh &
    [root@localhost ~]# loop.sh &
    
    Resulting quickly in a kernel crash. Let's properly protect using a
    mutex.
    
    Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory tracing")
    Cc: stable@vger.kernel.org# v4.14+
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201111145322.15793-3-david@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3f19058b09ecb3594d13a377a4a7ec7151e4f56
Author: David Hildenbrand <david@redhat.com>
Date:   Wed Nov 11 15:53:15 2020 +0100

    powerpc/powernv/memtrace: Don't leak kernel memory to user space
    
    commit c74cf7a3d59a21b290fe0468f5b470d0b8ee37df upstream.
    
    We currently leak kernel memory to user space, because memory
    offlining doesn't do any implicit clearing of memory and we are
    missing explicit clearing of memory.
    
    Let's keep it simple and clear pages before removing the linear
    mapping.
    
    Reproduced in QEMU/TCG with 10 GiB of main memory:
      [root@localhost ~]# dd obs=9G if=/dev/urandom of=/dev/null
      [... wait until "free -m" used counter no longer changes and cancel]
      19665802+0 records in
      1+0 records out
      9663676416 bytes (9.7 GB, 9.0 GiB) copied, 135.548 s, 71.3 MB/s
      [root@localhost ~]# cat /sys/devices/system/memory/block_size_bytes
      40000000
      [root@localhost ~]# echo 0x40000000 > /sys/kernel/debug/powerpc/memtrace/enable
      [  402.978663][ T1086] page:000000001bc4bc74 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24900
      [  402.980063][ T1086] flags: 0x7ffff000001000(reserved)
      [  402.980415][ T1086] raw: 007ffff000001000 c00c000000924008 c00c000000924008 0000000000000000
      [  402.980627][ T1086] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
      [  402.980845][ T1086] page dumped because: unmovable page
      [  402.989608][ T1086] Offlined Pages 16384
      [  403.324155][ T1086] memtrace: Allocated trace memory on node 0 at 0x0000000200000000
    
    Before this patch:
      [root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace  | head
      00000000  c8 25 72 51 4d 26 36 c5  5c c2 56 15 d5 1a cd 10  |.%rQM&6.\.V.....|
      00000010  19 b9 50 b2 cb e3 60 b8  ec 0a f3 ec 4b 3c 39 f0  |..P...`.....K<9.|$
      00000020  4e 5a 4c cf bd 26 19 ff  37 79 13 67 24 b7 b8 57  |NZL..&..7y.g$..W|$
      00000030  98 3e f5 be 6f 14 6a bd  a4 52 bc 6e e9 e0 c1 5d  |.>..o.j..R.n...]|$
      00000040  76 b3 ae b5 88 d7 da e3  64 23 85 2c 10 88 07 b6  |v.......d#.,....|$
      00000050  9a d8 91 de f7 50 27 69  2e 64 9c 6f d3 19 45 79  |.....P'i.d.o..Ey|$
      00000060  6a 6f 8a 61 71 19 1f c7  f1 df 28 26 ca 0f 84 55  |jo.aq.....(&...U|$
      00000070  01 3f be e4 e2 e1 da ff  7b 8c 8e 32 37 b4 24 53  |.?......{..27.$S|$
      00000080  1b 70 30 45 56 e6 8c c4  0e b5 4c fb 9f dd 88 06  |.p0EV.....L.....|$
      00000090  ef c4 18 79 f1 60 b1 5c  79 59 4d f4 36 d7 4a 5c  |...y.`.\yYM.6.J\|$
    
    After this patch:
      [root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace  | head
      00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
      *
      40000000
    
    Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory tracing")
    Cc: stable@vger.kernel.org # v4.14+
    Reported-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201111145322.15793-2-david@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 412cc34b718286866b25d09c8be532e42e360aa1
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Fri Dec 4 10:35:38 2020 +0000

    powerpc/xmon: Change printk() to pr_cont()
    
    commit 7c6c86b36a36dd4a13d30bba07718e767aa2e7a1 upstream.
    
    Since some time now, printk() adds carriage return, leading to
    unusable xmon output if there is no udbg backend available:
    
      [   54.288722] sysrq: Entering xmon
      [   54.292209] Vector: 0  at [cace3d2c]
      [   54.292274]     pc:
      [   54.292331] c0023650
      [   54.292468] : xmon+0x28/0x58
      [   54.292519]
      [   54.292574]     lr:
      [   54.292630] c0023724
      [   54.292749] : sysrq_handle_xmon+0xa4/0xfc
      [   54.292801]
      [   54.292867]     sp: cace3de8
      [   54.292931]    msr: 9032
      [   54.292999]   current = 0xc28d0000
      [   54.293072]     pid   = 377, comm = sh
      [   54.293157] Linux version 5.10.0-rc6-s3k-dev-01364-gedf13f0ccd76-dirty (root@po17688vm.idsi0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34) #4211 PREEMPT Fri Dec 4 09:32:11 UTC 2020
      [   54.293287] enter ? for help
      [   54.293470] [cace3de8]
      [   54.293532] c0023724
      [   54.293654]  sysrq_handle_xmon+0xa4/0xfc
      [   54.293711]  (unreliable)
      ...
      [   54.296002]
      [   54.296159] --- Exception: c01 (System Call) at
      [   54.296217] 0fd4e784
      [   54.296303]
      [   54.296375] SP (7fca6ff0) is in userspace
      [   54.296431] mon>
      [   54.296484]  <no input ...>
    
    Use pr_cont() instead.
    
    Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
    Cc: stable@vger.kernel.org # v4.9+
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [mpe: Mention that it only happens when udbg is not available]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/c8a6ec704416ecd5ff2bd26213c9bc026bdd19de.1607077340.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc04118ed00c8863502bcaa67a04e13ec7896b6c
Author: Tyrel Datwyler <tyreld@linux.ibm.com>
Date:   Tue Dec 8 13:54:34 2020 -0600

    powerpc/rtas: Fix typo of ibm,open-errinjct in RTAS filter
    
    commit f10881a46f8914428110d110140a455c66bdf27b upstream.
    
    Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
    introduced the following error when invoking the errinjct userspace
    tool:
    
      [root@ltcalpine2-lp5 librtas]# errinjct open
      [327884.071171] sys_rtas: RTAS call blocked - exploit attempt?
      [327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct)
      errinjct: Could not open RTAS error injection facility
      errinjct: librtas: open: Unexpected I/O error
    
    The entry for ibm,open-errinjct in rtas_filter array has a typo where
    the "j" is omitted in the rtas call name. After fixing this typo the
    errinjct tool functions again as expected.
    
      [root@ltcalpine2-lp5 linux]# errinjct open
      RTAS error injection facility open, token = 1
    
    Fixes: bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201208195434.8289-1-tyreld@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a246a0401aee5828ac1eda4d0f3de49872ab1ea
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Thu Oct 22 09:29:20 2020 +0000

    powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
    
    commit d85be8a49e733dcd23674aa6202870d54bf5600d upstream.
    
    The placeholder for instruction selection should use the second
    argument's operand, which is %1, not %0. This could generate incorrect
    assembly code if the memory addressing of operand %0 is a different
    form from that of operand %1.
    
    Also remove the %Un placeholder because having %Un placeholders
    for two operands which are based on the same local var (ptep) doesn't
    make much sense. By the way, it doesn't change the current behaviour
    because "<>" constraint is missing for the associated "=m".
    
    [chleroy: revised commit log iaw segher's comments and removed %U0]
    
    Fixes: 9bf2b5cdc5fe ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support")
    Cc: <stable@vger.kernel.org> # v2.6.28+
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/96354bd77977a6a933fe9020da57629007fdb920.1603358942.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3361541047c6583efe85ef97f88d034bb2c0fcf8
Author: Nicolas Ferre <nicolas.ferre@microchip.com>
Date:   Thu Dec 3 10:19:49 2020 +0100

    ARM: dts: at91: sama5d2: fix CAN message ram offset and size
    
    commit 85b8350ae99d1300eb6dc072459246c2649a8e50 upstream.
    
    CAN0 and CAN1 instances share the same message ram configured
    at 0x210000 on sama5d2 Linux systems.
    According to current configuration of CAN0, we need 0x1c00 bytes
    so that the CAN1 don't overlap its message ram:
    64 x RX FIFO0 elements => 64 x 72 bytes
    32 x TXE (TX Event FIFO) elements => 32 x 8 bytes
    32 x TXB (TX Buffer) elements => 32 x 72 bytes
    So a total of 7168 bytes (0x1C00).
    
    Fix offset to match this needed size.
    Make the CAN0 message ram ioremap match exactly this size so that is
    easily understandable.  Adapt CAN1 size accordingly.
    
    Fixes: bc6d5d7666b7 ("ARM: dts: at91: sama5d2: add m_can nodes")
    Reported-by: Dan Sneddon <dan.sneddon@microchip.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Tested-by: Cristian Birsan <cristian.birsan@microchip.com>
    Cc: stable@vger.kernel.org # v4.13+
    Link: https://lore.kernel.org/r/20201203091949.9015-1-nicolas.ferre@microchip.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a66d8ccc3aa6f0ab9923d2b22336c6cb29d0218b
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Sat Oct 3 16:10:00 2020 +0200

    ARM: dts: pandaboard: fix pinmux for gpio user button of Pandaboard ES
    
    commit df9dbaf2c415cd94ad520067a1eccfee62f00a33 upstream.
    
    The pinmux control register offset passed to OMAP4_IOPAD is odd.
    
    Fixes: ab9a13665e7c ("ARM: dts: pandaboard: add gpio user button")
    Cc: stable@vger.kernel.org
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1b68c71b6eac266e089756717bf37ba9634e24d
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Nov 10 11:10:15 2020 +0000

    KVM: arm64: Introduce handling of AArch32 TTBCR2 traps
    
    commit ca4e514774930f30b66375a974b5edcbebaf0e7e upstream.
    
    ARMv8.2 introduced TTBCR2, which shares TCR_EL1 with TTBCR.
    Gracefully handle traps to this register when HCR_EL2.TVM is set.
    
    Cc: stable@vger.kernel.org
    Reported-by: James Morse <james.morse@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 338b60216653f17080d9c36107a69fc0e6b2e46f
Author: Jan Kara <jack@suse.cz>
Date:   Fri Nov 27 12:06:49 2020 +0100

    ext4: fix deadlock with fs freezing and EA inodes
    
    commit 46e294efc355c48d1dd4d58501aa56dac461792a upstream.
    
    Xattr code using inodes with large xattr data can end up dropping last
    inode reference (and thus deleting the inode) from places like
    ext4_xattr_set_entry(). That function is called with transaction started
    and so ext4_evict_inode() can deadlock against fs freezing like:
    
    CPU1                                    CPU2
    
    removexattr()                           freeze_super()
      vfs_removexattr()
        ext4_xattr_set()
          handle = ext4_journal_start()
          ...
          ext4_xattr_set_entry()
            iput(old_ea_inode)
              ext4_evict_inode(old_ea_inode)
                                              sb->s_writers.frozen = SB_FREEZE_FS;
                                              sb_wait_write(sb, SB_FREEZE_FS);
                                              ext4_freeze()
                                                jbd2_journal_lock_updates()
                                                  -> blocks waiting for all
                                                     handles to stop
                sb_start_intwrite()
                  -> blocks as sb is already in SB_FREEZE_FS state
    
    Generally it is advisable to delete inodes from a separate transaction
    as it can consume quite some credits however in this case it would be
    quite clumsy and furthermore the credits for inode deletion are quite
    limited and already accounted for. So just tweak ext4_evict_inode() to
    avoid freeze protection if we have transaction already started and thus
    it is not really needed anyway.
    
    Cc: stable@vger.kernel.org
    Fixes: dec214d00e0d ("ext4: xattr inode deduplication")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Link: https://lore.kernel.org/r/20201127110649.24730-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48b91786875e25a2e958f5089fdad997615b538b
Author: Chunguang Xu <brookxu@tencent.com>
Date:   Sat Nov 7 23:58:18 2020 +0800

    ext4: fix a memory leak of ext4_free_data
    
    commit cca415537244f6102cbb09b5b90db6ae2c953bdd upstream.
    
    When freeing metadata, we will create an ext4_free_data and
    insert it into the pending free list.  After the current
    transaction is committed, the object will be freed.
    
    ext4_mb_free_metadata() will check whether the area to be freed
    overlaps with the pending free list. If true, return directly. At this
    time, ext4_free_data is leaked.  Fortunately, the probability of this
    problem is small, since it only occurs if the file system is corrupted
    such that a block is claimed by more one inode and those inodes are
    deleted within a single jbd2 transaction.
    
    Signed-off-by: Chunguang Xu <brookxu@tencent.com>
    Link: https://lore.kernel.org/r/1604764698-4269-8-git-send-email-brookxu@tencent.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e81c261b7ee6f129b121480b22f17675a8d0c1b
Author: Johan Hovold <johan@kernel.org>
Date:   Sun Oct 25 18:45:52 2020 +0100

    USB: serial: keyspan_pda: fix write unthrottling
    
    commit 320f9028c7873c3c7710e8e93e5c979f4c857490 upstream.
    
    The driver did not update its view of the available device buffer space
    until write() was called in task context. This meant that write_room()
    would return 0 even after the device had sent a write-unthrottle
    notification, something which could lead to blocked writers not being
    woken up (e.g. when using OPOST).
    
    Note that we must also request an unthrottle notification is case a
    write() request fills the device buffer exactly.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7d77722c89cc196bd0b364b060e738e3fb7ac97
Author: Johan Hovold <johan@kernel.org>
Date:   Sun Oct 25 18:45:51 2020 +0100

    USB: serial: keyspan_pda: fix tx-unthrottle use-after-free
    
    commit 49fbb8e37a961396a5b6c82937c70df91de45e9d upstream.
    
    The driver's transmit-unthrottle work was never flushed on disconnect,
    something which could lead to the driver port data being freed while the
    unthrottle work is still scheduled.
    
    Fix this by cancelling the unthrottle work when shutting down the port.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41bb69bb5f45d6f6bf0959216205972c1197a1b0
Author: Johan Hovold <johan@kernel.org>
Date:   Sun Oct 25 18:45:50 2020 +0100

    USB: serial: keyspan_pda: fix write-wakeup use-after-free
    
    commit 37faf50615412947868c49aee62f68233307f4e4 upstream.
    
    The driver's deferred write wakeup was never flushed on disconnect,
    something which could lead to the driver port data being freed while the
    wakeup work is still scheduled.
    
    Fix this by using the usb-serial write wakeup which gets cancelled
    properly on disconnect.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d5a037b430eb79043557be22e0f4a14acf32cc5
Author: Johan Hovold <johan@kernel.org>
Date:   Sun Oct 25 18:45:49 2020 +0100

    USB: serial: keyspan_pda: fix stalled writes
    
    commit c01d2c58698f710c9e13ba3e2d296328606f74fd upstream.
    
    Make sure to clear the write-busy flag also in case no new data was
    submitted due to lack of device buffer space so that writing is
    resumed once space again becomes available.
    
    Fixes: 507ca9bc0476 ("[PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.")
    Cc: stable <stable@vger.kernel.org>     # 2.6.13
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ba8e1972a99076b728ce21ef0ea43cad49731d8
Author: Johan Hovold <johan@kernel.org>
Date:   Sun Oct 25 18:45:48 2020 +0100

    USB: serial: keyspan_pda: fix write deadlock
    
    commit 7353cad7ee4deaefc16e94727e69285563e219f6 upstream.
    
    The write() callback can be called in interrupt context (e.g. when used
    as a console) so interrupts must be disabled while holding the port lock
    to prevent a possible deadlock.
    
    Fixes: e81ee637e4ae ("usb-serial: possible irq lock inversion (PPP vs. usb/serial)")
    Fixes: 507ca9bc0476 ("[PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.")
    Cc: stable <stable@vger.kernel.org>     # 2.6.19
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7216fd9d39de317c017954c36978d68b72fb327
Author: Johan Hovold <johan@kernel.org>
Date:   Sun Oct 25 18:45:47 2020 +0100

    USB: serial: keyspan_pda: fix dropped unthrottle interrupts
    
    commit 696c541c8c6cfa05d65aa24ae2b9e720fc01766e upstream.
    
    Commit c528fcb116e6 ("USB: serial: keyspan_pda: fix receive sanity
    checks") broke write-unthrottle handling by dropping well-formed
    unthrottle-interrupt packets which are precisely two bytes long. This
    could lead to blocked writers not being woken up when buffer space again
    becomes available.
    
    Instead, stop unconditionally printing the third byte which is
    (presumably) only valid on modem-line changes.
    
    Fixes: c528fcb116e6 ("USB: serial: keyspan_pda: fix receive sanity checks")
    Cc: stable <stable@vger.kernel.org>     # 4.11
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88dd1bcb9bc543d37ec7d5b369912e1ed44f04b2
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 26 11:43:06 2020 +0100

    USB: serial: digi_acceleport: fix write-wakeup deadlocks
    
    commit 5098e77962e7c8947f87bd8c5869c83e000a522a upstream.
    
    The driver must not call tty_wakeup() while holding its private lock as
    line disciplines are allowed to call back into write() from
    write_wakeup(), leading to a deadlock.
    
    Also remove the unneeded work struct that was used to defer wakeup in
    order to work around a possible race in ancient times (see comment about
    n_tty write_chan() in commit 14b54e39b412 ("USB: serial: remove
    changelogs and old todo entries")).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d27af9d8e806a46b281deba6ab11c3635021c9e
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Nov 4 17:47:27 2020 +0100

    USB: serial: mos7720: fix parallel-port state restore
    
    commit 975323ab8f116667676c30ca3502a6757bd89e8d upstream.
    
    The parallel-port restore operations is called when a driver claims the
    port and is supposed to restore the provided state (e.g. saved when
    releasing the port).
    
    Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715")
    Cc: stable <stable@vger.kernel.org>     # 2.6.35
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b560eaa4336b31dda6f546034e9f949555ca219c
Author: Borislav Petkov <bp@suse.de>
Date:   Sun Nov 22 15:57:21 2020 +0100

    EDAC/amd64: Fix PCI component registration
    
    commit 706657b1febf446a9ba37dc51b89f46604f57ee9 upstream.
    
    In order to setup its PCI component, the driver needs any node private
    instance in order to get a reference to the PCI device and hand that
    into edac_pci_create_generic_ctl(). For convenience, it uses the 0th
    memory controller descriptor under the assumption that if any, the 0th
    will be always present.
    
    However, this assumption goes wrong when the 0th node doesn't have
    memory and the driver doesn't initialize an instance for it:
    
      EDAC amd64: F17h detected (node 0).
      ...
      EDAC amd64: Node 0: No DIMMs detected.
    
    But looking up node instances is not really needed - all one needs is
    the pointer to the proper device which gets discovered during instance
    init.
    
    So stash that pointer into a variable and use it when setting up the
    EDAC PCI component.
    
    Clear that variable when the driver needs to unwind due to some
    instances failing init to avoid any registration imbalance.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20201122150815.13808-1-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85637bc064f4fd5539d4173798d8cb55dde7fc0a
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Tue Nov 24 11:47:19 2020 +0100

    crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()
    
    commit 17858b140bf49961b71d4e73f1c3ea9bc8e7dda0 upstream.
    
    ecdh_set_secret() casts a void* pointer to a const u64* in order to
    feed it into ecc_is_key_valid(). This is not generally permitted by
    the C standard, and leads to actual misalignment faults on ARMv6
    cores. In some cases, these are fixed up in software, but this still
    leads to performance hits that are entirely avoidable.
    
    So let's copy the key into the ctx buffer first, which we will do
    anyway in the common case, and which guarantees correct alignment.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1ea748795f0b491efb6f04c250ae9b995cde23c
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Wed Nov 25 02:26:55 2020 -0500

    powerpc/perf: Exclude kernel samples while counting events in user space.
    
    commit aa8e21c053d72b6639ea5a7f1d3a1d0209534c94 upstream.
    
    Perf event attritube supports exclude_kernel flag to avoid
    sampling/profiling in supervisor state (kernel). Based on this event
    attr flag, Monitor Mode Control Register bit is set to freeze on
    supervisor state. But sometimes (due to hardware limitation), Sampled
    Instruction Address Register (SIAR) locks on to kernel address even
    when freeze on supervisor is set. Patch here adds a check to drop
    those samples.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/1606289215-1433-1-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 275d8f007b6078c0229ca5ee282c904fc0948cbb
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Dec 7 14:58:06 2020 +0000

    staging: comedi: mf6x4: Fix AI end-of-conversion detection
    
    commit 56c90457ebfe9422496aac6ef3d3f0f0ea8b2ec2 upstream.
    
    I have had reports from two different people that attempts to read the
    analog input channels of the MF624 board fail with an `ETIMEDOUT` error.
    
    After triggering the conversion, the code calls `comedi_timeout()` with
    `mf6x4_ai_eoc()` as the callback function to check if the conversion is
    complete.  The callback returns 0 if complete or `-EBUSY` if not yet
    complete.  `comedi_timeout()` returns `-ETIMEDOUT` if it has not
    completed within a timeout period which is propagated as an error to the
    user application.
    
    The existing code considers the conversion to be complete when the EOLC
    bit is high.  However, according to the user manuals for the MF624 and
    MF634 boards, this test is incorrect because EOLC is an active low
    signal that goes high when the conversion is triggered, and goes low
    when the conversion is complete.  Fix the problem by inverting the test
    of the EOLC bit state.
    
    Fixes: 04b565021a83 ("comedi: Humusoft MF634 and MF624 DAQ cards driver")
    Cc: <stable@vger.kernel.org> # v4.4+
    Cc: Rostislav Lisovy <lisovy@gmail.com>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20201207145806.4046-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53563ca57cd8477b95cda7f421af2f3fdf6ae3db
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu Dec 17 16:59:07 2020 +0100

    s390/dasd: fix list corruption of lcu list
    
    commit 53a7f655834c7c335bf683f248208d4fbe4b47bc upstream.
    
    In dasd_alias_disconnect_device_from_lcu the device is removed from any
    list on the LCU. Afterwards the LCU is removed from the lcu list if it
    does not contain devices any longer.
    
    The lcu->lock protects the lcu from parallel updates. But to cancel all
    workers and wait for completion the lcu->lock has to be unlocked.
    
    If two devices are removed in parallel and both are removed from the LCU
    the first device that takes the lcu->lock again will delete the LCU because
    it is already empty but the second device also tries to free the LCU which
    leads to a list corruption of the lcu list.
    
    Fix by removing the device right before the lcu is checked without
    unlocking the lcu->lock in between.
    
    Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f9d96be70cd60e9d562ca2e185bd91477d8f22f
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu Dec 17 16:59:06 2020 +0100

    s390/dasd: fix list corruption of pavgroup group list
    
    commit 0ede91f83aa335da1c3ec68eb0f9e228f269f6d8 upstream.
    
    dasd_alias_add_device() moves devices to the active_devices list in case
    of a scheduled LCU update regardless if they have previously been in a
    pavgroup or not.
    
    Example: device A and B are in the same pavgroup.
    
    Device A has already been in a pavgroup and the private->pavgroup pointer
    is set and points to a valid pavgroup. While going through dasd_add_device
    it is moved from the pavgroup to the active_devices list.
    
    In parallel device B might be removed from the same pavgroup in
    remove_device_from_lcu() which in turn checks if the group is empty
    and deletes it accordingly because device A has already been removed from
    there.
    
    When now device A enters remove_device_from_lcu() it is tried to remove it
    from the pavgroup again because the pavgroup pointer is still set and again
    the empty group will be cleaned up which leads to a list corruption.
    
    Fix by setting private->pavgroup to NULL in dasd_add_device.
    
    If the device has been the last device on the pavgroup an empty pavgroup
    remains but this will be cleaned up by the scheduled lcu_update which
    iterates over all existing pavgroups.
    
    Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c175c54d8b007de88665f920e993e3d24cbd503e
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu Dec 17 16:59:05 2020 +0100

    s390/dasd: prevent inconsistent LCU device data
    
    commit a29ea01653493b94ea12bb2b89d1564a265081b6 upstream.
    
    Prevent _lcu_update from adding a device to a pavgroup if the LCU still
    requires an update. The data is not reliable any longer and in parallel
    devices might have been moved on the lists already.
    This might lead to list corruptions or invalid PAV grouping.
    Only add devices to a pavgroup if the LCU is up to date. Additional steps
    are taken by the scheduled lcu update.
    
    Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af814603ba60255c7db408dd4e7d76cd9f6f0c86
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu Dec 17 16:59:04 2020 +0100

    s390/dasd: fix hanging device offline processing
    
    commit 658a337a606f48b7ebe451591f7681d383fa115e upstream.
    
    For an LCU update a read unit address configuration IO is required.
    This is started using sleep_on(), which has early exit paths in case the
    device is not usable for IO. For example when it is in offline processing.
    
    In those cases the LCU update should fail and not be retried.
    Therefore lcu_update_work checks if EOPNOTSUPP is returned or not.
    
    Commit 41995342b40c ("s390/dasd: fix endless loop after read unit address configuration")
    accidentally removed the EOPNOTSUPP return code from
    read_unit_address_configuration(), which in turn might lead to an endless
    loop of the LCU update in offline processing.
    
    Fix by returning EOPNOTSUPP again if the device is not able to perform the
    request.
    
    Fixes: 41995342b40c ("s390/dasd: fix endless loop after read unit address configuration")
    Cc: stable@vger.kernel.org #5.3
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a874333de0cb756f423f302afe24215454ad6932
Author: Philipp Rudo <prudo@linux.ibm.com>
Date:   Thu Nov 26 18:31:08 2020 +0100

    s390/kexec_file: fix diag308 subcode when loading crash kernel
    
    commit 613775d62ec60202f98d2c5f520e6e9ba6dd4ac4 upstream.
    
    diag308 subcode 0 performes a clear reset which inlcudes the reset of
    all registers in the system. While this is the preferred behavior when
    loading a normal kernel via kexec it prevents the crash kernel to store
    the register values in the dump. To prevent this use subcode 1 when
    loading a crash kernel instead.
    
    Fixes: ee337f5469fd ("s390/kexec_file: Add crash support to image loader")
    Cc: <stable@vger.kernel.org> # 4.17
    Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
    Reported-by: Xiaoying Yan <yiyan@redhat.com>
    Tested-by: Lianbo Jiang <lijiang@redhat.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f3547b3eb0477b14b9ce95a99395503c6b616c7
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Tue Dec 8 07:35:21 2020 +0100

    s390/smp: perform initial CPU reset also for SMT siblings
    
    commit b5e438ebd7e808d1d2435159ac4742e01a94b8da upstream.
    
    Not resetting the SMT siblings might leave them in unpredictable
    state. One of the observed problems was that the CPU timer wasn't
    reset and therefore large system time values where accounted during
    CPU bringup.
    
    Cc: <stable@kernel.org> # 4.0
    Fixes: 10ad34bc76dfb ("s390: add SMT support")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 281d5bea129b2d8e64bca840fd9f9b336f5b6b37
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 18 15:58:58 2020 +0100

    ALSA: usb-audio: Disable sample read check if firmware doesn't give back
    
    commit 9df28edce7c6ab38050235f6f8b43dd7ccd01b6d upstream.
    
    Some buggy firmware don't give the current sample rate but leaves
    zero.  Handle this case more gracefully without warning but just skip
    the current rate verification from the next time.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201218145858.2357-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51f8e5d547bfa19d890e812b478320503f2ff81a
Author: Amadej Kastelic <amadejkastelic7@gmail.com>
Date:   Tue Dec 15 19:09:05 2020 +0100

    ALSA: usb-audio: Add VID to support native DSD reproduction on FiiO devices
    
    commit 725124d10d00b2f56bb5bd08b431cc74ab3b3ace upstream.
    
    Add VID to support native DSD reproduction on FiiO devices.
    
    Tested-by: Amadej Kastelic <amadejkastelic7@gmail.com>
    Signed-off-by: Emilio Moretti <emilio.moretti@gmail.com>
    Signed-off-by: Amadej Kastelic <amadejkastelic7@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/X9j7wdXSr4XyK7Bd@ryzen.localdomain
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c732bb97ca507d6b2a8a7eae019cef28e892d554
Author: Chris Chiu <chiu@endlessos.org>
Date:   Tue Dec 22 23:04:58 2020 +0800

    ALSA: hda/realtek: Apply jack fixup for Quanta NL3
    
    commit 6ca653e3f73a1af0f30dbf9c2c79d2897074989f upstream.
    
    The Quanta NL3 laptop has both a headphone output jack and a headset
    jack, on the right edge of the chassis.
    
    The pin information suggests that both of these are at the Front.
    The PulseAudio is confused to differentiate them so one of the jack
    can neither get the jack sense working nor the audio output.
    
    The ALC269_FIXUP_LIFEBOOK chained with ALC269_FIXUP_QUANTA_MUTE can
    help to differentiate 2 jacks and get the 'Auto-Mute Mode' working
    correctly.
    
    Signed-off-by: Chris Chiu <chiu@endlessos.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201222150459.9545-1-chiu@endlessos.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76a8b0c8cd1e75c2baaaf0803ac99ba58e427364
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Dec 20 09:09:43 2020 +0100

    ALSA: hda/realtek: Add quirk for MSI-GP73
    
    commit 09926202e939fd699650ac0fc0baa5757e069390 upstream.
    
    MSI-GP73 (with SSID 1462:1229) requires yet again
    ALC1220_FIXUP_CLEVO_P950 quirk like other MSI models.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210793
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201220080943.24839-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cf68eeaedd123ed83a975b02692ee584aef9bea
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 18 17:17:30 2020 +0100

    ALSA: pcm: oss: Fix a few more UBSAN fixes
    
    commit 11cb881bf075cea41092a20236ba708b18e1dbb2 upstream.
    
    There are a few places that call round{up|down}_pow_of_two() with the
    value zero, and this causes undefined behavior warnings.  Avoid
    calling those macros if such a nonsense value is passed; it's a minor
    optimization as well, as we handle it as either an error or a value to
    be skipped, instead.
    
    Reported-by: syzbot+33ef0b6639a8d2d42b4c@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201218161730.26596-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f02fcbd34923e5c9d62cfcd6e88d521c53488bf9
Author: Chris Chiu <chiu@endlessos.org>
Date:   Wed Dec 9 12:57:30 2020 +0800

    ALSA: hda/realtek - Enable headset mic of ASUS Q524UQK with ALC255
    
    commit 7e413528474d5895e3e315c019fb0c43522eb6d9 upstream.
    
    The ASUS laptop Q524UQK with ALC255 codec can't detect the headset
    microphone until ALC255_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
    
    Signed-off-by: Chris Chiu <chiu@endlessos.org>
    Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201209045730.9972-1-chiu@endlessos.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4059297cd1d8b1b1fd45d28e6933a435db26831
Author: Chris Chiu <chiu@endlessos.org>
Date:   Mon Dec 7 15:27:55 2020 +0800

    ALSA: hda/realtek - Enable headset mic of ASUS X430UN with ALC256
    
    commit 5cfca59604e423f720297e30a9dc493eea623493 upstream.
    
    The ASUS laptop X430UN with ALC256 can't detect the headset microphone
    until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
    
    Signed-off-by: Chris Chiu <chiu@endlessos.org>
    Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201207072755.16210-1-chiu@endlessos.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecd5d5354c2175f7f43b31c784ec515ae46cdc5a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 9 16:01:19 2020 +0100

    ALSA: hda: Fix regressions on clear and reconfig sysfs
    
    commit 2506318e382c4c7daa77bdc48f80a0ee82804588 upstream.
    
    It seems that the HD-audio clear and reconfig sysfs don't work any
    longer after the recent driver core change.  There are multiple issues
    around that: the linked list corruption and the dead device handling.
    The former issue is fixed by another patch for the driver core itself,
    while the latter patch needs to be addressed in HD-audio side.
    
    This patch corresponds to the latter, it recovers those broken
    functions by replacing the device detach and attach actions with the
    standard core API functions, which are almost equivalent with unbind
    and bind actions.
    
    Fixes: 654888327e9f ("driver core: Avoid binding drivers to dead devices")
    Cc: <stable@vger.kernel.org>
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209207
    Link: https://lore.kernel.org/r/20201209150119.7705-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20ef32728f5ef8987d7fe5de8b306b3beb451193
Author: Hui Wang <hui.wang@canonical.com>
Date:   Fri Dec 11 10:18:14 2020 +0800

    ACPI: PNP: compare the string length in the matching_id()
    
    commit b08221c40febcbda9309dd70c61cf1b0ebb0e351 upstream.
    
    Recently we met a touchscreen problem on some Thinkpad machines, the
    touchscreen driver (i2c-hid) is not loaded and the touchscreen can't
    work.
    
    An i2c ACPI device with the name WACF2200 is defined in the BIOS, with
    the current rule in matching_id(), this device will be regarded as
    a PNP device since there is WACFXXX in the acpi_pnp_device_ids[] and
    this PNP device is attached to the acpi device as the 1st
    physical_node, this will make the i2c bus match fail when i2c bus
    calls acpi_companion_match() to match the acpi_id_table in the i2c-hid
    driver.
    
    WACF2200 is an i2c device instead of a PNP device, after adding the
    string length comparing, the matching_id() will return false when
    matching WACF2200 and WACFXXX, and it is reasonable to compare the
    string length when matching two IDs.
    
    Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    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 6d6a32df9465923445c8f657edb34f3419e74ef7
Author: Daniel Scally <djrscally@gmail.com>
Date:   Sat Dec 5 17:04:03 2020 +0000

    Revert "ACPI / resources: Use AE_CTRL_TERMINATE to terminate resources walks"
    
    commit 12fc4dad94dfac25599f31257aac181c691ca96f upstream.
    
    This reverts commit 8a66790b7850a6669129af078768a1d42076a0ef.
    
    Switching this function to AE_CTRL_TERMINATE broke the documented
    behaviour of acpi_dev_get_resources() - AE_CTRL_TERMINATE does not, in
    fact, terminate the resource walk because acpi_walk_resource_buffer()
    ignores it (specifically converting it to AE_OK), referring to that
    value as "an OK termination by the user function". This means that
    acpi_dev_get_resources() does not abort processing when the preproc
    function returns a negative value.
    
    Signed-off-by: Daniel Scally <djrscally@gmail.com>
    Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64a48bf56640f2f78bebdfa2117df44a3e054955
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Nov 24 20:44:00 2020 +0100

    PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
    
    commit 7482c5cb90e5a7f9e9e12dd154d405e0219656e3 upstream.
    
    The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
    be reference counted for wakeup enabling, because they may be enabled
    to signal wakeup on behalf of their subordinate devices and that
    may happen for multiple times in a row, whereas for the other devices
    it only makes sense to enable wakeup signaling once.
    
    However, this becomes problematic if the bridge itself is suspended,
    because it is treated as a "regular" device in that case and the
    reference counting doesn't work.
    
    For instance, suppose that there are two devices below a bridge and
    they both can signal wakeup.  Every time one of them is suspended,
    wakeup signaling is enabled for the bridge, so when they both have
    been suspended, the bridge's wakeup reference counter value is 2.
    
    Say that the bridge is suspended subsequently and acpi_pci_wakeup()
    is called for it.  Because the bridge can signal wakeup, that
    function will invoke acpi_pm_set_device_wakeup() to configure it
    and __acpi_pm_set_device_wakeup() will be called with the last
    argument equal to 1.  This causes __acpi_device_wakeup_enable()
    invoked by it to omit the reference counting, because the reference
    counter of the target device (the bridge) is 2 at that time.
    
    Now say that the bridge resumes and one of the device below it
    resumes too, so the bridge's reference counter becomes 0 and
    wakeup signaling is disabled for it, but there is still the other
    suspended device which may need the bridge to signal wakeup on its
    behalf and that is not going to work.
    
    To address this scenario, use wakeup enable reference counting for
    all devices, not just for bridges, so drop the last argument from
    __acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
    which causes acpi_pm_set_device_wakeup() and
    acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
    and use the former instead of it everywhere.
    
    Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2de2deb4e3630c6399a1bb4d431bb3e2a55d4a26
Author: Connor McAdams <conmanx360@gmail.com>
Date:   Thu Dec 10 12:35:49 2020 -0500

    ALSA: hda/ca0132 - Change Input Source enum strings.
    
    commit 7079f785b50055a32b72eddcb7d9ba5688db24d0 upstream.
    
    Change the Input Source enumerated control's strings to make it play
    nice with pulseaudio.
    
    Fixes: 7cb9d94c05de9 ("ALSA: hda/ca0132: add alt_select_in/out for R3Di + SBZ")
    Cc: <stable@kernel.org>
    Signed-off-by: Connor McAdams <conmanx360@gmail.com>
    Link: https://lore.kernel.org/r/20201208195223.424753-2-conmanx360@gmail.com
    Link: https://lore.kernel.org/r/20201210173550.2968-2-conmanx360@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0225aaa7412ebaba73a179d50497955e8e383d65
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Dec 14 13:37:46 2020 -0800

    Input: cyapa_gen6 - fix out-of-bounds stack access
    
    commit f051ae4f6c732c231046945b36234e977f8467c6 upstream.
    
    gcc -Warray-bounds warns about a serious bug in
    cyapa_pip_retrieve_data_structure:
    
    drivers/input/mouse/cyapa_gen6.c: In function 'cyapa_pip_retrieve_data_structure.constprop':
    include/linux/unaligned/access_ok.h:40:17: warning: array subscript -1 is outside array bounds of 'struct retrieve_data_struct_cmd[1]' [-Warray-bounds]
       40 |  *((__le16 *)p) = cpu_to_le16(val);
    drivers/input/mouse/cyapa_gen6.c:569:13: note: while referencing 'cmd'
      569 |  } __packed cmd;
          |             ^~~
    
    Apparently the '-2' was added to the pointer instead of the value,
    writing garbage into the stack next to this variable.
    
    Fixes: c2c06c41f700 ("Input: cyapa - add gen6 device module support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20201026161332.3708389-1-arnd@kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e1f3bce394270345d4d966c02367bcca85d060e
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Fri Oct 9 15:56:05 2020 +0200

    media: ipu3-cio2: Make the field on subdev format V4L2_FIELD_NONE
    
    commit 219a8b9c04e54872f9a4d566633fb42f08bcbe2a upstream.
    
    The ipu3-cio2 doesn't make use of the field and this is reflected in V4L2
    buffers as well as the try format. Do this in active format, too.
    
    Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: stable@vger.kernel.org # v4.16 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b18999a05d37627d418f1e674ad3d18df0142e9
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Oct 8 21:33:26 2020 +0200

    media: ipu3-cio2: Validate mbus format in setting subdev format
    
    commit a86cf9b29e8b12811cf53c4970eefe0c1d290476 upstream.
    
    Validate media bus code, width and height when setting the subdev format.
    
    This effectively reworks how setting subdev format is implemented in the
    driver.
    
    Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: stable@vger.kernel.org # v4.16 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1bef842392ffeed86f7f9318b9a2c5114d280ab
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Oct 8 21:29:38 2020 +0200

    media: ipu3-cio2: Serialise access to pad format
    
    commit 55a6c6b2be3d6670bf5772364d8208bd8dc17da4 upstream.
    
    Pad format can be accessed from user space. Serialise access to it.
    
    Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: stable@vger.kernel.org # v4.16 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b72a9f15014aff6fc416f4bddfe45b99c5b2c7b2
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Oct 8 21:06:28 2020 +0200

    media: ipu3-cio2: Return actual subdev format
    
    commit 8160e86702e0807bd36d40f82648f9f9820b9d5a upstream.
    
    Return actual subdev format on ipu3-cio2 subdev pads. The earlier
    implementation was based on an infinite recursion that exhausted the
    stack.
    
    Reported-by: Tsuchiya Yuto <kitakar@gmail.com>
    Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: stable@vger.kernel.org # v4.16 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31d36c707bedb983da5af77d21c820f042de0506
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Mon Oct 12 17:25:28 2020 +0200

    media: ipu3-cio2: Remove traces of returned buffers
    
    commit 61e7f892b5ee1dd10ea8bff805f3c3fe6e535959 upstream.
    
    If starting a video buffer queue fails, the buffers are returned to
    videobuf2. Remove the reference to the buffer from the driver's queue as
    well.
    
    Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Cc: stable@vger.kernel.org # v4.16 and up
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-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 1bb7a3c69c3c43becf9e5d4ee5150ee83fd23ffe
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:12 2020 +0100

    media: netup_unidvb: Don't leak SPI master in probe error path
    
    commit e297ddf296de35037fa97f4302782def196d350a upstream.
    
    If the call to spi_register_master() fails on probe of the NetUP
    Universal DVB driver, the spi_master struct is erroneously not freed.
    
    Likewise, if spi_new_device() fails, the spi_controller struct is
    not unregistered.  Plug the leaks.
    
    While at it, fix an ordering issue in netup_spi_release() wherein
    spi_unregister_master() is called after fiddling with the IRQ control
    register.  The correct order is to call spi_unregister_master() *before*
    this teardown step because bus accesses may still be ongoing until that
    function returns.
    
    Fixes: 52b1eaf4c59a ("[media] netup_unidvb: NetUP Universal DVB-S/S2/T/T2/C PCI-E card driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Cc: <stable@vger.kernel.org> # v4.3+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v4.3+
    Cc: Kozlov Sergey <serjk@netup.ru>
    Link: https://lore.kernel.org/r/c4c24f333fc7840f4a3db24789e6e10dd660bede.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c97345cd8cc52663d2d97a41b877a53032186670
Author: Sean Young <sean@mess.org>
Date:   Mon Nov 9 23:16:52 2020 +0100

    media: sunxi-cir: ensure IR is handled when it is continuous
    
    commit 3f56df4c8ffeb120ed41906d3aae71799b7e726a upstream.
    
    If a user holds a button down on a remote, then no ir idle interrupt will
    be generated until the user releases the button, depending on how quickly
    the remote repeats. No IR is processed until that point, which means that
    holding down a button may not do anything.
    
    This also resolves an issue on a Cubieboard 1 where the IR receiver is
    picking up ambient infrared as IR and spews out endless
    "rc rc0: IR event FIFO is full!" messages unless you choose to live in
    the dark.
    
    Cc: stable@vger.kernel.org
    Tested-by: Hans Verkuil <hverkuil@xs4all.nl>
    Acked-by: Maxime Ripard <mripard@kernel.org>
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae1f265fbf4e38bfb18686f98fc0442a687e3b44
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Dec 2 18:20:04 2020 +0100

    media: gspca: Fix memory leak in probe
    
    commit e469d0b09a19496e1972a20974bbf55b728151eb upstream.
    
    The gspca driver leaks memory when a probe fails.  gspca_dev_probe2()
    calls v4l2_device_register(), which takes a reference to the
    underlying device node (in this case, a USB interface).  But the
    failure pathway neglects to call v4l2_device_unregister(), the routine
    responsible for dropping this reference.  Consequently the memory for
    the USB interface and its device never gets released.
    
    This patch adds the missing function call.
    
    Reported-and-tested-by: syzbot+44e64397bd81d5e84cba@syzkaller.appspotmail.com
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.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 e46034c8520a0746fb9e7d8069343d6d026a36a7
Author: Simon Beginn <linux@simonmicro.de>
Date:   Fri Dec 11 16:17:32 2020 -0800

    Input: goodix - add upside-down quirk for Teclast X98 Pro tablet
    
    [ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]
    
    The touchscreen on the Teclast x98 Pro is also mounted upside-down in
    relation to the display orientation.
    
    Signed-off-by: Simon Beginn <linux@simonmicro.de>
    Signed-off-by: Bastien Nocera <hadess@hadess.net>
    Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78a73f9556a17efedae85cc769c3c8913a732858
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Dec 9 17:59:53 2020 -0800

    Input: cros_ec_keyb - send 'scancodes' in addition to key events
    
    [ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]
    
    To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE
    and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in
    addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN
    capability, so it is only matter of actually sending the events.
    
    Link: https://lore.kernel.org/r/X87aOaSptPTvZ3nZ@google.com
    Acked-by: Rajat Jain <rajatja@google.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d27b8a31096c7acb1a7e2e340d6fb6d481bb23ae
Author: Dongdong Wang <wangdongdong.6@bytedance.com>
Date:   Fri Dec 4 23:59:45 2020 -0800

    lwt: Disable BH too in run_lwt_bpf()
    
    [ Upstream commit d9054a1ff585ba01029584ab730efc794603d68f ]
    
    The per-cpu bpf_redirect_info is shared among all skb_do_redirect()
    and BPF redirect helpers. Callers on RX path are all in BH context,
    disabling preemption is not sufficient to prevent BH interruption.
    
    In production, we observed strange packet drops because of the race
    condition between LWT xmit and TC ingress, and we verified this issue
    is fixed after we disable BH.
    
    Although this bug was technically introduced from the beginning, that
    is commit 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure"),
    at that time call_rcu() had to be call_rcu_bh() to match the RCU context.
    So this patch may not work well before RCU flavor consolidation has been
    completed around v5.0.
    
    Update the comments above the code too, as call_rcu() is now BH friendly.
    
    Signed-off-by: Dongdong Wang <wangdongdong.6@bytedance.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Link: https://lore.kernel.org/bpf/20201205075946.497763-1-xiyou.wangcong@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f0e4cd4eff265cf24b8253449e0bf8770ba363a
Author: Serge Hallyn <shallyn@cisco.com>
Date:   Sun Nov 15 21:55:31 2020 -0600

    fix namespaced fscaps when !CONFIG_SECURITY
    
    [ Upstream commit ed9b25d1970a4787ac6a39c2091e63b127ecbfc1 ]
    
    Namespaced file capabilities were introduced in 8db6c34f1dbc .
    When userspace reads an xattr for a namespaced capability, a
    virtualized representation of it is returned if the caller is
    in a user namespace owned by the capability's owning rootid.
    The function which performs this virtualization was not hooked
    up if CONFIG_SECURITY=n.  Therefore in that case the original
    xattr was shown instead of the virtualized one.
    
    To test this using libcap-bin (*1),
    
    $ v=$(mktemp)
    $ unshare -Ur setcap cap_sys_admin-eip $v
    $ unshare -Ur setcap -v cap_sys_admin-eip $v
    /tmp/tmp.lSiIFRvt8Y: OK
    
    "setcap -v" verifies the values instead of setting them, and
    will check whether the rootid value is set.  Therefore, with
    this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will
    fail:
    
    $ v=$(mktemp)
    $ unshare -Ur setcap cap_sys_admin=eip $v
    $ unshare -Ur setcap -v cap_sys_admin=eip $v
    nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []
    
    Fix this bug by calling cap_inode_getsecurity() in
    security_inode_getsecurity() instead of returning
    -EOPNOTSUPP, when CONFIG_SECURITY=n.
    
    *1 - note, if libcap is too old for getcap to have the '-n'
    option, then use verify-caps instead.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209689
    Cc: Hervé Guillemet <herve@guillemet.org>
    Acked-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Serge Hallyn <shallyn@cisco.com>
    Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
    Signed-off-by: James Morris <jamorris@linux.microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25d3b125c04c6eddaadbf299fc17a3b57a86e4da
Author: Sara Sharon <sara.sharon@intel.com>
Date:   Sun Nov 29 17:30:44 2020 +0200

    cfg80211: initialize rekey_data
    
    [ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]
    
    In case we have old supplicant, the akm field is uninitialized.
    
    Signed-off-by: Sara Sharon <sara.sharon@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3f4a89f318eafddc3eb7d556aecb@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aca2b5b075f87d108ce5f01a40238e2d4aa27bec
Author: Paul Kocialkowski <contact@paulk.fr>
Date:   Sat Oct 31 19:21:29 2020 +0100

    ARM: sunxi: Add machine match for the Allwinner V3 SoC
    
    [ Upstream commit ad2091f893bd5dfe2824f0d6819600d120698e9f ]
    
    The Allwinner V3 SoC shares the same base as the V3s but comes with
    extra pins and features available. As a result, it has its dedicated
    compatible string (already used in device trees), which is added here.
    
    Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20201031182137.1879521-2-contact@paulk.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0caa39f2c9d94cc1c0a5ff0940cb747651ba451c
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Dec 20 03:18:42 2020 +0900

    kconfig: fix return value of do_error_if()
    
    [ Upstream commit 135b4957eac43af2aedf8e2a277b9540f33c2558 ]
    
    $(error-if,...) is expanded to an empty string. Currently, it relies on
    eval_clause() returning xstrdup("") when all attempts for expansion fail,
    but the correct implementation is to make do_error_if() return xstrdup("").
    
    Fixes: 1d6272e6fe43 ("kconfig: add 'info', 'warning-if', and 'error-if' built-in functions")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adac0d69713deb2900bb886d79d65e61d634088b
Author: Jernej Skrabec <jernej.skrabec@siol.net>
Date:   Wed Dec 2 21:38:17 2020 +0100

    clk: sunxi-ng: Make sure divider tables have sentinel
    
    [ Upstream commit 48f68de00c1405351fa0e7bc44bca067c49cd0a3 ]
    
    Two clock divider tables are missing sentinel at the end. Effect of that
    is that clock framework reads past the last entry. Fix that with adding
    sentinel at the end.
    
    Issue was discovered with KASan.
    
    Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
    Fixes: c6a0637460c2 ("clk: sunxi-ng: Add A64 clocks")
    Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Link: https://lore.kernel.org/r/20201202203817.438713-1-jernej.skrabec@siol.net
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d02ee8817e73b5f368dd1b6908c821037a6cbba
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 12 13:28:18 2020 +0100

    clk: s2mps11: Fix a resource leak in error handling paths in the probe function
    
    [ Upstream commit d2d94fc567624f96187e8b52083795620f93e69f ]
    
    Some resource should be released in the error handling path of the probe
    function, as already done in the remove function.
    
    The remove function was fixed in commit bf416bd45738 ("clk: s2mps11: Add
    missing of_node_put and of_clk_del_provider")
    
    Fixes: 7cc560dea415 ("clk: s2mps11: Add support for s2mps11")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/20201212122818.86195-1-christophe.jaillet@wanadoo.fr
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c371bf491e00d94637e4cdb461b6f1619ad6443a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Dec 16 11:38:04 2020 +0300

    qlcnic: Fix error code in probe
    
    [ Upstream commit 0d52848632a357948028eab67ff9b7cc0c12a0fb ]
    
    Return -EINVAL if we can't find the correct device.  Currently it
    returns success.
    
    Fixes: 13159183ec7a ("qlcnic: 83xx base driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/X9nHbMqEyI/xPfGd@mwanda
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4281b2f75ffc5df34394b9157d9259aea9dcea2
Author: Zheng Zengkai <zhengzengkai@huawei.com>
Date:   Fri Jul 3 17:33:44 2020 +0800

    perf record: Fix memory leak when using '--user-regs=?' to list registers
    
    [ Upstream commit 2eb5dd418034ecea2f7031e3d33f2991a878b148 ]
    
    When using 'perf record's option '-I' or '--user-regs=' along with
    argument '?' to list available register names, memory of variable 'os'
    allocated by strdup() needs to be released before __parse_regs()
    returns, otherwise memory leak will occur.
    
    Fixes: bcc84ec65ad1 ("perf record: Add ability to name registers to record")
    Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
    Acked-by: Jiri Olsa <jolsa@redhat.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Li Bin <huawei.libin@huawei.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20200703093344.189450-1-zhengzengkai@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5992bce16a64662bb138237889201c30901c2dcf
Author: Lokesh Vutla <lokeshvutla@ti.com>
Date:   Fri Oct 30 19:11:35 2020 +0530

    pwm: lp3943: Dynamically allocate PWM chip base
    
    [ Upstream commit 1f0f1e80fdd3aa9631f6c22cda4f8550cfcfcc3e ]
    
    When there are other PWM controllers enabled along with pwm-lp3943,
    pwm-lp3942 is failing to probe with -EEXIST error. This is because
    other PWM controllers are probed first and assigned PWM base 0 and
    pwm-lp3943 is requesting for 0 again.
    
    In order to avoid this, assign the chip base with -1, so that it is
    dynamically allocated.
    
    Fixes: af66b3c0934e ("pwm: Add LP3943 PWM driver")
    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
    Reviewed-by: Uwe Kleine-König <u.kleine-könig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 550a7b7bba74f6a03f84e74c158bc0c72dd90eb6
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Tue Oct 13 10:13:21 2020 +0200

    pwm: zx: Add missing cleanup in error path
    
    [ Upstream commit 269effd03f6142df4c74814cfdd5f0b041b30bf9 ]
    
    zx_pwm_probe() called clk_prepare_enable() before; this must be undone
    in the error path.
    
    Fixes: 4836193c435c ("pwm: Add ZTE ZX PWM device driver")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 531d30493ddb26db900b666dd85b93dd3308b9b0
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Nov 13 21:16:23 2020 +0800

    clk: ti: Fix memleak in ti_fapll_synth_setup
    
    [ Upstream commit 8c6239f6e95f583bb763d0228e02d4dd0fb3d492 ]
    
    If clk_register fails, we should goto free branch
    before function returns to prevent memleak.
    
    Fixes: 163152cbbe321 ("clk: ti: Add support for FAPLL on dm816x")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201113131623.2098222-1-zhangqilong3@huawei.com
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18a78798b29cdb4ef7ef0abbdfbe469404da947b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 3 23:33:42 2020 +0100

    watchdog: coh901327: add COMMON_CLK dependency
    
    [ Upstream commit 36c47df85ee8e1f8a35366ac11324f8875de00eb ]
    
    clang produces a build failure in configurations without COMMON_CLK
    when a timeout calculation goes wrong:
    
    arm-linux-gnueabi-ld: drivers/watchdog/coh901327_wdt.o: in function `coh901327_enable':
    coh901327_wdt.c:(.text+0x50): undefined reference to `__bad_udelay'
    
    Add a Kconfig dependency to only do build testing when COMMON_CLK
    is enabled.
    
    Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20201203223358.1269372-1-arnd@kernel.org
    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 cd2b50aa0b2f0760ce3e0ff7a0cab808563f8db7
Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Date:   Mon Dec 7 11:30:05 2020 +0530

    watchdog: qcom: Avoid context switch in restart handler
    
    [ Upstream commit 7948fab26bcc468aa2a76462f441291b5fb0d5c7 ]
    
    The use of msleep() in the restart handler will cause scheduler to
    induce a context switch which is not desirable. This generates below
    warning on SDX55 when WDT is the only available restart source:
    
    [   39.800188] reboot: Restarting system
    [   39.804115] ------------[ cut here ]------------
    [   39.807855] WARNING: CPU: 0 PID: 678 at kernel/rcu/tree_plugin.h:297 rcu_note_context_switch+0x190/0x764
    [   39.812538] Modules linked in:
    [   39.821954] CPU: 0 PID: 678 Comm: reboot Not tainted 5.10.0-rc1-00063-g33a9990d1d66-dirty #47
    [   39.824854] Hardware name: Generic DT based system
    [   39.833470] [<c0310fbc>] (unwind_backtrace) from [<c030c544>] (show_stack+0x10/0x14)
    [   39.838154] [<c030c544>] (show_stack) from [<c0c218f0>] (dump_stack+0x8c/0xa0)
    [   39.846049] [<c0c218f0>] (dump_stack) from [<c0322f80>] (__warn+0xd8/0xf0)
    [   39.853058] [<c0322f80>] (__warn) from [<c0c1dc08>] (warn_slowpath_fmt+0x64/0xc8)
    [   39.859925] [<c0c1dc08>] (warn_slowpath_fmt) from [<c038b6f4>] (rcu_note_context_switch+0x190/0x764)
    [   39.867503] [<c038b6f4>] (rcu_note_context_switch) from [<c0c2aa3c>] (__schedule+0x84/0x640)
    [   39.876685] [<c0c2aa3c>] (__schedule) from [<c0c2b050>] (schedule+0x58/0x10c)
    [   39.885095] [<c0c2b050>] (schedule) from [<c0c2eed0>] (schedule_timeout+0x1e8/0x3d4)
    [   39.892135] [<c0c2eed0>] (schedule_timeout) from [<c039ad40>] (msleep+0x2c/0x38)
    [   39.899947] [<c039ad40>] (msleep) from [<c0a59d0c>] (qcom_wdt_restart+0xc4/0xcc)
    [   39.907319] [<c0a59d0c>] (qcom_wdt_restart) from [<c0a58290>] (watchdog_restart_notifier+0x18/0x28)
    [   39.914715] [<c0a58290>] (watchdog_restart_notifier) from [<c03468e0>] (atomic_notifier_call_chain+0x60/0x84)
    [   39.923487] [<c03468e0>] (atomic_notifier_call_chain) from [<c030ae64>] (machine_restart+0x78/0x7c)
    [   39.933551] [<c030ae64>] (machine_restart) from [<c0348048>] (__do_sys_reboot+0xdc/0x1e0)
    [   39.942397] [<c0348048>] (__do_sys_reboot) from [<c0300060>] (ret_fast_syscall+0x0/0x54)
    [   39.950721] Exception stack(0xc3e0bfa8 to 0xc3e0bff0)
    [   39.958855] bfa0:                   0001221c bed2fe24 fee1dead 28121969 01234567 00000000
    [   39.963832] bfc0: 0001221c bed2fe24 00000003 00000058 000225e0 00000000 00000000 00000000
    [   39.971985] bfe0: b6e62560 bed2fc84 00010fd8 b6e62580
    [   39.980124] ---[ end trace 3f578288bad866e4 ]---
    
    Hence, replace msleep() with mdelay() to fix this issue.
    
    Fixes: 05e487d905ab ("watchdog: qcom: register a restart notifier")
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20201207060005.21293-1-manivannan.sadhasivam@linaro.org
    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 4d3b5ddb7be74f853e090d45b4d57a20e4602394
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Sat Dec 5 19:50:56 2020 +0800

    libnvdimm/label: Return -ENXIO for no slot in __blk_label_update
    
    [ Upstream commit 4c46764733c85b82c07e9559b39da4d00a7dd659 ]
    
    Forget to set error code when nd_label_alloc_slot failed, and we
    add it to avoid overwritten error code.
    
    Fixes: 0ba1c634892b ("libnvdimm: write blk label set")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201205115056.2076523-1-zhangqilong3@huawei.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64db0fcb3fff1c58eef5a67429090aa48afb312a
Author: Vincent Stehlé <vincent.stehle@laposte.net>
Date:   Mon Dec 14 23:09:52 2020 +0100

    net: korina: fix return value
    
    [ Upstream commit 7eb000bdbe7c7da811ef51942b356f6e819b13ba ]
    
    The ndo_start_xmit() method must not attempt to free the skb to transmit
    when returning NETDEV_TX_BUSY. Therefore, make sure the
    korina_send_packet() function returns NETDEV_TX_OK when it frees a packet.
    
    Fixes: ef11291bcd5f ("Add support the Korina (IDT RC32434) Ethernet MAC")
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20201214220952.19935-1-vincent.stehle@laposte.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f013417209a6f01e0c5b34886b9f043d444b3e2c
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Dec 14 21:21:17 2020 +0100

    net: allwinner: Fix some resources leak in the error handling path of the probe and in the remove function
    
    [ Upstream commit 322e53d1e2529ae9d501f5e0f20604a79b873aef ]
    
    'irq_of_parse_and_map()' should be balanced by a corresponding
    'irq_dispose_mapping()' call. Otherwise, there is some resources leaks.
    
    Add such a call in the error handling path of the probe function and in the
    remove function.
    
    Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/20201214202117.146293-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fa570e8e1bfec861c173c5a850035540513d466
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 12 19:20:05 2020 +0100

    net: bcmgenet: Fix a resource leak in an error handling path in the probe functin
    
    [ Upstream commit 4375ada01963d1ebf733d60d1bb6e5db401e1ac6 ]
    
    If the 'register_netdev()' call fails, we must undo a previous
    'bcmgenet_mii_init()' call.
    
    Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20201212182005.120437-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c755c32c75ab1fcd7cdc292e8fe12c49170d676d
Author: Dwaipayan Ray <dwaipayanray1@gmail.com>
Date:   Tue Dec 15 20:45:02 2020 -0800

    checkpatch: fix unescaped left brace
    
    [ Upstream commit 03f4935135b9efeb780b970ba023c201f81cf4e6 ]
    
    There is an unescaped left brace in a regex in OPEN_BRACE check.  This
    throws a runtime error when checkpatch is run with --fix flag and the
    OPEN_BRACE check is executed.
    
    Fix it by escaping the left brace.
    
    Link: https://lkml.kernel.org/r/20201115202928.81955-1-dwaipayanray1@gmail.com
    Fixes: 8d1824780f2f ("checkpatch: add --fix option for a couple OPEN_BRACE misuses")
    Signed-off-by: Dwaipayan Ray <dwaipayanray1@gmail.com>
    Acked-by: Joe Perches <joe@perches.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 6bbf191f7403d819d4a3887d428241800b25acd3
Author: Vincent Stehlé <vincent.stehle@laposte.net>
Date:   Sun Dec 13 19:26:22 2020 +0100

    powerpc/ps3: use dma_mapping_error()
    
    [ Upstream commit d0edaa28a1f7830997131cbce87b6c52472825d1 ]
    
    The DMA address returned by dma_map_single() should be checked with
    dma_mapping_error(). Fix the ps3stor_setup() function accordingly.
    
    Fixes: 80071802cb9c ("[POWERPC] PS3: Storage Driver Core")
    Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201213182622.23047-1-vincent.stehle@laposte.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58263198150ff69deb5d54c0d120b10c4ebfebc6
Author: Bongsu Jeon <bongsu.jeon@samsung.com>
Date:   Sun Dec 13 18:58:50 2020 +0900

    nfc: s3fwrn5: Release the nfc firmware
    
    [ Upstream commit a4485baefa1efa596702ebffd5a9c760d42b14b5 ]
    
    add the code to release the nfc firmware when the firmware image size is
    wrong.
    
    Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
    Signed-off-by: Bongsu Jeon <bongsu.jeon@samsung.com>
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/20201213095850.28169-1-bongsu.jeon@samsung.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d33fa97d45bdc20e64352d3a80b3c229afcfe10
Author: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Date:   Mon Dec 7 17:19:40 2020 +0000

    um: chan_xterm: Fix fd leak
    
    [ Upstream commit 9431f7c199ab0d02da1482d62255e0b4621cb1b5 ]
    
    xterm serial channel was leaking a fd used in setting up the
    port helper
    
    This bug is prehistoric - it predates switching to git. The "fixes"
    header here is really just to mark all the versions we would like this to
    apply to which is "Anything from the Cretaceous period onwards".
    
    No dinosaurs were harmed in fixing this bug.
    
    Fixes: b40997b872cd ("um: drivers/xterm.c: fix a file descriptor leak")
    Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adddeb0ed1683d3880f182f25d7fbbace49c00e6
Author: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Date:   Mon Dec 7 17:19:39 2020 +0000

    um: tty: Fix handling of close in tty lines
    
    [ Upstream commit 9b1c0c0e25dcccafd30e7d4c150c249cc65550eb ]
    
    Fix a logical error in tty reading. We get 0 and errno == EAGAIN
    on the first attempt to read from a closed file descriptor.
    
    Compared to that a true EAGAIN is EAGAIN and -1.
    
    If we check errno for EAGAIN first, before checking the return
    value we miss the fact that the descriptor is closed.
    
    This bug is as old as the driver. It was not showing up with
    the original POLL based IRQ controller, because it was
    producing multiple events. Switching to EPOLL unmasked it.
    
    Fixes: ff6a17989c08 ("Epoll based IRQ controller")
    Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4629c75cb1e5476ae84ecd10aea2d5ec09c0695c
Author: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Date:   Mon Dec 7 17:19:38 2020 +0000

    um: Monitor error events in IRQ controller
    
    [ Upstream commit e3a01cbee9c5f2c6fc813dd6af007716e60257e7 ]
    
    Ensure that file closes, connection closes, etc are propagated
    as interrupts in the interrupt controller.
    
    Fixes: ff6a17989c08 ("Epoll based IRQ controller")
    Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5a958130b03c8b39fef88c6e616cd3b481b0671
Author: Wang Wensheng <wangwensheng4@huawei.com>
Date:   Mon Nov 9 13:05:12 2020 +0000

    watchdog: Fix potential dereferencing of null pointer
    
    [ Upstream commit 6f733cb2e7db38f8141b14740bcde577844a03b7 ]
    
    A reboot notifier, which stops the WDT by calling the stop hook without
    any check, would be registered when we set WDOG_STOP_ON_REBOOT flag.
    
    Howerer we allow the WDT driver to omit the stop hook since commit
    "d0684c8a93549" ("watchdog: Make stop function optional") and provide
    a module parameter for user that controls the WDOG_STOP_ON_REBOOT flag
    in commit 9232c80659e94 ("watchdog: Add stop_on_reboot parameter to
    control reboot policy"). Together that commits make user potential to
    insert a watchdog driver that don't provide a stop hook but with the
    stop_on_reboot parameter set, then dereferencing of null pointer occurs
    on system reboot.
    
    Check the stop hook before registering the reboot notifier to fix the
    issue.
    
    Fixes: d0684c8a9354 ("watchdog: Make stop function optional")
    Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20201109130512.28121-1-wangwensheng4@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e65c61ad99343d2e3d9bb207b9d4d0c83b4a2f94
Author: Lingling Xu <ling_ling.xu@unisoc.com>
Date:   Mon Nov 9 11:00:54 2020 +0800

    watchdog: sprd: check busy bit before new loading rather than after that
    
    [ Upstream commit 3e07d240939803bed9feb2a353d94686a411a7ca ]
    
    As the specification described, users must check busy bit before start
    a new loading operation to make sure that the previous loading is done
    and the device is ready to accept a new one.
    
    [ chunyan: Massaged changelog ]
    
    Fixes: 477603467009 ("watchdog: Add Spreadtrum watchdog driver")
    Signed-off-by: Lingling Xu <ling_ling.xu@unisoc.com>
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20201029023933.24548-3-zhang.lyra@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e62f759cdbabd160ce5490a53624aaf98e0d463
Author: Lingling Xu <ling_ling.xu@unisoc.com>
Date:   Thu Oct 29 10:39:31 2020 +0800

    watchdog: sprd: remove watchdog disable from resume fail path
    
    [ Upstream commit f61a59acb462840bebcc192f754fe71b6a16ff99 ]
    
    sprd_wdt_start() would return fail if the loading operation is not completed
    in a certain time, disabling watchdog for that case would probably cause
    the kernel crash when kick watchdog later, that's too bad, so remove the
    watchdog disable operation for the fail case to make sure other parts in
    the kernel can run normally.
    
    [ chunyan: Massaged changelog ]
    
    Fixes: 477603467009 ("watchdog: Add Spreadtrum watchdog driver")
    Signed-off-by: Lingling Xu <ling_ling.xu@unisoc.com>
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20201029023933.24548-2-zhang.lyra@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f85922a3e6bae5aa1446be9f02f87bb0e98f5e4b
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Nov 8 08:25:50 2020 -0800

    watchdog: sirfsoc: Add missing dependency on HAS_IOMEM
    
    [ Upstream commit 8ae2511112d2e18bc7d324b77f965d34083a25a2 ]
    
    If HAS_IOMEM is not defined and SIRFSOC_WATCHDOG is enabled,
    the build fails with the following error.
    
    drivers/watchdog/sirfsoc_wdt.o: in function `sirfsoc_wdt_probe':
    sirfsoc_wdt.c:(.text+0x112):
            undefined reference to `devm_platform_ioremap_resource'
    
    Reported-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
    Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
    Link: https://lore.kernel.org/r/20201108162550.27660-2-linux@roeck-us.net
    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 74f67af25132497299a5ec2b05203a98f2ec1b49
Author: Marc Zyngier <maz@kernel.org>
Date:   Sun Nov 29 13:55:25 2020 +0000

    irqchip/alpine-msi: Fix freeing of interrupts on allocation error path
    
    [ Upstream commit 3841245e8498a789c65dedd7ffa8fb2fee2c0684 ]
    
    The alpine-msi driver has an interesting allocation error handling,
    where it frees the same interrupts repeatedly. Hilarity follows.
    
    This code is probably never executed, but let's fix it nonetheless.
    
    Fixes: e6b78f2c3e14 ("irqchip: Add the Alpine MSIX interrupt controller")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Antoine Tenart <atenart@kernel.org>
    Cc: Tsahee Zidenberg <tsahee@annapurnalabs.com>
    Cc: Antoine Tenart <atenart@kernel.org>
    Link: https://lore.kernel.org/r/20201129135525.396671-1-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99ade218a3054746a943b3ec7ecc8b4168d09975
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Dec 9 09:54:09 2020 +0300

    ASoC: wm_adsp: remove "ctl" from list on error in wm_adsp_create_control()
    
    [ Upstream commit 85a7555575a0e48f9b73db310d0d762a08a46d63 ]
    
    The error handling frees "ctl" but it's still on the "dsp->ctl_list"
    list so that could result in a use after free.  Remove it from the list
    before returning.
    
    Fixes: 2323736dca72 ("ASoC: wm_adsp: Add basic support for rev 1 firmware file format")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/X9B0keV/02wrx9Xs@mwanda
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebbd7dc7ca856a182769c17c4c8a739cedc064c4
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sun Dec 6 14:54:44 2020 +0200

    mac80211: don't set set TDLS STA bandwidth wider than possible
    
    [ Upstream commit f65607cdbc6b0da356ef5a22552ddd9313cf87a0 ]
    
    When we set up a TDLS station, we set sta->sta.bandwidth solely based
    on the capabilities, because the "what's the current bandwidth" check
    is bypassed and only applied for other types of stations.
    
    This leads to the unfortunate scenario that the sta->sta.bandwidth is
    160 MHz if both stations support it, but we never actually configure
    this bandwidth unless the AP is already using 160 MHz; even for wider
    bandwidth support we only go up to 80 MHz (at least right now.)
    
    For iwlwifi, this can also lead to firmware asserts, telling us that
    we've configured the TX rates for a higher bandwidth than is actually
    available due to the PHY configuration.
    
    For non-TDLS, we check against the interface's requested bandwidth,
    but we explicitly skip this check for TDLS to cope with the wider BW
    case. Change this to
     (a) still limit to the TDLS peer's own chandef, which gets factored
         into the overall PHY configuration we request from the driver,
         and
     (b) limit it to when the TDLS peer is authorized, because it's only
         factored into the channel context in this case.
    
    Fixes: 504871e602d9 ("mac80211: fix bandwidth computation for TDLS peers")
    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.20201206145305.fcc7d29c4590.I11f77e9e25ddf871a3c8d5604650c763e2c5887a@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb4e0931040f9d9889112588666474286c59470b
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Tue Dec 8 14:36:27 2020 +0100

    extcon: max77693: Fix modalias string
    
    [ Upstream commit e1efdb604f5c9903a5d92ef42244009d3c04880f ]
    
    The platform device driver name is "max77693-muic", so advertise it
    properly in the modalias string. This fixes automated module loading when
    this driver is compiled as a module.
    
    Fixes: db1b9037424b ("extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 MUIC device")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73dcbf938b10c8e4680f65dff2951e8ea826c87c
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Mon Oct 26 01:42:12 2020 +0300

    clk: tegra: Fix duplicated SE clock entry
    
    [ Upstream commit 5bf5861d6ea6c3f4b38fc8fda2062b2dc44ac63d ]
    
    The periph_clks[] array contains duplicated entry for Security Engine
    clock which was meant to be defined for T210, but it wasn't added
    properly. This patch corrects the T210 SE entry and fixes the following
    error message on T114/T124: "Tegra clk 127: register failed with -17".
    
    Fixes: dc37fec48314 ("clk: tegra: periph: Add new periph clks and muxes for Tegra210")
    Tested-by Nicolas Chauvet <kwizart@gmail.com>
    Reported-by Nicolas Chauvet <kwizart@gmail.com>
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/20201025224212.7790-1-digetx@gmail.com
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9144c551fb0b5ecc89e5a728bda90e03345efde
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:02:47 2020 +0800

    bus: fsl-mc: fix error return code in fsl_mc_object_allocate()
    
    [ Upstream commit 3d70fb03711c37bc64e8e9aea5830f498835f6bf ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 197f4d6a4a00 ("staging: fsl-mc: fsl-mc object allocator driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Link: https://lore.kernel.org/r/1607068967-31991-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7524b26f2c580127ad3f795b5084b63b07b10cd8
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Oct 28 23:31:10 2020 +0900

    x86/kprobes: Restore BTF if the single-stepping is cancelled
    
    [ Upstream commit 78ff2733ff352175eb7f4418a34654346e1b6cd2 ]
    
    Fix to restore BTF if single-stepping causes a page fault and
    it is cancelled.
    
    Usually the BTF flag was restored when the single stepping is done
    (in resume_execution()). However, if a page fault happens on the
    single stepping instruction, the fault handler is invoked and
    the single stepping is cancelled. Thus, the BTF flag is not
    restored.
    
    Fixes: 1ecc798c6764 ("x86: debugctlmsr kprobes")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/160389546985.106936.12727996109376240993.stgit@devnote2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b1204d4d0cb9cefa59a32ce7a37d0d47c9eadc4
Author: Cheng Lin <cheng.lin130@zte.com.cn>
Date:   Tue Dec 1 07:06:35 2020 -0500

    nfs_common: need lock during iterate through the list
    
    [ Upstream commit 4a9d81caf841cd2c0ae36abec9c2963bf21d0284 ]
    
    If the elem is deleted during be iterated on it, the iteration
    process will fall into an endless loop.
    
    kernel: NMI watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [nfsd:17137]
    
    PID: 17137  TASK: ffff8818d93c0000  CPU: 4   COMMAND: "nfsd"
        [exception RIP: __state_in_grace+76]
        RIP: ffffffffc00e817c  RSP: ffff8818d3aefc98  RFLAGS: 00000246
        RAX: ffff881dc0c38298  RBX: ffffffff81b03580  RCX: ffff881dc02c9f50
        RDX: ffff881e3fce8500  RSI: 0000000000000001  RDI: ffffffff81b03580
        RBP: ffff8818d3aefca0   R8: 0000000000000020   R9: ffff8818d3aefd40
        R10: ffff88017fc03800  R11: ffff8818e83933c0  R12: ffff8818d3aefd40
        R13: 0000000000000000  R14: ffff8818e8391068  R15: ffff8818fa6e4000
        CS: 0010  SS: 0018
     #0 [ffff8818d3aefc98] opens_in_grace at ffffffffc00e81e3 [grace]
     #1 [ffff8818d3aefca8] nfs4_preprocess_stateid_op at ffffffffc02a3e6c [nfsd]
     #2 [ffff8818d3aefd18] nfsd4_write at ffffffffc028ed5b [nfsd]
     #3 [ffff8818d3aefd80] nfsd4_proc_compound at ffffffffc0290a0d [nfsd]
     #4 [ffff8818d3aefdd0] nfsd_dispatch at ffffffffc027b800 [nfsd]
     #5 [ffff8818d3aefe08] svc_process_common at ffffffffc02017f3 [sunrpc]
     #6 [ffff8818d3aefe70] svc_process at ffffffffc0201ce3 [sunrpc]
     #7 [ffff8818d3aefe98] nfsd at ffffffffc027b117 [nfsd]
     #8 [ffff8818d3aefec8] kthread at ffffffff810b88c1
     #9 [ffff8818d3aeff50] ret_from_fork at ffffffff816d1607
    
    The troublemake elem:
    crash> lock_manager ffff881dc0c38298
    struct lock_manager {
      list = {
        next = 0xffff881dc0c38298,
        prev = 0xffff881dc0c38298
      },
      block_opens = false
    }
    
    Fixes: c87fb4a378f9 ("lockd: NLM grace period shouldn't block NFSv4 opens")
    Signed-off-by: Cheng Lin <cheng.lin130@zte.com.cn>
    Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63a217e524773e63c127a140ec8d5f4f859b67a2
Author: kazuo ito <kzpn200@gmail.com>
Date:   Fri Nov 27 15:26:59 2020 +0900

    nfsd: Fix message level for normal termination
    
    [ Upstream commit 4420440c57892779f265108f46f83832a88ca795 ]
    
    The warning message from nfsd terminating normally
    can confuse system adminstrators or monitoring software.
    
    Though it's not exactly fair to pin-point a commit where it
    originated, the current form in the current place started
    to appear in:
    
    Fixes: e096bbc6488d ("knfsd: remove special handling for SIGHUP")
    Signed-off-by: kazuo ito <kzpn200@gmail.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e4e6acbdfcb7c654af259ce3e7f4081d36fb710
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 17 09:22:29 2020 +0800

    speakup: fix uninitialized flush_lock
    
    [ Upstream commit d1b928ee1cfa965a3327bbaa59bfa005d97fa0fe ]
    
    The flush_lock is uninitialized, use DEFINE_SPINLOCK
    to define and initialize flush_lock.
    
    Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20201117012229.3395186-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5c76864e3144420bc996281a04e041efabae3c1
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 23 22:58:09 2020 +0800

    usb: oxu210hp-hcd: Fix memory leak in oxu_create
    
    [ Upstream commit e5548b05631ec3e6bfdaef1cad28c799545b791b ]
    
    usb_create_hcd will alloc memory for hcd, and we should
    call usb_put_hcd to free it when adding fails to prevent
    memory leak.
    
    Fixes: b92a78e582b1a ("usb host: Oxford OXU210HP HCD driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201123145809.1456541-1-zhangqilong3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed0027a801f0ec5136f426b803f29f9e85d99863
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 23 22:57:19 2020 +0800

    usb: ehci-omap: Fix PM disable depth umbalance in ehci_hcd_omap_probe
    
    [ Upstream commit d6ff32478d7e95d6ca199b5c852710d6964d5811 ]
    
    The pm_runtime_enable will decrement the power disable depth. Imbalance
    depth will resulted in enabling runtime PM of device fails later.  Thus
    a pairing decrement must be needed on the error handling path to keep it
    balanced.
    
    Fixes: 6c984b066d84b ("ARM: OMAP: USBHOST: Replace usbhs core driver APIs by Runtime pm APIs")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201123145719.1455849-1-zhangqilong3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c26c10f28528e061b31cecca98b13c0c4546cc00
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Mon Dec 7 15:51:56 2020 -0600

    powerpc/pseries/hibernation: remove redundant cacheinfo update
    
    [ Upstream commit b866459489fe8ef0e92cde3cbd6bbb1af6c4e99b ]
    
    Partitions with cache nodes in the device tree can encounter the
    following warning on resume:
    
    CPU 0 already accounted in PowerPC,POWER9@0(Data)
    WARNING: CPU: 0 PID: 3177 at arch/powerpc/kernel/cacheinfo.c:197 cacheinfo_cpu_online+0x640/0x820
    
    These calls to cacheinfo_cpu_offline/online have been redundant since
    commit e610a466d16a ("powerpc/pseries/mobility: rebuild cacheinfo
    hierarchy post-migration").
    
    Fixes: e610a466d16a ("powerpc/pseries/mobility: rebuild cacheinfo hierarchy post-migration")
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201207215200.1785968-25-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6495fddfcaa8b220358b24609cd9b12bd76a6ff5
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Mon Dec 7 15:51:49 2020 -0600

    powerpc/pseries/hibernation: drop pseries_suspend_begin() from suspend ops
    
    [ Upstream commit 52719fce3f4c7a8ac9eaa191e8d75a697f9fbcbc ]
    
    There are three ways pseries_suspend_begin() can be reached:
    
    1. When "mem" is written to /sys/power/state:
    
    kobj_attr_store()
    -> state_store()
      -> pm_suspend()
        -> suspend_devices_and_enter()
          -> pseries_suspend_begin()
    
    This never works because there is no way to supply a valid stream id
    using this interface, and H_VASI_STATE is called with a stream id of
    zero. So this call path is useless at best.
    
    2. When a stream id is written to /sys/devices/system/power/hibernate.
    pseries_suspend_begin() is polled directly from store_hibernate()
    until the stream is in the "Suspending" state (i.e. the platform is
    ready for the OS to suspend execution):
    
    dev_attr_store()
    -> store_hibernate()
      -> pseries_suspend_begin()
    
    3. When a stream id is written to /sys/devices/system/power/hibernate
    (continued). After #2, pseries_suspend_begin() is called once again
    from the pm core:
    
    dev_attr_store()
    -> store_hibernate()
      -> pm_suspend()
        -> suspend_devices_and_enter()
          -> pseries_suspend_begin()
    
    This is redundant because the VASI suspend state is already known to
    be Suspending.
    
    The begin() callback of platform_suspend_ops is optional, so we can
    simply remove that assignment with no loss of function.
    
    Fixes: 32d8ad4e621d ("powerpc/pseries: Partition hibernation support")
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201207215200.1785968-18-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5597be8b4bca241000046e932f24a2bfa79fecd7
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Mon Dec 7 19:47:44 2020 +0200

    platform/x86: mlx-platform: Fix item counter assignment for MSN2700, MSN24xx systems
    
    [ Upstream commit ba4939f1dd46dde08c2f9b9d7ac86ed3ea7ead86 ]
    
    Fix array names to match assignments for data items and data items
    counter in 'mlxplat_mlxcpld_default_items' structure for:
            .data = mlxplat_mlxcpld_default_pwr_items_data,
            .count = ARRAY_SIZE(mlxplat_mlxcpld_pwr),
    and
            .data = mlxplat_mlxcpld_default_fan_items_data,
            .count = ARRAY_SIZE(mlxplat_mlxcpld_fan),
    
    Replace:
    - 'mlxplat_mlxcpld_pwr' by 'mlxplat_mlxcpld_default_pwr_items_data' for
       ARRAY_SIZE() calculation.
    - 'mlxplat_mlxcpld_fan' by 'mlxplat_mlxcpld_default_fan_items_data'
       for ARRAY_SIZE() calculation.
    
    Fixes: c6acad68eb2d ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface")
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Link: https://lore.kernel.org/r/20201207174745.22889-2-vadimp@nvidia.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c9001f82b4c7b85ea98f3564725bfd9cf4a1eec
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 15:47:39 2020 +0800

    scsi: fnic: Fix error return code in fnic_probe()
    
    [ Upstream commit d4fc94fe65578738ded138e9fce043db6bfc3241 ]
    
    Return a negative error code from the error handling case instead of 0 as
    done elsewhere in this function.
    
    Link: https://lore.kernel.org/r/1607068060-31203-1-git-send-email-zhangchangzhong@huawei.com
    Fixes: 5df6d737dd4b ("[SCSI] fnic: Add new Cisco PCI-Express FCoE HBA")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Reviewed-by: Karan Tilak Kumar <kartilak@cisco.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d494ddccf25feebbc6f4fc63f7d83322ad1488a0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 26 17:10:58 2020 +0100

    seq_buf: Avoid type mismatch for seq_buf_init
    
    [ Upstream commit d9a9280a0d0ae51dc1d4142138b99242b7ec8ac6 ]
    
    Building with W=2 prints a number of warnings for one function that
    has a pointer type mismatch:
    
    linux/seq_buf.h: In function 'seq_buf_init':
    linux/seq_buf.h:35:12: warning: pointer targets in assignment from 'unsigned char *' to 'char *' differ in signedness [-Wpointer-sign]
    
    Change the type in the function prototype according to the type in
    the structure.
    
    Link: https://lkml.kernel.org/r/20201026161108.3707783-1-arnd@kernel.org
    
    Fixes: 9a7777935c34 ("tracing: Convert seq_buf fields to be like seq_file fields")
    Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7b0f1f74a46917f942b82496fbf68f47b406ead
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Sat Dec 5 19:55:51 2020 +0800

    scsi: pm80xx: Fix error return in pm8001_pci_probe()
    
    [ Upstream commit 97031ccffa4f62728602bfea8439dd045cd3aeb2 ]
    
    The driver did not return an error in the case where
    pm8001_configure_phy_settings() failed.
    
    Use rc to store the return value of pm8001_configure_phy_settings().
    
    Link: https://lore.kernel.org/r/20201205115551.2079471-1-zhangqilong3@huawei.com
    Fixes: 279094079a44 ("[SCSI] pm80xx: Phy settings support for motherboard controller.")
    Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d9b8ab3b8368e147930e81e47271cd2e41e089b
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Mon Nov 9 17:15:18 2020 +0800

    scsi: qedi: Fix missing destroy_workqueue() on error in __qedi_probe
    
    [ Upstream commit 62eebd5247c4e4ce08826ad5995cf4dd7ce919dd ]
    
    Add the missing destroy_workqueue() before return from __qedi_probe in the
    error handling case when fails to create workqueue qedi->offload_thread.
    
    Link: https://lore.kernel.org/r/20201109091518.55941-1-miaoqinglang@huawei.com
    Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.")
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 163426bf46d30769c3a04d45b0e4b8d9a011306a
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:38 2020 +0100

    cpufreq: scpi: Add missing MODULE_ALIAS
    
    [ Upstream commit c0382d049d2def37b81e907a8b22661a4a4a6eb5 ]
    
    This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq
    driver when it is compiled as an external module.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: 8def31034d033 ("cpufreq: arm_big_little: add SCPI interface driver")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3042178be0a0a0d30541ca8c9a884b97774b999
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:37 2020 +0100

    cpufreq: loongson1: Add missing MODULE_ALIAS
    
    [ Upstream commit b9acab091842ca8b288882798bb809f7abf5408a ]
    
    This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq
    driver when it is compiled as an external module.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: a0a22cf14472f ("cpufreq: Loongson1: Add cpufreq driver for Loongson1B")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e08d6439dba96e9ce50d94ea06c50813a22ac49
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:35 2020 +0100

    cpufreq: st: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 183747ab52654eb406fc6b5bfb40806b75d31811 ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this cpufreq driver when it is
    compiled as an external module.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: ab0ea257fc58d ("cpufreq: st: Provide runtime initialised driver for ST's platforms")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49696897ee96e1654c4aecbd78674974d2d8abfe
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:33 2020 +0100

    cpufreq: mediatek: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit af6eca06501118af3e2ad46eee8edab20624b74e ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this cpufreq driver when it is
    compiled as an external module.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: 501c574f4e3a5 ("cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d7945618be39bac400c021f8a66c226ea4923d9
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:32 2020 +0100

    cpufreq: highbank: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 9433777a6e0aae27468d3434b75cd51bb88ff711 ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this cpufreq driver when it is
    compiled as an external module.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: 6754f556103be ("cpufreq / highbank: add support for highbank cpufreq")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21253ff57b2c953aba6d4615fd185431bf6ff4cc
Author: Keqian Zhu <zhukeqian1@huawei.com>
Date:   Fri Dec 4 15:31:26 2020 +0800

    clocksource/drivers/arm_arch_timer: Correct fault programming of CNTKCTL_EL1.EVNTI
    
    [ Upstream commit 8b7770b877d187bfdae1eaf587bd2b792479a31c ]
    
    ARM virtual counter supports event stream, it can only trigger an event
    when the trigger bit (the value of CNTKCTL_EL1.EVNTI) of CNTVCT_EL0 changes,
    so the actual period of event stream is 2^(cntkctl_evnti + 1). For example,
    when the trigger bit is 0, then virtual counter trigger an event for every
    two cycles.
    
    While we're at it, rework the way we compute the trigger bit position
    by making it more obvious that when bits [n:n-1] are both set (with n
    being the most significant bit), we pick bit (n + 1).
    
    Fixes: 037f637767a8 ("drivers: clocksource: add support for ARM architected timer event stream")
    Suggested-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20201204073126.6920-3-zhukeqian1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef6082dfafdbfcf2eb7b3077f56f02871a9cc2c8
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Sat Nov 28 18:19:59 2020 +0800

    dm ioctl: fix error return code in target_message
    
    [ Upstream commit 4d7659bfbe277a43399a4a2d90fca141e70f29e1 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 2ca4c92f58f9 ("dm ioctl: prevent empty message")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9b158b58f213d76f5c0b25b3885b63136b74511
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Thu Dec 3 22:42:27 2020 +0800

    ASoC: jz4740-i2s: add missed checks for clk_get()
    
    [ Upstream commit 1c1fb2653a0c2e3f310c07eacd8fc3a10e08c97a ]
    
    jz4740_i2s_set_sysclk() does not check the return values of clk_get(),
    while the file dereferences the pointers in clk_put().
    Add the missed checks to fix it.
    
    Fixes: 11bd3dd1b7c2 ("ASoC: Add JZ4740 ASoC support")
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Link: https://lore.kernel.org/r/20201203144227.418194-1-hslester96@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 949a49c8dad024489a202565f9e88cd027811ddc
Author: Leon Romanovsky <leon@kernel.org>
Date:   Thu Oct 15 14:52:00 2020 +0300

    net/mlx5: Properly convey driver version to firmware
    
    [ Upstream commit 907af0f0cab4ee5d5604f182ecec2c5b5119d294 ]
    
    mlx5 firmware expects driver version in specific format X.X.X, so
    make it always correct and based on real kernel version aligned with
    the driver.
    
    Fixes: 012e50e109fd ("net/mlx5: Set driver version into firmware")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1275c009c10c2a2e4a451c1c1b62456770ed7ba
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Wed Nov 25 09:47:18 2020 +0800

    memstick: r592: Fix error return in r592_probe()
    
    [ Upstream commit db29d3d1c2451e673e29c7257471e3ce9d50383a ]
    
    Fix to return a error code from the error handling case instead of 0.
    
    Fixes: 926341250102 ("memstick: add driver for Ricoh R5C592 card reader")
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Link: https://lore.kernel.org/r/20201125014718.153563-1-jingxiangfeng@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c13ad4f26b01805011c90a6680570da2fe159553
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Fri Dec 4 14:48:05 2020 +0800

    arm64: dts: rockchip: Fix UART pull-ups on rk3328
    
    [ Upstream commit 94dad6bed3c86c00050bf7c2b2ad6b630facae31 ]
    
    For UARTs, the local pull-ups should be on the RX pin, not the TX pin.
    UARTs transmit active-low, so a disconnected RX pin should be pulled
    high instead of left floating to prevent noise being interpreted as
    transmissions.
    
    This gets rid of bogus sysrq events when the UART console is not
    connected.
    
    Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20201204064805.6480-1-wens@kernel.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59f9efc349335a8a7b0481627fd6850e722fe523
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Nov 19 09:12:19 2020 +0800

    pinctrl: falcon: add missing put_device() call in pinctrl_falcon_probe()
    
    [ Upstream commit 89cce2b3f247a434ee174ab6803698041df98014 ]
    
    if of_find_device_by_node() succeed, pinctrl_falcon_probe() doesn't have
    a corresponding put_device(). Thus add put_device() to fix the exception
    handling for this function implementation.
    
    Fixes: e316cb2b16bb ("OF: pinctrl: MIPS: lantiq: adds support for FALCON SoC")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20201119011219.2248232-1-yukuai3@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3d3a8e7ab782928753818500165d64b9667f726
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Wed Dec 2 11:57:05 2020 +0200

    ARM: dts: at91: sama5d2: map securam as device
    
    [ Upstream commit 9b5dcc8d427e2bcb84c49eb03ffefe11e7537a55 ]
    
    Due to strobe signal not being propagated from CPU to securam
    the securam needs to be mapped as device or strongly ordered memory
    to work properly. Otherwise, updating to one offset may affect
    the adjacent locations in securam.
    
    Fixes: d4ce5f44d4409 ("ARM: dts: at91: sama5d2: Add securam node")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Link: https://lore.kernel.org/r/1606903025-14197-3-git-send-email-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 058656355dea56f7383fc68649fa7b2cdb2193dc
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Mon Nov 16 21:51:23 2020 +0800

    clocksource/drivers/cadence_ttc: Fix memory leak in ttc_setup_clockevent()
    
    [ Upstream commit eee422c46e6840a81c9db18a497b74387a557b29 ]
    
    If clk_notifier_register() failed, ttc_setup_clockevent() will return
    without freeing 'ttcce', which will leak memory.
    
    Fixes: 70504f311d4b ("clocksource/drivers/cadence_ttc: Convert init function to return error")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20201116135123.2164033-1-yukuai3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 062f9718dca50019a9e13dad4037b4a293e6c57d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Nov 17 08:23:40 2020 +0100

    media: saa7146: fix array overflow in vidioc_s_audio()
    
    [ Upstream commit 8e4d86e241cf035d6d3467cd346e7ce490681937 ]
    
    The "a->index" value comes from the user via the ioctl.  The problem is
    that the shift can wrap resulting in setting "mxb->cur_audinput" to an
    invalid value, which later results in an array overflow.
    
    Fixes: 6680427791c9 ("[media] mxb: fix audio handling")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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 bb3130192ff9333f93ca02cb6f17144cf55ba4d8
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Thu Nov 5 12:34:58 2020 -0400

    vfio-pci: Use io_remap_pfn_range() for PCI IO memory
    
    [ Upstream commit 7b06a56d468b756ad6bb43ac21b11e474ebc54a0 ]
    
    commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set
    pgprot_decrypted()") allows drivers using mmap to put PCI memory mapped
    BAR space into userspace to work correctly on AMD SME systems that default
    to all memory encrypted.
    
    Since vfio_pci_mmap_fault() is working with PCI memory mapped BAR space it
    should be calling io_remap_pfn_range() otherwise it will not work on SME
    systems.
    
    Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Acked-by: Peter Xu <peterx@redhat.com>
    Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5c43265c6244ce6df26b0c7a3d7f69449fb1a0a
Author: NeilBrown <neilb@suse.de>
Date:   Fri Nov 27 11:24:33 2020 +1100

    NFS: switch nfsiod to be an UNBOUND workqueue.
    
    [ Upstream commit bf701b765eaa82dd164d65edc5747ec7288bb5c3 ]
    
    nfsiod is currently a concurrency-managed workqueue (CMWQ).
    This means that workitems scheduled to nfsiod on a given CPU are queued
    behind all other work items queued on any CMWQ on the same CPU.  This
    can introduce unexpected latency.
    
    Occaionally nfsiod can even cause excessive latency.  If the work item
    to complete a CLOSE request calls the final iput() on an inode, the
    address_space of that inode will be dismantled.  This takes time
    proportional to the number of in-memory pages, which on a large host
    working on large files (e.g..  5TB), can be a large number of pages
    resulting in a noticable number of seconds.
    
    We can avoid these latency problems by switching nfsiod to WQ_UNBOUND.
    This causes each concurrent work item to gets a dedicated thread which
    can be scheduled to an idle CPU.
    
    There is precedent for this as several other filesystems use WQ_UNBOUND
    workqueue for handling various async events.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Fixes: ada609ee2ac2 ("workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea5569c61da9644fdee4700f0461a560c84d06b7
Author: Calum Mackay <calum.mackay@oracle.com>
Date:   Wed Oct 28 20:16:27 2020 +0000

    lockd: don't use interval-based rebinding over TCP
    
    [ Upstream commit 9b82d88d5976e5f2b8015d58913654856576ace5 ]
    
    NLM uses an interval-based rebinding, i.e. it clears the transport's
    binding under certain conditions if more than 60 seconds have elapsed
    since the connection was last bound.
    
    This rebinding is not necessary for an autobind RPC client over a
    connection-oriented protocol like TCP.
    
    It can also cause problems: it is possible for nlm_bind_host() to clear
    XPRT_BOUND whilst a connection worker is in the middle of trying to
    reconnect, after it had already been checked in xprt_connect().
    
    When the connection worker notices that XPRT_BOUND has been cleared
    under it, in xs_tcp_finish_connecting(), that results in:
    
            xs_tcp_setup_socket: connect returned unhandled error -107
    
    Worse, it's possible that the two can get into lockstep, resulting in
    the same behaviour repeated indefinitely, with the above error every
    300 seconds, without ever recovering, and the connection never being
    established. This has been seen in practice, with a large number of NLM
    client tasks, following a server restart.
    
    The existing callers of nlm_bind_host & nlm_rebind_host should not need
    to force the rebind, for TCP, so restrict the interval-based rebinding
    to UDP only.
    
    For TCP, we will still rebind when needed, e.g. on timeout, and connection
    error (including closure), since connection-related errors on an existing
    connection, ECONNREFUSED when trying to connect, and rpc_check_timeout(),
    already unconditionally clear XPRT_BOUND.
    
    To avoid having to add the fix, and explanation, to both nlm_bind_host()
    and nlm_rebind_host(), remove the duplicate code from the former, and
    have it call the latter.
    
    Drop the dprintk, which adds no value over a trace.
    
    Signed-off-by: Calum Mackay <calum.mackay@oracle.com>
    Fixes: 35f5a422ce1a ("SUNRPC: new interface to force an RPC rebind")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99bba785816dcfa122fcfc3872dc25b7ff82da4e
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Nov 6 16:33:38 2020 -0500

    SUNRPC: xprt_load_transport() needs to support the netid "rdma6"
    
    [ Upstream commit d5aa6b22e2258f05317313ecc02efbb988ed6d38 ]
    
    According to RFC5666, the correct netid for an IPv6 addressed RDMA
    transport is "rdma6", which we've supported as a mount option since
    Linux-4.7. The problem is when we try to load the module "xprtrdma6",
    that will fail, since there is no modulealias of that name.
    
    Fixes: 181342c5ebe8 ("xprtrdma: Add rdma6 option to support NFS/RDMA IPv6")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cdde54b6099025db7e870d81ff6e4bb8c98e950
Author: Olga Kornievskaia <kolga@netapp.com>
Date:   Fri Nov 6 16:03:38 2020 -0500

    NFSv4.2: condition READDIR's mask for security label based on LSM state
    
    [ Upstream commit 05ad917561fca39a03338cb21fe9622f998b0f9c ]
    
    Currently, the client will always ask for security_labels if the server
    returns that it supports that feature regardless of any LSM modules
    (such as Selinux) enforcing security policy. This adds performance
    penalty to the READDIR operation.
    
    Client adjusts superblock's support of the security_label based on
    the server's support but also current client's configuration of the
    LSM modules. Thus, prior to using the default bitmask in READDIR,
    this patch checks the server's capabilities and then instructs
    READDIR to remove FATTR4_WORD2_SECURITY_LABEL from the bitmask.
    
    v5: fixing silly mistakes of the rushed v4
    v4: simplifying logic
    v3: changing label's initialization per Ondrej's comment
    v2: dropping selinux hook and using the sb cap.
    
    Suggested-by: Ondrej Mosnacek <omosnace@redhat.com>
    Suggested-by: Scott Mayhew <smayhew@redhat.com>
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Fixes: 2b0143b5c986 ("VFS: normal filesystems (and lustre): d_inode() annotations")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd2c756eb1b700c0635462536540eb4bec1729c8
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Nov 24 17:59:18 2020 +0200

    ath10k: Release some resources in an error handling path
    
    [ Upstream commit 6364e693f4a7a89a2fb3dd2cbd6cc06d5fd6e26d ]
    
    Should an error occur after calling 'ath10k_usb_create()', it should be
    undone by a corresponding 'ath10k_usb_destroy()' call
    
    Fixes: 4db66499df91 ("ath10k: add initial USB support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201122170358.1346065-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 682a73cdc9cd1557d45478ec8c8d8671302c3b49
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Nov 24 17:59:18 2020 +0200

    ath10k: Fix an error handling path
    
    [ Upstream commit ed3573bc3943c27d2d8e405a242f87ed14572ca1 ]
    
    If 'ath10k_usb_create()' fails, we should release some resources and report
    an error instead of silently continuing.
    
    Fixes: 4db66499df91 ("ath10k: add initial USB support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201122170342.1346011-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e36d0ca5e10e3c9b612ab3d8f03c3b37d7918f8
Author: Rakesh Pillai <pillair@codeaurora.org>
Date:   Tue Nov 24 17:59:17 2020 +0200

    ath10k: Fix the parsing error in service available event
    
    [ Upstream commit c7cee9c0f499f27ec6de06bea664b61320534768 ]
    
    The wmi service available event has been
    extended to contain extra 128 bit for new services
    to be indicated by firmware.
    
    Currently the presence of any optional TLVs in
    the wmi service available event leads to a parsing
    error with the below error message:
    ath10k_snoc 18800000.wifi: failed to parse svc_avail tlv: -71
    
    The wmi service available event parsing should
    not return error for the newly added optional TLV.
    Fix this parsing for service available event message.
    
    Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2-00720-QCAHLSWMTPL-1
    
    Fixes: cea19a6ce8bf ("ath10k: add WMI_SERVICE_AVAILABLE_EVENT support")
    Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1605501291-23040-1-git-send-email-pillair@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99d45dac0b6dc80bf901309431d4159d0c2ba10a
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Wed Nov 25 14:50:32 2020 +0800

    platform/x86: dell-smbios-base: Fix error return code in dell_smbios_init
    
    [ Upstream commit 2425ccd30fd78ce35237350fe8baac31dc18bd45 ]
    
    Fix to return the error code -ENODEV when fails to init wmi and
    smm.
    
    Fixes: 41e36f2f85af ("platform/x86: dell-smbios: Link all dell-smbios-* modules together")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
    Link: https://lore.kernel.org/r/20201125065032.154125-1-miaoqinglang@huawei.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b18acf183b8f031e5b7618d8c6f3000d3e3977c
Author: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date:   Sat Nov 28 23:28:17 2020 +0100

    ARM: dts: at91: at91sam9rl: fix ADC triggers
    
    [ Upstream commit 851a95da583c26e2ddeb7281e9b61f0d76ea5aba ]
    
    The triggers for the ADC were taken from at91sam9260 dtsi but are not
    correct.
    
    Fixes: a4c1d6c75822 ("ARM: at91/dt: sam9rl: add lcd, adc, usb gadget and pwm support")
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20201128222818.1910764-10-alexandre.belloni@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dee66fe0627426901ce12086867008040e10b1c0
Author: Artem Lapkin <art@khadas.com>
Date:   Wed Nov 25 02:40:01 2020 +0000

    arm64: dts: meson: fix spi-max-frequency on Khadas VIM2
    
    [ Upstream commit b6c605e00ce8910d7ec3d9a54725d78b14db49b9 ]
    
    The max frequency for the w25q32 (VIM v1.2) and w25q128 (VIM v1.4) spifc
    chip should be 104Mhz not 30MHz.
    
    Fixes: b8b74dda3908 ("ARM64: dts: meson-gxm: Add support for Khadas VIM2")
    Signed-off-by: Artem Lapkin <art@khadas.com>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/20201125024001.19036-1-christianshewitt@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06773ce45d65c74c0aebdd766fbc3a916546d4ba
Author: Bharat Gooty <bharat.gooty@broadcom.com>
Date:   Thu Oct 1 11:30:52 2020 +0530

    PCI: iproc: Fix out-of-bound array accesses
    
    [ Upstream commit a3ff529f5d368a17ff35ada8009e101162ebeaf9 ]
    
    Declare the full size array for all revisions of PAX register sets
    to avoid potentially out of bound access of the register array
    when they are being initialized in iproc_pcie_rev_init().
    
    Link: https://lore.kernel.org/r/20201001060054.6616-2-srinath.mannam@broadcom.com
    Fixes: 06324ede76cdf ("PCI: iproc: Improve core register population")
    Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9817c8cf22f750f3547962544d4ae4e5d28c93c
Author: Colin Ian King <colin.king@canonical.com>
Date:   Sat Nov 14 15:48:04 2020 -0600

    PCI: Fix overflow in command-line resource alignment requests
    
    [ Upstream commit cc73eb321d246776e5a9f7723d15708809aa3699 ]
    
    The shift of 1 by align_order is evaluated using 32 bit arithmetic and the
    result is assigned to a resource_size_t type variable that is a 64 bit
    unsigned integer on 64 bit platforms. Fix an overflow before widening issue
    by making the 1 a ULL.
    
    Addresses-Coverity: ("Unintentional integer overflow")
    Fixes: 32a9a682bef2 ("PCI: allow assignment of memory resources with a specified alignment")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d7483c6434f1da19b0140bd4d62c7e18a26ffa6
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Nov 5 14:51:36 2020 -0600

    PCI: Bounds-check command-line resource alignment requests
    
    [ Upstream commit 6534aac198b58309ff2337981d3f893e0be1d19d ]
    
    32-bit BARs are limited to 2GB size (2^31).  By extension, I assume 64-bit
    BARs are limited to 2^63 bytes.  Limit the alignment requested by the
    "pci=resource_alignment=" command-line parameter to 2^63.
    
    Link: https://lore.kernel.org/r/20201007123045.GS4282@kadam
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4763ddb834462097ff818a8dcae2c545c0d5ba1a
Author: Marc Zyngier <maz@kernel.org>
Date:   Sun Nov 29 13:55:51 2020 +0000

    genirq/irqdomain: Don't try to free an interrupt that has no mapping
    
    [ Upstream commit 4615fbc3788ddc8e7c6d697714ad35a53729aa2c ]
    
    When an interrupt allocation fails for N interrupts, it is pretty
    common for the error handling code to free the same number of interrupts,
    no matter how many interrupts have actually been allocated.
    
    This may result in the domain freeing code to be unexpectedly called
    for interrupts that have no mapping in that domain. Things end pretty
    badly.
    
    Instead, add some checks to irq_domain_free_irqs_hierarchy() to make sure
    that thiss does not follow the hierarchy if no mapping exists for a given
    interrupt.
    
    Fixes: 6a6544e520abe ("genirq/irqdomain: Remove auto-recursive hierarchy support")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20201129135551.396777-1-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 281be921e2dc84e978ae043699bd364657383356
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 22:33:21 2020 +0800

    power: supply: bq24190_charger: fix reference leak
    
    [ Upstream commit b2f6cb78eaa1cad57dd3fe11d0458cd4fae9a584 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to call pm_runtime_put_noidle will result
    in reference leak in callers(bq24190_sysfs_show,
    bq24190_charger_get_property, bq24190_charger_set_property,
    bq24190_battery_get_property, bq24190_battery_set_property),
    so we should fix it.
    
    Fixes: f385e6e2a1532 ("power: bq24190_charger: Use PM runtime autosuspend")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e17354a34dd59140f2d34020a44b39384d42e9a
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Nov 18 13:13:12 2020 +0100

    power: supply: axp288_charger: Fix HP Pavilion x2 10 DMI matching
    
    [ Upstream commit a0f1ccd96c7049377d892a4299b6d5e47ec9179d ]
    
    Commit 9c80662a74cd ("power: supply: axp288_charger: Add special handling
    for HP Pavilion x2 10") added special handling for HP Pavilion x2 10
    models which use the weird combination of a Type-C connector and the
    non Type-C aware AXP288 PMIC.
    
    This special handling was activated by a DMI match a the product-name
    of "HP Pavilion x2 Detachable". Recently I've learned that there are
    also older "HP Pavilion x2 Detachable" models with an AXP288 PMIC +
    a micro-usb connector where we should not activate the special handling
    for the Type-C connectors.
    
    Extend the matching to also match on the DMI board-name and match on the
    2 boards (one Bay Trail based one Cherry Trail based) of which we are
    certain that they use the AXP288 + Type-C connector combination.
    
    Note the DSDT code from these older (AXP288 + micro-USB) models contains
    some AML code (which never runs under Linux) which reads the micro-USB
    connector id-pin and if it is pulled to ground, which would normally mean
    the port is in host mode!, then it sets the input-current-limit to 3A,
    it seems HP is using the micro-USB port as a charging only connector
    and identifies their own 3A capable charger though this hack which is a
    major violation of the USB specs. Note HP also hardcodes a 2A limit
    when the id-pin is not pulled to ground, which is also in violation
    of the specs.
    
    I've no intention to add support for HP's hack to support 3A charging
    on these older models. By making the DMI matches for the Type-C equipped
    models workaround more tighter, these older models will be treated just
    like any other AXP288 + micro-USB equipped device and the input-current
    limit will follow the BC 1.2 spec (using the defacto standard values
    there where the BC 1.2 spec defines a range).
    
    Fixes: 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10")
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1896924
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d42d28457bb9391e7574ddb89c3368855c0dc7b
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Thu Nov 26 15:33:34 2020 +0800

    arm64: dts: rockchip: Set dr_mode to "host" for OTG on rk3328-roc-cc
    
    [ Upstream commit 4076a007bd0f6171434bdb119a0b8797749b0502 ]
    
    The board has a standard USB A female port connected to the USB OTG
    controller's data pins. Set dr_mode in the OTG controller node to
    indicate this usage, instead of having the implementation guess.
    
    Fixes: 2171f4fdac06 ("arm64: dts: rockchip: add roc-rk3328-cc board")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20201126073336.30794-2-wens@kernel.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83b70d72e544103af9abc1fd039938e44e700b9a
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Tue Sep 8 09:17:11 2020 +1200

    ARM: dts: Remove non-existent i2c1 from 98dx3236
    
    [ Upstream commit 7f24479ead579459106bb55c2320a000135731f9 ]
    
    The switches with integrated CPUs have only got a single i2c controller.
    They incorrectly gained one when they were split from the Armada-XP.
    
    Fixes: 43e28ba87708 ("ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236")
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f71a4021c904fd55623e4cf7c56c11be477ba153
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Mon Oct 12 10:56:43 2020 +0800

    HSI: omap_ssi: Don't jump to free ID in ssi_add_controller()
    
    [ Upstream commit 41fff6e19bc8d6d8bca79ea388427c426e72e097 ]
    
    In current code, it jumps to ida_simple_remove() when ida_simple_get()
    failes to allocate an ID. Just return to fix it.
    
    Fixes: 0fae198988b8 ("HSI: omap_ssi: built omap_ssi and omap_ssi_port into one module")
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6e8cb839848ea2a044e65563429aa6fc368ce42
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Fri Nov 27 10:24:50 2020 +0000

    slimbus: qcom-ngd-ctrl: Avoid sending power requests without QMI
    
    [ Upstream commit 39014ce6d6028614a46395923a2c92d058b6fa87 ]
    
    Attempting to send a power request during PM operations, when the QMI
    handle isn't initialized results in a NULL pointer dereference. So check
    if the QMI handle has been initialized before attempting to post the
    power requests.
    
    Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver")
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20201127102451.17114-7-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c2f52123a4521de83c73df41f104e20ba44bd07
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Mar 4 15:23:12 2020 +0100

    media: max2175: fix max2175_set_csm_mode() error code
    
    [ Upstream commit 9b1b0cb0636166187478ef68d5b95f5caea062ec ]
    
    This is supposed to return negative error codes but the type is bool so
    it returns true instead.
    
    Fixes: b47b79d8a231 ("[media] media: i2c: max2175: Add MAX2175 support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84f341fa31faf4233a283d46fe4f6dc9b3026539
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Fri Nov 20 15:48:47 2020 +0800

    mips: cdmm: fix use-after-free in mips_cdmm_bus_discover
    
    [ Upstream commit f0e82242b16826077a2775eacfe201d803bb7a22 ]
    
    kfree(dev) has been called inside put_device so anther
    kfree would cause a use-after-free bug/
    
    Fixes: 8286ae03308c ("MIPS: Add CDMM bus support")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Acked-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f73062a69ecd13eb1940c990958123e9e186309
Author: Daniel T. Lee <danieltimlee@gmail.com>
Date:   Tue Nov 24 09:03:09 2020 +0000

    samples: bpf: Fix lwt_len_hist reusing previous BPF map
    
    [ Upstream commit 0afe0a998c40085a6342e1aeb4c510cccba46caf ]
    
    Currently, lwt_len_hist's map lwt_len_hist_map is uses pinning, and the
    map isn't cleared on test end. This leds to reuse of that map for
    each test, which prevents the results of the test from being accurate.
    
    This commit fixes the problem by removing of pinned map from bpffs.
    Also, this commit add the executable permission to shell script
    files.
    
    Fixes: f74599f7c5309 ("bpf: Add tests and samples for LWT-BPF")
    Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20201124090310.24374-7-danieltimlee@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21975cc933d6a4563e40ec06b3b01997c6ecdf57
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Wed Nov 25 12:10:56 2020 +0200

    platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration
    
    [ Upstream commit 912b341585e302ee44fc5a2733f7bcf505e2c86f ]
    
    Remove PSU EEPROM configuration for systems class equipped with
    Mellanox chip Spectrum and ATOM CPU - system types MSN274x. Till now
    all the systems from this class used few types of power units, all
    equipped with EEPROM device with address space two bytes. Thus, all
    these devices have been handled by EEPROM driver "24c02".
    
    There is a new requirement is to support power unit replacement by "off
    the shelf" device, matching electrical required parameters. Such device
    can be equipped with different EEPROM type, which could be one byte
    address space addressing or even could be not equipped with EEPROM.
    In such case "24c02" will not work.
    
    Fixes: ef08e14a3 ("platform/x86: mlx-platform: Add support for new msn274x system type")
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Link: https://lore.kernel.org/r/20201125101056.174708-3-vadimp@nvidia.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 725d730ee1cdd7af255b3234a4b40cb3150e555f
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Wed Nov 25 12:10:55 2020 +0200

    platform/x86: mlx-platform: Remove PSU EEPROM from default platform configuration
    
    [ Upstream commit 2bf5046bdb649908df8bcc0a012c56eee931a9af ]
    
    Remove PSU EEPROM configuration for systems class equipped with
    Mellanox chip Spectrum and Celeron CPU - system types MSN2700, MSN2100.
    Till now all the systems from this class used few types of power units,
    all equipped with EEPROM device with address space two bytes. Thus, all
    these devices have been handled by EEPROM driver "24c02".
    
    There is a new requirement is to support power unit replacement by "off
    the shelf" device, matching electrical required parameters. Such device
    can be equipped with different EEPROM type, which could be one byte
    address space addressing or even could be not equipped with EEPROM.
    In such case "24c02" will not work.
    
    Fixes: c6acad68e ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface")
    Fixes: ba814fdd0 ("platform/x86: mlx-platform: Use defines for bus assignment")
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Link: https://lore.kernel.org/r/20201125101056.174708-2-vadimp@nvidia.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fc23f6c20edaadff634320b13a781530a126ce7
Author: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
Date:   Wed Sep 9 14:56:57 2020 +0200

    media: siano: fix memory leak of debugfs members in smsdvb_hotplug
    
    [ Upstream commit abf287eeff4c6da6aa804bbd429dfd9d0dfb6ea7 ]
    
    When dvb_create_media_graph fails, the debugfs kept inside client should
    be released. However, the current implementation does not release them.
    
    Fix this by adding a new goto label to call smsdvb_debugfs_release.
    
    Fixes: 0d3ab8410dcb ("[media] dvb core: must check dvb_create_media_graph()")
    Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
    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 6a76b1da25be1985970573c3ec7c06dca79b5a12
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue Nov 24 09:08:13 2020 +0800

    dmaengine: mv_xor_v2: Fix error return code in mv_xor_v2_probe()
    
    [ Upstream commit c95e6515a8c065862361f7e0e452978ade7f94ec ]
    
    Return the corresponding error code when first_msi_entry() returns
    NULL in mv_xor_v2_probe().
    
    Fixes: 19a340b1a820430 ("dmaengine: mv_xor_v2: new driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20201124010813.1939095-1-chengzhihao1@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b62e01be3e95871f15e0a22244d44f82c69c48dc
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Thu Nov 19 15:08:42 2020 +0800

    cw1200: fix missing destroy_workqueue() on error in cw1200_init_common
    
    [ Upstream commit 7ec8a926188eb8e7a3cbaca43ec44f2d7146d71b ]
    
    Add the missing destroy_workqueue() before return from
    cw1200_init_common in the error handling case.
    
    Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201119070842.1011-1-miaoqinglang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6d1a50c57c272f8ea04c36f8c251b4a9ec39e4e
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Nov 13 22:22:43 2020 +0100

    orinoco: Move context allocation after processing the skb
    
    [ Upstream commit a31eb615646a63370aa1da1053c45439c7653d83 ]
    
    ezusb_xmit() allocates a context which is leaked if
    orinoco_process_xmit_skb() returns an error.
    
    Move ezusb_alloc_ctx() after the invocation of
    orinoco_process_xmit_skb() because the context is not needed so early.
    ezusb_access_ltv() will cleanup the context in case of an error.
    
    Fixes: bac6fafd4d6a0 ("orinoco: refactor xmit path")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201113212252.2243570-2-bigeasy@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bd2d5b8046be1b502ee0b295f7105a4a6bb4d7c
Author: Cristian Birsan <cristian.birsan@microchip.com>
Date:   Wed Nov 18 14:00:19 2020 +0200

    ARM: dts: at91: sama5d3_xplained: add pincontrol for USB Host
    
    [ Upstream commit e1062fa7292f1e3744db0a487c4ac0109e09b03d ]
    
    The pincontrol node is needed for USB Host since Linux v5.7-rc1. Without
    it the driver probes but VBus is not powered because of wrong pincontrol
    configuration.
    
    Fixes: b7c2b61570798 ("ARM: at91: add Atmel's SAMA5D3 Xplained board")
    Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Link: https://lore.kernel.org/r/20201118120019.1257580-4-cristian.birsan@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 226703d5131022a401d3f6fdb7e1812dba9147a5
Author: Cristian Birsan <cristian.birsan@microchip.com>
Date:   Wed Nov 18 14:00:18 2020 +0200

    ARM: dts: at91: sama5d4_xplained: add pincontrol for USB Host
    
    [ Upstream commit be4dd2d448816a27c1446f8f37fce375daf64148 ]
    
    The pincontrol node is needed for USB Host since Linux v5.7-rc1. Without
    it the driver probes but VBus is not powered because of wrong pincontrol
    configuration.
    
    Fixes: 38153a017896f ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board")
    Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Link: https://lore.kernel.org/r/20201118120019.1257580-3-cristian.birsan@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64a622c7bbc84c6a231fee2df4d13fca295cf17d
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Fri Nov 20 15:48:46 2020 +0800

    memstick: fix a double-free bug in memstick_check
    
    [ Upstream commit e3e9ced5c93803d5b2ea1942c4bf0192622531d6 ]
    
    kfree(host->card) has been called in put_device so that
    another kfree would raise cause a double-free bug.
    
    Fixes: 0193383a5833 ("memstick: core: fix device_register() error handling")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Link: https://lore.kernel.org/r/20201120074846.31322-1-miaoqinglang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b2f0afa3dc48a4d82c6a2afeb1bfbc0146b6a3c
Author: Kamal Heib <kamalheib1@gmail.com>
Date:   Sun Nov 8 15:20:07 2020 +0200

    RDMA/cxgb4: Validate the number of CQEs
    
    [ Upstream commit 6d8285e604e0221b67bd5db736921b7ddce37d00 ]
    
    Before create CQ, make sure that the requested number of CQEs is in the
    supported range.
    
    Fixes: cfdda9d76436 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC")
    Link: https://lore.kernel.org/r/20201108132007.67537-1-kamalheib1@gmail.com
    Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3c96c2b4bcb8c43389b82dd124ebf4c7281e9c5
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Nov 20 16:36:49 2020 -0800

    Input: omap4-keypad - fix runtime PM error handling
    
    [ Upstream commit 59bbf83835f591b95c3bdd09d900f3584fa227af ]
    
    In omap4_keypad_probe, the patch fix several bugs.
    
      1) pm_runtime_get_sync will increment pm usage counter even it
         failed. Forgetting to pm_runtime_put_noidle will result in
         reference leak.
    
      2) In err_unmap, forget to disable runtime of device,
         pm_runtime_enable will increase power disable depth. Thus a
         pairing decrement is needed on the error handling path to keep
         it balanced.
    
      3) In err_pm_disable, it will call pm_runtime_put_sync twice not
         one time.
    
    To fix this we factor out code reading revision and disabling touchpad, and
    drop PM reference once we are done talking to the device.
    
    Fixes: f77621cc640a7 ("Input: omap-keypad - dynamically handle register offsets")
    Fixes: 5ad567ffbaf20 ("Input: omap4-keypad - wire up runtime PM handling")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201120133918.2559681-1-zhangqilong3@huawei.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89d8af6bf6544270efdcd36045863615fdf0d31e
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Sat Nov 21 19:22:38 2020 -0800

    drivers: soc: ti: knav_qmss_queue: Fix error return code in knav_queue_probe
    
    [ Upstream commit 4cba398f37f868f515ff12868418dc28574853a1 ]
    
    Fix to return the error code from of_get_child_by_name() instaed of 0
    in knav_queue_probe().
    
    Fixes: 41f93af900a20d1a0a ("soc: ti: add Keystone Navigator QMSS driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dda44149d9928fbc81192858229a62ce6151c67b
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Sat Nov 21 19:22:37 2020 -0800

    soc: ti: Fix reference imbalance in knav_dma_probe
    
    [ Upstream commit b4fa73358c306d747a2200aec6f7acb97e5750e6 ]
    
    The patch fix two reference leak.
    
      1) pm_runtime_get_sync will increment pm usage counter even it
         failed. Forgetting to call put operation will result in
         reference leak.
    
      2) The pm_runtime_enable will increase power disable depth. Thus
         a pairing decrement is needed on the error handling path to
         keep it balanced.
    
    We fix it by: 1) adding call pm_runtime_put_noidle or
    pm_runtime_put_sync in error handling. 2) adding pm_runtime_disable
    in error handling, to keep usage counter and disable depth balanced.
    
    Fixes: 88139ed030583 ("soc: ti: add Keystone Navigator DMA support")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 626e72381e2ab1b57901334dfb3ae0101815fda0
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Sat Nov 21 19:22:00 2020 -0800

    soc: ti: knav_qmss: fix reference leak in knav_queue_probe
    
    [ Upstream commit ec8684847d8062496c4619bc3fcff31c19d56847 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in knav_queue_probe, so we should fix it.
    
    Fixes: 41f93af900a20 ("soc: ti: add Keystone Navigator QMSS driver")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d85ed98f5a91acb93b23b0e648f9c5c8fb426f14
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Nov 19 17:16:02 2020 +0100

    spi: fix resource leak for drivers without .remove callback
    
    [ Upstream commit 440408dbadfe47a615afd0a0a4a402e629be658a ]
    
    Consider an spi driver with a .probe but without a .remove callback (e.g.
    rtc-ds1347). The function spi_drv_probe() is called to bind a device and
    so dev_pm_domain_attach() is called. As there is no remove callback
    spi_drv_remove() isn't called at unbind time however and so calling
    dev_pm_domain_detach() is missed and the pm domain keeps active.
    
    To fix this always use both spi_drv_probe() and spi_drv_remove() and
    make them handle the respective callback not being set. This has the
    side effect that for a (hypothetical) driver that has neither .probe nor
    remove the clk and pm domain setup is done.
    
    Fixes: 33cf00e57082 ("spi: attach/detach SPI device to the ACPI power domain")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20201119161604.2633521-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad16a80015ea90dac6410277202972a913749957
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Nov 13 21:17:28 2020 +0800

    crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe
    
    [ Upstream commit ff8107200367f4abe0e5bce66a245e8d0f2d229e ]
    
    The pm_runtime_enable will increase power disable depth.
    Thus a pairing decrement is needed on the error handling
    path to keep it balanced according to context.
    
    Fixes: f7b2b5dd6a62a ("crypto: omap-aes - add error check for pm_runtime_get_sync")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e6754c4b02018baa7ba093784906238cd2ec613
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Nov 12 13:07:02 2020 -0700

    crypto: crypto4xx - Replace bitwise OR with logical OR in crypto4xx_build_pd
    
    [ Upstream commit 5bdad829c31a09069fd508534f03c2ea1576ac75 ]
    
    Clang warns:
    
    drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has
    lower precedence than '|'; '|' will be evaluated first
    [-Wbitwise-conditional-parentheses]
                     (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ?
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
    drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses
    around the '|' expression to silence this warning
                     (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ?
                                                                             ^
                                                                            )
    drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses
    around the '?:' expression to evaluate it first
                     (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ?
                                                                             ^
                     (
    1 warning generated.
    
    It looks like this should have been a logical OR so that
    PD_CTL_HASH_FINAL gets added to the w bitmask if crypto_tfm_alg_type
    is either CRYPTO_ALG_TYPE_AHASH or CRYPTO_ALG_TYPE_AEAD. Change the
    operator so that everything works properly.
    
    Fixes: 4b5b79998af6 ("crypto: crypto4xx - fix stalls under heavy load")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1198
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Christian Lamparter <chunkeey@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fa25a9d27dd1a19b4475f6d66ce3a1e049bda94
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Nov 3 18:07:12 2020 +0000

    powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
    
    [ Upstream commit 78665179e569c7e1fe102fb6c21d0f5b6951f084 ]
    
    On 8xx, we get the following features:
    
    [    0.000000] cpu_features      = 0x0000000000000100
    [    0.000000]   possible        = 0x0000000000000120
    [    0.000000]   always          = 0x0000000000000000
    
    This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all
    other configurations, the three lines should be equal.
    
    The problem is due to CPU_FTRS_GENERIC_32 which is taken when
    CONFIG_BOOK3S_32 is NOT selected. This CPU_FTRS_GENERIC_32 is
    pointless because there is no generic configuration supporting
    all 32 bits but book3s/32.
    
    Remove this pointless generic features definition to unbreak the
    calculation of 'possible' features and 'always' features.
    
    Fixes: 76bc080ef5a3 ("[POWERPC] Make default cputable entries reflect selected CPU family")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/76a85f30bf981d1aeaae00df99321235494da254.1604426550.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e92591b7812b4222bfa6a409c2bcbefd45fee858
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Nov 6 09:24:21 2020 +0800

    spi: mxs: fix reference leak in mxs_spi_probe
    
    [ Upstream commit 03fc41afaa6549baa2dab7a84e1afaf5cadb5b18 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in mxs_spi_probe, so we should fix it.
    
    Fixes: b7969caf41a1d ("spi: mxs: implement runtime pm")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201106012421.95420-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be71c20adbda6fe360269a07705c779b199c0101
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 17 14:15:00 2020 +0800

    usb/max3421: fix return error code in max3421_probe()
    
    [ Upstream commit 5a569343e8a618dc73edebe0957eb42f2ab476bd ]
    
    retval may be reassigned to 0 after max3421_of_vbus_en_pin(),
    if allocate memory failed after this, max3421_probe() cann't
    return ENOMEM, fix this by moving assign retval afther max3421_probe().
    
    Fixes: 721fdc83b31b ("usb: max3421: Add devicetree support")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20201117061500.3454223-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4055813c886f5c301e4032502eddda7c9f4eb1c3
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Nov 11 17:17:11 2020 -0800

    Input: ads7846 - fix unaligned access on 7845
    
    [ Upstream commit 03e2c9c782f721b661a0e42b1b58f394b5298544 ]
    
    req->sample[1] is not naturally aligned at word boundary, and therefore we
    should use get_unaligned_be16() when accessing it.
    
    Fixes: 3eac5c7e44f3 ("Input: ads7846 - extend the driver for ads7845 controller support")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8975ac54acc4b71bf86c65874522686d2fed431
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Tue Nov 17 15:33:24 2020 -0800

    Input: ads7846 - fix integer overflow on Rt calculation
    
    [ Upstream commit 820830ec918f6c3dcd77a54a1c6198ab57407916 ]
    
    In some rare cases the 32 bit Rt value will overflow if z2 and x is max,
    z1 is minimal value and x_plate_ohms is relatively high (for example 800
    ohm). This would happen on some screen age with low pressure.
    
    There are two possible fixes:
    - make Rt 64bit
    - reorder calculation to avoid overflow
    
    The second variant seems to be preferable, since 64 bit calculation on
    32 bit system is a bit more expensive.
    
    Fixes: ffa458c1bd9b6f653008d450f337602f3d52a646 ("spi: ads7846 driver")
    Co-developed-by: David Jander <david@protonic.nl>
    Signed-off-by: David Jander <david@protonic.nl>
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/r/20201113112240.1360-1-o.rempel@pengutronix.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5173b3900126b1d8b75331a3528c2ae8eebb7ae5
Author: David Jander <david@protonic.nl>
Date:   Wed Nov 11 11:00:59 2020 -0800

    Input: ads7846 - fix race that causes missing releases
    
    [ Upstream commit e52cd628a03f72a547dbf90ccb703ee64800504a ]
    
    If touchscreen is released while busy reading HWMON device, the release
    can be missed. The IRQ thread is not started because no touch is active
    and BTN_TOUCH release event is never sent.
    
    Fixes: f5a28a7d4858f94a ("Input: ads7846 - avoid pen up/down when reading hwmon")
    Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: David Jander <david@protonic.nl>
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/r/20201027105416.18773-1-o.rempel@pengutronix.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d4a8dd1a3eec63a7b2e6f4ffd9922d5fbc4bc30
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 17 14:10:45 2020 +0800

    drm/omap: dmm_tiler: fix return error code in omap_dmm_probe()
    
    [ Upstream commit 723ae803218da993143387bf966042eccefac077 ]
    
    Return -ENOMEM when allocating refill memory failed.
    
    Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201117061045.3452287-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44ce61c8bda4b0c94e3536625aa1a54ee6d98f9a
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 17 14:13:50 2020 +0800

    video: fbdev: atmel_lcdfb: fix return error code in atmel_lcdfb_of_init()
    
    [ Upstream commit ba236455ee750270f33998df57f982433cea4d8e ]
    
    If devm_kzalloc() failed after the first time, atmel_lcdfb_of_init()
    can't return -ENOMEM, fix this by putting the error code in loop.
    
    Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201117061350.3453742-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 965209a3d0aa4e7c647db9fcaa6799529b285b1f
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Wed Nov 11 04:22:01 2020 +0100

    media: solo6x10: fix missing snd_card_free in error handling case
    
    [ Upstream commit dcdff74fa6bc00c32079d0bebd620764c26f2d89 ]
    
    Fix to goto snd_error in error handling case when fails
    to do snd_ctl_add, as done elsewhere in this function.
    
    Fixes: 28cae868cd24 ("[media] solo6x10: move out of staging into drivers/media/pci.")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.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 2544b54d6384541845f0b0a7d55892214473bea9
Author: Martin Wilck <mwilck@suse.com>
Date:   Thu Oct 29 18:08:45 2020 +0100

    scsi: core: Fix VPD LUN ID designator priorities
    
    [ Upstream commit 2e4209b3806cda9b89c30fd5e7bfecb7044ec78b ]
    
    The current implementation of scsi_vpd_lun_id() uses the designator length
    as an implicit measure of priority. This works most of the time, but not
    always. For example, some Hitachi storage arrays return this in VPD 0x83:
    
    VPD INQUIRY: Device Identification page
      Designation descriptor number 1, descriptor length: 24
        designator_type: T10 vendor identification,  code_set: ASCII
        associated with the Addressed logical unit
          vendor id: HITACHI
          vendor specific: 5030C3502025
      Designation descriptor number 2, descriptor length: 6
        designator_type: vendor specific [0x0],  code_set: Binary
        associated with the Target port
          vendor specific: 08 03
      Designation descriptor number 3, descriptor length: 20
        designator_type: NAA,  code_set: Binary
        associated with the Addressed logical unit
          NAA 6, IEEE Company_id: 0x60e8
          Vendor Specific Identifier: 0x7c35000
          Vendor Specific Identifier Extension: 0x30c35000002025
          [0x60060e8007c350000030c35000002025]
    
    The current code would use the first descriptor because it's longer than
    the NAA descriptor. But this is wrong, the kernel is supposed to prefer NAA
    descriptors over T10 vendor ID. Designator length should only be used to
    compare designators of the same type.
    
    This patch addresses the issue by separating designator priority and
    length.
    
    Link: https://lore.kernel.org/r/20201029170846.14786-1-mwilck@suse.com
    Fixes: 9983bed3907c ("scsi: Add scsi_vpd_lun_id()")
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48222d98be9b58513c2cb8f2c49c808449fbe113
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Mon Nov 16 18:24:23 2020 +0100

    ASoC: meson: fix COMPILE_TEST error
    
    [ Upstream commit 299fe9937dbd1a4d9a1da6a2b6f222298534ca57 ]
    
    When compiled with CONFIG_HAVE_CLK, the kernel need to get provider for the
    clock API. This is usually selected by the platform and the sound drivers
    should not really care about this. However COMPILE_TEST is special and the
    platform required may not have been selected, leading to this type of
    error:
    
    > aiu-encoder-spdif.c:(.text+0x3a0): undefined reference to `clk_set_parent'
    
    Since we need a sane provider of the API with COMPILE_TEST, depends on
    COMMON_CLK.
    
    Fixes: 6dc4fa179fb8 ("ASoC: meson: add axg fifo base driver")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20201116172423.546855-1-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e92c43000273edd7bb49e66712d557f6dd5cba2a
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Oct 9 14:38:02 2020 +0200

    media: mtk-vcodec: add missing put_device() call in mtk_vcodec_release_dec_pm()
    
    [ Upstream commit 27c3943683f74e35e1d390ceb2e3639eff616ad6 ]
    
    mtk_vcodec_release_dec_pm() will be called in two places:
    
    a. mtk_vcodec_init_dec_pm() succeed while mtk_vcodec_probe() return error.
    b. mtk_vcodec_dec_remove().
    
    In both cases put_device() call is needed, since of_find_device_by_node()
    was called in mtk_vcodec_init_dec_pm() previously.
    
    Thus add put_devices() call in mtk_vcodec_release_dec_pm()
    
    Fixes: 590577a4e525 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver")
    Signed-off-by: Yu Kuai <yukuai3@huawei.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 390b4d5a38e46fc3abbaf6ca66ef3f2db9de7284
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Oct 8 23:12:23 2020 +0200

    media: tm6000: Fix sizeof() mismatches
    
    [ Upstream commit a08ad6339e0441ca12533969ed94a87e3655426e ]
    
    The are two instances of sizeof() being used incorrectly. The
    sizeof(void *) is incorrect because urb_buffer is a char ** pointer,
    fix this by using sizeof(*dev->urb_buffer).  The sizeof(dma_addr_t *)
    is incorrect, it should be sizeof(*dev->urb_dma), which is a dma_addr_t
    and not a dma_addr_t *.  This errors did not cause any issues because
    it just so happens the sizes are the same.
    
    Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)")
    
    Fixes: 16427faf2867 ("[media] tm6000: Add parameter to keep urb bufs allocated")
    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 d5f225ccabb49141dc0030a43b002d78a93045b5
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Thu Nov 12 14:49:24 2020 +0800

    staging: gasket: interrupt: fix the missed eventfd_ctx_put() in gasket_interrupt.c
    
    [ Upstream commit ab5b769a23af12a675b9f3d7dd529250c527f5ac ]
    
    gasket_interrupt_set_eventfd() misses to call eventfd_ctx_put() in an
    error path. We check interrupt is valid before calling
    eventfd_ctx_fdget() to fix it.
    
    There is the same issue in gasket_interrupt_clear_eventfd(), Add the
    missed function call to fix it.
    
    Fixes: 9a69f5087ccc ("drivers/staging: Gasket driver framework + Apex driver")
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Link: https://lore.kernel.org/r/20201112064924.99680-1-jingxiangfeng@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c54e646390e424e07df1a33f8d8b9dc4b721d8a
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 9 21:13:46 2020 +0800

    staging: greybus: codecs: Fix reference counter leak in error handling
    
    [ Upstream commit 3952659a6108f77a0d062d8e8487bdbdaf52a66c ]
    
    gb_pm_runtime_get_sync has increased the usage counter of the device here.
    Forgetting to call gb_pm_runtime_put_noidle will result in usage counter
    leak in the error branch of (gbcodec_hw_params and gbcodec_prepare). We
    fixed it by adding it.
    
    Fixes: c388ae7696992 ("greybus: audio: Update pm runtime support in dai_ops callback")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201109131347.1725288-2-zhangqilong3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 462850d0db0803ff192f7ea4a52c77c0907f78f6
Author: Jack Xu <jack.xu@intel.com>
Date:   Fri Nov 6 19:27:40 2020 +0800

    crypto: qat - fix status check in qat_hal_put_rel_rd_xfer()
    
    [ Upstream commit 3b5c130fb2e4c045369791c33c83b59f6e84f7d6 ]
    
    The return value of qat_hal_rd_ae_csr() is always a CSR value and never
    a status and should not be stored in the status variable of
    qat_hal_put_rel_rd_xfer().
    
    This removes the assignment as qat_hal_rd_ae_csr() is not expected to
    fail.
    A more comprehensive handling of the theoretical corner case which could
    result in a fail will be submitted in a separate patch.
    
    Fixes: 8c9478a400b7 ("crypto: qat - reduce stack size with KASAN")
    Signed-off-by: Jack Xu <jack.xu@intel.com>
    Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b30c2cc9cbe17c340de1b67f7e02164f5c4b43ed
Author: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Date:   Tue Nov 3 00:34:01 2020 +0300

    MIPS: BCM47XX: fix kconfig dependency bug for BCM47XX_BCMA
    
    [ Upstream commit 3a5fe2fb9635c43359c9729352f45044f3c8df6b ]
    
    When BCM47XX_BCMA is enabled and BCMA_DRIVER_PCI is disabled, it results
    in the following Kbuild warning:
    
    WARNING: unmet direct dependencies detected for BCMA_DRIVER_PCI_HOSTMODE
      Depends on [n]: MIPS [=y] && BCMA_DRIVER_PCI [=n] && PCI_DRIVERS_LEGACY [=y] && BCMA [=y]=y
      Selected by [y]:
      - BCM47XX_BCMA [=y] && BCM47XX [=y] && PCI [=y]
    
    The reason is that BCM47XX_BCMA selects BCMA_DRIVER_PCI_HOSTMODE without
    depending on or selecting BCMA_DRIVER_PCI while BCMA_DRIVER_PCI_HOSTMODE
    depends on BCMA_DRIVER_PCI. This can also fail building the kernel.
    
    Honor the kconfig dependency to remove unmet direct dependency warnings
    and avoid any potential build failures.
    
    Fixes: c1d1c5d4213e ("bcm47xx: add support for bcma bus")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=209879
    Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b68c10dbf4d6d6a9e4f9604eb598dda3edaf838
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 26 22:12:30 2020 +0100

    RDMa/mthca: Work around -Wenum-conversion warning
    
    [ Upstream commit fbb7dc5db6dee553b5a07c27e86364a5223e244c ]
    
    gcc points out a suspicious mixing of enum types in a function that
    converts from MTHCA_OPCODE_* values to IB_WC_* values:
    
    drivers/infiniband/hw/mthca/mthca_cq.c: In function 'mthca_poll_one':
    drivers/infiniband/hw/mthca/mthca_cq.c:607:21: warning: implicit conversion from 'enum <anonymous>' to 'enum ib_wc_opcode' [-Wenum-conversion]
      607 |    entry->opcode    = MTHCA_OPCODE_INVALID;
    
    Nothing seems to ever check for MTHCA_OPCODE_INVALID again, no idea if
    this is meaningful, but it seems harmless as it deals with an invalid
    input.
    
    Remove MTHCA_OPCODE_INVALID and set the ib_wc_opcode to 0xFF, which is
    still bogus, but at least doesn't make compiler warnings.
    
    Fixes: 2a4443a69934 ("[PATCH] IB/mthca: fill in opcode field for send completions")
    Link: https://lore.kernel.org/r/20201026211311.3887003-1-arnd@kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89225cc62cc621356f24fd763252f22cbc103144
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Wed Nov 11 21:09:20 2020 +0800

    ASoC: arizona: Fix a wrong free in wm8997_probe
    
    [ Upstream commit 5e7aace13df24ff72511f29c14ebbfe638ef733c ]
    
    In the normal path, we should not free the arizona,
    we should return immediately. It will be free when
    call remove operation.
    
    Fixes: 31833ead95c2c ("ASoC: arizona: Move request of speaker IRQs into bus probe")
    Reported-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Acked-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20201111130923.220186-2-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7b415ebf76c0d1a8dababa06bef595b7acd8260
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Wed Nov 11 12:13:26 2020 +0800

    ASoC: wm8998: Fix PM disable depth imbalance on error
    
    [ Upstream commit 193aa0a043645220d2a2f783ba06ae13d4601078 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context.
    
    Fixes: 31833ead95c2c ("ASoC: arizona: Move request of speaker IRQs into bus probe")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20201111041326.1257558-4-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df06d093baad8fd03a1bd69dc7ac08cb3ffc2659
Author: Tsuchiya Yuto <kitakar@gmail.com>
Date:   Wed Oct 28 23:21:09 2020 +0900

    mwifiex: fix mwifiex_shutdown_sw() causing sw reset failure
    
    [ Upstream commit fa74cb1dc0f4da46c441b735ca865ac52de42c0e ]
    
    When a PCIe function level reset (FLR) is performed but without fw reset for
    some reasons (e.g., on Microsoft Surface devices, fw reset requires other
    quirks), it fails to reset wifi properly. You can trigger the issue on such
    devices via debugfs entry for reset:
    
        $ echo 1 | sudo tee /sys/kernel/debug/mwifiex/mlan0/reset
    
    and the resulting dmesg log:
    
        [   45.740508] mwifiex_pcie 0000:03:00.0: Resetting per request
        [   45.742937] mwifiex_pcie 0000:03:00.0: info: successfully disconnected from [BSSID]: reason code 3
        [   45.744666] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex...
        [   45.751530] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.751539] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.771691] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.771695] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [   45.771697] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.771698] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [   45.771699] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.771701] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [   45.771702] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.771703] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [   45.771704] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.771705] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [   45.771707] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [   45.771708] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [   53.099343] mwifiex_pcie 0000:03:00.0: info: trying to associate to '[SSID]' bssid [BSSID]
        [   53.241870] mwifiex_pcie 0000:03:00.0: info: associated to bssid [BSSID] successfully
        [   75.377942] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
        [   85.385491] mwifiex_pcie 0000:03:00.0: info: successfully disconnected from [BSSID]: reason code 15
        [   87.539408] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
        [   87.539412] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [   99.699917] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
        [   99.699925] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [  111.859802] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
        [  111.859808] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
        [...]
    
    When comparing mwifiex_shutdown_sw() with mwifiex_pcie_remove(), it
    lacks mwifiex_init_shutdown_fw().
    
    This commit fixes mwifiex_shutdown_sw() by adding the missing
    mwifiex_init_shutdown_fw().
    
    Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
    Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201028142110.18144-2-kitakar@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74f92cc8b4b808e89cec017cf313bab19ba5927d
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Tue Nov 3 15:49:11 2020 +0800

    spi: bcm63xx-hsspi: fix missing clk_disable_unprepare() on error in bcm63xx_hsspi_resume
    
    [ Upstream commit 9bb9ef2b3e5d9d012876e7e2d7757eb30e865bee ]
    
    Fix the missing clk_disable_unprepare() before return
    from bcm63xx_hsspi_resume in the error handling case when
    fails to prepare and enable bs->pll_clk.
    
    Fixes: 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled")
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Link: https://lore.kernel.org/r/20201103074911.195530-1-miaoqinglang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9559ee15ca124e7ebe258d5219499cb805f8c31f
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Tue Nov 3 22:13:06 2020 +0800

    spi: tegra114: fix reference leak in tegra spi ops
    
    [ Upstream commit a042184c7fb99961ea083d4ec192614bec671969 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in two callers(tegra_spi_setup and
    tegra_spi_resume), so we should fix it.
    
    Fixes: f333a331adfac ("spi/tegra114: add spi driver")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201103141306.5607-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d40dbad5fb61bcbdd518dfa005eb1f994cb3ff7
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Tue Nov 3 22:13:23 2020 +0800

    spi: tegra20-sflash: fix reference leak in tegra_sflash_resume
    
    [ Upstream commit 3482e797ab688da6703fe18d8bad52f94199f4f2 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in tegra_sflash_resume, so we should fix it.
    
    Fixes: 8528547bcc336 ("spi: tegra: add spi driver for sflash controller")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201103141323.5841-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c0f136a052c7e8392e9d5ace113900b7a9a3209
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Tue Nov 3 22:13:45 2020 +0800

    spi: tegra20-slink: fix reference leak in slink ops of tegra20
    
    [ Upstream commit 763eab7074f6e71babd85d796156f05a675f9510 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in two callers(tegra_slink_setup and
    tegra_slink_resume), so we should fix it.
    
    Fixes: dc4dc36056392 ("spi: tegra: add spi driver for SLINK controller")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201103141345.6188-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7d60a1b3020550849bb2ac498b7247b2237559b
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Tue Nov 3 22:09:47 2020 +0800

    spi: spi-ti-qspi: fix reference leak in ti_qspi_setup
    
    [ Upstream commit 45c0cba753641e5d7c3207f04241bd0e7a021698 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in ti_qspi_setup, so we should fix it.
    
    Fixes: 505a14954e2d7 ("spi/qspi: Add qspi flash controller")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201103140947.3815-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a15989ce987c3b112d5ec4fdabb755dbdc1d923b
Author: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Date:   Fri Oct 16 18:44:47 2020 +0530

    Bluetooth: hci_h5: fix memory leak in h5_close
    
    [ Upstream commit 855af2d74c870d747bf53509f8b2d7b9dc9ee2c3 ]
    
    When h5_close() is called, h5 is directly freed when !hu->serdev.
    However, h5->rx_skb is not freed, which causes a memory leak.
    
    Freeing h5->rx_skb and setting it to NULL, fixes this memory leak.
    
    Fixes: ce945552fde4 ("Bluetooth: hci_h5: Add support for serdev enumerated devices")
    Reported-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com
    Tested-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com
    Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abae100355c011d14c75cabbf9eb773c231187ee
Author: Anmol Karn <anmol.karan123@gmail.com>
Date:   Wed Sep 30 19:48:13 2020 +0530

    Bluetooth: Fix null pointer dereference in hci_event_packet()
    
    [ Upstream commit 6dfccd13db2ff2b709ef60a50163925d477549aa ]
    
    AMP_MGR is getting derefernced in hci_phy_link_complete_evt(), when called
    from hci_event_packet() and there is a possibility, that hcon->amp_mgr may
    not be found when accessing after initialization of hcon.
    
    - net/bluetooth/hci_event.c:4945
    The bug seems to get triggered in this line:
    
    bredr_hcon = hcon->amp_mgr->l2cap_conn->hcon;
    
    Fix it by adding a NULL check for the hcon->amp_mgr before checking the ev-status.
    
    Fixes: d5e911928bd8 ("Bluetooth: AMP: Process Physical Link Complete evt")
    Reported-and-tested-by: syzbot+0bef568258653cff272f@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=0bef568258653cff272f
    Signed-off-by: Anmol Karn <anmol.karan123@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4da6c1af4d3115b19092f0fd1267163ce91dc796
Author: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Date:   Sat Nov 7 14:39:26 2020 +0100

    arm64: dts: exynos: Correct psci compatible used on Exynos7
    
    [ Upstream commit e1e47fbca668507a81bb388fcae044b89d112ecc ]
    
    It's not possible to reboot or poweroff Exynos7420 using PSCI. Instead
    we need to use syscon reboot/poweroff drivers, like it's done for other
    Exynos SoCs. This was confirmed by checking vendor source and testing it
    on Samsung Galaxy S6 device based on this SoC.
    
    To be able to use custom restart/poweroff handlers instead of PSCI
    functions, we need to correct psci compatible. This also requires us to
    provide function ids for CPU_ON and CPU_OFF.
    
    Fixes: fb026cb65247 ("arm64: dts: Add reboot node for exynos7")
    Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7")
    Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
    Link: https://lore.kernel.org/r/20201107133926.37187-2-pawel.mikolaj.chmiel@gmail.com
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36cfba099f8517e10c2a7fae8f47ba24e5c8379b
Author: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Date:   Sat Nov 7 14:39:25 2020 +0100

    arm64: dts: exynos: Include common syscon restart/poweroff for Exynos7
    
    [ Upstream commit 73bc7510ea0dafb4ff1ae6808759627a8ec51f5a ]
    
    Exynos7 uses the same syscon reboot and poweroff nodes as other Exynos
    SoCs, so instead of duplicating code we can just include common dtsi
    file, which already contains definitions of them. After this change,
    poweroff node will be also available, previously this dts file did
    contain only reboot node.
    
    Fixes: fb026cb65247 ("arm64: dts: Add reboot node for exynos7")
    Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7")
    Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
    Link: https://lore.kernel.org/r/20201107133926.37187-1-pawel.mikolaj.chmiel@gmail.com
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87294e61dafc7be280188581191722eac8b87932
Author: Paul Moore <paul@paul-moore.com>
Date:   Tue Nov 3 11:49:38 2020 -0500

    selinux: fix inode_doinit_with_dentry() LABEL_INVALID error handling
    
    [ Upstream commit 200ea5a2292dc444a818b096ae6a32ba3caa51b9 ]
    
    A previous fix, commit 83370b31a915 ("selinux: fix error initialization
    in inode_doinit_with_dentry()"), changed how failures were handled
    before a SELinux policy was loaded.  Unfortunately that patch was
    potentially problematic for two reasons: it set the isec->initialized
    state without holding a lock, and it didn't set the inode's SELinux
    label to the "default" for the particular filesystem.  The later can
    be a problem if/when a later attempt to revalidate the inode fails
    and SELinux reverts to the existing inode label.
    
    This patch should restore the default inode labeling that existed
    before the original fix, without affecting the LABEL_INVALID marking
    such that revalidation will still be attempted in the future.
    
    Fixes: 83370b31a915 ("selinux: fix error initialization in inode_doinit_with_dentry()")
    Reported-by: Sven Schnelle <svens@linux.ibm.com>
    Tested-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d1c05ed878d35523db9786f4223903f50962136
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Mon Oct 26 11:01:29 2020 +0100

    ASoC: pcm: DRAIN support reactivation
    
    [ Upstream commit 4c22b80f61540ea99d9b4af0127315338755f05b ]
    
    soc-pcm's dpcm_fe_dai_do_trigger() supported DRAIN commnad up to kernel
    v5.4 where explicit switch(cmd) has been introduced which takes into
    account all SNDRV_PCM_TRIGGER_xxx but SNDRV_PCM_TRIGGER_DRAIN. Update
    switch statement to reactive support for it.
    
    As DRAIN is somewhat unique by lacking negative/stop counterpart, bring
    behaviour of dpcm_fe_dai_do_trigger() for said command back to its
    pre-v5.4 state by adding it to START/RESUME/PAUSE_RELEASE group.
    
    Fixes: acbf27746ecf ("ASoC: pcm: update FE/BE trigger order based on the command")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20201026100129.8216-1-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b529e921c6f3e24c6e500de8d26cdc362453a8b7
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Oct 15 22:03:30 2020 +0300

    drm/msm/dsi_pll_10nm: restore VCO rate during restore_state
    
    [ Upstream commit a4ccc37693a271330a46208afbeaed939d54fdbb ]
    
    PHY disable/enable resets PLL registers to default values. Thus in
    addition to restoring several registers we also need to restore VCO rate
    settings.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Fixes: c6659785dfb3 ("drm/msm/dsi/pll: call vco set rate explicitly")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc8805b8e90fce4aeafd7e64ae00fd0f68fa310a
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 22:56:51 2020 +0800

    spi: img-spfi: fix reference leak in img_spfi_resume
    
    [ Upstream commit ee5558a9084584015c8754ffd029ce14a5827fa8 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in img_spfi_resume, so we should fix it.
    
    Fixes: deba25800a12b ("spi: Add driver for IMG SPFI controller")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201102145651.3875-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f3e93d881faad2334e8ff807444beab5b62249d
Author: Jordan Niethe <jniethe5@gmail.com>
Date:   Wed Oct 14 18:28:36 2020 +1100

    powerpc/64: Set up a kernel stack for secondaries before cpu_restore()
    
    [ Upstream commit 3c0b976bf20d236c57adcefa80f86a0a1d737727 ]
    
    Currently in generic_secondary_smp_init(), cur_cpu_spec->cpu_restore()
    is called before a stack has been set up in r1. This was previously fine
    as the cpu_restore() functions were implemented in assembly and did not
    use a stack. However commit 5a61ef74f269 ("powerpc/64s: Support new
    device tree binding for discovering CPU features") used
    __restore_cpu_cpufeatures() as the cpu_restore() function for a
    device-tree features based cputable entry. This is a C function and
    hence uses a stack in r1.
    
    generic_secondary_smp_init() is entered on the secondary cpus via the
    primary cpu using the OPAL call opal_start_cpu(). In OPAL, each hardware
    thread has its own stack. The OPAL call is ran in the primary's hardware
    thread. During the call, a job is scheduled on a secondary cpu that will
    start executing at the address of generic_secondary_smp_init().  Hence
    the value that will be left in r1 when the secondary cpu enters the
    kernel is part of that secondary cpu's individual OPAL stack. This means
    that __restore_cpu_cpufeatures() will write to that OPAL stack. This is
    not horribly bad as each hardware thread has its own stack and the call
    that enters the kernel from OPAL never returns, but it is still wrong
    and should be corrected.
    
    Create the temp kernel stack before calling cpu_restore().
    
    As noted by mpe, for a kexec boot, the secondary CPUs are released from
    the spin loop at address 0x60 by smp_release_cpus() and then jump to
    generic_secondary_smp_init(). The call to smp_release_cpus() is in
    setup_arch(), and it comes before the call to emergency_stack_init().
    emergency_stack_init() allocates an emergency stack in the PACA for each
    CPU.  This address in the PACA is what is used to set up the temp kernel
    stack in generic_secondary_smp_init(). Move releasing the secondary CPUs
    to after the PACAs have been allocated an emergency stack, otherwise the
    PACA stack pointer will contain garbage and hence the temp kernel stack
    created from it will be broken.
    
    Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")
    Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201014072837.24539-1-jniethe5@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 413de08ca4d81e78e50299293f4db4079615bbab
Author: Colin Ian King <colin.king@canonical.com>
Date:   Sat Oct 10 17:47:36 2020 +0100

    crypto: inside-secure - Fix sizeof() mismatch
    
    [ Upstream commit c98e233062cd9d0e2f10e445a671f0799daaef67 ]
    
    An incorrect sizeof() is being used, sizeof(priv->ring[i].rdr_req) is
    not correct, it should be sizeof(*priv->ring[i].rdr_req). Note that
    since the size of ** is the same size as * this is not causing any
    issues.
    
    Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)")
    Fixes: 9744fec95f06 ("crypto: inside-secure - remove request list to improve performance")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Antoine Tenart <atenart@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb9bc711140f0229f6cfa45cc97f9f5b01ab60ec
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Oct 8 09:34:56 2020 +0000

    crypto: talitos - Fix return type of current_desc_hdr()
    
    [ Upstream commit 0237616173fd363a54bd272aa3bd376faa1d7caa ]
    
    current_desc_hdr() returns a u32 but in fact this is a __be32,
    leading to a lot of sparse warnings.
    
    Change the return type to __be32 and ensure it is handled as
    sure by the caller.
    
    Fixes: 3e721aeb3df3 ("crypto: talitos - handle descriptor not found in error path")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3cfad9d183a8c0e05ec6829326643edd3f8b122
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Oct 8 09:34:55 2020 +0000

    crypto: talitos - Endianess in current_desc_hdr()
    
    [ Upstream commit 195404db27f9533c71fdcb78d32a77075c2cb4a2 ]
    
    current_desc_hdr() compares the value of the current descriptor
    with the next_desc member of the talitos_desc struct.
    
    While the current descriptor is obtained from in_be32() which
    return CPU ordered bytes, next_desc member is in big endian order.
    
    Convert the current descriptor into big endian before comparing it
    with next_desc.
    
    This fixes a sparse warning.
    
    Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6b6ba5754eee1907497504e4b31e22c78f7670f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Oct 20 16:46:55 2020 +0200

    sched: Reenable interrupts in do_sched_yield()
    
    [ Upstream commit 345a957fcc95630bf5535d7668a59ed983eb49a7 ]
    
    do_sched_yield() invokes schedule() with interrupts disabled which is
    not allowed. This goes back to the pre git era to commit a6efb709806c
    ("[PATCH] irqlock patch 2.5.27-H6") in the history tree.
    
    Reenable interrupts and remove the misleading comment which "explains" it.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/87r1pt7y5c.fsf@nanos.tec.linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6db84b27221204c37a53dd7c58b01b5d7e91ce0b
Author: Peng Liu <iwtbavbm@gmail.com>
Date:   Thu Oct 8 23:49:42 2020 +0800

    sched/deadline: Fix sched_dl_global_validate()
    
    [ Upstream commit a57415f5d1e43c3a5c5d412cd85e2792d7ed9b11 ]
    
    When change sched_rt_{runtime, period}_us, we validate that the new
    settings should at least accommodate the currently allocated -dl
    bandwidth:
    
      sched_rt_handler()
        --> sched_dl_bandwidth_validate()
            {
                    new_bw = global_rt_runtime()/global_rt_period();
    
                    for_each_possible_cpu(cpu) {
                            dl_b = dl_bw_of(cpu);
                            if (new_bw < dl_b->total_bw)    <-------
                                    ret = -EBUSY;
                    }
            }
    
    But under CONFIG_SMP, dl_bw is per root domain , but not per CPU,
    dl_b->total_bw is the allocated bandwidth of the whole root domain.
    Instead, we should compare dl_b->total_bw against "cpus*new_bw",
    where 'cpus' is the number of CPUs of the root domain.
    
    Also, below annotation(in kernel/sched/sched.h) implied implementation
    only appeared in SCHED_DEADLINE v2[1], then deadline scheduler kept
    evolving till got merged(v9), but the annotation remains unchanged,
    meaningless and misleading, update it.
    
    * With respect to SMP, the bandwidth is given on a per-CPU basis,
    * meaning that:
    *  - dl_bw (< 100%) is the bandwidth of the system (group) on each CPU;
    *  - dl_total_bw array contains, in the i-eth element, the currently
    *    allocated bandwidth on the i-eth CPU.
    
    [1]: https://lore.kernel.org/lkml/1267385230.13676.101.camel@Palantir/
    
    Fixes: 332ac17ef5bf ("sched/deadline: Add bandwidth management for SCHED_DEADLINE tasks")
    Signed-off-by: Peng Liu <iwtbavbm@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://lkml.kernel.org/r/db6bbda316048cda7a1bbc9571defde193a8d67e.1602171061.git.iwtbavbm@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3ad889a4557159123aceaf74465b890d34b1109
Author: David Woodhouse <dwmw@amazon.co.uk>
Date:   Sat Oct 24 22:35:01 2020 +0100

    x86/apic: Fix x2apic enablement without interrupt remapping
    
    [ Upstream commit 26573a97746c7a99f394f9d398ce91a8853b3b89 ]
    
    Currently, Linux as a hypervisor guest will enable x2apic only if there are
    no CPUs present at boot time with an APIC ID above 255.
    
    Hotplugging a CPU later with a higher APIC ID would result in a CPU which
    cannot be targeted by external interrupts.
    
    Add a filter in x2apic_apic_id_valid() which can be used to prevent such
    CPUs from coming online, and allow x2apic to be enabled even if they are
    present at boot time.
    
    Fixes: ce69a784504 ("x86/apic: Enable x2APIC without interrupt remapping under KVM")
    Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20201024213535.443185-2-dwmw2@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecc3960efd13003636238fe877f272f7cadd1707
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Sep 21 00:10:16 2020 +0200

    ARM: p2v: fix handling of LPAE translation in BE mode
    
    [ Upstream commit 4e79f0211b473f8e1eab8211a9fd50cc41a3a061 ]
    
    When running in BE mode on LPAE hardware with a PA-to-VA translation
    that exceeds 4 GB, we patch bits 39:32 of the offset into the wrong
    byte of the opcode. So fix that, by rotating the offset in r0 to the
    right by 8 bits, which will put the 8-bit immediate in bits 31:24.
    
    Note that this will also move bit #22 in its correct place when
    applying the rotation to the constant #0x400000.
    
    Fixes: d9a790df8e984 ("ARM: 7883/1: fix mov to mvn conversion in case of 64 bit phys_addr_t and BE")
    Acked-by: Nicolas Pitre <nico@fluxnic.net>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 373eac79ec767237cc4634785761bb3d29b553ab
Author: Arvind Sankar <nivedita@alum.mit.edu>
Date:   Tue Oct 27 19:06:48 2020 -0400

    x86/mm/ident_map: Check for errors from ident_pud_init()
    
    [ Upstream commit 1fcd009102ee02e217f2e7635ab65517d785da8e ]
    
    Commit
    
      ea3b5e60ce80 ("x86/mm/ident_map: Add 5-level paging support")
    
    added ident_p4d_init() to support 5-level paging, but this function
    doesn't check and return errors from ident_pud_init().
    
    For example, the decompressor stub uses this code to create an identity
    mapping. If it runs out of pages while trying to allocate a PMD
    pagetable, the error will be currently ignored.
    
    Fix this to propagate errors.
    
     [ bp: Space out statements for better readability. ]
    
    Fixes: ea3b5e60ce80 ("x86/mm/ident_map: Add 5-level paging support")
    Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Joerg Roedel <jroedel@suse.de>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Link: https://lkml.kernel.org/r/20201027230648.1885111-1-nivedita@alum.mit.edu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e02d63b00889661e868035d80bbcdbb687dedaf0
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Tue Oct 13 12:07:42 2020 -0500

    RDMA/rxe: Compute PSN windows correctly
    
    [ Upstream commit bb3ab2979fd69db23328691cb10067861df89037 ]
    
    The code which limited the number of unacknowledged PSNs was incorrect.
    The PSNs are limited to 24 bits and wrap back to zero from 0x00ffffff.
    The test was computing a 32 bit value which wraps at 32 bits so that
    qp->req.psn can appear smaller than the limit when it is actually larger.
    
    Replace '>' test with psn_compare which is used for other PSN comparisons
    and correctly handles the 24 bit size.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20201013170741.3590-1-rpearson@hpe.com
    Signed-off-by: Bob Pearson <rpearson@hpe.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 620974102ad8ed5641f805dfec7e75765c3d2df9
Author: Joel Stanley <joel@jms.id.au>
Date:   Tue Sep 22 16:12:34 2020 +0930

    ARM: dts: aspeed: s2600wf: Fix VGA memory region location
    
    [ Upstream commit 9e1cc9679776f5b9e42481d392b1550753ebd084 ]
    
    The VGA memory region is always from the top of RAM. On this board, that
    is 0x80000000 + 0x20000000 - 0x01000000 = 0x9f000000.
    
    This was not an issue in practice as the region is "reserved" by the
    vendor's u-boot reducing the amount of available RAM, and the only user
    is the host VGA device poking at RAM over PCIe. That is, nothing from
    the ARM touches it.
    
    It is worth fixing as developers copy existing device trees when
    building their machines, and the XDMA driver does use the memory region
    from the ARM side.
    
    Fixes: c4043ecac34a ("ARM: dts: aspeed: Add S2600WF BMC Machine")
    Reported-by: John Wang <wangzhiqiang.bj@bytedance.com>
    Link: https://lore.kernel.org/r/20200922064234.163799-1-joel@jms.id.au
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd7223dda090c9246b290a0b901c112d6484466a
Author: Tianyue Ren <rentianyue@kylinos.cn>
Date:   Fri Oct 9 09:36:30 2020 +0800

    selinux: fix error initialization in inode_doinit_with_dentry()
    
    [ Upstream commit 83370b31a915493231e5b9addc72e4bef69f8d31 ]
    
    Mark the inode security label as invalid if we cannot find
    a dentry so that we will retry later rather than marking it
    initialized with the unlabeled SID.
    
    Fixes: 9287aed2ad1f ("selinux: Convert isec->lock into a spinlock")
    Signed-off-by: Tianyue Ren <rentianyue@kylinos.cn>
    [PM: minor comment tweaks]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2b081c76ea8fbaf11d8c01dc12fac6416cb9cf7
Author: Kamal Heib <kamalheib1@gmail.com>
Date:   Wed Oct 21 14:49:52 2020 +0300

    RDMA/bnxt_re: Set queue pair state when being queried
    
    [ Upstream commit 53839b51a7671eeb3fb44d479d541cf3a0f2dd45 ]
    
    The API for ib_query_qp requires the driver to set cur_qp_state on return,
    add the missing set.
    
    Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver")
    Link: https://lore.kernel.org/r/20201021114952.38876-1-kamalheib1@gmail.com
    Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
    Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adb832343a8fe70ecca0b78abbe88632052de487
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue Oct 13 14:25:28 2020 -0700

    soc: qcom: geni: More properly switch to DMA mode
    
    [ Upstream commit 4b6ea87be44ef34732846fc71e44c41125f0c4fa ]
    
    On geni-i2c transfers using DMA, it was seen that if you program the
    command (I2C_READ) before calling geni_se_rx_dma_prep() that it could
    cause interrupts to fire.  If we get unlucky, these interrupts can
    just keep firing (and not be handled) blocking further progress and
    hanging the system.
    
    In commit 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
    we avoided that by making sure we didn't program the command until
    after geni_se_rx_dma_prep() was called.  While that avoided the
    problems, it also turns out to be invalid.  At least in the TX case we
    started seeing sporadic corrupted transfers.  This is easily seen by
    adding an msleep() between the DMA prep and the writing of the
    command, which makes the problem worse.  That means we need to revert
    that commit and find another way to fix the bogus IRQs.
    
    Specifically, after reverting commit 02b9aec59243 ("i2c:
    i2c-qcom-geni: Fix DMA transfer race"), I put some traces in.  I found
    that the when the interrupts were firing like crazy:
    - "m_stat" had bits for M_RX_IRQ_EN, M_RX_FIFO_WATERMARK_EN set.
    - "dma" was set.
    
    Further debugging showed that I could make the problem happen more
    reliably by adding an "msleep(1)" any time after geni_se_setup_m_cmd()
    ran up until geni_se_rx_dma_prep() programmed the length.
    
    A rather simple fix is to change geni_se_select_dma_mode() so it's a
    true inverse of geni_se_select_fifo_mode() and disables all the FIFO
    related interrupts.  Now the problematic interrupts can't fire and we
    can program things in the correct order without worrying.
    
    As part of this, let's also change the writel_relaxed() in the prepare
    function to a writel() so that our DMA is guaranteed to be prepared
    now that we can't rely on geni_se_setup_m_cmd()'s writel().
    
    NOTE: the only current user of GENI_SE_DMA in mainline is i2c.
    
    Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller")
    Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Akash Asthana <akashast@codeaurora.org>
    Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20201013142448.v2.1.Ifdb1b69fa3367b81118e16e9e4e63299980ca798@changeid
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b50304be30f8cb76f291dfbe20cacfaa2b2374b
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Mon Sep 28 11:31:35 2020 +0800

    soc: mediatek: Check if power domains can be powered on at boot time
    
    [ Upstream commit 4007844b05815717f522c7ea9914e24ad0ff6c79 ]
    
    In the error case, where a power domain cannot be powered on
    successfully at boot time (in mtk_register_power_domains),
    pm_genpd_init would still be called with is_off=false, and the
    system would later try to disable the power domain again, triggering
    warnings as disabled clocks are disabled again (and other potential
    issues).
    
    Also print a warning splat in that case, as this should never
    happen.
    
    Fixes: c84e358718a66f7 ("soc: Mediatek: Add SCPSYS power domain driver")
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Link: https://lore.kernel.org/r/20200928113107.v2.1.I5e6f8c262031d0451fe7241b744f4f3111c1ce71@changeid
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02167d71e0859701f313cd6b6a9a028d104282e0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Sep 23 14:31:42 2020 +0300

    soc: renesas: rmobile-sysc: Fix some leaks in rmobile_init_pm_domains()
    
    [ Upstream commit cf25d802e029c31efac8bdc979236927f37183bd ]
    
    This code needs to call iounmap() on one error path.
    
    Fixes: 2173fc7cb681 ("ARM: shmobile: R-Mobile: Add DT support for PM domains")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20200923113142.GC1473821@mwanda
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 577dcd1af8c680dd31e5de08289d5c1ca0674967
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Aug 27 09:11:07 2020 +0200

    drm/tve200: Fix handling of platform_get_irq() error
    
    [ Upstream commit 77bb5aaf2bb8180e7d1bb70b4df306f511707a7d ]
    
    platform_get_irq() returns -ERRNO on error.  In such case comparison
    to 0 would pass the check.
    
    Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200827071107.27429-2-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18a4a903b4684b420fb1facd496769f21a1cd1b1
Author: Tom Rix <trix@redhat.com>
Date:   Sat Oct 3 12:39:28 2020 -0700

    drm/gma500: fix double free of gma_connector
    
    [ Upstream commit 4e19d51ca5b28a1d435a844c7b2a8e1b1b6fa237 ]
    
    clang static analysis reports this problem:
    
    cdv_intel_dp.c:2101:2: warning: Attempt to free released memory
            kfree(gma_connector);
            ^~~~~~~~~~~~~~~~~~~~
    
    In cdv_intel_dp_init() when the call to cdv_intel_edp_panel_vdd_off()
    fails, the handler calls cdv_intel_dp_destroy(connector) which does
    the first free of gma_connector. So adjust the goto label and skip
    the second free.
    
    Fixes: d112a8163f83 ("gma500/cdv: Add eDP support")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201003193928.18869-1-trix@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c1abeea728aa407cbbda9f31d89d9b0c8b164dd
Author: Leo Yan <leo.yan@linaro.org>
Date:   Tue May 5 21:36:42 2020 +0800

    perf cs-etm: Move definition of 'traceid_list' global variable from header file
    
    commit 168200b6d6ea0cb5765943ec5da5b8149701f36a upstream.
    
    The variable 'traceid_list' is defined in the header file cs-etm.h,
    if multiple C files include cs-etm.h the compiler might complaint for
    multiple definition of 'traceid_list'.
    
    To fix multiple definition error, move the definition of 'traceid_list'
    into cs-etm.c.
    
    Fixes: cd8bfd8c973e ("perf tools: Add processing of coresight metadata")
    Reported-by: Thomas Backlund <tmb@mageia.org>
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Reviewed-by: Mike Leach <mike.leach@linaro.org>
    Tested-by: Mike Leach <mike.leach@linaro.org>
    Tested-by: Thomas Backlund <tmb@mageia.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
    Cc: Tor Jeremiassen <tor@ti.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lore.kernel.org/lkml/20200505133642.4756-1-leo.yan@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cb5508fc9c88974b7300b05c079e98c895f0e86
Author: Leo Yan <leo.yan@linaro.org>
Date:   Tue Jan 29 20:28:39 2019 +0800

    perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata
    
    commit 95c6fe970a0160cb770c5dce9f80311b42d030c0 upstream.
    
    If packet processing wants to know the packet is bound with which ETM
    version, it needs to access metadata to decide that based on metadata
    magic number; but we cannot simply to use CPU logic ID number as index
    to access metadata sequential array, especially when system have
    hotplugged off CPUs, the metadata array are only allocated for online
    CPUs but not offline CPUs, so the CPU logic number doesn't match with
    its index in the array.
    
    This patch is to change tuple from traceID-CPU# to traceID-metadata,
    thus it can use the tuple to retrieve metadata pointer according to
    traceID.
    
    For safe accessing metadata fields, this patch provides helper function
    cs_etm__get_cpu() which is used to return CPU number according to
    traceID; cs_etm_decoder__buffer_packet() is the first consumer for this
    helper function.
    
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Robert Walker <robert.walker@arm.com>
    Cc: Suzuki K Poulouse <suzuki.poulose@arm.com>
    Cc: coresight ml <coresight@lists.linaro.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/20190129122842.32041-6-leo.yan@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    [Salvatore Bonaccorso: Adjust for context changes in
    tools/perf/util/cs-etm-decoder/cs-etm-decoder.c]
    Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b85abab5913d89ee78bc5bb08231acb578677898
Author: Dae R. Jeong <dae.r.jeong@kaist.ac.kr>
Date:   Thu Oct 22 10:21:28 2020 +0900

    md: fix a warning caused by a race between concurrent md_ioctl()s
    
    commit c731b84b51bf7fe83448bea8f56a6d55006b0615 upstream.
    
    Syzkaller reports a warning as belows.
    WARNING: CPU: 0 PID: 9647 at drivers/md/md.c:7169
    ...
    Call Trace:
    ...
    RIP: 0010:md_ioctl+0x4017/0x5980 drivers/md/md.c:7169
    RSP: 0018:ffff888096027950 EFLAGS: 00010293
    RAX: ffff88809322c380 RBX: 0000000000000932 RCX: ffffffff84e266f2
    RDX: 0000000000000000 RSI: ffffffff84e299f7 RDI: 0000000000000007
    RBP: ffff888096027bc0 R08: ffff88809322c380 R09: ffffed101341a482
    R10: ffff888096027940 R11: ffff88809a0d240f R12: 0000000000000932
    R13: ffff8880a2c14100 R14: ffff88809a0d2268 R15: ffff88809a0d2408
     __blkdev_driver_ioctl block/ioctl.c:304 [inline]
     blkdev_ioctl+0xece/0x1c10 block/ioctl.c:606
     block_ioctl+0xee/0x130 fs/block_dev.c:1930
     vfs_ioctl fs/ioctl.c:46 [inline]
     file_ioctl fs/ioctl.c:509 [inline]
     do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
     ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
     __do_sys_ioctl fs/ioctl.c:720 [inline]
     __se_sys_ioctl fs/ioctl.c:718 [inline]
     __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
     do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    This is caused by a race between two concurrenct md_ioctl()s closing
    the array.
    CPU1 (md_ioctl())                   CPU2 (md_ioctl())
    ------                              ------
    set_bit(MD_CLOSING, &mddev->flags);
    did_set_md_closing = true;
                                        WARN_ON_ONCE(test_bit(MD_CLOSING,
                                                &mddev->flags));
    if(did_set_md_closing)
        clear_bit(MD_CLOSING, &mddev->flags);
    
    Fix the warning by returning immediately if the MD_CLOSING bit is set
    in &mddev->flags which indicates that the array is being closed.
    
    Fixes: 065e519e71b2 ("md: MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop")
    Reported-by: syzbot+1e46a0864c1a6e9bd3d8@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dae R. Jeong <dae.r.jeong@kaist.ac.kr>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 268a84d36ee80752e73db4a3010cac42c7dbdc2b
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Oct 26 13:07:15 2020 -0700

    crypto: af_alg - avoid undefined behavior accessing salg_name
    
    commit 92eb6c3060ebe3adf381fd9899451c5b047bb14d upstream.
    
    Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
    names") made the kernel start accepting arbitrarily long algorithm names
    in sockaddr_alg.  However, the actual length of the salg_name field
    stayed at the original 64 bytes.
    
    This is broken because the kernel can access indices >= 64 in salg_name,
    which is undefined behavior -- even though the memory that is accessed
    is still located within the sockaddr structure.  It would only be
    defined behavior if the array were properly marked as arbitrary-length
    (either by making it a flexible array, which is the recommended way
    these days, or by making it an array of length 0 or 1).
    
    We can't simply change salg_name into a flexible array, since that would
    break source compatibility with userspace programs that embed
    sockaddr_alg into another struct, or (more commonly) declare a
    sockaddr_alg like 'struct sockaddr_alg sa = { .salg_name = "foo" };'.
    
    One solution would be to change salg_name into a flexible array only
    when '#ifdef __KERNEL__'.  However, that would keep userspace without an
    easy way to actually use the longer algorithm names.
    
    Instead, add a new structure 'sockaddr_alg_new' that has the flexible
    array field, and expose it to both userspace and the kernel.
    Make the kernel use it correctly in alg_bind().
    
    This addresses the syzbot report
    "UBSAN: array-index-out-of-bounds in alg_bind"
    (https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e).
    
    Reported-by: syzbot+92ead4eb8e26a26d465e@syzkaller.appspotmail.com
    Fixes: 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names")
    Cc: <stable@vger.kernel.org> # v4.12+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53390efb1d09f43606d710e84b16de87575bc4e3
Author: Antti Palosaari <crope@iki.fi>
Date:   Sat Aug 17 03:12:10 2019 +0200

    media: msi2500: assign SPI bus number dynamically
    
    commit 9c60cc797cf72e95bb39f32316e9f0e5f85435f9 upstream.
    
    SPI bus number must be assigned dynamically for each device, otherwise it
    will crash when multiple devices are plugged to system.
    
    Reported-and-tested-by: syzbot+c60ddb60b685777d9d59@syzkaller.appspotmail.com
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bae84821b47e2ffa87a7afcb6891dd7e61c65ef
Author: Jan Kara <jack@suse.cz>
Date:   Mon Nov 2 16:16:29 2020 +0100

    quota: Sanity-check quota file headers on load
    
    commit 11c514a99bb960941535134f0587102855e8ddee upstream.
    
    Perform basic sanity checks of quota headers to avoid kernel crashes on
    corrupted quota files.
    
    CC: stable@vger.kernel.org
    Reported-by: syzbot+f816042a7ae2225f25ba@syzkaller.appspotmail.com
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61490c481c61ff230da5f6042f353c6c0db0bc0c
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Wed Sep 9 03:17:00 2020 -0400

    Bluetooth: Fix slab-out-of-bounds read in hci_le_direct_adv_report_evt()
    
    commit f7e0e8b2f1b0a09b527885babda3e912ba820798 upstream.
    
    `num_reports` is not being properly checked. A malformed event packet with
    a large `num_reports` number makes hci_le_direct_adv_report_evt() read out
    of bounds. Fix it.
    
    Cc: stable@vger.kernel.org
    Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct Advertising Report events")
    Reported-and-tested-by: syzbot+24ebd650e20bd263ca01@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a3c3a1c67e00942ae4890281b5b56026650bed8
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Thu Dec 3 16:58:34 2020 +1100

    serial_core: Check for port state when tty is in error state
    
    commit 2f70e49ed860020f5abae4f7015018ebc10e1f0e upstream.
    
    At the moment opening a serial device node (such as /dev/ttyS3)
    succeeds even if there is no actual serial device behind it.
    Reading/writing/ioctls fail as expected because the uart port is not
    initialized (the type is PORT_UNKNOWN) and the TTY_IO_ERROR error state
    bit is set fot the tty.
    
    However setting line discipline does not have these checks
    8250_port.c (8250 is the default choice made by univ8250_console_init()).
    As the result of PORT_UNKNOWN, uart_port::iobase is NULL which
    a platform translates onto some address accessing which produces a crash
    like below.
    
    This adds tty_port_initialized() to uart_set_ldisc() to prevent the crash.
    
    Found by syzkaller.
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Link: https://lore.kernel.org/r/20201203055834.45838-1-aik@ozlabs.ru
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 145b35d22ee296cd19d17333373ca56d206e2848
Author: Julian Sax <jsbc@gmx.de>
Date:   Thu Nov 26 18:51:58 2020 +0100

    HID: i2c-hid: add Vero K147 to descriptor override
    
    commit c870d50ce387d84b6438211a7044c60afbd5d60a upstream.
    
    This device uses the SIPODEV SP1064 touchpad, which does not
    supply descriptors, so it has to be added to the override list.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Julian Sax <jsbc@gmx.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 816e0b204e569962e84ee1ee9005df476041367e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Oct 30 17:44:20 2020 +0100

    scsi: megaraid_sas: Check user-provided offsets
    
    commit 381d34e376e3d9d27730fda8a0e870600e6c8196 upstream.
    
    It sounds unwise to let user space pass an unchecked 32-bit offset into a
    kernel structure in an ioctl. This is an unsigned variable, so checking the
    upper bound for the size of the structure it points into is sufficient to
    avoid data corruption, but as the pointer might also be unaligned, it has
    to be written carefully as well.
    
    While I stumbled over this problem by reading the code, I did not continue
    checking the function for further problems like it.
    
    Link: https://lore.kernel.org/r/20201030164450.1253641-2-arnd@kernel.org
    Fixes: c4a3e0a529ab ("[SCSI] MegaRAID SAS RAID: new driver")
    Cc: <stable@vger.kernel.org> # v2.6.15+
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9f589923f03a15402ea1e691e76897be65bb564
Author: Mao Jinlong <jinlmao@codeaurora.org>
Date:   Fri Nov 27 10:52:53 2020 -0700

    coresight: tmc-etr: Check if page is valid before dma_map_page()
    
    commit 1cc573d5754e92372a7e30e35468644f8811e1a4 upstream.
    
    alloc_pages_node() return should be checked before calling
    dma_map_page() to make sure that valid page is mapped or
    else it can lead to aborts as below:
    
     Unable to handle kernel paging request at virtual address ffffffc008000000
     Mem abort info:
     <snip>...
     pc : __dma_inv_area+0x40/0x58
     lr : dma_direct_map_page+0xd8/0x1c8
    
     Call trace:
      __dma_inv_area
      tmc_pages_alloc
      tmc_alloc_data_pages
      tmc_alloc_sg_table
      tmc_init_etr_sg_table
      tmc_alloc_etr_buf
      tmc_enable_etr_sink_sysfs
      tmc_enable_etr_sink
      coresight_enable_path
      coresight_enable
      enable_source_store
      dev_attr_store
      sysfs_kf_write
    
    Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework")
    Cc: stable@vger.kernel.org
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Mao Jinlong <jinlmao@codeaurora.org>
    Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Link: https://lore.kernel.org/r/20201127175256.1092685-13-mathieu.poirier@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 088b972e5cfc2e5be82ee061a02b958ab4270116
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Oct 15 20:20:43 2020 +0200

    ARM: dts: exynos: fix USB 3.0 pins supply being turned off on Odroid XU
    
    commit bd7e7ff56feea7810df900fb09c9741d259861d9 upstream.
    
    On Odroid XU LDO12 and LDO15 supplies the power to USB 3.0 blocks but
    the GPK GPIO pins are supplied by LDO7 (VDDQ_LCD).  LDO7 also supplies
    GPJ GPIO pins.
    
    The Exynos pinctrl driver does not take any supplies, so to have entire
    GPIO block always available, make the regulator always on.
    
    Fixes: 88644b4c750b ("ARM: dts: exynos: Configure PWM, usb3503, PMIC and thermal on Odroid XU board")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201015182044.480562-3-krzk@kernel.org
    Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 840b782cb942b5d9cab8db08de522d9f28365fe6
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Oct 15 20:20:42 2020 +0200

    ARM: dts: exynos: fix USB 3.0 VBUS control and over-current pins on Exynos5410
    
    commit 3d992fd8f4e0f09c980726308d2f2725587b32d6 upstream.
    
    The VBUS control (PWREN) and over-current pins of USB 3.0 DWC3
    controllers are on Exynos5410 regular GPIOs.  This is different than for
    example on Exynos5422 where these are special ETC pins with proper reset
    values (pulls, functions).
    
    Therefore these pins should be configured to enable proper USB 3.0
    peripheral and host modes.  This also fixes over-current warning:
    
        [    6.024658] usb usb4-port1: over-current condition
        [    6.028271] usb usb3-port1: over-current condition
    
    Fixes: cb0896562228 ("ARM: dts: exynos: Add USB to Exynos5410")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201015182044.480562-2-krzk@kernel.org
    Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b722d06f732e839457e993ee949bc6215a30e1c4
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Oct 15 20:20:41 2020 +0200

    ARM: dts: exynos: fix roles of USB 3.0 ports on Odroid XU
    
    commit ecc1ff532b499d20304a4f682247137025814c34 upstream.
    
    On Odroid XU board the USB3-0 port is a microUSB and USB3-1 port is USB
    type A (host).  The roles were copied from Odroid XU3 (Exynos5422)
    design which has it reversed.
    
    Fixes: 8149afe4dbf9 ("ARM: dts: exynos: Add initial support for Odroid XU board")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201015182044.480562-1-krzk@kernel.org
    Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d079263b2ee54eed7534d07f97f32dd17eebc2d7
Author: Fabio Estevam <festevam@gmail.com>
Date:   Mon Dec 7 10:09:09 2020 +0800

    usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to imx6ul
    
    commit c7721e15f434920145c376e8fe77e1c079fc3726 upstream.
    
    According to the i.MX6UL Errata document:
    https://www.nxp.com/docs/en/errata/IMX6ULCE.pdf
    
    ERR007881 also affects i.MX6UL, so pass the
    CI_HDRC_DISABLE_DEVICE_STREAMING flag to workaround the issue.
    
    Fixes: 52fe568e5d71 ("usb: chipidea: imx: add imx6ul usb support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20201207020909.22483-2-peter.chen@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1a14a02296f3a1a29bc0f8632ee8dd262cf13c0
Author: Will McVicker <willmcvicker@google.com>
Date:   Fri Nov 27 15:05:55 2020 +0100

    USB: gadget: f_rndis: fix bitrate for SuperSpeed and above
    
    commit b00f444f9add39b64d1943fa75538a1ebd54a290 upstream.
    
    Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate
    defined by commit 1650113888fe ("usb: gadget: f_ncm: add SuperSpeed descriptors
    for CDC NCM").
    
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: EJ Hsu <ejh@nvidia.com>
    Cc: Peter Chen <peter.chen@nxp.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Will McVicker <willmcvicker@google.com>
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20201127140559.381351-2-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3680c243af7a00940afef8a4f2c8de3364aa5bb9
Author: Jack Pham <jackp@codeaurora.org>
Date:   Tue Oct 27 16:07:31 2020 -0700

    usb: gadget: f_fs: Re-use SS descriptors for SuperSpeedPlus
    
    commit a353397b0d5dfa3c99b372505db3378fc919c6c6 upstream.
    
    In many cases a function that supports SuperSpeed can very well
    operate in SuperSpeedPlus, if a gadget controller supports it,
    as the endpoint descriptors (and companion descriptors) are
    generally identical and can be re-used. This is true for two
    commonly used functions: Android's ADB and MTP. So we can simply
    assign the usb_function's ssp_descriptors array to point to its
    ss_descriptors, if available. Similarly, we need to allow an
    epfile's ioctl for FUNCTIONFS_ENDPOINT_DESC to correctly
    return the corresponding SuperSpeed endpoint descriptor in case
    the connected speed is SuperSpeedPlus as well.
    
    The only exception is if a function wants to implement an
    Isochronous endpoint capable of transferring more than 48KB per
    service interval when operating at greater than USB 3.1 Gen1
    speed, in which case it would require an additional SuperSpeedPlus
    Isochronous Endpoint Companion descriptor to be returned as part
    of the Configuration Descriptor. Support for that would need
    to be separately added to the userspace-facing FunctionFS API
    which may not be a trivial task--likely a new descriptor format
    (v3?) may need to be devised to allow for separate SS and SSP
    descriptors to be supplied.
    
    Signed-off-by: Jack Pham <jackp@codeaurora.org>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201027230731.9073-1-jackp@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fda37854a0a3daff182f6c4e879cf4b015402ee
Author: Will McVicker <willmcvicker@google.com>
Date:   Fri Nov 27 15:05:57 2020 +0100

    USB: gadget: f_midi: setup SuperSpeed Plus descriptors
    
    commit 457a902ba1a73b7720666b21ca038cd19764db18 upstream.
    
    Needed for SuperSpeed Plus support for f_midi.  This allows the
    gadget to work properly without crashing at SuperSpeed rates.
    
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Will McVicker <willmcvicker@google.com>
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20201127140559.381351-4-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d353864a5053d3c5ce5274cc6371a808ba97a256
Author: taehyun.cho <taehyun.cho@samsung.com>
Date:   Fri Nov 27 15:05:56 2020 +0100

    USB: gadget: f_acm: add support for SuperSpeed Plus
    
    commit 3ee05c20656782387aa9eb010fdb9bb16982ac3f upstream.
    
    Setup the SuperSpeed Plus descriptors for f_acm.  This allows the gadget
    to work properly without crashing at SuperSpeed rates.
    
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: taehyun.cho <taehyun.cho@samsung.com>
    Signed-off-by: Will McVicker <willmcvicker@google.com>
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20201127140559.381351-3-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd5b60b923cc75b6da1a3e670b0ebcf1940c98a9
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Dec 9 11:42:21 2020 +0100

    USB: serial: option: add interface-number sanity check to flag handling
    
    commit a251963f76fa0226d0fdf0c4f989496f18d9ae7f upstream.
    
    Add an interface-number sanity check before testing the device flags to
    avoid relying on undefined behaviour when left shifting in case a device
    uses an interface number greater than or equal to BITS_PER_LONG (i.e. 64
    or 32).
    
    Reported-by: syzbot+8881b478dad0a7971f79@syzkaller.appspotmail.com
    Fixes: c3a65808f04a ("USB: serial: option: reimplement interface masking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b5d200895cf9087d6e71a56d4844e0c529ae121
Author: Nicolin Chen <nicoleotsuka@gmail.com>
Date:   Wed Nov 18 20:44:57 2020 -0800

    soc/tegra: fuse: Fix index bug in get_process_id
    
    commit b9ce9b0f83b536a4ac7de7567a265d28d13e5bea upstream.
    
    This patch simply fixes a bug of referencing speedos[num] in every
    for-loop iteration in get_process_id function.
    
    Fixes: 0dc5a0d83675 ("soc/tegra: fuse: Add Tegra210 support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00a39c0c48ae619ffb2a8de327ac4b4e2e98895d
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Nov 13 15:19:10 2020 +0100

    dm table: Remove BUG_ON(in_interrupt())
    
    [ Upstream commit e7b624183d921b49ef0a96329f21647d38865ee9 ]
    
    The BUG_ON(in_interrupt()) in dm_table_event() is a historic leftover from
    a rework of the dm table code which changed the calling context.
    
    Issuing a BUG for a wrong calling context is frowned upon and
    in_interrupt() is deprecated and only covering parts of the wrong
    contexts. The sanity check for the context is covered by
    CONFIG_DEBUG_ATOMIC_SLEEP and other debug facilities already.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe72ad02f8ab634b712a16de8d9c6bd59ee00228
Author: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Date:   Mon Nov 30 13:57:33 2020 +0530

    scsi: mpt3sas: Increase IOCInit request timeout to 30s
    
    [ Upstream commit 85dad327d9b58b4c9ce08189a2707167de392d23 ]
    
    Currently the IOCInit request message timeout is set to 10s. This is not
    sufficient in some scenarios such as during HBA FW downgrade operations.
    
    Increase the IOCInit request timeout to 30s.
    
    Link: https://lore.kernel.org/r/20201130082733.26120-1-sreekanth.reddy@broadcom.com
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 709392673a451c600b5e2db747a1528d39f8d7d4
Author: Sven Eckelmann <sven@narfation.org>
Date:   Thu Nov 26 13:52:47 2020 +0100

    vxlan: Copy needed_tailroom from lowerdev
    
    [ Upstream commit a5e74021e84bb5eadf760aaf2c583304f02269be ]
    
    While vxlan doesn't need any extra tailroom, the lowerdev might need it. In
    that case, copy it over to reduce the chance for additional (re)allocations
    in the transmit path.
    
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Link: https://lore.kernel.org/r/20201126125247.1047977-2-sven@narfation.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf187ef6e11c96cc49227eab966572806dbbc59b
Author: Sven Eckelmann <sven@narfation.org>
Date:   Thu Nov 26 13:52:46 2020 +0100

    vxlan: Add needed_headroom for lower device
    
    [ Upstream commit 0a35dc41fea67ac4495ce7584406bf9557a6e7d0 ]
    
    It was observed that sending data via batadv over vxlan (on top of
    wireguard) reduced the performance massively compared to raw ethernet or
    batadv on raw ethernet. A check of perf data showed that the
    vxlan_build_skb was calling all the time pskb_expand_head to allocate
    enough headroom for:
    
      min_headroom = LL_RESERVED_SPACE(dst->dev) + dst->header_len
                    + VXLAN_HLEN + iphdr_len;
    
    But the vxlan_config_apply only requested needed headroom for:
    
      lowerdev->hard_header_len + VXLAN6_HEADROOM or VXLAN_HEADROOM
    
    So it completely ignored the needed_headroom of the lower device. The first
    caller of net_dev_xmit could therefore never make sure that enough headroom
    was allocated for the rest of the transmit path.
    
    Cc: Annika Wickert <annika.wickert@exaring.de>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Tested-by: Annika Wickert <aw@awlnx.space>
    Link: https://lore.kernel.org/r/20201126125247.1047977-1-sven@narfation.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6abd3ab44001ff55ccff27793b925983cef23198
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Mon Nov 30 11:59:40 2020 +0000

    arm64: syscall: exit userspace before unmasking exceptions
    
    [ Upstream commit ca1314d73eed493c49bb1932c60a8605530db2e4 ]
    
    In el0_svc_common() we unmask exceptions before we call user_exit(), and
    so there's a window where an IRQ or debug exception can be taken while
    RCU is not watching. In do_debug_exception() we account for this in via
    debug_exception_{enter,exit}(), but in the el1_irq asm we do not and we
    call trace functions which rely on RCU before we have a guarantee that
    RCU is watching.
    
    Let's avoid this by having el0_svc_common() exit userspace before
    unmasking exceptions, matching what we do for all other EL0 entry paths.
    We can use user_exit_irqoff() to avoid the pointless save/restore of IRQ
    flags while we're sure exceptions are masked in DAIF.
    
    The workaround for Cortex-A76 erratum 1463225 may trigger a debug
    exception before this point, but the debug code invoked in this case is
    safe even when RCU is not watching.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20201130115950.22492-2-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4069f4247a8bb5d33902232e1ab9fb703a3d2729
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Fri Oct 30 09:34:24 2020 +0800

    drm/tegra: sor: Disable clocks on error in tegra_sor_init()
    
    [ Upstream commit bf3a3cdcad40e5928a22ea0fd200d17fd6d6308d ]
    
    Fix the missing clk_disable_unprepare() before return from
    tegra_sor_init() in the error handling case.
    
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd8098e75562bce212fd229a68f9f6588b9de119
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Thu Nov 26 20:25:29 2020 +1000

    kernel/cpu: add arch override for clear_tasks_mm_cpumask() mm handling
    
    [ Upstream commit 8ff00399b153440c1c83e20c43020385b416415b ]
    
    powerpc/64s keeps a counter in the mm which counts bits set in
    mm_cpumask as well as other things. This means it can't use generic code
    to clear bits out of the mask and doesn't adjust the arch specific
    counter.
    
    Add an arch override that allows powerpc/64s to use
    clear_tasks_mm_cpumask().
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201126102530.691335-4-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d90be35eaf5a0867c606d7b4ad96fa2e4806810b
Author: Deepak R Varma <mh12gx2825@gmail.com>
Date:   Thu Nov 5 23:29:28 2020 +0530

    drm/tegra: replace idr_init() by idr_init_base()
    
    [ Upstream commit 41f71629b4c432f8dd47d70ace813be5f79d4d75 ]
    
    idr_init() uses base 0 which is an invalid identifier for this driver.
    The new function idr_init_base allows IDR to set the ID lookup from
    base 1. This avoids all lookups that otherwise starts from 0 since
    0 is always unused.
    
    References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
    
    Signed-off-by: Deepak R Varma <mh12gx2825@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35d826c94266d842cd4c0a0a60a8805c58397cc2
Author: Björn Töpel <bjorn.topel@intel.com>
Date:   Tue Aug 25 19:27:35 2020 +0200

    ixgbe: avoid premature Rx buffer reuse
    
    [ Upstream commit a06316dc87bdc000f7f39a315476957af2ba0f05 ]
    
    The page recycle code, incorrectly, relied on that a page fragment
    could not be freed inside xdp_do_redirect(). This assumption leads to
    that page fragments that are used by the stack/XDP redirect can be
    reused and overwritten.
    
    To avoid this, store the page count prior invoking xdp_do_redirect().
    
    Fixes: 6453073987ba ("ixgbe: add initial support for xdp redirect")
    Reported-and-analyzed-by: Li RongQing <lirongqing@baidu.com>
    Signed-off-by: Björn Töpel <bjorn.topel@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 de7de695e300900465b4bdd7a796155de20fa00e
Author: Leon Romanovsky <leon@kernel.org>
Date:   Fri Dec 4 08:42:05 2020 +0200

    RDMA/cm: Fix an attempt to use non-valid pointer when cleaning timewait
    
    [ Upstream commit 340b940ea0ed12d9adbb8f72dea17d516b2019e8 ]
    
    If cm_create_timewait_info() fails, the timewait_info pointer will contain
    an error value and will be used in cm_remove_remote() later.
    
      general protection fault, probably for non-canonical address 0xdffffc0000000024: 0000 [#1] SMP KASAN PTI
      KASAN: null-ptr-deref in range [0×0000000000000120-0×0000000000000127]
      CPU: 2 PID: 12446 Comm: syz-executor.3 Not tainted 5.10.0-rc5-5d4c0742a60e #27
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      RIP: 0010:cm_remove_remote.isra.0+0x24/0×170 drivers/infiniband/core/cm.c:978
      Code: 84 00 00 00 00 00 41 54 55 53 48 89 fb 48 8d ab 2d 01 00 00 e8 7d bf 4b fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 04 02 48 89 ea 83 e2 07 38 d0 7f 08 84 c0 0f 85 fc 00 00 00
      RSP: 0018:ffff888013127918 EFLAGS: 00010006
      RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: ffffc9000a18b000
      RDX: 0000000000000024 RSI: ffffffff82edc573 RDI: fffffffffffffff4
      RBP: 0000000000000121 R08: 0000000000000001 R09: ffffed1002624f1d
      R10: 0000000000000003 R11: ffffed1002624f1c R12: ffff888107760c70
      R13: ffff888107760c40 R14: fffffffffffffff4 R15: ffff888107760c9c
      FS:  00007fe1ffcc1700(0000) GS:ffff88811a600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b2ff21000 CR3: 000000010f504001 CR4: 0000000000370ee0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       cm_destroy_id+0x189/0×15b0 drivers/infiniband/core/cm.c:1155
       cma_connect_ib drivers/infiniband/core/cma.c:4029 [inline]
       rdma_connect_locked+0x1100/0×17c0 drivers/infiniband/core/cma.c:4107
       rdma_connect+0x2a/0×40 drivers/infiniband/core/cma.c:4140
       ucma_connect+0x277/0×340 drivers/infiniband/core/ucma.c:1069
       ucma_write+0x236/0×2f0 drivers/infiniband/core/ucma.c:1724
       vfs_write+0x220/0×830 fs/read_write.c:603
       ksys_write+0x1df/0×240 fs/read_write.c:658
       do_syscall_64+0x33/0×40 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
    Link: https://lore.kernel.org/r/20201204064205.145795-1-leon@kernel.org
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Reported-by: Amit Matityahu <mitm@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 1303a9f0f91bab80498a6794c11416413f7cffd1
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Wed Dec 9 14:57:42 2020 +0100

    selftests/bpf/test_offload.py: Reset ethtool features after failed setting
    
    [ Upstream commit 766e62b7fcd2cf1d43e6594ba37c659dc48f7ddb ]
    
    When setting the ethtool feature flag fails (as expected for the test), the
    kernel now tracks that the feature was requested to be 'off' and refuses to
    subsequently disable it again. So reset it back to 'on' so a subsequent
    disable (that's not supposed to fail) can succeed.
    
    Fixes: 417ec26477a5 ("selftests/bpf: add offload test based on netdevsim")
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Link: https://lore.kernel.org/bpf/160752226280.110217.10696241563705667871.stgit@toke.dk
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5239367f6639c99a300404a40bd4c45509e268dd
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date:   Wed Dec 9 13:51:06 2020 +0800

    gpio: eic-sprd: break loop when getting NULL device resource
    
    [ Upstream commit 263ade7166a2e589c5b605272690c155c0637dcb ]
    
    EIC controller have unfixed numbers of banks on different Spreadtrum SoCs,
    and each bank has its own base address, the loop of getting there base
    address in driver should break if the resource gotten via
    platform_get_resource() is NULL already. The later ones would be all NULL
    even if the loop continues.
    
    Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Link: https://lore.kernel.org/r/20201209055106.840100-1-zhang.lyra@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98ab3ff5e789985ec8c24f813c7a989b445da084
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Wed Nov 25 11:27:22 2020 -0700

    netfilter: x_tables: Switch synchronization to RCU
    
    [ Upstream commit cc00bcaa589914096edef7fb87ca5cee4a166b5c ]
    
    When running concurrent iptables rules replacement with data, the per CPU
    sequence count is checked after the assignment of the new information.
    The sequence count is used to synchronize with the packet path without the
    use of any explicit locking. If there are any packets in the packet path using
    the table information, the sequence count is incremented to an odd value and
    is incremented to an even after the packet process completion.
    
    The new table value assignment is followed by a write memory barrier so every
    CPU should see the latest value. If the packet path has started with the old
    table information, the sequence counter will be odd and the iptables
    replacement will wait till the sequence count is even prior to freeing the
    old table info.
    
    However, this assumes that the new table information assignment and the memory
    barrier is actually executed prior to the counter check in the replacement
    thread. If CPU decides to execute the assignment later as there is no user of
    the table information prior to the sequence check, the packet path in another
    CPU may use the old table information. The replacement thread would then free
    the table information under it leading to a use after free in the packet
    processing context-
    
    Unable to handle kernel NULL pointer dereference at virtual
    address 000000000000008e
    pc : ip6t_do_table+0x5d0/0x89c
    lr : ip6t_do_table+0x5b8/0x89c
    ip6t_do_table+0x5d0/0x89c
    ip6table_filter_hook+0x24/0x30
    nf_hook_slow+0x84/0x120
    ip6_input+0x74/0xe0
    ip6_rcv_finish+0x7c/0x128
    ipv6_rcv+0xac/0xe4
    __netif_receive_skb+0x84/0x17c
    process_backlog+0x15c/0x1b8
    napi_poll+0x88/0x284
    net_rx_action+0xbc/0x23c
    __do_softirq+0x20c/0x48c
    
    This could be fixed by forcing instruction order after the new table
    information assignment or by switching to RCU for the synchronization.
    
    Fixes: 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
    Reported-by: Sean Tranchetti <stranche@codeaurora.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Suggested-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7894076fbc90e8c2528e339d50f0e669a6e7fc7a
Author: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Date:   Wed Mar 25 00:24:44 2020 +0900

    block: factor out requeue handling from dispatch code
    
    [ Upstream commit c92a41031a6d57395889b5c87cea359220a24d2a ]
    
    Factor out the requeue handling from the dispatch code, this will make
    subsequent addition of different requeueing schemes easier.
    
    Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f601479cdbe57f294a8894f35518113cda94cef9
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Nov 30 09:57:43 2020 +0100

    clk: renesas: r9a06g032: Drop __packed for portability
    
    [ Upstream commit ceabbf94c317c6175dee6e91805fca4a6353745a ]
    
    The R9A06G032 clock driver uses an array of packed structures to reduce
    kernel size.  However, this array contains pointers, which are no longer
    aligned naturally, and cannot be relocated on PPC64.  Hence when
    compile-testing this driver on PPC64 with CONFIG_RELOCATABLE=y (e.g.
    PowerPC allyesconfig), the following warnings are produced:
    
        WARNING: 136 bad relocations
        c000000000616be3 R_PPC64_UADDR64   .rodata+0x00000000000cf338
        c000000000616bfe R_PPC64_UADDR64   .rodata+0x00000000000cf370
        ...
    
    Fix this by dropping the __packed attribute from the r9a06g032_clkdesc
    definition, trading a small size increase for portability.
    
    This increases the 156-entry clock table by 1 byte per entry, but due to
    the compiler generating more efficient code for unpacked accesses, the
    net size increase is only 76 bytes (gcc 9.3.0 on arm32).
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20201130085743.1656317-1-geert+renesas@glider.be
    Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # PowerPC allyesconfig build
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56f7a0a34ac66fa4945fb38e4cd4fa9e757c04e9
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Dec 4 14:35:06 2020 +0100

    can: softing: softing_netdev_open(): fix error handling
    
    [ Upstream commit 4d1be581ec6b92a338bb7ed23e1381f45ddf336f ]
    
    If softing_netdev_open() fails, we should call close_candev() to avoid
    reference leak.
    
    Fixes: 03fd3cf5a179d ("can: add driver for Softing card")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Acked-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
    Link: https://lore.kernel.org/r/20201202151632.1343786-1-zhangqilong3@huawei.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Link: https://lore.kernel.org/r/20201204133508.742120-2-mkl@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 377bd57ed7ad2417228c6969b014e868a5b90c3a
Author: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Date:   Wed Nov 20 01:10:42 2019 +0100

    xsk: Fix xsk_poll()'s return type
    
    [ Upstream commit 5d946c5abbaf68083fa6a41824dd79e1f06286d8 ]
    
    xsk_poll() is defined as returning 'unsigned int' but the
    .poll method is declared as returning '__poll_t', a bitwise type.
    
    Fix this by using the proper return type and using the EPOLL
    constants instead of the POLL ones, as required for __poll_t.
    
    Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Björn Töpel <bjorn.topel@intel.com>
    Link: https://lore.kernel.org/bpf/20191120001042.30830-1-luc.vanoostenryck@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 076ba445d59296689ddaa8f90916ee29f7ca3dda
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Nov 28 23:09:16 2020 -0800

    scsi: bnx2i: Requires MMU
    
    [ Upstream commit 2d586494c4a001312650f0b919d534e429dd1e09 ]
    
    The SCSI_BNX2_ISCSI kconfig symbol selects CNIC and CNIC selects UIO, which
    depends on MMU.
    
    Since 'select' does not follow dependency chains, add the same MMU
    dependency to SCSI_BNX2_ISCSI.
    
    Quietens this kconfig warning:
    
    WARNING: unmet direct dependencies detected for CNIC
      Depends on [n]: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && PCI [=y] && (IPV6 [=m] || IPV6 [=m]=n) && MMU [=n]
      Selected by [m]:
      - SCSI_BNX2_ISCSI [=m] && SCSI_LOWLEVEL [=y] && SCSI [=y] && NET [=y] && PCI [=y] && (IPV6 [=m] || IPV6 [=m]=n)
    
    Link: https://lore.kernel.org/r/20201129070916.3919-1-rdunlap@infradead.org
    Fixes: cf4e6363859d ("[SCSI] bnx2i: Add bnx2i iSCSI driver.")
    Cc: linux-scsi@vger.kernel.org
    Cc: Nilesh Javali <njavali@marvell.com>
    Cc: Manish Rangankar <mrangankar@marvell.com>
    Cc: GR-QLogic-Storage-Upstream@marvell.com
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b219352f7ee6799b79ed32ec39b374a089f682a1
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Wed Dec 2 09:15:32 2020 +0200

    gpio: mvebu: fix potential user-after-free on probe
    
    [ Upstream commit 7ee1a01e47403f72b9f38839a737692f6991263e ]
    
    When mvebu_pwm_probe() fails IRQ domain is not released. Move pwm probe
    before IRQ domain allocation. Add pwm cleanup code to the failure path.
    
    Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
    Reported-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43e15738075ab328f385f8220d5c736f6b609a45
Author: Icenowy Zheng <icenowy@aosc.io>
Date:   Fri Nov 20 13:08:51 2020 +0800

    ARM: dts: sun8i: v3s: fix GIC node memory range
    
    [ Upstream commit a98fd117a2553ab1a6d2fe3c7acae88c1eca4372 ]
    
    Currently the GIC node in V3s DTSI follows some old DT examples, and
    being broken. This leads a warning at boot.
    
    Fix this.
    
    Fixes: f989086ccbc6 ("ARM: dts: sunxi: add dtsi file for V3s SoC")
    Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20201120050851.4123759-1-icenowy@aosc.io
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd809b0daab5a10fbb128ff2702da5fb0a07bb0d
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Nov 12 21:03:01 2020 +0200

    pinctrl: baytrail: Avoid clearing debounce value when turning it off
    
    [ Upstream commit 0b74e40a4e41f3cbad76dff4c50850d47b525b26 ]
    
    Baytrail pin control has a common register to set up debounce timeout.
    When a pin configuration requested debounce to be disabled, the rest
    of the pins may still want to have debounce enabled and thus rely on
    the common timeout value. Avoid clearing debounce value when turning
    it off for one pin while others may still use it.
    
    Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
    Depends-on: 04ff5a095d66 ("pinctrl: baytrail: Rectify debounce support")
    Depends-on: 827e1579e1d5 ("pinctrl: baytrail: Rectify debounce support (part 2)")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7549ccaebe0c11cf262662d354ab8e3f6c123d9a
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Nov 11 14:06:05 2020 +0200

    pinctrl: merrifield: Set default bias in case no particular value given
    
    [ Upstream commit 0fa86fc2e28227f1e64f13867e73cf864c6d25ad ]
    
    When GPIO library asks pin control to set the bias, it doesn't pass
    any value of it and argument is considered boolean (and this is true
    for ACPI GpioIo() / GpioInt() resources, by the way). Thus, individual
    drivers must behave well, when they got the resistance value of 1 Ohm,
    i.e. transforming it to sane default.
    
    In case of Intel Merrifield pin control hardware the 20 kOhm sounds plausible
    because it gives a good trade off between weakness and minimization of leakage
    current (will be only 50 uA with the above choice).
    
    Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support")
    Depends-on: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39152c3c2380ac966b6e359869adf748b295f31c
Author: Xiaochen Shen <xiaochen.shen@intel.com>
Date:   Fri Dec 4 14:27:59 2020 +0800

    x86/resctrl: Fix incorrect local bandwidth when mba_sc is enabled
    
    commit 06c5fe9b12dde1b62821f302f177c972bb1c81f9 upstream
    
    The MBA software controller (mba_sc) is a feedback loop which
    periodically reads MBM counters and tries to restrict the bandwidth
    below a user-specified value. It tags along the MBM counter overflow
    handler to do the updates with 1s interval in mbm_update() and
    update_mba_bw().
    
    The purpose of mbm_update() is to periodically read the MBM counters to
    make sure that the hardware counter doesn't wrap around more than once
    between user samplings. mbm_update() calls __mon_event_count() for local
    bandwidth updating when mba_sc is not enabled, but calls mbm_bw_count()
    instead when mba_sc is enabled. __mon_event_count() will not be called
    for local bandwidth updating in MBM counter overflow handler, but it is
    still called when reading MBM local bandwidth counter file
    'mbm_local_bytes', the call path is as below:
    
      rdtgroup_mondata_show()
        mon_event_read()
          mon_event_count()
            __mon_event_count()
    
    In __mon_event_count(), m->chunks is updated by delta chunks which is
    calculated from previous MSR value (m->prev_msr) and current MSR value.
    When mba_sc is enabled, m->chunks is also updated in mbm_update() by
    mistake by the delta chunks which is calculated from m->prev_bw_msr
    instead of m->prev_msr. But m->chunks is not used in update_mba_bw() in
    the mba_sc feedback loop.
    
    When reading MBM local bandwidth counter file, m->chunks was changed
    unexpectedly by mbm_bw_count(). As a result, the incorrect local
    bandwidth counter which calculated from incorrect m->chunks is shown to
    the user.
    
    Fix this by removing incorrect m->chunks updating in mbm_bw_count() in
    MBM counter overflow handler, and always calling __mon_event_count() in
    mbm_update() to make sure that the hardware local bandwidth counter
    doesn't wrap around.
    
    Test steps:
      # Run workload with aggressive memory bandwidth (e.g., 10 GB/s)
      git clone https://github.com/intel/intel-cmt-cat && cd intel-cmt-cat
      && make
      ./tools/membw/membw -c 0 -b 10000 --read
    
      # Enable MBA software controller
      mount -t resctrl resctrl -o mba_MBps /sys/fs/resctrl
    
      # Create control group c1
      mkdir /sys/fs/resctrl/c1
    
      # Set MB throttle to 6 GB/s
      echo "MB:0=6000;1=6000" > /sys/fs/resctrl/c1/schemata
    
      # Write PID of the workload to tasks file
      echo `pidof membw` > /sys/fs/resctrl/c1/tasks
    
      # Read local bytes counters twice with 1s interval, the calculated
      # local bandwidth is not as expected (approaching to 6 GB/s):
      local_1=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes`
      sleep 1
      local_2=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes`
      echo "local b/w (bytes/s):" `expr $local_2 - $local_1`
    
    Before fix:
      local b/w (bytes/s): 11076796416
    
    After fix:
      local b/w (bytes/s): 5465014272
    
    Fixes: ba0f26d8529c (x86/intel_rdt/mba_sc: Prepare for feedback loop)
    Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/1607063279-19437-1-git-send-email-xiaochen.shen@intel.com
    [sudip: manual backport to file at old path]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8b506affe10d12e8fb71c3d69dc8f609d3a05ba
Author: James Morse <james.morse@arm.com>
Date:   Wed Jul 8 16:39:20 2020 +0000

    x86/resctrl: Remove unused struct mbm_state::chunks_bw
    
    commit abe8f12b44250d02937665033a8b750c1bfeb26e upstream
    
    Nothing reads struct mbm_states's chunks_bw value, its a copy of
    chunks. Remove it.
    
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Link: https://lkml.kernel.org/r/20200708163929.2783-2-james.morse@arm.com
    [sudip: manual backport to file at old path]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13ed97c2bb939890fe0814d6952189dfec57797f
Author: Fangrui Song <maskray@google.com>
Date:   Thu Oct 29 11:19:51 2020 -0700

    arm64: Change .weak to SYM_FUNC_START_WEAK_PI for arch/arm64/lib/mem*.S
    
    commit ec9d78070de986ecf581ea204fd322af4d2477ec upstream.
    
    Commit 39d114ddc682 ("arm64: add KASAN support") added .weak directives to
    arch/arm64/lib/mem*.S instead of changing the existing SYM_FUNC_START_PI
    macros. This can lead to the assembly snippet `.weak memcpy ... .globl
    memcpy` which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL
    memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since
    https://reviews.llvm.org/D90108) will error on such an overridden symbol
    binding.
    
    Use the appropriate SYM_FUNC_START_WEAK_PI instead.
    
    Fixes: 39d114ddc682 ("arm64: add KASAN support")
    Reported-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Fangrui Song <maskray@google.com>
    Tested-by: Sami Tolvanen <samitolvanen@google.com>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201029181951.1866093-1-maskray@google.com
    Signed-off-by: Will Deacon <will@kernel.org>
    [nd: backport to adjust for missing:
      commit 3ac0f4526dfb ("arm64: lib: Use modern annotations for assembly functions")
      commit 35e61c77ef38 ("arm64: asm: Add new-style position independent function annotations")]
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96fd4981791602ba6f4cbe23c4bd9386408940c1
Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
Date:   Tue Feb 18 16:49:06 2020 +0000

    arm64: lse: Fix LSE atomics with LLVM
    
    commit dd1f6308b28edf0452dd5dc7877992903ec61e69 upstream.
    
    Commit e0d5896bd356 ("arm64: lse: fix LSE atomics with LLVM's integrated
    assembler") broke the build when clang is used in connjunction with the
    binutils assembler ("-no-integrated-as"). This happens because
    __LSE_PREAMBLE is defined as ".arch armv8-a+lse", which overrides the
    version of the CPU architecture passed via the "-march" paramter to gas:
    
    $ aarch64-none-linux-gnu-as -EL -I ./arch/arm64/include
                                    -I ./arch/arm64/include/generated
                                    -I ./include -I ./include
                                    -I ./arch/arm64/include/uapi
                                    -I ./arch/arm64/include/generated/uapi
                                    -I ./include/uapi -I ./include/generated/uapi
                                    -I ./init -I ./init
                                    -march=armv8.3-a -o init/do_mounts.o
                                    /tmp/do_mounts-d7992a.s
    /tmp/do_mounts-d7992a.s: Assembler messages:
    /tmp/do_mounts-d7992a.s:1959: Error: selected processor does not support `autiasp'
    /tmp/do_mounts-d7992a.s:2021: Error: selected processor does not support `paciasp'
    /tmp/do_mounts-d7992a.s:2157: Error: selected processor does not support `autiasp'
    /tmp/do_mounts-d7992a.s:2175: Error: selected processor does not support `paciasp'
    /tmp/do_mounts-d7992a.s:2494: Error: selected processor does not support `autiasp'
    
    Fix the issue by replacing ".arch armv8-a+lse" with ".arch_extension lse".
    Sami confirms that the clang integrated assembler does now support the
    '.arch_extension' directive, so this change will be fine even for LTO
    builds in future.
    
    Fixes: e0d5896bd356cd ("arm64: lse: fix LSE atomics with LLVM's integrated assembler")
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Reported-by: Amit Kachhap <Amit.Kachhap@arm.com>
    Tested-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5681cce44cf41dc3eed8fd62b9e299bb57d1cb7b
Author: Sami Tolvanen <samitolvanen@google.com>
Date:   Thu Oct 31 12:57:05 2019 -0700

    arm64: lse: fix LSE atomics with LLVM's integrated assembler
    
    commit e0d5896bd356cd577f9710a02d7a474cdf58426b upstream.
    
    Unlike gcc, clang considers each inline assembly block to be independent
    and therefore, when using the integrated assembler for inline assembly,
    any preambles that enable features must be repeated in each block.
    
    This change defines __LSE_PREAMBLE and adds it to each inline assembly
    block that has LSE instructions, which allows them to be compiled also
    with clang's assembler.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/671
    Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
    Tested-by: Andrew Murray <andrew.murray@arm.com>
    Tested-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Andrew Murray <andrew.murray@arm.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    [nd: backport adjusted due to missing:
      commit addfc38672c7 ("arm64: atomics: avoid out-of-line ll/sc atomics")]
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88ee1af064560d62df2d419484a96c6b01c0eb71
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Sun Jul 19 23:45:45 2020 +0800

    drm: fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi
    
    commit a34a0a632dd991a371fec56431d73279f9c54029 upstream
    
    drm_dp_mst_allocate_vcpi() invokes
    drm_dp_mst_topology_get_port_validated(), which increases the refcount
    of the "port".
    
    These reference counting issues take place in two exception handling
    paths separately. Either when “slots” is less than 0 or when
    drm_dp_init_vcpi() returns a negative value, the function forgets to
    reduce the refcnt increased drm_dp_mst_topology_get_port_validated(),
    which results in a refcount leak.
    
    Fix these issues by pulling up the error handling when "slots" is less
    than 0, and calling drm_dp_mst_topology_put_port() before termination
    when drm_dp_init_vcpi() returns a negative value.
    
    Fixes: 1e797f556c61 ("drm/dp: Split drm_dp_mst_allocate_vcpi")
    Cc: <stable@vger.kernel.org> # v4.12+
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200719154545.GA41231@xin-virtual-machine
    [sudip: use old functions before rename]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb60f048941265ed4d2de82002183e366f2b8a12
Author: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Date:   Thu Aug 13 09:21:10 2020 +0300

    drm/xen-front: Fix misused IS_ERR_OR_NULL checks
    
    commit 14dee058610446aa464254fc5c8e88c7535195e0 upstream
    
    The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
    display frontend" from Apr 3, 2018, leads to the following static
    checker warning:
    
            drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
            warn: passing zero to 'ERR_CAST'
    
    drivers/gpu/drm/xen/xen_drm_front_gem.c
       133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
       134                                                  size_t size)
       135  {
       136          struct xen_gem_object *xen_obj;
       137
       138          xen_obj = gem_create(dev, size);
       139          if (IS_ERR_OR_NULL(xen_obj))
       140                  return ERR_CAST(xen_obj);
    
    Fix this and the rest of misused places with IS_ERR_OR_NULL in the
    driver.
    
    Fixes:  c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend"
    
    Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200813062113.11030-3-andr2000@gmail.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcf9b7fbc2ac6b8d6b5f45a445fe3ed48b44234c
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Date:   Thu Dec 10 06:52:57 2020 +0100

    serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
    
    commit d96f04d347e4011977abdbb4da5d8f303ebd26f8 upstream.
    
    It has been observed that once per 300-1300 port openings the first
    transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared
    as "e" on the wire). It only happened if single byte has been transmitted
    right after port open, which means, DMA is not used for this transfer and
    the corruption never happened afterwards.
    
    Therefore I've carefully re-read the MDR1 errata (link below), which says
    "when accessing the MDR1 registers that causes a dummy under-run condition
    that will freeze the UART in IrDA transmission. In UART mode, this may
    corrupt the transferred data". Strictly speaking,
    omap_8250_mdr1_errataset() performs a read access and if the value is the
    same as should be written, exits without errata-recommended FIFO reset.
    
    A brief check of the serial_omap_mdr1_errataset() from the competing
    omap-serial driver showed it has no read access of MDR1. After removing the
    read access from omap_8250_mdr1_errataset() the data corruption never
    happened any more.
    
    Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf
    Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37172cffc6a4e5371c9a514ad6ab870108a73c9f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 9 09:45:52 2020 +0100

    ALSA: pcm: oss: Fix potential out-of-bounds shift
    
    commit 175b8d89fe292796811fdee87fa39799a5b6b87a upstream.
    
    syzbot spotted a potential out-of-bounds shift in the PCM OSS layer
    where it calculates the buffer size with the arbitrary shift value
    given via an ioctl.
    
    Add a range check for avoiding the undefined behavior.
    As the value can be treated by a signed integer, the max shift should
    be 30.
    
    Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201209084552.17109-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 912ce3daea6ff339c012d8388cde951fa8133d34
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Oct 19 12:06:30 2020 +0200

    USB: sisusbvga: Make console support depend on BROKEN
    
    commit 862ee699fefe1e6d6f2c1518395f0b999b8beb15 upstream.
    
    The console part of sisusbvga is broken vs. printk(). It uses in_atomic()
    to detect contexts in which it cannot sleep despite the big fat comment in
    preempt.h which says: Do not use in_atomic() in driver code.
    
    in_atomic() does not work on kernels with CONFIG_PREEMPT_COUNT=n which
    means that spin/rw_lock held regions are not detected by it.
    
    There is no way to make this work by handing context information through to
    the driver and this only can be solved once the core printk infrastructure
    supports sleepable console drivers.
    
    Make it depend on BROKEN for now.
    
    Fixes: 1bbb4f2035d9 ("[PATCH] USB: sisusb[vga] update")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Thomas Winischhofer <thomas@winischhofer.net>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: linux-usb@vger.kernel.org
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201019101109.603244207@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59fb80b4f24d310bcb026b722386393f3c24ba19
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Dec 9 16:26:39 2020 +0100

    USB: UAS: introduce a quirk to set no_write_same
    
    commit 8010622c86ca5bb44bc98492f5968726fc7c7a21 upstream.
    
    UAS does not share the pessimistic assumption storage is making that
    devices cannot deal with WRITE_SAME.  A few devices supported by UAS,
    are reported to not deal well with WRITE_SAME. Those need a quirk.
    
    Add it to the device that needs it.
    
    Reported-by: David C. Partridge <david.partridge@perdrix.co.uk>
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201209152639.9195-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 509bc7057f4f103e9558589c372222e746748d98
Author: Li Jun <jun.li@nxp.com>
Date:   Tue Dec 8 11:29:12 2020 +0200

    xhci: Give USB2 ports time to enter U3 in bus suspend
    
    commit c1373f10479b624fb6dba0805d673e860f1b421d upstream.
    
    If a USB2 device wakeup is not enabled/supported the link state may
    still be in U0 in xhci_bus_suspend(), where it's then manually put
    to suspended U3 state.
    
    Just as with selective suspend the device needs time to enter U3
    suspend before continuing with further suspend operations
    (e.g. system suspend), otherwise we may enter system suspend with link
    state in U0.
    
    [commit message rewording -Mathias]
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20201208092912.1773650-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b4ea92e45841e41b20cb96d55a645e7fbb5b82c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 11 14:00:48 2020 +0100

    ALSA: usb-audio: Fix control 'access overflow' errors from chmap
    
    commit c6dde8ffd071aea9d1ce64279178e470977b235c upstream.
    
    The current channel-map control implementation in USB-audio driver may
    lead to an error message like
      "control 3:0:0:Playback Channel Map:0: access overflow"
    when CONFIG_SND_CTL_VALIDATION is set.  It's because the chmap get
    callback clears the whole array no matter which count is set, and
    rather the false-positive detection.
    
    This patch fixes the problem by clearing only the needed array range
    at usb_chmap_ctl_get().
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201211130048.6358-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e60956a2d672adcf4e9f96c8e6c2c3fb113c8898
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 9 09:45:51 2020 +0100

    ALSA: usb-audio: Fix potential out-of-bounds shift
    
    commit 43d5ca88dfcd35e43010fdd818e067aa9a55f5ba upstream.
    
    syzbot spotted a potential out-of-bounds shift in the USB-audio format
    parser that receives the arbitrary shift value from the USB
    descriptor.
    
    Add a range check for avoiding the undefined behavior.
    
    Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201209084552.17109-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 465a57d94d7c9e8f54c513e572dc8119b5ce199c
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Dec 7 14:03:23 2020 +0100

    USB: add RESET_RESUME quirk for Snapscan 1212
    
    commit 08a02f954b0def3ada8ed6d4b2c7bcb67e885e9c upstream.
    
    I got reports that some models of this old scanner need
    this when using runtime PM.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201207130323.23857-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a9534ce92700ec04885b1eefe319fa877b5f5e4
Author: Bui Quang Minh <minhquangbui99@gmail.com>
Date:   Fri Dec 4 06:24:49 2020 +0000

    USB: dummy-hcd: Fix uninitialized array use in init()
    
    commit e90cfa813da7a527785033a0b247594c2de93dd8 upstream.
    
    This error path
    
            err_add_pdata:
                    for (i = 0; i < mod_data.num; i++)
                            kfree(dum[i]);
    
    can be triggered when not all dum's elements are initialized.
    
    Fix this by initializing all dum's elements to NULL.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
    Link: https://lore.kernel.org/r/1607063090-3426-1-git-send-email-minhquangbui99@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 013a9ef37f8497915979bd6a17d5a0af79f4c10d
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Mon Nov 30 16:32:55 2020 -0500

    ktest.pl: If size of log is too big to email, email error message
    
    commit 8cd6bc0359deebd8500e6de95899a8a78d3ec4ba upstream.
    
    If the size of the error log is too big to send via email, and the sending
    fails, it wont email any result. This can be confusing for the user who is
    waiting for an email on the completion of the tests.
    
    If it fails to send email, then try again without the log file stating that
    it failed to send an email. Obviously this will not be of use if the sending
    of email failed for some other reasons, but it will at least give the user
    some information when it fails for the most common reason.
    
    Cc: stable@vger.kernel.org
    Fixes: c2d84ddb338c8 ("ktest.pl: Add MAIL_COMMAND option to define how to send email")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e64cc462703f209ff0db62e5c75b7019df0cac97
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:48:56 2020 +0800

    net: bridge: vlan: fix error return code in __vlan_add()
    
    [ Upstream commit ee4f52a8de2c6f78b01f10b4c330867d88c1653a ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: f8ed289fab84 ("bridge: vlan: use br_vlan_(get|put)_master to deal with refcounts")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Link: https://lore.kernel.org/r/1607071737-33875-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db49408ad92e10a7c2bad473723f9c6a5662d8f8
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Dec 5 22:32:07 2020 +0100

    net: stmmac: dwmac-meson8b: fix mask definition of the m250_sel mux
    
    [ Upstream commit 82ca4c922b8992013a238d65cf4e60cc33e12f36 ]
    
    The m250_sel mux clock uses bit 4 in the PRG_ETH0 register. Fix this by
    shifting the PRG_ETH0_CLK_M250_SEL_MASK accordingly as the "mask" in
    struct clk_mux expects the mask relative to the "shift" field in the
    same struct.
    
    While here, get rid of the PRG_ETH0_CLK_M250_SEL_SHIFT macro and use
    __ffs() to determine it from the existing PRG_ETH0_CLK_M250_SEL_MASK
    macro.
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20201205213207.519341-1-martin.blumenstingl@googlemail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30b1b5aae6b2ffef8e0cf64fb0b555bb3e4a1026
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Mon Dec 7 18:51:40 2020 +0800

    net: stmmac: delete the eee_ctrl_timer after napi disabled
    
    [ Upstream commit 5f58591323bf3f342920179f24515935c4b5fd60 ]
    
    There have chance to re-enable the eee_ctrl_timer and fire the timer
    in napi callback after delete the timer in .stmmac_release(), which
    introduces to access eee registers in the timer function after clocks
    are disabled then causes system hang. Found this issue when do
    suspend/resume and reboot stress test.
    
    It is safe to delete the timer after napi disabled and disable lpi mode.
    
    Fixes: d765955d2ae0b ("stmmac: add the Energy Efficient Ethernet support")
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba88ac9e5832be764f25d233f51e064302717314
Author: Moshe Shemesh <moshe@mellanox.com>
Date:   Wed Dec 9 15:03:39 2020 +0200

    net/mlx4_en: Handle TX error CQE
    
    [ Upstream commit ba603d9d7b1215c72513d7c7aa02b6775fd4891b ]
    
    In case error CQE was found while polling TX CQ, the QP is in error
    state and all posted WQEs will generate error CQEs without any data
    transmitted. Fix it by reopening the channels, via same method used for
    TX timeout handling.
    
    In addition add some more info on error CQE and WQE for debug.
    
    Fixes: bd2f631d7c60 ("net/mlx4_en: Notify user when TX ring in error state")
    Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21ef20ffe9f0e5307278e1bd16b4ae305776c9c6
Author: Sergej Bauer <sbauer@blackbox.su>
Date:   Mon Nov 2 01:35:55 2020 +0300

    lan743x: fix for potential NULL pointer dereference with bare card
    
    [ Upstream commit e9e13b6adc338be1eb88db87bcb392696144bd02 ]
    
    This is the 3rd revision of the patch fix for potential null pointer dereference
    with lan743x card.
    
    The simpliest way to reproduce: boot with bare lan743x and issue "ethtool ethN"
    commant where ethN is the interface with lan743x card. Example:
    
    $ sudo ethtool eth7
    dmesg:
    [  103.510336] BUG: kernel NULL pointer dereference, address: 0000000000000340
    ...
    [  103.510836] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy]
    ...
    [  103.511629] Call Trace:
    [  103.511666]  lan743x_ethtool_get_wol+0x21/0x40 [lan743x]
    [  103.511724]  dev_ethtool+0x1507/0x29d0
    [  103.511769]  ? avc_has_extended_perms+0x17f/0x440
    [  103.511820]  ? tomoyo_init_request_info+0x84/0x90
    [  103.511870]  ? tomoyo_path_number_perm+0x68/0x1e0
    [  103.511919]  ? tty_insert_flip_string_fixed_flag+0x82/0xe0
    [  103.511973]  ? inet_ioctl+0x187/0x1d0
    [  103.512016]  dev_ioctl+0xb5/0x560
    [  103.512055]  sock_do_ioctl+0xa0/0x140
    [  103.512098]  sock_ioctl+0x2cb/0x3c0
    [  103.512139]  __x64_sys_ioctl+0x84/0xc0
    [  103.512183]  do_syscall_64+0x33/0x80
    [  103.512224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  103.512274] RIP: 0033:0x7f54a9cba427
    ...
    
    Previous versions can be found at:
    v1:
    initial version
        https://lkml.org/lkml/2020/10/28/921
    
    v2:
    do not return from lan743x_ethtool_set_wol if netdev->phydev == NULL, just skip
    the call of phy_ethtool_set_wol() instead.
        https://lkml.org/lkml/2020/10/31/380
    
    v3:
    in function lan743x_ethtool_set_wol:
    use ternary operator instead of if-else sentence (review by Markus Elfring)
    return -ENETDOWN insted of -EIO (review by Andrew Lunn)
    
    Signed-off-by: Sergej Bauer <sbauer@blackbox.su>
    
    Link: https://lore.kernel.org/r/20201101223556.16116-1-sbauer@blackbox.su
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7eb728345c422220407b68e339abd4a0cfb26439
Author: Moshe Shemesh <moshe@mellanox.com>
Date:   Wed Dec 9 15:03:38 2020 +0200

    net/mlx4_en: Avoid scheduling restart task if it is already running
    
    [ Upstream commit fed91613c9dd455dd154b22fa8e11b8526466082 ]
    
    Add restarting state flag to avoid scheduling another restart task while
    such task is already running. Change task name from watchdog_task to
    restart_task to better fit the task role.
    
    Fixes: 1e338db56e5a ("mlx4_en: Fix a race at restart task")
    Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bbbaaf3e64d934785f4c17f03d327a695d01006
Author: Neal Cardwell <ncardwell@google.com>
Date:   Tue Dec 8 22:57:59 2020 -0500

    tcp: fix cwnd-limited bug for TSO deferral where we send nothing
    
    [ Upstream commit 299bcb55ecd1412f6df606e9dc0912d55610029e ]
    
    When cwnd is not a multiple of the TSO skb size of N*MSS, we can get
    into persistent scenarios where we have the following sequence:
    
    (1) ACK for full-sized skb of N*MSS arrives
      -> tcp_write_xmit() transmit full-sized skb with N*MSS
      -> move pacing release time forward
      -> exit tcp_write_xmit() because pacing time is in the future
    
    (2) TSQ callback or TCP internal pacing timer fires
      -> try to transmit next skb, but TSO deferral finds remainder of
         available cwnd is not big enough to trigger an immediate send
         now, so we defer sending until the next ACK.
    
    (3) repeat...
    
    So we can get into a case where we never mark ourselves as
    cwnd-limited for many seconds at a time, even with
    bulk/infinite-backlog senders, because:
    
    o In case (1) above, every time in tcp_write_xmit() we have enough
    cwnd to send a full-sized skb, we are not fully using the cwnd
    (because cwnd is not a multiple of the TSO skb size). So every time we
    send data, we are not cwnd limited, and so in the cwnd-limited
    tracking code in tcp_cwnd_validate() we mark ourselves as not
    cwnd-limited.
    
    o In case (2) above, every time in tcp_write_xmit() that we try to
    transmit the "remainder" of the cwnd but defer, we set the local
    variable is_cwnd_limited to true, but we do not send any packets, so
    sent_pkts is zero, so we don't call the cwnd-limited logic to update
    tp->is_cwnd_limited.
    
    Fixes: ca8a22634381 ("tcp: make cwnd-limited checks measurement-based, and gentler")
    Reported-by: Ingemar Johansson <ingemar.s.johansson@ericsson.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20201209035759.1225145-1-ncardwell.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bf5774646e56c0860fa45c078ab6c1b8e8443c5
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 8 08:21:31 2020 -0800

    tcp: select sane initial rcvq_space.space for big MSS
    
    [ Upstream commit 72d05c00d7ecda85df29abd046da7e41cc071c17 ]
    
    Before commit a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
    small tcp_rmem[1] values were overridden by tcp_fixup_rcvbuf() to accommodate various MSS.
    
    This is no longer the case, and Hazem Mohamed Abuelfotoh reported
    that DRS would not work for MTU 9000 endpoints receiving regular (1500 bytes) frames.
    
    Root cause is that tcp_init_buffer_space() uses tp->rcv_wnd for upper limit
    of rcvq_space.space computation, while it can select later a smaller
    value for tp->rcv_ssthresh and tp->window_clamp.
    
    ss -temoi on receiver would show :
    
    skmem:(r0,rb131072,t0,tb46080,f0,w0,o0,bl0,d0) rcv_space:62496 rcv_ssthresh:56596
    
    This means that TCP can not increase its window in tcp_grow_window(),
    and that DRS can never kick.
    
    Fix this by making sure that rcvq_space.space is not bigger than number of bytes
    that can be held in TCP receive queue.
    
    People unable/unwilling to change their kernel can work around this issue by
    selecting a bigger tcp_rmem[1] value as in :
    
    echo "4096 196608 6291456" >/proc/sys/net/ipv4/tcp_rmem
    
    Based on an initial report and patch from Hazem Mohamed Abuelfotoh
     https://lore.kernel.org/netdev/20201204180622.14285-1-abuehaze@amazon.com/
    
    Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
    Fixes: 041a14d26715 ("tcp: start receiver buffer autotuning sooner")
    Reported-by: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cd5b620bce836862cf04ec51acf7c6594c86d82
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Mon Dec 7 18:51:39 2020 +0800

    net: stmmac: free tx skb buffer in stmmac_resume()
    
    [ Upstream commit 4ec236c7c51f89abb0224a4da4a6b77f9beb6600 ]
    
    When do suspend/resume test, there have WARN_ON() log dump from
    stmmac_xmit() funciton, the code logic:
            entry = tx_q->cur_tx;
            first_entry = entry;
            WARN_ON(tx_q->tx_skbuff[first_entry]);
    
    In normal case, tx_q->tx_skbuff[txq->cur_tx] should be NULL because
    the skb should be handled and freed in stmmac_tx_clean().
    
    But stmmac_resume() reset queue parameters like below, skb buffers
    may not be freed.
            tx_q->cur_tx = 0;
            tx_q->dirty_tx = 0;
    
    So free tx skb buffer in stmmac_resume() to avoid warning and
    memory leak.
    
    log:
    [   46.139824] ------------[ cut here ]------------
    [   46.144453] WARNING: CPU: 0 PID: 0 at drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3235 stmmac_xmit+0x7a0/0x9d0
    [   46.154969] Modules linked in: crct10dif_ce vvcam(O) flexcan can_dev
    [   46.161328] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      5.4.24-2.1.0+g2ad925d15481 #1
    [   46.170369] Hardware name: NXP i.MX8MPlus EVK board (DT)
    [   46.175677] pstate: 80000005 (Nzcv daif -PAN -UAO)
    [   46.180465] pc : stmmac_xmit+0x7a0/0x9d0
    [   46.184387] lr : dev_hard_start_xmit+0x94/0x158
    [   46.188913] sp : ffff800010003cc0
    [   46.192224] x29: ffff800010003cc0 x28: ffff000177e2a100
    [   46.197533] x27: ffff000176ef0840 x26: ffff000176ef0090
    [   46.202842] x25: 0000000000000000 x24: 0000000000000000
    [   46.208151] x23: 0000000000000003 x22: ffff8000119ddd30
    [   46.213460] x21: ffff00017636f000 x20: ffff000176ef0cc0
    [   46.218769] x19: 0000000000000003 x18: 0000000000000000
    [   46.224078] x17: 0000000000000000 x16: 0000000000000000
    [   46.229386] x15: 0000000000000079 x14: 0000000000000000
    [   46.234695] x13: 0000000000000003 x12: 0000000000000003
    [   46.240003] x11: 0000000000000010 x10: 0000000000000010
    [   46.245312] x9 : ffff00017002b140 x8 : 0000000000000000
    [   46.250621] x7 : ffff00017636f000 x6 : 0000000000000010
    [   46.255930] x5 : 0000000000000001 x4 : ffff000176ef0000
    [   46.261238] x3 : 0000000000000003 x2 : 00000000ffffffff
    [   46.266547] x1 : ffff000177e2a000 x0 : 0000000000000000
    [   46.271856] Call trace:
    [   46.274302]  stmmac_xmit+0x7a0/0x9d0
    [   46.277874]  dev_hard_start_xmit+0x94/0x158
    [   46.282056]  sch_direct_xmit+0x11c/0x338
    [   46.285976]  __qdisc_run+0x118/0x5f0
    [   46.289549]  net_tx_action+0x110/0x198
    [   46.293297]  __do_softirq+0x120/0x23c
    [   46.296958]  irq_exit+0xb8/0xd8
    [   46.300098]  __handle_domain_irq+0x64/0xb8
    [   46.304191]  gic_handle_irq+0x5c/0x148
    [   46.307936]  el1_irq+0xb8/0x180
    [   46.311076]  cpuidle_enter_state+0x84/0x360
    [   46.315256]  cpuidle_enter+0x34/0x48
    [   46.318829]  call_cpuidle+0x18/0x38
    [   46.322314]  do_idle+0x1e0/0x280
    [   46.325539]  cpu_startup_entry+0x24/0x40
    [   46.329460]  rest_init+0xd4/0xe0
    [   46.332687]  arch_call_rest_init+0xc/0x14
    [   46.336695]  start_kernel+0x420/0x44c
    [   46.340353] ---[ end trace bc1ee695123cbacd ]---
    
    Fixes: 47dd7a540b8a0 ("net: add support for STMicroelectronics Ethernet controllers.")
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 084a24477d017a52e542b8a87063d7afc9b86ca2
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Dec 4 08:24:28 2020 -0800

    mac80211: mesh: fix mesh_pathtbl_init() error path
    
    [ Upstream commit 905b2032fa424f253d9126271439cc1db2b01130 ]
    
    If tbl_mpp can not be allocated, we call mesh_table_free(tbl_path)
    while tbl_path rhashtable has not yet been initialized, which causes
    panics.
    
    Simply factorize the rhashtable_init() call into mesh_table_alloc()
    
    WARNING: CPU: 1 PID: 8474 at kernel/workqueue.c:3040 __flush_work kernel/workqueue.c:3040 [inline]
    WARNING: CPU: 1 PID: 8474 at kernel/workqueue.c:3040 __cancel_work_timer+0x514/0x540 kernel/workqueue.c:3136
    Modules linked in:
    CPU: 1 PID: 8474 Comm: syz-executor663 Not tainted 5.10.0-rc6-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__flush_work kernel/workqueue.c:3040 [inline]
    RIP: 0010:__cancel_work_timer+0x514/0x540 kernel/workqueue.c:3136
    Code: 5d c3 e8 bf ae 29 00 0f 0b e9 f0 fd ff ff e8 b3 ae 29 00 0f 0b 43 80 3c 3e 00 0f 85 31 ff ff ff e9 34 ff ff ff e8 9c ae 29 00 <0f> 0b e9 dc fe ff ff 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c 7d fd ff
    RSP: 0018:ffffc9000165f5a0 EFLAGS: 00010293
    RAX: ffffffff814b7064 RBX: 0000000000000001 RCX: ffff888021c80000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff888024039ca0 R08: dffffc0000000000 R09: fffffbfff1dd3e64
    R10: fffffbfff1dd3e64 R11: 0000000000000000 R12: 1ffff920002cbebd
    R13: ffff888024039c88 R14: 1ffff11004807391 R15: dffffc0000000000
    FS:  0000000001347880(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000140 CR3: 000000002cc0a000 CR4: 00000000001506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     rhashtable_free_and_destroy+0x25/0x9c0 lib/rhashtable.c:1137
     mesh_table_free net/mac80211/mesh_pathtbl.c:69 [inline]
     mesh_pathtbl_init+0x287/0x2e0 net/mac80211/mesh_pathtbl.c:785
     ieee80211_mesh_init_sdata+0x2ee/0x530 net/mac80211/mesh.c:1591
     ieee80211_setup_sdata+0x733/0xc40 net/mac80211/iface.c:1569
     ieee80211_if_add+0xd5c/0x1cd0 net/mac80211/iface.c:1987
     ieee80211_add_iface+0x59/0x130 net/mac80211/cfg.c:125
     rdev_add_virtual_intf net/wireless/rdev-ops.h:45 [inline]
     nl80211_new_interface+0x563/0xb40 net/wireless/nl80211.c:3855
     genl_family_rcv_msg_doit net/netlink/genetlink.c:739 [inline]
     genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
     genl_rcv_msg+0xe4e/0x1280 net/netlink/genetlink.c:800
     netlink_rcv_skb+0x190/0x3a0 net/netlink/af_netlink.c:2494
     genl_rcv+0x24/0x40 net/netlink/genetlink.c:811
     netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
     netlink_unicast+0x780/0x930 net/netlink/af_netlink.c:1330
     netlink_sendmsg+0x9a8/0xd40 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:651 [inline]
     sock_sendmsg net/socket.c:671 [inline]
     ____sys_sendmsg+0x519/0x800 net/socket.c:2353
     ___sys_sendmsg net/socket.c:2407 [inline]
     __sys_sendmsg+0x2b1/0x360 net/socket.c:2440
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
    Link: https://lore.kernel.org/r/20201204162428.2583119-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4458d16bdc957bf4ddebd2fb7f58d1c79b9cfdad
Author: Ansuel Smith <ansuelsmth@gmail.com>
Date:   Mon Jun 15 23:06:00 2020 +0200

    PCI: qcom: Add missing reset for ipq806x
    
    commit ee367e2cdd2202b5714982739e684543cd2cee0e upstream
    
    Add missing ext reset used by ipq8064 SoC in PCIe qcom driver.
    
    Link: https://lore.kernel.org/r/20200615210608.21469-5-ansuelsmth@gmail.com
    Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
    Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
    Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
    Cc: stable@vger.kernel.org # v4.5+
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b207caff4176e3a6ba273243da2db2e595e4aad2
Author: Arvind Sankar <nivedita@alum.mit.edu>
Date:   Fri Nov 13 22:51:59 2020 -0800

    compiler.h: fix barrier_data() on clang
    
    commit 3347acc6fcd4ee71ad18a9ff9d9dac176b517329 upstream.
    
    Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
    mutually exclusive") neglected to copy barrier_data() from
    compiler-gcc.h into compiler-clang.h.
    
    The definition in compiler-gcc.h was really to work around clang's more
    aggressive optimization, so this broke barrier_data() on clang, and
    consequently memzero_explicit() as well.
    
    For example, this results in at least the memzero_explicit() call in
    lib/crypto/sha256.c:sha256_transform() being optimized away by clang.
    
    Fix this by moving the definition of barrier_data() into compiler.h.
    
    Also move the gcc/clang definition of barrier() into compiler.h,
    __memory_barrier() is icc-specific (and barrier() is already defined
    using it in compiler-intel.h) and doesn't belong in compiler.h.
    
    [rdunlap@infradead.org: fix ALPHA builds when SMP is not enabled]
    
    Link: https://lkml.kernel.org/r/20201101231835.4589-1-rdunlap@infradead.org
    Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive")
    Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20201014212631.207844-1-nivedita@alum.mit.edu
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [nd: backport to account for missing
      commit e506ea451254a ("compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h")
      commit d08b9f0ca6605 ("scs: Add support for Clang's Shadow Call Stack (SCS)")
      commit a3f8a30f3f00 ("Compiler Attributes: use feature checks instead of version checks")]
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af7e080cf4128a1dba42d990bf0c9785ed68767d
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Dec 10 21:18:22 2020 +0100

    x86/apic/vector: Fix ordering in vector assignment
    
    commit 190113b4c6531c8e09b31d5235f9b5175cbb0f72 upstream.
    
    Prarit reported that depending on the affinity setting the
    
     ' irq $N: Affinity broken due to vector space exhaustion.'
    
    message is showing up in dmesg, but the vector space on the CPUs in the
    affinity mask is definitely not exhausted.
    
    Shung-Hsi provided traces and analysis which pinpoints the problem:
    
    The ordering of trying to assign an interrupt vector in
    assign_irq_vector_any_locked() is simply wrong if the interrupt data has a
    valid node assigned. It does:
    
     1) Try the intersection of affinity mask and node mask
     2) Try the node mask
     3) Try the full affinity mask
     4) Try the full online mask
    
    Obviously #2 and #3 are in the wrong order as the requested affinity
    mask has to take precedence.
    
    In the observed cases #1 failed because the affinity mask did not contain
    CPUs from node 0. That made it allocate a vector from node 0, thereby
    breaking affinity and emitting the misleading message.
    
    Revert the order of #2 and #3 so the full affinity mask without the node
    intersection is tried before actually affinity is broken.
    
    If no node is assigned then only the full affinity mask and if that fails
    the full online mask is tried.
    
    Fixes: d6ffc6ac83b1 ("x86/vector: Respect affinity mask in irq descriptor")
    Reported-by: Prarit Bhargava <prarit@redhat.com>
    Reported-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87ft4djtyp.fsf@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c34df413beb6b54a38e6583ac95114c321742b1
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Dec 3 21:07:03 2020 -0800

    x86/membarrier: Get rid of a dubious optimization
    
    commit a493d1ca1a03b532871f1da27f8dbda2b28b04c4 upstream.
    
    sync_core_before_usermode() had an incorrect optimization.  If the kernel
    returns from an interrupt, it can get to usermode without IRET. It just has
    to schedule to a different task in the same mm and do SYSRET.  Fortunately,
    there were no callers of sync_core_before_usermode() that could have had
    in_irq() or in_nmi() equal to true, because it's only ever called from the
    scheduler.
    
    While at it, clarify a related comment.
    
    Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE")
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/5afc7632be1422f91eaf7611aaaa1b5b8580a086.1607058304.git.luto@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 912f16267793dbb898215b655e4d666a09e81578
Author: Arvind Sankar <nivedita@alum.mit.edu>
Date:   Wed Nov 11 11:09:45 2020 -0500

    x86/mm/mem_encrypt: Fix definition of PMD_FLAGS_DEC_WP
    
    commit 29ac40cbed2bc06fa218ca25d7f5e280d3d08a25 upstream.
    
    The PAT bit is in different locations for 4k and 2M/1G page table
    entries.
    
    Add a definition for _PAGE_LARGE_CACHE_MASK to represent the three
    caching bits (PWT, PCD, PAT), similar to _PAGE_CACHE_MASK for 4k pages,
    and use it in the definition of PMD_FLAGS_DEC_WP to get the correct PAT
    index for write-protected pages.
    
    Fixes: 6ebcb060713f ("x86/mm: Add support to encrypt the kernel in-place")
    Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20201111160946.147341-1-nivedita@alum.mit.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23045c5f49c74d162a7368f8c05c1ffceb53fd18
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Dec 3 15:18:26 2020 +0300

    scsi: be2iscsi: Revert "Fix a theoretical leak in beiscsi_create_eqs()"
    
    commit eeaf06af6f87e1dba371fbe42674e6f963220b9c upstream.
    
    My patch caused kernel Oopses and delays in boot.  Revert it.
    
    The problem was that I moved the "mem->dma = paddr;" before the call to
    be_fill_queue().  But the first thing that the be_fill_queue() function
    does is memset the whole struct to zero which overwrites the assignment.
    
    Link: https://lore.kernel.org/r/X8jXkt6eThjyVP1v@mwanda
    Fixes: 38b2db564d9a ("scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd2583d25c2346061f99881f44af86d027b98195
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 11 13:36:38 2020 -0800

    kbuild: avoid static_assert for genksyms
    
    commit 14dc3983b5dff513a90bd5a8cc90acaf7867c3d0 upstream.
    
    genksyms does not know or care about the _Static_assert() built-in, and
    sometimes falls back to ignoring the later symbols, which causes
    undefined behavior such as
    
      WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned.
      ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object
      net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation
    
    Redefine static_assert for genksyms to avoid that.
    
    Link: https://lkml.kernel.org/r/20201203230955.1482058-1-arnd@kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Suggested-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Michal Marek <michal.lkml@markovi.net>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Rikard Falkeborn <rikard.falkeborn@gmail.com>
    Cc: Marco Elver <elver@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 95190daaf93dc77a30d3d3b3f91d3cf26a37741c
Author: Bean Huo <beanhuo@micron.com>
Date:   Wed Dec 2 21:23:20 2020 +0100

    mmc: block: Fixup condition for CMD13 polling for RPMB requests
    
    commit 6246d7c9d15aaff0bc3863f67900c6a6e6be921b upstream.
    
    The CMD13 polling is needed for commands with R1B responses. In commit
    a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B
    response"), the intent was to introduce this for requests targeted to the
    RPMB partition. However, the condition to trigger the polling loop became
    wrong, leading to unnecessary polling. Let's fix the condition to avoid
    this.
    
    Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response")
    Cc: stable@vger.kernel.org
    Reported-by: Zhan Liu <zliua@micron.com>
    Signed-off-by: Zhan Liu <zliua@micron.com>
    Signed-off-by: Bean Huo <beanhuo@micron.com>
    Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 063bfcf4ac67cbf919bf78a10efad7908388101a
Author: Coiby Xu <coiby.xu@gmail.com>
Date:   Wed Nov 25 21:03:19 2020 +0800

    pinctrl: amd: remove debounce filter setting in IRQ type setting
    
    commit 47a0001436352c9853d72bf2071e85b316d688a2 upstream.
    
    Debounce filter setting should be independent from IRQ type setting
    because according to the ACPI specs, there are separate arguments for
    specifying debounce timeout and IRQ type in GpioIo() and GpioInt().
    
    Together with commit 06abe8291bc31839950f7d0362d9979edc88a666
    ("pinctrl: amd: fix incorrect way to disable debounce filter") and
    Andy's patch "gpiolib: acpi: Take into account debounce settings" [1],
    this will fix broken touchpads for laptops whose BIOS set the
    debounce timeout to a relatively large value. For example, the BIOS
    of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000),
    Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce
    timeout to 124.8ms. This led to the kernel receiving only ~7 HID
    reports per second from the Synaptics touchpad
    (MSFT0001:00 06CB:7F28).
    
    Existing touchpads like [2][3] are not troubled by this bug because
    the debounce timeout has been set to 0 by the BIOS before enabling
    the debounce filter in setting IRQ type.
    
    [1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/
        8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings")
    [2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582
    [3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28
    
    Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/
    BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190
    Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3eb605efc721464955ddbe785cc4ecba16b9ba4
Author: Chris Chiu <chiu@endlessos.org>
Date:   Wed Dec 9 20:24:47 2020 -0800

    Input: i8042 - add Acer laptops to the i8042 reset list
    
    commit ce6520b0eafad5962ffc21dc47cd7bd3250e9045 upstream.
    
    The touchpad operates in Basic Mode by default in the Acer BIOS
    setup, but some Aspire/TravelMate models require the i8042 to be
    reset in order to be correctly detected.
    
    Signed-off-by: Chris Chiu <chiu@endlessos.org>
    Link: https://lore.kernel.org/r/20201207071250.15021-1-chiu@endlessos.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 956d173d4f0a92b12dcd976b42c04bd60723605e
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Dec 9 20:13:24 2020 -0800

    Input: cm109 - do not stomp on control URB
    
    commit 82e06090473289ce63e23fdeb8737aad59b10645 upstream.
    
    We need to make sure we are not stomping on the control URB that was
    issued when opening the device when attempting to toggle buzzer.
    To do that we need to mark it as pending in cm109_open().
    
    Reported-and-tested-by: syzbot+150f793ac5bc18eee150@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5386457f1b6f590514d67db8dc20331d32bee32
Author: Max Verevkin <me@maxverevkin.tk>
Date:   Tue Nov 24 15:16:52 2020 +0200

    platform/x86: intel-vbtn: Support for tablet mode on HP Pavilion 13 x360 PC
    
    [ Upstream commit 8b205d3e1bf52ab31cdd5c55f87c87a227793d84 ]
    
    The Pavilion 13 x360 PC has a chassis-type which does not indicate it is
    a convertible, while it is actually a convertible. Add it to the
    dmi_switches_allow_list.
    
    Signed-off-by: Max Verevkin <me@maxverevkin.tk>
    Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tk
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e23483c5036439fd79ba2573c1f72b9cadd56c78
Author: Timo Witte <timo.witte@gmail.com>
Date:   Tue Aug 4 02:14:23 2020 +0200

    platform/x86: acer-wmi: add automatic keyboard background light toggle key as KEY_LIGHTS_TOGGLE
    
    [ Upstream commit 9e7a005ad56aa7d6ea5830c5ffcc60bf35de380b ]
    
    Got a dmesg message on my AMD Renoir based Acer laptop:
    "acer_wmi: Unknown key number - 0x84" when toggling keyboard
    background light
    
    Signed-off-by: Timo Witte <timo.witte@gmail.com>
    Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
    Link: https://lore.kernel.org/r/20200804001423.36778-1-timo.witte@gmail.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da1abb8bc242995ae907b5bfc4590d2f93d487dc
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Nov 9 11:35:50 2020 +0100

    platform/x86: thinkpad_acpi: Add BAT1 is primary battery quirk for Thinkpad Yoga 11e 4th gen
    
    [ Upstream commit c986a7024916c92a775fc8d853fba3cae1d5fde4 ]
    
    The Thinkpad Yoga 11e 4th gen with the N3450 / Celeron CPU only has
    one battery which is named BAT1 instead of the expected BAT0, add a
    quirk for this. This fixes not being able to set the charging tresholds
    on this model; and this alsoe fixes the following errors in dmesg:
    
    ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as error
    thinkpad_acpi: Error probing battery 2
    battery: extension failed to load: ThinkPad Battery Extension
    battery: extension unregistered: ThinkPad Battery Extension
    
    Note that the added quirk is for the "R0K" BIOS versions which are
    used on the Thinkpad Yoga 11e 4th gen's with a Celeron CPU, there
    is a separate "R0L" BIOS for the i3/i5 based versions. This may also
    need the same quirk, but if that really is necessary is unknown.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201109103550.16265-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03e122ae3c5dbd2bc10c650e014039b587f4d29d
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Nov 6 15:01:30 2020 +0100

    platform/x86: thinkpad_acpi: Do not report SW_TABLET_MODE on Yoga 11e
    
    [ Upstream commit f2eae1888cf22590c38764b8fa3c989c0283870e ]
    
    The Yoga 11e series has 2 accelerometers described by a BOSC0200 ACPI node.
    This setup relies on a Windows service which reads both accelerometers and
    then calculates the angle between the 2 halves to determine laptop / tent /
    tablet mode and then reports the calculated mode back to the EC by calling
    special ACPI methods on the BOSC0200 node.
    
    The bmc150 iio driver does not support this (it involves double
    calculations requiring sqrt and arccos so this really needs to be done
    in userspace), as a result of this on the Yoga 11e the thinkpad_acpi
    code always reports SW_TABLET_MODE=0, starting with GNOME 3.38 reporting
    SW_TABLET_MODE=0 causes GNOME to:
    
    1. Not show the onscreen keyboard when a text-input field is focussed
       with the touchscreen.
    2. Disable accelerometer based auto display-rotation.
    
    This makes sense when in laptop-mode but not when in tablet-mode. But
    since for the Yoga 11e the thinkpad_acpi code always reports
    SW_TABLET_MODE=0, GNOME does not know when the device is in tablet-mode.
    
    Stop reporting the broken (always 0) SW_TABLET_MODE on Yoga 11e models
    to fix this.
    
    Note there are plans for userspace to support 360 degree hinges style
    2-in-1s with 2 accelerometers and figure out the mode by itself, see:
    https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/216
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201106140130.46820-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a65d094db8514836e99b6557000bb4a10be9ecda
Author: Hao Si <si.hao@zte.com.cn>
Date:   Tue Oct 20 10:18:32 2020 +0800

    soc: fsl: dpio: Get the cpumask through cpumask_of(cpu)
    
    [ Upstream commit 2663b3388551230cbc4606a40fabf3331ceb59e4 ]
    
    The local variable 'cpumask_t mask' is in the stack memory, and its address
    is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
    But the memory area where this variable is located is at risk of being
    modified.
    
    During LTP testing, the following error was generated:
    
    Unable to handle kernel paging request at virtual address ffff000012e9b790
    Mem abort info:
      ESR = 0x96000007
      Exception class = DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
    Data abort info:
      ISV = 0, ISS = 0x00000007
      CM = 0, WnR = 0
    swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07
    [ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003,
    pmd=00000027b6d61003, pte=0000000000000000
    Internal error: Oops: 96000007 [#1] PREEMPT SMP
    Modules linked in: xt_conntrack
    Process read_all (pid: 20171, stack limit = 0x0000000044ea4095)
    CPU: 14 PID: 20171 Comm: read_all Tainted: G    B   W
    Hardware name: NXP Layerscape LX2160ARDB (DT)
    pstate: 80000085 (Nzcv daIf -PAN -UAO)
    pc : irq_affinity_hint_proc_show+0x54/0xb0
    lr : irq_affinity_hint_proc_show+0x4c/0xb0
    sp : ffff00001138bc10
    x29: ffff00001138bc10 x28: 0000ffffd131d1e0
    x27: 00000000007000c0 x26: ffff8025b9480dc0
    x25: ffff8025b9480da8 x24: 00000000000003ff
    x23: ffff8027334f8300 x22: ffff80272e97d000
    x21: ffff80272e97d0b0 x20: ffff8025b9480d80
    x19: ffff000009a49000 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000
    x15: 0000000000000000 x14: 0000000000000000
    x13: 0000000000000000 x12: 0000000000000040
    x11: 0000000000000000 x10: ffff802735b79b88
    x9 : 0000000000000000 x8 : 0000000000000000
    x7 : ffff000009a49848 x6 : 0000000000000003
    x5 : 0000000000000000 x4 : ffff000008157d6c
    x3 : ffff00001138bc10 x2 : ffff000012e9b790
    x1 : 0000000000000000 x0 : 0000000000000000
    Call trace:
     irq_affinity_hint_proc_show+0x54/0xb0
     seq_read+0x1b0/0x440
     proc_reg_read+0x80/0xd8
     __vfs_read+0x60/0x178
     vfs_read+0x94/0x150
     ksys_read+0x74/0xf0
     __arm64_sys_read+0x24/0x30
     el0_svc_common.constprop.0+0xd8/0x1a0
     el0_svc_handler+0x34/0x88
     el0_svc+0x10/0x14
    Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041)
    ---[ end trace b495bdcb0b3b732b ]---
    Kernel panic - not syncing: Fatal exception
    SMP: stopping secondary CPUs
    SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
    Kernel Offset: disabled
    CPU features: 0x0,21006008
    Memory Limit: none
    ---[ end Kernel panic - not syncing: Fatal exception ]---
    
    Fix it by using 'cpumask_of(cpu)' to get the cpumask.
    
    Signed-off-by: Hao Si <si.hao@zte.com.cn>
    Signed-off-by: Lin Chen <chen.lin5@zte.com.cn>
    Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
    Signed-off-by: Li Yang <leoyang.li@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c486401a3dbce692a5c82f10518ae96a259f5f2
Author: Xu Qiang <xuqiang36@huawei.com>
Date:   Sat Nov 7 10:42:26 2020 +0000

    irqchip/gic-v3-its: Unconditionally save/restore the ITS state on suspend
    
    [ Upstream commit 74cde1a53368aed4f2b4b54bf7030437f64a534b ]
    
    On systems without HW-based collections (i.e. anything except GIC-500),
    we rely on firmware to perform the ITS save/restore. This doesn't
    really work, as although FW can properly save everything, it cannot
    fully restore the state of the command queue (the read-side is reset
    to the head of the queue). This results in the ITS consuming previously
    processed commands, potentially corrupting the state.
    
    Instead, let's always save the ITS state on suspend, disabling it in the
    process, and restore the full state on resume. This saves us from broken
    FW as long as it doesn't enable the ITS by itself (for which we can't do
    anything).
    
    This amounts to simply dropping the ITS_FLAGS_SAVE_SUSPEND_STATE.
    
    Signed-off-by: Xu Qiang <xuqiang36@huawei.com>
    [maz: added warning on resume, rewrote commit message]
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20201107104226.14282-1-xuqiang36@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0e74c97fe3f0affa3d1d9f0527894e153c1605a
Author: Can Guo <cang@codeaurora.org>
Date:   Tue Sep 22 00:09:04 2020 -0700

    scsi: ufs: Make sure clk scaling happens only when HBA is runtime ACTIVE
    
    [ Upstream commit 73cc291c270248567245f084dcdf5078069af6b5 ]
    
    If someone plays with the UFS clk scaling devfreq governor through sysfs,
    ufshcd_devfreq_scale may be called even when HBA is not runtime ACTIVE.
    This can lead to unexpected error. We cannot just protect it by calling
    pm_runtime_get_sync() because that may cause a race condition since HBA
    runtime suspend ops need to suspend clk scaling. To fix this call
    pm_runtime_get_noresume() and check HBA's runtime status. Only proceed if
    HBA is runtime ACTIVE, otherwise just bail.
    
    governor_store
     devfreq_performance_handler
      update_devfreq
       devfreq_set_target
        ufshcd_devfreq_target
         ufshcd_devfreq_scale
    
    Link: https://lore.kernel.org/r/1600758548-28576-1-git-send-email-cang@codeaurora.org
    Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Can Guo <cang@codeaurora.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e25867ac4168fd56d67dd5c34c4cab8f5f3948d
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Fri Nov 6 16:59:27 2020 -0800

    ARC: stack unwinding: don't assume non-current task is sleeping
    
    [ Upstream commit e42404fa10fd11fe72d0a0e149a321d10e577715 ]
    
    To start stack unwinding (SP, PC and BLINK) are needed. When the
    explicit execution context (pt_regs etc) is not available, unwinder
    assumes the task is sleeping (in __switch_to()) and fetches SP and BLINK
    from kernel mode stack.
    
    But this assumption is not true, specially in a SMP system, when top
    runs on 1 core, there may be active running processes on all cores.
    
    So when unwinding non courrent tasks, ensure they are NOT running.
    
    And while at it, handle the self unwinding case explicitly.
    
    This came out of investigation of a customer reported hang with
    rcutorture+top
    
    Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/31
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57ac40ee09cea2ec90f71c6f49b15d0d82667b38
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon Nov 16 23:09:13 2020 +1100

    powerpc: Drop -me200 addition to build flags
    
    [ Upstream commit e02152ba2810f7c88cb54e71cda096268dfa9241 ]
    
    Currently a build with CONFIG_E200=y will fail with:
    
      Error: invalid switch -me200
      Error: unrecognized option -me200
    
    Upstream binutils has never supported an -me200 option. Presumably it
    was supported at some point by either a fork or Freescale internal
    binutils.
    
    We can't support code that we can't even build test, so drop the
    addition of -me200 to the build flags, so we can at least build with
    CONFIG_E200=y.
    
    Reported-by: Németh Márton <nm127@freemail.hu>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Acked-by: Scott Wood <oss@buserror.net>
    Link: https://lore.kernel.org/r/20201116120913.165317-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c750d08b192e0eebcc21b1265a771be7df096987
Author: Sara Sharon <sara.sharon@intel.com>
Date:   Sat Nov 7 10:50:11 2020 +0200

    iwlwifi: mvm: fix kernel panic in case of assert during CSA
    
    [ Upstream commit fe56d05ee6c87f6a1a8c7267affd92c9438249cc ]
    
    During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx.
    In case we have a FW assert right after it, it remains NULL though.
    We end up running into endless loop due to mac80211 trying repeatedly to
    move us to ASSOC state, and we keep returning -EINVAL. Later down the road
    we hit a kernel panic.
    
    Detect and avoid this endless loop.
    
    Signed-off-by: Sara Sharon <sara.sharon@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.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 217f50dd949d385389548039cb7270ed9c2309f9
Author: Markus Reichl <m.reichl@fivetechno.de>
Date:   Wed Nov 4 17:23:55 2020 +0100

    arm64: dts: rockchip: Assign a fixed index to mmc devices on rk3399 boards.
    
    [ Upstream commit 0011c6d182774fc781fb9e115ebe8baa356029ae ]
    
    Recently introduced async probe on mmc devices can shuffle block IDs.
    Pin them to fixed values to ease booting in environments where UUIDs
    are not practical. Use newly introduced aliases for mmcblk devices from [1].
    
    [1]
    https://patchwork.kernel.org/patch/11747669/
    
    Signed-off-by: Markus Reichl <m.reichl@fivetechno.de>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20201104162356.1251-1-m.reichl@fivetechno.de
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a9897daf92ceef6869888f14d76d00d7791fa6d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Oct 22 16:51:03 2020 +0300

    iwlwifi: pcie: limit memory read spin time
    
    [ Upstream commit 04516706bb99889986ddfa3a769ed50d2dc7ac13 ]
    
    When we read device memory, we lock a spinlock, write the address we
    want to read from the device and then spin in a loop reading the data
    in 32-bit quantities from another register.
    
    As the description makes clear, this is rather inefficient, incurring
    a PCIe bus transaction for every read. In a typical device today, we
    want to read 786k SMEM if it crashes, leading to 192k register reads.
    Occasionally, we've seen the whole loop take over 20 seconds and then
    triggering the soft lockup detector.
    
    Clearly, it is unreasonable to spin here for such extended periods of
    time.
    
    To fix this, break the loop down into an outer and an inner loop, and
    break out of the inner loop if more than half a second elapsed. To
    avoid too much overhead, check for that only every 128 reads, though
    there's no particular reason for that number. Then, unlock and relock
    to obtain NIC access again, reprogram the start address and continue.
    
    This will keep (interrupt) latencies on the CPU down to a reasonable
    time.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Mordechay Goodstein <mordechay.goodstein@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.20201022165103.45878a7e49aa.I3b9b9c5a10002915072312ce75b68ed5b3dc6e14@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e2f19a1dc4190b7a391a15d01940e45ec49ad22
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Dec 10 20:20:02 2020 +0100

    spi: bcm2835aux: Restore err assignment in bcm2835aux_spi_probe
    
    [ Upstream commit d853b3406903a7dc5b14eb5bada3e8cd677f66a2 ]
    
    Clang warns:
    
    drivers/spi/spi-bcm2835aux.c:532:50: warning: variable 'err' is
    uninitialized when used here [-Wuninitialized]
                    dev_err(&pdev->dev, "could not get clk: %d\n", err);
                                                                   ^~~
    ./include/linux/dev_printk.h:112:32: note: expanded from macro 'dev_err'
            _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
                                          ^~~~~~~~~~~
    drivers/spi/spi-bcm2835aux.c:495:9: note: initialize the variable 'err'
    to silence this warning
            int err;
                   ^
                    = 0
    1 warning generated.
    
    Restore the assignment so that the error value can be used in the
    dev_err statement and there is no uninitialized memory being leaked.
    
    Fixes: e13ee6cc4781 ("spi: bcm2835aux: Fix use-after-free on unbind")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1199
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Link: https://lore.kernel.org/r/20201113180701.455541-1-natechancellor@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [lukas: backport to 4.19-stable, add stable designation]
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.4+: e13ee6cc4781: spi: bcm2835aux: Fix use-after-free on unbind
    Cc: <stable@vger.kernel.org> # v4.4+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b3f38cef400571ab292c77fdaa8e02a0ad44cd7
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Dec 10 20:20:01 2020 +0100

    spi: bcm2835aux: Fix use-after-free on unbind
    
    [ Upstream commit e13ee6cc4781edaf8c7321bee19217e3702ed481 ]
    
    bcm2835aux_spi_remove() accesses the driver's private data after calling
    spi_unregister_master() even though that function releases the last
    reference on the spi_master and thereby frees the private data.
    
    Fix by switching over to the new devm_spi_alloc_master() helper which
    keeps the private data accessible until the driver has unbound.
    
    Fixes: b9dd3f6d4172 ("spi: bcm2835aux: Fix controller unregister order")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.4+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v4.4+: b9dd3f6d4172: spi: bcm2835aux: Fix controller unregister order
    Cc: <stable@vger.kernel.org> # v4.4+
    Link: https://lore.kernel.org/r/b290b06357d0c0bdee9cecc539b840a90630f101.1605121038.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d43a80f2822f3f0450396617b2ab169d8564bc3e
Author: Fangrui Song <maskray@google.com>
Date:   Mon Nov 2 17:23:58 2020 -0800

    x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S
    
    commit 4d6ffa27b8e5116c0abb318790fd01d4e12d75e6 upstream.
    
    Commit
    
      393f203f5fd5 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions")
    
    added .weak directives to arch/x86/lib/mem*_64.S instead of changing the
    existing ENTRY macros to WEAK. This can lead to the assembly snippet
    
      .weak memcpy
      ...
      .globl memcpy
    
    which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy
    with LLVM's integrated assembler before LLVM 12. LLVM 12 (since
    https://reviews.llvm.org/D90108) will error on such an overridden symbol
    binding.
    
    Commit
    
      ef1e03152cb0 ("x86/asm: Make some functions local")
    
    changed ENTRY in arch/x86/lib/memcpy_64.S to SYM_FUNC_START_LOCAL, which
    was ineffective due to the preceding .weak directive.
    
    Use the appropriate SYM_FUNC_START_WEAK instead.
    
    Fixes: 393f203f5fd5 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions")
    Fixes: ef1e03152cb0 ("x86/asm: Make some functions local")
    Reported-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Fangrui Song <maskray@google.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20201103012358.168682-1-maskray@google.com
    [nd: backport due to missing
      commit e9b9d020c487 ("x86/asm: Annotate aliases")
      commit ffedeeb780dc ("linkage: Introduce new macros for assembler symbols")]
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3a2613c419060543392e7a612330c77e5039169
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Mon Nov 9 10:35:28 2020 -0800

    Kbuild: do not emit debug info for assembly with LLVM_IAS=1
    
    commit b8a9092330da2030496ff357272f342eb970d51b upstream.
    
    Clang's integrated assembler produces the warning for assembly files:
    
    warning: DWARF2 only supports one section per compilation unit
    
    If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for
    assembly sources (it is still emitted for C sources).  This will be
    re-enabled for newer DWARF versions in a follow up patch.
    
    Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with
    LLVM=1 LLVM_IAS=1 for x86_64 and arm64.
    
    Cc: <stable@vger.kernel.org>
    Link: https://github.com/ClangBuiltLinux/linux/issues/716
    Reported-by: Dmitry Golovin <dima@golovin.in>
    Reported-by: Nathan Chancellor <natechancellor@gmail.com>
    Suggested-by: Dmitry Golovin <dima@golovin.in>
    Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
    Suggested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Reviewed-by: Fangrui Song <maskray@google.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    [nd: backport to avoid conflicts from:
      commit 10e68b02c861 ("Makefile: support compressed debug info")
      commit 7b16994437c7 ("Makefile: Improve compressed debug info support detection")
      commit 695afd3d7d58 ("kbuild: Simplify DEBUG_INFO Kconfig handling")]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>