Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[David Brownell <david-b@pacbell.net>]

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