Re: [PATCH] libata: device suspend/resume

Jens Axboe
2005-05-24T08:51:35Z

On Tue, May 24 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Tue, May 24 2005, Jeff Garzik wrote:
> >
> >>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.
> >
> >
> >BTW, you also need to set host/device modes on resume. Where do you
> >propose to do that currently, without the LLD hook?
>
> In the START STOP UNIT emulation. SSU is basically a high level "do PM
> command".

Ok, works for me.

> As a tangent, I would like to try and convince you to stop thinking so
> much about hooks, and start thinking about adding new commands at the
> struct request level. Sending things down the request_queue is much
> nicer because commands can be sent using the normal rq mechanisms.
> Often, commands can be translated directly into ATA or SCSI commands in
> the prep function.
>
> Two commands I have been thinking about, to add alongside READ, WRITE,
> READA, READ_SYNC, etc. are: SYNC_CACHE and PM_EVENT.
>
> This would be quite useful for DM and md RAID, especially. It becomes
> trivial to clone a SYNC_CACHE command, and send it to 5 underlying ATA
> and SCSI devices in a RAID array. If the PM_EVENT or SYNC_CACHE command
> needs special processing, one can easily add code for that without
> needing any hooks -- just call your new code from the request_queue
> function that handles READ/WRITE/READA/...
>
> This applies to the current thread (PM_EVENT), and also fits right into
> your barrier work, too (SYNC_CACHE).

I agree, it's a cleaner approach, with the rq being a container for
generel messages as well not just SCSI commands. The one missing piece
for that was the rq->end_io() callback so everything doesn't have to go
down sync, but that is in now as well.

I'll try and cook something up.

--
Jens Axboe