From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755464AbcCBMwd (ORCPT ); Wed, 2 Mar 2016 07:52:33 -0500 Received: from mga09.intel.com ([134.134.136.24]:21757 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752873AbcCBMwc (ORCPT ); Wed, 2 Mar 2016 07:52:32 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,528,1449561600"; d="scan'208";a="925133479" Message-ID: <56D6E380.3060800@linux.intel.com> Date: Wed, 02 Mar 2016 14:58:40 +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: Lu Baolu , Greg Kroah-Hartman CC: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 07/10] usb: dbc: handle endpoint stall References: <1453813096-6991-1-git-send-email-baolu.lu@linux.intel.com> <1453813096-6991-8-git-send-email-baolu.lu@linux.intel.com> In-Reply-To: <1453813096-6991-8-git-send-email-baolu.lu@linux.intel.com> 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 26.01.2016 14:58, Lu Baolu wrote: > In case of endpoint stall, software is able to detect the situation > by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB > framework to handle endpoint stall. When software detects endpoint > stall situation, it should wait until endpoint is recovered before > read or write oprations. > > Signed-off-by: Lu Baolu > --- > drivers/usb/early/xhci-dbc.c | 36 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > > diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c > index c81df40..344d93e 100644 > --- a/drivers/usb/early/xhci-dbc.c > +++ b/drivers/usb/early/xhci-dbc.c > @@ -1163,6 +1163,37 @@ static int xdbc_wait_until_dbc_configured(void) > return -ETIMEDOUT; > } > > +static int xdbc_wait_until_epstall_cleared(bool read) > +{ > + int timeout = 0; > + > + if (read) { > + do { > + if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HIT)) { > + xdbcp->in_ep_state = EP_RUNNING; > + > + return 0; > + } > + > + xdbcp->in_ep_state = EP_HALTED; > + xdbc_udelay(10); > + } while (timeout++ < XDBC_LOOPS); > + } else { > + do { > + if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HOT)) { > + xdbcp->out_ep_state = EP_RUNNING; > + > + return 0; > + } > + > + xdbcp->out_ep_state = EP_HALTED; > + xdbc_udelay(10); > + } while (timeout++ < XDBC_LOOPS); > + } > + > + return -ETIMEDOUT; > +} > how about something like: enum xdbc_ep_state *ep_state; u32 halt_bit; if (read) { ep_state = &xdbcp->in_ep_state halt_bit = CTRL_HIT } else { ep_state = &xdbcp->out_ep_state halt_bit = CTRL_HOT } do { if (!(readl(..) & halt_bit)) { *ep_state = EP_RUNNING; return 0; } *ep_state = EP_HALTED; delay() } while (..) + > static int xdbc_bulk_transfer(void *data, int size, int loops, bool read) > { > u64 addr; > @@ -1182,6 +1213,11 @@ static int xdbc_bulk_transfer(void *data, int size, int loops, bool read) > return -EPERM; > } > > + if (xdbc_wait_until_epstall_cleared(read)) { > + xdbc_trace("%s: endpoint not ready\n", __func__); > + return -EPERM; Is -EPERM appropriate here? Not sure about what error codes the device side is using, but usually HALT is set due to some Data buffer/transmission/TRB error. In this case the failure is that debug host failed to send a clearFeature(EP_HALT) request in time. -Mathias