And only define WITH_SYSTEMD_SUSPEND_RESUME when enabled.
We already have other systemd specific features under the
--with-systemd-* name scheme, so consolidate that, given that we don't
have any other method to support suspend/resume notifications.
Looks like the preprocessor doesn't choke when using #if WITH_UDEV and
it isn't defined to any value, but anyway, better explicitly say that
we're checking if it's defined or not.
This logging is available if the software was build with the configure
option --with-systemd-journal.
It will be enabled by default if libsystemd is found.
The runtime parameter --log-journal enables to output of log messages
to the systemd journal.
Please note that the journal priority field has the same value as the
syslog level so no conversion is required here.
This allows for easier additions of other logging mechanism.
Using the syslog loglevel as parameter because we need to be able to
map the MMLogLevel and the GLogLevelFlags to a common representation
when using the log_backend in _mm_log and log_handler.
The syslog level is more suitable because it supports more values than
the MMLogLevel.
Adding a helper function to turn the log level into the text. Also
add an internal flag to disable this output. This flag will become
useful when adding systemd journal support.
Starting with adding a typed enum type for the log level named
MMLogLevel.
Suggested-By: Aleksander Morgado <aleksander@aleksander.es>
The level was checked twice in _mm_log. Once at the beginning and
again when turning the level into both the syslog priority and some
descriptive text which was added to the log level. Removing the check
at the second location as it was redundant.
Also adding a helper function to turn the MMLogLevel into the syslog
equivalent. This will become handy when adding support for systemd
journal.
This CL removes the unnecessary `>= 0' check on `mode_val' and
`ind_val', which are both guint values extracted from a GArray with
guint values, in mm_3gpp_parse_cmer_test_response to address the
following compiler warnings:
mm-modem-helpers.c:2933:22: error: comparison of unsigned expression >=
0 is always true [-Werror,-Wtautological-compare]
if (mode_val >= 0 && mode_val <= 3)
~~~~~~~~ ^ ~
mm-modem-helpers.c:2943:21: error: comparison of unsigned expression >=
0 is always true [-Werror,-Wtautological-compare]
if (ind_val >= 0 && ind_val <= 2)
~~~~~~~ ^ ~
The generic modem has several URC handlers for generic messages, like
+CIEV. But, there may be cases where the plugins themselves want to
provide their own URC handlers to be run before the generic one.
This patch enables this setup by always prepending the new URC
handlers, so that the last ones added are processed before the ones
already in the list. So if a plugin does its own unsolicited
messages setup, they can run first the parent setup and then their
own.
The only thing to consider is that the regex provided by the plugin
must be specific enough not to match the specific messages required
by the parent implementation.
We also remove the explicit refresh request from the Cinterion plugin,
as this is a generic action applicable to all modems that require
polling for signal quality and/or access technology.
Plugins have two ways to update signal quality and access technology
values: via unsolicited messages or via polling periodically.
Instead of keeping separate contexts for polling signal quality and
access technology values, we setup a common timeout to trigger
both. This allows us to simplify in which case the explicit update is
required, whenever one is needed to be explicitly updated, the other
one should also be.
The logic now also allows plugins to return an UNSUPPORTED error in
either load_signal_quality() and/or load_access_technologies() to tell
the interface logic that the polling of the specific item shouldn't be
performed (e.g. if the updates are expected via unsolicited messages).
If both signal quality and access technology polling is flagged as
disabled, we totally disable the polling logic internally.
The new SignalCheckContext is bound to the lifetime of the object so
that we can keep the value of the supported flags until the object is
destroyed.
If we ask too quick for the PDP context status after a successful
connection attempt reported by the modem, we may find it still flagged
as inactive if the modem is still busy setting up the PPP session.
Do an explicit longer initial timeout before we run the first check,
and after that one setup the additional checks at a higher rate.
Reported-by: Colin Helliwell <colin.helliwell@ln-systems.com>
Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable
Mobile Equipment Event Reporting. We now query the device for the
supported formats and use that info to build commands that will work.
The whitelist made all platform TTYs managed by the 'atmel_usart'
kernel driver probed by ModemManager, which isn't something we want,
as most of these aren't broadband modems.
We leave the logic supporting the ID_MM_PLATFORM_DRIVER_PROBE udev tag
as there may be a case where the user does need ModemManager to probe
a given platform TTY.
The user can build the project passing custom CFLAGS to enable the
function location information, e.g.:
$ ./configure --prefix=/usr CFLAGS="-DMM_LOG_FUNC_LOC"
Group together all options that allow configuring the logging output,
and make them have the same --log-[XXX] prefix.
Also rework the --help output so that all option groups are printed by
default (i.e. there is no longer a --help-all option).
Blacklist the default VID:PID for the Linux USB Serial Gadget in ACM
mode:
{LINUX}/drivers/usb/gadget/legacy/serial.c
#define GS_VENDOR_ID 0x0525 /* NetChip */
#define GS_CDC_PRODUCT_ID 0xa4a7 /* ... as CDC-ACM */
This should never be reused for real products by hardware
manufacturers, but anyway...
Patch actually ported from downstream Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1105352
If going directly e.g. from "Searching" to "Connecting", just setup
the signal quality retrieval logic right away, don't assume we always
go through "Registered" state before starting a connection.
Reported-by: <colin.helliwell@ln-systems.com>
Ben Chan
Aleksander Morgado
Torsten Hilbrich
Daniele Palmas
Dan Williams