Re: [MM] [PATCH 2/5] novatel: Use the ALLOWED_SINGLE_AT property. Saves 5 seconds on probing.



Dan Williams <dcbw redhat com> writes:

> On Sat, 2012-05-05 at 10:41 +0200, Bjørn Mork wrote:
>> Dan Williams <dcbw redhat com> writes:
>> 
>> > Port layout of the Novatel 551L (LTE Band 13 device similar to the E362
>> > this Nathan's plugin targets, but USB instead of PCI-E minicard) is as
>> > follows:
>> >
>> > 0: AT commands
>> > 1: DM
>> > 2: another DM
>> > 3: unknown (probably QMI; doesn't respond to $GPS_START)
>> > 4/5: CDC Ether
>> >
>> > Odd that we have two DM ports. If Intf3 is really QMI then we should
>> > make sure it's blacklisted in 'option' so we don't have to do
>> > serial-related junk with it.
>> 
>> what sort of endpoins does interface 3 have?  Is the 4/5 configured as a
>
> FF/FF/FF, bulk in+out, no interrupt

Then it certainly isn't the "QMI embedded in CDC" that we have been
seeing so far.  It could of course still be QMI in some other wrapping,
but is that likely?

>> standard CDC Ether class interface set with the appropriate CDC
>> functional descriptors and class codes?  I assume it's configured using
>> either AT commands or DM?
>
> Yeah, standard CDC Ether, recognized fine by the kernel (but needs a
> quirk for FLAG_WWAN).  AT commands set up the connection and then DHCP
> is used to obtain IP addresses.
>
>> I wonder... QMI could also be embedded in the CDC Ether control
>> interface.  But then you should see "CDC: unexpected notification 01!"
>> messages from time to time from cdc_ether, assuming that the device
>> sends unsolicited indications.  Most (all?) QMI devices seem to do that.
>> They send a QMI_CTL SYNC indication during startup at the very least.
>
> I'll take a look, thanks for the suggestion.  The #5 CDC Data interface
> does have an additional:
>
>         ** UNRECOGNIZED:  2c ff 42 49 53 54 00 01 07 06 40 00 00 00 00
> 00 01 07 f4 01 02 08 f4 01 03 09 88 13 04 0a 10 27 05 0b 10 27 06 0c f4
> 01 07 0d f4 01

Weird.  I've never actually made it through all of the CDC class specs,
but I believe there shouldn't ever be any extra descriptors on the data
interface, should there?  And I didn't think FF was a valid descriptor
type either.  Vendor-specific?  But how to you interpret that when you
don't even know whether it describes endpoint, interface or device?



Bjørn


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]