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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200611121521.22105.david-b@pacbell.net>
Date:	Sun, 12 Nov 2006 15:21:21 -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

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