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=-15.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_SANE_2 autolearn=unavailable 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 56EFFC433E0 for ; Tue, 19 Jan 2021 02:43:29 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1451522DFB for ; Tue, 19 Jan 2021 02:43:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1451522DFB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=PQR68qVLVsBGaAgtciz5+bDfxm8YowiWo8t/PIdkM8Q=; b=QUGWvzc8wRcKHObCVFyMjxfkD izrug0tHEZsQLDGXcNLwXyOAqkDk6oNqNYJ9NTgYLVm9/AiQ+tepp/607nPTGwO8h0k63NQQNt8Bz FvRUlnw68PXf6H6+vEXoTeeyQ9Ev9l6Qu9bNdqFsitoESz+OpQxJ19TLJYz/F7q1YFnSsfAiDgaMW XZX3cFUYwha4JCX+/dSKaMyVL9hyZBl6mtE3WDeP515ePHms3VBaK6Zn+Pdh3MI6uI2Qh7xuYCf8P sDUkNspB95q32NPaD4pGqwHL5CYqa+c2aQLNzV4oNaj/Z2/ZzHN+WCxV7/e9T0XxLnQbSFJlH/rWN QRWU3KuaA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1gxq-00053h-B5; Tue, 19 Jan 2021 02:41:50 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1gxm-000535-Tn; Tue, 19 Jan 2021 02:41:48 +0000 X-UUID: 8860af115ba34abfbf3c34a9b2ca5d76-20210118 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=4kexQ2hHpQDh0WXQE4QqbROz+eLRj3yLnugH4alvgz4=; b=OLXAV9xEQ4eaEFkpPwAsAn1JPspckHz2lyq0rV3acNRhp+jeiBGURdkphgAddRr85Mvc5Zxagjkfc34dN3oogxQ7c12cHPq2isO0CDt1dR0pXHE6+ZM1rsxXo6q02VubM6agu3PkYrFuNiKKiCil3MttuNHyFzB6tulEivoPtQ8=; X-UUID: 8860af115ba34abfbf3c34a9b2ca5d76-20210118 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 68215041; Mon, 18 Jan 2021 18:41:34 -0800 Received: from MTKMBS31N2.mediatek.inc (172.27.4.87) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 18 Jan 2021 18:33:18 -0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31N2.mediatek.inc (172.27.4.87) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 19 Jan 2021 10:33:15 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 19 Jan 2021 10:33:14 +0800 Message-ID: <1611023594.11995.4.camel@mhfsdcap03> Subject: Re: [PATCH v5] usb: xhci-mtk: fix unreleased bandwidth data From: Chunfeng Yun To: Ikjoon Jang Date: Tue, 19 Jan 2021 10:33:14 +0800 In-Reply-To: References: <20201229142406.v5.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid> <2aea44f0-85e7-fd55-2c35-c1d994f20e03@linux.intel.com> <1610086308.24856.30.camel@mhfsdcap03> <1610612988.30053.15.camel@mhfsdcap03> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: A6115A169AEB976A4B832476D0D8D2120FA2368B9779F77F46ED1A7ED5A498A62000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210118_214147_159563_D79B5463 X-CRM114-Status: GOOD ( 36.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Zhanyong Wang , Mathias Nyman , Greg Kroah-Hartman , linux-usb@vger.kernel.org, open list , Tianping Fang , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , Mathias Nyman , "moderated list:ARM/Mediatek SoC support" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 2021-01-15 at 10:51 +0800, Ikjoon Jang wrote: > On Thu, Jan 14, 2021 at 4:30 PM Chunfeng Yun wrote: > > > > Hi Ikjoon, > > > > On Tue, 2021-01-12 at 13:48 +0800, Ikjoon Jang wrote: > > > On Fri, Jan 8, 2021 at 10:44 PM Mathias Nyman > > > wrote: > > > > > > > > On 8.1.2021 8.11, Chunfeng Yun wrote: > > > > > On Thu, 2021-01-07 at 13:09 +0200, Mathias Nyman wrote: > > > > >> On 29.12.2020 8.24, Ikjoon Jang wrote: > > > > >>> xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci > > > > >>> to handle its own sw bandwidth managements and stores bandwidth data > > > > >>> into internal table every time add_endpoint() is called, > > > > >>> so when bandwidth allocation fails at one endpoint, all earlier > > > > >>> allocation from the same interface could still remain at the table. > > > > >>> > > > > >>> This patch adds two more hooks from check_bandwidth() and > > > > >>> reset_bandwidth(), and make mtk-xhci to releases all failed endpoints > > > > >>> from reset_bandwidth(). > > > > >>> > > > > >>> Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT") > > > > >>> Signed-off-by: Ikjoon Jang > > > > >>> > > > > >> > > > > >> ... > > > > >> > > > > >>> > > > > >>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > > > > >>> index d4a8d0efbbc4..e1fcd3cf723f 100644 > > > > >>> --- a/drivers/usb/host/xhci.c > > > > >>> +++ b/drivers/usb/host/xhci.c > > > > >>> @@ -2882,6 +2882,12 @@ static int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev) > > > > >>> xhci_dbg(xhci, "%s called for udev %p\n", __func__, udev); > > > > >>> virt_dev = xhci->devs[udev->slot_id]; > > > > >>> > > > > >>> + if (xhci->quirks & XHCI_MTK_HOST) { > > > > >>> + ret = xhci_mtk_check_bandwidth(hcd, udev); > > > > >>> + if (ret < 0) > > > > >>> + return ret; > > > > >>> + } > > > > >>> + > > > > >> > > > > >> Just noticed that XHCI_MTK_HOST quirk is only set in xhci-mtk.c. > > > > >> xhci-mtk.c calls xhci_init_driver(..., xhci_mtk_overrides) with a .reset override function. > > > > >> > > > > >> why not add override functions for .check_bandwidth and .reset_bandwidth to xhci_mtk_overrides instead? > > > > >> > > > > >> Another patch to add similar overrides for .add_endpoint and .drop_endpoint should probably be > > > > >> done so that we can get rid of the xhci_mtk_add/drop_ep_quirk() calls in xhci.c as well > > > > > You mean, we can export xhci_add/drop_endpoint()? > > > > > > > > I think so, unless you have a better idea. > > > > I prefer exporting the generic add/drop_endpoint functions rather than the vendor specific quirk functions. > > > > > > > > > > When moving out all MTK_HOST quirks and unlink xhci-mtk-sch from xhci, > > > xhci-mtk-sch still needs to touch the xhci internals, at least struct > > > xhci_ep_ctx. > > > > > > My naive idea is just let xhci export one more function to expose xhci_ep_ctx. > > > But I'm not sure whether this is acceptable: > > I find that xhci_add_endpoint() ignores some errors with return 0, for > > these cases we needn't call xhci_mtk_add_ep-quirk(), so may be not a > > good way to just export xhci_add_endpoint(). > > yeah, maybe that's from ep0 case? > > And I've thought that we could also unlink xhci-mtk-sch from the xhci module > if MTK_HOST quirk functions are moved out to mtk platform driver's overrides. > I guess I've gone too far. > > If we keep xhci-mtk-sch being built with the xhci module, > xhci-mtk-sch can directly access input control context and its drop/add flags, > so I think we can simply remove {add|drop}_endpoint() quirks and just handle > them all in {check|reset}_bandwidth() overrides. It's ok if check_bandwidth() could get added ep and update context. I'll spend some time to look at the code and test it. Thank you > > > > > > > > > +struct xhci_ep_ctx* xhci_get_ep_contex(struct xhci_hcd *xhci, struct > > > usb_host_endpoint *ep) > > > +{ ... } > > > +EXPORT_SYMBOL(xhci_get_ep_context); > > > > > > But for v6, I'm going to submit a patch with {check|reset}_bandwidth() > > > quirk function > > > switched into xhci_driver_overrides first. (and preserve existing > > > MTK_HOST quirk functions). > > > > > > Thanks! > > > > > > > -Mathias > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel