Many of the issues raised here were concerned with how to handle the case of CONFIG_USB_SUSPENDED not set. Given the strategy of maintaining the drivers' current behavior for that case, there's not much point in worrying about it any more. But one or two aspects may still be of interest...
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. > > 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? > > Otherwise, if the hardware doesn't provide any resume request capability, > > the HCD must clear the can_resume flag (not the can_wakeup flag; I mixed > > the two of them up, sorry). > > I'm still assuming there's no can_resume flag... > > All USB hubs that can put ports into the USB suspend state must > be able to report resume signaling from the downstream devices; > I think we shouldn't worry about ports not reporting it. The > root hub code could just fail requests to suspend those ports. I was speaking of suspending the root hub, not an external hub. But it looks like all root hubs ought to be able to support resume requests by polling if nothing else, so this is a non-issue. > > > The code duplication was inherent in having CONFIG_USB_SUSPEND be > > > a compile time option, last I looked. And it was just a handful > > > of lines at best; everything else involved state that wasn't > > > directly visible to upper level code. > > > > But it can lead to other problems. For example, suppose we agree that > > usb_suspend_device should change every device on the bus to > > USB_STATE_SUSPENDED when the root hub suspends and CONFIG_USB_SUSPEND > > isn't set. Your way, it would be necessary to change the OHCI driver as > > well as usb_suspend_device. > > Nope. How could a port be suspended without the device being > in USB_STATE_SUSPENDED? So if autosuspend ever kicks in, it's > by definition safe: either no devices on that root hub, or only > devices which have already suspended. This is yet another of those things that doesn't matter. However I still want to point out a couple of things: A device can be suspended without its parent's downstream port being suspended; the two notions are not identical. And devices can get suspended without autosuspend ever kicking in (when a PM sleep transition occurs, for example) -- that's what I was talking about. > > 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. Alan Stern ------------------------------------------------------- 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
