Søren Holm <s...@sgh.dk> writes: > Oh dear it's friday .... > > # modinfo qcserial | grep 1199p68 > alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in03* > alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in02* > alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in00* > alias: usb:v1199p68A9d*dc*dsc*dp*ic*isc*ip*in* > alias: usb:v1199p68A8d*dc*dsc*dp*ic*isc*ip*in* > alias: usb:v1199p68A5d*dc*dsc*dp*ic*isc*ip*in* > alias: usb:v1199p68A4d*dc*dsc*dp*ic*isc*ip*in*
Hmm, is that from a v3.14.5 kernel? I was expecting to see alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in03* alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in02* alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in00* there as well (I deliberately made the grep match more than this to make sure that we would see something). BTW, if you were worrying about the 'UNRECOGNIZED' messages from lsusb then please do not :-) Those messages are expected. The descriptors are interface specific functional descriptors. And lsusb cannot decode such descriptors attached to a Vendor Specific interface, because the interpretation of those descriptors is class specific. I.e. vendor specific. In this case, all of them are actually proper CDC descriptors. But there is just no way lsusb can know that when the vendor claims otherwise. This doesn't matter to the drivers like "sierra" or "qcserial". They will know how to interpret such descriptors, if necessary, for any vendor specific function they support. Here we just ignore them because they don't tell us anything we don't already know (or might even be misleading because the Windows driver doesn't use them either). Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
