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

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

> > That's why the original OHCI autosuspend code initialized the "can this
> > root hub autosuspend" by testing the root hub wakeup flag:
> > 
> >         can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
> > 
> > and then cleared it if any enabled port wasn't suspended, any schedule
> > was active, or any deletions were pending.
> 
> But the silicon or board-level implementation bug you mentioned wouldn't 
> cause any of those tests to succeed, would it?  Hence it wouldn't prevent 
> an unwanted root-hub suspend.
> 
> 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.


> >   A quick glance at your new
> > "autostop" code shows that it only checks whether ports are enabled;
> > those other important constraints have been removed.
> 
> No, you must have misread the code.  It retains the checks for active 
> schedules or pending deletions.  There's no need to check for unsuspended 
> enabled ports, since autostop kicks in only when no ports are enabled.

Well, there are at least two regressions then.  One is the one in $SUBJECT,
and the other is for suspended-but-enabled ports.  (You've argued the latter
would be handled by a separate mechanism; fair enough, but I'm pointing
out that it's still a regression.)


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

- Dave