Modem reset handling

[Aleksander Morgado]

Hey,
>
> I am writing an application that handles (multiple) LTE modems (currently using Sierra EM7455, but it is intended to be generic). The application makes calls to libmm-glib (version 1.12) to handle various modem actions.
>
> To reset the modem it calls mm_modem_reset_sync. The call returns TRUE. However, the modem has not yet been reset, and if I attempt other operation with the modem too soon, they will later fail with the error message:
>
> GDBus.Error:org.freedesktop.libqmi.Error.Core.Timeout: Transaction timed out.
>
> Also I noticed that the modem DBus path changes after each modem reset:
>
> /org/freedesktop/ModemManager1/Modem/2 --> reset -->  /org/freedesktop/ModemManager1/Modem/3
>
> I have 2 questions:
>
> 1. Is it possible to know when the modem is ready after it comes out of the reset? Or what is the best way to handle the reset?
>

After the reset operation is successful in the API, the user of the
API should expect the modem object to disappear from the bus and a new
modem object to reappear. The modem will be ready to be used after the
reset once the new object has been exposed in the bus.

> 2. Is it possible to reset the modem, and have the DBus path not change?
>

Nope; that's actually a feature :) When the DBus path changes after a
reset we're telling upper layers to treat the modem as a fully new
one, as if a physical hotplug had occurred.

If you want a fixed reference for a given modem, you can use the
device sysfs path ("device" field in mmcli output), that path will be
the same one for as long as the hardware layout doesn't change. So, if
a given modem goes away and appears a new modem object with the same
device sysfs path, you can assume it's the same device: you should not
assume it has the same SIM card, or the same carrier config, though;
which is why we treat the newly exposed modem as a fully new modem,
even if it really was never unplugged from anywhere.

-- 
Aleksander
https://aleksander.es