From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751040AbdAPU5n convert rfc822-to-8bit (ORCPT ); Mon, 16 Jan 2017 15:57:43 -0500 Received: from smtprelay4.synopsys.com ([198.182.47.9]:59849 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbdAPU5k (ORCPT ); Mon, 16 Jan 2017 15:57:40 -0500 From: John Youn To: John Stultz CC: Felipe Balbi , John Youn , lkml , Wei Xu , Guodong Xu , Amit Pundir , Rob Herring , Douglas Anderson , Chen Yu , Vardan Mikayelyan , Kishon Vijay Abraham I , Greg Kroah-Hartman , Linux USB List Subject: Re: [PATCH 1/4 v3] usb: dwc2: Avoid sleeping while holding hsotg->lock Thread-Topic: [PATCH 1/4 v3] usb: dwc2: Avoid sleeping while holding hsotg->lock Thread-Index: AQHSbGnrMv1JeR9HHUWAo13Z4p97V6E7l9VtgAAFgts= Date: Mon, 16 Jan 2017 20:57:01 +0000 Message-ID: References: <1484180524-4087-1-git-send-email-john.stultz@linaro.org> <1484180524-4087-2-git-send-email-john.stultz@linaro.org> <87shojmgv8.fsf@linux.intel.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jan 16, 2017, at 12:37 PM, John Stultz wrote: > > On Mon, Jan 16, 2017 at 2:36 AM, Felipe Balbi > wrote: >> >> Hi, >> >> John Stultz writes: >>> Basically when plugging in various cables in different orders, I'm >>> occasionally seeing the following BUG splat: >>> >>> [ 86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x00000002 >>> [ 86.219164] usb 1-1: USB disconnect, device number 9 >>> [ 86.226845] Preemption disabled at:[ 86.230218] >>> [] dwc2_conn_id_status_change+0x120/0x250 >>> [ 86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: G W >>> 4.9.0-rc8-00051-gd5a7979-dirty #1702 >>> [ 86.246836] Hardware name: HiKey Development Board (DT) >>> [ 86.252100] Workqueue: dwc2 dwc2_conn_id_status_change >>> [ 86.257279] Call trace: >>> [ 86.259771] [] dump_backtrace+0x0/0x1a0 >>> [ 86.265210] [] show_stack+0x14/0x20 >>> [ 86.270308] [] dump_stack+0x90/0xb0 >>> [ 86.275401] [] __schedule_bug+0x6c/0xb8 >>> [ 86.280841] [] __schedule+0x4f8/0x5b0 >>> [ 86.286099] [] schedule+0x38/0xa0 >>> [ 86.291017] [] schedule_hrtimeout_range_clock+0x8c/0xf0 >>> [ 86.297846] [] schedule_hrtimeout_range+0x10/0x18 >>> [ 86.304150] [] usleep_range+0x50/0x58 >>> [ 86.309418] [] dwc2_wait_for_mode.isra.4+0x54/0xd0 >>> [ 86.315815] [] dwc2_core_reset+0xe0/0x168 >>> [ 86.321431] [] dwc2_hsotg_core_init_disconnected+0x2c/0x310 >>> [ 86.328602] [] dwc2_conn_id_status_change+0x130/0x250 >>> [ 86.335254] [] process_one_work+0x118/0x370 >>> [ 86.341035] [] worker_thread+0x48/0x498 >>> [ 86.346473] [] kthread+0xd0/0xe8 >>> [ 86.351299] [] ret_from_fork+0x10/0x50 >>> >>> This seems to be caused by the dwc2_wait_for_mode() calling >>> usleep_range() while the hstog->lock spinlock is held, since >>> we take that before calling dwc2_hsotg_core_init_disconnected(). >>> >>> This patch avoids the issue by adding an extra argument to >>> dwc2_core_reset(), as suggested by John Youn, which allows us to >>> skip the waiting, which should be unnecessary when calling from >>> dwc2_hsotg_core_init_disconnected(). >>> >>> Cc: Wei Xu >>> Cc: Guodong Xu >>> Cc: Amit Pundir >>> Cc: Rob Herring >>> Cc: John Youn >>> Cc: Douglas Anderson >>> Cc: Chen Yu >>> Cc: Vardan Mikayelyan >>> Cc: Kishon Vijay Abraham I >>> Cc: Felipe Balbi >>> Cc: Greg Kroah-Hartman >>> Cc: linux-usb@vger.kernel.org >>> Signed-off-by: John Stultz >>> --- >> >> doesn't apply to my testing/next. Please rebase > > So these were rebased onto JohnY's tree here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_synopsys-2Dusb_linux.git&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA&m=eBJTBuJyU21iKJvHdy5FxqtxsVARo0iIqJGxMHrlbyQ&s=VIiAT32aG7s04G5NoOOthNdm2JX0eWjJpg62neY_-KI&e= next > > And apparently have been merged there. I suspect he's going to submit > his entire tree there to you? > > JohnY: Is this right? Yeah I'll get these issues sorted out with Felipe. Which may mean resubmitting everything the the proper order. Thanks, John