Message-Id: <200611130839.11459.david-b@pacbell.net>
Date:	Mon, 13 Nov 2006 08:39:11 -0800
From:	David Brownell <david-b@...bell.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	arvidjaar@...l.ru, linux-usb-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

On Monday 13 November 2006 7:57 am, Alan Stern wrote:
> On Sun, 12 Nov 2006, David Brownell wrote:
> 
> > > Or are you trying to say that the original device_may_wakeup() value would 
> > > be 0 if the bug were detected?
> > 
> > The latter:  device_may_wakeup() never returns true.  There are three paths
> > for that:
> > 
> >   (a) userspace workaround, which is the regression that was reported;
> >   (b) the AMD 756 workaround, and
> >   (c) that board-specific quirk code.
> > 
> > Of course (c) hasn't been submitted yet because it didn't work ... evidently
> > because of the regression where device_may_wakeup(root_hub) was ignored.
> 
> 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".


> 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.


> > > 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.  :)

 
> 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.

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

Powered by blists - more mailing lists