Hi jeevaka,
>> static void sim_iccid_read_cb(int ok, int length, int record, @@
>-1454,6 +1452,8 @@ static void sim_initialize(struct ofono_sim *sim)
>> ofono_sim_read(sim, SIM_EFPL_FILEID,
>> OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
>> sim_efpl_read_cb, sim);
>> +
>> + sim_pin_check(sim);
>> }
>
>> static void sim_op_error(struct ofono_sim *sim)
>> --
>> 1.7.0.4
>
>As per the 3GPP 31.102 section 5.1.1.2, CHV1 verification procedure will
>be done after reading of EFli and EFpl. Earlier( before "sim: Reorder
>SIM initialization" patch) src/sim.c had the sim_pin_check()called from
>sim_efphase_read_cb() where it called after issuing EFli and EFpl file
>read request. The patch "sim: Reorder SIM initialization" changed it to
>call from sim_efpl_read_cb() which is as per the specification.If the
>reading of EFli and EFpl fails, then sim_pin_check is not getting called
>because we are returning from "if (sim->language_prefs == NULL)". In
>your patch, you are moving it to be called after the EFpl read request
>which is same as what we had before "sim: Reorder SIM initialization"
>patch. I believe the right place to call the sim_pin_check() will be
>before the if condition(if (sim->language_prefs == NULL)) in
>sim_efpl_read_cb(), like shown below
>
> if (efpl) {
> g_slist_foreach(efpl, (GFunc)g_free, NULL);
> g_slist_free(efpl);
> }
>
> sim_pin_check(sim);
>
> if (sim->language_prefs == NULL)
> return;
>
> ofono_dbus_signal_array_property_changed(conn, path,
>
>OFONO_SIM_MANAGER_INTERFACE,
> "PreferredLanguages",
> DBUS_TYPE_STRING,
> &sim->language_prefs);
>
>Let me know your views on this.
Your solution is better than mine, and might be Denis' intention of
modification. Honestly, I ever thought about the change like your proposal
(Actually it was the same as ppessi's patch), but I had a concern on current
code. Now we read EFli and EFpl in parallel. Is it guaranteed the callback of
EFli will be called before the callback of EFpl? IMO, it can't always guarantee
this. If I'm correct, your solution is just half way to the final target. Maybe
we need to work out a better one:)
Regards,
-Yang
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
