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
This is not just a rename of the rule, we also now avoid doing an
explicit check on the port name as well, and we rely on subsystem
checks only; i.e. the same logic applied for net ports.
The port candidate rules already do a 'cdc-wdm*' device name check
so it shouldn't be a big deal.
Until now, the plugin whitelist rule in the filter would only handle
those plugins that require specific udev tags, and those that had
explicit full vid:pid pairs.
This update makes a new implicit automatic whitelist for all devices
that match any of the vids managed by the different plugins.
Looking at the current list of devices in the blacklist and greylist
maintained by ModemManager, there are no devices falling under the
list of supported plugin vids that would need to be blacklisted;
except for u-blox GPS modules:
huawei -> 0x12d1 -> None in blacklist/greylist
thuraya -> 0x1a26 -> None in blacklist/greylist
telit -> 0x1bc7 -> None in blacklist/greylist
dLink -> 0x2001 -> None in blacklist/greylist
wavecom -> 0x114f -> None in blacklist/greylist
x22x -> 0x1bbb,0x0b3c -> None in blacklist/greylist
anydata -> 0x16d5 -> None in blacklist/greylist
quectel -> 0x2c7c -> None in blacklist/greylist
haier -> 0x201e -> None in blacklist/greylist
novatel -> 0x1410 -> None in blacklist/greylist
dell -> 0x413c -> None in blacklist/greylist
option -> 0x0af0,0x1931 -> None in blacklist/greylist
nokia -> 0x0421 -> None in blacklist/greylist
cinterion -> 0x1e2d,0x0681 -> None in blacklist/greylist
simtech -> 0x1e0e -> None in blacklist/greylist
iridium -> 0x1edd -> None in blacklist/greylist
pantech -> 0x106c -> None in blacklist/greylist
longcheer -> 0x1c9e,0x1bbb -> None in blacklist/greylist
linktop -> 0x230d -> None in blacklist/greylist
sierra -> 0x1199 -> None in blacklist/greylist
ublox -> 0x1546 -------------> GPS chips blacklisted !!!!!
foxconn -> 0x0489 -> None in blacklist/greylist
broadmobi -> 0x2020 -> None in blacklist/greylist
fibocom -> 0x2cb7 -> None in blacklist/greylist
tplink -> 0x2357 -> None in blacklist/greylist
zte -> 0x19d2 -> None in blacklist/greylist
The rules used to blacklist the u-blox GPS chips have already been
moved to the u-blox plugin itself, and now they use the broader
ID_MM_DEVICE_IGNORE tag that applies in all filter modes.
Several plugins define the specific device vid:pid pairs they
support. Let's use this information as a direct indication that
ModemManager can probe the devices.
Several plugins define specific udev tags that must be available in
the device in order for the plugins to use them. Let's use these tags
as a direct indication that ModemManager can probe the devices.
In particular, this change would make all Ericsson MBM modems probed
right away also in STRICT filter mode, without needing to check the
ttyACM interface type or the available net ports.
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the
internal blacklist of devices shipped by ModemManager when running in
either DEFAULT or PARANOID filter modes. The name of the tag is
extremely misleading because it doesn't really make the full device be
ignored, the tag only applied to TTY ports.
This commit repurposes the tag so that it applies to ANY kind of
port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type
(i.e. also applicable in STRICT mode).
The internal blacklist shipped by ModemManager, which should NOT be
used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST.
The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its
name is really meaningful. If there are users or third-party projects
adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name,
they should have no problem as the new rule is more restrictive than
the old one.
All the previous filter rules were applicable per-port independently.
But, we also want to apply rules on a port based on the existence of
other ports on the same device (e.g. allow TTY if the device also has
a NET port). In this case, we need to wait for all ports to appear and
then apply the additional rules.
We re-use the "min wait time" timeout in the plugin-manager for this
same purpose. This timeout is setup to wait for ports to appear before
starting the probing process (e.g. so that plugin filters like the
forbidden-drivers one work). The very same timeout can therefore be
used to check whether we start the probing or not based on additional
filter rules.
The 'default' filter policy was based on blacklisting as much as
possible and otherwise allow.
The new 'strict' filter policy will be based on whitelisting as much
as much as possible, using custom defined rules, and otherwise forbid
the ports.
The new 'paranoid' filter policy is equivalent to the 'strict' filter
after having applied the blacklist rules from the 'default' filter.
Added a new '--filter-policy=[POLICY]' option in the daemon, which
allows selecting between the supported filter policies. For now, only
two policies are defined:
* default: the default policy used by ModemManager, where it tries
to probe and detect as many modem ports as possible.
* whitelist-only: only devices explicitly tagged via udev (with the
ID_MM_DEVICE_PROCESS tag) will be probed and used.
The user can tag modems (either full devices or ports independently)
to be explicitly probed by ModemManager, using the new
"ID_MM_DEVICE_PROCESS" udev tag, e.g.:
$ sudo vim /lib/udev/rules.d/78-mm-whitelist-internal-modem.rules
ACTION!="add|change|move", GOTO="mm_whitelist_internal_modem_end"
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="a001", ENV{ID_MM_DEVICE_PROCESS}="1"
LABEL="mm_whitelist_internal_modem_end"
$ sudo udevadm control --reload
$ sudo udevadm trigger
This rule runs before any other filter rule.
This tag may be used e.g. by manufacturers building systems with
built-in modems that will always be available.
Distributions targeting support for multiple modem devices shouldn't
use this udev tag.
E.g. forcing a MBIM modem to run in AT-only mode:
# MM_FILTER_RULE_NET=0 \
MM_FILTER_RULE_CDC_WDM=0 \
/usr/sbin/ModemManager --debug
This is just for quick testing for now.
This new object allows configuring the filter rules applied to the
device ports. By default, for now, it implements the same rules as the
MMKernelDevice is_candidate() method, which is obsoleted.
Loic Poulain
Andrew Lassalle
Aleksander Morgado