Andrey Konovalov wrote: > 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. Please don't remove this. We also use it for one of our HW validation tools. BR, Thinh
