--- /dev/null
+From 52218fcd61cb42bde0d301db4acb3ffdf3463cc7 Mon Sep 17 00:00:00 2001
+From: Zhenyu Ye <yezhenyu2@huawei.com>
+Date: Wed, 23 Jun 2021 15:05:22 +0800
+Subject: arm64: tlb: fix the TTL value of tlb_get_level
+
+From: Zhenyu Ye <yezhenyu2@huawei.com>
+
+commit 52218fcd61cb42bde0d301db4acb3ffdf3463cc7 upstream.
+
+The TTL field indicates the level of page table walk holding the *leaf*
+entry for the address being invalidated. But currently, the TTL field
+may be set to an incorrent value in the following stack:
+
+pte_free_tlb
+ __pte_free_tlb
+ tlb_remove_table
+ tlb_table_invalidate
+ tlb_flush_mmu_tlbonly
+ tlb_flush
+
+In this case, we just want to flush a PTE page, but the tlb->cleared_pmds
+is set and we get tlb_level = 2 in the tlb_get_level() function. This may
+cause some unexpected problems.
+
+This patch set the TTL field to 0 if tlb->freed_tables is set. The
+tlb->freed_tables indicates page table pages are freed, not the leaf
+entry.
+
+Cc: <stable@vger.kernel.org> # 5.9.x
+Fixes: c4ab2cbc1d87 ("arm64: tlb: Set the TTL field in flush_tlb_range")
+Acked-by: Catalin Marinas <catalin.marinas@arm.com>
+Reported-by: ZhuRui <zhurui3@huawei.com>
+Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com>
+Link: https://lore.kernel.org/r/b80ead47-1f88-3a00-18e1-cacc22f54cc4@huawei.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/tlb.h | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/arm64/include/asm/tlb.h
++++ b/arch/arm64/include/asm/tlb.h
+@@ -28,6 +28,10 @@ static void tlb_flush(struct mmu_gather
+ */
+ static inline int tlb_get_level(struct mmu_gather *tlb)
+ {
++ /* The TTL field is only valid for the leaf entry. */
++ if (tlb->freed_tables)
++ return 0;
++
+ if (tlb->cleared_ptes && !(tlb->cleared_pmds ||
+ tlb->cleared_puds ||
+ tlb->cleared_p4ds))
--- /dev/null
+From f6bca4d91b2ea052e917cca3f9d866b5cc1d500a Mon Sep 17 00:00:00 2001
+From: Timo Sigurdsson <public_timo.s@silentcreek.de>
+Date: Mon, 14 Jun 2021 09:25:39 +0200
+Subject: ata: ahci_sunxi: Disable DIPM
+
+From: Timo Sigurdsson <public_timo.s@silentcreek.de>
+
+commit f6bca4d91b2ea052e917cca3f9d866b5cc1d500a upstream.
+
+DIPM is unsupported or broken on sunxi. Trying to enable the power
+management policy med_power_with_dipm on an Allwinner A20 SoC based board
+leads to immediate I/O errors and the attached SATA disk disappears from
+the /dev filesystem. A reset (power cycle) is required to make the SATA
+controller or disk work again. The A10 and A20 SoC data sheets and manuals
+don't mention DIPM at all [1], so it's fair to assume that it's simply not
+supported. But even if it was, it should be considered broken and best be
+disabled in the ahci_sunxi driver.
+
+[1] https://github.com/allwinner-zh/documents/tree/master/
+
+Fixes: c5754b5220f0 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform")
+Cc: stable@vger.kernel.org
+Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
+Tested-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
+Link: https://lore.kernel.org/r/20210614072539.3307-1-public_timo.s@silentcreek.de
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/ahci_sunxi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/ata/ahci_sunxi.c
++++ b/drivers/ata/ahci_sunxi.c
+@@ -200,7 +200,7 @@ static void ahci_sunxi_start_engine(stru
+ }
+
+ static const struct ata_port_info ahci_sunxi_port_info = {
+- .flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
++ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ | ATA_FLAG_NO_DIPM,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_platform_ops,
--- /dev/null
+From 8b33dfe0ba1c84c1aab2456590b38195837f1e6e Mon Sep 17 00:00:00 2001
+From: Samuel Holland <samuel@sholland.org>
+Date: Fri, 14 May 2021 21:14:39 -0500
+Subject: clocksource/arm_arch_timer: Improve Allwinner A64 timer workaround
+
+From: Samuel Holland <samuel@sholland.org>
+
+commit 8b33dfe0ba1c84c1aab2456590b38195837f1e6e upstream.
+
+Bad counter reads are experienced sometimes when bit 10 or greater rolls
+over. Originally, testing showed that at least 10 lower bits would be
+set to the same value during these bad reads. However, some users still
+reported time skips.
+
+Wider testing revealed that on some chips, occasionally only the lowest
+9 bits would read as the anomalous value. During these reads (which
+still happen only when bit 10), bit 9 would read as the correct value.
+
+Reduce the mask by one bit to cover these cases as well.
+
+Cc: stable@vger.kernel.org
+Fixes: c950ca8c35ee ("clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability")
+Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
+Signed-off-by: Samuel Holland <samuel@sholland.org>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20210515021439.55316-1-samuel@sholland.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/arm_arch_timer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clocksource/arm_arch_timer.c
++++ b/drivers/clocksource/arm_arch_timer.c
+@@ -352,7 +352,7 @@ static u64 notrace arm64_858921_read_cnt
+ do { \
+ _val = read_sysreg(reg); \
+ _retries--; \
+- } while (((_val + 1) & GENMASK(9, 0)) <= 1 && _retries); \
++ } while (((_val + 1) & GENMASK(8, 0)) <= 1 && _retries); \
+ \
+ WARN_ON_ONCE(!_retries); \
+ _val; \
--- /dev/null
+From b22afcdf04c96ca58327784e280e10288cfd3303 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Sat, 27 Mar 2021 22:01:36 +0100
+Subject: cpu/hotplug: Cure the cpusets trainwreck
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit b22afcdf04c96ca58327784e280e10288cfd3303 upstream.
+
+Alexey and Joshua tried to solve a cpusets related hotplug problem which is
+user space visible and results in unexpected behaviour for some time after
+a CPU has been plugged in and the corresponding uevent was delivered.
+
+cpusets delegate the hotplug work (rebuilding cpumasks etc.) to a
+workqueue. This is done because the cpusets code has already a lock
+nesting of cgroups_mutex -> cpu_hotplug_lock. A synchronous callback or
+waiting for the work to finish with cpu_hotplug_lock held can and will
+deadlock because that results in the reverse lock order.
+
+As a consequence the uevent can be delivered before cpusets have consistent
+state which means that a user space invocation of sched_setaffinity() to
+move a task to the plugged CPU fails up to the point where the scheduled
+work has been processed.
+
+The same is true for CPU unplug, but that does not create user observable
+failure (yet).
+
+It's still inconsistent to claim that an operation is finished before it
+actually is and that's the real issue at hand. uevents just make it
+reliably observable.
+
+Obviously the problem should be fixed in cpusets/cgroups, but untangling
+that is pretty much impossible because according to the changelog of the
+commit which introduced this 8 years ago:
+
+ 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()")
+
+the lock order cgroups_mutex -> cpu_hotplug_lock is a design decision and
+the whole code is built around that.
+
+So bite the bullet and invoke the relevant cpuset function, which waits for
+the work to finish, in _cpu_up/down() after dropping cpu_hotplug_lock and
+only when tasks are not frozen by suspend/hibernate because that would
+obviously wait forever.
+
+Waiting there with cpu_add_remove_lock, which is protecting the present
+and possible CPU maps, held is not a problem at all because neither work
+queues nor cpusets/cgroups have any lockchains related to that lock.
+
+Waiting in the hotplug machinery is not problematic either because there
+are already state callbacks which wait for hardware queues to drain. It
+makes the operations slightly slower, but hotplug is slow anyway.
+
+This ensures that state is consistent before returning from a hotplug
+up/down operation. It's still inconsistent during the operation, but that's
+a different story.
+
+Add a large comment which explains why this is done and why this is not a
+dump ground for the hack of the day to work around half thought out locking
+schemes. Document also the implications vs. hotplug operations and
+serialization or the lack of it.
+
+Thanks to Alexy and Joshua for analyzing why this temporary
+sched_setaffinity() failure happened.
+
+Fixes: 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()")
+Reported-by: Alexey Klimov <aklimov@redhat.com>
+Reported-by: Joshua Baker <jobaker@redhat.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Alexey Klimov <aklimov@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/87tuowcnv3.ffs@nanos.tec.linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 49 insertions(+)
+
+--- a/kernel/cpu.c
++++ b/kernel/cpu.c
+@@ -32,6 +32,7 @@
+ #include <linux/relay.h>
+ #include <linux/slab.h>
+ #include <linux/percpu-rwsem.h>
++#include <linux/cpuset.h>
+
+ #include <trace/events/power.h>
+ #define CREATE_TRACE_POINTS
+@@ -814,6 +815,52 @@ void __init cpuhp_threads_init(void)
+ kthread_unpark(this_cpu_read(cpuhp_state.thread));
+ }
+
++/*
++ *
++ * Serialize hotplug trainwrecks outside of the cpu_hotplug_lock
++ * protected region.
++ *
++ * The operation is still serialized against concurrent CPU hotplug via
++ * cpu_add_remove_lock, i.e. CPU map protection. But it is _not_
++ * serialized against other hotplug related activity like adding or
++ * removing of state callbacks and state instances, which invoke either the
++ * startup or the teardown callback of the affected state.
++ *
++ * This is required for subsystems which are unfixable vs. CPU hotplug and
++ * evade lock inversion problems by scheduling work which has to be
++ * completed _before_ cpu_up()/_cpu_down() returns.
++ *
++ * Don't even think about adding anything to this for any new code or even
++ * drivers. It's only purpose is to keep existing lock order trainwrecks
++ * working.
++ *
++ * For cpu_down() there might be valid reasons to finish cleanups which are
++ * not required to be done under cpu_hotplug_lock, but that's a different
++ * story and would be not invoked via this.
++ */
++static void cpu_up_down_serialize_trainwrecks(bool tasks_frozen)
++{
++ /*
++ * cpusets delegate hotplug operations to a worker to "solve" the
++ * lock order problems. Wait for the worker, but only if tasks are
++ * _not_ frozen (suspend, hibernate) as that would wait forever.
++ *
++ * The wait is required because otherwise the hotplug operation
++ * returns with inconsistent state, which could even be observed in
++ * user space when a new CPU is brought up. The CPU plug uevent
++ * would be delivered and user space reacting on it would fail to
++ * move tasks to the newly plugged CPU up to the point where the
++ * work has finished because up to that point the newly plugged CPU
++ * is not assignable in cpusets/cgroups. On unplug that's not
++ * necessarily a visible issue, but it is still inconsistent state,
++ * which is the real problem which needs to be "fixed". This can't
++ * prevent the transient state between scheduling the work and
++ * returning from waiting for it.
++ */
++ if (!tasks_frozen)
++ cpuset_wait_for_hotplug();
++}
++
+ #ifdef CONFIG_HOTPLUG_CPU
+ #ifndef arch_clear_mm_cpumask_cpu
+ #define arch_clear_mm_cpumask_cpu(cpu, mm) cpumask_clear_cpu(cpu, mm_cpumask(mm))
+@@ -1051,6 +1098,7 @@ out:
+ */
+ lockup_detector_cleanup();
+ arch_smt_update();
++ cpu_up_down_serialize_trainwrecks(tasks_frozen);
+ return ret;
+ }
+
+@@ -1247,6 +1295,7 @@ static int _cpu_up(unsigned int cpu, int
+ out:
+ cpus_write_unlock();
+ arch_smt_update();
++ cpu_up_down_serialize_trainwrecks(tasks_frozen);
+ return ret;
+ }
+
--- /dev/null
+From e38ca7e422791a4d1c01e56dbf7f9982db0ed365 Mon Sep 17 00:00:00 2001
+From: Guchun Chen <guchun.chen@amd.com>
+Date: Mon, 28 Jun 2021 17:03:48 +0800
+Subject: drm/amd/display: fix incorrrect valid irq check
+
+From: Guchun Chen <guchun.chen@amd.com>
+
+commit e38ca7e422791a4d1c01e56dbf7f9982db0ed365 upstream.
+
+valid DAL irq should be < DAL_IRQ_SOURCES_NUMBER.
+
+Signed-off-by: Guchun Chen <guchun.chen@amd.com>
+Reviewed-and-tested-by: Evan Quan <evan.quan@amd.com>
+Reviewed-by: Harry Wentland <harry.wentland@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>
+
+---
+ drivers/gpu/drm/amd/display/dc/irq_types.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/irq_types.h
++++ b/drivers/gpu/drm/amd/display/dc/irq_types.h
+@@ -163,7 +163,7 @@ enum irq_type
+ };
+
+ #define DAL_VALID_IRQ_SRC_NUM(src) \
+- ((src) <= DAL_IRQ_SOURCES_NUMBER && (src) > DC_IRQ_SOURCE_INVALID)
++ ((src) < DAL_IRQ_SOURCES_NUMBER && (src) > DC_IRQ_SOURCE_INVALID)
+
+ /* Number of Page Flip IRQ Sources. */
+ #define DAL_PFLIP_IRQ_SRC_NUM \
--- /dev/null
+From c6c6a712199ab355ce333fa5764a59506bb107c1 Mon Sep 17 00:00:00 2001
+From: Harry Wentland <harry.wentland@amd.com>
+Date: Thu, 22 Apr 2021 19:10:52 -0400
+Subject: drm/amd/display: Reject non-zero src_y and src_x for video planes
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Harry Wentland <harry.wentland@amd.com>
+
+commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream.
+
+[Why]
+This hasn't been well tested and leads to complete system hangs on DCN1
+based systems, possibly others.
+
+The system hang can be reproduced by gesturing the video on the YouTube
+Android app on ChromeOS into full screen.
+
+[How]
+Reject atomic commits with non-zero drm_plane_state.src_x or src_y values.
+
+v2:
+ - Add code comment describing the reason we're rejecting non-zero
+ src_x and src_y
+ - Drop gerrit Change-Id
+ - Add stable CC
+ - Based on amd-staging-drm-next
+
+v3: removed trailing whitespace
+
+Signed-off-by: Harry Wentland <harry.wentland@amd.com>
+Cc: stable@vger.kernel.org
+Cc: nicholas.kazlauskas@amd.com
+Cc: amd-gfx@lists.freedesktop.org
+Cc: alexander.deucher@amd.com
+Cc: Roman.Li@amd.com
+Cc: hersenxs.wu@amd.com
+Cc: danny.wang@amd.com
+Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Acked-by: Christian König <christian.koenig@amd.com>
+Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -3702,6 +3702,23 @@ static int fill_dc_scaling_info(const st
+ scaling_info->src_rect.y != 0))
+ return -EINVAL;
+
++ /*
++ * For reasons we don't (yet) fully understand a non-zero
++ * src_y coordinate into an NV12 buffer can cause a
++ * system hang. To avoid hangs (and maybe be overly cautious)
++ * let's reject both non-zero src_x and src_y.
++ *
++ * We currently know of only one use-case to reproduce a
++ * scenario with non-zero src_x and src_y for NV12, which
++ * is to gesture the YouTube Android app into full screen
++ * on ChromeOS.
++ */
++ if (state->fb &&
++ state->fb->format->format == DRM_FORMAT_NV12 &&
++ (scaling_info->src_rect.x != 0 ||
++ scaling_info->src_rect.y != 0))
++ return -EINVAL;
++
+ scaling_info->src_rect.width = state->src_w >> 16;
+ if (scaling_info->src_rect.width == 0)
+ return -EINVAL;
--- /dev/null
+From e2329e74a615cc58b25c42b7aa1477a5e3f6a435 Mon Sep 17 00:00:00 2001
+From: Aaron Liu <aaron.liu@amd.com>
+Date: Fri, 25 Jun 2021 13:50:19 +0800
+Subject: drm/amdgpu: enable sdma0 tmz for Raven/Renoir(V2)
+
+From: Aaron Liu <aaron.liu@amd.com>
+
+commit e2329e74a615cc58b25c42b7aa1477a5e3f6a435 upstream.
+
+Without driver loaded, SDMA0_UTCL1_PAGE.TMZ_ENABLE is set to 1
+by default for all asic. On Raven/Renoir, the sdma goldsetting
+changes SDMA0_UTCL1_PAGE.TMZ_ENABLE to 0.
+This patch restores SDMA0_UTCL1_PAGE.TMZ_ENABLE to 1.
+
+Signed-off-by: Aaron Liu <aaron.liu@amd.com>
+Acked-by: Luben Tuikov <luben.tuikov@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@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>
+
+---
+ drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+@@ -143,7 +143,7 @@ static const struct soc15_reg_golden gol
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC0_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_IB_CNTL, 0x800f0111, 0x00000100),
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
+- SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003c0),
++ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003e0),
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc000000, 0x00000000)
+ };
+
+@@ -269,7 +269,7 @@ static const struct soc15_reg_golden gol
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_POWER_CNTL, 0x003fff07, 0x40000051),
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC0_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
+- SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003c0),
++ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003e0),
+ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc000000, 0x03fbe1fe)
+ };
+
--- /dev/null
+From aa6158112645aae514982ad8d56df64428fcf203 Mon Sep 17 00:00:00 2001
+From: Joseph Greathouse <Joseph.Greathouse@amd.com>
+Date: Tue, 29 Jun 2021 21:08:52 -0500
+Subject: drm/amdgpu: Update NV SIMD-per-CU to 2
+
+From: Joseph Greathouse <Joseph.Greathouse@amd.com>
+
+commit aa6158112645aae514982ad8d56df64428fcf203 upstream.
+
+Navi series GPUs have 2 SIMDs per CU (and then 2 CUs per WGP).
+The NV enum headers incorrectly listed this as 4, which later meant
+we were incorrectly reporting the number of SIMDs in the HSA
+topology. This could cause problems down the line for user-space
+applications that want to launch a fixed amount of work to each
+SIMD.
+
+Signed-off-by: Joseph Greathouse <Joseph.Greathouse@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Felix Kuehling <Felix.Kuehling@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>
+
+---
+ drivers/gpu/drm/amd/include/navi10_enum.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/include/navi10_enum.h
++++ b/drivers/gpu/drm/amd/include/navi10_enum.h
+@@ -430,7 +430,7 @@ ARRAY_2D_DEPTH
+ */
+
+ typedef enum ENUM_NUM_SIMD_PER_CU {
+-NUM_SIMD_PER_CU = 0x00000004,
++NUM_SIMD_PER_CU = 0x00000002,
+ } ENUM_NUM_SIMD_PER_CU;
+
+ /*
--- /dev/null
+From 26c3e7fd5a3499e408915dadae5d5360790aae9a Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Tue, 27 Apr 2021 11:20:12 +0200
+Subject: drm/arm/malidp: Always list modifiers
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 26c3e7fd5a3499e408915dadae5d5360790aae9a upstream.
+
+Even when all we support is linear, make that explicit. Otherwise the
+uapi is rather confusing.
+
+Acked-by: Liviu Dudau <liviu.dudau@arm.com>
+Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Cc: stable@vger.kernel.org
+Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
+Cc: Liviu Dudau <liviu.dudau@arm.com>
+Cc: Brian Starkey <brian.starkey@arm.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-2-daniel.vetter@ffwll.ch
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/arm/malidp_planes.c
++++ b/drivers/gpu/drm/arm/malidp_planes.c
+@@ -922,6 +922,11 @@ static const struct drm_plane_helper_fun
+ .atomic_disable = malidp_de_plane_disable,
+ };
+
++static const uint64_t linear_only_modifiers[] = {
++ DRM_FORMAT_MOD_LINEAR,
++ DRM_FORMAT_MOD_INVALID
++};
++
+ int malidp_de_planes_init(struct drm_device *drm)
+ {
+ struct malidp_drm *malidp = drm->dev_private;
+@@ -985,8 +990,8 @@ int malidp_de_planes_init(struct drm_dev
+ */
+ ret = drm_universal_plane_init(drm, &plane->base, crtcs,
+ &malidp_de_plane_funcs, formats, n,
+- (id == DE_SMART) ? NULL : modifiers, plane_type,
+- NULL);
++ (id == DE_SMART) ? linear_only_modifiers : modifiers,
++ plane_type, NULL);
+
+ if (ret < 0)
+ goto cleanup;
--- /dev/null
+From 205bb69a90363541a634a662a599fddb95956524 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Fri, 30 Apr 2021 18:34:27 -0400
+Subject: drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 205bb69a90363541a634a662a599fddb95956524 upstream.
+
+While the DP specification isn't entirely clear on if this should be
+allowed or not, some branch devices report having downstream ports present
+while also reporting a downstream port count of 0. So to avoid breaking
+those devices, we need to handle this in drm_dp_read_downstream_info().
+
+So, to do this we assume there's no downstream port info when the
+downstream port count is 0.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
+Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3416
+Fixes: 3d3721ccb18a ("drm/i915/dp: Extract drm_dp_read_downstream_info()")
+Cc: <stable@vger.kernel.org> # v5.10+
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210430223428.10514-1-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_dp_helper.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/drm_dp_helper.c
++++ b/drivers/gpu/drm/drm_dp_helper.c
+@@ -602,7 +602,14 @@ int drm_dp_read_downstream_info(struct d
+ !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+ return 0;
+
++ /* Some branches advertise having 0 downstream ports, despite also advertising they have a
++ * downstream port present. The DP spec isn't clear on if this is allowed or not, but since
++ * some branches do it we need to handle it regardless.
++ */
+ len = drm_dp_downstream_port_count(dpcd);
++ if (!len)
++ return 0;
++
+ if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
+ len *= 4;
+
--- /dev/null
+From 35d3e8cb35e75450f87f87e3d314e2d418b6954b Mon Sep 17 00:00:00 2001
+From: Wayne Lin <Wayne.Lin@amd.com>
+Date: Wed, 16 Jun 2021 11:55:00 +0800
+Subject: drm/dp_mst: Do not set proposed vcpi directly
+
+From: Wayne Lin <Wayne.Lin@amd.com>
+
+commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream.
+
+[Why]
+When we receive CSN message to notify one port is disconnected, we will
+implicitly set its corresponding num_slots to 0. Later on, we will
+eventually call drm_dp_update_payload_part1() to arrange down streams.
+
+In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[]
+to do the update. Not specific to a target sink only. For example, if we
+light up 2 monitors, Monitor_A and Monitor_B, and then we unplug
+Monitor_B. Later on, when we call drm_dp_update_payload_part1() to try
+to update payload for Monitor_A, we'll also implicitly clean payload for
+Monitor_B at the same time. And finally, when we try to call
+drm_dp_update_payload_part1() to clean payload for Monitor_B, we will do
+nothing at this time since payload for Monitor_B has been cleaned up
+previously.
+
+For StarTech 1to3 DP hub, it seems like if we didn't update DPCD payload
+ID table then polling for "ACT Handled"(BIT_1 of DPCD 002C0h) will fail
+and this polling will last for 3 seconds.
+
+Therefore, guess the best way is we don't set the proposed_vcpi[]
+diretly. Let user of these herlper functions to set the proposed_vcpi
+directly.
+
+[How]
+1. Revert commit 7617e9621bf2 ("drm/dp_mst: clear time slots for ports
+invalid")
+2. Tackle the issue in previous commit by skipping those trasient
+proposed VCPIs. These stale VCPIs shoulde be explicitly cleared by
+user later on.
+
+Changes since v1:
+* Change debug macro to use drm_dbg_kms() instead
+* Amend the commit message to add Fixed & Cc tags
+
+Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
+Fixes: 7617e9621bf2 ("drm/dp_mst: clear time slots for ports invalid")
+Cc: Lyude Paul <lyude@redhat.com>
+Cc: Wayne Lin <Wayne.Lin@amd.com>
+Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Maxime Ripard <mripard@kernel.org>
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: dri-devel@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v5.5+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210616035501.3776-2-Wayne.Lin@amd.com
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++++++++-------------------------
+ 1 file changed, 10 insertions(+), 26 deletions(-)
+
+--- a/drivers/gpu/drm/drm_dp_mst_topology.c
++++ b/drivers/gpu/drm/drm_dp_mst_topology.c
+@@ -2499,7 +2499,7 @@ drm_dp_mst_handle_conn_stat(struct drm_d
+ {
+ struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
+ struct drm_dp_mst_port *port;
+- int old_ddps, old_input, ret, i;
++ int old_ddps, ret;
+ u8 new_pdt;
+ bool new_mcs;
+ bool dowork = false, create_connector = false;
+@@ -2531,7 +2531,6 @@ drm_dp_mst_handle_conn_stat(struct drm_d
+ }
+
+ old_ddps = port->ddps;
+- old_input = port->input;
+ port->input = conn_stat->input_port;
+ port->ldps = conn_stat->legacy_device_plug_status;
+ port->ddps = conn_stat->displayport_device_plug_status;
+@@ -2554,28 +2553,6 @@ drm_dp_mst_handle_conn_stat(struct drm_d
+ dowork = false;
+ }
+
+- if (!old_input && old_ddps != port->ddps && !port->ddps) {
+- for (i = 0; i < mgr->max_payloads; i++) {
+- struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
+- struct drm_dp_mst_port *port_validated;
+-
+- if (!vcpi)
+- continue;
+-
+- port_validated =
+- container_of(vcpi, struct drm_dp_mst_port, vcpi);
+- port_validated =
+- drm_dp_mst_topology_get_port_validated(mgr, port_validated);
+- if (!port_validated) {
+- mutex_lock(&mgr->payload_lock);
+- vcpi->num_slots = 0;
+- mutex_unlock(&mgr->payload_lock);
+- } else {
+- drm_dp_mst_topology_put_port(port_validated);
+- }
+- }
+- }
+-
+ if (port->connector)
+ drm_modeset_unlock(&mgr->base.lock);
+ else if (create_connector)
+@@ -3406,8 +3383,15 @@ int drm_dp_update_payload_part1(struct d
+ port = drm_dp_mst_topology_get_port_validated(
+ mgr, port);
+ if (!port) {
+- mutex_unlock(&mgr->payload_lock);
+- return -EINVAL;
++ if (vcpi->num_slots == payload->num_slots) {
++ cur_slots += vcpi->num_slots;
++ payload->start_slot = req_payload.start_slot;
++ continue;
++ } else {
++ drm_dbg_kms("Fail:set payload to invalid sink");
++ mutex_unlock(&mgr->payload_lock);
++ return -EINVAL;
++ }
+ }
+ put_port = true;
+ }
--- /dev/null
+From 07b72960d2b4a087ff2445e286159e69742069cc Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Thu, 17 Jun 2021 14:33:01 -0700
+Subject: drm/i915/display: Do not zero past infoframes.vsc
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 07b72960d2b4a087ff2445e286159e69742069cc upstream.
+
+intel_dp_vsc_sdp_unpack() was using a memset() size (36, struct dp_sdp)
+larger than the destination (24, struct drm_dp_vsc_sdp), clobbering
+fields in struct intel_crtc_state after infoframes.vsc. Use the actual
+target size for the memset().
+
+Fixes: 1b404b7dbb10 ("drm/i915/dp: Read out DP SDPs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
+Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210617213301.1824728-1-keescook@chromium.org
+(cherry picked from commit c88e2647c5bb45d04dc4302018ebe6ebbf331823)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_dp.c
++++ b/drivers/gpu/drm/i915/display/intel_dp.c
+@@ -5080,7 +5080,7 @@ static int intel_dp_vsc_sdp_unpack(struc
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+- memset(vsc, 0, size);
++ memset(vsc, 0, sizeof(*vsc));
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
--- /dev/null
+From 35cbb8c91e9cf310277d3dfb4d046df8edf2df33 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Tue, 27 Apr 2021 11:20:15 +0200
+Subject: drm/msm/mdp4: Fix modifier support enabling
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 35cbb8c91e9cf310277d3dfb4d046df8edf2df33 upstream.
+
+Setting the cap without the modifier list is very confusing to
+userspace. Fix that by listing the ones we support explicitly.
+
+Stable backport so that userspace can rely on this working in a
+reasonable way, i.e. that the cap set implies IN_FORMATS is available.
+
+Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Cc: stable@vger.kernel.org
+Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
+Cc: Rob Clark <robdclark@chromium.org>
+Cc: Jordan Crouse <jordan@cosmicpenguin.net>
+Cc: Emil Velikov <emil.velikov@collabora.com>
+Cc: Sam Ravnborg <sam@ravnborg.org>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-5-daniel.vetter@ffwll.ch
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
+ drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8 +++++++-
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
++++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+@@ -88,8 +88,6 @@ static int mdp4_hw_init(struct msm_kms *
+ if (mdp4_kms->rev > 1)
+ mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
+
+- dev->mode_config.allow_fb_modifiers = true;
+-
+ out:
+ pm_runtime_put_sync(dev->dev);
+
+--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
++++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+@@ -347,6 +347,12 @@ enum mdp4_pipe mdp4_plane_pipe(struct dr
+ return mdp4_plane->pipe;
+ }
+
++static const uint64_t supported_format_modifiers[] = {
++ DRM_FORMAT_MOD_SAMSUNG_64_32_TILE,
++ DRM_FORMAT_MOD_LINEAR,
++ DRM_FORMAT_MOD_INVALID
++};
++
+ /* initialize plane */
+ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
+ enum mdp4_pipe pipe_id, bool private_plane)
+@@ -375,7 +381,7 @@ struct drm_plane *mdp4_plane_init(struct
+ type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs,
+ mdp4_plane->formats, mdp4_plane->nformats,
+- NULL, type, NULL);
++ supported_format_modifiers, type, NULL);
+ if (ret)
+ goto fail;
+
--- /dev/null
+From cee93c028288b9af02919f3bd8593ba61d1e610d Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Tue, 27 Apr 2021 11:20:16 +0200
+Subject: drm/nouveau: Don't set allow_fb_modifiers explicitly
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit cee93c028288b9af02919f3bd8593ba61d1e610d upstream.
+
+Since
+
+commit 890880ddfdbe256083170866e49c87618b706ac7
+Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
+Date: Fri Jan 4 09:56:10 2019 +0100
+
+ drm: Auto-set allow_fb_modifiers when given modifiers at plane init
+
+this is done automatically as part of plane init, if drivers set the
+modifier list correctly. Which is the case here.
+
+Note that this fixes an inconsistency: We've set the cap everywhere,
+but only nv50+ supports modifiers. Hence cc stable, but not further
+back then the patch from Paul.
+
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Cc: stable@vger.kernel.org # v5.1 +
+Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Cc: Ben Skeggs <bskeggs@redhat.com>
+Cc: nouveau@lists.freedesktop.org
+Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-6-daniel.vetter@ffwll.ch
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_display.c
++++ b/drivers/gpu/drm/nouveau/nouveau_display.c
+@@ -700,7 +700,6 @@ nouveau_display_create(struct drm_device
+
+ dev->mode_config.preferred_depth = 24;
+ dev->mode_config.prefer_shadow = 1;
+- dev->mode_config.allow_fb_modifiers = true;
+
+ if (drm->client.device.info.chipset < 0x11)
+ dev->mode_config.async_page_flip = false;
--- /dev/null
+From 9ba85914c36c8fed9bf3e8b69c0782908c1247b7 Mon Sep 17 00:00:00 2001
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Tue, 29 Jun 2021 19:44:55 +0800
+Subject: drm/radeon: Add the missed drm_gem_object_put() in radeon_user_framebuffer_create()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+
+commit 9ba85914c36c8fed9bf3e8b69c0782908c1247b7 upstream.
+
+radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
+an error path. Add the missed function call to fix it.
+
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_display.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_display.c
++++ b/drivers/gpu/drm/radeon/radeon_display.c
+@@ -1334,6 +1334,7 @@ radeon_user_framebuffer_create(struct dr
+ /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */
+ if (obj->import_attach) {
+ DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n");
++ drm_gem_object_put(obj);
+ return ERR_PTR(-EINVAL);
+ }
+
--- /dev/null
+From c1bfd74bfef77bcefc88d12eaf8996c0dfd51331 Mon Sep 17 00:00:00 2001
+From: Tiezhu Yang <yangtiezhu@loongson.cn>
+Date: Mon, 28 Jun 2021 10:53:06 -0400
+Subject: drm/radeon: Call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64
+
+From: Tiezhu Yang <yangtiezhu@loongson.cn>
+
+commit c1bfd74bfef77bcefc88d12eaf8996c0dfd51331 upstream.
+
+On the Loongson64 platform used with Radeon GPU, shutdown or reboot failed
+when console=tty is in the boot cmdline.
+
+radeon_suspend_kms() puts the hw in the suspend state, especially set fb
+state as FBINFO_STATE_SUSPENDED:
+
+ if (fbcon) {
+ console_lock();
+ radeon_fbdev_set_suspend(rdev, 1);
+ console_unlock();
+ }
+
+Then avoid to do any more fb operations in the related functions:
+
+ if (p->state != FBINFO_STATE_RUNNING)
+ return;
+
+So call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64 to fix
+this issue, it looks like some kind of workaround like powerpc.
+
+Co-developed-by: Jianmin Lv <lvjianmin@loongson.cn>
+Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
+Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_drv.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/radeon/radeon_drv.c
++++ b/drivers/gpu/drm/radeon/radeon_drv.c
+@@ -416,13 +416,13 @@ radeon_pci_shutdown(struct pci_dev *pdev
+ if (radeon_device_is_virtual())
+ radeon_pci_remove(pdev);
+
+-#ifdef CONFIG_PPC64
++#if defined(CONFIG_PPC64) || defined(CONFIG_MACH_LOONGSON64)
+ /*
+ * Some adapters need to be suspended before a
+ * shutdown occurs in order to prevent an error
+- * during kexec.
+- * Make this power specific becauase it breaks
+- * some non-power boards.
++ * during kexec, shutdown or reboot.
++ * Make this power and Loongson specific because
++ * it breaks some other boards.
+ */
+ radeon_suspend_kms(pci_get_drvdata(pdev), true, true, false);
+ #endif
--- /dev/null
+From b354498bbe65c917d521b3b56317ddc9ab217425 Mon Sep 17 00:00:00 2001
+From: Thomas Hebb <tommyhebb@gmail.com>
+Date: Sun, 18 Apr 2021 19:03:04 -0700
+Subject: drm/rockchip: dsi: remove extra component_del() call
+
+From: Thomas Hebb <tommyhebb@gmail.com>
+
+commit b354498bbe65c917d521b3b56317ddc9ab217425 upstream.
+
+commit cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support") added
+this devcnt field and call to component_del(). However, these both
+appear to be erroneous changes left over from an earlier version of the
+patch. In the version merged, nothing ever modifies devcnt, meaning
+component_del() runs unconditionally and in addition to the
+component_del() calls in dw_mipi_dsi_rockchip_host_detach(). The second
+call fails to delete anything and produces a warning in dmesg.
+
+If we look at the previous version of the patch[1], however, we see that
+it had logic to calculate devcnt and call component_add() in certain
+situations. This was removed in v6, and the fact that the deletion code
+was not appears to have been an oversight.
+
+[1] https://patchwork.kernel.org/project/dri-devel/patch/20180821140515.22246-8-heiko@sntech.de/
+
+Fixes: cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/201385acb0eeb5dfb037afdc6a94bfbcdab97f99.1618797778.git.tommyhebb@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
++++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+@@ -243,7 +243,6 @@ struct dw_mipi_dsi_rockchip {
+ struct dw_mipi_dsi *dmd;
+ const struct rockchip_dw_dsi_chip_data *cdata;
+ struct dw_mipi_dsi_plat_data pdata;
+- int devcnt;
+ };
+
+ struct dphy_pll_parameter_map {
+@@ -1141,9 +1140,6 @@ static int dw_mipi_dsi_rockchip_remove(s
+ {
+ struct dw_mipi_dsi_rockchip *dsi = platform_get_drvdata(pdev);
+
+- if (dsi->devcnt == 0)
+- component_del(dsi->dev, &dw_mipi_dsi_rockchip_ops);
+-
+ dw_mipi_dsi_remove(dsi->dmd);
+
+ return 0;
--- /dev/null
+From be4306ad928fcf736cbe2616b6dd19d91f1bc083 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Tue, 13 Apr 2021 11:49:01 +0200
+Subject: drm/tegra: Don't set allow_fb_modifiers explicitly
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit be4306ad928fcf736cbe2616b6dd19d91f1bc083 upstream.
+
+Since
+
+commit 890880ddfdbe256083170866e49c87618b706ac7
+Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
+Date: Fri Jan 4 09:56:10 2019 +0100
+
+ drm: Auto-set allow_fb_modifiers when given modifiers at plane init
+
+this is done automatically as part of plane init, if drivers set the
+modifier list correctly. Which is the case here.
+
+It was slightly inconsistently though, since planes with only linear
+modifier support haven't listed that explicitly. Fix that, and cc:
+stable to allow userspace to rely on this. Again don't backport
+further than where Paul's patch got added.
+
+Cc: stable@vger.kernel.org # v5.1 +
+Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
+Acked-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Cc: Thierry Reding <thierry.reding@gmail.com>
+Cc: Jonathan Hunter <jonathanh@nvidia.com>
+Cc: linux-tegra@vger.kernel.org
+Link: https://patchwork.freedesktop.org/patch/msgid/20210413094904.3736372-10-daniel.vetter@ffwll.ch
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/tegra/dc.c | 10 ++++++++--
+ drivers/gpu/drm/tegra/drm.c | 2 --
+ 2 files changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/tegra/dc.c
++++ b/drivers/gpu/drm/tegra/dc.c
+@@ -947,6 +947,11 @@ static const struct drm_plane_helper_fun
+ .atomic_disable = tegra_cursor_atomic_disable,
+ };
+
++static const uint64_t linear_modifiers[] = {
++ DRM_FORMAT_MOD_LINEAR,
++ DRM_FORMAT_MOD_INVALID
++};
++
+ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
+ struct tegra_dc *dc)
+ {
+@@ -975,7 +980,7 @@ static struct drm_plane *tegra_dc_cursor
+
+ err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
+ &tegra_plane_funcs, formats,
+- num_formats, NULL,
++ num_formats, linear_modifiers,
+ DRM_PLANE_TYPE_CURSOR, NULL);
+ if (err < 0) {
+ kfree(plane);
+@@ -1094,7 +1099,8 @@ static struct drm_plane *tegra_dc_overla
+
+ err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
+ &tegra_plane_funcs, formats,
+- num_formats, NULL, type, NULL);
++ num_formats, linear_modifiers,
++ type, NULL);
+ if (err < 0) {
+ kfree(plane);
+ return ERR_PTR(err);
+--- a/drivers/gpu/drm/tegra/drm.c
++++ b/drivers/gpu/drm/tegra/drm.c
+@@ -1127,8 +1127,6 @@ static int host1x_drm_probe(struct host1
+ drm->mode_config.max_width = 4096;
+ drm->mode_config.max_height = 4096;
+
+- drm->mode_config.allow_fb_modifiers = true;
+-
+ drm->mode_config.normalize_zpos = true;
+
+ drm->mode_config.funcs = &tegra_drm_mode_config_funcs;
--- /dev/null
+From 47a50743031ad4138050ae6d266ddd3dfe845ead Mon Sep 17 00:00:00 2001
+From: Maxime Ripard <maxime@cerno.tech>
+Date: Fri, 7 May 2021 17:05:05 +0200
+Subject: drm/vc4: crtc: Skip the TXP
+
+From: Maxime Ripard <maxime@cerno.tech>
+
+commit 47a50743031ad4138050ae6d266ddd3dfe845ead upstream.
+
+The vc4_set_crtc_possible_masks is meant to run over all the encoders
+and then set their possible_crtcs mask to their associated pixelvalve.
+
+However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into
+a CRTC of its own"), the TXP has been turned to a CRTC and encoder of
+its own, and while it does indeed register an encoder, it no longer has
+an associated pixelvalve. The code will thus run over the TXP encoder
+and set a bogus possible_crtcs mask, overriding the one set in the TXP
+bind function.
+
+In order to fix this, let's skip any virtual encoder.
+
+Cc: <stable@vger.kernel.org> # v5.9+
+Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own")
+Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-3-maxime@cerno.tech
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vc4/vc4_crtc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/vc4/vc4_crtc.c
++++ b/drivers/gpu/drm/vc4/vc4_crtc.c
+@@ -1042,6 +1042,9 @@ static void vc4_set_crtc_possible_masks(
+ struct vc4_encoder *vc4_encoder;
+ int i;
+
++ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
++ continue;
++
+ vc4_encoder = to_vc4_encoder(encoder);
+ for (i = 0; i < ARRAY_SIZE(pv_data->encoder_types); i++) {
+ if (vc4_encoder->type == encoder_types[i]) {
--- /dev/null
+From 5b006000423667ef0f55721fc93e477b31f22d28 Mon Sep 17 00:00:00 2001
+From: Maxime Ripard <maxime@cerno.tech>
+Date: Fri, 7 May 2021 17:05:09 +0200
+Subject: drm/vc4: hdmi: Prevent clock unbalance
+
+From: Maxime Ripard <maxime@cerno.tech>
+
+commit 5b006000423667ef0f55721fc93e477b31f22d28 upstream.
+
+Since we fixed the hooks to disable the encoder at boot, we now have an
+unbalanced clk_disable call at boot since we never enabled them in the
+first place.
+
+Let's mimic the state of the hardware and enable the clocks at boot if
+the controller is enabled to get the use-count right.
+
+Cc: <stable@vger.kernel.org> # v5.10+
+Fixes: 09c438139b8f ("drm/vc4: hdmi: Implement finer-grained hooks")
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-7-maxime@cerno.tech
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vc4/vc4_hdmi.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
++++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
+@@ -1807,6 +1807,14 @@ static int vc4_hdmi_bind(struct device *
+ if (vc4_hdmi->variant->reset)
+ vc4_hdmi->variant->reset(vc4_hdmi);
+
++ if ((of_device_is_compatible(dev->of_node, "brcm,bcm2711-hdmi0") ||
++ of_device_is_compatible(dev->of_node, "brcm,bcm2711-hdmi1")) &&
++ HDMI_READ(HDMI_VID_CTL) & VC4_HD_VID_CTL_ENABLE) {
++ clk_prepare_enable(vc4_hdmi->pixel_clock);
++ clk_prepare_enable(vc4_hdmi->hsm_clock);
++ clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
++ }
++
+ pm_runtime_enable(dev);
+
+ drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
--- /dev/null
+From bf6de8e61509f3c957d7f75f017b18d40a18a950 Mon Sep 17 00:00:00 2001
+From: Maxime Ripard <maxime@cerno.tech>
+Date: Fri, 7 May 2021 17:05:04 +0200
+Subject: drm/vc4: txp: Properly set the possible_crtcs mask
+
+From: Maxime Ripard <maxime@cerno.tech>
+
+commit bf6de8e61509f3c957d7f75f017b18d40a18a950 upstream.
+
+The current code does a binary OR on the possible_crtcs variable of the
+TXP encoder, while we want to set it to that value instead.
+
+Cc: <stable@vger.kernel.org> # v5.9+
+Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own")
+Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-2-maxime@cerno.tech
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/vc4/vc4_txp.c
++++ b/drivers/gpu/drm/vc4/vc4_txp.c
+@@ -503,7 +503,7 @@ static int vc4_txp_bind(struct device *d
+ return ret;
+
+ encoder = &txp->connector.encoder;
+- encoder->possible_crtcs |= drm_crtc_mask(crtc);
++ encoder->possible_crtcs = drm_crtc_mask(crtc);
+
+ ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
+ dev_name(dev), txp);
--- /dev/null
+From d9ec9daa20eb8de1efe6abae78c9835ec8ed86f9 Mon Sep 17 00:00:00 2001
+From: Russ Weight <russell.h.weight@intel.com>
+Date: Mon, 14 Jun 2021 10:09:03 -0700
+Subject: fpga: stratix10-soc: Add missing fpga_mgr_free() call
+
+From: Russ Weight <russell.h.weight@intel.com>
+
+commit d9ec9daa20eb8de1efe6abae78c9835ec8ed86f9 upstream.
+
+The stratix10-soc driver uses fpga_mgr_create() function and is therefore
+responsible to call fpga_mgr_free() to release the class driver resources.
+Add a missing call to fpga_mgr_free in the s10_remove() function.
+
+Signed-off-by: Russ Weight <russell.h.weight@intel.com>
+Reviewed-by: Xu Yilun <yilun.xu@intel.com>
+Signed-off-by: Moritz Fischer <mdf@kernel.org>
+Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210614170909.232415-3-mdf@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/fpga/stratix10-soc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/fpga/stratix10-soc.c
++++ b/drivers/fpga/stratix10-soc.c
+@@ -454,6 +454,7 @@ static int s10_remove(struct platform_de
+ struct s10_priv *priv = mgr->priv;
+
+ fpga_mgr_unregister(mgr);
++ fpga_mgr_free(mgr);
+ stratix10_svc_free_channel(priv->chan);
+
+ return 0;
--- /dev/null
+From 09247e110b2efce3a104e57e887c373e0a57a412 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20L=C3=B6hle?= <CLoehle@hyperstone.com>
+Date: Wed, 12 May 2021 16:03:24 +0000
+Subject: mmc: core: Allow UHS-I voltage switch for SDSC cards if supported
+
+From: Christian Löhle <CLoehle@hyperstone.com>
+
+commit 09247e110b2efce3a104e57e887c373e0a57a412 upstream.
+
+While initializing an UHS-I SD card, the mmc core first tries to switch to
+1.8V I/O voltage, before it continues to change the settings for the bus
+speed mode.
+
+However, the current behaviour in the mmc core is inconsistent and doesn't
+conform to the SD spec. More precisely, an SD card that supports UHS-I must
+set both the SD_OCR_CCS bit and the SD_OCR_S18R bit in the OCR register
+response. When switching to 1.8V I/O the mmc core correctly checks both of
+the bits, but only the SD_OCR_S18R bit when changing the settings for bus
+speed mode.
+
+Rather than actually fixing the code to confirm to the SD spec, let's
+deliberately deviate from it by requiring only the SD_OCR_S18R bit for both
+parts. This enables us to support UHS-I for SDSC cards (outside spec),
+which is actually being supported by some existing SDSC cards. Moreover,
+this fixes the inconsistent behaviour.
+
+Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
+Link: https://lore.kernel.org/r/CWXP265MB26803AE79E0AD5ED083BF2A6C4529@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM
+Cc: stable@vger.kernel.org
+[Ulf: Rewrote commit message and comments to clarify the changes]
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/sd.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/core/sd.c
++++ b/drivers/mmc/core/sd.c
+@@ -847,11 +847,13 @@ try_again:
+ return err;
+
+ /*
+- * In case CCS and S18A in the response is set, start Signal Voltage
+- * Switch procedure. SPI mode doesn't support CMD11.
++ * In case the S18A bit is set in the response, let's start the signal
++ * voltage switch procedure. SPI mode doesn't support CMD11.
++ * Note that, according to the spec, the S18A bit is not valid unless
++ * the CCS bit is set as well. We deliberately deviate from the spec in
++ * regards to this, which allows UHS-I to be supported for SDSC cards.
+ */
+- if (!mmc_host_is_spi(host) && rocr &&
+- ((*rocr & 0x41000000) == 0x41000000)) {
++ if (!mmc_host_is_spi(host) && rocr && (*rocr & 0x01000000)) {
+ err = mmc_set_uhs_voltage(host, pocr);
+ if (err == -EAGAIN) {
+ retries--;
--- /dev/null
+From 77347eda64ed5c9383961d1de9165f9d0b7d8df6 Mon Sep 17 00:00:00 2001
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Date: Thu, 24 Jun 2021 17:16:14 +0200
+Subject: mmc: core: clear flags before allowing to retune
+
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+commit 77347eda64ed5c9383961d1de9165f9d0b7d8df6 upstream.
+
+It might be that something goes wrong during tuning so the MMC core will
+immediately trigger a retune. In our case it was:
+
+ - we sent a tuning block
+ - there was an error so we need to send an abort cmd to the eMMC
+ - the abort cmd had a CRC error
+ - retune was set by the MMC core
+
+This lead to a vicious circle causing a performance regression of 75%.
+So, clear retuning flags before we enable retuning to start with a known
+cleared state.
+
+Reported-by Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210624151616.38770-2-wsa+renesas@sang-engineering.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/core.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/core/core.c
++++ b/drivers/mmc/core/core.c
+@@ -936,11 +936,14 @@ int mmc_execute_tuning(struct mmc_card *
+
+ err = host->ops->execute_tuning(host, opcode);
+
+- if (err)
++ if (err) {
+ pr_err("%s: tuning execution failed: %d\n",
+ mmc_hostname(host), err);
+- else
++ } else {
++ host->retune_now = 0;
++ host->need_retune = 0;
+ mmc_retune_enable(host);
++ }
+
+ return err;
+ }
--- /dev/null
+From 94ee6782e045645abd9180ab9369b01293d862bd Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 3 May 2021 11:21:57 +0200
+Subject: mmc: sdhci-acpi: Disable write protect detection on Toshiba Encore 2 WT8-B
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 94ee6782e045645abd9180ab9369b01293d862bd upstream.
+
+On the Toshiba Encore 2 WT8-B the microSD slot always reports the card
+being write-protected even though microSD cards do not have a write-protect
+switch at all.
+
+Add a new DMI_QUIRK_SD_NO_WRITE_PROTECT quirk entry to sdhci-acpi.c's
+DMI quirk table for this.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/20210503092157.5689-1-hdegoede@redhat.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-acpi.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-acpi.c
++++ b/drivers/mmc/host/sdhci-acpi.c
+@@ -788,6 +788,17 @@ static const struct dmi_system_id sdhci_
+ },
+ .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT,
+ },
++ {
++ /*
++ * The Toshiba WT8-B's microSD slot always reports the card being
++ * write-protected.
++ */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "TOSHIBA ENCORE 2 WT8-B"),
++ },
++ .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT,
++ },
+ {} /* Terminating entry */
+ };
+
--- /dev/null
+From d0244847f9fc5e20df8b7483c8a4717fe0432d38 Mon Sep 17 00:00:00 2001
+From: Al Cooper <alcooperx@gmail.com>
+Date: Thu, 24 Jun 2021 12:30:45 -0400
+Subject: mmc: sdhci: Fix warning message when accessing RPMB in HS400 mode
+
+From: Al Cooper <alcooperx@gmail.com>
+
+commit d0244847f9fc5e20df8b7483c8a4717fe0432d38 upstream.
+
+When an eMMC device is being run in HS400 mode, any access to the
+RPMB device will cause the error message "mmc1: Invalid UHS-I mode
+selected". This happens as a result of tuning being disabled before
+RPMB access and then re-enabled after the RPMB access is complete.
+When tuning is re-enabled, the system has to switch from HS400
+to HS200 to do the tuning and then back to HS400. As part of
+sequence to switch from HS400 to HS200 the system is temporarily
+put into HS mode. When switching to HS mode, sdhci_get_preset_value()
+is called and does not have support for HS mode and prints the warning
+message and returns the preset for SDR12. The fix is to add support
+for MMC and SD HS modes to sdhci_get_preset_value().
+
+This can be reproduced on any system running eMMC in HS400 mode
+(not HS400ES) by using the "mmc" utility to run the following
+command: "mmc rpmb read-counter /dev/mmcblk0rpmb".
+
+Signed-off-by: Al Cooper <alcooperx@gmail.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: 52983382c74f ("mmc: sdhci: enhance preset value function")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210624163045.33651-1-alcooperx@gmail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci.c | 4 ++++
+ drivers/mmc/host/sdhci.h | 1 +
+ 2 files changed, 5 insertions(+)
+
+--- a/drivers/mmc/host/sdhci.c
++++ b/drivers/mmc/host/sdhci.c
+@@ -1813,6 +1813,10 @@ static u16 sdhci_get_preset_value(struct
+ u16 preset = 0;
+
+ switch (host->timing) {
++ case MMC_TIMING_MMC_HS:
++ case MMC_TIMING_SD_HS:
++ preset = sdhci_readw(host, SDHCI_PRESET_FOR_HIGH_SPEED);
++ break;
+ case MMC_TIMING_UHS_SDR12:
+ preset = sdhci_readw(host, SDHCI_PRESET_FOR_SDR12);
+ break;
+--- a/drivers/mmc/host/sdhci.h
++++ b/drivers/mmc/host/sdhci.h
+@@ -253,6 +253,7 @@
+
+ /* 60-FB reserved */
+
++#define SDHCI_PRESET_FOR_HIGH_SPEED 0x64
+ #define SDHCI_PRESET_FOR_SDR12 0x66
+ #define SDHCI_PRESET_FOR_SDR25 0x68
+ #define SDHCI_PRESET_FOR_SDR50 0x6A
--- /dev/null
+From 1ca46d3e43569186bd1decfb02a6b4c4ddb4304b Mon Sep 17 00:00:00 2001
+From: Maximilian Luz <luzmaximilian@gmail.com>
+Date: Wed, 12 May 2021 23:03:16 +0200
+Subject: pinctrl/amd: Add device HID for new AMD GPIO controller
+
+From: Maximilian Luz <luzmaximilian@gmail.com>
+
+commit 1ca46d3e43569186bd1decfb02a6b4c4ddb4304b upstream.
+
+Add device HID AMDI0031 to the AMD GPIO controller driver match table.
+This controller can be found on Microsoft Surface Laptop 4 devices and
+seems similar enough that we can just copy the existing AMDI0030 entry.
+
+Cc: <stable@vger.kernel.org> # 5.10+
+Tested-by: Sachi King <nakato@nakato.io>
+Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
+Link: https://lore.kernel.org/r/20210512210316.1982416-1-luzmaximilian@gmail.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-amd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pinctrl/pinctrl-amd.c
++++ b/drivers/pinctrl/pinctrl-amd.c
+@@ -952,6 +952,7 @@ static int amd_gpio_remove(struct platfo
+ static const struct acpi_device_id amd_gpio_acpi_match[] = {
+ { "AMD0030", 0 },
+ { "AMDI0030", 0},
++ { "AMDI0031", 0},
+ { },
+ };
+ MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match);
powerpc-mm-fix-lockup-on-kernel-exec-fault.patch
powerpc-barrier-avoid-collision-with-clang-s-__lwsync-macro.patch
powerpc-powernv-vas-release-reference-to-tgid-during-window-close.patch
+drm-amdgpu-update-nv-simd-per-cu-to-2.patch
+drm-amdgpu-enable-sdma0-tmz-for-raven-renoir-v2.patch
+drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch
+drm-radeon-call-radeon_suspend_kms-in-radeon_pci_shutdown-for-loongson64.patch
+drm-vc4-txp-properly-set-the-possible_crtcs-mask.patch
+drm-vc4-crtc-skip-the-txp.patch
+drm-vc4-hdmi-prevent-clock-unbalance.patch
+drm-dp-handle-zeroed-port-counts-in-drm_dp_read_downstream_info.patch
+drm-dp_mst-do-not-set-proposed-vcpi-directly.patch
+drm-rockchip-dsi-remove-extra-component_del-call.patch
+drm-amd-display-fix-incorrrect-valid-irq-check.patch
+pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch
+drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch
+drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch
+drm-msm-mdp4-fix-modifier-support-enabling.patch
+drm-arm-malidp-always-list-modifiers.patch
+drm-nouveau-don-t-set-allow_fb_modifiers-explicitly.patch
+drm-i915-display-do-not-zero-past-infoframes.vsc.patch
+mmc-sdhci-acpi-disable-write-protect-detection-on-toshiba-encore-2-wt8-b.patch
+mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch
+mmc-core-clear-flags-before-allowing-to-retune.patch
+mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch
+ata-ahci_sunxi-disable-dipm.patch
+arm64-tlb-fix-the-ttl-value-of-tlb_get_level.patch
+cpu-hotplug-cure-the-cpusets-trainwreck.patch
+clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch
+fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
