Instead of going through the messaging interface, which just asks
the MMSmsList anyway, just go straight to the list.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Move error paths after getting a multipart reference to before getting
one, to reduce the possiblity that we get a reference from the MMSmsList
that ultimately doesn't end up getting used.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Instead of getting it from the MMIfaceModemMessaging when the
SMS is stored. This flattens dependencies between MMBaseSms and
MMIfaceModemMessaging.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This commit moves creation of the MMBaseSms objects out of MMSmsList and up
into MMIfaceModemMessaging (which is already a MMBroadbandModem) and
the MMBroadbandModem subclasses themselves.
This flattens the creation of MMBaseSms objects by passing them down
from the object that creates the SMS parts, rather than having a
convoluted callback scheme relying on MMSmsList and MMBaseSms having
direct knowledge of their owning modem.
The goal is to eventually remove usage of MMBaseModem from MMBaseSms
and MMSmsList so that we can test them more easily.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Simplify MMBaseSms (making it easier to use from testcases) by
splitting the AT-specific code into MMSmsAt rather than keeping
it in the base class.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
CBM isn't as complicated as SMS, and the CBM class itself doesn't
need to be overridden by QMI/MBIM/etc. Now that the log parent
and connection binding no longer require MMBaseModem we can flatten
the CBM object creation and remove usage of MMBaseModem.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Continues removing usage of MMBaseModem in a bunch of files
by splitting out bits of its usage to separate interfaces.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Rather than make all of them rely on MMBaseModem for it. This
lets us disentangle dependencies for easier unit testing.
For interfaces, rather than casting directly to MMBaseModem
use intermediate interfaces (MMIfaceAuth and MMIfaceOpLock)
that tests can fake out.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
AT docs for many (most?) Quectel devices state that QPOWD=1 receives
the OK response very quickly but the caller must wait for the
POWERED DOWN URC to avoid data loss. Do that.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
When matching profiles ignore disabled ones. When activating a
specific profile index, return an error if that profile is marked
as disabled.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Previously, a disabled profile would cause Profile Manager interface
enabling to fail because get_profile_settings_ready() returned an
error for disabled profiles.
But 3GPP profile objects already have support for the enable/disabled
setting, so just hook that up and stop returning an error for disabled
ones.
This allows successful initialization of the 3GPP Profile Manager
on devices that contain disabled profiles.
While we're at it, allow creating disabled profiles, and changing
profiles back and forth from enabled<->disabled.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
We want ports to be closed as early as possible; so make sure they
are closed in dispose() which is run explicitly by MMDevice when
cleaning up and removing the modem. Otherwise they could stay
open longer than we want, causing problems for suspend/resume.
This caused problems with suspend because cancelling the
MMBaseModem's cancellable triggered an idle handler that held
a reference to the modem, preventing finalize() from running
until after the suspend code was finished, thus preventing
ports from being closed and cleaned up. Closing them in
dispose() handles this.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
base_modem_invalid_idle() needs to keep a reference to the
MMBaseModem until its done. But if the modem is cancelled during
removal right before we're trying to forget about it, keeping
that reference can prevent everything getting cleaned up by
MMBaseModem's dispose() until after the mainloop has run again
and all our removal operations are supposedly complete.
MMDevice uses an explicit dispose() trigger that mitigates
most of this (and requires it for other reasons, like breaking
reference cycles between the modem and it's various child
classes) but it's somewhat error-prone to keep the modem
around if we don't really need to.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Every use of mm_device_remove_modem() was already trying to cancel the
modem's canellable, so let's just put it there and simplify the callers.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This refreshes operator information after manual registration. QMI and
MBIM implementations return operator info along with registration info
so they handle this easily, while with AT-based devices we must run
additional commands to retrieve that after the manual registration has
finished.
Suggested by: Kirill Buksha <kirill.buksha@axians.rs>
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/971
Signed-off-by: Dan Williams <dan@ioncontrol.co>
When an outgoing call is created and added to the call list its state
is UNKNOWN. The call list emits the ADDED signal which MMIfaceModemVoice
listens for to check whether to begin polling call state.
But since UNKNOWN is not an in-progress call state polling isn't started.
And nothing was rechecking whether to start polling when the call state
changed to something other than UNKNOWN.
Do that so that we can track call progress as it dials out and is
answered.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Dan Williams
Anders Jonsson
Lukas Voegl