On Fri, 7 Oct 2005, Olav Kongas wrote: > The last reply from Ivan, given below, shows that his chip > is reset during suspend to mem. The resume fails as the > isp116x-hcd's resume() method has currently no support to > handle the reset chip. > > I went thru the docs in kernel's Documentation/power/ and > understood that for supporting suspend to mem, the driver's > resume method must be prepared to initialize the hardware > from scratch.
That's right. One would hope that during suspend-to-RAM, there would be power available to maintain devices like the isp116x in a suspended state. Nevertheless, some systems don't provide such power and the devices get reset. Perhaps the platform code for this particular system can be tweaked so that suspend power _is_ provided? > Have I understood it right? If yes then the solution would > be to add the necessary state saving and restoring support > to isp116x-hcd. A quicker, temporary solution may be to > unload isp116x-hcd before suspend and reload it after > resume. The latter may not work for mounted memory sticks, > however. Saving and restoring the state won't work for mounted storage devices either, because you will not know whether the device was unplugged while the controller was reset. You will have to assume that it was, and report a connect-change event on each connected port. > I go look how other usb HCD's handle this. That's what uhci-hcd does. The resume procedure checks the state of the controller, to see if it is still suspended. If it isn't, the controller gets completely reset and the old state is lost. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
