Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753514AbcJMJ7K (ORCPT ); Thu, 13 Oct 2016 05:59:10 -0400 Received: from mga03.intel.com ([134.134.136.65]:28056 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752777AbcJMJ7D (ORCPT ); Thu, 13 Oct 2016 05:59:03 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,339,1473145200"; d="asc'?scan'208";a="19220769" From: Felipe Balbi To: Baolin Wang Cc: Greg KH , Mark Brown , USB , LKML Subject: Re: [PATCH v2] usb: dwc3: gadget: Wait for end transfer complete before free irq In-Reply-To: References: <87r37kviic.fsf@linux.intel.com> <87inswvg80.fsf@linux.intel.com> Date: Thu, 13 Oct 2016 12:55:20 +0300 Message-ID: <87a8e8vaif.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: 2299 Lines: 57 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Baolin Wang writes: >>>> 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 >>>> ->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? >>> >>> No, it is not any endpoints are still enabled. Like I said in commit >>> message, we will start end transfer command when disable the endpoint, >>> if the end transfer command complete event comes after we have freed >>> the gadget irq, it will trigger the interrupt line all the time to >>> crash the system. >> >> I see what the problem is. Databook tells us we *must* set CMDIOC when >> issuing EndTransfer command and we should always wait for Command >> Complete IRQ. However, we took a shortcut and just delayed for 100us >> after issuing End Transfer. > > Yes, but 100us delay is not enough in some scenarios, like changing > function with configfs frequently, we will met problems. heh, 100us *is* enough. However we still get an IRQ because we requested for it. If you want to fix this, then you need to find a way to get rid of that 100us udelay() and add a proper wait_for_completion() to delay execution until command complete IRQ fires up. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX/1oIAAoJEMy+uJnhGpkGvnoQALV+jHMlGkIBSkKjmLOaZbgP dv3oYiGGqt6tXgzvTAE0KMKk+xXmvMeNIaVYjoiTNyuE2+q+zvCrFn26W80Flzhx BWNt4j/NdIwad87i1VXJf7h+5i8nmtvA7U6WxFaDrAFQo5fDXGTeIP8UAP79BjL7 FCyC1SXKoJX4BBb6Vdt2mcVWta/P3ATfVKA4A7cFrV4RBRRfilktzRWzARVmcr3J RSc2QtNrWrSn3L2whZq48ip7Ofo0Q7SqY848lutSuiijEXCzNPHMSS1VFWhD8Ex5 qGbZY40YUKXLwwSFpFl91uZVMnMcdJ7h9GT7tthdGXGK4KAVKX89x2H005rVfSGy tpZ+9AD/imtq262aYRrJl1vJX+wLoUFONfrkYf8dGF27pVHemV/4dcfC1XgX+sYO mP/oigEYttvm7GcbuPZBH9qNmuN36APwmOOoDZ18Qgidm5RK2cT4GPYX7yFYdUlh KRlbIJxk8R88j2fLQcvwP818Lc5TILZLQ46DtRSqXynIkJVvLQmnXykXhMZW1Fzq A58E530Ax+24FwEKB0wLO4SLBlxc/wHFfPWjW1AT5xdfkrzQoAj/TRFlRl8ZjJjO v4/YUxpSTsSJ4vAoyP94tJIpD9taCjeurmQOpJRFdmZqUJt+8U8jXR4Nt11L8G1D Oa/mcMZSGzi5XsDkrYNH =ovIf -----END PGP SIGNATURE----- --=-=-=--