From 72b83ab0926613a5ef5e41f99e2702c24c64aa43 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 31 Aug 2020 14:07:33 +0200 Subject: [PATCH] 4.19-stable patches added patches: device-property-fix-the-secondary-firmware-node-handling-in-set_primary_fwnode.patch drm-amd-pm-correct-vega10-swctf-limit-setting.patch drm-amd-pm-correct-vega12-swctf-limit-setting.patch drm-amdgpu-fix-buffer-overflow-in-info-ioctl.patch genirq-matrix-deal-with-the-sillyness-of-for_each_cpu-on-up.patch irqchip-stm32-exti-avoid-losing-interrupts-due-to-clearing-pending-bits-by-mistake.patch pm-sleep-core-fix-the-handling-of-pending-runtime-resume-requests.patch --- ...-node-handling-in-set_primary_fwnode.patch | 59 +++++++++++++ ...m-correct-vega10-swctf-limit-setting.patch | 46 +++++++++++ ...m-correct-vega12-swctf-limit-setting.patch | 43 ++++++++++ ...pu-fix-buffer-overflow-in-info-ioctl.patch | 39 +++++++++ ...-the-sillyness-of-for_each_cpu-on-up.patch | 48 +++++++++++ ...-to-clearing-pending-bits-by-mistake.patch | 72 ++++++++++++++++ ...g-of-pending-runtime-resume-requests.patch | 82 +++++++++++++++++++ queue-4.19/series | 7 ++ 8 files changed, 396 insertions(+) create mode 100644 queue-4.19/device-property-fix-the-secondary-firmware-node-handling-in-set_primary_fwnode.patch create mode 100644 queue-4.19/drm-amd-pm-correct-vega10-swctf-limit-setting.patch create mode 100644 queue-4.19/drm-amd-pm-correct-vega12-swctf-limit-setting.patch create mode 100644 queue-4.19/drm-amdgpu-fix-buffer-overflow-in-info-ioctl.patch create mode 100644 queue-4.19/genirq-matrix-deal-with-the-sillyness-of-for_each_cpu-on-up.patch create mode 100644 queue-4.19/irqchip-stm32-exti-avoid-losing-interrupts-due-to-clearing-pending-bits-by-mistake.patch create mode 100644 queue-4.19/pm-sleep-core-fix-the-handling-of-pending-runtime-resume-requests.patch diff --git a/queue-4.19/device-property-fix-the-secondary-firmware-node-handling-in-set_primary_fwnode.patch b/queue-4.19/device-property-fix-the-secondary-firmware-node-handling-in-set_primary_fwnode.patch new file mode 100644 index 00000000000..0b4a7e4d473 --- /dev/null +++ b/queue-4.19/device-property-fix-the-secondary-firmware-node-handling-in-set_primary_fwnode.patch @@ -0,0 +1,59 @@ +From c15e1bdda4365a5f17cdadf22bf1c1df13884a9e Mon Sep 17 00:00:00 2001 +From: Heikki Krogerus +Date: Fri, 21 Aug 2020 13:53:42 +0300 +Subject: device property: Fix the secondary firmware node handling in set_primary_fwnode() + +From: Heikki Krogerus + +commit c15e1bdda4365a5f17cdadf22bf1c1df13884a9e upstream. + +When the primary firmware node pointer is removed from a +device (set to NULL) the secondary firmware node pointer, +when it exists, is made the primary node for the device. +However, the secondary firmware node pointer of the original +primary firmware node is never cleared (set to NULL). + +To avoid situation where the secondary firmware node pointer +is pointing to a non-existing object, clearing it properly +when the primary node is removed from a device in +set_primary_fwnode(). + +Fixes: 97badf873ab6 ("device property: Make it possible to use secondary firmware nodes") +Cc: All applicable +Signed-off-by: Heikki Krogerus +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/base/core.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +--- a/drivers/base/core.c ++++ b/drivers/base/core.c +@@ -3333,9 +3333,9 @@ static inline bool fwnode_is_primary(str + */ + void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode) + { +- if (fwnode) { +- struct fwnode_handle *fn = dev->fwnode; ++ struct fwnode_handle *fn = dev->fwnode; + ++ if (fwnode) { + if (fwnode_is_primary(fn)) + fn = fn->secondary; + +@@ -3345,8 +3345,12 @@ void set_primary_fwnode(struct device *d + } + dev->fwnode = fwnode; + } else { +- dev->fwnode = fwnode_is_primary(dev->fwnode) ? +- dev->fwnode->secondary : NULL; ++ if (fwnode_is_primary(fn)) { ++ dev->fwnode = fn->secondary; ++ fn->secondary = NULL; ++ } else { ++ dev->fwnode = NULL; ++ } + } + } + EXPORT_SYMBOL_GPL(set_primary_fwnode); diff --git a/queue-4.19/drm-amd-pm-correct-vega10-swctf-limit-setting.patch b/queue-4.19/drm-amd-pm-correct-vega10-swctf-limit-setting.patch new file mode 100644 index 00000000000..7ecf3b8b48c --- /dev/null +++ b/queue-4.19/drm-amd-pm-correct-vega10-swctf-limit-setting.patch @@ -0,0 +1,46 @@ +From b05d71b51078fc428c6b72582126d9d75d3c1f4c Mon Sep 17 00:00:00 2001 +From: Evan Quan +Date: Fri, 21 Aug 2020 12:05:03 +0800 +Subject: drm/amd/pm: correct Vega10 swctf limit setting + +From: Evan Quan + +commit b05d71b51078fc428c6b72582126d9d75d3c1f4c upstream. + +Correct the Vega10 thermal swctf limit. + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1267 + +Signed-off-by: Evan Quan +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c ++++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c +@@ -362,6 +362,9 @@ int vega10_thermal_get_temperature(struc + static int vega10_thermal_set_temperature_range(struct pp_hwmgr *hwmgr, + struct PP_TemperatureRange *range) + { ++ struct phm_ppt_v2_information *pp_table_info = ++ (struct phm_ppt_v2_information *)(hwmgr->pptable); ++ struct phm_tdp_table *tdp_table = pp_table_info->tdp_table; + struct amdgpu_device *adev = hwmgr->adev; + int low = VEGA10_THERMAL_MINIMUM_ALERT_TEMP * + PP_TEMPERATURE_UNITS_PER_CENTIGRADES; +@@ -371,8 +374,8 @@ static int vega10_thermal_set_temperatur + + if (low < range->min) + low = range->min; +- if (high > range->max) +- high = range->max; ++ if (high > tdp_table->usSoftwareShutdownTemp) ++ high = tdp_table->usSoftwareShutdownTemp; + + if (low > high) + return -EINVAL; diff --git a/queue-4.19/drm-amd-pm-correct-vega12-swctf-limit-setting.patch b/queue-4.19/drm-amd-pm-correct-vega12-swctf-limit-setting.patch new file mode 100644 index 00000000000..1559c1e3b8b --- /dev/null +++ b/queue-4.19/drm-amd-pm-correct-vega12-swctf-limit-setting.patch @@ -0,0 +1,43 @@ +From e0ffd340249699ad27a6c91abdfa3e89f7823941 Mon Sep 17 00:00:00 2001 +From: Evan Quan +Date: Fri, 21 Aug 2020 12:18:58 +0800 +Subject: drm/amd/pm: correct Vega12 swctf limit setting + +From: Evan Quan + +commit e0ffd340249699ad27a6c91abdfa3e89f7823941 upstream. + +Correct the Vega12 thermal swctf limit. + +Signed-off-by: Evan Quan +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/powerplay/hwmgr/vega12_thermal.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_thermal.c ++++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_thermal.c +@@ -170,6 +170,8 @@ int vega12_thermal_get_temperature(struc + static int vega12_thermal_set_temperature_range(struct pp_hwmgr *hwmgr, + struct PP_TemperatureRange *range) + { ++ struct phm_ppt_v3_information *pptable_information = ++ (struct phm_ppt_v3_information *)hwmgr->pptable; + struct amdgpu_device *adev = hwmgr->adev; + int low = VEGA12_THERMAL_MINIMUM_ALERT_TEMP * + PP_TEMPERATURE_UNITS_PER_CENTIGRADES; +@@ -179,8 +181,8 @@ static int vega12_thermal_set_temperatur + + if (low < range->min) + low = range->min; +- if (high > range->max) +- high = range->max; ++ if (high > pptable_information->us_software_shutdown_temp) ++ high = pptable_information->us_software_shutdown_temp; + + if (low > high) + return -EINVAL; diff --git a/queue-4.19/drm-amdgpu-fix-buffer-overflow-in-info-ioctl.patch b/queue-4.19/drm-amdgpu-fix-buffer-overflow-in-info-ioctl.patch new file mode 100644 index 00000000000..acbf3744a44 --- /dev/null +++ b/queue-4.19/drm-amdgpu-fix-buffer-overflow-in-info-ioctl.patch @@ -0,0 +1,39 @@ +From b5b97cab55eb71daba3283c8b1d2cce456d511a1 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 25 Aug 2020 11:43:45 -0400 +Subject: drm/amdgpu: Fix buffer overflow in INFO ioctl + +From: Alex Deucher + +commit b5b97cab55eb71daba3283c8b1d2cce456d511a1 upstream. + +The values for "se_num" and "sh_num" come from the user in the ioctl. +They can be in the 0-255 range but if they're more than +AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in +an out of bounds read. + +Reported-by: Dan Carpenter +Acked-by: Dan Carpenter +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c +@@ -524,8 +524,12 @@ static int amdgpu_info_ioctl(struct drm_ + * in the bitfields */ + if (se_num == AMDGPU_INFO_MMR_SE_INDEX_MASK) + se_num = 0xffffffff; ++ else if (se_num >= AMDGPU_GFX_MAX_SE) ++ return -EINVAL; + if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK) + sh_num = 0xffffffff; ++ else if (sh_num >= AMDGPU_GFX_MAX_SH_PER_SE) ++ return -EINVAL; + + if (info->read_mmr_reg.count > 128) + return -EINVAL; diff --git a/queue-4.19/genirq-matrix-deal-with-the-sillyness-of-for_each_cpu-on-up.patch b/queue-4.19/genirq-matrix-deal-with-the-sillyness-of-for_each_cpu-on-up.patch new file mode 100644 index 00000000000..afd71422152 --- /dev/null +++ b/queue-4.19/genirq-matrix-deal-with-the-sillyness-of-for_each_cpu-on-up.patch @@ -0,0 +1,48 @@ +From 784a0830377d0761834e385975bc46861fea9fa0 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Sun, 30 Aug 2020 19:07:53 +0200 +Subject: genirq/matrix: Deal with the sillyness of for_each_cpu() on UP + +From: Thomas Gleixner + +commit 784a0830377d0761834e385975bc46861fea9fa0 upstream. + +Most of the CPU mask operations behave the same way, but for_each_cpu() and +it's variants ignore the cpumask argument and claim that CPU0 is always in +the mask. This is historical, inconsistent and annoying behaviour. + +The matrix allocator uses for_each_cpu() and can be called on UP with an +empty cpumask. The calling code does not expect that this succeeds but +until commit e027fffff799 ("x86/irq: Unbreak interrupt affinity setting") +this went unnoticed. That commit added a WARN_ON() to catch cases which +move an interrupt from one vector to another on the same CPU. The warning +triggers on UP. + +Add a check for the cpumask being empty to prevent this. + +Fixes: 2f75d9e1c905 ("genirq: Implement bitmap matrix allocator") +Reported-by: kernel test robot +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/matrix.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/kernel/irq/matrix.c ++++ b/kernel/irq/matrix.c +@@ -380,6 +380,13 @@ int irq_matrix_alloc(struct irq_matrix * + unsigned int cpu, bit; + struct cpumap *cm; + ++ /* ++ * Not required in theory, but matrix_find_best_cpu() uses ++ * for_each_cpu() which ignores the cpumask on UP . ++ */ ++ if (cpumask_empty(msk)) ++ return -EINVAL; ++ + cpu = matrix_find_best_cpu(m, msk); + if (cpu == UINT_MAX) + return -ENOSPC; diff --git a/queue-4.19/irqchip-stm32-exti-avoid-losing-interrupts-due-to-clearing-pending-bits-by-mistake.patch b/queue-4.19/irqchip-stm32-exti-avoid-losing-interrupts-due-to-clearing-pending-bits-by-mistake.patch new file mode 100644 index 00000000000..487fcc86252 --- /dev/null +++ b/queue-4.19/irqchip-stm32-exti-avoid-losing-interrupts-due-to-clearing-pending-bits-by-mistake.patch @@ -0,0 +1,72 @@ +From e579076ac0a3bebb440fab101aef3c42c9f4c709 Mon Sep 17 00:00:00 2001 +From: qiuguorui1 +Date: Thu, 20 Aug 2020 11:16:29 +0800 +Subject: irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by mistake + +From: qiuguorui1 + +commit e579076ac0a3bebb440fab101aef3c42c9f4c709 upstream. + +In the current code, when the eoi callback of the exti clears the pending +bit of the current interrupt, it will first read the values of fpr and +rpr, then logically OR the corresponding bit of the interrupt number, +and finally write back to fpr and rpr. + +We found through experiments that if two exti interrupts, +we call them int1/int2, arrive almost at the same time. in our scenario, +the time difference is 30 microseconds, assuming int1 is triggered first. + +there will be an extreme scenario: both int's pending bit are set to 1, +the irq handle of int1 is executed first, and eoi handle is then executed, +at this moment, all pending bits are cleared, but the int 2 has not +finally been reported to the cpu yet, which eventually lost int2. + +According to stm32's TRM description about rpr and fpr: Writing a 1 to this +bit will trigger a rising edge event on event x, Writing 0 has no +effect. + +Therefore, when clearing the pending bit, we only need to clear the +pending bit of the irq. + +Fixes: 927abfc4461e7 ("irqchip/stm32: Add stm32mp1 support with hierarchy domain") +Signed-off-by: qiuguorui1 +Signed-off-by: Marc Zyngier +Cc: stable@vger.kernel.org # v4.18+ +Link: https://lore.kernel.org/r/20200820031629.15582-1-qiuguorui1@huawei.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-stm32-exti.c | 14 ++++++++++++-- + 1 file changed, 12 insertions(+), 2 deletions(-) + +--- a/drivers/irqchip/irq-stm32-exti.c ++++ b/drivers/irqchip/irq-stm32-exti.c +@@ -382,6 +382,16 @@ static void stm32_irq_ack(struct irq_dat + irq_gc_unlock(gc); + } + ++/* directly set the target bit without reading first. */ ++static inline void stm32_exti_write_bit(struct irq_data *d, u32 reg) ++{ ++ struct stm32_exti_chip_data *chip_data = irq_data_get_irq_chip_data(d); ++ void __iomem *base = chip_data->host_data->base; ++ u32 val = BIT(d->hwirq % IRQS_PER_BANK); ++ ++ writel_relaxed(val, base + reg); ++} ++ + static inline u32 stm32_exti_set_bit(struct irq_data *d, u32 reg) + { + struct stm32_exti_chip_data *chip_data = irq_data_get_irq_chip_data(d); +@@ -415,9 +425,9 @@ static void stm32_exti_h_eoi(struct irq_ + + raw_spin_lock(&chip_data->rlock); + +- stm32_exti_set_bit(d, stm32_bank->rpr_ofst); ++ stm32_exti_write_bit(d, stm32_bank->rpr_ofst); + if (stm32_bank->fpr_ofst != UNDEF_REG) +- stm32_exti_set_bit(d, stm32_bank->fpr_ofst); ++ stm32_exti_write_bit(d, stm32_bank->fpr_ofst); + + raw_spin_unlock(&chip_data->rlock); + diff --git a/queue-4.19/pm-sleep-core-fix-the-handling-of-pending-runtime-resume-requests.patch b/queue-4.19/pm-sleep-core-fix-the-handling-of-pending-runtime-resume-requests.patch new file mode 100644 index 00000000000..4d4faecda59 --- /dev/null +++ b/queue-4.19/pm-sleep-core-fix-the-handling-of-pending-runtime-resume-requests.patch @@ -0,0 +1,82 @@ +From e3eb6e8fba65094328b8dca635d00de74ba75b45 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Mon, 24 Aug 2020 19:35:31 +0200 +Subject: PM: sleep: core: Fix the handling of pending runtime resume requests + +From: Rafael J. Wysocki + +commit e3eb6e8fba65094328b8dca635d00de74ba75b45 upstream. + +It has been reported that system-wide suspend may be aborted in the +absence of any wakeup events due to unforseen interactions of it with +the runtume PM framework. + +One failing scenario is when there are multiple devices sharing an +ACPI power resource and runtime-resume needs to be carried out for +one of them during system-wide suspend (for example, because it needs +to be reconfigured before the whole system goes to sleep). In that +case, the runtime-resume of that device involves turning the ACPI +power resource "on" which in turn causes runtime-resume requests +to be queued up for all of the other devices sharing it. Those +requests go to the runtime PM workqueue which is frozen during +system-wide suspend, so they are not actually taken care of until +the resume of the whole system, but the pm_runtime_barrier() +call in __device_suspend() sees them and triggers system wakeup +events for them which then cause the system-wide suspend to be +aborted if wakeup source objects are in active use. + +Of course, the logic that leads to triggering those wakeup events is +questionable in the first place, because clearly there are cases in +which a pending runtime resume request for a device is not connected +to any real wakeup events in any way (like the one above). Moreover, +it is racy, because the device may be resuming already by the time +the pm_runtime_barrier() runs and so if the driver doesn't take care +of signaling the wakeup event as appropriate, it will be lost. +However, if the driver does take care of that, the extra +pm_wakeup_event() call in the core is redundant. + +Accordingly, drop the conditional pm_wakeup_event() call fron +__device_suspend() and make the latter call pm_runtime_barrier() +alone. Also modify the comment next to that call to reflect the new +code and extend it to mention the need to avoid unwanted interactions +between runtime PM and system-wide device suspend callbacks. + +Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)") +Signed-off-by: Rafael J. Wysocki +Acked-by: Alan Stern +Reported-by: Utkarsh H Patel +Tested-by: Utkarsh H Patel +Tested-by: Pengfei Xu +Cc: All applicable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/base/power/main.c | 16 ++++++++++------ + 1 file changed, 10 insertions(+), 6 deletions(-) + +--- a/drivers/base/power/main.c ++++ b/drivers/base/power/main.c +@@ -1751,13 +1751,17 @@ static int __device_suspend(struct devic + } + + /* +- * If a device configured to wake up the system from sleep states +- * has been suspended at run time and there's a resume request pending +- * for it, this is equivalent to the device signaling wakeup, so the +- * system suspend operation should be aborted. ++ * Wait for possible runtime PM transitions of the device in progress ++ * to complete and if there's a runtime resume request pending for it, ++ * resume it before proceeding with invoking the system-wide suspend ++ * callbacks for it. ++ * ++ * If the system-wide suspend callbacks below change the configuration ++ * of the device, they must disable runtime PM for it or otherwise ++ * ensure that its runtime-resume callbacks will not be confused by that ++ * change in case they are invoked going forward. + */ +- if (pm_runtime_barrier(dev) && device_may_wakeup(dev)) +- pm_wakeup_event(dev, 0); ++ pm_runtime_barrier(dev); + + if (pm_wakeup_pending()) { + dev->power.direct_complete = false; diff --git a/queue-4.19/series b/queue-4.19/series index bb5bc723b25..82bfdbe8719 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -98,3 +98,10 @@ xen-uses-irqdesc-irq_data_common-handler_data-to-store-a-per-interrupt-xen-data- usb-host-xhci-fix-ep-context-print-mismatch-in-debugfs.patch xhci-do-warm-reset-when-both-cas-and-xdev_resume-are-set.patch xhci-always-restore-ep_soft_clear_toggle-even-if-ep-reset-failed.patch +pm-sleep-core-fix-the-handling-of-pending-runtime-resume-requests.patch +device-property-fix-the-secondary-firmware-node-handling-in-set_primary_fwnode.patch +genirq-matrix-deal-with-the-sillyness-of-for_each_cpu-on-up.patch +irqchip-stm32-exti-avoid-losing-interrupts-due-to-clearing-pending-bits-by-mistake.patch +drm-amdgpu-fix-buffer-overflow-in-info-ioctl.patch +drm-amd-pm-correct-vega10-swctf-limit-setting.patch +drm-amd-pm-correct-vega12-swctf-limit-setting.patch -- 2.47.2