| Message ID | 20230417230656.523826-3-bvanassche@acm.org |
|---|---|
| State | New |
| Headers | show |
| Series | SCSI core and UFS patches for kernel v6.4 | expand |
On 4/18/23 06:45, Adrian Hunter wrote: > On 18/04/23 02:06, Bart Van Assche wrote: >> Now that sd_shutdown() fails future I/O the code for quiescing LUNs in >> ufshcd_wl_shutdown() is superfluous. Remove the code for quiescing LUNs. >> Also remove the ufshcd_rpm_get_sync() call because it is not necessary >> to resume a UFS device before submitting a START STOP UNIT command. > > What about the host controller hba->dev? The above question is not clear to me. Please elaborate. Bart.
On 18/04/23 17:06, Bart Van Assche wrote: > On 4/18/23 06:45, Adrian Hunter wrote: >> On 18/04/23 02:06, Bart Van Assche wrote: >>> Now that sd_shutdown() fails future I/O the code for quiescing LUNs in >>> ufshcd_wl_shutdown() is superfluous. Remove the code for quiescing LUNs. >>> Also remove the ufshcd_rpm_get_sync() call because it is not necessary >>> to resume a UFS device before submitting a START STOP UNIT command. >> >> What about the host controller hba->dev? > > The above question is not clear to me. Please elaborate. Does hba->dev need to be runtime resumed?
On 18/04/23 23:14, Bart Van Assche wrote: > On 4/18/23 07:13, Adrian Hunter wrote: >> On 18/04/23 17:06, Bart Van Assche wrote: >>> On 4/18/23 06:45, Adrian Hunter wrote: >>>> On 18/04/23 02:06, Bart Van Assche wrote: >>>>> Now that sd_shutdown() fails future I/O the code for quiescing LUNs in >>>>> ufshcd_wl_shutdown() is superfluous. Remove the code for quiescing LUNs. >>>>> Also remove the ufshcd_rpm_get_sync() call because it is not necessary >>>>> to resume a UFS device before submitting a START STOP UNIT command. >>>> >>>> What about the host controller hba->dev? >>> >>> The above question is not clear to me. Please elaborate. >> >> Does hba->dev need to be runtime resumed? > > Hi Adrian, > > I don't think so. Shutdown callback functions are expected to quiesce hardware activity. To me runtime resuming a device seems to contradict the goal of quiescing hardware activity. I don't think the host controller can be used to submit a START STOP UNIT command if the host controller is runtime suspended.
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index 9434328ba323..784787cf08c3 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -9768,22 +9768,12 @@ static int ufshcd_wl_resume(struct device *dev) static void ufshcd_wl_shutdown(struct device *dev) { struct scsi_device *sdev = to_scsi_device(dev); - struct ufs_hba *hba; - - hba = shost_priv(sdev->host); + struct ufs_hba *hba = shost_priv(sdev->host); down(&hba->host_sem); hba->shutting_down = true; up(&hba->host_sem); - /* Turn on everything while shutting down */ - ufshcd_rpm_get_sync(hba); - scsi_device_quiesce(sdev); - shost_for_each_device(sdev, hba->host) { - if (sdev == hba->ufs_device_wlun) - continue; - scsi_device_quiesce(sdev); - } __ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM); }
Now that sd_shutdown() fails future I/O the code for quiescing LUNs in ufshcd_wl_shutdown() is superfluous. Remove the code for quiescing LUNs. Also remove the ufshcd_rpm_get_sync() call because it is not necessary to resume a UFS device before submitting a START STOP UNIT command. Cc: Asutosh Das <asutoshd@codeaurora.org> Cc: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> --- drivers/ufs/core/ufshcd.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-)