On Wed, 24 Nov 2004, David Brownell wrote: > On Tuesday 23 November 2004 14:15, Alan Stern wrote: > > It's not a question of using timers or anything else. If wakeup_enabled > > isn't set then the HCD _must not_ allow wakeup/resume signalling in any > > form. Regardless of whether it is able to. That's the whole point of the > > wakeup_enabled flag, right? > > I'd describe "wakeup_enabled" as "allow wakeup", rather than > "!wakeup_enabled" as "... also treat wakeup as error".
Isn't that the same as what I just said? If wakeup_enabled set means "allow wakeup", then what can wakeup_enabled clear mean but "don't allow wakeup"? What else could it mean? I wasn't suggesting treating wakeup requests as errors; I was suggesting that they should be disabled entirely when wakeup_enabled isn't set. After all, your patch makes hub_port_suspend skip doing the set-feature(REMOTE_WAKEUP) if wakeup_enabled isn't set. Real hubs obey that feature setting, so virtual root hubs should also. > When devices misbehave, their parent devices will still > receive the wakeup signaling. I suppose the khubd could > just not resume devices when "!wakeup_enabled", but that > still wouldn't be a "must not". Obviously, when devices misbehave almost anything can happen. That doesn't diminish drivers' responsibility to make sure that the right things happen for properly behaving devices. Furthermore, things might not be under khubd's control. Suppose the HC device's wakeup_enabled is on but the root hub's is off. If the driver allowed the root hub to generate wakeup requests anyhow, it could wake the entire system up from a global suspend state before khubd has a chance to do anything. > > Without the possibility of resume signalling, we won't want to > > autosuspend the root hub. There's no argument about that, I hope. > > Without the possibility of resume signaling, no USB device will > really be suspended ... so whatever an HCD does to reduce power > consumption won't be "autosuspend", right? Drivers need to be > free to (transparently) reduce power usage at any time. Almost right. Even if resume signalling isn't allowed, USB devices will still be suspended whenever someone (like the PM core or sysfs) calls usb_suspend_device. But hubs won't autosuspend, so HCDs will have to do something else to reduce power. > I've called what OHCI does now "autosuspend", which expects IRQs > to work (and tolerates root hub timer polling) ... usbcore has > no need to care about that state. Maybe you should call it something else, if the root hub isn't totally suspended. Think of it this way: If root_hub->state == USB_STATE_SUSPENDED and the hub driver's hub_suspend routine has been called, then it really is suspended. Otherwise it isn't, it's only "half-suspended" or something similar. 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
