AceLan Kao <acelan.kao@xxxxxxxxxxxxx> writes:
> Hi,
>
> I'm not an expert of this field, so I can't really understand your reply.
> So, is the patch is acceptable?
>
> And I have another pci modem card with id 413c:81a3.
> I tried to add its id into sierra driver, but no luck.
I still don't think the sierra driver is correct for these devices. But
the reason you have no success is because cfg #2 of this device has no
serial functions at all. It's a MBIM only config. More (very technical)
details follow...
> Here are the logs, could you also take a look of it?
[..]
> [ 2.924414] usb 1-1.8.3: new high-speed USB device number 7 using ehci-pci
> [ 2.928390] Switched to clocksource tsc
> [ 3.028854] usb 1-1.8.3: config 1 has an invalid interface number: 8 but max is 3
> [ 3.028859] usb 1-1.8.3: config 1 has no interface number 1
many modern Sierra Wireless devices use fixed interface numbers to
identify different function types. They do this both for vendor
specific functions and for class functions. The lsusb output will show
the same, but we can figure out lots of stuff based on the two lines
above:
- "max is 3" => there are 4 interfaces in total in cfg #1
- "invalid interface number: 8" => one of them is numbered '8'.
- "no interface number 1" => interfaces 0, 2 and 3 exists
So this is a typical Sierra QMI config, with 3 serial funcions and one
network function:
0: QCDM
2: NMEA (Qualcomm)
3: AT + PPP modem
8: QMI/wwan
These interfaces all use ff/ff/ff class codes, so we have to look at the
interface numbers to tell them apart.
We've (well, OK "I have". My fault...) previously added a number of
similar devices to the qcserial driver, using 3 lines per device and the
USB_DEVICE_INTERFACE_NUMBER to match only the serial functions. This
works, but having 3 matching entries per device doesn't really scale too
well. Sierra are obviously selling these designs to vendors using their
own device IDs, so we must expect the number of such entries to grow.
I guess we should create a probe explicitly for this type of device?
Maybe just extend the qcserial driver with a "sierra" device type in
addition to the gobi1k and gobi2k types?
> [ 3.029353] usb 1-1.8.3: config 2 has an invalid interface number: 12 but max is 1
> [ 3.029358] usb 1-1.8.3: config 2 has an invalid interface number: 13 but max is 1
> [ 3.029361] usb 1-1.8.3: config 2 has an invalid interface number: 13 but max is 1
> [ 3.029363] usb 1-1.8.3: config 2 has no interface number 0
> [ 3.029364] usb 1-1.8.3: config 2 has no interface number 1
And this device has a 2nd configuration with only 2 interfaces, number
12 and 13. Sierra use these numbers for MBIM control and data
interfaces.
This will be the default configuration in Linux because the first
interface (number 12) has a proper class (CDC MBIM), while the first
interface of configuration #1 is vendor specific. This default can be a
bit surprising. Especially the fact that it isn't tied to the
availability of a class driver, and we do have quite a few kernel
releases where there are drivers for cfg #1 but not for cfg#2. But this
device shows why the policy is sane: Each new device ID must be added to
the vendor specific drivers before they can work, while the class driver
just works even if we've never heard of this device before:
> [ 11.141019] cdc_mbim 1-1.8.3:2.12: cdc-wdm1: USB WDM device
> [ 11.141208] cdc_mbim 1-1.8.3:2.12 wwan0: register 'cdc_mbim' at usb-0000:00:1d.0-1.8.3, CDC MBIM, ba:e1:96:a8:eb:2f
So everything is fine :-)
Not really. We should update the vendor specific drivers as well to
allow users to choose serial + QMI instead of MBIM. That means qmi_wwan
and *some* serial driver. But the vendor specific drivers still won't
be used by default for this device unless you create an udev rule.
Example only - I'm no udev expert:
ATTR{idVendor}=="413c",ATTR{idProduct}=="81a3",ATTR{bConfigurationValue}=="2" ATTR{bConfigurationValue}="1"
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
