| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Given the new pre-probing filters, the IDs are no longer retrieved by the
plugins.
|
|
device
E.g. the Generic plugin will give as unsupported 'net' ports found in the
device, as it doesn't know how to use them.
|
|
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).
|
|
|
|
|
|
only one
If we got an existing modem showing a new port, and the plugin handling that modem
said that only one AT port was expected, we shouldn't be AT-probing it any more.
|
|
|
|
Since udev 147 the gudev API is no longer marked as experimental, and therefore
`G_UDEV_API_IS_SUBJECT_TO_CHANGE' is no longer needed.
|
|
If we only expect a single AT port, we'll cancel all remaining AT port probings
in the other ports, as soon as we get the first one.
|
|
Will allow us to cancel other AT probings as soon as the first AT port is
grabbed.
|
|
So that we get logs when net ports are being checked for support, which won't be
probed.
|
|
Plugins that need to get sorted last by the PluginManager can now be determined
just by looking at the post probing filters.
|
|
|
|
|
|
|
|
|
|
|
|
'net' ports will be supported as soon as there is another port reporting
successful support.
|
|
|
|
We chain up the Generic plugin created MMBroadbandModem objects within the
GDBusObjectManagerServer in MMManager, so that they get properly exported in
DBus.
|
|
|
|
Capabilities checking is done during the Modem interface initialization.
|
|
|
|
If the port is supported by the plugin, leave the probe in the internal HT until
the port gets grabbed afterwards.
|
|
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.
|
|
Some devices support 'net' devices, which cannot be AT or QCDM probed.
If the port being checked for support corresponds to an already existing modem,
the port will be reported as SUPPORTED.
If this is the first port of the modem being checked for support, we will just
DEFER the support check until we get a modem created.
|
|
Instead of just a boolean, provide a MMPluginSupportsResult, so that we can pass
it as is during `supports_port_finish()'.
|
|
If the plugin does a Vendor ID check and it passes, it doesn't need Vendor
string probing.
If the plugin does a Vendor ID check and it fails:
- If Vendor strings reported, it needs Vendor probing.
- If Vendor strings not reported, fail as unsupported.
If the plugin does a Product ID check and it passes, it doesn't need Product
string probing.
If the plugin does a Product ID check and it fails:
- If Product strings reported, it needs Product probing.
- If Product strings not reported, fail as unsupported.
|
|
Once probing is finished, the plugin will check whether the port is supported
or not based on the following filters:
- Capabilities
- Reported Vendor string
- Reported Product string
|
|
Before any real probing is launched in the port, the plugin will check whether
it can skip the request based on the following filters:
- Subsystems
- Drivers
- udev-reported Vendor ID
- udev-reported Product ID
- udev-reported Tags
|
|
The previous 'MMPluginBaseSupportsTask' object is more or less equivalent to the
new `MMPortProbe' in terms of what information it contains. The main difference
being that the new `MMPortProbe' object handles internally the whole probing
flow as needed: only the needed probing sequences are done. For example, vendor
or product string probing will only be performed if a plugin requests it.
|
|
The plugins can set this property to filter support check requests by the
availability of a given udev tag in the port. The value given to the property
should be a NULL-terminated array of C strings, e.g.:
const gchar *tags[] = { "ID_MM_X22X_TAGGED", NULL };
|
|
The plugins can set this property to filter support check requests by physical
device driver. The value given to the property should be a NULL-terminated array
of C strings, e.g.:
const gchar *drivers[] = { "qcserial", NULL };
|
|
The plugins can set this boolean property to specify whether they can handle
QCDM ports, and therefore probing for them is needed.
|
|
The plugins can set this property to provide a custom value for the send delay
used for characters sent to the AT port during probing.
The value given to the property should be a guint64 specifying the delay in
microseconds.
|
|
The plugins can set this property to filter support check requests by probed
capabilities.
The value given to the property should be a guint built as a mask of
MM_PORT_PROBE_CAPABILITY flags, e.g.:
const guint capabilities = (MM_PORT_PROBE_CAPABILITY_GSM |
MM_PORT_PROBE_CAPABILITY_CDMA);
|
|
properties
The plugins can set these properties to filter support check requests by
AT-reported Vendor string and Product string.
The value given to the properties should be a NULL-terminated array of strings,
e.g.,
static const gchar *vendor_strings[] = { "cinterion" , NULL };
|
|
The plugins can set this property to provide custom initialization commands that
should be issued to the modem before real probing starts.
The value given to the property should be an array of MMPortProbeAtCommand
variables finished with a last one exposing a NULL command, e.g.:
static gboolean
parse_init (const gchar *response,
const GError *error,
GValue *result,
GError **result_error)
{
if (error)
return FALSE;
/* If we didn't get any error, it is an AT port */
g_value_init (result, G_TYPE_BOOLEAN);
g_value_set_boolean (result, TRUE);
return TRUE;
}
static gboolean
parse_init_last (const gchar *response,
const GError *error,
GValue *result,
GError **result_error)
{
g_value_init (result, G_TYPE_BOOLEAN);
/* On last error, report as not being an AT port */
g_value_set_boolean (result, error ? FALSE : TRUE);
return TRUE;
}
static const MMPortProbeAtCommand custom_init[] = {
{ "ATE1 E0", parse_init },
{ "ATE1 E0", parse_init },
{ "ATE1 E0", parse_init_last },
{ NULL }
};
|
|
The plugins can set these properties to filter support check requests by
udev-reported Vendor ID and Product ID.
The value given to the properties should be a 0-terminated array of guint16s,
e.g.,
static const guint16 vendor_ids[] = { 0x0421 , 0 };
|
|
The plugins can set this property to filter support check requests by subsystem.
The value given to the property should be a NULL-terminated array of C strings,
e.g.:
const gchar *subsystems[] = { "tty", NULL };
|
|
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.
|
|
Make port roles more flexible. We have modems that do PPP
on interfaces other than the primary interface, and that
wasn't possible with the old code. So clean up all that
logic and move the port organization code into the core
so we can reduce code in the plugins.
In the new world order, the plugins say whether the port
is a QCDM port, an AT port, or ignored. If it's an AT
port the plugins get to tag it as primary, secondary, or
PPP, or any combination of the 3. This allows for modems
where PPP should really be done on the secondary port
(Huawei E220, Sierra devices) so that the primary port
stays open for command and status.
Modem subclasses no longer get asked to handle port grabbing
themselves. Instead, that's now done by the generic classes
(MMGenericCdma and MMGenericGsm) and the plugins are notified
when a port is grabbed so they can add unsolicited response
handlers for it. After all ports are grabbed by the generic
classes, they get "organized", which assigns various ports
to the roles of PRIMARY, SECONDARY, DATA, and QCDM based
on specific rules and hints that the plugin provided (which
are expressed as MMAtPortFlags). The plugins then have
a chance to perform fixups on the primary port if they choose.
The plugin code is responsible for determining the port
hints (ie MMAtPortFlags) at probe time, instead of having
a combination of the plugin and the modem class do the
job. This simplifies things greatly for the plugins at
the expense of more complicated logic in the core.
|
|
|
|
|
|
Observed on a generic ZTE device.
|
|
On a ZTE MF626, sometimes the aux port will respond only with
"ERROR" to probing commands (while the SIM is starting up) and
previously we'd lose the port because we were only looking for
valid probe responses. But if the port returns ERROR or CME ERROR
etc we know it's an AT port and that we can use it once we've
gotten the type response (CDMA or GSM) from the main port.
|
|
If there was data waiting, the task freed it, but then the port
got closed, and the data callback might have freed the data again.
|
|
Newer Sierra devices have this (ie 306); it's the CnS port so ignore
it immediately.
|
