Fail to load SIM information during modem initialization when modem in CFUN 4 state

[Ben Chan]

> I'm not sure I've seen this with other modems, but it really does seem
> unfortunate. Reading this information so late just makes useless any
> attempt to e.g. try to match connection settings to IMSI (which would be
> useful to decide which SIM-PIN to automatically send). But anyway, if
> possible, I think we should probably try to implement this and provide
> proper values whenever we can get them.
>
> Reading SIM-related read-only properties is attempted twice now: during
> the initialization phase, even if SIM-PIN is required; and also when
> re-running the initialization phase after sending SIM-PIN. We could
> definitely add a third try after going into full functionality mode
> (e.g. CFUN=1), but if so I'd suggest to do it in such a way that we let
> plugins decide when they want to do it. Some plugins will never load
> e.g. IMSI well even in the two attempts that we currently do, so we
> shouldn't retry it a third time just to see it fail. A boolean property
> in the MMIfaceModem interface could help, stating whether
> mm_sim_initialize() should be called as an additional step after
> ENABLING_STEP_SET_POWER_STATE.
>
> In which modem(s) have you seen this?
>
>
The issue may be trickier than that. The modem has the SIM interface
de-activated but incorrectly reports CPIN Ready. If that's fixed,
ModemManager will fail to determine the SIM lock state and put the modem in
the failed state. I guess, on a per plugin basis, we may need to do:

1. After checking the current CFUN state, change to CFUN=1 if it isn't
2. Perform the CPIN? check and load ICCID, IMSI, etc
3. At the end of the initialization, restore the CFUN state

However, that certainly increases the modem initialization and enabling
time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20131010/e86afa5f/attachment.html>