> What should what -- and why? :) > > The cost to resume would be on the order of a few seeks. > If the drive were busy, that'd matter; but in that case > nothing would be suspending, the drive's not idle! I'd > be interested in knowing more what the SCSI folk think. > > You later said: > > > But whatever subsystem you are providing a service for (fs, networking, > > etc...) aren't to be part of the bus hierarchy and aren't to be > > suspended or resumed. > > But that's exactly this case. USB is the bus hierarchy; > SCSI is just a functional layer on top, it doesn't have > anything particular to do with *this* hardware. Unless > someone added power switching to SCSI when I wasn't > watching (entirely possible). Hrm... ok, that isn't trivial, but here's how I see it. The actual PM scenario goes down to the disk (sd in our case). Not below. The SCSI is a bus in that case, it's a transport, like USB. We are basically stacking 2 layers of transport but SCSI is part of the bus hierarchy. What I do on IDE is this: The disk itself is the leaf of the PM tree. Actually, the callback goes to the ide_bus structure, since busses are what get the callbacks. ide_bus (but that could really be the disk struct device, it was just simple to put it there because it's generic for all IDE devices). That callbacks are then turned into a special request that I send down the queue on suspend (and wait for it to complete) and that I inject at the head of the queue (and wait for it to complete eventually, that is optional, completion of resume can be asynchronous in some carefully chosen cases). The core IDE queue management will then make sure it accepts no other request after processing the PM suspend one, and will make sure all pending ones have been flushed out before processing it (it acts like a barrier). Once processing it, it then calls back a subdriver specific callback that processes the PM request in a state machine model (that's best suited for IDE: send taskfiles, gets called again on completion, maybe that's fine for SCSI too). Once the state machine at the subdriver level is complete, the PM request is "completed". For suspend, that means the queue stays blocked, which is why the resume request is directly injected at the head of the queue, triggering a special case in the IDE code to start the resume process. This sounds complicated, but it's not very in practice (the implementation is simple). For scsi, the idea would be the same. The disk gets suspended (the leaf of the PM tree, provider of the request queue). sd() (or the core SCSI like I do on IDE to simplify) would get the callback, would then forge & send a PM request down the queue for the device. sd, st, etc... subdrivers would then have their own handling of it once the request reach them and the PM request would be treated as a barrier making sure previous pending stuff is completed. I'll probably give a try at implementing that one of these day if I can find my cardbus adaptec scsi card :) Ben.
