On Friday 09 June 2006 7:36 am, Alan Stern wrote: > On Thu, 8 Jun 2006, David Brownell wrote: > > > Agreed that with USB at least we know some good things to do which > > we have not yet done ... like autosuspending devices, and thereby > > reducing VBUS consumption by factors on the order of 100. (And > > because the functionality is associated with interfaces not devices, > > achieving some of those things calls for USB framework updates.) > > But this is another case where USB has PM needs that the rest of > > the kernel hasn't yet thought about yet. > > Interesting you should bring this up. As part of my autosuspend > development, I decided it would simplify things if devices and their > interfaces were always suspended together.
And for such discussions, the canonical example is a USB speaker interface (with various ISO-OUT altsettings) paired with a HID interface used for volume controls (one interrupt-IN endpoint). That is, two functions that are all but unrelated. > That is, I changed the bus-level suspend and resume routines so that a PM > request directed at a USB device always affects the device _and_ its > interfaces, We had code like that a while back, ISTR. It got removed as part of the "remove (most) PM recursion from the USB stack". For the record, I don't think I'd mind requiring that all interfaces be suspended or resumed together. But that does mean that if one can't be updated, changes to the others must be reverted... otherwise users could end up with a volume control that doesn't work (using that speaker example) and that would be Wrong. > while a request directed at an interface does nothing (but > returns 0). That seems odd. For example, how is the _device_ ever going to be able to suspend, if the interfaces always stay active??? There needs to be some mechanism whereby the interface drivers get suspended/resumed. And I don't see any reason not to use the existing one. > For system sleep this won't hurt anything, since everything > always gets suspended and resumed. Erm, that doesn't match what you said above, "does nothing". Surely if an interface's driver suspends, it must necessarily do something to quiesce the interface's I/O stream? That can't be done wholly at the usbcore level, since other parts of the driver stack need to participate ... > For runtime-PM using sysfs it > simplifies things, since userspace no longer needs to worry about > interfaces. I believe userspace should not worry about individual devices through the driver model in any case. Micromanagement doesn't generally work, outside of unit testing. > In most cases this is the appropriate thing to do. For single-interface > devices, or devices where a single driver manages multiple cooperating > interfaces (such as CDC), we definitely want this behavior. Indeed, the > alternative possibility -- that the device might be awake while the > interface drivers are suspended -- is pretty bad, because the drivers will > rely on remote-wakeup messages to notify them when something interesting > happens, and remote wakeup doesn't operate unless the device is suspended. Yes. > There might be a few cases where somebody _does_ want to suspend some but > not all of a device's interfaces. But such cases are likely to be quite > rare. For now it should be okay to disallow them. > > Do you agree with this reasoning? Sounds OK to me in general, though your "interface suspend does nothing" seems problematic. - Dave _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
