Minimizing unsolicited events & wakeups

[Tom Loten]

Appreciate the response Aleksander :)

> Is it that you're building MM without suspend/resume support?
It is built with the suspend/resume support, but I forgot to mention
I'm yanking the tablecloth out via 'echo mem > /sys/power/state'. If I
do it via 'systemctl suspend' MM does indeed teardown & reset things
as expected - so I will need to build it without suspend/resume
support for when I'm doing this properly.

> you should know that a lot of things may happen in the modem while the host is suspended, and you cannot rely on the state known by MM about the modem once the system is resumed, as that state may likely be wrong.
Wouldn't most state-changes in the modem raise an indication? Meaning
the host wakes up, receives the indication and passes it to MM, and
thus MM has a complete picture again.
Or are there some things that are polled, and if MM missed a
transition through a critical state then things go awry?
I imagine it's hard to say, especially with all the devices you're
supporting :) But I do understand what you're getting at, so I will
keep it in mind if/when I come across any issues.

> These are actually polled, and we should allow disabling them, see https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/287
Thanks - that provides some background on the 3 patches I found at
https://source.puri.sm/Librem5/debs/ModemManager/-/merge_requests/21/diffs#diff-content-48234ec1e586754643cc0c206633e95c8efaa86c
I targeted this specific event first as it was noisy and looked like
low-hanging-fruit, but I now see that it wasn't actually causing a
wakeup of the host. However the rationale they mentioned in the issue
is still applicable in my case - keeping the modem idle as much as
possible in order to conserve power. At sleep (even with open
connections) it sits at around 5mA. Waking the modem up to get packet
stats it increases to approx 50mA and remains that way for ~5 seconds
at which the USB bus auto suspends and it enters it's sleep mode
again.

> None of the indications are critical, unless the user applications on top require to know about them.
Thanks, and fair point :) Thankfully this is an embedded system and
the user-applications are also controlled by us. That said, I suspect
that I should provide some level of polling based replacement for
these indications - at least for signal strength anyway.

> Not the same issue, but there are even modems that will crash if those indications sent by the modem while the host is suspended aren't read by the host as the internal buffers in the USB layer of the modem would get full and the modem doesn't know how to react.
I don't think this applies in my case, as the host immediately wakes
up as soon as any USB activity occurs & reads the messages.

Again, thanks very much for the guidance. While I'm not sure any
patches I make can be easily integrated as they are very targeted to
this specific use-case (and in some sense at-odds with the typical MM
user), I will be sure to post them here for reference.

Regards,
Tom