The QCDM port commands are never cached, so remove the option from the command()
method. Will also simplify command caching afterwards as it will be an AT-only
thing.
otherwise we fail with:
CC ModemManager-mm-broadband-modem-qmi.o
mm-broadband-modem-qmi.c: In function ‘process_gsm_info’:
mm-broadband-modem-qmi.c:4182:18: error: ‘egprs_support_valid’ undeclared (first use in this function)
&egprs_support_valid, &egprs_support,
^
mm-broadband-modem-qmi.c:4182:18: note: each undeclared identifier is reported only once for each function it appears in
mm-broadband-modem-qmi.c:4182:40: error: ‘egprs_support’ undeclared (first use in this function)
&egprs_support_valid, &egprs_support,
otherwise we fail with:
CC ModemManager-mm-broadband-modem-qmi.o
mm-broadband-modem-qmi.c: In function ‘get_signal_info_ready’:
mm-broadband-modem-qmi.c:2309:5: error: passing argument 3 of ‘signal_info_get_quality’ from incompatible pointer type [-Werror]
if (!signal_info_get_quality (ctx->self, output, &quality)) {
^
mm-broadband-modem-qmi.c:2236:1: note: expected ‘gint8 *’ but argument is of type ‘guint *’
signal_info_get_quality (MMBroadbandModemQmi *self,
^
cc1: all warnings being treated as errors
otherwise we fail with:
CC ModemManager-mm-broadband-modem-qmi.o
mm-broadband-modem-qmi.c: In function ‘modem_load_current_bands’:
mm-broadband-modem-qmi.c:1881:35: error: ‘ctx’ undeclared (first use in this function)
if (qmi_client_check_version (ctx->client, 1, 19)) {
^
mm-broadband-modem-qmi.c:1881:35: note: each undeclared identifier is reported only once for each function it appears in
Make sure we cleanup the 'buffer-full' signal handler when moving from AT
probing to QCDM probing, so that we don't try to remove a signal handler from
a QCDM port in which we haven't set it.
E.g. avoids:
ModemManager[1493]: <debug> [1390731359.108502] [mm-port-probe.c:239] mm_port_probe_set_result_qcdm(): (tty/ttyHS2) port is QCDM-capable
(ModemManager:1493): GLib-GObject-WARNING **: gsignal.c:2585: instance '0x7431b0' has no handler with id '16'
After a MMSerialPort object is forced close, it may be opened again if some
other object still holds a reference to it. When the MMSerialPort object is
eventually disposed, mm_serial_port_close_force is invoked on the object but
does nothing as 'priv->forced_close' is already set to TRUE. 'priv->watch_id'
is still active, which could potentially lead to a crash if data_available is
called after the MMSerialPort object is finalized. This patch prevents such a
scenario by failing mm_serial_port_open / mm_serial_port_reopen after the
MMSerialPort has been forced close.
Based on a patch from: Bjørn Mork <bjorn@mork.no>
Some messages provide an additional NwError cause code from
the network in case of failure. This means that we need to
parse the reply even if the status indicates failure, to be
able to return the exact failure cause.