Am Freitag 28 September 2007 schrieb Alan Stern: > On Fri, 28 Sep 2007, Oliver Neukum wrote: > > > Am Donnerstag 27 September 2007 schrieb Alan Stern: > > > There's also a philosophical objection. Who is in a better position to > > > judge when a device like a SCSI drive should be autosuspended: its own > > > driver (sd) or someone else (usb-storage)? > > > > Then a philosophical answer. The highest entity which understands what > > it is doing when using power management. Highest here to be understood > > not as a position in the device tree, but in the flow of information. > > In this sense, sd is higher than usb-storage, right? Because I/O > requests pass through sd first, then usb-storage, on their way to the > device. Yes, but sr doesn't know hardware. > My point is that when dealing with SCSI disks, sd understands the > implications of Power Management better than usb-storage does. > Similarly, when dealing with SCSI cd drives, sr understands the > implications of Power Management better than usb-storage. No. The capabilities of the hardware are determined by USB. USB imposes two strict rules. 1. The host cannot talk to a suspended device (keeping it suspended) 2. Power consumption is very limited It makes no sense to talk about power management of devices as such. You need to talk about devices on the bus type they are connected to. > Hence by your own argument, the SCSI high-level drivers should be > responsible for autosuspending their respective devices. usb-storage, > on the other hand, should be responsible only for suspending the > transport, since that's what it does understand. The weakest link of the chain determines the whole. > > That is in our case usb-storage. Sr or sd can't do it because they don't > > and can't understand power management. > > That's simply not true. If sd didn't understand Power Management then > sd_suspend() and sd_resume() would be empty. It understands on and off. The methods simply do what is to be done to safely switch off a disk. > > Now they might be asked to provide some helpers. An open count and > > notifications about the state of the queue would be obvious. Other > > suggestions? > > I still think you're trying to go about it all backwards. I am using the point where the logical flow of information and the device tree diverge. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
