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]

Date:	Sun, 12 Nov 2006 16:59:09 -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:

> > Undoubtedly this change in behavior is caused by the "autostop" code I 
> > added to ohci-hcd.  It doesn't check the "wakeup" attribute.
> 
> That's the basic bug ... it needs to do that, like it does in a 2.6.18
> kernel I happen to still have sitting around.

It's not so clear whether this behavior is a bug.  Remember, autostop is 
different from autosuspend.  For instance, the root hub will never be in 
autostop mode during a system sleep (suspend to RAM or suspend to disk) -- 
hence autostop doesn't have to worry about waking up the system.

> > Dave, is there any clue about exactly what triggers the immediate wakeup?  
> > If you could tell me what to test for, I could try writing a patch to fix 
> > it.  Perhaps the driver needs a "resume_detect_is_broken" quirk.
> 
> It's an implementation bug in some silicon, or in some case some boards.
> 
> 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?

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

> Knowing this is a regression probably explains why that one patch adding
> the "broken suspend" board-specific quirk for the Tohsiba Portege 4000
> didn't work:  the mechanism it relied on (root hub marked as "can't wakeup")
> is broken.
> 
> I expect the AMD756 erratum 10 workaround is also broken, since that makes
> a point of initializing the root hub so that device_may_wakeup() prevents
> the autosuspend mechanism from kicking in.

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.

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/