| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This message is used to bind a muxed data port to a controller device.
The Muxed data port has to be managed by qmi_wwan driver.
The Muxed data port is identified by:
- mux_id: the numeric ID given to qmi_wwan once created
- interface number: the interface number of the qmi controller device on
the modem
Once the binding is completed, all the commands sent (and I expect also
received, but I could not test it) using the same Client ID are for the
binded data port instead of the real one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the following configurable values:
- upload datagram protocol
- download datagram protocol
- download datagram max size
- download max datagrams
- endpoint type
- endpoint interface number
According to last GobiNet from CodeAura project, it is necessary to set
the following values to enable multiple data connection through one
controller device:
- upload datagram protocol = QMAP
- download datagram protocol = QMAP
- download datagram max size = 32 (it seems working even without setting it)
- download max datagrams = 32768 (it seems working even without setting it)
- endpoint type = HSUSB (it seems working even without setting it)
- endpoint interface number = this depends on the modem, but it seems working
even without setting it
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Enabled by default, may be disabled using --without-mm-runtime-check
during configure.
|
|
|
|
|
|
|
| |
We OR each flag value found in the output directly, so make sure that
output is clear before adding any new flag.
Reported-by: Paul Gildea <gildeap@tcd.ie>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We allow running FW updates even when udev isn't available in the
system. In this case, though, only the manual operations will be
supported (i.e. --reset and --update-qdl).
|
|
|
|
| |
Added example of how to manually update 9x15 and 9x30 devices.
|
|
|
|
|
| |
The actions map to different QMI messages, and we try to keep one action
per QMI message.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==14200== 308 (208 direct, 100 indirect) bytes in 1 blocks are definitely lost in loss record 1,163 of 1,191
==14200== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14200== by 0x5D34B98: g_malloc (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x5D4D0D2: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x5D4D6FD: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x5AC62B3: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5AA81FA: ??? (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5AA9C0C: g_object_newv (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5AAA3C3: g_object_new (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5789694: g_task_new (in /usr/lib/libgio-2.0.so.0.5000.2)
==14200== by 0x40D2E1: qfu_udev_helper_wait_for_device (qfu-udev-helpers.c:580)
==14200== by 0x40753D: qfu_device_selection_wait_for_tty (qfu-device-selection.c:211)
==14200== by 0x40A380: run_context_step_wait_for_tty (qfu-updater.c:798)
==14200==
==14200== 308 (208 direct, 100 indirect) bytes in 1 blocks are definitely lost in loss record 1,164 of 1,191
==14200== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14200== by 0x5D34B98: g_malloc (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x5D4D0D2: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x5D4D6FD: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x5AC62B3: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5AA81FA: ??? (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5AA9C0C: g_object_newv (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5AAA3C3: g_object_new (in /usr/lib/libgobject-2.0.so.0.5000.2)
==14200== by 0x5789694: g_task_new (in /usr/lib/libgio-2.0.so.0.5000.2)
==14200== by 0x40D2E1: qfu_udev_helper_wait_for_device (qfu-udev-helpers.c:580)
==14200== by 0x4074DD: qfu_device_selection_wait_for_cdc_wdm (qfu-device-selection.c:195)
==14200== by 0x409977: run_context_step_wait_for_cdc_wdm (qfu-updater.c:579)
|
|
|
|
|
|
|
|
|
|
|
|
| |
==14200== 52 bytes in 1 blocks are definitely lost in loss record 792 of 1,191
==14200== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14200== by 0x5D34B98: g_malloc (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x5D4EC3E: g_strdup (in /usr/lib/libglib-2.0.so.0.5000.2)
==14200== by 0x40C16D: udev_helper_get_udev_device_details (qfu-udev-helpers.c:94)
==14200== by 0x40C72C: udev_helper_find_by_device_info_in_subsystem (qfu-udev-helpers.c:263)
==14200== by 0x40C978: qfu_udev_helper_find_by_device_info (qfu-udev-helpers.c:314)
==14200== by 0x4076A9: qfu_device_selection_new (qfu-device-selection.c:264)
==14200== by 0x406A99: main (qfu-main.c:559)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After an update operation, before exiting, we MUST close the QmiDevice
using the asynchronous method, so that we wait for the inner 'MBIM
close' message (when QMI over MBIM is being used).
We don't want to leave the 'MBIM close done' message unread, as that
seems to interfere with the next 'MBIM open' sequence.
This sequence is incorrect:
qmi-firmware-update
...
--> mbim close
(exit without reading response)
qmi-firmware-update
--> mbim open (seq 1)
<-- mbim close done
--> mbim open (seq 2)
--> mbim open (seq 3)
--> mbim open (seq 4)
...
(times out)
This sequence is correct:
qmi-firmware-update
...
--> mbim close
<-- mbim close done
(exit)
qmi-firmware-update
--> mbim open (seq 1)
<-- mbim open done
...
|
|
|
|
|
|
|
|
|
| |
src/libqmi-glib/qmi-device.c: In function 'device_open_context_step':
src/libqmi-glib/qmi-device.c:2204:5: error: label 'next_step' defined but not used [-Werror=unused-label]
next_step:
^
cc1: all warnings being treated as errors
Makefile:614: recipe for target 'libqmi_glib_la-qmi-device.lo' failed
|
| |
|
| |
|
|
|
|
|
|
| |
They all had the WDS prefix instead of WMS, so fix that.
We include the old names in -compat to avoid breaking API.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The 'since' tag specifies in which major stable version the given
message or TLV was introduced.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|