Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Mon, 4 May 2020, Andrey Konovalov wrote: > >> On Mon, May 4, 2020 at 4:24 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > >> > On Mon, 4 May 2020, Andrey Konovalov wrote: >> > >> > > One more question (sorry for so many :). >> > > >> > > Looking at other fields of usb_request struct I see frame_number. >> > > AFAIU it's filled in by the UDC driver for ISO transfers. Does it make >> > > sense to expose it to userspace? I don't see any composite/legacy >> > > gadgets use that field at all. >> > >> > Do any of those gadget drivers use isochronous endpoints? >> >> Yes, there are audio/uvc function/legacy drivers that use those. >> >> > In fact, it also looks like none of the drivers in gadget/udc/ touch >> > the frame_number field. Maybe we should just get rid of it, since it >> > isn't being used. >> >> It is used by dwc2/3 gadget drivers (which are not in gadget/udc/). > > Well, if Felipe thinks we ought to keep the field then you might as > well export it to userspace. Drivers are free to ignore it. :-) dwc3 has its own private frame_number as part of its own endpoint structure. We simply copy that to the request. That's is currently telling the gadget driver which frame the request completed. It could be used by the function to decide when to queue more requests. It can also be used to predict if we're in sync with the frames or will we diverge and miss frames in the future. If nobody has implemented any of that so far, I don't mind removing it. We need strong evidence that this will never be used, though :-) -- balbi
Attachment:
signature.asc
Description: PGP signature
