On Mon, 2004-11-01 at 10:18 -0700, David Brownell wrote: > Of course in this case the child devices -- logical SCSI hosts > and disks -- really seem like they're different kinds of animal > than the physical USB devices. It's not at all clear to me > that the SCSI layer needs to know when requests might take a bit > longer to complete, or that it even makes sense to talk of them > as having any power consumption managed through SCSI. (Except > maybe for SCSI commands to spin down idle disks...) > > But this also highlights one of the reasons for that last sentence. > The usb-storage driver is literally a bridge between two different > frameworks. It can know things about how that bridging works, > things that no generic PM layer can reasonably know. In this > case, that there's a low power mode for the bridge that doesn't > need to be visible to SCSI. It should just do what IDE does and what I didn't have time to do for SCSI yet, that is for system PM have a PM request go down the queue acting as a barrier, ensuring completion of previous pending requests and blocking any further from coming down. The wakeup is done by injecting a wakeup request at the head of the queue. Anyway, I think what we have defined so far seem to be good enough to start the actual move. The only thing I'd like you to judge is wether we keep the original PM message semantics we discussed, or we move the freeze semantic to a separate flag as discussed in another message so that we have some kind of generic way of triggering drivers local PM... Ben
