On Fri, Oct 19, 2012 at 11:30 AM, Bjørn Mork <bjorn@xxxxxxx> wrote: > Bjørn Mork <bjorn@xxxxxxx> writes: >> Alexey Orishko <alexey.orishko@xxxxxxxxx> writes: >> > OK, I did some more experiments, and I am wondering if the real firmware > problem is in the MBIM descriptor. It is > > CDC MBIM: > bcdMBIMVersion 1.00 > wMaxControlMessage 1536 > bNumberFilters 16 > bMaxFilterSize 40 > wMaxSegmentSize 4096 > bmNetworkCapabilities 0x20 > 8-byte ntb input size > > > so we use the 8-byte version of USB_CDC_SET_NTB_INPUT_SIZE, which fails > with -EPIPE. But forcing the 4-byte version seems to work. Hmm, I also > see that the device returns 4 bytes in response to at > USB_CDC_GET_NTB_INPUT_SIZE with an 8-byte buffer. Maybe we can > auto-quirk based on that? I.e., if USB_CDC_GET_NTB_INPUT_SIZE returns > only 4 bytes then we assume that the bmNetworkCapabilities flag is > wrong. > > Is that acceptable? Then it seems we are able to inform this device of > the reduced buffer, and the other problems can be ignored. > Based on NCM errata, NCM functional descriptor: if Bit 5 is set, then device can (must) handle 8-byte form of Set/GetNtbInputSize. If they set a flag, but don't support the feature, hm.. is it a prototype device or commercially available one? At least device must support Set request, but for GetNtbInputSize we could happily live without wNtbInMaxDatagrams (i.e. use 4 byte variant) on Linux. Since we must anyway receive a complete NTB and making any number of skb buffers from received NTB is not a problem at all. regards, alexey -- 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
