On Thu, 16 Jan 2014, Todd E Brandt wrote:
> > Does this plan sound reasonable to everyone? Are there important
> > aspects I haven't considered (such as interactions between the SCSI and
> > ATA layers)?
> >
> > Alan Stern
> >
>
> Both approaches employ non-blocking resume of the scsi disks so why don't
> we treat these two patch sets as parts one and two. My patch just spins
> everything up but sets everything to non-blocking, so it will take care
> of the most common use cases. Your patch will then fine-tune that behavior
> to only spin up those disks that are actually needed. I don't think there
> are any serious conflicts between the two patch sets.
Hmmm. In your 2/2 patch, sd_resume_complete() gets called in atomic
context. I would need a process context in order to carry out a
runtime resume. Any suggestions?
Also, I don't understand the point of your 1/2 patch. If the whole
point of that patch was to carry out the ATA port resume asynchronously
("thus allowing the next device in the pm queue to resume"), doesn't
device_enable_async_suspend() already do that for you?
Alan Stern
--
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
