Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2974503pxb; Tue, 12 Jan 2021 03:18:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJzfaBqmRSCBDaB2utjI7gJYpsYQoKb2KidDTgDzpaH5fiJ21wiIqHwPz5CA7O4OLpUpRls7 X-Received: by 2002:aa7:cb12:: with SMTP id s18mr2982319edt.125.1610450331706; Tue, 12 Jan 2021 03:18:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610450331; cv=none; d=google.com; s=arc-20160816; b=UFBkj/iUYy3H7b+gNo9DUDuSKAwAgeHnAZZ4n4e4IfMb3OO0WsCW5A+hY/5fQGC12N Er7cyKtzd/H1SUR7bwzZ/Yow1qt/eh8DgHJRLSg3dRe9F01Luh+VoKrE4NUCs+jaOQk9 MT/qEyFW/g4z3IvHBLJ/d8mmTr4ZpRKvAB3Ul+b+18LPTDd4cwAx5i6Gk9SNa9jybCLy 0xUq2RlNAgr29B3EndZEz04iYDp2ux/I0jKcuyh1ItWBe1RY9JdQaHuVtF5d4LUkh8o0 UBboh0jq2b3oNqdJvMwT05FbGy0f7bLJE4pQlGzcEH35c4sxobOQZ9qwTdUWQ5uCwO+/ Vk5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=z+UuZJMzg7vrix92H8yNvymjWYn4v4tuh1SrKJzSLm8=; b=WH+4FUgUKXkDih0Tm8adF9/On/i7reS/WKKrU4jPwZDCKh2JnATNw9Vuvc/1LHxd7Q fhEtwCOYAGxzsbO1VxDNfaQ5Nbv1mt3z2OWRSNxMNkxAZj58P269IxL+2cB8OqKWf7+i 459nntqdg0R9o4EHzaB+IYJOCYsX66wR64l+UbNbcPoQbOLU5gwMdcRzgpErZ91oWtUT iqLL4iWjDkCLuPg/WyXI7I0GW56D0kz+NdNiPOn+dVve4DBEudE+cYePRy6g4piScNl5 aDBZdorR9JPa6z7YoRsqTapAn3II4SmSw1DZK7myt/xYeOrvuXfSOLK9A+xZpM636/Ip qBGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=JQsTmcLP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v24si1221208eda.114.2021.01.12.03.18.27; Tue, 12 Jan 2021 03:18:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=JQsTmcLP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727847AbhALFtc (ORCPT + 99 others); Tue, 12 Jan 2021 00:49:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728515AbhALFtb (ORCPT ); Tue, 12 Jan 2021 00:49:31 -0500 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F60EC061786 for ; Mon, 11 Jan 2021 21:48:51 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id b8so832923plx.0 for ; Mon, 11 Jan 2021 21:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z+UuZJMzg7vrix92H8yNvymjWYn4v4tuh1SrKJzSLm8=; b=JQsTmcLPoTaeeli611Tt6mGBNg5TJNkKTfXLDKVEnoX/OOqLNikQE4Ip2Rw6MA9Yuz KemfmMaptOX/ZNgHeDXdIN72y0gMJ44Dj2zLYwZ6eAwiDN9a7SPJjT4Vn3yO4vLV00pL DOY6W8keINeAjRVcriy8igeimSynyNmMITakQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z+UuZJMzg7vrix92H8yNvymjWYn4v4tuh1SrKJzSLm8=; b=kYk/AALWAx1bRfeIClU95ORUx8zV8QUAGNSt2eKeCijbN7murMJazSk4YWZnG4+ufe MbWXNKxDSNzuF6bJYBgtYuTdxun47yNoDuNpjIrlgOzl2oXusT2f9bD0HRQUqaRtOBS8 qMJk5BZZyigXeH7z2184gTCXt3Lt+qBONfLPPsEHljpJRQLwXTSpZcs42dfZw2R5hl/6 bhanPgL24zklLJ4gj8/lN1Kcw5V/ySFJyoHedmfsvSBpXefyctQj7nm3HQELORYyLxPz b3vUh1RETqtbW1nYZdOnh1AKDE+An7vEVhe64pM84UocAk7a5kPx9qOdab9f5rW1QyhL CfDw== X-Gm-Message-State: AOAM530GgO9JlPKQoXtVNf8VlXhuW7vULBUAVyiHtwczY8XgOrAzmLmX abV9a9AnBfSBdt9mKYMYB0g6o57nfYXL1LkboyBn3w== X-Received: by 2002:a17:902:a501:b029:dc:3e1d:4ddb with SMTP id s1-20020a170902a501b02900dc3e1d4ddbmr3151522plq.60.1610430530661; Mon, 11 Jan 2021 21:48:50 -0800 (PST) MIME-Version: 1.0 References: <20201229142406.v5.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid> <2aea44f0-85e7-fd55-2c35-c1d994f20e03@linux.intel.com> <1610086308.24856.30.camel@mhfsdcap03> In-Reply-To: From: Ikjoon Jang Date: Tue, 12 Jan 2021 13:48:39 +0800 Message-ID: Subject: Re: [PATCH v5] usb: xhci-mtk: fix unreleased bandwidth data To: Mathias Nyman Cc: Chunfeng Yun , "moderated list:ARM/Mediatek SoC support" , linux-usb@vger.kernel.org, Tianping Fang , Zhanyong Wang , Greg Kroah-Hartman , Mathias Nyman , Matthias Brugger , "moderated list:ARM/Mediatek SoC support" , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: +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 >