Re: Testing endpoint halt support for raw-gadget

From: Andrey Konovalov <andreyknvl@google.com>
To: Felipe Balbi <balbi@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	USB list <linux-usb@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: Testing endpoint halt support for raw-gadget
Date: Tue, 5 May 2020 14:13:09 +0200	[thread overview]
Message-ID: <CAAeHK+yk-qDR=8VvhEyxggT-3KuT26smHX_HTeUNRxg+1ObeQA@mail.gmail.com> (raw)
In-Reply-To: <87a72mc2le.fsf@kernel.org>

On Tue, May 5, 2020 at 8:34 AM Felipe Balbi <balbi@kernel.org> wrote:
>
>
> Hi,
>
> Alan Stern <stern@rowland.harvard.edu> writes:
> > On Mon, 4 May 2020, Andrey Konovalov wrote:
> >
> >> On Mon, May 4, 2020 at 4:24 PM Alan Stern <stern@rowland.harvard.edu> 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.