On Mon, 8 Nov 2004, David Brownell wrote: > 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"?
Sorry about that... Greg was referring to the intermediate state of the hcd memory cycle, where the driver was responsible for allocating the storage and the core was responsible for freeing it. As a corollary, drivers were forced to embed a struct usb_hcd at the very start of their private structure. The patches I wrote change all that and move the memory operations into the core. Most of the areas of conflict are places where I converted, for example, ohci->hcd into ohci_to_hcd(ohci). > > 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 ... :) This was part of the reason I suggested (in a different context) that it might make sense to have a field in the driver model power structure to keep track of whether or not a device is frozen. Subsystems other than USB might have the same need to know the current setting, and it wouldn't hurt to have the information kept in a standard location. > > 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. Okay, I concede the point. > 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.) Exactly. Drivers should stop everything whenever their interface is frozen. Only usbcore should worry about actually changing power levels during a SUSPEND call. (It may turn out, by coincidence, that a frozen device does end up getting suspended -- if the controller is UHCI for instance -- but that shouldn't affect anything.) 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
