commit b6032ab67a9a02a21fa484181e666fcd6069ace9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Feb 7 14:48:38 2021 +0100

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

commit 1746d1dcae9a960052b7a956523cc1719f71513c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jan 15 19:08:36 2021 +0100

    workqueue: Restrict affinity change to rescuer
    
    [ Upstream commit 640f17c82460e9724fd256f0a1f5d99e7ff0bda4 ]
    
    create_worker() will already set the right affinity using
    kthread_bind_mask(), this means only the rescuer will need to change
    it's affinity.
    
    Howveer, while in cpu-hot-unplug a regular task is not allowed to run
    on online&&!active as it would be pushed away quite agressively. We
    need KTHREAD_IS_PER_CPU to survive in that environment.
    
    Therefore set the affinity after getting that magic flag.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Tested-by: Valentin Schneider <valentin.schneider@arm.com>
    Link: https://lkml.kernel.org/r/20210121103506.826629830@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbad32181af9c8c76698b16115c28a493c26a2ee
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jan 12 11:24:04 2021 +0100

    kthread: Extract KTHREAD_IS_PER_CPU
    
    [ Upstream commit ac687e6e8c26181a33270efd1a2e2241377924b0 ]
    
    There is a need to distinguish geniune per-cpu kthreads from kthreads
    that happen to have a single CPU affinity.
    
    Geniune per-cpu kthreads are kthreads that are CPU affine for
    correctness, these will obviously have PF_KTHREAD set, but must also
    have PF_NO_SETAFFINITY set, lest userspace modify their affinity and
    ruins things.
    
    However, these two things are not sufficient, PF_NO_SETAFFINITY is
    also set on other tasks that have their affinities controlled through
    other means, like for instance workqueues.
    
    Therefore another bit is needed; it turns out kthread_create_per_cpu()
    already has such a bit: KTHREAD_IS_PER_CPU, which is used to make
    kthread_park()/kthread_unpark() work correctly.
    
    Expose this flag and remove the implicit setting of it from
    kthread_create_on_cpu(); the io_uring usage of it seems dubious at
    best.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Tested-by: Valentin Schneider <valentin.schneider@arm.com>
    Link: https://lkml.kernel.org/r/20210121103506.557620262@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52b4c58bac0e03732961d6d1c29c21a1eb7364e5
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Thu Jan 14 16:14:01 2021 -0600

    objtool: Don't fail on missing symbol table
    
    [ Upstream commit 1d489151e9f9d1647110277ff77282fe4d96d09b ]
    
    Thanks to a recent binutils change which doesn't generate unused
    symbols, it's now possible for thunk_64.o be completely empty without
    CONFIG_PREEMPTION: no text, no data, no symbols.
    
    We could edit the Makefile to only build that file when
    CONFIG_PREEMPTION is enabled, but that will likely create confusion
    if/when the thunks end up getting used by some other code again.
    
    Just ignore it and move on.
    
    Reported-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1254
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 10365001390876ffb846bcbc5b94404928b0f9ca
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Jan 19 15:18:00 2021 +1100

    selftests/powerpc: Only test lwm/stmw on big endian
    
    [ Upstream commit dd3a44c06f7b4f14e90065bf05d62c255b20005f ]
    
    Newer binutils (>= 2.36) refuse to assemble lmw/stmw when building in
    little endian mode. That breaks compilation of our alignment handler
    test:
    
      /tmp/cco4l14N.s: Assembler messages:
      /tmp/cco4l14N.s:1440: Error: `lmw' invalid when little-endian
      /tmp/cco4l14N.s:1814: Error: `stmw' invalid when little-endian
      make[2]: *** [../../lib.mk:139: /output/kselftest/powerpc/alignment/alignment_handler] Error 1
    
    These tests do pass on little endian machines, as the kernel will
    still emulate those instructions even when running little
    endian (which is arguably a kernel bug).
    
    But we don't really need to test that case, so ifdef those
    instructions out to get the alignment test building again.
    
    Reported-by: Libor Pechacek <lpechacek@suse.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Tested-by: Libor Pechacek <lpechacek@suse.com>
    Link: https://lore.kernel.org/r/20210119041800.3093047-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7a479e168668a16aa9bed158718a5fc9b5c9679
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Jan 12 09:06:38 2021 -0600

    scsi: ibmvfc: Set default timeout to avoid crash during migration
    
    [ Upstream commit 764907293edc1af7ac857389af9dc858944f53dc ]
    
    While testing live partition mobility, we have observed occasional crashes
    of the Linux partition. What we've seen is that during the live migration,
    for specific configurations with large amounts of memory, slow network
    links, and workloads that are changing memory a lot, the partition can end
    up being suspended for 30 seconds or longer. This resulted in the following
    scenario:
    
    CPU 0                          CPU 1
    -------------------------------  ----------------------------------
    scsi_queue_rq                    migration_store
     -> blk_mq_start_request          -> rtas_ibm_suspend_me
      -> blk_add_timer                 -> on_each_cpu(rtas_percpu_suspend_me
                  _______________________________________V
                 |
                 V
        -> IPI from CPU 1
         -> rtas_percpu_suspend_me
                                         -> __rtas_suspend_last_cpu
    
    -- Linux partition suspended for > 30 seconds --
                                          -> for_each_online_cpu(cpu)
                                               plpar_hcall_norets(H_PROD
     -> scsi_dispatch_cmd
                                          -> scsi_times_out
                                           -> scsi_abort_command
                                            -> queue_delayed_work
      -> ibmvfc_queuecommand_lck
       -> ibmvfc_send_event
        -> ibmvfc_send_crq
         - returns H_CLOSED
       <- returns SCSI_MLQUEUE_HOST_BUSY
    -> __blk_mq_requeue_request
    
                                          -> scmd_eh_abort_handler
                                           -> scsi_try_to_abort_cmd
                                             - returns SUCCESS
                                           -> scsi_queue_insert
    
    Normally, the SCMD_STATE_COMPLETE bit would protect against the command
    completion and the timeout, but that doesn't work here, since we don't
    check that at all in the SCSI_MLQUEUE_HOST_BUSY path.
    
    In this case we end up calling scsi_queue_insert on a request that has
    already been queued, or possibly even freed, and we crash.
    
    The patch below simply increases the default I/O timeout to avoid this race
    condition. This is also the timeout value that nearly all IBM SAN storage
    recommends setting as the default value.
    
    Link: https://lore.kernel.org/r/1610463998-19791-1-git-send-email-brking@linux.vnet.ibm.com
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b70798906c4c85314511cf6d5cae98385861fc07
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Dec 18 19:47:17 2020 +0100

    mac80211: fix fast-rx encryption check
    
    [ Upstream commit 622d3b4e39381262da7b18ca1ed1311df227de86 ]
    
    When using WEP, the default unicast key needs to be selected, instead of
    the STA PTK.
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://lore.kernel.org/r/20201218184718.93650-5-nbd@nbd.name
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d29232ebc8165f3489048230d29c382d69cab2a8
Author: Javed Hasan <jhasan@marvell.com>
Date:   Tue Dec 15 11:47:31 2020 -0800

    scsi: libfc: Avoid invoking response handler twice if ep is already completed
    
    [ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]
    
    A race condition exists between the response handler getting called because
    of exchange_mgr_reset() (which clears out all the active XIDs) and the
    response we get via an interrupt.
    
    Sequence of events:
    
             rport ba0200: Port timeout, state PLOGI
             rport ba0200: Port entered PLOGI state from PLOGI state
             xid 1052: Exchange timer armed : 20000 msecs      xid timer armed here
             rport ba0200: Received LOGO request while in state PLOGI
             rport ba0200: Delete port
             rport ba0200: work event 3
             rport ba0200: lld callback ev 3
             bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
             bnx2fc: ba0200 - rport not created Yet!!
             /* Here we reset any outstanding exchanges before
             freeing rport using the exch_mgr_reset() */
             xid 1052: Exchange timer canceled
             /* Here we got two responses for one xid */
             xid 1052: invoking resp(), esb 20000000 state 3
             xid 1052: invoking resp(), esb 20000000 state 3
             xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
             xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
    
    Skip the response if the exchange is already completed.
    
    Link: https://lore.kernel.org/r/20201215194731.2326-1-jhasan@marvell.com
    Signed-off-by: Javed Hasan <jhasan@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b27b3f8e555379117d4d4f047017d33972907b6
Author: Martin Wilck <mwilck@suse.com>
Date:   Mon Jan 11 15:25:41 2021 +0100

    scsi: scsi_transport_srp: Don't block target in failfast state
    
    [ Upstream commit 72eeb7c7151302ef007f1acd018cbf6f30e50321 ]
    
    If the port is in SRP_RPORT_FAIL_FAST state when srp_reconnect_rport() is
    entered, a transition to SDEV_BLOCK would be illegal, and a kernel WARNING
    would be triggered. Skip scsi_target_block() in this case.
    
    Link: https://lore.kernel.org/r/20210111142541.21534-1-mwilck@suse.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    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 3b9aacf27e06fee5f7b2ea3c2e0e9702767576e9
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jan 7 11:14:25 2021 +0100

    x86: __always_inline __{rd,wr}msr()
    
    [ Upstream commit 66a425011c61e71560c234492d204e83cfb73d1d ]
    
    When the compiler choses to not inline the trivial MSR helpers:
    
      vmlinux.o: warning: objtool: __sev_es_nmi_complete()+0xce: call to __wrmsr.constprop.14() leaves .noinstr.text section
    
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
    Link: https://lore.kernel.org/r/X/bf3gV+BW7kGEsB@hirez.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96c5db6cf422a07d00a05350bda36d2769cc8233
Author: Arnold Gozum <arngozum@gmail.com>
Date:   Sat Dec 26 15:53:06 2020 -0500

    platform/x86: intel-vbtn: Support for tablet mode on Dell Inspiron 7352
    
    [ Upstream commit fcd38f178b785623c0325958225744f0d8a075c0 ]
    
    The Dell Inspiron 7352 is a 2-in-1 model that has chassis-type "Notebook".
    Add this model to the dmi_switches_allow_list.
    
    Signed-off-by: Arnold Gozum <arngozum@gmail.com>
    Link: https://lore.kernel.org/r/20201226205307.249659-1-arngozum@gmail.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac518835f2dde43c0ece8d6ffc1437a794c7bc1e
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Dec 24 14:51:58 2020 +0100

    platform/x86: touchscreen_dmi: Add swap-x-y quirk for Goodix touchscreen on Estar Beauty HD tablet
    
    [ Upstream commit 46c54cf2706122c37497896d56d67b0c0aca2ede ]
    
    The Estar Beauty HD (MID 7316R) tablet uses a Goodix touchscreen,
    with the X and Y coordinates swapped compared to the LCD panel.
    
    Add a touchscreen_dmi entry for this adding a "touchscreen-swapped-x-y"
    device-property to the i2c-client instantiated for this device before
    the driver binds.
    
    This is the first entry of a Goodix touchscreen to touchscreen_dmi.c,
    so far DMI quirks for Goodix touchscreen's have been added directly
    to drivers/input/touchscreen/goodix.c. Currently there are 3
    DMI tables in goodix.c:
    1. rotated_screen[] for devices where the touchscreen is rotated
       180 degrees vs the LCD panel
    2. inverted_x_screen[] for devices where the X axis is inverted
    3. nine_bytes_report[] for devices which use a non standard touch
       report size
    
    Arguably only 3. really needs to be inside the driver and the other
    2 cases are better handled through the generic touchscreen DMI quirk
    mechanism from touchscreen_dmi.c, which allows adding device-props to
    any i2c-client. Esp. now that goodix.c is using the generic
    touchscreen_properties code.
    
    Alternative to the approach from this patch we could add a 4th
    dmi_system_id table for devices with swapped-x-y axis to goodix.c,
    but that seems undesirable.
    
    Cc: Bastien Nocera <hadess@hadess.net>
    Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201224135158.10976-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 836e842b67b060829d10cb657c52a3f605aa6662
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Dec 30 12:21:05 2020 +0200

    phy: cpcap-usb: Fix warning for missing regulator_disable
    
    [ Upstream commit 764257d9069a9c19758b626cc1ba4ae079335d9e ]
    
    On deferred probe, we will get the following splat:
    
    cpcap-usb-phy cpcap-usb-phy.0: could not initialize VBUS or ID IIO: -517
    WARNING: CPU: 0 PID: 21 at drivers/regulator/core.c:2123 regulator_put+0x68/0x78
    ...
    (regulator_put) from [<c068ebf0>] (release_nodes+0x1b4/0x1fc)
    (release_nodes) from [<c068a9a4>] (really_probe+0x104/0x4a0)
    (really_probe) from [<c068b034>] (driver_probe_device+0x58/0xb4)
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20201230102105.11826-1-tony@atomide.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69874c3152adac06d04360d40e1ea775788a2c12
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jan 14 10:19:29 2021 -0800

    net_sched: gen_estimator: support large ewma log
    
    commit dd5e073381f2ada3630f36be42833c6e9c78b75e upstream
    
    syzbot report reminded us that very big ewma_log were supported in the past,
    even if they made litle sense.
    
    tc qdisc replace dev xxx root est 1sec 131072sec ...
    
    While fixing the bug, also add boundary checks for ewma_log, in line
    with range supported by iproute2.
    
    UBSAN: shift-out-of-bounds in net/core/gen_estimator.c:83:38
    shift exponent -1 is negative
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     <IRQ>
     __dump_stack lib/dump_stack.c:79 [inline]
     dump_stack+0x107/0x163 lib/dump_stack.c:120
     ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
     __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
     est_timer.cold+0xbb/0x12d net/core/gen_estimator.c:83
     call_timer_fn+0x1a5/0x710 kernel/time/timer.c:1417
     expire_timers kernel/time/timer.c:1462 [inline]
     __run_timers.part.0+0x692/0xa80 kernel/time/timer.c:1731
     __run_timers kernel/time/timer.c:1712 [inline]
     run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1744
     __do_softirq+0x2bc/0xa77 kernel/softirq.c:343
     asm_call_irq_on_stack+0xf/0x20
     </IRQ>
     __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
     run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
     do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77
     invoke_softirq kernel/softirq.c:226 [inline]
     __irq_exit_rcu+0x17f/0x200 kernel/softirq.c:420
     irq_exit_rcu+0x5/0x20 kernel/softirq.c:432
     sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1096
     asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:628
    RIP: 0010:native_save_fl arch/x86/include/asm/irqflags.h:29 [inline]
    RIP: 0010:arch_local_save_flags arch/x86/include/asm/irqflags.h:79 [inline]
    RIP: 0010:arch_irqs_disabled arch/x86/include/asm/irqflags.h:169 [inline]
    RIP: 0010:acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
    RIP: 0010:acpi_idle_do_entry+0x1c9/0x250 drivers/acpi/processor_idle.c:516
    
    Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Link: https://lore.kernel.org/r/20210114181929.1717985-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cbe06fe63af46c74ec80c39bacd79546d89ea9c
Author: Christian Brauner <christian@brauner.io>
Date:   Thu Mar 7 16:29:40 2019 -0800

    sysctl: handle overflow in proc_get_long
    
    commit 7f2923c4f73f21cfd714d12a2d48de8c21f11cfe upstream.
    
    proc_get_long() is a funny function.  It uses simple_strtoul() and for a
    good reason.  proc_get_long() wants to always succeed the parse and
    return the maybe incorrect value and the trailing characters to check
    against a pre-defined list of acceptable trailing values.  However,
    simple_strtoul() explicitly ignores overflows which can cause funny
    things like the following to happen:
    
      echo 18446744073709551616 > /proc/sys/fs/file-max
      cat /proc/sys/fs/file-max
      0
    
    (Which will cause your system to silently die behind your back.)
    
    On the other hand kstrtoul() does do overflow detection but does not
    return the trailing characters, and also fails the parse when anything
    other than '\n' is a trailing character whereas proc_get_long() wants to
    be more lenient.
    
    Now, before adding another kstrtoul() function let's simply add a static
    parse strtoul_lenient() which:
     - fails on overflow with -ERANGE
     - returns the trailing characters to the caller
    
    The reason why we should fail on ERANGE is that we already do a partial
    fail on overflow right now.  Namely, when the TMPBUFLEN is exceeded.  So
    we already reject values such as 184467440737095516160 (21 chars) but
    accept values such as 18446744073709551616 (20 chars) but both are
    overflows.  So we should just always reject 64bit overflows and not
    special-case this based on the number of chars.
    
    Link: http://lkml.kernel.org/r/20190107222700.15954-2-christian@brauner.io
    Signed-off-by: Christian Brauner <christian@brauner.io>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Joe Lawrence <joe.lawrence@redhat.com>
    Cc: Waiman Long <longman@redhat.com>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Joerg Vehlow <lkml@jv-coder.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26ec09650f3ebcfd5e2cc136f362c211ae55a1d4
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jan 14 19:34:22 2021 +0100

    ACPI: thermal: Do not call acpi_thermal_check() directly
    
    commit 81b704d3e4674e09781d331df73d76675d5ad8cb upstream.
    
    Calling acpi_thermal_check() from acpi_thermal_notify() directly
    is problematic if _TMP triggers Notify () on the thermal zone for
    which it has been evaluated (which happens on some systems), because
    it causes a new acpi_thermal_notify() invocation to be queued up
    every time and if that takes place too often, an indefinite number of
    pending work items may accumulate in kacpi_notify_wq over time.
    
    Besides, it is not really useful to queue up a new invocation of
    acpi_thermal_check() if one of them is pending already.
    
    For these reasons, rework acpi_thermal_notify() to queue up a thermal
    check instead of calling acpi_thermal_check() directly and only allow
    one thermal check to be pending at a time.  Moreover, only allow one
    acpi_thermal_check_fn() instance at a time to run
    thermal_zone_device_update() for one thermal zone and make it return
    early if it sees other instances running for the same thermal zone.
    
    While at it, fold acpi_thermal_check() into acpi_thermal_check_fn(),
    as it is only called from there after the other changes made here.
    
    [This issue appears to have been exposed by commit 6d25be5782e4
     ("sched/core, workqueues: Distangle worker accounting from rq
     lock"), but it is unclear why it was not visible earlier.]
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208877
    Reported-by: Stephen Berman <stephen.berman@gmx.net>
    Diagnosed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Stephen Berman <stephen.berman@gmx.net>
    Cc: All applicable <stable@vger.kernel.org>
    [bigeasy: Backported to v5.4.y]
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55288f9a4cb334edab841f8f2cc08dd814030673
Author: Lijun Pan <ljp@linux.ibm.com>
Date:   Wed Jan 27 19:34:42 2021 -0600

    ibmvnic: Ensure that CRQ entry read are correctly ordered
    
    commit e41aec79e62fa50f940cf222d1e9577f14e149dc upstream.
    
    Ensure that received Command-Response Queue (CRQ) entries are
    properly read in order by the driver. dma_rmb barrier has
    been added before accessing the CRQ descriptor to ensure
    the entire descriptor is read before processing.
    
    Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol")
    Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210128013442.88319-1-ljp@linux.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf6bb58f80019aa15f1605de396c30cd9e1ffc93
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Jan 21 04:33:43 2021 -0800

    net: dsa: bcm_sf2: put device node before return
    
    commit cf3c46631e1637582f517a574c77cd6c05793817 upstream.
    
    Put the device node dn before return error code on failure path.
    
    Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Link: https://lore.kernel.org/r/20210121123343.26330-1-bianpan2016@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>