Fixes for 4.9

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

diff --git a/queue-4.9/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch b/queue-4.9/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
new file mode 100644 (file)
index 0000000..f281962
--- /dev/null
+++ b/queue-4.9/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
@@ -0,0 +1,57 @@
+From 9e71b9fb9fff95291db02e6f4c6b6b6c369aeeb8 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 16239b07ce45..2610919eb709 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.9/scsi-core-put-.shost_dev-in-failure-path-if-host-sta.patch b/queue-4.9/scsi-core-put-.shost_dev-in-failure-path-if-host-sta.patch
new file mode 100644 (file)
index 0000000..5912b5f
--- /dev/null
+++ b/queue-4.9/scsi-core-put-.shost_dev-in-failure-path-if-host-sta.patch
@@ -0,0 +1,66 @@
+From 4aa8d7701c3dc843404c670bb3d5fe360e62c661 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Jun 2021 21:30:28 +0800
+Subject: scsi: core: Put .shost_dev in failure path if host state changes to
+ RUNNING
+
+From: Ming Lei <ming.lei@redhat.com>
+
+[ Upstream commit 11714026c02d613c30a149c3f4c4a15047744529 ]
+
+scsi_host_dev_release() only frees dev_name when host state is
+SHOST_CREATED. After host state has changed to SHOST_RUNNING,
+scsi_host_dev_release() no longer cleans up.
+
+Fix this by doing a put_device(&shost->shost_dev) in the failure path when
+host state is SHOST_RUNNING. Move get_device(&shost->shost_gendev) before
+device_add(&shost->shost_dev) so that scsi_host_cls_release() can do a put
+on this reference.
+
+Link: https://lore.kernel.org/r/20210602133029.2864069-4-ming.lei@redhat.com
+Cc: Bart Van Assche <bvanassche@acm.org>
+Cc: Hannes Reinecke <hare@suse.de>
+Reported-by: John Garry <john.garry@huawei.com>
+Tested-by: John Garry <john.garry@huawei.com>
+Reviewed-by: John Garry <john.garry@huawei.com>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/hosts.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
+index dc09f10d5d4b..604cf3385aae 100644
+--- a/drivers/scsi/hosts.c
++++ b/drivers/scsi/hosts.c
+@@ -265,12 +265,11 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev,
+ 
+       device_enable_async_suspend(&shost->shost_dev);
+ 
++      get_device(&shost->shost_gendev);
+       error = device_add(&shost->shost_dev);
+       if (error)
+               goto out_del_gendev;
+ 
+-      get_device(&shost->shost_gendev);
+-
+       if (shost->transportt->host_size) {
+               shost->shost_data = kzalloc(shost->transportt->host_size,
+                                        GFP_KERNEL);
+@@ -307,6 +306,11 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev,
+  out_del_dev:
+       device_del(&shost->shost_dev);
+  out_del_gendev:
++      /*
++       * Host state is SHOST_RUNNING so we have to explicitly release
++       * ->shost_dev.
++       */
++      put_device(&shost->shost_dev);
+       device_del(&shost->shost_gendev);
+  out_destroy_freelist:
+       device_disable_async_suspend(&shost->shost_gendev);
+-- 
+2.30.2
+

diff --git a/queue-4.9/series b/queue-4.9/series
index 07a3b948a832e8938b8b0867c138e20a29c8adf2..6750a9804c7e7eae340a1e718035405ad6025973 100644 (file)
--- a/queue-4.9/series
+++ b/queue-4.9/series
@@ -35,3 +35,5 @@ be2net-fix-an-error-handling-path-in-be_probe.patch
 net-hamradio-fix-memory-leak-in-mkiss_close.patch
 net-cdc_eem-fix-tx-fixup-skb-leak.patch
 net-ethernet-fix-potential-use-after-free-in-ec_bhf_.patch
+scsi-core-put-.shost_dev-in-failure-path-if-host-sta.patch
+radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch