On Mon, 2012-01-16 at 23:34 +0100, Bjørn Mork wrote: > Dan Williams <dcbw@xxxxxxxxxx> writes: > > > Try setting the data format then to make sure it's in 802.3 mode. See > > the CTL/Set Data Format command: > > > > 26 00 09 00 01 01 00 00 10 02 00 01 00 > > > > Cmd: 0x0026 (SET_DATA_FORMAT) > > Size: 0x0009 > > > > TLV: 0x01 (Format) > > Size: 0x0001 > > Data: 0x00 (0 = no QoS Header, 1 = include QoS header) > > > > TLV: 0x10 (Protocol) > > Size: 0x0002 > > Data[0]: 0x01 (1 = 802.3, 2 = raw IP mode) > > Data[1]: 0x00 > > > Thanks. That looks like a policy the driver definitely should touch. > And now I understand why I haven't found it before. I have been looking > all over the QMI_WDS spec. Why is this a CTL command? And is there a > GET one as well, so that I can verify what my modem is up to when I > don't touch this? Hmm, guess I can look that up in your python code. > Never mind. > > BTW, where did you get the CTL spec? I haven't seen that anywhere. > It's not in the qmi.zip file you get from Qualcomm, is it? Or am I just > blind? > > FYI, the CTL commands I've been using so far have all come out of other > open source drivers (Google's Android-stuff, Huawei's hacked-up mess and > the CodeAurora Gobi-driver) I was looking for why the UML290 driver seemed to operate in "raw IP" mode, and then I also remembered some additions to smd_rmnet.c from the Android tree that handled raw-IP mode that aren't upstream. So I concluded that QMI must somehow allow either 802.3 mode or raw IP mode. Then after you posted about the Huawei dongle I decided to snoop the USB control transfers of the UML290 and sure enough it was QMUX. I then wrote all the decode python logic to inspect them and looked at all the TLVs, and sure enough, there was the command to select raw IP mode. I get all these commands from the GobiAPI database from the CodeAurora Gobi module drops. The QMI database has almost all this stuff in it, but of course you need to extract it all and figure out the format. I've been doing that in the qmidb.py program of the libqmi project: http://cgit.freedesktop.org/libqmi/ (my goal with libqmi is to create a *SANE* C library that talks QMI, instead of the very un-Unix-like, Windows-ported stuff in GobiAPI that's a pain to work with, has had buffer overflows in the past, and seems to be about 5000 LoC more than it needs to be) If you run qmidb.py and point it at Database/QMI it'll spit out C-formatted defines for everything in the database. It's not perfect yet as it doesn't quite handle bitfields and padding but it's got enough that you can manage to figure out most of what's going on. If you want to waste a few days you can try to walk the database in your head, but it's a b*tch. Qualcomm also pushed out a flattened version of some of the database stuff (much like qmidb.py spits out) recently but it doesn't contain as much stuff as the QMI database from GobiAPI. The flattened stuff does include a few tidbits about LTE though that the database doesn't. Second, like I said you can find decode.py in ModemManager; if you want to send me the usbmon files you have (privately, they include your IMSI, MEID, etc), I'd be happy to make decode.py work with them to make your life easier. > >> Ugh. So I now send the QMI command only on reconnects. Seems to do the > >> job. But I expect there are other weird issues like this... > > > > Try the data format thing. I don't think that's a firmware bug really, > > but simply that you didn't set the format first. The UML290 sends this > > command to ensure the data format is always [ no QoS, raw IP ]. > > Will do. That should make things cleaner again. Thanks. > > > Yeah, we'll see, but we really, really do need a way of handling this > > sort of thing and if it's all using the same endpoints as the CDC ether > > driver (which it is) and since they are both intimately related it's > > hard to see how they really should be separated. Unfortunately that's > > the mechanism Qualcomm chose instead of a separate USB interface for the > > QMI stuff :(. > > I think the cdc-wdm stuff Oliver pointed me to is looking good. It has > the advantages that it is well tested, has found its place both in the > kernel code and in the sysfs, and has well established device names. > > Am making some progress getting it to work in a multi-writer/multi- > reader enviroment. Hope to soon get to a point where I can attach a > network driver to it as well. That will be somewhat ugly as only one of > them can own the interrupt ep and the interface data, but let's not > worry about that yet... > > Yes, the drivers must cooperate closely given that they must share the > interrupt endpoint, but I believe that is doable. And it shouldn't > matter to userspace. In fact it's an advantage as you get the USB > interface as a common container for both the net device and the char > device. No doubt that they belong together. Sounds great, looking forward to it. Thanks again for working 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
