GitLab

The man pages are generated using help2man.  There's a Debian bug,
948403, filed for the problem here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948403

If the transaction id ends up mismatched between device and libqmi due
to some reason, we may end up assuming a response is of a given type
when it isn't in reality.

Make sure this does not happen, as this would end up triggering a
g_return_val_if_fail() check that returns a NULL reply by the parser
without GError set, and the users of libqmi, like MM here may not
like that:

  ERR daemon ModemManager[4842]: __qmi_message_ctl_set_data_format_response_parse: assertion 'qmi_message_get_message_id (message) == QMI_MESSAGE_CTL_SET_DATA_FORMAT' failed
  ERR daemon ModemManager[4842]: __qmi_message_ctl_allocate_cid_response_parse: assertion 'qmi_message_get_message_id (message) == QMI_MESSAGE_CTL_ALLOCATE_CID' failed
  WARNIN user kernel:[ 687.347162] /tmp/ModemManager.4842.6.1575343251.core core dumped

The internal response_parse() methods used by libqmi should always be
used when we know that the response matches the expected type.

(cherry picked from commit 69354f53)

Fixes 202133e1

(cherry picked from commit ffe1f711)

(cherry picked from commit 29e14666)

(cherry picked from commit ec811501)

Add @MBIM_LIBS@ to Libs.Private in qmi-glib.pc.in so applications
linking statically with qmi-glib (such as modem-manager) will retrieve
these dependencies

Fixes:
 - http://autobuild.buildroot.org/results/9c6b8ec2b9cc31f1ab460532c378731ab455210cSigned-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
(cherry picked from commit c816e407)

The previous commit was easier to diagnose with the error condition from
qmi_message_new_from_data provided.  This change adds g_assert_no_error to
the test_message_new_request_from_data case so that any future issues can
be diagnosed quickly.

(cherry picked from commit c7ba1ee1)

Creation of the fake QMUX header wrote the length as a native value, which
caused the wrong value to be written on big endian systems.

Before, a test run on a ppc64 system gave:

ERROR:test-message.c:296:test_message_new_request_from_data: assertion failed: (self)
  /libqmi-glib/message/new/request:                                    OK
  /libqmi-glib/message/new/request-from-data:                          FAIL

Adding a g_assert_no_error gave the more helpful message:

ERROR:test-message.c:296:test_message_new_request_from_data: assertion failed (error == NULL): QMUX length and buffer length don't match (3072 != 12) (qmi_core_error_quark, 4)

After this commit is applied, all tests pass on a big endian ppc64 system.

(cherry picked from commit d9d1f330)

We don't want to create different QmiDevices for the same cdc-wdm
port when it's accessed through different symlinks.

(cherry picked from commit 882bc012)

If building client methods for commands that are abortable, make sure
we use the new qmi_device_command_abortable() method so that there are
no race conditions between an aborted operation and a successful
response received before the abortion happened.

This update should fix the race conditions seen in the following
ModemManager merge request:
  https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/100

This new method should be used when a command is abortable and we want
to wait for the abort operation to finish before returning the result
of the operation.

This logic solves race condition issues when e.g. a response to the
original request arrives just after we have sent the abort, so the
abort ends up failing. In this situation we should return the
successful response to the user and forget about the internal abort
sequence.

If we attempt to run qmi-firmware-update on the MC7455, we first need
to detect that the device is NOT a sahara device, and in order to do
that we'll just try to create a QfuSaharaDevice.

During this process, we will try to read from the ttyUSB0 the 'hello'
message that the device sends to us, but it may happen that the device
does not send anything at all and we would end up reading 0 bytes. If
this happens, we should treat it as an indication that this is not a
sahara device right away. If we don't do this, the protocol runner
sahara_device_run_protocol_step() method will return STEP_UNKNOWN
without any error set, which ends up making sahara_device_initialize()
return FALSE without error, and that will make initable_init() wrongly
succeed.

  [14 Aug 2019, 20:28:08] [Debug] [qfu-sahara-device] opening TTY: /dev/ttyUSB0
  [14 Aug 2019, 20:28:08] [Debug] [qfu-sahara-device] setting terminal in raw mode...
  [14 Aug 2019, 20:28:08] [Debug] [qfu-sahara-device] waiting time for device to boot properly...
  [14 Aug 2019, 20:28:10] [Debug] [qfu-sahara-device] initializing sahara protocol...
  [14 Aug 2019, 20:28:13] [Debug] [qfu-updater] selected file 'SWI9X30C_02.26.01.00.cwe' (64480431 bytes)
  downloading cwe image: SWI9X30C_02.26.01.00.cwe (64.5 MB)...
  Floating point exception (core dumped)

  #0  0x0000000000410a8b in qfu_sahara_device_firehose_setup_download (self=0x2110680, image=0x2124dc0, n_blocks=0x7ffc3baf5838,cancellable=0x211c240, error=0x7ffc3baf5860) at qfu-sahara-device.c:573
  #1  0x0000000000407b89 in download_image_firehose (device=0x2110680,#image=0x2124dc0, cancellable=0x211c240, error=0x7ffc3baf5860) at qfu-updater.c:691
  #2  0x00000000004080d9 in run_context_step_download_image (task=0x2125840) at qfu-updater.c:808
  #3  0x0000000000408595 in run_context_step (task=0x2125840) at qfu-updater.c:1490
  #4  0x00000000004077c9 in run_context_step_cb (task=0x2125840) at qfu-updater.c:366
  #5  0x00007fd1e0f0becc in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
  #6  0x00007fd1e0f0c238 in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0
  #7  0x00007fd1e0f0c492 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
  #8  0x00000000004067c8 in operation_update_run (updater=0x211c210, images=0x211b1f0) at qfu-operation-update.c:108
  #9  0x0000000000406862 in qfu_operation_update_download_run (images=0x211b1f0,#device_selection=0x211b820) at qfu-operation-update.c:163
  #10 0x0000000000405f3f in main (argc=1, argv=0x7ffc3baf5bf8) at qfu-main.c:726

This Sierra Wireless (swi) specific request returns some of the system
info known from the swi specific AT command "!GSTATUS?".

[/dev/cdc-wdm0] Successfully got status:
Common Info:
        Temperature: '32'
        Modem mode: 'online'
        System mode: 'lte'
        IMS registration state: 'no-srv'
        Packet service state: 'attached'
LTE info:
        Band: 'bc-3'
        Bandwidth: '20'
        RX channel: '1450'
        TX channel: '19450'
        EMM state: 'registered'
        EMM sub state: '0'
        EMM connection state: 'rrc-connecting'
Signed-off-by: Bjørn Mork <bjorn@mork.no>

The current definitions of QMI_*_LTE_BAND_*_EUTRAN_32 get converted to a
negative value (0xffffffff80000000) which causes side effects like the
incorrect ModemManager to QMI band mapping in
https://lists.freedesktop.org/archives/modemmanager-devel/2019-August/007371.html
.

Replace 1 << 31  with ((guint64) 1) << 31 for QMI_*_LTE_BAND_*_EUTRAN_32
to avoid this.
Reported-by: Nick <mips171@icloud.com>
Signed-off-by: Reinhard Speyerer <rspmn@arcor.de>

You can pass in a URI-only file via qmicli since it creates
the file via g_file_new_for_commandline_arg(). This means
that we might try to call g_file_get_path (which will be
NULL) and then use it later, causing a segfault.

This patch fixes a potential dereference of a null GArray in
gnss_sv_info_received().

  qmicli-gas.c: In function 'print_firmware_listing':
  qmicli-gas.c:132:32: error: declaration of 'index' shadows a global declaration [-Werror=shadow]
  qmicli-gas.c: In function 'get_firmware_list_ready':
  qmicli-gas.c:155:12: error: declaration of 'index' shadows a global declaration [-Werror=shadow]

This is actually a QmiGasFirmwareListingMode, so let's reflect that in the API.
Also rename it to "Mode" so it matches the input.

qmi-device.c: In function ‘device_open_step’:
qmi-device.c:1866:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
    ctx->step++;
    ~~~~~~~~~^~

GCC checks for comments annotating intentional fallthrough, but it didn't
recognize "Fall down", so this patch tweaks it to say "Fall through".