Skip to content
  • Dan Williams's avatar
    libata, libsas: kill pm_result and related cleanup · bc6e7c4b
    Dan Williams authored
    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 <psusi@ubuntu.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Suggested-by: default avatarTejun Heo <tj@kernel.org>
    Signed-off-by: default avatarTodd Brandt <todd.e.brandt@intel.com>
    Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    Signed-off-by: default avatarTejun Heo <tj@kernel.org>
    bc6e7c4b