... > > The second event is always COMP_SUCCESS and the event->transfer_len is > always set to 0 in that one. The 3 cases I've seen are: > > case 1: 1 event on last TRB > COMP_SUCCESS, event->len=0 > > case 2: short event but with data > COMP_SHORT_TX, event->len < urb->transfer_buffer_len > COMP_SUCCESS, event->len=0 > > case 3: short event with no data > COMP_SHORT_TX, event->len = urb->transfer_buffer_len > COMP_SUCCESS, event->len=0 > Ok, I was hoping COMP_SUCCESS event->len in case 2 and 3 would show the same value as the previous COMP_SHORT_TX event->len >>> >>> The other thing I thought of was to somehow always initialize the URB >>> actual length to the transfer buffer length from the very beginning, >>> and only update it if a COMP_SHORT_TX event is received. Not sure if >>> that would be much more complex to handle, though. >>> >> >> This could be an option, need to look into it. > I'm starting to like your idea of setting the urb->actual_length in advance, It may actually simplify things. I already started implementing a testpatch, will send it shortly If you'd like to test it with your device and hso driver. -Mathias -- 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
