On Monday 08 November 2004 09:59, Alan Stern wrote: > On Mon, 8 Nov 2004, David Brownell wrote: > > > 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).
I guess I'd need to see that patch. I was kind of hoping to hold off on cleanups in favor of bugfixes for a while, at least inside usbcore. We're still shaking out the consequences of merging all those other changes ... > > > 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. I've got to catch up on those linux-pm discussions (I was doing some PM work instead of discussing it :) ... but last time I checked in, I didn't like the way "frozen" was getting addressed. It was looking more and more like a swsusp-specific state that's just a workaround for not having selective resume for the device on which the swsusp snapshot would be written out... > > > 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.) Except it doesn't seem to me like it can be so neat, especially given those examples where "frozen" is by definition a power reduced state. (No audio out, so the device disables all that circuitry...) The last notion that made sense to me was having "frozen" just be another suspend state ... one that places even fewer constraints than system-S1 does. - 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
