| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
Reported by: Jose Maria Gonzalez <jmgonzalezc@indra.es>
|
|
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 is really just to have a nice valgrind/memcheck output report, no big deal
if they were never freed.
|
|
|
|
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.
|
|
Don't require vendor/product string probing if the plugin already had
vendor/product ID filters and we actually passed those.
|
|
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.
|
|
|
|
|
|
assuming it's not
|
|
|
|
|
|
|
|
|
|
|
|
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().
|
|
|
|
We let plugins execute some custom initialization in the ports, specified by
a `MMAsyncMethod'.
|
|
It allows plugins to specify whether they cannot support ports handled by
specific drivers.
|
|
The `custom-at-probe' property is just to modify the way we check for AT port
support.
|
|
G_TYPE_INSTANCE_GET_PRIVATE() is really slow, so try to call it as less as
possible.
|
|
|
|
|
|
We'll do it with a GCancellable.
|
|
|
|
The `MMDevice' acts as port probe cache for us now, directly storing all port
probes of the same device.
|
|
And don't do it in MMPlugin.
|
|
|
|
|
|
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.
|
|
|
