mbim-proxy listening to systemd suspend/resume events

[Aleksander Morgado]

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?

I also thought about the udev tags as the last option. Before
resorting to that, though, we could attempt to detect the state of the
modem after a suspend/resume cycle. E.g. just upon resume, we attempt
to contact the modem using the control channels that we had open, and
if they work we check the status of the connection if it was up before
the suspend. And if the modem doesn't reply at all, we directly assume
we need to mark the modem object as invalid and reprobe from scratch.
Don't know, something like that; I'm sure there will be corner cases
to handle in the different devices, but at least that could give us a
good start.

And if we still need the udev tags, we could use them to "force"
assuming the modems need to be reprobed always, e.g. to trigger the
MBIM channel close in the Cinterion device that may crash when too
many indications get buffered in the device side.

-- 
Aleksander
https://aleksander.es