Prior to this change, a hotswap on the inactive slot would result
in reprobe of the modem. With this change, the sim object would be
updated, but no reprobe will be performed. The advantage is
1) we do not drop connections on the active slot
2) Slot status on the inactive slot is susceptible to firmware bugs.
We have seen scenarios where the inactive slot is reported as
absent/ iccid={0}, followed by a correction. We should not
reprobe the modem if our active slot hasn't changed.
If a SIM is known to exist, for e.g. if it was created during load_sim_slots,
persist a few more times before giving up on the SIM to be ready. There
are modems on which the SIM takes more than 15s to be ready, luckily,
they happen to be QMI modems where the SIM's iccid in load_sim_slots
lets us know that there is a sim.
MM used to iterate over each SIM slot to load IMSI, operator name etc.
However, switching slots at start up caused a few issues in the real
world.
a) Sierra Wireless' AUTO-SIM feature, the hidden SIM slot switching
is actually triggering a full modem reset (because the firmware
detects a new SIM for a different operator, and automatically resets
itself to load the firmware+carrier config associated to that other
operator).
b) The IMSI on slot 2 is reported to be the same as slot 1.
This is solved by adding a 1000ms delay before reading IMSI
on slot 2, after GET_CARD_STATUS indicates the sim is ready. The
delay means a 2s startup penalty when both slots are loaded.
c) 2/5 developers have encountered a fw bug where the modem
incorrectly reports that the SIM on slot 1 has vanished
after the sequence of slot switches. This makes the modem
unusable.
d) If the eSIM daemon changes slots and opens a channel to the eUICC,
MM will detect a hotswap, and break the channel during reprobe.
e) SIMs from a certain large operator in the US take over 20s to be
ready. Thus, switching to such a SIM for just loading IMSI may not be
worth it.
This change does not affect detection of sims in all slots. We still
expose the iccid and presence of all sims. However, properties like
IMSI and operator_name will not be exposed for the inactive slot.
Prior to this change, hotswap was detected on the primary sim slot only.
After this change, hotswap on any slot triggers reenumeration of the
modem. SIM hotswap events happening on the non-active slot would also
trigger a full modem reprobe. The modem may already have been
connected while the SIM event happens on the secondary slot, and we force
disconnection to reload the inactive SIM info. However, a user would
expect feedback for their SIM action, so we need to reprobe the modem.
Enabling/Disabling/Changing/Sending the PIN1 lock is usually limited to
3 retries. If these attempts are exhausted, the modem is puk_locked.
We reprobe the modem to get rid of any unwanted interfaces and move
to a locked state.
If the lock status cannot be read during a puk unblock attempt, reprobe
the modem. It is likely that the SIM was permanently blocked if the lock
status cannot be read.
Fixes a bug introduced in commit 7e386389, which caused user requested
disable operations to go to step
DISABLING_STEP_FIRST_AFTER_ENABLE_FAILED. For user requested disable,
the first step should be DISABLING_STEP_FIRST.
Prior to this CL, failure to get pin status while probing facility locks
would not flag an error. Failure to read a pin lock is a critical error
and we return it to higher layers.
DMS_UIM messages have been deprecated, and have been replaced by
equivalent UIM messages. Use UIM_GET_CARD_STATUS while querying for facility
locks if dms_uim messages were found to be deprecated.
Pavan Holla