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.
Currently, supported band AT query #BND=? is failing with LM9x0 because
it expects BND 4G decimal format instead than hexadecimal.
Adding also LN920 and FN980 for completeness. They do not fail right now
because they have also "4g band extended" which format is always
hexadecimal.
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
Telit revision string can be used to identify the specific model, which
in turn is useful to specialize the behavior of the plugin.
This change adds revision parsing to detect some telit modems. Initially
it adds the ones that have different behaviors in #BND output parsing
for example.
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.
Fix the following segmentation fault:
ModemManager[128007]: mm_port_peek_kernel_device: assertion 'MM_IS_PORT (self)' failed
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x00005555556c6e3e in mm_kernel_device_get_global_property
(self=0x0, property=0x7ffff5947480 "ID_MM_TELIT_BND_ALTERNATE")
at kerneldevice/mm-kernel-device.c:309
Reported by Carlo Lobrano <c.lobrano@gmail.com>
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()