The new PHS8 or PXS8 devices may expose multiple tty ports, but only one is
supposed to be used for PPP. So, query which port that is and flag it before
grabbing it in the modem.
When I use clang 3.5 to build it, I got
commands.c:1444:16: error: expression which evaluates to zero treated as a
null
pointer constant of type 'QcdmResult *' (aka 'struct QcdmResult *')
[-Werror,-Wnon-literal-null-conversion]
return FALSE;
^~~~~
./utils.h:29:15: note: expanded from macro 'FALSE'
#define FALSE ((u_int8_t) 0)
^~~~~~~~~~~~~~
commands.c:1464:20: error: expression which evaluates to zero treated as a
null
pointer constant of type 'QcdmResult *' (aka 'struct QcdmResult *')
[-Werror,-Wnon-literal-null-conversion]
return FALSE;
^~~~~
./utils.h:29:15: note: expanded from macro 'FALSE'
#define FALSE ((u_int8_t) 0)
^~~~~~~~~~~~~~
2 errors generated.
make[3]: *** [libqcdm_la-commands.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
Below is the patch that fixes it
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'
This patch modifies MMBroadbandBearerHuawei such that connect_3gpp
simply reports an error via g_simple_async_report_error_in_idle, without
creating a Connect3gppContext, if no data port is available.
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.
This patch prevents connect_3gpp_context_complete_and_free from calling
'g_object_unref (ctx->data)' when connect_3gpp finds no data port (i.e.
ctx->data is set to NULL).
