Currently, LM940 is expected to have not LTE band extended, however they
have been introduced since version 24.01.516.
This change adds a software revision compare function for Telit modem
limited to LM9x0 modems (LM940 and LM960 share the same revision format
string) to verify if the current LM940 software revision is equal or
newer than 24.01.516 and enable/disable LTE band extended accordingly.
Currently functions dealing with #BND request
- mm_telit_parse_bnd_query_response
- mm_telit_parse_bnd_test_response
- mm_telit_build_bnd_request
have all a long list of arguments configuring how to deal with the BND
string.
This commit reworks this list of arguments into a single new structure
"MMTelitBNDParseConfig" with the following advantages
- shorter list of arguments for the above functions
- future changes to this arguments will be transparent for the functions
above that only pass the values
- one single point where the structure is created: a new function
mm_shared_telit_get_bnd_parse_config.
Some modems, like LE910C1-EUX, express the LTE part of #BND output in
HEX format, but currently the MM parser for such case is limited to
modems that have "ext_4g_bands". This commits use the new MMTelitModel
info to decide how to parse #BND command output.
Fixes#487
Currently, firmware revision string is obtained via AT+CGMR or AT+GMR
commands from the default mm-broadband-modem. For a class of Telit
modems however this command does not return the actual Telit Software
Package version, but the "Modem FW Version", which is only a component
of the whole firmware. For this class of modems, the correct string is
obtained with "AT#SWPKGV" command.
This change overrides load_revision* functions to add the ability to
parse "AT#SWPKGV" command for the modems that support it, and falls back
to the same logic that was implemented in mm-broadband-modem otherwise.
Telit modems that require hexadecimal number when specifying 4G bands
also reply to #BND=? command with a 4th parameter <LTE_band_ext>
(e.g. LM940, LM960, LN920, FN980).
On the other hand, modems that require decimal number when specifying 4G
bands only return 3 parameters to the same command.
It is then possible replace the detection of ext_4g_bands via UDEV tags
with an inspection of BND=? reply.
And added support for several new things, including:
* Setting "any" band now attempts to set all supported bands.
* Added new 2G band value '5' (egsm+dcs+pcs+g850).
* Setup support for two different 3G band combinations, a default one
plus an alternate one applicable to the LM940/960 models only. The
alternate combination is selected via udev tags.
During the refactor, the following Telit-specific helpers were also
removed and exchanged with more generic counterparts.
* mm_telit_bands_contains() -> mm_common_bands_garray_lookup()
* mm_telit_get_band_flags_from_string() -> mm_parse_uint_list()
Updated to use the non-deprecated MMModemBand values.
Also, use explicit enums for 2G/3G bands when building internal flags,
as relying on UTRAN band 7 (MM_MODEM_BAND_U2600) being greater than
UTRAN bands 8 and 9 is a MM implementation issue.
Given that the MMTelitQssStatus enums are mapped directly to the
values read from the #QSS response, we need to make sure that we never
return a value for which we don't have an enum defined.
Also, use set_error() instead of the propagate_error() + error_new()
combo.
Currently, Telit's SIM swap implementation is stateless and
based on #QSS unsolicited messages 0/1 (SIM_REMOVED/SIM_INSERTED).
However, the user might have configured the modem in order to provide a
more detailed information, with #QSS values 2/3 (SIM UNLOCKED/SIM READY).
In this case and with current implementation, even receiving "#QSS: 3" will
trigger the "SIM swap" logic. The same issue might occur in other use cases
too, i.e. with SIM locked or when the message is received from both USB
ports.
This patch makes SIM swap implementation stateful, and it considers as an
actual SIM swap, only transitions from #QSS: 0 to #QSS: 1/2/3 and vice
versa.
- Refactored mm_telit_parse_csim_response in order to correctly
recognize the following +CSIM error codes:
* 6300 - Verification failed
* 6983 - Authentication method blocked
* 6984 - Reference data invalidated
* 6A86 - Incorrect parameters
* 6A88 - Reference data not found
- Updated correspondent tests.
- Finally, some minor changes in other files for better error logging
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100374
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
`g_assert_true' and `g_assert_false' are defined in glib 2.38 or later.
The minimum glib version currently required by ModemMamanger is 2.36.
While `g_assert_true' and `g_assert_false' may be preferred over the
more generic `g_assert', it seems like overkill to bump the minimum glib
version requirement just for that. When more code in ModemManager later
requires newer versions of glib, we can migrate all existing code to use
`g_assert_true' and `g_assert_false' when appropriate.
In place of two slightly different regexes for 2g/3g and 2g/3g/4g modems
we now use only one regex with conditional patterns for both supported
and current Bands detection.
Adding also minor fix in test code
GE910 is a 2g only modem and when queried for bands it returns
only a 2g set of bands:
--> 'AT#BND=?<CR>'
<-- '<CR><LF>#BND: (0-3)<CR><LF><CR><LF>OK<CR><LF>'
Current regex fails, since it considers the 3g bands block mandatory.
A similar problem happens for current bands.
This patch modifies the regular expressions for properly
supporting GE910 and updates tests.
Carlo Lobrano
Carlo Lobrano
Amol Lad
Aleksander Morgado
Colin Helliwell
Ben Chan
Daniele Palmas