Re: [PATCH] libata: device suspend/resume

[Jens Axboe <axboe@suse.de>]

On Tue, May 24 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >suspend/resume is a lot more complicated than just flushing a cache, the
> >below will probably get you safe asleep but you will never get devices
> >alive again after power-up on suspend-to-ram.
> >
> >I also greatly prefer issuing a standby command to the drive after the
> >flush, so that we don't risk using the emergency parks of the drive. If
> >a drive happens to lie about wrt the flush command, it gets an extra
> >chance to flush the cache as it now knows that power will be gone very
> >soon. So I think the ->suspend/->resume hooks should belong to the LLD,
> >not the ULD as the ULD has no idea how to suspend all devices types.
> 
> 
> You are right about issuing the standby command after flush.  I don't 
> think an LLD hook is the proper way to accomplish it, however.
> 
> The SCSI layer needs to issue the START STOP UNIT command in response to 
> a suspend event, and libata-scsi will (per SAT spec) translate that into 
> the ATA standby command.  Merely following the relevant SCSI+SAT+ATA 
> standards gets us there.

That sounds fine!

> Longer term, SATA PM through SCSI will have three facets:
> 
> * Device PM.  This is best handled by the device class driver (sd/sr/st).
> 
> * Bus PM.  This is best handled by the transport class driver (need to 
> write for SATA and SAS).
> 
> * Host PM.  This is handled in the obvious manner, using existing PM 
> driver hooks.  PCI D0/D3, etc.
> 
> I can describe how this will look when libata is divorced from SCSI, if 
> you would like, too...

I was beginning to dispair you had given up that plan...

-- 
Jens Axboe