On Wednesday 24 November 2004 08:03, Alan Stern wrote: > On Tue, 23 Nov 2004, David Brownell wrote: > > > > I would be happy to make it not be special by allowing any device to be in > > > USB_STATE_SUSPENDED, even when CONFIG_USB_SUSPEND is not set. The > > > difference being that when CONFIG_USB_SUSPEND is off, the only way for a > > > device to enter the state is for the PM core to suspend the root hub (and > > > hence the entire bus). > > > > That might be an useful intermediate step ... suspend() and resume() > > calls would be made. > > > > The thing that would necessarily be different is handling wakeup > > events ... they can't be issued without a real suspend state. > > This is an example of one of the things we probably don't need to > consider, if we just keep the drivers as they are. Yes, it will be buggy, > but no more so than it is now.
One reason I didn't go that route to start with is that we still don't have many drivers implementing suspend() and resume() methods. And things will start to break if devices that usbcore thinks are suspended still have drivers that are active ... we'll need to disconnect() those drivers, or do something similarly sensible. That is: we _will_ be buggier than now, until more USB drivers understand suspend() and resume(). So I think that particular intermediate step will need to be preceded by some driver updates. > > > Exactly. If the hardware allows using IRQs for port events, then great. > > > If not, but it allows polling, then the HCD can use polling if it wants. > > > > OK, I'm glad we can agree on that way of looking at things; > > it should help define HCD responsibilities better. (And I'm > > still expecting usbcore to change so the HCD can control > > whether it's polled by usbcore, or the HCD can just issue > > "status changed" calls. Simple patch.) > > Relatively simple, but it will take some care to make sure all the HCDs > use the new ability correctly. Would you like to start working on it, or > shall I? I think OHCI and EHCI will be more able to use it than UHCI, but if you want to start, be my guest. Otherwise it may take me a while to get to that. (I had in mind a flag in the HCD struct, initialized by board-aware HCD startup code, plus some call that the HCD can make from IRQ handlers to start what the timer calls now start.) > > > What _is_ true is that we don't want to autosuspend an input device that > > > can't issue resume events, > > > > As reported in the "can_wakeup" flag, added to the driver model > > by that one patch. > > Also affected by the wakeup_enabled flag. If a device isn't _allowed_ to > issue resume requests then we don't want to autosuspend it either. Yes. That's a different sense of the word "can" ... ;) - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
