| Message ID | 20230523061952.204537-1-yi.fang.gan@intel.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1931965vqo;
Mon, 22 May 2023 23:28:31 -0700 (PDT)
X-Google-Smtp-Source:
ACHHUZ50IU2ocWYLB2LZ4bx/YM89uHIxG1yirpMUnvc9KNMvEc4cVk+iJ+uGMsrYA8iLcUUlg9KG
X-Received: by 2002:a05:6a21:78a4:b0:10a:dd89:420f with SMTP id
bf36-20020a056a2178a400b0010add89420fmr11088416pzc.6.1684823311374;
Mon, 22 May 2023 23:28:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1684823311; cv=none;
d=google.com; s=arc-20160816;
b=dFFjpiJZoCucZVaPUUjaDrSTZgyCKSoSDyKMUAne9ZAFtQaYaj7r/9xDAabMH7MwXd
YVPdLgK6HEODRkzDSg5M6TyRFub7dgNYNPGZb8iU5WUdYfbuNMLD5qVK0Qf+j+osN6JQ
vyxsk0k/OlmosVMFr+CmBKvEsLf10kl7blM25EW8Dsk58AJN6lPJQosvWPnLxVaS17f6
O41pLsAQ6gUHCcGc6qxPNq8ju+gITuzDo4Zgey1XG8JvjbG9G+eVEP+hEb9AN/teP8wP
LUbjrLcAzvdnkvT9HOUh4Ji5cYXXPcR2xHYm5818eJZ9TtXqMmDxcnDrdo+PvZlkTh/P
J0zA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-transfer-encoding:mime-version
:message-id:date:subject:cc:to:from:dkim-signature;
bh=XOwI9zzx3UJYobf96lJIEe8i6rhkj/gDLVlyWRH4kEo=;
b=OEljrTIUmETQc81aPt99rXTe9SLNrHF6yjvyv66MTZbdJLA43cQ0ZVEB7O/kLl3Z8N
29iEmlca1CiFG+p56qafwg1zjuC21WVVYAchiUn0HyduscXjYeOm2UW+SxYzCP9awIHU
4R6CYJk/YABzf1HWLQ30THDFaa6tnKVGgP/EBzTLOFJ39pWHY/4JgKuia2fWImn/ITFY
a/RCZeTPUbE0bJcMCuwtCFRx1bFb1Ey8q2erAuWD55T3Iehi+PYRZ4dtoEQ3Ukk1/rq2
nu1cji9hstBU8LDC5H+rKe4qwCEF2URCGZDdd+f/4/IwAtOqMr3lcUo7UfBz4bzDuiGG
0T1g==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@intel.com header.s=Intel header.b="cqq//bPa";
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
l187-20020a6391c4000000b00534873a6643si6054924pge.329.2023.05.22.23.28.16;
Mon, 22 May 2023 23:28:31 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
dkim=pass header.i=@intel.com header.s=Intel header.b="cqq//bPa";
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S232059AbjEWGUa (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com>
+ 99 others); Tue, 23 May 2023 02:20:30 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60098 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S235200AbjEWGUX (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 23 May 2023 02:20:23 -0400
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23A721BD;
Mon, 22 May 2023 23:20:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1684822812; x=1716358812;
h=from:to:cc:subject:date:message-id:mime-version:
content-transfer-encoding;
bh=kv+U3eR2t5jXrzu7bhE+tT5rUsZNuQI3uVH6Dk7rusQ=;
b=cqq//bPah+oPEEmq1hxULMMLI4G6PPUbCiHkVNhPS5mYyZL4iXjtQ7ZK
5OGeEJi85vAegfpZItWyyqOxexWJZDV584CYn12RM1Dj1i3C8CRNMZHqW
RhOKe7oNzhpOaA3TwHV3EBM44rfnCapY2dfSWU/SQp4osOSwyJfSQM5U+
CfFYiUgwcGidEC0KrFLviFyBVBqKZ7FMBxKfE7wzibnRnlWrbZ3KVm3ee
ESxc0eJFbWTfwD+sm/viGdkWHj0PnGw6zESeImh8mZj8dGPEdlvwim+GT
pvlmzVxgXozOwwEEIfXbVxsvJLafeFah0Xt7rSaIjQUWKpNzIDcuT89Lg
g==;
X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="351994164"
X-IronPort-AV: E=Sophos;i="6.00,185,1681196400";
d="scan'208";a="351994164"
Received: from orsmga008.jf.intel.com ([10.7.209.65])
by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
22 May 2023 23:20:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="734636085"
X-IronPort-AV: E=Sophos;i="6.00,185,1681196400";
d="scan'208";a="734636085"
Received: from ganyifangubuntu20-ilbpg12.png.intel.com ([10.88.229.31])
by orsmga008.jf.intel.com with ESMTP; 22 May 2023 23:20:07 -0700
From: Gan Yi Fang <yi.fang.gan@intel.com>
To: Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Jose Abreu <joabreu@synopsys.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
Looi Hong Aun <hong.aun.looi@intel.com>,
Michael Sit Wei Hong <michael.wei.hong.sit@intel.com>,
Gan Yi Fang <yi.fang.gan@intel.com>
Subject: [PATCH net-next 1/1] net: stmmac: Remove redundant checking for
rx_coalesce_usecs
Date: Tue, 23 May 2023 02:19:52 -0400
Message-Id: <20230523061952.204537-1-yi.fang.gan@intel.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-4.1 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00,
DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,
URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1766656284735286799?=
X-GMAIL-MSGID: =?utf-8?q?1766665288202238491?=
|
| Series |
[net-next,1/1] net: stmmac: Remove redundant checking for rx_coalesce_usecs
|
|
Commit Message
Gan, Yi Fang
May 23, 2023, 6:19 a.m. UTC
The datatype of rx_coalesce_usecs is u32, always larger or equal to zero.
Previous checking does not include value 0, this patch removes the
checking to handle the value 0.
Signed-off-by: Gan Yi Fang <yi.fang.gan@intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, May 23, 2023 at 02:19:52AM -0400, Gan Yi Fang wrote: > The datatype of rx_coalesce_usecs is u32, always larger or equal to zero. > Previous checking does not include value 0, this patch removes the > checking to handle the value 0. > > Signed-off-by: Gan Yi Fang <yi.fang.gan@intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com>
On Tue, May 23, 2023 at 02:19:52AM -0400, Gan Yi Fang wrote: > The datatype of rx_coalesce_usecs is u32, always larger or equal to zero. > Previous checking does not include value 0, this patch removes the > checking to handle the value 0. > > Signed-off-by: Gan Yi Fang <yi.fang.gan@intel.com> > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c > index 35c8dd92d369..6ed0e683b5e0 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c > @@ -917,7 +917,7 @@ static int __stmmac_set_coalesce(struct net_device *dev, > else if (queue >= max_cnt) > return -EINVAL; > > - if (priv->use_riwt && (ec->rx_coalesce_usecs > 0)) { > + if (priv->use_riwt) { > rx_riwt = stmmac_usec2riwt(ec->rx_coalesce_usecs, priv); > > if ((rx_riwt > MAX_DMA_RIWT) || (rx_riwt < MIN_DMA_RIWT)) This appears to be a user visible ABI change. For the current code, a value of zero here is ignored, and 0 is returned. With this change, 0 will result in rx_riwt being calculated as 0, which is less than MIN_DMA_RIWT, so you get -EINVAL returned. I don't know this uAPI too well. What values are passed to this function for: ethtool -C eth24 tx-usecs 42 where you only want to change transmit coalesce? Is rx_usecs 0? At minimum you need to explain in the commit message: "This change in behaviour making the value of 0 cause an error is not a problem because...." Andrew --- pw-bot: cr
Hi Andrew, Thank you for your feedback. I will submit V2 to update the commit message. The value of rx-usecs will not be affected when the tx-usecs is set. When the command "ethtool -C eth24 tx-usecs 42" is applied, the value of rx-usecs is remaining the same as previously. Best Regards, Gan Yi Fang > -----Original Message----- > From: Andrew Lunn <andrew@lunn.ch> > Sent: Tuesday, May 23, 2023 8:48 PM > To: Gan, Yi Fang <yi.fang.gan@intel.com> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>; Alexandre Torgue > <alexandre.torgue@st.com>; Jose Abreu <joabreu@synopsys.com>; David S . > Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub > Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Maxime > Coquelin <mcoquelin.stm32@gmail.com>; netdev@vger.kernel.org; linux- > stm32@st-md-mailman.stormreply.com; linux-arm-kernel@lists.infradead.org; > linux-kernel@vger.kernel.org; Looi, Hong Aun <hong.aun.looi@intel.com>; Sit, > Michael Wei Hong <michael.wei.hong.sit@intel.com> > Subject: Re: [PATCH net-next 1/1] net: stmmac: Remove redundant checking for > rx_coalesce_usecs > > On Tue, May 23, 2023 at 02:19:52AM -0400, Gan Yi Fang wrote: > > The datatype of rx_coalesce_usecs is u32, always larger or equal to zero. > > Previous checking does not include value 0, this patch removes the > > checking to handle the value 0. > > > > Signed-off-by: Gan Yi Fang <yi.fang.gan@intel.com> > > --- > > drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c > > b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c > > index 35c8dd92d369..6ed0e683b5e0 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c > > @@ -917,7 +917,7 @@ static int __stmmac_set_coalesce(struct net_device > *dev, > > else if (queue >= max_cnt) > > return -EINVAL; > > > > - if (priv->use_riwt && (ec->rx_coalesce_usecs > 0)) { > > + if (priv->use_riwt) { > > rx_riwt = stmmac_usec2riwt(ec->rx_coalesce_usecs, priv); > > > > if ((rx_riwt > MAX_DMA_RIWT) || (rx_riwt < > MIN_DMA_RIWT)) > > This appears to be a user visible ABI change. For the current code, a value of > zero here is ignored, and 0 is returned. With this change, 0 will result in rx_riwt > being calculated as 0, which is less than MIN_DMA_RIWT, so you get -EINVAL > returned. > > I don't know this uAPI too well. What values are passed to this function for: > > ethtool -C eth24 tx-usecs 42 > > where you only want to change transmit coalesce? Is rx_usecs 0? > > At minimum you need to explain in the commit message: "This change in > behaviour making the value of 0 cause an error is not a problem because...." > > Andrew > > --- > pw-bot: cr
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c index 35c8dd92d369..6ed0e683b5e0 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c @@ -917,7 +917,7 @@ static int __stmmac_set_coalesce(struct net_device *dev, else if (queue >= max_cnt) return -EINVAL; - if (priv->use_riwt && (ec->rx_coalesce_usecs > 0)) { + if (priv->use_riwt) { rx_riwt = stmmac_usec2riwt(ec->rx_coalesce_usecs, priv); if ((rx_riwt > MAX_DMA_RIWT) || (rx_riwt < MIN_DMA_RIWT))