<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 12:22 PM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@lanedo.com" target="_blank">aleksander@lanedo.com</a>></span> wrote:<br>

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

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> I wonder why the new registration state isn't set immediately in<br>
> update_registration_state() before loading the operator stuff?  If we<br>
> fail to load operator name/code/subscription, IMHO we should still set<br>
> the correct registration state for the modem.<br>
<br>
</div>The new registration state is set in the interface after loading<br>
operator code/name, so that clients getting notified about the new<br>
REGISTERED state can read the new operator code/name right away. You<br>
just need to assume that if<br>
load_operator_code/load_operator_name/load_subscription_state is called,<br>
the modem is already registered, even if the interface doesn't say it.<br></blockquote><div> </div><div>I agree with the reasoning that the registration_info should be valid when the registration state is set to a REGISTERED state.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> We could delay the<br>
> mm_iface_modem_update_subsystem_state() until the current registration<br>
> information is loaded if modem state changes might make the call chain<br>
> too complicated.<br>
><br>
> Aleksander, what do you think?  If this were done, Prathmesh, would this<br>
> Altair patch still be needed?<br>
<br>
</div>I would actually update Prathmesh's patch and make it the default<br>
implementation in MMBroadbandModem. This is, whenever we're registered<br>
in the network, we can safely? say that the subscription state is<br>
PROVISIONED (otherwise it wouldn't have registered, right?). Then,<br>
whenever Altair makes use of the PCO info, they can subclass this<br>
load_subscription_state() method and provide a more detailed value if<br>
needed.<br></blockquote><div> </div><div>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.</div><div><br></div>

<div>I'll send in a patch for this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
</font></span></blockquote></div><br></div></div>