Re: PATCH/RFC: usbcore wakeup updates (3/4)

From: Pavel Machek
Date: Thu Oct 07 2004 - 16:28:37 EST


Hi!

> > > There were already some hooks in usbcore, but they were only
> > > configurable for root hubs ... but not keyboards, mice, Ethernet
> > > adapters, or other devices.
> >
> > That "when asked about D1 enter D3" bit worries me a bit, because
> > it is (ugly) workaround to core problems, but I can survive it.
>
> I'm not sure what a better fix would be though ... I think WIndows
> doesn't bother entering a low power state at all in such cases.
> Which seems particularly pointless for the typical USB controller,
> which is probably idle at that point already, and which can't take
> all that much longer to resume from D3hot than from D1.

Hmm, perhaps it is wrong thing to tell the devices what state to enter
in the first place.

> Do you think adding those two bits to per-device PM state
> is basically a good way to introduce their wakeup capabilities
> to the PM core? Suggestions on the next step?

It did not look overly ugly to me... so it is probably okay. Not sure
what the next step is -- you'll probably want some sysfs interface for
suspending single devices?

> > Introducing enums where PCI suspend level is stored in u32
> > would be welcome...
>
> I'm not averse to enums, especially once sparse does good things
> with them, but I still think that sort of change would just be nibbling
> around the edges of a larger problem. (Which should be addressed
> by different patches making device power states/policies, like G0/D1
> or "idle yourself", be types that are fully distinct from system power
> states like G1/S3, and for which abuse creates compiler errors.)

I'm not sure we want to move to anything complicated than simple enum.

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/