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