Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752138AbcJMHW5 (ORCPT ); Thu, 13 Oct 2016 03:22:57 -0400 Received: from mga01.intel.com ([192.55.52.88]:44496 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751288AbcJMHWs (ORCPT ); Thu, 13 Oct 2016 03:22:48 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,339,1473145200"; d="asc'?scan'208";a="19560891" From: Felipe Balbi To: Baolin Wang Cc: gregkh@linuxfoundation.org, broonie@kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, baolin.wang@linaro.org Subject: Re: [PATCH v2] usb: dwc3: gadget: Wait for end transfer complete before free irq In-Reply-To: References: Date: Thu, 13 Oct 2016 10:02:35 +0300 Message-ID: <87r37kviic.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-Length: 2083 Lines: 56 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Baolin Wang writes: > @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g) > dwc->gadget_driver =3D NULL; > spin_unlock_irqrestore(&dwc->lock, flags); >=20=20 > + /* > + * Since the xHCI will share the same interrupt with gadget, thus when > + * free the gadget irq, it will not shutdown this gadget irq line. Then > + * the gadget driver can not handle the end transfer command complete > + * event after free the gadget irq, which will hang the system to crash. > + * > + * So we should wait for the end transfer command complete event before > + * free it to avoid this situation. > + */ > + dwc3_wait_command_complete(dwc); this doesn't make sense. We have already masked all interrupts before getting here. We have also, already, disabled all endpoints. I'm thinking this is a bug in configfs interface of Gadget API, not dwc3. The only reason for this to happen would be if we get to =2D>udc_stop() with endpoints still enabled. Can you check if that's the case? i.e. can you check if any endpoints are still enabled when we get here? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX/zGLAAoJEMy+uJnhGpkGUV4QAKk8eDqYoujWFgfoFDOJBLb5 hV73txU9j9pg64zxte72I7cNHHHua1Q42szBtAHqSGA1XrvLrPUbiZdCjy+VvJ1l oEatnrmfpEbFEEd2s6Pm3wcJYE6vTiXPXAQwxx4f+Io5skO8n+fYiBoZ+TXhn3f+ drqS8uflqqEy67rU3+bB+BpDYHt4LlFpaSNB6ueHJCKf+PpeErSLNtLbGb0Jhwib vnwcAUkD9YP66r/oee1f6q46SA3NxVB5yqQYSt3eUCPFI8OAcVUSTxJQSdodyxcM jZHSBsUxltuuorOubVCHU1u/R7/42msjiw9Efsely/awWzkci1UHtuyuQZj/hEWX 3yfhnbqxqXwNAEzMxaLQUCtPQNF7GIroi/IHD+pnNWfJKo93uKT0Q/dnw2sm+NZj MGsVaUn9T82oGwEvJTPEsWup9emMobYeVpveJGY9UAkY+XX/x2C2Oc85LGRQUcub Pv5KbOz9M4J0J7MpV30wQtjPS7pz9aFbLULMsxs9SnUpAuOnRT1dpQ/B+hPHWJem av3+k74ot9NP+5Q9cMA1JpecZUuLrS27wNWoU49Km5G1qCqx51f6knmnBnnh+Gqv r/AYL5t3/4gm26FW4plEhpu3exqDNWL/tMjjbRzsqFMPMJpa70MlFjtExo3gC+P9 r33IFa8CqCjBjyGqDUPN =kahV -----END PGP SIGNATURE----- --=-=-=--