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

[Alan Stern <stern@rowland.harvard.edu>]

On Mon, 13 Nov 2006, David Brownell wrote:

> > Well, I would argue that part of the problem has to do with the use of 
> > device_may_wakeup.  It is tied to a sysfs API 
> 
> 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.

> > and therefore administrative  
> > in nature, but now you say it's also being used to record hardware quirks.
> 
> No; I'm saying the driver model is used to record that the hardware mechanism
> isn't available.   The fact that it's because of an implementation artifact
> (bad silicon, or board layout, etc) versus a design artifact (silicon designed
> without that feature) is immaterial ... in either case, the system can't use
> the mechanism.

But the information is being recorded in the wrong spot.  The correct test
should use device_can_wakeup, not device_may_wakeup.  The can_wakeup flag
is the one which records whether or not the hardware mechanism is actually
available.


> > > > If you think autostop should also check for device_may_wakeup(), I'll make 
> > > > it do so.  Remember though that autostop is intended to work even when 
> > > > CONFIG_PM is off.
> > > 
> > > The original autosuspend logic would never kick in without PM; after all,
> > > it's purely a power saving mechanism!  And testing device_may_wakeup() will
> > > be restoring that behavior, since without PM that's always false.
> > 
> > It would restore that behavior, and it would be silly way of doing so.  
> > There are better ways to prevent autostop without PM, such as making
> > ohci_rh_suspend() and ohci_rh_resume() depend on CONFIG_PM!
> 
> ISTR they do that too.  :)

They used to, but I changed it when I added autostop.  Looks like I need 
to change it back.

> > However it was always my intention that autostop should operate without
> > PM.  It's not only about saving power, it also is about reducing load on
> > system resources -- primarily DMA, although this may be a lot less severe
> > with OHCI than with UHCI.  Does OHCI do any DMA at all when no devices are
> > plugged in and the schedule is empty?
> 
> That's not an issue at all with OHCI; it only DMAs when the relevant
> schedule is enabled.  Which it isn't, unless it has work to do.
> 
>  
> > My quick impression from the spec is that it does not, in which case 
> > there is no point in keeping autostop when CONFIG_PM is off.
> 
> Exactly.  That's why I said it's purely a power saving mechanism.

Okay.  I'll write a patch to eliminate autostop and those routines when
CONFIG_PM is off.

But that doesn't answer the question above: Should autostop check 
device_can_wakeup rather than device_may_wakeup?

Also: Does the quirk/bug detection logic clear can_wakeup, as it should?  
Or does it only affect may_wakeup?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/