On Thu, 19 Jul 2007, James Graves wrote: > Hello all, > > We're working on suspend / resume again with a Sierra Wireless modem > (the MC8775 in our case). > > We're actually doing a 'suspend' this time (instead of 'hibernate'). > The openSUSE website was very helpful in setting up the parameters for > the s2ram utility. > > Anyway, the first issue we're faced with is that the modem appears to > reset sometime during the suspend / resume cycle.
Warning: You're opening a can of worms! > When the system resumes, we're basically seeing a disconnect sequence > and then a reconnect sequence. Meaning that it is nearly the same > series of events as if you unplugged the modem, and plugged it back in > again. > > So this is all not entirely unexpected, but it is causing us some issues > at the application level. > > This is because the user-level application still has the /dev/ttyUSBx > device files open. When the system comes out of suspend, it seems to > see that these device files are still in use, and the modem is assigned > to a different set of device files. So, for example, if we started out > with: > > /dev/ttyUSB0 > /dev/ttyUSB1 > /dev/ttyUSB2 > > after coming out of resume, the modem is now at: > > /dev/ttyUSB3 > /dev/ttyUSB4 > /dev/ttyUSB5 > > It looks like the modem itself is being reset. Is this to be expected? Yes, depending on your motherboard and USB controllers. However the application should be able to handle this. It's no different from what would happen if the user really did unplug the modem and then plug it back in. In theory that could happen at any time, regardless of any suspend activity. > ------------------------------------------------------------------- > > I've tried a suspend / resume cycle with another USB serial device, a > Belkin RS-232 serial converter which uses the mct_u232 driver. > > And here we're seeing basically the same thing. When initially plugged > in, it comes up as /dev/ttyUSB0. I can fire up minicom, and talk to > another RS-232 device. > > When the system comes out of suspend, the serial converter is back as > /dev/ttyUSB1. The minicom application is of course clueless as to what > has happened, and communication to the other RS-232 device no longer works. > > ------------------------------------------------------------------- > > So the question in my mind is now this, is it possible to close the > driver upon suspend? Would this allow the device, when it is "plugged > back in" to get the same /dev device file(s) it previously had. If you exited from minicom or your other application before the suspend and then restarted it after the resume, you should be okay. Is that what you're asking? > This will still leave the application with an invalid file descriptor, > but at least it wouldn't have to go looking around for a different > device file. > > Any advice appreciated. Just recently added to the mainline GIT tree is a way around your problem. (It has been in Greg KH's development tree for some time now.) You can read all about it in Documentation/usb/persist.txt. To make this work, your device driver must define a "reset_resume" method. It will be called in place of the regular "resume" method if the device has been reset. It can reinitialize the device and put it back in the original pre-suspend condition, after which it ought to continue operating normally. The application wouldn't notice a thing, except perhaps that the serial connection had been lost. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
