Reducing delay in port probing for MBIM modems

[Aleksander Morgado]

On Thu, Mar 27, 2014 at 5:24 PM, Dan Williams <dcbw at redhat.com> wrote:
> 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.
>

What I have seen in all my tests is that whenever a QMI+AT device
shows up, the QMI and net ports are always exposed first. But I guess
we cannot apply that as a general rule, of course.

> 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.
>

The current codebase doesn't allow adding new ports to an already
created modem object. The 2s aggregation delay tries to cope with that
more or less, and if needed I guess we can tweak that per-device in
the future via udev rules.

> 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.
>

Actually, for QMI devices, if you get a qmi_wwan net port you don't
need just one cdc-wdm port; you need a very specific cdc-wdm port
associated with the net port. Bjorn has a QMI device exposing two net
and two cdc-wdm ports that need to be paired in a very specific way.

> 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.
>

I believe that we should actually allow specific USB interface
tagging, as a way for system builders (i.e. people building their own
systems with mobile broadband support) to make the probing as fast as
possible. If a company is building a system which has modem X and
firmware Y, why not let them specify e.g. which port will be AT and
which port is to be used as primary right away (via udev)? Another
thing, of course, is for a more general use case, we cannot control
all modem models and firmware versions out there, and port probing is
just the safest way.


-- 
Aleksander
https://aleksander.es