On Fri, Aug 11, 2017 at 1:05 PM, Tim Small <t...@seoss.co.uk> wrote:
> A couple more questions...
> What should the code do if a return to AT command mode fails? Currently
> the code just continues to try and use a port which is still in data
> mode - issuing AT commands on it...
Yeah, not ideal :)
> In my case I'd like to be able to (as a last resort) power-cycle the
> modem if it remains unresponsive. Being able to do this is quite common
> for embedded systems (and with most phones entering "aeroplane mode"
> does that too). One possible way to integrate that would be to allow an
> external binary to be specified via a udev rule, does that sound reasonable?
No, we shouldn't call any external binary. I'd suggest we try to move
that modem to "Failed" state instead, as we really lost the control
port; and let the applications using MM do whatever they need to do
with a failed modem, including external power cycle or whatever.
Actually, IIRC, there should already be some mechanism to detect an
unresponsive TTY and if it's the control port of a modem, do a full
modem removal and re-probe (e.g. for RS232 modems which get suddenly
ModemManager-devel mailing list