Patchwork [v5,4/6] usb: gadget: add mechanism to specify an explicit status stage

login
register
mail settings
Submitter Alan Stern
Date Jan. 9, 2019, 7:06 p.m.
Message ID <Pine.LNX.4.44L0.1901091359020.1205-100000@iolanthe.rowland.org>
Download mbox | patch
Permalink /patch/696139/
State New
Headers show

Comments

Alan Stern - Jan. 9, 2019, 7:06 p.m.
On Wed, 9 Jan 2019, Paul Elder wrote:

> A usb gadget function driver may or may not want to delay the status
> stage of a control OUT request. An instance where it might want to is to
> asynchronously validate the data of a class-specific request.
> 
> A function driver that wants an explicit status stage should set the
> newly added explicit_status flag of the usb_request corresponding to the
> data stage. Later on, the function driver can explicitly complete the
> status stage by enqueueing a usb_request for ACK, or calling
> usb_ep_set_halt() for STALL.
> 
> To support both explicit and implicit status stages, a UDC driver must
> call the newly added usb_gadget_control_complete function right before
> calling usb_gadget_giveback_request. To support the explicit status
> stage, it might then check what stage the usb_request was queued in, and
> for control IN ACK the host's zero-length data packet, or for control
> OUT send a zero-length DATA1 ACK packet.
> 
> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> v4 Acked-by: Alan Stern <stern@rowland.harvard.edu>
> v1 Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

This looks good and has passed my tests so far.  Can you check your uvc
changes using dummy_hcd with the patch below?

Alan Stern
Paul Elder - Jan. 11, 2019, 8:23 a.m.
On Wed, Jan 09, 2019 at 02:06:31PM -0500, Alan Stern wrote:
> On Wed, 9 Jan 2019, Paul Elder wrote:
> 
> > A usb gadget function driver may or may not want to delay the status
> > stage of a control OUT request. An instance where it might want to is to
> > asynchronously validate the data of a class-specific request.
> > 
> > A function driver that wants an explicit status stage should set the
> > newly added explicit_status flag of the usb_request corresponding to the
> > data stage. Later on, the function driver can explicitly complete the
> > status stage by enqueueing a usb_request for ACK, or calling
> > usb_ep_set_halt() for STALL.
> > 
> > To support both explicit and implicit status stages, a UDC driver must
> > call the newly added usb_gadget_control_complete function right before
> > calling usb_gadget_giveback_request. To support the explicit status
> > stage, it might then check what stage the usb_request was queued in, and
> > for control IN ACK the host's zero-length data packet, or for control
> > OUT send a zero-length DATA1 ACK packet.
> > 
> > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > v4 Acked-by: Alan Stern <stern@rowland.harvard.edu>
> > v1 Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> This looks good and has passed my tests so far.

Good! Thank you :)

> Can you check your uvc
> changes using dummy_hcd with the patch below?

I'm not sure what to make of the test results. I get the same results
with or without the patch. Which I guess makes sense... in dummy_queue,
this is getting hit when the uvc function driver tries to complete the
delayed status:

	req = usb_request_to_dummy_request(_req);
	if (!_req || !list_empty(&req->queue) || !_req->complete)
		return -EINVAL;

So the delayed/explicit status stage is never completed, afaict.

Paul
Alan Stern - Jan. 11, 2019, 3:50 p.m.
On Fri, 11 Jan 2019, Paul Elder wrote:

> On Wed, Jan 09, 2019 at 02:06:31PM -0500, Alan Stern wrote:
> > On Wed, 9 Jan 2019, Paul Elder wrote:
> > 
> > > A usb gadget function driver may or may not want to delay the status
> > > stage of a control OUT request. An instance where it might want to is to
> > > asynchronously validate the data of a class-specific request.
> > > 
> > > A function driver that wants an explicit status stage should set the
> > > newly added explicit_status flag of the usb_request corresponding to the
> > > data stage. Later on, the function driver can explicitly complete the
> > > status stage by enqueueing a usb_request for ACK, or calling
> > > usb_ep_set_halt() for STALL.
> > > 
> > > To support both explicit and implicit status stages, a UDC driver must
> > > call the newly added usb_gadget_control_complete function right before
> > > calling usb_gadget_giveback_request. To support the explicit status
> > > stage, it might then check what stage the usb_request was queued in, and
> > > for control IN ACK the host's zero-length data packet, or for control
> > > OUT send a zero-length DATA1 ACK packet.
> > > 
> > > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > > v4 Acked-by: Alan Stern <stern@rowland.harvard.edu>
> > > v1 Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > 
> > This looks good and has passed my tests so far.
> 
> Good! Thank you :)
> 
> > Can you check your uvc
> > changes using dummy_hcd with the patch below?
> 
> I'm not sure what to make of the test results. I get the same results
> with or without the patch. Which I guess makes sense... in dummy_queue,
> this is getting hit when the uvc function driver tries to complete the
> delayed status:
> 
> 	req = usb_request_to_dummy_request(_req);
> 	if (!_req || !list_empty(&req->queue) || !_req->complete)
> 		return -EINVAL;
> 
> So the delayed/explicit status stage is never completed, afaict.

I presume you are hitting the !list_empty(&req->queue) test, yes?  The 
other two tests are trivial.

Triggering the !list_empty() test means the request has already been
submitted and not yet completed.  This probably indicates there is a
bug in the uvc function driver code.

Alan Stern
Paul Elder - Jan. 14, 2019, 5:11 a.m.
On Fri, Jan 11, 2019 at 10:50:11AM -0500, Alan Stern wrote:
> On Fri, 11 Jan 2019, Paul Elder wrote:
> 
> > On Wed, Jan 09, 2019 at 02:06:31PM -0500, Alan Stern wrote:
> > > On Wed, 9 Jan 2019, Paul Elder wrote:
> > > 
> > > > A usb gadget function driver may or may not want to delay the status
> > > > stage of a control OUT request. An instance where it might want to is to
> > > > asynchronously validate the data of a class-specific request.
> > > > 
> > > > A function driver that wants an explicit status stage should set the
> > > > newly added explicit_status flag of the usb_request corresponding to the
> > > > data stage. Later on, the function driver can explicitly complete the
> > > > status stage by enqueueing a usb_request for ACK, or calling
> > > > usb_ep_set_halt() for STALL.
> > > > 
> > > > To support both explicit and implicit status stages, a UDC driver must
> > > > call the newly added usb_gadget_control_complete function right before
> > > > calling usb_gadget_giveback_request. To support the explicit status
> > > > stage, it might then check what stage the usb_request was queued in, and
> > > > for control IN ACK the host's zero-length data packet, or for control
> > > > OUT send a zero-length DATA1 ACK packet.
> > > > 
> > > > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > > > v4 Acked-by: Alan Stern <stern@rowland.harvard.edu>
> > > > v1 Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > 
> > > This looks good and has passed my tests so far.
> > 
> > Good! Thank you :)
> > 
> > > Can you check your uvc
> > > changes using dummy_hcd with the patch below?
> > 
> > I'm not sure what to make of the test results. I get the same results
> > with or without the patch. Which I guess makes sense... in dummy_queue,
> > this is getting hit when the uvc function driver tries to complete the
> > delayed status:
> > 
> > 	req = usb_request_to_dummy_request(_req);
> > 	if (!_req || !list_empty(&req->queue) || !_req->complete)
> > 		return -EINVAL;
> > 
> > So the delayed/explicit status stage is never completed, afaict.
> 
> I presume you are hitting the !list_empty(&req->queue) test, yes?  The 
> other two tests are trivial.

Yes, that is what's happening.

> Triggering the !list_empty() test means the request has already been
> submitted and not yet completed.  This probably indicates there is a
> bug in the uvc function driver code.

The uvc function driver works with musb, though :/

I compared the sequence of calls to the uvc setup, completion handler,
and status stage sending, and for some reason dummy_hcd, after an OUT
setup-completion-status sequence, calls a completion-status-completion
sequence, and then goes on the the next request. musb simply goes on to
the next request after the setup-completion-status sequence.

I commented out the paranoia block in dummy_timer, and dummy_hcd still
does the extra completion, but it doesn't error out anymore. I doubt
that's the/a solution though, especially since I get:

[   22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 (exp. 26).
[   22.624481] uvcvideo: Failed to initialize the device (-5).

Not sure if that's a result of dummy_hcd not supporting isochronous
transfers or not.

I'm not sure where to continue investigating :/


Thanks,

Paul
Alan Stern - Jan. 14, 2019, 3:24 p.m.
On Mon, 14 Jan 2019, Paul Elder wrote:

> > > > Can you check your uvc
> > > > changes using dummy_hcd with the patch below?
> > > 
> > > I'm not sure what to make of the test results. I get the same results
> > > with or without the patch. Which I guess makes sense... in dummy_queue,
> > > this is getting hit when the uvc function driver tries to complete the
> > > delayed status:
> > > 
> > > 	req = usb_request_to_dummy_request(_req);
> > > 	if (!_req || !list_empty(&req->queue) || !_req->complete)
> > > 		return -EINVAL;
> > > 
> > > So the delayed/explicit status stage is never completed, afaict.
> > 
> > I presume you are hitting the !list_empty(&req->queue) test, yes?  The 
> > other two tests are trivial.
> 
> Yes, that is what's happening.
> 
> > Triggering the !list_empty() test means the request has already been
> > submitted and not yet completed.  This probably indicates there is a
> > bug in the uvc function driver code.
> 
> The uvc function driver works with musb, though :/
> 
> I compared the sequence of calls to the uvc setup, completion handler,
> and status stage sending, and for some reason dummy_hcd, after an OUT
> setup-completion-status sequence, calls a completion-status-completion
> sequence, and then goes on the the next request. musb simply goes on to
> the next request after the setup-completion-status sequence.

I don't quite understand.  There's a control-OUT transfer, the setup, 
data, and status transactions all complete normally, and then what 
happens?  What do you mean by "a completion-status-completion 
sequence"?  A more detailed description would help.

> I commented out the paranoia block in dummy_timer, and dummy_hcd still
> does the extra completion, but it doesn't error out anymore. I doubt
> that's the/a solution though, especially since I get:
> 
> [   22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 (exp. 26).
> [   22.624481] uvcvideo: Failed to initialize the device (-5).
> 
> Not sure if that's a result of dummy_hcd not supporting isochronous
> transfers or not.
> 
> I'm not sure where to continue investigating :/

Perhaps removing the "#if 0" protecting the dev_dbg line in 
dummy_queue() would provide some helpful output.

Another thing to check would be if the "implement an emulated 
single-request FIFO" in dummy_queue() is causing trouble.  There's no 
harm in replacing the long "if" condition with "if (0)".

Alan Stern
Paul Elder - Jan. 16, 2019, 5 a.m.
On Mon, Jan 14, 2019 at 10:24:44AM -0500, Alan Stern wrote:
> On Mon, 14 Jan 2019, Paul Elder wrote:
> 
> > > > > Can you check your uvc
> > > > > changes using dummy_hcd with the patch below?
> > > > 
> > > > I'm not sure what to make of the test results. I get the same results
> > > > with or without the patch. Which I guess makes sense... in dummy_queue,
> > > > this is getting hit when the uvc function driver tries to complete the
> > > > delayed status:
> > > > 
> > > > 	req = usb_request_to_dummy_request(_req);
> > > > 	if (!_req || !list_empty(&req->queue) || !_req->complete)
> > > > 		return -EINVAL;
> > > > 
> > > > So the delayed/explicit status stage is never completed, afaict.
> > > 
> > > I presume you are hitting the !list_empty(&req->queue) test, yes?  The 
> > > other two tests are trivial.
> > 
> > Yes, that is what's happening.
> > 
> > > Triggering the !list_empty() test means the request has already been
> > > submitted and not yet completed.  This probably indicates there is a
> > > bug in the uvc function driver code.
> > 
> > The uvc function driver works with musb, though :/
> > 
> > I compared the sequence of calls to the uvc setup, completion handler,
> > and status stage sending, and for some reason dummy_hcd, after an OUT
> > setup-completion-status sequence, calls a completion-status-completion
> > sequence, and then goes on the the next request. musb simply goes on to
> > the next request after the setup-completion-status sequence.
> 
> I don't quite understand.  There's a control-OUT transfer, the setup, 
> data, and status transactions all complete normally, and then what 
> happens?  What do you mean by "a completion-status-completion 
> sequence"?  A more detailed description would help.
> 

I meant the functions (procedures) in the function driver, so the setup
handler (uvc_function_setup), the completion handler
(uvc_function_ep0_complete), and the status sender (uvc_send_response),
although the last one actually sends the data stage for control IN.
So after the status is sent on the uvc gadget driver's end, its
completion handler is called again without the setup handler being
called beforehand and I cant figure out why.

> > I commented out the paranoia block in dummy_timer, and dummy_hcd still
> > does the extra completion, but it doesn't error out anymore. I doubt
> > that's the/a solution though, especially since I get:
> > 
> > [   22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 (exp. 26).
> > [   22.624481] uvcvideo: Failed to initialize the device (-5).
> > 
> > Not sure if that's a result of dummy_hcd not supporting isochronous
> > transfers or not.
> > 
> > I'm not sure where to continue investigating :/
> 
> Perhaps removing the "#if 0" protecting the dev_dbg line in 
> dummy_queue() would provide some helpful output.

It did, but didn't get me much farther :/

> Another thing to check would be if the "implement an emulated 
> single-request FIFO" in dummy_queue() is causing trouble.  There's no 
> harm in replacing the long "if" condition with "if (0)".

That didn't change anything.

Although I did notice that the dummy_queue that calls the completion
handler without the preceeding setup handler says that it's in the
status stage (ep->status_stage == 1).


Thanks,

Paul
Alan Stern - Jan. 16, 2019, 3:06 p.m.
On Wed, 16 Jan 2019, Paul Elder wrote:

> On Mon, Jan 14, 2019 at 10:24:44AM -0500, Alan Stern wrote:
> > On Mon, 14 Jan 2019, Paul Elder wrote:
> > 
> > > > > > Can you check your uvc
> > > > > > changes using dummy_hcd with the patch below?
> > > > > 
> > > > > I'm not sure what to make of the test results. I get the same results
> > > > > with or without the patch. Which I guess makes sense... in dummy_queue,
> > > > > this is getting hit when the uvc function driver tries to complete the
> > > > > delayed status:
> > > > > 
> > > > > 	req = usb_request_to_dummy_request(_req);
> > > > > 	if (!_req || !list_empty(&req->queue) || !_req->complete)
> > > > > 		return -EINVAL;
> > > > > 
> > > > > So the delayed/explicit status stage is never completed, afaict.
> > > > 
> > > > I presume you are hitting the !list_empty(&req->queue) test, yes?  The 
> > > > other two tests are trivial.
> > > 
> > > Yes, that is what's happening.
> > > 
> > > > Triggering the !list_empty() test means the request has already been
> > > > submitted and not yet completed.  This probably indicates there is a
> > > > bug in the uvc function driver code.
> > > 
> > > The uvc function driver works with musb, though :/
> > > 
> > > I compared the sequence of calls to the uvc setup, completion handler,
> > > and status stage sending, and for some reason dummy_hcd, after an OUT
> > > setup-completion-status sequence, calls a completion-status-completion
> > > sequence, and then goes on the the next request. musb simply goes on to
> > > the next request after the setup-completion-status sequence.
> > 
> > I don't quite understand.  There's a control-OUT transfer, the setup, 
> > data, and status transactions all complete normally, and then what 
> > happens?  What do you mean by "a completion-status-completion 
> > sequence"?  A more detailed description would help.
> > 
> 
> I meant the functions (procedures) in the function driver, so the setup
> handler (uvc_function_setup), the completion handler
> (uvc_function_ep0_complete), and the status sender (uvc_send_response),
> although the last one actually sends the data stage for control IN.
> So after the status is sent on the uvc gadget driver's end, its
> completion handler is called again without the setup handler being
> called beforehand and I cant figure out why.

Isn't this what you should expect?  Every usb_request, if it is queued
successfully, eventually gets a completion callback.  That promise is
made by every UDC driver; it's part of the gadget API.  So for a
control transfer with a data stage, you expect to have:

	Setup handler called
	Data-stage request submitted
	Data-stage request completion callback
	Status-stage request submitted
	Status-stage request completion callback

Thus, two completion callbacks but only one setup callback.

> > > I commented out the paranoia block in dummy_timer, and dummy_hcd still
> > > does the extra completion, but it doesn't error out anymore. I doubt
> > > that's the/a solution though, especially since I get:
> > > 
> > > [   22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 (exp. 26).
> > > [   22.624481] uvcvideo: Failed to initialize the device (-5).
> > > 
> > > Not sure if that's a result of dummy_hcd not supporting isochronous
> > > transfers or not.
> > > 
> > > I'm not sure where to continue investigating :/
> > 
> > Perhaps removing the "#if 0" protecting the dev_dbg line in 
> > dummy_queue() would provide some helpful output.
> 
> It did, but didn't get me much farther :/
> 
> > Another thing to check would be if the "implement an emulated 
> > single-request FIFO" in dummy_queue() is causing trouble.  There's no 
> > harm in replacing the long "if" condition with "if (0)".
> 
> That didn't change anything.
> 
> Although I did notice that the dummy_queue that calls the completion
> handler without the preceeding setup handler says that it's in the
> status stage (ep->status_stage == 1).

That is consistent with the events outlined above.

Alan Stern
Paul Elder - Jan. 18, 2019, 4:31 p.m.
On Wed, Jan 16, 2019 at 10:06:53AM -0500, Alan Stern wrote:
> On Wed, 16 Jan 2019, Paul Elder wrote:
> 
> > On Mon, Jan 14, 2019 at 10:24:44AM -0500, Alan Stern wrote:
> > > On Mon, 14 Jan 2019, Paul Elder wrote:
> > > 
> > > > > > > Can you check your uvc
> > > > > > > changes using dummy_hcd with the patch below?
> > > > > > 
> > > > > > I'm not sure what to make of the test results. I get the same results
> > > > > > with or without the patch. Which I guess makes sense... in dummy_queue,
> > > > > > this is getting hit when the uvc function driver tries to complete the
> > > > > > delayed status:
> > > > > > 
> > > > > > 	req = usb_request_to_dummy_request(_req);
> > > > > > 	if (!_req || !list_empty(&req->queue) || !_req->complete)
> > > > > > 		return -EINVAL;
> > > > > > 
> > > > > > So the delayed/explicit status stage is never completed, afaict.
> > > > > 
> > > > > I presume you are hitting the !list_empty(&req->queue) test, yes?  The 
> > > > > other two tests are trivial.
> > > > 
> > > > Yes, that is what's happening.
> > > > 
> > > > > Triggering the !list_empty() test means the request has already been
> > > > > submitted and not yet completed.  This probably indicates there is a
> > > > > bug in the uvc function driver code.
> > > > 
> > > > The uvc function driver works with musb, though :/
> > > > 
> > > > I compared the sequence of calls to the uvc setup, completion handler,
> > > > and status stage sending, and for some reason dummy_hcd, after an OUT
> > > > setup-completion-status sequence, calls a completion-status-completion
> > > > sequence, and then goes on the the next request. musb simply goes on to
> > > > the next request after the setup-completion-status sequence.
> > > 
> > > I don't quite understand.  There's a control-OUT transfer, the setup, 
> > > data, and status transactions all complete normally, and then what 
> > > happens?  What do you mean by "a completion-status-completion 
> > > sequence"?  A more detailed description would help.
> > > 
> > 
> > I meant the functions (procedures) in the function driver, so the setup
> > handler (uvc_function_setup), the completion handler
> > (uvc_function_ep0_complete), and the status sender (uvc_send_response),
> > although the last one actually sends the data stage for control IN.
> > So after the status is sent on the uvc gadget driver's end, its
> > completion handler is called again without the setup handler being
> > called beforehand and I cant figure out why.
> 
> Isn't this what you should expect?  Every usb_request, if it is queued
> successfully, eventually gets a completion callback.  That promise is
> made by every UDC driver; it's part of the gadget API.  So for a
> control transfer with a data stage, you expect to have:
> 
> 	Setup handler called
> 	Data-stage request submitted
> 	Data-stage request completion callback
> 	Status-stage request submitted
> 	Status-stage request completion callback
> 
> Thus, two completion callbacks but only one setup callback.

omg how did I not notice this :/

I guess I have to fix the uvc function driver so it works with that.
musb doesn't call the status stage completion callback though; not that
it does anything so it seems fine to me, but indeed the function driver
has to be ready for it if it is called.

> > > > I commented out the paranoia block in dummy_timer, and dummy_hcd still
> > > > does the extra completion, but it doesn't error out anymore. I doubt
> > > > that's the/a solution though, especially since I get:
> > > > 
> > > > [   22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 (exp. 26).
> > > > [   22.624481] uvcvideo: Failed to initialize the device (-5).
> > > > 
> > > > Not sure if that's a result of dummy_hcd not supporting isochronous
> > > > transfers or not.
> > > > 
> > > > I'm not sure where to continue investigating :/
> > > 
> > > Perhaps removing the "#if 0" protecting the dev_dbg line in 
> > > dummy_queue() would provide some helpful output.
> > 
> > It did, but didn't get me much farther :/
> > 
> > > Another thing to check would be if the "implement an emulated 
> > > single-request FIFO" in dummy_queue() is causing trouble.  There's no 
> > > harm in replacing the long "if" condition with "if (0)".
> > 
> > That didn't change anything.
> > 
> > Although I did notice that the dummy_queue that calls the completion
> > handler without the preceeding setup handler says that it's in the
> > status stage (ep->status_stage == 1).
> 
> That is consistent with the events outlined above.


Thanks,

Paul
Alan Stern - Jan. 18, 2019, 4:52 p.m.
On Fri, 18 Jan 2019, Paul Elder wrote:

> > > I meant the functions (procedures) in the function driver, so the setup
> > > handler (uvc_function_setup), the completion handler
> > > (uvc_function_ep0_complete), and the status sender (uvc_send_response),
> > > although the last one actually sends the data stage for control IN.
> > > So after the status is sent on the uvc gadget driver's end, its
> > > completion handler is called again without the setup handler being
> > > called beforehand and I cant figure out why.
> > 
> > Isn't this what you should expect?  Every usb_request, if it is queued
> > successfully, eventually gets a completion callback.  That promise is
> > made by every UDC driver; it's part of the gadget API.  So for a
> > control transfer with a data stage, you expect to have:
> > 
> > 	Setup handler called
> > 	Data-stage request submitted
> > 	Data-stage request completion callback
> > 	Status-stage request submitted
> > 	Status-stage request completion callback
> > 
> > Thus, two completion callbacks but only one setup callback.
> 
> omg how did I not notice this :/
> 
> I guess I have to fix the uvc function driver so it works with that.
> musb doesn't call the status stage completion callback though; not that
> it does anything so it seems fine to me, but indeed the function driver
> has to be ready for it if it is called.

musb _has_ to call the status-stage completion callback.  As just one
reason, if the explicit_status flag isn't set then that callback is
responsible for deallocating the status request.  Without it, the
status request will leak.

Alan Stern

Patch

Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
===================================================================
--- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
+++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
@@ -88,6 +88,7 @@  struct dummy_ep {
 	unsigned			wedged:1;
 	unsigned			already_seen:1;
 	unsigned			setup_stage:1;
+	unsigned			status_stage:1;
 	unsigned			stream_en:1;
 };
 
@@ -1037,7 +1038,7 @@  static void init_dummy_udc_hw(struct dum
 		ep->ep.ops = &dummy_ep_ops;
 		list_add_tail(&ep->ep.ep_list, &dum->gadget.ep_list);
 		ep->halted = ep->wedged = ep->already_seen =
-				ep->setup_stage = 0;
+				ep->setup_stage = ep->status_stage = 0;
 		usb_ep_set_maxpacket_limit(&ep->ep, ~0);
 		ep->ep.max_streams = 16;
 		ep->last_io = jiffies;
@@ -1386,6 +1387,7 @@  static int transfer(struct dummy_hcd *du
 	struct dummy		*dum = dum_hcd->dum;
 	struct dummy_request	*req;
 	int			sent = 0;
+	bool			is_ep0 = (ep == &dum->ep[0]);
 
 top:
 	/* if there's no request queued, the device is NAKing; return */
@@ -1407,6 +1409,11 @@  top:
 		 * terminate reads.
 		 */
 		host_len = urb->transfer_buffer_length - urb->actual_length;
+		if (ep->status_stage)
+			host_len = 0;
+		else if (is_ep0 && host_len == 0)
+			ep->status_stage = 1;
+
 		dev_len = req->req.length - req->req.actual;
 		len = min(host_len, dev_len);
 
@@ -1471,6 +1478,12 @@  top:
 					req->req.status = 0;
 			}
 
+			/* Truncated control-IN => start the status stage */
+			if (*status == 0 && is_ep0 && !ep->status_stage) {
+				ep->status_stage = 1;
+				*status = -EINPROGRESS;
+			}
+
 		/*
 		 * many requests terminate without a short packet.
 		 * send a zlp if demanded by flags.
@@ -1486,6 +1499,8 @@  top:
 				if (urb->transfer_flags & URB_ZERO_PACKET &&
 				    !to_host)
 					rescan = 1;
+				else if (is_ep0 && !ep->status_stage)
+					ep->status_stage = rescan = 1;
 				else
 					*status = 0;
 			}
@@ -1496,6 +1511,9 @@  top:
 			list_del_init(&req->queue);
 
 			spin_unlock(&dum->lock);
+			if (is_ep0)
+				usb_gadget_control_complete(&dum->gadget,
+						&req->req);
 			usb_gadget_giveback_request(&ep->ep, &req->req);
 			spin_lock(&dum->lock);
 
@@ -1849,6 +1867,7 @@  restart:
 		ep->already_seen = 1;
 		if (ep == &dum->ep[0] && urb->error_count) {
 			ep->setup_stage = 1;	/* a new urb */
+			ep->status_stage = 0;
 			urb->error_count = 0;
 		}
 		if (ep->halted && !ep->setup_stage) {