On Tue, 13 Jun 2006, David Brownell wrote:
> > 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.
Or a USB disk drive with an additional HID pushbutton interface.
> > 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.
Yes. My patch takes care of that; if a suspend fails partway through then
the routine goes back and resumes the interfaces which had gotten
suspended.
> > 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.
What I mean is:
echo -n 2 >/sys/.../4-2/4-2:1.0/power/state
does nothing, while
echo -n 2 >/sys/.../4-2/power/state
calls all the interface drivers' suspend methods and then suspends the
device itself. That's what you had in mind, right?
> > Do you agree with this reasoning?
>
> Sounds OK to me in general, though your "interface suspend does nothing"
> seems problematic.
Probably just a misunderstanding...
Alan Stern
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
