> -----Original Message----- > From: Oliver Neukum [mailto:oneukum@xxxxxxx] > On Monday 21 January 2013 15:47:13 Bjørn Mork wrote: > > But I wonder if this isn't really a generic problem in usbnet. The > > FLAG_MULTI_PACKET test here seems completely bogus: > > > > if (length % dev->maxpacket == 0) { > > if (!(info->flags & FLAG_SEND_ZLP)) { > > if (!(info->flags & FLAG_MULTI_PACKET)) { > > urb->transfer_buffer_length++; > > if (skb_tailroom(skb)) { > > skb->data[skb->len] = 0; > > __skb_put(skb, 1); > > } > > } > > } else > > urb->transfer_flags |= URB_ZERO_PACKET; > > } > > > > Either the FLAG_MULTI_PACKET minidriver will have already padded the > > buffer so that we do not hit (length % dev->maxpacket == 0), or we > > should choose one of the alternatives: ZLP or padding. > > But we cannot simply call __skb_put for a complicated data frame. > Besides you may want the current behavior. > Specification says: NCM/MBIM shall not send ZLP if buffer size is dwNtbOutMaxSize. The problem is: dwNtbOutMaxSize value is negotiated between host and device NCM/MBIM entities and usbnet has no knowledge about it. Adding one byte to make buffer looking like a short packet was most simple approach instead of inventing a way to communicate dwNtbOutMaxSize to usbnet. You could drop short packet approach if dwNtbOutMaxSize is provided to usbnet and decision is made accordingly to NCM/MBIM spec (with exception to faulty devices). 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
