In a somewhat bizarre case, both PNN and OPL might change, which will
trigger sim_pnn_opl_changed twice. This can have some funny
side-effects, so don't allow this to happen in the first place.
If both EFspn and EFspdi are changed, then we trigger reading of EFspn
twice which leads to a memory leak. Instead, always read EFspdi if the
relevant service is available.
If EFspdi is changed, use a simple heuristic to update the 'Name'
property if appropriate. This heuristic is not always correct, but in
the worst case we will emit the same name.
Some hardware returns an empty mcc/mnc operator during an operator scan
when no operators are found (e.g. on an LTE dongle in a non-LTE area).
This results in oFono mistaking trying to update a non-existent operator
object.
For reference:
ofonod[27532]: Device: < \r\n+NWSTATEIND: 4\r\n\r\n+COPS:
(0,"","","",255),,(0-4),(0-2)\r\n\r
\nOK\r\n
process 27532: arguments to dbus_message_new_signal() were incorrect,
assertion "_dbus_check_
is_valid_path (path)" failed in file dbus-message.c line 1289.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
With the fix to query the signal strength when the registration status
changes it should be now fine again to just ignore notifications about
signal strength changes when not registered. So put this extra check
and comment back into signal strenth notification function.
Signal strength is set to -1 whenever registration status changes
and differs from registered or roaming. When registration status
changes again to registered or roaming, the signal strength needs to
be updated, added query towards driver to get it.
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>