On 2020-05-02 01:56, Bart Van Assche wrote:
On 2020-04-30 22:12, Can Guo wrote:
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 3717eea..d18271d 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -74,12 +74,15 @@ static int scsi_dev_type_resume(struct device
On 2020-04-30 22:12, Can Guo wrote:
> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
> index 3717eea..d18271d 100644
> --- a/drivers/scsi/scsi_pm.c
> +++ b/drivers/scsi/scsi_pm.c
> @@ -74,12 +74,15 @@ static int scsi_dev_type_resume(struct device *dev,
> {
> const struct
On 2020-05-01 09:50, Bart Van Assche wrote:
On 2020-04-30 18:42, Can Guo wrote:
On 2020-05-01 04:32, Bart Van Assche wrote:
> Has it been considered to test directly whether a SCSI device has been
> runtime suspended instead of relying on blk_queue_pm_only()? How about
> using
On 2020-04-30 18:42, Can Guo wrote:
> On 2020-05-01 04:32, Bart Van Assche wrote:
> > Has it been considered to test directly whether a SCSI device has been
> > runtime suspended instead of relying on blk_queue_pm_only()? How about
> > using pm_runtime_status_suspended() or adding a function in
>
On 2020-05-01 04:32, Bart Van Assche wrote:
On 2020-04-29 22:40, Can Guo wrote:
On 2020-04-30 13:08, Bart Van Assche wrote:
On 2020-04-29 21:10, Can Guo wrote:
During system resume, scsi_resume_device() decreases a request
queue's
pm_only counter if the scsi device was quiesced before. But
On 2020-05-01 04:32, Bart Van Assche wrote:
On 2020-04-29 22:40, Can Guo wrote:
On 2020-04-30 13:08, Bart Van Assche wrote:
On 2020-04-29 21:10, Can Guo wrote:
During system resume, scsi_resume_device() decreases a request
queue's
pm_only counter if the scsi device was quiesced before. But
On 2020-04-29 22:40, Can Guo wrote:
> On 2020-04-30 13:08, Bart Van Assche wrote:
>> On 2020-04-29 21:10, Can Guo wrote:
>>> During system resume, scsi_resume_device() decreases a request queue's
>>> pm_only counter if the scsi device was quiesced before. But after that,
>>> if the scsi device's
Hi Avri,
On 2020-04-30 17:11, Avri Altman wrote:
On 2020-04-29 21:10, Can Guo wrote:
> During system resume, scsi_resume_device() decreases a request queue's
> pm_only counter if the scsi device was quiesced before. But after that,
> if the scsi device's RPM status is RPM_SUSPENDED, the
>
> On 2020-04-29 21:10, Can Guo wrote:
> > During system resume, scsi_resume_device() decreases a request queue's
> > pm_only counter if the scsi device was quiesced before. But after that,
> > if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is
> > still held (non-zero).
Hi Bart,
On 2020-04-30 13:08, Bart Van Assche wrote:
On 2020-04-29 21:10, Can Guo wrote:
During system resume, scsi_resume_device() decreases a request queue's
pm_only counter if the scsi device was quiesced before. But after
that,
if the scsi device's RPM status is RPM_SUSPENDED, the pm_only
On 2020-04-29 21:10, Can Guo wrote:
> During system resume, scsi_resume_device() decreases a request queue's
> pm_only counter if the scsi device was quiesced before. But after that,
> if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is
> still held (non-zero). Current scsi
During system resume, scsi_resume_device() decreases a request queue's
pm_only counter if the scsi device was quiesced before. But after that,
if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is
still held (non-zero). Current scsi resume hook only sets the RPM status
of the
12 matches
Mail list logo
