Dan Williams <dcbw@xxxxxxxxxx> writes: > People just want their stuff to work, so they add IDs to 'option' > because that's what they've always done for modems. > > But that's not right. The name 'option' was chosen because the driver > was originally for Option NV devices from 5 years ago. It uses specific > protocol constructs that may or may not actually work with other > devices. In fact they often don't work with other devices: see the > SENDSETUP quirk in option. People just kept adding IDs because it > mostly worked. Well, it still mostly works to a degree that it is fully usable. So people will continue to add their 3-4-5G modems to it, unless there is an obviously better alternative. And quite frankly, I do not know what other option (ehhhm..) there is if we want to support the serial ports on non-Gobi QMI devices like the Huawei stuff. The additional usb-storage class interfaces they expose in modem mode will prevent the current qcserial from being used. Should that driver be more flexible, only binding to the known serial interfaces 1, 2 and 3, but allowing more than 4 interfaces in total for the device? Or should we make another usb-serial driver such devices? Or do such a driver already exist? > But we split things into separate drivers for a few reasons: > > 1) protocol: a QMI-speaking USB interface isn't really a serial device. > It doesn't care about baudrate, XON/XOFF, stopbits, etc. It just > expects a full QMUX frame in each USB packet. So this interface should > be driven by a driver that doesn't do any serial junk. > > AT commands and DIAG *are* serial-based protocols and they do often > accept serial setup commands. So USB interfaces that talk these > protocols may be driven by option or some other driver. > > 2) vendor: but Sierra Wireless devices should usually be driven by the > 'sierra' driver, since these devices have some special setup. Actually, I am not all that convinced that this is necessarily true for the QMI speaking Sierra Wireless devices. The MC7710 does not like the additional setup packets at all, resulting in an unwanted 5 second pause in probing the first serial port: May 18 08:45:23 nemi kernel: [125405.116123] usb 2-4: new high-speed USB device number 26 using ehci_hcd May 18 08:45:23 nemi kernel: [125405.250519] usb 2-4: config 1 has an invalid interface number: 8 but max is 3 May 18 08:45:23 nemi kernel: [125405.250531] usb 2-4: config 1 has no interface number 1 May 18 08:45:23 nemi kernel: [125405.252669] usb 2-4: New USB device found, idVendor=1199, idProduct=68a2 May 18 08:45:23 nemi kernel: [125405.252681] usb 2-4: New USB device strings: Mfr=3, Product=2, SerialNumber=4 May 18 08:45:23 nemi kernel: [125405.252687] usb 2-4: Product: MC7710 May 18 08:45:23 nemi kernel: [125405.252693] usb 2-4: Manufacturer: Sierra Wireless, Incorporated May 18 08:45:23 nemi kernel: [125405.252703] usb 2-4: SerialNumber: 3581780400xxxxx May 18 08:45:23 nemi kernel: [125405.254445] sierra 2-4:1.0: Sierra USB modem converter detected May 18 08:45:28 nemi kernel: [125410.252489] usb 2-4: Sierra USB modem converter now attached to ttyUSB0 May 18 08:45:28 nemi kernel: [125410.252750] sierra 2-4:1.2: Sierra USB modem converter detected May 18 08:45:28 nemi kernel: [125410.253273] usb 2-4: Sierra USB modem converter now attached to ttyUSB1 May 18 08:45:28 nemi kernel: [125410.253495] sierra 2-4:1.3: Sierra USB modem converter detected May 18 08:45:28 nemi kernel: [125410.254020] usb 2-4: Sierra USB modem converter now attached to ttyUSB2 May 18 08:45:28 nemi kernel: [125410.257069] qmi_wwan 2-4:1.8: cdc-wdm0: USB WDM device May 18 08:45:28 nemi kernel: [125410.259237] qmi_wwan 2-4:1.8: wwan0: register 'qmi_wwan' at usb-0000:00:1d.7-4, Sierra Wireless wwan/QMI device, 8a:c6:82:04:84:7a I'm planning on researching this a bit more before proposing anything, but I do suspect that the sierra driver is just plain wrong for this device ("device" as in 1199:68a2, implying QMI mode). The sierra driver is probably correct for the same card in Direct IP mode, but that is no problem as Sierra Wireless use distinct device IDs for these different modes. > Some of > their USB interfaces are also driven by sierra_net on newer devices. Of > course, if it's a Sierra-branded device that is actually a Gobi device > and isn't customized by Sierra at all, then it's a Gobi and should be > handled by qcserial and qmi_wwan. I am not convinced about this either. The default interface layout of the MC7710 in QMI mode is as shown above: ifs# 0, 2 and 3 are serial ports (DM, NMEA and AT) while if#8 is QMI/wwan. Note the number on the DM interface! qcserial won't handle this... And then there are the other (non-default) QMI modes, having more interfaces and therefore making qcserial fail completely. I do not think qcserial is suitable for any non-Gobi device. We need to be aware that QMI support does not equal Gobi. I am sure Qualcomm can say a lot more about this, but "Gobi" is a set of design rules making the device layout consistent. You do not have to follow these just because you use a Qualcomm chipset. Some vendors (e.g. Huawei and Sierra Wireless) have both Gobi and non-Gobi devices with QMI. > Newer Option NV devices should be driven by 'hso' because they also have > some custom stuff that needs to be done. 'hso' drives both the serial > interfaces and the network interface. Even though the device is made by > Option, it doesn't get driven by the 'option' driver. Sure. Driver names have historical reasons and choosing the correct name for the future is difficult. The qmi_wwan driver could easily have ended up as "huawei_wwan" as the first supported device was a Huawei device... So we just have to learn that "option" driver do not imply "Option" device and vice versa. > 3) detection: the driver bound to a device gives some indication of what > protocols it supports, which helps userspace figure out how to talk to > the device. If it's driven by qcserial/qmi_wwan then we have a pretty > good idea that it's a Gobi device and we should talk to it via QMI. > That saves userspace from duplicating all the work we put into the > kernel module device tables and makes adding support for newer devices > faster to various userspace stuff. If it's driven by 'sierra' we know > we should use AT*CNTI=0 to get the current access technology instead of > AT+ZPAS or AT^SYSINFO or AT+PSRAT. Maybe... The thing is that you have an interface between your userspace app and the device (AT commands over ttyUSBx) and an interface between the driver and USB device (a collection of USB endpoints and some setup protocol). And these two software interfaces aren't necessarily as connected as you assume above. Sierra Wireless devices will support AT*CNTI=0 because they use Sierra's nice AT interpreter, but they may not always support the serial port setup protocol used by the "sierra" driver. And the driver doesn't know anything about AT commands at all, so it will not care that both devices support the same AT command set. If the setup protocol is different, then the driver need to be different. So you can assume "sierra driver" => "AT*CNTI=0 support", but not the other way round. > D) What vendor is the device from? > 1) Sierra: use 'sierra' and 'sierra_net': DONE That will only work for the "Direct IP" devices from Sierra, which judging on the device table in sierra_net is a single vid:pid. > ASIDE: we really need USB interface # matching in the module device > tables too. 'option' is a sledgehammer where often only 2 or the > modem's ports should be driven by option, and others aren't actually > serial interfaces or are network interfaces that we haven't figured out > how to talk to yet. These completely different interfaces often have > the same class/subclass/protocol and thus option tries to claim them > all. We need something like: > > USB_DEVICE_INTERFACE_NUM_INFO(vid, pid, class, subclass, proto, intf#) Yes! Being a newbie around here I wonder if this has been discussed and refused before? If so, a pointer to the discussion would be appreciated. Looking at the Windows drivers for all these devices, it is quite obvious that the designers assume driver matching based on fixed interface numbers. Not being able to do that in Linux is a problem, which can easily be seen by all the workarounds in a number of drivers. A typical probe function will have to consult a blacklist and/or whitelist of interface numbers or descriptor layouts it can support. Moving at least the interface numbers into the device ID table would simplify a number of drivers and avoid unnecessary probing of unsupported interfaces. It would of course be much better if every vendor specific interface had a meaningful subclass/protocol, but that won't happen as long as Windows matches just fine on interface number. 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