On Wed, 2012-01-25 at 08:10 -0800, Marcel Holtmann wrote: > Hi Bjorn, > > > >> Also you may not have seen, but the QUIC codeaurora people pushed a new > > >> rmnet USB driver to their MSM kernel tree: > > >> > > >> https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commit;h=37c35e4ee5226099374a1a1eda637d0f26fc023d > > > > > > Thanks for the pointer. Will take a look at it. But I guess these are > > > still doing the integrated QMI approach. Which most likely isn't > > > acceptable to anyone here, after you managed to convince me :-) > > > > Looked at it, and I believe I've seen most of it before. It does > > support the IP mode, which is nice. But that depends on the core > > ARPHRD_RAWIP changes. And the driver uses netdev ioctls to switch > > modes. BTW, it also supports a "QMI QOS header" mode, which obviously > > adds some QoS header to the outgoing packets. > > > > The driver exports the full QMI interface to userspace using a new > > character device in its own class, and it also exports one driver > > control command using sysfs and some stats using debugfs. I like > > that. It does however, statically create 4 such devices on driver load, > > which I don't think is a design which will fly nowadays.. > > > > Reusing cdc-wdm is far more elegant IMHO, but I'm bound to be biased... > > I prefer a simpler approach where the kernel is not involved in QMI as > well. If we involve the kernel, then it needs to become a socket based > design and not character interfaces. I think that I mentioned this > before, CAIF and Phonet are also socket based and that for a reason. > > > > And having all these devices expose their QMI interface as a > > > /dev/cdc-wdmX should make things look more consistent for users and > > > userspace. > > > > I was given another Huawei modem with newer firmware today, which leaves > > me with two of them + the internal Ericsson modem in the laptop. So I > > no have 4 cdc-wdm devices to play with, two AT and two QMI: > > > > Jan 25 15:32:06 nemi kernel: [60970.442946] cdc_wdm 2-4:1.5: Finding maximum buffer length: 2048 > > Jan 25 15:32:06 nemi kernel: [60970.443623] cdc_wdm 2-4:1.5: cdc-wdm0: USB WDM device > > Jan 25 15:32:06 nemi kernel: [60970.443638] cdc_wdm 2-4:1.6: Finding maximum buffer length: 2048 > > Jan 25 15:32:06 nemi kernel: [60970.443889] cdc_wdm 2-4:1.6: cdc-wdm1: USB WDM device > > Jan 25 15:32:06 nemi kernel: [60970.443932] usbcore: registered new interface driver cdc_wdm > > Jan 25 15:32:17 nemi kernel: [60981.492525] qmi_wwan 2-1:1.3: cdc-wdm2: USB WDM device > > Jan 25 15:32:17 nemi kernel: [60981.498160] qmi_wwan 2-1:1.3: wwan1: register 'qmi_wwan' at usb-0000:00:1d.7-1, QMI speaking wwan device with combined interface, 0e:b8:5e:cd:9c:78 > > Jan 25 15:32:17 nemi kernel: [60981.498943] qmi_wwan 1-1:1.3: cdc-wdm3: USB WDM device > > Jan 25 15:32:17 nemi kernel: [60981.502264] qmi_wwan 1-1:1.3: wwan2: register 'qmi_wwan' at usb-0000:00:1a.7-1, QMI speaking wwan device with combined interface, 0e:b8:5e:cd:9c:78 > > Jan 25 15:32:17 nemi kernel: [60981.502601] usbcore: registered new interface driver qmi_wwan > > > > > > bjorn@nemi:~$ ls -l /dev/cdc-wdm* > > crw-rw---T 1 root dialout 180, 0 Jan 25 15:32 /dev/cdc-wdm0 > > crw-rw---T 1 root dialout 180, 1 Jan 25 15:32 /dev/cdc-wdm1 > > crw-rw---T 1 root dialout 180, 2 Jan 25 15:32 /dev/cdc-wdm2 > > crw-rw---T 1 root dialout 180, 3 Jan 25 15:32 /dev/cdc-wdm3 > > > > > > Detecting netdev => wdm mapping based on USB device connection works > > well enough as long as there is only one netdev per USB device. And > > detecting AT command interface is as easy as just trying AT or ATI and > > see if you get an OK back. The Huawei modem does not seem to have any > > problems with this kind of noise, so protocol probing in the order > > AT,QMI is possible. > > I personally never liked the port probing crazy, but that is up to > ModemManager. Inside oFono we do not need this. And we can nicely figure > out which device nodes belongs to which device. Especially since we are > also understanding the USB interface order as well. Obviously it can be optimized, but we tried the tagging thing with early versions of 3G support in NetworkManager (via HAL .fdi files). It really breaks down for a lot of devices, because you simply cannot depend on the manufacturers for sane USB VID/PID in many cases. While data cards sometimes have this issue (I'm looking at you, ZTE), they weren't the major problem: tethered phones were. It turns out there are so many phones out there, and many of those use the same VID/PID for wildly different devices with different command sets and port layouts. So if you can't depend on VID/PID to know what command set the device supports, or even what protocols each port speaks, what else can you do? You have to probe, at least to see if it's an AT port or DIAG or QMI or WMC or CnS or whatever. Nice modems include AT commands to tell you the port layouts, but there aren't many of those. And probing made MM work with a much larger variety of hardware than tagging ever could, since we'd always be chasing manufacturers releasing new devices. Second, while the tagging approach does allow users to test out new devices themselves, we found lots of confusion and issues reported by users that tried to tag devices manually themselves and got it wrong. Probing also staunched that flow of bug reports. So in the end, a combination of port tagging and port probing is the best way to go. If you don't have tags, you need to probe, otherwise you'll never achieve any sort of plug and play or good user experience. Of course on more embedded systems where you have full control over the hardware it's easier to use tags. The probing behavior of MM is not optimal right now, and that's something we're working on, and I expect it to be much quicker in the near future. > > We could also put known protocols per device into the usbnet driver and > > export that to userspace using sysfs, but I don't know if it has enough > > value? > > If you know everything up front, this would make it easier. With cdc-wdm > you might have a chance to do this, with the "option" driver it is > almost hopeless ;) The problem here is that the drivers can only know this based on VID/PID since they don't really do any inspection of the ports themselves. And if the driver gets it wrong, it takes a lot more time to change the kernel than it does to update a package with new udev tags. I'd love it if we could do this, but I'm worried that encoding too much logic like this in the kernel will bite us in the future when new devices come out with different layouts but the same VID/PID or such. 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
