On Monday 08 November 2004 07:35, Alan Stern wrote: > On Wed, 3 Nov 2004, Greg KH wrote: > > > Applied, thanks. > > > > But please fix this up soon, I really don't like this restriction. > > I worked out a series of patches over the weekend, but they conflict in > several spots with these patches from David. What would you like me to > do?
I'm missing some context there ... what is "this"? > On Sun, 7 Nov 2004, David Brownell wrote: > > > Hi, > > > > Following this will be four patches. These four patches, all curiously > > about the same size, have been tested: > > > > ... > > > > And they all worked, which is a milestone! ... a few > > of the 2^7 combinations there could still stand more work, and there are > > other things that need attention too. ... > > > > I'm thinking that these should all get merged. In particular, there > > have been some significant problems recently with OHCI recently, and > > these fix them for me; 2.6.10 shouldn't ship with those problems. > > > > Comments? > > Although this may not be the best time for it, I would like to see all > those USB_STATE_... things for host controllers turn into HCD_STATE_... Fine with me, but I was trying to keep this patch to just bugfixes. I'm glad to know that USB-vs-HCD thing gets on more nerves than just my own! > It's not a good idea to rely on the power.power_state field for the > interface devices. What should be used instead? I want to see that field vanish, but there'd need to be something in usb_interface to replace it. And that wouldn't be a bugfix ... :) > In fact, is there really any point in allowing an > interface to be suspended without suspending the entire USB device? Selective suspend is allowed elsewhere; why would it be prohibited here? One point would be just reflecting reality: one of the device's functions (say the speakers) can be suspended while another (say the controls) is active. > This > seems especially problematic when a driver owns several interfaces on the > same device. Only if by "problematic" you mean "driver must suspend all its interfaces together". That seems like a really basic concept, something that needs to be solved for other cases. (Including drivers for a piece of hardware that includes several controllers that work together. Where that "piece" is much less than the entire system.) Admittedly the PM core code doesn't expect that to happen! Such drivers need to expect multiple suspend calls. > I suggest the code be restructured so that the bus routines > basically ignore suspend/resume calls for interface devices. Why would USB functions be any more restrictive than others? Consider the analogy with PCI: both have multi-function hardware, but for USB it's a "device" not a PCI "card". > Then the > interfaces will always be in the same state as the physical devices. That'd be trouble. Consider interfaces using iso transfers, which can be idle/quiesced/frozen using altsetting 0 (no endpoints), while the device is active: different states. The state that's shared among all interfaces is already accessible through that parent device. I've been thinking that the interface drivers are mostly doing freeze/thaw style operations, rather than real power management operations ... but with some hardware, that could actually affect the power usage. (Speaker on/off, etc.) - Dave > Alan Stern > > ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
