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

[Dan Williams]

On Thu, 2013-10-10 at 17:43 +0200, Aleksander Morgado wrote:
> On 10/10/13 17:37, Ben Chan wrote:
> >     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,
> 
> Wait, you mean the modem will reply CPIN ready when CFUN!=1 even if
> SIM-PIN is required? Which modem is this?

One would certainly expect a "SIM NOT READY" error here; and we're
getting into "fix the firmware" territory.  In any case, workarounds
like this should be confined to the device's plugin if we can manage
that...

Dan

> 
> > 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.
>