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'
This is the port to git master of the following commit:
commit 65f13f41cfd00cd38f118121a58b83713501f45f
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Jul 17 16:00:31 2012 -0500
gsm: fix sending SMS messages on some modems and use PDU by default
It turns out we really do have to wait for the modem to return the
">" prompt before sending the message data, otherwise a number of
modems will complain about the data and fail the message. Fix that
by sending the first bit of the CMGS, waiting for the ">", and then
sending the rest.
This also switches all modems over to PDU mode by default if they
support it, since it's more compatible and most recent modems don't
even bother to support text mode anyway.
Instead of using a predefined set of string values for 'ip-type' in
Modem.CreateBearer() and Simple.Connect(), we'll use an enumeration. The
implementation will then need to convert the requested IP family type to e.g.
the correct PDP type in 3GPP modems.
This change also consolidates the use of enums in dictionary properties when
possible to do so, as with the Rm Protocol.
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.
In practice, it may take longer time for a SIM to become ready when the
modem interface tries to use AT+CPIN? to determine if the SIM is
PIN-locked. This patch increases the number of trials for PIN check to
address the issue.
Once upon a time it was a good idea to have separate steps for CS and PS related
actions, so that plugins could override specific steps with a great detail. That
idea turned out to be not very useful, as the only case which requires custom
CS/PS registration actions is the QMI-enabled modem, and that one has commands
to act on both registration actions at the same time. So, we now consolidate
all steps, so that the implementation of the interface needs to provide all the
logic to setup/enable/disable/cleanup/check registrations in each mode.
Also, we consolidate how the unsolicited registration messages are handled, so
that it's equivalent to other unsolicited messages:
* 'Setup' will configure ports to process the unsolicited messages.
* 'Enable' will tell the modem to send unsolicited messages.
* 'Disable' will tell the modem not to send unsolicited messages.
* 'Cleanup will configure ports to ignore the unsolicited messages.
Aleksander Morgado
Ben Chan