[PATCH V2] altair-lte: mark SIM provisioned in load_subscription_state

[Prathmesh Prabhu Chromium]

On Fri, Oct 11, 2013 at 12:22 PM, Aleksander Morgado
<aleksander at lanedo.com>wrote:

> On 11/10/13 19:10, Dan Williams wrote:
> > On Thu, 2013-10-10 at 14:31 -0700, Prathmesh Prabhu wrote:
> >> > An unknown --> home (roaming) registration state change is not
> visible to the
> >> > plugin until mm_iface_modem_3gpp_reload_current_registration_info
> completes.
> >> > This causes the subscription state check during registration to miss
> the fact
> >> > that registration was successful.
> >> >
> >> > load_subscription_state is intended to check subscription state
> >> > post-registration. As an initial implementation, mark the SIM
> provisioned in
> >> > absence of more information post-registration.
> > Ok, to clarify here, when update_registration_state() gets called in
> > response to either a poll or an unsolicited registration state message,
> > it only sets the new registration state *after* it calls
> > mm_iface_modem_3gpp_reload_current_registration_info().  So the sequence
> > is:
> >
> > something sets old registration state>
> > ... (time passes)
> > new registration state read
> > update_registration_state() called
> > if (home | roaming)
> >    mm_iface_modem_3gpp_reload_current_registration_info()
> >      loads operator code
> >      loads operator name
> >      loads subscription state
> > <note that nothing here knows about new registration state>
> > update_registration_reload_current_registration_info_ready() called
> > sets new registration state on skeleton
> > updates 3GPP subsystem state
> >
> > So yeah, if a plugin overrides load_subscription_state, and the
> > registration state changes to home|roaming, there's no way the plugin's
> > load_subscription_state can figure out the new registration state.
> >
>
> If load_subscription_state is called, the modem is registered in either
> home or a roaming network. Not sure it needs to know anything else.
>

Correct. The problem here is with the plugin's overriding implementation of
update_registration_state. If it chains up to mm_broadband_modem's
implementation, it will miss out on successful registration updates,
because the asynchronous call sequence for update_registration_state
finishes without updating the registration state to home (roaming).

>
> > I wonder why the new registration state isn't set immediately in
> > update_registration_state() before loading the operator stuff?  If we
> > fail to load operator name/code/subscription, IMHO we should still set
> > the correct registration state for the modem.
>
> The new registration state is set in the interface after loading
> operator code/name, so that clients getting notified about the new
> REGISTERED state can read the new operator code/name right away. You
> just need to assume that if
> load_operator_code/load_operator_name/load_subscription_state is called,
> the modem is already registered, even if the interface doesn't say it.
>

I agree with the reasoning that the registration_info should be valid when
the registration state is set to a REGISTERED state.

>
> > We could delay the
> > mm_iface_modem_update_subsystem_state() until the current registration
> > information is loaded if modem state changes might make the call chain
> > too complicated.
> >
> > Aleksander, what do you think?  If this were done, Prathmesh, would this
> > Altair patch still be needed?
>
> I would actually update Prathmesh's patch and make it the default
> implementation in MMBroadbandModem. This is, whenever we're registered
> in the network, we can safely? say that the subscription state is
> PROVISIONED (otherwise it wouldn't have registered, right?). Then,
> whenever Altair makes use of the PCO info, they can subclass this
> load_subscription_state() method and provide a more detailed value if
> needed.
>

I like this approach. Plugins will then override load_subscription_state to
use more detailed information (like the PCO) info to take a more informed
decision.

I'll send in a patch for this.


> --
> Aleksander
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20131018/2feb8506/attachment-0001.html>