On Fri, Mar 14, 2014 at 01:52:48PM -0700, Dan Williams wrote:
> Tejun says:
> "At least for libata, worrying about suspend/resume failures don't make
> whole lot of sense. If suspend failed, just proceed with suspend. If
> the device can't be woken up afterwards, that's that. There isn't
> anything we could have done differently anyway. The same for resume, if
> spinup fails, the device is dud and the following commands will invoke
> EH actions and will eventually fail. Again, there really isn't any
> *choice* to make. Just making sure the errors are handled gracefully
> (ie. don't crash) and the following commands are handled correctly
> should be enough."
>
> The only libata user that actually cares about the result from a suspend
> operation is libsas. However, it only cares about whether queuing a new
> operation collides with an in-flight one. All libsas does with the
> error is retry, but we can just let libata wait for the previous
> operation before continuing.
>
> Other cleanups include:
> 1/ Unifying all ata port pm operations on an ata_port_pm_ prefix
> 2/ Marking all ata port pm helper routines as returning void, only
> ata_port_pm_ entry points need to fake a 0 return value.
> 3/ Killing ata_port_{suspend|resume}_common() in favor of calling
> ata_port_request_pm() directly
> 4/ Killing the wrappers that just do a to_ata_port() conversion
> 5/ Clearly marking the entry points that do async operations with an
> _async suffix.
>
> Reference: http://marc.info/?l=linux-scsi&m=138995409532286&w=2
>
> Cc: Phillip Susi <[email protected]>
> Cc: Alan Stern <[email protected]>
> Suggested-by: Tejun Heo <[email protected]>
> Signed-off-by: Todd Brandt <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
Can somebody ack the sas part?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
