little bit off topic: problem with mm

Dan Williams dcbw at redhat.com
Mon Jan 14 07:32:44 PST 2013


On Fri, 2013-01-11 at 10:28 +0100, Aleksander Morgado wrote:
> > 
> > Or alternatively how about something like dcbw/06-endpoints?  The only
> > reason we care about USBIF #0 on Huawei is that they used to always be
> > the modem/PPP interface.  But obviously that's not always true anymore.
> > However, we can be reasonably sure that an interface with only two
> > endpoints is *not* a modem/PPP interface.
> > 
> > In any case, I think something like the patch in the branch ported to
> > git master would be useful for cases where we don't already have
> > explicit modem/PPP port tags for various plugins (especially ZTE), and
> > could be useful for the Huawei bits too.
> > 
> 
> According to the logs usbif#0 in this modem is neither an AT port nor a
> QCDM port; maybe GPS data port? Can we use the number of endpoints
> reliably to filter out ttys which for sure are *not* AT or QCDM?

Not really.  The only thing that # endpoints tells us is whether a given
port is probably not a modem/PPP port.  Usually only one 3-endpoint
AT-capable port will be a modem/PPP port.  The rest will be either
2-endpoint (AT, QCDM, NMEA, etc) or 3-endpoint (usb-storage, QMI,
cdc-ether/ncm).

In this case, if the port isn't an AT port at all, then I thought the
code would use whatever the first available AT port was, as the
modem/PPP or command/status port.  In any case, if we find an AT-capable
port that has 3 endpoints, whatever its port #, it's very likely to be
the modem/PPP port.

> Given that the usbif#0 is no longer what we expected; we should probably
> change that logic completely... right now it will possibly end up
> working (if the previous patch works), but in the worst case we're
> really having a long probing time due to not probing the ports in parallel.

True.

Dan



More information about the libqmi-devel mailing list