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 10:00:21 -0800
From:	David Brownell <david-b@...bell.net>
To:	stern@...land.harvard.edu, arvidjaar@...l.ru
Cc:	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

> > > > 	echo -n disabled >
> > > > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup
> > >
> > > That's what I meant ... thanks, and sorry for the confusion.
> > 
> > this does not work anymore in current rc5. After writing 
> > cat /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup shows "disabled" 
> > but messages continue to be logged.
> > 
> > Anything I can do to help narrow it down?
>
> 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.

> 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.  A quick glance at your new
"autostop" code shows that it only checks whether ports are enabled;
those other important constraints have been removed.

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.

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