Bjørn Mork <bjorn@xxxxxxx> writes: > Dan Williams <dcbw@xxxxxxxxxx> writes: > >> 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... > 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. 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? 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
