On Tue, May 5, 2020 at 8:34 AM Felipe Balbi <balbi@xxxxxxxxxx> wrote: > > > 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 :-) OK, I see, If this field is a potential candidate for removal, I won't expose it through raw-gadget just yet, but I'll try to make the interface extensible so that it can be easily added when needed.
