AceLan Kao <acelan.kao@xxxxxxxxxxxxx> writes: > [ 4.042629] usb 2-8.1: new full-speed USB device number 9 using xhci_hcd [..] > [ 4.095722] usb 2-8.1: not running at top speed; connect to a high speed hub This is a bit odd, isn't it? Not related to the serial driver question, though. [..] > [ 4.096989] usb 2-8.1: config 1 has an invalid interface number: 12 but max is 4 > [ 4.096993] usb 2-8.1: config 1 has an invalid interface number: 13 but max is 4 > [ 4.096996] usb 2-8.1: config 1 has an invalid interface number: 13 but max is 4 > [ 4.096998] usb 2-8.1: config 1 has no interface number 1 > [ 4.097000] usb 2-8.1: config 1 has no interface number 4 Yes, typical for how Sierra does this: Interface numbers 12 and 13 are used for MBIM, leaving lots of holes in a 5 interface configuration. > [ 4.099386] usb 2-8.1: New USB device found, idVendor=413c, idProduct=81a9 > [ 4.099390] usb 2-8.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 4.099393] usb 2-8.1: Product: Dell Wireless 5808e Gobi\xffffffe2\xffffff84\xffffffa2\xffffff84\xffffffa2 4G LTE Mobile Broadband Card > [ 4.099395] usb 2-8.1: Manufacturer: Sierra Wireless, Incorporated [..] > [ 4.364597] cdc_mbim 2-8.1:1.12: cdc-wdm0: USB WDM device > [ 4.364764] cdc_mbim 2-8.1:1.12 wwan0: register 'cdc_mbim' at usb-0000:00:14.0-8.1, CDC MBIM, 46:10:e8:c3:a2:02 So the MBIM driver leads the race, making this actually work in this case. But I don't think the "sierra" serial driver looks at class codes, and it definitely does not blacklist interface 12 and 13, so it would probably happily have bound to interface 13 if it won the race. > [ 5.940610] usbcore: registered new interface driver usbserial > [ 5.940628] usbcore: registered new interface driver usbserial_generic > [ 5.940642] usbserial: USB Serial support registered for generic > [ 5.942641] usbcore: registered new interface driver sierra > [ 5.942655] usbserial: USB Serial support registered for Sierra USB modem > [ 5.942682] sierra 2-8.1:1.2: Sierra USB modem converter detected > [ 5.946191] usb 2-8.1: Sierra USB modem converter now attached to ttyUSB0 > [ 5.946214] sierra 2-8.1:1.3: Sierra USB modem converter detected > [ 5.946577] usb 2-8.1: Sierra USB modem converter now attached to ttyUSB2 > [ 5.946593] sierra 2-8.1:1.0: Sierra USB modem converter detected > [ 5.947277] usb 2-8.1: Sierra USB modem converter now attached to ttyUSB3 OK, this looks like it works without any 5 second timeout. Which I guess means that the driver can be used, provided the entry is limited to vendor specific interfaces and using the blacklist. But is this the most "correct" driver? I don't know... The pattern using ff/ff/ff class interfaces for these functions is common to many Qualcomm based Sierra Wireless devices: 0: QC Device Management 2: NMEA 3: Modem Some of these have been added to qcserial, some to option and some are probably somewhere else. I have a couple of new devices in this cathegory on "todo" list already. Maybe it's time for a serial minidriver explicitly for these devices, moving them all there? That would simplify the entries a lot. > Bus 002 Device 009: ID 413c:81a9 Dell Computer Corp. > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x413c Dell Computer Corp. > idProduct 0x81a9 > bcdDevice 0.06 > iManufacturer 1 Sierra Wireless, Incorporated > iProduct 2 Dell Wireless 5808e Gobi™ 4G LTE Mobile Broadband Card > iSerial 3 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 247 > bNumInterfaces 5 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xe0 > Self Powered > Remote Wakeup > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 OK, so that's ff/00/00 instead of ff/ff/ff. Something to be aware of if we try to match on class. For the record: The Sierra Wireless MC7710 has ff/ff/ff serial functions. > ** UNRECOGNIZED: 05 24 00 10 01 > ** UNRECOGNIZED: 05 24 01 00 00 > ** UNRECOGNIZED: 04 24 02 02 > ** UNRECOGNIZED: 05 24 06 00 00 We are probably better off continuing to ignore these descriptors, but they are somewhat typical to Qualcomm serial functions. You'll recognise typical CDC functional descriptors for an ACM fucntion: header - CDC ver 1.10 call management - no caps, data interface = 0 acm - CDC_CAP_LINE union - master interface = 0, slave interface = 0 but do note that the call management and union descriptors are completely misleading. Interface #0 belongs to another function. Which I believe says it all. These descriptors are probably not used by anything on any system. > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 12 > bInterfaceCount 2 > bFunctionClass 2 Communications > bFunctionSubClass 14 > bFunctionProtocol 0 > iFunction 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 12 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 14 > bInterfaceProtocol 0 > iInterface 0 > CDC Header: > bcdCDC 1.10 > CDC MBIM: > bcdMBIMVersion 1.00 > wMaxControlMessage 4096 > bNumberFilters 16 > bMaxFilterSize 128 > wMaxSegmentSize 4064 > bmNetworkCapabilities 0x20 > 8-byte ntb input size > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x86 EP 6 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 32 Another typical Sierra firmware bug, which we do have a generic workaround for: The union descriptor is mandatory for a MBIM function. It's missing here. So we use the IAD instead. <rant> It's sort of fascinating that such a stupid and pointless firmware bug isn't detected and corrected during early testing. And even more so that it still appears in new firmwares more than a year after it was first reported by an end user. It is quite obvious that firmwaere bug reports go to /dev/null and that the only testing that's every done is something like "Does it work with Windows8?". And I guess Windows looks only at the IAD. This tells us what kind of spec conformance we can expect. </rant> > ** UNRECOGNIZED: 2c ff 42 49 53 54 00 01 07 f5 40 f6 00 00 00 00 01 f7 c4 09 02 f8 c4 09 03 f9 88 13 04 fa 10 27 05 fb 10 27 06 fc c4 09 07 fd c4 09 Strange. I believe I've seen this before, but I don't know what it is. Is 0xff a valid descriptor type? Vendor specific? It starts with the string 'BIST'. The rest is gibberish to me. > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 Putting interface #0 at the end is also something typical for Sierra devices. Weird but probably OK. Note that this serial interface (which I assume is talking QCDM) use ff/ff/ff class codes. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
