Vendor specific plugins that support QMI or MBIM based devices need to
handle the creation of these modems themselves.
https://bugs.freedesktop.org/show_bug.cgi?id=100372
Original patch by Aleksander Morgado.
There are 2 main types of udev properties: device-specific and
port-specific.
The port-specific properties are set independently per port (e.g. port
type hints set per interface number for a given vid:pid).
The device-specific properties apply to all ports in the device. Some
of these properties are currently expected in the physical device
(e.g. ID_MM_PLATFORM_DRIVER_PROBE) while some others are expected in
each port (e.g. the plugin udev tag filters).
This patch tries to simplify the logic and just assume that the device
specific tags may be given in either the physical device or the port
device, by providing separate APIs to retrieve port-specific or
device-specific (global) properties. If the same tag is given in both
the device and the port, the one in the device takes preference.
For the generic backend, these new APIs are really useless, as all
device-specific and port-specific properties are always stored in the
port object themselves (there is no 'tree' of devices in the generic
backend, no 'physdev' device).
For the udev backend, though, there really is a difference, as the
tags may be set in port or device.
https://bugs.freedesktop.org/show_bug.cgi?id=100156
The telit plugin is based on two main ways of checking the purpose of
each port: udev tags flagging specific interfaces (with info taken
from Windows .inf drivers), or otherwise using AT#PORTCFG? to query
the modem about that information. If none of those applies, the port
is ignored by default.
In order to support devices that are not explicitly tagged, the plugin
shouldn't flag as ignored the AT-capable TTYs, instead they are now
grabbed as 'secondary': ports grabbed as secondary will never be used
for either primary/data IF there is another port flagged explicitly
for primary/data.
This fixes the support for modems with a single TTY and no explicit
port type hint tag, e.g. RS232 modems with just one single TTY where
there's no point in specifying port type hints: the port will be
grabbed as secondary, and then automatically promoted to primary/data
as there is no other port grabbed.
https://bugs.freedesktop.org/show_bug.cgi?id=100159
GE910 family supports #PORTCFG layouts different than HE910
family ones.
This patch properly tags GE910 ports according to Telit document
"GE910 Family Ports Arrangements, 1vv0301049"
The mm_base_modem_grab_port() now receives a MMKernelDevice directly from the
plugin, which is then stored in the MMPort corresponding to the port.
This means that we have direct access to e.g. all properties set by udev rules
everywhere, and we don't need additional GUdevClient objects (e.g. like the one
used in the Huawei plugin to detect NDISDUP support during runtime).
For virtual ports (e.g. generated during unit tests), we have a new 'generic'
kernel device object which just provides the values from the kernel device
properties given during its creation.
Instead of relying constantly on GUdevDevice objects reported by GUdev, we now
use a new generic object (MMKernelDevice) for which we provide an initial GUdev
based backend.
