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