Extended the ModemManager Signal interface to include 5G signal
information for RSRP, RSRQ and SINR via libqmi. Also extended mmci
to print 5G signal info.
Instead of using the FALSE return of the method to indicate either a
fatal error (if result_error was set) or the continuation request (if
result_error wasn't set), provide a enum that has explicit states for
all three possible values (failure, success or continue).
Running NDISDUP=1,0 on an already disconnected bearer/context will
report ERROR, so we can really ignore the result of the command,
because we're anyway going to get the correct bearer/context status
later on with the NDISSTATQRY checks.
When a network-initiated event is received telling us that a
bearer/context is disconnected, we should handle and process it right
away, without thinking on whether there is going to be a
user-requested disconnect afterwards or not.
This effectively reverts the changes introduced in commit
21a5aaf4fe, which looks like was done to
handle synchronization issues with upper layers (e.g. with
NetworkManager or Shill).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/205
We can safely cast the data in a GArray to gpointer first, and then
to the pointer type we require.
huawei/mm-broadband-modem-huawei.c: In function 'set_current_bands':
huawei/mm-broadband-modem-huawei.c:916:50: error: cast increases required alignment of target type [-Werror=cast-align]
bands_string = mm_common_build_bands_string ((MMModemBand *)bands_array->data,
^
E.g. do nothing if the response is empty:
<debug> (ttyUSB1): -->'AT^GETPORTMODE<CR>'
<debug> (ttyUSB1): <--'<CR><LF>^GETPORTMODE: TYPE: WCDMA: Huawei Technologies Co.,Ltd.,<CR><LF><CR><LF>OK<CR><LF>'
So far, we're really only interested in the "modem" and "pcui" ports.
root@9d52738:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4# find . -name interface|sort
./1-1.4:2.0/interface
./1-1.4:2.1/interface
./1-1.4:2.2/interface
./1-1.4:2.3/interface
./1-1.4:2.4/interface
./1-1.4:2.5/interface
./1-1.4:2.6/interface
root@9d52738:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4# find . -name interface|sort|xargs cat
CDC Ethernet Control Model (ECM)
CDC Ethernet Data
Huawei Mobile Connect - Modem
Huawei Mobile Connect - Application
Huawei Mobile Connect - Pcui
Huawei Mobile Connect - Ctrl
Huawei Mobile Connect - Serial B
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/170
It has the same exact format as MMBaseModemAtCommand, but its contents
are assumed heap allocated.
The only real purpose of this type is to allow defining static
constant MMBaseModemAtCommand variables without warnings when using
-Wdiscarded-qualifiers.
huawei/mm-broadband-bearer-huawei.c: In function ‘connect_3gpp_context_step’:
huawei/mm-broadband-bearer-huawei.c:378:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
378 | ctx->step++;
| ~~~~~~~~~^~
huawei/mm-broadband-bearer-huawei.c:382:5: note: here
382 | case CONNECT_3GPP_CONTEXT_STEP_NDISDUP: {
| ^~~~
huawei/mm-broadband-bearer-huawei.c: In function ‘disconnect_3gpp_context_step’:
huawei/mm-broadband-bearer-huawei.c:708:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
708 | ctx->step++;
| ~~~~~~~~~^~
huawei/mm-broadband-bearer-huawei.c:711:5: note: here
711 | case DISCONNECT_3GPP_CONTEXT_STEP_NDISDUP:
| ^~~~
huawei/mm-broadband-modem-huawei.c: In function ‘huawei_hcsq_changed’:
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN’ not handled in switch [-Werror=switch-enum]
1816 | switch (act) {
| ^~~~~~
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_POTS’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_GSM_COMPACT’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_GPRS’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EDGE’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSDPA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSUPA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSPA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSPA_PLUS’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_1XRTT’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EVDO0’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EVDOA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EVDOB’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_ANY’ not handled in switch [-Werror=switch-enum]
Useful when clamping a unsigned integer with low threshold set to 0,
which would give us compiler warnings with -Wtype-limits when using
CLAMP(), e.g.:
via/mm-broadband-modem-via.c: In function ‘handle_evdo_quality_change’:
/usr/include/glib-2.0/glib/gmacros.h:811:63: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
811 | #define CLAMP(x, low, high) (((x) > (high)) ? (high) : (((x) < (low)) ? (low) : (x)))
| ^
via/mm-broadband-modem-via.c:284:19: note: in expansion of macro ‘CLAMP’
284 | quality = CLAMP (quality, 0, 100);
| ^~~~~
huawei/mm-modem-helpers-huawei.c: In function ‘parse_mode_combination_string’:
huawei/mm-modem-helpers-huawei.c:991:20: error: this statement may fall through [-Werror=implicit-fallthrough=]
991 | *preferred = MM_MODEM_MODE_NONE;
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
huawei/mm-modem-helpers-huawei.c:993:5: note: here
993 | default:
| ^~~~~~~
huawei/mm-modem-helpers-huawei.c: In function ‘mm_huawei_parse_prefmode_response’:
huawei/mm-modem-helpers-huawei.c:550:18: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘const unsigned int’} [-Werror=sign-compare]
550 | if (mode == combination->prefmode)
| ^~
USB sticks only support voice if ^CVOICE returns 0. And to enable audio
streaming on the "Application" port (whatever is returned by AT^DDSETEX=?)
we need to send AT^DDSETEX=<port> after starting the call. After that
the serial port will send and accept signed 16-bit 8000hz PCM audio, or
whatever format is returned by ^CVOICE?.
This patch is a rework of the original implementation by:
Dan Williams <dcbw@redhat.com>
Calls created from property bundles are always outgoing, while calls
created as input events from URCs during runtime are always incoming.
This change makes it mandatory to provide at least direction of the
call when the object is created, leaving the number as an optional
property that may or may not be known in advance (e.g. it would be
optional only for incoming calls).
Instead of handling the URCs in the modem object and using the
MMIfaceModem as a bridge to report the status read from the URC to a
call obtained from the MMCallList... just handle the URCs in the call
object itself.
In order to detect state changes while we're in-call, we have to
monitor the standard connection errors we're used to, but have them
processed as URCs instead of as responses to ATD requests.
The most detailed call state transition flow for a new outgoing call
would be:
UNKNOWN -> DIALING -> RINGING -> ACTIVE
But, if the modem doesn't support reporting intermediate states
(e.g. DIALING or RINGING) then a successful start() should imply
getting into ACTIVE state right away.
For now, only the Huawei plugin implements the detailed transition
support, so make them configurable via call object properties.
We keep the pflags input in mm_base_modem_grab_port() so that plugins
can use other methods to gather port type hints (e.g. querying with AT
commands as in Huawei/Telit or looking at sysfs properties as in HSO).
For standard udev tag port type hints, it will be the base modem
looking them up.
Note that there is no longer any need to ignore non-flagged ports for
those modems that require primary/secondary flags. They will be
implicitly ignored when mm_base_modem_organize_ports() decides which
ports to use, as the flagged ones are preferred over the non-flagged
ones.
Walter Hagstrom
Aleksander Morgado
Louis-Alexis Eyraud
Murithi Borona
Ben Chan