If a suspend/resume cycle happens or ModemManager is restarted (e.g.
after a crash) the modem may be left with a given session id
connected. With this change we're forcing a session disconnection
before we attempt a session connection.
https://bugs.freedesktop.org/show_bug.cgi?id=102231
If PIN1 is disabled and we have tried to enable it with a wrong PIN, a
MBIM modem would have indicated the number of remaining attempts for
PIN1 (unless PUK1 is engaged) in the response to the failed MBIM_CID_PIN
set operation.
However, a MBIM_CID_PIN query may be issued (e.g. MMBaseSim calls
mm_iface_modem_update_lock_info()) after the MBIM_CID_PIN set operation
to query the number of remaining attempts for a PIN type. Unfortunately,
we can't specify a particular PIN type in a MBIM_CID_PIN query. The
modem may not reply with information about PIN1 if PIN1 is disabled.
When that happens, we would like to preserve our knowledge about the
number of remaining attempts for PIN1.
This patch modifies MMBroadbandModemMbim's load_unlock_retries()
operation to carry over any previously observed information on PIN1 if
the MBIM_CID_PIN query reports something other than PIN1.
After MMSimMbim performs a MBIM_CID_PIN set operation, it calls
mm_iface_modem_update_lock_info() (through its base class MMBaseSim) to
refresh the unlock retries information, which results in a MBIM_CID_PIN
query. However, a MBIM_CID_PIN query reports only the information of one
PIN type and the PIN type can't be specified, we need to deduce the
number of retries left for a specific PIN type from the response of a
MBIM_CID_PIN set operation for that PIN type. To allow that, this patch
modifies MMSimMbim to update the unlock retries information after a PIN
operation based on the response to the MBIM_CID_PIN set operation.
This patch exports the internal function update_unlock_retries() in
MMIfaceModem as mm_iface_modem_update_unlock_retries(), which later
allows us to call it from other classes.
Ben Chan
Aleksander Morgado
Arto Jantunen