From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 310E3C31E50 for ; Mon, 17 Jun 2019 13:48:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A7012080A for ; Mon, 17 Jun 2019 13:48:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560779321; bh=C8x4XMBWurVmDDCvxvDaMnT68umwkOurL5UcRw8O5VU=; h=Subject:To:From:Date:List-ID:From; b=dRKY6F9fCX+tDLO1rYilMGvphvtcZwEVhW8GzNnkVjT1glpIqyc5C763jhG7gjnyo VJwi3zdP2GuPNd36sAuoR/vOuoHPZee+8XArxs8JcfGk/0QztAQ2Dgl6QsZzxcZPtt rr21R8vbt8OxNeibbkzMjnYHTRSV32mh55YsDrdE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725995AbfFQNsk (ORCPT ); Mon, 17 Jun 2019 09:48:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:37196 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726822AbfFQNsk (ORCPT ); Mon, 17 Jun 2019 09:48:40 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 116A02085A; Mon, 17 Jun 2019 13:48:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560779319; bh=C8x4XMBWurVmDDCvxvDaMnT68umwkOurL5UcRw8O5VU=; h=Subject:To:From:Date:From; b=sCDCQkijg3IKB7dIzIw4PScg1Fnk0ew88z7mvYFZvbcpwN7yJps+Bb7ssgPy2Bhz2 tTP4tFSWdJZjchL8qq2L07N08Hzzt3nNXGccdq/8SFkQIctjX5XTbtiqJb7r83ULfG Vk6bSBAYHfZ1rHntyRl/9zIVicK/PVG7E+9fNQFQ= Subject: patch "usb: chipidea: udc: workaround for endpoint conflict issue" added to usb-linus To: peter.chen@nxp.com, festevam@gmail.com, gregkh@linuxfoundation.org, jun.li@nxp.com, sergei.shtylyov@cogentembedded.com, stable@vger.kernel.org From: Date: Mon, 17 Jun 2019 15:48:36 +0200 Message-ID: <156077931647160@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org This is a note to let you know that I've just added the patch titled usb: chipidea: udc: workaround for endpoint conflict issue to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From c19dffc0a9511a7d7493ec21019aefd97e9a111b Mon Sep 17 00:00:00 2001 From: Peter Chen Date: Mon, 17 Jun 2019 09:49:07 +0800 Subject: usb: chipidea: udc: workaround for endpoint conflict issue An endpoint conflict occurs when the USB is working in device mode during an isochronous communication. When the endpointA IN direction is an isochronous IN endpoint, and the host sends an IN token to endpointA on another device, then the OUT transaction may be missed regardless the OUT endpoint number. Generally, this occurs when the device is connected to the host through a hub and other devices are connected to the same hub. The affected OUT endpoint can be either control, bulk, isochronous, or an interrupt endpoint. After the OUT endpoint is primed, if an IN token to the same endpoint number on another device is received, then the OUT endpoint may be unprimed (cannot be detected by software), which causes this endpoint to no longer respond to the host OUT token, and thus, no corresponding interrupt occurs. There is no good workaround for this issue, the only thing the software could do is numbering isochronous IN from the highest endpoint since we have observed most of device number endpoint from the lowest. Cc: #v3.14+ Cc: Fabio Estevam Cc: Greg KH Cc: Sergei Shtylyov Cc: Jun Li Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman --- drivers/usb/chipidea/udc.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 829e947cabf5..6a5ee8e6da10 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1622,6 +1622,25 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on) static int ci_udc_start(struct usb_gadget *gadget, struct usb_gadget_driver *driver); static int ci_udc_stop(struct usb_gadget *gadget); + +/* Match ISOC IN from the highest endpoint */ +static struct usb_ep *ci_udc_match_ep(struct usb_gadget *gadget, + struct usb_endpoint_descriptor *desc, + struct usb_ss_ep_comp_descriptor *comp_desc) +{ + struct ci_hdrc *ci = container_of(gadget, struct ci_hdrc, gadget); + struct usb_ep *ep; + + if (usb_endpoint_xfer_isoc(desc) && usb_endpoint_dir_in(desc)) { + list_for_each_entry_reverse(ep, &ci->gadget.ep_list, ep_list) { + if (ep->caps.dir_in && !ep->claimed) + return ep; + } + } + + return NULL; +} + /** * Device operations part of the API to the USB controller hardware, * which don't involve endpoints (or i/o) @@ -1635,6 +1654,7 @@ static const struct usb_gadget_ops usb_gadget_ops = { .vbus_draw = ci_udc_vbus_draw, .udc_start = ci_udc_start, .udc_stop = ci_udc_stop, + .match_ep = ci_udc_match_ep, }; static int init_eps(struct ci_hdrc *ci) -- 2.22.0