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