Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3564441pxj; Mon, 21 Jun 2021 01:20:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxM9+EU4GP01sk6wO/qczrM0S67LSytcQ4OOwY1/baI7B+AgZ6o5V8NH5ryowyUgJqhg81H X-Received: by 2002:a6b:fe09:: with SMTP id x9mr18303439ioh.111.1624263616760; Mon, 21 Jun 2021 01:20:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624263616; cv=none; d=google.com; s=arc-20160816; b=OuNH76CApP7LRtkxmSOVYtVaPkkHjF5CJb3FJ7A+pM55umgibqwfAuiFSR8A7k0KSv BQhOm6uaw+++ODsQWvY/iHQbtV3w8lhZfftJ+b7O3qy7+Oz7aGYOk5rC1xRBMLfGqUc4 fI58Rt2sVS3S2MonRpFou+MNNCZSqBe1XhHeRamlVXGRftFk4RqCkoowUc0J07yj8Og8 c8aa8KxRlDu4uA6PMsshkrW4daWLWeLGlBwtRlFYF+2FGs9ZRSGQ+8+bGDw3yp49vL4N zpJM8ThJTtVLYXYxEDsOq3CFv+FuVzEFVbGPHM6BxdykfvDILcaGtQO7Z7KzOVDRoZaR MrXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=qscjNuNnVvTSyC0lyL0nBXyt5ygw/o+jc/d7n35ADPE=; b=zGCvpVuIGCrs32EB38FIW/nYO737GBRn6fqh0bP+bEXHJKkGOYEHV/+19LkL1Euc1T tKj1wDu+XptK6LAzE98irNwOTan99ZyGnigaQZNSx7aRQT/0h2NFtB0pdKEaToT0H2LX J1vRROXf0SOVWEbY2vFMSihJnc4+PyQFmie40zobYFBzVBiZsyikZdrHEaZ/I7FbDvE2 ZksQyAtBUjiCby88Sm1rwvSuZ4AkH2TfZ58SbjIF5yDXEG6IC4XQ534yRDWnhPRJgy4g 93HSpUryoAvIf3cx9LA3qTPq3Neupmny4CXNhX+iKd2qicRGszc3jcs3Qb3/P56/aETp aNrg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i2si20911576iov.82.2021.06.21.01.20.04; Mon, 21 Jun 2021 01:20:16 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230235AbhFUIVT (ORCPT + 99 others); Mon, 21 Jun 2021 04:21:19 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:5058 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230229AbhFUIVP (ORCPT ); Mon, 21 Jun 2021 04:21:15 -0400 Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4G7j3M1VvFzXjHK; Mon, 21 Jun 2021 16:13:51 +0800 (CST) Received: from dggpemm500016.china.huawei.com (7.185.36.25) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 21 Jun 2021 16:18:53 +0800 Received: from [10.67.108.248] (10.67.108.248) by dggpemm500016.china.huawei.com (7.185.36.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 21 Jun 2021 16:18:53 +0800 Subject: Re: [PATCH] net: ethernet: ti: fix netdev_queue compiling error To: Grygorii Strashko , , , , , , CC: References: <20210617112838.143314-1-chenjiahao16@huawei.com> <6dbabec2-25df-7a4a-457f-d738479d36b1@ti.com> From: "chenjiahao (C)" Message-ID: Date: Mon, 21 Jun 2021 16:18:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <6dbabec2-25df-7a4a-457f-d738479d36b1@ti.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.108.248] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500016.china.huawei.com (7.185.36.25) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Thanks for the review. But still I have a little question in the helper you just mentioned: static inline int qdisc_avail_bulklimit(const struct netdev_queue *txq) { #ifdef CONFIG_BQL /* Non-BQL migrated drivers will return 0, too. */ return dql_avail(&txq->dql); #else return 0; #endif } In the snippet above, if CONFIG_BQL is not set, 0 will be simply returned and get printed. Should we distinguish this case, or just let it be? Sincerely, Jiahao Chen 在 2021/6/18 18:40, Grygorii Strashko 写道: > > > On 17/06/2021 14:28, Chen Jiahao wrote: >> There is a compiling error in am65-cpsw-nuss.c while not selecting >> CONFIG_BQL: >> >> drivers/net/ethernet/ti/am65-cpsw-nuss.c: In function >> ‘am65_cpsw_nuss_ndo_host_tx_timeout’: >> drivers/net/ethernet/ti/am65-cpsw-nuss.c:353:26: error: >> ‘struct netdev_queue’ has no member named ‘dql’ >>    353 |      dql_avail(&netif_txq->dql), >>        |                          ^~ >> >> This problem is solved by adding the #ifdef CONFIG_BQL directive >> where struct dql is used. >> >> Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit >> eth subsystem driver") >> Signed-off-by: Chen Jiahao >> --- >>   drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++ >>   1 file changed, 8 insertions(+) >> >> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c >> b/drivers/net/ethernet/ti/am65-cpsw-nuss.c >> index 6a67b026df0b..a0b30bb763ea 100644 >> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c >> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c >> @@ -346,12 +346,20 @@ static void >> am65_cpsw_nuss_ndo_host_tx_timeout(struct net_device *ndev, >>       tx_chn = &common->tx_chns[txqueue]; >>       trans_start = netif_txq->trans_start; >> +#ifdef CONFIG_BQL >>       netdev_err(ndev, "txq:%d DRV_XOFF:%d tmo:%u dql_avail:%d >> free_desc:%zu\n", >>              txqueue, >>              netif_tx_queue_stopped(netif_txq), >>              jiffies_to_msecs(jiffies - trans_start), >>              dql_avail(&netif_txq->dql), >>              k3_cppi_desc_pool_avail(tx_chn->desc_pool)); >> +#else >> +    netdev_err(ndev, "txq:%d DRV_XOFF:%d tmo:%u free_desc:%zu\n", >> +           txqueue, >> +           netif_tx_queue_stopped(netif_txq), >> +           jiffies_to_msecs(jiffies - trans_start), >> +           k3_cppi_desc_pool_avail(tx_chn->desc_pool)); >> +#endif >>       if (netif_tx_queue_stopped(netif_txq)) { >>           /* try recover if stopped by us */ >> > > Seems like there is right helper available - qdisc_avail_bulklimit(). > > Any way, it most probably has to be solved in generic way on netdev/dql > level. >