On Fri, 2012-06-22 at 09:49 -0400, Forest Bond wrote: > Hi Bjørn, > > On Fri, Jun 22, 2012 at 11:53:12AM +0200, Bjørn Mork wrote: > > Dan Williams <dcbw@xxxxxxxxxx> writes: > > > > > This was just a comment to let others (Bjorn!) know that we'll *also* > > > probably need some more ids in cdc_wdm. I'm not 100% certain the device > > > does QMI, but I'm 95% sure. > > > > Thanks for the confidence, but I don't see how I can guess this at > > all. The only way to know for sure is if one of you with the device can > > test it. > > > > I am attaching my perl example of how QMI support can be tested without > > any driver support or other QMI utilities. It creates a CDC embedded > > QMI_CTL "Get Version" request and sends that using libusb to all possible > > interfaces on a device. No magic. If we get a response, then the > > interface supports QMI. Otherwise it doesn't. > > I guess this indicates no QMI support? Or is there some other problem? > > # ./qmiver.pl --device=1410:b001 > Debugging: off > Device: 1410:b001 > Candidate: ifnum=0 > control_msg() failed (-32): Broken pipe > Unsupported endpoint configuration on ifnum=1 > Unsupported endpoint configuration on ifnum=2 > Unsupported endpoint configuration on ifnum=4 > Candidate: ifnum=6 > control_msg() failed (-108): Cannot send after transport endpoint shutdown > Unsupported endpoint configuration on ifnum=7 So after 'rmmod cdc_ether usbnet' and running the tool, the device crashes and disconnects from the bus. But it clearly is doing QMUX in Windows.... 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