mbim-proxy listening to systemd suspend/resume events

[Dan Williams]

On Fri, 2020-09-18 at 19:30 +0200, Aleksander Morgado wrote:
> Hey,
> 
> > > > From a device point of view, the application asks for
> > > > notifications, and
> > > > then doesn't read them.
> > > > It is forced to buffer them, and the buffer is limited.
> > > 
> > > The device knows the USB connection is suspended.  It should not
> > > attempt
> > > to send any USB data when this happens.  This is the same on the
> > > host
> > > side.  We kill URBs before suspending.
> > > 
> > > There is no obligation to buffer everything on the device.  That
> > > would
> > > not scale at all. The device can and should drop anything it
> > > cannot
> > > deliver in a timely manner, whether that is a notification for
> > > the host
> > > or incoming data packets from the network.
> > > 
> > 
> > Yes, I do agree that the device firmware should be robust enough to
> > handle this, and this has also been my suggestion when I learned
> > about
> > this issue. The device should be able to handle this nicely, not
> > rely
> > on the host requiring the MBIM session close.
> > 
> > As with MM's own suspend/resume logic, it's really optional at
> > build
> > time, and if there are systems that require to keep open TCP
> > sessions
> > during suspend, this can be disabled. Don't take me wrong, I
> > totally
> > understand your point regarding the open TCP sessions, but if we
> > were
> > to support that I would first focus on doing it at MM level in a
> > generic way.
> 
> I've changed my mind a bit over the past days (thanks Bjørn for your
> point of view!), and now I think that we should probably try to
> handle
> the suspend/resume logic more gracefully in ModemManager. Whenever
> possible, we should try to keep the ongoing connection up and
> therefore not explicitly disconnect and disable the modem. I have no
> idea how clean that would be for all usecases that we need to
> consider
> though; e.g. the modem may be externally powered and therefore kept
> on, or the modem may also get suspended or even powered off... I'll
> try to work on this in this next MM dev cycle.

It's really a per-modem toggle but unfortunately there's nothing in the
kernel I can think of that tells us whether the modem (a) keeps power
over suspend and (b) the hardware/firmware/driver can handle re-
handshake of the data pipe (eg USB, PCI, serial, etc) across
suspend/resume.

eg, many modem dev boards (eg external PCIe/M.2 to USB dev kits) are
externally powered but there's no way to know that automatically.

Options I see are per-connection toggle (which I don't really like
since it's really per-modem) or maybe udev/etc tagging of the modem
object by the system integrator?
Dan

> So, I don't think we should be merging this MR as it is for the time
> being. I'd like to investigate a bit more about the MM use case, and
> then suggest the way forward for libmbim again here in the mailing
> list.
>