ModemManager watching suspend/resume events

[Aleksander Morgado]

On Mon, Jan 12, 2015 at 4:40 PM, Dan Williams <dcbw at redhat.com> wrote:
>>
>> Some MBIM modems will end up getting fully reseted during a
>> suspend/resume cycle, and ModemManager may not be notified by the
>> kernel of the ports being removed/readded. This ends up causing issues
>> because the MBIM session is closed and ModemManager assumes it's open
>> (and we get NotOpened errors).
>>
>> I tried to handle that directly in ModemManager just by trying to
>> reprobe from scratch the modem when we do detect the first NotOpened
>> error, see:
>> https://bugs.freedesktop.org/show_bug.cgi?id=84994
>>
>> The branch has some bugs; but anyway I don't think it's the way to go.
>> Instead of waiting for the first NotOpened error to happen (which may
>> not happen quick enough if the modem is e.g. in Disabled state), we
>> should instead listen for Suspend/Resume events and fully reload
>> modems when that happens (code to do this is already ready in the
>> branch), as we cannot assume that the state of the modem is the same
>> as before the cycle.
>>
>> Comments anyone? Anyone willing to help develop this? :)
>
> We could pull some of the suspend/resume code out of NetworkManager for
> this, which would at least handle systemd and upower.  We'd also need
> separate D-Bus interfaces for suspend/resume or sleep/wake for systems
> that don't use systemd or upower, like embedded ones.  That way people
> can also use scripts to do it if they like.
>

Yes, that would be the best way to go I think. We basically have all
the bits ready in MM and NM, just need to put all together.

> Would it help for ModemManager to do something like the QMI CTL reset or
> some kind of MBIM reset to clear out the old connection on resume?
> Maybe that would help with some of these cases where the device needs
> re-init but MM doesn't know?

Yeah, that's something to consider. I think that MM shouldn't do any
kind of assumption w.r.t. what the MBIM session status is:
 * ModemManager shouldn't assume that the MBIM session is *open* after
a suspend/resume cycle: we need to remove all modems during the
suspend/resume cycle and re-probe them from scratch after that.
 * But also, ModemManager shouldn't assume that the MBIM session is
*closed* after a suspend/resume cycle. So we need to explicitly
request to close any previously available MBIM session before
reprobing, in case they were kept open during the cycle. That second
thing would be equivalent to the CTL Sync command which was the one
reseting all allocated clients in QMI. In MBIM there aren't multiple
clients, so closing the MBIM session should be sufficient to keep the
logic.

-- 
Aleksander
https://aleksander.es