commit 2d18b3ee633e0c9d7ddcaa489299113fb88ea672
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 10 09:29:23 2021 +0100

    Linux 5.10.15
    
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Davidson Francis <davidsondfgl@gmail.com>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Ross Schmidt <ross.schm.dev@gmail.com>
    Link: https://lore.kernel.org/r/20210208145818.395353822@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0414bde7796802753672700ff0c9d3909ef07bd7
Author: Alexander Ovechkin <ovov@yandex-team.ru>
Date:   Mon Feb 1 23:00:49 2021 +0300

    net: sched: replaced invalid qdisc tree flush helper in qdisc_replace
    
    commit 938e0fcd3253efdef8924714158911286d08cfe1 upstream.
    
    Commit e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
    introduced qdisc tree flush/purge helpers, but erroneously used flush helper
    instead of purge helper in qdisc_replace function.
    This issue was found in our CI, that tests various qdisc setups by configuring
    qdisc and sending data through it. Call of invalid helper sporadically leads
    to corruption of vt_tree/cf_tree of hfsc_class that causes kernel oops:
    
     Oops: 0000 [#1] SMP PTI
     CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.11.0-8f6859df #1
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
     RIP: 0010:rb_insert_color+0x18/0x190
     Code: c3 31 c0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 07 48 85 c0 0f 84 05 01 00 00 48 8b 10 f6 c2 01 0f 85 34 01 00 00 <48> 8b 4a 08 49 89 d0 48 39 c1 74 7d 48 85 c9 74 32 f6 01 01 75 2d
     RSP: 0018:ffffc900000b8bb0 EFLAGS: 00010246
     RAX: ffff8881ef4c38b0 RBX: ffff8881d956e400 RCX: ffff8881ef4c38b0
     RDX: 0000000000000000 RSI: ffff8881d956f0a8 RDI: ffff8881d956e4b0
     RBP: 0000000000000000 R08: 000000d5c4e249da R09: 1600000000000000
     R10: ffffc900000b8be0 R11: ffffc900000b8b28 R12: 0000000000000001
     R13: 000000000000005a R14: ffff8881f0905000 R15: ffff8881f0387d00
     FS:  0000000000000000(0000) GS:ffff8881f8b00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000008 CR3: 00000001f4796004 CR4: 0000000000060ee0
     Call Trace:
      <IRQ>
      init_vf.isra.19+0xec/0x250 [sch_hfsc]
      hfsc_enqueue+0x245/0x300 [sch_hfsc]
      ? fib_rules_lookup+0x12a/0x1d0
      ? __dev_queue_xmit+0x4b6/0x930
      ? hfsc_delete_class+0x250/0x250 [sch_hfsc]
      __dev_queue_xmit+0x4b6/0x930
      ? ip6_finish_output2+0x24d/0x590
      ip6_finish_output2+0x24d/0x590
      ? ip6_output+0x6c/0x130
      ip6_output+0x6c/0x130
      ? __ip6_finish_output+0x110/0x110
      mld_sendpack+0x224/0x230
      mld_ifc_timer_expire+0x186/0x2c0
      ? igmp6_group_dropped+0x200/0x200
      call_timer_fn+0x2d/0x150
      run_timer_softirq+0x20c/0x480
      ? tick_sched_do_timer+0x60/0x60
      ? tick_sched_timer+0x37/0x70
      __do_softirq+0xf7/0x2cb
      irq_exit+0xa0/0xb0
      smp_apic_timer_interrupt+0x74/0x150
      apic_timer_interrupt+0xf/0x20
      </IRQ>
    
    Fixes: e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
    Signed-off-by: Alexander Ovechkin <ovov@yandex-team.ru>
    Reported-by: Alexander Kuznetsov <wwfq@yandex-team.ru>
    Acked-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
    Acked-by: Dmitry Yakunin <zeil@yandex-team.ru>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Link: https://lore.kernel.org/r/20210201200049.299153-1-ovov@yandex-team.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 836f791aba588adb94fda349b2abca35aebc31c6
Author: DENG Qingfang <dqfext@gmail.com>
Date:   Sat Jan 30 21:43:34 2021 +0800

    net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add
    
    commit f72f2fb8fb6be095b98af5d740ac50cffd0b0cae upstream.
    
    Having multiple destination ports for a unicast address does not make
    sense.
    Make port_db_load_purge override existent unicast portvec instead of
    adding a new port bit.
    
    Fixes: 884729399260 ("net: dsa: mv88e6xxx: handle multiple ports in ATU")
    Signed-off-by: DENG Qingfang <dqfext@gmail.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20210130134334.10243-1-dqfext@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d6df63a5cbe3fa167149831341e5d485f75dab6
Author: Dongseok Yi <dseok.yi@samsung.com>
Date:   Sat Jan 30 08:13:27 2021 +0900

    udp: ipv4: manipulate network header of NATed UDP GRO fraglist
    
    commit c3df39ac9b0e3747bf8233ea9ce4ed5ceb3199d3 upstream.
    
    UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
    forwarding. Only the header of head_skb from ip_finish_output_gso ->
    skb_gso_segment is updated but following frag_skbs are not updated.
    
    A call path skb_mac_gso_segment -> inet_gso_segment ->
    udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
    does not try to update UDP/IP header of the segment list but copy
    only the MAC header.
    
    Update port, addr and check of each skb of the segment list in
    __udp_gso_segment_list. It covers both SNAT and DNAT.
    
    Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
    Signed-off-by: Dongseok Yi <dseok.yi@samsung.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Link: https://lore.kernel.org/r/1611962007-80092-1-git-send-email-dseok.yi@samsung.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2b30f9f0889f61b9679bb0630e835636a270fb7
Author: Vadim Fedorenko <vfedorenko@novek.ru>
Date:   Sat Jan 30 01:27:47 2021 +0300

    net: ip_tunnel: fix mtu calculation
    
    commit 28e104d00281ade30250b24e098bf50887671ea4 upstream.
    
    dev->hard_header_len for tunnel interface is set only when header_ops
    are set too and already contains full overhead of any tunnel encapsulation.
    That's why there is not need to use this overhead twice in mtu calc.
    
    Fixes: fdafed459998 ("ip_gre: set dev->hard_header_len and dev->needed_headroom properly")
    Reported-by: Slava Bacherikov <mail@slava.cc>
    Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Link: https://lore.kernel.org/r/1611959267-20536-1-git-send-email-vfedorenko@novek.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e4583ad6df09bd10d3f572ababc017c39f5109f
Author: Chinmay Agarwal <chinagar@codeaurora.org>
Date:   Wed Jan 27 22:24:54 2021 +0530

    neighbour: Prevent a dead entry from updating gc_list
    
    commit eb4e8fac00d1e01ada5e57c05d24739156086677 upstream.
    
    Following race condition was detected:
    <CPU A, t0> - neigh_flush_dev() is under execution and calls
    neigh_mark_dead(n) marking the neighbour entry 'n' as dead.
    
    <CPU B, t1> - Executing: __netif_receive_skb() ->
    __netif_receive_skb_core() -> arp_rcv() -> arp_process().arp_process()
    calls __neigh_lookup() which takes a reference on neighbour entry 'n'.
    
    <CPU A, t2> - Moves further along neigh_flush_dev() and calls
    neigh_cleanup_and_release(n), but since reference count increased in t2,
    'n' couldn't be destroyed.
    
    <CPU B, t3> - Moves further along, arp_process() and calls
    neigh_update()-> __neigh_update() -> neigh_update_gc_list(), which adds
    the neighbour entry back in gc_list(neigh_mark_dead(), removed it
    earlier in t0 from gc_list)
    
    <CPU B, t4> - arp_process() finally calls neigh_release(n), destroying
    the neighbour entry.
    
    This leads to 'n' still being part of gc_list, but the actual
    neighbour structure has been freed.
    
    The situation can be prevented from happening if we disallow a dead
    entry to have any possibility of updating gc_list. This is what the
    patch intends to achieve.
    
    Fixes: 9c29a2f55ec0 ("neighbor: Fix locking order for gc_list changes")
    Signed-off-by: Chinmay Agarwal <chinagar@codeaurora.org>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20210127165453.GA20514@chinagar-linux.qualcomm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a8a25d56a63a3e0ff3bb24b7deb934c92fbc522
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Dec 2 15:50:17 2020 +0800

    igc: Report speed and duplex as unknown when device is runtime suspended
    
    commit 2e99dedc73f004f650b197c9b269c15c7e01ad15 upstream.
    
    Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
    when device is runtime suspended"), if we try to read speed and duplex
    sysfs while the device is runtime suspended, igc will complain and
    stops working:
    
    [  123.449883] igc 0000:03:00.0 enp3s0: PCIe link lost, device now detached
    [  123.450052] BUG: kernel NULL pointer dereference, address: 0000000000000008
    [  123.450056] #PF: supervisor read access in kernel mode
    [  123.450058] #PF: error_code(0x0000) - not-present page
    [  123.450059] PGD 0 P4D 0
    [  123.450064] Oops: 0000 [#1] SMP NOPTI
    [  123.450068] CPU: 0 PID: 2525 Comm: udevadm Tainted: G     U  W  OE     5.10.0-1002-oem #2+rkl2-Ubuntu
    [  123.450078] RIP: 0010:igc_rd32+0x1c/0x90 [igc]
    [  123.450080] Code: c0 5d c3 b8 fd ff ff ff c3 0f 1f 44 00 00 0f 1f 44 00 00 55 89 f0 48 89 e5 41 56 41 55 41 54 49 89 c4 53 48 8b 57 08 48 01 d0 <44> 8b 28 41 83 fd ff 74 0c 5b 44 89 e8 41 5c 41 5d 4
    
    [  123.450083] RSP: 0018:ffffb0d100d6fcc0 EFLAGS: 00010202
    [  123.450085] RAX: 0000000000000008 RBX: ffffb0d100d6fd30 RCX: 0000000000000000
    [  123.450087] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff945a12716c10
    [  123.450089] RBP: ffffb0d100d6fce0 R08: ffff945a12716550 R09: ffff945a09874000
    [  123.450090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000008
    [  123.450092] R13: ffff945a12716000 R14: ffff945a037da280 R15: ffff945a037da290
    [  123.450094] FS:  00007f3b34c868c0(0000) GS:ffff945b89200000(0000) knlGS:0000000000000000
    [  123.450096] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  123.450098] CR2: 0000000000000008 CR3: 00000001144de006 CR4: 0000000000770ef0
    [  123.450100] PKRU: 55555554
    [  123.450101] Call Trace:
    [  123.450111]  igc_ethtool_get_link_ksettings+0xd6/0x1b0 [igc]
    [  123.450118]  __ethtool_get_link_ksettings+0x71/0xb0
    [  123.450123]  duplex_show+0x74/0xc0
    [  123.450129]  dev_attr_show+0x1d/0x40
    [  123.450134]  sysfs_kf_seq_show+0xa1/0x100
    [  123.450137]  kernfs_seq_show+0x27/0x30
    [  123.450142]  seq_read+0xb7/0x400
    [  123.450148]  ? common_file_perm+0x72/0x170
    [  123.450151]  kernfs_fop_read+0x35/0x1b0
    [  123.450155]  vfs_read+0xb5/0x1b0
    [  123.450157]  ksys_read+0x67/0xe0
    [  123.450160]  __x64_sys_read+0x1a/0x20
    [  123.450164]  do_syscall_64+0x38/0x90
    [  123.450168]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  123.450170] RIP: 0033:0x7f3b351fe142
    [  123.450173] Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
    [  123.450174] RSP: 002b:00007fffef2ec138 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
    [  123.450177] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3b351fe142
    [  123.450179] RDX: 0000000000001001 RSI: 00005644c047f070 RDI: 0000000000000003
    [  123.450180] RBP: 00007fffef2ec340 R08: 00005644c047f070 R09: 00007f3b352d9320
    [  123.450182] R10: 00005644c047c010 R11: 0000000000000246 R12: 00005644c047cbf0
    [  123.450184] R13: 00005644c047e6d0 R14: 0000000000000003 R15: 00007fffef2ec140
    [  123.450189] Modules linked in: rfcomm ccm cmac algif_hash algif_skcipher af_alg bnep toshiba_acpi industrialio toshiba_haps hp_accel lis3lv02d btusb btrtl btbcm btintel bluetooth ecdh_generic ecc joydev input_leds nls_iso8859_1 snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_hda_codec_hdmi snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation soundwire_cadence snd_hda_codec snd_hda_core ath10k_pci snd_hwdep intel_rapl_msr intel_rapl_common ath10k_core soundwire_bus snd_soc_core x86_pkg_temp_thermal ath intel_powerclamp snd_compress ac97_bus snd_pcm_dmaengine mac80211 snd_pcm coretemp snd_seq_midi snd_seq_midi_event snd_rawmidi kvm_intel cfg80211 snd_seq snd_seq_device snd_timer mei_hdcp kvm libarc4 snd crct10dif_pclmul ghash_clmulni_intel aesni_intel
     mei_me dell_wmi
    [  123.450266]  dell_smbios soundcore sparse_keymap dcdbas crypto_simd cryptd mei dell_uart_backlight glue_helper ee1004 wmi_bmof intel_wmi_thunderbolt dell_wmi_descriptor mac_hid efi_pstore acpi_pad acpi_tad intel_cstate sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crc32_pclmul rc_core drm intel_lpss_pci i2c_i801 ahci igc intel_lpss i2c_smbus idma64 xhci_pci libahci virt_dma xhci_pci_renesas wmi video pinctrl_tigerlake
    [  123.450335] CR2: 0000000000000008
    [  123.450338] ---[ end trace 9f731e38b53c35cc ]---
    
    The more generic approach will be wrap get_link_ksettings() with begin()
    and complete() callbacks, and calls runtime resume and runtime suspend
    routine respectively. However, igc is like igb, runtime resume routine
    uses rtnl_lock() which upper ethtool layer also uses.
    
    So to prevent a deadlock on rtnl, take a different approach, use
    pm_runtime_suspended() to avoid reading register while device is runtime
    suspended.
    
    Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Sasha Neftin <sasha.neftin@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe272570d0037c54c40cba31eaa42a343a5656fa
Author: Xiao Ni <xni@redhat.com>
Date:   Thu Dec 10 14:33:32 2020 +0800

    md: Set prev_flush_start and flush_bio in an atomic way
    
    commit dc5d17a3c39b06aef866afca19245a9cfb533a79 upstream.
    
    One customer reports a crash problem which causes by flush request. It
    triggers a warning before crash.
    
            /* new request after previous flush is completed */
            if (ktime_after(req_start, mddev->prev_flush_start)) {
                    WARN_ON(mddev->flush_bio);
                    mddev->flush_bio = bio;
                    bio = NULL;
            }
    
    The WARN_ON is triggered. We use spin lock to protect prev_flush_start and
    flush_bio in md_flush_request. But there is no lock protection in
    md_submit_flush_data. It can set flush_bio to NULL first because of
    compiler reordering write instructions.
    
    For example, flush bio1 sets flush bio to NULL first in
    md_submit_flush_data. An interrupt or vmware causing an extended stall
    happen between updating flush_bio and prev_flush_start. Because flush_bio
    is NULL, flush bio2 can get the lock and submit to underlayer disks. Then
    flush bio1 updates prev_flush_start after the interrupt or extended stall.
    
    Then flush bio3 enters in md_flush_request. The start time req_start is
    behind prev_flush_start. The flush_bio is not NULL(flush bio2 hasn't
    finished). So it can trigger the WARN_ON now. Then it calls INIT_WORK
    again. INIT_WORK() will re-initialize the list pointers in the
    work_struct, which then can result in a corrupted work list and the
    work_struct queued a second time. With the work list corrupted, it can
    lead in invalid work items being used and cause a crash in
    process_one_work.
    
    We need to make sure only one flush bio can be handled at one same time.
    So add spin lock in md_submit_flush_data to protect prev_flush_start and
    flush_bio in an atomic way.
    
    Reviewed-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a492e4403ee2e3442397230d68e26e81525af90
Author: Marek Vasut <marex@denx.de>
Date:   Sun Jan 3 17:43:04 2021 -0800

    Input: ili210x - implement pressure reporting for ILI251x
    
    commit 60159e9e7bc7e528c103b6b6d47dfd83af29669c upstream.
    
    The ILI251x seems to report pressure information in the 5th byte of
    each per-finger touch data element. On the available hardware, this
    information has the values ranging from 0x0 to 0xa, which is also
    matching the downstream example code. Report pressure information
    on the ILI251x.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Link: https://lore.kernel.org/r/20201224071238.160098-1-marex@denx.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1841be8d0bc6dbb5a2f545dbf1c5d0746f179f26
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Thu Jan 21 19:24:17 2021 -0800

    Input: xpad - sync supported devices with fork on GitHub
    
    commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
    
    There is a fork of this driver on GitHub [0] that has been updated
    with new device IDs.
    
    Merge those into the mainline driver, so the out-of-tree fork is not
    needed for users of those devices anymore.
    
    [0] https://github.com/paroj/xpad
    
    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Link: https://lore.kernel.org/r/20210121142523.1b6b050f@rechenknecht2k11
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b442912f678a495a922c54c5c5a8c3f529b84111
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Date:   Sat Jan 9 22:14:39 2021 -0800

    Input: goodix - add support for Goodix GT9286 chip
    
    commit 2dce6db70c77bbe639f5cd9cc796fb8f2694a7d0 upstream.
    
    The Goodix GT9286 is a capacitive touch sensor IC based on GT1x.
    
    This chip can be found on a number of smartphones, including the
    F(x)tec Pro 1 and the Elephone U.
    
    This has been tested on F(x)Tec Pro1 (MSM8998).
    
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Link: https://lore.kernel.org/r/20210109135512.149032-2-angelogioacchino.delregno@somainline.org
    Reviewed-by: Bastien Nocera <hadess@hadess.net>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ce5be67d134bc2488980ca4cd31b458c932d385
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date:   Thu Mar 5 09:47:08 2020 -0800

    x86/apic: Add extra serialization for non-serializing MSRs
    
    commit 25a068b8e9a4eb193d755d58efcb3c98928636e0 upstream.
    
    Jan Kiszka reported that the x2apic_wrmsr_fence() function uses a plain
    MFENCE while the Intel SDM (10.12.3 MSR Access in x2APIC Mode) calls for
    MFENCE; LFENCE.
    
    Short summary: we have special MSRs that have weaker ordering than all
    the rest. Add fencing consistent with current SDM recommendations.
    
    This is not known to cause any issues in practice, only in theory.
    
    Longer story below:
    
    The reason the kernel uses a different semantic is that the SDM changed
    (roughly in late 2017). The SDM changed because folks at Intel were
    auditing all of the recommended fences in the SDM and realized that the
    x2apic fences were insufficient.
    
    Why was the pain MFENCE judged insufficient?
    
    WRMSR itself is normally a serializing instruction. No fences are needed
    because the instruction itself serializes everything.
    
    But, there are explicit exceptions for this serializing behavior written
    into the WRMSR instruction documentation for two classes of MSRs:
    IA32_TSC_DEADLINE and the X2APIC MSRs.
    
    Back to x2apic: WRMSR is *not* serializing in this specific case.
    But why is MFENCE insufficient? MFENCE makes writes visible, but
    only affects load/store instructions. WRMSR is unfortunately not a
    load/store instruction and is unaffected by MFENCE. This means that a
    non-serializing WRMSR could be reordered by the CPU to execute before
    the writes made visible by the MFENCE have even occurred in the first
    place.
    
    This means that an x2apic IPI could theoretically be triggered before
    there is any (visible) data to process.
    
    Does this affect anything in practice? I honestly don't know. It seems
    quite possible that by the time an interrupt gets to consume the (not
    yet) MFENCE'd data, it has become visible, mostly by accident.
    
    To be safe, add the SDM-recommended fences for all x2apic WRMSRs.
    
    This also leaves open the question of the _other_ weakly-ordered WRMSR:
    MSR_IA32_TSC_DEADLINE. While it has the same ordering architecture as
    the x2APIC MSRs, it seems substantially less likely to be a problem in
    practice. While writes to the in-memory Local Vector Table (LVT) might
    theoretically be reordered with respect to a weakly-ordered WRMSR like
    TSC_DEADLINE, the SDM has this to say:
    
      In x2APIC mode, the WRMSR instruction is used to write to the LVT
      entry. The processor ensures the ordering of this write and any
      subsequent WRMSR to the deadline; no fencing is required.
    
    But, that might still leave xAPIC exposed. The safest thing to do for
    now is to add the extra, recommended LFENCE.
    
     [ bp: Massage commit message, fix typos, drop accidentally added
       newline to tools/arch/x86/include/asm/barrier.h. ]
    
    Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200305174708.F77040DD@viggo.jf.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3dcf233b5845c99a3a0d3a3049f9d0c1b68ed49b
Author: Lai Jiangshan <laijs@linux.alibaba.com>
Date:   Thu Feb 4 23:27:07 2021 +0800

    x86/debug: Prevent data breakpoints on cpu_dr7
    
    commit 3943abf2dbfae9ea4d2da05c1db569a0603f76da upstream.
    
    local_db_save() is called at the start of exc_debug_kernel(), reads DR7 and
    disables breakpoints to prevent recursion.
    
    When running in a guest (X86_FEATURE_HYPERVISOR), local_db_save() reads the
    per-cpu variable cpu_dr7 to check whether a breakpoint is active or not
    before it accesses DR7.
    
    A data breakpoint on cpu_dr7 therefore results in infinite #DB recursion.
    
    Disallow data breakpoints on cpu_dr7 to prevent that.
    
    Fixes: 84b6a3491567a("x86/entry: Optimize local_db_save() for virt")
    Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210204152708.21308-2-jiangshanlai@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b796770c6db3dabe0daa7d7d1f04cc6afd53c569
Author: Lai Jiangshan <laijs@linux.alibaba.com>
Date:   Thu Feb 4 23:27:06 2021 +0800

    x86/debug: Prevent data breakpoints on __per_cpu_offset
    
    commit c4bed4b96918ff1d062ee81fdae4d207da4fa9b0 upstream.
    
    When FSGSBASE is enabled, paranoid_entry() fetches the per-CPU GSBASE value
    via __per_cpu_offset or pcpu_unit_offsets.
    
    When a data breakpoint is set on __per_cpu_offset[cpu] (read-write
    operation), the specific CPU will be stuck in an infinite #DB loop.
    
    RCU will try to send an NMI to the specific CPU, but it is not working
    either since NMI also relies on paranoid_entry(). Which means it's
    undebuggable.
    
    Fixes: eaad981291ee3("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")
    Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210204152708.21308-1-jiangshanlai@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c000dcfb3aede952db92086053d03be3da30487e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jan 28 22:16:27 2021 +0100

    x86/debug: Fix DR6 handling
    
    commit 9ad22e165994ccb64d85b68499eaef97342c175b upstream.
    
    Tom reported that one of the GDB test-cases failed, and Boris bisected
    it to commit:
    
      d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6")
    
    The debugging session led us to commit:
    
      6c0aca288e72 ("x86: Ignore trap bits on single step exceptions")
    
    It turns out that TF and data breakpoints are both traps and will be
    merged, while instruction breakpoints are faults and will not be merged.
    This means 6c0aca288e72 is wrong, only TF and instruction breakpoints
    need to be excluded while TF and data breakpoints can be merged.
    
     [ bp: Massage commit message. ]
    
    Fixes: d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6")
    Fixes: 6c0aca288e72 ("x86: Ignore trap bits on single step exceptions")
    Reported-by: Tom de Vries <tdevries@suse.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/YBMAbQGACujjfz%2Bi@hirez.programming.kicks-ass.net
    Link: https://lkml.kernel.org/r/20210128211627.GB4348@worktop.programming.kicks-ass.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a2dfe6a319afb47448b28bedd65319aa59faef0
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Thu Jan 28 15:52:19 2021 -0600

    x86/build: Disable CET instrumentation in the kernel
    
    commit 20bf2b378729c4a0366a53e2018a0b70ace94bcd upstream.
    
    With retpolines disabled, some configurations of GCC, and specifically
    the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
    to the kernel by default. That breaks certain tracing scenarios by
    adding a superfluous ENDBR64 instruction before the fentry call, for
    functions which can be called indirectly.
    
    CET instrumentation isn't currently necessary in the kernel, as CET is
    only supported in user space. Disable it unconditionally and move it
    into the x86's Makefile as CET/CFI... enablement should be a per-arch
    decision anyway.
    
     [ bp: Massage and extend commit message. ]
    
    Fixes: 29be86d7f9cb ("kbuild: add -fcf-protection=none when using retpoline flags")
    Reported-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Tested-by: Nikolay Borisov <nborisov@suse.com>
    Cc: <stable@vger.kernel.org>
    Cc: Seth Forshee <seth.forshee@canonical.com>
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 032f8e04c0353f015d243008f039bb6e18a173c7
Author: Waiman Long <longman@redhat.com>
Date:   Thu Feb 4 18:32:45 2021 -0800

    mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked()
    
    commit da74240eb3fcd806edb1643874363e954d9e948b upstream.
    
    Commit 3fea5a499d57 ("mm: memcontrol: convert page cache to a new
    mem_cgroup_charge() API") introduced a bug in __add_to_page_cache_locked()
    causing the following splat:
    
      page dumped because: VM_BUG_ON_PAGE(page_memcg(page))
      pages's memcg:ffff8889a4116000
      ------------[ cut here ]------------
      kernel BUG at mm/memcontrol.c:2924!
      invalid opcode: 0000 [#1] SMP KASAN PTI
      CPU: 35 PID: 12345 Comm: cat Tainted: G S      W I       5.11.0-rc4-debug+ #1
      Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 v01.25 12/06/2017
      RIP: commit_charge+0xf4/0x130
      Call Trace:
        mem_cgroup_charge+0x175/0x770
        __add_to_page_cache_locked+0x712/0xad0
        add_to_page_cache_lru+0xc5/0x1f0
        cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles]
        __fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache]
        __nfs_readpages_from_fscache+0x16d/0x630 [nfs]
        nfs_readpages+0x24e/0x540 [nfs]
        read_pages+0x5b1/0xc40
        page_cache_ra_unbounded+0x460/0x750
        generic_file_buffered_read_get_pages+0x290/0x1710
        generic_file_buffered_read+0x2a9/0xc30
        nfs_file_read+0x13f/0x230 [nfs]
        new_sync_read+0x3af/0x610
        vfs_read+0x339/0x4b0
        ksys_read+0xf1/0x1c0
        do_syscall_64+0x33/0x40
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Before that commit, there was a try_charge() and commit_charge() in
    __add_to_page_cache_locked().  These two separated charge functions were
    replaced by a single mem_cgroup_charge().  However, it forgot to add a
    matching mem_cgroup_uncharge() when the xarray insertion failed with the
    page released back to the pool.
    
    Fix this by adding a mem_cgroup_uncharge() call when insertion error
    happens.
    
    Link: https://lkml.kernel.org/r/20210125042441.20030-1-longman@redhat.com
    Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new mem_cgroup_charge() API")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Alex Shi <alex.shi@linux.alibaba.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Muchun Song <smuchun@gmail.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a249ac189fc7fad3e989640384fde5fe62ac550
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Feb 4 18:32:31 2021 -0800

    mm: thp: fix MADV_REMOVE deadlock on shmem THP
    
    commit 1c2f67308af4c102b4e1e6cd6f69819ae59408e0 upstream.
    
    Sergey reported deadlock between kswapd correctly doing its usual
    lock_page(page) followed by down_read(page->mapping->i_mmap_rwsem), and
    madvise(MADV_REMOVE) on an madvise(MADV_HUGEPAGE) area doing
    down_write(page->mapping->i_mmap_rwsem) followed by lock_page(page).
    
    This happened when shmem_fallocate(punch hole)'s unmap_mapping_range()
    reaches zap_pmd_range()'s call to __split_huge_pmd().  The same deadlock
    could occur when partially truncating a mapped huge tmpfs file, or using
    fallocate(FALLOC_FL_PUNCH_HOLE) on it.
    
    __split_huge_pmd()'s page lock was added in 5.8, to make sure that any
    concurrent use of reuse_swap_page() (holding page lock) could not catch
    the anon THP's mapcounts and swapcounts while they were being split.
    
    Fortunately, reuse_swap_page() is never applied to a shmem or file THP
    (not even by khugepaged, which checks PageSwapCache before calling), and
    anonymous THPs are never created in shmem or file areas: so that
    __split_huge_pmd()'s page lock can only be necessary for anonymous THPs,
    on which there is no risk of deadlock with i_mmap_rwsem.
    
    Link: https://lkml.kernel.org/r/alpine.LSU.2.11.2101161409470.2022@eggly.anvils
    Fixes: c444eb564fb1 ("mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9abdd2c05b59ad6f0ab4aaa3977c544c52d56f8a
Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
Date:   Thu Feb 4 18:32:24 2021 -0800

    mm/vmalloc: separate put pages and flush VM flags
    
    commit 4f6ec8602341e97b364e4e0d41a1ed08148f5e98 upstream.
    
    When VM_MAP_PUT_PAGES was added, it was defined with the same value as
    VM_FLUSH_RESET_PERMS.  This doesn't seem like it will cause any big
    functional problems other than some excess flushing for VM_MAP_PUT_PAGES
    allocations.
    
    Redefine VM_MAP_PUT_PAGES to have its own value.  Also, rearrange things
    so flags are less likely to be missed in the future.
    
    Link: https://lkml.kernel.org/r/20210122233706.9304-1-rick.p.edgecombe@intel.com
    Fixes: b944afc9d64d ("mm: add a VM_MAP_PUT_PAGES flag for vmap")
    Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Suggested-by: Matthew Wilcox <willy@infradead.org>
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Daniel Axtens <dja@axtens.net>
    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 76303d3fab9fcd6167a87fd0ef0de9b3222e97da
Author: Rokudo Yan <wu-yan@tcl.com>
Date:   Thu Feb 4 18:32:20 2021 -0800

    mm, compaction: move high_pfn to the for loop scope
    
    commit 74e21484e40bb8ce0f9828bbfe1c9fc9b04249c6 upstream.
    
    In fast_isolate_freepages, high_pfn will be used if a prefered one (ie
    PFN >= low_fn) not found.
    
    But the high_pfn is not reset before searching an free area, so when it
    was used as freepage, it may from another free area searched before.  As
    a result move_freelist_head(freelist, freepage) will have unexpected
    behavior (eg corrupt the MOVABLE freelist)
    
      Unable to handle kernel paging request at virtual address dead000000000200
      Mem abort info:
        ESR = 0x96000044
        Exception class = DABT (current EL), IL = 32 bits
        SET = 0, FnV = 0
        EA = 0, S1PTW = 0
      Data abort info:
        ISV = 0, ISS = 0x00000044
        CM = 0, WnR = 1
      [dead000000000200] address between user and kernel address ranges
    
      -000|list_cut_before(inline)
      -000|move_freelist_head(inline)
      -000|fast_isolate_freepages(inline)
      -000|isolate_freepages(inline)
      -000|compaction_alloc(?, ?)
      -001|unmap_and_move(inline)
      -001|migrate_pages([NSD:0xFFFFFF80088CBBD0] from = 0xFFFFFF80088CBD88, [NSD:0xFFFFFF80088CBBC8] get_new_p
      -002|__read_once_size(inline)
      -002|static_key_count(inline)
      -002|static_key_false(inline)
      -002|trace_mm_compaction_migratepages(inline)
      -002|compact_zone(?, [NSD:0xFFFFFF80088CBCB0] capc = 0x0)
      -003|kcompactd_do_work(inline)
      -003|kcompactd([X19] p = 0xFFFFFF93227FBC40)
      -004|kthread([X20] _create = 0xFFFFFFE1AFB26380)
      -005|ret_from_fork(asm)
    
    The issue was reported on an smart phone product with 6GB ram and 3GB
    zram as swap device.
    
    This patch fixes the issue by reset high_pfn before searching each free
    area, which ensure freepage and freelist match when call
    move_freelist_head in fast_isolate_freepages().
    
    Link: http://lkml.kernel.org/r/20190118175136.31341-12-mgorman@techsingularity.net
    Link: https://lkml.kernel.org/r/20210112094720.1238444-1-wu-yan@tcl.com
    Fixes: 5a811889de10f1eb ("mm, compaction: use free lists to quickly locate a migration target")
    Signed-off-by: Rokudo Yan <wu-yan@tcl.com>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eca84ebef17f1564f2f25201f5c7ac173d54e32d
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:13 2021 -0800

    mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active
    
    commit ecbf4724e6061b4b01be20f6d797d64d462b2bc8 upstream.
    
    The page_huge_active() can be called from scan_movable_pages() which do
    not hold a reference count to the HugeTLB page.  So when we call
    page_huge_active() from scan_movable_pages(), the HugeTLB page can be
    freed parallel.  Then we will trigger a BUG_ON which is in the
    page_huge_active() when CONFIG_DEBUG_VM is enabled.  Just remove the
    VM_BUG_ON_PAGE.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-6-songmuchun@bytedance.com
    Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b9631cb6f3493408c26fcbbf8b90bf49f31bfed
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:10 2021 -0800

    mm: hugetlb: fix a race between isolating and freeing page
    
    commit 0eb2df2b5629794020f75e94655e1994af63f0d4 upstream.
    
    There is a race between isolate_huge_page() and __free_huge_page().
    
      CPU0:                                     CPU1:
    
      if (PageHuge(page))
                                                put_page(page)
                                                  __free_huge_page(page)
                                                      spin_lock(&hugetlb_lock)
                                                      update_and_free_page(page)
                                                        set_compound_page_dtor(page,
                                                          NULL_COMPOUND_DTOR)
                                                      spin_unlock(&hugetlb_lock)
        isolate_huge_page(page)
          // trigger BUG_ON
          VM_BUG_ON_PAGE(!PageHead(page), page)
          spin_lock(&hugetlb_lock)
          page_huge_active(page)
            // trigger BUG_ON
            VM_BUG_ON_PAGE(!PageHuge(page), page)
          spin_unlock(&hugetlb_lock)
    
    When we isolate a HugeTLB page on CPU0.  Meanwhile, we free it to the
    buddy allocator on CPU1.  Then, we can trigger a BUG_ON on CPU0, because
    it is already freed to the buddy allocator.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-5-songmuchun@bytedance.com
    Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e334b1fec6f426ce47967f390fd7c9c94c56dd5b
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:06 2021 -0800

    mm: hugetlb: fix a race between freeing and dissolving the page
    
    commit 7ffddd499ba6122b1a07828f023d1d67629aa017 upstream.
    
    There is a race condition between __free_huge_page()
    and dissolve_free_huge_page().
    
      CPU0:                         CPU1:
    
      // page_count(page) == 1
      put_page(page)
        __free_huge_page(page)
                                    dissolve_free_huge_page(page)
                                      spin_lock(&hugetlb_lock)
                                      // PageHuge(page) && !page_count(page)
                                      update_and_free_page(page)
                                      // page is freed to the buddy
                                      spin_unlock(&hugetlb_lock)
          spin_lock(&hugetlb_lock)
          clear_page_huge_active(page)
          enqueue_huge_page(page)
          // It is wrong, the page is already freed
          spin_unlock(&hugetlb_lock)
    
    The race window is between put_page() and dissolve_free_huge_page().
    
    We should make sure that the page is already on the free list when it is
    dissolved.
    
    As a result __free_huge_page would corrupt page(s) already in the buddy
    allocator.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-4-songmuchun@bytedance.com
    Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afe6c31b84f6f27ea54d5424af1ff186f01144e4
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:03 2021 -0800

    mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
    
    commit 585fc0d2871c9318c949fbf45b1f081edd489e96 upstream.
    
    If a new hugetlb page is allocated during fallocate it will not be
    marked as active (set_page_huge_active) which will result in a later
    isolate_huge_page failure when the page migration code would like to
    move that page.  Such a failure would be unexpected and wrong.
    
    Only export set_page_huge_active, just leave clear_page_huge_active as
    static.  Because there are no external users.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-3-songmuchun@bytedance.com
    Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate())
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2de0745463e328d6f3f3f727011dd5767c4b5efa
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Tue Dec 15 16:16:44 2020 +0100

    ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor
    
    commit 538eea5362a1179dfa7770dd2b6607dc30cc50c6 upstream.
    
    The tegra_uart_config of the DEBUG_LL code is now placed right at the
    start of the .text section after commit which enabled debug output in the
    decompressor. Tegra devices are not booting anymore if DEBUG_LL is enabled
    since tegra_uart_config data is executes as a code. Fix the misplaced
    tegra_uart_config storage by embedding it into the code.
    
    Cc: stable@vger.kernel.org
    Fixes: 2596a72d3384 ("ARM: 9009/1: uncompress: Enable debug in head.S")
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 384cddbee46f07b029c7b44622d504e6ec4b3e22
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Sun Oct 18 09:39:21 2020 +0100

    ARM: footbridge: fix dc21285 PCI configuration accessors
    
    commit 39d3454c3513840eb123b3913fda6903e45ce671 upstream.
    
    Building with gcc 4.9.2 reveals a latent bug in the PCI accessors
    for Footbridge platforms, which causes a fatal alignment fault
    while accessing IO memory. Fix this by making the assembly volatile.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc7b2fc9091626be615a938aa18c697e95ee0a97
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Wed Dec 23 11:30:21 2020 +0100

    ARM: dts; gta04: SPI panel chip select is active low
    
    commit 181739822cf6f8f4e12b173913af2967a28906c0 upstream.
    
    With the arrival of
    
    commit 2fee9583198eb9 ("spi: dt-bindings: clarify CS behavior for spi-cs-high and gpio descriptors")
    
    it was clarified what the proper state for cs-gpios should be, even if the
    flag is ignored. The driver code is doing the right thing since
    
    766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
    
    The chip-select of the td028ttec1 panel is active-low, so we must omit spi-cs-high;
    attribute (already removed by separate patch) and should now use GPIO_ACTIVE_LOW for
    the client device description to be fully consistent.
    
    Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
    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 160237c192c4b75f42c5971a66e88e822ae8fa9a
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Sat Dec 12 10:55:25 2020 +0100

    DTS: ARM: gta04: remove legacy spi-cs-high to make display work again
    
    commit 07af7810e0a5bc4e51682c90f9fa19fc4cb93f18 upstream.
    
    This reverts
    
    commit f1f028ff89cb ("DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again")
    
    which had to be intruduced after
    
    commit 6953c57ab172 ("gpio: of: Handle SPI chipselect legacy bindings")
    
    broke the GTA04 display. This contradicted the data sheet but was the only
    way to get it as an spi client operational again.
    
    The panel data sheet defines the chip-select to be active low.
    
    Now, with the arrival of
    
    commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
    
    the logic of interaction between spi-cs-high and the gpio descriptor flags
    has been changed a second time, making the display broken again. So we have
    to remove the original fix which in retrospect was a workaround of a bug in
    the spi subsystem and not a feature of the panel or bug in the device tree.
    
    With this fix the device tree is back in sync with the data sheet and
    spi subsystem code.
    
    Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
    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 7159239d2de1eea77b322e661141a36c6a909b05
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Feb 3 16:01:06 2021 -0800

    KVM: x86: Set so called 'reserved CR3 bits in LM mask' at vCPU reset
    
    commit 031b91a5fe6f1ce61b7617614ddde9ed61e252be upstream.
    
    Set cr3_lm_rsvd_bits, which is effectively an invalid GPA mask, at vCPU
    reset.  The reserved bits check needs to be done even if userspace never
    configures the guest's CPUID model.
    
    Cc: stable@vger.kernel.org
    Fixes: 0107973a80ad ("KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210204000117.3303214-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d73af5ae22d419264208a5411cfaf5b3ccb1bd48
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Feb 2 08:55:46 2021 -0800

    KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode
    
    commit 943dea8af21bd896e0d6c30ea221203fb3cd3265 upstream.
    
    Set the emulator context to PROT64 if SYSENTER transitions from 32-bit
    userspace (compat mode) to a 64-bit kernel, otherwise the RIP update at
    the end of x86_emulate_insn() will incorrectly truncate the new RIP.
    
    Note, this bug is mostly limited to running an Intel virtual CPU model on
    an AMD physical CPU, as other combinations of virtual and physical CPUs
    do not trigger full emulation.  On Intel CPUs, SYSENTER in compatibility
    mode is legal, and unconditionally transitions to 64-bit mode.  On AMD
    CPUs, SYSENTER is illegal in compatibility mode and #UDs.  If the vCPU is
    AMD, KVM injects a #UD on SYSENTER in compat mode.  If the pCPU is Intel,
    SYSENTER will execute natively and not trigger #UD->VM-Exit (ignoring
    guest TLB shenanigans).
    
    Fixes: fede8076aab4 ("KVM: x86: handle wrap around 32-bit address space")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonny Barker <jonny@jonnybarker.com>
    [sean: wrote changelog]
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210202165546.2390296-1-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46add0349ba3a9be96d3f1dd202bb589770798cc
Author: Michael Roth <michael.roth@amd.com>
Date:   Wed Jan 27 20:44:51 2021 -0600

    KVM: x86: fix CPUID entries returned by KVM_GET_CPUID2 ioctl
    
    commit 181f494888d5b178ffda41bed965f187d5e5c432 upstream.
    
    Recent commit 255cbecfe0 modified struct kvm_vcpu_arch to make
    'cpuid_entries' a pointer to an array of kvm_cpuid_entry2 entries
    rather than embedding the array in the struct. KVM_SET_CPUID and
    KVM_SET_CPUID2 were updated accordingly, but KVM_GET_CPUID2 was missed.
    
    As a result, KVM_GET_CPUID2 currently returns random fields from struct
    kvm_vcpu_arch to userspace rather than the expected CPUID values. Fix
    this by treating 'cpuid_entries' as a pointer when copying its
    contents to userspace buffer.
    
    Fixes: 255cbecfe0c9 ("KVM: x86: allocate vcpu->arch.cpuid_entries dynamically")
    Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Michael Roth <michael.roth@amd.com.com>
    Message-Id: <20210128024451.1816770-1-michael.roth@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 6c0e069ac6e8db0c49dcc90d37ede5b1da08fe0b
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 28 11:45:00 2021 -0500

    KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off
    
    commit 7131636e7ea5b50ca910f8953f6365ef2d1f741c upstream.
    
    Userspace that does not know about KVM_GET_MSR_FEATURE_INDEX_LIST
    will generally use the default value for MSR_IA32_ARCH_CAPABILITIES.
    When this happens and the host has tsx=on, it is possible to end up with
    virtual machines that have HLE and RTM disabled, but TSX_CTRL available.
    
    If the fleet is then switched to tsx=off, kvm_get_arch_capabilities()
    will clear the ARCH_CAP_TSX_CTRL_MSR bit and it will not be possible to
    use the tsx=off hosts as migration destinations, even though the guests
    do not have TSX enabled.
    
    To allow this migration, allow guests to write to their TSX_CTRL MSR,
    while keeping the host MSR unchanged for the entire life of the guests.
    This ensures that TSX remains disabled and also saves MSR reads and
    writes, and it's okay to do because with tsx=off we know that guests will
    not have the HLE and RTM features in their CPUID.  (If userspace sets
    bogus CPUID data, we do not expect HLE and RTM to work in guests anyway).
    
    Cc: stable@vger.kernel.org
    Fixes: cbbaa2727aa3 ("KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES")
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd7f10523b19c809b908be8b11da35c8e13e15f2
Author: Ben Gardon <bgardon@google.com>
Date:   Tue Feb 2 10:57:16 2021 -0800

    KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEs
    
    commit 87aa9ec939ec7277b730786e19c161c9194cc8ca upstream.
    
    There is a bug in the TDP MMU function to zap SPTEs which could be
    replaced with a larger mapping which prevents the function from doing
    anything. Fix this by correctly zapping the last level SPTEs.
    
    Cc: stable@vger.kernel.org
    Fixes: 14881998566d ("kvm: x86/mmu: Support disabling dirty logging for the tdp MMU")
    Signed-off-by: Ben Gardon <bgardon@google.com>
    Message-Id: <20210202185734.1680553-11-bgardon@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff0c437a0e02eb9ecc71f3907ca611ac57fdbcc6
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Feb 2 13:20:17 2021 -0800

    KVM: SVM: Treat SVM as unsupported when running as an SEV guest
    
    commit ccd85d90ce092bdb047a7f6580f3955393833b22 upstream.
    
    Don't let KVM load when running as an SEV guest, regardless of what
    CPUID says.  Memory is encrypted with a key that is not accessible to
    the host (L0), thus it's impossible for L0 to emulate SVM, e.g. it'll
    see garbage when reading the VMCB.
    
    Technically, KVM could decrypt all memory that needs to be accessible to
    the L0 and use shadow paging so that L0 does not need to shadow NPT, but
    exposing such information to L0 largely defeats the purpose of running as
    an SEV guest.  This can always be revisited if someone comes up with a
    use case for running VMs inside SEV guests.
    
    Note, VMLOAD, VMRUN, etc... will also #GP on GPAs with C-bit set, i.e. KVM
    is doomed even if the SEV guest is debuggable and the hypervisor is willing
    to decrypt the VMCB.  This may or may not be fixed on CPUs that have the
    SVME_ADDR_CHK fix.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210202212017.2486595-1-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 720639ef01f5caf9090515ed45b4cd7f37a4cede
Author: Thorsten Leemhuis <linux@leemhuis.info>
Date:   Fri Jan 29 06:24:42 2021 +0100

    nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs
    
    commit 538e4a8c571efdf131834431e0c14808bcfb1004 upstream.
    
    Some Kingston A2000 NVMe SSDs sooner or later get confused and stop
    working when they use the deepest APST sleep while running Linux. The
    system then crashes and one has to cold boot it to get the SSD working
    again.
    
    Kingston seems to known about this since at least mid-September 2020:
    https://bbs.archlinux.org/viewtopic.php?pid=1926994#p1926994
    
    Someone working for a German company representing Kingston to the German
    press confirmed to me Kingston engineering is aware of the issue and
    investigating; the person stated that to their current knowledge only
    the deepest APST sleep state causes trouble. Therefore, make Linux avoid
    it for now by applying the NVME_QUIRK_NO_DEEPEST_PS to this SSD.
    
    I have two such SSDs, but it seems the problem doesn't occur with them.
    I hence couldn't verify if this patch really fixes the problem, but all
    the data in front of me suggests it should.
    
    This patch can easily be reverted or improved upon if a better solution
    surfaces.
    
    FWIW, there are many reports about the issue scattered around the web;
    most of the users disabled APST completely to make things work, some
    just made Linux avoid the deepest sleep state:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c65
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c73
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c74
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c78
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c79
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c80
    https://askubuntu.com/questions/1222049/nvmekingston-a2000-sometimes-stops-giving-response-in-ubuntu-18-04dell-inspir
    https://community.acer.com/en/discussion/604326/m-2-nvme-ssd-aspire-517-51g-issue-compatibility-kingston-a2000-linux-ubuntu
    
    For the record, some data from 'nvme id-ctrl /dev/nvme0'
    
    NVME Identify Controller:
    vid       : 0x2646
    ssvid     : 0x2646
    mn        : KINGSTON SA2000M81000G
    fr        : S5Z42105
    [...]
    ps    0 : mp:9.00W operational enlat:0 exlat:0 rrt:0 rrl:0
              rwt:0 rwl:0 idle_power:- active_power:-
    ps    1 : mp:4.60W operational enlat:0 exlat:0 rrt:1 rrl:1
              rwt:1 rwl:1 idle_power:- active_power:-
    ps    2 : mp:3.80W operational enlat:0 exlat:0 rrt:2 rrl:2
              rwt:2 rwl:2 idle_power:- active_power:-
    ps    3 : mp:0.0450W non-operational enlat:2000 exlat:2000 rrt:3 rrl:3
              rwt:3 rwl:3 idle_power:- active_power:-
    ps    4 : mp:0.0040W non-operational enlat:15000 exlat:15000 rrt:4 rrl:4
              rwt:4 rwl:4 idle_power:- active_power:-
    
    Cc: stable@vger.kernel.org # 4.14+
    Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f25d448d947fcf3afd288acb842dc4abeb4134c
Author: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
Date:   Thu Feb 4 17:20:56 2021 +0800

    io_uring: don't modify identity's files uncess identity is cowed
    
    commit d7e10d47691d1702db1cd1edcc689d3031eefc67 upstream.
    
    Abaci Robot reported following panic:
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    PGD 800000010ef3f067 P4D 800000010ef3f067 PUD 10d9df067 PMD 0
    Oops: 0002 [#1] SMP PTI
    CPU: 0 PID: 1869 Comm: io_wqe_worker-0 Not tainted 5.11.0-rc3+ #1
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    RIP: 0010:put_files_struct+0x1b/0x120
    Code: 24 18 c7 00 f4 ff ff ff e9 4d fd ff ff 66 90 0f 1f 44 00 00 41 57 41 56 49 89 fe 41 55 41 54 55 53 48 83 ec 08 e8 b5 6b db ff  41 ff 0e 74 13 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f e9 9c
    RSP: 0000:ffffc90002147d48 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffff88810d9a5300 RCX: 0000000000000000
    RDX: ffff88810d87c280 RSI: ffffffff8144ba6b RDI: 0000000000000000
    RBP: 0000000000000080 R08: 0000000000000001 R09: ffffffff81431500
    R10: ffff8881001be000 R11: 0000000000000000 R12: ffff88810ac2f800
    R13: ffff88810af38a00 R14: 0000000000000000 R15: ffff8881057130c0
    FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 000000010dbaa002 CR4: 00000000003706f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     __io_clean_op+0x10c/0x2a0
     io_dismantle_req+0x3c7/0x600
     __io_free_req+0x34/0x280
     io_put_req+0x63/0xb0
     io_worker_handle_work+0x60e/0x830
     ? io_wqe_worker+0x135/0x520
     io_wqe_worker+0x158/0x520
     ? __kthread_parkme+0x96/0xc0
     ? io_worker_handle_work+0x830/0x830
     kthread+0x134/0x180
     ? kthread_create_worker_on_cpu+0x90/0x90
     ret_from_fork+0x1f/0x30
    Modules linked in:
    CR2: 0000000000000000
    ---[ end trace c358ca86af95b1e7 ]---
    
    I guess case below can trigger above panic: there're two threads which
    operates different io_uring ctxs and share same sqthread identity, and
    later one thread exits, io_uring_cancel_task_requests() will clear
    task->io_uring->identity->files to be NULL in sqpoll mode, then another
    ctx that uses same identity will panic.
    
    Indeed we don't need to clear task->io_uring->identity->files here,
    io_grab_identity() should handle identity->files changes well, if
    task->io_uring->identity->files is not equal to current->files,
    io_cow_identity() should handle this changes well.
    
    Cc: stable@vger.kernel.org # 5.5+
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    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 2fd938741a792a7fc3aaef6f7bccb2f08a0f1b3d
Author: Stylon Wang <stylon.wang@amd.com>
Date:   Tue Jan 5 11:29:34 2021 +0800

    drm/amd/display: Revert "Fix EDID parsing after resume from suspend"
    
    commit 1a10e5244778169a5a53a527d7830cf0438132a1 upstream.
    
    This reverts commit b24bdc37d03a0478189e20a50286092840f414fa.
    It caused memory leak after S3 on 4K HDMI displays.
    
    Signed-off-by: Stylon Wang <stylon.wang@amd.com>
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Acked-by: Anson Jacob <Anson.Jacob@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@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 09c6d51b16efc425d79d9a4c8db47706691d9605
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Jan 28 17:59:46 2021 +0200

    drm/i915: Power up combo PHY lanes for for HDMI as well
    
    commit fad9bae9ee5d578afbe6380c82e4715efaddf118 upstream.
    
    Currently we only explicitly power up the combo PHY lanes
    for DP. The spec says we should do it for HDMI as well.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-3-ville.syrjala@linux.intel.com
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    (cherry picked from commit 1e0cb7bef35f0d1aed383bf69a209df218b807c9)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24946da51ce79557dbb7e42e360c57539b0a6566
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Jan 28 17:59:45 2021 +0200

    drm/i915: Extract intel_ddi_power_up_lanes()
    
    commit 425cbd1fce10d4d68188123404d1a302a6939e0a upstream.
    
    Reduce the copypasta by pulling the combo PHY lane
    power up stuff into a helper. We'll have a third user soon.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-2-ville.syrjala@linux.intel.com
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    (cherry picked from commit 5cdf706fb91a6e4e6af799bb957c4d598e6a067b)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f27c7362e2b8967a494f1bfa911a8d79f4c4c5b
Author: Andres Calderon Jaramillo <andrescj@chromium.org>
Date:   Tue Feb 2 10:45:53 2021 +0200

    drm/i915/display: Prevent double YUV range correction on HDR planes
    
    commit 00f9a08fbc3c703b71842a5425c1eb82053c8a70 upstream.
    
    Prevent the ICL HDR plane pipeline from performing YUV color range
    correction twice when the input is in limited range. This is done by
    removing the limited-range code from icl_program_input_csc().
    
    Before this patch the following could happen: user space gives us a YUV
    buffer in limited range; per the pipeline in [1], the plane would first
    go through a "YUV Range correct" stage that expands the range; the plane
    would then go through the "Input CSC" stage which would also expand the
    range because icl_program_input_csc() would use a matrix and an offset
    that assume limited-range input; this would ultimately cause dark and
    light colors to appear darker and lighter than they should respectively.
    
    This is an issue because if a buffer switches between being scanned out
    and being composited with the GPU, the user will see a color difference.
    If this switching happens quickly and frequently, the user will perceive
    this as a flickering.
    
    [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201215224219.3896256-1-andrescj@google.com
    (cherry picked from commit fed387572040e84ead53852a7820e30a30e515d0)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210202084553.30691-1-ville.syrjala@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2545b18b98348da5c8f35b27327a6e1c154268e4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 19 16:20:57 2021 +0000

    drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs
    
    commit e4747cb3ec3c232d65c84cbe77633abd5871fda3 upstream.
    
    If we enable_breadcrumbs for a request while that request is being
    removed from HW; we may see that the request is active as we take the
    ce->signal_lock and proceed to attach the request to ce->signals.
    However, during unsubmission after marking the request as inactive, we
    see that the request has not yet been added to ce->signals and so skip
    the removal. Pull the check during cancel_breadcrumbs under the same
    spinlock as enabling so that we the two tests are consistent in
    enable/cancel.
    
    Otherwise, we may insert a request onto ce->signals that we expect should
    not be there:
    
      intel_context_remove_breadcrumbs:488 GEM_BUG_ON(!__i915_request_is_complete(rq))
    
    While updating, we can note that we are always called with
    irqs-disabled, due to the engine->active.lock being held at the single
    caller, and so remove the irqsave/restore making it symmetric to
    enable_breadcrumbs.
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2931
    Fixes: c18636f76344 ("drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: Andi Shyti <andi.shyti@intel.com>
    Cc: <stable@vger.kernel.org> # v5.10+
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210119162057.31097-1-chris@chris-wilson.co.uk
    (cherry picked from commit e7004ea4f5f528f5a5018f0b70cab36d25315498)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cd8e3ef7f68319c7108c9cd5a7f4f62d0ac1758
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 25 13:21:58 2021 +0000

    drm/i915/gem: Drop lru bumping on display unpinning
    
    commit 761c70a52586a9214b29026d384d2c01b73661a8 upstream.
    
    Simplify the frontbuffer unpin by removing the lock requirement. The LRU
    bumping was primarily to protect the GTT from being evicted and from
    frontbuffers being eagerly shrunk. Now we protect frontbuffers from the
    shrinker, and we avoid accidentally evicting from the GTT, so the
    benefit from bumping LRU is no more, and we can save more time by not.
    
    Reported-and-tested-by: Matti Hämäläinen <ccr@tnsp.org>
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2905
    Fixes: c1793ba86a41 ("drm/i915: Add ww locking to pin_to_display_plane, v2.")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-6-chris@chris-wilson.co.uk
    (cherry picked from commit 14ca83eece9565a2d2177291ceb122982dc38420)
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: <stable@vger.kernel.org> # v5.10+
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fe98e455784a6c11e0dd48612acd343f4a46fce
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Jan 25 19:36:36 2021 +0200

    drm/i915: Fix the MST PBN divider calculation
    
    commit 882554042d138dbc6fb1a43017d0b9c3b38ee5f5 upstream.
    
    Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit)
    value for MST streams if the link parameters (link rate or lane count)
    are limited in a way independent of the sink capabilities (reported by
    DPCD).
    
    One example of such a limitation is when a MUX between the sink and
    source connects only a limited number of lanes to the display and
    connects the rest of the lanes to other peripherals (USB).
    
    Another issue is that atm MST core calculates the divider based on the
    backwards compatible DPCD (at address 0x0000) vs. the extended
    capability info (at address 0x2200). This can result in leaving some
    part of the MST BW unused (For instance in case of the WD19TB dock).
    
    Fix the above two issues by calculating the PBN divider value based on
    the rate and lane count link parameters that the driver uses for all
    other computation.
    
    Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: Ville Syrjala <ville.syrjala@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Ville Syrjala <ville.syrjala@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com
    (cherry picked from commit b59c27cab257cfbff939615a87b72bce83925710)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ef4cf6abaa7772c3f75f7bbe8bef2a8f5978de7
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Jan 25 19:36:35 2021 +0200

    drm/dp/mst: Export drm_dp_get_vc_payload_bw()
    
    commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
    
    This function will be needed by the next patch where the driver
    calculates the BW based on driver specific parameters, so export it.
    
    At the same time sanitize the function params, passing the more natural
    link rate instead of the encoding of the same rate.
    
    v2:
    - Fix function documentation. (Lyude)
    
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: Ville Syrjala <ville.syrjala@intel.com>
    Cc: <stable@vger.kernel.org>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-1-imre.deak@intel.com
    (cherry picked from commit a321fc2b4e60fc1b39517d26c8104351636a6062)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f627ecde7329e476a077bb0590db8f27bb8f912
Author: Peter Gonda <pgonda@google.com>
Date:   Wed Jan 27 08:15:24 2021 -0800

    Fix unsynchronized access to sev members through svm_register_enc_region
    
    commit 19a23da53932bc8011220bd8c410cb76012de004 upstream.
    
    Grab kvm->lock before pinning memory when registering an encrypted
    region; sev_pin_memory() relies on kvm->lock being held to ensure
    correctness when checking and updating the number of pinned pages.
    
    Add a lockdep assertion to help prevent future regressions.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: x86@kernel.org
    Cc: kvm@vger.kernel.org
    Cc: stable@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active")
    Signed-off-by: Peter Gonda <pgonda@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    V2
     - Fix up patch description
     - Correct file paths svm.c -> sev.c
     - Add unlock of kvm->lock on sev_pin_memory error
    
    V1
     - https://lore.kernel.org/kvm/20210126185431.1824530-1-pgonda@google.com/
    
    Message-Id: <20210127161524.2832400-1-pgonda@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit a03a8693b1a26a3ea435fd4b9607de00c573c60b
Author: Fengnan Chang <fengnanchang@gmail.com>
Date:   Sat Jan 23 11:32:31 2021 +0800

    mmc: core: Limit retries when analyse of SDIO tuples fails
    
    commit f92e04f764b86e55e522988e6f4b6082d19a2721 upstream.
    
    When analysing tuples fails we may loop indefinitely to retry. Let's avoid
    this by using a 10s timeout and bail if not completed earlier.
    
    Signed-off-by: Fengnan Chang <fengnanchang@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210123033230.36442-1-fengnanchang@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57b452c5ab1e0b3126e14856939170d7a9bc72ef
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Jan 26 10:43:13 2021 +0100

    mmc: sdhci-pltfm: Fix linking err for sdhci-brcmstb
    
    commit d7fb9c24209556478e65211d7a1f056f2d43cceb upstream.
    
    The implementation of sdhci_pltfm_suspend() is only available when
    CONFIG_PM_SLEEP is set, which triggers a linking error:
    
    "undefined symbol: sdhci_pltfm_suspend" when building sdhci-brcmstb.c.
    
    Fix this by implementing the missing stubs when CONFIG_PM_SLEEP is unset.
    
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
    Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
    Cc: stable@vger.kernel.org
    Tested-By: Nicolas Schichan <nschichan@freeebox.fr>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2502610927ee51c11f3208c7a11a5661a7c78fa3
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Tue Feb 2 22:34:32 2021 -0600

    smb3: fix crediting for compounding when only one request in flight
    
    commit 91792bb8089b63b7b780251eb83939348ac58a64 upstream.
    
    Currently we try to guess if a compound request is going to
    succeed waiting for credits or not based on the number of
    requests in flight. This approach doesn't work correctly
    all the time because there may be only one request in
    flight which is going to bring multiple credits satisfying
    the compound request.
    
    Change the behavior to fail a request only if there are no requests
    in flight at all and proceed waiting for credits otherwise.
    
    Cc: <stable@vger.kernel.org> # 5.1+
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Reviewed-by: Tom Talpey <tom@talpey.com>
    Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b793e9fca6337841ca6ede9594f5c1c7e8ec3f1d
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Mon Feb 1 20:36:54 2021 -0600

    smb3: Fix out-of-bounds bug in SMB2_negotiate()
    
    commit 8d8d1dbefc423d42d626cf5b81aac214870ebaab upstream.
    
    While addressing some warnings generated by -Warray-bounds, I found this
    bug that was introduced back in 2017:
    
      CC [M]  fs/cifs/smb2pdu.o
    fs/cifs/smb2pdu.c: In function ‘SMB2_negotiate’:
    fs/cifs/smb2pdu.c:822:16: warning: array subscript 1 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      822 |   req->Dialects[1] = cpu_to_le16(SMB30_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    fs/cifs/smb2pdu.c:823:16: warning: array subscript 2 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      823 |   req->Dialects[2] = cpu_to_le16(SMB302_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    fs/cifs/smb2pdu.c:824:16: warning: array subscript 3 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      824 |   req->Dialects[3] = cpu_to_le16(SMB311_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    fs/cifs/smb2pdu.c:816:16: warning: array subscript 1 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      816 |   req->Dialects[1] = cpu_to_le16(SMB302_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    
    At the time, the size of array _Dialects_ was changed from 1 to 3 in struct
    validate_negotiate_info_req, and then in 2019 it was changed from 3 to 4,
    but those changes were never made in struct smb2_negotiate_req, which has
    led to a 3 and a half years old out-of-bounds bug in function
    SMB2_negotiate() (fs/cifs/smb2pdu.c).
    
    Fix this by increasing the size of array _Dialects_ in struct
    smb2_negotiate_req to 4.
    
    Fixes: 9764c02fcbad ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
    Fixes: d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2bb221a16ac90a98c4fd2a6a4e0e096cba3bd45
Author: Joerg Roedel <jroedel@suse.de>
Date:   Tue Feb 2 15:54:19 2021 +0100

    iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it
    
    commit 4c9fb5d9140802db4db9f66c23887f43174e113c upstream.
    
    The dev_iommu_priv_get() needs a similar check to
    dev_iommu_fwspec_get() to make sure no NULL-ptr is dereferenced.
    
    Fixes: 05a0542b456e1 ("iommu/amd: Store dev_data as device iommu private data")
    Cc: stable@vger.kernel.org      # v5.8+
    Link: https://lore.kernel.org/r/20210202145419.29143-1-joro@8bytes.org
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=211241
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a3361e5ecf16c072609bfae898d1e9061552ed9
Author: Aurelien Aptel <aaptel@suse.com>
Date:   Fri Feb 5 15:42:48 2021 +0100

    cifs: report error instead of invalid when revalidating a dentry fails
    
    commit 21b200d091826a83aafc95d847139b2b0582f6d1 upstream.
    
    Assuming
    - //HOST/a is mounted on /mnt
    - //HOST/b is mounted on /mnt/b
    
    On a slow connection, running 'df' and killing it while it's
    processing /mnt/b can make cifs_get_inode_info() returns -ERESTARTSYS.
    
    This triggers the following chain of events:
    => the dentry revalidation fail
    => dentry is put and released
    => superblock associated with the dentry is put
    => /mnt/b is unmounted
    
    This patch makes cifs_d_revalidate() return the error instead of 0
    (invalid) when cifs_revalidate_dentry() fails, except for ENOENT (file
    deleted) and ESTALE (file recreated).
    
    Signed-off-by: Aurelien Aptel <aaptel@suse.com>
    Suggested-by: Shyam Prasad N <nspmangalore@gmail.com>
    Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c026844c6156e9c9e7d529443e7d5b12d0aba02b
Author: Atish Patra <atish.patra@wdc.com>
Date:   Fri Jan 29 11:00:38 2021 -0800

    RISC-V: Define MAXPHYSMEM_1GB only for RV32
    
    commit de5f4b8f634beacf667e6eff334522601dd03b59 upstream.
    
    MAXPHYSMEM_1GB option was added for RV32 because RV32 only supports 1GB
    of maximum physical memory. This lead to few compilation errors reported
    by kernel test robot which created the following configuration combination
    which are not useful but can be configured.
    
    1. MAXPHYSMEM_1GB & RV64
    2, MAXPHYSMEM_2GB & RV32
    
    Fix this by restricting MAXPHYSMEM_1GB for RV32 and MAXPHYSMEM_2GB only for
    RV64.
    
    Fixes: e557793799c5 ("RISC-V: Fix maximum allowed phsyical memory for RV32")
    Cc: stable@vger.kernel.org
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    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 57ea7b257a1a764e0910dbeffcbffc30b6bfc431
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Wed Feb 3 13:37:02 2021 +0200

    xhci: fix bounce buffer usage for non-sg list case
    
    commit d4a610635400ccc382792f6be69427078541c678 upstream.
    
    xhci driver may in some special cases need to copy small amounts
    of payload data to a bounce buffer in order to meet the boundary
    and alignment restrictions set by the xHCI specification.
    
    In the majority of these cases the data is in a sg list, and
    driver incorrectly assumed data is always in urb->sg when using
    the bounce buffer.
    
    If data instead is contiguous, and in urb->transfer_buffer, we may still
    need to bounce buffer a small part if data starts very close (less than
    packet size) to a 64k boundary.
    
    Check if sg list is used before copying data to/from it.
    
    Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
    Cc: stable@vger.kernel.org
    Reported-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Tested-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210203113702.436762-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee23b9329ec261b5144259f42b1b4eee543d0cb6
Author: Rolf Eike Beer <eb@emlix.com>
Date:   Thu Nov 22 16:40:49 2018 +0100

    scripts: use pkg-config to locate libcrypto
    
    commit 2cea4a7a1885bd0c765089afc14f7ff0eb77864e upstream.
    
    Otherwise build fails if the headers are not in the default location. While at
    it also ask pkg-config for the libs, with fallback to the existing value.
    
    Signed-off-by: Rolf Eike Beer <eb@emlix.com>
    Cc: stable@vger.kernel.org # 5.6.x
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fe48a40ac63ef8e56ae998006a4a48ea1b27783
Author: Marc Zyngier <maz@kernel.org>
Date:   Sat Jan 23 12:27:59 2021 +0000

    genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set
    
    commit 4c457e8cb75eda91906a4f89fc39bde3f9a43922 upstream.
    
    When MSI_FLAG_ACTIVATE_EARLY is set (which is the case for PCI),
    __msi_domain_alloc_irqs() performs the activation of the interrupt (which
    in the case of PCI results in the endpoint being programmed) as soon as the
    interrupt is allocated.
    
    But it appears that this is only done for the first vector, introducing an
    inconsistent behaviour for PCI Multi-MSI.
    
    Fix it by iterating over the number of vectors allocated to each MSI
    descriptor. This is easily achieved by introducing a new
    "for_each_msi_vector" iterator, together with a tiny bit of refactoring.
    
    Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
    Reported-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210123122759.1781359-1-maz@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2415fde8cad25b8507d90edd5a879e732e2d247
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Dec 21 19:56:47 2020 +0100

    genirq: Prevent [devm_]irq_alloc_desc from returning irq 0
    
    commit 4c7bcb51ae25f79e3733982e5d0cd8ce8640ddfc upstream.
    
    Since commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0
    is invalid"), having a linux-irq with number 0 will trigger a WARN()
    when calling platform_get_irq*() to retrieve that linux-irq.
    
    Since [devm_]irq_alloc_desc allocs a single irq and since irq 0 is not used
    on some systems, it can return 0, triggering that WARN(). This happens
    e.g. on Intel Bay Trail and Cherry Trail devices using the LPE audio engine
    for HDMI audio:
    
     0 is an invalid IRQ number
     WARNING: CPU: 3 PID: 472 at drivers/base/platform.c:238 platform_get_irq_optional+0x108/0x180
     Modules linked in: snd_hdmi_lpe_audio(+) ...
    
     Call Trace:
      platform_get_irq+0x17/0x30
      hdmi_lpe_audio_probe+0x4a/0x6c0 [snd_hdmi_lpe_audio]
    
     ---[ end trace ceece38854223a0b ]---
    
    Change the 'from' parameter passed to __[devm_]irq_alloc_descs() by the
    [devm_]irq_alloc_desc macros from 0 to 1, so that these macros will no
    longer return 0.
    
    Fixes: a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201221185647.226146-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a80e9eee50034301f04ee55d5c53d9e487329326
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Feb 1 16:20:40 2021 -0800

    libnvdimm/dimm: Avoid race between probe and available_slots_show()
    
    commit 7018c897c2f243d4b5f1b94bc6b4831a7eab80fb upstream.
    
    Richard reports that the following test:
    
    (while true; do
         cat /sys/bus/nd/devices/nmem*/available_slots 2>&1 > /dev/null
     done) &
    
    while true; do
         for i in $(seq 0 4); do
             echo nmem$i > /sys/bus/nd/drivers/nvdimm/bind
         done
         for i in $(seq 0 4); do
             echo nmem$i > /sys/bus/nd/drivers/nvdimm/unbind
         done
     done
    
    ...fails with a crash signature like:
    
        divide error: 0000 [#1] SMP KASAN PTI
        RIP: 0010:nd_label_nfree+0x134/0x1a0 [libnvdimm]
        [..]
        Call Trace:
         available_slots_show+0x4e/0x120 [libnvdimm]
         dev_attr_show+0x42/0x80
         ? memset+0x20/0x40
         sysfs_kf_seq_show+0x218/0x410
    
    The root cause is that available_slots_show() consults driver-data, but
    fails to synchronize against device-unbind setting up a TOCTOU race to
    access uninitialized memory.
    
    Validate driver-data under the device-lock.
    
    Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure")
    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>
    Cc: Coly Li <colyli@suse.com>
    Reported-by: Richard Palethorpe <rpalethorpe@suse.com>
    Acked-by: Richard Palethorpe <rpalethorpe@suse.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2560f88e1c3c27391fde12dc2c985601c264532
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 12 23:35:50 2021 -0800

    libnvdimm/namespace: Fix visibility of namespace resource attribute
    
    commit 13f445d65955f388499f00851dc9a86280970f7c upstream.
    
    Legacy pmem namespaces lost support for the "resource" attribute when
    the code was cleaned up to put the permission visibility in the
    declaration. Restore this by listing 'resource' in the default
    attributes.
    
    A new ndctl regression test for pfn_to_online_page() corner cases builds
    on this fix.
    
    Fixes: bfd2e9140656 ("libnvdimm: Simplify root read-only definition for the 'resource' attribute")
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Ira Weiny <ira.weiny@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/161052334995.1805594.12054873528154362921.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 059e68da31b024967fd2371d42349d03f2b52df8
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Tue Feb 2 18:23:26 2021 +1100

    tracepoint: Fix race between tracing and removing tracepoint
    
    commit c8b186a8d54d7e12d28e9f9686cb00ff18fc2ab2 upstream.
    
    When executing a tracepoint, the tracepoint's func is dereferenced twice -
    in __DO_TRACE() (where the returned pointer is checked) and later on in
    __traceiter_##_name where the returned pointer is dereferenced without
    checking which leads to races against tracepoint_removal_sync() and
    crashes.
    
    This adds a check before referencing the pointer in tracepoint_ptr_deref.
    
    Link: https://lkml.kernel.org/r/20210202072326.120557-1-aik@ozlabs.ru
    
    Cc: stable@vger.kernel.org
    Fixes: d25e37d89dd2f ("tracepoint: Optimize using static_call()")
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e4a668f4f0ac136cb4a8df2c765d8d00d65774b
Author: Viktor Rosendahl <Viktor.Rosendahl@bmw.de>
Date:   Tue Jan 19 17:43:43 2021 +0100

    tracing: Use pause-on-trace with the latency tracers
    
    commit da7f84cdf02fd5f66864041f45018b328911b722 upstream.
    
    Eaerlier, tracing was disabled when reading the trace file. This behavior
    was changed with:
    
    commit 06e0a548bad0 ("tracing: Do not disable tracing when reading the
    trace file").
    
    This doesn't seem to work with the latency tracers.
    
    The above mentioned commit dit not only change the behavior but also added
    an option to emulate the old behavior. The idea with this patch is to
    enable this pause-on-trace option when the latency tracers are used.
    
    Link: https://lkml.kernel.org/r/20210119164344.37500-2-Viktor.Rosendahl@bmw.de
    
    Cc: stable@vger.kernel.org
    Fixes: 06e0a548bad0 ("tracing: Do not disable tracing when reading the trace file")
    Signed-off-by: Viktor Rosendahl <Viktor.Rosendahl@bmw.de>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ce84b8e8eb30f85a697fcd087e62936a06a7390
Author: Wang ShaoBo <bobo.shaobowang@huawei.com>
Date:   Thu Jan 28 20:44:27 2021 +0800

    kretprobe: Avoid re-registration of the same kretprobe earlier
    
    commit 0188b87899ffc4a1d36a0badbe77d56c92fd91dc upstream.
    
    Our system encountered a re-init error when re-registering same kretprobe,
    where the kretprobe_instance in rp->free_instances is illegally accessed
    after re-init.
    
    Implementation to avoid re-registration has been introduced for kprobe
    before, but lags for register_kretprobe(). We must check if kprobe has
    been re-registered before re-initializing kretprobe, otherwise it will
    destroy the data struct of kretprobe registered, which can lead to memory
    leak, system crash, also some unexpected behaviors.
    
    We use check_kprobe_rereg() to check if kprobe has been re-registered
    before running register_kretprobe()'s body, for giving a warning message
    and terminate registration process.
    
    Link: https://lkml.kernel.org/r/20210128124427.2031088-1-bobo.shaobowang@huawei.com
    
    Cc: stable@vger.kernel.org
    Fixes: 1f0ab40976460 ("kprobes: Prevent re-registration of the same kprobe")
    [ The above commit should have been done for kretprobes too ]
    Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Acked-by: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb03f14cc1483bf9d3af26229149989237074a76
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Jan 28 00:37:51 2021 +0900

    tracing/kprobe: Fix to support kretprobe events on unloaded modules
    
    commit 97c753e62e6c31a404183898d950d8c08d752dbd upstream.
    
    Fix kprobe_on_func_entry() returns error code instead of false so that
    register_kretprobe() can return an appropriate error code.
    
    append_trace_kprobe() expects the kprobe registration returns -ENOENT
    when the target symbol is not found, and it checks whether the target
    module is unloaded or not. If the target module doesn't exist, it
    defers to probe the target symbol until the module is loaded.
    
    However, since register_kretprobe() returns -EINVAL instead of -ENOENT
    in that case, it always fail on putting the kretprobe event on unloaded
    modules. e.g.
    
    Kprobe event:
    /sys/kernel/debug/tracing # echo p xfs:xfs_end_io >> kprobe_events
    [   16.515574] trace_kprobe: This probe might be able to register after target module is loaded. Continue.
    
    Kretprobe event: (p -> r)
    /sys/kernel/debug/tracing # echo r xfs:xfs_end_io >> kprobe_events
    sh: write error: Invalid argument
    /sys/kernel/debug/tracing # cat error_log
    [   41.122514] trace_kprobe: error: Failed to register probe event
      Command: r xfs:xfs_end_io
                 ^
    
    To fix this bug, change kprobe_on_func_entry() to detect symbol lookup
    failure and return -ENOENT in that case. Otherwise it returns -EINVAL
    or 0 (succeeded, given address is on the entry).
    
    Link: https://lkml.kernel.org/r/161176187132.1067016.8118042342894378981.stgit@devnote2
    
    Cc: stable@vger.kernel.org
    Fixes: 59158ec4aef7 ("tracing/kprobes: Check the probe on unloaded module correctly")
    Reported-by: Jianlin Lv <Jianlin.Lv@arm.com>
    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 43b5bdbf96444b394259851035b5b891b915b557
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Fri Jan 29 10:13:53 2021 -0500

    fgraph: Initialize tracing_graph_pause at task creation
    
    commit 7e0a9220467dbcfdc5bc62825724f3e52e50ab31 upstream.
    
    On some archs, the idle task can call into cpu_suspend(). The cpu_suspend()
    will disable or pause function graph tracing, as there's some paths in
    bringing down the CPU that can have issues with its return address being
    modified. The task_struct structure has a "tracing_graph_pause" atomic
    counter, that when set to something other than zero, the function graph
    tracer will not modify the return address.
    
    The problem is that the tracing_graph_pause counter is initialized when the
    function graph tracer is enabled. This can corrupt the counter for the idle
    task if it is suspended in these architectures.
    
       CPU 1                                CPU 2
       -----                                -----
      do_idle()
        cpu_suspend()
          pause_graph_tracing()
              task_struct->tracing_graph_pause++ (0 -> 1)
    
                                    start_graph_tracing()
                                      for_each_online_cpu(cpu) {
                                        ftrace_graph_init_idle_task(cpu)
                                          task-struct->tracing_graph_pause = 0 (1 -> 0)
    
          unpause_graph_tracing()
              task_struct->tracing_graph_pause-- (0 -> -1)
    
    The above should have gone from 1 to zero, and enabled function graph
    tracing again. But instead, it is set to -1, which keeps it disabled.
    
    There's no reason that the field tracing_graph_pause on the task_struct can
    not be initialized at boot up.
    
    Cc: stable@vger.kernel.org
    Fixes: 380c4b1411ccd ("tracing/function-graph-tracer: append the tracing_graph_flag")
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211339
    Reported-by: pierre.gondois@arm.com
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8847a756e1df06767e64717f79e19f48b6524c44
Author: Quanyang Wang <quanyang.wang@windriver.com>
Date:   Fri Jan 29 16:19:17 2021 +0800

    gpiolib: free device name on error path to fix kmemleak
    
    commit c351bb64cbe67029c68dea3adbec1b9508c6ff0f upstream.
    
    In gpiochip_add_data_with_key, we should check the return value of
    dev_set_name to ensure that device name is allocated successfully
    and then add a label on the error path to free device name to fix
    kmemleak as below:
    
    unreferenced object 0xc2d6fc40 (size 64):
      comm "kworker/0:1", pid 16, jiffies 4294937425 (age 65.120s)
      hex dump (first 32 bytes):
        67 70 69 6f 63 68 69 70 30 00 1a c0 54 63 1a c0  gpiochip0...Tc..
        0c ed 84 c0 48 ed 84 c0 3c ee 84 c0 10 00 00 00  ....H...<.......
      backtrace:
        [<962810f7>] kobject_set_name_vargs+0x2c/0xa0
        [<f50797e6>] dev_set_name+0x2c/0x5c
        [<94abbca9>] gpiochip_add_data_with_key+0xfc/0xce8
        [<5c4193e0>] omap_gpio_probe+0x33c/0x68c
        [<3402f137>] platform_probe+0x58/0xb8
        [<7421e210>] really_probe+0xec/0x3b4
        [<000f8ada>] driver_probe_device+0x58/0xb4
        [<67e0f7f7>] bus_for_each_drv+0x80/0xd0
        [<4de545dc>] __device_attach+0xe8/0x15c
        [<2e4431e7>] bus_probe_device+0x84/0x8c
        [<c18b1de9>] device_add+0x384/0x7c0
        [<5aff2995>] of_platform_device_create_pdata+0x8c/0xb8
        [<061c3483>] of_platform_bus_create+0x198/0x230
        [<5ee6d42a>] of_platform_populate+0x60/0xb8
        [<2647300f>] sysc_probe+0xd18/0x135c
        [<3402f137>] platform_probe+0x58/0xb8
    
    Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ca1ddc32b884b814c4e9fc45bc524ccd9bd168b
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Feb 1 09:33:24 2021 +0100

    mac80211: fix station rate table updates on assoc
    
    commit 18fe0fae61252b5ae6e26553e2676b5fac555951 upstream.
    
    If the driver uses .sta_add, station entries are only uploaded after the sta
    is in assoc state. Fix early station rate table updates by deferring them
    until the sta has been uploaded.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://lore.kernel.org/r/20210201083324.3134-1-nbd@nbd.name
    [use rcu_access_pointer() instead since we won't dereference here]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ccf963c6227ff1feb2db6b1bdcb5243f7f38067
Author: Sargun Dhillon <sargun@sargun.me>
Date:   Thu Jan 7 16:10:43 2021 -0800

    ovl: implement volatile-specific fsync error behaviour
    
    commit 335d3fc57941e5c6164c69d439aec1cb7a800876 upstream.
    
    Overlayfs's volatile option allows the user to bypass all forced sync calls
    to the upperdir filesystem. This comes at the cost of safety. We can never
    ensure that the user's data is intact, but we can make a best effort to
    expose whether or not the data is likely to be in a bad state.
    
    The best way to handle this in the time being is that if an overlayfs's
    upperdir experiences an error after a volatile mount occurs, that error
    will be returned on fsync, fdatasync, sync, and syncfs. This is
    contradictory to the traditional behaviour of VFS which fails the call
    once, and only raises an error if a subsequent fsync error has occurred,
    and been raised by the filesystem.
    
    One awkward aspect of the patch is that we have to manually set the
    superblock's errseq_t after the sync_fs callback as opposed to just
    returning an error from syncfs. This is because the call chain looks
    something like this:
    
    sys_syncfs ->
            sync_filesystem ->
                    __sync_filesystem ->
                            /* The return value is ignored here
                            sb->s_op->sync_fs(sb)
                            _sync_blockdev
                    /* Where the VFS fetches the error to raise to userspace */
                    errseq_check_and_advance
    
    Because of this we call errseq_set every time the sync_fs callback occurs.
    Due to the nature of this seen / unseen dichotomy, if the upperdir is an
    inconsistent state at the initial mount time, overlayfs will refuse to
    mount, as overlayfs cannot get a snapshot of the upperdir's errseq that
    will increment on error until the user calls syncfs.
    
    Signed-off-by: Sargun Dhillon <sargun@sargun.me>
    Suggested-by: Amir Goldstein <amir73il@gmail.com>
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Fixes: c86243b090bc ("ovl: provide a mount option "volatile"")
    Cc: stable@vger.kernel.org
    Reviewed-by: Vivek Goyal <vgoyal@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a66f82a1de028878bb158cfaac178f3a710ebdeb
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Jan 5 08:36:11 2021 +0800

    ovl: avoid deadlock on directory ioctl
    
    commit b854cc659dcb80f172cb35dbedc15d39d49c383f upstream.
    
    The function ovl_dir_real_file() currently uses the inode lock to serialize
    writes to the od->upperfile field.
    
    However, this function will get called by ovl_ioctl_set_flags(), which
    utilizes the inode lock too.  In this case ovl_dir_real_file() will try to
    claim a lock that is owned by a function in its call stack, which won't get
    released before ovl_dir_real_file() returns.
    
    Fix by replacing the open coded compare and exchange by an explicit atomic
    op.
    
    Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR ioctls for directories")
    Cc: stable@vger.kernel.org # v5.10
    Reported-by: Icenowy Zheng <icenowy@aosc.io>
    Tested-by: Icenowy Zheng <icenowy@aosc.io>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb8caef7c020267ad30e868a5aeaa5da6ccf0c6e
Author: Liangyan <liangyan.peng@linux.alibaba.com>
Date:   Tue Dec 22 11:06:26 2020 +0800

    ovl: fix dentry leak in ovl_get_redirect
    
    commit e04527fefba6e4e66492f122cf8cc6314f3cf3bf upstream.
    
    We need to lock d_parent->d_lock before dget_dlock, or this may
    have d_lockref updated parallelly like calltrace below which will
    cause dentry->d_lockref leak and risk a crash.
    
         CPU 0                                CPU 1
    ovl_set_redirect                       lookup_fast
      ovl_get_redirect                       __d_lookup
        dget_dlock
          //no lock protection here            spin_lock(&dentry->d_lock)
          dentry->d_lockref.count++            dentry->d_lockref.count++
    
    [   49.799059] PGD 800000061fed7067 P4D 800000061fed7067 PUD 61fec5067 PMD 0
    [   49.799689] Oops: 0002 [#1] SMP PTI
    [   49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 4.19.24-7.20.al7.x86_64 #1
    [   49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe 04/01/2014
    [   49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20
    [   49.803470] RSP: 0018:ffffac6fc5417e98 EFLAGS: 00010246
    [   49.803949] RAX: 0000000000000000 RBX: ffff93b8da3446c0 RCX: 0000000a00000000
    [   49.804600] RDX: 0000000000000001 RSI: 000000000000000a RDI: 0000000000000088
    [   49.805252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff993cf040
    [   49.805898] R10: ffff93b92292e580 R11: ffffd27f188a4b80 R12: 0000000000000000
    [   49.806548] R13: 00000000ffffff9c R14: 00000000fffffffe R15: ffff93b8da3446c0
    [   49.807200] FS:  00007ffbedffb700(0000) GS:ffff93b927880000(0000) knlGS:0000000000000000
    [   49.807935] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   49.808461] CR2: 0000000000000088 CR3: 00000005e3f74006 CR4: 00000000003606a0
    [   49.809113] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   49.809758] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   49.810410] Call Trace:
    [   49.810653]  d_delete+0x2c/0xb0
    [   49.810951]  vfs_rmdir+0xfd/0x120
    [   49.811264]  do_rmdir+0x14f/0x1a0
    [   49.811573]  do_syscall_64+0x5b/0x190
    [   49.811917]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [   49.812385] RIP: 0033:0x7ffbf505ffd7
    [   49.814404] RSP: 002b:00007ffbedffada8 EFLAGS: 00000297 ORIG_RAX: 0000000000000054
    [   49.815098] RAX: ffffffffffffffda RBX: 00007ffbedffb640 RCX: 00007ffbf505ffd7
    [   49.815744] RDX: 0000000004449700 RSI: 0000000000000000 RDI: 0000000006c8cd50
    [   49.816394] RBP: 00007ffbedffaea0 R08: 0000000000000000 R09: 0000000000017d0b
    [   49.817038] R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000012
    [   49.817687] R13: 00000000072823d8 R14: 00007ffbedffb700 R15: 00000000072823d8
    [   49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd libps2 i8042
    [   49.819052] CR2: 0000000000000088
    [   49.819368] ---[ end trace 4e652b8aa299aa2d ]---
    [   49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20
    [   49.821880] RSP: 0018:ffffac6fc5417e98 EFLAGS: 00010246
    [   49.822363] RAX: 0000000000000000 RBX: ffff93b8da3446c0 RCX: 0000000a00000000
    [   49.823008] RDX: 0000000000000001 RSI: 000000000000000a RDI: 0000000000000088
    [   49.823658] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff993cf040
    [   49.825404] R10: ffff93b92292e580 R11: ffffd27f188a4b80 R12: 0000000000000000
    [   49.827147] R13: 00000000ffffff9c R14: 00000000fffffffe R15: ffff93b8da3446c0
    [   49.828890] FS:  00007ffbedffb700(0000) GS:ffff93b927880000(0000) knlGS:0000000000000000
    [   49.830725] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   49.832359] CR2: 0000000000000088 CR3: 00000005e3f74006 CR4: 00000000003606a0
    [   49.834085] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   49.835792] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Cc: <stable@vger.kernel.org>
    Fixes: a6c606551141 ("ovl: redirect on rename-dir")
    Signed-off-by: Liangyan <liangyan.peng@linux.alibaba.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e5cb872fbbb32308ef5d71ea595ec42b8d2ac1b
Author: Mario Limonciello <mario.limonciello@dell.com>
Date:   Mon Oct 26 19:12:59 2020 +0300

    thunderbolt: Fix possible NULL pointer dereference in tb_acpi_add_link()
    
    commit 4d395c5e74398f664405819330e5a298da37f655 upstream.
    
    When we walk up the device hierarchy in tb_acpi_add_link() make sure we
    break the loop if the device has no parent. Otherwise we may crash the
    kernel by dereferencing a NULL pointer.
    
    Fixes: b2be2b05cf3b ("thunderbolt: Create device links from ACPI description")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
    Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19155473f3bac244def9f7a7ee609e7f4dbca357
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed Feb 3 16:52:39 2021 +0900

    kbuild: fix duplicated flags in DEBUG_CFLAGS
    
    [ Upstream commit 315da87c0f99a4741a639782d59dae44878199f5 ]
    
    Sedat Dilek noticed duplicated flags in DEBUG_CFLAGS when building
    deb-pkg with CONFIG_DEBUG_INFO. For example, 'make CC=clang bindeb-pkg'
    reproduces the issue.
    
    Kbuild recurses to the top Makefile for some targets such as package
    builds.
    
    With commit 121c5d08d53c ("kbuild: Only add -fno-var-tracking-assignments
    for old GCC versions") applied, DEBUG_CFLAGS is now reset only when
    CONFIG_CC_IS_GCC=y.
    
    Fix it to reset DEBUG_CFLAGS all the time.
    
    Fixes: 121c5d08d53c ("kbuild: Only add -fno-var-tracking-assignments for old GCC versions")
    Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Reviewed-by: Mark Wielaard <mark@klomp.org>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1897a8f0ef20f6710f2e7e3b4ad1d5a89f7e47d9
Author: Roman Gushchin <guro@fb.com>
Date:   Thu Feb 4 18:32:36 2021 -0800

    memblock: do not start bottom-up allocations with kernel_end
    
    [ Upstream commit 2dcb3964544177c51853a210b6ad400de78ef17d ]
    
    With kaslr the kernel image is placed at a random place, so starting the
    bottom-up allocation with the kernel_end can result in an allocation
    failure and a warning like this one:
    
      hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
      ------------[ cut here ]------------
      memblock: bottom-up allocation failed, memory hotremove may be affected
      WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x178/0x25a
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #1169
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
      RIP: 0010:memblock_find_in_range_node+0x178/0x25a
      Code: e9 6d ff ff ff 48 85 c0 0f 85 da 00 00 00 80 3d 9b 35 df 00 00 75 15 48 c7 c7 c0 75 59 88 c6 05 8b 35 df 00 01 e8 25 8a fa ff <0f> 0b 48 c7 44 24 20 ff ff ff ff 44 89 e6 44 89 ea 48 c7 c1 70 5c
      RSP: 0000:ffffffff88803d18 EFLAGS: 00010086 ORIG_RAX: 0000000000000000
      RAX: 0000000000000000 RBX: 0000000240000000 RCX: 00000000ffffdfff
      RDX: 00000000ffffdfff RSI: 00000000ffffffea RDI: 0000000000000046
      RBP: 0000000100000000 R08: ffffffff88922788 R09: 0000000000009ffb
      R10: 00000000ffffe000 R11: 3fffffffffffffff R12: 0000000000000000
      R13: 0000000000000000 R14: 0000000080000000 R15: 00000001fb42c000
      FS:  0000000000000000(0000) GS:ffffffff88f71000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffa080fb401000 CR3: 00000001fa80a000 CR4: 00000000000406b0
      Call Trace:
        memblock_alloc_range_nid+0x8d/0x11e
        cma_declare_contiguous_nid+0x2c4/0x38c
        hugetlb_cma_reserve+0xdc/0x128
        flush_tlb_one_kernel+0xc/0x20
        native_set_fixmap+0x82/0xd0
        flat_get_apic_id+0x5/0x10
        register_lapic_address+0x8e/0x97
        setup_arch+0x8a5/0xc3f
        start_kernel+0x66/0x547
        load_ucode_bsp+0x4c/0xcd
        secondary_startup_64_no_verify+0xb0/0xbb
      random: get_random_bytes called from __warn+0xab/0x110 with crng_init=0
      ---[ end trace f151227d0b39be70 ]---
    
    At the same time, the kernel image is protected with memblock_reserve(),
    so we can just start searching at PAGE_SIZE.  In this case the bottom-up
    allocation has the same chances to success as a top-down allocation, so
    there is no reason to fallback in the case of a failure.  All together it
    simplifies the logic.
    
    Link: https://lkml.kernel.org/r/20201217201214.3414100-2-guro@fb.com
    Fixes: 8fabc623238e ("powerpc: Ensure that swiotlb buffer is allocated from low memory")
    Signed-off-by: Roman Gushchin <guro@fb.com>
    Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Wonhyuk Yang <vvghjk1234@gmail.com>
    Cc: Thiago Jung Bauermann <bauerman@linux.ibm.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 346ea7cc27b71a923cdd365642824b3ac4f11081
Author: Eli Cohen <elic@nvidia.com>
Date:   Thu Feb 4 09:36:18 2021 +0200

    vdpa/mlx5: Restore the hardware used index after change map
    
    [ Upstream commit b35ccebe3ef76168aa2edaa35809c0232cb3578e ]
    
    When a change of memory map occurs, the hardware resources are destroyed
    and then re-created again with the new memory map. In such case, we need
    to restore the hardware available and used indices. The driver failed to
    restore the used index which is added here.
    
    Also, since the driver also fails to reset the available and used
    indices upon device reset, fix this here to avoid regression caused by
    the fact that used index may not be zero upon device reset.
    
    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/20210204073618.36336-1-elic@nvidia.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1debbaf158d674f64ce75e98266d01731e97c21
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Wed Feb 3 01:20:25 2021 -0800

    nvmet-tcp: fix out-of-bounds access when receiving multiple h2cdata PDUs
    
    [ Upstream commit cb8563f5c735a042ea2dd7df1ad55ae06d63ffeb ]
    
    When the host sends multiple h2cdata PDUs, we keep track on
    the receive progress and calculate the scatterlist index and
    offsets.
    
    The issue is that sg_offset should only be kept for the first
    iov entry we map in the iovec as this is the difference between
    our cursor and the sg entry offset itself.
    
    In addition, the sg index was calculated wrong because we should
    not round up when dividing the command byte offset with PAG_SIZE.
    
    Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
    Reported-by: Narayan Ayalasomayajula <Narayan.Ayalasomayajula@wdc.com>
    Tested-by: Narayan Ayalasomayajula <Narayan.Ayalasomayajula@wdc.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9464c5f4663442bdf5f53550eaf30fe0f28b517
Author: Hermann Lauer <Hermann.Lauer@uni-heidelberg.de>
Date:   Thu Jan 28 12:18:42 2021 +0100

    ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode
    
    [ Upstream commit a900cac3750b9f0b8f5ed0503d9c6359532f644d ]
    
    BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high
    packet loss rates. The realtek phy driver overrides the settings of the
    pull ups for the delays, so fix this for BananaPro.
    
    Fix the phy-mode description to correctly reflect this so that the
    implementation doesn't reconfigure the delays incorrectly. This
    happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
    rx/tx delay config").
    
    Fixes: 10662a33dcd9 ("ARM: dts: sun7i: Add dts file for Bananapro board")
    Signed-off-by: Hermann Lauer <Hermann.Lauer@uni-heidelberg.de>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20210128111842.GA11919@lemon.iwr.uni-heidelberg.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38b83bcec904fb599e7f79a508042c8cf96090d0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 2 08:55:25 2021 +0300

    net: ipa: pass correct dma_handle to dma_free_coherent()
    
    [ Upstream commit 4ace7a6e287b7e3b33276cd9fe870c326f880480 ]
    
    The "ring->addr = addr;" assignment is done a few lines later so we
    can't use "ring->addr" yet.  The correct dma_handle is "addr".
    
    Fixes: 650d1603825d ("soc: qcom: ipa: the generic software interface")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Link: https://lore.kernel.org/r/YBjpTU2oejkNIULT@mwanda
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 714c19bc13151962775c610b6ee507c455189d88
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Feb 1 21:50:56 2021 +0100

    r8169: fix WoL on shutdown if CONFIG_DEBUG_SHIRQ is set
    
    [ Upstream commit cc9f07a838c4988ed244d0907cb71d54b85482a5 ]
    
    So far phy_disconnect() is called before free_irq(). If CONFIG_DEBUG_SHIRQ
    is set and interrupt is shared, then free_irq() creates an "artificial"
    interrupt by calling the interrupt handler. The "link change" flag is set
    in the interrupt status register, causing phylib to eventually call
    phy_suspend(). Because the net_device is detached from the PHY already,
    the PHY driver can't recognize that WoL is configured and powers down the
    PHY.
    
    Fixes: f1e911d5d0df ("r8169: add basic phylib support")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/fe732c2c-a473-9088-3974-df83cfbd6efd@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 397ae1a245024bc68e371e9d40deea9f51451759
Author: Stefan Chulski <stefanc@marvell.com>
Date:   Mon Feb 1 11:35:39 2021 +0200

    net: mvpp2: TCAM entry enable should be written after SRAM data
    
    [ Upstream commit 43f4a20a1266d393840ce010f547486d14cc0071 ]
    
    Last TCAM data contains TCAM enable bit.
    It should be written after SRAM data before entry enabled.
    
    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Signed-off-by: Stefan Chulski <stefanc@marvell.com>
    Link: https://lore.kernel.org/r/1612172139-28343-1-git-send-email-stefanc@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dec629e972611bd267fbd3a72cb72d1163bf576b
Author: Xie He <xie.he.0141@gmail.com>
Date:   Sun Jan 31 21:57:06 2021 -0800

    net: lapb: Copy the skb before sending a packet
    
    [ Upstream commit 88c7a9fd9bdd3e453f04018920964c6f848a591a ]
    
    When sending a packet, we will prepend it with an LAPB header.
    This modifies the shared parts of a cloned skb, so we should copy the
    skb rather than just clone it, before we prepend the header.
    
    In "Documentation/networking/driver.rst" (the 2nd point), it states
    that drivers shouldn't modify the shared parts of a cloned skb when
    transmitting.
    
    The "dev_queue_xmit_nit" function in "net/core/dev.c", which is called
    when an skb is being sent, clones the skb and sents the clone to
    AF_PACKET sockets. Because the LAPB drivers first remove a 1-byte
    pseudo-header before handing over the skb to us, if we don't copy the
    skb before prepending the LAPB header, the first byte of the packets
    received on AF_PACKET sockets can be corrupted.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xie He <xie.he.0141@gmail.com>
    Acked-by: Martin Schiller <ms@dev.tdt.de>
    Link: https://lore.kernel.org/r/20210201055706.415842-1-xie.he.0141@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a5c3bac805461acaf3cf33fcaa695377155b603
Author: Maor Dickman <maord@nvidia.com>
Date:   Sun Jan 31 18:47:15 2021 +0200

    net/mlx5e: Release skb in case of failure in tc update skb
    
    [ Upstream commit a34ffec8af8ff1c730697a99e09ec7b74a3423b6 ]
    
    In case of failure in tc update skb the packet is dropped
    without freeing the skb.
    
    Fixed by freeing the skb in case failure in tc update skb.
    
    Fixes: d6d27782864f ("net/mlx5: E-Switch, Restore chain id on miss")
    Fixes: c75690972228 ("net/mlx5e: Add tc chains offload support for nic flows")
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2b2c4d24b40f5981a345fdd40691154ac5b33ac
Author: Maxim Mikityanskiy <maximmi@mellanox.com>
Date:   Thu Jan 28 14:37:59 2021 +0200

    net/mlx5e: Update max_opened_tc also when channels are closed
    
    [ Upstream commit 5a2ba25a55c4dc0f143567c99aede768b6628ebd ]
    
    max_opened_tc is used for stats, so that potentially non-zero stats
    won't disappear when num_tc decreases. However, mlx5e_setup_tc_mqprio
    fails to update it in the flow where channels are closed.
    
    This commit fixes it. The new value of priv->channels.params.num_tc is
    always checked on exit. In case of errors it will just be the old value,
    and in case of success it will be the updated value.
    
    Fixes: 05909babce53 ("net/mlx5e: Avoid reset netdev stats on configuration changes")
    Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11c2c8fb889d6ee61f268810175818d05ae0323b
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Wed Jan 20 17:41:18 2021 +0200

    net/mlx5: Fix leak upon failure of rule creation
    
    [ Upstream commit a5bfe6b4675e0eefbd9418055b5cc6e89af27eb4 ]
    
    When creation of a new rule that requires allocation of an FTE fails,
    need to call to tree_put_node on the FTE in order to release its'
    resource.
    
    Fixes: cefc23554fc2 ("net/mlx5: Fix FTE cleanup")
    Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
    Reviewed-by: Alaa Hleihel <alaa@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ada342012b2d703d3e409103f11f817b47ab56e5
Author: Daniel Jurgens <danielj@nvidia.com>
Date:   Mon Feb 1 18:11:10 2021 +0200

    net/mlx5: Fix function calculation for page trees
    
    [ Upstream commit ed5e83a3c02948dad9dc4e68fb4e535baa5da630 ]
    
    The function calculation always results in a value of 0. This works
    generally, but when the release all pages feature is enabled it will
    result in crashes.
    
    Fixes: 0aa128475d33 ("net/mlx5: Maintain separate page trees for ECPF and PF functions")
    Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5802b747596d22fe438055ba4e249b1f08b5703
Author: Lijun Pan <ljp@linux.ibm.com>
Date:   Thu Jan 28 22:34:01 2021 -0600

    ibmvnic: device remove has higher precedence over reset
    
    [ Upstream commit 5e9eff5dfa460cd1a74b7c1fde4fced7c04383af ]
    
    Returning -EBUSY in ibmvnic_remove() does not actually hold the
    removal procedure since driver core doesn't care for the return
    value (see __device_release_driver() in drivers/base/dd.c
    calling dev->bus->remove()) though vio_bus_remove
    (in arch/powerpc/platforms/pseries/vio.c) records the
    return value and passes it on. [1]
    
    During the device removal precedure, checking for resetting
    bit is dropped so that we can continue executing all the
    cleanup calls in the rest of the remove function. Otherwise,
    it can cause latent memory leaks and kernel crashes.
    
    [1] https://lore.kernel.org/linuxppc-dev/20210117101242.dpwayq6wdgfdzirl@pengutronix.de/T/#m48f5befd96bc9842ece2a3ad14f4c27747206a53
    Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device reset")
    Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210129043402.95744-1-ljp@linux.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd77dccc122fb4a45682a26c14964cb7e34b9ebf
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Sat Jan 23 00:22:23 2021 +0000

    i40e: Revert "i40e: don't report link up for a VF who hasn't enabled queues"
    
    [ Upstream commit f559a356043a55bab25a4c00505ea65c50a956fb ]
    
    This reverts commit 2ad1274fa35ace5c6360762ba48d33b63da2396c
    
    VF queues were not brought up when PF was brought up after being
    downed if the VF driver disabled VFs queues during PF down.
    This could happen in some older or external VF driver implementations.
    The problem was that PF driver used vf->queues_enabled as a condition
    to decide what link-state it would send out which caused the issue.
    
    Remove the check for vf->queues_enabled in the VF link notify.
    Now VF will always be notified of the current link status.
    Also remove the queues_enabled member from i40e_vf structure as it is
    not used anymore. Otherwise VNF implementation was broken and caused
    a link flap.
    
    The original commit was a workaround to avoid breaking existing VFs though
    it's really a fault of the VF code not the PF. The commit should be safe to
    revert as all of the VFs we know of have been fixed. Also, since we now
    know there is a related bug in the workaround, removing it is preferred.
    
    Fixes: 2ad1274fa35a ("i40e: don't report link up for a VF who hasn't enabled")
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ac8bec2205efbcef59ec989e9a9a4e57428a64e
Author: Kevin Lo <kevlo@kevlo.org>
Date:   Thu Jan 7 14:10:38 2021 +0800

    igc: check return value of ret_val in igc_config_fc_after_link_up
    
    [ Upstream commit b881145642ce0bbe2be521e0882e72a5cebe93b8 ]
    
    Check return value from ret_val to make error check actually work.
    
    Fixes: 4eb8080143a9 ("igc: Add setup link functionality")
    Signed-off-by: Kevin Lo <kevlo@kevlo.org>
    Acked-by: Sasha Neftin <sasha.neftin@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cda160418583c066a17a2881babd3522c08e859
Author: Kevin Lo <kevlo@kevlo.org>
Date:   Sun Dec 20 22:18:19 2020 +0800

    igc: set the default return value to -IGC_ERR_NVM in igc_write_nvm_srwr
    
    [ Upstream commit ebc8d125062e7dccb7922b2190b097c20d88ad96 ]
    
    This patch sets the default return value to -IGC_ERR_NVM in
    igc_write_nvm_srwr. Without this change it wouldn't lead to a shadow RAM
    write EEWR timeout.
    
    Fixes: ab4056126813 ("igc: Add NVM support")
    Signed-off-by: Kevin Lo <kevlo@kevlo.org>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e081627f3a7f733a4955ee40b385c972f010f05
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Sun Jan 31 16:16:23 2021 -0500

    SUNRPC: Fix NFS READs that start at non-page-aligned offsets
    
    [ Upstream commit bad4c6eb5eaa8300e065bd4426727db5141d687d ]
    
    Anj Duvnjak reports that the Kodi.tv NFS client is not able to read
    video files from a v5.10.11 Linux NFS server.
    
    The new sendpage-based TCP sendto logic was not attentive to non-
    zero page_base values. nfsd_splice_read() sets that field when a
    READ payload starts in the middle of a page.
    
    The Linux NFS client rarely emits an NFS READ that is not page-
    aligned. All of my testing so far has been with Linux clients, so I
    missed this one.
    
    Reported-by: A. Duvnjak <avian@extremenerds.net>
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211471
    Fixes: 4a85a6a3320b ("SUNRPC: Handle TCP socket sends with kernel_sendpage() again")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: A. Duvnjak <avian@extremenerds.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ceca8baed5d815c61c768e5b336a739fe77deeb7
Author: Zyta Szpak <zr@semihalf.com>
Date:   Thu Jan 21 16:52:37 2021 +0100

    arm64: dts: ls1046a: fix dcfg address range
    
    [ Upstream commit aa880c6f3ee6dbd0d5ab02026a514ff8ea0a3328 ]
    
    Dcfg was overlapping with clockgen address space which resulted
    in failure in memory allocation for dcfg. According regs description
    dcfg size should not be bigger than 4KB.
    
    Signed-off-by: Zyta Szpak <zr@semihalf.com>
    Fixes: 8126d88162a5 ("arm64: dts: add QorIQ LS1046A SoC support")
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5ed4e08d8507dfc616f1ffb1b771f88b3c819cb
Author: David Howells <dhowells@redhat.com>
Date:   Fri Jan 29 23:53:50 2021 +0000

    rxrpc: Fix deadlock around release of dst cached on udp tunnel
    
    [ Upstream commit 5399d52233c47905bbf97dcbaa2d7a9cc31670ba ]
    
    AF_RXRPC sockets use UDP ports in encap mode.  This causes socket and dst
    from an incoming packet to get stolen and attached to the UDP socket from
    whence it is leaked when that socket is closed.
    
    When a network namespace is removed, the wait for dst records to be cleaned
    up happens before the cleanup of the rxrpc and UDP socket, meaning that the
    wait never finishes.
    
    Fix this by moving the rxrpc (and, by dependence, the afs) private
    per-network namespace registrations to the device group rather than subsys
    group.  This allows cached rxrpc local endpoints to be cleared and their
    UDP sockets closed before we try waiting for the dst records.
    
    The symptom is that lines looking like the following:
    
            unregister_netdevice: waiting for lo to become free
    
    get emitted at regular intervals after running something like the
    referenced syzbot test.
    
    Thanks to Vadim for tracking this down and work out the fix.
    
    Reported-by: syzbot+df400f2f24a1677cd7e0@syzkaller.appspotmail.com
    Reported-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Link: https://lore.kernel.org/r/161196443016.3868642.5577440140646403533.stgit@warthog.procyon.org.uk
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fc1a5a50e6ea218e54e57f76fca493c88a312ab
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Thu Jan 28 23:01:54 2021 +0100

    r8169: work around RTL8125 UDP hw bug
    
    [ Upstream commit 8d520b4de3edca4f4fb242b5ddc659b6a9b9e65e ]
    
    It was reported that on RTL8125 network breaks under heavy UDP load,
    e.g. torrent traffic ([0], from comment 27). Realtek confirmed a hw bug
    and provided me with a test version of the r8125 driver including a
    workaround. Tests confirmed that the workaround fixes the issue.
    I modified the original version of the workaround to meet mainline
    code style.
    
    [0] https://bugzilla.kernel.org/show_bug.cgi?id=209839
    
    v2:
    - rebased to net
    v3:
    - make rtl_skb_is_udp() more robust and use skb_header_pointer()
      to access the ip(v6) header
    v4:
    - remove dependency on ptp_classify.h
    - replace magic number with offsetof(struct udphdr, len)
    
    Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
    Tested-by: xplo <xplo.bn@gmail.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/6e453d49-1801-e6de-d5f7-d7e6c7526c8f@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee1709a311cd0a1d21e53724c38db78eb5cffe6e
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Fri Jan 22 06:52:18 2021 +0100

    arm64: dts: meson: switch TFLASH_VDD_EN pin to open drain on Odroid-C4
    
    [ Upstream commit daf12bee07b9e2f38216f58aca7ac4e4e66a7146 ]
    
    For the proper reboot Odroid-C4 board requires to switch TFLASH_VDD_EN
    pin to the high impedance mode, otherwise the board is stuck in the
    middle of loading early stages of the bootloader from SD card.
    
    This can be achieved by using the OPEN_DRAIN flag instead of the
    ACTIVE_HIGH, what will leave the pin in input mode to achieve high state
    (pin has the pull-up) and solve the issue.
    
    Suggested-by: Neil Armstrong <narmstrong@baylibre.com>
    Fixes: 326e57518b0d ("arm64: dts: meson-sm1: add support for Hardkernel ODROID-C4")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/20210122055218.27241-1-m.szyprowski@samsung.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f5ee57a68c7d38a9f692a8ba99fc23dbbf1840a
Author: Quentin Monnet <quentin@isovalent.com>
Date:   Tue Jan 26 16:13:20 2021 +0000

    bpf, preload: Fix build when $(O) points to a relative path
    
    [ Upstream commit 150a27328b681425c8cab239894a48f2aeb870e9 ]
    
    Building the kernel with CONFIG_BPF_PRELOAD, and by providing a relative
    path for the output directory, may fail with the following error:
    
      $ make O=build bindeb-pkg
      ...
      /.../linux/tools/scripts/Makefile.include:5: *** O=build does not exist.  Stop.
      make[7]: *** [/.../linux/kernel/bpf/preload/Makefile:9: kernel/bpf/preload/libbpf.a] Error 2
      make[6]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf/preload] Error 2
      make[5]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf] Error 2
      make[4]: *** [/.../linux/Makefile:1799: kernel] Error 2
      make[4]: *** Waiting for unfinished jobs....
    
    In the case above, for the "bindeb-pkg" target, the error is produced by
    the "dummy" check in Makefile.include, called from libbpf's Makefile.
    This check changes directory to $(PWD) before checking for the existence
    of $(O). But at this step we have $(PWD) pointing to "/.../linux/build",
    and $(O) pointing to "build". So the Makefile.include tries in fact to
    assert the existence of a directory named "/.../linux/build/build",
    which does not exist.
    
    Note that the error does not occur for all make targets and
    architectures combinations. This was observed on x86 for "bindeb-pkg",
    or for a regular build for UML [0].
    
    Here are some details. The root Makefile recursively calls itself once,
    after changing directory to $(O). The content for the variable $(PWD) is
    preserved across recursive calls to make, so it is unchanged at this
    step. For "bindeb-pkg", $(PWD) is eventually updated because the target
    writes a new Makefile (as debian/rules) and calls it indirectly through
    dpkg-buildpackage. This script does not preserve $(PWD), which is reset
    to the current working directory when the target in debian/rules is
    called.
    
    Although not investigated, it seems likely that something similar causes
    UML to change its value for $(PWD).
    
    Non-trivial fixes could be to remove the use of $(PWD) from the "dummy"
    check, or to make sure that $(PWD) and $(O) are preserved or updated to
    always play well and form a valid $(PWD)/$(O) path across the different
    targets and architectures. Instead, we take a simpler approach and just
    update $(O) when calling libbpf's Makefile, so it points to an absolute
    path which should always resolve for the "dummy" check run (through
    includes) by that Makefile.
    
    David Gow previously posted a slightly different version of this patch
    as a RFC [0], two months ago or so.
    
      [0] https://lore.kernel.org/bpf/20201119085022.3606135-1-davidgow@google.com/t/#u
    
    Fixes: d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
    Reported-by: David Gow <davidgow@google.com>
    Signed-off-by: Quentin Monnet <quentin@isovalent.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Cc: Brendan Higgins <brendanhiggins@google.com>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Link: https://lore.kernel.org/bpf/20210126161320.24561-1-quentin@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72c8389fc7ff0a931383f56a9a1148e629f42ade
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jan 7 22:15:21 2021 +0100

    um: virtio: free vu_dev only with the contained struct device
    
    [ Upstream commit f4172b084342fd3f9e38c10650ffe19eac30d8ce ]
    
    Since struct device is refcounted, we shouldn't free the vu_dev
    immediately when it's removed from the platform device, but only
    when the references actually all go away. Move the freeing to
    the release to accomplish that.
    
    Fixes: 5d38f324993f ("um: drivers: Add virtio vhost-user driver")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 571fe1ba22c26ceedecec067ffe32235b8710b60
Author: Pan Bian <bianpan2016@163.com>
Date:   Wed Jan 20 18:08:56 2021 -0800

    bpf, inode_storage: Put file handler if no storage was found
    
    [ Upstream commit b9557caaf872271671bdc1ef003d72f421eb72f6 ]
    
    Put file f if inode_storage_ptr() returns NULL.
    
    Fixes: 8ea636848aca ("bpf: Implement bpf_local_storage for inodes")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: KP Singh <kpsingh@kernel.org>
    Link: https://lore.kernel.org/bpf/20210121020856.25507-1-bianpan2016@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9447d0f8a621be34ba1507b15aa20057c00ae7fc
Author: Loris Reiff <loris.reiff@liblor.ch>
Date:   Fri Jan 22 17:42:32 2021 +0100

    bpf, cgroup: Fix problematic bounds check
    
    [ Upstream commit f4a2da755a7e1f5d845c52aee71336cee289935a ]
    
    Since ctx.optlen is signed, a larger value than max_value could be
    passed, as it is later on used as unsigned, which causes a WARN_ON_ONCE
    in the copy_to_user.
    
    Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
    Signed-off-by: Loris Reiff <loris.reiff@liblor.ch>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/bpf/20210122164232.61770-2-loris.reiff@liblor.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee3844e61706dc7a349b5380c1dff7b8d7153cad
Author: Loris Reiff <loris.reiff@liblor.ch>
Date:   Fri Jan 22 17:42:31 2021 +0100

    bpf, cgroup: Fix optlen WARN_ON_ONCE toctou
    
    [ Upstream commit bb8b81e396f7afbe7c50d789e2107512274d2a35 ]
    
    A toctou issue in `__cgroup_bpf_run_filter_getsockopt` can trigger a
    WARN_ON_ONCE in a check of `copy_from_user`.
    
    `*optlen` is checked to be non-negative in the individual getsockopt
    functions beforehand. Changing `*optlen` in a race to a negative value
    will result in a `copy_from_user(ctx.optval, optval, ctx.optlen)` with
    `ctx.optlen` being a negative integer.
    
    Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
    Signed-off-by: Loris Reiff <loris.reiff@liblor.ch>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/bpf/20210122164232.61770-1-loris.reiff@liblor.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28ad17a5e93635e8e538eb9df094ee177691183a
Author: Eli Cohen <elic@nvidia.com>
Date:   Thu Jan 7 09:18:45 2021 +0200

    vdpa/mlx5: Fix memory key MTT population
    
    [ Upstream commit 710eb8e32d04714452759f2b66884bfa7e97d495 ]
    
    map_direct_mr() assumed that the number of scatter/gather entries
    returned by dma_map_sg_attrs() was equal to the number of segments in
    the sgl list. This led to wrong population of the mkey object. Fix this
    by properly referring to the returned value.
    
    The hardware expects each MTT entry to contain the DMA address of a
    contiguous block of memory of size (1 << mr->log_size) bytes.
    dma_map_sg_attrs() can coalesce several sg entries into a single
    scatter/gather entry of contiguous DMA range so we need to scan the list
    and refer to the size of each s/g entry.
    
    In addition, get rid of fill_sg() which effect is overwritten by
    populate_mtts().
    
    Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code")
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Link: https://lore.kernel.org/r/20210107071845.GA224876@mtl-vdi-166.wap.labs.mlnx
    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 636ef657eedfac886924a21d1b7bdb7911a1c85d
Author: Marek Vasut <marex@denx.de>
Date:   Tue Dec 29 18:55:21 2020 +0100

    ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02
    
    [ Upstream commit 83d411224025ac1baab981e3d2f5d29e7761541d ]
    
    The GPIO hog flags are ignored by gpiolib-of.c now, set the flags to 0.
    Since GPIO_ACTIVE_HIGH is defined as 0, this change only increases the
    correctness of the DT.
    
    Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Patrice Chotard <patrice.chotard@st.com>
    Cc: Patrick Delaunay <patrick.delaunay@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ec543da64e1b665d52e5710e2ee2e589fd53304
Author: Marek Vasut <marex@denx.de>
Date:   Thu Jan 7 16:07:42 2021 +0100

    ARM: dts: stm32: Disable optional TSC2004 on DRC02 board
    
    [ Upstream commit 087698939f30d489e785d7df3e6aa5dce2487b39 ]
    
    The DRC02 has no use for the on-SoM touchscreen controller, and the
    on-SoM touchscreen controller may not even be populated, which then
    results in error messages in kernel log. Disable the touchscreen
    controller in DT.
    
    Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Patrice Chotard <patrice.chotard@st.com>
    Cc: Patrick Delaunay <patrick.delaunay@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43019f6f888491d8997329aae2def774d8c4b8cc
Author: Marek Vasut <marex@denx.de>
Date:   Tue Dec 1 12:13:31 2020 +0100

    ARM: dts: stm32: Disable WP on DHCOM uSD slot
    
    [ Upstream commit 063a60634d48ee89f697371c9850c9370e494f22 ]
    
    The uSD slot has no WP detection, disable it.
    
    Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Patrice Chotard <patrice.chotard@st.com>
    Cc: Patrick Delaunay <patrick.delaunay@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7a74822c6eb427803dee3304535d2e77a321ae3
Author: Marek Vasut <marex@denx.de>
Date:   Tue Dec 1 12:13:30 2020 +0100

    ARM: dts: stm32: Connect card-detect signal on DHCOM
    
    [ Upstream commit 1a9b001237f85d3cf11a408c2daca6a2245b2add ]
    
    The DHCOM SoM uSD slot card detect signal is connected to GPIO PG1,
    describe it in the DT.
    
    Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Patrice Chotard <patrice.chotard@st.com>
    Cc: Patrick Delaunay <patrick.delaunay@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29aebc79169c05b1c7cbae322c60c7297c5d6007
Author: Marek Vasut <marex@denx.de>
Date:   Tue Dec 1 12:13:29 2020 +0100

    ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detect
    
    [ Upstream commit a0572c0734e4926ac51a31f97c12f752e1cdc7c8 ]
    
    The uSD card detect signal on the DH DRC02 is active-high, with
    a default pull down resistor on the board. Invert the polarity.
    
    Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Patrice Chotard <patrice.chotard@st.com>
    Cc: Patrick Delaunay <patrick.delaunay@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    To: linux-arm-kernel@lists.infradead.org
    --
    Note that this could not be tested on prototype SoMs, now that it is
    tested, this issue surfaced, so it needs to be fixed.
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25af99f88d3ee6849fbabe019176fd8c25e97140
Author: Simon South <simon@simonsouth.net>
Date:   Wed Sep 30 14:56:27 2020 -0400

    arm64: dts: rockchip: Use only supported PCIe link speed on Pinebook Pro
    
    [ Upstream commit 642fb2795290c4abe629ca34fb8ff6d78baa9fd3 ]
    
    On Pinebook Pro laptops with an NVMe SSD installed, prevent random
    crashes in the NVMe driver by not attempting to use a PCIe link speed
    higher than that supported by the RK3399 SoC.
    
    See commit 712fa1777207 ("arm64: dts: rockchip: add max-link-speed for
    rk3399").
    
    Fixes: 5a65505a6988 ("arm64: dts: rockchip: Add initial support for Pinebook Pro")
    Signed-off-by: Simon South <simon@simonsouth.net>
    Link: https://lore.kernel.org/r/20200930185627.5918-1-simon@simonsouth.net
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2947904fbbaea4645d5c680c6aa319384233c03
Author: Sandy Huang <hjc@rock-chips.com>
Date:   Fri Jan 8 12:06:27 2021 +0100

    arm64: dts: rockchip: fix vopl iommu irq on px30
    
    [ Upstream commit 656c648354e1561fa4f445b0b3252ec1d24e3951 ]
    
    The vop-mmu shares the irq with its matched vop but not the vpu.
    
    Fixes: 7053e06b1422 ("arm64: dts: rockchip: add core dtsi file for PX30 SoCs")
    Signed-off-by: Sandy Huang <hjc@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
    Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Link: https://lore.kernel.org/r/20210108110627.3231226-1-heiko@sntech.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b1996ae3a274c9dedf4923fad60dba29536aea8
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Thu Dec 10 12:17:47 2020 +0300

    arm64: dts: amlogic: meson-g12: Set FL-adj property value
    
    [ Upstream commit 7386a559caa6414e74578172c2bc4e636d6bd0a0 ]
    
    In accordance with the DWC USB3 bindings the property is supposed to have
    uint32 type. It's erroneous from the DT schema and driver points of view
    to declare it as boolean. As Neil suggested set it to 0x20 so not break
    the platform and to make the dtbs checker happy.
    
    Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-Sergey.Semin@baikalelectronics.ru/
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Fixes: 9baf7d6be730 ("arm64: dts: meson: g12a: Add G12A USB nodes")
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/20201210091756.18057-3-Sergey.Semin@baikalelectronics.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fcaf04963e2f370d1d5934c737dbadcf3fcccc0
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sun Jan 3 17:59:51 2021 -0800

    Input: i8042 - unbreak Pegatron C15B
    
    [ Upstream commit a3a9060ecad030e2c7903b2b258383d2c716b56c ]
    
    g++ reports
    
            drivers/input/serio/i8042-x86ia64io.h:225:3: error: ‘.matches’ designator used multiple times in the same initializer list
    
    C99 semantics is that last duplicated initialiser wins,
    so DMI entry gets overwritten.
    
    Fixes: a48491c65b51 ("Input: i8042 - add ByteSpeed touchpad to noloop table")
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Link: https://lore.kernel.org/r/20201228072335.GA27766@localhost.localdomain
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd508a509c2ac47b9bfe5ad8719fafa8576e56a6
Author: Shawn Guo <shawn.guo@linaro.org>
Date:   Sat Jan 2 12:59:40 2021 +0800

    arm64: dts: qcom: c630: keep both touchpad devices enabled
    
    [ Upstream commit a9164910c5ceed63551280a4a0b85d37ac2b19a5 ]
    
    Indicated by AML code in ACPI table, the touchpad in-use could be found
    on two possible slave addresses on &i2c3, i.e. hid@15 and hid@2c.  And
    which one is in-use can be determined by reading another address on the
    I2C bus.  Unfortunately, for DT boot, there is currently no support in
    firmware to make this check and patch DT accordingly.  This results in
    a non-functional touchpad on those C630 devices with hid@2c.
    
    As i2c-hid driver will stop probing the device if there is nothing on
    the slave address, we can actually keep both devices enabled in DT, and
    i2c-hid driver will only probe the existing one.  The only problem is
    that we cannot set up pinctrl in both device nodes, as two devices with
    the same pinctrl will cause pin conflict that makes the second device
    fail to probe.  Let's move the pinctrl state up to parent node to solve
    this problem.  As the pinctrl state of parent node is already defined in
    sdm845.dtsi, it ends up with overwriting pinctrl-0 with i2c3_hid_active
    state added in there.
    
    Fixes: 11d0e4f28156 ("arm64: dts: qcom: c630: Polish i2c-hid devices")
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Link: https://lore.kernel.org/r/20210102045940.26874-1-shawn.guo@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bcb395a7f67e9408fd57e487bb016afcdef531d
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Mon Dec 14 23:01:21 2020 +0200

    ARM: OMAP1: OSK: fix ohci-omap breakage
    
    [ Upstream commit 6efac0173cd15460b48c91e1b0a000379f341f00 ]
    
    Commit 45c5775460f3 ("usb: ohci-omap: Fix descriptor conversion") tried to
    fix all issues related to ohci-omap descriptor conversion, but a wrong
    patch was applied, and one needed change to the OSK board file is still
    missing. Fix that.
    
    Fixes: 45c5775460f3 ("usb: ohci-omap: Fix descriptor conversion")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [aaro.koskinen@iki.fi: rebased and updated the changelog]
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f808da6bc6e4569987db4c124da5cf92b956c619
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Tue Feb 2 16:38:24 2021 +0800

    usb: xhci-mtk: break loop when find the endpoint to drop
    
    commit a50ea34d6dd00a12c9cd29cf7b0fa72816bffbcb upstream.
    
    No need to check the following endpoints after finding the endpoint
    wanted to drop.
    
    Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: Ikjoon Jang <ikjn@chromium.org>
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/1612255104-5363-1-git-send-email-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85f0409e9ce3ea2d2f526353e8645e1406f72950
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Mon Feb 1 13:57:44 2021 +0800

    usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints
    
    commit 54f6a8af372213a254af6609758d99f7c0b6b5ad upstream.
    
    For those unchecked endpoints, we don't allocate bandwidth for
    them, so no need free the bandwidth, otherwise will decrease
    the allocated bandwidth.
    Meanwhile use xhci_dbg() instead of dev_dbg() to print logs and
    rename bw_ep_list_new as bw_ep_chk_list.
    
    Fixes: 1d69f9d901ef ("usb: xhci-mtk: fix unreleased bandwidth data")
    Cc: stable <stable@vger.kernel.org>
    Reviewed-and-tested-by: Ikjoon Jang <ikjn@chromium.org>
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/1612159064-28413-1-git-send-email-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5139bf6a3455c0a9ddaf1c8cb20a50a649ecac55
Author: Ikjoon Jang <ikjn@chromium.org>
Date:   Wed Jan 13 18:05:11 2021 +0800

    usb: xhci-mtk: fix unreleased bandwidth data
    
    commit 1d69f9d901ef14d81c3b004e3282b8cc7b456280 upstream.
    
    xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and
    drop_endpoint() to handle its own sw bandwidth management.
    
    It stores bandwidth data into an internal table every time
    add_endpoint() is called, and drops those in drop_endpoint().
    But when bandwidth allocation fails at one endpoint, all earlier
    allocation from the same interface could still remain at the table.
    
    This patch moves bandwidth management codes to check_bandwidth() and
    reset_bandwidth() path. To do so, this patch also adds those functions
    to xhci_driver_overrides and lets mtk-xhci to release all failed
    endpoints in reset_bandwidth() path.
    
    Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT")
    Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
    Link: https://lore.kernel.org/r/20210113180444.v6.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6609c0a537b3fe15a098534675fd7bdfadf553b
Author: Gary Bisson <gary.bisson@boundarydevices.com>
Date:   Mon Jan 25 17:19:34 2021 +0100

    usb: dwc3: fix clock issue during resume in OTG mode
    
    commit 0e5a3c8284a30f4c43fd81d7285528ece74563b5 upstream.
    
    Commit fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3
    core") introduced clock support and a new function named
    dwc3_core_init_for_resume() which enables the clock before calling
    dwc3_core_init() during resume as clocks get disabled during suspend.
    
    Unfortunately in this commit the DWC3_GCTL_PRTCAP_OTG case was forgotten
    and therefore during resume, a platform could call dwc3_core_init()
    without re-enabling the clocks first, preventing to resume properly.
    
    So update the resume path to call dwc3_core_init_for_resume() as it
    should.
    
    Fixes: fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3 core")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
    Link: https://lore.kernel.org/r/20210125161934.527820-1-gary.bisson@boundarydevices.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 750829e1931a495d6889752811584a23ddad9db5
Author: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Date:   Wed Jan 27 11:39:19 2021 +0100

    usb: dwc2: Fix endpoint direction check in ep_from_windex
    
    commit f670e9f9c8cac716c3506c6bac9e997b27ad441a upstream.
    
    dwc2_hsotg_process_req_status uses ep_from_windex() to retrieve
    the endpoint for the index provided in the wIndex request param.
    
    In a test-case with a rndis gadget running and sending a malformed
    packet to it like:
        dev.ctrl_transfer(
            0x82,      # bmRequestType
            0x00,       # bRequest
            0x0000,     # wValue
            0x0001,     # wIndex
            0x00       # wLength
        )
    it is possible to cause a crash:
    
    [  217.533022] dwc2 ff300000.usb: dwc2_hsotg_process_req_status: USB_REQ_GET_STATUS
    [  217.559003] Unable to handle kernel read from unreadable memory at virtual address 0000000000000088
    ...
    [  218.313189] Call trace:
    [  218.330217]  ep_from_windex+0x3c/0x54
    [  218.348565]  usb_gadget_giveback_request+0x10/0x20
    [  218.368056]  dwc2_hsotg_complete_request+0x144/0x184
    
    This happens because ep_from_windex wants to compare the endpoint
    direction even if index_to_ep() didn't return an endpoint due to
    the direction not matching.
    
    The fix is easy insofar that the actual direction check is already
    happening when calling index_to_ep() which will return NULL if there
    is no endpoint for the targeted direction, so the offending check
    can go away completely.
    
    Fixes: c6f5c050e2a7 ("usb: dwc2: gadget: add bi-directional endpoint support")
    Cc: stable@vger.kernel.org
    Reported-by: Gerhard Klostermeier <gerhard.klostermeier@syss.de>
    Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20210127103919.58215-1-heiko@sntech.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 039656997da316c4828795bef833d81b49a3681d
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon Feb 1 21:47:20 2021 +0900

    usb: renesas_usbhs: Clear pipe running flag in usbhs_pkt_pop()
    
    commit 9917f0e3cdba7b9f1a23f70e3f70b1a106be54a8 upstream.
    
    Should clear the pipe running flag in usbhs_pkt_pop(). Otherwise,
    we cannot use this pipe after dequeue was called while the pipe was
    running.
    
    Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
    Reported-by: Tho Vu <tho.vu.wh@renesas.com>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/1612183640-8898-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75582ceb723e6ca95c93a6587080e5aba35322a0
Author: Jeremy Figgins <kernel@jeremyfiggins.com>
Date:   Sat Jan 23 18:21:36 2021 -0600

    USB: usblp: don't call usb_set_interface if there's a single alt
    
    commit d8c6edfa3f4ee0d45d7ce5ef18d1245b78774b9d upstream.
    
    Some devices, such as the Winbond Electronics Corp. Virtual Com Port
    (Vendor=0416, ProdId=5011), lockup when usb_set_interface() or
    usb_clear_halt() are called. This device has only a single
    altsetting, so it should not be necessary to call usb_set_interface().
    
    Acked-by: Pete Zaitcev <zaitcev@redhat.com>
    Signed-off-by: Jeremy Figgins <kernel@jeremyfiggins.com>
    Link: https://lore.kernel.org/r/YAy9kJhM/rG8EQXC@watson
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4025244544b802d15eee76840702a3088b89624b
Author: kernel test robot <lkp@intel.com>
Date:   Thu Jan 21 19:12:54 2021 +0100

    usb: gadget: aspeed: add missing of_node_put
    
    commit a55a9a4c5c6253f6e4dea268af728664ac997790 upstream.
    
    Breaking out of for_each_child_of_node requires a put on the
    child value.
    
    Generated by: scripts/coccinelle/iterators/for_each_child.cocci
    
    Fixes: 82c2d81361ec ("coccinelle: iterators: Add for_each_child.cocci script")
    CC: Sumera Priyadarsini <sylphrenadin@gmail.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2101211907060.14700@hadrien
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8e1dabc1e0536c1618b7aac7a07d532095834a0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 28 12:33:42 2021 +0300

    USB: gadget: legacy: fix an error code in eth_bind()
    
    commit 3e1f4a2e1184ae6ad7f4caf682ced9554141a0f4 upstream.
    
    This code should return -ENOMEM if the allocation fails but it currently
    returns success.
    
    Fixes: 9b95236eebdb ("usb: gadget: ether: allocate and init otg descriptor by otg capabilities")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YBKE9rqVuJEOUWpW@mwanda
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d56e0ac9a1fc44ad14bfe9bdcc539048211f6ea5
Author: Pali Rohár <pali@kernel.org>
Date:   Mon Feb 1 16:08:03 2021 +0100

    usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720
    
    commit 3241929b67d28c83945d3191c6816a3271fd6b85 upstream.
    
    Older ATF does not provide SMC call for USB 3.0 phy power on functionality
    and therefore initialization of xhci-hcd is failing when older version of
    ATF is used. In this case phy_power_on() function returns -EOPNOTSUPP.
    
    [    3.108467] mvebu-a3700-comphy d0018300.phy: unsupported SMC call, try updating your firmware
    [    3.117250] phy phy-d0018300.phy.0: phy poweron failed --> -95
    [    3.123465] xhci-hcd: probe of d0058000.usb failed with error -95
    
    This patch introduces a new plat_setup callback for xhci platform drivers
    which is called prior calling usb_add_hcd() function. This function at its
    beginning skips PHY init if hcd->skip_phy_initialization is set.
    
    Current init_quirk callback for xhci platform drivers is called from
    xhci_plat_setup() function which is called after chip reset completes.
    It happens in the middle of the usb_add_hcd() function and therefore this
    callback cannot be used for setting if PHY init should be skipped or not.
    
    For Armada 3720 this patch introduce a new xhci_mvebu_a3700_plat_setup()
    function configured as a xhci platform plat_setup callback. This new
    function calls phy_power_on() and in case it returns -EOPNOTSUPP then
    XHCI_SKIP_PHY_INIT quirk is set to instruct xhci-plat to skip PHY
    initialization.
    
    This patch fixes above failure by ignoring 'not supported' error in
    xhci-hcd driver. In this case it is expected that phy is already power on.
    
    It fixes initialization of xhci-hcd on Espressobin boards where is older
    Marvell's Arm Trusted Firmware without SMC call for USB 3.0 phy power.
    
    This is regression introduced in commit bd3d25b07342 ("arm64: dts: marvell:
    armada-37xx: link USB hosts with their PHYs") where USB 3.0 phy was defined
    and therefore xhci-hcd on Espressobin with older ATF started failing.
    
    Fixes: bd3d25b07342 ("arm64: dts: marvell: armada-37xx: link USB hosts with their PHYs")
    Cc: <stable@vger.kernel.org> # 5.1+: ea17a0f153af: phy: marvell: comphy: Convert internal SMCC firmware return codes to errno
    Cc: <stable@vger.kernel.org> # 5.1+: f768e718911e: usb: host: xhci-plat: add priv quirk for skip PHY initialization
    Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> # On R-Car
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> # xhci-plat
    Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20210201150803.7305-1-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73b1de6b5ea3051042368dfb2fc9663a8c1c787a
Author: Christoph Schemmel <christoph.schemmel@gmail.com>
Date:   Wed Jan 27 20:58:46 2021 +0100

    USB: serial: option: Adding support for Cinterion MV31
    
    commit e478d6029dca9d8462f426aee0d32896ef64f10f upstream.
    
    Adding support for Cinterion device MV31 for enumeration with
    PID 0x00B3 and 0x00B7.
    
    usb-devices output for 0x00B3
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b3 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B3 USB Mobile Broadband
    S:  SerialNumber=b3246eed
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=cdc_wdm
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    usb-devices output for 0x00B7
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b7 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B3 USB Mobile Broadband
    S:  SerialNumber=b3246eed
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    Signed-off-by: Christoph Schemmel <christoph.schemmel@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c43cb08791a27d338011b38f04de358966103f78
Author: Chenxin Jin <bg4akv@hotmail.com>
Date:   Wed Jan 13 16:59:05 2021 +0800

    USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000
    
    commit 43377df70480f82919032eb09832e9646a8a5efb upstream.
    
    Teraoka AD2000 uses the CP210x driver, but the chip VID/PID is
    customized with 0988/0578. We need the driver to support the new
    VID/PID.
    
    Signed-off-by: Chenxin Jin <bg4akv@hotmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17fb12b4a75673a9bde295e996bb3378b3fc5b54
Author: Pho Tran <Pho.Tran@silabs.com>
Date:   Mon Jan 25 09:26:54 2021 +0000

    USB: serial: cp210x: add pid/vid for WSDA-200-USB
    
    commit 3c4f6ecd93442f4376a58b38bb40ee0b8c46e0e6 upstream.
    
    Information pid/vid of WSDA-200-USB, Lord corporation company:
    vid: 199b
    pid: ba30
    
    Signed-off-by: Pho Tran <pho.tran@silabs.com>
    [ johan: amend comment with product name ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>