| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Kernel driver mhi-net sets a custom MTU for the netdevice: use the
same value when resetting the netdevice to its initial state.
This is important especially when rmnet is used on top of mhi-net,
since rmnet netdevices get their initial MTU from the mhi-net one.
|
|
The current requested downlink data aggregation protocol maximum size is
set to 32768, but this is not accordingly set as the MTU of the main
qmi_wwan interface, that is instead set to RMNET_MAX_PACKET_SIZE that is
16384.
So, the modem is able to send QMAP aggregated blocks larger than 16384,
but the driver is not able to properly collect them, since the URB size
is 16384.
It is not simply possible to set qmi_wwan main interface MTU to the
returned dl max aggregated size, since when creating the rmnet netdevice
the rmnet kernel module automatically set the mtu as the size of the
parent netdevice MTU - the qmap header size (4), but this won't work
because the rmnet kernel module does not support MTU > 16384.
As an immediate fix, set the requested dl dap max size to 16384, while
thinking about how to refactor the logic for supporting higher values.
qmi_wwan inbox qmap management is not affected by this issue.
|
|
It could happen that when MM starts the aggregation protocol is already
configured on the modem side (e.g. if MM is stopped and restarted): this
prevents the links to be properly configured, resulting in using the qmimux
multiplex implementation even if rmnet is available.
Fix the issue by always performing the first time the links reset procedure,
even if the data format on the modem side is the expected one.
|
|
When using QMAPv5 and QMAPv4 the checksum is enabled by default
at the modem level, so it should be also enabled when creating the
rmnet netdevices: add the required flags also when rmnet is used
through qmi_wwan.
|
|
qmi_device_list_links can return TRUE, but with a NULL value for
the links list: check for validity before using the list.
|
|
The feature/rx_offload and feature/tx_offload sysfs attributes specify
which offload settings should be used when creating new links.
|
|
Letting the MMBroadbandModemQmi listen for the notifications of the
QmiDevice was not a good idea, especially since no explicit reference
to the device object was hold in the modem object. This leads to race
conditions in which the QmiDevice outlives the MMBroadbandModemQmi and
the MMPortQmi, and when the "device-removed" signal is triggered, the
program crashes.
The MMPortQmi will now emit its own 'removed' signals when the
underlying QmiDevice emits "device-removed', ensuring that the signal
handler is properly cleared up during the MMPortQmi disposal.
|
|
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
|
|
At the moment the endpoint type/number is chosen based on the QMI
control port. The assumption is that multiplexing is implemented using
an additional protocol layer (e.g. QMAP) or that each network interface
has its own QMI control port.
This is not necessarily the case for BAM-DMUX. To use the built-in
multiplexing the WDS client must be bound to the correct data port.
This works already for older firmware versions using "Bind Data Port"
(SIO port numbers), but not for newer ones using "Bind Mux Data Port"
(endpoint type/interface numbers).
Make it work for newer firmware versions as well by choosing the
endpoint type/number based on the data port similar to the existing
implementation for SIO port numbers.
Note: The correct endpoint interface number is currently only used for
the steps in mm-bearer-qmi. Ideally more refactoring should be done in
mm-port-qmi to call WDA Set Data Format for each of the endpoints.
In practice it usually works fine without because the data format is
set correctly by default.
|
|
At the moment the endpoint type and number for the QMI WDA calls are
chosen based on the subsystem of the QMI control port. This does not
work correctly for some configurations:
- SUBSYS_QRTR currently implies ENDPOINT_TYPE_EMBEDDED, but this is
only valid for QRTR+IPA configurations. For QRTR+BAM-DMUX the
correct type is ENDPOINT_TYPE_BAM_DMUX.
- SUBSYS_WWAN currently implies ENDPOINT_TYPE_PCIE, but there is
already a comment that mentions that this selection works only for
MHI/PCIe modems. SUBSYS_WWAN is also used by RPMSG+BAM-DMUX
configurations in which case the correct type is also
ENDPOINT_TYPE_BAM_DMUX.
Looking closer at these cases suggests that the endpoint type actually
refers to the data/net port and not the control port. It is more
reliable choose it based on the network driver and not the subsystem
of the control port.
Address this partially by choosing the endpoint type based on the
net_driver. Choosing the endpoint interface number correctly requires
more refactoring since most of the logic is currently handled globally
for a QMI control port, while it's actually specific to the chosen
data/net port in some cases (e.g. multiple BAM-DMUX network interfaces).
|
|
|
|
|
|
The maximum MTU that the master interface can support should be less
or equal than RMNET_MAX_PACKET_SIZE, as defined in the
`rmnet_private.h` file in the linux sources (not a public header).
Only applicable to RMNET link management (i.e. not to qmi_wwan
add_mux/del_mux).
Fixes https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/issues/71
|
|
When not requesting multiplexing support, only assume we don't need
any additional setup if multiplexing is disabled AND if the data modes
match between kernel and device.
This fixes the connection setup in MSM8916 (rpmsg+bam/dmux).
|
|
Regardless of whether WDA is supported or not.
|
|
We should check if WDA is supported before running any other logic
that may change the state of the kernel or the modem. E.g. if we don't
do this as the first step, the loading of the supported kernel data
modes may end up changing the expected kernel data mode to raw-ip.
|
|
ModemManager[703345]: <debug> [1626962477.971869] [modem0] couldn't open QMI port with data format update: Unexpected kernel data mode: cannot setup using CTL
ModemManager[703345]: <debug> [1626962477.972197] [cdc-wdm0/qmi] Opening QMI device...
ModemManager[703345]: <debug> [1626962477.972310] [cdc-wdm0/qmi] Checking if QMI device already opening...
ModemManager[703345]: <warn> [1626962477.975182] [modem0] couldn't start initialization: QMI device open/close operation in progress
|
|
E.g. the ZTE MF190 has a very old QMI firmware that is not able to run
CTL Set Data Format (raw-ip).
ModemManager[666366]: [/dev/cdc-wdm0] QMI Device supports 4 services:
ModemManager[666366]: [/dev/cdc-wdm0] ctl (1.2)
ModemManager[666366]: [/dev/cdc-wdm0] wds (1.3)
ModemManager[666366]: [/dev/cdc-wdm0] dms (1.2)
ModemManager[666366]: [/dev/cdc-wdm0] nas (1.0)
ModemManager[666366]: [/dev/cdc-wdm0] Setting network port data format...
ModemManager[666366]: [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<< length = 21
<<<<<< data = 01:14:00:00:00:00:00:03:26:00:09:00:10:02:00:02:00:01:01:00:00
ModemManager[666366]: [/dev/cdc-wdm0] Sent generic request (translated)...
<<<<<< QMUX:
<<<<<< length = 20
<<<<<< flags = 0x00
<<<<<< service = "ctl"
<<<<<< client = 0
<<<<<< QMI:
<<<<<< flags = "none"
<<<<<< transaction = 3
<<<<<< tlv_length = 9
<<<<<< message = "Set Data Format" (0x0026)
<<<<<< TLV:
<<<<<< type = "Protocol" (0x10)
<<<<<< length = 2
<<<<<< value = 02:00
<<<<<< translated = raw-ip
<<<<<< TLV:
<<<<<< type = "Format" (0x01)
<<<<<< length = 1
<<<<<< value = 00
<<<<<< translated = absent
ModemManager[666366]: [/dev/cdc-wdm0] Received message...
<<<<<< RAW:
<<<<<< length = 19
<<<<<< data = 01:12:00:80:00:00:01:03:26:00:07:00:02:04:00:01:00:2D:00
ModemManager[666366]: [/dev/cdc-wdm0] Received generic response (translated)...
<<<<<< QMUX:
<<<<<< length = 18
<<<<<< flags = 0x80
<<<<<< service = "ctl"
<<<<<< client = 0
<<<<<< QMI:
<<<<<< flags = "response"
<<<<<< transaction = 3
<<<<<< tlv_length = 7
<<<<<< message = "Set Data Format" (0x0026)
<<<<<< TLV:
<<<<<< type = "Result" (0x02)
<<<<<< length = 4
<<<<<< value = 01:00:2D:00
<<<<<< translated = FAILURE: InvalidDataFormat
ModemManager[666366]: <debug> [1626961628.001354] [cdc-wdm0/qmi] QMI port open operation failed: QMI protocol error (45): 'InvalidDataFormat'
ModemManager[666366]: <warn> [1626961628.002563] [modem0] couldn't start initialization: QMI protocol error (45): 'InvalidDataFormat'
ModemManager[666366]: <warn> [1626961628.004181] [modem0] couldn't initialize: 'Modem is unusable, cannot fully initialize'
|
|
Requires IPA kernel driver to expose the TX and RX endpoint IDs through sysfs.
Available from linux 5.14 onwards.
|
|
Will be set by base modem when organizing ports, similar to
net driver name. Required for fetching the TX and RX endpoint IDs
through sysfs from linux 5.14 onwards.
|
|
Currently, we are not increasing the reference counter of the QrtrNode
when creating a PortQmi for a QRTR port, and we are clearing the object
when disposing the port.
|
|
If using rmnet and IP passthrough setting in qmi_wwan, also configure
the master interface with an MTU equal to the maximum data aggregation
size.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/367
|
|
We'll setup the properties only if QRTR support is being built,
otherwise we fully skip all property related setup.
(ModemManager:480463): GLib-GObject-CRITICAL **: 22:48:14.264: g_object_class_install_properties: assertion 'n_pspecs > 1' failed
Thread 1 "ModemManager" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff76e3295 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff76e3295 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff76e4579 in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff76e4743 in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00005555556af70c in mm_port_qmi_class_init (klass=0x5555557fae20) at mm-port-qmi.c:2619
#4 0x00005555556a94c3 in mm_port_qmi_class_intern_init (klass=0x5555557fae20) at mm-port-qmi.c:34
#5 0x00007ffff77ed1d1 in g_type_class_ref () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007ffff77d05e1 in g_object_new_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007ffff77d06cd in g_object_new () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00005555556af25a in mm_port_qmi_new (name=0x5555557e54e0 "cdc-wdm0", subsys=MM_PORT_SUBSYS_USBMISC) at mm-port-qmi.c:2481
#9 0x000055555563c8d7 in wdm_probe_qmi (self=0x5555557de1b0) at mm-port-probe.c:517
#10 0x000055555563cc70 in wdm_probe (self=0x5555557de1b0) at mm-port-probe.c:623
#11 0x00007ffff76dd04e in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff76dd400 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff76dd6f3 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00005555555b1ae4 in main (argc=1, argv=0x7fffffffe558) at main.c:213
|
|
In addition to differentiating between IPv4 and IPv6 clients, we also
need to explicitly allocate different clients in different bearer
objects when in multiplexing.
|
|
|
|
Fix typo causing crash when WITH_QRTR is undefined:
[6596]: <debug> [1619029470.854688] [cdc-wdm0/probe] probing QMI...
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x77a7310f in install_property_internal () from /usr/lib/libgobject-2.0.so.0
(gdb) bt
#0 0x77a7310f in install_property_internal () from /usr/lib/libgobject-2.0.so.0
#1 0x77a731db in validate_and_install_class_property () from /usr/lib/libgobject-2.0.so.0
Backtrace stopped: frame did not save the PC
Fixes: ec375bd959f0 ("port-qmi: add support for QRTR")
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
SDX55 modem can take slighlty more than 25 seconds to start all
its services from cold boot/reset (including QMI services), causing
QMI port opening timeout error. This patch increases the qmi_device_open
timeout from 25 seconds to 45 seconds to prevent such issue.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
|
|
|
|
|
|
|
|
Extend mm-port-qmi to accept a QRTR node to work with modems using the
QRTR protocol.
|
|
Connect the signal to initialize endpoint info in the generic object
initialization, also applicable for QRTR ports.
|
|
When using the IPA driver we cannot blindly use the master network
interface, we must always use RMNET based multiplexing.
|
|
The QmiDeviceExpectedDataFormat is specific to modules exposed by the
qmi_wwan driver, it has nothing to do with other drivers we may find
in the system like bam-dmux or ipa, which don't allow changing the
expected data format.
The port setup logic is now updated to use a new flags bitmask that
specifies which kernel data modes are supported or currently
available.
|
|
In BAM-DMUX based setups we already have multiple network interfaces
exposed in the system, which we bind to using the SIO port number.
So, disable QMAP multiplexing in this case, to simplify the setup and
avoid attempting to create additional net links when connecting
multiple bearers.
|
|
The MMPortQmi may need to know very early what kind of net ports are
going to be used later on during connection, e.g. to decide what kind
of multiplexing capabilities are available and such.
So, once we have organized ports in the modem, we'll take the driver
of the first network port in the list of data ports, and pass it down
to all QMI ports setup in the modem object.
|
|
For the qmi_wwan driver, we have imposed a limitation of max 4 links
when using the add_mux/del_mux interface, because we're forced to
precreate links before multiplexing may be enabled.
When using rmnet over qmi_wwan, or rmnet over other drivers, we don't
have any limitation other than the one imposed by the WDA protocol
itself. The amount of links that may be created in this case is
1 + (QMI_DEVICE_MUX_ID_MAX - QMI_DEVICE_MUX_ID_MIN).
This information is loaded in the MMPortQmi, used to create the
MMBearerList in the QMI modem, and finally populated in the
'MaxActiveMultiplexedBearers' property of the modem interface.
|
|
This step is required when using the qmi_wwan add_mux/del_mux logic,
and must be done before changing the kernel data format to raw-ip.
|
|
If the port has net links that have been setup, don't allow switching
it from multiplexing mode to non-multiplexing mode.
|
|
The logic to setup/cleanup net links is based on the QmiDevice net
link addition/removal operations.
When the qmi_wwan add_mux/del_mux based logic is in use, we default to
precreate 4 net links and we limit the amount of bearers that may be
connected to that maximum, because it is not guaranteed that the
qmi_wwan driver is able to create new links once the master interface
is up; and the master interface needs to be up for a proper data
connection.
For all other drivers, or when qmi_wwan uses qmap-pass-through, we
allow adding/deleting new links at any moment, without needing to rely
on the precreated ones.
|
|
We now allow requesting for multiplex support in the set data format
operation of the MMPortQmi.
If multiplexing is supported, we'll configure both the modem (link
layer protocol and data aggregation protocol) and the kernel expected
data format (if qmi_wwan in use).
The logic adds additional preferences over the different choices we
may find in the logic:
* In newer modems, by default QMAPv5 is preferred over QMAP as data
aggregation protocol.
* If using qmi_wwan, by default rmnet (qmap-pass-through) is
preferred over add_mux/del_mux (raw-ip) kernel expected data
format.
These preferences are only considered if the specific support is found
in the setup.
Whenever we change the multiplexing support, an internal port reset
operation will be run, in order to bring the state of the setup to a
clean known one.
|
|
The port reset operation will attempt to setup the QMI and associated
NET ports to the same state as they has when the modem was originally
detected: no mux links, net interface down and (for the qmi_wwan based
devices) expected kernel data format set to 802.3.
By default, the external calls to the port reset logic will require
the port to be closed (i.e. no internal QmiDevice), so a new temporary
QmiDevice will be created just for this operation. The new QmiDevice
doesn't even need to be open, as the reset operations just uses the
device to attempt to remove net links.
The internal call to the port reset logic uses an input QmiDevice
which may be the newly allocated one in the external call, or the
internal QmiDevice, if there is one.
|
|
The new logic is implemented as a separate async method with its own
state machine, which allows selecting different data format setups
with an strict preference.
Until now, we would not attempt to re-configure the link layer
protocol in the modem interface if we could instead change the
expected data format in the kernel. E.g. a MC7304 exposing one
interface in 802.3 format and another one in raw-ip format would be
used in either 802.3 or raw-ip, depending on the network interface
being connected.
This logic changes now, and we now by default always prefer raw-ip
over 802.3. E.g. the same MC7304 would now always be used in raw-ip
mode, regardless of whether the interface was by default in raw-ip or
not. Obviously, raw-ip will only be used if the kernel data format can
be changed. If the qmi_wwan driver in use is older than 4.5, the
default link layer protocol attempted would be 802.3, if the modem
supports it.
In addition to this change in logic, we also now avoid setting up the
WDA data format as soon as the port is opened; instead we defer that
logic until a connection request arrives, because once QMAP support is
integrated, we'll need to know whether the user requested the
multiplexing support or not. Therefore, during port open we just
query current state and during the connection attempt we reconfigure
either modem or kernel or both.
If WDA is unsupported, the logic falls back to CTL-based link layer
protocol configuration, as it use to.
The logic now also supports WDA Set/Get Data Format operations with
the newest modems that require the explicit endpoint info TLV. As soon
as the first failure is reported asking for the endpoint TLV, we'll
flag the port as requiring the endpoint info always.
|
|
The endpoint info of a given MMPortQmi is immutable (it's associated
to the specific kernel driver in use and to the specific physical
interface number of the device).
We'll load it as soon as the kernel device object is set in the port,
and we'll keep it in the private struct so that it can be used at any
time, e.g. by the WDA Get/Set Data Format operations on newest
devices, where the endpoint info TLV is mandatory.
|
|
The qmi_wwan driver is the only one that allows switching between
802.3 and raw-ip during runtime, and therefore we must not assume that
every QMI port managed allows to do so, we'll limit that feature only
to QMI ports in the 'usbmisc' subsystem.
For every other port, we assume the kernel expects raw-ip by default,
and so we include logic to switch the modem to raw-ip both using WDA
and CTL (WDA preferred over CTL). This assumption may not be perfect,
but it's probably a good guess, as raw-ip is the preferred and
sometimes the only format supported by new devices.
|
|
We have assumed until now that all QMI ports are based on the
qmi_wwan driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating QMI ports with
an explicit subsystem instead of defaulting always to USBMISC.
|
|
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
So, rename the port subsystem type enumn to 'usbmisc'.
|
|
Telit FN980 requires more time for becoming responsive to
qmi requests after device appearance.
|
|
==43111== 24 bytes in 1 blocks are definitely lost in loss record 1,999 of 5,339
==43111== at 0x483BB65: calloc (vg_replace_malloc.c:762)
==43111== by 0x50259D1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6400.2)
==43111== by 0x22AAB8: mm_port_qmi_allocate_client (mm-port-qmi.c:201)
==43111== by 0x2007F0: parent_enabling_started_ready (mm-broadband-modem-qmi.c:9114)
==43111== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==43111== by 0x4E6DA26: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==43111== by 0x1C535E: enabling_flash_done (mm-broadband-modem.c:10318)
==43111== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==43111== by 0x4E6DA26: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==43111== by 0x224F0B: flash_do (mm-port-serial.c:1776)
==43111== by 0x502AC03: ??? (in /usr/lib/libglib-2.0.so.0.6400.2)
==43111== by 0x502B58E: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.6400.2)
==43111==
|
