From patchwork Mon Jun 24 09:42:03 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 2769461 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 2D2459F245 for ; Mon, 24 Jun 2013 09:44:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 343FE20163 for ; Mon, 24 Jun 2013 09:44:50 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 034D92015A for ; Mon, 24 Jun 2013 09:44:49 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Ur3J3-0004Cj-Lz; Mon, 24 Jun 2013 09:43:30 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Ur3Il-0003Qz-5n; Mon, 24 Jun 2013 09:43:11 +0000 Received: from mail-pd0-x234.google.com ([2607:f8b0:400e:c02::234]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Ur3Ia-0003Oo-Cf for linux-arm-kernel@lists.infradead.org; Mon, 24 Jun 2013 09:43:01 +0000 Received: by mail-pd0-f180.google.com with SMTP id 10so435582pdi.25 for ; Mon, 24 Jun 2013 02:42:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=1ouef0vJN+UcVIZ0KI/jdGy9aNHwnvKw1FrLLRoay80=; b=Ck7uy2OQAVXGN4CZ8GM4tJi3e2vTOGVmCA7mEL9m/UmeOzjgTjX7o2ffkBcc/oqF1+ ebtdClMNSHL07TKG9/SGJMl86EZ7npfdEEfM1nVBQG4bcNoZwc/SG5V87PghgbR9UHga LKc7En9GNoXeaUM/8RFqYTiwYmI/XKpEeUVAu5aVK2sjubsnVVTFegVRjm4SbSkxfoOP hak59FJ720g1TvrYmjiCcqquXhRwIKRSHLtkxYJJmeLPlG3zXw6l1i2dYnyIslLj/wYq tVVw1/Wq3yd0WRsWW78wf5QSQyRRE9XD//j9ERu2jY7TBBBCOcr4vHKhtZWn7I2k56vT jAKw== X-Received: by 10.68.232.225 with SMTP id tr1mr22712975pbc.143.1372066958884; Mon, 24 Jun 2013 02:42:38 -0700 (PDT) Received: from localhost ([183.37.208.198]) by mx.google.com with ESMTPSA id jf4sm9604772pbb.19.2013.06.24.02.42.33 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 24 Jun 2013 02:42:38 -0700 (PDT) From: Ming Lei To: Greg Kroah-Hartman Subject: [PATCH v2 2/4] USB: URB documentation: claim complete() will be run with IRQs enabled Date: Mon, 24 Jun 2013 17:42:03 +0800 Message-Id: <1372066925-23579-3-git-send-email-ming.lei@canonical.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1372066925-23579-1-git-send-email-ming.lei@canonical.com> References: <1372066925-23579-1-git-send-email-ming.lei@canonical.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130624_054300_568193_6247CC12 X-CRM114-Status: GOOD ( 13.87 ) X-Spam-Score: -1.9 (-) Cc: Oliver Neukum , Ming Lei , linux-usb@vger.kernel.org, Steven Rostedt , Alan Stern , Thomas Gleixner , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There is no good reason to run complete() in hard interrupt disabled context. After switch to run complete() in tasklet, we will enable local IRQs when calling complete() since we can do it at that time. Even though we still disable IRQs now when calling complete() in tasklet, the URB documentation is updated to claim complete() will be run in tasklet context and local IRQs will be enabled, so that USB drivers can know the change and avoid one deadlock caused by: assume IRQs disabled in complete() and call spin_lock() to hold lock which might be acquired in interrupt context. Current spin_lock() usages in drivers' complete() will be cleaned up at the same time, and once the cleanup is finished, local IRQs will be enabled when calling complete() in tasklet. Also fix description about type of usb_complete_t, and remove the advice of running completion handler in tasklet for decreasing system latency. Cc: Oliver Neukum Cc: Alan Stern Signed-off-by: Ming Lei Acked-by: Alan Stern --- Documentation/usb/URB.txt | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/Documentation/usb/URB.txt b/Documentation/usb/URB.txt index 00d2c64..50da0d4 100644 --- a/Documentation/usb/URB.txt +++ b/Documentation/usb/URB.txt @@ -195,13 +195,12 @@ by the completion handler. The handler is of the following type: - typedef void (*usb_complete_t)(struct urb *, struct pt_regs *) + typedef void (*usb_complete_t)(struct urb *) -I.e., it gets the URB that caused the completion call, plus the -register values at the time of the corresponding interrupt (if any). -In the completion handler, you should have a look at urb->status to -detect any USB errors. Since the context parameter is included in the URB, -you can pass information to the completion handler. +I.e., it gets the URB that caused the completion call. In the completion +handler, you should have a look at urb->status to detect any USB errors. +Since the context parameter is included in the URB, you can pass +information to the completion handler. Note that even when an error (or unlink) is reported, data may have been transferred. That's because USB transfers are packetized; it might take @@ -210,12 +209,12 @@ have transferred successfully before the completion was called. NOTE: ***** WARNING ***** -NEVER SLEEP IN A COMPLETION HANDLER. These are normally called -during hardware interrupt processing. If you can, defer substantial -work to a tasklet (bottom half) to keep system latencies low. You'll -probably need to use spinlocks to protect data structures you manipulate -in completion handlers. +NEVER SLEEP IN A COMPLETION HANDLER. These are often called in atomic +context. +In the current kernel, completion handlers run with local interrupts +disabled, but in the future this will be changed, so don't assume that +local IRQs are always disabled inside completion handlers. 1.8. How to do isochronous (ISO) transfers?