--- /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
+@@ -348,7 +348,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;
+ }
+
+@@ -1186,6 +1234,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
+@@ -2649,6 +2649,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 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 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 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
+@@ -1333,6 +1333,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 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
+@@ -231,7 +231,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 {
+@@ -1001,9 +1000,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
+@@ -919,6 +919,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)
+ {
+@@ -947,7 +952,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);
+@@ -1065,7 +1070,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
+@@ -122,8 +122,6 @@ static int tegra_drm_load(struct drm_dev
+ 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 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
+@@ -476,6 +476,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
+@@ -793,11 +793,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
+@@ -953,11 +953,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 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
+@@ -1511,6 +1511,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
+@@ -261,6 +261,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
+@@ -958,6 +958,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);
perf-bench-fix-2-memory-sanitizer-warnings.patch
powerpc-mm-fix-lockup-on-kernel-exec-fault.patch
powerpc-barrier-avoid-collision-with-clang-s-__lwsync-macro.patch
+drm-amdgpu-update-nv-simd-per-cu-to-2.patch
+drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.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
+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
+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
