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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
