On Mon, Dec 16, 2013 at 3:30 PM, Phillip Susi <psusi@xxxxxxxxxx> wrote:
> Don't block the resume path waiting for the disk to
> spin up.
> ---
> drivers/ata/libata-core.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 8f856bb..4a28caf 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -5430,20 +5430,18 @@ static int __ata_port_resume_common(struct ata_port *ap, pm_message_t mesg,
> static int ata_port_resume_common(struct device *dev, pm_message_t mesg)
> {
> struct ata_port *ap = to_ata_port(dev);
> + static int dontcare;
>
> - return __ata_port_resume_common(ap, mesg, NULL);
> + return __ata_port_resume_common(ap, mesg, &dontcare);
> }
I was going to comment that this leaves us open to a race to submit
new i/o before recovery starts, but scsi_schedule_eh already blocks
new i/o, so I think we're good. I think it deserves a comment here
about why it's safe to not care.
>
> static int ata_port_resume(struct device *dev)
> {
> int rc;
>
> + if (pm_runtime_suspended(dev))
> + return 0;
Why? If we dpm_resume() a port that was rpm_suspend()ed the state
needs to be reset to active. I think this check also forces the port
to resume twice, once for system resume and again for the eventual
runtime_resume.
> rc = ata_port_resume_common(dev, PMSG_RESUME);
> - if (!rc) {
> - pm_runtime_disable(dev);
> - pm_runtime_set_active(dev);
> - pm_runtime_enable(dev);
> - }
>
> return rc;
> }
...so, the pm_runtime_suspended() check should go and something like
this folded in:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 92d7797223be..a6cc107c9434 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -4143,5 +4143,11 @@ static void ata_eh_handle_port_resume(struct
ata_port *ap)
ap->pm_result = NULL;
}
spin_unlock_irqrestore(ap->lock, flags);
+
+ if (rc == 0) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ }
}
#endif /* CONFIG_PM */
--
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
