For modems that need more time to respond to AT port probes (like some Telit devices,
and Cinterion-based Telit MV31/MV32) allow a custom number of AT probe tries on a
per-port basis for generic probing, or plugins that opt into this functionality.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If multiple plugins are selected for probing a modem with AT probes,
earlier plugins may only request some probes but not all. When
those probes complete successfully, subsequent plugins won't re-do
the probes that were already completed, but jump to ones that
haven't yet been done.
For example, plugin A may request only AT probes but plugin B
may request AT, AT_PRODUCT, and AT_VENDOR. Plugin B will start
with AT_PRODUCT probes because plugin A already completed the AT
probe.
The code in probe_step() only opened the serial port for the
AT probe, I guess assuming that all AT-type probes would be
done in sequence. But in the above scenario they are not.
Instead, make sure the port is opened for all AT style probes
that have not yet been executed.
Fixes: 7937a89a37 port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIM
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Seen on a Qualcomm-based Quectel EG915Q on the diag port:
ModemManager[34547]: <dbg> [1732077670.330527] [ttyUSB0/at] <-- ' \0\0\0\8\0\0\0\2\0\0\0\0`%\160$"\6\169\128\200\1\30\197\142\0G\184\225\128\0\1+\127\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254'
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If by any chance the same ports needs to go through AT and
QMI/MBIM probing, make sure the serial port created during
AT probing is closed before starting the QMI/MBIM probing.
Referenced commit broke custom init flows because the AT port
was not opened when custom inits were run, which was the case
before the commit landed.
Rework probing flow to follow a step model like much of our
other code, and ensure that the AT port is opened as part
of the custom init flow.
Fixes: 7937a89a37 port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIM
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If the system and modem are independently powered, a system restart may
leave one of the modem's AT ports in PPP mode. On restart this may cause
AT probing to fail. The modem may terminate PPP after receiving bogus
HDLC frames from QCDM probing (since PPP also uses HDLC framing), and
return "NO CARRIER". We can use this to restart AT probing now that
PPP is down and auto-detect the expected additional AT ports.
Feb 08 20:22:53 ModemManager[385]: <debug> [1675887773.887574] [ttyUSB2/at] <-- '\8\158\239~'
Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.215054] [ttyUSB2/at] <-- '\8\214\137~'
Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.851349] [ttyUSB2/at] <-- '\8\250\177~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.576776] [ttyUSB2/at] <-- '\8\168u~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.612694] [ttyUSB2/at] <-- '\8w\25~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.862886] [ttyUSB2/at] <-- '\8!&~'
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.614747] [ttyUSB2/at] <-- '\8%\254~'
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686207] [ttyUSB2/probe] port is not AT-capable
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686447] [ttyUSB2/probe] probing QCDM...
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.725483] [ttyUSB2/qcdm] --> 7e 00 78 f0 7e
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.880941] [ttyUSB2/qcdm] <-- 0d 0a 4e 4f 20 43 41 52 52 49 45 52 0d 0a
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Open the AT port from the regular port probe flow rather than doing
that one-off at the beginning of probing. That lets us re-open the AT
port later if needed, based on QCDM/QMI/MBIM probing results.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
There is no guarantee from the kernel that the ports of a given device
will all be notified via uevents on a timely manner. We assume it, but
we cannot be completely sure.
There are two main scenarios that we have been seen when the ports of a
device are not notified close enough to each other:
* A modem object is created, but not with the desired control protocol.
E.g. a QMI or MBIM modem would end up controlled via AT commands if
the cdc-wdm port was added too late.
* A modem object is not created at all, and the device object was
removed completely. E.g. when the net port addition in a QMI or MBIM
modem happens too late.
In order to avoid those cases, we will now fully reprobe all the ports
of the device from scratch whenever a new valid port addition happens
after the initial probing of the device has already been completed. If a
modem object is available at that time, we will remove it right away.
Ensure that the cdc-wdm port probing task is canceled if the
modem drops off the bus before the task completes.
This prevents the task from preventing other port probing tasks from starting.
After the modem recovers, the ports are up but not yet responsive. When MM tries to probe the ports, they do not respond.
As a result, the probing tasks are left ongoing, waiting for a response from the modem.
If the modem drops off the bus for any reason, the cdc-wdm port probing task is not immediately canceled.
This patch fixes this issue by passing a cancellable object to mm_port_mbim_open().
In other words, the patch ensures that the cdc-wdm port probing task is canceled if the
modem drops off the bus before the task completes. This prevents the task from preventing
other port probing tasks from starting.
We can remove the port type hint udev tags for the wwan subsystem, as
that logic is now incorporated in the port type hint processing logic
in the daemon itself.
This makes it clearer to know what exact hints are being used, as the
logic is in a single place and it has proper logging of all possible
cases.
Do not do this in the plugin; instead, do it along with the logic that
looks for port type hints in udev, so that we can properly warn if
things don't match.
This will make it slightly easier to port mm_port_serial_at_command() to
use GTask, since we won't have to keep a pointer to the result in GTask
after _finish() has been called.
In most cases the caller needs the value anyway, so this doesn't add too
much hasle.
When QCDM is not required we don't run an explicit QCDM port probing
operation.
In this case, though, we should not assume that the port is QCDM
capable, even if it is also flagged as ignored.
Instead, we'll flag the port as QCDM capable and ignored only if there
was a udev port type hint associated to the port. Otherwise, we'll
report the port as not being QCDM capable, and the port won't even be
reported in the list of ports as its type is unknown.
The QCDM/DIAG port is usually nowadays exclusively used by applications
gathering traces from the modem, so avoid port probing and grabbing
when plugins set the property MM_PLUGIN_ALLOWED_QCDM.
A new property MM_PLUGIN_REQUIRED_QCDM is created for those plugins
requiring the QCDM port for properly using a modem.
We originally did only 3 attempts every 3s, so the maximum probing
time for a given TTY port looking for AT capabilities was 9 seconds.
We now duplicate the amount of times, so up to 18s of port probing,
which is quite a lot more than before, but unfortunately it's needed
because most new modems take a lot of time to boot up internally.
The way to avoid this long probing time is to make sure port type
hints for the possible AT ports are set correctly.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/379
Add support for the Linux wwan subsystem that started to expose
control channel as character devices (e.g. /dev/wwan0p1MBIM...).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Most older Qualcomm SoCs (e.g. MSM8916, MSM8974, ...) communicate with
the integrated modem via shared memory (SMD channels). This is similar
to QRTR on newer SoCs, but without the "network" layer. In fact, the
older SoCs also have QRTR, but the modem QMI services are not exposed
there.
The mainline Linux kernel exposes SMD channels via the "remote processor
messaging bus" (rpmsg). Through special IOCTL calls it is possible to
create a char device for a rpmsg/SMD channel. We can then use these to
send QMI/AT messages to the modem, much like the ordinary serial char
devices when using a Qualcomm modem through USB.
This commit introduces support for the new 'rpmsg' subsystem, which
allows exporting QMI-capable and AT-capable ports.
By default NO rpmsg port is flagged as candidate, it is assumed that
the plugin adding support for the rpmsg subsystem will add specific
rules to do so (e.g. so that non-modem ports are explicitly not
flagged as candidate).
All rpmsg ports will be probed for AT or QMI capabilities, unless
explicit port type hints (e.g. ID_MM_PORT_TYPE_QMI or
ID_MM_PORT_TYPE_AT_PRIMARY) are set.
These changes are highly based on the initial integration work done by
Stephan Gerhold <stephan@gerhold.net> in postmarketOS, see:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/363
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
This patch removes all monitoring of the 'usb' subsystem completely,
which is anyway a valid subsystem but for which we shouldn't need any
special handling. Right now, with newer kernels, we were using that
monitoring exclusively to get notified of full USB device remove
events, which is really not required as we already process the port
removals one by one.
We simplify the logic everywhere that attempted to match either the
'usb' or 'usbmisc' subsystems, and we no longer require the explicit
checks for the port name being named 'cdc-wdm[0-9]*' in the code, as
that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
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.
We have assumed until now that all MBIM ports are based on the
cdc_mbim driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating MBIM ports with
an explicit subsystem instead of defaulting always to USBMISC.
We have assumed until now that all QCDM ports are based on TTY
drivers, e.g. exposed via USB.
This may no longer be true, so allow creating QCDM ports with
an explicit subsystem instead of defaulting always to TTY.
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'.
It is no longer true that all QMI ports are exposed by the qmi_wwan
driver and that all MBIM ports are exposed by the cdc_mbim driver.
There are other generic setups that allow exposing these types of
ports using different drivers, and usually we can also know the type
of port in advance via other means. Therefore, allow adding udev port
type hints for QMI and MBIM ports as well.
There should be no need to do an early check to filter out ports of
the wrong subsystem.
For the user of these methods it is irrelevant if the FALSE is
returned because the port is of the wrong subsystem, or because the
test wasn't added to be probed, or because the test actually failed.
In other words, the ports where the test succeeded will only have
succeeded if they are of the correct subsystem and if the test was
actually executed successfully.
Instead of flagging them as 'ignored' so that they aren't probed, we
can also flag them as 'audio' now, so that the logic knows which port
to report as used for audio in the Call object.
By default the build used -Wno-unused-but-set-variable but that's
clearly not what we want. Fix those problems.
When using clang, the compiler doesn't error on unknown compile
options, so let's add -Werror to the checking too.
CC='clang'
configure:3408: checking for gcc
configure:3435: result: clang
...
configure:17644: checking whether gcc understands -Wno-unused-but-set-variable
configure:17657: clang -c -Wall -std=gnu89 -g -O2 -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wstrict-prototypes -Wno-unused-parameter -Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-but-set-variable conftest.c >&5
warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
1 warning generated.
configure:17657: $? = 0
configure:17666: result: yes
Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
This prevents errors due to nasty typos in the strings.
We define all symbols in a single header file that is NOT considered
part of the API, as there is no need for MM clients to know about
these tags code-wise. These tags are only meaningful when associated
to devices in udev.
Information of each tag is included in the general API documentation.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/88
Lukas Voegl
Dan Williams
Aleksander Morgado
Thomas Vogt
Z-张旭
Aleksander Morgado
Madhav
Lubomir Rintel
Daniele Palmas
Loic Poulain
Andrew Lassalle
Dan Williams
Alfonso Sánchez-Beato
Ben Chan