Fixes for 4.4

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

diff --git a/queue-4.4/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch b/queue-4.4/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
new file mode 100644 (file)
index 0000000..e4d7c37
--- /dev/null
+++ b/queue-4.4/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
@@ -0,0 +1,57 @@
+From 966204301c91257584315e6511d6cbf3fe7ab178 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 b35ebabd6a9f..eab985fdcfbd 100644
+--- a/drivers/gpu/drm/radeon/radeon_uvd.c
++++ b/drivers/gpu/drm/radeon/radeon_uvd.c
+@@ -242,7 +242,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;
+@@ -250,7 +250,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.4/scsi-core-put-.shost_dev-in-failure-path-if-host-sta.patch b/queue-4.4/scsi-core-put-.shost_dev-in-failure-path-if-host-sta.patch
new file mode 100644 (file)
index 0000000..0fabfd2
--- /dev/null
+++ b/queue-4.4/scsi-core-put-.shost_dev-in-failure-path-if-host-sta.patch
@@ -0,0 +1,66 @@
+From b5dddeba98e84ccf2c6df1678990c992e116a673 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 fb4b6034f644..636548030046 100644
+--- a/drivers/scsi/hosts.c
++++ b/drivers/scsi/hosts.c
+@@ -259,12 +259,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);
+@@ -300,6 +299,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:
+       scsi_destroy_command_freelist(shost);
+-- 
+2.30.2
+

diff --git a/queue-4.4/series b/queue-4.4/series
index dbe96e3fd30cb97db07bfd637663cc09f2914766..75ecd86c60dea2a5e3b275d2e425a1909bf9822c 100644 (file)
--- a/queue-4.4/series
+++ b/queue-4.4/series
@@ -26,3 +26,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