On Fri, Apr 20, 2012 at 11:26 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote: > On 03/14/2012 03:13 AM, Dan Williams wrote: >> >> Reuse ata_port_{suspend|resume}_common for sas. This path is chosen >> over adding coordination between ata-tranport and sas-transport because >> libsas wants to revalidate the domain at resume-time at the host level. >> It can not validate links have resumed properly until libata has had a >> chance to perform its revalidation, and any sane placing of an ata_port >> in the sas-transport model would delay it's resumption until after the >> host. >> >> Export the common portion of port suspend/resume (bypass pm_runtime), >> and allow sas to perform these operations asynchronously (similar to the >> libsas async-ata probe implmentation). Async operation is determined by >> having an external, rather than stack based, location for storing the >> result of the operation. >> >> Reviewed-by: Jacek Danecki<jacek.danecki@xxxxxxxxx> >> Signed-off-by: Dan Williams<dan.j.williams@xxxxxxxxx> >> --- >> drivers/ata/libata-core.c | 58 >> ++++++++++++++++++++++++++++++++++++--------- >> include/linux/libata.h | 11 +++++++++ >> 2 files changed, 57 insertions(+), 12 deletions(-) > > > Now that libata's runtime PM problems seem to be fixed for the moment, we > can revisit port PM here. Just checking... Is this patch still needed? Yeah, this one is still needed. libsas wants to validate links at the host level. I tried letting these routines be called "naturally" by registering libsas-ata_ports with the ata-transport class, but it hangs / got messy in cases where the link needed recovery (SATA_PENDING), but the ata_port was still suspended. Also, I think the ata_port pm_runtime bits need a review for suitability for the libsas case. So, with this approach libsas does not register libsas-ata_ports with the ata transport class and instead calls the core routines directly (similar to how libata did before the dev_pm_ops rework). -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html