--- /dev/null
+From c15e1bdda4365a5f17cdadf22bf1c1df13884a9e Mon Sep 17 00:00:00 2001
+From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+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 <heikki.krogerus@linux.intel.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From b05d71b51078fc428c6b72582126d9d75d3c1f4c Mon Sep 17 00:00:00 2001
+From: Evan Quan <evan.quan@amd.com>
+Date: Fri, 21 Aug 2020 12:05:03 +0800
+Subject: drm/amd/pm: correct Vega10 swctf limit setting
+
+From: Evan Quan <evan.quan@amd.com>
+
+commit b05d71b51078fc428c6b72582126d9d75d3c1f4c upstream.
+
+Correct the Vega10 thermal swctf limit.
+
+Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1267
+
+Signed-off-by: Evan Quan <evan.quan@amd.com>
+Reviewed-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/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;
--- /dev/null
+From e0ffd340249699ad27a6c91abdfa3e89f7823941 Mon Sep 17 00:00:00 2001
+From: Evan Quan <evan.quan@amd.com>
+Date: Fri, 21 Aug 2020 12:18:58 +0800
+Subject: drm/amd/pm: correct Vega12 swctf limit setting
+
+From: Evan Quan <evan.quan@amd.com>
+
+commit e0ffd340249699ad27a6c91abdfa3e89f7823941 upstream.
+
+Correct the Vega12 thermal swctf limit.
+
+Signed-off-by: Evan Quan <evan.quan@amd.com>
+Reviewed-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/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;
--- /dev/null
+From b5b97cab55eb71daba3283c8b1d2cce456d511a1 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 25 Aug 2020 11:43:45 -0400
+Subject: drm/amdgpu: Fix buffer overflow in INFO ioctl
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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 <dan.carpenter@oracle.com>
+Acked-by: Dan Carpenter <dan.carpenter@oracle.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/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;
--- /dev/null
+From 784a0830377d0761834e385975bc46861fea9fa0 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+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 <tglx@linutronix.de>
+
+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 <rong.a.chen@intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From e579076ac0a3bebb440fab101aef3c42c9f4c709 Mon Sep 17 00:00:00 2001
+From: qiuguorui1 <qiuguorui1@huawei.com>
+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 <qiuguorui1@huawei.com>
+
+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 <qiuguorui1@huawei.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+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 <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From e3eb6e8fba65094328b8dca635d00de74ba75b45 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+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 <rafael.j.wysocki@intel.com>
+
+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 <rafael.j.wysocki@intel.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
+Tested-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
+Tested-by: Pengfei Xu <pengfei.xu@intel.com>
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
