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().
There's no real point in maintaining a separate `MMPlugin' interface, as all the
plugins will inherit from `MMPluginBase', so just merge them and simplify
everything.
Before this, we only exported the modem to DBus when all ports were organized,
in order to make sure that we select as primary port the one we really want and
not the first AT port grabbed. Given that to get all the ports organized we also
needed to wait to get all the ports grabbed, we can now also defer the creation
of the modem object until all the ports get grabbed. This allows us to create
different types of objects based on the ports available (e.g. we can now create
QMI-supported modem objects if we see a QMI port around).
We chain up the Generic plugin created MMBroadbandModem objects within the
GDBusObjectManagerServer in MMManager, so that they get properly exported in
DBus.
There is no single case where more than one plugin may end up wanting to support
a given port, and therefore there is no need to report the numeric support level
when reporting SUPPORTED.
We now have 'supports_port' (async method) and 'supports_port_finish' (to get
the result of the async method), so it makes sense to rename the method to
'supports_port_cancel'.
Before this change, supports check was either synchronous (e.g. in some
UNSUPPORTED cases) or asynchronous (when IN_PROGRESS was returned).
With this fix, the supports check requested to the plugin will always be
completed asynchronously; either directly in an idle before launching any real
probing operation, or once the probing operation is finished.
Therefore, it is not expected to get a IN_PROGRESS reply in
mm_plugin_supports_port_finish(), only UNSUPPORTED|SUPPORTED|DEFERRED.
Note that even if a plugin says it wants to be sorted last, the generic plugin
will always be the last one. Also, there is no order guaranteed between two
plugins that request to be sorted last.
Allow plugins to perform asynchronous port detection, and to defer port detection
until later. This moves the prober bits into MMPluginBase so that all plugins
can take adavantage of it only when needed; the probing is not done at udev time.
Furthermore, plugins like Novatel can flip the secondary ports over the AT mode
through deferred detection, by deferring the secondary ports until the main port
has been detected and AT$NWDMAT has been sent.
This commit also finishes the port of the rest of the plugins (except mbm) over
to the new port detection methods and plugin API.
Get rid of dependency on HAL, using libgudev instead. Fix up the plugin API
to no longer use either HAL or udev defines, but let plugins use whatever
mechanism they want for getting more information out of the device given the
subsystem and device node name.
Modems are now defined as "master" devices which "own" a one or more ports.
A port could be a serial tty device or a network device or whatever. The
plugin figures out whether it supports a given port or not and then assigns
it to a new or existing modem. Modems now have a 'valid' property that
should be set to TRUE when the modem has enough ports to operate correctly.
For devices (ex. 'hso') that use a network device for data transfer, the
modem would need to grab at least one TTY and the network device associated
with that physical device to be 'valid'.
Also move the generic modem support code to a plugin like other modem plugins,
and change the I-support-this-device mechanism to return a number indicating
the level of support. For example, the generic plugin would return a quite
low number if the device indicates via probing that it can do GSM or CDMA, but
a more specific plugin can indicate better support for the device, and thus
the more specific plugin would win control.
Aleksander Morgado
Aleksander Morgado
Dan Williams
Alexander Sack
Tambet Ingo