ModemManager watching suspend/resume events

[Dan Williams]

On Sun, 2015-01-11 at 19:56 +0100, Aleksander Morgado wrote:
> Hey,
> 
> 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.

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?

Dan