From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752703AbdCBM0K (ORCPT ); Thu, 2 Mar 2017 07:26:10 -0500 Received: from mga04.intel.com ([192.55.52.120]:32510 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752489AbdCBMZy (ORCPT ); Thu, 2 Mar 2017 07:25:54 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,230,1484035200"; d="asc'?scan'208";a="231414890" From: Felipe Balbi To: Alan Stern Cc: Baolin Wang , Greg KH , USB , LKML , Linaro Kernel Mailman List , Mark Brown Subject: Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase In-Reply-To: References: Date: Thu, 02 Mar 2017 12:43:31 +0200 Message-ID: <87innst0vg.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Alan Stern writes: >> Alan Stern writes: >> >> So I am not sure how the Gadget driver can figure out that it needs to >> >> usb_ep_queue() another request for status stage when handling the >> >> no-data control? >> > >> > Gadget drivers already queue status-stage requests for no-data >> > control-OUT requests. The difficulty comes when you want to handle an >> > IN request or an OUT request with a data stage. >>=20 >> I don't see a difficulty there. Gadget driver will see wLength and >> notice it needs both data and status stages, then it does: >>=20 >> usb_ep_queue(ep0, data_req, GFP_KERNEL); >> usb_ep_queue(ep0, status_req, GFP_KERNEL); > > The main difficulty is that all the gadget/function drivers will have=20 > to be audited to add the status requests. yeah, that's a given and was also mentioned in this thread somewhere. >> Just needs to prepare both requests and queue them both ahead of >> time. UDC drivers should hold both requests in their own private list >> and process one at a time. > > Or the gadget driver should queue the status request after the=20 > data stage has been fully processed, in the case of an OUT transfer. right, we could use ->complete() for that. > There is still a possible race. The host might send another SETUP > packet before the status request has been queued, or after it has been we should also have code for this race since it would happen with USB_GADGET_DELAYED_STATUS. > queued but before the UDC driver has completed it. (Of course, that's=20 > already true now for the data request...) right =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAli391MACgkQzL64meEa mQZ5PA/6AhYlHsEVcEWmwlkZWaXxvK4WLX1Jqv5qrL5hoXC1HvTHRqoyzyQ0/1EB YjBt/7wfreiNdbz1ecH/3cUw2dBzu+vVRfgOUNfbH96FPqz8JfCjOksHrz1/KY42 pqzUIKkPlG5mvsnxVEhffdyrfnBmULo0oV8T5gv28Rl9PI+d3ey1oWlKZC8RDu0x 13YXKpbe1RwI+OoSGLhS01WjjBhPPnolbXELkCyWA2O6+GCVDs90qkppWCDntqCl qw86a+JE/racr/5WFTStU1twcrrP8ZlHZ4Mll/B+0TfarYsdeCmnyLiVYVEwRlKx 1Foidq8GrPWQqDEwRSeIY2fxP6liPVjSh74hcvUzzWViE9LnLRhokuoTDDbKi06y 0X1tDKZZQb8uwkOb44xg0Yl0zqs8gGbERu/Hg1xGb2zTd7zVn0oPTmzVdui6MY7I RQv1zNtBiCRHtlz2I/fnvKhI598E1ztnIyN+jHWp4EuI2KUVH8ZqU6iWPcSWn9wO h9XmZKiyCh77y98ILZ0GvqAcMRvtVV7gFMjF9QPdHSjZS9i2h9WbdjkOfhK7mAwC ADZAUoqI+FwMQQ5BXxwSWIn9T69mTv8y9vRxFVWpitJNQkGkvAwEZmPfrgW/dtZU vnCPpo1UF4BPsI4UUQ3D9XA8VIyCKQEqNi3cZ5oS68r/wQkFHXE= =CGYu -----END PGP SIGNATURE----- --=-=-=--