Faster resume probing

[Aleksander Morgado]

Hey Dylan,

> > > So with these your modem always stays connected over USB? How does
> > > ModemManager react to this when resuming/suspending? ModemManager
> > > still reprobes the device right?
> > Yes, the modem remains connected over USB, even over many
> > suspend/resume cycles. MM doesn't reprobe upon resume. My
> > understanding is that MM is completely unaware that a suspend/resume
> > has occurred - hence it doesn't feel the need to reprobe upon resume.
> > On your PinePhone, when it comes out of suspend does the USB system
> > re-enumerate the modem? (e.g. do you get the USB device connected &
> > qmi/option driver kernel messages, or a message like 'usb1-1: reset
> > full speed device...'). If so, then I'd look into that first.
> >
>
> Well, I disabled suspend/resume hooks in ModemManager and upgraded to
> the master branch. Besides that, I also use the master branch of eg25-
> manager (a daemon specific for the EG25-G modem enabling, suspend
> handling, etc.)[1].
>
> Now calls are working immediately when waking up for suspend :O
> The call URCs are coming in for ModemManager and are processed.
>

Nice!

> However, text messages are ignored in suspend. The device wakes up but
> ModemManager doesn't fetch the latest text messages.

You disabled suspend/resume monitoring, so MM wouldn't know when to
reload the incoming text messages, if that's something we should be
doing. Is the host awaken when the new SMS arrives, even if MM doesn't
re-read the full list of SMS? Or is the host not even awaken in this
case?

> If you restart
> ModemManager or reboot, the ignored text messages are coming through.
> Text messages received when awake are properly processed though.
> Text messages are retrieved over QMI instead of AT.
>

The restart of MM will trigger a full reading of the whole list of
SMS, so that makes sense, yes.

> Currently, it's a bit vague for me how this can be solved.

I assume this merge request goes in line of trying to fix this, right?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/433

I replied there some comments about the approach taken; in short, I
don't think we should blindly replace the whole WMS based logic to use
the AT based SMS management in all Quectel modems, that's a bit
overkill :D

I think we need to understand why, in the case of suspend/resume cycle
and using only QMI, we're not receiving and processing the WMS
indications properly:
 * As said above, does the host even awake when the SMS arrives and
we're using QMI?
 * Is it any different (host awaking) when using AT?
 * Or is it that when using AT the URCs are queued in the modem and
once the host is awake later on we end up reading them correctly? And
if so, why is this not happening in the same way with QMI?

On the host-sleep modem-awake usecase, my understanding is that QMI
indication messages would be queued in the modem until the host reads
them. I don't know how many can be queued or whether the modem has any
logic to clean them up or something. The only recent case I've worked
on similar to that was with a Cinterion MBIM-based modem, which would
crash if the MBIM channel wasn't explicitly closed before going to
suspend because (it seems) the internal buffer in the modem would get
full as the host didn't read the MBIM indications, and the modem would
crash. That is why we should understand the setup before moving
forward with other changes like the one you're suggesting, because we
may be putting a workaround somewhere instead of something that could
be fixed in some other way.

@Bjørn Mork @Giacinto Cifelli @Dan Williams do you have any experience
with this kind of setup (host sleep, modem awake, MM without
suspend/resume monitoring) with QMI modems?

-- 
Aleksander
https://aleksander.es