On Thu, 2012-05-17 at 00:01 +0200, Bjørn Mork wrote:
> Olli Helin <olli.helin@xxxxxx> writes:
>
> >>
> >> Nevermind, I found some drivers for it. It does indeed appear to be a
> >> Gobi-derived device, as you've found from the CodeAurora drivers. It
> >> should be driven by qcserial and qmi_wwan. Can you grab 'lsusb -v -d
> >> 1c9e:9801' after modeswitch for me? We need to find out what class of
> >> gobi it is.
> >>
> >> The rough mapping between codeaurora drivers and the upstream is:
> >>
> >> QCUSBNet = qmi_wwan
> >> QCSerial = qcserial
> >>
> >> Dan
> >>
> >
> > What is the reason that Gobi-derived devices should never be used with
> > the option driver? Is there some kind of a risk of hickup, speed
> > problems or what? I'll try the qcserial later to see if the modem
> > works with it also.
>
> I believe the main reason is that it will bind to the correct serial
> interfaces and nothing else, while the option driver will bind to almost
> anything - including any QMI/wwan interface.
>
> > bNumInterfaces 6
>
> But that won't work with qcserial. It requires bNumInterfaces to be 1, 3
> or 4. So use option, but make sure to blacklist the interface used for
> QMI/wwan. I'm guessing that's interface #3, but please test.
>
> Hmm, maybe the qcserial driver should disregard any storage interfaces
> when counting interfaces? Seems like a number of these devices come
> with both a card reader and driver CD enabled in modem mode as well.
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.
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. 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.
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.
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.
So the decision tree is something like this:
A) Is the USB interface a standard CDC-ACM/CDC-ETHER/CDC-WDM/CDC-NCM?
1) yes: let the standard drivers handle it: DONE
2) no: go to B
B) Is the device a plain rebranded Gobi device?
1) yes: AT/DIAG/NMEA interfaces -> qcserial, QMI -> qmi_wwan: DONE
2) no: go to C
C) What protocol does the interface speak?
1) AT/DIAG/CnS/NMEA/WMC: go to D
2) QMI: go to F
D) What vendor is the device from?
1) Sierra: use 'sierra' and 'sierra_net': DONE
2) Option NV: use 'hso' unless it's really old: DONE
3) Old Motorola phones: use 'moto-modem'
4) go to E
E) Is the device Qualcomm-based and exposes a CDC-ACM interface, but
this interface is *not* a CDC-ACM interface?
1) yes: use 'qcaux': DONE
2) no: go to G
F) The interface is QMI, not a standard CDC-ACM interface, and not a
plain Gobi device. Figure out how to add it to the qmi_wwan driver,
like we did for the Pantech UML290. DONE
G) The interface talks a serial-based protocol (AT/DIAG/CnS/NMEA/WMC)
and doesn't have a vendor-specific driver, so yes, it might have to live
in 'option'. But some interfaces don't like what option does (often
unknown interfaces on ZTE devices that may be DIAG or network
interfaces) and we may have to move them later when we find out what
kind of interface it really is. DONE
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#)
Dan
--
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
