Hi, On Mon, Mar 06, 2017 at 10:19:39AM +0100, Krzysztof Opasiak wrote: > >I did the experiment. Our device "requires" that the SUPER_SPPED be used. > >So, we are attempting to add SUPER_SPEED support to usbip. To assess the > >effort, could you please give us some pointers on how to do it? And what > >are the difficulties? > > In the beginning I would start with this commit: > > 1cd8fd2887e162ad3d067150962cc3d32dcf3150 > > This commit adds Super Speed support to dummy_hcd so from the kernel > point of view this should be a good source of knowledge how to add > Super Speed mode to existing HCD. Thanks a lot. I'll take a look at it. > There is also other side, the protocol. Probably we won't be able to > handle this using exiting protocol messages. At first glance I see > at least one reason: > > Documentation/usb/usbip_protocol.txt: > > USBIP_RET_SUBMIT: Reply for submitting an URB > > Offset | Length | Value | Description > -----------+--------+------------+--------------------------------------------------- > 0 | 4 | 0x00000003 | command > -----------+--------+------------+--------------------------------------------------- > 4 | 4 | | seqnum: URB sequence number > -----------+--------+------------+--------------------------------------------------- > 8 | 4 | | devid > -----------+--------+------------+--------------------------------------------------- > 0xC | 4 | | direction: 0: USBIP_DIR_OUT > | | | 1: USBIP_DIR_IN > -----------+--------+------------+--------------------------------------------------- > 0x10 | 4 | | ep: endpoint number > -----------+--------+------------+--------------------------------------------------- > 0x14 | 4 | | status: zero for successful URB > transaction, > | | | otherwise some kind of error happened. > -----------+--------+------------+--------------------------------------------------- > 0x18 | 4 | n | actual_length: number of URB data bytes > -----------+--------+------------+--------------------------------------------------- > 0x1C | 4 | | start_frame: for an ISO frame the > actually > | | | selected frame for transmit. > -----------+--------+------------+--------------------------------------------------- > 0x20 | 4 | | number_of_packets > -----------+--------+------------+--------------------------------------------------- > 0x24 | 4 | | error_count > -----------+--------+------------+--------------------------------------------------- > 0x28 | 8 | | setup: data bytes for USB setup, > filled with > | | | zeros if not used > -----------+--------+------------+--------------------------------------------------- > 0x30 | n | | URB data bytes. For ISO transfers > the padding > | | | between each ISO packets is not > transmitted. > > > > As you see we have a field for devid, direction and ep but we don't > have a field for stream id. Then, as Oliver pointed out, if we don't need bulk streams transfer type, the current protocol should work fine, right? Thanks, Yuyang -- 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
