On Tue, 26 Apr 2005, Alan Stern wrote: > On Tue, 26 Apr 2005, Olav Kongas wrote: > > I haven't fully understood the intended relationship between > > device's and root hub's suspend/resume operations. The > > reason why root hub's suspend/resume are currently called > > from device's suspend/resume in isp116x-hcd was exactly to > > avoid this explicit double suspending/resuming via sysfs. > > Don't forget the world outside of USB! As far as I know there aren't any > other parts of the kernel where suspending/resuming a device will > automatically suspend/resume the children/parent. Why should USB be any > different? > > In any case, this sort of recursion belongs in the driver-model core > rather than in the individual device drivers.
Yes, sure. I will rework suspend/resume in isp116x-hcd. > > Thanks for explaining the plans about auto-suspend. I guess > > auto-suspend, when implemented in USB core, won't depend on > > CONFIG_PM? > > Actually it probably will. That might be a good reason to keep a minimal > auto-suspend capability in the HCDs, for use when CONFIG_PM is off. Why should USB core's auto-suspend depend on CONFIG_PM? In particular, if this results in (at least partial) duplication of the auto-suspend functionality in HCDs. Olav ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
