This property is used in the MMIfaceModem to flag whether the SIM hot
swap setup has been performed or not. The flag is now moved to the
iface-specific private context.
The property was also used in AT-based modems, so that implementations
supporting the SIM hot swap via AT URCs could flag the upper layers
whether the enabling of the feature was done correctly or not, and if
so, create and keep the AT ports context open. But this feature only
made sense in AT-based modems, i.e. an MBIM modem that detects SIM hot
swaps via MBIM indications exclusively should not require the AT ports
context open for anything. The check in the MMBroadbandModem object
has therefore been removed, and the logic will be updated so that it
only applies to AT-based modems.
The udev rules expect matches based on shell globbing pattern, not
based on regex. This means that "[0-9]*" doesn't mean "zero or more
digits", it actually means "one digit and zero or more other
characters".
So, avoid the regex like match, even if it worked for us, because it
didn't mean what we thought it meant, plus, it breaks our custom udev
rules processing logic, in which we convert the input patterns into
real regex expressions.
See https://bbs.archlinux.org/viewtopic.php?pid=1415916#p1415916
While at it, also make sure that the wildcard matching is done
exclusively for prefix and suffix matches, never in the middle of
a string, or our custom rules parser would not match correctly.
Since the 'wwan' subsystem addition to the qcom-soc plugin, the rules
to say a modem is handled by this plugin are too broad, and the plugin
attempts to support any kind of device exposed by the WWAN subsystem,
not just those from Qualcomm SoCs.
Update the plugin to require a new ID_MM_QCOM_SOC udev tag that is set
in the plugin udev rules, given that these rules already check for the
expected SoC drivers (bam-dmux, ipa, qcom-q6v5-mss).
Recent Linux kernel versions have introduced a generic WWAN subsystem
that provides various char devices for QMI, AT etc, similar to the
subsystem-specific char devices for USB or RPMSG.
The RPMSG char device for Qualcomm SoCs (e.g. MSM8916/MSM8974)
are particularly complicated to work with because they need to be
explicitly created from userspace with rpmsgexport and don't show up
automatically.
However, it turns out it's fairly simple to wrap the RPMSG subsystem
in a simple driver for the WWAN subsystem. This has several advantages:
- We can drop support for the special RPMSG char devices entirely
at some point.
- The WWAN char devices show up automatically, without having to export
them explicitly, making ModemManager work out of the box on these devices.
For now, just support using the WWAN subsystem alternatively for the
qcom-soc plugin. Later we can consider dropping the old RPMSG code.
This plugin implements support for old Qualcomm SoCs like the MSM8916
or the MSM8974, where:
* control ports are available via RPMSG channels exported as devices
e.g. with rpmsgexport:
https://github.com/andersson/rpmsgexport
* network ports are exposed by the bam-dmux kernel driver:
https://github.com/msm8916-mainline/linux/commits/bam-dmux
Adding support for newer Qualcomm SoCs (e.g. QRTR+IPA) could be done
in a similar way on this very same plugin.
This plugin is the first and only one that implements support for a
modem device that is "built in" the system, as opposed to external
modems that may be available via USB or PCI.
The ID_MM_PHYSDEV_UID based udev tags provided by the plugin provide
the logic to bind all the SoC ports together in the same modem object,
and therefore ID_MM_PHYSDEV_UID should not be used by users to
override the ones set by the plugin.
All "rpmsg[0-9]*" ports that are considered part of the modem are
flagged as candidate, ignoring the parent "rpmsg_ctrl[0-9]*" ports on
purpose. This setup therefore assumes that the channels have been
exported already as devices (e.g. using rpmsgexport).
libqmi 1.27.2 is required to support the "WDS Bind Data Port" message.
