On 2018-06-22 12:01:13 [+0200], Daniel Mack wrote: > Hmm, there is no such thing as usb_fill_iso_urb() in my tree, are you going > to add that? Yes. > The only part that needs attention is the interval parameter, which is > passed to usb_fill_int_urb() as 1 now, and hence urb->interval will also be > 1, just like the open-coded version before. Unless I miss anything, your > conversion should work, but I haven't tested it yet. It should work in most cases. The point is that the argument expects bInterval (from the endpoint) which has a different encoding on FS vs HS/SS for INTR endpoints but not for ISOC endpoints and I got this wrong initially. > But I agree the function name is misleading, so we should probably get a > usb_fill_iso_urb() and use it where appropriate. AFAICS, it will be > identical to usb_fill_bulk_urb(), as the endpoint type is encoded in the > pipe. Maybe it's worth adding a check? What check? it should be identical to INTR without the speed check (always the HS version should be used). I need to check if it makes sense to extend the parameters to cover ->number_of_packets and so on. Any way, I plan to first RFC the function, land it upstream and then convert the users. > Thanks, > Daniel Sebastian -- 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
