[PATCH v10 1/2] scsi: ufs: Enable power management for wlun
Asutosh Das (asd)
asutoshd at codeaurora.org
Wed Mar 10 04:04:53 GMT 2021
On 3/9/2021 7:14 PM, Alan Stern wrote:
> On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote:
>> Hello
>> I & Can (thanks CanG) debugged this further:
>>
>> Looks like this issue can occur if the sd probe is asynchronous.
>>
>> Essentially, the sd_probe() is done asynchronously and driver_probe_device()
>> invokes pm_runtime_get_suppliers() before invoking sd_probe().
>>
>> But scsi_probe_and_add_lun() runs in a separate context.
>> So the scsi_autopm_put_device() invoked from scsi_scan_host() context
>> reduces the link->rpm_active to 1. And sd_probe() invokes
>> scsi_autopm_put_device() and starts a timer. And then driver_probe_device()
>> invoked from __device_attach_async_helper context reduces the
>> link->rpm_active to 1 thus enabling the supplier to suspend before the
>> consumer suspends.
>
>> I don't see a way around this. Please let me know if you
>> (@Alan/@Bart/@Adrian) have any thoughts on this.
>
> How about changing the SCSI core so that it does a runtime_get before
> starting an async probe, and the async probe routine does a
> runtime_put when it is finished? In other words, don't allow a device
> to go into runtime suspend while it is waiting to be probed.
>
> I don't think that would be too intrusive.
>
> Alan Stern
>
Hi Alan
Thanks for the suggestion.
Am trying to understand:
Do you mean something like this:
int scsi_sysfs_add_sdev(struct scsi_device *sdev)
{
scsi_autopm_get_device(sdev);
pm_runtime_get_noresume(&sdev->sdev_gendev);
[...]
scsi_autopm_put_device(sdev);
[...]
}
static int sd_probe(struct device *dev)
{
[...]
pm_runtime_put_noidle(dev);
scsi_autopm_put_device(sdp);
[...]
}
This may work (I'm limited by my imagination in scsi layer :) ).
But the pm_runtime_put_noidle() would have to be added to all registered
scsi_driver{}, perhaps? Or may be I can check for sdp->type?
-asd
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
More information about the Linux-mediatek
mailing list