On Tuesday 14 November 2006 1:42 pm, Alan Stern wrote:
> On Tue, 14 Nov 2006, David Brownell wrote:
>
> > On Monday 13 November 2006 9:15 am, Alan Stern wrote:
> > > On Mon, 13 Nov 2006, David Brownell wrote:
> > >
> > > > It's a *driver model* API, which is also accessible from sysfs ... to support
> > > > per-device policies, for example the (a) workaround. The mechanism exists
> > > > even on kernels that don't include sysfs ... although on such systems, there
> > > > is no way for users to do things like say "ignore the fact that this mouse
> > > > claims to issue wakeup events, its descriptors lie".
> > >
> > > Yes, it is separate from sysfs -- but it is _tied_ to the sysfs API.
> >
> > I can't agree. If you deconfigure sysfs, it still works.
> > Since it's independent like that, there's no way it's "tied".
>
> We could carry on this argument indefinitely. Yes, the device_may_wakeup
> stuff does work without sysfs. But it doesn't do anything significant; it
> amounts to no more than device_can_wakeup(). AFAIK there's no way to
> change the setting of the may_wakeup flag other than via sysfs. That's
> what I meant by "tied".
So "tied" means "nobody has yet needed to create a different API for
that subset of the mechanism"? Still can't agree. Nothing's preventing
anyone from creating such an API, if they need to.
> > So "may" is correct, and "can" is insufficient.
>
> Things work differently in uhci-hcd.
They shouldn't. That's the point of having this in the driver model:
so that all wakeup-capable devices can/will act the same in terms of
the basic capability and policy.
(Of course, there are ugly PPC/OF-only enumeration issues that keep us
from kicking in the wakeup mechanisms for PCI devices. But that's a
separate issue, specific to PCI ... although it sucks hugely, since
so few developers have non-PCI wakeup-capable devices.)
> However even when it is added and may_wakeup is off, autostop will still
> function. It won't rely on interrupts or other wakeup events, though --
> instead the root-hub status polling mechanism will be used.
Well, as was said previously: For UHCI it's not "just" a PM mechanism.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
