On Fri, 2012-05-18 at 10:06 +0200, Bjørn Mork wrote:
> 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?
The drivers should be more flexible, and thanks for posting that patch.
The problem with Option right now is that it *doesn't* allow matching on
interface number, and thus it prevents finer-grained driver matching.
Like you say, it's mostly about protocol. If the interface talks a
serial protocol, and it can handle the setup packets that option sends,
and it's not covered already by Sierra or HSO or whatever, then yes
option works.
> > 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:
I said "usually" :) And that may not include QMI-based devices, but it
does depend on the specifics. Does the MC7710 support TruInstall? (I'd
guess not). Does it support the custom Sierra power state stuff? Does
it support the custom NMEA port setup stuff? If the 7710 doesn't
support this stuff, then it perhaps shouldn't go into sierra.
But really, how standard is the option_send_setup() stuff anyway?
Sierra sends the same setup packet too. Is *that* the thing the 7710
doesn't like, or is it the custom Sierra power state or NMEA stuff?
> 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).
That would be great. The more we know the better.
> 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.
Thankfully.
> > 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...
My point above was also that if it supports HIP/CnS then we need to add
*some* interfaces to sierra/sierra_net. I don't know if it does. But
it would be nice to find out. Maybe the DirectIP/HIP/CnS devices also
support QMI without the QMI-based ether port too :) In which case what
driver should handle *that* interface?
> And then there are the other (non-default) QMI modes, having more
> interfaces and therefore making qcserial fail completely.
qcserial should only really be for plain Gobi devices; many
manufacturers rebrand Gobis or change the IDs. Up until very recently
the only Gobi devices we had were really plain Gobis. And clearly those
should probably be driven by qcserial/qmi_wwan.
But QMI is not really a serial protocol. I don't think we should be
driving QMI ports with option, unless the firmware has been hacked up to
layer QMI over serial somehow. QMI doesn't care about serial port setup
stuff, DTR, whatever, that 'option' does. It doesn't really have any
framing, so it can't really be used like a serial link; instead it
relies on the USB transfer specifics, at least for USB. Yes, QMI can
also be used over other transports like SMD and SDIO, but those aren't
serial either.
> 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.
Fully agreed. The problem is that besides qmi_wwan we don't have a pure
QMI driver yet; if an interface is just QMI (do we have any of these?)
and not also a cdc-wdm port, what do we do with it? Can qmi_wwan still
drive it?
> > 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.
Again, the main problem is that people just dump stuff into option, and
that's not always right. It always depends on the protocol of the
interface and the specifics of the device.
> > 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.
Clearly. It's never foolproof to assume things based on the driver, but
up until now that's worked fairly well. But with the proliferation of
devices and interface combinations, it's clear that if you want any
random device to Just Work you need some sort of probing to figure out
what protocol that port speaks. Obviously if we have something driven
by qmi_wwan, we can talk QMI to it. But for 'option' or 'sierra' or
'qcserial' all bets are off, but at least we can use those as hints to
optimize the setup time. If it's driven by qcserial then we're not
going to ask it whether it speaks WMC or LG-600 for example.
The rules for detecting what protocol an interface speaks are
complicated and putting devices into the right driver helps make things
faster by quite a bit.
> 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.
As Greg said, it really hasn't been. I don't think we've really had a
need for this until I started expanding the option driver blacklist to
ensure that interfaces that weren't actually serial interfaces were
dropped by option.
> 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.
Thanks again for the patch on this.
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
