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: <Pine.LNX.4.44L0.0611131040590.2260-100000@iolanthe.rowland.org>
Date:	Mon, 13 Nov 2006 10:57:58 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	David Brownell <david-b@...bell.net>
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 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 and therefore administrative 
in nature, but now you say it's also being used to record hardware quirks.

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

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?

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.

Alan Stern

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