Fixes for 4.14

Signed-off-by: Sasha Levin <sashal@kernel.org>

diff --git a/queue-4.14/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch b/queue-4.14/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch
new file mode 100644 (file)
index 0000000..9498b53
--- /dev/null
+++ b/queue-4.14/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch
@@ -0,0 +1,46 @@
+From 3a27e348446ed4044bc9d0298e6ec80b2640d192 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Jun 2021 11:09:59 +0800
+Subject: hwmon: (scpi-hwmon) shows the negative temperature properly
+
+From: Riwen Lu <luriwen@kylinos.cn>
+
+[ Upstream commit 78d13552346289bad4a9bf8eabb5eec5e5a321a5 ]
+
+The scpi hwmon shows the sub-zero temperature in an unsigned integer,
+which would confuse the users when the machine works in low temperature
+environment. This shows the sub-zero temperature in an signed value and
+users can get it properly from sensors.
+
+Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
+Tested-by: Xin Chen <chenxin@kylinos.cn>
+Link: https://lore.kernel.org/r/20210604030959.736379-1-luriwen@kylinos.cn
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hwmon/scpi-hwmon.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
+index 7e49da50bc69..562f3e287297 100644
+--- a/drivers/hwmon/scpi-hwmon.c
++++ b/drivers/hwmon/scpi-hwmon.c
+@@ -107,6 +107,15 @@ scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
+ 
+       scpi_scale_reading(&value, sensor);
+ 
++      /*
++       * Temperature sensor values are treated as signed values based on
++       * observation even though that is not explicitly specified, and
++       * because an unsigned u64 temperature does not really make practical
++       * sense especially when the temperature is below zero degrees Celsius.
++       */
++      if (sensor->info.class == TEMPERATURE)
++              return sprintf(buf, "%lld\n", (s64)value);
++
+       return sprintf(buf, "%llu\n", value);
+ }
+ 
+-- 
+2.30.2
+

diff --git a/queue-4.14/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch b/queue-4.14/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
new file mode 100644 (file)
index 0000000..86c0447
--- /dev/null
+++ b/queue-4.14/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
@@ -0,0 +1,57 @@
+From ff91dfe354157b4b7db2f05fb8eab5444db1f9bd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Jun 2021 16:43:02 +0800
+Subject: radeon: use memcpy_to/fromio for UVD fw upload
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chen Li <chenli@uniontech.com>
+
+[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
+
+I met a gpu addr bug recently and the kernel log
+tells me the pc is memcpy/memset and link register is
+radeon_uvd_resume.
+
+As we know, in some architectures, optimized memcpy/memset
+may not work well on device memory. Trival memcpy_toio/memset_io
+can fix this problem.
+
+BTW, amdgpu has already done it in:
+commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
+that's why it has no this issue on the same gpu and platform.
+
+Signed-off-by: Chen Li <chenli@uniontech.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/radeon/radeon_uvd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c
+index 95f4db70dd22..fde9c69ecc86 100644
+--- a/drivers/gpu/drm/radeon/radeon_uvd.c
++++ b/drivers/gpu/drm/radeon/radeon_uvd.c
+@@ -286,7 +286,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
+       if (rdev->uvd.vcpu_bo == NULL)
+               return -EINVAL;
+ 
+-      memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
++      memcpy_toio((void __iomem *)rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+ 
+       size = radeon_bo_size(rdev->uvd.vcpu_bo);
+       size -= rdev->uvd_fw->size;
+@@ -294,7 +294,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
+       ptr = rdev->uvd.cpu_addr;
+       ptr += rdev->uvd_fw->size;
+ 
+-      memset(ptr, 0, size);
++      memset_io((void __iomem *)ptr, 0, size);
+ 
+       return 0;
+ }
+-- 
+2.30.2
+

diff --git a/queue-4.14/series b/queue-4.14/series
index e1cdef439a206938da66a40a70d83057c59d2e4b..43a88a8ee6016c68a21822c9cfe54719bb03938f 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -38,3 +38,5 @@ net-hamradio-fix-memory-leak-in-mkiss_close.patch
 net-cdc_eem-fix-tx-fixup-skb-leak.patch
 icmp-don-t-send-out-icmp-messages-with-a-source-addr.patch
 net-ethernet-fix-potential-use-after-free-in-ec_bhf_.patch
+radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
+hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch