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) >> 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. 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
