commit b1313fe517ca3703119dcc99ef3bbf75ab42bcfb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 30 11:54:29 2020 +0100

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

commit 700d098acec5271161606f3c0086b71695ea2ef8
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date:   Mon Nov 9 21:06:56 2020 +0000

    x86/CPU/AMD: Save AMD NodeId as cpu_die_id
    
    [ Upstream commit 028c221ed1904af9ac3c5162ee98f48966de6b3d ]
    
    AMD systems provide a "NodeId" value that represents a global ID
    indicating to which "Node" a logical CPU belongs. The "Node" is a
    physical structure equivalent to a Die, and it should not be confused
    with logical structures like NUMA nodes. Logical nodes can be adjusted
    based on firmware or other settings whereas the physical nodes/dies are
    fixed based on hardware topology.
    
    The NodeId value can be used when a physical ID is needed by software.
    
    Save the AMD NodeId to struct cpuinfo_x86.cpu_die_id. Use the value
    from CPUID or MSR as appropriate. Default to phys_proc_id otherwise.
    Do so for both AMD and Hygon systems.
    
    Drop the node_id parameter from cacheinfo_*_init_llc_id() as it is no
    longer needed.
    
    Update the x86 topology documentation.
    
    Suggested-by: Borislav Petkov <bp@alien8.de>
    Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20201109210659.754018-2-Yazen.Ghannam@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb25fd492693a3a8654318f79c4c9e22f2d02aa1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Dec 17 09:27:57 2020 -0800

    drm/edid: fix objtool warning in drm_cvt_modes()
    
    commit d652d5f1eeeb06046009f4fcb9b4542249526916 upstream.
    
    Commit 991fcb77f490 ("drm/edid: Fix uninitialized variable in
    drm_cvt_modes()") just replaced one warning with another.
    
    The original warning about a possibly uninitialized variable was due to
    the compiler not being smart enough to see that the case statement
    actually enumerated all possible cases.  And the initial fix was just to
    add a "default" case that had a single "unreachable()", just to tell the
    compiler that that situation cannot happen.
    
    However, that doesn't actually fix the fundamental reason for the
    problem: the compiler still doesn't see that the existing case
    statements enumerate all possibilities, so the compiler will still
    generate code to jump to that unreachable case statement.  It just won't
    complain about an uninitialized variable any more.
    
    So now the compiler generates code to our inline asm marker that we told
    it would not fall through, and end end result is basically random.  We
    have created a bridge to nowhere.
    
    And then, depending on the random details of just exactly what the
    compiler ends up doing, 'objtool' might end up complaining about the
    conditional branches (for conditions that cannot happen, and that thus
    will never be taken - but if the compiler was not smart enough to figure
    that out, we can't expect objtool to do so) going off in the weeds.
    
    So depending on how the compiler has laid out the result, you might see
    something like this:
    
        drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to next function drm_mode_detailed.isra.0()
    
    and now you have a truly inscrutable warning that makes no sense at all
    unless you start looking at whatever random code the compiler happened
    to generate for our bare "unreachable()" statement.
    
    IOW, don't use "unreachable()" unless you have an _active_ operation
    that generates code that actually makes it obvious that something is not
    reachable (ie an UD instruction or similar).
    
    Solve the "compiler isn't smart enough" problem by just marking one of
    the cases as "default", so that even when the compiler doesn't otherwise
    see that we've enumerated all cases, the compiler will feel happy and
    safe about there always being a valid case that initializes the 'width'
    variable.
    
    This also generates better code, since now the compiler doesn't generate
    comparisons for five different possibilities (the four real ones and the
    one that can't happen), but just for the three real ones and "the rest"
    (which is that last one).
    
    A smart enough compiler that sees that we cover all the cases won't care.
    
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: Ilia Mirkin <imirkin@alum.mit.edu>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c13edadf1029a4c2f4c8440575bc1e4e483ac585
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Fri Nov 20 10:55:12 2020 +0900

    null_blk: Fail zone append to conventional zones
    
    commit 2e896d89510f23927ec393bee1e0570db3d5a6c6 upstream.
    
    Conventional zones do not have a write pointer and so cannot accept zone
    append writes. Make sure to fail any zone append write command issued to
    a conventional zone.
    
    Reported-by: Naohiro Aota <naohiro.aota@wdc.com>
    Fixes: e0489ed5daeb ("null_blk: Support REQ_OP_ZONE_APPEND")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92ee9b9fa8a463fc4053f3053efc49357023e133
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Fri Nov 20 10:55:11 2020 +0900

    null_blk: Fix zone size initialization
    
    commit 0ebcdd702f49aeb0ad2e2d894f8c124a0acc6e23 upstream.
    
    For a null_blk device with zoned mode enabled is currently initialized
    with a number of zones equal to the device capacity divided by the zone
    size, without considering if the device capacity is a multiple of the
    zone size. If the zone size is not a divisor of the capacity, the zones
    end up not covering the entire capacity, potentially resulting is out
    of bounds accesses to the zone array.
    
    Fix this by adding one last smaller zone with a size equal to the
    remainder of the disk capacity divided by the zone size if the capacity
    is not a multiple of the zone size. For such smaller last zone, the zone
    capacity is also checked so that it does not exceed the smaller zone
    size.
    
    Reported-by: Naohiro Aota <naohiro.aota@wdc.com>
    Fixes: ca4b2a011948 ("null_blk: add zone support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bbb32065694dc5e66a028f91d69a6bf592be430
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Mon Dec 14 12:33:51 2020 -0500

    Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"
    
    commit adab66b71abfe206a020f11e561f4df41f0b2aba upstream.
    
    It was believed that metag was the only architecture that required the ring
    buffer to keep 8 byte words aligned on 8 byte architectures, and with its
    removal, it was assumed that the ring buffer code did not need to handle
    this case. It appears that sparc64 also requires this.
    
    The following was reported on a sparc64 boot up:
    
       kernel: futex hash table entries: 65536 (order: 9, 4194304 bytes, linear)
       kernel: Running postponed tracer tests:
       kernel: Testing tracer function:
       kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140
       kernel: Kernel unaligned access at TPC[552a24] trace_function+0x44/0x140
       kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140
       kernel: Kernel unaligned access at TPC[552a24] trace_function+0x44/0x140
       kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140
       kernel: PASSED
    
    Need to put back the 64BIT aligned code for the ring buffer.
    
    Link: https://lore.kernel.org/r/CADxRZqzXQRYgKc=y-KV=S_yHL+Y8Ay2mh5ezeZUnpRvg+syWKw@mail.gmail.com
    
    Cc: stable@vger.kernel.org
    Fixes: 86b3de60a0b6 ("ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS")
    Reported-by: Anatoly Pugachev <matorola@gmail.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 783c5d48b22f5138368406a0b642b6fc2ea29512
Author: Nikita Shubin <nikita.shubin@maquefel.me>
Date:   Tue Dec 1 12:55:07 2020 +0300

    rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time
    
    commit 00c33482bb6110bce8110daa351f9b3baf4df7dc upstream.
    
    Mismatch in probe platform_set_drvdata set's and method's that call
    dev_get_platdata will result in "Unable to handle kernel NULL pointer
    dereference", let's use according method for getting driver data after
    platform_set_drvdata.
    
    8<--- cut here ---
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = (ptrval)
    [00000000] *pgd=00000000
    Internal error: Oops: 5 [#1] ARM
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.10-00003-g723e101e0037-dirty #4
    Hardware name: Technologic Systems TS-72xx SBC
    PC is at ep93xx_rtc_read_time+0xc/0x2c
    LR is at __rtc_read_time+0x4c/0x8c
    [...]
    [<c02b01c8>] (ep93xx_rtc_read_time) from [<c02ac38c>] (__rtc_read_time+0x4c/0x8c)
    [<c02ac38c>] (__rtc_read_time) from [<c02ac3f8>] (rtc_read_time+0x2c/0x4c)
    [<c02ac3f8>] (rtc_read_time) from [<c02acc54>] (__rtc_read_alarm+0x28/0x358)
    [<c02acc54>] (__rtc_read_alarm) from [<c02abd80>] (__rtc_register_device+0x124/0x2ec)
    [<c02abd80>] (__rtc_register_device) from [<c02b028c>] (ep93xx_rtc_probe+0xa4/0xac)
    [<c02b028c>] (ep93xx_rtc_probe) from [<c026424c>] (platform_drv_probe+0x24/0x5c)
    [<c026424c>] (platform_drv_probe) from [<c0262918>] (really_probe+0x218/0x374)
    [<c0262918>] (really_probe) from [<c0262da0>] (device_driver_attach+0x44/0x60)
    [<c0262da0>] (device_driver_attach) from [<c0262e70>] (__driver_attach+0xb4/0xc0)
    [<c0262e70>] (__driver_attach) from [<c0260d44>] (bus_for_each_dev+0x68/0xac)
    [<c0260d44>] (bus_for_each_dev) from [<c026223c>] (driver_attach+0x18/0x24)
    [<c026223c>] (driver_attach) from [<c0261dd8>] (bus_add_driver+0x150/0x1b4)
    [<c0261dd8>] (bus_add_driver) from [<c026342c>] (driver_register+0xb0/0xf4)
    [<c026342c>] (driver_register) from [<c0264210>] (__platform_driver_register+0x30/0x48)
    [<c0264210>] (__platform_driver_register) from [<c04cb9ac>] (ep93xx_rtc_driver_init+0x10/0x1c)
    [<c04cb9ac>] (ep93xx_rtc_driver_init) from [<c000973c>] (do_one_initcall+0x7c/0x1c0)
    [<c000973c>] (do_one_initcall) from [<c04b9ecc>] (kernel_init_freeable+0x168/0x1ac)
    [<c04b9ecc>] (kernel_init_freeable) from [<c03b2228>] (kernel_init+0x8/0xf4)
    [<c03b2228>] (kernel_init) from [<c00082c0>] (ret_from_fork+0x14/0x34)
    Exception stack(0xc441dfb0 to 0xc441dff8)
    dfa0:                                     00000000 00000000 00000000 00000000
    dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
    Code: e12fff1e e92d4010 e590303c e1a02001 (e5933000)
    ---[ end trace c914d6030eaa95c8 ]---
    
    Fixes: b809d192eb98 ("rtc: ep93xx: stop setting platform_data")
    Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201201095507.10317-1-nikita.shubin@maquefel.me
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b98ce1a17266bf33c261534f54e58d7e062d8469
Author: Zhuguangqing <zhuguangqing@xiaomi.com>
Date:   Fri Nov 6 17:22:43 2020 +0800

    thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
    
    commit 236761f19a4f373354f1dcf399b57753f1f4b871 upstream.
    
    If state has not changed successfully and we updated cpufreq_state,
    next time when the new state is equal to cpufreq_state (not changed
    successfully last time), we will return directly and miss a
    freq_qos_update_request() that should have been.
    
    Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits")
    Cc: v5.4+ <stable@vger.kernel.org> # v5.4+
    Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20201106092243.15574-1-zhuguangqing83@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 450fc74de129155efee7f8c77a83d2823fdecb0e
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Sat Nov 21 21:41:32 2020 -0800

    remoteproc: sysmon: Ensure remote notification ordering
    
    commit 138a6428ba9023ae29e103e87a223575fbc3d2b7 upstream.
    
    The reliance on the remoteproc's state for determining when to send
    sysmon notifications to a remote processor is racy with regard to
    concurrent remoteproc operations.
    
    Further more the advertisement of the state of other remote processor to
    a newly started remote processor might not only send the wrong state,
    but might result in a stream of state changes that are out of order.
    
    Address this by introducing state tracking within the sysmon instances
    themselves and extend the locking to ensure that the notifications are
    consistent with this state.
    
    Fixes: 1f36ab3f6e3b ("remoteproc: sysmon: Inform current rproc about all active rprocs")
    Fixes: 1877f54f75ad ("remoteproc: sysmon: Add notifications for events")
    Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
    Cc: stable@vger.kernel.org
    Reviewed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
    Link: https://lore.kernel.org/r/20201122054135.802935-2-bjorn.andersson@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f4b60a70c56e734c30a286765fe084fdeedfe63
Author: DingHua Ma <dinghua.ma.sz@gmail.com>
Date:   Tue Dec 1 08:10:00 2020 +0800

    regulator: axp20x: Fix DLDO2 voltage control register mask for AXP22x
    
    commit 291de1d102fafef0798cdad9666cd4f8da7da7cc upstream.
    
    When I use the axp20x chip to power my SDIO device on the 5.4 kernel,
    the output voltage of DLDO2 is wrong. After comparing the register
    manual and source code of the chip, I found that the mask bit of the
    driver register of the port was wrong. I fixed this error by modifying
    the mask register of the source code. This error seems to be a copy
    error of the macro when writing the code. Now the voltage output of
    the DLDO2 port of axp20x is correct. My development environment is
    Allwinner A40I of arm architecture, and the kernel version is 5.4.
    
    Signed-off-by: DingHua Ma <dinghua.ma.sz@gmail.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Cc: <stable@vger.kernel.org>
    Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
    Link: https://lore.kernel.org/r/20201201001000.22302-1-dinghua.ma.sz@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39a6f4bef6a51cdadbbaa715fdb5f9ae6209a0ec
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 94bc6f5e2c14309e536f61e815521975eb0c62d0
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Nov 23 11:23:12 2020 +0100

    of: fix linker-section match-table corruption
    
    commit 5812b32e01c6d86ba7a84110702b46d8a8531fe9 upstream.
    
    Specify type alignment when declaring linker-section match-table entries
    to prevent gcc from increasing alignment and corrupting the various
    tables with padding (e.g. timers, irqchips, clocks, reserved memory).
    
    This is specifically needed on x86 where gcc (typically) aligns larger
    objects like struct of_device_id with static extent on 32-byte
    boundaries which at best prevents matching on anything but the first
    entry. Specifying alignment when declaring variables suppresses this
    optimisation.
    
    Here's a 64-bit example where all entries are corrupt as 16 bytes of
    padding has been inserted before the first entry:
    
            ffffffff8266b4b0 D __clk_of_table
            ffffffff8266b4c0 d __of_table_fixed_factor_clk
            ffffffff8266b5a0 d __of_table_fixed_clk
            ffffffff8266b680 d __clk_of_table_sentinel
    
    And here's a 32-bit example where the 8-byte-aligned table happens to be
    placed on a 32-byte boundary so that all but the first entry are corrupt
    due to the 28 bytes of padding inserted between entries:
    
            812b3ec0 D __irqchip_of_table
            812b3ec0 d __of_table_irqchip1
            812b3fa0 d __of_table_irqchip2
            812b4080 d __of_table_irqchip3
            812b4160 d irqchip_of_match_end
    
    Verified on x86 using gcc-9.3 and gcc-4.9 (which uses 64-byte
    alignment), and on arm using gcc-7.2.
    
    Note that there are no in-tree users of these tables on x86 currently
    (even if they are included in the image).
    
    Fixes: 54196ccbe0ba ("of: consolidate linker section OF match table declarations")
    Fixes: f6e916b82022 ("irqchip: add basic infrastructure")
    Cc: stable <stable@vger.kernel.org>     # 3.9
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20201123102319.8090-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 680e7b2a0e0980e7aa988e04133a1883d2030c7c
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Oct 10 15:20:18 2020 +0200

    mt76: add back the SUPPORTS_REORDERING_BUFFER flag
    
    commit ed89b89330b521f20682ead6bf93e1014b21a200 upstream.
    
    It was accidentally dropped while adding multiple wiphy support
    Fixes fast-rx support and avoids handling reordering in both mac80211
    and the driver
    
    Cc: stable@vger.kernel.org
    Fixes: c89d36254155 ("mt76: add function for allocating an extra wiphy")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2d7cffc20f6d81e572868cc676defe5228abae8
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Tue Dec 8 17:54:09 2020 +0900

    tracing: Disable ftrace selftests when any tracer is running
    
    commit 60efe21e5976d3d4170a8190ca76a271d6419754 upstream.
    
    Disable ftrace selftests when any tracer (kernel command line options
    like ftrace=, trace_events=, kprobe_events=, and boot-time tracing)
    starts running because selftest can disturb it.
    
    Currently ftrace= and trace_events= are checked, but kprobe_events
    has a different flag, and boot-time tracing didn't checked. This unifies
    the disabled flag and all of those boot-time tracing features sets
    the flag.
    
    This also fixes warnings on kprobe-event selftest
    (CONFIG_FTRACE_STARTUP_TEST=y and CONFIG_KPROBE_EVENTS=y) with boot-time
    tracing (ftrace.event.kprobes.EVENT.probes) like below;
    
    [   59.803496] trace_kprobe: Testing kprobe tracing:
    [   59.804258] ------------[ cut here ]------------
    [   59.805682] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:1987 kprobe_trace_self_tests_ib
    [   59.806944] Modules linked in:
    [   59.807335] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.10.0-rc7+ #172
    [   59.808029] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/204
    [   59.808999] RIP: 0010:kprobe_trace_self_tests_init+0x5f/0x42b
    [   59.809696] Code: e8 03 00 00 48 c7 c7 30 8e 07 82 e8 6d 3c 46 ff 48 c7 c6 00 b2 1a 81 48 c7 c7 7
    [   59.812439] RSP: 0018:ffffc90000013e78 EFLAGS: 00010282
    [   59.813038] RAX: 00000000ffffffef RBX: 0000000000000000 RCX: 0000000000049443
    [   59.813780] RDX: 0000000000049403 RSI: 0000000000049403 RDI: 000000000002deb0
    [   59.814589] RBP: ffffc90000013e90 R08: 0000000000000001 R09: 0000000000000001
    [   59.815349] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000ffffffef
    [   59.816138] R13: ffff888004613d80 R14: ffffffff82696940 R15: ffff888004429138
    [   59.816877] FS:  0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000
    [   59.817772] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   59.818395] CR2: 0000000001a8dd38 CR3: 0000000002222000 CR4: 00000000000006a0
    [   59.819144] Call Trace:
    [   59.819469]  ? init_kprobe_trace+0x6b/0x6b
    [   59.819948]  do_one_initcall+0x5f/0x300
    [   59.820392]  ? rcu_read_lock_sched_held+0x4f/0x80
    [   59.820916]  kernel_init_freeable+0x22a/0x271
    [   59.821416]  ? rest_init+0x241/0x241
    [   59.821841]  kernel_init+0xe/0x10f
    [   59.822251]  ret_from_fork+0x22/0x30
    [   59.822683] irq event stamp: 16403349
    [   59.823121] hardirqs last  enabled at (16403359): [<ffffffff810db81e>] console_unlock+0x48e/0x580
    [   59.824074] hardirqs last disabled at (16403368): [<ffffffff810db786>] console_unlock+0x3f6/0x580
    [   59.825036] softirqs last  enabled at (16403200): [<ffffffff81c0033a>] __do_softirq+0x33a/0x484
    [   59.825982] softirqs last disabled at (16403087): [<ffffffff81a00f02>] asm_call_irq_on_stack+0x10
    [   59.827034] ---[ end trace 200c544775cdfeb3 ]---
    [   59.827635] trace_kprobe: error on probing function entry.
    
    Link: https://lkml.kernel.org/r/160741764955.3448999.3347769358299456915.stgit@devnote2
    
    Fixes: 4d655281eb1b ("tracing/boot Add kprobe event support")
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 054c923fd376b5d23db4621a7aea35d2f0e990a6
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 16ecf8cecdd128f68bfcf9d248075f0d5e008b28
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 ea43135a3cb28b770c7f588d5090e89b5faa7870
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Thu Nov 26 19:11:43 2020 +0000

    memory: renesas-rpc-if: Fix unbalanced pm_runtime_enable in rpcif_{enable,disable}_rpm
    
    commit 61a6d854b9555b420fbfae62ef26baa8b9493b32 upstream.
    
    rpcif_enable_rpm calls pm_runtime_enable, so rpcif_disable_rpm needs to
    call pm_runtime_disable and not pm_runtime_put_sync.
    
    Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
    Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201126191146.8753-3-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f826e66b067ebd9413e117dd7710a4106732793
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Thu Nov 26 19:11:42 2020 +0000

    memory: renesas-rpc-if: Return correct value to the caller of rpcif_manual_xfer()
    
    commit a0453f4ed066cae651b3119ed11f52d31dae1eca upstream.
    
    In the error path of rpcif_manual_xfer() the value of ret is overwritten
    by value returned by reset_control_reset() function and thus returning
    incorrect value to the caller.
    
    This patch makes sure the correct value is returned to the caller of
    rpcif_manual_xfer() by dropping the overwrite of ret in error path.
    Also now we ignore the value returned by reset_control_reset() in the
    error path and instead print a error message when it fails.
    
    Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
    Reported-by: Pavel Machek <pavel@denx.de>
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Pavel Machek (CIP) <pavel@denx.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201126191146.8753-2-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7397049404250aed6773af293a8eadd97f969820
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Thu Nov 26 19:11:44 2020 +0000

    memory: renesas-rpc-if: Fix a node reference leak in rpcif_probe()
    
    commit 4e6b86b409f9fc63fedb39d6e3a0202c4b0244ce upstream.
    
    Release the node reference by calling of_node_put(flash) in the probe.
    
    Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
    Reported-by: Pavel Machek <pavel@denx.de>
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Pavel Machek (CIP) <pavel@denx.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201126191146.8753-4-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6fc90d170df77583edc90d132a796d3abda1fba
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Aug 3 17:36:07 2020 +0300

    memory: jz4780_nemc: Fix an error pointer vs NULL check in probe()
    
    commit 96999c797ec1ef41259f00b4ddf9cf33b342cb78 upstream.
    
    The devm_ioremap() function returns NULL on error, it doesn't return
    error pointers.  This bug could lead to an Oops during probe.
    
    Fixes: f046e4a3f0b9 ("memory: jz4780_nemc: Only request IO memory the driver will use")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Paul Cercueil <paul@crapouillou.net>
    Link: https://lore.kernel.org/r/20200803143607.GC346925@mwanda
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c88347ae936482f079cc17eac405f3f54e839a8d
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 1a72241aabcbb19b52be6f009423e5782b87a09e
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 6835334e154652858651ac6336e71290e0cc1396
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 9ae6d2f4ca8aa871cbb9c2ab78e1848177c5641c
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 b4898bdd2020bae5391b1667fc6c9e27310c59fe
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 aadd67750f43132177138fcd56ebc60aeb06228a
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 c26062328e727bef49317270176f122d21c78de9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Dec 8 20:03:26 2020 +0100

    driver: core: Fix list corruption after device_del()
    
    commit 66482f640755b31cb94371ff6cef17400cda6db5 upstream.
    
    The device_links_purge() function (called from device_del()) tries to
    remove the links.needs_suppliers list entry, but it's using
    list_del(), hence it doesn't initialize after the removal.  This is OK
    for normal cases where device_del() is called via device_destroy().
    However, it's not guaranteed that the device object will be really
    deleted soon after device_del().  In a minor case like HD-audio codec
    reconfiguration that re-initializes the device after device_del(), it
    may lead to a crash by the corrupted list entry.
    
    As a simple fix, replace list_del() with list_del_init() in order to
    make the list intact after the device_del() call.
    
    Fixes: e2ae9bcc4aaa ("driver core: Add support for linking devices during device addition")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20201208190326.27531-1-tiwai@suse.de
    Cc: Saravana Kannan <saravanak@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c500d6a5c7a1e363652781e4dd03b7ec37f3c04
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Tue Nov 24 12:57:07 2020 +0100

    dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.
    
    commit bf8975837dac156c33a4d15d46602700998cb6dd upstream.
    
    We hardcode the maximum number of shared fences to 4, instead of
    respecting num_fences. Use a minimum of 4, but more if num_fences
    is higher.
    
    This seems to have been an oversight when first implementing the
    api.
    
    Fixes: 04a5faa8cbe5 ("reservation: update api and add some helpers")
    Cc: <stable@vger.kernel.org> # v3.17+
    Reported-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201124115707.406917-1-maarten.lankhorst@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 224adad2c975ec706ba3c451ce8e10f1d3d9806d
Author: Wang Hai <wanghai38@huawei.com>
Date:   Tue Dec 1 21:59:29 2020 +0800

    device-dax/core: Fix memory leak when rmmod dax.ko
    
    commit 1aa574312518ef1d60d2dc62d58f7021db3b163a upstream.
    
    When I repeatedly modprobe and rmmod dax.ko, kmemleak report a
    memory leak as follows:
    
    unreferenced object 0xffff9a5588c05088 (size 8):
      comm "modprobe", pid 261, jiffies 4294693644 (age 42.063s)
    ...
      backtrace:
        [<00000000e007ced0>] kstrdup+0x35/0x70
        [<000000002ae73897>] kstrdup_const+0x3d/0x50
        [<000000002b00c9c3>] kvasprintf_const+0xbc/0xf0
        [<000000008023282f>] kobject_set_name_vargs+0x3b/0xd0
        [<00000000d2cbaa4e>] kobject_set_name+0x62/0x90
        [<00000000202e7a22>] bus_register+0x7f/0x2b0
        [<000000000b77792c>] 0xffffffffc02840f7
        [<000000002d5be5ac>] 0xffffffffc02840b4
        [<00000000dcafb7cd>] do_one_initcall+0x58/0x240
        [<00000000049fe480>] do_init_module+0x56/0x1e2
        [<0000000022671491>] load_module+0x2517/0x2840
        [<000000001a2201cb>] __do_sys_finit_module+0x9c/0xe0
        [<000000003eb304e7>] do_syscall_64+0x33/0x40
        [<0000000051c5fd06>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    When rmmod dax is executed, dax_bus_exit() is missing. This patch
    can fix this bug.
    
    Fixes: 9567da0b408a ("device-dax: Introduce bus + driver model")
    Cc: <stable@vger.kernel.org>
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Link: https://lore.kernel.org/r/20201201135929.66530-1-wanghai38@huawei.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e75951e9b43f6049aa650e4a8b572aac4968d60
Author: William Breathitt Gray <vilhelm.gray@gmail.com>
Date:   Sat Nov 14 18:28:05 2020 -0500

    counter: microchip-tcb-capture: Fix CMR value check
    
    commit 3418bd7cfce0bd8ef1ccedc4655f9f86f6c3b0ca upstream.
    
    The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values
    for CMR. This patch fixes the action_get() callback to properly check
    for these values rather than mask them.
    
    Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
    Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
    Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201114232805.253108-1-vilhelm.gray@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b11905a3b977c39cb392d88decad4ecca5330859
Author: Nicolin Chen <nicoleotsuka@gmail.com>
Date:   Wed Oct 28 17:48:20 2020 -0700

    clk: tegra: Do not return 0 on failure
    
    commit 6160aca443148416994c022a35c77daeba948ea6 upstream.
    
    Return values from read_dt_param() will be either TRUE (1) or
    FALSE (0), while dfll_fetch_pwm_params() returns 0 on success
    or an ERR code on failure.
    
    So this patch fixes the bug of returning 0 on failure.
    
    Fixes: 36541f0499fe ("clk: tegra: dfll: support PWM regulator control")
    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 db003855f7d1afd7baeb25d8244e9c0ee8e4e276
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 070e386727fd5960fec99d845e1a915576495d43
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Sat Dec 12 13:57:33 2020 +0000

    clk: ingenic: Fix divider calculation with div tables
    
    commit 11a163f2c7d6a9f27ce144cd7e367a81c851621a upstream.
    
    The previous code assumed that a higher hardware value always resulted
    in a bigger divider, which is correct for the regular clocks, but is
    an invalid assumption when a divider table is provided for the clock.
    
    Perfect example of this is the PLL0_HALF clock, which applies a /2
    divider with the hardware value 0, and a /1 divider otherwise.
    
    Fixes: a9fa2893fcc6 ("clk: ingenic: Add support for divider tables")
    Cc: <stable@vger.kernel.org> # 5.2
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Link: https://lore.kernel.org/r/20201212135733.38050-1-paul@crapouillou.net
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcea0b3835dff7df8eca6c3358010c620a328d4d
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 d27d1942e173c1c719e00a596f5db60221b05b14
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 3ace8d52ee4afac46e4d718612efa09591bd7506
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 c1f4549a7399bd6469c299449854d26b21b1a68c
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Sep 20 12:27:42 2020 +0100

    iio:adc:ti-ads124s08: Fix alignment and data leak issues.
    
    commit 1e405bc2512f80a903ddd6ba8740cee885238d7f 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() data with alignment
    explicitly requested.  This data is allocated with kzalloc() so no
    data can leak apart from previous readings.
    
    In this driver the timestamp can end up in various different locations
    depending on what other channels are enabled.  As a result, we don't
    use a structure to specify it's position as that would be misleading.
    
    Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
    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>
    Cc: Dan Murphy <dmurphy@ti.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    iio:adc:ti-ads124s08: Fix buffer being too long.
    
    commit b0bd27f02d768e3a861c4e6c27f8e369720e6c25 upstream.
    
    The buffer is expressed as a u32 array, yet the extra space for
    the s64 timestamp was expressed as sizeof(s64)/sizeof(u16).
    This will result in 2 extra u32 elements.
    Fix by dividing by sizeof(u32).
    
    Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
    Signed-off-by: Jonathan Cameron<Jonathan.Cameron@huawei.com>
    Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: Dan Murphy <dmurphy@ti.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-8-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    iio:imu:bmi160: Fix alignment and data leak issues
    
    commit 7b6b51234df6cd8b04fe736b0b89c25612d896b8 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 array in the iio_priv() data with alignment
    explicitly requested.  This data is allocated with kzalloc() so no
    data can leak apart from previous readings.
    
    In this driver, depending on which channels are enabled, the timestamp
    can be in a number of locations.  Hence we cannot use a structure
    to specify the data layout without it being misleading.
    
    Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160")
    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>
    Cc: Daniel Baluta  <daniel.baluta@gmail.com>
    Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f57464c4037b929bbb06caa4fa1e409d0e26b886
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 5550e16128ed666413f7250c8b679532f7ae8ec0
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 c02f8e0ef056652654f304d83c4274aed166a8e9
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Sep 20 12:27:37 2020 +0100

    iio:magnetometer:mag3110: Fix alignment and data leak issues.
    
    commit 89deb1334252ea4a8491d47654811e28b0790364 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() data.
    This data is allocated with kzalloc() so no data can leak apart from
    previous readings.
    
    The explicit alignment of ts is not necessary in this case but
    does make the code slightly less fragile so I have included it.
    
    Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver")
    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>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2409bfd6e34480de1108d978b91f4470f4fcd5c5
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 45ebad3dc0573555b730e4965c7b869184a60c8c
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 6e94b8314c1f9d719e1ac87391b934eb7ea1af42
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Sat Nov 14 19:39:05 2020 +0100

    iio: imu: st_lsm6dsx: fix edge-trigger interrupts
    
    commit 3f9bce7a22a3f8ac9d885c9d75bc45569f24ac8b upstream.
    
    If we are using edge IRQs, new samples can arrive while processing
    current interrupt since there are no hw guarantees the irq line
    stays "low" long enough to properly detect the new interrupt.
    In this case the new sample will be missed.
    Polling FIFO status register in st_lsm6dsx_handler_thread routine
    allow us to read new samples even if the interrupt arrives while
    processing previous data and the timeslot where the line is "low"
    is too short to be properly detected.
    
    Fixes: 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts")
    Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 160ec8afa7cfd24478b60a72f9aea964b6028f60
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 2adb3f8bcc29a0b3c885fdb7e90ccd3228e1b23e
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 aa606ebab122a108c2af4304a6036fc5c87ee85e
Author: Aleksa Sarai <cyphar@cyphar.com>
Date:   Wed Oct 28 10:50:43 2020 +1100

    openat2: reject RESOLVE_BENEATH|RESOLVE_IN_ROOT
    
    commit 398840f8bb935d33c64df4ec4fed77a7d24c267d upstream.
    
    This was an oversight in the original implementation, as it makes no
    sense to specify both scoping flags to the same openat2(2) invocation
    (before this patch, the result of such an invocation was equivalent to
    RESOLVE_IN_ROOT being ignored).
    
    This is a userspace-visible ABI change, but the only user of openat2(2)
    at the moment is LXC which doesn't specify both flags and so no
    userspace programs will break as a result.
    
    Fixes: fddb5d430ad9 ("open: introduce openat2(2) syscall")
    Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: <stable@vger.kernel.org> # v5.6+
    Link: https://lore.kernel.org/r/20201027235044.5240-2-cyphar@cyphar.com
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da65881cecf536b9c4235ca70f044f94ab66e782
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 d234a0e76c748c6f12175cd5ce8b44a66f8911d9
Author: James Smart <james.smart@broadcom.com>
Date:   Tue Oct 20 13:27:12 2020 -0700

    scsi: lpfc: Fix scheduling call while in softirq context in lpfc_unreg_rpi
    
    commit e7dab164a9aa457f89d4528452bdfc3e15ac98b6 upstream.
    
    The following call trace was seen during HBA reset testing:
    
    BUG: scheduling while atomic: swapper/2/0/0x10000100
    ...
    Call Trace:
    dump_stack+0x19/0x1b
    __schedule_bug+0x64/0x72
    __schedule+0x782/0x840
    __cond_resched+0x26/0x30
    _cond_resched+0x3a/0x50
    mempool_alloc+0xa0/0x170
    lpfc_unreg_rpi+0x151/0x630 [lpfc]
    lpfc_sli_abts_recover_port+0x171/0x190 [lpfc]
    lpfc_sli4_abts_err_handler+0xb2/0x1f0 [lpfc]
    lpfc_sli4_io_xri_aborted+0x256/0x300 [lpfc]
    lpfc_sli4_sp_handle_abort_xri_wcqe.isra.51+0xa3/0x190 [lpfc]
    lpfc_sli4_fp_handle_cqe+0x89/0x4d0 [lpfc]
    __lpfc_sli4_process_cq+0xdb/0x2e0 [lpfc]
    __lpfc_sli4_hba_process_cq+0x41/0x100 [lpfc]
    lpfc_cq_poll_hdler+0x1a/0x30 [lpfc]
    irq_poll_softirq+0xc7/0x100
    __do_softirq+0xf5/0x280
    call_softirq+0x1c/0x30
    do_softirq+0x65/0xa0
    irq_exit+0x105/0x110
    do_IRQ+0x56/0xf0
    common_interrupt+0x16a/0x16a
    
    With the conversion to blk_io_poll for better interrupt latency in normal
    cases, it introduced this code path, executed when I/O aborts or logouts
    are seen, which attempts to allocate memory for a mailbox command to be
    issued.  The allocation is GFP_KERNEL, thus it could attempt to sleep.
    
    Fix by creating a work element that performs the event handling for the
    remote port. This will have the mailbox commands and other items performed
    in the work element, not the irq. A much better method as the "irq" routine
    does not stall while performing all this deep handling code.
    
    Ensure that allocation failures are handled and send LOGO on failure.
    
    Additionally, enlarge the mailbox memory pool to reduce the possibility of
    additional allocation in this path.
    
    Link: https://lore.kernel.org/r/20201020202719.54726-3-james.smart@broadcom.com
    Fixes: 317aeb83c92b ("scsi: lpfc: Add blk_io_poll support for latency improvment")
    Cc: <stable@vger.kernel.org> # v5.9+
    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 0af3d9342c321ee280226afa03a567d3a00f240c
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 6a6754485b0ce198bb1c46a23479ec66d5341e0b
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Dec 2 05:23:04 2020 -0800

    scsi: qla2xxx: Fix crash during driver load on big endian machines
    
    commit 8de309e7299a00b3045fb274f82b326f356404f0 upstream.
    
    Crash stack:
            [576544.715489] Unable to handle kernel paging request for data at address 0xd00000000f970000
            [576544.715497] Faulting instruction address: 0xd00000000f880f64
            [576544.715503] Oops: Kernel access of bad area, sig: 11 [#1]
            [576544.715506] SMP NR_CPUS=2048 NUMA pSeries
            :
            [576544.715703] NIP [d00000000f880f64] .qla27xx_fwdt_template_valid+0x94/0x100 [qla2xxx]
            [576544.715722] LR [d00000000f7952dc] .qla24xx_load_risc_flash+0x2fc/0x590 [qla2xxx]
            [576544.715726] Call Trace:
            [576544.715731] [c0000004d0ffb000] [c0000006fe02c350] 0xc0000006fe02c350 (unreliable)
            [576544.715750] [c0000004d0ffb080] [d00000000f7952dc] .qla24xx_load_risc_flash+0x2fc/0x590 [qla2xxx]
            [576544.715770] [c0000004d0ffb170] [d00000000f7aa034] .qla81xx_load_risc+0x84/0x1a0 [qla2xxx]
            [576544.715789] [c0000004d0ffb210] [d00000000f79f7c8] .qla2x00_setup_chip+0xc8/0x910 [qla2xxx]
            [576544.715808] [c0000004d0ffb300] [d00000000f7a631c] .qla2x00_initialize_adapter+0x4dc/0xb00 [qla2xxx]
            [576544.715826] [c0000004d0ffb3e0] [d00000000f78ce28] .qla2x00_probe_one+0xf08/0x2200 [qla2xxx]
    
    Link: https://lore.kernel.org/r/20201202132312.19966-8-njavali@marvell.com
    Fixes: f73cb695d3ec ("[SCSI] qla2xxx: Add support for ISP2071.")
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e7312ba3e314adc4c76b6cdf6239b9c8cb68d0d
Author: Sergei Antonov <saproj@gmail.com>
Date:   Wed Oct 28 12:49:40 2020 +0300

    mtd: rawnand: meson: fix meson_nfc_dma_buffer_release() arguments
    
    commit c13d845e9a69580424d40b7b101c37d4f71bcd63 upstream.
    
    Arguments 'infolen' and 'datalen' to meson_nfc_dma_buffer_release() were mixed up.
    
    Fixes: 8fae856c53500 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sergei Antonov <saproj@gmail.com>
    Acked-by: Liang Yang <liang.yang@amlogic.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20201028094940.11765-1-saproj@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 392a56b9f2c52d21d8fca76f28fb6f2a0fb86604
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 d5e3fc275ea1f0f67f3b713cc866eb3248ae4080
Author: Richard Weinberger <richard@nod.at>
Date:   Sun Dec 6 21:22:20 2020 +0100

    mtd: core: Fix refcounting for unpartitioned MTDs
    
    commit 1ca71415f075353974524e96ed175306d8a937a8 upstream.
    
    Apply changes to usecount also to the master partition.
    Otherwise we have no refcounting at all if an MTD has no partitions.
    
    Cc: stable@vger.kernel.org
    Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20201206202220.27290-1-richard@nod.at
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e43463d5a97b036579158bfcbacd7ba058c9d3b
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 baad618d078c857f99cc286ea249e9629159901f
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 3bcf02208e9e5687389efa6773cdbc5d5afa3835
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 785eee857dba720ead998fa663f063384dc6401c
Author: Tudor Ambarus <tudor.ambarus@microchip.com>
Date:   Mon Dec 7 15:59:56 2020 +0200

    spi: atmel-quadspi: Fix AHB memory accesses
    
    commit cac8c821059639b015586abf61623c62cc549a13 upstream.
    
    Following error was seen when mounting a 16MByte ubifs:
    UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type
    
    QSPI_IFR.TFRTYP was not set correctly. When data transfer is enabled
    and one wants to access the serial memory through AHB in order to:
     - read in the serial memory, but not a memory data, for example
       a JEDEC-ID, QSPI_IFR.TFRTYP must be written to '0' (both sama5d2
       and sam9x60).
     - read in the serial memory, and particularly a memory data,
       TFRTYP must be written to '1' (both sama5d2 and sam9x60).
     - write in the serial memory, but not a memory data, for example
       writing the configuration or the QSPI_SR, TFRTYP must be written
       to '2' for sama5d2 and to '0' for sam9x60.
     - write in the serial memory in particular to program a memory data,
       TFRTYP must be written to '3' for sama5d2 and to '1' for sam9x60.
    
    Fix the setting of the QSPI_IFR.TFRTYP field.
    
    Fixes: 2d30ac5ed633 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver")
    Cc: <stable@vger.kernel.org> # v5.0+
    Reported-by: Tom Burkart <tom@aussec.com>
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20201207135959.154124-2-tudor.ambarus@microchip.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: atmel-quadspi: Disable clock in probe error path
    
    commit 0e685017c7ba1a2fe9f6f1e7a9302890747d934c upstream.
    
    If the call to of_device_get_match_data() fails on probe of the Atmel
    QuadSPI driver, the clock "aq->pclk" is erroneously not unprepared and
    disabled.  Fix it.
    
    Fixes: 2e5c88887358 ("spi: atmel-quadspi: add support for sam9x60 qspi controller")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.1+
    Cc: Tudor Ambarus <tudor.ambarus@microchip.com>
    Cc: Boris Brezillon <boris.brezillon@collabora.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/8f8dc2815aa97b2378528f08f923bf81e19611f0.1604874488.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: mt7621: Don't leak SPI master in probe error path
    
    commit 46b5c4fb87ce8211e0f9b0383dbde72c3652d2ba upstream.
    
    If the calls to device_reset() or devm_spi_register_controller() fail on
    probe of the MediaTek MT7621 SPI driver, the spi_controller struct is
    erroneously not freed.  Fix by switching over to the new
    devm_spi_alloc_master() helper.
    
    Additionally, there's an ordering issue in mt7621_spi_remove() wherein
    the spi_controller is unregistered after disabling the SYS clock.
    The correct order is to call spi_unregister_controller() *before* this
    teardown step because bus accesses may still be ongoing until that
    function returns.
    
    All of these bugs have existed since the driver was first introduced,
    so it seems fair to fix them together in a single commit.
    
    Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Stefan Roese <sr@denx.de>
    Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v4.17+
    Link: https://lore.kernel.org/r/72b680796149f5fcda0b3f530ffb7ee73b04f224.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: mt7621: Disable clock in probe error path
    
    commit 24f7033405abe195224ec793dbc3d7a27dec0b98 upstream.
    
    Commit 702b15cb9712 ("spi: mt7621: fix missing clk_disable_unprepare()
    on error in mt7621_spi_probe") sought to disable the SYS clock on probe
    errors, but only did so for 2 of 3 potentially failing calls:  The clock
    needs to be disabled on failure of devm_spi_register_controller() as
    well.
    
    Moreover, the commit purports to fix a bug in commit cbd66c626e16 ("spi:
    mt7621: Move SPI driver out of staging") but in reality the bug has
    existed since the driver was first introduced.
    
    Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.17+: 702b15cb9712: spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe
    Cc: <stable@vger.kernel.org> # v4.17+
    Cc: Qinglang Miao <miaoqinglang@huawei.com>
    Link: https://lore.kernel.org/r/36ad42760087952fb7c10aae7d2628547c26a7ec.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: synquacer: Disable clock in probe error path
    
    commit 8853b2503014aca5c793d2c7f0aabc990b32bdad upstream.
    
    If the calls to platform_get_irq() or devm_request_irq() fail on probe
    of the SynQuacer SPI driver, the clock "sspi->clk" is erroneously not
    unprepared and disabled.
    
    If the clock rate "master->max_speed_hz" cannot be determined, the same
    happens and in addition the spi_master struct is not freed.
    
    Fix it.
    
    Fixes: b0823ee35cf9 ("spi: Add spi driver for Socionext SynQuacer platform")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.3+
    Cc: Masahisa Kojima <masahisa.kojima@linaro.org>
    Link: https://lore.kernel.org/r/232281df1ab91d8f0f553a62d5f97fc264ace4da.1604874488.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e932dce770ec5f04d087d5300774cbcbf979c50a
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 186147729d83dabeb026cb55b7a460fdc8738b84
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:03 2020 +0100

    spi: spi-qcom-qspi: Fix use-after-free on unbind
    
    commit 6cfd39e212dee2e77a0227ce4e0f55fa06d79f46 upstream.
    
    qcom_qspi_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: f79a158d37c2 ("spi: spi-qcom-qspi: Use OPP API to set clk/perf state")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v5.9+
    Cc: Rajendra Nayak <rnayak@codeaurora.org>
    Link: https://lore.kernel.org/r/b6d3c4dce571d78a532fd74f27def0d5dc8d8a24.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: spi-geni-qcom: Fix use-after-free on unbind
    
    commit 8f96c434dfbc85ffa755d6634c8c1cb2233fcf24 upstream.
    
    spi_geni_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.
    
    Moreover, since commit 1a9e489e6128 ("spi: spi-geni-qcom: Use OPP API to
    set clk/perf state"), spi_geni_probe() leaks the spi_master allocation
    if the calls to dev_pm_opp_set_clkname() or dev_pm_opp_of_add_table()
    fail.
    
    Fix by switching over to the new devm_spi_alloc_master() helper which
    keeps the private data accessible until the driver has unbound and also
    avoids the spi_master leak on probe.
    
    Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.20+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v4.20+
    Cc: Rajendra Nayak <rnayak@codeaurora.org>
    Cc: Girish Mahadevan <girishm@codeaurora.org>
    Link: https://lore.kernel.org/r/dfa1d8c41b8acdfad87ec8654cd124e6e3cb3f31.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4fd01eef86def0d1ac0cc4fb9067454def7175b
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 11b81d94f8df34e8bff60e51d1162d7f11ae49d6
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:06 2020 +0100

    spi: rpc-if: Fix use-after-free on unbind
    
    commit 393f981ca5f797b58b882d42b7621fb6e43c7f5b upstream.
    
    rpcif_spi_remove() accesses the driver's private data after calling
    spi_unregister_controller() even though that function releases the last
    reference on the spi_controller 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: eb8d6d464a27 ("spi: add Renesas RPC-IF driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v5.9+
    Cc: Sergei Shtylyov <s.shtylyov@omprussia.ru>
    Link: https://lore.kernel.org/r/c5da472c28021da2f6517441685cef033d40b140.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3e86ed72890ce4c846f5d5782a13962a4059403
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 cc5a0cb114501f6be33e879afc75f7032572a196
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 a73ee1d8faff1538b23336b391983d53fbe245c5
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:16 2020 +0100

    spi: npcm-fiu: Disable clock in probe error path
    
    commit 234266a5168bbe8220d263e3aa7aa80cf921c483 upstream.
    
    If the call to devm_spi_register_master() fails on probe of the NPCM FIU
    SPI driver, the clock "fiu->clk" is erroneously not unprepared and
    disabled.  Fix it.
    
    Fixes: ace55c411b11 ("spi: npcm-fiu: add NPCM FIU controller driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.4+
    Cc: Tomer Maimon <tmaimon77@gmail.com>
    Link: https://lore.kernel.org/r/9ae62f4e1cfe542bec57ac2743e6fca9f9548f55.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: mxic: Don't leak SPI master in probe error path
    
    commit cc53711b2191cf3b3210283ae89bf0abb98c70a3 upstream.
    
    If the calls to devm_clk_get() or devm_ioremap_resource() fail on probe
    of the Macronix SPI driver, the spi_master struct is erroneously not freed.
    
    Fix by switching over to the new devm_spi_alloc_master() helper.
    
    Fixes: b942d80b0a39 ("spi: Add MXIC controller driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.0+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v5.0+
    Cc: Mason Yang <masonccyang@mxic.com.tw>
    Link: https://lore.kernel.org/r/4fa6857806e7e75741c05d057ac9df3564460114.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: gpio: Don't leak SPI master in probe error path
    
    commit 7174dc655ef0578877b0b4598e69619d2be28b4d upstream.
    
    If the call to devm_spi_register_master() fails on probe of the GPIO SPI
    driver, the spi_master struct is erroneously not freed:
    
    After allocating the spi_master, its reference count is 1.  The driver
    unconditionally decrements the reference count on unbind using a devm
    action.  Before calling devm_spi_register_master(), the driver
    unconditionally increments the reference count because on success,
    that function will decrement the reference count on unbind.  However on
    failure, devm_spi_register_master() does *not* decrement the reference
    count, so the spi_master is leaked.
    
    The issue was introduced by commits 8b797490b4db ("spi: gpio: Make sure
    spi_master_put() is called in every error path") and 79567c1a321e ("spi:
    gpio: Use devm_spi_register_master()"), which sought to plug leaks
    introduced by 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO
    descriptors") but missed this remaining leak.
    
    The situation was later aggravated by commit d3b0ffa1d75d ("spi: gpio:
    prevent memory leak in spi_gpio_probe"), which introduced a
    use-after-free because it releases a reference on the spi_master if
    devm_add_action_or_reset() fails even though the function already
    does that.
    
    Fix by switching over to the new devm_spi_alloc_master() helper.
    
    Fixes: 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO descriptors")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v5.1-: 8b797490b4db: spi: gpio: Make sure spi_master_put() is called in every error path
    Cc: <stable@vger.kernel.org> # v5.1-: 45beec351998: spi: bitbang: Introduce spi_bitbang_init()
    Cc: <stable@vger.kernel.org> # v5.1-: 79567c1a321e: spi: gpio: Use devm_spi_register_master()
    Cc: <stable@vger.kernel.org> # v5.4-: d3b0ffa1d75d: spi: gpio: prevent memory leak in spi_gpio_probe
    Cc: <stable@vger.kernel.org> # v4.17+
    Cc: Navid Emamdoost <navid.emamdoost@gmail.com>
    Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
    Link: https://lore.kernel.org/r/86eaed27431c3d709e3748eb76ceecbfc790dd37.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea923e72784e01531325fd9e4bbd441e4cdc647a
Author: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date:   Fri Nov 27 16:29:47 2020 +0100

    spi: fsl: fix use of spisel_boot signal on MPC8309
    
    commit 122541f2b10897b08f7f7e6db5f1eb693e51f0a1 upstream.
    
    Commit 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
    broke the use of the SPISEL_BOOT signal as a chip select on the
    MPC8309.
    
    pdata->max_chipselect, which becomes master->num_chipselect, must be
    initialized to take into account the possibility that there's one more
    chip select in use than the number of GPIO chip selects.
    
    Cc: stable@vger.kernel.org # v5.4+
    Cc: Christophe Leroy <christophe.leroy@c-s.fr>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
    Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Link: https://lore.kernel.org/r/20201127152947.376-1-rasmus.villemoes@prevas.dk
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e80a2e9603721c1fdaf94d28a3af62b02411a92
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 bbba6b7a53572be5eb3082ee6f8c81aef26876d9
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:15 2020 +0100

    spi: ar934x: Don't leak SPI master in probe error path
    
    commit 236924ee531d6251c8d10e9177b7742a60534ed5 upstream.
    
    If the call to devm_spi_register_controller() fails on probe of the
    Qualcomm Atheros AR934x/QCA95xx SPI driver, the spi_controller struct is
    erroneously not freed.  Fix by switching over to the new
    devm_spi_alloc_master() helper.
    
    Moreover, the controller's clock is enabled on probe but not disabled if
    any of the subsequent probe steps fail.
    
    Finally, there's an ordering issue in ar934x_spi_remove() wherein the
    clock is disabled even though the controller is not yet unregistered.
    It is unregistered after ar934x_spi_remove() by the devres framework.
    As long as it is not unregistered, SPI transfers may still be ongoing
    and disabling the clock may break them.  It is not possible to use
    devm_spi_register_controller() in this case, so move to the non-devm
    variant.
    
    All of these bugs have existed since the driver was first introduced,
    so it seems fair to fix them together in a single commit.
    
    Fixes: 047980c582af ("spi: add driver for ar934x spi controller")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v5.7+
    Cc: Chuanhong Guo <gch981213@gmail.com>
    Link: https://lore.kernel.org/r/1d58367d74d55741e0c2730a51a2b65012c8ab33.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: spi-mtk-nor: Don't leak SPI master in probe error path
    
    commit 0f4ad8d59f33b24dd86739f3be23e6af1a86f5a9 upstream.
    
    If the call to devm_spi_register_controller() fails on probe of the
    MediaTek SPI NOR driver, the spi_controller struct is erroneously not
    freed.
    
    Since commit a1daaa991ed1 ("spi: spi-mtk-nor: use dma_alloc_coherent()
    for bounce buffer"), the same happens if the call to
    dmam_alloc_coherent() fails.
    
    Since commit 3bfd9103c7af ("spi: spi-mtk-nor: Add power management
    support"), the same happens if the call to mtk_nor_enable_clk() fails.
    
    Fix by switching over to the new devm_spi_alloc_master() helper.
    
    Fixes: 881d1ee9fe81 ("spi: add support for mediatek spi-nor controller")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Ikjoon Jang <ikjn@chromium.org>
    Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v5.7+
    Cc: Chuanhong Guo <gch981213@gmail.com>
    Link: https://lore.kernel.org/r/d5b9f0289465394e73dedb8ec51e180a8f1dffc9.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    spi: atmel-quadspi: Fix use-after-free on unbind
    
    commit c7b884561cb5b641f3dbba950094110794119a6d upstream.
    
    atmel_qspi_remove() accesses the driver's private data after calling
    spi_unregister_controller() even though that function releases the last
    reference on the spi_controller 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: 2d30ac5ed633 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v5.0+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v5.0+
    Cc: Piotr Bugalski <bugalski.piotr@gmail.com>
    Link: https://lore.kernel.org/r/4b05c65cf6f1ea3251484fe9a00b4c65478a1ae3.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 672631640424191aa5334aaa6fc742a558ada7d1
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 14949322a14cd4cbd242ab6fd470248c853bdf4a
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:05 2020 +0100

    spi: pxa2xx: Fix use-after-free on unbind
    
    commit 5626308bb94d9f930aa5f7c77327df4c6daa7759 upstream.
    
    pxa2xx_spi_remove() accesses the driver's private data after calling
    spi_unregister_controller() even though that function releases the last
    reference on the spi_controller and thereby frees the private data.
    
    Fix by switching over to the new devm_spi_alloc_master/slave() helper
    which keeps the private data accessible until the driver has unbound.
    
    Fixes: 32e5b57232c0 ("spi: pxa2xx: Fix controller unregister order")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v2.6.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v2.6.17+: 32e5b57232c0: spi: pxa2xx: Fix controller unregister order
    Cc: <stable@vger.kernel.org> # v2.6.17+
    Link: https://lore.kernel.org/r/5764b04d4a6e43069ebb7808f64c2f774ac6f193.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 067d9120a3289460520079841813cd28981dc298
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Tue Nov 24 14:38:07 2020 +0200

    iio: ad_sigma_delta: Don't put SPI transfer buffer on the stack
    
    commit 0fb6ee8d0b5e90b72f870f76debc8bd31a742014 upstream.
    
    Use a heap allocated memory for the SPI transfer buffer. Using stack memory
    can corrupt stack memory when using DMA on some systems.
    
    This change moves the buffer from the stack of the trigger handler call to
    the heap of the buffer of the state struct. The size increases takes into
    account the alignment for the timestamp, which is 8 bytes.
    
    The 'data' buffer is split into 'tx_buf' and 'rx_buf', to make a clearer
    separation of which part of the buffer should be used for TX & RX.
    
    Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Link: https://lore.kernel.org/r/20201124123807.19717-1-alexandru.ardelean@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 43be7c3b8192e75e07f1a7f44e465441149aff7a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Dec 16 09:29:51 2020 +0000

    drm/i915: Fix mismatch between misplaced vma check and vma insert
    
    commit 0e53656ad8abc99e0a80c3de611e593ebbf55829 upstream.
    
    When inserting a VMA, we restrict the placement to the low 4G unless the
    caller opts into using the full range. This was done to allow usersapce
    the opportunity to transition slowly from a 32b address space, and to
    avoid breaking inherent 32b assumptions of some commands.
    
    However, for insert we limited ourselves to 4G-4K, but on verification
    we allowed the full 4G. This causes some attempts to bind a new buffer
    to sporadically fail with -ENOSPC, but at other times be bound
    successfully.
    
    commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
    page") suggests that there is a genuine problem with stateless addressing
    that cannot utilize the last page in 4G and so we purposefully excluded
    it. This means that the quick pin pass may cause us to utilize a buggy
    placement.
    
    Reported-by: CQ Tang <cq.tang@intel.com>
    Testcase: igt/gem_exec_params/larger-than-life-batch
    Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: CQ Tang <cq.tang@intel.com>
    Reviewed-by: CQ Tang <cq.tang@intel.com>
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Cc: <stable@vger.kernel.org> # v4.5+
    Link: https://patchwork.freedesktop.org/patch/msgid/20201216092951.7124-1-chris@chris-wilson.co.uk
    (cherry picked from commit 5f22cc0b134ab702d7f64b714e26018f7288ffee)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8357c910e4143d168045843e84cbda3ebbd5880
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 ea64b21c6638d1ac3120fff89eb20c0e525a21d9
Author: Stylon Wang <stylon.wang@amd.com>
Date:   Tue Nov 10 15:40:06 2020 +0800

    drm/amd/display: Fix memory leaks in S3 resume
    
    commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362 upstream.
    
    EDID parsing in S3 resume pushes new display modes
    to probed_modes list but doesn't consolidate to actual
    mode list. This creates a race condition when
    amdgpu_dm_connector_ddc_get_modes() re-initializes the
    list head without walking the list and results in  memory leak.
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209987
    Acked-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Signed-off-by: Stylon Wang <stylon.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08a050c197ed840a800dc30c6c9322bd678019b4
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Dec 17 12:11:36 2020 -0500

    drm/amdgpu: only set DP subconnector type on DP and eDP connectors
    
    commit 05211e7fbbf042dd7f51155ebe64eb2ecacb25cb upstream.
    
    Fixes a crash in drm_object_property_set_value() because the property
    is not set for internal DP ports that connect to a bridge chips
    (e.g., DP to VGA or DP to LVDS).
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=210739
    Fixes: 65bf2cf95d3ade ("drm/amdgpu: utilize subconnector property for DP through atombios")
    Tested-By: Kris Karas <bugs-a17@moonlit-rail.com>
    Cc: Oleg Vasilev <oleg.vasilev@intel.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 5.10.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 898f999e940f2feee2d26532adefb67b2548f91f
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 86fcb7910df7afd6c31e6e0a5c30c22af5ae009b
Author: Boris Brezillon <boris.brezillon@collabora.com>
Date:   Thu Nov 5 16:17:04 2020 +0100

    drm/panfrost: Move the GPU reset bits outside the timeout handler
    
    commit 5bc5cc2819c2c0adb644919e3e790b504ea47e0a upstream.
    
    We've fixed many races in panfrost_job_timedout() but some remain.
    Instead of trying to fix it again, let's simplify the logic and move
    the reset bits to a separate work scheduled when one of the queue
    reports a timeout.
    
    v5:
    - Simplify panfrost_scheduler_stop() (Steven Price)
    - Always restart the queue in panfrost_scheduler_start() even if
      the status is corrupted (Steven Price)
    
    v4:
    - Rework the logic to prevent a race between drm_sched_start()
      (reset work) and drm_sched_job_timedout() (timeout work)
    - Drop Steven's R-b
    - Add dma_fence annotation to the panfrost_reset() function (Daniel Vetter)
    
    v3:
    - Replace the atomic_cmpxchg() by an atomic_xchg() (Robin Murphy)
    - Add Steven's R-b
    
    v2:
    - Use atomic_cmpxchg() to conditionally schedule the reset work
      (Steven Price)
    
    Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Signed-off-by: Steven Price <steven.price@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201105151704.2010667-1-boris.brezillon@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a61da034c5e97ac879f102c831eaa311af9cbaab
Author: Boris Brezillon <boris.brezillon@collabora.com>
Date:   Fri Oct 2 14:25:06 2020 +0200

    drm/panfrost: Fix job timeout handling
    
    commit 1a11a88cfd9a97e13be8bc880c4795f9844fbbec upstream.
    
    If more than two jobs end up timeout-ing concurrently, only one of them
    (the one attached to the scheduler acquiring the lock) is fully handled.
    The other one remains in a dangling state where it's no longer part of
    the scheduling queue, but still blocks something in scheduler, leading
    to repetitive timeouts when new jobs are queued.
    
    Let's make sure all bad jobs are properly handled by the thread
    acquiring the lock.
    
    v3:
    - Add Steven's R-b
    - Don't take the sched_lock when stopping the schedulers
    
    v2:
    - Fix the subject prefix
    - Stop the scheduler before returning from panfrost_job_timedout()
    - Call cancel_delayed_work_sync() after drm_sched_stop() to make sure
      no timeout handlers are in flight when we reset the GPU (Steven Price)
    - Make sure we release the reset lock before restarting the
      schedulers (Steven Price)
    
    Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Signed-off-by: Steven Price <steven.price@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201002122506.1374183-1-boris.brezillon@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2032bf94ba4fb15db0c277614338d377fe430d2
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 41bf5eed809ec037ef5023b1950772a623051f98
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Dec 2 14:07:09 2020 +0200

    fsnotify: fix events reported to watching parent and child
    
    commit fecc4559780d52d174ea05e3bf543669165389c3 upstream.
    
    fsnotify_parent() used to send two separate events to backends when a
    parent inode is watching children and the child inode is also watching.
    In an attempt to avoid duplicate events in fanotify, we unified the two
    backend callbacks to a single callback and handled the reporting of the
    two separate events for the relevant backends (inotify and dnotify).
    However the handling is buggy and can result in inotify and dnotify
    listeners receiving events of the type they never asked for or spurious
    events.
    
    The problem is the unified event callback with two inode marks (parent and
    child) is called when any of the parent and child inodes are watched and
    interested in the event, but the parent inode's mark that is interested
    in the event on the child is not necessarily the one we are currently
    reporting to (it could belong to a different group).
    
    So before reporting the parent or child event flavor to backend we need
    to check that the mark is really interested in that event flavor.
    
    The semantics of INODE and CHILD marks were hard to follow and made the
    logic more complicated than it should have been.  Replace it with INODE
    and PARENT marks semantics to hopefully make the logic more clear.
    
    Thanks to Hugh Dickins for spotting a bug in the earlier version of this
    patch.
    
    Fixes: 497b0c5a7c06 ("fsnotify: send event to parent and child with single callback")
    CC: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201202120713.702387-4-amir73il@gmail.com
    Reported-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e78c6bd905e3d972d19a06d8fab8c81350a60ee
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Dec 2 14:07:08 2020 +0200

    inotify: convert to handle_inode_event() interface
    
    commit 1a2620a99803ad660edc5d22fd9c66cce91ceb1c upstream.
    
    Convert inotify to use the simple handle_inode_event() interface to
    get rid of the code duplication between the generic helper
    fsnotify_handle_event() and the inotify_handle_event() callback, which
    also happen to be buggy code.
    
    The bug will be fixed in the generic helper.
    
    Link: https://lore.kernel.org/r/20201202120713.702387-3-amir73il@gmail.com
    CC: stable@vger.kernel.org
    Fixes: b9a1b9772509 ("fsnotify: create method handle_inode_event() in fsnotify_operations")
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9be99c8619185e371dc6c0dd748fd1f5760d917
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Dec 2 14:07:07 2020 +0200

    fsnotify: generalize handle_inode_event()
    
    commit 950cc0d2bef078e1f6459900ca4d4b2a2e0e3c37 upstream.
    
    The handle_inode_event() interface was added as (quoting comment):
    "a simple variant of handle_event() for groups that only have inode
    marks and don't have ignore mask".
    
    In other words, all backends except fanotify.  The inotify backend
    also falls under this category, but because it required extra arguments
    it was left out of the initial pass of backends conversion to the
    simple interface.
    
    This results in code duplication between the generic helper
    fsnotify_handle_event() and the inotify_handle_event() callback
    which also happen to be buggy code.
    
    Generalize the handle_inode_event() arguments and add the check for
    FS_EXCL_UNLINK flag to the generic helper, so inotify backend could
    be converted to use the simple interface.
    
    Link: https://lore.kernel.org/r/20201202120713.702387-2-amir73il@gmail.com
    CC: stable@vger.kernel.org
    Fixes: b9a1b9772509 ("fsnotify: create method handle_inode_event() in fsnotify_operations")
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1aa8e7801ec2355565bda77d025272098270e77d
Author: lizhe <lizhe67@huawei.com>
Date:   Wed Oct 14 14:54:42 2020 +0800

    jffs2: Fix ignoring mounting options problem during remounting
    
    commit 08cd274f9b8283a1da93e2ccab216a336da83525 upstream.
    
    The jffs2 mount options will be ignored when remounting jffs2.
    It can be easily reproduced with the steps listed below.
    1. mount -t jffs2 -o compr=none /dev/mtdblockx /mnt
    2. mount -o remount compr=zlib /mnt
    
    Since ec10a24f10c8, the option parsing happens before fill_super and
    then pass fc, which contains the options parsing results, to function
    jffs2_reconfigure during remounting. But function jffs2_reconfigure do
    not update c->mount_opts.
    
    This patch add a function jffs2_update_mount_opts to fix this problem.
    
    By the way, I notice that tmpfs use the same way to update remounting
    options. If it is necessary to unify them?
    
    Cc: <stable@vger.kernel.org>
    Fixes: ec10a24f10c8 ("vfs: Convert jffs2 to use the new mount API")
    Signed-off-by: lizhe <lizhe67@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecdb868accde166eb55e2693109bcfc88ddbb710
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 453f2dfa340ffb8332b76d56eb51b170e64646d1
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 6489b80239ad1621562fa97a2c1322d97a806306
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 639fd38197ee2004c8ce08695f42a49c536173aa
Author: Steve French <stfrench@microsoft.com>
Date:   Wed Dec 9 01:12:35 2020 -0600

    SMB3.1.1: remove confusing mount warning when no SPNEGO info on negprot rsp
    
    commit bc7c4129d4cdc56d1b5477c1714246f27df914dd upstream.
    
    Azure does not send an SPNEGO blob in the negotiate protocol response,
    so we shouldn't assume that it is there when validating the location
    of the first negotiate context.  This avoids the potential confusing
    mount warning:
    
       CIFS: Invalid negotiate context offset
    
    CC: Stable <stable@vger.kernel.org>
    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 aa36952c5662894301a9c3ee3760879a450f3bf5
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 db1c6b8a266ef33ac0c1ddcdf82b8600c3e35d75
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 ef82413937d1656ff1b74310bb5496b18df1520e
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Nov 20 21:08:51 2020 +0100

    um: Fix time-travel mode
    
    commit ff9632d2a66512436d616ef4c380a0e73f748db1 upstream.
    
    Since the time-travel rework, basic time-travel mode hasn't worked
    properly, but there's no longer a need for this WARN_ON() so just
    remove it and thereby fix things.
    
    Cc: stable@vger.kernel.org
    Fixes: 4b786e24ca80 ("um: time-travel: Rewrite as an event scheduler")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4b425322134e2ee2950bc1ca54a66511a1526a9
Author: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Date:   Fri Nov 13 10:26:17 2020 +0000

    um: Remove use of asprinf in umid.c
    
    commit 97be7ceaf7fea68104824b6aa874cff235333ac1 upstream.
    
    asprintf is not compatible with the existing uml memory allocation
    mechanism. Its use on the "user" side of UML results in a corrupt slab
    state.
    
    Fixes: 0d4e5ac7e780 ("um: remove uses of variable length arrays")
    Cc: stable@vger.kernel.org
    Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f2206e3d90a9f131b8cfc3f7629c698aa625ce4
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 7c8c9e1e53fae71d574e418b3455fbc9b7f57f69
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Mon Dec 14 15:26:14 2020 +0100

    ovl: make ioctl() safe
    
    commit 89bdfaf93d9157499c3a0d61f489df66f2dead7f upstream.
    
    ovl_ioctl_set_flags() does a capability check using flags, but then the
    real ioctl double-fetches flags and uses potentially different value.
    
    The "Check the capability before cred override" comment misleading: user
    can skip this check by presenting benign flags first and then overwriting
    them to non-benign flags.
    
    Just remove the cred override for now, hoping this doesn't cause a
    regression.
    
    The proper solution is to create a new setxflags i_op (patches are in the
    works).
    
    Xfstests don't show a regression.
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Fixes: dab5ca8fd9dd ("ovl: add lsattr/chattr support")
    Cc: <stable@vger.kernel.org> # v4.19
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd2eda58ea0312645c8859945ff43e1fd3d6945f
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 4b8dcb006e181af228bd913926a4a39a19507848
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 8fe4bee4c0f65eac069998ba91595756309a2970
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Sun Nov 22 18:38:28 2020 +1100

    powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU
    
    commit b1198a88230f2ce50c271e22b82a8b8610b2eea9 upstream.
    
    We execute certain NPU2 setup code (such as mapping an LPID to a device
    in NPU2) unconditionally if an Nvlink bridge is detected. However this
    cannot succeed on POWER8NVL machines and errors appear in dmesg. This is
    harmless as skiboot returns an error and the only place we check it is
    vfio-pci but that code does not get called on P8+ either.
    
    This adds a check if pnv_npu2_xxx helpers are called on a machine with
    NPU2 which initializes pnv_phb::npu in pnv_npu2_init();
    pnv_phb::npu==NULL on POWER8/NVL (Naples).
    
    While at this, fix NULL derefencing in pnv_npu_peers_take_ownership/
    pnv_npu_peers_release_ownership which occurs when GPUs on mentioned P8s
    cause EEH which happens if "vfio-pci" disables devices using
    the D3 power state; the vfio-pci's disable_idle_d3 module parameter
    controls this and must be set on Naples. The EEH handling clears
    the entire pnv_ioda_pe struct in pnv_ioda_free_pe() hence
    the NULL derefencing. We cannot recover from that but at least we stop
    crashing.
    
    Tested on
    - POWER9 pvr=004e1201, Ubuntu 19.04 host, Ubuntu 18.04 vm,
      NVIDIA GV100 10de:1db1 driver 418.39
    - POWER8 pvr=004c0100, RHEL 7.6 host, Ubuntu 16.10 vm,
      NVIDIA P100 10de:15f9 driver 396.47
    
    Fixes: 1b785611e119 ("powerpc/powernv/npu: Add release_ownership hook")
    Cc: stable@vger.kernel.org # 5.0
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201122073828.15446-1-aik@ozlabs.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 600ebd043469bae31ad133cca77ef64fee2f168d
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Sat Oct 10 17:30:59 2020 +0000

    powerpc/mm: Fix verification of MMU_FTR_TYPE_44x
    
    commit 17179aeb9d34cc81e1a4ae3f85e5b12b13a1f8d0 upstream.
    
    MMU_FTR_TYPE_44x cannot be checked by cpu_has_feature()
    
    Use mmu_has_feature() instead
    
    Fixes: 23eb7f560a2a ("powerpc: Convert flush_icache_range & friends to C")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/ceede82fadf37f3b8275e61fcf8cf29a3e2ec7fe.1602351011.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8b871dfacfb4d5c3a10599d418520ca8a44ddb3
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Fri Dec 4 10:11:34 2020 +0000

    powerpc/8xx: Fix early debug when SMC1 is relocated
    
    commit 1e78f723d6a52966bfe3804209dbf404fdc9d3bb upstream.
    
    When SMC1 is relocated and early debug is selected, the
    board hangs is ppc_md.setup_arch(). This is because ones
    the microcode has been loaded and SMC1 relocated, early
    debug writes in the weed.
    
    To allow smooth continuation, the SMC1 parameter RAM set up
    by the bootloader have to be copied into the new location.
    
    Fixes: 43db76f41824 ("powerpc/8xx: Add microcode patch to move SMC parameter RAM.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/b2f71f39eca543f1e4ec06596f09a8b12235c701.1607076683.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bc125f596d166005f90835314d07c2fd735f6d6
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 2ae45223e46b49314a957d00292b4d7d2f61a1b7
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Oct 12 08:02:13 2020 +0000

    powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE
    
    commit 197493af414ee22427be3343637ac290a791925a upstream.
    
    G2_LE has a 603 core, add CPU_FTR_NOEXECUTE.
    
    Fixes: 385e89d5b20f ("powerpc/mm: add exec protection on powerpc 603")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/39a530ee41d83f49747ab3af8e39c056450b9b4d.1602489653.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe534d76d450b9b80481ac5fd620fc97cb977249
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Oct 22 14:05:46 2020 +0000

    powerpc/bitops: Fix possible undefined behaviour with fls() and fls64()
    
    commit 1891ef21d92c4801ea082ee8ed478e304ddc6749 upstream.
    
    fls() and fls64() are using __builtin_ctz() and _builtin_ctzll().
    On powerpc, those builtins trivially use ctlzw and ctlzd power
    instructions.
    
    Allthough those instructions provide the expected result with
    input argument 0, __builtin_ctz() and __builtin_ctzll() are
    documented as undefined for value 0.
    
    The easiest fix would be to use fls() and fls64() functions
    defined in include/asm-generic/bitops/builtin-fls.h and
    include/asm-generic/bitops/fls64.h, but GCC output is not optimal:
    
    00000388 <testfls>:
     388:   2c 03 00 00     cmpwi   r3,0
     38c:   41 82 00 10     beq     39c <testfls+0x14>
     390:   7c 63 00 34     cntlzw  r3,r3
     394:   20 63 00 20     subfic  r3,r3,32
     398:   4e 80 00 20     blr
     39c:   38 60 00 00     li      r3,0
     3a0:   4e 80 00 20     blr
    
    000003b0 <testfls64>:
     3b0:   2c 03 00 00     cmpwi   r3,0
     3b4:   40 82 00 1c     bne     3d0 <testfls64+0x20>
     3b8:   2f 84 00 00     cmpwi   cr7,r4,0
     3bc:   38 60 00 00     li      r3,0
     3c0:   4d 9e 00 20     beqlr   cr7
     3c4:   7c 83 00 34     cntlzw  r3,r4
     3c8:   20 63 00 20     subfic  r3,r3,32
     3cc:   4e 80 00 20     blr
     3d0:   7c 63 00 34     cntlzw  r3,r3
     3d4:   20 63 00 40     subfic  r3,r3,64
     3d8:   4e 80 00 20     blr
    
    When the input of fls(x) is a constant, just check x for nullity and
    return either 0 or __builtin_clz(x). Otherwise, use cntlzw instruction
    directly.
    
    For fls64() on PPC64, do the same but with __builtin_clzll() and
    cntlzd instruction. On PPC32, lets take the generic fls64() which
    will use our fls(). The result is as expected:
    
    00000388 <testfls>:
     388:   7c 63 00 34     cntlzw  r3,r3
     38c:   20 63 00 20     subfic  r3,r3,32
     390:   4e 80 00 20     blr
    
    000003a0 <testfls64>:
     3a0:   2c 03 00 00     cmpwi   r3,0
     3a4:   40 82 00 10     bne     3b4 <testfls64+0x14>
     3a8:   7c 83 00 34     cntlzw  r3,r4
     3ac:   20 63 00 20     subfic  r3,r3,32
     3b0:   4e 80 00 20     blr
     3b4:   7c 63 00 34     cntlzw  r3,r3
     3b8:   20 63 00 40     subfic  r3,r3,64
     3bc:   4e 80 00 20     blr
    
    Fixes: 2fcff790dcb4 ("powerpc: Use builtin functions for fls()/__fls()/fls64()")
    Cc: stable@vger.kernel.org
    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/348c2d3f19ffcff8abe50d52513f989c4581d000.1603375524.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e02baf91c7ccb463768a6a1349505f5049c96029
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 a4af71ae5a6becd5ab9a84314407eb9fed349133
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 ac9911f8119dc2104c35c5f70c9f39211bbf7936
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Dec 21 06:18:03 2020 +0000

    powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too
    
    commit d5c243989fb0cb03c74d7340daca3b819f706ee7 upstream.
    
    We need r1 to be properly set before activating MMU, otherwise any new
    exception taken while saving registers into the stack in syscall
    prologs will use the user stack, which is wrong and will even lockup
    or crash when KUAP is selected.
    
    Do that by switching the meaning of r11 and r1 until we have saved r1
    to the stack: copy r1 into r11 and setup the new stack pointer in r1.
    To avoid complicating and impacting all generic and specific prolog
    code (and more), copy back r1 into r11 once r11 is save onto
    the stack.
    
    We could get rid of copying r1 back and forth at the cost of rewriting
    everything to use r1 instead of r11 all the way when CONFIG_VMAP_STACK
    is set, but the effort is probably not worth it for now.
    
    Fixes: da7bb43ab9da ("powerpc/32: Fix vmap stack - Properly set r1 before activating MMU")
    Cc: stable@vger.kernel.org # v5.10+
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/a3d819d5c348cee9783a311d5d3f3ba9b48fd219.1608531452.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35f71f3cbd7d09dbc77764a3694bb0080ee0cb61
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Dec 8 18:29:02 2020 -0500

    xprtrdma: Fix XDRBUF_SPARSE_PAGES support
    
    commit 15261b9126cd5bb2ad8521da49d8f5c042d904c7 upstream.
    
    Olga K. observed that rpcrdma_marsh_req() allocates sparse pages
    only when it has determined that a Reply chunk is necessary. There
    are plenty of cases where no Reply chunk is needed, but the
    XDRBUF_SPARSE_PAGES flag is set. The result would be a crash in
    rpcrdma_inline_fixup() when it tries to copy parts of the received
    Reply into a missing page.
    
    To avoid crashing, handle sparse page allocation up front.
    
    Until XATTR support was added, this issue did not appear often
    because the only SPARSE_PAGES consumer always expected a reply large
    enough to always require a Reply chunk.
    
    Reported-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a9a98fdd45ed4daf2d99ba7ba168f2850ddbe38
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Wed Nov 11 10:38:47 2020 +0000

    ARM: tegra: Populate OPP table for Tegra20 Ventana
    
    commit bd7cd7e05a42491469ca19861da44abc3168cf5f upstream.
    
    Commit 9ce274630495 ("cpufreq: tegra20: Use generic cpufreq-dt driver
    (Tegra30 supported now)") update the Tegra20 CPUFREQ driver to use the
    generic CPUFREQ device-tree driver. Since this change CPUFREQ support
    on the Tegra20 Ventana platform has been broken because the necessary
    device-tree nodes with the operating point information are not populated
    for this platform. Fix this by updating device-tree for Venata to
    include the operating point informration for Tegra20.
    
    Fixes: 9ce274630495 ("cpufreq: tegra20: Use generic cpufreq-dt driver (Tegra30 supported now)")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a7899afed753bd0acd1d083e0ae1367909d7ed6
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 f02ba166a56d04e1eae3530bdf3f07269816cab8
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 1dd44b5e5f202c8d62794df13dd4a5e587a2e105
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Mon Oct 19 11:23:23 2020 -0700

    iommu/arm-smmu-qcom: Implement S2CR quirk
    
    commit f9081b8ff5934b8d69c748d0200e844cadd2c667 upstream.
    
    The firmware found in some Qualcomm platforms intercepts writes to S2CR
    in order to replace bypass type streams with fault; and ignore S2CR
    updates of type fault.
    
    Detect this behavior and implement a custom write_s2cr function in order
    to trick the firmware into supporting bypass streams by the means of
    configuring the stream for translation using a reserved and disabled
    context bank.
    
    Also circumvent the problem of configuring faulting streams by
    configuring the stream as bypass.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Acked-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20201019182323.3162386-4-bjorn.andersson@linaro.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f48e7f77713e844a1f77e1b2e0b90a1216159b8c
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Mon Oct 19 11:23:22 2020 -0700

    iommu/arm-smmu-qcom: Read back stream mappings
    
    commit 07a7f2caaa5a2619934491bab3c47b261c554fb0 upstream.
    
    The Qualcomm boot loader configures stream mapping for the peripherals
    that it accesses and in particular it sets up the stream mapping for the
    display controller to be allowed to scan out a splash screen or EFI
    framebuffer.
    
    Read back the stream mappings during initialization and make the
    arm-smmu driver maintain the streams in bypass mode.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Acked-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20201019182323.3162386-3-bjorn.andersson@linaro.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3192e184ad9476938d8fb797731dfd1ac25ffa09
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Mon Oct 19 11:23:21 2020 -0700

    iommu/arm-smmu: Allow implementation specific write_s2cr
    
    commit 56b75b51ed6d5e7bffda59440404409bca2dff00 upstream.
    
    The firmware found in some Qualcomm platforms intercepts writes to the
    S2CR register in order to replace the BYPASS type with FAULT. Further
    more it treats faults at this level as catastrophic and restarts the
    device.
    
    Add support for providing implementation specific versions of the S2CR
    write function, to allow the Qualcomm driver to work around this
    behavior.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20201019182323.3162386-2-bjorn.andersson@linaro.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 711081d7e09606ecbcef9e40774d7363a894cade
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Thu Dec 10 11:09:37 2020 -0600

    KVM: SVM: Remove the call to sev_platform_status() during setup
    
    commit 9d4747d02376aeb8de38afa25430de79129c5799 upstream.
    
    When both KVM support and the CCP driver are built into the kernel instead
    of as modules, KVM initialization can happen before CCP initialization. As
    a result, sev_platform_status() will return a failure when it is called
    from sev_hardware_setup(), when this isn't really an error condition.
    
    Since sev_platform_status() doesn't need to be called at this time anyway,
    remove the invocation from sev_hardware_setup().
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Message-Id: <618380488358b56af558f2682203786f09a49483.1607620209.git.thomas.lendacky@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49830b2d1b91e7d840808a6a9809496e70edeeab
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Dec 3 09:40:15 2020 -0500

    KVM: x86: reinstate vendor-agnostic check on SPEC_CTRL cpuid bits
    
    commit 39485ed95d6b83b62fa75c06c2c4d33992e0d971 upstream.
    
    Until commit e7c587da1252 ("x86/speculation: Use synthetic bits for
    IBRS/IBPB/STIBP"), KVM was testing both Intel and AMD CPUID bits before
    allowing the guest to write MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD.
    Testing only Intel bits on VMX processors, or only AMD bits on SVM
    processors, fails if the guests are created with the "opposite" vendor
    as the host.
    
    While at it, also tweak the host CPU check to use the vendor-agnostic
    feature bit X86_FEATURE_IBPB, since we only care about the availability
    of the MSR on the host here and not about specific CPUID bits.
    
    Fixes: e7c587da1252 ("x86/speculation: Use synthetic bits for IBRS/IBPB/STIBP")
    Cc: stable@vger.kernel.org
    Reported-by: Denis V. Lunev <den@openvz.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e365b97a1576e2bb268664585533c1671e2f0709
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 e0dad9a78c853e0b636cc6acae88b2faed6d2fa5
Author: Tomasz Nowicki <tn@semihalf.com>
Date:   Thu Nov 5 12:26:02 2020 +0100

    arm64: dts: marvell: keep SMMU disabled by default for Armada 7040 and 8040
    
    commit f43cadef2df260101497a6aace05e24201f00202 upstream.
    
    FW has to configure devices' StreamIDs so that SMMU is able to lookup
    context and do proper translation later on. For Armada 7040 & 8040 and
    publicly available FW, most of the devices are configured properly,
    but some like ap_sdhci0, PCIe, NIC still remain unassigned which
    results in SMMU faults about unmatched StreamID (assuming
    ARM_SMMU_DISABLE_BYPASS_BY_DEFAUL=y).
    
    Since there is dependency on custom FW let SMMU be disabled by default.
    People who still willing to use SMMU need to enable manually and
    use ARM_SMMU_DISABLE_BYPASS_BY_DEFAUL=n (or via kernel command line)
    with extra caution.
    
    Fixes: 83a3545d9c37 ("arm64: dts: marvell: add SMMU support")
    Cc: <stable@vger.kernel.org> # 5.9+
    Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0403bf25a46dc8725498de37000a764231a2db0d
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Mon Nov 2 15:46:50 2020 +0200

    arm64: dts: ti: k3-am65: mark dss as dma-coherent
    
    commit 50301e8815c681bc5de8ca7050c4b426923d4e19 upstream.
    
    DSS is IO coherent on AM65, so we should mark it as such with
    'dma-coherent' property in the DT file.
    
    Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Acked-by: Nikhil Devshatwar <nikhil.nd@ti.com>
    Cc: stable@vger.kernel.org # v5.8+
    Link: https://lore.kernel.org/r/20201102134650.55321-1-tomi.valkeinen@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72b5a6ace8a8183c132f050f177e6d84a3c890e9
Author: Atish Patra <atish.patra@wdc.com>
Date:   Fri Dec 18 16:13:56 2020 -0800

    RISC-V: Fix usage of memblock_enforce_memory_limit
    
    commit de043da0b9e71147ca610ed542d34858aadfc61c upstream.
    
    memblock_enforce_memory_limit accepts the maximum memory size not the
    maximum address that can be handled by kernel. Fix the function invocation
    accordingly.
    
    Fixes: 1bd14a66ee52 ("RISC-V: Remove any memblock representing unusable memory area")
    Cc: stable@vger.kernel.org
    Reported-by: Bin Meng <bin.meng@windriver.com>
    Tested-by: Bin Meng <bin.meng@windriver.com>
    Acked-by: Mike Rapoport <rppt@linux.ibm.com>
    Signed-off-by: Atish Patra <atish.patra@wdc.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b3ade0b86865046ea07173011372cc9c5874773
Author: Jan Kara <jack@suse.cz>
Date:   Fri Nov 27 12:33:54 2020 +0100

    ext4: don't remount read-only with errors=continue on reboot
    
    commit b08070eca9e247f60ab39d79b2c25d274750441f upstream.
    
    ext4_handle_error() with errors=continue mount option can accidentally
    remount the filesystem read-only when the system is rebooting. Fix that.
    
    Fixes: 1dc1097ff60e ("ext4: avoid panic during forced reboot")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20201127113405.26867-2-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8f8e6ae9744af9e819c33771e73f79a1c9a516a
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 d28f60699590877f940f675717eafbfb30299b26
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 bc0e046052b204bd9fc1c45cfe044a82c7dd6c3d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Oct 23 14:22:32 2020 +0300

    ext4: fix an IS_ERR() vs NULL check
    
    commit bc18546bf68e47996a359d2533168d5770a22024 upstream.
    
    The ext4_find_extent() function never returns NULL, it returns error
    pointers.
    
    Fixes: 44059e503b03 ("ext4: fast commit recovery path")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20201023112232.GB282278@mwanda
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f4bf6eea3f3b920130a055eebc2cfc8398d5ba3
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Nov 4 11:07:33 2020 +0000

    btrfs: fix race when defragmenting leads to unnecessary IO
    
    commit 7f458a3873ae94efe1f37c8b96c97e7298769e98 upstream.
    
    When defragmenting we skip ranges that have holes or inline extents, so that
    we don't do unnecessary IO and waste space. We do this check when calling
    should_defrag_range() at btrfs_defrag_file(). However we do it without
    holding the inode's lock. The reason we do it like this is to avoid
    blocking other tasks for too long, that possibly want to operate on other
    file ranges, since after the call to should_defrag_range() and before
    locking the inode, we trigger a synchronous page cache readahead. However
    before we were able to lock the inode, some other task might have punched
    a hole in our range, or we may now have an inline extent there, in which
    case we should not set the range for defrag anymore since that would cause
    unnecessary IO and make us waste space (i.e. allocating extents to contain
    zeros for a hole).
    
    So after we locked the inode and the range in the iotree, check again if
    we have holes or an inline extent, and if we do, just skip the range.
    
    I hit this while testing my next patch that fixes races when updating an
    inode's number of bytes (subject "btrfs: update the number of bytes used
    by an inode atomically"), and it depends on this change in order to work
    correctly. Alternatively I could rework that other patch to detect holes
    and flag their range with the 'new delalloc' bit, but this itself fixes
    an efficiency problem due a race that from a functional point of view is
    not harmful (it could be triggered with btrfs/062 from fstests).
    
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c5bc5738be2677d7706e5cbd3561ffe820ed591
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri Oct 23 09:58:05 2020 -0400

    btrfs: update last_byte_to_unpin in switch_commit_roots
    
    commit 27d56e62e4748c2135650c260024e9904b8c1a0a upstream.
    
    While writing an explanation for the need of the commit_root_sem for
    btrfs_prepare_extent_commit, I realized we have a slight hole that could
    result in leaked space if we have to do the old style caching.  Consider
    the following scenario
    
     commit root
     +----+----+----+----+----+----+----+
     |\\\\|    |\\\\|\\\\|    |\\\\|\\\\|
     +----+----+----+----+----+----+----+
     0    1    2    3    4    5    6    7
    
     new commit root
     +----+----+----+----+----+----+----+
     |    |    |    |\\\\|    |    |\\\\|
     +----+----+----+----+----+----+----+
     0    1    2    3    4    5    6    7
    
    Prior to this patch, we run btrfs_prepare_extent_commit, which updates
    the last_byte_to_unpin, and then we subsequently run
    switch_commit_roots.  In this example lets assume that
    caching_ctl->progress == 1 at btrfs_prepare_extent_commit() time, which
    means that cache->last_byte_to_unpin == 1.  Then we go and do the
    switch_commit_roots(), but in the meantime the caching thread has made
    some more progress, because we drop the commit_root_sem and re-acquired
    it.  Now caching_ctl->progress == 3.  We swap out the commit root and
    carry on to unpin.
    
    The race can happen like:
    
      1) The caching thread was running using the old commit root when it
         found the extent for [2, 3);
    
      2) Then it released the commit_root_sem because it was in the last
         item of a leaf and the semaphore was contended, and set ->progress
         to 3 (value of 'last'), as the last extent item in the current leaf
         was for the extent for range [2, 3);
    
      3) Next time it gets the commit_root_sem, will start using the new
         commit root and search for a key with offset 3, so it never finds
         the hole for [2, 3).
    
      So the caching thread never saw [2, 3) as free space in any of the
      commit roots, and by the time finish_extent_commit() was called for
      the range [0, 3), ->last_byte_to_unpin was 1, so it only returned the
      subrange [0, 1) to the free space cache, skipping [2, 3).
    
    In the unpin code we have last_byte_to_unpin == 1, so we unpin [0,1),
    but do not unpin [2,3).  However because caching_ctl->progress == 3 we
    do not see the newly freed section of [2,3), and thus do not add it to
    our free space cache.  This results in us missing a chunk of free space
    in memory (on disk too, unless we have a power failure before writing
    the free space cache to disk).
    
    Fix this by making sure the ->last_byte_to_unpin is set at the same time
    that we swap the commit roots, this ensures that we will always be
    consistent.
    
    CC: stable@vger.kernel.org # 5.8+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    [ update changelog with Filipe's review comments ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56d1654dc2fe1deaabf0a11b24cbe429951da855
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri Oct 23 09:58:04 2020 -0400

    btrfs: do not shorten unpin len for caching block groups
    
    commit 9076dbd5ee837c3882fc42891c14cecd0354a849 upstream.
    
    While fixing up our ->last_byte_to_unpin locking I noticed that we will
    shorten len based on ->last_byte_to_unpin if we're caching when we're
    adding back the free space.  This is correct for the free space, as we
    cannot unpin more than ->last_byte_to_unpin, however we use len to
    adjust the ->bytes_pinned counters and such, which need to track the
    actual pinned usage.  This could result in
    WARN_ON(space_info->bytes_pinned) triggering at unmount time.
    
    Fix this by using a local variable for the amount to add to free space
    cache, and leave len untouched in this case.
    
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed5e2515a3d679d1e31b9c7927096a361aa52bf6
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 28a9c268380afdfc650200949c8b94e8d54e3650
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 df2754ae5f0eb7d15d541d837b8e8725d3e56817
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 1254104e1c43f837abf047215bb1ffb0722d3007
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 3a24c8cbb618700ef4209fea24dc1ae31dc585e3
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 24372050388d648d3544829808fab68def47a844
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 272c6a678efe021bb6bd25e793a970edc70294b6
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 ddbb36cb3f2d496db04d0f58d7d81125e011f3a8
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 fe9db435d27eee184b0370e435e319093a3bd172
Author: Jim Cromie <jim.cromie@gmail.com>
Date:   Wed Dec 9 11:36:25 2020 -0700

    dyndbg: fix use before null check
    
    commit 3577afb0052fca65e67efdfc8e0859bb7bac87a6 upstream.
    
    In commit a2d375eda771 ("dyndbg: refine export, rename to
    dynamic_debug_exec_queries()"), a string is copied before checking it
    isn't NULL.  Fix this, report a usage/interface error, and return the
    proper error code.
    
    Fixes: a2d375eda771 ("dyndbg: refine export, rename to dynamic_debug_exec_queries()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
    Link: https://lore.kernel.org/r/20201209183625.2432329-1-jim.cromie@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 771b663fa532de68992f0ffda8205c2e871b0e9a
Author: Daniel Jordan <daniel.m.jordan@oracle.com>
Date:   Thu Nov 12 12:17:11 2020 -0500

    cpuset: fix race between hotplug work and later CPU offline
    
    commit 406100f3da08066c00105165db8520bbc7694a36 upstream.
    
    One of our machines keeled over trying to rebuild the scheduler domains.
    Mainline produces the same splat:
    
      BUG: unable to handle page fault for address: 0000607f820054db
      CPU: 2 PID: 149 Comm: kworker/1:1 Not tainted 5.10.0-rc1-master+ #6
      Workqueue: events cpuset_hotplug_workfn
      RIP: build_sched_domains
      Call Trace:
       partition_sched_domains_locked
       rebuild_sched_domains_locked
       cpuset_hotplug_workfn
    
    It happens with cgroup2 and exclusive cpusets only.  This reproducer
    triggers it on an 8-cpu vm and works most effectively with no
    preexisting child cgroups:
    
      cd $UNIFIED_ROOT
      mkdir cg1
      echo 4-7 > cg1/cpuset.cpus
      echo root > cg1/cpuset.cpus.partition
    
      # with smt/control reading 'on',
      echo off > /sys/devices/system/cpu/smt/control
    
    RIP maps to
    
      sd->shared = *per_cpu_ptr(sdd->sds, sd_id);
    
    from sd_init().  sd_id is calculated earlier in the same function:
    
      cpumask_and(sched_domain_span(sd), cpu_map, tl->mask(cpu));
      sd_id = cpumask_first(sched_domain_span(sd));
    
    tl->mask(cpu), which reads cpu_sibling_map on x86, returns an empty mask
    and so cpumask_first() returns >= nr_cpu_ids, which leads to the bogus
    value from per_cpu_ptr() above.
    
    The problem is a race between cpuset_hotplug_workfn() and a later
    offline of CPU N.  cpuset_hotplug_workfn() updates the effective masks
    when N is still online, the offline clears N from cpu_sibling_map, and
    then the worker uses the stale effective masks that still have N to
    generate the scheduling domains, leading the worker to read
    N's empty cpu_sibling_map in sd_init().
    
    rebuild_sched_domains_locked() prevented the race during the cgroup2
    cpuset series up until the Fixes commit changed its check.  Make the
    check more robust so that it can detect an offline CPU in any exclusive
    cpuset's effective mask, not just the top one.
    
    Fixes: 0ccea8feb980 ("cpuset: Make generate_sched_domains() work with partition")
    Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20201112171711.639541-1-daniel.m.jordan@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eae95da7fcc6fcc01e4325f461576aefe8a670ba
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 3a881be1b4e9f7485de4bc1a2f5968763df8a789
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date:   Tue Nov 17 20:49:51 2020 +0800

    EDAC/i10nm: Use readl() to access MMIO registers
    
    commit 83ff51c4e3fecf6b8587ce4d46f6eac59f5d7c5a upstream.
    
    Instead of raw access, use readl() to access MMIO registers of
    memory controller to avoid possible compiler re-ordering.
    
    Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d03b710d8eae5479a4c24cfadbca4bdb6bd05328
Author: Ahmed S. Darwish <a.darwish@linutronix.de>
Date:   Sun Dec 6 17:21:41 2020 +0100

    Documentation: seqlock: s/LOCKTYPE/LOCKNAME/g
    
    commit cf48647243cc28d15280600292db5777592606c5 upstream.
    
    Sequence counters with an associated write serialization lock are called
    seqcount_LOCKNAME_t. Fix the documentation accordingly.
    
    While at it, remove a paragraph that inappropriately discussed a
    seqlock.h implementation detail.
    
    Fixes: 6dd699b13d53 ("seqlock: seqcount_LOCKNAME_t: Standardize naming convention")
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20201206162143.14387-2-a.darwish@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29563a73819a93f44d0311c3ac59d26d907fb4ca
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Sun Nov 22 10:28:17 2020 +1100

    m68k: Fix WARNING splat in pmac_zilog driver
    
    commit a7b5458ce73b235be027cf2658c39b19b7e58cf2 upstream.
    
    Don't add platform resources that won't be used. This avoids a
    recently-added warning from the driver core, that can show up on a
    multi-platform kernel when !MACH_IS_MAC.
    
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 0 at drivers/base/platform.c:224 platform_get_irq_optional+0x8e/0xce
    0 is an invalid IRQ number
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-multi #1
    Stack from 004b3f04:
            004b3f04 00462c2f 00462c2f 004b3f20 0002e128 004754db 004b6ad4 004b3f4c
            0002e19c 004754f7 000000e0 00285ba0 00000009 00000000 004b3f44 ffffffff
            004754db 004b3f64 004b3f74 00285ba0 004754f7 000000e0 00000009 004754db
            004fdf0c 005269e2 004fdf0c 00000000 004b3f88 00285cae 004b6964 00000000
            004fdf0c 004b3fac 0051cc68 004b6964 00000000 004b6964 00000200 00000000
            0051cc3e 0023c18a 004b3fc0 0051cd8a 004fdf0c 00000002 0052b43c 004b3fc8
    Call Trace: [<0002e128>] __warn+0xa6/0xd6
     [<0002e19c>] warn_slowpath_fmt+0x44/0x76
     [<00285ba0>] platform_get_irq_optional+0x8e/0xce
     [<00285ba0>] platform_get_irq_optional+0x8e/0xce
     [<00285cae>] platform_get_irq+0x12/0x4c
     [<0051cc68>] pmz_init_port+0x2a/0xa6
     [<0051cc3e>] pmz_init_port+0x0/0xa6
     [<0023c18a>] strlen+0x0/0x22
     [<0051cd8a>] pmz_probe+0x34/0x88
     [<0051cde6>] pmz_console_init+0x8/0x28
     [<00511776>] console_init+0x1e/0x28
     [<0005a3bc>] printk+0x0/0x16
     [<0050a8a6>] start_kernel+0x368/0x4ce
     [<005094f8>] _sinittext+0x4f8/0xc48
    random: get_random_bytes called from print_oops_end_marker+0x56/0x80 with crng_init=0
    ---[ end trace 392d8e82eed68d6c ]---
    
    Commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid"),
    which introduced the WARNING, suggests that testing for irq == 0 is
    undesirable. Instead of that comparison, just test for resource existence.
    
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Joshua Thompson <funaho@jurai.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Cc: stable@vger.kernel.org # v5.8+
    Reported-by: Laurent Vivier <laurent@vivier.eu>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Link: https://lore.kernel.org/r/0c0fe1e4f11ccec202d4df09ea7d9d98155d101a.1606001297.git.fthain@telegraphics.com.au
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da446be71e3b67cc45e473ec50b50f12d7f2d368
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Thu Nov 26 08:49:07 2020 +0100

    crypto: arm/aes-ce - work around Cortex-A57/A72 silion errata
    
    commit f3456b9fd269c6d0c973b136c5449d46b2510f4b upstream.
    
    ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected
    by silicon errata #1742098 and #1655431, respectively, where the second
    instruction of a AES instruction pair may execute twice if an interrupt
    is taken right after the first instruction consumes an input register of
    which a single 32-bit lane has been updated the last time it was modified.
    
    This is not such a rare occurrence as it may seem: in counter mode, only
    the least significant 32-bit word is incremented in the absence of a
    carry, which makes our counter mode implementation susceptible to these
    errata.
    
    So let's shuffle the counter assignments around a bit so that the most
    recent updates when the AES instruction pair executes are 128-bit wide.
    
    [0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice
    [1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice
    
    Cc: <stable@vger.kernel.org> # v5.4+
    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 c49bfdb521017bdabd9dc5420afbfd688e8f300f
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 fef8633a85fb6d8f11535057808e87d71e1e51a6
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Dec 17 20:17:49 2020 +0100

    cpufreq: intel_pstate: Use most recent guaranteed performance values
    
    commit e40ad84c26b4deeee46666492ec66b9a534b8e59 upstream.
    
    When turbo has been disabled by the BIOS, but HWP_CAP.GUARANTEED is
    changed later, user space may want to take advantage of this increased
    guaranteed performance.
    
    HWP_CAP.GUARANTEED is not a static value.  It can be adjusted by an
    out-of-band agent or during an Intel Speed Select performance level
    change.  The HWP_CAP.MAX is still the maximum achievable performance
    with turbo disabled by the BIOS, so HWP_CAP.GUARANTEED can still
    change as long as it remains less than or equal to HWP_CAP.MAX.
    
    When HWP_CAP.GUARANTEED is changed, the sysfs base_frequency
    attribute shows the most recent guaranteed frequency value. This
    attribute can be used by user space software to update the scaling
    min/max limits of the CPU.
    
    Currently, the ->setpolicy() callback already uses the latest
    HWP_CAP values when setting HWP_REQ, but the ->verify() callback will
    restrict the user settings to the to old guaranteed performance value
    which prevents user space from making use of the extra CPU capacity
    theoretically available to it after increasing HWP_CAP.GUARANTEED.
    
    To address this, read HWP_CAP in intel_pstate_verify_cpu_policy()
    to obtain the maximum P-state that can be used and use that to
    confine the policy max limit instead of using the cached and
    possibly stale pstate.max_freq value for this purpose.
    
    For consistency, update intel_pstate_update_perf_limits() to use the
    maximum available P-state returned by intel_pstate_get_hwp_max() to
    compute the maximum frequency instead of using the return value of
    intel_pstate_get_max_freq() which, again, may be stale.
    
    This issue is a side-effect of fixing the scaling frequency limits in
    commit eacc9c5a927e ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max()
    for turbo disabled") which corrected the setting of the reduced scaling
    frequency values, but caused stale HWP_CAP.GUARANTEED to be used in
    the case at hand.
    
    Fixes: eacc9c5a927e ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled")
    Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: 5.8+ <stable@vger.kernel.org> # 5.8+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58b97af1768d6fb5cfcdd683b67eab65f93c9936
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 0b505007f93e5976814c167f40b61ae7fe01799b
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed Nov 25 13:37:20 2020 -0800

    perf/x86/intel/lbr: Fix the return type of get_lbr_cycles()
    
    commit f8129cd958b395575e5543ce25a8434874b04d3a upstream.
    
    The cycle count of a timed LBR is always 1 in perf record -D.
    
    The cycle count is stored in the first 16 bits of the IA32_LBR_x_INFO
    register, but the get_lbr_cycles() return Boolean type.
    
    Use u16 to replace the Boolean type.
    
    Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
    Reported-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20201125213720.15692-2-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc4ac17ece7447056999dbe644c1e6fc1b06f27
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed Nov 25 13:37:19 2020 -0800

    perf/x86/intel: Fix rtm_abort_event encoding on Ice Lake
    
    commit 46b72e1bf4fc571da0c29c6fb3e5b2a2107a4c26 upstream.
    
    According to the event list from icelake_core_v1.09.json, the encoding
    of the RTM_RETIRED.ABORTED event on Ice Lake should be,
        "EventCode": "0xc9",
        "UMask": "0x04",
        "EventName": "RTM_RETIRED.ABORTED",
    
    Correct the wrong encoding.
    
    Fixes: 6017608936c1 ("perf/x86/intel: Add Icelake support")
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20201125213720.15692-1-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fdd3589a26367081dc0ef9f5d83c5cf2c310059
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Mon Oct 19 09:45:29 2020 -0700

    perf/x86/intel: Add event constraint for CYCLE_ACTIVITY.STALLS_MEM_ANY
    
    commit 306e3e91edf1c6739a55312edd110d298ff498dd upstream.
    
    The event CYCLE_ACTIVITY.STALLS_MEM_ANY (0x14a3) should be available on
    all 8 GP counters on ICL, but it's only scheduled on the first four
    counters due to the current ICL constraint table.
    
    Add a line for the CYCLE_ACTIVITY.STALLS_MEM_ANY event in the ICL
    constraint table.
    Correct the comments for the CYCLE_ACTIVITY.CYCLES_MEM_ANY event.
    
    Fixes: 6017608936c1 ("perf/x86/intel: Add Icelake support")
    Reported-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20201019164529.32154-1-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 746d179b0e66b986dd7e186adf48b01a0d0283c0
Author: Vitaly Wool <vitaly.wool@konsulko.com>
Date:   Mon Dec 14 19:12:33 2020 -0800

    z3fold: stricter locking and more careful reclaim
    
    commit dcf5aedb24f899d537e21c18ea552c780598d352 upstream.
    
    Use temporary slots in reclaim function to avoid possible race when
    freeing those.
    
    While at it, make sure we check CLAIMED flag under page lock in the
    reclaim function to make sure we are not racing with z3fold_alloc().
    
    Link: https://lkml.kernel.org/r/20201209145151.18994-4-vitaly.wool@konsulko.com
    Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com>
    Cc: <stable@vger.kernel.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    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 b8b1d4e96a1074707cbaf1df59ae328e691b2bd5
Author: Vitaly Wool <vitaly.wool@konsulko.com>
Date:   Mon Dec 14 19:12:30 2020 -0800

    z3fold: simplify freeing slots
    
    commit fc5488651c7d840c9cad9b0f273f2f31bd03413a upstream.
    
    Patch series "z3fold: stability / rt fixes".
    
    Address z3fold stability issues under stress load, primarily in the
    reclaim and free aspects.  Besides, it fixes the locking problems that
    were only seen in real-time kernel configuration.
    
    This patch (of 3):
    
    There used to be two places in the code where slots could be freed, namely
    when freeing the last allocated handle from the slots and when releasing
    the z3fold header these slots aree linked to.  The logic to decide on
    whether to free certain slots was complicated and error prone in both
    functions and it led to failures in RT case.
    
    To fix that, make free_handle() the single point of freeing slots.
    
    Link: https://lkml.kernel.org/r/20201209145151.18994-1-vitaly.wool@konsulko.com
    Link: https://lkml.kernel.org/r/20201209145151.18994-2-vitaly.wool@konsulko.com
    Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com>
    Tested-by: Mike Galbraith <efault@gmx.de>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    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 e885d1c515dabd18e05b838a3b36364b400ad58c
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 6dcea0e5d277b7f0be1284d70a35e2080f83cdd3
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Tue Dec 8 19:12:33 2020 +0100

    ASoC: AMD Raven/Renoir - fix the PCI probe (PCI revision)
    
    commit 55d8e6a85bce21f748c42eedea63681219f70523 upstream.
    
    The Raven and Renoir ACP can be distinguished by the PCI revision.
    Let's do the check very early, otherwise the wrong probe code
    can be run.
    
    Link: https://lore.kernel.org/alsa-devel/2e4587f8-f602-cf23-4845-fd27a32b1cfc@amd.com/
    Cc: <stable@kernel.org>
    Cc: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20201208181233.2745726-1-perex@perex.cz
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7d6aaca08c65bbe1c8879dccd5c6d4640530039
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Tue Dec 8 18:12:00 2020 +0100

    ASoC: AMD Renoir - add DMI table to avoid the ACP mic probe (broken BIOS)
    
    commit 718c406e1ffaca4eac987b957bbb36ce1090797a upstream.
    
    Users reported that some Lenovo AMD platforms do not have ACP microphone,
    but the BIOS advertises it via ACPI.
    
    This patch create a simple DMI table, where those machines with the broken
    BIOS can be added. The DMI description for Lenovo IdeaPad 5 and
    IdeaPad Flex 5 devices are added there.
    
    Also describe the dmic_acpi_check kernel module parameter in a more
    understandable way.
    
    Cc: <stable@kernel.org>
    Cc: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20201208171200.2737620-1-perex@perex.cz
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74a4802ff431759e41a514880942109140199d32
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Dec 8 14:51:54 2020 +0100

    ASoC: cx2072x: Fix doubly definitions of Playback and Capture streams
    
    commit 0d024a8bec084205fdd9fa17479ba91f45f85db3 upstream.
    
    The cx2072x codec driver defines multiple DAIs with the same stream
    name "Playback" and "Capture".  Although the current code works more
    or less as is as the secondary streams are never used, it still leads
    the error message like:
     debugfs: File 'Playback' in directory 'dapm' already present!
     debugfs: File 'Capture' in directory 'dapm' already present!
    
    Fix it by renaming the secondary streams to unique names.
    
    Fixes: a497a4363706 ("ASoC: Add support for Conexant CX2072X CODEC")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20201208135154.9188-1-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06da7fff770170eb140a47fbf11b87189bf360d2
Author: Todd Kjos <tkjos@google.com>
Date:   Fri Nov 20 15:37:43 2020 -0800

    binder: add flag to clear buffer on txn complete
    
    commit 0f966cba95c78029f491b433ea95ff38f414a761 upstream.
    
    Add a per-transaction flag to indicate that the buffer
    must be cleared when the transaction is complete to
    prevent copies of sensitive data from being preserved
    in memory.
    
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Link: https://lore.kernel.org/r/20201120233743.3617529-1-tkjos@google.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 983e7f3521f1442bc5629760b2008ebae676fcbc
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 18494d12ef9b75fbec3a63e6376f452e7d0174c6
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 96aca84128f2f4e3b687ad523ce96d10df51c39f
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 a67e261b5b9e36a73bb9d9d0bb1fcdeeea0e8232
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 24d9a8ef1f92277e2216ba73f8c087160a7b42f3
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Sun Dec 6 10:47:47 2020 +0100

    s390/idle: fix accounting with machine checks
    
    commit 454efcf82ea17d7efeb86ebaa20775a21ec87d27 upstream.
    
    When a machine check interrupt is triggered during idle, the code
    is using the async timer/clock for idle time calculation. It should use
    the machine check enter timer/clock which is passed to the macro.
    
    Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
    Cc: <stable@vger.kernel.org> # 5.8
    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 d5d21549d7eb73c3eeeef1e60d0c53ac2e61ad36
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Dec 3 22:03:32 2020 +0100

    s390/idle: add missing mt_cycles calculation
    
    commit e259b3fafa7de362b04ecd86e7fa9a9e9273e5fb upstream.
    
    During removal of the critical section cleanup the calculation
    of mt_cycles during idle was removed. This causes invalid
    accounting on systems with SMT enabled.
    
    Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
    Cc: <stable@vger.kernel.org> # 5.8
    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 bc8f8833e994c7b58236101686188ccd3d65098f
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 0063e1142a73fdd21dcc37d0251b91e515ecc797
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 bb9dc2f2e590197a9ddf160eec652d99b8ff1b79
Author: Robin Gong <yibin.gong@nxp.com>
Date:   Fri Dec 18 00:15:47 2020 +0800

    ALSA: core: memalloc: add page alignment for iram
    
    commit 74c64efa1557fef731b59eb813f115436d18078e upstream.
    
    Since mmap for userspace is based on page alignment, add page alignment
    for iram alloc from pool, otherwise, some good data located in the same
    page of dmab->area maybe touched wrongly by userspace like pulseaudio.
    
    Signed-off-by: Robin Gong <yibin.gong@nxp.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1608221747-3474-1-git-send-email-yibin.gong@nxp.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac95e33828cd63578ee2959c1ac3c23d2d738b58
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Dec 21 09:01:59 2020 +0100

    ALSA: usb-audio: Add alias entry for ASUS PRIME TRX40 PRO-S
    
    commit 525d9c57d0eeeb660d9b25e5b2d1c95975e3ba95 upstream.
    
    ASUS PRIME TRX40 PRO-S mobo with 0b05:1918 needs the same quirk alias
    for another ASUS mobo (0b05:1917) for the proper mixer mapping, etc.
    Add the corresponding entry.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210783
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201221080159.24468-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de8f8a38f2227e17e0aa2e6af43d044de23284d3
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 92549c90ed0ffabfaf7749e06c0decd3962cde64
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 11ba87db73b512b6eac1cb2ff0fb31abe73271ce
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Dec 17 16:52:44 2020 +0800

    ALSA: hda/realtek - Supported Dell fixed type headset
    
    commit 150927c3674d7db4dd51a7269e01423c8c78e53b upstream.
    
    This platform only supported iphone type headset.
    It can't support Dell headset mode.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/b97e971978034bc9b772a08ec91265e8@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dab63c1908af69d351a0a0c9bbe4e7eff83b86df
Author: Chris Chiu <chiu@endlessos.org>
Date:   Wed Dec 16 20:52:00 2020 +0800

    ALSA: hda/realtek: Remove dummy lineout on Acer TravelMate P648/P658
    
    commit 34cdf405aa5de827b8bef79a6c82c39120b3729b upstream.
    
    Acer TravelMate laptops P648/P658 series with codec ALC282 only have
    one physical jack for headset but there's a confusing lineout pin on
    NID 0x1b reported. Audio applications hence misunderstand that there
    are a speaker and a lineout, and take the lineout as the default audio
    output.
    
    Add a new quirk to remove the useless lineout and enable the pin 0x18
    for jack sensing and headset microphone.
    
    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/20201216125200.27053-1-chiu@endlessos.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c131e56ac9106ffb625ed886dd4091ed4c35814f
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 8a0e34b2739c65c0bf5fa54210cb7a82adc1b10f
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 8fdb961045883af17038196fba724e6fd6439e46
Author: Chris Chiu <chiu@endlessos.org>
Date:   Tue Dec 22 23:04:59 2020 +0800

    ALSA/hda: apply jack fixup for the Acer Veriton N4640G/N6640G/N2510G
    
    commit 13be30f156fda725b168ac89fc91f78651575307 upstream.
    
    This Acer Veriton N4640G/N6640G/N2510G desktops have 2 headphone
    jacks(front and rear), and a separate Mic In jack.
    
    The rear headphone jack is actually a line out jack but always silent
    while playing audio. The front 'Mic In' also fails the jack sensing.
    Apply the ALC269_FIXUP_LIFEBOOK to have all audio jacks to work as
    expected.
    
    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/20201222150459.9545-2-chiu@endlessos.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01b4436d027083c59bfeea61e22165409416e51a
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 eae5f04c934604b67cf45d88b5c3b616eb3fbe7a
Author: Kailang Yang <kailang@realtek.com>
Date:   Fri Dec 11 14:17:09 2020 +0800

    ALSA: hda/realtek - Add supported for more Lenovo ALC285 Headset Button
    
    commit 607184cb1635eaee239fe3fb9648a8b82a5232d7 upstream.
    
    Add supported for more Lenovo ALC285 Headset Button.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/bb1f1da1526d460885aa4257be81eb94@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 753f5e987ccd5933cc894146695f6ee5e3bc708f
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 c4be5cc0199e7350a99fceeef40a56236d29e928
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 8fcbbcdcdf233bb75c1f107c4e5114001b8137b2
Author: Hui Wang <hui.wang@canonical.com>
Date:   Sat Dec 5 13:11:30 2020 +0800

    ALSA: hda/realtek: make bass spk volume adjustable on a yoga laptop
    
    commit c72b9bfe0f914639cc475585f45722a3eb57a56d upstream.
    
    This change could fix 2 issues on this machine:
     - the bass speaker's output volume can't be adjusted, that is because
       the bass speaker is routed to the DAC (Nid 0x6) which has no volume
       control.
     - after plugging a headset with vol+, vol- and pause buttons on it,
       press those buttons, nothing happens, this means those buttons
       don't work at all. This machine has alc287 codec, need to add the
       codec id to the disable/enable_headset_jack_key(), then the headset
       button could work.
    
    The quirk of ALC285_FIXUP_THINKPAD_HEADSET_JACK could fix both of these
    2 issues.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20201205051130.8122-1-hui.wang@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ALSA: hda/ca0132 - Fix AE-5 rear headphone pincfg.
    
    commit c697ba85a94b8f65bf90dec5ef9af5c39c3e73b2 upstream.
    
    The Windows driver sets the pincfg for the AE-5's rear-headphone to
    report as a microphone. This causes issues with Pulseaudio mistakenly
    believing there is no headphone plugged in. In Linux, we should instead
    set it to be a headphone.
    
    Fixes: a6b0961b39896 ("ALSA: hda/ca0132 - fix AE-5 pincfg")
    Cc: <stable@kernel.org>
    Signed-off-by: Connor McAdams <conmanx360@gmail.com>
    Link: https://lore.kernel.org/r/20201208195223.424753-1-conmanx360@gmail.com
    Link: https://lore.kernel.org/r/20201210173550.2968-1-conmanx360@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66d7c29bcb43b0615e6065e7aade556a0024c429
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 66afcbcc75541c6ffa53d8325cc2eb8061025eb9
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 c5f7d62440ee5d1f0289e4c0831b36a49a94430e
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 0a9801f58ab2b5a66c7a20ce6ceb6dcfd22ad7b6
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 36fdd770c037e8292e4184eb2a36054c16d08739
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Nov 23 17:43:53 2020 -0800

    ACPI: NFIT: Fix input validation of bus-family
    
    commit 9a7e3d7f056831a6193d6d737fb7a26dfdceb04b upstream.
    
    Dan reports that smatch thinks userspace can craft an out-of-bound bus
    family number. However, nd_cmd_clear_to_send() blocks all non-zero
    values of bus-family since only the kernel can initiate these commands.
    However, in the speculation path, family is a user controlled array
    index value so mask it for speculation safety. Also, since the
    nd_cmd_clear_to_send() safety is non-obvious and possibly may change in
    the future include input validation as if userspace could get past the
    nd_cmd_clear_to_send() gatekeeper.
    
    Link: http://lore.kernel.org/r/20201111113000.GA1237157@mwanda
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e437f7e7a7672b15d5959212ac256cc411b93a6
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 f5a430c8ee0bf769765ea946429303ddf0807b6d
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 3974a5004626fd4fdbdeebbe6e3168c0ef7803a6
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 dd9d14e067fb0f887095b7ab49d1ea8398c9f051
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 ffa790f9e17eb9e104256072ddec9b2405c35c61
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 8a0f5b91e78c9a2c774b671c7baad46cd4baf5fc
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 6dbe4457e4d780586dd3c38a0009176e28411a2f
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 f3d752c6cd32c231576607075eb4cf90f084e0bb
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 330787231015ee9231ecb15c7673ced8fd8c2ff6
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 7b81e2af5a55b07016afa81123d40acf70c994c0
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Dec 20 10:45:02 2020 -0700

    io_uring: make ctx cancel on exit targeted to actual ctx
    
    commit 00c18640c2430c4bafaaeede1f9dd6f7ec0e4b25 upstream.
    
    Before IORING_SETUP_ATTACH_WQ, we could just cancel everything on the
    io-wq when exiting. But that's not the case if they are shared, so
    cancel for the specific ctx instead.
    
    Cc: stable@vger.kernel.org
    Fixes: 24369c2e3bb0 ("io_uring: add io-wq workqueue sharing")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5998fe548db9496ad0d151148ff1c6dbe1e0dacc
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Dec 21 18:34:05 2020 +0000

    io_uring: fix double io_uring free
    
    commit 9faadcc8abe4b83d0263216dc3a6321d5bbd616b upstream.
    
    Once we created a file for current context during setup, we should not
    call io_ring_ctx_wait_and_kill() directly as it'll be done by fput(file)
    
    Cc: stable@vger.kernel.org # 5.10
    Reported-by: syzbot+c9937dfb2303a5f18640@syzkaller.appspotmail.com
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    [axboe: fix unused 'ret' for !CONFIG_UNIX]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f8ebecc86a42a1ec9cd8646c752c772e7ee3bde
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Dec 21 18:34:04 2020 +0000

    io_uring: fix ignoring xa_store errors
    
    commit a528b04ea40690ff40501f50d618a62a02b19620 upstream.
    
    xa_store() may fail, check the result.
    
    Cc: stable@vger.kernel.org # 5.10
    Fixes: 0f2122045b946 ("io_uring: don't rely on weak ->files references")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10e5fb03e2dae2ff768a88227356dfc4c023b0cb
Author: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
Date:   Mon Dec 14 23:49:41 2020 +0800

    io_uring: hold uring_lock while completing failed polled io in io_wq_submit_work()
    
    commit c07e6719511e77c4b289f62bfe96423eb6ea061d upstream.
    
    io_iopoll_complete() does not hold completion_lock to complete polled io,
    so in io_wq_submit_work(), we can not call io_req_complete() directly, to
    complete polled io, otherwise there maybe concurrent access to cqring,
    defer_list, etc, which is not safe. Commit dad1b1242fd5 ("io_uring: always
    let io_iopoll_complete() complete polled io") has fixed this issue, but
    Pavel reported that IOPOLL apart from rw can do buf reg/unreg requests(
    IORING_OP_PROVIDE_BUFFERS or IORING_OP_REMOVE_BUFFERS), so the fix is not
    good.
    
    Given that io_iopoll_complete() is always called under uring_lock, so here
    for polled io, we can also get uring_lock to fix this issue.
    
    Fixes: dad1b1242fd5 ("io_uring: always let io_iopoll_complete() complete polled io")
    Cc: <stable@vger.kernel.org> # 5.5+
    Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    [axboe: don't deref 'req' after completing it']
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72a016d42d3611ee13eb1e0c943b7397f21f7b62
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Sat Dec 19 03:15:43 2020 +0000

    io_uring: fix 0-iov read buffer select
    
    commit dd20166236953c8cd14f4c668bf972af32f0c6be upstream.
    
    Doing vectored buf-select read with 0 iovec passed is meaningless and
    utterly broken, forbid it.
    
    Cc: <stable@vger.kernel.org> # 5.7+
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1442adcd964b2e58781455484d46e5f37959c5f
Author: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
Date:   Fri Dec 18 15:26:48 2020 +0800

    io_uring: fix io_wqe->work_list corruption
    
    commit 0020ef04e48571a88d4f482ad08f71052c5c5a08 upstream.
    
    For the first time a req punted to io-wq, we'll initialize io_wq_work's
    list to be NULL, then insert req to io_wqe->work_list. If this req is not
    inserted into tail of io_wqe->work_list, this req's io_wq_work list will
    point to another req's io_wq_work. For splitted bio case, this req maybe
    inserted to io_wqe->work_list repeatedly, once we insert it to tail of
    io_wqe->work_list for the second time, now io_wq_work->list->next will be
    invalid pointer, which then result in many strang error, panic, kernel
    soft-lockup, rcu stall, etc.
    
    In my vm, kernel doest not have commit cc29e1bf0d63f7 ("block: disable
    iopoll for split bio"), below fio job can reproduce this bug steadily:
    [global]
    name=iouring-sqpoll-iopoll-1
    ioengine=io_uring
    iodepth=128
    numjobs=1
    thread
    rw=randread
    direct=1
    registerfiles=1
    hipri=1
    bs=4m
    size=100M
    runtime=120
    time_based
    group_reporting
    randrepeat=0
    
    [device]
    directory=/home/feiman.wxg/mntpoint/  # an ext4 mount point
    
    If we have commit cc29e1bf0d63f7 ("block: disable iopoll for split bio"),
    there will no splitted bio case for polled io, but I think we still to need
    to fix this list corruption, it also should maybe go to stable branchs.
    
    To fix this corruption, if a req is inserted into tail of io_wqe->work_list,
    initialize req->io_wq_work->list->next to bu NULL.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acdd941fca537d64fea69352891a1d83f8b16967
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 06e5f9bb114b2fa11ca719727766977e9a93eb46
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Sun Nov 22 18:39:50 2020 +1100

    vfio/pci/nvlink2: Do not attempt NPU2 setup on POWER8NVL NPU
    
    commit d22f9a6c92de96304c81792942ae7c306f08ac77 upstream.
    
    We execute certain NPU2 setup code (such as mapping an LPID to a device
    in NPU2) unconditionally if an Nvlink bridge is detected. However this
    cannot succeed on POWER8NVL machines as the init helpers return an error
    other than ENODEV which means the device is there is and setup failed so
    vfio_pci_enable() fails and pass through is not possible.
    
    This changes the two NPU2 related init helpers to return -ENODEV if
    there is no "memory-region" device tree property as this is
    the distinction between NPU and NPU2.
    
    Tested on
    - POWER9 pvr=004e1201, Ubuntu 19.04 host, Ubuntu 18.04 vm,
      NVIDIA GV100 10de:1db1 driver 418.39
    - POWER8 pvr=004c0100, RHEL 7.6 host, Ubuntu 16.10 vm,
      NVIDIA P100 10de:15f9 driver 396.47
    
    Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver")
    Cc: stable@vger.kernel.org # 5.0
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be9aaec325cbc588a5393c04b015b18d2e3dff2e
Author: Eric Auger <eric.auger@redhat.com>
Date:   Fri Nov 13 18:52:02 2020 +0100

    vfio/pci: Move dummy_resources_list init in vfio_pci_probe()
    
    commit 16b8fe4caf499ae8e12d2ab1b1324497e36a7b83 upstream.
    
    In case an error occurs in vfio_pci_enable() before the call to
    vfio_pci_probe_mmaps(), vfio_pci_disable() will  try to iterate
    on an uninitialized list and cause a kernel panic.
    
    Lets move to the initialization to vfio_pci_probe() to fix the
    issue.
    
    Signed-off-by: Eric Auger <eric.auger@redhat.com>
    Fixes: 05f0c03fbac1 ("vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive")
    CC: Stable <stable@vger.kernel.org> # v4.7+
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd13f1d002a630bf8758df51e9c83da219ce0854
Author: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
Date:   Sun Dec 6 22:22:42 2020 +0000

    io_uring: always let io_iopoll_complete() complete polled io
    
    commit dad1b1242fd5717af18ae4ac9d12b9f65849e13a upstream.
    
    Abaci Fuzz reported a double-free or invalid-free BUG in io_commit_cqring():
    [   95.504842] BUG: KASAN: double-free or invalid-free in io_commit_cqring+0x3ec/0x8e0
    [   95.505921]
    [   95.506225] CPU: 0 PID: 4037 Comm: io_wqe_worker-0 Tainted: G    B
    W         5.10.0-rc5+ #1
    [   95.507434] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    [   95.508248] Call Trace:
    [   95.508683]  dump_stack+0x107/0x163
    [   95.509323]  ? io_commit_cqring+0x3ec/0x8e0
    [   95.509982]  print_address_description.constprop.0+0x3e/0x60
    [   95.510814]  ? vprintk_func+0x98/0x140
    [   95.511399]  ? io_commit_cqring+0x3ec/0x8e0
    [   95.512036]  ? io_commit_cqring+0x3ec/0x8e0
    [   95.512733]  kasan_report_invalid_free+0x51/0x80
    [   95.513431]  ? io_commit_cqring+0x3ec/0x8e0
    [   95.514047]  __kasan_slab_free+0x141/0x160
    [   95.514699]  kfree+0xd1/0x390
    [   95.515182]  io_commit_cqring+0x3ec/0x8e0
    [   95.515799]  __io_req_complete.part.0+0x64/0x90
    [   95.516483]  io_wq_submit_work+0x1fa/0x260
    [   95.517117]  io_worker_handle_work+0xeac/0x1c00
    [   95.517828]  io_wqe_worker+0xc94/0x11a0
    [   95.518438]  ? io_worker_handle_work+0x1c00/0x1c00
    [   95.519151]  ? __kthread_parkme+0x11d/0x1d0
    [   95.519806]  ? io_worker_handle_work+0x1c00/0x1c00
    [   95.520512]  ? io_worker_handle_work+0x1c00/0x1c00
    [   95.521211]  kthread+0x396/0x470
    [   95.521727]  ? _raw_spin_unlock_irq+0x24/0x30
    [   95.522380]  ? kthread_mod_delayed_work+0x180/0x180
    [   95.523108]  ret_from_fork+0x22/0x30
    [   95.523684]
    [   95.523985] Allocated by task 4035:
    [   95.524543]  kasan_save_stack+0x1b/0x40
    [   95.525136]  __kasan_kmalloc.constprop.0+0xc2/0xd0
    [   95.525882]  kmem_cache_alloc_trace+0x17b/0x310
    [   95.533930]  io_queue_sqe+0x225/0xcb0
    [   95.534505]  io_submit_sqes+0x1768/0x25f0
    [   95.535164]  __x64_sys_io_uring_enter+0x89e/0xd10
    [   95.535900]  do_syscall_64+0x33/0x40
    [   95.536465]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [   95.537199]
    [   95.537505] Freed by task 4035:
    [   95.538003]  kasan_save_stack+0x1b/0x40
    [   95.538599]  kasan_set_track+0x1c/0x30
    [   95.539177]  kasan_set_free_info+0x1b/0x30
    [   95.539798]  __kasan_slab_free+0x112/0x160
    [   95.540427]  kfree+0xd1/0x390
    [   95.540910]  io_commit_cqring+0x3ec/0x8e0
    [   95.541516]  io_iopoll_complete+0x914/0x1390
    [   95.542150]  io_do_iopoll+0x580/0x700
    [   95.542724]  io_iopoll_try_reap_events.part.0+0x108/0x200
    [   95.543512]  io_ring_ctx_wait_and_kill+0x118/0x340
    [   95.544206]  io_uring_release+0x43/0x50
    [   95.544791]  __fput+0x28d/0x940
    [   95.545291]  task_work_run+0xea/0x1b0
    [   95.545873]  do_exit+0xb6a/0x2c60
    [   95.546400]  do_group_exit+0x12a/0x320
    [   95.546967]  __x64_sys_exit_group+0x3f/0x50
    [   95.547605]  do_syscall_64+0x33/0x40
    [   95.548155]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The reason is that once we got a non EAGAIN error in io_wq_submit_work(),
    we'll complete req by calling io_req_complete(), which will hold completion_lock
    to call io_commit_cqring(), but for polled io, io_iopoll_complete() won't
    hold completion_lock to call io_commit_cqring(), then there maybe concurrent
    access to ctx->defer_list, double free may happen.
    
    To fix this bug, we always let io_iopoll_complete() complete polled io.
    
    Cc: <stable@vger.kernel.org> # 5.5+
    Reported-by: Abaci Fuzz <abaci@linux.alibaba.com>
    Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f961c2b496e60214a5913857958238e6ca0e1c0e
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Sun Dec 6 22:22:43 2020 +0000

    io_uring: fix racy IOPOLL completions
    
    commit 31bff9a51b264df6d144931a6a5f1d6cc815ed4b upstream.
    
    IOPOLL allows buffer remove/provide requests, but they doesn't
    synchronise by rules of IOPOLL, namely it have to hold uring_lock.
    
    Cc: <stable@vger.kernel.org> # 5.7+
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 821d12a15cc264f3597c93dc5d44d6e9bbf9f3a3
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Sun Dec 6 22:22:45 2020 +0000

    io_uring: fix io_cqring_events()'s noflush
    
    commit 59850d226e4907a6f37c1d2fe5ba97546a8691a4 upstream.
    
    Checking !list_empty(&ctx->cq_overflow_list) around noflush in
    io_cqring_events() is racy, because if it fails but a request overflowed
    just after that, io_cqring_overflow_flush() still will be called.
    
    Remove the second check, it shouldn't be a problem for performance,
    because there is cq_check_overflow bit check just above.
    
    Cc: <stable@vger.kernel.org> # 5.5+
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54677c80ba1cfb47984c76d9d67d282dc5ce9fb9
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Dec 27 10:56:33 2020 -0800

    proc mountinfo: make splice available again
    
    [ Upstream commit 14e3e989f6a5d9646b6cf60690499cc8bdc11f7d ]
    
    Since commit 36e2c7421f02 ("fs: don't allow splice read/write without
    explicit ops") we've required that file operation structures explicitly
    enable splice support, rather than falling back to the default handlers.
    
    Most /proc files use the indirect 'struct proc_ops' to describe their
    file operations, and were fixed up to support splice earlier in commits
    40be821d627c..b24c30c67863, but the mountinfo files interact with the
    VFS directly using their own 'struct file_operations' and got missed as
    a result.
    
    This adds the necessary support for splice to work for /proc/*/mountinfo
    and friends.
    
    Reported-by: Joan Bruguera Micó <joanbrugueram@gmail.com>
    Reported-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=209971
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f939abd8119564c1df3d9d16534879796f063c1
Author: Casey Schaufler <casey@schaufler-ca.com>
Date:   Tue Dec 22 15:34:24 2020 -0800

    Smack: Handle io_uring kernel thread privileges
    
    [ Upstream commit 942cb357ae7d9249088e3687ee6a00ed2745a0c7 ]
    
    Smack assumes that kernel threads are privileged for smackfs
    operations. This was necessary because the credential of the
    kernel thread was not related to a user operation. With io_uring
    the credential does reflect a user's rights and can be used.
    
    Suggested-by: Jens Axboe <axboe@kernel.dk>
    Acked-by: Jens Axboe <axboe@kernel.dk>
    Acked-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2ec2b12a45009e1801ea7b60bc644628d4ddee2
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Thu Dec 17 00:24:35 2020 +0000

    io_uring: cancel reqs shouldn't kill overflow list
    
    [ Upstream commit cda286f0715c82f8117e166afd42cca068876dde ]
    
    io_uring_cancel_task_requests() doesn't imply that the ring is going
    away, it may continue to work well after that. The problem is that it
    sets ->cq_overflow_flushed effectively disabling the CQ overflow feature
    
    Split setting cq_overflow_flushed from flush, and do the first one only
    on exit. It's ok in terms of cancellations because there is a
    io_uring->in_idle check in __io_cqring_fill_event().
    
    It also fixes a race with setting ->cq_overflow_flushed in
    io_uring_cancel_task_requests, whuch's is not atomic and a part of a
    bitmask with other flags. Though, the only other flag that's not set
    during init is drain_next, so it's not as bad for sane architectures.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Fixes: 0f2122045b946 ("io_uring: don't rely on weak ->files references")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0fd45a9a97e0e46b9a590c957204434315a66c0
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Sun Dec 6 22:22:44 2020 +0000

    io_uring: fix racy IOPOLL flush overflow
    
    [ Upstream commit 634578f800652035debba3098d8ab0d21af7c7a5 ]
    
    It's not safe to call io_cqring_overflow_flush() for IOPOLL mode without
    hodling uring_lock, because it does synchronisation differently. Make
    sure we have it.
    
    As for io_ring_exit_work(), we don't even need it there because
    io_ring_ctx_wait_and_kill() already set force flag making all overflowed
    requests to be dropped.
    
    Cc: <stable@vger.kernel.org> # 5.5+
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b931ea024e4531c02607978a04c55b7f7f6f5c7d
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Dec 24 10:52:10 2020 -0300

    perf probe: Fix memory leak when synthesizing SDT probes
    
    [ Upstream commit 5149303fdfe5c67ddb51c911e23262f781cd75eb ]
    
    The argv_split() function must be paired with argv_free(), else we must
    keep a reference to the argv array received or do the freeing ourselves,
    in synthesize_sdt_probe_command() we were simply leaking that argv[]
    array.
    
    Fixes: 3b1f8311f6963cd1 ("perf probe: Add sdt probes arguments into the uprobe cmd string")
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Alexandre Truong <alexandre.truong@arm.com>
    Cc: Alexis Berlemont <alexis.berlemont@gmail.com>
    Cc: He Zhe <zhe.he@windriver.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: John Garry <john.garry@huawei.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20201224135139.GF477817@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ca9c391938780ec6142de45335caeb2acaf4923
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Dec 4 10:37:14 2020 +0100

    ARM: 9036/1: uncompress: Fix dbgadtb size parameter name
    
    [ Upstream commit 1ecec38547d415054fdb63a231234f44396b6d06 ]
    
    The dbgadtb macro is passed the size of the appended DTB, not the end
    address.
    
    Fixes: c03e41470e901123 ("ARM: 9010/1: uncompress: Print the location of appended DTB")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf7b8c112a93f4e3c2bf0323605275b11d764194
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Sat Dec 19 16:29:58 2020 +0100

    ARM: 9044/1: vfp: use undef hook for VFP support detection
    
    [ Upstream commit 3cce9d44321e460e7c88cdec4e4537a6e9ad7c0d ]
    
    Commit f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND
    exceptions taken in kernel mode") failed to take into account that there
    is in fact a case where we relied on this code path: during boot, the
    VFP detection code issues a read of FPSID, which will trigger an undef
    exception on cores that lack VFP support.
    
    So let's reinstate this logic using an undef hook which is registered
    only for the duration of the initcall to vpf_init(), and which sets
    VFP_arch to a non-zero value - as before - if no VFP support is present.
    
    Fixes: f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND ...")
    Reported-by: "kernelci.org bot" <bot@kernelci.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f27cb2e13a10cc97321762670523d5545758554
Author: Cédric Le Goater <clg@kaod.org>
Date:   Mon Dec 21 08:41:54 2020 +0100

    powerpc/smp: Add __init to init_big_cores()
    
    [ Upstream commit 9014eab6a38c60fd185bc92ed60f46cf99a462ab ]
    
    It fixes this link warning:
    
    WARNING: modpost: vmlinux.o(.text.unlikely+0x2d98): Section mismatch in reference from the function init_big_cores.isra.0() to the function .init.text:init_thread_group_cache_map()
    The function init_big_cores.isra.0() references
    the function __init init_thread_group_cache_map().
    This is often because init_big_cores.isra.0 lacks a __init
    annotation or the annotation of init_thread_group_cache_map is wrong.
    
    Fixes: 425752c63b6f ("powerpc: Detect the presence of big-cores via "ibm, thread-groups"")
    Signed-off-by: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201221074154.403779-1-clg@kaod.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d670c4b43e3e9ee4c29601fa2eb40a92128f3c56
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Dec 15 14:29:06 2020 +1100

    powerpc/boot: Fix build of dts/fsl
    
    [ Upstream commit b36f835b636908e4122f2e17310b1dbc380a3b19 ]
    
    The lkp robot reported that some configs fail to build, for example
    mpc85xx_smp_defconfig, with:
    
      cc1: fatal error: opening output file arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
    
    This bisects to:
      cc8a51ca6f05 ("kbuild: always create directories of targets")
    
    Although that commit claims to be about in-tree builds, it somehow
    breaks out-of-tree builds. But presumably it's just exposing a latent
    bug in our Makefiles.
    
    We can fix it by adding to targets for dts/fsl in the same way that we
    do for dts.
    
    Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201215032906.473460-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87c0d2ab8a8e0bf7bf5d0abf0d695aeab6a8af3b
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 edc71c5fe563a99a8af1c5a1253d34a244bf9e13
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Dec 18 13:52:53 2020 +0100

    clk: vc5: Use "idt,voltage-microvolt" instead of "idt,voltage-microvolts"
    
    [ Upstream commit 4b003f5fcadfa2d0e087e907b0c65d023f6e29fb ]
    
    Commit 45c940184b501fc6 ("dt-bindings: clk: versaclock5: convert to
    yaml") accidentally changed "idt,voltage-microvolts" to
    "idt,voltage-microvolt" in the DT bindings, while the driver still used
    the former.
    
    Update the driver to match the bindings, as
    Documentation/devicetree/bindings/property-units.txt actually recommends
    using "microvolt".
    
    Fixes: 260249f929e81d3d ("clk: vc5: Enable addition output configurations of the Versaclock")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20201218125253.3815567-1-geert+renesas@glider.be
    Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdc8fe51a7063edd93f7f9db1832c404250bc666
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 75b84dafb943c0bd4533f76eb1fd6b9bc82aed6e
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 64f3af800c61d1bf45ceef9253ccb2334e714e05
Author: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date:   Wed Dec 2 13:58:15 2020 +0100

    clk: at91: sam9x60: remove atmel,osc-bypass support
    
    [ Upstream commit 01324f9e88b5cfc1f4c26eef66bdcb52596c9af8 ]
    
    The sam9x60 doesn't have the MOSCXTBY bit to enable the crystal oscillator
    bypass.
    
    Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver")
    Reported-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20201202125816.168618-1-alexandre.belloni@bootlin.com
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fcf9b5fa1c9aba86998550980de9e78958b1d85a
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Nov 19 17:43:07 2020 +0200

    clk: at91: sama7g5: fix compilation error
    
    [ Upstream commit 91274497c79170aaadc491d4ffe4de35495a060d ]
    
    pmc_data_allocate() has been changed. pmc_data_free() was removed.
    Adapt the code taking this into consideration. With this the programmable
    clocks were also saved in sama7g5_pmc so that they could be later
    referenced.
    
    Fixes: cb783bbbcf54 ("clk: at91: sama7g5: add clock support for sama7g5")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Tested-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/1605800597-16720-2-git-send-email-claudiu.beznea@microchip.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4713787c1f9c4a310d6333b0f3d35043449ce638
Author: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Date:   Wed Dec 2 11:35:18 2020 +0100

    clk: bcm: dvp: Add MODULE_DEVICE_TABLE()
    
    [ Upstream commit be439cc4c404f646a8ba090fa786d53c10926b12 ]
    
    Add MODULE_DEVICE_TABLE() so as to be able to use the driver as a
    module. More precisely, for the driver to be loaded automatically at
    boot.
    
    Fixes: 1bc95972715a ("clk: bcm: Add BCM2711 DVP driver")
    Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Link: https://lore.kernel.org/r/20201202103518.21889-1-nsaenzjulienne@suse.de
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1afb979cdceeff80066a57d4ceb521e24af79965
Author: Soheil Hassas Yeganeh <soheil@google.com>
Date:   Fri Dec 18 14:01:44 2020 -0800

    epoll: check for events when removing a timed out thread from the wait queue
    
    [ Upstream commit 289caf5d8f6c61c6d2b7fd752a7f483cd153f182 ]
    
    Patch series "simplify ep_poll".
    
    This patch series is a followup based on the suggestions and feedback by
    Linus:
    https://lkml.kernel.org/r/CAHk-=wizk=OxUyQPbO8MS41w2Pag1kniUV5WdD5qWL-gq1kjDA@mail.gmail.com
    
    The first patch in the series is a fix for the epoll race in presence of
    timeouts, so that it can be cleanly backported to all affected stable
    kernels.
    
    The rest of the patch series simplify the ep_poll() implementation.  Some
    of these simplifications result in minor performance enhancements as well.
    We have kept these changes under self tests and internal benchmarks for a
    few days, and there are minor (1-2%) performance enhancements as a result.
    
    This patch (of 8):
    
    After abc610e01c66 ("fs/epoll: avoid barrier after an epoll_wait(2)
    timeout"), we break out of the ep_poll loop upon timeout, without checking
    whether there is any new events available.  Prior to that patch-series we
    always called ep_events_available() after exiting the loop.
    
    This can cause races and missed wakeups.  For example, consider the
    following scenario reported by Guantao Liu:
    
    Suppose we have an eventfd added using EPOLLET to an epollfd.
    
    Thread 1: Sleeps for just below 5ms and then writes to an eventfd.
    Thread 2: Calls epoll_wait with a timeout of 5 ms. If it sees an
              event of the eventfd, it will write back on that fd.
    Thread 3: Calls epoll_wait with a negative timeout.
    
    Prior to abc610e01c66, it is guaranteed that Thread 3 will wake up either
    by Thread 1 or Thread 2.  After abc610e01c66, Thread 3 can be blocked
    indefinitely if Thread 2 sees a timeout right before the write to the
    eventfd by Thread 1.  Thread 2 will be woken up from
    schedule_hrtimeout_range and, with evail 0, it will not call
    ep_send_events().
    
    To fix this issue:
    1) Simplify the timed_out case as suggested by Linus.
    2) while holding the lock, recheck whether the thread was woken up
       after its time out has reached.
    
    Note that (2) is different from Linus' original suggestion: It do not set
    "eavail = ep_events_available(ep)" to avoid unnecessary contention (when
    there are too many timed-out threads and a small number of events), as
    well as races mentioned in the discussion thread.
    
    This is the first patch in the series so that the backport to stable
    releases is straightforward.
    
    Link: https://lkml.kernel.org/r/20201106231635.3528496-1-soheil.kdev@gmail.com
    Link: https://lkml.kernel.org/r/CAHk-=wizk=OxUyQPbO8MS41w2Pag1kniUV5WdD5qWL-gq1kjDA@mail.gmail.com
    Link: https://lkml.kernel.org/r/20201106231635.3528496-2-soheil.kdev@gmail.com
    Fixes: abc610e01c66 ("fs/epoll: avoid barrier after an epoll_wait(2) timeout")
    Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
    Tested-by: Guantao Liu <guantaol@google.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reported-by: Guantao Liu <guantaol@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Khazhismel Kumykov <khazhy@google.com>
    Reviewed-by: Davidlohr Bueso <dbueso@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7bc097f2908a94700073a677531c6d283b93f52
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:43:30 2020 +0800

    vhost scsi: fix error return code in vhost_scsi_set_endpoint()
    
    [ Upstream commit 2e1139d613c7fb0956e82f72a8281c0a475ad4f8 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 25b98b64e284 ("vhost scsi: alloc cmds per vq instead of session")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Link: https://lore.kernel.org/r/1607071411-33484-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbdfefc71ae555d64bfb29f0d8ee5b76167ce3f3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 4 17:23:36 2020 +0300

    virtio_ring: Fix two use after free bugs
    
    [ Upstream commit e152d8af4220a05c9797591609151d404866beaa ]
    
    The "vq" struct is added to the "vdev->vqs" list prematurely.  If we
    encounter an error later in the function then the "vq" is freed, but
    since it is still on the list that could lead to a use after free bug.
    
    Fixes: cbeedb72b97a ("virtio_ring: allocate desc state for split ring separately")
    Reported-by: Robert Buhren <robert.buhren@sect.tu-berlin.de>
    Reported-by: Felicitas Hetzelt <file@sect.tu-berlin.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/X8pGaG/zkI3jk8mk@mwanda
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78b35fd94cf91d782f6e65ed45f0355215f8fb94
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 4 17:23:16 2020 +0300

    virtio_net: Fix error code in probe()
    
    [ Upstream commit 411ea23a76526e6efed0b601abb603d3c981b333 ]
    
    Set a negative error code intead of returning success if the MTU has
    been changed to something invalid.
    
    Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range")
    Reported-by: Robert Buhren <robert.buhren@sect.tu-berlin.de>
    Reported-by: Felicitas Hetzelt <file@sect.tu-berlin.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/X8pGVJSeeCdII1Ys@mwanda
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bfffbd34bb0a2f8b93214df8eb7441ade58844f6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 4 17:23:00 2020 +0300

    virtio_ring: Cut and paste bugs in vring_create_virtqueue_packed()
    
    [ Upstream commit ae93d8ea0fa701e84ab9df0db9fb60ec6c80d7b8 ]
    
    There is a copy and paste bug in the error handling of this code and
    it uses "ring_dma_addr" three times instead of "device_event_dma_addr"
    and "driver_event_dma_addr".
    
    Fixes: 1ce9e6055fa0 (" virtio_ring: introduce packed ring support")
    Reported-by: Robert Buhren <robert.buhren@sect.tu-berlin.de>
    Reported-by: Felicitas Hetzelt <file@sect.tu-berlin.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/X8pGRJlEzyn+04u2@mwanda
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 069fedf3fba21a6406104222f0c680c613828890
Author: Eli Cohen <elic@nvidia.com>
Date:   Wed Dec 9 16:00:04 2020 +0200

    vdpa/mlx5: Use write memory barrier after updating CQ index
    
    [ Upstream commit 83ef73b27eb2363f44faf9c3ee28a3fe752cfd15 ]
    
    Make sure to put dma write memory barrier after updating CQ consumer
    index so the hardware knows that there are available CQE slots in the
    queue.
    
    Failure to do this can cause the update of the RX doorbell record to get
    updated before the CQ consumer index resulting in CQ overrun.
    
    Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Link: https://lore.kernel.org/r/20201209140004.15892-1-elic@nvidia.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ae314300079913277f78d4130d82038c5f20327
Author: Simon Horman <simon.horman@netronome.com>
Date:   Wed Dec 16 15:57:01 2020 +0100

    nfp: move indirect block cleanup to flower app stop callback
    
    [ Upstream commit 5b33afee93a1e7665a5ffae027fc66f9376f4ea7 ]
    
    The indirect block cleanup may cause control messages to be sent
    if offloaded flows are present. However, by the time the flower app
    cleanup callback is called txbufs are no longer available and attempts
    to send control messages result in a NULL-pointer dereference in
    nfp_ctrl_tx_one().
    
    This problem may be resolved by moving the indirect block cleanup
    to the stop callback, where txbufs are still available.
    
    As suggested by Jakub Kicinski and Louis Peens.
    
    Fixes: a1db217861f3 ("net: flow_offload: fix flow_indr_dev_unregister path")
    Signed-off-by: Simon Horman <simon.horman@netronome.com>
    Signed-off-by: Louis Peens <louis.peens@netronome.com>
    Link: https://lore.kernel.org/r/20201216145701.30005-1-simon.horman@netronome.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 466587ce57bf39afd13346d74766efa3139f0ad6
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 98c9b3aeff7d93f81fef79684bddbec37a73e9ef
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 03cbbd56485077159446245ffc04ed60ede8b5b2
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Fri Dec 4 00:08:36 2020 +0100

    tools build: Add missing libcap to test-all.bin target
    
    [ Upstream commit 09d59c2f3465fb01e65a0c96698697b026ea8e79 ]
    
    We're missing -lcap in test-all.bin target, so in case it's the only
    library missing (if more are missing test-all.bin fails anyway), we will
    falsely claim that we detected it and fail build, like:
    
      $ make
      ...
      Auto-detecting system features:
      ...                         dwarf: [ on  ]
      ...            dwarf_getlocations: [ on  ]
      ...                         glibc: [ on  ]
      ...                        libbfd: [ on  ]
      ...                libbfd-buildid: [ on  ]
      ...                        libcap: [ on  ]
      ...                        libelf: [ on  ]
      ...                       libnuma: [ on  ]
      ...        numa_num_possible_cpus: [ on  ]
      ...                       libperl: [ on  ]
      ...                     libpython: [ on  ]
      ...                     libcrypto: [ on  ]
      ...                     libunwind: [ on  ]
      ...            libdw-dwarf-unwind: [ on  ]
      ...                          zlib: [ on  ]
      ...                          lzma: [ on  ]
      ...                     get_cpuid: [ on  ]
      ...                           bpf: [ on  ]
      ...                        libaio: [ on  ]
      ...                       libzstd: [ on  ]
      ...        disassembler-four-args: [ on  ]
    
      ...
    
        CC       builtin-ftrace.o
    
      In file included from builtin-ftrace.c:29:
      util/cap.h:11:10: fatal error: sys/capability.h: No such file or directory
         11 | #include <sys/capability.h>
            |          ^~~~~~~~~~~~~~~~~~
      compilation terminated.
    
    Fixes: 74d5f3d06f707eb5 ("tools build: Add capability-related feature detection")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Igor Lubashev <ilubashe@akamai.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Michael Petlan <mpetlan@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lore.kernel.org/lkml/20201203230836.3751981-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a773dea1a9f2e55cc1c5d145d238630d7d69609a
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Fri Nov 6 13:00:23 2020 +0000

    io_uring: cancel only requests of current task
    
    [ Upstream commit df9923f96717d0aebb0a73adbcf6285fa79e38cb ]
    
    io_uring_cancel_files() cancels all request that match files regardless
    of task. There is no real need in that, cancel only requests of the
    specified task. That also handles SQPOLL case as it already changes task
    to it.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b148744090bef856269f4cd1856f3d16ac9f276
Author: Thierry Reding <thierry.reding@gmail.com>
Date:   Wed Dec 16 18:33:55 2020 +0100

    pwm: sun4i: Remove erroneous else branch
    
    [ Upstream commit 6eefb79d6f5bc4086bd02c76f1072dd4a8d9d9f6 ]
    
    Commit d3817a647059 ("pwm: sun4i: Remove redundant needs_delay") changed
    the logic of an else branch so that the PWM_EN and PWM_CLK_GATING bits
    are now cleared if the PWM is to be disabled, whereas previously the
    condition was always false, and hence the branch never got executed.
    
    This code is reported causing backlight issues on boards based on the
    Allwinner A20 SoC. Fix this by removing the else branch, which restores
    the behaviour prior to the offending commit.
    
    Note that the PWM_EN and PWM_CLK_GATING bits still get cleared later in
    sun4i_pwm_apply() if the PWM is to be disabled.
    
    Fixes: d3817a647059 ("pwm: sun4i: Remove redundant needs_delay")
    Reported-by: Taras Galchenko <tpgalchenko@gmail.com>
    Suggested-by: Taras Galchenko <tpgalchenko@gmail.com>
    Tested-by: Taras Galchenko <tpgalchenko@gmail.com>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c4544a216e34c3867429585e532bec540c99751
Author: Uwe Kleine-König <uwe@kleine-koenig.org>
Date:   Mon Dec 7 15:13:24 2020 +0100

    pwm: imx27: Fix overflow for bigger periods
    
    [ Upstream commit 1ce65396e6b2386b4fd54f87beff0647a772e1cd ]
    
    The second parameter of do_div is an u32 and NSEC_PER_SEC * prescale
    overflows this for bigger periods. Assuming the usual pwm input clk rate
    of 66 MHz this happens starting at requested period > 606060 ns.
    
    Splitting the division into two operations doesn't loose any precision.
    It doesn't need to be feared that c / NSEC_PER_SEC doesn't fit into the
    unsigned long variable "duty_cycles" because in this case the assignment
    above to period_cycles would already have been overflowing as
    period >= duty_cycle and then the calculation is moot anyhow.
    
    Fixes: aef1a3799b5c ("pwm: imx27: Fix rounding behavior")
    Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
    Tested-by: Johannes Pointner <johannes.pointner@br-automation.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cacf60c924521b99d9c0fafe63f128ddc191b6b
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 00fb97e2d7c8f05752699bce9ee1afe39523f949
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 91877b1fb0da8d429146702b0959c96a08c62cc5
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 43fc2d3a4a84f111dc6284d2ad2fce12525eeb23
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 45867d2ee459e1f648713e7496091ec1a0ca8908
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 a3c168082828b2c26d60813aa6da3371adb0fb9d
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Dec 15 12:57:20 2020 +1100

    powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug
    
    [ Upstream commit c1bea0a840ac75dca19bc6aa05575a33eb9fd058 ]
    
    Currently pmac32_defconfig with SMP=y doesn't build:
    
      arch/powerpc/platforms/powermac/smp.c:
      error: implicit declaration of function 'cleanup_cpu_mmu_context'
    
    It would be nice for consistency if all platforms clear mm_cpumask and
    flush TLBs on unplug, but the TLB invalidation bug described in commit
    01b0f0eae081 ("powerpc/64s: Trim offlined CPUs from mm_cpumasks") only
    applies to 64s and for now we only have the TLB flush code for that
    platform.
    
    So just add an empty version for 32-bit Book3S.
    
    Fixes: 01b0f0eae081 ("powerpc/64s: Trim offlined CPUs from mm_cpumasks")
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    [mpe: Change log based on comments from Nick]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0572a4aa7415b86708e25676200db8f4d332cf6b
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 0eecef0fec4aae5a80f37bcaabbe91d4717dad46
Author: Tobias Klauser <tklauser@distanz.ch>
Date:   Tue Dec 15 11:25:31 2020 +0100

    devlink: use _BITUL() macro instead of BIT() in the UAPI header
    
    [ Upstream commit 75f4d4544db9fa34e1f04174f27d9f8a387be37d ]
    
    The BIT() macro is not available for the UAPI headers. Moreover, it can
    be defined differently in user space headers. Thus, replace its usage
    with the _BITUL() macro which is already used in other macro definitions
    in <linux/devlink.h>.
    
    Fixes: dc64cc7c6310 ("devlink: Add devlink reload limit option")
    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Link: https://lore.kernel.org/r/20201215102531.16958-1-tklauser@distanz.ch
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 027112b2671b2bd5a64b0bd9299aecc6b9982134
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 de16a86c9d70e3f0f39b3ccfe7cd0d12126c8cc9
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Dec 16 17:17:45 2020 -0500

    NFS/pNFS: Fix a typo in ff_layout_resend_pnfs_read()
    
    [ Upstream commit 52104f274e2d7f134d34bab11cada8913d4544e2 ]
    
    Don't bump the index twice.
    
    Fixes: 563c53e73b8b ("NFS: Fix flexfiles read failover")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b75aea3e360f5e660612b6c25a54cb16c313b23
Author: Jack Wang <jinpu.wang@cloud.ionos.com>
Date:   Thu Dec 10 11:18:21 2020 +0100

    block/rnbd-clt: Fix possible memleak
    
    [ Upstream commit 46067844efdb8275ade705923120fc5391543b53 ]
    
    In error case, we do not free the memory for blk_symlink_name.
    
    Do it by free the memory in error case, and set to NULL
    afterwards.
    
    Also fix the condition in rnbd_clt_remove_dev_symlink.
    
    Fixes: 64e8a6ece1a5 ("block/rnbd-clt: Dynamically alloc buffer for pathname & blk_symlink_name")
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 996ce53a2af75bf7d59e2515b475b7c7cc45d2b5
Author: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Date:   Thu Dec 10 11:18:20 2020 +0100

    block/rnbd-clt: Get rid of warning regarding size argument in strlcpy
    
    [ Upstream commit e7508d48565060af5d89f10cb83c9359c8ae1310 ]
    
    The kernel test robot triggerred the following warning,
    
    >> drivers/block/rnbd/rnbd-clt.c:1397:42: warning: size argument in
    'strlcpy' call appears to be size of the source; expected the size of the
    destination [-Wstrlcpy-strlcat-size]
            strlcpy(dev->pathname, pathname, strlen(pathname) + 1);
                                                  ~~~~~~~^~~~~~~~~~~~~
    
    To get rid of the above warning, use a kstrdup as Bart suggested.
    
    Fixes: 64e8a6ece1a5 ("block/rnbd-clt: Dynamically alloc buffer for pathname & blk_symlink_name")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e50eea719ff0b916d219ed036c1d5b96cad6049c
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 8f995afae90a922ef6ac696720ef0f9807218819
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Dec 13 12:48:38 2020 +0100

    net: mscc: ocelot: Fix a resource leak in the error handling path of the probe function
    
    [ Upstream commit f87675b836b324d270fd52f1f5e6d6bb9f4bd1d5 ]
    
    In case of error after calling 'ocelot_init()', it must be undone by a
    corresponding 'ocelot_deinit()' call, as already done in the remove
    function.
    
    Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20201213114838.126922-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e7524c981cc6efc99973f653500f26044ddb109
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 5c0109f7794cd4e26e1837ebf34edecbe1efbc97
Author: Ioana Ciornei <ioana.ciornei@nxp.com>
Date:   Fri Dec 11 19:16:07 2020 +0200

    dpaa2-eth: fix the size of the mapped SGT buffer
    
    [ Upstream commit 54a57d1c449275ee727154ac106ec1accae012e3 ]
    
    This patch fixes an error condition triggered when the code path which
    transmits a S/G frame descriptor when the skb's headroom is not enough
    for DPAA2's needs.
    
    We are greated with a splat like the one below when a SGT structure is
    recycled and that is because even though a dma_unmap is performed on the
    Tx confirmation path, the unmap is not done with the proper size.
    
    [  714.464927] WARNING: CPU: 13 PID: 0 at drivers/iommu/io-pgtable-arm.c:281 __arm_lpae_map+0x2d4/0x30c
    (...)
    [  714.465343] Call trace:
    [  714.465348]  __arm_lpae_map+0x2d4/0x30c
    [  714.465353]  __arm_lpae_map+0x114/0x30c
    [  714.465357]  __arm_lpae_map+0x114/0x30c
    [  714.465362]  __arm_lpae_map+0x114/0x30c
    [  714.465366]  arm_lpae_map+0xf4/0x180
    [  714.465373]  arm_smmu_map+0x4c/0xc0
    [  714.465379]  __iommu_map+0x100/0x2bc
    [  714.465385]  iommu_map_atomic+0x20/0x30
    [  714.465391]  __iommu_dma_map+0xb0/0x110
    [  714.465397]  iommu_dma_map_page+0xb8/0x120
    [  714.465404]  dma_map_page_attrs+0x1a8/0x210
    [  714.465413]  __dpaa2_eth_tx+0x384/0xbd0 [fsl_dpaa2_eth]
    [  714.465421]  dpaa2_eth_tx+0x84/0x134 [fsl_dpaa2_eth]
    [  714.465427]  dev_hard_start_xmit+0x10c/0x2b0
    [  714.465433]  sch_direct_xmit+0x1a0/0x550
    (...)
    
    The dpaa2-eth driver uses an area of software annotations to transmit
    necessary information from the Tx path to the Tx confirmation one. This
    SWA structure has a different layout for each kind of frame that we are
    dealing with: linear, S/G or XDP.
    
    The commit referenced was incorrectly setting up the 'sgt_size' field
    for the S/G type of SWA even though we are dealing with a linear skb
    here.
    
    Fixes: d70446ee1f40 ("dpaa2-eth: send a scatter-gather FD instead of realloc-ing")
    Reported-by: Daniel Thompson <daniel.thompson@linaro.org>
    Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Link: https://lore.kernel.org/r/20201211171607.108034-1-ciorneiioana@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d50170ac3054f9b54c4f392fde938b4d7df90300
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Fri Dec 11 12:03:17 2020 +0100

    net: dsa: qca: ar9331: fix sleeping function called from invalid context bug
    
    [ Upstream commit 3e47495fc4de4122598dd51ae8527b09b8209646 ]
    
    With lockdep enabled, we will get following warning:
    
     ar9331_switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13)
     BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935
     in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 18, name: kworker/0:1
     INFO: lockdep is turned off.
     irq event stamp: 602
     hardirqs last  enabled at (601): [<8073fde0>] _raw_spin_unlock_irq+0x3c/0x80
     hardirqs last disabled at (602): [<8073a4f4>] __schedule+0x184/0x800
     softirqs last  enabled at (0): [<80080f60>] copy_process+0x578/0x14c8
     softirqs last disabled at (0): [<00000000>] 0x0
     CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 5.10.0-rc3-ar9331-00734-g7d644991df0c #31
     Workqueue: events deferred_probe_work_func
     Stack : 80980000 80980000 8089ef70 80890000 804b5414 80980000 00000002 80b53728
             00000000 800d1268 804b5414 ffffffde 00000017 800afe08 81943860 0f5bfc32
             00000000 00000000 8089ef70 819436c0 ffffffea 00000000 00000000 00000000
             8194390c 808e353c 0000000f 66657272 80980000 00000000 00000000 80890000
             804b5414 80980000 00000002 80b53728 00000000 00000000 00000000 80d40000
             ...
     Call Trace:
     [<80069ce0>] show_stack+0x9c/0x140
     [<800afe08>] ___might_sleep+0x220/0x244
     [<8073bfb0>] __mutex_lock+0x70/0x374
     [<8073c2e0>] mutex_lock_nested+0x2c/0x38
     [<804b5414>] regmap_update_bits_base+0x38/0x8c
     [<804ee584>] regmap_update_bits+0x1c/0x28
     [<804ee714>] ar9331_sw_unmask_irq+0x34/0x60
     [<800d91f0>] unmask_irq+0x48/0x70
     [<800d93d4>] irq_startup+0x114/0x11c
     [<800d65b4>] __setup_irq+0x4f4/0x6d0
     [<800d68a0>] request_threaded_irq+0x110/0x190
     [<804e3ef0>] phy_request_interrupt+0x4c/0xe4
     [<804df508>] phylink_bringup_phy+0x2c0/0x37c
     [<804df7bc>] phylink_of_phy_connect+0x118/0x130
     [<806c1a64>] dsa_slave_create+0x3d0/0x578
     [<806bc4ec>] dsa_register_switch+0x934/0xa20
     [<804eef98>] ar9331_sw_probe+0x34c/0x364
     [<804eb48c>] mdio_probe+0x44/0x70
     [<8049e3b4>] really_probe+0x30c/0x4f4
     [<8049ea10>] driver_probe_device+0x264/0x26c
     [<8049bc10>] bus_for_each_drv+0xb4/0xd8
     [<8049e684>] __device_attach+0xe8/0x18c
     [<8049ce58>] bus_probe_device+0x48/0xc4
     [<8049db70>] deferred_probe_work_func+0xdc/0xf8
     [<8009ff64>] process_one_work+0x2e4/0x4a0
     [<800a0770>] worker_thread+0x2a8/0x354
     [<800a774c>] kthread+0x16c/0x174
     [<8006306c>] ret_from_kernel_thread+0x14/0x1c
    
     ar9331_switch ethernet.1:10 lan1 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:02] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13)
     DSA: tree 0 setup
    
    To fix it, it is better to move access to MDIO register to the .irq_bus_sync_unlock
    call back.
    
    Fixes: ec6698c272de ("net: dsa: add support for Atheros AR9331 built-in switch")
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20201211110317.17061-1-o.rempel@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc79bf6c581cde11213a2119bcf7dc2c59cd22ec
Author: Björn Töpel <bjorn.topel@intel.com>
Date:   Fri Dec 11 15:57:12 2020 +0100

    i40e, xsk: clear the status bits for the next_to_use descriptor
    
    [ Upstream commit 64050b5b8706d304ba647591b06e1eddc55e8bd9 ]
    
    On the Rx side, the next_to_use index points to the next item in the
    HW ring to be refilled/allocated, and next_to_clean points to the next
    item to potentially be processed.
    
    When the HW Rx ring is fully refilled, i.e. no packets has been
    processed, the next_to_use will be next_to_clean - 1. When the ring is
    fully processed next_to_clean will be equal to next_to_use. The latter
    case is where a bug is triggered.
    
    If the next_to_use bits are not cleared, and the "fully processed"
    state is entered, a stale descriptor can be processed.
    
    The skb-path correctly clear the status bit for the next_to_use
    descriptor, but the AF_XDP zero-copy path did not do that.
    
    This change adds the status bits clearing of the next_to_use
    descriptor.
    
    Fixes: 3b4f0b66c2b3 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL")
    Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c3d87fa50a6c7bf68806b7406c165c5e18d3737
Author: Björn Töpel <bjorn.topel@intel.com>
Date:   Fri Dec 11 15:57:11 2020 +0100

    ice, xsk: clear the status bits for the next_to_use descriptor
    
    [ Upstream commit 8d14768a7972b92c73259f0c9c45b969d85e3a60 ]
    
    On the Rx side, the next_to_use index points to the next item in the
    HW ring to be refilled/allocated, and next_to_clean points to the next
    item to potentially be processed.
    
    When the HW Rx ring is fully refilled, i.e. no packets has been
    processed, the next_to_use will be next_to_clean - 1. When the ring is
    fully processed next_to_clean will be equal to next_to_use. The latter
    case is where a bug is triggered.
    
    If the next_to_use bits are not cleared, and the "fully processed"
    state is entered, a stale descriptor can be processed.
    
    The skb-path correctly clear the status bit for the next_to_use
    descriptor, but the AF_XDP zero-copy path did not do that.
    
    This change adds the status bits clearing of the next_to_use
    descriptor.
    
    Fixes: 2d4238f55697 ("ice: Add support for AF_XDP")
    Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f290c9bed144fb901816dae78d8c9d9d8e063946
Author: Sven Van Asbroeck <thesven73@gmail.com>
Date:   Tue Dec 15 11:19:54 2020 -0500

    lan743x: fix rx_napi_poll/interrupt ping-pong
    
    [ Upstream commit 57030a0b620f735bf557696e5ceb9f32c2b3bb8f ]
    
    Even if there is more rx data waiting on the chip, the rx napi poll fn
    will never run more than once - it will always read a few buffers, then
    bail out and re-arm interrupts. Which results in ping-pong between napi
    and interrupt.
    
    This defeats the purpose of napi, and is bad for performance.
    
    Fix by making the rx napi poll behave identically to other ethernet
    drivers:
    1. initialize rx napi polling with an arbitrary budget (64).
    2. in the polling fn, return full weight if rx queue is not depleted,
       this tells the napi core to "keep polling".
    3. update the rx tail ("ring the doorbell") once for every 8 processed
       rx ring buffers.
    
    Thanks to Jakub Kicinski, Eric Dumazet and Andrew Lunn for their expert
    opinions and suggestions.
    
    Tested with 20 seconds of full bandwidth receive (iperf3):
            rx irqs      softirqs(NET_RX)
            -----------------------------
    before  23827        33620
    after   129          4081
    
    Tested-by: Sven Van Asbroeck <thesven73@gmail.com> # lan7430
    Fixes: 23f0703c125be ("lan743x: Add main source files for new lan743x driver")
    Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com>
    Link: https://lore.kernel.org/r/20201215161954.5950-1-TheSven73@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 185640586280a76437303e668f66bffb0d112b28
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Sun Dec 13 18:05:56 2020 +0100

    s390/test_unwind: fix CALL_ON_STACK tests
    
    [ Upstream commit f22b9c219a798e1bf11110a3d2733d883e6da059 ]
    
    The CALL_ON_STACK tests use the no_dat stack to switch to a different
    stack for unwinding tests. If an interrupt or machine check happens
    while using that stack, and previously being on the async stack, the
    interrupt / machine check entry code (SWITCH_ASYNC) will assume that
    the previous context did not use the async stack and happily use the
    async stack again.
    
    This will lead to stack corruption of the previous context.
    
    To solve this disable both interrupts and machine checks before
    switching to the no_dat stack.
    
    Fixes: 7868249fbbc8 ("s390/test_unwind: add CALL_ON_STACK tests")
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0633094ec7ffd63f3f014e551570aaab2db4690c
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 b202ac9c7345a917ec429479dd64d46c7719343c
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Tue Dec 15 20:42:39 2020 -0800

    proc: fix lookup in /proc/net subdirectories after setns(2)
    
    [ Upstream commit c6c75deda81344c3a95d1d1f606d5cee109e5d54 ]
    
    Commit 1fde6f21d90f ("proc: fix /proc/net/* after setns(2)") only forced
    revalidation of regular files under /proc/net/
    
    However, /proc/net/ is unusual in the sense of /proc/net/foo handlers
    take netns pointer from parent directory which is old netns.
    
    Steps to reproduce:
    
            (void)open("/proc/net/sctp/snmp", O_RDONLY);
            unshare(CLONE_NEWNET);
    
            int fd = open("/proc/net/sctp/snmp", O_RDONLY);
            read(fd, &c, 1);
    
    Read will read wrong data from original netns.
    
    Patch forces lookup on every directory under /proc/net .
    
    Link: https://lkml.kernel.org/r/20201205160916.GA109739@localhost.localdomain
    Fixes: 1da4d377f943 ("proc: revalidate misc dentries")
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Reported-by: "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@nokia.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    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 bd3f4b6fd98ca7e77cca3c7299353ea787f3bf36
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Mon Dec 14 19:12:15 2020 -0800

    mm: don't wake kswapd prematurely when watermark boosting is disabled
    
    [ Upstream commit 597c892038e08098b17ccfe65afd9677e6979800 ]
    
    On 2-node NUMA hosts we see bursts of kswapd reclaim and subsequent
    pressure spikes and stalls from cache refaults while there is plenty of
    free memory in the system.
    
    Usually, kswapd is woken up when all eligible nodes in an allocation are
    full.  But the code related to watermark boosting can wake kswapd on one
    full node while the other one is mostly empty.  This may be justified to
    fight fragmentation, but is currently unconditionally done whether
    watermark boosting is occurring or not.
    
    In our case, many of our workloads' throughput scales with available
    memory, and pure utilization is a more tangible concern than trends
    around longer-term fragmentation.  As a result we generally disable
    watermark boosting.
    
    Wake kswapd only woken when watermark boosting is requested.
    
    Link: https://lkml.kernel.org/r/20201020175833.397286-1-hannes@cmpxchg.org
    Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs")
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b52a37fb348a9fadfe922652d0e627d53cb087f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Dec 14 19:12:11 2020 -0800

    hugetlb: fix an error code in hugetlb_reserve_pages()
    
    [ Upstream commit 7fc2513aa237e2ce239ab54d7b04d1d79b317110 ]
    
    Preserve the error code from region_add() instead of returning success.
    
    Link: https://lkml.kernel.org/r/X9NGZWnZl5/Mt99R@mwanda
    Fixes: 0db9d74ed884 ("hugetlb: disable region_add file_region coalescing")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: Mina Almasry <almasrymina@google.com>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7bf8ed8d177fa03b66eecfb0f8fe3ed52697991
Author: Oscar Salvador <osalvador@suse.de>
Date:   Mon Dec 14 19:11:48 2020 -0800

    mm,memory_failure: always pin the page in madvise_inject_error
    
    [ Upstream commit 1e8aaedb182d6ddffc894b832e4962629907b3e0 ]
    
    madvise_inject_error() uses get_user_pages_fast to translate the address
    we specified to a page.  After [1], we drop the extra reference count for
    memory_failure() path.  That commit says that memory_failure wanted to
    keep the pin in order to take the page out of circulation.
    
    The truth is that we need to keep the page pinned, otherwise the page
    might be re-used after the put_page() and we can end up messing with
    someone else's memory.
    
    E.g:
    
    CPU0
    process X                                       CPU1
     madvise_inject_error
      get_user_pages
       put_page
                                            page gets reclaimed
                                            process Y allocates the page
      memory_failure
       // We mess with process Y memory
    
    madvise() is meant to operate on a self address space, so messing with
    pages that do not belong to us seems the wrong thing to do.
    To avoid that, let us keep the page pinned for memory_failure as well.
    
    Pages for DAX mappings will release this extra refcount in
    memory_failure_dev_pagemap.
    
    [1] ("23e7b5c2e271: mm, madvise_inject_error:
          Let memory_failure() optionally take a page reference")
    
    Link: https://lkml.kernel.org/r/20201207094818.8518-1-osalvador@suse.de
    Fixes: 23e7b5c2e271 ("mm, madvise_inject_error: Let memory_failure() optionally take a page reference")
    Signed-off-by: Oscar Salvador <osalvador@suse.de>
    Suggested-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Dan Williams <dan.j.williams@intel.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 23713b480da1b86926dee3611dfab875b711b35a
Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
Date:   Mon Dec 14 19:09:06 2020 -0800

    mm/vmalloc.c: fix kasan shadow poisoning size
    
    [ Upstream commit c041098c690fe53cea5d20c62f128a4f7a5c19fe ]
    
    The size of vm area can be affected by the presence or not of the guard
    page.  In particular when VM_NO_GUARD is present, the actual accessible
    size has to be considered like the real size minus the guard page.
    
    Currently kasan does not keep into account this information during the
    poison operation and in particular tries to poison the guard page as well.
    
    This approach, even if incorrect, does not cause an issue because the tags
    for the guard page are written in the shadow memory.  With the future
    introduction of the Tag-Based KASAN, being the guard page inaccessible by
    nature, the write tag operation on this page triggers a fault.
    
    Fix kasan shadow poisoning size invoking get_vm_area_size() instead of
    accessing directly the field in the data structure to detect the correct
    value.
    
    Link: https://lkml.kernel.org/r/20201027160213.32904-1-vincenzo.frascino@arm.com
    Fixes: d98c9e83b5e7c ("kasan: fix crashes on access to memory mapped by vm_map_ram()")
    Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Marco Elver <elver@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a9d8b0789e300476da1f8a59ae79642a0e63687
Author: Waiman Long <longman@redhat.com>
Date:   Mon Dec 14 19:08:59 2020 -0800

    mm/vmalloc: Fix unlock order in s_stop()
    
    [ Upstream commit 0a7dd4e901b8a4ee040ba953900d1d7120b34ee5 ]
    
    When multiple locks are acquired, they should be released in reverse
    order. For s_start() and s_stop() in mm/vmalloc.c, that is not the
    case.
    
      s_start: mutex_lock(&vmap_purge_lock); spin_lock(&vmap_area_lock);
      s_stop : mutex_unlock(&vmap_purge_lock); spin_unlock(&vmap_area_lock);
    
    This unlock sequence, though allowed, is not optimal. If a waiter is
    present, mutex_unlock() will need to go through the slowpath of waking
    up the waiter with preemption disabled. Fix that by releasing the
    spinlock first before the mutex.
    
    Link: https://lkml.kernel.org/r/20201213180843.16938-1-longman@redhat.com
    Fixes: e36176be1c39 ("mm/vmalloc: rework vmap_area_lock")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbb7c059fd5ec7750fd4245842137d35c26cebcc
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Mon Dec 14 19:07:59 2020 -0800

    sparc: fix handling of page table constructor failure
    
    [ Upstream commit 06517c9a336f4c20f2064611bf4b1e7881a95fe1 ]
    
    The page has just been allocated, so its refcount is 1.  free_unref_page()
    is for use on pages which have a zero refcount.  Use __free_page() like
    the other implementations of pte_alloc_one().
    
    Link: https://lkml.kernel.org/r/20201125034655.27687-1-willy@infradead.org
    Fixes: 1ae9ae5f7df7 ("sparc: handle pgtable_page_ctor() fail")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: David Miller <davem@davemloft.net>
    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 dd156e3fcabff9ac2f102ae92f9b2f5dd8525e4d
Author: Shakeel Butt <shakeelb@google.com>
Date:   Mon Dec 14 19:06:39 2020 -0800

    mm/rmap: always do TTU_IGNORE_ACCESS
    
    [ Upstream commit 013339df116c2ee0d796dd8bfb8f293a2030c063 ]
    
    Since commit 369ea8242c0f ("mm/rmap: update to new mmu_notifier semantic
    v2"), the code to check the secondary MMU's page table access bit is
    broken for !(TTU_IGNORE_ACCESS) because the page is unmapped from the
    secondary MMU's page table before the check.  More specifically for those
    secondary MMUs which unmap the memory in
    mmu_notifier_invalidate_range_start() like kvm.
    
    However memory reclaim is the only user of !(TTU_IGNORE_ACCESS) or the
    absence of TTU_IGNORE_ACCESS and it explicitly performs the page table
    access check before trying to unmap the page.  So, at worst the reclaim
    will miss accesses in a very short window if we remove page table access
    check in unmapping code.
    
    There is an unintented consequence of !(TTU_IGNORE_ACCESS) for the memcg
    reclaim.  From memcg reclaim the page_referenced() only account the
    accesses from the processes which are in the same memcg of the target page
    but the unmapping code is considering accesses from all the processes, so,
    decreasing the effectiveness of memcg reclaim.
    
    The simplest solution is to always assume TTU_IGNORE_ACCESS in unmapping
    code.
    
    Link: https://lkml.kernel.org/r/20201104231928.1494083-1-shakeelb@google.com
    Fixes: 369ea8242c0f ("mm/rmap: update to new mmu_notifier semantic v2")
    Signed-off-by: Shakeel Butt <shakeelb@google.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Dan Williams <dan.j.williams@intel.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 6d48fff6d350ba69079cab6c71e9177a42b10215
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Mon Dec 14 19:06:35 2020 -0800

    mm: memcg/slab: fix use after free in obj_cgroup_charge
    
    [ Upstream commit eefbfa7fd678805b38a46293e78543f98f353d3e ]
    
    The rcu_read_lock/unlock only can guarantee that the memcg will not be
    freed, but it cannot guarantee the success of css_get to memcg.
    
    If the whole process of a cgroup offlining is completed between reading a
    objcg->memcg pointer and bumping the css reference on another CPU, and
    there are exactly 0 external references to this memory cgroup (how we get
    to the obj_cgroup_charge() then?), css_get() can change the ref counter
    from 0 back to 1.
    
    Link: https://lkml.kernel.org/r/20201028035013.99711-2-songmuchun@bytedance.com
    Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Acked-by: Roman Gushchin <guro@fb.com>
    Reviewed-by: Shakeel Butt <shakeelb@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Yafang Shao <laoar.shao@gmail.com>
    Cc: Chris Down <chris@chrisdown.name>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02314d05e8a01449dc0418d9b47b24c253b20826
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Mon Dec 14 19:06:31 2020 -0800

    mm: memcg/slab: fix return of child memcg objcg for root memcg
    
    [ Upstream commit 2f7659a314736b32b66273dbf91c19874a052fde ]
    
    Consider the following memcg hierarchy.
    
                        root
                       /    \
                      A      B
    
    If we failed to get the reference on objcg of memcg A, the
    get_obj_cgroup_from_current can return the wrong objcg for the root
    memcg.
    
    Link: https://lkml.kernel.org/r/20201029164429.58703-1-songmuchun@bytedance.com
    Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Acked-by: Roman Gushchin <guro@fb.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Yafang Shao <laoar.shao@gmail.com>
    Cc: Chris Down <chris@chrisdown.name>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Eugene Syromiatnikov <esyr@redhat.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Adrian Reber <areber@redhat.com>
    Cc: Marco Elver <elver@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfde6c1810c96a133dc7ae738294cc99dd97be4f
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Dec 14 19:05:51 2020 -0800

    mm/gup: combine put_compound_head() and unpin_user_page()
    
    [ Upstream commit 4509b42c38963f495b49aa50209c34337286ecbe ]
    
    These functions accomplish the same thing but have different
    implementations.
    
    unpin_user_page() has a bug where it calls mod_node_page_state() after
    calling put_page() which creates a risk that the page could have been
    hot-uplugged from the system.
    
    Fix this by using put_compound_head() as the only implementation.
    
    __unpin_devmap_managed_user_page() and related can be deleted as well in
    favour of the simpler, but slower, version in put_compound_head() that has
    an extra atomic page_ref_sub, but always calls put_page() which internally
    contains the special devmap code.
    
    Move put_compound_head() to be directly after try_grab_compound_head() so
    people can find it in future.
    
    Link: https://lkml.kernel.org/r/0-v1-6730d4ee0d32+40e6-gup_combine_put_jgg@nvidia.com
    Fixes: 1970dc6f5226 ("mm/gup: /proc/vmstat: pin_user_pages (FOLL_PIN) reporting")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    CC: Joao Martins <joao.m.martins@oracle.com>
    CC: Jonathan Corbet <corbet@lwn.net>
    CC: Dan Williams <dan.j.williams@intel.com>
    CC: Dave Chinner <david@fromorbit.com>
    CC: Christoph Hellwig <hch@infradead.org>
    CC: Jane Chu <jane.chu@oracle.com>
    CC: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    CC: Michal Hocko <mhocko@suse.com>
    CC: Mike Kravetz <mike.kravetz@oracle.com>
    CC: Shuah Khan <shuah@kernel.org>
    CC: Muchun Song <songmuchun@bytedance.com>
    CC: Vlastimil Babka <vbabka@suse.cz>
    CC: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 537946556cc971c9f4405cd76c2434fb78b0e992
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Dec 14 19:05:44 2020 -0800

    mm/gup: prevent gup_fast from racing with COW during fork
    
    [ Upstream commit 57efa1fe5957694fa541c9062de0a127f0b9acb0 ]
    
    Since commit 70e806e4e645 ("mm: Do early cow for pinned pages during
    fork() for ptes") pages under a FOLL_PIN will not be write protected
    during COW for fork.  This means that pages returned from
    pin_user_pages(FOLL_WRITE) should not become write protected while the pin
    is active.
    
    However, there is a small race where get_user_pages_fast(FOLL_PIN) can
    establish a FOLL_PIN at the same time copy_present_page() is write
    protecting it:
    
            CPU 0                             CPU 1
       get_user_pages_fast()
        internal_get_user_pages_fast()
                                           copy_page_range()
                                             pte_alloc_map_lock()
                                               copy_present_page()
                                                 atomic_read(has_pinned) == 0
                                                 page_maybe_dma_pinned() == false
         atomic_set(has_pinned, 1);
         gup_pgd_range()
          gup_pte_range()
           pte_t pte = gup_get_pte(ptep)
           pte_access_permitted(pte)
           try_grab_compound_head()
                                                 pte = pte_wrprotect(pte)
                                                 set_pte_at();
                                             pte_unmap_unlock()
          // GUP now returns with a write protected page
    
    The first attempt to resolve this by using the write protect caused
    problems (and was missing a barrrier), see commit f3c64eda3e50 ("mm: avoid
    early COW write protect games during fork()")
    
    Instead wrap copy_p4d_range() with the write side of a seqcount and check
    the read side around gup_pgd_range().  If there is a collision then
    get_user_pages_fast() fails and falls back to slow GUP.
    
    Slow GUP is safe against this race because copy_page_range() is only
    called while holding the exclusive side of the mmap_lock on the src
    mm_struct.
    
    [akpm@linux-foundation.org: coding style fixes]
      Link: https://lore.kernel.org/r/CAHk-=wi=iCnYCARbPGjkVJu9eyYeZ13N64tZYLdOB8CP5Q_PLw@mail.gmail.com
    
    Link: https://lkml.kernel.org/r/2-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com
    Fixes: f3c64eda3e50 ("mm: avoid early COW write protect games during fork()")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Acked-by: "Ahmed S. Darwish" <a.darwish@linutronix.de>  [seqcount_t parts]
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Kirill Shutemov <kirill@shutemov.name>
    Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
    Cc: Leon Romanovsky <leonro@nvidia.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcb0f647c1fae9496e6ce499618a8da003c56088
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Dec 14 19:05:41 2020 -0800

    mm/gup: reorganize internal_get_user_pages_fast()
    
    [ Upstream commit c28b1fc70390df32e29991eedd52bd86e7aba080 ]
    
    Patch series "Add a seqcount between gup_fast and copy_page_range()", v4.
    
    As discussed and suggested by Linus use a seqcount to close the small race
    between gup_fast and copy_page_range().
    
    Ahmed confirms that raw_write_seqcount_begin() is the correct API to use
    in this case and it doesn't trigger any lockdeps.
    
    I was able to test it using two threads, one forking and the other using
    ibv_reg_mr() to trigger GUP fast.  Modifying copy_page_range() to sleep
    made the window large enough to reliably hit to test the logic.
    
    This patch (of 2):
    
    The next patch in this series makes the lockless flow a little more
    complex, so move the entire block into a new function and remove a level
    of indention.  Tidy a bit of cruft:
    
     - addr is always the same as start, so use start
    
     - Use the modern check_add_overflow() for computing end = start + len
    
     - nr_pinned/pages << PAGE_SHIFT needs the LHS to be unsigned long to
       avoid shift overflow, make the variables unsigned long to avoid coding
       casts in both places. nr_pinned was missing its cast
    
     - The handling of ret and nr_pinned can be streamlined a bit
    
    No functional change.
    
    Link: https://lkml.kernel.org/r/0-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com
    Link: https://lkml.kernel.org/r/1-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c51e3679ebb532ad05483738ead6eb0a59c985a0
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Dec 14 11:00:47 2020 -0500

    drm/amdgpu: fix regression in vbios reservation handling on headless
    
    [ Upstream commit 7eded018bfeccb365963bb51be731a9f99aeea59 ]
    
    We need to move the check under the non-headless case, otherwise
    we always reserve the VGA save size.
    
    Fixes: 157fe68d74c2ad ("drm/amdgpu: fix size calculation with stolen vga memory")
    Reviewed-by: Guchun Chen <guchun.chen@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33e8ef090befe0e1177183ef2d0a5c16abbf3495
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Thu Nov 19 20:54:11 2020 +0530

    perf test: Fix metric parsing test
    
    [ Upstream commit b2ce5dbc15819ea4bef47dbd368239cb1e965158 ]
    
    Commit e1c92a7fbbc5 ("perf tests: Add another metric parsing test") add
    another test for metric parsing. The test goes through all metrics
    compiled for arch within pmu events and try to parse them.
    
    Right now this test is failing in powerpc machine.
    
    Result in power9 platform:
    
      [command]# ./perf test 10
      10: PMU events                                                      :
      10.1: PMU event table sanity                                        : Ok
      10.2: PMU event map aliases                                         : Ok
      10.3: Parsing of PMU event table metrics                            : Skip (some metrics failed)
      10.4: Parsing of PMU event table metrics with fake PMUs             : FAILED!
    
    Issue is we are passing different runtime parameter value in
    "expr__find_other" and "expr__parse" function which is called from
    function `metric_parse_fake`.  And because of this parsing of hv-24x7
    metrics is failing.
    
      [command]# ./perf test 10 -vv
      .....
      hv_24x7/pm_mcs01_128b_rd_disp_port01,chip=1/ not found
      expr__parse failed
      test child finished with -1
      ---- end ----
      PMU events subtest 4: FAILED!
    
    This patch fix this issue and change runtime parameter value to '0' in
    expr__parse function.
    
    Result in power9 platform after this patch:
    
      [command]# ./perf test 10
      10: PMU events                                                      :
      10.1: PMU event table sanity                                        : Ok
      10.2: PMU event map aliases                                         : Ok
      10.3: Parsing of PMU event table metrics                            : Skip (some metrics failed)
      10.4: Parsing of PMU event table metrics with fake PMUs             : Ok
    
    Fixes: e1c92a7fbbc5 ("perf tests: Add another metric parsing test")
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Acked-by: Ian Rogers <irogers@google.com>
    Acked-by: Jiri Olsa <jolsa@redhat.com>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Link: http://lore.kernel.org/lkml/20201119152411.46041-1-kjain@linux.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 280f29c6bae156b9f13c3a3a3eb7de8b3df0c8ed
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 34169b582aa9ed98cd48ec543b8f1b1b72b67e52
Author: Madhavan Srinivasan <maddy@linux.ibm.com>
Date:   Tue Dec 15 03:56:18 2020 -0500

    powerpc/perf: Fix Threshold Event Counter Multiplier width for P10
    
    [ Upstream commit ef0e3b650f8ddc54bb70868852f50642ee3ae765 ]
    
    Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
    Control Register A (MMCRA). This field along with Threshold Event
    Counter Exponent (TECE) is used to get threshould counter value.
    In Power10, this is a 8bit field, so patch fixes the
    current code to modify the MMCRA[TECM] extraction macro to
    handle this change. ISA v3.1 says this is a 7 bit field but
    POWER10 it's actually 8 bits which will hopefully be fixed
    in ISA v3.1 update.
    
    Fixes: 170a315f41c6 ("powerpc/perf: Support to export MMCRA[TEC*] field to userspace")
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    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/1608022578-1532-1-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6fba53d44e8fb3247f814caf707668445511bdc
Author: Guido Günther <agx@sigxcpu.org>
Date:   Tue Dec 15 09:23:38 2020 +0100

    drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge
    
    [ Upstream commit ee46d16d2e40bebc2aa790fd7b6a056466ff895c ]
    
    It can take multiple iterations until all components for an attached DSI
    bridge are up leading to several:
    
    [    3.796425] mxsfb 30320000.lcd-controller: Cannot connect bridge: -517
    [    3.816952] mxsfb 30320000.lcd-controller: [drm:mxsfb_probe [mxsfb]] *ERROR* failed to attach bridge: -517
    
    Silence this by checking for -EPROBE_DEFER and using dev_err_probe() so
    we set a deferred reason in case a dependency fails to probe (which
    quickly happens on small config/DT changes due to the rather long probe
    chain which can include bridges, phys, panels, backights, leds, etc.).
    
    This also removes the only DRM_DEV_ERROR() usage, the rest of the driver
    uses dev_err().
    
    Signed-off-by: Guido Günther <agx@sigxcpu.org>
    Fixes: c42001e357f7 ("drm: mxsfb: Use drm_panel_bridge")
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/d5761eb871adde5464ba112b89d966568bc2ff6c.1608020391.git.agx@sigxcpu.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 582e1021fb68aabe386489440f4153a0ff94090f
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 04ca5e7fa40d0a82d08d85a282f7b6df975e6989
Author: Leon Romanovsky <leon@kernel.org>
Date:   Sun Dec 13 15:29:39 2020 +0200

    RDMA/cma: Don't overwrite sgid_attr after device is released
    
    [ Upstream commit e246b7c035d74abfb3507fa10082d0c42cc016c3 ]
    
    As part of the cma_dev release, that pointer will be set to NULL.  In case
    it happens in rdma_bind_addr() (part of an error flow), the next call to
    addr_handler() will have a call to cma_acquire_dev_by_src_ip() which will
    overwrite sgid_attr without releasing it.
    
      WARNING: CPU: 2 PID: 108 at drivers/infiniband/core/cma.c:606 cma_bind_sgid_attr drivers/infiniband/core/cma.c:606 [inline]
      WARNING: CPU: 2 PID: 108 at drivers/infiniband/core/cma.c:606 cma_acquire_dev_by_src_ip+0x470/0x4b0 drivers/infiniband/core/cma.c:649
      CPU: 2 PID: 108 Comm: kworker/u8:1 Not tainted 5.10.0-rc6+ #257
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      Workqueue: ib_addr process_one_req
      RIP: 0010:cma_bind_sgid_attr drivers/infiniband/core/cma.c:606 [inline]
      RIP: 0010:cma_acquire_dev_by_src_ip+0x470/0x4b0 drivers/infiniband/core/cma.c:649
      Code: 66 d9 4a ff 4d 8b 6e 10 49 8d bd 1c 08 00 00 e8 b6 d6 4a ff 45 0f b6 bd 1c 08 00 00 41 83 e7 01 e9 49 fd ff ff e8 90 c5 29 ff <0f> 0b e9 80 fe ff ff e8 84 c5 29 ff 4c 89 f7 e8 2c d9 4a ff 4d 8b
      RSP: 0018:ffff8881047c7b40 EFLAGS: 00010293
      RAX: ffff888104789c80 RBX: 0000000000000001 RCX: ffffffff820b8ef8
      RDX: 0000000000000000 RSI: ffffffff820b9080 RDI: ffff88810cd4c998
      RBP: ffff8881047c7c08 R08: ffff888104789c80 R09: ffffed10209f4036
      R10: ffff888104fa01ab R11: ffffed10209f4035 R12: ffff88810cd4c800
      R13: ffff888105750e28 R14: ffff888108f0a100 R15: ffff88810cd4c998
      FS:  0000000000000000(0000) GS:ffff888119c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 0000000104e60005 CR4: 0000000000370ea0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       addr_handler+0x266/0x350 drivers/infiniband/core/cma.c:3190
       process_one_req+0xa3/0x300 drivers/infiniband/core/addr.c:645
       process_one_work+0x54c/0x930 kernel/workqueue.c:2272
       worker_thread+0x82/0x830 kernel/workqueue.c:2418
       kthread+0x1ca/0x220 kernel/kthread.c:292
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
    
    Fixes: ff11c6cd521f ("RDMA/cma: Introduce and use cma_acquire_dev_by_src_ip()")
    Link: https://lore.kernel.org/r/20201213132940.345554-5-leon@kernel.org
    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 d9a7b8fcd08325d11d54b38cad946983658cc0ae
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Sun Dec 13 15:29:36 2020 +0200

    RDMA/mlx5: Fix MR cache memory leak
    
    [ Upstream commit e89938902927a54abebccc9537991aca5237dfaf ]
    
    If the MR cache entry invalidation failed, then we detach this entry from
    the cache, therefore we must to free the memory as well.
    
    Allcation backtrace for the leaker:
    
        [<00000000d8e423b0>] alloc_cache_mr+0x23/0xc0 [mlx5_ib]
        [<000000001f21304c>] create_cache_mr+0x3f/0xf0 [mlx5_ib]
        [<000000009d6b45dc>] mlx5_ib_alloc_implicit_mr+0x41/0×210 [mlx5_ib]
        [<00000000879d0d68>] mlx5_ib_reg_user_mr+0x9e/0×6e0 [mlx5_ib]
        [<00000000be74bf89>] create_qp+0x2fc/0xf00 [ib_uverbs]
        [<000000001a532d22>] ib_uverbs_handler_UVERBS_METHOD_COUNTERS_READ+0x1d9/0×230 [ib_uverbs]
        [<0000000070f46001>] rdma_alloc_commit_uobject+0xb5/0×120 [ib_uverbs]
        [<000000006d8a0b38>] uverbs_alloc+0x2b/0xf0 [ib_uverbs]
        [<00000000075217c9>] ksysioctl+0x234/0×7d0
        [<00000000eb5c120b>] __x64_sys_ioctl+0x16/0×20
        [<00000000db135b48>] do_syscall_64+0x59/0×2e0
    
    Fixes: 1769c4c57548 ("RDMA/mlx5: Always remove MRs from the cache before destroying them")
    Link: https://lore.kernel.org/r/20201213132940.345554-2-leon@kernel.org
    Signed-off-by: Maor Gottlieb <maorg@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 c02c1df4fbd806bf1da545fe83adffedd64b6bdb
Author: Dan Aloni <dan@kernelim.com>
Date:   Sat Dec 5 11:28:35 2020 +0200

    sunrpc: fix xs_read_xdr_buf for partial pages receive
    
    [ Upstream commit ac9645c87380e39a8fa87a1b51721efcdea89dbf ]
    
    When receiving pages data, return value 'ret' when positive includes
    `buf->page_base`, so we should subtract that before it is used for
    changing `offset` and comparing against `want`.
    
    This was discovered on the very rare cases where the server returned a
    chunk of bytes that when added to the already received amount of bytes
    for the pages happened to match the current `recv.len`, for example
    on this case:
    
         buf->page_base : 258356
         actually received from socket: 1740
         ret : 260096
         want : 260096
    
    In this case neither of the two 'if ... goto out' trigger, and we
    continue to tail parsing.
    
    Worth to mention that the ensuing EMSGSIZE from the continued execution of
    `xs_read_xdr_buf` may be observed by an application due to 4 superfluous
    bytes being added to the pages data.
    
    Fixes: 277e4ab7d530 ("SUNRPC: Simplify TCP receive code by switching to using iterators")
    Signed-off-by: Dan Aloni <dan@kernelim.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d26a4edda515450cb65e69ea38a4ef8d0c63b53c
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 48628ec96d2ec572b0a44a8d078e7d80f2950ceb
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 4553c8cecbefdfe0133ed21c27e0e1c16b70f46d
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 0cc9725e4b25292b838cc7c3d16dc9520b184926
Author: Wang ShaoBo <bobo.shaobowang@huawei.com>
Date:   Tue Nov 24 14:33:20 2020 +0800

    ubifs: Fix error return code in ubifs_init_authentication()
    
    [ Upstream commit 3cded66330591cfd2554a3fd5edca8859ea365a2 ]
    
    Fix to return PTR_ERR() error code from the error handling case where
    ubifs_hash_get_desc() failed instead of 0 in ubifs_init_authentication(),
    as done elsewhere in this function.
    
    Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication support")
    Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9dc1b44d4f968f1d0df383b1f08a2c58076de9fa
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 17a3ee000334d192289038a7636cc6deeca5fb05
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 f71f75aceadb65969b432b7d2db70e696ad7166d
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 2d42e0354db18d2c7a3d7bb7793db04720c6d00b
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 118a8b7e4d575282e3b30d89391e48553bdbe6e3
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Nov 8 08:25:49 2020 -0800

    watchdog: armada_37xx: Add missing dependency on HAS_IOMEM
    
    [ Upstream commit 7f6f1dfb2dcbe5d2bfa213f2df5d74c147cd5954 ]
    
    The following kbuild warning is seen on a system without HAS_IOMEM.
    
    WARNING: unmet direct dependencies detected for MFD_SYSCON
      Depends on [n]: HAS_IOMEM [=n]
      Selected by [y]:
      - ARMADA_37XX_WATCHDOG [=y] && WATCHDOG [=y] && (ARCH_MVEBU || COMPILE_TEST
    
    This results in a subsequent compile error.
    
    drivers/watchdog/armada_37xx_wdt.o: in function `armada_37xx_wdt_probe':
    armada_37xx_wdt.c:(.text+0xdc): undefined reference to `devm_ioremap'
    
    Add the missing dependency.
    
    Reported-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
    Fixes: 54e3d9b518c8 ("watchdog: Add support for Armada 37xx CPU watchdog")
    Link: https://lore.kernel.org/r/20201108162550.27660-1-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 9721dd96e904074e13e9bab2039647038cf724f2
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri Dec 11 14:15:35 2020 -0800

    irqchip/qcom-pdc: Fix phantom irq when changing between rising/falling
    
    [ Upstream commit 2f5fbc4305d07725bfebaedb09e57271315691ef ]
    
    We have a problem if we use gpio-keys and configure wakeups such that
    we only want one edge to wake us up.  AKA:
      wakeup-event-action = <EV_ACT_DEASSERTED>;
      wakeup-source;
    
    Specifically we end up with a phantom interrupt that blocks suspend if
    the line was already high and we want wakeups on rising edges (AKA we
    want the GPIO to go low and then high again before we wake up).  The
    opposite is also problematic.
    
    Specifically, here's what's happening today:
    1. Normally, gpio-keys configures to look for both edges.  Due to the
       current workaround introduced in commit c3c0c2e18d94 ("pinctrl:
       qcom: Handle broken/missing PDC dual edge IRQs on sc7180"), if the
       line was high we'd configure for falling edges.
    2. At suspend time, we change to look for rising edges.
    3. After qcom_pdc_gic_set_type() runs, we get a phantom interrupt.
    
    We can solve this by just clearing the phantom interrupt.
    
    NOTE: it is possible that this could cause problems for a client with
    very specific needs, but there's not much we can do with this
    hardware.  As an example, let's say the interrupt signal is currently
    high and the client is looking for falling edges.  The client now
    changes to look for rising edges.  The client could possibly expect
    that if the line has a short pulse low (and back high) that it would
    always be detected.  Specifically no matter when the pulse happened,
    it should either have tripped the (old) falling edge trigger or the
    (new) rising edge trigger.  We will simply not trip it.  We could
    narrow down the race a bit by polling our parent before changing
    types, but no matter what we do there will still be a period of time
    where we can't tell the difference between a real transition (or more
    than one transition) and the phantom.
    
    Fixes: f55c73aef890 ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Tested-by: Maulik Shah <mkshah@codeaurora.org>
    Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20201211141514.v4.1.I2702919afc253e2a451bebc3b701b462b2d22344@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6003ff9ca7259a08ce938b51231ab36198a14bb0
Author: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Date:   Thu Dec 10 16:05:24 2020 +0200

    ath11k: Fix incorrect tlvs in scan start command
    
    [ Upstream commit f57ad6a9885e8399897daee3249cabccf9c972f8 ]
    
    Currently 6G specific tlvs have duplicate entries which is causing
    scan failures. Fix this by removing the duplicate entries of the same
    tlv. This also fixes out-of-bound memory writes caused due to
    adding tlvs when num_hint_bssid and num_hint_s_ssid are ZEROs.
    
    Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01386-QCAHKSWPL_SILICONZ-1
    
    Fixes: 74601ecfef6e ("ath11k: Add support for 6g scan hint")
    Reported-by: Carl Huang <cjhuang@codeaurora.org>
    Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1607609124-17250-7-git-send-email-kvalo@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d9284c18862480bcabb331088692b51c70dad2c
Author: Nikita Shubin <nikita.shubin@maquefel.me>
Date:   Thu Dec 10 10:05:14 2020 +0300

    gpiolib: irq hooks: fix recursion in gpiochip_irq_unmask
    
    [ Upstream commit 9d5522199505c761575c8ea31dcfd9a2a8d73614 ]
    
    irqchip shared with multiple gpiochips, leads to recursive call of
    gpiochip_irq_mask/gpiochip_irq_unmask which was assigned to
    rqchip->irq_mask/irqchip->irq_unmask, these happens becouse of
    only irqchip->irq_enable == gpiochip_irq_enable is checked.
    
    Let's add an additional check to make sure shared irqchip is detected
    even if irqchip->irq_enable wasn't defined.
    
    Fixes: a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable")
    Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
    Link: https://lore.kernel.org/r/20201210070514.13238-1-nikita.shubin@maquefel.me
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78d22dd9894293e5380b01e948670593ff408cff
Author: Weihang Li <liweihang@huawei.com>
Date:   Fri Dec 11 09:37:29 2020 +0800

    RDMA/hns: Do shift on traffic class when using RoCEv2
    
    [ Upstream commit 603bee935f38080a3674c763c50787751e387779 ]
    
    The high 6 bits of traffic class in GRH is DSCP (Differentiated Services
    Codepoint), the driver should shift it before the hardware gets it when
    using RoCEv2.
    
    Fixes: 606bf89e98ef ("RDMA/hns: Refactor for hns_roce_v2_modify_qp function")
    Fixes: fba429fcf9a5 ("RDMA/hns: Fix missing fields in address vector")
    Link: https://lore.kernel.org/r/1607650657-35992-4-git-send-email-liweihang@huawei.com
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44dd35a017301dc512c9e94765d11020dab7be90
Author: Wenpeng Liang <liangwenpeng@huawei.com>
Date:   Fri Dec 11 09:37:28 2020 +0800

    RDMA/hns: Normalization the judgment of some features
    
    [ Upstream commit 4ddeacf68a3dd05f346b63f4507e1032a15cc3cc ]
    
    Whether to enable the these features should better depend on the enable
    flags, not the value of related fields.
    
    Fixes: 5c1f167af112 ("RDMA/hns: Init SRQ table for hip08")
    Fixes: 3cb2c996c9dc ("RDMA/hns: Add support for SCCC in size of 64 Bytes")
    Link: https://lore.kernel.org/r/1607650657-35992-3-git-send-email-liweihang@huawei.com
    Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27f2d59a4a5cf87a06f32f021efe24ceae931fa6
Author: Wenpeng Liang <liangwenpeng@huawei.com>
Date:   Fri Dec 11 09:37:27 2020 +0800

    RDMA/hns: Limit the length of data copied between kernel and userspace
    
    [ Upstream commit 1c0ca9cd1741687f529498ddb899805fc2c51caa ]
    
    For ib_copy_from_user(), the length of udata may not be the same as that
    of cmd. For ib_copy_to_user(), the length of udata may not be the same as
    that of resp. So limit the length to prevent out-of-bounds read and write
    operations from ib_copy_from_user() and ib_copy_to_user().
    
    Fixes: de77503a5940 ("RDMA/hns: RDMA/hns: Assign rq head pointer when enable rq record db")
    Fixes: 633fb4d9fdaa ("RDMA/hns: Use structs to describe the uABI instead of opencoding")
    Fixes: ae85bf92effc ("RDMA/hns: Optimize qp param setup flow")
    Fixes: 6fd610c5733d ("RDMA/hns: Support 0 hop addressing for SRQ buffer")
    Fixes: 9d9d4ff78884 ("RDMA/hns: Update the kernel header file of hns")
    Link: https://lore.kernel.org/r/1607650657-35992-2-git-send-email-liweihang@huawei.com
    Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 567a8417b7fe154360a4124c2064b8ae14553895
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Tue Dec 8 11:04:21 2020 +0200

    dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt is not 0
    
    [ Upstream commit e2de925bbfe321ba0588c99f577c59386ab1f428 ]
    
    According to different sections of the TRM, the hchan_cnt of CAP3 includes
    the number of uchan in UDMA, thus the start offset of the normal channels
    are hchan_cnt.
    
    Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level information from hardware")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Link: https://lore.kernel.org/r/20201208090440.31792-2-peter.ujfalusi@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ce041fad2418efd45140c575e6e3d00ca87e5d7
Author: Lokesh Vutla <lokeshvutla@ti.com>
Date:   Mon Nov 2 17:36:31 2020 +0530

    irqchip/ti-sci-intr: Fix freeing of irqs
    
    [ Upstream commit fc6c7cd3878641fd43189f15697e7ad0871f5c1a ]
    
    ti_sci_intr_irq_domain_free() assumes that out_irq of intr is stored in
    data->chip_data and uses it for calling ti_sci irq_free() and then
    mark the out_irq as available resource. But ti_sci_intr_irq_domain_alloc()
    is storing p_hwirq(parent's hardware irq) which is translated from out_irq.
    This is causing resource leakage and eventually out_irq resources might
    be exhausted. Fix ti_sci_intr_irq_domain_alloc() by storing the out_irq
    in data->chip_data.
    
    Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR")
    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20201102120631.11165-1-lokeshvutla@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 629d6ba81ff29834cae9a4743b0fb2b9debad1e6
Author: Lokesh Vutla <lokeshvutla@ti.com>
Date:   Mon Nov 2 17:36:14 2020 +0530

    irqchip/ti-sci-inta: Fix printing of inta id on probe success
    
    [ Upstream commit b10d5fd489b0c67f59cbdd28d95f4bd9f76a62f2 ]
    
    On a successful probe, the driver tries to print a success message with
    INTA device id. It uses pdev->id for printing the id but id is stored in
    inta->ti_sci_id. Fix it by correcting the dev_info parameter.
    
    Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC")
    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20201102120614.11109-1-lokeshvutla@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d05c219375b7256bd0ebad6dd124f71aa5557fcb
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 ebfeeb104facda4f6d8f9d241e8f8cc342f52821
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 7fcf1c13802f26628d1a276f750fd1a9c7e08382
Author: Wen Gong <wgong@codeaurora.org>
Date:   Wed Dec 9 11:06:29 2020 +0800

    mac80211: fix a mistake check for rx_stats update
    
    [ Upstream commit f879ac8ed6c83ce05fcb53815a8ea83c5b6099a1 ]
    
    It should be !is_multicast_ether_addr() in ieee80211_rx_h_sta_process()
    for the rx_stats update, below commit remove the !, this patch is to
    change it back.
    
    It lead the rx rate "iw wlan0 station dump" become invalid for some
    scenario when IEEE80211_HW_USES_RSS is set.
    
    Fixes: 09a740ce352e ("mac80211: receive and process S1G beacons")
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Link: https://lore.kernel.org/r/1607483189-3891-1-git-send-email-wgong@codeaurora.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a889bda7d7c456a4e857ad17f71e39e5dc5c78e
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 7682cd97aa38edc811836be42d11b25f76ca328e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 4 00:20:04 2020 +0100

    crypto: atmel-i2c - select CONFIG_BITREVERSE
    
    [ Upstream commit d33a23b0532d5d1b5b700e8641661261e7dbef61 ]
    
    The bitreverse helper is almost always built into the kernel,
    but in a rare randconfig build it is possible to hit a case
    in which it is a loadable module while the atmel-i2c driver
    is built-in:
    
    arm-linux-gnueabi-ld: drivers/crypto/atmel-i2c.o: in function `atmel_i2c_checksum':
    atmel-i2c.c:(.text+0xa0): undefined reference to `byte_rev_table'
    
    Add one more 'select' statement to prevent this.
    
    Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df1c37a8786b307cd59fc0d72bdf8819dab095b2
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 9f5ab03f7fc57c70d410b5a774f18a90972184d1
Author: Hao Li <lihao2018.fnst@cn.fujitsu.com>
Date:   Tue Dec 8 10:08:43 2020 +0800

    fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode()
    
    [ Upstream commit 88149082bb8ef31b289673669e080ec6a00c2e59 ]
    
    If generic_drop_inode() returns true, it means iput_final() can evict
    this inode regardless of whether it is dirty or not. If we check
    I_DONTCACHE in generic_drop_inode(), any inode with this bit set will be
    evicted unconditionally. This is not the desired behavior because
    I_DONTCACHE only means the inode shouldn't be cached on the LRU list.
    As for whether we need to evict this inode, this is what
    generic_drop_inode() should do. This patch corrects the usage of
    I_DONTCACHE.
    
    This patch was proposed in [1].
    
    [1]: https://lore.kernel.org/linux-fsdevel/20200831003407.GE12096@dread.disaster.area/
    
    Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer")
    Signed-off-by: Hao Li <lihao2018.fnst@cn.fujitsu.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81ef603e86161b76087a9043e3d811146e3d0184
Author: Magnus Karlsson <magnus.karlsson@intel.com>
Date:   Thu Dec 10 17:34:07 2020 +0100

    samples/bpf: Fix possible hang in xdpsock with multiple threads
    
    [ Upstream commit 092fde0f863b72b67c4d6dc03844f5658fc00a35 ]
    
    Fix a possible hang in xdpsock that can occur when using multiple
    threads. In this case, one or more of the threads might get stuck in
    the while-loop in tx_only after the user has signaled the main thread
    to stop execution. In this case, no more Tx packets will be sent, so a
    thread might get stuck in the aforementioned while-loop. Fix this by
    introducing a test inside the while-loop to check if the benchmark has
    been terminated. If so, return from the function.
    
    Fixes: cd9e72b6f210 ("samples/bpf: xdpsock: Add option to specify batch size")
    Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20201210163407.22066-1-magnus.karlsson@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d0721cb10aa55027bd6c8075aab62ce08fe0c57
Author: Han Xu <han.xu@nxp.com>
Date:   Tue Dec 8 21:51:04 2020 -0600

    mtd: rawnand: gpmi: Fix the random DMA timeout issue
    
    [ Upstream commit 7671edeb193910482a9b0c22cd32176e7de7b2ed ]
    
    To get better performance, current gpmi driver collected and chained all
    small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and
    wait for complete at the end.
    
    But some random DMA timeout found in this new driver, with the help of
    ftrace, we found the root cause is as follows:
    
    Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6
    DMA transfers and the DMA chain triggered at the end. It waits for bch
    completion and check jiffies if it's timeout. The typical function graph
    shown below,
    
       63.216351 |   1)               |  gpmi_ecc_read_page() {
       63.216352 |   1)   0.750 us    |    gpmi_bch_layout_std();
       63.216354 |   1)               |    gpmi_nfc_exec_op() {
       63.216355 |   1)               |      gpmi_chain_command() {
       63.216356 |   1)               |        mxs_dma_prep_slave_sg() {
       63.216357 |   1)               |          /* mxs chan ccw idx: 0 */
       63.216358 |   1)   1.750 us    |        }
       63.216359 |   1)               |        mxs_dma_prep_slave_sg() {
       63.216360 |   1)               |          /* mxs chan ccw idx: 1 */
       63.216361 |   1)   2.000 us    |        }
       63.216361 |   1)   6.500 us    |      }
       63.216362 |   1)               |      gpmi_chain_command() {
       63.216363 |   1)               |        mxs_dma_prep_slave_sg() {
       63.216364 |   1)               |          /* mxs chan ccw idx: 2 */
       63.216365 |   1)   1.750 us    |        }
       63.216366 |   1)               |        mxs_dma_prep_slave_sg() {
       63.216367 |   1)               |          /* mxs chan ccw idx: 3 */
       63.216367 |   1)   1.750 us    |        }
       63.216368 |   1)   5.875 us    |      }
       63.216369 |   1)               |      /* gpmi_chain_wait_ready */
       63.216370 |   1)               |      mxs_dma_prep_slave_sg() {
       63.216372 |   1)               |        /* mxs chan ccw idx: 4 */
       63.216373 |   1)   3.000 us    |      }
       63.216374 |   1)               |      /* gpmi_chain_data_read */
       63.216376 |   1)               |      mxs_dma_prep_slave_sg() {
       63.216377 |   1)               |        /* mxs chan ccw idx: 5 */
       63.216378 |   1)   2.000 us    |      }
       63.216379 |   1)   1.125 us    |      mxs_dma_tx_submit();
       63.216381 |   1)   1.000 us    |      mxs_dma_enable_chan();
       63.216712 |   0)   2.625 us    |  mxs_dma_int_handler();
       63.216717 |   0)   4.250 us    |  bch_irq();
       63.216723 |   0)   1.250 us    |  mxs_dma_tasklet();
       63.216723 |   1)               |      /* jiffies left 250 */
       63.216725 |   1) ! 372.000 us  |    }
       63.216726 |   1)   2.625 us    |    gpmi_count_bitflips();
       63.216730 |   1) ! 379.125 us  |  }
    
    but it's not gurantee that bch irq handled always after dma irq handled,
    sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore,
    another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ
    handled, this messed up the next DMA chain and causes DMA timeout. Check
    the trace log when issue happened.
    
       63.218923 |   1)               |  gpmi_ecc_read_page() {
       63.218924 |   1)   0.625 us    |    gpmi_bch_layout_std();
       63.218926 |   1)               |    gpmi_nfc_exec_op() {
       63.218927 |   1)               |      gpmi_chain_command() {
       63.218928 |   1)               |        mxs_dma_prep_slave_sg() {
       63.218929 |   1)               |          /* mxs chan ccw idx: 0 */
       63.218929 |   1)   1.625 us    |        }
       63.218931 |   1)               |        mxs_dma_prep_slave_sg() {
       63.218931 |   1)               |          /* mxs chan ccw idx: 1 */
       63.218932 |   1)   1.750 us    |        }
       63.218933 |   1)   5.875 us    |      }
       63.218934 |   1)               |      gpmi_chain_command() {
       63.218934 |   1)               |        mxs_dma_prep_slave_sg() {
       63.218935 |   1)               |          /* mxs chan ccw idx: 2 */
       63.218936 |   1)   1.875 us    |        }
       63.218937 |   1)               |        mxs_dma_prep_slave_sg() {
       63.218938 |   1)               |          /* mxs chan ccw idx: 3 */
       63.218939 |   1)   1.625 us    |        }
       63.218939 |   1)   5.875 us    |      }
       63.218940 |   1)               |      /* gpmi_chain_wait_ready */
       63.218941 |   1)               |      mxs_dma_prep_slave_sg() {
       63.218942 |   1)               |        /* mxs chan ccw idx: 4 */
       63.218942 |   1)   1.625 us    |      }
       63.218943 |   1)               |      /* gpmi_chain_data_read */
       63.218944 |   1)               |      mxs_dma_prep_slave_sg() {
       63.218945 |   1)               |        /* mxs chan ccw idx: 5 */
       63.218947 |   1)   2.375 us    |      }
       63.218948 |   1)   0.625 us    |      mxs_dma_tx_submit();
       63.218949 |   1)   1.000 us    |      mxs_dma_enable_chan();
       63.219276 |   0)   5.125 us    |  bch_irq();                  <----
       63.219283 |   1)               |      /* jiffies left 250 */
       63.219285 |   1) ! 358.625 us  |    }
       63.219286 |   1)   2.750 us    |    gpmi_count_bitflips();
       63.219289 |   1) ! 366.000 us  |  }
       63.219290 |   1)               |  gpmi_ecc_read_page() {
       63.219291 |   1)   0.750 us    |    gpmi_bch_layout_std();
       63.219293 |   1)               |    gpmi_nfc_exec_op() {
       63.219294 |   1)               |      gpmi_chain_command() {
       63.219295 |   1)               |        mxs_dma_prep_slave_sg() {
       63.219295 |   0)   1.875 us    |  mxs_dma_int_handler();      <----
       63.219296 |   1)               |          /* mxs chan ccw idx: 6 */
       63.219297 |   1)   2.250 us    |        }
       63.219298 |   1)               |        mxs_dma_prep_slave_sg() {
       63.219298 |   0)   1.000 us    |  mxs_dma_tasklet();
       63.219299 |   1)               |          /* mxs chan ccw idx: 0 */
       63.219300 |   1)   1.625 us    |        }
       63.219300 |   1)   6.375 us    |      }
       63.219301 |   1)               |      gpmi_chain_command() {
       63.219302 |   1)               |        mxs_dma_prep_slave_sg() {
       63.219303 |   1)               |          /* mxs chan ccw idx: 1 */
       63.219304 |   1)   1.625 us    |        }
       63.219305 |   1)               |        mxs_dma_prep_slave_sg() {
       63.219306 |   1)               |          /* mxs chan ccw idx: 2 */
       63.219306 |   1)   1.875 us    |        }
       63.219307 |   1)   6.000 us    |      }
       63.219308 |   1)               |      /* gpmi_chain_wait_ready */
       63.219308 |   1)               |      mxs_dma_prep_slave_sg() {
       63.219309 |   1)               |        /* mxs chan ccw idx: 3 */
       63.219310 |   1)   2.000 us    |      }
       63.219311 |   1)               |      /* gpmi_chain_data_read */
       63.219312 |   1)               |      mxs_dma_prep_slave_sg() {
       63.219313 |   1)               |        /* mxs chan ccw idx: 4 */
       63.219314 |   1)   1.750 us    |      }
       63.219315 |   1)   0.625 us    |      mxs_dma_tx_submit();
       63.219316 |   1)   0.875 us    |      mxs_dma_enable_chan();
       64.224227 |   1)               |      /* jiffies left 0 */
    
    In the first gpmi_nfc_exec_op, bch_irq comes first and gpmi_nfc_exec_op
    exits, but DMA IRQ still not happened yet until the middle of following
    gpmi_nfc_exec_op, the first DMA transfer index get messed and DMA get
    timeout.
    
    To fix the issue, when there is bch ops in DMA chain, the
    gpmi_nfc_exec_op should wait for both completions rather than bch
    completion only.
    
    Fixes: ef347c0cfd61 ("mtd: rawnand: gpmi: Implement exec_op")
    Signed-off-by: Han Xu <han.xu@nxp.com>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20201209035104.22679-3-han.xu@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03c9406a3ef8c71ecc946b28a25c3915a2948fea
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Dec 3 11:39:48 2020 +0300

    mtd: rawnand: meson: Fix a resource leak in init
    
    [ Upstream commit ad8566d3555c4731e6b48823b92d3929b0394c14 ]
    
    Call clk_disable_unprepare(nfc->phase_rx) if the clk_set_rate() function
    fails to avoid a resource leak.
    
    Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/X8ikVCnUsfTpffFB@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a50f5a6393e4de7627c9c7c3f50976bdef68b7f9
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Sat Nov 7 19:05:52 2020 +0800

    mtd: rawnand: gpmi: fix reference count leak in gpmi ops
    
    [ Upstream commit 1b391c7f2e863985668d705f525af3ceb55bc800 ]
    
    pm_runtime_get_sync() will increment pm usage at first and it
    will resume the device later. If runtime of the device has
    error or device is in inaccessible state(or other error state),
    resume operation will fail. If we do not call put operation to
    decrease the reference, it will result in reference leak in
    the two functions(gpmi_init and gpmi_nfc_exec_op). Moreover,
    this device cannot enter the idle state and always stay busy or
    other non-idle state later. So we fixed it through adding
    pm_runtime_put_noidle.
    
    Fixes: 5bc6bb603b4d0 ("mtd: rawnand: gpmi: Fix suspend/resume problem")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Acked-by: Han Xu <han.xu@nxp.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20201107110552.1568742-1-zhangqilong3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0440989a08a5c71a7304da3dcb7d43de968cb721
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 be5c560996ac9ed1e3f3f1e03c8c090f39a71e8a
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Dec 10 10:22:38 2020 -0800

    clk: qcom: gcc-sc7180: Use floor ops for sdcc clks
    
    [ Upstream commit 6d37a8d192830267e6b10a6d57ae28d2e89097e7 ]
    
    I would repeat the same commit message that was in commit 5e4b7e82d497
    ("clk: qcom: gcc-sdm845: Use floor ops for sdcc clks") but it seems
    silly to do so when you could just go read that commit.
    
    NOTE: this is actually extra terrible because we're missing the 50 MHz
    rate in the table (see the next patch AKA ("clk: qcom: gcc-sc7180: Add
    50 MHz clock rate for SDC2")).  That means then when you run an older
    SD card it'll try to clock it at 100 MHz when it's only specced to run
    at 50 MHz max.  As you can probably guess that doesn't work super
    well.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Fixes: 17269568f726 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180")
    Link: https://lore.kernel.org/r/20201210102234.1.I096779f219625148900fc984dd0084ed1ba87c7f@changeid
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ca59ab95f9fc1b853602a8b51ccbde46c3e41ec
Author: Tzung-Bi Shih <tzungbi@google.com>
Date:   Thu Dec 3 23:59:14 2020 +0800

    remoteproc/mediatek: unprepare clk if scp_before_load fails
    
    [ Upstream commit 22c3df6f5574c8d401ea431c7ce24e7c5c5e7ef3 ]
    
    Fixes the error handling to unprepare clk if scp_before_load fails.
    
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP")
    Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
    Link: https://lore.kernel.org/r/20201203155914.3844426-1-tzungbi@google.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d909187e538b7b1603cf453f5d7240e9f36c293
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Tue Dec 8 09:54:20 2020 +0800

    remoteproc: qcom: Fix potential NULL dereference in adsp_init_mmio()
    
    [ Upstream commit c3d4e5b12672bbdf63f4cc933e3169bc6bbec8da ]
    
    platform_get_resource() may fail and in this case a NULL dereference
    will occur.
    
    Fix it to use devm_platform_ioremap_resource() instead of calling
    platform_get_resource() and devm_ioremap().
    
    This is detected by Coccinelle semantic patch.
    
    @@
    expression pdev, res, n, t, e, e1, e2;
    @@
    
    res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t,
    n);
    + if (!res)
    +   return -EINVAL;
    ... when != res == NULL
    e = devm_ioremap(e1, res->start, e2);
    
    Fixes: dc160e449122 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Link: https://lore.kernel.org/r/1607392460-20516-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fc6cdb1d67ef7ff68d861fbce745f3f2dc54673
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sat Sep 5 20:25:03 2020 +0800

    remoteproc: k3-dsp: Fix return value check in k3_dsp_rproc_of_get_memories()
    
    [ Upstream commit 6dfdf6e4e7096fead7755d47d91d72e896bb4804 ]
    
    In case of error, the function devm_ioremap_wc() returns NULL pointer
    not ERR_PTR(). The IS_ERR() test in the return value check should be
    replaced with NULL test.
    
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Fixes: 6edbe024ba17 ("remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Suman Anna <s-anna@ti.com>
    Link: https://lore.kernel.org/r/20200905122503.17352-1-yuehaibing@huawei.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1bf8c9f49adacb32584b1213b94a813ec565cf3
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 22:35:54 2020 +0800

    remoteproc: qcom: pas: fix error handling in adsp_pds_enable
    
    [ Upstream commit c0a6e5ee1ecfe4c3a5799cfd30820748eff5dfab ]
    
    If the pm_runtime_get_sync failed in adsp_pds_enable when
    loop (i), The unroll_pd_votes will start from (i - 1), and
    it will resulted in following problems:
    
      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) Have not reset pds[i] performance state.
    
    Then we fix it.
    
    Fixes: 17ee2fb4e8567 ("remoteproc: qcom: pas: Vote for active/proxy power domains")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201102143554.144707-1-zhangqilong3@huawei.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cce77d667f5586d1b3a92ce0cbefa1c3156e9c8b
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 22:35:34 2020 +0800

    remoteproc: qcom: fix reference leak in adsp_start
    
    [ Upstream commit aa37448f597c09844942da87d042fc6793f989c2 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in adsp_start, so we should fix it.
    
    Fixes: dc160e4491222 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201102143534.144484-1-zhangqilong3@huawei.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70ea4c7d1d39020cff13f8a3ca7404b8cce296fa
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 22:34:33 2020 +0800

    remoteproc: q6v5-mss: fix error handling in q6v5_pds_enable
    
    [ Upstream commit a24723050037303e4008b37f1f8dcc99c58901aa ]
    
    If the pm_runtime_get_sync failed in q6v5_pds_enable when
    loop (i), The unroll_pd_votes will start from (i - 1), and
    it will resulted in following problems:
    
      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) Have not reset pds[i] performance state.
    
    Then we fix it.
    
    Fixes: 4760a896be88e ("remoteproc: q6v5-mss: Vote for rpmh power domains")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201102143433.143996-1-zhangqilong3@huawei.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01e2c27b8a30e5fc2211d28fc9133d8eca37adc8
Author: Alexandre Courbot <acourbot@chromium.org>
Date:   Mon Nov 2 16:40:07 2020 +0900

    remoteproc/mtk_scp: surround DT device IDs with CONFIG_OF
    
    [ Upstream commit e59aef4edc45133ccb10b8e962cb74dcf1e3240b ]
    
    Now that this driver can be compiled with COMPILE_TEST, we have no
    guarantee that CONFIG_OF will also be defined. When that happens, a
    warning about mtk_scp_of_match being defined but unused will be reported
    so make sure this variable is only defined if of_match_ptr() actually
    uses it.
    
    Fixes: cbd2dca74926c0e4610c40923cc786b732c9e8ef remoteproc: scp: add COMPILE_TEST dependency
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
    Link: https://lore.kernel.org/r/20201102074007.299222-1-acourbot@chromium.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7fd58cc440bc870d550659104c0bfca96457f14
Author: Tzung-Bi Shih <tzungbi@google.com>
Date:   Thu Dec 10 13:41:09 2020 +0800

    remoteproc/mediatek: change MT8192 CFG register base
    
    [ Upstream commit 0a441514bc2b8a48ebe23c2dcb9feee6351d45b6 ]
    
    The correct MT8192 CFG register base is 0x20000 off.  Changes the
    registers accordingly.
    
    Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP")
    Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
    Link: https://lore.kernel.org/r/20201210054109.587795-1-tzungbi@google.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1cbcdec82c53a4a03d5d6db831a1c0228dfe1109
Author: Avihai Horon <avihaih@nvidia.com>
Date:   Tue Dec 8 09:35:45 2020 +0200

    RDMA/uverbs: Fix incorrect variable type
    
    [ Upstream commit e0da68994d16b46384cce7b86eb645f1ef7c51ef ]
    
    Fix incorrect type of max_entries in UVERBS_METHOD_QUERY_GID_TABLE -
    max_entries is of type size_t although it can take negative values.
    
    The following static check revealed it:
    
    drivers/infiniband/core/uverbs_std_types_device.c:338 ib_uverbs_handler_UVERBS_METHOD_QUERY_GID_TABLE() warn: 'max_entries' unsigned <= 0
    
    Fixes: 9f85cbe50aa0 ("RDMA/uverbs: Expose the new GID query API to user space")
    Link: https://lore.kernel.org/r/20201208073545.9723-4-leon@kernel.org
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Avihai Horon <avihaih@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 53e9a5a692f839780084ad81dbd461ec917f74f7
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Tue Dec 8 09:35:44 2020 +0200

    RDMA/core: Do not indicate device ready when device enablement fails
    
    [ Upstream commit 779e0bf47632c609c59f527f9711ecd3214dccb0 ]
    
    In procedure ib_register_device, procedure kobject_uevent is called
    (advertising that the device is ready for userspace usage) even when
    device_enable_and_get() returned an error.
    
    As a result, various RDMA modules attempted to register for the device
    even while the device driver was preparing to unregister the device.
    
    Fix this by advertising the device availability only after enabling the
    device succeeds.
    
    Fixes: e7a5b4aafd82 ("RDMA/device: Don't fire uevent before device is fully initialized")
    Link: https://lore.kernel.org/r/20201208073545.9723-3-leon@kernel.org
    Suggested-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    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 db71bc7ef3edd98299f83c7dba80b2cdba32de23
Author: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Date:   Thu Dec 10 19:44:45 2020 +0200

    ALSA: hda/hdmi: fix silent stream for first playback to DP
    
    [ Upstream commit b1a5039759cb7bfcb2157f28604dbda0bca58598 ]
    
    A problem exists in enabling silent stream when connection type is
    DisplayPort. Silent stream programming is completed when a new DP
    receiver is connected, but infoframe transmission does not actually
    start until PCM is opened for the first time. This can result in audible
    gap of multiple seconds. This only affects the first PCM open.
    
    Fix the issue by properly assigning a converter to the silent stream,
    and modifying the required stream ID programming sequence.
    
    This change only affects Intel display audio codecs.
    
    BugLink: https://github.com/thesofproject/linux/issues/2468
    Fixes: 951894cf30f4 ("ALSA: hda/hdmi: Add Intel silent stream support")
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20201210174445.3134104-1-kai.vehmanen@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bc1c2d4a7e8f9ee47c8bd1e92a2adf00ffceb12
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Tue Dec 8 09:54:32 2020 +0800

    slimbus: qcom: fix potential NULL dereference in qcom_slim_prg_slew()
    
    [ Upstream commit 428bb001143cf5bfb65aa4ae90d4ebc95f82d007 ]
    
    platform_get_resource_byname() may fail and in this case a NULL
    dereference will occur.
    
    Fix it to use devm_platform_ioremap_resource_byname() instead of calling
    platform_get_resource_byname() and devm_ioremap().
    
    This is detected by Coccinelle semantic patch.
    
    @@
    expression pdev, res, n, t, e, e1, e2;
    @@
    
    res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t,
    n);
    + if (!res)
    +   return -EINVAL;
    ... when != res == NULL
    e = devm_ioremap(e1, res->start, e2);
    
    Fixes: ad7fcbc308b0 ("slimbus: qcom: Add Qualcomm Slimbus controller driver")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Link: https://lore.kernel.org/r/1607392473-20610-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 2ae4b562d78f458798506030c1e29b7a09ce561a
Author: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Date:   Sun Oct 11 10:39:05 2020 +0530

    powerpc/sstep: Cover new VSX instructions under CONFIG_VSX
    
    [ Upstream commit 1817de2f141c718f1a0ae59927ec003e9b144349 ]
    
    Recently added Power10 prefixed VSX instruction are included
    unconditionally in the kernel. If they are executed on a
    machine without VSX support, it might create issues. Fix that.
    Also fix one mnemonics spelling mistake in comment.
    
    Fixes: 50b80a12e4cc ("powerpc sstep: Add support for prefixed load/stores")
    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201011050908.72173-3-ravi.bangoria@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf608cf329a3c6cd77ca02ae11870866fd04a20e
Author: Balamuruhan S <bala24@linux.ibm.com>
Date:   Sun Oct 11 10:39:04 2020 +0530

    powerpc/sstep: Emulate prefixed instructions only when CPU_FTR_ARCH_31 is set
    
    [ Upstream commit ef6879f8c8053cc3b493f400a06d452d7fb13650 ]
    
    Unconditional emulation of prefixed instructions will allow
    emulation of them on Power10 predecessors which might cause
    issues. Restrict that.
    
    Fixes: 3920742b92f5 ("powerpc sstep: Add support for prefixed fixed-point arithmetic")
    Fixes: 50b80a12e4cc ("powerpc sstep: Add support for prefixed load/stores")
    Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
    Reviewed-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201011050908.72173-2-ravi.bangoria@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62cd477bbdffb7bbd6c88c038a90289cdc27c606
Author: Sean Nyekjaer <sean@geanix.com>
Date:   Wed Dec 11 07:32:27 2019 +0100

    can: m_can: m_can_config_endisable(): remove double clearing of clock stop request bit
    
    [ Upstream commit c9f4cad6cdfe350ce2637e57f7f2aa7ff326bcc6 ]
    
    The CSR bit is already cleared when arriving here so remove this section of
    duplicate code.
    
    The registers set in m_can_config_endisable() is set to same exact values as
    before this patch.
    
    Signed-off-by: Sean Nyekjaer <sean@geanix.com>
    Acked-by: Sriram Dash <sriram.dash@samsung.com>
    Acked-by: Dan Murphy <dmurphy@ti.com>
    Link: https://lore.kernel.org/r/20191211063227.84259-1-sean@geanix.com
    Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework")
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23b70b31675cc766d83faf9b61d9c874875202d8
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Nov 9 16:26:14 2020 +0100

    clk: renesas: r8a779a0: Fix R and OSC clocks
    
    [ Upstream commit 14653942de7f63e21ece32e3901f09a248598a43 ]
    
    The R-Car V3U clock driver defines the R and OSC clocks using R-Car Gen3
    clock types.  However, The R-Car V3U clock driver does not use the R-Car
    Gen3 clock driver core, hence registering the R and OSC clocks fails:
    
        renesas-cpg-mssr e6150000.clock-controller: Failed to register core clock osc: -22
        renesas-cpg-mssr e6150000.clock-controller: Failed to register core clock r: -22
    
    Fix this by introducing clock definition macros specific to R-Car V3U.
    Note that rcar_r8a779a0_cpg_clk_register() already handled the related
    clock types.  Drop the now unneeded include of rcar-gen3-cpg.h.
    
    Fixes: 17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20201109152614.2465483-1-geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a60cb39186fb4dbf3d505fb9d5e9322cb7465b3d
Author: Huang Jianan <huangjianan@oppo.com>
Date:   Wed Dec 9 19:57:40 2020 +0800

    erofs: avoid using generic_block_bmap
    
    [ Upstream commit d8b3df8b1048405e73558b88cba2adf29490d468 ]
    
    Surprisingly, `block' in sector_t indicates the number of
    i_blkbits-sized blocks rather than sectors for bmap.
    
    In addition, considering buffer_head limits mapped size to 32-bits,
    should avoid using generic_block_bmap.
    
    Link: https://lore.kernel.org/r/20201209115740.18802-1-huangjianan@oppo.com
    Fixes: 9da681e017a3 ("staging: erofs: support bmap")
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Reviewed-by: Gao Xiang <hsiangkao@redhat.com>
    Signed-off-by: Huang Jianan <huangjianan@oppo.com>
    Signed-off-by: Guo Weichao <guoweichao@oppo.com>
    [ Gao Xiang: slightly update the commit message description. ]
    Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82d87b59df4c1d7eba71829d9da3f14e71295be6
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Dec 9 23:16:47 2020 +0200

    iwlwifi: mvm: hook up missing RX handlers
    
    [ Upstream commit 8a59d39033c35bb484f6bd91891db86ebe07fdc2 ]
    
    The RX handlers for probe response data and channel switch weren't
    hooked up properly, fix that.
    
    Fixes: 86e177d80ff7 ("iwlwifi: mvm: add NOA and CSA to a probe response")
    Fixes: d3a108a48dc6 ("iwlwifi: mvm: Support CSA countdown offloading")
    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.20201209231352.2d07dcee0d35.I07a61b5d734478db57d9434ff303e4c90bf6c32b@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31269e6ac076d56d5aa781470d02208ea5487dc2
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Dec 9 23:16:37 2020 +0200

    iwlwifi: dbg-tlv: fix old length in is_trig_data_contained()
    
    [ Upstream commit 58a1c9f9a9b6b9092ae10b84f6b571a06596e296 ]
    
    There's a bug in the lengths - the 'old length' needs to be calculated
    using the 'old' pointer, of course, likely a copy/paste mistake. Fix
    this.
    
    Reported-by: Daniel Gabay <daniel.gabay@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Fixes: cf29c5b66b9f ("iwlwifi: dbg_ini: implement time point handling")
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20201209231352.c0105ddffa74.I1ddb243053ff763c91b663748b6a593ecc3b5634@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b4f4a160b0cd5b6c35fd26c1e969c5326a2d86c
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Tue Dec 1 14:31:50 2020 +0800

    s390/cio: fix use-after-free in ccw_device_destroy_console
    
    [ Upstream commit 14d4c4fa46eeaa3922e8e1c4aa727eb0a1412804 ]
    
    Use of sch->dev reference after the put_device() call could trigger
    the use-after-free bugs.
    
    Fix this by simply adjusting the position of put_device.
    
    Fixes: 37db8985b211 ("s390/cio: add basic protected virtualization support")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Suggested-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    [vneethv@linux.ibm.com: Slight modification in the commit-message]
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11b2118f4ddde9b09f23039f29bea81f11ec4117
Author: Eddie James <eajames@linux.ibm.com>
Date:   Fri Nov 20 11:19:29 2020 +1030

    fsi: Aspeed: Add mutex to protect HW access
    
    [ Upstream commit dfd7f2c1c532efaeff6084970bb60ec2f2e44191 ]
    
    There is nothing to prevent multiple commands being executed
    simultaneously. Add a mutex to prevent this.
    
    Fixes: 606397d67f41 ("fsi: Add ast2600 master driver")
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Reviewed-by: Milton Miller <miltonm@us.ibm.com>
    Signed-off-by: Eddie James <eajames@linux.ibm.com>
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20201120004929.185239-1-joel@jms.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67475eb26416d201a26820df9f8d944824d4af76
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 45f8472fa26b31612f143e89f46d7ed5758cd306
Author: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Date:   Thu Nov 5 17:30:49 2020 +0200

    bus: fsl-mc: add back accidentally dropped error check
    
    [ Upstream commit 61243c03dde238170001093a29716c2369e8358f ]
    
    A previous patch accidentally dropped an error check, so add it back.
    
    Fixes: aef85b56c3c1 ("bus: fsl-mc: MC control registers are not always available")
    Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
    Link: https://lore.kernel.org/r/20201105153050.19662-1-laurentiu.tudor@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 096ee6ebd01e81305e6646b27d5ec238cbaa963d
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Thu Nov 19 20:49:18 2020 +0800

    misc: pci_endpoint_test: fix return value of error branch
    
    [ Upstream commit 1749c90489f2afa6b59dbf3ab59d58a9014c84a1 ]
    
    We return 'err' in the error branch, but this variable may be set as
    zero before. Fix it by setting 'err' as a negative value before we
    goto the error label.
    
    Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Link: https://lore.kernel.org/r/1605790158-6780-1-git-send-email-wangxiongfeng2@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70f87d48bf565497f61dfc911b78311026424894
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Fri Dec 4 11:35:38 2020 -0800

    platform/chrome: cros_ec_spi: Don't overwrite spi::mode
    
    [ Upstream commit 74639cbf51d7c0304342544a83dfda354a6bd208 ]
    
    There isn't any need to overwrite the mode here in the driver with what
    has been detected by the firmware, such as DT or ACPI. In fact, if we
    use the SPI CS gpio descriptor feature we will overwrite the mode with
    SPI_MODE_0 where it already contains SPI_MODE_0 and more importantly
    SPI_CS_HIGH. Clearing the SPI_CS_HIGH bit causes the CS line to toggle
    when the device is probed when it shouldn't change, confusing the driver
    and making it fail to probe. Drop the assignment and let the spi core
    take care of it.
    
    Fixes: a17d94f0b6e1 ("mfd: Add ChromeOS EC SPI driver")
    Cc: Simon Glass <sjg@chromium.org>
    Cc: Gwendal Grignou <gwendal@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Cc: Alexandru M Stan <amstan@chromium.org>
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Simon Glass <sjg@chromium.org>
    Link: https://lore.kernel.org/r/20201204193540.3047030-2-swboyd@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ed7389709a40b532f26cf93788e0b74538acc46
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Dec 2 05:23:06 2020 -0800

    scsi: qla2xxx: Fix N2N and NVMe connect retry failure
    
    [ Upstream commit 07a5f69248e3486e387c40af64793466371c7d91 ]
    
    FC-NVMe target discovery failed when initiator wwpn < target wwpn in an N2N
    (Direct Attach) config, where the driver was stuck on FCP PRLI mode and
    failed to retry with NVMe PRLI.
    
    Link: https://lore.kernel.org/r/20201202132312.19966-10-njavali@marvell.com
    Fixes: 84ed362ac40c ("scsi: qla2xxx: Dual FCP-NVMe target port support”)
    Fixes: 983f127603fa ("scsi: qla2xxx: Retry PLOGI on FC-NVMe PRLI failure”)
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf69f3bbbde69e8f072558ef4678bbde18b51e3b
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Dec 2 05:23:05 2020 -0800

    scsi: qla2xxx: Fix FW initialization error on big endian machines
    
    [ Upstream commit 8a78dd6ed1af06bfa7b4ade81328ff7ea11b6947 ]
    
    Some fields are not correctly byte swapped causing failure during
    initialization. As probe() returns failure, HBAs will not be claimed when
    this happens.
    
    qla2xxx [0007:01:00.0]-ffff:3: Secure Flash Update in FW: Supported
    qla2xxx [0007:01:00.0]-ffff:3: SCM in FW: Supported
    qla2xxx [0007:01:00.0]-00d2:3: Init Firmware **** FAILED ****.
    qla2xxx [0007:01:00.0]-00d6:3: Failed to initialize adapter - Adapter flags 2.
    qla2xxx 0007:01:00.1: enabling device (0140 -> 0142)
    qla2xxx [0007:01:00.1]-011c: : MSI-X vector count: 128.
    qla2xxx [0007:01:00.1]-001d: : Found an ISP2289 irq 18 iobase 0xd000080080004000.
    qla2xxx 0007:01:00.1: Using 64-bit direct DMA at offset 800000000000000
    BUG: Bad page state in process insmod  pfn:67118 page:f00000000168bd40
    count:-1 mapcount:0 mapping: (null) index:0x0
    page flags: 0x3ffff800000000() page dumped because: nonzero _count
    Modules linked in: qla2xxx(OE+) nvme_fc nvme_fabrics
            nvme_core scsi_transport_fc scsi_tgt nls_utf8 isofs ip6t_rpfilter
            ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set
            nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat
            nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
            ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4
            nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
            iptable_security iptable_raw ebtable_filter ebtables ip6table_filter
            ip6_tables iptable_filter nx_crypto ses enclosure scsi_transport_sas
            pseries_rng sg ip_tables xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif
            crct10dif_generic crct10dif_common usb_storage ipr libata tg3 ptp
            pps_core dm_mirror dm_region_hash dm_log dm_mod
    CPU: 32 PID: 8560 Comm: insmod Kdump: loaded Tainted: G
            OE  ------------   3.10.0-957.el7.ppc64 #1
    Call Trace:
    [c0000006dd7caa70] [c00000000001cca8] .show_stack+0x88/0x330 (unreliable)
    [c0000006dd7cab30] [c000000000ac3d88] .dump_stack+0x28/0x3c
    [c0000006dd7caba0] [c00000000029e48c] .bad_page+0x15c/0x1c0
    [c0000006dd7cac40] [c00000000029f938] .get_page_from_freelist+0x11e8/0x1ea0
    [c0000006dd7caf40] [c0000000002a1d30] .__alloc_pages_nodemask+0x1c0/0xc70
    [c0000006dd7cb140] [c00000000002ba0c] .__dma_direct_alloc_coherent+0x8c/0x170
    [c0000006dd7cb1e0] [d000000010a94688] .qla2x00_mem_alloc+0x10f8/0x1370 [qla2xxx]
    [c0000006dd7cb2d0] [d000000010a9c790] .qla2x00_probe_one+0xb60/0x22e0 [qla2xxx]
    [c0000006dd7cb540] [c0000000005de764] .pci_device_probe+0x204/0x300
    [c0000006dd7cb600] [c0000000006ca61c] .driver_probe_device+0x2cc/0x6f0
    [c0000006dd7cb6b0] [c0000000006cabec] .__driver_attach+0x10c/0x110
    [c0000006dd7cb740] [c0000000006c5f04] .bus_for_each_dev+0x94/0x100
    [c0000006dd7cb7e0] [c0000000006c94f4] .driver_attach+0x34/0x50
    [c0000006dd7cb860] [c0000000006c8f58] .bus_add_driver+0x298/0x3b0
    [c0000006dd7cb900] [c0000000006cb6e0] .driver_register+0xb0/0x1a0
    [c0000006dd7cb980] [c0000000005dc474] .__pci_register_driver+0xc4/0xf0
    [c0000006dd7cba10] [d000000010b94e20] .qla2x00_module_init+0x2a8/0x328 [qla2xxx]
    [c0000006dd7cbaa0] [c00000000000c130] .do_one_initcall+0x130/0x2e0
    [c0000006dd7cbb50] [c0000000001b2e8c] .load_module+0x1afc/0x2340
    [c0000006dd7cbd40] [c0000000001b3920] .SyS_finit_module+0xd0/0x130
    [c0000006dd7cbe30] [c00000000000a284]   system_call+0x38/0xfc
    
    Link: https://lore.kernel.org/r/20201202132312.19966-9-njavali@marvell.com
    Fixes: 9f2475fe7406 ("scsi: qla2xxx: SAN congestion management implementation")
    Fixes: cf3c54fb49a4 ("scsi: qla2xxx: Add SLER and PI control support”)
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50cf9c6ca2674459626a8e47c88b8229097b9221
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 2deeead49c7a6bc7e84f8792534eedb590b47ead
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 ac228fbe522d1c93739dc9167960ab0f1399f726
Author: Dai Ngo <dai.ngo@oracle.com>
Date:   Mon Nov 30 16:24:49 2020 -0500

    NFSD: Fix 5 seconds delay when doing inter server copy
    
    [ Upstream commit ca9364dde50daba93eff711b4b945fd08beafcc2 ]
    
    Since commit b4868b44c5628 ("NFSv4: Wait for stateid updates after
    CLOSE/OPEN_DOWNGRADE"), every inter server copy operation suffers 5
    seconds delay regardless of the size of the copy. The delay is from
    nfs_set_open_stateid_locked when the check by nfs_stateid_is_sequential
    fails because the seqid in both nfs4_state and nfs4_stateid are 0.
    
    Fix by modifying nfs4_init_cp_state to return the stateid with seqid 1
    instead of 0. This is also to conform with section 4.8 of RFC 7862.
    
    Here is the relevant paragraph from section 4.8 of RFC 7862:
    
       A copy offload stateid's seqid MUST NOT be zero.  In the context of a
       copy offload operation, it is inappropriate to indicate "the most
       recent copy offload operation" using a stateid with a seqid of zero
       (see Section 8.2.2 of [RFC5661]).  It is inappropriate because the
       stateid refers to internal state in the server and there may be
       several asynchronous COPY operations being performed in parallel on
       the same file by the server.  Therefore, a copy offload stateid with
       a seqid of zero MUST be considered invalid.
    
    Fixes: ce0887ac96d3 ("NFSD add nfs4 inter ssc to nfsd4_copy")
    Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f6742261ab9624bb4a41fc7b0ade30363496f11
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 837935e21f7f35bf19095560273c3d504bd0d723
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 12dba6742b1360e529cd165656a565935159859c
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 db1ccd6b7ea650b1298cde59edf4707f31d196b6
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 7a5870d95403f3b19fe1ca6ac82b6ba2575f5b94
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Dec 9 05:29:21 2020 +0000

    powerpc/mm: sanity_check_fault() should work for all, not only BOOK3S
    
    [ Upstream commit 7ceb40027e19567a0a066e3b380cc034cdd9a124 ]
    
    The verification and message introduced by commit 374f3f5979f9
    ("powerpc/mm/hash: Handle user access of kernel address gracefully")
    applies to all platforms, it should not be limited to BOOK3S.
    
    Make the BOOK3S version of sanity_check_fault() the one for all,
    and bail out earlier if not BOOK3S.
    
    Fixes: 374f3f5979f9 ("powerpc/mm/hash: Handle user access of kernel address gracefully")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/fe199d5af3578d3bf80035d203a94d742a7a28af.1607491748.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    ASoC: max98390: Fix error codes in max98390_dsm_init()
    
    [ Upstream commit 3cea33b6f2d7782d1be17c71509986f33ee93541 ]
    
    These error paths return success but they should return -EINVAL.
    
    Fixes: 97ed3e509ee6 ("ASoC: max98390: Fix potential crash during param fw loading")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/X9B0uz4svyNTqeMb@mwanda
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 939b32e18e8b6fd2435f1d02709ec872d795124f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Dec 8 11:26:50 2020 -0700

    coresight: remove broken __exit annotations
    
    [ Upstream commit 45fe7befe0db5e61cd3c846315f0ac48541e8445 ]
    
    Functions that are annotated __exit are discarded for built-in drivers,
    but the .remove callback in a device driver must still be kept around
    to allow bind/unbind operations.
    
    There is now a linker warning for the discarded symbol references:
    
    `tmc_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-tmc-core.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-tmc-core.o
    `tpiu_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-tpiu.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-tpiu.o
    `etb_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-etb10.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-etb10.o
    `static_funnel_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-funnel.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-funnel.o
    `dynamic_funnel_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-funnel.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-funnel.o
    `static_replicator_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-replicator.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-replicator.o
    `dynamic_replicator_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-replicator.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-replicator.o
    `catu_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-catu.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-catu.o
    
    Remove all those annotations.
    
    Fixes: 8b0cf82677d1 ("coresight: stm: Allow to build coresight-stm as a module")
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Link: https://lore.kernel.org/r/20201208182651.1597945-3-mathieu.poirier@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64ffbfb1d734001fd0b9a23ab635bd610eacbdd0
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Fri Dec 4 14:36:10 2020 +0800

    ASoC: amd: change clk_get() to devm_clk_get() and add missed checks
    
    [ Upstream commit 95d3befbc5e1ee39fc8a78713924cf7ed2b3cabe ]
    
    cz_da7219_init() does not check the return values of clk_get(),
    while da7219_clk_enable() calls clk_set_rate() to dereference
    the pointers.
    Add checks to fix the problems.
    Also, change clk_get() to devm_clk_get() to avoid data leak after
    failures.
    
    Fixes: bb24a31ed584 ("ASoC: AMD: Configure wclk and bclk of master codec")
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Link: https://lore.kernel.org/r/20201204063610.513556-1-hslester96@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e52398d49d8d20ea93e564ccfa55a814bb08f655
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Dec 7 15:09:37 2020 +0000

    drm/mediatek: avoid dereferencing a null hdmi_phy on an error message
    
    [ Upstream commit b097efba9580d1f7cbc80cda84e768983e3de541 ]
    
    Currently there is a null pointer check for hdmi_phy that implies it
    may be null, however a dev_err messages dereferences this potential null
    pointer.  Avoid a null pointer dereference by only emitting the dev_err
    message if hdmi_phy is non-null.  It is a moot point if the error message
    needs to be printed at all, but since this is a relatively new piece of
    code it may be useful to keep the message in for the moment in case there
    are unforseen errors that need to be reported.
    
    Fixes: be28b6507c46 ("drm/mediatek: separate hdmi phy to different file")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Addresses-Coverity: ("Dereference after null check")
    Link: https://lore.kernel.org/r/20201207150937.170435-1-colin.king@canonical.com
    [vkoul: fix indent of return call]
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66d1918b2ddb2c45aeb63228e35537e4b5d18005
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Dec 8 05:24:19 2020 +0000

    powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACK
    
    [ Upstream commit db972a3787d12b1ce9ba7a31ec376d8a79e04c47 ]
    
    low_sleep_handler() can't restore the context from standard
    stack because the stack can hardly be accessed with MMU OFF.
    
    Store everything in a global storage area instead of storing
    a pointer to the stack in that global storage area.
    
    To avoid a complete churn of the function, still use r1 as
    the pointer to the storage area during restore.
    
    Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
    Reported-by: Giuseppe Sacco <giuseppe@sguazz.it>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Tested-by: Giuseppe Sacco <giuseppe@sguazz.it>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/e3e0d8042a3ba75cb4a9546c19c408b5b5b28994.1607404931.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 904c6f64fda624e487ce41a4ce43daa74efbd5ba
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 b155175979e165803b8ab8d2c476f6a005166e5f
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 40a281cbef6c6c5c59a486625867155058fe8806
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Thu Nov 19 18:09:16 2020 +0100

    ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode
    
    [ Upstream commit f77ac2e378be9dd61eb88728f0840642f045d9d1 ]
    
    There are a couple of problems with the exception entry code that deals
    with FP exceptions (which are reported as UND exceptions) when building
    the kernel in Thumb2 mode:
    - the conditional branch to vfp_kmode_exception in vfp_support_entry()
      may be out of range for its target, depending on how the linker decides
      to arrange the sections;
    - when the UND exception is taken in kernel mode, the emulation handling
      logic is entered via the 'call_fpe' label, which means we end up using
      the wrong value/mask pairs to match and detect the NEON opcodes.
    
    Since UND exceptions in kernel mode are unlikely to occur on a hot path
    (as opposed to the user mode version which is invoked for VFP support
    code and lazy restore), we can use the existing undef hook machinery for
    any kernel mode instruction emulation that is needed, including calling
    the existing vfp_kmode_exception() routine for unexpected cases. So drop
    the call to call_fpe, and instead, install an undef hook that will get
    called for NEON and VFP instructions that trigger an UND exception in
    kernel mode.
    
    While at it, make sure that the PC correction is accurate for the
    execution mode where the exception was taken, by checking the PSR
    Thumb bit.
    
    Cc: Dmitry Osipenko <digetx@gmail.com>
    Cc: Kees Cook <keescook@chromium.org>
    Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00c54f28046d4f2d28b237db42e03140e6fd786c
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Mon Dec 7 19:47:45 2020 +0200

    platform/x86: mlx-platform: Fix item counter assignment for MSN2700/ComEx system
    
    [ Upstream commit cf791774a16caf87b0e4c0c55b82979bad0b6c01 ]
    
    Fix array names to match assignments for data items and data items
    counter in 'mlxplat_mlxcpld_comex_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: bdd6e155e0d6 ("platform/x86: mlx-platform: Add support for new system type")
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Link: https://lore.kernel.org/r/20201207174745.22889-3-vadimp@nvidia.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit acf787ea279d9be94a23207e7d4ab0dd20257fb6
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 b8c0a6e6574d545036a555f1e56bccdd9f4214cd
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 adbd2547e0c5ffe4e4b55a48e50a310557b73d25
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 dcda662622b17adaec14a1a6d82bf09e87b9ce11
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Fri Nov 20 15:48:52 2020 +0800

    scsi: iscsi: Fix inappropriate use of put_device()
    
    [ Upstream commit 6dc1c7ab6f047f45b62986ffebc5324e86ed5f5a ]
    
    kfree(conn) is called inside put_device(&conn->dev) which could lead to
    use-after-free. In addition, device_unregister() should be used here rather
    than put_deviceO().
    
    Link: https://lore.kernel.org/r/20201120074852.31658-1-miaoqinglang@huawei.com
    Fixes: f3c893e3dbb5 ("scsi: iscsi: Fail session and connection on transport registration failure")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    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 f6d844be9502ae6ea90a603f349be332ef9e5841
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 2619d3cbf7747b3c07ee2486306edd48640bf78e
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 45d670efcb0b3efbf5a356353b9cada31473acf8
Author: Michael Walle <michael@walle.cc>
Date:   Thu Nov 5 20:27:44 2020 +0100

    clk: fsl-sai: fix memory leak
    
    [ Upstream commit e81bed419f032824e7ddf8b5630153be6637e480 ]
    
    If the device is removed we don't unregister the composite clock. Fix
    that.
    
    Fixes: 9cd10205227c ("clk: fsl-sai: new driver")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Link: https://lore.kernel.org/r/20201105192746.19564-2-michael@walle.cc
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 608918e878d4e0b44e141c2796d2e26ba4bfa0e5
Author: Stefan Agner <stefan@agner.ch>
Date:   Mon Dec 7 18:58:03 2020 +0100

    arm64: dts: meson: g12b: w400: fix PHY deassert timing requirements
    
    [ Upstream commit 9e454e37dc7c0ee9e108d70b983e7a71332aedff ]
    
    According to the datasheet (Rev. 1.9) the RTL8211F requires at least
    72ms "for internal circuits settling time" before accessing the PHY
    egisters. On similar boards with the same PHY this fixes an issue where
    Ethernet link would not come up when using ip link set down/up.
    
    Fixes: 2cd2310fca4c ("arm64: dts: meson-g12b-ugoos-am6: add initial device-tree")
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/46298e66572784c44f873f1b71cc4ab3d8fc5aa6.1607363522.git.stefan@agner.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb7fadab988e8e5271c408b9b70068213cd310c9
Author: Stefan Agner <stefan@agner.ch>
Date:   Mon Dec 7 18:58:02 2020 +0100

    arm64: dts: meson: g12a: x96-max: fix PHY deassert timing requirements
    
    [ Upstream commit 3d07c3b3a886fefd583c1b485b5e4e3c4e2da493 ]
    
    According to the datasheet (Rev. 1.9) the RTL8211F requires at least
    72ms "for internal circuits settling time" before accessing the PHY
    registers. On similar boards with the same PHY this fixes an issue where
    Ethernet link would not come up when using ip link set down/up.
    
    Fixes: ed5e8f689154 ("arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY reset line")
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/12506964ca5d5f936579a280ad0a7e7f9a0a2d4c.1607363522.git.stefan@agner.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aaeb52620dd9d7d37c37d3e4c3132c5f057868be
Author: Stefan Agner <stefan@agner.ch>
Date:   Mon Dec 7 18:58:01 2020 +0100

    ARM: dts: meson: fix PHY deassert timing requirements
    
    [ Upstream commit 656ab1bdcd2b755dc161a9774201100d5bf74b8d ]
    
    According to the datasheet (Rev. 1.9) the RTL8211F requires at least
    72ms "for internal circuits settling time" before accessing the PHY
    registers. On similar boards with the same PHY this fixes an issue where
    Ethernet link would not come up when using ip link set down/up.
    
    Fixes: a2c6e82e5341 ("ARM: dts: meson: switch to the generic Ethernet PHY reset bindings")
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # on Odroid-C1+
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/ff78772b306411e145769c46d4090554344db41e.1607363522.git.stefan@agner.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46b7f2249854532d5783e24bb2a6d143d323558d
Author: Stefan Agner <stefan@agner.ch>
Date:   Mon Dec 7 18:58:00 2020 +0100

    arm64: dts: meson: fix PHY deassert timing requirements
    
    [ Upstream commit c183c406c4321002fe85b345b51bc1a3a04b6d33 ]
    
    According to the datasheet (Rev. 1.9) the RTL8211F requires at least
    72ms "for internal circuits settling time" before accessing the PHY
    registers. This fixes an issue seen on ODROID-C2 where the Ethernet
    link doesn't come up when using ip link set down/up:
      [ 6630.714855] meson8b-dwmac c9410000.ethernet eth0: Link is Down
      [ 6630.785775] meson8b-dwmac c9410000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=36)
      [ 6630.893071] meson8b-dwmac c9410000.ethernet: Failed to reset the dma
      [ 6630.893800] meson8b-dwmac c9410000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
      [ 6630.902835] meson8b-dwmac c9410000.ethernet eth0: stmmac_open: Hw setup failed
    
    Fixes: f29cabf240ed ("arm64: dts: meson: use the generic Ethernet PHY reset GPIO bindings")
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/4a322c198b86e4c8b3dda015560a683babea4d63.1607363522.git.stefan@agner.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a83bf1290710b82c420f9a33808d8d69f90f0eb3
Author: Stefan Agner <stefan@agner.ch>
Date:   Mon Dec 7 18:57:59 2020 +0100

    arm64: dts: meson: g12b: odroid-n2: fix PHY deassert timing requirements
    
    [ Upstream commit 1c7412530d5d0e0a0b27f1642f5c13c8b9f36f05 ]
    
    According to the datasheet (Rev. 1.9) the RTL8211F requires at least
    72ms "for internal circuits settling time" before accessing the PHY
    registers. This fixes an issue where the Ethernet link doesn't come up
    when using ip link set down/up:
      [   29.360965] meson8b-dwmac ff3f0000.ethernet eth0: Link is Down
      [   34.569012] meson8b-dwmac ff3f0000.ethernet eth0: PHY [0.0:00] driver [RTL8211F Gigabit Ethernet] (irq=31)
      [   34.676732] meson8b-dwmac ff3f0000.ethernet: Failed to reset the dma
      [   34.678874] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
      [   34.687850] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_open: Hw setup failed
    
    Fixes: 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY reset line")
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/df3f5c4fc6e43c55429fd3662a636036a21eed49.1607363522.git.stefan@agner.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9ee2a910d4418da57ed3ad79300bb02e2133b3a
Author: Michael Walle <michael@walle.cc>
Date:   Thu Dec 3 17:29:58 2020 +0100

    mtd: spi-nor: atmel: fix unlock_all() for AT25FS010/040
    
    [ Upstream commit 8c174d1511d235ed6c049dcb2b704777ad0df7a5 ]
    
    These flashes have some weird BP bits mapping which aren't supported in
    the current locking code. Just add a simple unlock op to unprotect the
    entire flash array which is needed for legacy behavior.
    
    Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20201203162959.29589-7-michael@walle.cc
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4f620ed499cdf3d7934031babd0b49f69cb87fc
Author: Michael Walle <michael@walle.cc>
Date:   Thu Dec 3 17:29:55 2020 +0100

    mtd: spi-nor: atmel: remove global protection flag
    
    [ Upstream commit e6204d4620276398ed7317d64c369813a1f96615 ]
    
    This is considered bad for the following reasons:
     (1) We only support the block protection with BPn bits for write
         protection. Not all Atmel parts support this.
     (2) Newly added flash chip will automatically inherit the "has
         locking" support and thus needs to explicitly tested. Better
         be opt-in instead of opt-out.
     (3) There are already supported flashes which doesn't support
         the locking scheme. So I assume this wasn't properly tested
         before adding that chip; which enforces my previous argument
         that locking support should be an opt-in.
    
    Remove the global flag and add individual flags to all flashes which
    supports BP locking. In particular the following flashes don't support
    the BP scheme:
     - AT26F004
     - AT25SL321
     - AT45DB081D
    
    Please note, that some flashes which are marked as SPI_NOR_HAS_LOCK just
    support Global Protection, i.e. not our supported block protection
    locking scheme. This is to keep backwards compatibility with the
    current "unlock all at boot" mechanism. In particular the following
    flashes doesn't have BP bits:
     - AT25DF041A
     - AT25DF321
     - AT25DF321A
     - AT25DF641
     - AT26DF081A
     - AT26DF161A
     - AT26DF321
    
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20201203162959.29589-4-michael@walle.cc
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c39f4a1191f025dc49f9c70a3ece702b06368472
Author: Michael Walle <michael@walle.cc>
Date:   Thu Dec 3 17:29:54 2020 +0100

    mtd: spi-nor: ignore errors in spi_nor_unlock_all()
    
    [ Upstream commit bdb1a75e4b9df6861ec6a6e3e3997820d3cebabe ]
    
    Just try to unlock the whole SPI-NOR flash array. Don't abort the
    probing in case of an error. Justifications:
     (1) For some boards, this just works because
         spi_nor_write_16bit_sr_and_check() is broken and just checks the
         second half of the 16bit. Once that will be fixed, SPI probe will
         fail for boards which has hardware-write protected SPI-NOR flashes.
     (2) Until now, hardware write-protection was the only viable solution
         to use the block protection bits. This is because this very
         function spi_nor_unlock_all() will be called unconditionally on
         every linux boot. Therefore, this bits only makes sense in
         combination with the hardware write-protection. If we would fail
         the SPI probe on an error in spi_nor_unlock_all() we'd break
         virtually all users of the block protection bits.
     (3) We should try hard to keep the MTD working even if the flash might
         not be writable/erasable.
    
    Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20201203162959.29589-3-michael@walle.cc
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f79f7258f3b7091ae5180dfe07a98e6b76ac5132
Author: Michael Walle <michael@walle.cc>
Date:   Thu Dec 3 17:29:53 2020 +0100

    mtd: spi-nor: sst: fix BPn bits for the SST25VF064C
    
    [ Upstream commit 989d4b72bae3b05c1564d38e71e18f65b12734fb ]
    
    This flash part actually has 4 block protection bits.
    
    Please note, that this patch is just based on information of the
    datasheet of the datasheet and wasn't tested.
    
    Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection")
    Reported-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20201203162959.29589-2-michael@walle.cc
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    adm8211: fix error return code in adm8211_probe()
    
    [ Upstream commit 05c2a61d69ea306e891884a86486e1ef37c4b78d ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1607071638-33619-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9488824795474f4c816dc46c93a84797607a3c08
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Sep 12 11:35:32 2020 +0200

    platform/x86: intel-vbtn: Fix SW_TABLET_MODE always reporting 1 on some HP x360 models
    
    [ Upstream commit a4327979a19e8734ddefbd8bcbb73bd9905b69cd ]
    
    Some HP x360 models have an ACPI VGBS method which sets bit 4 instead of
    bit 6 when NOT in tablet mode at boot. Inspecting all the DSDTs in my DSDT
    collection shows only one other model, the Medion E1239T ever setting bit 4
    and it always sets this together with bit 6.
    
    So lets treat bit 4 as a second bit which when set indicates the device not
    being in tablet-mode, as we already do for bit 6.
    
    While at it also prefix all VGBS constant defines with "VGBS_".
    
    Note this wrokaround was first added to the kernel as
    commit d823346876a9 ("platform/x86: intel-vbtn: Fix SW_TABLET_MODE always
    reporting 1 on the HP Pavilion 11 x360").
    After commit 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an
    allow-list for SW_TABLET_MODE reporting") got added to the kernel this
    was reverted, because with the new allow-list approach the workaround
    was no longer necessary for the model on which the issue was first
    reported.
    
    But it turns out that the workaround is still necessary because some
    affected models report a chassis-type of 31 which is on the allow-list.
    
    BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894017
    Fixes: 21d64817c724 ("platform/x86: intel-vbtn: Revert "Fix SW_TABLET_MODE always reporting 1 on the HP Pavilion 11 x360"")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6af7b5ab2a0346c7404f22dff53ebdf91b8d87f1
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Dec 5 16:02:00 2020 +0100

    Bluetooth: btusb: Fix detection of some fake CSR controllers with a bcdDevice val of 0x0134
    
    [ Upstream commit d74e0ae7e03032b47b8631cc1e52a7ae1ce988c0 ]
    
    Commit cde1a8a99287 ("Bluetooth: btusb: Fix and detect most of the
    Chinese Bluetooth controllers") made the detection of fake controllers
    more generic fixing it for much of the newer fakes / clones.
    
    But this does not work for a fake CSR controller with a bcdDevice
    value of 0x0134, which was correctly identified as fake before
    this change.
    
    Add an extra check for this special case, checking for a combination
    of a bcdDevice value of 0x0134, together with a lmp_subver of 0x0c5c
    and a hci_ver of BLUETOOTH_VER_2_0.
    
    The chip inside this fake dongle is marked as with "clockwise cw6629d".
    
    Fixes: cde1a8a99287 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa4f552aec3d43cc1455490825399d178da0a65f
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Dec 7 14:54:46 2020 +0000

    block/rnbd: fix a null pointer dereference on dev->blk_symlink_name
    
    [ Upstream commit 733c15bd3a944b8eeaacdddf061759b6a83dd3f4 ]
    
    Currently in the case where dev->blk_symlink_name fails to be allocates
    the error return path attempts to set an end-of-string character to
    the unallocated dev->blk_symlink_name causing a null pointer dereference
    error. Fix this by returning with an explicity ENOMEM error (which also
    is missing in the original code as was not initialized).
    
    Fixes: 1eb54f8f5dd8 ("block/rnbd: client: sysfs interface functions")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Addresses-Coverity: ("Dereference after null check")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7d4dd109eae096eb38cef8a50a9c86335420a98
Author: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Date:   Thu Nov 26 11:47:23 2020 +0100

    block/rnbd-clt: Dynamically alloc buffer for pathname & blk_symlink_name
    
    [ Upstream commit 64e8a6ece1a5b1fa21316918053d068baeac84af ]
    
    For every rnbd_clt_dev, we alloc the pathname and blk_symlink_name
    statically to NAME_MAX which is 255 bytes. In most of the cases we only
    need less than 10 bytes, so 500 bytes per block device are wasted.
    
    This commit dynamically allocates memory buffer for pathname and
    blk_symlink_name.
    
    Signed-off-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Reviewed-by: Lutz Pogrell <lutz.pogrell@cloud.ionos.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6013c99742160d3901c4d108733e29b83b25f452
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Mon Nov 16 21:24:21 2020 +0800

    Bluetooth: sco: Fix crash when using BT_SNDMTU/BT_RCVMTU option
    
    [ Upstream commit f6b8c6b5543983e9de29dc14716bfa4eb3f157c4 ]
    
    This commit add the invalid check for connected socket, without it will
    causes the following crash due to sco_pi(sk)->conn being NULL:
    
    KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
    CPU: 3 PID: 4284 Comm: test_sco Not tainted 5.10.0-rc3+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
    RIP: 0010:sco_sock_getsockopt+0x45d/0x8e0
    Code: 48 c1 ea 03 80 3c 02 00 0f 85 ca 03 00 00 49 8b 9d f8 04 00 00 48 b8 00
          00 00 00 00 fc ff df 48 8d 7b 50 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
          c0 74 08 3c 03 0f 8e b5 03 00 00 8b 43 50 48 8b 0c
    RSP: 0018:ffff88801bb17d88 EFLAGS: 00010206
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83a4ecdf
    RDX: 000000000000000a RSI: ffffc90002fce000 RDI: 0000000000000050
    RBP: 1ffff11003762fb4 R08: 0000000000000001 R09: ffff88810e1008c0
    R10: ffffffffbd695dcf R11: fffffbfff7ad2bb9 R12: 0000000000000000
    R13: ffff888018ff1000 R14: dffffc0000000000 R15: 000000000000000d
    FS:  00007fb4f76c1700(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005555e3b7a938 CR3: 00000001117be001 CR4: 0000000000770ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     ? sco_skb_put_cmsg+0x80/0x80
     ? sco_skb_put_cmsg+0x80/0x80
     __sys_getsockopt+0x12a/0x220
     ? __ia32_sys_setsockopt+0x150/0x150
     ? syscall_enter_from_user_mode+0x18/0x50
     ? rcu_read_lock_bh_held+0xb0/0xb0
     __x64_sys_getsockopt+0xba/0x150
     ? syscall_enter_from_user_mode+0x1d/0x50
     do_syscall_64+0x33/0x40
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 0fc1a726f897 ("Bluetooth: sco: new getsockopt options BT_SNDMTU/BT_RCVMTU")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Reviewed-by: Luiz Augusto Von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 046182ddb93460330ad43fd319d8318bf9b2e3c2
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Tue Nov 17 10:43:32 2020 +0800

    Bluetooth: btmtksdio: Add the missed release_firmware() in mtk_setup_firmware()
    
    [ Upstream commit b73b5781a85c03113476f62346c390f0277baa4b ]
    
    mtk_setup_firmware() misses to call release_firmware() in an error
    path. Jump to free_fw to fix it.
    
    Fixes: 737cd06072a7 ("Bluetooth: btmtksdio: fix up firmware download sequence")
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae0e737765b88e48db69e485ebe9a70716ecad46
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Tue Nov 17 10:59:17 2020 +0800

    Bluetooth: btusb: Add the missed release_firmware() in btusb_mtk_setup_firmware()
    
    [ Upstream commit d1e9d232e1e60fa63df1b836ec3ecba5abd3fa9d ]
    
    btusb_mtk_setup_firmware() misses to call release_firmware() in an error
    path. Jump to err_release_fw to fix it.
    
    Fixes: f645125711c8 ("Bluetooth: btusb: fix up firmware download sequence")
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 848120a0d13bf00a0d21a88306b8ab5ec88c4e45
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:42:37 2020 +0800

    spi: dw: Fix error return code in dw_spi_bt1_probe()
    
    [ Upstream commit e748edd9841306908b4e02dddd0afd1aa1f8b973 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Serge Semin <fancer.lancer@gmail.com>
    Link: https://lore.kernel.org/r/1607071357-33378-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f636755d7fe51fc908c5329bc90486d1c9c5d561
Author: Wang Hai <wanghai38@huawei.com>
Date:   Sat Dec 5 18:38:27 2020 +0800

    staging: greybus: audio: Fix possible leak free widgets in gbaudio_dapm_free_controls
    
    [ Upstream commit e77b259f67ab99f1e22ce895b9b1c637fd5f2d4c ]
    
    In gbaudio_dapm_free_controls(), if one of the widgets is not found, an error
    will be returned directly, which will cause the rest to be unable to be freed,
    resulting in leak.
    
    This patch fixes the bug. If if one of them is not found, just skip and free the others.
    
    Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic audio module")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Reviewed-by: Vaibhav Agarwal <vaibhav.sr@gmail.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Link: https://lore.kernel.org/r/20201205103827.31244-1-wanghai38@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    staging: bcm2835: fix vchiq_mmal dependencies
    
    [ Upstream commit 6c91799f59ed491a2b5bf5ef7c6d60306cda4e09 ]
    
    When the MMAL code is built-in but the vchiq core config is
    set to =m, the mmal code never gets built, which in turn can
    lead to link errors:
    
    ERROR: modpost: "vchiq_mmal_port_set_format" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_port_disable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_port_parameter_set" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_component_finalise" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_port_connect_tunnel" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_component_enable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_finalise" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_component_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_component_disable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "mmal_vchi_buffer_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_port_enable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_version" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_submit_buffer" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "mmal_vchi_buffer_cleanup" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    ERROR: modpost: "vchiq_mmal_port_parameter_get" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
    
    Change the Kconfig to depend on BCM2835_VCHIQ like the other drivers,
    and remove the now redundant dependencies.
    
    Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
    Acked-by: Jacopo Mondi <jacopo@jmondi.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20201203223836.1362313-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7884eed1301792b79b18cf86036baceb3c7033d
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Fri Nov 20 15:39:56 2020 +1100

    macintosh/adb-iop: Send correct poll command
    
    [ Upstream commit 10199e90ee20e68859f8128331ec8d85b036d349 ]
    
    The behaviour of the IOP firmware is not well documented but we do know
    that IOP message reply data can be used to issue new ADB commands.
    Use the message reply to better control autopoll behaviour by sending
    a Talk Register 0 command after every ADB response, not unlike the
    algorithm in the via-macii driver. This poll command is addressed to
    that device which last received a Talk command (explicit or otherwise).
    
    Cc: Joshua Thompson <funaho@jurai.org>
    Fixes: 32226e817043 ("macintosh/adb-iop: Implement idle -> sending state transition")
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Link: https://lore.kernel.org/r/58bba4310da4c29b068345a4b36af8a531397ff7.1605847196.git.fthain@telegraphics.com.au
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbae91abbc27037e59326a9541c8912606665414
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Fri Nov 20 15:39:56 2020 +1100

    macintosh/adb-iop: Always wait for reply message from IOP
    
    [ Upstream commit 2c9cfbadfa234b03473f1ef54e6f4772cc07a371 ]
    
    A recent patch incorrectly altered the adb-iop state machine behaviour
    and introduced a regression that can appear intermittently as a
    malfunctioning ADB input device. This seems to be caused when reply
    packets from different ADB commands become mixed up, especially during
    the adb bus scan. Fix this by unconditionally entering the awaiting_reply
    state after sending an explicit command, even when the ADB command won't
    generate a reply from the ADB device.
    
    It turns out that the IOP always generates reply messages, even when the
    ADB command does not produce a reply packet (e.g. ADB Listen command).
    So it's not really the ADB reply packets that are being mixed up, it's the
    IOP messages that enclose them. The bug goes like this:
    
      1. CPU sends a message to the IOP, expecting no response because this
         message contains an ADB Listen command. The ADB command is now
         considered complete.
    
      2. CPU sends a second message to the IOP, this time expecting a
         response because this message contains an ADB Talk command. This
         ADB command needs a reply before it can be completed.
    
      3. adb-iop driver receives an IOP message and assumes that it relates
         to the Talk command. It's actually an empty one (with flags ==
         ADB_IOP_EXPLICIT|ADB_IOP_TIMEOUT) for the previous command. The
         Talk command is now considered complete but it gets the wrong reply
         data.
    
      4. adb-iop driver gets another IOP response message, which contains
         the actual reply data for the Talk command, but this is dropped
         (the driver is no longer in awaiting_reply state).
    
    Cc: Joshua Thompson <funaho@jurai.org>
    Fixes: e2954e5f727f ("macintosh/adb-iop: Implement sending -> idle state transition")
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Link: https://lore.kernel.org/r/0f0a25855391e7eaa53a50f651aea0124e8525dd.1605847196.git.fthain@telegraphics.com.au
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d806ffec27b1786d453e84fdddc647219941f103
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 3 23:53:32 2020 +0100

    cpufreq: imx: fix NVMEM_IMX_OCOTP dependency
    
    [ Upstream commit fc928b901dc68481ba3e524860a641fe13e25dfe ]
    
    A driver should not 'select' drivers from another subsystem.
    If NVMEM is disabled, this one results in a warning:
    
    WARNING: unmet direct dependencies detected for NVMEM_IMX_OCOTP
      Depends on [n]: NVMEM [=n] && (ARCH_MXC [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y]
      Selected by [y]:
      - ARM_IMX6Q_CPUFREQ [=y] && CPU_FREQ [=y] && (ARM || ARM64 [=y]) && ARCH_MXC [=y] && REGULATOR_ANATOP [=y]
    
    Change the 'select' to 'depends on' to prevent it from going wrong,
    and allow compile-testing without that driver, since it is only
    a runtime dependency.
    
    Fixes: 2782ef34ed23 ("cpufreq: imx: Select NVMEM_IMX_OCOTP")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    cpufreq: vexpress-spc: Add missing MODULE_ALIAS
    
    [ Upstream commit d15183991c2d53d7cecf27a1555c91b702cef1ea ]
    
    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: 47ac9aa165540 ("cpufreq: arm_big_little: add vexpress SPC interface driver")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35f501f734b630418004693514584eb1fbccb6b7
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 8f92fe114fa71d1f08eef0a33df71e6b69a51510
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 60b517181a6ef6c5283d43332a9370ae4b792a16
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:36 2020 +0100

    cpufreq: sun50i: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit af2096f285077e3339eb835ad06c50bdd59f01b5 ]
    
    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: f328584f7bff8 ("cpufreq: Add sun50i nvmem based CPU scaling driver")
    Reviewed-by: Yangtao Li <tiny.windzz@gmail.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b15fcc3a31c4f249793c4b0e7f4adfb45df35171
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 757ee8737ddf282814a208658fb2eecc12156180
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:34 2020 +0100

    cpufreq: qcom: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit a5a6031663bc1dd0a10babd49d1bcb3153a8327f ]
    
    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: 46e2856b8e188 ("cpufreq: Add Kryo CPU scaling driver")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f03e8a02c4e9edaa481412fd65ef98d50daff8e
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 7000750ae37a561598c35be5cd77cce20e7e208e
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 345990ffc952130080eb06f235fcf579124f849e
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Nov 3 16:11:31 2020 +0100

    cpufreq: ap806: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 925a5bcefe105f2790ecbdc252eb2315573f309d ]
    
    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: f525a670533d9 ("cpufreq: ap806: add cpufreq driver for Armada 8K")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 276c71eea8c74cb81ffb587f4a7abdcb808c5a1a
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 f94df0cb1e099661f20a7817183d1669f5b323b7
Author: Keqian Zhu <zhukeqian1@huawei.com>
Date:   Fri Dec 4 15:31:25 2020 +0800

    clocksource/drivers/arm_arch_timer: Use stable count reader in erratum sne
    
    [ Upstream commit d8cc3905b8073c7cfbff94af889fa8dc71f21dd5 ]
    
    In commit 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter
    to access stable counters"), we separate stable and normal count reader to omit
    unnecessary overhead on systems that have no timer erratum.
    
    However, in erratum_set_next_event_tval_generic(), count reader becomes normal
    reader. This converts it to stable reader.
    
    Fixes: 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter to access stable counters")
    Acked-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20201204073126.6920-2-zhukeqian1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5acad354237daf59e3d418c7cf51db620b64ba09
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 4 00:13:38 2020 +0100

    drm/msm: add IOMMU_SUPPORT dependency
    
    [ Upstream commit e319a1b956f785f618611857cd946dca2bb68542 ]
    
    The iommu pgtable support is only available when IOMMU support
    is built into the kernel:
    
    WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE
      Depends on [n]: IOMMU_SUPPORT [=n]
      Selected by [y]:
      - DRM_MSM [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_QCOM [=y] || SOC_IMX5 || ARM && COMPILE_TEST [=y]) && OF [=y] && COMMON_CLK [=y] && MMU [=y] && (QCOM_OCMEM [=y] || QCOM_OCMEM [=y]=n)
    
    Fix the dependency accordingly. There is no need for depending on
    CONFIG_MMU any more, as that is implied by the iommu support.
    
    Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5471864d27e5945320f0de3e7cce48b3c3990d6c
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Mon Nov 2 21:02:25 2020 +0100

    drm/msm: a5xx: Make preemption reset case reentrant
    
    [ Upstream commit 7cc29fcdfcc8784e97c5151c848e193800ec79ac ]
    
    nr_rings is reset to 1, but when this function is called for a second
    (and third!) time nr_rings > 1 is false, thus the else case is entered
    to set up a buffer for the RPTR shadow and consequently written to
    RB_RPTR_ADDR, hanging platforms without WHERE_AM_I firmware support.
    
    Restructure the condition in such a way that shadow buffer setup only
    ever happens when has_whereami is true; otherwise preemption is only
    finalized when the number of ring buffers has not been reset to 1 yet.
    
    Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as privileged")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7af811f2e745ecd3495b21f80e3cb007ef54af4
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:31:57 2020 +0800

    memory: jz4780_nemc: Fix potential NULL dereference in jz4780_nemc_probe()
    
    [ Upstream commit 4bfa07300b9334b487ed4f3d4901c35ebb31b7ca ]
    
    platform_get_resource() may fail and return NULL, so we should
    better check it's return value to avoid a NULL pointer dereference
    a bit later in the code.
    
    This is detected by Coccinelle semantic patch.
    
    Fixes: 911a88829725 ("memory: jz4780-nemc: driver for the NEMC on JZ4780 SoCs")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Paul Cercueil <paul@crapouillou.net>
    Link: https://lore.kernel.org/r/1607070717-32880-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20d79c2a54155dbcc338f799788a305a9d190976
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 4 00:08:14 2020 +0100

    memory: ti-emif-sram: only build for ARMv7
    
    [ Upstream commit d77d22d701b0471584abe1871570bb43deb6e3c4 ]
    
    The driver can be compile-tested on all ARM machines, but
    causes a failure when built for ARMv7-M:
    
    arm-linux-gnueabi-ld: error: drivers/memory/ti-emif-sram-pm.o: conflicting architecture profiles A/M
    
    Limit the target machines to configurations that have ARMv7 enabled.
    
    Fixes: ea0c0ad6b6eb ("memory: Enable compile testing for most of the drivers")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20201203230832.1481767-1-arnd@kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3aec054f58c7e0deb77c1107475e2490585ece36
Author: Wang Li <wangli74@huawei.com>
Date:   Thu Nov 26 10:44:12 2020 +0800

    phy: renesas: rcar-gen3-usb2: disable runtime pm in case of failure
    
    [ Upstream commit 51e339deab1e51443f6ac3b1bd5cd6cc8e8fe1d9 ]
    
    pm_runtime_enable() will decrease power disable depth. Thus a pairing
    increment is needed on the error handling path to keep it balanced.
    
    Fixes: 5d8042e95fd4 ("phy: rcar-gen3-usb2: Add support for r8a77470")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Li <wangli74@huawei.com>
    Link: https://lore.kernel.org/r/20201126024412.4046845-1-wangli74@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8178c539e4dff95bc38626f795f04e9f75f83a88
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 4 14:56:43 2020 +0100

    phy: mediatek: allow compile-testing the hdmi phy
    
    [ Upstream commit f5f6e01f9164040ba120f30522efdb4deceb529a ]
    
    Compile-testing the DRM_MEDIATEK_HDMI driver shows two missing
    dependencies, one results in a link failure:
    
    arm-linux-gnueabi-ld: drivers/phy/mediatek/phy-mtk-hdmi.o: in function `mtk_hdmi_phy_probe':
    phy-mtk-hdmi.c:(.text+0xd8): undefined reference to `__clk_get_name'
    arm-linux-gnueabi-ld: phy-mtk-hdmi.c:(.text+0x12c): undefined reference to `devm_clk_register'
    arm-linux-gnueabi-ld: phy-mtk-hdmi.c:(.text+0x250): undefined reference to `of_clk_add_provider'
    arm-linux-gnueabi-ld: phy-mtk-hdmi.c:(.text+0x298): undefined reference to `of_clk_src_simple_get'
    
    The other one is a harmless warning:
    
    WARNING: unmet direct dependencies detected for PHY_MTK_HDMI
      Depends on [n]: ARCH_MEDIATEK [=n] && OF [=y]
      Selected by [y]:
      - DRM_MEDIATEK_HDMI [=y] && HAS_IOMEM [=y] && DRM_MEDIATEK [=y]
    
    Fix these by adding dependencies on CONFIG_OF and CONFIG_COMMON_CLK.
    With that done, there is also no reason against adding
    CONFIG_COMPILE_TEST.
    
    Fixes: b28be59a2e26 ("phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20201204135650.2744481-1-arnd@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ae5c3f9f4d9abce72932680f368bf832f53778b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 4 00:14:18 2020 +0100

    ASoC: qcom: fix QDSP6 dependencies, attempt #3
    
    [ Upstream commit b1b8eb1283c90a953089d988930d7b6156418958 ]
    
    The previous fix left another warning in randconfig builds:
    
    WARNING: unmet direct dependencies detected for SND_SOC_QDSP6
      Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_QCOM [=y] && QCOM_APR [=y] && COMMON_CLK [=n]
      Selected by [y]:
      - SND_SOC_MSM8996 [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_QCOM [=y] && QCOM_APR [=y]
    
    Add one more dependency for this one.
    
    Fixes: 2bc8831b135c ("ASoC: qcom: fix SDM845 & QDSP6 dependencies more")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20201203231443.1483763-1-arnd@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3ea5a0a1e380d00a42d5d0c9184db627776ffd6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 3 23:38:05 2020 +0100

    ASoC: atmel: mchp-spdifrx needs COMMON_CLK
    
    [ Upstream commit 29275309b0e32bb838d67158c6b6e687275f43e9 ]
    
    Compile-testing this driver on an older platform without CONFIG_COMMON_CLK fails with
    
    ERROR: modpost: "clk_set_min_rate" [sound/soc/atmel/snd-soc-mchp-spdifrx.ko] undefined!
    
    Make this is a strict dependency.
    
    Fixes: ef265c55c1ac ("ASoC: mchp-spdifrx: add driver for SPDIF RX")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Link: https://lore.kernel.org/r/20201203223815.1353451-1-arnd@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b00ff200d89fa4f7ea61bbd5749212781b10e77
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 3 23:54:41 2020 +0100

    ASoC: cros_ec_codec: fix uninitialized memory read
    
    [ Upstream commit 7061b8a52296e044eed47b605d136a48da1a7761 ]
    
    gcc points out a memory area that is copied to a device
    but not initialized:
    
    sound/soc/codecs/cros_ec_codec.c: In function 'i2s_rx_event':
    arch/x86/include/asm/string_32.h:83:20: error: '*((void *)&p+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       83 |   *((int *)to + 1) = *((int *)from + 1);
    
    Initialize all the unused fields to zero.
    
    Fixes: 727f1c71c780 ("ASoC: cros_ec_codec: refactor I2S RX")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Tzung-Bi Shih <tzungbi@google.com>
    Link: https://lore.kernel.org/r/20201203225458.1477830-1-arnd@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a579661e5840a0d2a0641f32e3ebc8259fc8597
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 54919a7153240810f62a0b378a9b97560374e617
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Fri Dec 4 16:42:28 2020 +0000

    ASoC: q6afe-clocks: Add missing parent clock rate
    
    [ Upstream commit 7e20ae1208daaf6dad85c2dcb968fc590b6f3b99 ]
    
    setting clock rate on child clocks without a parent clock rate will
    result in zero clk rate for child. This also means that when audio
    is started dsp will attempt to access registers without enabling
    clock resulting in board boot up.
    
    Fix this by adding the missing parent clock rate.
    
    Fixes: 520a1c396d196 ("ASoC: q6afe-clocks: add q6afe clock controller")
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20201204164228.1826-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7403022a695ab3f32a3958e72ed4b8224c2ffba1
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 2952eef157b95ed615e7117b69a26f0dee7a6e44
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Sat Oct 17 17:15:25 2020 +0200

    mt76: fix tkip configuration for mt7615/7663 devices
    
    [ Upstream commit 930e0eaddf810cfa90e114a0df02f48539e1346f ]
    
    Fix Tx-Rx MIC overwrite during TKIP hw key configuration
    
    Fixes: 01cfc1b45421 ("mt76: mt7615: add BIP_CMAC_128 cipher support")
    Tested-by: YN Chen <yn.chen@mediatek.com>
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2dea65052ee91b0f5c26758b3053bdc3ce714e3
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Tue Oct 13 10:33:49 2020 +0200

    mt76: fix memory leak if device probing fails
    
    [ Upstream commit bc348defcc6eceeb4f7784bf9a263ddb72fd3fb4 ]
    
    Run mt76_free_device instead of ieee80211_free_hw if device probing
    fails in order to remove the already allocated mt76 workqueue
    
    Fixes: a86f1d01f5ce5 ("mt76: move mt76 workqueue in common code")
    Fixes: f1d962369d568 ("mt76: mt7915: implement HE per-rate tx power support")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5f908355d1b61164eeeb81a36d674271391dfaf
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 1669724f7052655119786238d6194e8f5f0b42bb
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Mon Oct 12 00:43:55 2020 +0200

    mt76: dma: fix possible deadlock running mt76_dma_cleanup
    
    [ Upstream commit 5f0ce5848733b86deaba1c6d102e20479230b20a ]
    
    Fix the following possible deadlock reported by lockdep disabling BH
    running mt76_free_pending_txwi()
    
    ================================
    WARNING: inconsistent lock state
    5.9.0-rc6 #14 Not tainted
    --------------------------------
    inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
    rmmod/1227 [HC0[0]:SC0[0]:HE1:SE1] takes:
    ffff888156a83530 (&dev->lock#2){+.?.}-{2:2}, at: mt76_dma_cleanup+0x125/0x150 [mt76]
    {IN-SOFTIRQ-W} state was registered at:
      __lock_acquire+0x20c/0x6b0
      lock_acquire+0x9d/0x220
      _raw_spin_lock+0x2c/0x70
      mt76_dma_tx_cleanup+0xc7/0x200 [mt76]
      mt76x02_poll_tx+0x31/0xb0 [mt76x02_lib]
      napi_poll+0x3a/0x100
      net_rx_action+0xa8/0x200
      __do_softirq+0xc4/0x430
      asm_call_on_stack+0xf/0x20
      do_softirq_own_stack+0x49/0x60
      irq_exit_rcu+0x9a/0xd0
      common_interrupt+0xa4/0x190
      asm_common_interrupt+0x1e/0x40
    irq event stamp: 9915
    hardirqs last  enabled at (9915): [<ffffffff8124e286>] __free_pages_ok+0x336/0x3b0
    hardirqs last disabled at (9914): [<ffffffff8124e24e>] __free_pages_ok+0x2fe/0x3b0
    softirqs last  enabled at (9912): [<ffffffffa03aa672>] mt76_dma_rx_cleanup+0xa2/0x120 [mt76]
    softirqs last disabled at (9846): [<ffffffffa03aa5ea>] mt76_dma_rx_cleanup+0x1a/0x120 [mt76]
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&dev->lock#2);
      <Interrupt>
        lock(&dev->lock#2);
    
     *** DEADLOCK ***
    
    1 lock held by rmmod/1227:
     #0: ffff88815b5eb240 (&dev->mutex){....}-{3:3}, at: driver_detach+0xb5/0x110
    
    stack backtrace:
    CPU: 1 PID: 1227 Comm: rmmod Kdump: loaded Not tainted 5.9.0-rc6-wdn-src+ #14
    Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009
    Call Trace:
     dump_stack+0x77/0xa0
     mark_lock_irq.cold+0x15/0x39
     mark_lock+0x1fc/0x500
     mark_usage+0xc7/0x140
     __lock_acquire+0x20c/0x6b0
     ? find_held_lock+0x2b/0x80
     ? sched_clock_cpu+0xc/0xb0
     lock_acquire+0x9d/0x220
     ? mt76_dma_cleanup+0x125/0x150 [mt76]
     _raw_spin_lock+0x2c/0x70
     ? mt76_dma_cleanup+0x125/0x150 [mt76]
     mt76_dma_cleanup+0x125/0x150 [mt76]
     mt76x2_cleanup+0x5a/0x70 [mt76x2e]
     mt76x2e_remove+0x18/0x30 [mt76x2e]
     pci_device_remove+0x36/0xa0
     __device_release_driver+0x16c/0x220
     driver_detach+0xcf/0x110
     bus_remove_driver+0x56/0xca
     pci_unregister_driver+0x36/0x80
     __do_sys_delete_module.constprop.0+0x127/0x200
     ? syscall_enter_from_user_mode+0x1d/0x50
     ? trace_hardirqs_on+0x1c/0xe0
     do_syscall_64+0x33/0x80
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x7ff0da54e36b
    Code: 73 01 c3 48 8b 0d 2d 0b 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 0a 0c 00 f7 d8 64 89 01 48
    
    Fixes: dd57a95cfddc ("mt76: move txwi handling code to dma.c, since it is mmio specific")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b5b803ba5b7242a87f25ddc60d45cb53ee35efa
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Oct 8 15:51:56 2020 +0000

    mt76: set fops_tx_stats.owner to THIS_MODULE
    
    [ Upstream commit f9df085ce1be5c599e4df590ff7ba853786c6d95 ]
    
    If THIS_MODULE is not set, the module would be removed while debugfs is
    being used.
    It eventually makes kernel panic.
    
    Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 722faae3826ad45ea3207916f631e187ec93aab0
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Oct 8 15:51:57 2020 +0000

    mt76: mt7915: set fops_sta_stats.owner to THIS_MODULE
    
    [ Upstream commit 5efbe3b1b8992d5f837388091920945c23212159 ]
    
    If THIS_MODULE is not set, the module would be removed while debugfs is
    being used.
    It eventually makes kernel panic.
    
    Fixes: ec9742a8f38e ("mt76: mt7915: add .sta_add_debugfs support")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28f41cc1baed02f7ad2ccf597482f282299c7280
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Mon Oct 5 17:22:23 2020 +0200

    mt76: mt7663s: fix a possible ple quota underflow
    
    [ Upstream commit 1c79a190e94325e01811f653f770a34e816fdd8f ]
    
    Properly account current consumed ple quota in mt7663s_tx_pick_quota
    routine and avoid possible underflow.
    
    Fixes: 6ef2d665f64d ("mt76: mt7663s: split mt7663s_tx_update_sched in mt7663s_tx_{pick,update}_quota")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3164472e2ebfd09f1931f84bafe3831fcbfa940
Author: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Date:   Thu Dec 3 13:36:48 2020 +0100

    MIPS: Don't round up kernel sections size for memblock_add()
    
    [ Upstream commit d121f125af22a16f0f679293756d28a9691fa46d ]
    
    Linux doesn't own the memory immediately after the kernel image. On Octeon
    bootloader places a shared structure right close after the kernel _end,
    refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c.
    
    If check_kernel_sections_mem() rounds the PFNs up, first memblock_alloc()
    inside early_init_dt_alloc_memory_arch() <= device_tree_init() returns
    memory block overlapping with the above octeon_bootinfo structure, which
    is being overwritten afterwards.
    
    Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db4a90026e153c995ba33c95ef1f370e048d9f79
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 28cb1d639ee862df78ebe0a1e3c027159184153e
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 4771a82fa0dd772de4e677c8a2652fa4a82c409e
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:33:25 2020 +0800

    soc: rockchip: io-domain: Fix error return code in rockchip_iodomain_probe()
    
    [ Upstream commit c2867b2e710fc85bb39c6f6e5948450c48e8a33e ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: e943c43b32ce ("PM: AVS: rockchip-io: Move the driver to the rockchip specific drivers")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Link: https://lore.kernel.org/r/1607070805-33038-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64ae763eefd317459029a6cd9036612d0624b6a0
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 b23eae9fc72637690ec98dbfa5d0d5042d25da98
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Thu Dec 3 15:54:40 2020 -0800

    selftests/bpf: Fix invalid use of strncat in test_sockmap
    
    [ Upstream commit eceae70bdeaeb6b8ceb662983cf663ff352fbc96 ]
    
    strncat()'s third argument is how many bytes will be added *in addition* to
    already existing bytes in destination. Plus extra zero byte will be added
    after that. So existing use in test_sockmap has many opportunities to overflow
    the string and cause memory corruptions. And in this case, GCC complains for
    a good reason.
    
    Fixes: 16962b2404ac ("bpf: sockmap, add selftests")
    Fixes: 73563aa3d977 ("selftests/bpf: test_sockmap, print additional test options")
    Fixes: 1ade9abadfca ("bpf: test_sockmap, add options for msg_pop_data() helper")
    Fixes: 463bac5f1ca7 ("bpf, selftests: Add test for ktls with skb bpf ingress policy")
    Fixes: e9dd904708c4 ("bpf: add tls support for testing in test_sockmap")
    Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20201203235440.2302137-2-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4322f9a646535191f3da67a6a4932aba16d0f6aa
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Thu Dec 3 12:46:21 2020 -0800

    bpf: Fix bpf_put_raw_tracepoint()'s use of __module_address()
    
    [ Upstream commit 12cc126df82c96c89706aa207ad27c56f219047c ]
    
    __module_address() needs to be called with preemption disabled or with
    module_mutex taken. preempt_disable() is enough for read-only uses, which is
    what this fix does. Also, module_put() does internal check for NULL, so drop
    it as well.
    
    Fixes: a38d1107f937 ("bpf: support raw tracepoints in modules")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/bpf/20201203204634.1325171-2-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9cee260310155a2191595e5e91a76417196e168d
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date:   Wed Dec 2 09:17:32 2020 +0100

    scripts: kernel-doc: fix parsing function-like typedefs
    
    [ Upstream commit 7d2c6b1edf790d96e9017a0b27be2425e1af1532 ]
    
    Changeset 6b80975c6308 ("scripts: kernel-doc: fix typedef parsing")
    added support for things like:
    
            typedef unsigned long foo();
    
    However, it caused a regression on this prototype:
    
            typedef bool v4l2_check_dv_timings_fnc(const struct v4l2_dv_timings *t, void *handle);
    
    This is only noticed after adding a patch that checks if the
    kernel-doc identifier matches the typedef:
    
            ./scripts/kernel-doc -none $(git grep '^.. kernel-doc::' Documentation/ |cut -d ' ' -f 3|sort|uniq) 2>&1|grep expecting
            include/media/v4l2-dv-timings.h:38: warning: expecting prototype for typedef v4l2_check_dv_timings_fnc. Prototype was for typedef nc instead
    
    The problem is that, with the new parsing logic, it is not
    checking for complete words at the type part.
    
    Fix it by adding a \b at the end of each type word at the
    regex.
    
    fixes: 6b80975c6308 ("scripts: kernel-doc: fix typedef parsing")
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Link: https://lore.kernel.org/r/218ff56dcb8e73755005d3fb64586eb1841a276b.1606896997.git.mchehab+huawei@kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a8db263abc42acb4786c6aec68adaf6e0066608
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 94c84a4327d771a3419d1527e0cd8912e0ec1627
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Wed Dec 2 11:57:04 2020 +0200

    ARM: dts: at91: sam9x60ek: remove bypass property
    
    [ Upstream commit ab8a9bb41b2c330a0b280280bf37b6f3b1dd1e58 ]
    
    atmel,osc-bypass property sets the bit 1 at main oscillator register.
    On SAM9X60 this bit is not valid according to datasheet (chapter
    28.16.9 PMC Clock Generator Main Oscillator Register).
    
    Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
    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>
    Cc: Marco Cardellini <marco.cardellini@microchip.com>
    Link: https://lore.kernel.org/r/1606903025-14197-2-git-send-email-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit beef1b4383e7502b2d84bcfa153342540c2fffc4
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Thu Dec 3 10:33:06 2020 +0100

    libbpf: Sanitise map names before pinning
    
    [ Upstream commit 9cf309c56f7910a81fbe053b6f11c3b1f0987b12 ]
    
    When we added sanitising of map names before loading programs to libbpf, we
    still allowed periods in the name. While the kernel will accept these for
    the map names themselves, they are not allowed in file names when pinning
    maps. This means that bpf_object__pin_maps() will fail if called on an
    object that contains internal maps (such as sections .rodata).
    
    Fix this by replacing periods with underscores when constructing map pin
    paths. This only affects the paths generated by libbpf when
    bpf_object__pin_maps() is called with a path argument. Any pin paths set
    by bpf_map__set_pin_path() are unaffected, and it will still be up to the
    caller to avoid invalid characters in those.
    
    Fixes: 113e6b7e15e2 ("libbpf: Sanitise internal map names so they are not rejected by the kernel")
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20201203093306.107676-1-toke@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b113f3bf167fe23dea6b0a04d57865224bc2ad30
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Tue Nov 17 11:37:50 2020 +0100

    iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context
    
    [ Upstream commit 0178297c1e6898e2197fe169ef3be723e019b971 ]
    
    On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft
    interrupt expiry mode by default.
    
    The IIO hrtimer-trigger needs to run in hard interrupt context since it
    will end up calling generic_handle_irq() which has the requirement to run
    in hard interrupt context.
    
    Explicitly specify that the timer needs to run in hard interrupt context by
    using the HRTIMER_MODE_REL_HARD flag.
    
    Fixes: f5c2f0215e36 ("hrtimer: Move unmarked hrtimers to soft interrupt expiry on RT")
    Reported-by: Christian Eggers <ceggers@arri.de>
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://lore.kernel.org/r/20201117103751.16131-1-lars@metafoo.de
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e3847accafa3c6da69c7d66a44be407fed2556d
Author: Peter Collingbourne <pcc@google.com>
Date:   Wed Dec 2 23:51:10 2020 -0800

    arm64: mte: fix prctl(PR_GET_TAGGED_ADDR_CTRL) if TCF0=NONE
    
    [ Upstream commit 929c1f3384d7e5cd319d03242cb925c3f91236f7 ]
    
    Previously we were always returning a tag inclusion mask of zero via
    PR_GET_TAGGED_ADDR_CTRL if TCF0 was set to NONE. Fix it by making
    the code for the NONE case match the others.
    
    Signed-off-by: Peter Collingbourne <pcc@google.com>
    Link: https://linux-review.googlesource.com/id/Iefbea66cf7d2b4c80b82f9639b9ea7f33f7fac53
    Fixes: af5ce95282dc ("arm64: mte: Allow user control of the generated random tags via prctl()")
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Link: https://lore.kernel.org/r/20201203075110.2781021-1-pcc@google.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16cf69c25c96b366d77d9ffd2b5fce6394499e32
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date:   Wed Oct 28 21:12:30 2020 +0800

    clocksource/drivers/riscv: Make RISCV_TIMER depends on RISCV_SBI
    
    [ Upstream commit ab3105446f1ec4e98fadfc998ee24feec271c16c ]
    
    The riscv timer is set via SBI timer call, let's make RISCV_TIMER
    depends on RISCV_SBI, and it also fixes some build issue.
    
    Fixes: d5be89a8d118 ("RISC-V: Resurrect the MMIO timer implementation for M-mode systems")
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20201028131230.72907-1-wangkefeng.wang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df4411e4b8d09a75400ee72f1fdc5cd58bb96574
Author: Daniel Lezcano <daniel.lezcano@linaro.org>
Date:   Wed Nov 25 11:23:45 2020 +0100

    clocksource/drivers/ingenic: Fix section mismatch
    
    [ Upstream commit 5bd7cb29eceb52e4b108917786fdbf2a2c2048ef ]
    
    The function ingenic_tcu_get_clock() is annotated for the __init
    section but it is actually called from the online cpu callback.
    
    That will lead to a crash if a CPU is hotplugged after boot time.
    
    Remove the __init annotation for the ingenic_tcu_get_clock()
    function.
    
    Fixes: f19d838d08fc (clocksource/drivers/ingenic: Add high resolution timer support for SMP/SMT)
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Reviewed-by: Paul Cercueil <paul@crapouillou.net>
    Tested-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
    Link: https://lore.kernel.org/r/20201125102346.1816310-1-daniel.lezcano@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93bf920799d92d883cc7240ee8bc648d5534117c
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 e2983080b0230c7e6316e0c955bf12abaad149fa
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Nov 11 14:47:06 2020 +0800

    clocksource/drivers/orion: Add missing clk_disable_unprepare() on error path
    
    [ Upstream commit c1e6cad00aa2f17845e7270e38ff3cc82c7b022a ]
    
    After calling clk_prepare_enable(), clk_disable_unprepare() need
    be called on error path.
    
    Fixes: fbe4b3566ddc ("clocksource/drivers/orion: Convert init function...")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20201111064706.3397156-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba6a7e6ca5b722792887e9765d673b1953dfbc39
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Thu Nov 26 11:54:40 2020 -0500

    powerpc/perf: Fix the PMU group constraints for threshold events in power10
    
    [ Upstream commit 0263bbb377af0c2d38bc8b2ad2ff147e240094de ]
    
    The PMU group constraints mask for threshold events covers
    all thresholding bits which includes threshold control value
    (start/stop), select value as well as thresh_cmp value (MMCRA[9:18].
    In power9, thresh_cmp bits were part of the event code. But in case
    of power10, thresh_cmp bits are not part of event code due to
    inclusion of MMCR3 bits. Hence thresh_cmp is not valid for
    group constraints for power10.
    
    Fix the PMU group constraints checking for threshold events in
    power10 by using constraint mask and value for only threshold control
    and select bits.
    
    Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
    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/1606409684-1589-4-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e559aaba71b9d1eebe8e3ac8627b641686dc04d8
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Thu Nov 26 11:54:39 2020 -0500

    powerpc/perf: Update the PMU group constraints for l2l3 events in power10
    
    [ Upstream commit e924be7b0b0d1f37d0509c854a92c7a71e3cdfe7 ]
    
    In Power9, L2/L3 bus events are always available as a
    "bank" of 4 events. To obtain the counts for any of the
    l2/l3 bus events in a given bank, the user will have to
    program PMC4 with corresponding l2/l3 bus event for that
    bank.
    
    Commit 59029136d750 ("powerpc/perf: Add constraints for power9 l2/l3 bus events")
    enforced this rule in Power9. But this is not valid for
    Power10, since in Power10 Monitor Mode Control Register2
    (MMCR2) has bits to configure l2/l3 event bits. Hence remove
    this PMC4 constraint check from power10.
    
    Since the l2/l3 bits in MMCR2 are not per-pmc, patch handles
    group constrints checks for l2/l3 bits in MMCR2.
    
    Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
    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/1606409684-1589-3-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0760233fd45070542fbc4f1b1156296fcde096bb
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Thu Nov 26 11:54:38 2020 -0500

    powerpc/perf: Fix to update radix_scope_qual in power10
    
    [ Upstream commit d3afd28cd2f35b2a1046b76e0cf010b684da2e84 ]
    
    power10 uses bit 9 of the raw event code as RADIX_SCOPE_QUAL.
    This bit is used for enabling the radix process events.
    Patch fixes the PMU counter support functions to program bit
    18 of MMCR1 ( Monitor Mode Control Register1 ) with the
    RADIX_SCOPE_QUAL bit value. Since this field is not per-pmc,
    add this to PMU group constraints to make sure events in a
    group will have same bit value for this field. Use bit 21 as
    constraint bit field for radix_scope_qual. Patch also updates
    the power10 raw event encoding layout information, format field
    and constraints bit layout to include the radix_scope_qual bit.
    
    Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
    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/1606409684-1589-2-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36daf5b174a1fa7475b8e0edfc6547880d677fe9
Author: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Date:   Mon Nov 30 09:14:06 2020 +0530

    powerpc/xmon: Fix build failure for 8xx
    
    [ Upstream commit f3e90408019b353fd1fcd338091fb8d3c4a1c1a5 ]
    
    With CONFIG_PPC_8xx and CONFIG_XMON set, kernel build fails with
    
      arch/powerpc/xmon/xmon.c:1379:12: error: 'find_free_data_bpt' defined
      but not used [-Werror=unused-function]
    
    Fix it by enclosing find_free_data_bpt() inside #ifndef CONFIG_PPC_8xx.
    
    Fixes: 30df74d67d48 ("powerpc/watchpoint/xmon: Support 2nd DAWR")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201130034406.288047-1-ravi.bangoria@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 746ef5ac254c01cef49d85dde8b321475133c752
Author: Jordan Niethe <jniethe5@gmail.com>
Date:   Mon Nov 30 11:44:04 2020 +1100

    powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
    
    [ Upstream commit fe18a35e685c9bdabc8b11b3e19deb85a068b75d ]
    
    Commit 63ce271b5e37 ("powerpc/prom: convert PROM_BUG() to standard
    trap") added an EMIT_BUG_ENTRY for the trap after the branch to
    start_kernel(). The EMIT_BUG_ENTRY was for the address "0b", however the
    trap was not labeled with "0". Hence the address used for bug is in
    relative_toc() where the previous "0" label is. Label the trap as "0" so
    the correct address is used.
    
    Fixes: 63ce271b5e37 ("powerpc/prom: convert PROM_BUG() to standard trap")
    Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201130004404.30953-1-jniethe5@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 668f649850ae477df13155b2ee416c43331a291d
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Mon Nov 23 21:40:40 2020 -0500

    powerpc/perf: Fix crash with is_sier_available when pmu is not set
    
    [ Upstream commit f75e7d73bdf73f07b0701a6d21c111ef5d9021dd ]
    
    On systems without any specific PMU driver support registered, running
    'perf record' with —intr-regs  will crash ( perf record -I <workload> ).
    
    The relevant portion from crash logs and Call Trace:
    
    Unable to handle kernel paging request for data at address 0x00000068
    Faulting instruction address: 0xc00000000013eb18
    Oops: Kernel access of bad area, sig: 11 [#1]
    CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le #1
    NIP:  c00000000013eb18 LR: c000000000139f2c CTR: c000000000393d80
    REGS: c0000004a07ab4f0 TRAP: 0300   Not tainted  (4.18.0-193.el8.ppc64le)
    NIP [c00000000013eb18] is_sier_available+0x18/0x30
    LR [c000000000139f2c] perf_reg_value+0x6c/0xb0
    Call Trace:
    [c0000004a07ab770] [c0000004a07ab7c8] 0xc0000004a07ab7c8 (unreliable)
    [c0000004a07ab7a0] [c0000000003aa77c] perf_output_sample+0x60c/0xac0
    [c0000004a07ab840] [c0000000003ab3f0] perf_event_output_forward+0x70/0xb0
    [c0000004a07ab8c0] [c00000000039e208] __perf_event_overflow+0x88/0x1a0
    [c0000004a07ab910] [c00000000039e42c] perf_swevent_hrtimer+0x10c/0x1d0
    [c0000004a07abc50] [c000000000228b9c] __hrtimer_run_queues+0x17c/0x480
    [c0000004a07abcf0] [c00000000022aaf4] hrtimer_interrupt+0x144/0x520
    [c0000004a07abdd0] [c00000000002a864] timer_interrupt+0x104/0x2f0
    [c0000004a07abe30] [c0000000000091c4] decrementer_common+0x114/0x120
    
    When perf record session is started with "-I" option, capturing registers
    on each sample calls is_sier_available() to check for the
    SIER (Sample Instruction Event Register) availability in the platform.
    This function in core-book3s accesses 'ppmu->flags'. If a platform specific
    PMU driver is not registered, ppmu is set to NULL and accessing its
    members results in a crash. Fix the crash by returning false in
    is_sier_available() if ppmu is not set.
    
    Fixes: 333804dc3b7a ("powerpc/perf: Update perf_regs structure to include SIER")
    Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
    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/1606185640-1720-1-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8486f6f9de6beb2892f853d0af2c51dc06e2baab
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 1067e2496e936d55b24639fc583713ae05e71f61
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Mon Nov 16 15:18:01 2020 +0100

    media: tvp5150: Fix wrong return value of tvp5150_parse_dt()
    
    [ Upstream commit eb08c48132a1f594478ab9fa2b6ee646c3513a49 ]
    
    If of_graph_get_endpoint_by_regs() return NULL, it will return 0 rather
    than an errno, because we doesn't initialize the return value.
    
    Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c14fb58a1a7b1c987eeb8bc107faf3f628f76d5
Author: Hyeongseok Kim <hyeongseok@gmail.com>
Date:   Thu Nov 12 18:14:54 2020 +0900

    f2fs: fix double free of unicode map
    
    [ Upstream commit 89ff6005039a878afac87889fee748fa3f957c3a ]
    
    In case of retrying fill_super with skip_recovery,
    s_encoding for casefold would not be loaded again even though it's
    already been freed because it's not NULL.
    Set NULL after free to prevent double freeing when unmount.
    
    Fixes: eca4873ee1b6 ("f2fs: Use generic casefolding support")
    Signed-off-by: Hyeongseok Kim <hyeongseok@gmail.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55dbc5e2d9c95d2654cd50d91cdd90f807db8f15
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Wed Dec 2 22:53:20 2020 +0800

    hwmon: (ina3221) Fix PM usage counter unbalance in ina3221_write_enable
    
    [ Upstream commit bce776f10069c806290eaac712ba73432ae8ecd7 ]
    
    pm_runtime_get_sync will increment pm usage counter
    even it failed. Forgetting to putting operation will
    result in reference leak here. We fix it by replacing
    it with pm_runtime_resume_and_get to keep usage counter
    balanced. It depends on the mainline commit[PM: runtime:
    Add pm_runtime_resume_and_get to deal with usagecounter].
    
    Fixes: 323aeb0eb5d9a ("hwmon: (ina3221) Add PM runtime support")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201202145320.1135614-1-zhangqilong3@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a08dbd0120016cf7f7f1dcb72ea5c3aa90cd510d
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 79449799269fb4788c2fcf75caf478db270c677a
Author: Mickaël Salaün <mic@linux.microsoft.com>
Date:   Wed Dec 2 17:26:43 2020 +0100

    selftests/seccomp: Update kernel config
    
    [ Upstream commit 2c07343abd8932200a45ff7b10950e71081e9e77 ]
    
    seccomp_bpf.c uses unshare(CLONE_NEWPID), which requires CONFIG_PID_NS
    to be set.
    
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
    Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
    Acked-by: Tycho Andersen <tycho@tycho.pizza>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20201202162643.249276-1-mic@digikod.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb9cc35ae98be96264791dac581eeb6ba95c53ab
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 0e1c02e4e08540412cd403cad9d862eaf8d4f2b5
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 7941ee42dccabbbea7be8985f73945c5caaacc57
Author: Fedor Tokarev <ftokarev@gmail.com>
Date:   Thu Oct 15 16:59:08 2020 +0300

    net: sunrpc: Fix 'snprintf' return value check in 'do_xprt_debugfs'
    
    [ Upstream commit 35a6d396721e28ba161595b0fc9e8896c00399bb ]
    
    'snprintf' returns the number of characters which would have been written
    if enough space had been available, excluding the terminating null byte.
    Thus, the return value of 'sizeof(buf)' means that the last character
    has been dropped.
    
    Signed-off-by: Fedor Tokarev <ftokarev@gmail.com>
    Fixes: 2f34b8bfae19 ("SUNRPC: add links for all client xprts to debugfs")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77303b6b5e4a27f6bb08a334451c95889a049ccd
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Nov 13 21:42:16 2020 -0500

    NFSv4: Fix the alignment of page data in the getdeviceinfo reply
    
    [ Upstream commit 046e5ccb4198b990190e11fb52fd9cfd264402eb ]
    
    We can fit the device_addr4 opaque data padding in the pages.
    
    Fixes: cf500bac8fd4 ("SUNRPC: Introduce rpc_prepare_reply_pages()")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1e628f9105176b9ae913b508339a74e26459d1c
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 78c9026a727062c204a3d8fe09953f904b3c167b
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 d1296acac0c1925be1f16f81d6deffb899467ef7
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Oct 22 17:40:33 2020 -0400

    SUNRPC: rpc_wake_up() should wake up tasks in the correct order
    
    [ Upstream commit e4c72201b6ec3173dfe13fa2e2335a3ad78d4921 ]
    
    Currently, we wake up the tasks by priority queue ordering, which means
    that we ignore the batching that is supposed to help with QoS issues.
    
    Fixes: c049f8ea9a0d ("SUNRPC: Remove the bh-safe lock requirement on the rpc_wait_queue->lock")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd6019d83a9ab2df0973c0d503826ce1b38e1d1a
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 96e8abed38b1f70a2c82b9eb41f0863dd8530060
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 6165f20d351dbc1536a57b6d3592fc655192df61
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 01c0691ead1e2ac8169459c8dbc05761bcf55145
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Nov 24 17:59:16 2020 +0200

    ath11k: Fix an error handling path
    
    [ Upstream commit e7bcc145bcd035e56da7b97b033c463b32a5ff80 ]
    
    If 'kzalloc' fails, we must return an error code.
    
    While at it, remove a useless initialization of 'err' which could hide the
    issue.
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201122173943.1366167-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08c7e5615496a5ed9f1c80bcd710b677946f9d7e
Author: Sven Eckelmann <sven@narfation.org>
Date:   Tue Nov 24 17:59:15 2020 +0200

    ath11k: Reset ath11k_skb_cb before setting new flags
    
    [ Upstream commit 5da7acfec5ec55aa0b69b8760f1d2116b4e2ad26 ]
    
    It was observed that the codepath for the ATH11K_SKB_HW_80211_ENCAP was
    used even when the IEEE80211_TX_CTRL_HW_80211_ENCAP was not enabled for a
    an skbuff. This became even more prominent when the QCAs wlan-open patchset
    for ath11k [1] was applied and a sane looking fix just caused crashes when
    injecting frames via a monitor interface (for example with ratechecker):
    
      [   86.963152] Unable to handle kernel NULL pointer dereference at virtual address 00000338
      [   86.963192] pgd = ffffffc0008f0000
      [   86.971034] [00000338] *pgd=0000000051706003, *pud=0000000051706003, *pmd=0000000051707003, *pte=00e800000b000707
      [   86.984292] Internal error: Oops: 96000006 [#1] PREEMPT SMP
      [...]
      [   87.713339] [<ffffffbffc802480>] ieee80211_tx_status_8023+0xf8/0x220 [mac80211]
      [   87.715654] [<ffffffbffc98bad4>] ath11k_dp_tx_completion_handler+0x42c/0xa10 [ath11k]
      [   87.722924] [<ffffffbffc989190>] ath11k_dp_service_srng+0x70/0x3c8 [ath11k]
      [   87.730831] [<ffffffbffca03460>] 0xffffffbffca03460
      [   87.737599] [<ffffffc00046ef58>] net_rx_action+0xf8/0x288
      [   87.742462] [<ffffffc000097554>] __do_softirq+0xfc/0x220
      [   87.748014] [<ffffffc000097900>] irq_exit+0x98/0xe8
      [   87.753396] [<ffffffc0000cf188>] __handle_domain_irq+0x90/0xb8
      [   87.757999] [<ffffffc000081ca4>] gic_handle_irq+0x6c/0xc8
      [   87.763899] Exception stack(0xffffffc00081bdc0 to 0xffffffc00081bef0)
    
    Problem is that the state of ath11k_skb_cb->flags must be considered
    unknown and could contain anything when it is not manually initialized. So
    it could also contain ATH11K_SKB_HW_80211_ENCAP. And this can result in the
    code to assume that the ath11k_skb_cb->vif is set - even when this is not
    always the case for non ATH11K_SKB_HW_80211_ENCAP transmissions.
    
    Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00026-QCAHKSWPL_SILICONZ-2
    
    [1] https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches?h=NHSS.QSDK.11.4.r3
        (162 patches at the moment which are often not upstreamed but essential
         to get ath11k working)
    
    Fixes: e7f33e0c52c0 ("ath11k: add tx hw 802.11 encapsulation offloading support")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201119154235.263250-2-sven@narfation.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 345511c3f49608f80d5893181893e286c3d3c28b
Author: Sven Eckelmann <sven@narfation.org>
Date:   Tue Nov 24 17:59:15 2020 +0200

    ath11k: Don't cast ath11k_skb_cb to ieee80211_tx_info.control
    
    [ Upstream commit f4d291b43f809b74c66b21f5190cd578af43070b ]
    
    The driver_data area of ieee80211_tx_info is used in ath11k for
    ath11k_skb_cb. The first function in the TX patch which rewrites it to
    ath11k_skb_cb is already ath11k_mac_op_tx. No one else in the code path
    must use it for something else before it reinitializes it. Otherwise the
    data has to be considered uninitialized or corrupt.
    
    But the ieee80211_tx_info.control shares exactly the same area as
    ieee80211_tx_info.driver_data and ath11k is still using it. This results in
    best case in a
    
      ath11k c000000.wifi1: no vif found for mgmt frame, flags 0x0
    
    or (slightly worse) in a kernel oops.
    
    Instead, the interesting data must be moved first into the ath11k_skb_cb
    and ieee80211_tx_info.control must then not be used anymore.
    
    Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00026-QCAHKSWPL_SILICONZ-2
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201119154235.263250-1-sven@narfation.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa7396d8b36ba78a9cb24e94d8ce35e8736a1fc6
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Wed Aug 5 12:57:21 2020 +0200

    media: i2c: imx219: Selection compliance fixes
    
    [ Upstream commit 1ed36ecd1459b653cced8929bfb37dba94b64c5d ]
    
    To comply with the intended usage of the V4L2 selection target when
    used to retrieve a sensor image properties, adjust the rectangles
    returned by the imx219 driver.
    
    The top/left crop coordinates of the TGT_CROP rectangle were set to
    (0, 0) instead of (8, 8) which is the offset from the larger physical
    pixel array rectangle. This was also a mismatch with the default values
    crop rectangle value, so this is corrected. Found with v4l2-compliance.
    
    While at it, add V4L2_SEL_TGT_CROP_BOUNDS support: CROP_DEFAULT and
    CROP_BOUNDS have the same size as the non-active pixels are not readable
    using the selection API. Found with v4l2-compliance.
    
    [reword commit message, use macros for pixel offsets]
    
    Fixes: e6d4ef7d58aa7 ("media: i2c: imx219: Implement get_selection")
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4440b4861798f7f8feb72dd36e7aaa0b77635f00
Author: Jacopo Mondi <jacopo+renesas@jmondi.org>
Date:   Fri Nov 20 17:15:29 2020 +0100

    media: rdacm20: Enable GPIO1 explicitly
    
    [ Upstream commit 7fe1d4453fb6bf103d668a19d957a7b2fc21887c ]
    
    The MAX9271 GPIO1 line that controls the sensor reset is by default
    enabled after a serializer chip reset.
    
    As rdacm20 does not go through an explicit serializer reset, make sure
    GPIO1 is enabled to make the camera module driver more robust.
    
    Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver")
    Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 978649ab70c17e282af5715b8e01a078f5b27dbc
Author: Jacopo Mondi <jacopo+renesas@jmondi.org>
Date:   Fri Nov 20 17:15:28 2020 +0100

    media: max9271: Fix GPIO enable/disable
    
    [ Upstream commit 909a0a189c677307edd461e21fd962784370d27f ]
    
    Fix GPIO enable/disable operations which wrongly read the 0x0f register
    to obtain the current mask of the enabled lines instead of using
    the correct 0x0e register.
    
    Also fix access to bit 0 of the register which is marked as reserved.
    
    Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver")
    Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af85e2467900e266b3dfb253b0a799ae92312e88
Author: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Date:   Tue Dec 1 13:11:50 2020 -0800

    ASoC: Intel: Boards: tgl_max98373: update TDM slot_width
    
    [ Upstream commit 0d7f2459ae926a964ab211aac413d72074131727 ]
    
    Speaker amp's SSP bclk configuration was changed in the topology file to be
    based on 12.288MHz and dai_ops->hw_params is based on s32le format.
    But, the TDM slot size remained set to 24 bits.
    This inconsistency created audible noises and needs to be corrected.
    This patch updates TDM slot width to 32.
    
    Fixes: bc7477fc2ab4 ("ASoC: Intel: Boards: tgl_max98373: Update TDM configuration in hw_params")
    
    Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20201201211150.433472-1-ranjani.sridharan@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e94331e0d7d2568157f18ab4d19df5b770de35f5
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 df40cc8c1c860a2febfad02e2a2dad2c37ff01ad
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Nov 24 21:07:42 2020 +0800

    soundwire: master: use pm_runtime_set_active() on add
    
    [ Upstream commit e04e60fce47e61743a8726d76b0149c1f4ad8957 ]
    
    The 'master' device acts as a glue layer used during bus
    initialization only, and it needs to be 'transparent' for pm_runtime
    management. Its behavior should be that it becomes active when one of
    its children becomes active, and suspends when all of its children are
    suspended.
    
    In our tests on Intel platforms, we routinely see these sort of
    warnings on the initial boot:
    
    [ 21.447345] rt715 sdw:3:25d:715:0: runtime PM trying to activate
    child device sdw:3:25d:715:0 but parent (sdw-master-3) is not active
    
    This is root-caused to a missing setup to make the device 'active' on
    probe. Since we don't want the device to remain active forever after
    the probe, the autosuspend configuration is also enabled at the end of
    the probe - the device will actually autosuspend only in the case
    where there are no devices physically attached. In practice, the
    master device will suspend when all its children are no longer active.
    
    Fixes: bd84256e86ecf ('soundwire: master: enable pm runtime')
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@linux.intel.com>
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Link: https://lore.kernel.org/r/20201124130742.10986-1-yung-chuan.liao@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3592fa49daf709e8a5d311a7c505e27c4f5e7a7
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Mon Nov 30 10:28:04 2020 +0000

    mailbox: arm_mhu_db: Fix mhu_db_shutdown by replacing kfree with devm_kfree
    
    [ Upstream commit 9905f728b0bda737fe2c2afd7c24f3365a45cc7b ]
    
    The mhu_db_channel info is allocated per channel using devm_kzalloc from
    mhu_db_mbox_xlate which gets called from mbox_request_channel. However
    we are releasing the allocated mhu_db_channel info using plain kfree from
    mhu_db_shutdown which is called from mbox_free_channel.
    
    This leads to random crashes when the channel is freed like below one:
    
      Unable to handle kernel paging request at virtual address 0080000400000008
      [0080000400000008] address between user and kernel address ranges
      Internal error: Oops: 96000044 [#1] PREEMPT SMP
      Modules linked in: scmi_module(-)
      CPU: 1 PID: 2212 Comm: rmmod Not tainted 5.10.0-rc5 #31
      Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno
            Development Platform, BIOS EDK II Nov 19 2020
      pstate: 20000085 (nzCv daIf -PAN -UAO -TCO BTYPE=--)
      pc : release_nodes+0x74/0x230
      lr : devres_release_all+0x40/0x68
      Call trace:
       release_nodes+0x74/0x230
       devres_release_all+0x40/0x68
       device_release_driver_internal+0x12c/0x1f8
       driver_detach+0x58/0xe8
       bus_remove_driver+0x64/0xe0
       driver_unregister+0x38/0x68
       platform_driver_unregister+0x1c/0x28
       scmi_driver_exit+0x38/0x44 [scmi_module]
       __arm64_sys_delete_module+0x188/0x260
       el0_svc_common.constprop.0+0x80/0x1a8
       do_el0_svc+0x2c/0x98
       el0_sync_handler+0x160/0x168
       el0_sync+0x174/0x180
      Code: 1400000d eb07009f 54000460 f9400486 (f90004a6)
      ---[ end trace c55ffd306c140233 ]---
    
    Fix it by replacing kfree with devm_kfree as required.
    
    Fixes: 7002ca237b21 ("mailbox: arm_mhu: Add ARM MHU doorbell driver")
    Reported-by: Cristian Marussi <cristian.marussi@arm.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Tested-by: Cristian Marussi <cristian.marussi@arm.com>
    Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 482d2345bf8f5cc8cc4340e39926f89294847369
Author: Yangyang Li <liyangyang20@huawei.com>
Date:   Sat Nov 28 18:22:38 2020 +0800

    RDMA/hns: Bugfix for calculation of extended sge
    
    [ Upstream commit d34895c319faa1e0fc1a48c3b06bba6a8a39ba44 ]
    
    Page alignment is required when setting the number of extended sge
    according to the hardware's achivement. If the space of needed extended
    sge is greater than one page, the roundup_pow_of_two() can ensure
    that. But if the needed extended sge isn't 0 and can not be filled in a
    whole page, the driver should align it specifically.
    
    Fixes: 54d6638765b0 ("RDMA/hns: Optimize WQE buffer size calculating process")
    Link: https://lore.kernel.org/r/1606558959-48510-3-git-send-email-liweihang@huawei.com
    Signed-off-by: Yangyang Li <liyangyang20@huawei.com>
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5c7bc609740d0a1b1218187a4c67ba4fae76a13
Author: Lang Cheng <chenglang@huawei.com>
Date:   Sat Nov 28 18:22:37 2020 +0800

    RDMA/hns: Fix 0-length sge calculation error
    
    [ Upstream commit 0fd0175e30e487f8d70ecb2cdd67fbb514fdf50f ]
    
    One RC SQ WQE can store 2 sges but UD can't, so ignore 2 valid sges of
    wr.sglist for RC which have been filled in WQE before setting extended
    sge.  Either of RC and UD can not contain 0-length sges, so these 0-length
    sges should be skipped.
    
    Fixes: 54d6638765b0 ("RDMA/hns: Optimize WQE buffer size calculating process")
    Link: https://lore.kernel.org/r/1606558959-48510-2-git-send-email-liweihang@huawei.com
    Signed-off-by: Lang Cheng <chenglang@huawei.com>
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38fcd69c7ae53ba5d2f6755ef7417e39e4ee213f
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 f107dfac508ff58649db32eacd918b567867507d
Author: Maxim Kochetkov <fido_max@inbox.ru>
Date:   Tue Dec 1 11:59:16 2020 +0300

    spi: spi-fsl-dspi: Use max_native_cs instead of num_chipselect to set SPI_MCR
    
    [ Upstream commit 2c2b3ad2c4c801bab1eec7264ea6991b1e4e8f2c ]
    
    If cs-gpios property is used in devicetree then ctlr->num_chipselect value
    may be changed by spi_get_gpio_descs().
    So use ctlr->max_native_cs instead of ctlr->num_chipselect to set SPI_MCR
    
    Fixes: 4fcc7c2292de (spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR)
    Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
    Link: https://lore.kernel.org/r/20201201085916.63543-1-fido_max@inbox.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee9f3f0ff49649c9e763d7ec10be0abfdc497faf
Author: Ahmed S. Darwish <a.darwish@linutronix.de>
Date:   Thu Nov 26 14:29:39 2020 +0100

    scsi: pm80xx: Do not sleep in atomic context
    
    [ Upstream commit 4ba9e516573e60c471c01bb369144651f6f8d50b ]
    
    hw_event_sas_phy_up() is used in hardirq/softirq context:
    
     pm8001_interrupt_handler_msix() || pm8001_interrupt_handler_intx() || pm8001_tasklet
       => PM8001_CHIP_DISP->isr() = pm80xx_chip_isr()
         => process_oq() [spin_lock_irqsave(&pm8001_ha->lock,)]
           => process_one_iomb()
             => mpi_hw_event()
               => hw_event_sas_phy_up()
                 => msleep(200)
    
    Revert the msleep() back to an mdelay() to avoid sleeping in atomic
    context.
    
    Link: https://lore.kernel.org/r/20201126132952.2287996-2-bigeasy@linutronix.de
    Fixes: 4daf1ef3c681 ("scsi: pm80xx: Convert 'long' mdelay to msleep")
    Cc: Vikram Auradkar <auradkar@google.com>
    Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
    Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ca2795bfe22a847f24047f0fb1f29790a39a5dc
Author: Xiang Chen <chenxiang66@hisilicon.com>
Date:   Tue Nov 24 16:46:33 2020 +0800

    scsi: hisi_sas: Fix up probe error handling for v3 hw
    
    [ Upstream commit 2ebde94f2ea4cffd812ece2f318c2f4922239b1d ]
    
    Fix some rollbacks in function hisi_sas_v3_probe() and
    interrupt_init_v3_hw().
    
    Link: https://lore.kernel.org/r/1606207594-196362-3-git-send-email-john.garry@huawei.com
    Fixes: 8d98416a55eb ("scsi: hisi_sas: Switch v3 hw to MQ")
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9e71ed020b9d7f1f91230762e23c653f78f73f6
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Nov 17 09:13:22 2020 +0800

    soc: amlogic: canvas: add missing put_device() call in meson_canvas_get()
    
    [ Upstream commit 28f851e6afa858f182802e23ac60c3ed7d1c04a1 ]
    
    if of_find_device_by_node() succeed, meson_canvas_get() doesn't have
    a corresponding put_device(). Thus add put_device() to fix the exception
    handling for this function implementation.
    
    Fixes: 382f8be04551 ("soc: amlogic: canvas: Fix meson_canvas_get when probe failed")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/20201117011322.522477-1-yukuai3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67d91e51f98f4dd6761a671c89799d4bb07fa7b2
Author: Dongjin Kim <tobetter@gmail.com>
Date:   Mon Nov 30 15:03:20 2020 +0900

    arm64: dts: meson-sm1: fix typo in opp table
    
    [ Upstream commit b6a1c8a1eaa73b1e2ae251399308e9445d74cef7 ]
    
    The freqency 1512000000 should be 1500000000.
    
    Signed-off-by: Dongjin Kim <tobetter@gmail.com>
    Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS")
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/20201130060320.GA30098@anyang-linuxfactory-or-kr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 95fae43b04e49c7cc073c75ea5aa4171077ce65e
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 3ff34b89a43000b403e5ea098bb9d2582ead15d6
Author: Roman Bacik <roman.bacik@broadcom.com>
Date:   Thu Oct 1 11:30:53 2020 +0530

    PCI: iproc: Invalidate correct PAXB inbound windows
    
    [ Upstream commit 89bbcaac3dff21f3567956b3416f5ec8b45f5555 ]
    
    Second stage bootloaders prior to Linux boot may use all inbound windows
    including IARR1/IMAP1. We need to ensure that all previous configuration
    of inbound windows are invalidated during the initialization stage of
    the Linux iProc PCIe driver so let's add a fix to define and invalidate
    IARR1/IMAP1 because it is currently missing, fixing the issue.
    
    Link: https://lore.kernel.org/r/20201001060054.6616-3-srinath.mannam@broadcom.com
    Fixes: 9415743e4c8a ("PCI: iproc: Invalidate PAXB address mapping")
    Signed-off-by: Roman Bacik <roman.bacik@broadcom.com>
    Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
    [lorenzo.pieralisi@arm.com: commit log]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98518a523354241049d409c9a597939dff23789b
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 2df49a5de565ba5ed1c492e83e01b7d5d7c3a35d
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 3ce25814038050fa21b81d6ec55d1d4d59175b1a
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 25cff7f514188f470aa5cfbf5c8d122ff0e68a25
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Mon Nov 30 11:00:28 2020 -0600

    arm64: dts: qcom: c630: Fix pinctrl pins properties
    
    [ Upstream commit f55d373f7953909160cb4c1398f62123cdbe7650 ]
    
    The "pins" property takes an array of pin _names_, not pin numbers. Fix
    this.
    
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630")
    Link: https://lore.kernel.org/r/20201130170028.319798-1-bjorn.andersson@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71d0ca4e29eefbd272c60791a3f85f89514f7c4e
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Mon Nov 30 10:59:24 2020 -0600

    arm64: dts: qcom: c630: Polish i2c-hid devices
    
    [ Upstream commit 11d0e4f281565ef757479764ce7fd8d35eeb01b0 ]
    
    The numbering of the i2c busses differs from ACPI and a number of typos
    was made in the original patch. Further more the irq flags for the
    various resources was not correct and i2c3 only has one of the two
    client devices active in any one device.
    
    Also label the various devices, for easier comparison with the ACPI
    tables.
    
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630")
    Link: https://lore.kernel.org/r/20201130165924.319708-1-bjorn.andersson@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ad229df47324a453f86612c42144cca053f9a43
Author: JC Kuo <jckuo@nvidia.com>
Date:   Tue Nov 17 16:38:03 2020 +0800

    phy: tegra: xusb: Fix usb_phy device driver field
    
    [ Upstream commit 4ea0bf2a52f1eea76578eac5a9148d95f5e181c0 ]
    
    In commit "phy: tegra: xusb: Add usb-phy support", an OTG capable PHY
    device, such as phy-usb2.0 device of Jetson-TX1 platform, will be
    bound to the tegra-xusb-padctl driver by the following line in
    tegra_xusb_setup_usb_role_switch().
    
            port->usb_phy.dev->driver = port->padctl->dev->driver;
    
    With this, dev_pm_ops set of tegra-xusb-padctl driver will be invoked
    for the OTG capable PHY incorrectly as below logs show.
    
    This commit fixes the issue by assigning an empty driver to it.
    
    [  153.451108] tegra-xusb-padctl phy-usb2.0: > tegra_xusb_padctl_suspend_noirq(dev=ffff000080917000)
    [  153.460353] tegra-xusb-padctl phy-usb2.0:   driver: ffff8000114453e0 (tegra_xusb_padctl_driver)
    [  153.469245] tegra-xusb-padctl phy-usb2.0:   padctl: ffff0000829f6480
    [  153.475772] tegra-xusb-padctl phy-usb2.0:     soc: ef7bdd7fffffffff (0xef7bdd7fffffffff)
    [  153.484061] Unable to handle kernel paging request at virtual address 007bdd800000004f
    [  153.492132] Mem abort info:
    [  153.495083]   ESR = 0x96000004
    [  153.498308]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  153.503771]   SET = 0, FnV = 0
    [  153.506979]   EA = 0, S1PTW = 0
    [  153.510260] Data abort info:
    [  153.513200]   ISV = 0, ISS = 0x00000004
    [  153.517181]   CM = 0, WnR = 0
    [  153.520302] [007bdd800000004f] address between user and kernel address ranges
    [  153.527600] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [  153.533231] Modules linked in: nouveau panel_simple tegra_video(C) tegra_drm drm_ttm_helper videobuf2_dma_contig ttm videobuf2_memops cec videobuf2_v4l2 videobuf2_common drm_kms_helper v4l2_fwnode videodev drm mc snd_hda_codec_hdmi cdc_ether usbnet snd_hda_tegra r8152 crct10dif_ce snd_hda_codec snd_hda_core tegra_xudc host1x lp855x_bl at24 ip_tables x_tables ipv6
    [  153.566417] CPU: 0 PID: 300 Comm: systemd-sleep Tainted: G         C        5.10.0-rc3-next-20201113-00019-g5c064d5372b0-dirty #624
    [  153.578283] Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
    [  153.584281] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
    [  153.590381] pc : tegra_xusb_padctl_suspend_noirq+0x88/0x100
    [  153.596016] lr : tegra_xusb_padctl_suspend_noirq+0x80/0x100
    [  153.601632] sp : ffff8000120dbb60
    [  153.604999] x29: ffff8000120dbb60 x28: ffff000080a1df00
    [  153.610430] x27: 0000000000000002 x26: ffff8000106f8540
    [  153.615858] x25: ffff8000113ac4a4 x24: ffff80001148c198
    [  153.621277] x23: ffff800010c4538c x22: 0000000000000002
    [  153.626692] x21: ffff800010ccde80 x20: ffff0000829f6480
    [  153.632107] x19: ffff000080917000 x18: 0000000000000030
    [  153.637521] x17: 0000000000000000 x16: 0000000000000000
    [  153.642933] x15: ffff000080a1e380 x14: 74636461702d6273
    [  153.648346] x13: ffff8000113ad058 x12: 0000000000000f39
    [  153.653759] x11: 0000000000000513 x10: ffff800011405058
    [  153.659176] x9 : 00000000fffff000 x8 : ffff8000113ad058
    [  153.664590] x7 : ffff800011405058 x6 : 0000000000000000
    [  153.670002] x5 : 0000000000000000 x4 : ffff0000fe908bc0
    [  153.675414] x3 : ffff0000fe910228 x2 : 162ef67e0581e700
    [  153.680826] x1 : 162ef67e0581e700 x0 : ef7bdd7fffffffff
    [  153.686241] Call trace:
    [  153.688769]  tegra_xusb_padctl_suspend_noirq+0x88/0x100
    [  153.694077]  __device_suspend_noirq+0x68/0x1cc
    [  153.698594]  dpm_noirq_suspend_devices+0x10c/0x1d0
    [  153.703456]  dpm_suspend_noirq+0x28/0xa0
    [  153.707461]  suspend_devices_and_enter+0x234/0x4bc
    [  153.712314]  pm_suspend+0x1e4/0x270
    [  153.715868]  state_store+0x8c/0x110
    [  153.719440]  kobj_attr_store+0x1c/0x30
    [  153.723259]  sysfs_kf_write+0x4c/0x7c
    [  153.726981]  kernfs_fop_write+0x124/0x240
    [  153.731065]  vfs_write+0xe4/0x204
    [  153.734449]  ksys_write+0x6c/0x100
    [  153.737925]  __arm64_sys_write+0x20/0x30
    [  153.741931]  el0_svc_common.constprop.0+0x78/0x1a0
    [  153.746789]  do_el0_svc+0x24/0x90
    [  153.750181]  el0_sync_handler+0x254/0x260
    [  153.754251]  el0_sync+0x174/0x180
    [  153.757663] Code: aa0303e2 94000f64 f9405680 b40000e0 (f9402803)
    [  153.763826] ---[ end trace 81543a3394cb409d ]---
    
    Fixes: e8f7d2f409a1 ("phy: tegra: xusb: Add usb-phy support")
    
    Signed-off-by: JC Kuo <jckuo@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20201117083803.185209-1-jckuo@nvidia.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e747c8d16eb9ab47f1d7dc956b61b3e63ab49c3c
Author: Michael Walle <michael@walle.cc>
Date:   Sun Nov 15 23:54:35 2020 +0100

    arm64: dts: freescale: sl28: combine SPI MTD partitions
    
    [ Upstream commit 91ab1c12285c9999afe56c09aa296d8b96862976 ]
    
    The upstream port, doesn't really follow the vendor partitioning. The
    bootloader partition has one U-Boot FIT image containing all needed
    bits and pieces. Even today the bootloader is already larger than the
    current "bootloader" partition. Thus, fold all the partitions into one
    and keep the environment one. The latter is still valid.
    We keep the failsafe partitions because the first half of the SPI flash
    is preinstalled by the vendor and immutable.
    
    Fixes: 815364d0424e ("arm64: dts: freescale: add Kontron sl28 support")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 893d1502500ca4bd17c33db1a60541c8a5399ce5
Author: Michael Walle <michael@walle.cc>
Date:   Sun Nov 8 19:51:06 2020 +0100

    arm64: dts: ls1028a: fix FlexSPI clock input
    
    [ Upstream commit 588b17eda1356e06efa4b888d0af02c80a2788f6 ]
    
    On the LS1028A the FlexSPI clock is connected to the first HWA output,
    see Figure 7 "Clock subsystem block diagram".
    
    Fixes: c77fae5ba09a ("arm64: dts: ls1028a: Add FlexSPI support")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb8447610e2ea076c767c55430ec3b619eee56fc
Author: Michael Walle <michael@walle.cc>
Date:   Sun Nov 8 19:51:05 2020 +0100

    arm64: dts: ls1028a: fix ENETC PTP clock input
    
    [ Upstream commit d0570a575aa83116bd0f6a99c4de548af773d950 ]
    
    On the LS1028A the ENETC reference clock is connected to 4th HWA output,
    see Figure 7 "Clock subsystem block diagram".
    
    The PHC may run with a wrong frequency. ptp_qoriq_auto_config() will read
    the clock speed of the clock given in the device tree. It is likely that,
    on the reference board this wasn't noticed because both clocks have the
    same frequency. But this must not be always the case. Fix it.
    
    Fixes: 49401003e260 ("arm64: dts: fsl: ls1028a: add ENETC 1588 timer node")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f11ebb7651a9743452ae51f94a03774903618025
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 891bb86926f2788990ed35d4d96fb577ff3aca9b
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 67c91336e0d1c4772cc906e3a294a86f36326016
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 e6207f098896401cd88e4b0130d82fe81c1fe52f
Author: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Date:   Wed Nov 25 05:44:44 2020 +0100

    power: supply: max17042_battery: Fix current_{avg,now} hiding with no current sense
    
    [ Upstream commit 4b0a56e692503692da6555337a697c17feabbb3e ]
    
    When current sense is disabled, max17042_no_current_sense_psy_desc gets
    used which ignores two last properties from the list.
    
    Fixes: 21b01cc879cc ("power: supply: max17042_battery: Add support for the TTE_NOW prop")
    Reported-by: Timon Baetz <timon.baetz@protonmail.com>
    Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d73be8a24bb273db3fabf0aea0fbb874f4af70fd
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 a47f8c9537694079a81ed62c91be583e1cbeb628
Author: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Date:   Wed Nov 25 04:48:05 2020 +0100

    power: supply: bq25890: Use the correct range for IILIM register
    
    [ Upstream commit d4e9e7b6f7ae37a99bc11ce9efe6e8bdc711362f ]
    
    I've checked bq25890, bq25892, bq25895 and bq25896 datasheets and
    they all define IILIM to be between 100mA-3.25A with 50mA steps.
    
    Fixes: 478efc79ee32 ("power: bq25890: implement INPUT_CURRENT_LIMIT property")
    Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
    Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d4ba95a41fb3c2738cc5e2b2da940515f2f61cc
Author: Marek Behún <kabel@kernel.org>
Date:   Sat Nov 14 21:42:53 2020 +0100

    arm64: dts: armada-3720-turris-mox: update ethernet-phy handle name
    
    [ Upstream commit 3aa669a994c9110a2dc7e08a5c0958a9ea5eb17c ]
    
    Use property name `phy-handle` instead of the deprecated `phy` to
    connect eth2 to the PHY.
    
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
    Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
    Cc: Andrew Lunn <andrew@lunn.ch>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: devicetree@vger.kernel.org
    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 f64ffe32f54fb31403d51cfe1cdc56db896c187f
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 9e363d142f2e87dc215503533b9828e81e12f917
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 38429d879dcd1d4743448ef08b425bdf5d8252f9
Author: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Date:   Fri Nov 27 12:02:04 2020 +0100

    drm/mediatek: Use correct aliases name for ovl
    
    [ Upstream commit 414562b0ef36ce658f0ffec00e7039c7911e4cdc ]
    
    Aliases property name must include only lowercase and '-', so fix this
    in the driver, so we're not tempted to do "ovl_2l0 = &ovl_2l0" in the
    device-tree instead of the right one which is "ovl-2l0 = &ovl_2l0".
    
    Fixes: b17bdd0d7a73 ("drm/mediatek: add component OVL_2L0")
    Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit deaeb67c9da0d8a51625e299cd197aa5dcf40bc3
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Nov 17 09:01:46 2020 +0200

    RDMA/core: Track device memory MRs
    
    [ Upstream commit b47a98efa97889c5b16d17e77eed3dc4500674eb ]
    
    Device memory (DM) are registered as MR during initialization flow, these
    MRs were not tracked by resource tracker and had res->valid set as a
    false. Update the code to manage them too.
    
    Before this change:
    $ ibv_rc_pingpong -j &
    $ rdma res show mr <-- shows nothing
    
    After this change:
    $ ibv_rc_pingpong -j &
    $ rdma res show mr
    dev ibp0s9 mrn 0 mrlen 4096 pdn 3 pid 734 comm ibv_rc_pingpong
    
    Fixes: be934cca9e98 ("IB/uverbs: Add device memory registration ioctl support")
    Link: https://lore.kernel.org/r/20201117070148.1974114-2-leon@kernel.org
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aaaa7a6006c78362bbc660ae8adf8052ec8ae8bc
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 1f29c438707d00c27d2ab737a4626bdbe2f98276
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 1108b0f4920decba745e4f4df21d679bb61dce48
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 e7fd18c20342f59877755c94e5626cb50e350111
Author: Daniel Gomez <daniel@qtec.com>
Date:   Thu Oct 3 16:46:24 2019 +0200

    media: imx214: Fix stop streaming
    
    [ Upstream commit eeb76afbe8d91e112396c6281cd020725160f006 ]
    
    Stop video streaming when requested.
    
    When s_stream is called to stop the video streaming, if/else condition calls
    start_streaming function instead of the one for stopping it.
    
    Fixes: 436190596241 ("media: imx214: Add imx214 camera sensor driver")
    Signed-off-by: Daniel Gomez <daniel@qtec.com>
    Signed-off-by: Ricardo Ribalda <ribalda@kernel.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bf76d566a76b847658b3513af2793eb24612f28
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 048a04aa031bceaa6e211fe44626ef89ae0a92e6
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Thu Nov 19 22:11:26 2020 +0800

    serial: 8250-mtk: Fix reference leak in mtk8250_probe
    
    [ Upstream commit 6e4e636e0e3e0b5deffc5e233adcb2cd4e68f2d0 ]
    
    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: e32a83c70cf98 ("serial: 8250-mtk: modify mtk uart power and clock management")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201119141126.168850-1-zhangqilong3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af7ae245945a3eac45db5ac51aa1ae855ccf6d98
Author: Weihang Li <liweihang@huawei.com>
Date:   Mon Nov 16 19:33:24 2020 +0800

    RDMA/hns: Avoid setting loopback indicator when smac is same as dmac
    
    [ Upstream commit 3631dadfb118821236098a215e59fb5d3e1c30a8 ]
    
    The loopback flag will be set to 1 by the hardware when the source mac
    address is same as the destination mac address. So the driver don't need
    to compare them.
    
    Fixes: d6a3627e311c ("RDMA/hns: Optimize wqe buffer set flow for post send")
    Link: https://lore.kernel.org/r/1605526408-6936-4-git-send-email-liweihang@huawei.com
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b8a015eda204c985ba643ae1e0a428b4ea5f574
Author: Weihang Li <liweihang@huawei.com>
Date:   Mon Nov 16 19:33:23 2020 +0800

    RDMA/hns: Fix missing fields in address vector
    
    [ Upstream commit fba429fcf9a5e0c4ec2523ecf4cf18bc0507fcbc ]
    
    Traffic class and hop limit in address vector is not assigned from GRH,
    but it will be filled into UD SQ WQE. So the hardware will get a wrong
    value.
    
    Fixes: 82e620d9c3a0 ("RDMA/hns: Modify the data structure of hns_roce_av")
    Link: https://lore.kernel.org/r/1605526408-6936-3-git-send-email-liweihang@huawei.com
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba9479d75ef13b998201fd75d568896c47eba381
Author: Weihang Li <liweihang@huawei.com>
Date:   Mon Nov 16 19:33:22 2020 +0800

    RDMA/hns: Only record vlan info for HIP08
    
    [ Upstream commit 7406c0036f851ee1cd93cb08349f24b051b4cbf8 ]
    
    Information about vlan is stored in GMV(GID/MAC/VLAN) table for HIP09, so
    there is no need to copy it to address vector.
    
    Link: https://lore.kernel.org/r/1605526408-6936-2-git-send-email-liweihang@huawei.com
    Signed-off-by: Weihang Li <liweihang@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57d22f146803223534a238d7ea49b45a8dfbcb10
Author: Alex Elder <elder@linaro.org>
Date:   Wed Nov 25 19:54:55 2020 -0600

    arm64: dts: qcom: sc7180: limit IPA iommu streams
    
    [ Upstream commit 8f34831d3659d38f480fddccb76d84c6c3e0ac0b ]
    
    Recently we learned that Android and Windows firmware don't seem to
    like using 3 as an iommu mask value for IPA.  A simple fix was to
    specify exactly the streams needed explicitly, rather than implying
    a range with the mask.  Make the same change for the SC7180 platform.
    
    See also:
      https://lore.kernel.org/linux-arm-msm/20201123052305.157686-1-bjorn.andersson@linaro.org/
    
    Fixes: d82fade846aa8 ("arm64: dts: qcom: sc7180: add IPA information")
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Alex Elder <elder@linaro.org>
    Link: https://lore.kernel.org/r/20201126015457.6557-2-elder@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bdb7acb892618b55c89b98d0b921efde7471090d
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 d285968ae009c82e49e5e88a0dd571cf81cc73e4
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 0736d6a86fd36045383ba9579c55f7f47a8c3f97
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 bac43b0f1144aec4bc579c960eb25acba722e2cd
Author: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Date:   Thu Nov 5 16:01:25 2020 +0200

    drm/imx/dcss: fix rotations for Vivante tiled formats
    
    [ Upstream commit 59cb403f38099506ddbe05fd09126f3f0890860b ]
    
    DCSS supports 90/180/270 degree rotations for Vivante tiled and super-tiled
    formats. Unfortunately, with the current code, they didn't work properly.
    
    This simple patch makes the rotations work by fixing the way the scaler is set
    up for 90/270 degree rotations. In this particular case, the source width and
    height need to be swapped since DPR is sending the buffer to scaler already
    rotated.
    
    Also, make sure to allow full rotations for DRM_FORMAT_MOD_VIVANTE_SUPER_TILED.
    
    Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ")
    Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201105140127.25249-2-laurentiu.palcu@oss.nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c87a177fa7cac480c820c70635b5fca77532a96f
Author: Vinod Koul <vkoul@kernel.org>
Date:   Wed Nov 25 11:21:55 2020 +0530

    soundwire: qcom: Fix build failure when slimbus is module
    
    [ Upstream commit 47edc0104c61d609b0898a302267b7269d87a6af ]
    
    Commit 5bd773242f75 ("soundwire: qcom: avoid dependency on
    CONFIG_SLIMBUS") removed hard dependency on Slimbus for qcom driver but
    it results in build failure when: CONFIG_SOUNDWIRE_QCOM=y
    CONFIG_SLIMBUS=m
    
    drivers/soundwire/qcom.o: In function `qcom_swrm_probe':
    qcom.c:(.text+0xf44): undefined reference to `slimbus_bus'
    
    Fix this by using IS_REACHABLE() in driver which is recommended to be
    used with imply.
    
    Fixes: 5bd773242f75 ("soundwire: qcom: avoid dependency on CONFIG_SLIMBUS")
    Reported-by: kernel test robot <lkp@intel.com>
    Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
    Link: https://lore.kernel.org/r/20201125055155.GD8403@vkoul-mobl
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f85d05c0a599ede6f161988ab6eea1a62b1b400f
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Wed Nov 18 09:33:23 2020 -0400

    RDMA/cma: Fix deadlock on &lock in rdma_cma_listen_on_all() error unwind
    
    [ Upstream commit dd37d2f59eb839d51b988f6668ce5f0d533b23fd ]
    
    rdma_detroy_id() cannot be called under &lock - we must instead keep the
    error'd ID around until &lock can be released, then destroy it.
    
    This is complicated by the usual way listen IDs are destroyed through
    cma_process_remove() which can run at any time and will asynchronously
    destroy the same ID.
    
    Remove the ID from visiblity of cma_process_remove() before going down the
    destroy path outside the locking.
    
    Fixes: c80a0c52d85c ("RDMA/cma: Add missing error handling of listen_id")
    Link: https://lore.kernel.org/r/20201118133756.GK244516@ziepe.ca
    Reported-by: syzbot+1bc48bf7f78253f664a9@syzkaller.appspotmail.com
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98e72ffe934d0e9879a4620d1d8762ca34c1476f
Author: Vidya Sagar <vidyas@nvidia.com>
Date:   Mon Oct 26 12:09:02 2020 +0530

    arm64: tegra: Fix DT binding for IO High Voltage entry
    
    [ Upstream commit 6b26c1a034885923822f6c4d94f8644d32bc2481 ]
    
    Fix the device-tree entry that represents I/O High Voltage property
    by replacing 'nvidia,io-high-voltage' with 'nvidia,io-hv' as the former
    entry is deprecated.
    
    Fixes: dbb72e2c305b ("arm64: tegra: Add configuration for PCIe C5 sideband signals")
    Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbbc5e42c467d4a825c08177c15c8d4a53340454
Author: Marek Behún <kabel@kernel.org>
Date:   Fri Oct 30 03:39:06 2020 +0100

    leds: turris-omnia: check for LED_COLOR_ID_RGB instead LED_COLOR_ID_MULTI
    
    [ Upstream commit 98650b0874171cc443251f7b369d3b1544db9d4e ]
    
    LED core does not allow LED_COLOR_ID_MULTI for now and instead for RGB
    LEDs prefers LED_COLOR_ID_RGB.
    
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Fixes: 77dce3a22e89 ("leds: disallow /sys/class/leds/*:multi:* for now")
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad316987c4e451af60f82919a0e639d5d87e3132
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Sep 22 23:05:15 2020 +0200

    leds: lp50xx: Fix an error handling path in 'lp50xx_probe_dt()'
    
    [ Upstream commit 6d8d014c7dcf85a79da71ef586d06d03d2cae558 ]
    
    In case of memory allocation failure, we must release some resources as
    done in all other error handling paths of the function.
    
    'goto child_out' instead of a direct return so that 'fwnode_handle_put()'
    is called when we break out of a 'device_for_each_child_node' loop.
    
    Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Dan Murphy <dmurphy@ti.com>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1687f01f0ea8ff2202b29886c97625f8e13fb48e
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Oct 29 17:23:05 2020 +0800

    leds: netxbig: add missing put_device() call in netxbig_leds_get_of_pdata()
    
    [ Upstream commit 311066aa9ebcd6f1789c829da5039ca02f2dfe46 ]
    
    if of_find_device_by_node() succeed, netxbig_leds_get_of_pdata() doesn't
    have a corresponding put_device(). Thus add jump target to fix the
    exception handling for this function implementation.
    
    Fixes: 2976b1798909 ("leds: netxbig: add device tree binding")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4827f0cabc16ab83a6ad5c058d26d966beaef8f2
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Sun Nov 22 23:23:05 2020 -0600

    arm64: dts: qcom: sdm845: Limit ipa iommu streams
    
    [ Upstream commit 95e6f8467c83c4074a6f6b47bad00653549ff90a ]
    
    The Android and Windows firmware does not accept the use of 3 as a mask
    to cover the IPA streams. But with 0x721 being related to WiFi and 0x723
    being unsed the mapping can be reduced to just cover 0x720 and 0x722,
    which is accepted.
    
    Acked-by: Alex Elder <elder@linaro.org>
    Tested-by: Alex Elder <elder@linaro.org>
    Fixes: e9e89c45bfeb ("arm64: dts: sdm845: add IPA iommus property")
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20201123052305.157686-1-bjorn.andersson@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 17fdb0eb50e7efef6a5e99ccc812114268f32079
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 0dee7fabab783de5ae97ddec68b42e6b02e447cc
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 b8da48050a26a88eaa915e18ebe3b482c64745c2
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Tue Nov 17 11:07:34 2020 +0800

    rsi: fix error return code in rsi_reset_card()
    
    [ Upstream commit fb21d14694bd46a538258d86498736490b3ba855 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 17ff2c794f39 ("rsi: reset device changes for 9116")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1605582454-39649-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71a0eb78d6f0b04b431b24a5dc5ce3e786c8ed43
Author: Wang Hai <wanghai38@huawei.com>
Date:   Sat Nov 14 20:33:47 2020 +0800

    qtnfmac: fix error return code in qtnf_pcie_probe()
    
    [ Upstream commit 31e07aa33fa7cdc93fa91c3f78f031e8d38862c2 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: b7da53cd6cd1 ("qtnfmac_pcie: use single PCIe driver for all platforms")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201114123347.29632-1-wanghai38@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15e39825a2706b758e93025d25c4bbdeeb8382a1
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 174f2189f7697bdec2fe6acd96ca7d5f518b37b9
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Nov 13 14:28:16 2020 +0800

    brcmfmac: fix error return code in brcmf_cfg80211_connect()
    
    [ Upstream commit 37ff144d29acd7bca3d465ce2fc4cb5c7072a7e5 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 3b1e0a7bdfee ("brcmfmac: add support for SAE authentication offload")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Reviewed-by: Chi-hsien Lin <chi-hsien.lin@infineon.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1605248896-16812-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c9e1e32a2883747a65eba1211b95b0f33fc9810
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Sat Nov 21 10:14:31 2020 +0800

    mmc: pxamci: Fix error return code in pxamci_probe
    
    [ Upstream commit d7b819b5d33869d41bdaa427aeb98ae24c57a38b ]
    
    Fix to return the error code from devm_gpiod_get_optional() instaed
    of 0 in pxamci_probe().
    
    Fixes: f54005b508b9a9d9c ("mmc: pxa: Use GPIO descriptor for power")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20201121021431.3168506-1-chengzhihao1@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ab2d54ae31ee956450ef4aef5801e844739b5d9
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 a0f8184693e3a0468281a9a7c1c7229712efbf68
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 1d8ae9da94eb0c00aa1d7d50ff2da5a44bf1097a
Author: Cristian Birsan <cristian.birsan@microchip.com>
Date:   Wed Nov 18 14:00:17 2020 +0200

    ARM: dts: at91: sam9x60: add pincontrol for USB Host
    
    [ Upstream commit 5ba6291086d2ae8006be9e0f19bf2001a85c9dc1 ]
    
    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: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and 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-2-cristian.birsan@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 365a94fc1e3d0c78df67b39b819ceb645b96b391
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 c802d9e5e69d9f631a9f126a2b645f2fbac4858f
Author: Yangtao Li <frank@allwinnertech.com>
Date:   Tue Nov 10 14:22:55 2020 +0800

    pinctrl: sunxi: fix irq bank map for the Allwinner A100 pin controller
    
    [ Upstream commit 6de7ed693c631d4689acfe90c434147598d75543 ]
    
    A100's pin starts with PB, so it should start with 1.
    
    Fixes: 473436e7647d6 ("pinctrl: sunxi: add support for the Allwinner A100 pin controller")
    Signed-off-by: Yangtao Li <frank@allwinnertech.com>
    Link: https://lore.kernel.org/r/9db51667bf9065be55beafd56e5c319e3bbe8310.1604988979.git.frank@allwinnertech.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed27e6b21505d2daec5c77b78eede963a208befb
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Wed Nov 4 11:29:41 2020 +0000

    soundwire: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute
    
    [ Upstream commit e6db818a3f51781ba12ac4d52b8773f74d57b06b ]
    
    running kernel with CONFIG_DEBUG_LOCKS_ALLOC enabled will below warning:
    
    BUG: key ffff502e09807098 has not been registered!
    DEBUG_LOCKS_WARN_ON(1)
    WARNING: CPU: 5 PID: 129 at kernel/locking/lockdep.c:4623
            lockdep_init_map_waits+0xe8/0x250
    Modules linked in:
    CPU: 5 PID: 129 Comm: kworker/5:1 Tainted: G
           W         5.10.0-rc1-00277-ged49f224ca3f-dirty #1210
    Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
    Workqueue: events deferred_probe_work_func
    pstate: 80c00005 (Nzcv daif +PAN +UAO -TCO BTYPE=--)
    pc : lockdep_init_map_waits+0xe8/0x250
    lr : lockdep_init_map_waits+0xe8/0x250
     [ Trimmed ]
    
    Call trace:
     lockdep_init_map_waits+0xe8/0x250
     __kernfs_create_file+0x78/0x180
     sysfs_add_file_mode_ns+0x94/0x1c8
     internal_create_group+0x110/0x3e0
     sysfs_create_group+0x18/0x28
     devm_device_add_group+0x4c/0xb0
     add_all_attributes+0x438/0x490
     sdw_slave_sysfs_dpn_init+0x128/0x138
     sdw_slave_sysfs_init+0x80/0xa0
     sdw_drv_probe+0x94/0x170
     really_probe+0x118/0x3e0
     driver_probe_device+0x5c/0xc0
    
     [ Trimmed ]
    
    CPU: 5 PID: 129 Comm: kworker/5:1 Tainted: G
         W         5.10.0-rc1-00277-ged49f224ca3f-dirty #1210
    Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
    Workqueue: events deferred_probe_work_func
    Call trace:
     dump_backtrace+0x0/0x1c0
     show_stack+0x18/0x68
     dump_stack+0xd8/0x134
     __warn+0xa0/0x158
     report_bug+0xc8/0x178
     bug_handler+0x20/0x78
     brk_handler+0x70/0xc8
    
    [ Trimmed ]
    
    Fix this by initializing dynamically allocated sysfs attribute to keep lockdep happy!
    
    Fixes: bcac59029955 ("soundwire: add Slave sysfs support")
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20201104112941.1134-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 623793c8da90e622bc839f058d66724d1016352a
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 7688ca1121ba0a5a4f385fe9f176f0feb0d60307
Author: Maharaja Kennadyrajan <mkenna@codeaurora.org>
Date:   Wed Nov 11 16:08:37 2020 +0530

    ath11k: Fix the rx_filter flag setting for peer rssi stats
    
    [ Upstream commit 11af6de4799ee6eeae3730f18fd417414d212e2d ]
    
    Set the rx_filter in ath11k_mac_config_mon_status_default(),
    only when the rx_filter value exists in ath11k_debug_rx_filter().
    
    Without this change, rx_filter gets set to 0 and peer rssi stats
    aren't updating properly from firmware.
    
    Tested-on: IPQ8074 WLAN.HK.2.1.0.1-01230-QCAHKSWPL_SILICONZ-4
    
    Fixes: ec48d28ba291 ("ath11k: Fix rx_filter flags setting for per peer rx_stats")
    
    Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1605091117-11005-1-git-send-email-mkenna@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0121a853eaced609813886b0d523968325b970dc
Author: Wang Hai <wanghai38@huawei.com>
Date:   Wed Nov 18 18:37:24 2020 +0800

    staging: mfd: hi6421-spmi-pmic: fix error return code in hi6421_spmi_pmic_probe()
    
    [ Upstream commit ba3e4a2a0b3c639d3835f2f1dce27d79576ae453 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 4524ac56cdca ("staging: mfd: add a PMIC driver for HiSilicon 6421 SPMI version")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Link: https://lore.kernel.org/r/20201118103724.57451-1-wanghai38@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47324dbd56807af02febeff1bed48748bfce4dca
Author: Kevin Hilman <khilman@baylibre.com>
Date:   Wed Nov 18 11:09:30 2020 -0800

    clk: meson: Kconfig: fix dependency for G12A
    
    [ Upstream commit bae69bfa3a586493469078ec4ca35499b754ba5c ]
    
    When building only G12A, ensure that VID_PLL_DIV clock driver is
    selected, otherwise results in this build error:
    
    ERROR: modpost: "meson_vid_pll_div_ro_ops" [drivers/clk/meson/g12a.ko] undefined!
    
    Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller")
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20201118190930.34352-1-khilman@baylibre.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e8d632e41622e7ffe2c71a5d356fb5f9105e315
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 94268e0c9a59bad6e56379ca57bb0bb51f8da1bf
Author: Nikita Travkin <nikitos.tr@gmail.com>
Date:   Fri Nov 13 22:59:17 2020 +0500

    arm64: dts: qcom: msm8916-samsung-a2015: Disable muic i2c pin bias
    
    [ Upstream commit 4e8692c2ee3d4ac6b669f7e306364d77a574c810 ]
    
    Some versions of the firmware leave i2c gpios in a wrong state.
    Add pinctrl that disables pin bias since external pull-up resistors
    are present.
    
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Fixes: 1329c1ab0730 ("arm64: dts: qcom: Add device tree for Samsung Galaxy A3U/A5U")
    Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com>
    Link: https://lore.kernel.org/r/20201113175917.189123-6-nikitos.tr@gmail.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 281c972aaa4eea302d72957a23b5d7bc930df74b
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Sep 30 14:21:33 2020 +0300

    arm64: dts: qcom: sm8250: correct compatible for sm8250-mtp
    
    [ Upstream commit d371a931540bc36fd1199de3ec365a1187b7b282 ]
    
    Qualcomm boards should define two compatible strings: one for board,
    anoter one for SoC family. sm8250-mtp.dts lists just the board
    compatible, which makes it incompatible with qcom.yaml schema.
    
    Reviewed-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Fixes: 60378f1a171e ("arm64: dts: qcom: sm8250: Add sm8250 dts file")
    Link: https://lore.kernel.org/r/20200930112133.2091505-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d3131ace30336bb03b8b322e4fd6fdae7a6f4a1
Author: Tom Rix <trix@redhat.com>
Date:   Wed Aug 19 11:46:37 2020 -0700

    soc: qcom: initialize local variable
    
    [ Upstream commit a161ffe4b877721d8917e18e70461d255a090f19 ]
    
    clang static analysis reports this problem
    
    pdr_interface.c:596:6: warning: Branch condition evaluates
      to a garbage value
            if (!req.service_path[0])
                ^~~~~~~~~~~~~~~~~~~~
    
    This check that req.service_path was set in an earlier loop.
    However req is a stack variable and its initial value
    is undefined.
    
    So initialize req to 0.
    
    Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
    Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
    Signed-off-by: Tom Rix <trix@redhat.com>
    Link: https://lore.kernel.org/r/20200819184637.15648-1-trix@redhat.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 561397df16e3fa730fe3340f3065353ffcc18e07
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 97d14d592159a34f73bda07d925a2925f90a35ea
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 bdf76d879ac372ef7c04af353fd2ee56e5f6f10d
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 e7e8d6dc17a8359d815cb3852865f51df144465e
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date:   Mon Nov 2 15:57:12 2020 -0500

    PCI: brcmstb: Initialize "tmp" before use
    
    [ Upstream commit ddaff0af653136ee1e0b49116ecf2988c2fc64ca ]
    
    The variable 'tmp' is used multiple times in the brcm_pcie_setup()
    function.  One such usage did not initialize 'tmp' to the current value
    of the target register.  By luck the mistake does not currently affect
    behavior;  regardless 'tmp' is now initialized properly.
    
    Suggested-by: Rafał Miłecki <zajec5@gmail.com>
    Link: https://lore.kernel.org/r/20201102205712.23332-1-james.quinlan@broadcom.com
    Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver")
    Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddf1dab2919b15c29f1cc1baa9546b5d686afd95
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Nov 6 12:05:25 2020 +0200

    PCI: Disable MSI for Pericom PCIe-USB adapter
    
    [ Upstream commit f83c37941e881224885f2e694e0626bea358e96b ]
    
    Pericom PCIe-USB adapter advertises MSI, but documentation says "The MSI
    Function is not implemented on this device" in chapters 7.3.27,
    7.3.29-7.3.31, and Alberto found that MSI in fact does not work.
    
    Disable MSI for these devices.
    
    Datasheet: https://www.diodes.com/assets/Datasheets/PI7C9X440SL.pdf
    Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices")
    Link: https://lore.kernel.org/linux-usb/20201030134826.GP4077@smile.fi.intel.com/
    Link: https://lore.kernel.org/r/20201106100526.17726-1-andriy.shevchenko@linux.intel.com
    Reported-by: alberto.vignani@fastwebnet.it
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cf9c3f4dfa07837acb520256091b21d315cfda8
Author: Marc Zyngier <maz@kernel.org>
Date:   Fri Nov 20 09:42:05 2020 +0000

    drm/meson: dw-hdmi: Enable the iahb clock early enough
    
    [ Upstream commit 2b6cb81b95d1e8abfb6d32cf194a5bd2992c315c ]
    
    Instead of moving meson_dw_hdmi_init() around which breaks existing
    platform, let's enable the clock meson_dw_hdmi_init() depends on.
    This means we don't have to worry about this clock being enabled or
    not, depending on the boot-loader features.
    
    Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are enabled before touching the TOP registers")
    Reported-by: "kernelci.org bot" <bot@kernelci.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    [narmstrong: changed reported by to kernelci.org bot]
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201120094205.525228-3-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0ef2d794000fba8b7a0f3f45e54c7d2541bd974
Author: Marc Zyngier <maz@kernel.org>
Date:   Fri Nov 20 09:42:04 2020 +0000

    drm/meson: dw-hdmi: Disable clocks on driver teardown
    
    [ Upstream commit 1dfeea904550c11eccf3fd5f6256e4b0f0208dfe ]
    
    The HDMI driver request clocks early, but never disable them, leaving
    the clocks on even when the driver is removed.
    
    Fix it by slightly refactoring the clock code, and register a devm
    action that will eventually disable/unprepare the enabled clocks.
    
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201120094205.525228-2-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddbed6d02751a02f95f520767cf4900feaa5a93d
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 098a597f31150ea6a6d4a3e978bdc3b27212a64d
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Sun Nov 15 19:08:07 2020 +0000

    crypto: sun8i-ce - fix two error path's memory leak
    
    [ Upstream commit 732b764099f651a088fd931d7b8121b6aa84e62e ]
    
    This patch fixes the following smatch warnings:
    drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c:412
    sun8i_ce_hash_run() warn: possible memory leak of 'result'
    Note: "buf" is leaked as well.
    
    Furthermore, in case of ENOMEM, crypto_finalize_hash_request() was not
    called which was an error.
    
    Fixes: 56f6d5aee88d ("crypto: sun8i-ce - support hash algorithms")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3cf33a4686c4c7572ef8db3d04b09ccf1ec938ef
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 2ec7b49a1f39047c90e2b65df3b0b69ffd13cfac
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 9b81af9c845559f8cf9fad2dfc377e548be6da59
Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
Date:   Thu Oct 29 17:50:04 2020 +0100

    rcu/tree: Defer kvfree_rcu() allocation to a clean context
    
    [ Upstream commit 56292e8609e39537297a7468dda4d87b9bd81d6a ]
    
    The current memmory-allocation interface causes the following difficulties
    for kvfree_rcu():
    
    a) If built with CONFIG_PROVE_RAW_LOCK_NESTING, the lockdep will
       complain about violation of the nesting rules, as in "BUG: Invalid
       wait context".  This Kconfig option checks for proper raw_spinlock
       vs. spinlock nesting, in particular, it is not legal to acquire a
       spinlock_t while holding a raw_spinlock_t.
    
       This is a problem because kfree_rcu() uses raw_spinlock_t whereas the
       "page allocator" internally deals with spinlock_t to access to its
       zones. The code also can be broken from higher level of view:
       <snip>
           raw_spin_lock(&some_lock);
           kfree_rcu(some_pointer, some_field_offset);
       <snip>
    
    b) If built with CONFIG_PREEMPT_RT, spinlock_t is converted into
       sleeplock.  This means that invoking the page allocator from atomic
       contexts results in "BUG: scheduling while atomic".
    
    c) Please note that call_rcu() is already invoked from raw atomic context,
       so it is only reasonable to expaect that kfree_rcu() and kvfree_rcu()
       will also be called from atomic raw context.
    
    This commit therefore defers page allocation to a clean context using the
    combination of an hrtimer and a workqueue.  The hrtimer stage is required
    in order to avoid deadlocks with the scheduler.  This deferred allocation
    is required only when kvfree_rcu()'s per-CPU page cache is empty.
    
    Link: https://lore.kernel.org/lkml/20200630164543.4mdcf6zb4zfclhln@linutronix.de/
    Fixes: 3042f83f19be ("rcu: Support reclaim for head-less object")
    Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5cacd18c52073ea1c5419bd192309befc345c2ea
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Sep 29 13:33:40 2020 +0200

    rcu,ftrace: Fix ftrace recursion
    
    [ Upstream commit d2098b4440981705e844c50254540ba7b5f82795 ]
    
    Kim reported that perf-ftrace made his box unhappy. It turns out that
    commit:
    
      ff5c4f5cad33 ("rcu/tree: Mark the idle relevant functions noinstr")
    
    removed one too many notrace qualifiers, probably due to there not being
    a helpful comment.
    
    This commit therefore reinstates the notrace and adds a comment to avoid
    losing it again.
    
    [ paulmck: Apply Steven Rostedt's feedback on the comment. ]
    Fixes: ff5c4f5cad33 ("rcu/tree: Mark the idle relevant functions noinstr")
    Reported-by: Kim Phillips <kim.phillips@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4540e84bd8a97b1d79f556edd692fdb15c431604
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Nov 16 13:10:12 2020 +0100

    rcu: Allow rcu_irq_enter_check_tick() from NMI
    
    [ Upstream commit 6dbce04d8417ae706596366e16841d77c454ba52 ]
    
    Eugenio managed to tickle #PF from NMI context which resulted in
    hitting a WARN in RCU through irqentry_enter() ->
    __rcu_irq_enter_check_tick().
    
    However, this situation is perfectly sane and does not warrant an
    WARN. The #PF will (necessarily) be atomic and not require messing
    with the tick state, so early return is correct.  This commit
    therefore removes the WARN.
    
    Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
    Reported-by: "Eugenio Pérez" <eupm90@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbab483613f20249bd45873fdb460e68bca26f77
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Nov 17 08:58:38 2020 -0800

    scsi: ufs: Fix clkgating on/off
    
    [ Upstream commit 8eb456be75af7e5a7ac0cd223eaa198cf7ee2ac1 ]
    
    The following call stack prevents clk_gating at every I/O completion.  We
    can remove the condition, ufshcd_any_tag_in_use(), since clkgating_work
    will check it again.
    
    ufshcd_complete_requests(struct ufs_hba *hba)
      ufshcd_transfer_req_compl()
        __ufshcd_transfer_req_compl()
          __ufshcd_release(hba)
            if (ufshcd_any_tag_in_use() == 1)
               return;
      ufshcd_tmc_handler(hba);
        blk_mq_tagset_busy_iter();
    
    Note that this still requires work to deal with a potential race condition
    when user sets clkgating.delay_ms to very small value. That can cause
    preventing clkgating by the check of ufshcd_any_tag_in_use() in gate_work.
    
    Link: https://lore.kernel.org/r/20201117165839.1643377-7-jaegeuk@kernel.org
    Fixes: 7252a3603015 ("scsi: ufs: Avoid busy-waiting by eliminating tag conflicts")
    Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
    Reviewed-by: Can Guo <cang@codeaurora.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df7ae049e02a84b82c30c216b91c404a50dd2360
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Nov 17 08:58:33 2020 -0800

    scsi: ufs: Avoid to call REQ_CLKS_OFF to CLKS_OFF
    
    [ Upstream commit fd62de114f8c9df098dcd43b5d83c5714176dd12 ]
    
    Once UFS is gated with CLKS_OFF, it should not call REQ_CLKS_OFF
    again. This can lead to hibern8_enter failure.
    
    Link: https://lore.kernel.org/r/20201117165839.1643377-2-jaegeuk@kernel.org
    Reviewed-by: Can Guo <cang@codeaurora.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3897b71e1a68ce6962a29fe57372382a5eecc0f8
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date:   Mon Nov 9 21:06:58 2020 +0000

    EDAC/mce_amd: Use struct cpuinfo_x86.cpu_die_id for AMD NodeId
    
    [ Upstream commit 8de0c9917cc1297bc5543b61992d5bdee4ce621a ]
    
    The edac_mce_amd module calls decode_dram_ecc() on AMD Family17h and
    later systems. This function is used in amd64_edac_mod to do
    system-specific decoding for DRAM ECC errors. The function takes a
    "NodeId" as a parameter.
    
    In AMD documentation, NodeId is used to identify a physical die in a
    system. This can be used to identify a node in the AMD_NB code and also
    it is used with umc_normaddr_to_sysaddr().
    
    However, the input used for decode_dram_ecc() is currently the NUMA node
    of a logical CPU. In the default configuration, the NUMA node and
    physical die will be equivalent, so this doesn't have an impact.
    
    But the NUMA node configuration can be adjusted with optional memory
    interleaving modes. This will cause the NUMA node enumeration to not
    match the physical die enumeration. The mismatch will cause the address
    translation function to fail or report incorrect results.
    
    Use struct cpuinfo_x86.cpu_die_id for the node_id parameter to ensure the
    physical ID is used.
    
    Fixes: fbe63acf62f5 ("EDAC, mce_amd: Use cpu_to_node() to find the node ID")
    Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20201109210659.754018-4-Yazen.Ghannam@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2081572eb105be127af7a34ba2b438df8dd07e56
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Nov 11 19:06:13 2020 +0200

    mfd: cpcap: Fix interrupt regression with regmap clear_ack
    
    [ Upstream commit 14639a22de657eabbb776f503a816594393cc935 ]
    
    With commit 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack
    registers"), the cpcap interrupts are no longer getting acked properly
    leading to a very unresponsive device with CPUs fully loaded spinning
    in the threaded IRQ handlers.
    
    To me it looks like the clear_ack commit above actually fixed a long
    standing bug in regmap_irq_thread() where we unconditionally acked the
    interrupts earlier without considering ack_invert. And the issue with
    cpcap started happening as we now also consider ack_invert.
    
    Tim Harvey <tharvey@gateworks.com> tried to fix this issue earlier with
    "[PATCH v2] regmap: irq: fix ack-invert", but the reading of the ack
    register was considered unnecessary for just ack_invert, and we did not
    have clear_ack available yet. As the cpcap irqs worked both with and
    without ack_invert earlier because of the unconditional ack, the
    problem remained hidden until now.
    
    Also, looks like the earlier v3.0.8 based Motorola Android Linux kernel
    does clear_ack style read-clear-write with "ireg_val & ~mreg_val" instead
    of just ack_invert style write. So let's switch cpcap to use clear_ack
    to fix the issue.
    
    Fixes: 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers")
    Cc: Carl Philipp Klemm <philipp@uvos.xyz>
    Cc: Laxminath Kasam <lkasam@codeaurora.org>
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Sebastian Reichel <sre@kernel.org>
    Cc: Tim Harvey <tharvey@gateworks.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Tested-by: Pavel Machek <pavel@ucw.cz>
    Reviewed-By: Tim Harvey <tharvey@gateworks.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de39384806af37564a0fd6aef7557bf61cbde0e1
Author: Amelie Delaunay <amelie.delaunay@st.com>
Date:   Fri Nov 13 13:27:25 2020 +0100

    mfd: stmfx: Fix dev_err_probe() call in stmfx_chip_init()
    
    [ Upstream commit d75846ed08e6f4135ec73778575c34d9c0ace993 ]
    
    'ret' may be 0 so, dev_err_probe() should be called only when 'ret' is
    an error code.
    
    Fixes: 41c9c06c491a ("mfd: stmfx: Simplify with dev_err_probe()")
    Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b278cdb100399bbe233d8072d03884c52b7079fa
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Nov 10 16:57:27 2020 +0100

    mfd: MFD_SL28CPLD should depend on ARCH_LAYERSCAPE
    
    [ Upstream commit de1292817cf736c04fab31903a6aa9d9ffe60b79 ]
    
    Currently the Kontron sl28cpld Board Management Controller is found only
    on Kontron boards equipped with a Freescale Layerscape SoC.  Hence add a
    dependency on ARCH_LAYERSCAPE, to prevent asking the user about a driver
    for this controller when configuring a kernel without Layerscape support.
    
    Fixes: a538ad229bbee4f8 ("mfd: simple-mfd-i2c: Add sl28cpld support")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0300c814520acef6d288551209f320a96fb9c0cc
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Fri Nov 6 15:43:46 2020 +0800

    mfd: htc-i2cpld: Add the missed i2c_put_adapter() in htcpld_register_chip_i2c()
    
    [ Upstream commit 9a463284706c5217872c3cadaca863d47129bd95 ]
    
    htcpld_register_chip_i2c() misses to call i2c_put_adapter() in an error
    path. Add the missed function call to fix it.
    
    Fixes: 6048a3dd2371 ("mfd: Add HTCPLD driver")
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e377bb0734d721d9457b331e9af273431c69d66
Author: Kaixu Xia <kaixuxia@tencent.com>
Date:   Tue Nov 10 19:19:30 2020 +0800

    powerpc/powernv/sriov: fix unsigned int win compared to less than zero
    
    [ Upstream commit 027717a45ca251a7ba67a63db359994836962cd2 ]
    
    Fix coccicheck warning:
    
      arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10:
      WARNING: Unsigned expression compared with zero: win < 0
    
      arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10:
      WARNING: Unsigned expression compared with zero: win < 0
    
    Fixes: 39efc03e3ee8 ("powerpc/powernv/sriov: Move M64 BAR allocation into a helper")
    Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
    Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
    Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/1605007170-22171-1-git-send-email-kaixuxia@tencent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02cf67c9b608d192fab2a33641f4a3b243f7a04d
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Tue Nov 10 21:07:52 2020 -0500

    Revert "powerpc/pseries/hotplug-cpu: Remove double free in error path"
    
    [ Upstream commit a40fdaf1420d6e6bda0dd2df1e6806013e58dbe1 ]
    
    This reverts commit a0ff72f9f5a780341e7ff5e9ba50a0dad5fa1980.
    
    Since the commit b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR
    support for drc-info property"), the 'cpu_drcs' wouldn't be double
    freed when the 'cpus' node not found.
    
    So we needn't apply this patch, otherwise, the memory will be leaked.
    
    Fixes: a0ff72f9f5a7 ("powerpc/pseries/hotplug-cpu: Remove double free in error path")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    [mpe: Caused by me applying a patch to a function that had changed in the interim]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201111020752.1686139-1-zhangxiaoxu5@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a063e3faa3edc2371fd9009d9c1b544b679ead33
Author: Andrew Jeffery <andrew@aj.id.au>
Date:   Thu Oct 22 12:17:26 2020 +1030

    ARM: dts: tacoma: Fix node vs reg mismatch for flash memory
    
    [ Upstream commit cbee028da69d31cb927142e2828710de55a49f2a ]
    
    The mismatch lead to a miscalculation of regions in another patch, and
    shouldn't be mismatched anyway, so make them consistent.
    
    Fixes: 575640201e66 ("ARM: dts: aspeed: tacoma: Use 64MB for firmware memory")
    Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20201022014731.2035438-2-andrew@aj.id.au
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c6e4b13306fa663f1f2e9446f516dec786920e2
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 b1a0097b8298f03e5885fa580053520435fd3209
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Wed Oct 28 09:04:33 2020 +0100

    powerpc: Avoid broken GCC __attribute__((optimize))
    
    [ Upstream commit a7223f5bfcaeade4a86d35263493bcda6c940891 ]
    
    Commit 7053f80d9696 ("powerpc/64: Prevent stack protection in early
    boot") introduced a couple of uses of __attribute__((optimize)) with
    function scope, to disable the stack protector in some early boot
    code.
    
    Unfortunately, and this is documented in the GCC man pages [0],
    overriding function attributes for optimization is broken, and is only
    supported for debug scenarios, not for production: the problem appears
    to be that setting GCC -f flags using this method will cause it to
    forget about some or all other optimization settings that have been
    applied.
    
    So the only safe way to disable the stack protector is to disable it
    for the entire source file.
    
    [0] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
    
    Fixes: 7053f80d9696 ("powerpc/64: Prevent stack protection in early boot")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    [mpe: Drop one remaining use of __nostackprotector, reported by snowpatch]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201028080433.26799-1-ardb@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6014c6ed74f1aa61da6286bfd6738950200333a8
Author: Björn Töpel <bjorn.topel@gmail.com>
Date:   Wed Nov 18 08:16:38 2020 +0100

    selftests/bpf: Fix broken riscv build
    
    [ Upstream commit 6016df8fe874e1cf36f6357d71438b384198ce06 ]
    
    The selftests/bpf Makefile includes system include directories from
    the host, when building BPF programs. On RISC-V glibc requires that
    __riscv_xlen is defined. This is not the case for "clang -target bpf",
    which messes up __WORDSIZE (errno.h -> ... -> wordsize.h) and breaks
    the build.
    
    By explicitly defining __risc_xlen correctly for riscv, we can
    workaround this.
    
    Fixes: 167381f3eac0 ("selftests/bpf: Makefile fix "missing" headers on build with -idirafter")
    Signed-off-by: Björn Töpel <bjorn.topel@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Luke Nelson <luke.r.nels@gmail.com>
    Link: https://lore.kernel.org/bpf/20201118071640.83773-2-bjorn.topel@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98283ebab45ca3b47361abb65ea641a5d7687042
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 b6e018b059a543c4876378f87a67a2211670f2eb
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 351c360a7c2deab4f708607792919886d66c038b
Author: Carl Yin <carl.yin@quectel.com>
Date:   Mon Nov 2 20:27:10 2020 +0800

    bus: mhi: core: Fix null pointer access when parsing MHI configuration
    
    [ Upstream commit f4d0b39c842585c74bce8f8a80553369181b72df ]
    
    Functions parse_ev_cfg() and parse_ch_cfg() access mhi_cntrl->mhi_dev
    before it is set in function mhi_register_controller(),
    use cntrl_dev instead of mhi_dev.
    
    Fixes: 0cbf260820fa ("bus: mhi: core: Add support for registering MHI controllers")
    Signed-off-by: Carl Yin <carl.yin@quectel.com>
    Reviewed-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
    Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 417602ef3f4a81116c1a7742eeb9183f9b2729d4
Author: Bhaumik Bhatt <bbhatt@codeaurora.org>
Date:   Thu Oct 15 11:47:51 2020 -0700

    bus: mhi: core: Remove double locking from mhi_driver_remove()
    
    [ Upstream commit 9b627c25e70816a5e1dca940444b5029065b4d60 ]
    
    There is double acquisition of the pm_lock from mhi_driver_remove()
    function. Remove the read_lock_bh/read_unlock_bh calls for pm_lock
    taken during a call to mhi_device_put() as the lock is acquired
    within the function already. This will help avoid a potential
    kernel panic.
    
    Fixes: 189ff97cca53 ("bus: mhi: core: Add support for data transfer")
    Reported-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2fd75615c2fc779a20b870e3351d995b2a8adba
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 eced9dfb66913d18df605a7b5cc36bef28f82bb7
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 77b0790ac6bdbd01b022273b070ca20919c571ac
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 1a94c18952af51783056e5de12c007717b738472
Author: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Date:   Sun Nov 15 21:59:51 2020 +0100

    iommu/vt-d: include conditionally on CONFIG_INTEL_IOMMU_SVM
    
    [ Upstream commit 68dd9d89eaf56dfab8d46bf25610aa4650247617 ]
    
    Commit 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function")
    introduced intel_iommu_sva_invalidate() when CONFIG_INTEL_IOMMU_SVM.
    This function uses the dedicated static variable inv_type_granu_table
    and functions to_vtd_granularity() and to_vtd_size().
    
    These parts are unused when !CONFIG_INTEL_IOMMU_SVM, and hence,
    make CC=clang W=1 warns with an -Wunused-function warning.
    
    Include these parts conditionally on CONFIG_INTEL_IOMMU_SVM.
    
    Fixes: 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function")
    Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
    Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/20201115205951.20698-1-lukas.bulwahn@gmail.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f1e14d91704015aa74155b32e2a2a4a05a82ae4
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Nov 10 15:50:01 2020 +0100

    ASoC: intel: SND_SOC_INTEL_KEEMBAY should depend on ARCH_KEEMBAY
    
    [ Upstream commit 9a207228bdf0a4933b794c944d7111564353ea94 ]
    
    The Intel Keem Bay audio module is only present on Intel Keem Bay SoCs.
    Hence add a dependency on ARCH_KEEMBAY, to prevent asking the user about
    this driver when configuring a kernel without Intel Keem Bay platform
    support.
    
    Fixes: c544912bcc2dc806 ("ASoC: Intel: Add makefiles and kconfig changes for KeemBay")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20201110145001.3280479-1-geert+renesas@glider.be
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3f027ec7649fc85f48e202a4cddfa949114bffd
Author: Marc Zyngier <maz@kernel.org>
Date:   Mon Nov 16 20:07:44 2020 +0000

    drm/meson: dw-hdmi: Ensure that clocks are enabled before touching the TOP registers
    
    [ Upstream commit b33340e33acdfe5ca6a5aa1244709575ae1e0432 ]
    
    Removing the meson-dw-hdmi module and re-inserting it results in a hang
    as the driver writes to HDMITX_TOP_SW_RESET. Similar effects can be seen
    when booting with mainline u-boot and using the u-boot provided DT (which
    is highly desirable).
    
    The reason for the hang seem to be that the clocks are not always
    enabled by the time we enter meson_dw_hdmi_init(). Moving this call
    *after* dw_hdmi_probe() ensures that the clocks are enabled.
    
    Fixes: 1374b8375c2e ("drm/meson: dw_hdmi: add resume/suspend hooks")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201116200744.495826-5-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ce569f4b5017a843848abfb2650aa06e8dec0f9
Author: Marc Zyngier <maz@kernel.org>
Date:   Mon Nov 16 20:07:43 2020 +0000

    drm/meson: dw-hdmi: Register a callback to disable the regulator
    
    [ Upstream commit 0405f94a1ae0586ca237aec0e859f1b796d6325d ]
    
    Removing the meson-dw-hdmi module results in the following splat:
    
    i[   43.340509] WARNING: CPU: 0 PID: 572 at drivers/regulator/core.c:2125 _regulator_put.part.0+0x16c/0x174
    [...]
    [   43.454870] CPU: 0 PID: 572 Comm: modprobe Tainted: G        W   E     5.10.0-rc4-00049-gd274813a4de3-dirty #2147
    [   43.465042] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
    [   43.471945] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
    [   43.477896] pc : _regulator_put.part.0+0x16c/0x174
    [   43.482638] lr : regulator_put+0x44/0x60
    [...]
    [   43.568715] Call trace:
    [   43.571132]  _regulator_put.part.0+0x16c/0x174
    [   43.575529]  regulator_put+0x44/0x60
    [   43.579067]  devm_regulator_release+0x20/0x2c
    [   43.583380]  release_nodes+0x1c8/0x2b4
    [   43.587087]  devres_release_all+0x44/0x6c
    [   43.591056]  __device_release_driver+0x1a0/0x23c
    [   43.595626]  driver_detach+0xcc/0x160
    [   43.599249]  bus_remove_driver+0x68/0xe0
    [   43.603130]  driver_unregister+0x3c/0x6c
    [   43.607011]  platform_driver_unregister+0x20/0x2c
    [   43.611678]  meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
    [   43.618485]  __arm64_sys_delete_module+0x1bc/0x294
    
    as the HDMI regulator is still enabled on release.
    
    In order to address this, register a callback that will deal with
    the disabling when the driver is unbound, solving the problem.
    
    Fixes: 161a803fe32d ("drm/meson: dw_hdmi: Add support for an optional external 5V regulator")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201116200744.495826-4-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2777970add401e92d531a16dda30d84ec0831226
Author: Marc Zyngier <maz@kernel.org>
Date:   Mon Nov 16 20:07:42 2020 +0000

    drm/meson: Unbind all connectors on module removal
    
    [ Upstream commit e78ad18ba3658fbc8c63629e034b68d8e51acbf1 ]
    
    Removing the meson DRM module results in the following splats:
    
    [   42.689228] WARNING: CPU: 0 PID: 572 at drivers/gpu/drm/drm_irq.c:192 drm_irq_uninstall+0x130/0x160 [drm]
    [...]
    [   42.812820] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
    [   42.819723] pstate: 80400089 (Nzcv daIf +PAN -UAO -TCO BTYPE=--)
    [   42.825737] pc : drm_irq_uninstall+0x130/0x160 [drm]
    [   42.830647] lr : drm_irq_uninstall+0xc4/0x160 [drm]
    [...]
    [   42.917614] Call trace:
    [   42.920086]  drm_irq_uninstall+0x130/0x160 [drm]
    [   42.924612]  meson_drv_unbind+0x68/0xa4 [meson_drm]
    [   42.929436]  component_del+0xc0/0x180
    [   42.933058]  meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
    [   42.938576]  platform_drv_remove+0x38/0x60
    [   42.942628]  __device_release_driver+0x190/0x23c
    [   42.947198]  driver_detach+0xcc/0x160
    [   42.950822]  bus_remove_driver+0x68/0xe0
    [   42.954702]  driver_unregister+0x3c/0x6c
    [   42.958583]  platform_driver_unregister+0x20/0x2c
    [   42.963243]  meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
    [   42.970057]  __arm64_sys_delete_module+0x1bc/0x294
    [   42.974801]  el0_svc_common.constprop.0+0x80/0x240
    [   42.979542]  do_el0_svc+0x30/0xa0
    [   42.982821]  el0_svc+0x18/0x50
    [   42.985839]  el0_sync_handler+0x198/0x404
    [   42.989806]  el0_sync+0x158/0x180
    
    immediatelly followed by
    
    [   43.002296] WARNING: CPU: 0 PID: 572 at drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cleanup+0x2a8/0x304 [drm]
    [...]
    [   43.128150] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
    [   43.135052] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
    [   43.141062] pc : drm_mode_config_cleanup+0x2a8/0x304 [drm]
    [   43.146492] lr : drm_mode_config_cleanup+0xac/0x304 [drm]
    [...]
    [   43.233979] Call trace:
    [   43.236451]  drm_mode_config_cleanup+0x2a8/0x304 [drm]
    [   43.241538]  drm_mode_config_init_release+0x1c/0x2c [drm]
    [   43.246886]  drm_managed_release+0xa8/0x120 [drm]
    [   43.251543]  drm_dev_put+0x94/0xc0 [drm]
    [   43.255380]  meson_drv_unbind+0x78/0xa4 [meson_drm]
    [   43.260204]  component_del+0xc0/0x180
    [   43.263829]  meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
    [   43.269344]  platform_drv_remove+0x38/0x60
    [   43.273398]  __device_release_driver+0x190/0x23c
    [   43.277967]  driver_detach+0xcc/0x160
    [   43.281590]  bus_remove_driver+0x68/0xe0
    [   43.285471]  driver_unregister+0x3c/0x6c
    [   43.289352]  platform_driver_unregister+0x20/0x2c
    [   43.294011]  meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
    [   43.300826]  __arm64_sys_delete_module+0x1bc/0x294
    [   43.305570]  el0_svc_common.constprop.0+0x80/0x240
    [   43.310312]  do_el0_svc+0x30/0xa0
    [   43.313590]  el0_svc+0x18/0x50
    [   43.316608]  el0_sync_handler+0x198/0x404
    [   43.320574]  el0_sync+0x158/0x180
    [   43.323852] ---[ end trace d796a3072dab01da ]---
    [   43.328561] [drm:drm_mode_config_cleanup [drm]] *ERROR* connector HDMI-A-1 leaked!
    
    both triggered by the fact that the HDMI subsystem is still active,
    and the DRM removal doesn't result in the connectors being torn down.
    
    Call drm_atomic_helper_shutdown() and component_unbind_all() to safely
    tear the module down.
    
    Fixes: 2d8f92897ad8 ("drm/meson: Uninstall IRQ handler")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201116200744.495826-3-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2ddf64f5e9630dbec32b16d6480043006282388
Author: Marc Zyngier <maz@kernel.org>
Date:   Mon Nov 16 20:07:41 2020 +0000

    drm/meson: Free RDMA resources after tearing down DRM
    
    [ Upstream commit fa62ee25280ff6ae1f720f363263cb5e7743a8c8 ]
    
    Removing the meson DRM module results in the following splat:
    
    [ 2179.451346] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
    [ 2179.458316] Workqueue: events drm_mode_rmfb_work_fn [drm]
    [ 2179.463597] pstate: 80c00009 (Nzcv daif +PAN +UAO -TCO BTYPE=--)
    [ 2179.469558] pc : meson_rdma_writel_sync+0x44/0xb0 [meson_drm]
    [ 2179.475243] lr : meson_g12a_afbcd_reset+0x34/0x60 [meson_drm]
    [ 2179.480930] sp : ffffffc01212bb70
    [ 2179.484207] x29: ffffffc01212bb70 x28: ffffff8044f66f00
    [ 2179.489469] x27: ffffff8045b13800 x26: 0000000000000001
    [ 2179.494730] x25: 0000000000000000 x24: 0000000000000001
    [ 2179.499991] x23: 0000000000000000 x22: 0000000000000000
    [ 2179.505252] x21: 0000000000280000 x20: 0000000000001a01
    [ 2179.510513] x19: ffffff8046029480 x18: 0000000000000000
    [ 2179.515775] x17: 0000000000000000 x16: 0000000000000000
    [ 2179.521036] x15: 0000000000000000 x14: 0000000000000000
    [ 2179.526297] x13: 0040000000000326 x12: 0309030303260300
    [ 2179.531558] x11: 03000000054004a0 x10: 0418054004000400
    [ 2179.536820] x9 : ffffffc008fe4914 x8 : ffffff8040a1adc0
    [ 2179.542081] x7 : 0000000000000000 x6 : ffffff8042aa0080
    [ 2179.547342] x5 : ffffff8044f66f00 x4 : ffffffc008fe5bc8
    [ 2179.552603] x3 : 0000000000010101 x2 : 0000000000000001
    [ 2179.557865] x1 : 0000000000000000 x0 : 0000000000000000
    [ 2179.563127] Call trace:
    [ 2179.565548]  meson_rdma_writel_sync+0x44/0xb0 [meson_drm]
    [ 2179.570894]  meson_g12a_afbcd_reset+0x34/0x60 [meson_drm]
    [ 2179.576241]  meson_plane_atomic_disable+0x38/0xb0 [meson_drm]
    [ 2179.581966]  drm_atomic_helper_commit_planes+0x1e0/0x21c [drm_kms_helper]
    [ 2179.588684]  drm_atomic_helper_commit_tail_rpm+0x68/0xb0 [drm_kms_helper]
    [ 2179.595410]  commit_tail+0xac/0x190 [drm_kms_helper]
    [ 2179.600326]  drm_atomic_helper_commit+0x16c/0x390 [drm_kms_helper]
    [ 2179.606484]  drm_atomic_commit+0x58/0x70 [drm]
    [ 2179.610880]  drm_framebuffer_remove+0x398/0x434 [drm]
    [ 2179.615881]  drm_mode_rmfb_work_fn+0x68/0x8c [drm]
    [ 2179.620575]  process_one_work+0x1cc/0x49c
    [ 2179.624538]  worker_thread+0x200/0x444
    [ 2179.628246]  kthread+0x14c/0x160
    [ 2179.631439]  ret_from_fork+0x10/0x38
    
    caused by the fact that the RDMA buffer has already been freed,
    resulting in meson_rdma_writel_sync() getting a NULL pointer.
    
    Move the afbcd reset and meson_rdma_free calls after the DRM
    unregistration is complete so that the teardown can safely complete.
    
    Fixes: d1b5e41e13a7 ("drm/meson: Add AFBCD module driver")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201116200744.495826-2-maz@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b087cb814da21dff11f8aa5b288cc07e61220847
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 b9e069283b78dd890271ad146604d1a13906e758
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Mon Nov 16 14:22:06 2020 +0100

    mmc: sdhci: tegra: fix wrong unit with busy_timeout
    
    [ Upstream commit fcc541fea394d67ad607ee41acfa891e79fe17a2 ]
    
    'busy_timeout' is in msecs, not in jiffies. Use the correct factor.
    
    Fixes: 5e958e4aacf4 ("sdhci: tegra: Implement Tegra specific set_timeout callback")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Acked-by: Sowjanya Komatineni <skomatineni@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20201116132206.23518-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58d23abd5fa1c8b43afaecefd9ec0e82eafdbdc0
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 a622848f5938f1f86e5264c516b871d0967bbea1
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 e1a709edc21d96f5d986c1e8d844ec19fb9c1853
Author: Mansur Alisha Shaik <mansur@codeaurora.org>
Date:   Mon Oct 19 06:18:14 2020 +0200

    media: venus: put dummy vote on video-mem path after last session release
    
    [ Upstream commit eff5ce02e170125936c43ca96c7dc701a86681ed ]
    
    As per current implementation, video driver is unvoting "videom-mem" path
    for last video session during vdec_session_release().
    While video playback when we try to suspend device, we see video clock
    warnings since votes are already removed during vdec_session_release().
    
    corrected this by putting dummy vote on "video-mem" after last video
    session release and unvoting it during suspend.
    
    suspend")
    
    Fixes: 07f8f22a33a9e ("media: venus: core: remove CNOC voting while device
    Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43275d43b521d5dd1d99fdfcc753295550c801ab
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 c77798b58799139da0a68a04ed674c26eea588b5
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Nov 15 20:07:21 2020 -0800

    spi: dw: fix build error by selecting MULTIPLEXER
    
    [ Upstream commit 1241f0787578136ab58f49adc52f2dcd2bbc4bf2 ]
    
    Fix build error for spi-dw-bt1.o by selecting MULTIPLEXER.
    
    hppa-linux-ld: drivers/spi/spi-dw-bt1.o: in function `dw_spi_bt1_sys_init':
    (.text+0x1ac): undefined reference to `devm_mux_control_get'
    
    Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: linux-spi@vger.kernel.org
    Acked-by: Serge Semin <fancer.lancer@gmail.com>
    Link: https://lore.kernel.org/r/20201116040721.8001-1-rdunlap@infradead.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a5333fb175b1eda63f0f114f18ad1237d42f4c1
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 70ba8b1697e35c04ea5f22edb6e401aeb1208d96
Author: Leon Romanovsky <leon@kernel.org>
Date:   Wed Nov 4 16:40:07 2020 +0200

    RDMA/cma: Add missing error handling of listen_id
    
    [ Upstream commit c80a0c52d85c49a910d0dc0e342e8d8898677dc0 ]
    
    Don't silently continue if rdma_listen() fails but destroy previously
    created CM_ID and return an error to the caller.
    
    Fixes: d02d1f5359e7 ("RDMA/cma: Fix deadlock destroying listen requests")
    Link: https://lore.kernel.org/r/20201104144008.3808124-5-leon@kernel.org
    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 8d82904f8d220153af49d02273f1751a4426669d
Author: Mansur Alisha Shaik <mansur@codeaurora.org>
Date:   Mon Oct 19 06:18:13 2020 +0200

    media: venus: core: vote with average bandwidth and peak bandwidth as zero
    
    [ Upstream commit e44fb034b03231cd117d6db73fb8048deab6ea41 ]
    
    As per bandwidth table video driver is voting with average bandwidth
    for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
    in bandwidth table.
    
    suspend")
    
    Fixes: 07f8f22a33a9e ("media: venus: core: remove CNOC voting while device
    Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d28c98f44af3e88f15312dffac29ce5a4329bdb
Author: Mansur Alisha Shaik <mansur@codeaurora.org>
Date:   Mon Oct 19 06:18:12 2020 +0200

    media: venus: core: vote for video-mem path
    
    [ Upstream commit 9e8efdb5787986cc0d0134925cf5c4f001bb3f2e ]
    
    Currently video driver is voting for venus0-ebi path during buffer
    processing with an average bandwidth of all the instances and
    unvoting during session release.
    
    While video streaming when we try to do XO-SD using the command
    "echo mem > /sys/power/state command" , device is not entering
    to suspend state and from interconnect summary seeing votes for venus0-ebi
    
    Corrected this by voting for venus0-ebi path in venus_runtime_resume()
    and unvote during venus_runtime_suspend().
    
    suspend")
    
    Fixes: 07f8f22a33a9e ("media: venus: core: remove CNOC voting while device
    Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9acc5fa0aeb29a3124e8f0e557324b466e06308f
Author: Mansur Alisha Shaik <mansur@codeaurora.org>
Date:   Mon Oct 19 06:18:11 2020 +0200

    media: venus: core: change clk enable and disable order in resume and suspend
    
    [ Upstream commit 21926d466e3a4f35c2536244d1d56512cc81a0a9 ]
    
    Currently video driver is voting after clk enable and un voting
    before clk disable. This is incorrect, video driver should vote
    before clk enable and unvote after clk disable.
    
    Corrected this by changing the order of clk enable and clk disable.
    
    suspend")
    
    Fixes: 07f8f22a33a9e ("media: venus: core: remove CNOC voting while device
    Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 393957d3976238dbcd0f645f67184fae00124dc1
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Wed Nov 4 13:41:36 2020 +0100

    media: platform: add missing put_device() call in mtk_jpeg_probe() and mtk_jpeg_remove()
    
    [ Upstream commit 0d72f489995bb8565f6fe30539d4504c88356a9e ]
    
    if mtk_jpeg_clk_init() succeed, mtk_jpeg_probe() and mtk_jpeg_remove()
    doesn't have a corresponding put_device(). Thus add a new helper
    mtk_jpeg_clk_release() to fix it.
    
    Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG 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 a3307503af9e520b88d5fdb3654ab3e484420e01
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 15:26:22 2020 +0100

    media: cedrus: fix reference leak in cedrus_start_streaming
    
    [ Upstream commit 940727bf22f74cbdef8de327de34c4ae565c89ea ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in cedrus_start_streaming. We should fix it.
    
    Fixes: d5aecd289babf ("media: cedrus: Implement runtime PM")
    Signed-off-by: Zhang Qilong <zhangqilong3@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 d5b2529aa572bb0da814146f6794f49b5e9110be
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 15:28:52 2020 +0100

    media: staging: rkisp1: cap: fix runtime PM imbalance on error
    
    [ Upstream commit 4cbbe2aaa0536b0e7b3dfbd7febc3bc2ec300559 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference imbalance in rkisp1_vb2_start_streaming, so we
    should fix it.
    
    Fixes: 56e3b29f9f6b2 ("media: staging: rkisp1: add streaming paths")
    Signed-off-by: Zhang Qilong <zhangqilong3@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 cbb25882cd66de5b84fa8762c176e5c7c2a76dba
Author: Hugues Fruchet <hugues.fruchet@st.com>
Date:   Tue Oct 13 11:02:23 2020 +0200

    media: ov5640: fix support of BT656 bus mode
    
    [ Upstream commit 68579b32e786f9680e7c6b6c7d17e26943bb02b3 ]
    
    Fix PCLK polarity not being taken into account.
    Add comments about BT656 register control.
    Remove useless ov5640_set_stream_bt656() function.
    Refine comments about MIPI IO register control.
    
    Fixes: 4039b03720f7 ("media: i2c: ov5640: Add support for BT656 mode")
    Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
    Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b9209c963fb0445e0f74cee100cdc05ede3942e
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Wed Sep 30 14:08:03 2020 +0200

    media: v4l2-fwnode: v4l2_fwnode_endpoint_parse caller must init vep argument
    
    [ Upstream commit b3cc73d2bf14e7c6e0376fa9433e708349e9ddfc ]
    
    Document that the caller of v4l2_fwnode_endpoint_parse() must init the
    fields of struct v4l2_fwnode_endpoint (vep argument) fields.
    
    It used to be that the fields were zeroed by v4l2_fwnode_endpoint_parse
    when bus type was set to V4L2_MBUS_UNKNOWN but with recent changes (Fixes:
    line below) that no longer makes sense.
    
    Fixes: bb4bba9232fc ("media: v4l2-fwnode: Make bus configuration a struct")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f43c83293044297f1d3493568bae84c22de8f5cf
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Thu Sep 17 18:08:47 2020 +0200

    media: v4l2-fwnode: Return -EINVAL for invalid bus-type
    
    [ Upstream commit 69baf338fc16a4d55c78da8874ce3f06feb38c78 ]
    
    Return -EINVAL if invalid bus-type is detected while parsing endpoints.
    
    Fixes: 26c1126c9b56 ("media: v4l: fwnode: Use media bus type for bus parser selection")
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    media: mtk-vcodec: add missing put_device() call in mtk_vcodec_init_enc_pm()
    
    [ Upstream commit 4affafd7bec7c65da31777f18bd20420f1aeb5f8 ]
    
    if of_find_device_by_node() succeed, mtk_vcodec_init_enc_pm() doesn't have
    a corresponding put_device(). Thus add jump target to fix the exception
    handling for this function implementation.
    
    Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder 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 1144412d4a0cfeb142396d4e5371e149f30718e0
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 d9292412258bf3a8d7dd93d075a6fdd670cb8901
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Oct 9 14:38:01 2020 +0200

    media: mtk-vcodec: add missing put_device() call in mtk_vcodec_init_dec_pm()
    
    [ Upstream commit 5d4fa2c50125c9cda9e380d89268757cc5fa743d ]
    
    if of_find_device_by_node() succeed, mtk_vcodec_init_dec_pm() doesn't have
    a corresponding put_device(). Thus add jump target to fix the exception
    handling for this function implementation.
    
    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 c7ffc289daa3fb264e271b3a5b4f533a61f91e9c
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Oct 9 14:37:58 2020 +0200

    media: platform: add missing put_device() call in mtk_jpeg_clk_init()
    
    [ Upstream commit f28a81a3b64270da3588174feff4628c36e0ff4e ]
    
    if of_find_device_by_node() succeeds, mtk_jpeg_clk_init() doesn't have
    a corresponding put_device(). Thus add put_device() to fix the exception
    handling for this function implementation.
    
    Fixes: 648372a87cee ("media: platform: Change the call functions of getting/enable/disable the jpeg's clock")
    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 22ec70191039a9a5c22c07d0f53a79b3aca0a9e7
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 3d28470532a38eff26d0eb4875effbc0ffa09d41
Author: Shannon Nelson <snelson@pensando.io>
Date:   Thu Nov 12 10:22:07 2020 -0800

    ionic: change set_rx_mode from_ndo to can_sleep
    
    [ Upstream commit 81dbc24147f9250c186ae5875b3ed3136e9e293b ]
    
    Instead of having two different ways of expressing the same
    sleepability concept, using opposite logic, we can rework the
    from_ndo to can_sleep for a more consistent usage.
    
    Fixes: 1800eee16676 ("net: ionic: Replace in_interrupt() usage.")
    Signed-off-by: Shannon Nelson <snelson@pensando.io>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee6bf69107b04ea7865faa4759cbe4243f7518f1
Author: Shannon Nelson <snelson@pensando.io>
Date:   Thu Nov 12 10:22:06 2020 -0800

    ionic: flatten calls to ionic_lif_rx_mode
    
    [ Upstream commit e94f76bb206333efcd0c02da5dbb142518c941a2 ]
    
    The _ionic_lif_rx_mode() is only used once and really doesn't
    need to be broken out.
    
    Signed-off-by: Shannon Nelson <snelson@pensando.io>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68684d55e57845c1265a6c5f5133aaf716c17667
Author: Shannon Nelson <snelson@pensando.io>
Date:   Thu Nov 12 10:22:05 2020 -0800

    ionic: use mc sync for multicast filters
    
    [ Upstream commit e0243e1966592859da4c6ffe6d43e1576ec3c457 ]
    
    We should be using the multicast sync routines for the multicast
    filters.  Also, let's just flatten the logic a bit and pull
    the small unicast routine back into ionic_set_rx_mode().
    
    Fixes: 1800eee16676 ("net: ionic: Replace in_interrupt() usage.")
    Signed-off-by: Shannon Nelson <snelson@pensando.io>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91a5950181d1e4d4558311d64f54763679aaaa90
Author: Hanjun Guo <guohanjun@huawei.com>
Date:   Fri Nov 13 11:11:14 2020 +0800

    drm/amdkfd: Put ACPI table after using it
    
    [ Upstream commit c4cb773c702be5519442c8375a6476d08fe2cb46 ]
    
    The acpi_get_table() should be coupled with acpi_put_table() if
    the mapped table is not used at runtime to release the table
    mapping which can prevent the memory leak.
    
    In kfd_create_crat_image_acpi(), crat_table is copied to pcrat_image,
    and in kfd_create_vcrat_image_cpu(), the acpi_table is only used to
    get the OEM information, so those two table mappings need to be released
    after using it.
    
    Fixes: 174de876d6d0 ("drm/amdkfd: Group up CRAT related functions")
    Fixes: 520b8fb755cc ("drm/amdkfd: Add topology support for CPUs")
    Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c0aa48d046d2150c2510342ed45c8b84254f344
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Nov 2 19:06:37 2020 +0200

    scripts: kernel-doc: Restore anonymous enum parsing
    
    [ Upstream commit ae5b17e464146ddb8fee744fa2150922d6072916 ]
    
    The commit d38c8cfb0571 ("scripts: kernel-doc: add support for typedef enum")
    broke anonymous enum parsing. Restore it by relying on members rather than
    its name.
    
    Fixes: d38c8cfb0571 ("scripts: kernel-doc: add support for typedef enum")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Link: https://lore.kernel.org/r/20201102170637.36138-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f1cae8e15a68be2724777356fb2aba4a592b39d
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 63c4e010a53066fa8530ffd21324ebcdb7b0d87b
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 e4e1f57c6afb6b41e80f677ad1defc0bdf138ae5
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Nov 13 13:15:02 2020 +0300

    drm/udl: Fix missing error code in udl_handle_damage()
    
    [ Upstream commit a7319c8f50c5e93a12997e2d0821a2f7946fb734 ]
    
    If udl_get_urb() fails then this should return a negative error code
    but currently it returns success.
    
    Fixes: 798ce3fe1c3a ("drm/udl: Begin/end access to imported buffers in damage-handler")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201113101502.GD168908@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fa9f294415374b02faabee6a20671874c9cacb8
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Tue Nov 10 15:42:21 2020 +0800

    firmware: arm_scmi: Fix missing destroy_workqueue()
    
    [ Upstream commit 6bbdb46c4b1bd57839c9c0a110bd81b0be0a4046 ]
    
    destroy_workqueue is required before the return from scmi_notification_init
    in case devm_kcalloc fails to allocate registered_protocols. Fix this by
    simply moving registered_protocols allocation before alloc_workqueue.
    
    Link: https://lore.kernel.org/r/20201110074221.41235-1-miaoqinglang@huawei.com
    Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery")
    Suggested-by: Cristian Marussi <cristian.marussi@arm.com>
    Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27a26763de9abc07257cbbc8c37dbf3d0e85d05b
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 4110602d9d730fc934e8e1a8bdafd3659d2579ed
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Nov 2 14:48:15 2020 +0100

    crypto: Kconfig - CRYPTO_MANAGER_EXTRA_TESTS requires the manager
    
    [ Upstream commit 6569e3097f1c4a490bdf2b23d326855e04942dfd ]
    
    The extra tests in the manager actually require the manager to be
    selected too. Otherwise the linker gives errors like:
    
    ld: arch/x86/crypto/chacha_glue.o: in function `chacha_simd_stream_xor':
    chacha_glue.c:(.text+0x422): undefined reference to `crypto_simd_disabled_for_test'
    
    Fixes: 2343d1529aff ("crypto: Kconfig - allow tests to be disabled when manager is disabled")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53cb44edb2677efd624bfae31d6be84b9b1326da
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Nov 16 12:57:13 2020 +0200

    soc: ti: omap-prm: Do not check rstst bit on deassert if already deasserted
    
    [ Upstream commit c1995e5afaf6abf3922b5395ad1f4096951e3276 ]
    
    If a rstctrl reset bit is already deasserted, we can just bail out early
    not wait for rstst to clear. Otherwise we can have deassert fail for
    already deasserted resets.
    
    Fixes: c5117a78dd88 ("soc: ti: omap-prm: poll for reset complete during de-assert")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5f81cb875ba151a2e2886778a93d56254b4f5a3
Author: Nirmoy Das <nirmoy.das@amd.com>
Date:   Mon Nov 9 17:04:51 2020 +0100

    drm/amdgpu: fix compute queue priority if num_kcq is less than 4
    
    [ Upstream commit 3f66bf401e9fde1c35bb8b02dd7975659c40411d ]
    
    Compute queues are configurable with module param, num_kcq.
    amdgpu_gfx_is_high_priority_compute_queue was setting 1st 4 queues to
    high priority queue leaving a null drm scheduler in
    adev->gpu_sched[hw_ip]["normal_prio"].sched if num_kcq < 5.
    
    This patch tries to fix it by alternating compute queue priority between
    normal and high priority.
    
    Fixes: 33abcb1f5a1719b1c (drm/amdgpu: set compute queue priority at mqd_init)
    Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 070dfffdc278608d35dbc066cc72bd5e070fbd2a
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 c77a95b65bdc1107878332233317b55004c418ee
Author: Nishanth Menon <nm@ti.com>
Date:   Wed Nov 4 16:25:19 2020 -0600

    arm64: dts: ti: k3-am65*/j721e*: Fix unit address format error for dss node
    
    [ Upstream commit cfbf17e69ae82f647c287366b7573e532fc281ee ]
    
    Fix the node address to follow the device tree convention.
    
    This fixes the dtc warning:
    <stdout>: Warning (simple_bus_reg): /bus@100000/dss@04a00000: simple-bus
    unit address format error, expected "4a00000"
    
    Fixes: 76921f15acc0 ("arm64: dts: ti: k3-j721e-main: Add DSS node")
    Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Reviewed-by: Jyri Sarha <jsarha@ti.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Jyri Sarha <jsarha@ti.com>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Link: https://lore.kernel.org/r/20201104222519.12308-1-nm@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 10811262111e10a5648663dfc2e7371cfdf13fff
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Nov 12 10:44:25 2020 -0600

    ASoC: SOF: Intel: fix Kconfig dependency for SND_INTEL_DSP_CONFIG
    
    [ Upstream commit 358f0ac1f2791c80c19cc26706cf34664c9fd756 ]
    
    SND_INTEL_DSP_CONFIG is selected by the HDaudio, Skylake and SOF
    drivers. When the HDaudio link is not selected as a option, this
    Kconfig option is not touched and will default to whatever other
    drivers selected. In the case e.g. where HDaudio is compiled as
    built-in, the linker will complain:
    
    ld: sound/soc/sof/sof-pci-dev.o: in function `sof_pci_probe':
    sof-pci-dev.c:(.text+0x5c): undefined reference to
    `snd_intel_dsp_driver_probe'
    
    Adding the select for all HDaudio platforms, regardless of whether
    they rely on the HDaudio link or not, solves the problem.
    
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Fixes: 82d9d54a6c0ee ('ALSA: hda: add Intel DSP configuration / probe code')
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20201112164425.25603-5-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec6a178521bf753372820b49e773a2db500b8a4d
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 81d23c1d63f37a9506298f98920463a239b9ea6d
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 941327d40d30ac345899bbcd6f9e8c50397b574f
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Nov 11 17:22:31 2020 +0100

    virtiofs fix leak in setup
    
    [ Upstream commit 66ab33bf6d4341574f88b511e856a73f6f2a921e ]
    
    This can be triggered for example by adding the "-omand" mount option,
    which will be rejected and virtio_fs_fill_super() will return an error.
    
    In such a case the allocations for fuse_conn and fuse_mount will leak due
    to s_root not yet being set and so ->put_super() not being called.
    
    Fixes: a62a8ef9d97d ("virtio-fs: add virtiofs filesystem")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b14a8f29c31eee6a525c20a2210cb81ca2b28c68
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Nov 6 09:50:35 2020 +0800

    spi: sprd: fix reference leak in sprd_spi_remove
    
    [ Upstream commit e4062765bc2a41e025e29dd56bad798505036427 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in sprd_spi_remove, so we should fix it.
    
    Fixes: e7d973a31c24b ("spi: sprd: Add SPI driver for Spreadtrum SC9860")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
    Link: https://lore.kernel.org/r/20201106015035.139574-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82162f4bdf6a89f719fcf4a4ae6fde2c6194abee
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 351d0015c1bf5977b9aa88c325d8ff56158f762e
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Wed Nov 11 12:13:24 2020 +0800

    ASoC: wm8994: Fix PM disable depth imbalance on error
    
    [ Upstream commit b8161cbe55a1892a19a318eaebbda92438fa708c ]
    
    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: 57e265c8d71fb ("ASoC: wm8994: Move runtime PM init to platform device init")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20201111041326.1257558-2-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f48a2000249908792c3396648b9b77ec264a71a
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Tue Nov 10 09:50:12 2020 +0800

    selftest/bpf: Add missed ip6ip6 test back
    
    [ Upstream commit 58cfa49c2ba7f815adccc27a775e7cf8a8f7f539 ]
    
    In comment 173ca26e9b51 ("samples/bpf: add comprehensive ipip, ipip6,
    ip6ip6 test") we added ip6ip6 test for bpf tunnel testing. But in commit
    933a741e3b82 ("selftests/bpf: bpf tunnel test.") when we moved it to
    the current folder, we didn't add it.
    
    This patch add the ip6ip6 test back to bpf tunnel test. Update the ipip6's
    topology for both IPv4 and IPv6 testing. Since iperf test is removed as
    currect framework simplified it in purpose, I also removed unused tcp
    checkings in test_tunnel_kern.c.
    
    Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20201110015013.1570716-2-liuhangbin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8a4a04ddfdbbafe6adbe50b787f086d3ecb729a
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Oct 28 16:31:14 2020 +0800

    selftests/run_kselftest.sh: fix dry-run typo
    
    [ Upstream commit 93f20eff0cca972d74cb554a2e8b47730228be16 ]
    
    Should be -d instead of -n for dry-run.
    
    Fixes: 5da1918446a1 ("selftests/run_kselftest.sh: Make each test individually selectable")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56b491d7de00c7c5e87edf58482a12eb2749aa1c
Author: Abhinav Kumar <abhinavk@codeaurora.org>
Date:   Mon Nov 2 17:10:23 2020 -0800

    drm/msm/dp: do not notify audio subsystem if sink doesn't support audio
    
    [ Upstream commit e8c765811b1064c200829eacf237ac8c25e79cd0 ]
    
    For sinks that do not support audio, there is no need to notify
    audio subsystem of the connection event.
    
    This will make sure that audio routes only to the primary display
    when connected to such sinks.
    
    changes in v2:
      - Added fixes tag
      - Removed nested if condition and removed usage of global pointer
    
    Fixes: d13e36d7d222 ("drm/msm/dp: add audio support for Display Port on MSM")
    Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be5795e2098fc4ccc6655bbb3588cef6d81499c5
Author: Kuogee Hsieh <khsieh@codeaurora.org>
Date:   Tue Nov 3 12:49:01 2020 -0800

    drm/msm/dp: skip checking LINK_STATUS_UPDATED bit
    
    [ Upstream commit ea530388e64bd584645f2d89e40ca7dffade8eff ]
    
    Some dongle will not clear LINK_STATUS_UPDATED bit after
    DPCD read which cause link training failed. This patch
    just read 6 bytes of DPCD link status from sink and return
    without checking LINK_STATUS_UPDATED bit.
    Only 8 bits are used to represent link rate at sinker DPCD.
    The really link rate is 2.7Mb times the 8 bits value.
    For example, 0x0A at DPCD is equal to 2.7Gb (10 * 2.7Mb).
    This patch also convert 8 bits value of DPCD to really link
    rate to fix worng link rate error during phy compliance test.
    
    Fixes: 6625e2637d93 ("drm/msm/dp: DisplayPort PHY compliance tests fixup")
    Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae5b3fc2dce45fabc8463e001aa70d1c1cabe124
Author: Kuogee Hsieh <khsieh@codeaurora.org>
Date:   Tue Nov 3 14:53:35 2020 -0800

    drm/msm/dp: return correct connection status after suspend
    
    [ Upstream commit 19e52bcb27c2ba140699d2230d722366d7d048a1 ]
    
    During suspend, dp host controller and hpd block are disabled due to
    both ahb and aux clock are disabled. Therefore hpd plug/unplug interrupts
    will not be generated. At dp_pm_resume(), reinitialize both dp host
    controller and hpd block so that hpd plug/unplug interrupts will be
    generated and handled by driver so that hpd connection state is updated
    correctly. This patch will fix link training flaky issues.
    
    Changes in v2:
    -- use container_of to cast correct dp_display_private pointer
       at both dp_pm_suspend() and dp_pm_resume().
    
    Changes in v3:
    -- replace hpd_state atomic_t  with u32
    
    Changes in v4
    -- call dp_display_host_deinit() at dp_pm_suspend()
    -- call dp_display_host_init() at msm_dp_display_enable()
    -- fix phy->init_count unbalance which causes link training failed
    
    Changes in v5
    --  add Fixes tag
    
    Fixes:  8ede2ecc3e5e (drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets)
    Tested-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b0a337dec82780f3b009e0d2aae728f918bafd8
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 26 17:49:21 2020 +0100

    firmware: tegra: fix strncpy()/strncat() confusion
    
    [ Upstream commit 9294996f0be40e9da818ed891c82397ab63c00d0 ]
    
    The way that bpmp_populate_debugfs_inband() uses strncpy()
    and strncat() makes no sense since the size argument for
    the first is insufficient to contain the trailing '/'
    and the second passes the length of the input rather than
    the output, which triggers a warning:
    
    In function 'strncat',
        inlined from 'bpmp_populate_debugfs_inband' at ../drivers/firmware/tegra/bpmp-debugfs.c:422:4:
    include/linux/string.h:289:30: warning: '__builtin_strncat' specified bound depends on the length of the source argument [-Wstringop-overflow=]
      289 | #define __underlying_strncat __builtin_strncat
          |                              ^
    include/linux/string.h:367:10: note: in expansion of macro '__underlying_strncat'
      367 |   return __underlying_strncat(p, q, count);
          |          ^~~~~~~~~~~~~~~~~~~~
    drivers/firmware/tegra/bpmp-debugfs.c: In function 'bpmp_populate_debugfs_inband':
    include/linux/string.h:288:29: note: length computed here
      288 | #define __underlying_strlen __builtin_strlen
          |                             ^
    include/linux/string.h:321:10: note: in expansion of macro '__underlying_strlen'
      321 |   return __underlying_strlen(p);
    
    Simplify this to use an snprintf() instead.
    
    Fixes: 5e37b9c137ee ("firmware: tegra: Add support for in-band debug")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66bb2a8a601111a9adc0b44e730291a52350c250
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Nov 10 10:39:46 2020 -0800

    drm/msm/a5xx: Clear shadow on suspend
    
    [ Upstream commit 5771de5d5b3bfaf279e5c262a113d4b6fbe54355 ]
    
    Similar to the previous patch, clear shadow on suspend to avoid timeouts
    waiting for ringbuffer space.
    
    Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as privileged")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3edab64c3e424a71afd09fabd57c329a0baaac28
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Nov 10 10:23:06 2020 -0800

    drm/msm/a6xx: Clear shadow on suspend
    
    [ Upstream commit e8b0b994c3a5881f0648d53f90435120089c56ad ]
    
    Clear the shadow rptr on suspend.  Otherwise, when we resume, we can
    have a stale value until CP_WHERE_AM_I executes.  If we suspend near
    the ringbuffer wraparound point, this can lead to a chicken/egg
    situation where we are waiting for ringbuffer space to write the
    CP_WHERE_AM_I (or CP_INIT) packet, because we mistakenly believe that
    the ringbuffer is full (due to stale rptr value in the shadow).
    
    Fixes errors like:
    
      [drm:adreno_wait_ring [msm]] *ERROR* timeout waiting for space in ringbuffer 0
    
    in the resume path.
    
    Fixes: d3a569fccfa0 ("drm/msm: a6xx: Use WHERE_AM_I for eligible targets")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b38258b69352e68163a6e6d3d8004719967c1787
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 00f7592609c98412cabdbc82fa7549f9fb077982
Author: Alex Dewar <alex.dewar90@gmail.com>
Date:   Sat Nov 7 10:16:29 2020 +0200

    ath11k: Handle errors if peer creation fails
    
    [ Upstream commit c134d1f8c436d96b3f62896c630278e3ec001280 ]
    
    ath11k_peer_create() is called without its return value being checked,
    meaning errors will be unhandled. Add missing check and, as the mutex is
    unconditionally unlocked on leaving this function, simplify the exit
    path.
    
    Addresses-Coverity-ID: 1497531 ("Code maintainability issues")
    Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
    Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201004100218.311653-1-alex.dewar90@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 468b3a1ab2877f44d67ad3ffe82f82acea96365b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Nov 5 15:51:54 2020 +0300

    ASoC: qcom: common: Fix refcounting in qcom_snd_parse_of()
    
    [ Upstream commit 4e59dd249cd513a211e2ecce2cb31f4e29a5ce5b ]
    
    There are two issues in this function.
    
    1) We can't drop the refrences on "cpu", "codec" and "platform" before
       we take the reference.  This doesn't cause a problem on the first
       iteration because those pointers start as NULL so the of_node_put()
       is a no-op.  But on the subsequent iterations, it will lead to a use
       after free.
    
    2) If the devm_kzalloc() allocation failed then the code returned
       directly instead of cleaning up.
    
    Fixes: c1e6414cdc37 ("ASoC: qcom: common: Fix refcount imbalance on error")
    Fixes: 1e36ea360ab9 ("ASoC: qcom: common: use modern dai_link style")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20201105125154.GA176426@mwanda
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 851228fd1f6782e89b02b0d4f8b25db75b8881c6
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Nov 2 22:58:35 2020 +0800

    spi: imx: fix reference leak in two imx operations
    
    [ Upstream commit 1dcbdd944824369d4569959f8130336fe6fe5f39 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in callers(spi_imx_prepare_message and
    spi_imx_remove), so we should fix it.
    
    Fixes: 525c9e5a32bd7 ("spi: imx: enable runtime pm support")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201102145835.4765-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8c65a716e8d862210394d76d492e0dc74f31ac3
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 d7dc725c7eb4ead569ee2dee9c4a8fd3c1f28fd3
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 b25ccec949692e4d6541706c0680a8f4442b170b
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 0c26f7b292dad14ca25613939464d2c596bbb043
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 6f3e58894446441eae0de2f86ff10f801f75378e
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
    
    [ Upstream commit 702b15cb97123cedcec56a39d9a21c5288eb9ae1 ]
    
    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: Sasha Levin <sashal@kernel.org>

commit 7e2556779cb7a9f0af1de93f4ee0f01a25fa95ab
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 ea5ee372c7265cd02785b02d22c747ca888f3741
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Nov 6 09:53:57 2020 +0800

    spi: stm32-qspi: fix reference leak in stm32 qspi operations
    
    [ Upstream commit 88e1419b5ee30cc50e0c4d5265bdee1ba04af539 ]
    
    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(stm32_qspi_exec_op and
    stm32_qspi_setup), so we should fix it.
    
    Fixes: 9d282c17b023a ("spi: stm32-qspi: Add pm_runtime support")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
    Link: https://lore.kernel.org/r/20201106015357.141235-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f48dbf5152336f4b831a4afa8c8ae4f62af03077
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 c98d3357920623bbb5a316907bfbc9c300552873
Author: Sathish Narasimman <nsathish41@gmail.com>
Date:   Thu Oct 29 13:18:21 2020 +0530

    Bluetooth: Fix: LL PRivacy BLE device fails to connect
    
    [ Upstream commit 1fb17dfc258ff6208f7873cc7b8e40e27515d2d5 ]
    
    When adding device to white list the device is added to resolving list
    also. It has to be added only when HCI_ENABLE_LL_PRIVACY flag is set.
    HCI_ENABLE_LL_PRIVACY flag has to be tested before adding/deleting devices
    to resolving list. use_ll_privacy macro is used only to check if controller
    supports LL_Privacy.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=209745
    
    Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist")
    Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 147cdf5f344b8432f103bc154eb250f848c54767
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 1a5f0500d885b2e97a0d3fdb5735530c168e0c78
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Fri Nov 6 10:23:33 2020 -0800

    drm/panel: simple: Add flags to boe_nv133fhm_n61
    
    [ Upstream commit ab6fd5d44aa21ede9e566f89132f7bdda7f33093 ]
    
    Reading the EDID of this panel shows that these flags should be set. Set
    them so that we match what is in the EDID.
    
    Cc: Douglas Anderson <dianders@chromium.org>
    Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
    Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201106182333.3080124-1-swboyd@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 848ad332d74de338a4d0dae8f58be7255c403bff
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 ac5ae8c926670295426aa982e0712b8b9718fc2d
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 af9d37f4343675da3b8f63d4629a6508af7f7480
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Wed Oct 28 10:52:47 2020 +0900

    brcmfmac: Fix memory leak for unpaired brcmf_{alloc/free}
    
    [ Upstream commit 9db946284e07bb27309dd546b7fee528664ba82a ]
    
    There are missig brcmf_free() for brcmf_alloc(). Fix memory leak
    by adding missed brcmf_free().
    
    Reported-by: Jaehoon Chung <jh80.chung@samsung.com>
    Fixes: a1f5aac1765a ("brcmfmac: don't realloc wiphy during PCIe reset")
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1603849967-22817-1-git-send-email-sw0312.kim@samsung.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a8fe3e58c3e4d2f333ed6e4818b311d39b70eca
Author: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Date:   Wed Nov 4 23:17:00 2020 +0530

    ath11k: fix wmi init configuration
    
    [ Upstream commit 36c7c640ffeb87168e5ff79b7a36ae3a020bd378 ]
    
    Assign the correct hw_op ath11k_init_wmi_config_ipq8074 to
    the hw IPQ8074. Also update the correct TWT radio count.
    Incorrect TWT radio count cause TWT feature fails on radio2
    because physical device count is hardcoded to 2. so set
    the value dynamically.
    
    Found this during code review.
    
    Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01238-QCAHKSWPL_SILICONZ-2
    
    Fixes: 2d4bcbed5b7d53e1 ("ath11k: initialize wmi config based on hw_params")
    Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1604512020-25197-1-git-send-email-periyasa@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3f640e6a085695f0153e775833033c62ce4e164
Author: Sven Eckelmann <sven@narfation.org>
Date:   Fri Oct 30 11:19:40 2020 +0100

    ath11k: Fix number of rules in filtered ETSI regdomain
    
    [ Upstream commit 6189be7d145c3a2d48514eb8755483602ff5a4b4 ]
    
    The ath11k code will try to insert wheather rader related limits when the
    DFS region is set to ETSI. For this reason, it will add two more entries in
    the array of reg_rules. But the 2.4.0.1 firmware is prefiltering the list
    of reg rules it returns for 2.4GHz PHYs. They will then not contain the
    list of 5GHz rules and thus no wheather radar band rules were inserted by
    this code.
    
    But the code didn't fix the n_reg_rules for this regulatory domain and PHY
    when this happened. This resulted in a rejection by is_valid_rd because it
    found rules which start and end at 0khz. This resulted in a splat like:
    
      Invalid regulatory domain detected
      ------------[ cut here ]------------
      WARNING: at backports-20200628-4.4.60-9a94b73e75/net/wireless/reg.c:3721
      [...]
      ath11k c000000.wifi1: failed to perform regd update : -22
    
    The number of rules must therefore be saved after they were converted from
    the ath11k format to the ieee80211_regdomain format and not before.
    
    Tested with IPQ8074 WLAN.HK.2.4.0.1.r1-00019-QCAHKSWPL_SILICONZ-1
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201030101940.2387952-1-sven@narfation.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce79baf7b3ebfd4daa52e07debf6d40135e12ea6
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed Oct 21 16:05:55 2020 +0200

    ath11k: Initialize complete alpha2 for regulatory change
    
    [ Upstream commit 383a32cde4172db19d4743d4c782c00af39ff275 ]
    
    The function ath11k_wmi_send_init_country_cmd is taking 3 byte from alpha2
    of the structure wmi_init_country_params. But the function
    ath11k_reg_notifier is only initializing 2 bytes. The third byte is
    therefore always an uninitialized value.
    
    The command can happen to look like
    
      0c 00 87 02 01 00 00 00 00 00 00 00 43 41 f8 00
    
    instead of
    
      0c 00 87 02 01 00 00 00 00 00 00 00 43 41 00 00
    
    Tested-on: IPQ8074 hw2.0 WLAN.HK.2.1.0.1-01161-QCAHKSWPL_SILICONZ-1
    Tested-on: IPQ8074 hw2.0 WLAN.HK.2.1.0.1-01228-QCAHKSWPL_SILICONZ-1
    Tested-on: IPQ8074 hw2.0 WLAN.HK.2.1.0.1-01238-QCAHKSWPL_SILICONZ-2
    Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00019-QCAHKSWPL_SILICONZ-1
    Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00026-QCAHKSWPL_SILICONZ-2
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201021140555.4114715-1-sven@narfation.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d43f95abf1cfe2aebf06eddcc6531b20afebff6
Author: Lyude Paul <lyude@redhat.com>
Date:   Thu Nov 5 18:57:02 2020 -0500

    drm/edid: Fix uninitialized variable in drm_cvt_modes()
    
    [ Upstream commit 991fcb77f490390bcad89fa67d95763c58cdc04c ]
    
    Noticed this when trying to compile with -Wall on a kernel fork. We
    potentially don't set width here, which causes the compiler to complain
    about width potentially being uninitialized in drm_cvt_modes(). So, let's
    fix that.
    
    Changes since v1:
    * Don't emit an error as this code isn't reachable, just mark it as such
    Changes since v2:
    * Remove now unused variable
    
    Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201105235703.1328115-1-lyude@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2aa2d48927a1a021c64a309b379120a3c452aebc
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Fri Nov 6 22:12:16 2020 +0800

    x86/mce: Correct the detection of invalid notifier priorities
    
    [ Upstream commit 15af36596ae305aefc8c502c2d3e8c58221709eb ]
    
    Commit
    
      c9c6d216ed28 ("x86/mce: Rename "first" function as "early"")
    
    changed the enumeration of MCE notifier priorities. Correct the check
    for notifier priorities to cover the new range.
    
     [ bp: Rewrite commit message, remove superfluous brackets in
       conditional. ]
    
    Fixes: c9c6d216ed28 ("x86/mce: Rename "first" function as "early"")
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20201106141216.2062-2-thunder.leizhen@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c306918ce98bc7cb66c62481b18d7e554556d4a7
Author: KP Singh <kpsingh@google.com>
Date:   Fri Nov 6 10:37:44 2020 +0000

    bpf: Fix tests for local_storage
    
    [ Upstream commit f0e5ba0bc481df77cf0afac2b33e420b33eeb463 ]
    
    The {inode,sk}_storage_result checking if the correct value was retrieved
    was being clobbered unconditionally by the return value of the
    bpf_{inode,sk}_storage_delete call.
    
    Also, consistently use the newly added BPF_LOCAL_STORAGE_GET_F_CREATE
    flag.
    
    Fixes: cd324d7abb3d ("bpf: Add selftests for local_storage")
    Signed-off-by: KP Singh <kpsingh@google.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20201106103747.2780972-7-kpsingh@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26a19bbe6003b667da63f609307473df6b52d343
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Nov 6 09:52:17 2020 +0800

    spi: stm32: fix reference leak in stm32_spi_resume
    
    [ Upstream commit 900ccdcb79bb61471df1566a70b2b39687a628d5 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in stm32_spi_resume, so we should fix it.
    
    Fixes: db96bf976a4fc ("spi: stm32: fixes suspend/resume management")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Reviewed-by: Alain Volmat <alain.volmat@st.com>
    Link: https://lore.kernel.org/r/20201106015217.140476-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 615bc1ba5b87843f932ea729b6c3304f58faf7bb
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Oct 29 22:24:07 2020 +0000

    nl80211/cfg80211: fix potential infinite loop
    
    [ Upstream commit ba5c25236bc3d399df82ebe923490ea8d2d35cf2 ]
    
    The for-loop iterates with a u8 loop counter and compares this
    with the loop upper limit of request->n_ssids which is an int type.
    There is a potential infinite loop if n_ssids is larger than the
    u8 loop counter, so fix this by making the loop counter an int.
    
    Addresses-Coverity: ("Infinite loop")
    Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20201029222407.390218-1-colin.king@canonical.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e5ea342fc652573d29adcdeb805081dd7253e67
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 ae292e43b06d4f57b12acf47d874dc9af7bad80b
Author: Horia Geantă <horia.geanta@nxp.com>
Date:   Sun Nov 1 22:05:53 2020 +0200

    crypto: caam - fix printing on xts fallback allocation error path
    
    [ Upstream commit ab95bd2aa904e4f53b7358efeea1d57693fb7889 ]
    
    At the time xts fallback tfm allocation fails the device struct
    hasn't been enabled yet in the caam xts tfm's private context.
    
    Fix this by using the device struct from xts algorithm's private context
    or, when not available, by replacing dev_err with pr_err.
    
    Fixes: 9d9b14dbe077 ("crypto: caam/jr - add fallback for XTS with more than 8B IV")
    Fixes: 83e8aa912138 ("crypto: caam/qi - add fallback for XTS with more than 8B IV")
    Fixes: 36e2d7cfdcf1 ("crypto: caam/qi2 - add fallback for XTS with more than 8B IV")
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6aa4660cba6115ab1c6ad109b1101aefde45b7a5
Author: Horia Geantă <horia.geanta@nxp.com>
Date:   Wed Oct 28 11:03:20 2020 +0200

    crypto: arm/aes-neonbs - fix usage of cbc(aes) fallback
    
    [ Upstream commit a2715fbdc6fc387e85211df917a4778761ec693d ]
    
    Loading the module deadlocks since:
    -local cbc(aes) implementation needs a fallback and
    -crypto API tries to find one but the request_module() resolves back to
    the same module
    
    Fix this by changing the module alias for cbc(aes) and
    using the NEED_FALLBACK flag when requesting for a fallback algorithm.
    
    Fixes: 00b99ad2bac2 ("crypto: arm/aes-neonbs - Use generic cbc encryption path")
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 17df190b6a337ad66d1df34bca201d83f72e1d99
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Tue Oct 27 00:00:27 2020 +0100

    crypto: arm64/poly1305-neon - reorder PAC authentication with SP update
    
    [ Upstream commit 519a0d7e495a6d3ce62594e485aea2a3a4a2ca0a ]
    
    PAC pointer authentication signs the return address against the value
    of the stack pointer, to prevent stack overrun exploits from corrupting
    the control flow. However, this requires that the AUTIASP is issued with
    SP holding the same value as it held when the PAC value was generated.
    The Poly1305 NEON code got this wrong, resulting in crashes on PAC
    capable hardware.
    
    Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS ...")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ed6e024e3bb58332af0840b2658bc4252978ea4
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Mon Nov 2 22:30:24 2020 +0800

    drm/bridge: tpd12s015: Fix irq registering in tpd12s015_probe
    
    [ Upstream commit c2530cc9610d84a5a0118ba40d0f09309605047f ]
    
    gpiod_to_irq() return negative value in case of error,
    the existing code doesn't handle negative error codes.
    If the HPD gpio supports IRQs (gpiod_to_irq returns a
    valid number), we use the IRQ. If it doesn't (gpiod_to_irq
    returns an error), it gets polled via detect().
    
    Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201102143024.26216-1-yuehaibing@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 332a2c3b6f8760410de607706b7b8943c07a2762
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 3b0c3b66b6b96ac9beee774b8e505b142192539b
Author: He Zhe <zhe.he@windriver.com>
Date:   Wed Oct 28 18:39:21 2020 +0800

    pinctrl: core: Add missing #ifdef CONFIG_GPIOLIB
    
    [ Upstream commit b507cb92477ad85902783a183c5ce01d16296687 ]
    
    To fix the following build warnings when CONFIG_GPIOLIB=n.
    
    drivers/pinctrl/core.c:1607:20: warning: unused variable 'chip' [-Wunused-variable]
     1608 |  struct gpio_chip *chip;
          |                    ^~~~
    drivers/pinctrl/core.c:1606:15: warning: unused variable 'gpio_num' [-Wunused-variable]
     1607 |  unsigned int gpio_num;
          |               ^~~~~~~~
    drivers/pinctrl/core.c:1605:29: warning: unused variable 'range' [-Wunused-variable]
     1606 |  struct pinctrl_gpio_range *range;
          |                             ^~~~~
    
    Fixes: f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20201028103921.22486-1-zhe.he@windriver.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6dd60eb9b3de5fc43e48a10f7de3a2d352f3d658
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Oct 30 17:44:19 2020 +0100

    scsi: aacraid: Improve compat_ioctl handlers
    
    [ Upstream commit 077054215a7f787e389a807ece8a39247abbbc1e ]
    
    The use of compat_alloc_user_space() can be easily replaced by handling
    compat arguments in the regular handler, and this will make it work for
    big-endian kernels as well, which at the moment get an invalid indirect
    pointer argument.
    
    Calling aac_ioctl() instead of aac_compat_do_ioctl() means the compat and
    native code paths behave the same way again, which they stopped when the
    adapter health check was added only in the native function.
    
    Link: https://lore.kernel.org/r/20201030164450.1253641-1-arnd@kernel.org
    Fixes: 572ee53a9bad ("scsi: aacraid: check adapter health")
    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: Sasha Levin <sashal@kernel.org>

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

    spi: spi-mem: fix reference leak in spi_mem_access_start
    
    [ Upstream commit c02bb16b0e826bf0e19aa42c3ae60ea339f32cf5 ]
    
    pm_runtime_get_sync will increment pm usage counter even it
    failed. Forgetting to pm_runtime_put_noidle will result in
    reference leak in spi_mem_access_start, so we should fix it.
    
    Fixes: f86c24f479530 ("spi: spi-mem: Split spi_mem_exec_op() code")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20201103140910.3482-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 159869d42023474d8d4e0be5629a5c0603f7f28c
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Oct 27 13:23:04 2020 +0300

    drm/msm/dpu: fix clock scaling on non-sc7180 board
    
    [ Upstream commit cccdeda362fafd0613b571affe7199eb7d8f3fba ]
    
    c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for
    display") has added support for handling bandwidth voting in kms path in
    addition to old mdss path. However this broke all other platforms since
    _dpu_core_perf_crtc_update_bus() will now error out instead of properly
    calculating bandwidth and core clocks. Fix
    _dpu_core_perf_crtc_update_bus() to just skip bandwidth setting instead
    of returning an error in case kms->num_paths == 0 (MDSS is used for
    bandwidth management).
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")
    Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c72aa2169db1836b2ea1477c7d251c9d1076dc4e
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 9e737d120b524b7bb3937af282eb452276830902
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Oct 15 22:03:29 2020 +0300

    drm/msm/dsi_pll_7nm: restore VCO rate during restore_state
    
    [ Upstream commit 5047ab95bb7db0e7b2ecfd5e9bcafc7fd822c652 ]
    
    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: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfc0c1840354187f71f0334ac66ac1bec6bdcbeb
Author: Tanmay Shah <tanmay@codeaurora.org>
Date:   Fri Sep 25 21:50:48 2020 -0700

    drm/msm/dp: DisplayPort PHY compliance tests fixup
    
    [ Upstream commit 6625e2637d93d2f52ef0d17656f21bfa2cb4983a ]
    
    Bandwidth code was being used as test link rate. Fix this by converting
    bandwidth code to test link rate
    
    Do not reset voltage and pre-emphasis level during IRQ HPD attention
    interrupt. Also fix pre-emphasis parsing during test link status process
    
    Signed-off-by: Tanmay Shah <tanmay@codeaurora.org>
    Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets")
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3647b89442e52d689b7053f4c25c335c026854e7
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Oct 27 16:28:54 2020 +0900

    perf test: Use generic event for expand_libpfm_events()
    
    [ Upstream commit 9b0a7836359443227c9af101f7aea8412e739458 ]
    
    I found that the UNHALTED_CORE_CYCLES event is only available in the
    Intel machines and it makes other vendors/archs fail on the test.  As
    libpfm4 can parse the generic events like cycles, let's use them.
    
    Fixes: 40b74c30ffb9 ("perf test: Add expand cgroup event test")
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lore.kernel.org/lkml/20201027072855.655449-1-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5c1af1107d60955a265eae3437ee18b33138039
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Oct 26 15:19:31 2020 +0200

    RDMA/mlx5: Fix corruption of reg_pages in mlx5_ib_rereg_user_mr()
    
    [ Upstream commit fc3325701a6353594083f08e297d4c1965c601aa ]
    
    reg_pages should always contain mr->npage since when the mr is finally
    de-reg'd it is always subtracted out.
    
    If there were any error exits then mlx5_ib_rereg_user_mr() would leave the
    reg_pages adjusted and this will cause it to be double subtracted
    eventually.
    
    The manipulation of reg_pages is inherently connected to the umem, so lift
    it out of set_mr_fields() and only adjust it around creating/destroying a
    umem.
    
    reg_pages is only used for diagnostics in sysfs.
    
    Fixes: 7d0cc6edcc70 ("IB/mlx5: Add MR cache for large UMR regions")
    Link: https://lore.kernel.org/r/20201026131936.1335664-3-leon@kernel.org
    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 8b1a51fb42182251ac3dc2e0d463e161d4b3aaf2
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Sun Oct 25 07:35:47 2020 -0700

    f2fs: call f2fs_get_meta_page_retry for nat page
    
    [ Upstream commit 3acc4522d89e0a326db69e9d0afaad8cf763a54c ]
    
    When running fault injection test, if we don't stop checkpoint, some stale
    NAT entries were flushed which breaks consistency.
    
    Fixes: 86f33603f8c5 ("f2fs: handle errors of f2fs_get_meta_page_nofail")
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5eab98b40aaaa5b340558c032a521c65de6fbfba
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 130a8874f811e59f7f4cd5ec46361a6652668a40
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 61b3d5e201c1d2fd1ac2d79afd6a8da74020d7d9
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 26 22:00:32 2020 +0100

    drm/amdgpu: fix build_coefficients() argument
    
    [ Upstream commit dbb60031dd0c2b85f10ce4c12ae604c28d3aaca4 ]
    
    gcc -Wextra warns about a function taking an enum argument
    being called with a bool:
    
    drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function 'apply_degamma_for_user_regamma':
    drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1617:29: warning: implicit conversion from 'enum <anonymous>' to 'enum dc_transfer_func_predefined' [-Wenum-conversion]
     1617 |  build_coefficients(&coeff, true);
    
    It appears that a patch was added using the old calling conventions
    after the type was changed, and the value should actually be 0
    (TRANSFER_FUNCTION_SRGB) here instead of 1 (true).
    
    Fixes: 55a01d4023ce ("drm/amd/display: Add user_regamma to color module")
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 764184e33908b42ed237bf4990c0d3aa962561ce
Author: Vijay Khemka <vijaykhemka@fb.com>
Date:   Thu Aug 13 12:04:30 2020 -0700

    ARM: dts: aspeed: tiogapass: Remove vuart
    
    [ Upstream commit 14f100c00f1e35e5890340d4c6a64bda5dff4320 ]
    
    Removed vuart for facebook tiogapass platform as it uses uart2 and
    uart3 pin with aspeed uart routing feature.
    
    Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Fixes: ffdbf494821d ("ARM: dts: aspeed: tiogapass: Enable VUART")
    Link: https://lore.kernel.org/r/20200813190431.3331026-1-vijaykhemka@fb.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 651df0443878484bd74e714fcd6c75b43bb50e01
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon Oct 26 12:48:37 2020 +0000

    drm/msm: Add missing stub definition
    
    [ Upstream commit a0b21e0ad29420b04911a98d360b9586168eeae5 ]
    
    DRM_MSM fails to build with DRM_MSM_DP=n; add the missing stub.
    
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7e27d606484284f813690edfe9341957e9391a7
Author: Clément Péron <peron.clem@gmail.com>
Date:   Fri Oct 30 15:46:34 2020 +0100

    ASoC: sun4i-i2s: Fix lrck_period computation for I2S justified mode
    
    [ Upstream commit 93c0210671d8f3ec2262da703fab93a1497158a8 ]
    
    Left and Right justified mode are computed using the same formula
    as DSP_A and DSP_B mode.
    Which is wrong and the user manual explicitly says:
    
    LRCK_PERDIOD:
    PCM Mode: Number of BCLKs within (Left + Right) channel width.
    I2S/Left-Justified/Right-Justified Mode: Number of BCLKs within each
    individual channel width(Left or Right)
    
    Fix this by using the same formula as the I2S mode.
    
    Fixes: 7ae7834ec446 ("ASoC: sun4i-i2s: Add support for DSP formats")
    Signed-off-by: Clément Péron <peron.clem@gmail.com>
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Link: https://lore.kernel.org/r/20201030144648.397824-2-peron.clem@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7428e7ca8899173e76bd1b68cb15d9c67312d26
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 16ec50845816e43a94eeb6e3c8238a3e104f286a
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 7023c8164125eb5a5c603b1ef900b08d9d9ed70c
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 3267132353937c0d45abbf5acc97430b8c5d5f03
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 26 22:00:30 2020 +0100

    drm/amdgpu: fix incorrect enum type
    
    [ Upstream commit a110f3750bf8b93764f13bd1402c7cba03d15d61 ]
    
    core_link_write_dpcd() returns enum dc_status, not ddc_result:
    
    display/dc/core/dc_link_dp.c: In function 'dp_set_panel_mode':
    display/dc/core/dc_link_dp.c:4237:11: warning: implicit conversion from 'enum dc_status' to 'enum ddc_result'
    [-Wenum-conversion]
    
    Avoid the warning by using the correct enum in the caller.
    
    Fixes: 0b226322434c ("drm/amd/display: Synchronous DisplayPort Link Training")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8933a52534212ed6246653361f9b778ef0cd393b
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 6d4250fe7d9804cced3fb507be750619e85b9c0f
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 e3c471e7f1a421635ba5a0ed1ccd1539ae85eb0f
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed Oct 28 11:51:12 2020 +0000

    ASoC: qcom: fix unsigned int bitwidth compared to less than zero
    
    [ Upstream commit bcc96dc3cf8048c80af7c487af17e19be27ac57d ]
    
    The check for an error return from the call to snd_pcm_format_width
    is never true as the unsigned int bitwidth can never be less than
    zero. Fix this by making bitwidth an int.
    
    Fixes: 7cb37b7bd0d3 ("ASoC: qcom: Add support for lpass hdmi driver")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20201028115112.109017-1-colin.king@canonical.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8ab21e0171753577d42110841bdbfbd85a9d97c
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 459c15dd6847cb1e1f061e7a600715e50ad24b43
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Fri Oct 23 09:43:46 2020 +0200

    RDMA/rtrs-srv: Don't guard the whole __alloc_srv with srv_mutex
    
    [ Upstream commit d715ff8acbd5876549ef2b21b755ed919f40dcc1 ]
    
    The purpose of srv_mutex is to protect srv_list as in put_srv, so no need
    to hold it when allocate memory for srv since it could be time consuming.
    
    Otherwise if one machine has limited memory, rsrv_close_work could be
    blocked for a longer time due to the mutex is held by get_or_create_srv
    since it can't get memory in time.
    
      INFO: task kworker/1:1:27478 blocked for more than 120 seconds.
            Tainted: G           O    4.14.171-1-storage #4.14.171-1.3~deb9
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      kworker/1:1     D    0 27478      2 0x80000000
      Workqueue: rtrs_server_wq rtrs_srv_close_work [rtrs_server]
      Call Trace:
       ? __schedule+0x38c/0x7e0
       schedule+0x32/0x80
       schedule_preempt_disabled+0xa/0x10
       __mutex_lock.isra.2+0x25e/0x4d0
       ? put_srv+0x44/0x100 [rtrs_server]
       put_srv+0x44/0x100 [rtrs_server]
       rtrs_srv_close_work+0x16c/0x280 [rtrs_server]
       process_one_work+0x1c5/0x3c0
       worker_thread+0x47/0x3e0
       kthread+0xfc/0x130
       ? trace_event_raw_event_workqueue_execute_start+0xa0/0xa0
       ? kthread_create_on_node+0x70/0x70
       ret_from_fork+0x1f/0x30
    
    Let's move all the logics from __find_srv_and_get and __alloc_srv to
    get_or_create_srv, and remove the two functions. Then it should be safe
    for multiple processes to access the same srv since it is protected with
    srv_mutex.
    
    And since we don't want to allocate chunks with srv_mutex held, let's
    check the srv->refcount after get srv because the chunks could not be
    allocated yet.
    
    Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
    Link: https://lore.kernel.org/r/20201023074353.21946-6-jinpu.wang@cloud.ionos.com
    Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f647978994ce9afc1c07cca0c34b8bf7bd0ca1e
Author: Gioh Kim <gi-oh.kim@cloud.ionos.com>
Date:   Fri Oct 23 09:43:45 2020 +0200

    RDMA/rtrs-clt: Missing error from rtrs_rdma_conn_established
    
    [ Upstream commit f553e7601df9566ba7644541fc09152a3a81f793 ]
    
    When rtrs_rdma_conn_established returns error (non-zero value), the error
    value is stored in con->cm_err and it cannot trigger
    rtrs_rdma_error_recovery. Finally the error of rtrs_rdma_con_established
    will be forgot.
    
    Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
    Link: https://lore.kernel.org/r/20201023074353.21946-5-jinpu.wang@cloud.ionos.com
    Signed-off-by: Gioh Kim <gi-oh.kim@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78bd070fa38acfc41b25210cbb3c9fedb0791c87
Author: Danil Kipnis <danil.kipnis@cloud.ionos.com>
Date:   Fri Oct 23 09:43:42 2020 +0200

    RDMA/rtrs-clt: Remove destroy_con_cq_qp in case route resolving failed
    
    [ Upstream commit 2b3062e4d997f201c1ad2bbde88b7271dd9ef35f ]
    
    We call destroy_con_cq_qp(con) in rtrs_rdma_addr_resolved() in case route
    couldn't be resolved and then again in create_cm() because nothing
    happens.
    
    Don't call destroy_con_cq_qp from rtrs_rdma_addr_resolved, create_cm()
    does the clean up already.
    
    Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
    Link: https://lore.kernel.org/r/20201023074353.21946-2-jinpu.wang@cloud.ionos.com
    Signed-off-by: Danil Kipnis <danil.kipnis@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78905c6ab15478b3aa005b86f3c01201786af5bf
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 9c79c9e658e33774005e6502bd603d8566c8d963
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 965f5593933f545b79b2de1d9710ef5b14c2f27b
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 e7c49c634aff348b3baa2c3a07bd6e5f21adf0ac
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Fri Oct 16 15:58:45 2020 +0800

    RDMA/core: Fix error return in _ib_modify_qp()
    
    [ Upstream commit 5333499c6014224756e97fa1a1047dfa592d76d3 ]
    
    Fix to return error code PTR_ERR() from the error handling case instead of
    0.
    
    Fixes: 51aab12631dd ("RDMA/core: Get xmit slave for LAG")
    Link: https://lore.kernel.org/r/20201016075845.129562-1-jingxiangfeng@huawei.com
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56cc090c2b21d904c108d902f96c05c96a23656b
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 5ea241ef954307c3a3e013eef409b1e0dba846e1
Author: Billy Tsai <billy_tsai@aspeedtech.com>
Date:   Mon Oct 12 11:31:48 2020 +0800

    ARM: dts: aspeed-g6: Fix the GPIO memory size
    
    [ Upstream commit 886f82ce9f1f4559c139fdb2d79d158999ca38cd ]
    
    The GPIO controller is a GPIO controller followed by some SGPIO
    controllers, which are a different type of device with their own binding
    and drivers.
    
    Make the gpio node cover the only conventional GPIO controller.
    
    Fixes: 8dbcb5b709b9 ("ARM: dts: aspeed-g6: Add gpio devices")
    Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
    Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20201012033150.21056-2-billy_tsai@aspeedtech.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0d7de09261b0dd076a470b77f38678e89362bed
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 ae3739fcfe3baf1595dac00ac8440fe4f1bd3a38
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Mon Oct 12 23:15:52 2020 -0700

    RDMA/bnxt_re: Fix entry size during SRQ create
    
    [ Upstream commit b898d5c50cab1f985e77d053eb5c4d2c4a7694ae ]
    
    Only static WQE is supported for SRQ. So always use the max supported SGEs
    while calculating SRQ entry size.
    
    Fixes: 2bb3c32c5c5f ("RDMA/bnxt_re: Change wr posting logic to accommodate variable wqes")
    Link: https://lore.kernel.org/r/1602569752-12745-1-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Devesh Sharma <devesh.sharma@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c647cc8e5804755e6f5fae2cd82a69e51081e5ea
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Oct 22 10:04:51 2020 +0300

    rtc: pcf2127: fix pcf2127_nvmem_read/write() returns
    
    [ Upstream commit ba1c30bf3f2536f248d262c6f257b5a787305991 ]
    
    These functions should return zero on success.  Non-zero returns are
    treated as error.  On some paths, this doesn't matter but in
    nvmem_cell_read() a non-zero return would be passed to ERR_PTR() and
    lead to an Oops.
    
    Fixes: d6c3029f32f7 ("rtc: pcf2127: add support for accessing internal static RAM")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20201022070451.GA2817669@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d281791bee58736e010c3397b402dd2e1e0465d
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 942e8f31dff6a378e66d93982f0e69a459f8a5f2
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue Oct 13 14:25:29 2020 -0700

    Revert "i2c: i2c-qcom-geni: Fix DMA transfer race"
    
    [ Upstream commit 9cb4c67d7717135d6f4600a49ab07b470ea4ee2f ]
    
    This reverts commit 02b9aec59243c6240fc42884acc958602146ddf6.
    
    As talked about in the patch ("soc: qcom: geni: More properly switch
    to DMA mode"), swapping the order of geni_se_setup_m_cmd() and
    geni_se_xx_dma_prep() can sometimes cause corrupted transfers.  Thus
    we traded one problem for another.  Now that we've debugged the
    problem further and fixed the geni helper functions to more disable
    FIFO interrupts when we move to DMA mode we can revert it and end up
    with (hopefully) zero problems!
    
    To be explicit, the patch ("soc: qcom: geni: More properly switch
    to DMA mode") is a prerequisite for this one.
    
    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.2.I7b22281453b8a18ab16ef2bfd4c641fb1cc6a92c@changeid
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 614199a8d1d19a1b007f157866fd66e703b2d0af
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 dd90a827ff189abb4d8cb180038779d5c9b05cb8
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Oct 1 14:18:55 2020 -0700

    arm64: dts: qcom: sc7180: Fix one forgotten interconnect reference
    
    [ Upstream commit 228813aaa71113d7a12313b87c4905a9d3f9df37 ]
    
    In commit e23b1220a246 ("arm64: dts: qcom: sc7180: Increase the number
    of interconnect cells") we missed increasing the cells on one
    interconnect.  That's no bueno.  Fix it.
    
    NOTE: it appears that things aren't totally broken without this fix,
    but clearly something isn't going to be working right.  If nothing
    else, without this fix I see this in the logs:
    
      OF: /soc@0/mdss@ae00000: could not get #interconnect-cells for /soc@0/interrupt-controller@17a00000
    
    Fixes: e23b1220a246 ("arm64: dts: qcom: sc7180: Increase the number of interconnect cells")
    Reviewed-by: Georgi Djakov <georgi.djakov@linaro.org>
    Reviewed-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20201001141838.1.I08054d1d976eed64ffa1b0e21d568e0dc6040b54@changeid
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c6b8eda1ee6cfae10eabf68d78d57a3f994ed05
Author: Kathiravan T <kathirav@codeaurora.org>
Date:   Wed Oct 14 21:16:17 2020 +0530

    arm64: dts: ipq6018: update the reserved-memory node
    
    [ Upstream commit 4af5c6dc255ca64e5263a5254bb7553f05bb682c ]
    
    Memory region reserved for the TZ is changed long back. Let's
    update the same to align with the corret region. Its size also
    increased to 4MB from 2MB.
    
    Along with that, bump the Q6 region size to 85MB.
    
    Fixes: 1e8277854b49 ("arm64: dts: Add ipq6018 SoC and CP01 board support")
    Signed-off-by: Kathiravan T <kathirav@codeaurora.org>
    Link: https://lore.kernel.org/r/1602690377-21304-1-git-send-email-kathirav@codeaurora.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33be7295fbebcb4065f127a11d6894e6c4df1743
Author: Fabien Parent <fparent@baylibre.com>
Date:   Sun Oct 18 21:42:25 2020 +0200

    arm64: dts: mediatek: mt8183: fix gce incorrect mbox-cells value
    
    [ Upstream commit e55c56df43dd11de4a6c08e3ea52ca45b51c8800 ]
    
    The binding documentation says:
    - #mbox-cells: Should be 2.
            <&phandle channel priority>
            phandle: Label name of a gce node.
            channel: Channel of mailbox. Be equal to the thread id of GCE.
            priority: Priority of GCE thread.
    
    Fix the value of #mbox-cells.
    
    Fixes: d3c306e31bc7 ("arm64: dts: add gce node for mt8183")
    Signed-off-by: Fabien Parent <fparent@baylibre.com>
    Link: https://lore.kernel.org/r/20201018194225.3361182-1-fparent@baylibre.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2eaddba03b3bfb7ca51e793b14e4d011a69de49
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 de37cfd12056994a9d9829032664f5df72629c3f
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 a7b30bb959828e40250727dd66e5e4417a1ff676
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Thu Oct 15 14:23:50 2020 +0100

    arm64: dts: renesas: cat875: Remove rxc-skew-ps from ethernet-phy node
    
    [ Upstream commit 53e573dc39fba1834f3e4fa002cb754b61a30701 ]
    
    The CAT875 sub board from Silicon Linux uses Realtek phy and the driver
    does not support rxc-skew-ps property.
    
    Fixes: 6b170cd3ed02949f ("arm64: dts: renesas: cat875: Add ethernet support")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Link: https://lore.kernel.org/r/20201015132350.8360-2-biju.das.jz@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f53a676571273697684e80e6d0dd5fc66818fe51
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Thu Oct 15 14:23:49 2020 +0100

    arm64: dts: renesas: hihope-rzg2-ex: Drop rxc-skew-ps from ethernet-phy node
    
    [ Upstream commit 67d3dcf12a3d245b6fd6ca5672893f7ae4e137ed ]
    
    HiHope RZG2[HMN] boards uses Realtek phy and the driver does not support
    rxc-skew-ps property. So remove rxc-skew-ps from ethernet-phy node.
    
    Fixes: 7433f1fb8ec8fe ("arm64: dts: renesas: Add HiHope RZ/G2M sub board support")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Link: https://lore.kernel.org/r/20201015132350.8360-1-biju.das.jz@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 172b7228a31f5b4a991a599f43e0630c48d5d725
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 22bf070017629afc24521b5d23f0a14cafd3411e
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Aug 27 09:11:06 2020 +0200

    drm/mcde: Fix handling of platform_get_irq() error
    
    [ Upstream commit e2dae672a9d5e11856fe30ede63467c65f999a81 ]
    
    platform_get_irq() returns -ERRNO on error.  In such case comparison
    to 0 would pass the check.
    
    Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
    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-1-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc797be0e38cbadd62b58e7d8164ee6aed32d91f
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Oct 11 16:01:31 2020 -0700

    drm/aspeed: Fix Kconfig warning & subsequent build errors
    
    [ Upstream commit bf296b35489b46780b73b74ad984d06750ed5479 ]
    
    Kernel test robot reported build errors (undefined references)
    that didn't make much sense. After reproducing them, there is also
    a Kconfig warning that is the root cause of the build errors, so
    fix that Kconfig problem.
    
    Fixes this Kconfig warning:
    WARNING: unmet direct dependencies detected for CMA
      Depends on [n]: MMU [=n]
      Selected by [m]:
      - DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=m] && OF [=y] && (COMPILE_TEST [=y] || ARCH_ASPEED) && HAVE_DMA_CONTIGUOUS [=y]
    
    and these dependent build errors:
    (.text+0x10c8c): undefined reference to `start_isolate_page_range'
    microblaze-linux-ld: (.text+0x10f14): undefined reference to `test_pages_isolated'
    microblaze-linux-ld: (.text+0x10fd0): undefined reference to `undo_isolate_page_range'
    
    Fixes: 76356a966e33 ("drm: aspeed: Clean up Kconfig options")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Cc: Joel Stanley <joel@jms.id.au>
    Cc: Andrew Jeffery <andrew@aj.id.au>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Michal Simek <monstr@monstr.eu>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Cc: linux-mm@kvack.org
    Cc: linux-aspeed@lists.ozlabs.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: David Airlie <airlied@linux.ie>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201011230131.4922-1-rdunlap@infradead.org
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8c27b95869d72af9db579414b77730d93352c8c
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date:   Wed Sep 30 16:50:47 2020 +0300

    iio: adc: at91_adc: add Kconfig dep on the OF symbol and remove of_match_ptr()
    
    [ Upstream commit f091d7c5fe6cc39e916b50f90e3cac67a032d0be ]
    
    This tries to solve a warning reported by the lkp bot:
    
    >> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
    >> 'at91_adc_dt_ids' [-Wunused-const-variable]
       static const struct of_device_id at91_adc_dt_ids[] = {
                                        ^
       1 warning generated.
    
    This warning has appeared after the AT91_ADC driver compilation has been
    enabled via the COMPILE_TEST symbol dependency.
    
    The warning is caused by the 'of_match_ptr()' helper which returns NULL if
    OF is undefined. This driver should build only for device-tree context, so
    a dependency on the OF Kconfig symbol has been added.
    Also, the usage of of_match_ptr() helper has been removed since it
    shouldn't ever return NULL (because the driver should not be built for the
    non-OF context).
    
    Fixes: 4027860dcc4c ("iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20200930135048.11530-4-alexandru.ardelean@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d7961ef3d8935a5d87aed27e9e06e8378063958
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 dafbfbed308f5e0013cca56ddb3dec0de65604f9
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Mon Dec 14 10:26:22 2020 -0800

    hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUs
    
    commit 0a4e668b5d52eed8026f5d717196b02b55fb2dc6 upstream.
    
    Voltages and current are reported by Zen CPUs. However, the means
    to do so is undocumented, changes from CPU to CPU, and the raw data
    is not calibrated. Calibration information is available, but again
    not documented. This results in less than perfect user experience,
    up to concerns that loading the driver might possibly damage
    the hardware (by reporting out-of range voltages). Effectively
    support for reporting voltages and current is not maintainable.
    Drop it.
    
    Cc: Artem S. Tashkinov <aros@gmx.com>
    Cc: Wei Huang <wei.huang2@amd.com>
    Tested-by: Wei Huang <wei.huang2@amd.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>