Reducing delay in port probing for MBIM modems

[Ben Chan]

> While I can't comment on the MBIM part, for
> mm_plugin_manager_find_device_support() I think the issue is this...
>
> When devices get exposed by the kernel and then udev is variable due to
> driver initialization time, udev rules, etc.  So it may well be that one
> port shows up 5 seconds before another port, and that probing could
> complete within that time.  And then the other port shows up, but we've
> already exported the modem to D-Bus and clients have (potentially)
> started using it.  So we're left with a dangling port that we should be
> using, but can't.
>
> (if it's an AT port then it's easier to handle later.  But if a net or
> QMI port shows up long after the AT port has been probed and the modem
> created, then we can't use the net port because we may have created a
> completely different object for the modem already)
>
> The pathological case: a quick-responding AT port and a net/QMI/MBIM
> port that takes a second or two to show up.  If we eliminate the 2s
> aggregation delay, it's quite possible that the AT port gets probed and
> a Generic modem created before ModemManager is even notified of the
> net/QMI/MBIM port by udev.  Then we're stuck with a Generic modem when
> it should be a QMI or a Huawei-with-net-device.
>
> Obviously we can and should do better to reduce probing time.  I think a
> strategy could be that if we know the minimal useful port setup for a
> device, then we should just create and expose the modem with those
> ports, and let other ports (NMEA, secondary AT, etc) show up later
> because they aren't critical to the modem object.  Some of this is
> already implicitly encoded, but we could  make it more explicit.
>
> For example, if we get a qmi_wwan net port, we know we need
> one-and-only-one WDM port before the modem is complete.  And we could
> mostly assume that whatever WDM port we get will be a QMI port, and when
> we have it, modem probing is complete and the modem can be created.  The
> same thing might work for MBIM, except there could be multiple WDM and
> multiple net ports for these devices in the future.
>
> In addition, specific devices could be tagged with minimal port setup I
> suppose, but only for devices we *know* are singular.  I don't mean
> specific USB interface tagging, but "Novatel E362 is a known quantity
> and we expect only WDM+QMI" type stuff.
>
> Last question: is the delay that's hurting you the port *detection*
> (waiting until sufficient ports have been found by udev), or the port
> *probing* (determining the protocol each of those ports actually use)?
>
> Thoughts?
> Dan
>

Dan,

Thanks for the detailed write-up, which provides a lot of insights!

I'd certainly like to optimize both port "detection" and "probing" :)
The goal is to bring the system online as soon as possible in the
following scenarios:

1. The modem is booting up after the kernel and ModemManager are
running. This happens after a cold system boot or after a S3
suspend/resume cycle if the modem power is cut during suspend.

2. The kernel and ModemManager are starting after the modem is already
running. This happens after a warm system reboot or after a S3
suspend/resume cycle while the modem remains powered.

3. The Modem is already running, and then ModemManager restarts (e.g.
after a crash).

The pathological case you mentioned could happen in (1) and (2), but
not (3). For modems with only a single control port (AT or MBIM), we
can avoid the minimum port probing delay for (1) and (2) as well.