On Fri, 28 Sep 2007, Oliver Neukum wrote: > 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. I don't know what that's supposed to mean. And whatever that means, it must be equally true that usb-storage doesn't know CD drives. Or disk drives, or flash memories, or SCSI tape drives, or ... On the whole, I'd say that usb-storage's lack of knowledge about SCSI devices greatly outweighs sr's lack of knowledge about 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. You forget that the USB bus ends at the USB interface chip on the device. From there on it's a different sort of bus. It might be ATA, as in commonly-available USB-ATA converter boxes. It might be a genuine SCSI bus, as in some USB-SCSI bridges. It might be an internal flash-memory "bus". It might be a full-blown Linux gadget. And so on. The suspend done by usb-storage suspends only the USB part of the link. It might or might not affect anything beyond the device's USB chip, depending on how the device was designed. Your (1) is correct, since all communication must take place over the USB link. Your (2) is wrong -- the _link_'s power consumption is indeed limited, but the _device_ could be self-powered and so its power consumption need not be affected by the link state. For instance in the case of a USB-ATA drive enclosure, power consumption is affected more by whether or not the disk is spinning than anything else. > > 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. We're talking about conserving energy, not destroying chains. :-) > > > 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. That's arguable, at least as regards START-STOP UNIT. Spinning down a disk is more than just preparation; it is itself a power-saving measure. And anyway, that's beside the point. The SCSI drivers do what they can or what they must -- it's none of usb-storage's business. All usb-storage cares about is whether the link will be needed, and the only code that can tell it is the code that uses the link -- i.e., the SCSI drivers. > > > 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. I don't understand that. Suppose we have devices A1 and A2, where A1 is the parent and A2 is the child. In order to pass between the CPU and A2, data must flow through A1. Let D1 and D2 be the drivers for A1 and A2. It may be that for D2 to communicate with A2, it has to ask D1 to send or receive the data for it. Or it may be that once D1 has configured A1, data can flow automatically through A1 with no need for further involvement on D1's part. Would you say that in either case the flow of information has diverged from the device tree? Suppose D1 decides that it wants to suspend A1, thus breaking the data link to A2. Shouldn't it get D2's permission first? Better yet, shouldn't it wait until D2 tells it: "Okay, A2 is safely suspended and I'm not going to talk to it for a while, you can suspend the link"? Alan Stern - 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
