Also bump required libqmi version, as this change uses flags from the
latest available API.
UMTS B19 is NTT DoCoMo's 800MHz band.
UMTS B6 is NTT DoCoMo's 850MHz band
Several changes here:
* Updated to use the non-deprecated MMModemBand values.
* Added support for GSM 450, GSM 480 and GSM 750.
* Added support for UMTS bands 11 and 19.
This check makes no sense. We're converting from a ModemManager enum to a QMI
enum, nothing else; i.e. 'caps' is *not* the current capabilities of the modem.
This facility cannot be retrieved via 'DMS UIM Get CK Status' and seems
currently unimplemented for mm-broadband-modem-qmi. The SIM enabled
status is however available via 'DMS UIM Get PIN Status'.
Using this message to add the retrieval of PIN status just after the
other facilities were queried.
Succesfully tested with Gobi2000 (05c6:9205), both retrieval of 3gpp
SIM lock status and enabling/disabling the PIN.
This patch fixes the following enumeration type mismatches:
mm-modem-helpers-qmi.c:980:12: error: implicit conversion from
enumeration type 'QmiNasRatModePreference' to different
enumeration type 'QmiNasRadioTechnologyPreference' [-Werror,-Wenum-conversion]
return qmi;
~~~~~~ ^~~
mm-modem-helpers-qmi.c:1082:12: error: implicit conversion from
enumeration type 'MMModemMode' to different
enumeration type 'QmiNasGsmWcdmaAcquisitionOrderPreference' [-Werror,-Wenum-conversion]
return MM_MODEM_MODE_NONE;
~~~~~~ ^~~~~~~~~~~~~~~~~~
mm-modem-helpers-qmi.c:1096:16: error: implicit conversion from
enumeration type 'QmiNasRegistrationState' to different
enumeration type 'MMModem3gppRegistrationState' [-Werror,-Wenum-conversion]
return QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED;
~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Changes being:
* Don't rely on the band preference TLVs presence. The band preference TLVs are
always given, even if the modem doesn't support the specific capability right
away. E.g. a GSM/UMTS/LTE modem configured with 'gsm-umts' capability (no
'lte') still shows the LTE band preference TLV in the SSP responses.
* Don't automatically add LTE as current capability. We needed this when we
were not able to change capabilities, so that we didn't lose the ability to
set 4G mode as allowed.
For loading current capabilities we use a mix of "Technology Preference" (TP),
"System Selection Preference" (SSP) and DMS-reported capabilities. But, as we
also use TP and SSP for allowed modes, it may be the case that we end up
leaving 4G out of the allowed modes, which afterwards will make the modem not
report LTE as current capabilitiy, as TP/SSP don't include LTE.
So, just assume LTE is a current capability if DMS-reported capabilities include
it. We can really do this because LTE is the only 4G technology, the same logic
wouldn't apply correctly for 2G or 3G (due to having different techs for 3GPP
and 3GPP2).
We will not report 'CS' as a supported mode every time '2G' is supported. This
actually was forcing all plugins to handle a 'CS' fallback when they didn't have
CS-specific mode setup. So, to simplify things, we will only report 'CS' as
supported for those plugins which actually allow to select 'CS' mode (e.g. the
'wavecom' plugin).
Specifying 'none' is really not exclusive. We may want to say that the modem can
either authenticate with a given protocol, or otherwise just try without
authentication.
The reality is that 'none' itself is usually always given in the connection
settings.
Current capabilities is the set of *active* radios that can be used
right now. Modem capabilities are the set of all radios the modem
could use, if some action were performed to enable them if they are
not enabled already (firmware reload, changing allowed mode, etc).
For QMI devices, the DMS Get Capabilities command represents all
radios, and thus "modem capabilities".
But to read *current* capabilities, ie active radios, we need to
query the NAS System Selection Preference and grab the "mode
preference" TLV. Unfortunately that is only available with NAS
>= 1.1, which means older Gobi devices (1K and 2K) don't support
it. So for older devices, we try to get the Technology Preference
(which takes into account user-requested limitations) and then
mask that with the DMS Get Capabilities result for a best-effort
current capabilities.
For example, the Pantech UML290VW reports DMS Get Capabilities
of "cdma, evdo, gsm, umts, lte", but a more limited SSP mode
preference according to what modes are actually enabled. Gobi
1K devices don't support SSP, and the DMS Get Capabilities
reports cdma/evdo or gsm/umts depending on the currently loaded
firmware. Previous to this patch, ModemManager reported all
modes as available on the UML290, ignoring what modes were
actually enabled.
Get/Set Technology Preference was introduced in NAS 1.0, so should be always
available (even if we thought it was introduced in NAS 1.7, that's not true).
But the newer System Selection Preference behaves better as it allows more
features like 'preferred' modes; so use it when available (NAS >= 1.1).
Aleksander Morgado
Ben Chan
Torsten Hilbrich
Aleksander Morgado
Dan Williams