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
