From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754009AbcCUJJu (ORCPT ); Mon, 21 Mar 2016 05:09:50 -0400 Received: from mga09.intel.com ([134.134.136.24]:38737 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752638AbcCUJJk (ORCPT ); Mon, 21 Mar 2016 05:09:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,370,1455004800"; d="scan'208";a="941676766" Message-ID: <56EFBBD1.6080600@intel.com> Date: Mon, 21 Mar 2016 11:16:01 +0200 From: Mathias Nyman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Rajesh Bhagat , Mathias Nyman , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" CC: "gregkh@linuxfoundation.org" , Sriram Dash Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout References: <1458284463-12743-1-git-send-email-rajesh.bhagat@nxp.com> <56EBE485.1060301@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21.03.2016 06:18, Rajesh Bhagat wrote: > > >> >> Hi >> >> I think clearing the whole command ring is a bit too much in this case. >> It may cause issues for all attached devices when one command times out. >> > > Hi Mathias, > > I understand your point, But I want to understand how would completion handler be called > if a command is timed out and xhci_abort_cmd_ring is successful. In this case all the code > would be waiting on completion handler forever. > > > 2. xhci_handle_command_timeout -> xhci_abort_cmd_ring(failure) -> xhci_cleanup_command_queue -> xhci_complete_del_and_free_cmd > > In our case command is timed out, Hence we hit the case #2 but xhci_abort_cmd_ring is success which > does not calls complete. xhci_abort_cmd_ring() will write CA bit (CMD_RING_ABORT) to CRCR register. This will generate a command completion event with status "command aborted" for the pending command. This event is then followed by a "command ring stopped" command completion event. See xHCI specs 5.4.5 and 4.6.1.2 handle_cmd_completion() will check if cmd_comp_code == COMP_CMD_ABORT, goto event_handled, and call xhci_complete_del_and_free_cmd(cmd, cmd_comp_code) for the aborted command. If xHCI already processed the aborted command, we might only get a command ring stopped event, in this case handle_cmd_completion() will call xhci_handle_stopped_cmd_ring(xhci, cmd), which will turn the commands that were tagged for "abort" that still remain on the command ring to NO-OP commands. The completion callback will be called for these NO-OP command later when we get a command completion event for them. >> What kernel version, and what xhci vendor was this triggered on? >> > > We are using 4.1.8 kernel > Are you able to try a more recent version? -Mathias