Alan Stern wrote: > On Wed, 13 Aug 2008, Oliver Neukum wrote: >> Am Mittwoch 13 August 2008 16:59:23 schrieb Alan Stern: >> > Is the USB transport unique in its requirement that all the child >> > devices must be suspended before the link can be powered down? Maybe >> >> All children that are USB must be powered down. We know in fact that most >> drives don't care that the device is suspended. The problem was drive >> enclosures that cut power upon suspension losing cached data. > > You misunderstood my question. Are there SCSI transports other than > USB sharing the requirement that all child devices must be suspended > before the link can be powered down? Yes in case of FireWire; it's necessary there too (but not sufficient). (It's a bad example though since I have no good idea whether power management beyond (a) system suspend and (b) disk spindown is feasible in reality at all.) [...] >> So do we really want to do autosuspend on the device level? Or do we work >> on hosts and just use the suspend()/resume() support of the sd, sr, ... etc? > > For transports which are like USB, we should do autosuspend at the > target (not device) level. This means invoking the suspend/resume > routines of the ULDs like sd and sr. The transport gets notified when > all of the targets are suspended. (Or maybe the host driver gets > notified instead; there probably isn't any advantage to using the > transport class here.) > > For other transports, we should only do idle-timeout detection. The > transport gets notified when any target has been idle for sufficiently > long, so that it can power down the link. The ULDs are not involved. > > Does that sound okay? Minor correction: The ULD suspend/resume methods necessarily work on logical units, not targets. -- Stefan Richter -=====-==--- =--- -==-= http://arcgraph.de/sr/ _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
