From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757308AbbJ2OZc (ORCPT ); Thu, 29 Oct 2015 10:25:32 -0400 Received: from mga11.intel.com ([192.55.52.93]:11959 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757182AbbJ2OZa (ORCPT ); Thu, 29 Oct 2015 10:25:30 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,214,1444719600"; d="scan'208";a="674337586" Subject: Re: [PATCH v2 1/1] usb: xhci: fix checking ep busy for CFC To: Mathias Nyman , Sergei Shtylyov , Mathias Nyman , Greg Kroah-Hartman References: <1446086797-7218-1-git-send-email-baolu.lu@linux.intel.com> <5632165E.2020102@cogentembedded.com> <563217F9.7040707@linux.intel.com> <56322849.50304@linux.intel.com> Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org From: "Lu, Baolu" Message-ID: <56322C46.4060800@linux.intel.com> Date: Thu, 29 Oct 2015 22:25:10 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56322849.50304@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 10/29/2015 10:08 PM, Mathias Nyman wrote: > On 29.10.2015 14:58, Lu, Baolu wrote: >> >> >> On 10/29/2015 08:51 PM, Sergei Shtylyov wrote: >>> Hello. >>> >>> On 10/29/2015 5:46 AM, Lu Baolu wrote: >>> >>>> Function ep_ring_is_processing() checks the dequeue pointer >>>> in endpoint context to know whether an endpoint is busy with >>>> processing TRBs. This is not correct since dequeue pointer >>>> field in an endpoint context is only valid when the endpoint >>>> is in Halted or Stopped states. This buggy code causes audio >>>> noise when playing sound with USB headset connected to host >>>> controllers which support CFC (one of xhci 1.1 features). >>>> >>>> This patch should exist in stable kernel since v4.3. >>>> >>>> Reported-and-tested-by: YD Tseng >>>> Signed-off-by: Lu Baolu >>>> >>>> --- >>>> v1->v2: >>>> Implement the logic in xhci_queue_isoc_tx_prepare() instead of >>>> a seperated function as suggested by Mathias. >>>> >>>> --- >>>> drivers/usb/host/xhci-ring.c | 32 ++++++-------------------------- >>>> 1 file changed, 6 insertions(+), 26 deletions(-) >>>> >>>> diff --git a/drivers/usb/host/xhci-ring.c >>>> b/drivers/usb/host/xhci-ring.c >>>> index fa83625..8edc286 100644 >>>> --- a/drivers/usb/host/xhci-ring.c >>>> +++ b/drivers/usb/host/xhci-ring.c >>> [...] >>>> @@ -3983,10 +3961,12 @@ int xhci_queue_isoc_tx_prepare(struct >>>> xhci_hcd *xhci, gfp_t mem_flags, >>>> } >>>> >>>> /* Calculate the start frame and put it in urb->start_frame. */ >>>> - if (HCC_CFC(xhci->hcc_params) && >>>> - ep_ring_is_processing(xhci, slot_id, ep_index)) { >>>> - urb->start_frame = xep->next_frame_id; >>>> - goto skip_start_over; >>>> + if (HCC_CFC(xhci->hcc_params)) { >>>> + if ((le32_to_cpu(ep_ctx->ep_info) & EP_STATE_MASK) >>>> + == EP_STATE_RUNNING && >>>> + !list_empty(&ep_ring->td_list)) >>>> + urb->start_frame = xep->next_frame_id; >>>> + goto skip_start_over; >>> >>> Forgot {}? >> >> Oh, I am sorry. I am wondering how it passed my test. >> >> I will send v3 patch soon any way. >> >> > > If you are anyway making a v3 then maybe one more change, > just for readability, no (real) functional change: > > if (HCC_CFC(xhci->hcc_params) && !list_empty(&ep_ring->td_list)) { > if (le32_to_cpu(ep_... Done. > > While thinking about code cleanup I also think we should use a local > variable > u32 ep_info = le32_to_cpu(ep_ctx->ep_info) as it's used several times > in xhci_queue_isoc_tx_preapare(), > causing a lot of line splitting. > > It should be ok as we are under the same spinlock so ep_ctx should not > change. > > But that is not a fix sent to a rc and stable, I can make a separate > cleanup patch for it later. > > -Mathias > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >