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.
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?
-------------------------------------------------------------------
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.
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.
Thanks,
James Graves
-------------------------------------------------------------------------
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
