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 _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel