Re: Testing endpoint halt support for raw-gadget

From: Felipe Balbi <balbi@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>,
	Andrey Konovalov <andreyknvl@google.com>
Cc: 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, 05 May 2020 09:34:05 +0300	[thread overview]
Message-ID: <87a72mc2le.fsf@kernel.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.2005041114130.11213-100000@netrider.rowland.org>

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

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 :-)

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]