Age | Commit message (Collapse) | Author |
|
We already have methods to query for interface specific attributes
like class/subclass/protocol, so add a new one for the interface
number, and make sure we use ATTRS{bInterfaceNumber} to load it
always, instead of assuming the ID_USB_INTERFACE_NUM property is set.
|
|
|
|
Also providing support to report errors when attempting to decode the
strings.
|
|
Instead of blindly assuming that we can take whatever string given as
valid UTF-8, we'll always attempt to convert from the current modem
charset into UTF-8. Before we were doing this for hex-encoded UCS2,
but not for example for GSM-7.
And due to the now applied GSM-7 conversion, the mf627a/mf627b +COPS
parsing unit tests are updated accordingly, because when converting
from an input string that contains byte 0x40 ('@' in UTF-8) as if it
were GSM-7, the 0x40 is taken as character '¡', encoded as 0xc2,0xa1
in UTF-8).
|
|
The sequence of commands is exclusively used during the set current
bands operation, so there is no point in storing it in the private
object data.
|
|
take_and_convert_to_current_charset()
|
|
Use the generic mm_modem_charset_bytearray_to_utf8() instead.
|
|
Use the generic mm_modem_charset_bytearray_from_utf8() instead.
|
|
If the conversion is not fully compatible, the user of the method
needs to request transliteration enabled explicitly in order to avoid
returning errors in this method.
|
|
Until now, this method would automatically apply transliteration;
i.e. replacing characters with '?' when no direct translation was
available.
We can attempt to do that transliteration on strings that are not
critical, e.g. the operator name reported by the network. But we
should not do that on other types of strings, e.g. on SMS contents
that may really have additional purposes than just being
human-readable.
This commit makes the transliteration option to be explicitly
requested by the caller.
|
|
It makes much more sense than returning a gchar array, as gchar is
signed.
|
|
Optionally given explicitly, and -1 can be used to assume it's
NUL-terminated.
|
|
This util method checks whether the input string is a valid hex
string, so make sure we return a GError on failure.
|
|
|
|
During disabling of gps sources the bitmask that keeps track of them is
updated incorrectly. Instead of removing the current source, all other
sources are removed from the mask.
One problem that arises from this is, that when you enable GPS after it
has been disabled completely (e.g. by disabling all GPS sources), the
code will not send a "+CGPS=1,1" command because it incorrectly assumes
that GPS is still enabled on the device.
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/306
Signed-off-by: Louis-Alexis Eyraud <louis-alexis.eyraud@sigfox.com>
|
|
The _get_port_gps() returns a full reference, use _peek_port_gps()
instead.
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/302
|
|
The parse_vendor_pco_info() method was returning NULL without error if
the pco info string was empty.
Under this situation, the code would have tried to add a NULL MMPco
into the pco_list list, which is not desired.
Avoid this, by making sure a NULL return always sets an error.
|
|
|
|
|
|
|
|
This property (initially set to FALSE) controls whether QMI over MBIM
should never be considered. This property is set to TRUE for XMM-based
MBIM devices as they don't support QMI.
This fixes a probing delay of 15s on a Fibocom L850-GL device
(2cb7:0007) found in the Lenovo T14 Gen 1.
The establishing of a QMI connection was refused multiple time with
MBIM error OperationNotAllowed. Only the timeout of 15s for this
connection resumed the probing.
The properties in the MMBroadbandModemMbim are only installed when
WITH_QMI and QMI_MBIM_QMUX_SUPPORTED are set. Actually, this should only
disable the PROP_QMI_UNSUPPORTED but as this is the only property this
avoids the "unused variable 'self'" warnings/errors when trying to
compile set_property and get_property without QMI support. This can be
changed once other properties are needed.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/284
|
|
|
|
|
|
This plugin implements support for old Qualcomm SoCs like the MSM8916
or the MSM8974, where:
* control ports are available via RPMSG channels exported as devices
e.g. with rpmsgexport:
https://github.com/andersson/rpmsgexport
* network ports are exposed by the bam-dmux kernel driver:
https://github.com/msm8916-mainline/linux/commits/bam-dmux
Adding support for newer Qualcomm SoCs (e.g. QRTR+IPA) could be done
in a similar way on this very same plugin.
This plugin is the first and only one that implements support for a
modem device that is "built in" the system, as opposed to external
modems that may be available via USB or PCI.
The ID_MM_PHYSDEV_UID based udev tags provided by the plugin provide
the logic to bind all the SoC ports together in the same modem object,
and therefore ID_MM_PHYSDEV_UID should not be used by users to
override the ones set by the plugin.
All "rpmsg[0-9]*" ports that are considered part of the modem are
flagged as candidate, ignoring the parent "rpmsg_ctrl[0-9]*" ports on
purpose. This setup therefore assumes that the channels have been
exported already as devices (e.g. using rpmsgexport).
libqmi 1.27.2 is required to support the "WDS Bind Data Port" message.
|
|
Each different plugin or protocol had a different connection attempt
value. E.g. QMI and MBIM both used 60s max for the connection attempt,
while the u-blox plugin had up to 180s for ECM based connection
setups.
This commit consolidates all plugins and protocols to use the same
timeout values for commands that may take long to respond, e.g. a
connection atempt under low signal quality conditions.
A value of 180s for the connection attempt steps and 120s for a
disconnection attempt step is considered. Note, though, that in some
cases (like a IPv4v6 setup attempt using QMI) we may have more than
one such long step, so this doesn't mean that a connection attempt
will always take less than 180s.
Users of the connection/disconnection APIs should be able to handle
the case where the attempt times out in their side (e.g. with a lower
DBus request timeout), and which would not mean the actual request
they did really failed. E.g. a connection attempt with a DBus timeout
of 30s may fail in the user with a timeout error, but the attempt
would still go on for as much as the plugin/protocol needs.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/270
|
|
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
This patch removes all monitoring of the 'usb' subsystem completely,
which is anyway a valid subsystem but for which we shouldn't need any
special handling. Right now, with newer kernels, we were using that
monitoring exclusively to get notified of full USB device remove
events, which is really not required as we already process the port
removals one by one.
We simplify the logic everywhere that attempted to match either the
'usb' or 'usbmisc' subsystems, and we no longer require the explicit
checks for the port name being named 'cdc-wdm[0-9]*' in the code, as
that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
|
|
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
So, rename the port subsystem type enumn to 'usbmisc'.
|
|
The numbers associated to each port mode given by the AT^GETPORTMODE
response are not USB interface numbers, they are 'port numbers'.
Moreover, these numbers may start either at 0 or at 1, depending on
the firmware.
The only reasonable way to parse this response is to just gather the
order of all the port modes reported, and apply the modes to each
serial port found in the system in the same order.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/239
|
|
|
|
So don't re-process them in the generic modem when grabbing the port.
|
|
We will use one single method to apply port type hints, not a mix of
them:
* If AT^GETPORTMODE is supported, prefer its hints over any other
method.
* Otherwise, try to guess hints from USB interface descriptions.
* And if none of the plugin-specific hints are supported, we'll
default to applying generic port type hints from udev tags.
Once the hints have been applied by one of the methods above, the
fallback hint sequences are run:
* Flag the first cdc-wdm port as primary if no other port has been
flagged as primary.
* Flag the USB interface 0 as PPP if no other port type hint has
been set in any other port.
The logic applying all these procedures has been refactored so that we
have separate functions for each, which is much easier to read and
follow, even if it requires multiple iterations over the port probe
list.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/238
|
|
The mm_base_modem_get_port_*() returns a full reference, we should use
the mm_base_modem_peek_port_*() methods instead. Also, refactor a bit
the logic because both ports are really configured in the same way, so
just apply the same setup to both.
|
|
The class object definition should always be last in the file,
following the interface definitions. The actual method implementations
should be given before any other type system method (i.e. before even
the _new() method).
|
|
There is no need to reload it on every settings update attempt; just
load it once when the 3GPP interface is initialized, and re-use the
loaded value on every new update attempt.
|
|
Don't go to next step and then check if we need to jump to the RF on
step, jump right away.
|
|
Attempting to change the initial EPS bearer settings while in full
functionality mode shouldn't happen, so make sure we don't attempt to
do that if going into low power mode fails.
|
|
|
|
|
|
|
|
Multiple changes that shouldn't affect behavior:
* Avoid reusing the same context and state machine for the set and
the load operations, because they truly have different behaviors.
* Setup the common load operation in a separate async method, and
reuse the common operation for both the runtime state loading and
the settings configuration loading.
* Avoid having a "generic step ready" method, and instead provide
proper ready methods for each step, so that we can give
comprehensive warning logs when things fail.
* Use the common CFUN? response parser instead of a custom
implementation.
|
|
|
|
|
|
|
|
|
|
Add a polling mechanism for port responsiveness, since some modem
families require some time before being usable after the serial
ports have been exposed by the kernel.
|
|
|
|
|
|
So that e.g. in QMI-based devices we have both things, not just one.
|
|
This reverts commit e91f2ef315526a1a8a1b451acb5a190686b05225.
This was wrongly merged squashing multiple commits together. Reverting
to merge separate commits.
|