little bit off topic: problem with mm

Dan Williams dcbw at redhat.com
Mon Jan 14 08:58:59 PST 2013


On Mon, 2013-01-14 at 17:05 +0100, Aleksander Morgado wrote:
> On 14/01/13 16:32, Dan Williams wrote:
> > 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.
> 
> Thanks for the clarification, that makes a lot of sense. If the logic
> can be applied to every modem out there; it probably makes sense to put
> it directly in mm_base_modem_organize_ports(), instead of in a plugin.
> Unless we want this hint to be applied before other plugin specific hints...

We can use this with perhaps a 90% confidence level.  If it's
AT-capable, and it has 3 endpoints, then we should use it for PPP
instead of using some AT-capable port that has only 2 endpoints.  I
suggest that it should be set as a *hint* or something so that plugins
can ignore it when they have more specific information (ie, udev rules).

But huawei could replace it's usbif#0 logic with checking this hint
instead.  Plus then we could consolidate the 3GPP and CDMA bits because
this logic holds true for both.

Some caveats:

1) older sierra devices (C885 for example) have *one* USB interface with
like 10 endpoints.  The Sierra driver untangles the endpoint mess and
creates the correct number of serial ports for these.  But this means
that we should only check for 3 endpoints, not more.

2) udev doesn't give us a good way to identify the *type* of the
endpoints (ie, bulk in, bulk out, interrupt), so while doing so would be
nice, in practice you'll never see an AT-capable port that has 3
endpoints that *aren't* bulk in/out + interrupt.

Dan



More information about the libqmi-devel mailing list