commit 5650152ddab1a6b367e6804deea344e001bd656e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jan 9 13:46:25 2021 +0100

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

commit 94cc73b27a2599e4c88b7b2d6fd190107c58e480
Author: Zhang Xiaohui <ruc_zhangxiaohui@163.com>
Date:   Sun Dec 6 16:48:01 2020 +0800

    mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
    
    [ Upstream commit 5c455c5ab332773464d02ba17015acdca198f03d ]
    
    mwifiex_cmd_802_11_ad_hoc_start() calls memcpy() without checking
    the destination size may trigger a buffer overflower,
    which a local user could use to cause denial of service
    or the execution of arbitrary code.
    Fix it by putting the length check before calling memcpy().
    
    Signed-off-by: Zhang Xiaohui <ruc_zhangxiaohui@163.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201206084801.26479-1-ruc_zhangxiaohui@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab7709b551de24e7bebf44946120e6740b1e28db
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Dec 3 14:12:00 2020 -0600

    exec: Transform exec_update_mutex into a rw_semaphore
    
    [ Upstream commit f7cfd871ae0c5008d94b6f66834e7845caa93c15 ]
    
    Recently syzbot reported[0] that there is a deadlock amongst the users
    of exec_update_mutex.  The problematic lock ordering found by lockdep
    was:
    
       perf_event_open  (exec_update_mutex -> ovl_i_mutex)
       chown            (ovl_i_mutex       -> sb_writes)
       sendfile         (sb_writes         -> p->lock)
         by reading from a proc file and writing to overlayfs
       proc_pid_syscall (p->lock           -> exec_update_mutex)
    
    While looking at possible solutions it occured to me that all of the
    users and possible users involved only wanted to state of the given
    process to remain the same.  They are all readers.  The only writer is
    exec.
    
    There is no reason for readers to block on each other.  So fix
    this deadlock by transforming exec_update_mutex into a rw_semaphore
    named exec_update_lock that only exec takes for writing.
    
    Cc: Jann Horn <jannh@google.com>
    Cc: Vasiliy Kulikov <segoon@openwall.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Christopher Yeoh <cyeoh@au1.ibm.com>
    Cc: Cyrill Gorcunov <gorcunov@gmail.com>
    Cc: Sargun Dhillon <sargun@sargun.me>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Fixes: eea9673250db ("exec: Add exec_update_mutex to replace cred_guard_mutex")
    [0] https://lkml.kernel.org/r/00000000000063640c05ade8e3de@google.com
    Reported-by: syzbot+db9cdf3dd1f64252c6ef@syzkaller.appspotmail.com
    Link: https://lkml.kernel.org/r/87ft4mbqen.fsf@x220.int.ebiederm.org
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 933b7cc86068fe9c2b8ebb51606022a37a7f958a
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Dec 3 14:11:13 2020 -0600

    rwsem: Implement down_read_interruptible
    
    [ Upstream commit 31784cff7ee073b34d6eddabb95e3be2880a425c ]
    
    In preparation for converting exec_update_mutex to a rwsem so that
    multiple readers can execute in parallel and not deadlock, add
    down_read_interruptible.  This is needed for perf_event_open to be
    converted (with no semantic changes) from working on a mutex to
    wroking on a rwsem.
    
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/87k0tybqfy.fsf@x220.int.ebiederm.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27bae39e4fc4f911eae970ed2a332a36a92d463d
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Dec 3 14:10:32 2020 -0600

    rwsem: Implement down_read_killable_nested
    
    [ Upstream commit 0f9368b5bf6db0c04afc5454b1be79022a681615 ]
    
    In preparation for converting exec_update_mutex to a rwsem so that
    multiple readers can execute in parallel and not deadlock, add
    down_read_killable_nested.  This is needed so that kcmp_lock
    can be converted from working on a mutexes to working on rw_semaphores.
    
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/87o8jabqh3.fsf@x220.int.ebiederm.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cded5a3cc38545472a717b16402cbde1c1712b5
Author: peterz@infradead.org <peterz@infradead.org>
Date:   Fri Aug 28 14:37:20 2020 +0200

    perf: Break deadlock involving exec_update_mutex
    
    [ Upstream commit 78af4dc949daaa37b3fcd5f348f373085b4e858f ]
    
    Syzbot reported a lock inversion involving perf. The sore point being
    perf holding exec_update_mutex() for a very long time, specifically
    across a whole bunch of filesystem ops in pmu::event_init() (uprobes)
    and anon_inode_getfile().
    
    This then inverts against procfs code trying to take
    exec_update_mutex.
    
    Move the permission checks later, such that we need to hold the mutex
    over less code.
    
    Reported-by: syzbot+db9cdf3dd1f64252c6ef@syzkaller.appspotmail.com
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36cf9ae54b0ead0daab7701a994de3dcd9ef605d
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Dec 10 15:33:14 2020 +0100

    fuse: fix bad inode
    
    [ Upstream commit 5d069dbe8aaf2a197142558b6fb2978189ba3454 ]
    
    Jan Kara's analysis of the syzbot report (edited):
    
      The reproducer opens a directory on FUSE filesystem, it then attaches
      dnotify mark to the open directory.  After that a fuse_do_getattr() call
      finds that attributes returned by the server are inconsistent, and calls
      make_bad_inode() which, among other things does:
    
              inode->i_mode = S_IFREG;
    
      This then confuses dnotify which doesn't tear down its structures
      properly and eventually crashes.
    
    Avoid calling make_bad_inode() on a live inode: switch to a private flag on
    the fuse inode.  Also add the test to ops which the bad_inode_ops would
    have caught.
    
    This bug goes back to the initial merge of fuse in 2.6.14...
    
    Reported-by: syzbot+f427adf9324b92652ccc@syzkaller.appspotmail.com
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Tested-by: Jan Kara <jack@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e522a788eb915dacde4a060e49f69ca1ea0cb34a
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Fri Nov 6 10:00:49 2020 -0400

    RDMA/siw,rxe: Make emulated devices virtual in the device tree
    
    [ Upstream commit a9d2e9ae953f0ddd0327479c81a085adaa76d903 ]
    
    This moves siw and rxe to be virtual devices in the device tree:
    
    lrwxrwxrwx 1 root root 0 Nov  6 13:55 /sys/class/infiniband/rxe0 -> ../../devices/virtual/infiniband/rxe0/
    
    Previously they were trying to parent themselves to the physical device of
    their attached netdev, which doesn't make alot of sense.
    
    My hope is this will solve some weird syzkaller hits related to sysfs as
    it could be possible that the parent of a netdev is another netdev, eg
    under bonding or some other syzkaller found netdev configuration.
    
    Nesting a ib_device under anything but a physical device is going to cause
    inconsistencies in sysfs during destructions.
    
    Link: https://lore.kernel.org/r/0-v1-dcbfc68c4b4a+d6-virtual_dev_jgg@nvidia.com
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 404fa093741e15e16fd522cc76cd9f86e9ef81d2
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Nov 6 19:19:38 2020 +0100

    RDMA/core: remove use of dma_virt_ops
    
    [ Upstream commit 5a7a9e038b032137ae9c45d5429f18a2ffdf7d42 ]
    
    Use the ib_dma_* helpers to skip the DMA translation instead.  This
    removes the last user if dma_virt_ops and keeps the weird layering
    violation inside the RDMA core instead of burderning the DMA mapping
    subsystems with it.  This also means the software RDMA drivers now don't
    have to mess with DMA parameters that are not relevant to them at all, and
    that in the future we can use PCI P2P transfers even for software RDMA, as
    there is no first fake layer of DMA mapping that the P2P DMA support.
    
    Link: https://lore.kernel.org/r/20201106181941.1878556-8-hch@lst.de
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Tested-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a54ad3066a810ffa8f5ee958def3dc3065d8cd6
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Tue Dec 8 21:56:34 2020 +0800

    scsi: ufs: Re-enable WriteBooster after device reset
    
    [ Upstream commit bd14bf0e4a084514aa62d24d2109e0f09a93822f ]
    
    UFS 3.1 specification mentions that the WriteBooster flags listed below
    will be set to their default values, i.e. disabled, after power cycle or
    any type of reset event. Thus we need to reset the flag variables kept in
    struct hba to align with the device status and ensure that
    WriteBooster-related functions are configured properly after device reset.
    
    Without this fix, WriteBooster will not be enabled successfully after by
    ufshcd_wb_ctrl() after device reset because hba->wb_enabled remains true.
    
    Flags required to be reset to default values:
    
     - fWriteBoosterEn: hba->wb_enabled
    
     - fWriteBoosterBufferFlushEn: hba->wb_buf_flush_enabled
    
     - fWriteBoosterBufferFlushDuringHibernate: No variable mapped
    
    Link: https://lore.kernel.org/r/20201208135635.15326-2-stanley.chu@mediatek.com
    Fixes: 3d17b9b5ab11 ("scsi: ufs: Add write booster feature support")
    Reviewed-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit acbf7db67ae334b1884321755b097142d4d79674
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 3 16:14:03 2020 +0200

    scsi: ufs: Allow an error return value from ->device_reset()
    
    [ Upstream commit 151f1b664ffbb847c7fbbce5a5b8580f1b9b1d98 ]
    
    It is simpler for drivers to provide a ->device_reset() callback
    irrespective of whether the GPIO, or firmware interface necessary to do the
    reset, is discovered during probe.
    
    Change ->device_reset() to return an error code.  Drivers that provide the
    callback, but do not do the reset operation should return -EOPNOTSUPP.
    
    Link: https://lore.kernel.org/r/20201103141403.2142-3-adrian.hunter@intel.com
    Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
    Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
    Reviewed-by: Bean huo <beanhuo@micron.com>
    Reviewed-by: Can Guo <cang@codeaurora.org>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8cba90399216ac12ad86193a5dcb0bb7606e15c9
Author: Imre Deak <imre.deak@intel.com>
Date:   Sat Oct 3 03:18:46 2020 +0300

    drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock
    
    commit 0e2497e334de42dbaaee8e325241b5b5b34ede7e upstream.
    
    Apply Display WA #22010492432 for combo PHY PLLs too. This should fix a
    problem where the PLL output frequency is slightly off with the current
    PLL fractional divider value.
    
    I haven't seen an actual case where this causes a problem, but let's
    follow the spec. It's also needed on some EHL platforms, but for that we
    also need a way to distinguish the affected EHL SKUs, so I leave that
    for a follow-up.
    
    v2:
    - Apply the WA at one place when calculating the PLL dividers from the
      frequency and the frequency from the dividers for all the combo PLL
      use cases (DP, HDMI, TBT). (Ville)
    
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201003001846.1271151-6-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adee1c5126ef0aa7951e0ba101b73a3cd6732c09
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jan 1 09:38:52 2021 +0100

    ALSA: hda/hdmi: Fix incorrect mutex unlock in silent_stream_disable()
    
    commit 3d5c5fdcee0f9a94deb0472e594706018b00aa31 upstream.
    
    The silent_stream_disable() function introduced by the commit
    b1a5039759cb ("ALSA: hda/hdmi: fix silent stream for first playback to
    DP") takes the per_pin->lock mutex, but it unlocks the wrong one,
    spec->pcm_lock, which causes a deadlock.  This patch corrects it.
    
    Fixes: b1a5039759cb ("ALSA: hda/hdmi: fix silent stream for first playback to DP")
    Reported-by: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
    Cc: <stable@vger.kernel.org>
    Acked-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20210101083852.12094-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e235fd076eb7ad6e730bb1e0bfedd66519b236f4
Author: Kailang Yang <kailang@realtek.com>
Date:   Wed Dec 23 15:34:57 2020 +0800

    ALSA: hda/realtek - Modify Dell platform name
    
    commit c1e8952395c1f44a6304c71401519d19ed2ac56a upstream.
    
    Dell platform SSID:0x0a58 change platform name.
    Use the generic name instead for avoiding confusion.
    
    Fixes: 150927c3674d ("ALSA: hda/realtek - Supported Dell fixed type headset")
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/efe7c196158241aa817229df7835d645@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce9163cf7a84e43ac7329aa0f585dff734c72c4e
Author: Edward Vear <edwardvear@gmail.com>
Date:   Tue Oct 27 00:02:03 2020 -0700

    Bluetooth: Fix attempting to set RPA timeout when unsupported
    
    commit a31489d2a368d2f9225ed6a6f595c63bc7d10de8 upstream.
    
    During controller initialization, an LE Set RPA Timeout command is sent
    to the controller if supported. However, the value checked to determine
    if the command is supported is incorrect. Page 1921 of the Bluetooth
    Core Spec v5.2 shows that bit 2 of octet 35 of the Supported_Commands
    field corresponds to the LE Set RPA Timeout command, but currently
    bit 6 of octet 35 is checked. This patch checks the correct value
    instead.
    
    This issue led to the error seen in the following btmon output during
    initialization of an adapter (rtl8761b) and prevented initialization
    from completing.
    
    < HCI Command: LE Set Resolvable Private Address Timeout (0x08|0x002e) plen 2
            Timeout: 900 seconds
    > HCI Event: Command Complete (0x0e) plen 4
          LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 2
            Status: Unsupported Remote Feature / Unsupported LMP Feature (0x1a)
    = Close Index: 00:E0:4C:6B:E5:03
    
    The error did not appear when running with this patch.
    
    Signed-off-by: Edward Vear <edwardvear@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e073508920aeafa8c6896a8897ee71e8b864559
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Tue Dec 29 15:14:55 2020 -0800

    kdev_t: always inline major/minor helper functions
    
    commit aa8c7db494d0a83ecae583aa193f1134ef25d506 upstream.
    
    Silly GCC doesn't always inline these trivial functions.
    
    Fixes the following warning:
    
      arch/x86/kernel/sys_ia32.o: warning: objtool: cp_stat64()+0xd8: call to new_encode_dev() with UACCESS enabled
    
    Link: https://lkml.kernel.org/r/984353b44a4484d86ba9f73884b7306232e25e30.1608737428.git.jpoimboe@redhat.com
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>  [build-tested]
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.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 fd3ec3b2513799a97e4d734dfc4a116512dcc5f2
Author: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date:   Fri Dec 18 11:10:53 2020 +0100

    dt-bindings: rtc: add reset-source property
    
    commit 320d159e2d63a97a40f24cd6dfda5a57eec65b91 upstream.
    
    Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
    if the reset pin is not actually wired up, the driver exposes a
    watchdog device that doesn't actually work.
    
    Provide a standard binding that can be used to indicate that a given
    RTC can perform a reset of the machine, similar to wakeup-source.
    
    Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20201218101054.25416-2-rasmus.villemoes@prevas.dk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 757cd94ac8598b0365e8b2b46564ff537d74805c
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Dec 18 11:10:54 2020 +0100

    rtc: pcf2127: only use watchdog when explicitly available
    
    commit 71ac13457d9d1007effde65b54818106b2c2b525 upstream.
    
    Most boards using the pcf2127 chip (in my bubble) don't make use of the
    watchdog functionality and the respective output is not connected. The
    effect on such a board is that there is a watchdog device provided that
    doesn't work.
    
    So only register the watchdog if the device tree has a "reset-source"
    property.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    [RV: s/has-watchdog/reset-source/]
    Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20201218101054.25416-3-rasmus.villemoes@prevas.dk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acb821425c8cc5a4b688c973446cde356a04923a
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Sep 24 12:52:55 2020 +0200

    rtc: pcf2127: move watchdog initialisation to a separate function
    
    commit 5d78533a0c53af9659227c803df944ba27cd56e0 upstream.
    
    The obvious advantages are:
    
     - The linker can drop the watchdog functions if CONFIG_WATCHDOG is off.
     - All watchdog stuff grouped together with only a single function call
       left in generic code.
     - Watchdog register is only read when it is actually used.
     - Less #ifdefery
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20200924105256.18162-2-u.kleine-koenig@pengutronix.de
    Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b00195241186db6e2fb5698afe67971b05b1a959
Author: Felix Fietkau <nbd@nbd.name>
Date:   Tue Jan 5 11:18:21 2021 +0100

    Revert "mtd: spinand: Fix OOB read"
    
    This reverts stable commit baad618d078c857f99cc286ea249e9629159901f.
    
    This commit is adding lines to spinand_write_to_cache_op, wheras the upstream
    commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 that this was supposed to
    backport was touching spinand_read_from_cache_op.
    It causes a crash on writing OOB data by attempting to write to read-only
    kernel memory.
    
    Cc: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 261f4d03ad23c63964a6e1dd7b3611b108b1cb57
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Tue Jan 5 11:45:45 2021 -0500

    Revert "drm/amd/display: Fix memory leaks in S3 resume"
    
    This reverts commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362.
    
    This leads to blank screens on some boards after replugging a
    display.  Revert until we understand the root cause and can
    fix both the leak and the blank screen after replug.
    
    Cc: Stylon Wang <stylon.wang@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Cc: Andre Tomt <andre@tomt.net>
    Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>