From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754040AbcIIKsZ (ORCPT ); Fri, 9 Sep 2016 06:48:25 -0400 Received: from mga05.intel.com ([192.55.52.43]:18004 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753972AbcIIKsY (ORCPT ); Fri, 9 Sep 2016 06:48:24 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,304,1470726000"; d="asc'?scan'208";a="1053572147" From: Felipe Balbi To: Baolin Wang , gregkh@linuxfoundation.org Cc: broonie@kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, baolin.wang@linaro.org Subject: Re: [PATCH v2 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically In-Reply-To: References: User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.3 (x86_64-pc-linux-gnu) Date: Fri, 09 Sep 2016 13:47:43 +0300 Message-ID: <874m5pgxio.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, Baolin Wang writes: > When system has stpped the gadget, we should avoid queuing any requests > which will cause tranfer failed. Thus adding some disconnect checking to > avoid this situation. > > Signed-off-by: Baolin Wang do you mind if we discuss this for a little longer? > --- > Changes since v1: > - Split into 2 separate ptaches. > - Choose complete mechanism instead of polling. > --- > drivers/usb/dwc3/ep0.c | 8 ++++++++ > drivers/usb/dwc3/gadget.c | 12 +++++++++--- > 2 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c > index fe79d77..632e5a4 100644 > --- a/drivers/usb/dwc3/ep0.c > +++ b/drivers/usb/dwc3/ep0.c > @@ -228,6 +228,14 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct = usb_request *request, > int ret; >=20=20 > spin_lock_irqsave(&dwc->lock, flags); > + if (!dwc->pullups_connected) { > + dwc3_trace(trace_dwc3_ep0, > + "queuing request %p to %s when gadget is disconnected", > + request, dep->name); > + ret =3D -ESHUTDOWN; > + goto out; > + } I have been thinking about this branch here. It's not a problem to queue a request with pullups disconnected. It's only a problem to issue START_TRANSFER without RUN_STOP bit set. So maybe this check should be done in dwc3_send_gadget_ep_cmd(). By doing that we also make sure to do the check in one place and one place only because all endpoints rely dwc3_send_gadget_ep_cmd(). > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 1783406..1a33308 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -1040,6 +1040,13 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *= dep, struct dwc3_request *req) > struct dwc3 *dwc =3D dep->dwc; > int ret; >=20=20 > + if (!dwc->pullups_connected) { > + dwc3_trace(trace_dwc3_gadget, > + "queuing request %p to %s when gadget is disconnected", > + &req->request, dep->endpoint.name); > + return -ESHUTDOWN; > + } > + > if (!dep->endpoint.desc) { > dwc3_trace(trace_dwc3_gadget, > "trying to queue request %p to disabled %s", > @@ -1984,13 +1991,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dw= c, struct dwc3_ep *dep, > if (ret) > break; > } > - trailing change. > /* > * Our endpoint might get disabled by another thread during > * dwc3_gadget_giveback(). If that happens, we're just gonna return 1 > * early on so DWC3_EP_BUSY flag gets cleared > */ > - if (!dep->endpoint.desc) > + if (!dep->endpoint.desc || !dwc->pullups_connected) I'm still considering this as well. Sure, we kill pullups before the descriptor is set to NULL, but that shouldn't be a problem. What will happen is: usb_gadget_disconnect(); udc->driver->disconnect(); for_each_ep() { for_each_request() { usb_ep_dequeue(); } usb_ep_disable(); dep->endpoint.desc =3D NULL; } udc->driver->unbind(); usb_gadget_udc_stop(); I don't see a problem here. Did you manage to trigger any failure when you didn't have this check? Care to show some logs? We might have a bug elsewhere which we don't want to mask by adding this check here. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX0pNPAAoJEMy+uJnhGpkGyOwP/iEquqtKrjswL76El3NG8woV QWR+BqAAo/P3uqypVx2haCbtkfgtdsyjvNOqA4ckQXBi9XSfjoqO4wi6lWxQE7Lx 8Vb6VvcR9HXQqPHGBxul94aTu2K/4kSgJYWkaPemZbYX7dqm7scbrg3D3xjYQh08 rgKirF+2QZ0p195jNqNFoufOTyKPFz9tFFdCJRtc+8nvzIveAwPbaxW2P6Pg5GXM Y+j8KF1N0BxECwsUyQ0d4gguBvX3YqClYh7ZJdLK2Mgg3tdu8tckOHkbwTO5yyhK pSTBRRW98kbEKBlysrO04PeCMS2WNPf3xorQO96RKP9cKB2X6oJgFGb9jZX5u4pZ W++lgkTC4pGo4EgU/VQIS8VdK3itwp21JVBcAgymuFWWwBNUd4nuOVPu5zIduhVH TJIVp82+6Ortc4qgDGRluSUn9TzxfpZH5exEORbipAvniB64GddsZECINVfb7ih7 +qZAcUouRp6uq1YTxJs9MKtjCHjD0DzDxMYDKc3LDITrhScoBd1qePBsk2Cwsixk zeUiAaMoQIS4+mHFxD6KrQKABdy4Ic13Uo9yBv6/TEaxZMWpyHAcolILdAZg72WN KbBnmgcipG8B8YVRH7ZsFMSbNXnXJf9DGTQkABXU6UdxQntXM0+viTkpomBtIOgT P9c7qBFkwaqq7pYeS3Oc =Axh/ -----END PGP SIGNATURE----- --=-=-=--