From 0d2abd2d88be73d3f42561d71c6058a767d4e16d Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 18 Sep 2021 14:38:35 +0200 Subject: [PATCH] 5.10-stable patches added patches: arm64-sve-use-correct-size-when-reinitialising-sve-state.patch bnx2x-fix-enabling-network-interfaces-without-vfs.patch btrfs-fix-upper-limit-for-max_inline-for-page-size-64k.patch drm-amd-amdgpu-increase-hwip_max_instance-to-10.patch drm-bridge-lt9611-fix-handling-of-4k-panels.patch io_uring-ensure-symmetry-in-handling-iter-types-in-loop_rw_iter.patch pci-add-amd-gpu-multi-function-power-dependencies.patch pm-base-power-don-t-try-to-use-non-existing-rtc-for-storing-data.patch xen-reset-legacy-rtc-flag-for-pv-domu.patch --- ...t-size-when-reinitialising-sve-state.patch | 45 +++++++++ ...bling-network-interfaces-without-vfs.patch | 36 ++++++++ ...mit-for-max_inline-for-page-size-64k.patch | 91 +++++++++++++++++++ ...gpu-increase-hwip_max_instance-to-10.patch | 37 ++++++++ ...dge-lt9611-fix-handling-of-4k-panels.patch | 46 ++++++++++ ...-handling-iter-types-in-loop_rw_iter.patch | 45 +++++++++ ...pu-multi-function-power-dependencies.patch | 63 +++++++++++++ ...se-non-existing-rtc-for-storing-data.patch | 62 +++++++++++++ queue-5.10/series | 9 ++ ...en-reset-legacy-rtc-flag-for-pv-domu.patch | 71 +++++++++++++++ 10 files changed, 505 insertions(+) create mode 100644 queue-5.10/arm64-sve-use-correct-size-when-reinitialising-sve-state.patch create mode 100644 queue-5.10/bnx2x-fix-enabling-network-interfaces-without-vfs.patch create mode 100644 queue-5.10/btrfs-fix-upper-limit-for-max_inline-for-page-size-64k.patch create mode 100644 queue-5.10/drm-amd-amdgpu-increase-hwip_max_instance-to-10.patch create mode 100644 queue-5.10/drm-bridge-lt9611-fix-handling-of-4k-panels.patch create mode 100644 queue-5.10/io_uring-ensure-symmetry-in-handling-iter-types-in-loop_rw_iter.patch create mode 100644 queue-5.10/pci-add-amd-gpu-multi-function-power-dependencies.patch create mode 100644 queue-5.10/pm-base-power-don-t-try-to-use-non-existing-rtc-for-storing-data.patch create mode 100644 queue-5.10/series create mode 100644 queue-5.10/xen-reset-legacy-rtc-flag-for-pv-domu.patch diff --git a/queue-5.10/arm64-sve-use-correct-size-when-reinitialising-sve-state.patch b/queue-5.10/arm64-sve-use-correct-size-when-reinitialising-sve-state.patch new file mode 100644 index 00000000000..89dc01c7d78 --- /dev/null +++ b/queue-5.10/arm64-sve-use-correct-size-when-reinitialising-sve-state.patch @@ -0,0 +1,45 @@ +From e35ac9d0b56e9efefaeeb84b635ea26c2839ea86 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Thu, 9 Sep 2021 17:53:56 +0100 +Subject: arm64/sve: Use correct size when reinitialising SVE state + +From: Mark Brown + +commit e35ac9d0b56e9efefaeeb84b635ea26c2839ea86 upstream. + +When we need a buffer for SVE register state we call sve_alloc() to make +sure that one is there. In order to avoid repeated allocations and frees +we keep the buffer around unless we change vector length and just memset() +it to ensure a clean register state. The function that deals with this +takes the task to operate on as an argument, however in the case where we +do a memset() we initialise using the SVE state size for the current task +rather than the task passed as an argument. + +This is only an issue in the case where we are setting the register state +for a task via ptrace and the task being configured has a different vector +length to the task tracing it. In the case where the buffer is larger in +the traced process we will leak old state from the traced process to +itself, in the case where the buffer is smaller in the traced process we +will overflow the buffer and corrupt memory. + +Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") +Cc: # 4.15.x +Signed-off-by: Mark Brown +Link: https://lore.kernel.org/r/20210909165356.10675-1-broonie@kernel.org +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/fpsimd.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/kernel/fpsimd.c ++++ b/arch/arm64/kernel/fpsimd.c +@@ -510,7 +510,7 @@ size_t sve_state_size(struct task_struct + void sve_alloc(struct task_struct *task) + { + if (task->thread.sve_state) { +- memset(task->thread.sve_state, 0, sve_state_size(current)); ++ memset(task->thread.sve_state, 0, sve_state_size(task)); + return; + } + diff --git a/queue-5.10/bnx2x-fix-enabling-network-interfaces-without-vfs.patch b/queue-5.10/bnx2x-fix-enabling-network-interfaces-without-vfs.patch new file mode 100644 index 00000000000..26826822158 --- /dev/null +++ b/queue-5.10/bnx2x-fix-enabling-network-interfaces-without-vfs.patch @@ -0,0 +1,36 @@ +From 52ce14c134a003fee03d8fc57442c05a55b53715 Mon Sep 17 00:00:00 2001 +From: Adrian Bunk +Date: Sun, 12 Sep 2021 22:05:23 +0300 +Subject: bnx2x: Fix enabling network interfaces without VFs + +From: Adrian Bunk + +commit 52ce14c134a003fee03d8fc57442c05a55b53715 upstream. + +This function is called to enable SR-IOV when available, +not enabling interfaces without VFs was a regression. + +Fixes: 65161c35554f ("bnx2x: Fix missing error code in bnx2x_iov_init_one()") +Signed-off-by: Adrian Bunk +Reported-by: YunQiang Su +Tested-by: YunQiang Su +Cc: stable@vger.kernel.org +Acked-by: Shai Malin +Link: https://lore.kernel.org/r/20210912190523.27991-1-bunk@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c ++++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c +@@ -1225,7 +1225,7 @@ int bnx2x_iov_init_one(struct bnx2x *bp, + + /* SR-IOV capability was enabled but there are no VFs*/ + if (iov->total == 0) { +- err = -EINVAL; ++ err = 0; + goto failed; + } + diff --git a/queue-5.10/btrfs-fix-upper-limit-for-max_inline-for-page-size-64k.patch b/queue-5.10/btrfs-fix-upper-limit-for-max_inline-for-page-size-64k.patch new file mode 100644 index 00000000000..f70028da6a4 --- /dev/null +++ b/queue-5.10/btrfs-fix-upper-limit-for-max_inline-for-page-size-64k.patch @@ -0,0 +1,91 @@ +From 6f93e834fa7c5faa0372e46828b4b2a966ac61d7 Mon Sep 17 00:00:00 2001 +From: Anand Jain +Date: Tue, 10 Aug 2021 23:23:44 +0800 +Subject: btrfs: fix upper limit for max_inline for page size 64K + +From: Anand Jain + +commit 6f93e834fa7c5faa0372e46828b4b2a966ac61d7 upstream. + +The mount option max_inline ranges from 0 to the sectorsize (which is +now equal to page size). But we parse the mount options too early and +before the actual sectorsize is read from the superblock. So the upper +limit of max_inline is unaware of the actual sectorsize and is limited +by the temporary sectorsize 4096, even on a system where the default +sectorsize is 64K. + +Fix this by reading the superblock sectorsize before the mount option +parse. + +Reported-by: Alexander Tsvetkov +CC: stable@vger.kernel.org # 5.4+ +Signed-off-by: Anand Jain +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Anand Jain +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 45 +++++++++++++++++++++++---------------------- + 1 file changed, 23 insertions(+), 22 deletions(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -3019,6 +3019,29 @@ int __cold open_ctree(struct super_block + */ + fs_info->compress_type = BTRFS_COMPRESS_ZLIB; + ++ /* ++ * Flag our filesystem as having big metadata blocks if they are bigger ++ * than the page size ++ */ ++ if (btrfs_super_nodesize(disk_super) > PAGE_SIZE) { ++ if (!(features & BTRFS_FEATURE_INCOMPAT_BIG_METADATA)) ++ btrfs_info(fs_info, ++ "flagging fs with big metadata feature"); ++ features |= BTRFS_FEATURE_INCOMPAT_BIG_METADATA; ++ } ++ ++ /* Set up fs_info before parsing mount options */ ++ nodesize = btrfs_super_nodesize(disk_super); ++ sectorsize = btrfs_super_sectorsize(disk_super); ++ stripesize = sectorsize; ++ fs_info->dirty_metadata_batch = nodesize * (1 + ilog2(nr_cpu_ids)); ++ fs_info->delalloc_batch = sectorsize * 512 * (1 + ilog2(nr_cpu_ids)); ++ ++ /* Cache block sizes */ ++ fs_info->nodesize = nodesize; ++ fs_info->sectorsize = sectorsize; ++ fs_info->stripesize = stripesize; ++ + ret = btrfs_parse_options(fs_info, options, sb->s_flags); + if (ret) { + err = ret; +@@ -3046,28 +3069,6 @@ int __cold open_ctree(struct super_block + btrfs_info(fs_info, "has skinny extents"); + + /* +- * flag our filesystem as having big metadata blocks if +- * they are bigger than the page size +- */ +- if (btrfs_super_nodesize(disk_super) > PAGE_SIZE) { +- if (!(features & BTRFS_FEATURE_INCOMPAT_BIG_METADATA)) +- btrfs_info(fs_info, +- "flagging fs with big metadata feature"); +- features |= BTRFS_FEATURE_INCOMPAT_BIG_METADATA; +- } +- +- nodesize = btrfs_super_nodesize(disk_super); +- sectorsize = btrfs_super_sectorsize(disk_super); +- stripesize = sectorsize; +- fs_info->dirty_metadata_batch = nodesize * (1 + ilog2(nr_cpu_ids)); +- fs_info->delalloc_batch = sectorsize * 512 * (1 + ilog2(nr_cpu_ids)); +- +- /* Cache block sizes */ +- fs_info->nodesize = nodesize; +- fs_info->sectorsize = sectorsize; +- fs_info->stripesize = stripesize; +- +- /* + * mixed block groups end up with duplicate but slightly offset + * extent buffers for the same range. It leads to corruptions + */ diff --git a/queue-5.10/drm-amd-amdgpu-increase-hwip_max_instance-to-10.patch b/queue-5.10/drm-amd-amdgpu-increase-hwip_max_instance-to-10.patch new file mode 100644 index 00000000000..7ba422017d1 --- /dev/null +++ b/queue-5.10/drm-amd-amdgpu-increase-hwip_max_instance-to-10.patch @@ -0,0 +1,37 @@ +From 67a44e659888569a133a8f858c8230e9d7aad1d5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ernst=20Sj=C3=B6strand?= +Date: Thu, 2 Sep 2021 09:50:27 +0200 +Subject: drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ernst Sjöstrand + +commit 67a44e659888569a133a8f858c8230e9d7aad1d5 upstream. + +Seems like newer cards can have even more instances now. +Found by UBSAN: array-index-out-of-bounds in +drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:318:29 +index 8 is out of range for type 'uint32_t *[8]' + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1697 +Cc: stable@vger.kernel.org +Signed-off-by: Ernst Sjöstrand +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h +@@ -717,7 +717,7 @@ enum amd_hw_ip_block_type { + MAX_HWIP + }; + +-#define HWIP_MAX_INSTANCE 8 ++#define HWIP_MAX_INSTANCE 10 + + struct amd_powerplay { + void *pp_handle; diff --git a/queue-5.10/drm-bridge-lt9611-fix-handling-of-4k-panels.patch b/queue-5.10/drm-bridge-lt9611-fix-handling-of-4k-panels.patch new file mode 100644 index 00000000000..93036c2e58f --- /dev/null +++ b/queue-5.10/drm-bridge-lt9611-fix-handling-of-4k-panels.patch @@ -0,0 +1,46 @@ +From d1a97648ae028a44536927c87837c45ada7141c9 Mon Sep 17 00:00:00 2001 +From: Robert Foss +Date: Thu, 17 Dec 2020 15:09:33 +0100 +Subject: drm/bridge: lt9611: Fix handling of 4k panels + +From: Robert Foss + +commit d1a97648ae028a44536927c87837c45ada7141c9 upstream. + +4k requires two dsi pipes, so don't report MODE_OK when only a +single pipe is configured. But rather report MODE_PANEL to +signal that requirements of the panel are not being met. + +Reported-by: Peter Collingbourne +Suggested-by: Peter Collingbourne +Signed-off-by: Robert Foss +Tested-by: John Stultz +Tested-by: Anibal Limon +Tested-by: Peter Collingbourne +Reviewed-by: Bjorn Andersson +Acked-by: Vinod Koul +Link: https://patchwork.freedesktop.org/patch/msgid/20201217140933.1133969-1-robert.foss@linaro.org +Cc: Peter Collingbourne +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/bridge/lontium-lt9611.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/bridge/lontium-lt9611.c ++++ b/drivers/gpu/drm/bridge/lontium-lt9611.c +@@ -867,8 +867,14 @@ static enum drm_mode_status lt9611_bridg + const struct drm_display_mode *mode) + { + struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode); ++ struct lt9611 *lt9611 = bridge_to_lt9611(bridge); + +- return lt9611_mode ? MODE_OK : MODE_BAD; ++ if (!lt9611_mode) ++ return MODE_BAD; ++ else if (lt9611_mode->intfs > 1 && !lt9611->dsi1) ++ return MODE_PANEL; ++ else ++ return MODE_OK; + } + + static void lt9611_bridge_pre_enable(struct drm_bridge *bridge) diff --git a/queue-5.10/io_uring-ensure-symmetry-in-handling-iter-types-in-loop_rw_iter.patch b/queue-5.10/io_uring-ensure-symmetry-in-handling-iter-types-in-loop_rw_iter.patch new file mode 100644 index 00000000000..06f023d298d --- /dev/null +++ b/queue-5.10/io_uring-ensure-symmetry-in-handling-iter-types-in-loop_rw_iter.patch @@ -0,0 +1,45 @@ +From 16c8d2df7ec0eed31b7d3b61cb13206a7fb930cc Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Sun, 12 Sep 2021 06:45:07 -0600 +Subject: io_uring: ensure symmetry in handling iter types in loop_rw_iter() + +From: Jens Axboe + +commit 16c8d2df7ec0eed31b7d3b61cb13206a7fb930cc upstream. + +When setting up the next segment, we check what type the iter is and +handle it accordingly. However, when incrementing and processed amount +we do not, and both iter advance and addr/len are adjusted, regardless +of type. Split the increment side just like we do on the setup side. + +Fixes: 4017eb91a9e7 ("io_uring: make loop_rw_iter() use original user supplied pointers") +Cc: stable@vger.kernel.org +Reported-by: Valentina Palmiotti +Reviewed-by: Pavel Begunkov +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + fs/io_uring.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -3206,12 +3206,15 @@ static ssize_t loop_rw_iter(int rw, stru + ret = nr; + break; + } ++ if (!iov_iter_is_bvec(iter)) { ++ iov_iter_advance(iter, nr); ++ } else { ++ req->rw.len -= nr; ++ req->rw.addr += nr; ++ } + ret += nr; + if (nr != iovec.iov_len) + break; +- req->rw.len -= nr; +- req->rw.addr += nr; +- iov_iter_advance(iter, nr); + } + + return ret; diff --git a/queue-5.10/pci-add-amd-gpu-multi-function-power-dependencies.patch b/queue-5.10/pci-add-amd-gpu-multi-function-power-dependencies.patch new file mode 100644 index 00000000000..047eae9072c --- /dev/null +++ b/queue-5.10/pci-add-amd-gpu-multi-function-power-dependencies.patch @@ -0,0 +1,63 @@ +From 60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a Mon Sep 17 00:00:00 2001 +From: Evan Quan +Date: Fri, 3 Sep 2021 14:33:11 +0800 +Subject: PCI: Add AMD GPU multi-function power dependencies + +From: Evan Quan + +commit 60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a upstream. + +Some AMD GPUs have built-in USB xHCI and USB Type-C UCSI controllers with +power dependencies between the GPU and the other functions as in +6d2e369f0d4c ("PCI: Add NVIDIA GPU multi-function power dependencies"). + +Add device link support for the AMD integrated USB xHCI and USB Type-C UCSI +controllers. + +Without this, runtime power management, including GPU resume and temp and +fan sensors don't work correctly. + +Reported-at: https://gitlab.freedesktop.org/drm/amd/-/issues/1704 +Link: https://lore.kernel.org/r/20210903063311.3606226-1-evan.quan@amd.com +Signed-off-by: Evan Quan +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/quirks.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -5346,7 +5346,7 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR + PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda); + + /* +- * Create device link for NVIDIA GPU with integrated USB xHCI Host ++ * Create device link for GPUs with integrated USB xHCI Host + * controller to VGA. + */ + static void quirk_gpu_usb(struct pci_dev *usb) +@@ -5355,9 +5355,11 @@ static void quirk_gpu_usb(struct pci_dev + } + DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID, + PCI_CLASS_SERIAL_USB, 8, quirk_gpu_usb); ++DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID, ++ PCI_CLASS_SERIAL_USB, 8, quirk_gpu_usb); + + /* +- * Create device link for NVIDIA GPU with integrated Type-C UCSI controller ++ * Create device link for GPUs with integrated Type-C UCSI controller + * to VGA. Currently there is no class code defined for UCSI device over PCI + * so using UNKNOWN class for now and it will be updated when UCSI + * over PCI gets a class code. +@@ -5370,6 +5372,9 @@ static void quirk_gpu_usb_typec_ucsi(str + DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID, + PCI_CLASS_SERIAL_UNKNOWN, 8, + quirk_gpu_usb_typec_ucsi); ++DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID, ++ PCI_CLASS_SERIAL_UNKNOWN, 8, ++ quirk_gpu_usb_typec_ucsi); + + /* + * Enable the NVIDIA GPU integrated HDA controller if the BIOS left it diff --git a/queue-5.10/pm-base-power-don-t-try-to-use-non-existing-rtc-for-storing-data.patch b/queue-5.10/pm-base-power-don-t-try-to-use-non-existing-rtc-for-storing-data.patch new file mode 100644 index 00000000000..73e8420f3e2 --- /dev/null +++ b/queue-5.10/pm-base-power-don-t-try-to-use-non-existing-rtc-for-storing-data.patch @@ -0,0 +1,62 @@ +From 0560204b360a332c321124dbc5cdfd3364533a74 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Fri, 3 Sep 2021 10:49:36 +0200 +Subject: PM: base: power: don't try to use non-existing RTC for storing data + +From: Juergen Gross + +commit 0560204b360a332c321124dbc5cdfd3364533a74 upstream. + +If there is no legacy RTC device, don't try to use it for storing trace +data across suspend/resume. + +Cc: +Signed-off-by: Juergen Gross +Reviewed-by: Rafael J. Wysocki +Link: https://lore.kernel.org/r/20210903084937.19392-2-jgross@suse.com +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/trace.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/base/power/trace.c ++++ b/drivers/base/power/trace.c +@@ -13,6 +13,7 @@ + #include + #include + #include ++#include + + #include + +@@ -165,6 +166,9 @@ void generate_pm_trace(const void *trace + const char *file = *(const char **)(tracedata + 2); + unsigned int user_hash_value, file_hash_value; + ++ if (!x86_platform.legacy.rtc) ++ return; ++ + user_hash_value = user % USERHASH; + file_hash_value = hash_string(lineno, file, FILEHASH); + set_magic_time(user_hash_value, file_hash_value, dev_hash_value); +@@ -267,6 +271,9 @@ static struct notifier_block pm_trace_nb + + static int __init early_resume_init(void) + { ++ if (!x86_platform.legacy.rtc) ++ return 0; ++ + hash_value_early_read = read_magic_time(); + register_pm_notifier(&pm_trace_nb); + return 0; +@@ -277,6 +284,9 @@ static int __init late_resume_init(void) + unsigned int val = hash_value_early_read; + unsigned int user, file, dev; + ++ if (!x86_platform.legacy.rtc) ++ return 0; ++ + user = val % USERHASH; + val = val / USERHASH; + file = val % FILEHASH; diff --git a/queue-5.10/series b/queue-5.10/series new file mode 100644 index 00000000000..387f7efd73f --- /dev/null +++ b/queue-5.10/series @@ -0,0 +1,9 @@ +drm-bridge-lt9611-fix-handling-of-4k-panels.patch +btrfs-fix-upper-limit-for-max_inline-for-page-size-64k.patch +io_uring-ensure-symmetry-in-handling-iter-types-in-loop_rw_iter.patch +xen-reset-legacy-rtc-flag-for-pv-domu.patch +bnx2x-fix-enabling-network-interfaces-without-vfs.patch +arm64-sve-use-correct-size-when-reinitialising-sve-state.patch +pm-base-power-don-t-try-to-use-non-existing-rtc-for-storing-data.patch +pci-add-amd-gpu-multi-function-power-dependencies.patch +drm-amd-amdgpu-increase-hwip_max_instance-to-10.patch diff --git a/queue-5.10/xen-reset-legacy-rtc-flag-for-pv-domu.patch b/queue-5.10/xen-reset-legacy-rtc-flag-for-pv-domu.patch new file mode 100644 index 00000000000..e62ab551250 --- /dev/null +++ b/queue-5.10/xen-reset-legacy-rtc-flag-for-pv-domu.patch @@ -0,0 +1,71 @@ +From f68aa100d815b5b4467fd1c3abbe3b99d65fd028 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Fri, 3 Sep 2021 10:49:37 +0200 +Subject: xen: reset legacy rtc flag for PV domU + +From: Juergen Gross + +commit f68aa100d815b5b4467fd1c3abbe3b99d65fd028 upstream. + +A Xen PV guest doesn't have a legacy RTC device, so reset the legacy +RTC flag. Otherwise the following WARN splat will occur at boot: + +[ 1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210 +[ 1.333404] Modules linked in: +[ 1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0-rc7-default+ #282 +[ 1.333404] RIP: e030:mc146818_get_time+0x1be/0x210 +[ 1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff +[ 1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002 +[ 1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000 +[ 1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d +[ 1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000 +[ 1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200 +[ 1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4 +[ 1.333404] FS: 0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000 +[ 1.333404] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660 +[ 1.333404] Call Trace: +[ 1.333404] ? wakeup_sources_sysfs_init+0x30/0x30 +[ 1.333404] ? rdinit_setup+0x2b/0x2b +[ 1.333404] early_resume_init+0x23/0xa4 +[ 1.333404] ? cn_proc_init+0x36/0x36 +[ 1.333404] do_one_initcall+0x3e/0x200 +[ 1.333404] kernel_init_freeable+0x232/0x28e +[ 1.333404] ? rest_init+0xd0/0xd0 +[ 1.333404] kernel_init+0x16/0x120 +[ 1.333404] ret_from_fork+0x1f/0x30 + +Cc: +Fixes: 8d152e7a5c7537 ("x86/rtc: Replace paravirt rtc check with platform legacy quirk") +Signed-off-by: Juergen Gross +Reviewed-by: Boris Ostrovsky +Link: https://lore.kernel.org/r/20210903084937.19392-3-jgross@suse.com +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/xen/enlighten_pv.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/arch/x86/xen/enlighten_pv.c ++++ b/arch/x86/xen/enlighten_pv.c +@@ -1204,6 +1204,11 @@ static void __init xen_dom0_set_legacy_f + x86_platform.legacy.rtc = 1; + } + ++static void __init xen_domu_set_legacy_features(void) ++{ ++ x86_platform.legacy.rtc = 0; ++} ++ + /* First C function to be called on Xen boot */ + asmlinkage __visible void __init xen_start_kernel(void) + { +@@ -1356,6 +1361,8 @@ asmlinkage __visible void __init xen_sta + add_preferred_console("xenboot", 0, NULL); + if (pci_xen) + x86_init.pci.arch_init = pci_xen_init; ++ x86_platform.set_legacy_features = ++ xen_domu_set_legacy_features; + } else { + const struct dom0_vga_console_info *info = + (void *)((char *)xen_start_info + -- 2.47.2