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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
