On Sunday 07 November 2004 07:20, Alan Stern wrote: > On Sat, 6 Nov 2004, David Brownell wrote: > > > On Saturday 06 November 2004 14:24, Alan Stern wrote: > > > David: > > > > > > It would be surprising if you weren't already aware of this, but just in > > > case you aren't... > > > > It's always interesting to see if/when bug reports happen; yes.
And I should have mentioned the workaround: CONFIG_PM = n. > > I've got patches that resolve this, and I hope to post them soon. > > The root cause is "too many notions of root hub state", at least > > three ... the fix involves relying on usb_device->state in most > > cases, but there are a godawful number of code paths to test > > given the various ways to suspend/resume. > > Okay, sounds reasonable. Given that dev->power.power_state is being > devalued and given that the root hub shouldn't care about the PCI power > level (or non-PCI for alternative OHCI implementations!), root_hub->state > remains as the only candidate. There's also hcd->state. So for example, without CONFIG_USB_SUSPEND nothing ever suspends individual devices, including root hubs. Which means the root hub may be suspended, and even in a low power mode (so that registers read as all-ones, like CardBus eject), but only the HCD is marked as SUSPENDED (not root hub or any other device). Yet hub timers are firing, maybe accessing registers... Also there's hardware state. Particularly after resume from STD, there are lots of variables: S1 and S3 are only slightly different, but there are several STD variants (including swsusp and s4bios) combined with BIOS keyboard handling options, optional PCI PM support, power switching options, selective and system-wide wakeup ... ouch! > Once the PM core stuff gets into slightly better shape, it may be > necessary to rethink the interface between it and the USB drivers. For > instance, we will no longer want to suspend entire subtrees automatically > if the PM core does it for us. That mechanism might rely on whatever replaces sysfs power/state; we could reasonably offload the "suspend children first" requirement. In fact, the hub code would probably be better off even right now if it just refused to suspend if its children weren't suspended... Once the USB stack handles suspend/resume/wakeup in more different system configurations, it'll be a lot easier to do such rethinking. - Dave > Alan Stern > > ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
