The new 'ID_MM_PORT_IGNORE' tag will tell ModemManager to fully avoid using a
given port.
Note that it is key to not only flag the port probe as ignored, but also to
fully ignore the ports in e.g. mm_port_probe_list_has_qmi_port() as those
methods will be used to decide which kind of modem object to create. We don't
want to create a QMI-based modem which may have all QMI ports blacklisted.
E.g. this would be the result when having ModemManager compiled without QMI
support, and a modem with 2 QMI/WWAN pairs:
$ mmcli -m 2
/org/freedesktop/ModemManager1/Modem/2 (device id '417e4dcff7f232b62cfe6c972e2099701848fd7f')
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7304'
| revision: 'SWI9X15C_05.05.02.00 r19147 carmd-fwbuild1 2013/11/15 13:54:28'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: 'unknown'
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7'
| drivers: 'qcserial, qmi_wwan'
| plugin: 'Gobi'
| primary port: 'ttyUSB8'
| ports: 'ttyUSB8 (at), wwp0s29u1u7i8 (unknown), ttyUSB6 (qcdm), wwp0s29u1u7i10 (unknown)'
The /dev/cdc-wdm ports don't even appear (as they were not even probed), but the
newly ignored WWAN ports do appear in the list, but flagged as UNKNOWN type
(instead of NET).
So, we may have modems with multiple /dev/cdc-wdm ports, like Ericsson modems,
where only 1 of them is MBIM. With the previous logic, we would probe all
/dev/cdc-wdm ports for MBIM as soon as one of the ports was handled by the
cdc_mbim driver. That is totally not optimal, as we are already know that they
are not MBIM (not handled by cdc_mbim).
Instead, fix the logic to just probe for MBIM or QMI if the actual driver
managing the port is MBIM or QMI.
When running the pre-probing VID/PID filters, the ports were not filtered out if
the plugin had configured post-probing vendor/product string filters. But, these
post-probing filters are only applicable to AT ports.
From now on, this logic will not be applied to non-serial ports. In other words,
pre-probing VID/PID filters applied to non-serial ports will always result in
the port being filtered out or being allowed, regardless of any additional
vendor/product string post-probing filter configured by the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=710437
Plugins which may support QMI ports need to explicitly request QMI probing
in cdc-wdm devices. This should also avoid probing cdc-wdm ports when we know
that the plugin doesn't support them (e.g. with Ericsson MBM devices).
https://bugzilla.gnome.org/show_bug.cgi?id=696701
A new reference to probe was acquired through mm_device_get_probe(), just unref it
when no longer needed. Note that mm_port_probe_run() will take its own reference
for as long as required to complete the operation.
This patch adds a 'hotplugged' flag to MMBaseModem to indicate if a
modem is newly plugged in. A plugin can use this information to
determine if, for example, the modem needs to be soft reset using the
ATZ command.
Dan Williams <dcbw@redhat.com> contributed the idea of implementation.
Every port probing will have the Generic plugin as fallback, and due to some
other issues in other plugins (see ee099fcd), we need to allow overwriting the
suggested plugin from the Generic to a more specific one.
One of the drawbacks of this is that we're actually allowing the Generic plugin
to probe and accept the port, which means that the generic plugin may accept a
specific port type (e.g. QMI) while the specific plugin wouldn't. So, we will
now also run the subsystems filter before grabbing the specific port, in order
to really filter out those cases. We still keep the subsystems filter in
pre-probing, so that we build a better initial plugin list to probe.
For each port, we will construct the list of plugins to test with. In that list
we will include those plugins which are likely to handle a given port, so we
will skip all those which aren't.
To see if a plugin is likely or not, we will run the pre-probing filters before
adding them to the list, with the new `mm_plugin_discard_port_early()'. This
method will return one of these hints:
* UNSUPPORTED: The plugin will not be able to handle this port.
* MAYBE: The plugin may handle this port.
* LIKELY: The plugin may (very likely) handle this port.
* SUPPORTED: If any plugin should support the port, this is it.
Plugins reported to be 'likely' supporting the port will be probed before the
ones reported just as 'maybe'.
If a plugin reports 'supported' only that one and the fallback generic ones will
be tried.
Logging which are the reasons for a plugin to filter a given port really help
when trying to debug user issues. Some other general logging improvements also
done.
Huawei modems will probe interface 0 always first; if we try to probe another
interface meanwhile the supports check will give us a MM_CORE_ERROR_RETRY error,
indicating that we need to defer the probing of the port.
This is the port to git master of the following patch:
commit 21e66dfa1774ac2ee037ac8b6e8bb4d71a6f7931
Author: Dan Williams <dcbw@redhat.com>
Date: Thu Aug 23 21:13:35 2012 -0500
core: add function to open probe ports without removing echo
Some devices (Sierra GSM ones) return stuff we need but don't
bother to prefix it with <CR><LF>, so we need to optionally turn
off the echo removal at probe time.
We'll try to cope with getting devices being reported in either 'usb' or
'usbmisc', trying to avoid the need of checking kernel version during runtime.
Some devices may export cdc-wdm ports talking AT. We need to explicitly check
for QMI protocol support on the cdc-wdm ports before assuming they are QMI.
Different ports of the same modem may get handled by different drivers. We
therefore need to provide a list of drivers (new `Modem.Drivers' property with
signature 'as') instead of just one (removed `Modem.Driver' property with
signature 's').
$ sudo mmcli -m 0 | grep drivers
| drivers: 'qcserial, qmi_wwan'
Plugins may specify that specific vendor & product IDs or strings are not
supported. This is useful when plugins need to specify that they support
all devices of a given vendor except for some specific ones.
Instead of providing a method to get if a plugin is requesting to get sorted
last, we provide a way to comparing two plugins, compatible with the
GCompareFunc required in g_list_sort().
