On 01/08/2014 01:24 PM, Phillip Susi wrote: > On 01/07/2014 09:36 PM, Aaron Lu wrote: >> Oh, of course, my stupid :-) Then I suddenly think my patches can >> kind of work - let's say we have done the hdparm setting thing >> before suspend and the disk will be spun up in standby mode next >> time it is powered. Then during system resume phase, remove the >> pm_request_resume call in both SCSI and ATA's system resume >> callback, - if the disk is powered, it will be in standby mode and >> its runtime status is RPM_SUSPENDED, match its real status(sort >> of); - if the disk is not powered due to some host feature or >> whatever, it will be in unpowered mode and its runtime status is >> RPM_SUSPENDED, still match its real status. > > Right, but if the disk is a run of the mill ATA disk not configured > for power up in standby, then you end up with runtime pm saying that > it is suspended, when in fact, it spun up on its own and is sitting > there waiting for commands. > > The PuiS setting isn't something we can or want to twiggle on our own > during suspend, that's an admin decision that they set more or less > permanently either with hdparm or the hardware jumper. We just need OK, I see. > to detect what the drive has done and update the runtime pm status to > match. Then I would say we just keep the pm_request_resume call in their system resume callback. For drives that have that cool feature turned on, it will be in runtime active state while it's actually in standby mode, not a big deal since it should go to runtime suspended state once the autosuspend timer is due(the runtime PM core will schedule an idle call for newly resumed device); For drives that don't have that feature turned on, it will be in runtime active state while it's actually spun up, no problem here. For the PuiS set drive, there is a time window the drive's power mode doesn't agree with its runtime status, the window is the length of the autosuspend time interval. Not a big deal I suppose, considering that time interval isn't eternal? And I wouldn't say the runtime status for the drive is wrong even in this case, since the runtime status is a reflection of whether the device is in use or not from kernel's view, instead of whether it is in a low power mode. But I agree we better align them. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
