On Wednesday 24 November 2004 13:25, Alan Stern wrote: > 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?
"should" is weaker than "must". There are devices that ignore the setting of the device's remote wakeup feature flag (or maybe the default is just set wrong: "on", not "off"). Likewise "enable" is different from "allow". That's how it's different: "device not enabled to issue wakeup signaling" doesn't (in RFC terms) imply that it "MUST NOT". By intent: there are completely reasonable ways to handle the cases where it surprised us. If it issues a wakeup without being specifically enabled, to do that, maybe it's no big deal, and the event just gets ignored. Or maybe, as in the current code, it's no big deal, and the event gets handled normally. > I wasn't suggesting treating wakeup requests as errors; You emphasized "_must not_" as if it were following RFC semantics, which makes violating the rule be an error. That's why I thought that you were! > 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. As in, always force the device feature flag to the right value? That makes sense. (Wasn't clear to me that's what you were talking about.) > Real hubs obey > that feature setting, so virtual root hubs should also. Right, but real devices get less validation than hubs, and I'm told some will misbehave there. One way to make it easier to cope with things is to avoid having too many flags. > > 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. But what _should_ happen? Your "must" means "it's an error", and that's what bothered me. Why not just cope with it? Errors are severe things, not for easily-ignored noises. > 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. I don't understand how a hub that's "off" could generate any kind of event at all! > > > 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. Eventually; though you were also talking about an intermediate step where the devices receive SOFs but are in USB_STATE_SUSPENDED... > But hubs won't autosuspend, so HCDs will have to do > something else to reduce power. I didn't say "no autosuspend", where did that come from? > > 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, That's a generic term though; I'd call lots of things "autosuspend". Calling it something else wouldn't change the fact that OHCI calls that state "suspended", without reference to the Linux PM framework, and that the driver automatically puts the hardware into that state whenever it makes sense. > 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. It's what the OHCI spec describes as "suspended"; no "half" about it. Would you be happier to talk about different mechanisms like "controller autosuspend" (what OHCI does) versus "hub autosuspend" (does those other things too)? The HCD hub_suspend() method doesn't change anything except HC registers, so it's for "controller suspend". - 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
