| Message ID | 595559852924cc1b58778659d2dbca8e263ee9d8.1666011479.git.drv@mailo.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1464650wrs;
Mon, 17 Oct 2022 07:03:37 -0700 (PDT)
X-Google-Smtp-Source:
AMsMyM7JczcyRQlzpR0LQTrrw7NBfU+RUsWBnSc0ZTF6TaPtZe4bBIOhEoPOznaUPM2xyrkOrLT1
X-Received: by 2002:a17:907:2cd9:b0:78d:9e76:be26 with SMTP id
hg25-20020a1709072cd900b0078d9e76be26mr8656950ejc.315.1666015417090;
Mon, 17 Oct 2022 07:03:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1666015417; cv=none;
d=google.com; s=arc-20160816;
b=MX/SUg/1dYlhXl0USK8DHWLGr6Idm4+4ix5vJOYYmQyvE4rBUG29/GuXhb+QHshi1c
LU7q0w72pODS99FBnT7EWd3SLDuP9dZ2VVnzprGtcf9gKeiGv+nZS7du4qptOWOsPEnK
lHVRJ/hUP3mlNPuLrPtR9xXcrdR1zsUPvFs4d7HM+f+Pb7wfEJOjIa/IDDEk1GX9hCot
DE06yyd0rmyUd6nU3BxQoo62iE99oiv/wZs2nrzD9OppsvtswkSbG9eR/X0P1EbDt9pK
VdWHQEET5FkIaYcWpGnbNmufIW2l57+uVwskECAzsayIWbOF10qIpDjK41l9nq46b+Jq
sYiQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:dkim-signature;
bh=z3JqR+FrwRLBd6TK7u6sxYTKEMECr2tbf/8wNirnYMI=;
b=Za8tbJgeKEMN4hFxso+/8VEzLUvnqRnqisJDP9OUMw2r2KHj1+XY7X3MPCFJWvM2wO
pb3Ee+oGIOFaOrFFex9g27DFrVXzx0zNp+U84UZQW4DxjRNP3pSBVZ7NnwRQTeTB59OO
4/AGKXFIUAjJmWL+P0a1/+EvgNLtDtfLtEW7egeilrpAvFUfDwK7ZtrwaY2hdBOPekww
GymAsCZMYY//f3PAINx8rWcBR/nMD/2kqibSCbnsmZX2M71uzot1Z5d4YWpnrR6gA5Ww
ccwT8v1S0iOINwV5rirhCWY7bON2Ht/JjC/2nLPWCCCL58zhqP71x2VONTc0nkv917fR
Norg==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=fail header.i=@mailo.com header.s=mailo header.b=m12rP1zZ;
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=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
ht12-20020a170907608c00b0073da19d0cdasi9304330ejc.973.2022.10.17.07.02.06;
Mon, 17 Oct 2022 07:03:37 -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=fail header.i=@mailo.com header.s=mailo header.b=m12rP1zZ;
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=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S229691AbiJQNyE (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others);
Mon, 17 Oct 2022 09:54:04 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55884 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S229913AbiJQNyB (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Mon, 17 Oct 2022 09:54:01 -0400
Received: from msg-4.mailo.com (msg-4.mailo.com [213.182.54.15])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9583437431
for <linux-kernel@vger.kernel.org>;
Mon, 17 Oct 2022 06:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo;
t=1666014825; bh=yto/l1lyLDHKlg80DQzPoJMZv1MlSDpRPOIfnKmwexM=;
h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References:
MIME-Version:Content-Type:In-Reply-To;
b=m12rP1zZOzS6Ghc0a/VVGajyRURzCP/lhvNUvqprvfO6eHRur83EUcI4SsggNX1Lu
lcoCtPOMtD3kGlw3tKB0aLrPOWK/dFG3tiJ48p/7uc9oc/3HA8nRnIE9f3RwdmnolD
tA0ht+keLWgynPVKt6SohYo0P7KM/iB5gr22Rr+0=
Received: by b-3.in.mailobj.net [192.168.90.13] with ESMTP
via [213.182.55.206]
Mon, 17 Oct 2022 15:53:45 +0200 (CEST)
X-EA-Auth:
J+Gjj6U9qBUSFbOzvtoxK/8I+/Kqe6dpy1Kyzts/HqVGDvcxnsz5SAW4MqYLaUVhkhDbl1Y4Fke8hF5bvPgWF33YGJCaoTvm
Date: Mon, 17 Oct 2022 18:54:11 +0530
From: Deepak R Varma <drv@mailo.com>
To: outreachy@lists.linux.dev, Larry.Finger@lwfinger.net,
phil@philpotter.co.uk, paskripkin@gmail.com,
gregkh@linuxfoundation.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Cc: kumarpraveen@linux.microsoft.com, saurabh.truth@gmail.com
Subject: [PATCH 4/4] staging: r8188eu: use htons macro instead of
__constant_htons
Message-ID:
<595559852924cc1b58778659d2dbca8e263ee9d8.1666011479.git.drv@mailo.com>
References: <cover.1666011479.git.drv@mailo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cover.1666011479.git.drv@mailo.com>
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS
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?1746943781955556810?=
X-GMAIL-MSGID: =?utf-8?q?1746943781955556810?=
|
| Series |
staging: r8188eu: trivial code cleanup patches
|
|
Commit Message
Deepak R Varma
Oct. 17, 2022, 1:24 p.m. UTC
Macro "htons" is more efficiant and clearer. It should be used for
constants instead of the __contast_htons macro. Resolves following
checkpatch script complaint:
WARNING: __constant_htons should be htons
Signed-off-by: Deepak R Varma <drv@mailo.com>
---
drivers/staging/r8188eu/core/rtw_br_ext.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.30.2
Comments
On Mon, 2022-10-17 at 18:54 +0530, Deepak R Varma wrote: > Macro "htons" is more efficiant and clearer. It should be used for > constants instead of the __contast_htons macro. Resolves following typo: __constant_htons > checkpatch script complaint: > WARNING: __constant_htons should be htons [] > diff --git a/drivers/staging/r8188eu/core/rtw_br_ext.c b/drivers/staging/r8188eu/core/rtw_br_ext.c [] > @@ -612,14 +612,14 @@ void dhcp_flag_bcast(struct adapter *priv, struct sk_buff *skb) > if (!priv->ethBrExtInfo.dhcp_bcst_disable) { > __be16 protocol = *((__be16 *)(skb->data + 2 * ETH_ALEN)); > > - if (protocol == __constant_htons(ETH_P_IP)) { /* IP */ > + if (protocol == htons(ETH_P_IP)) { /* IP */ > struct iphdr *iph = (struct iphdr *)(skb->data + ETH_HLEN); > > if (iph->protocol == IPPROTO_UDP) { /* UDP */ > struct udphdr *udph = (struct udphdr *)((size_t)iph + (iph->ihl << 2)); > > - if ((udph->source == __constant_htons(CLIENT_PORT)) && > - (udph->dest == __constant_htons(SERVER_PORT))) { /* DHCP request */ > + if ((udph->source == htons(CLIENT_PORT)) && > + (udph->dest == htons(SERVER_PORT))) { /* DHCP request */ OK, this bit seems fine > struct dhcpMessage *dhcph = > (struct dhcpMessage *)((size_t)udph + sizeof(struct udphdr)); IMO: this existing code however is ugly. Casting a pointer to a size_t isn't great. Perhaps: struct dhcpMessage *dhcp; dhcp = (void *)udhp + sizeof(struct udphdr); in a separate patch. > u32 cookie = be32_to_cpu((__be32)dhcph->cookie); And dhcph->cookie already is a __be32 so the cast is pointless. drivers/staging/r8188eu/core/rtw_br_ext.c-598- __be32 cookie;
On Tue, Oct 18, 2022 at 11:08:06PM -0700, Joe Perches wrote: > On Mon, 2022-10-17 at 18:54 +0530, Deepak R Varma wrote: > > Macro "htons" is more efficiant and clearer. It should be used for > > constants instead of the __contast_htons macro. Resolves following > > typo: __constant_htons > > > checkpatch script complaint: > > WARNING: __constant_htons should be htons > [] > > diff --git a/drivers/staging/r8188eu/core/rtw_br_ext.c b/drivers/staging/r8188eu/core/rtw_br_ext.c > [] > > @@ -612,14 +612,14 @@ void dhcp_flag_bcast(struct adapter *priv, struct sk_buff *skb) > > if (!priv->ethBrExtInfo.dhcp_bcst_disable) { > > __be16 protocol = *((__be16 *)(skb->data + 2 * ETH_ALEN)); > > > > - if (protocol == __constant_htons(ETH_P_IP)) { /* IP */ > > + if (protocol == htons(ETH_P_IP)) { /* IP */ > > struct iphdr *iph = (struct iphdr *)(skb->data + ETH_HLEN); > > > > if (iph->protocol == IPPROTO_UDP) { /* UDP */ > > struct udphdr *udph = (struct udphdr *)((size_t)iph + (iph->ihl << 2)); > > > > - if ((udph->source == __constant_htons(CLIENT_PORT)) && > > - (udph->dest == __constant_htons(SERVER_PORT))) { /* DHCP request */ > > + if ((udph->source == htons(CLIENT_PORT)) && > > + (udph->dest == htons(SERVER_PORT))) { /* DHCP request */ > > OK, this bit seems fine > > > struct dhcpMessage *dhcph = > > (struct dhcpMessage *)((size_t)udph + sizeof(struct udphdr)); > > IMO: this existing code however is ugly. > Casting a pointer to a size_t isn't great. > > Perhaps: > > struct dhcpMessage *dhcp; > > dhcp = (void *)udhp + sizeof(struct udphdr); > > in a separate patch. > > > u32 cookie = be32_to_cpu((__be32)dhcph->cookie); > > And dhcph->cookie already is a __be32 so the cast is pointless. > > drivers/staging/r8188eu/core/rtw_br_ext.c-598- __be32 cookie; Thank you Joe. I will include this code clean up as separates patches are resend the patch set. > >
On Tue, Oct 18, 2022 at 11:08:06PM -0700, Joe Perches wrote: > On Mon, 2022-10-17 at 18:54 +0530, Deepak R Varma wrote: > > Macro "htons" is more efficiant and clearer. It should be used for > > constants instead of the __contast_htons macro. Resolves following > > typo: __constant_htons > > > checkpatch script complaint: > > WARNING: __constant_htons should be htons > [] > > diff --git a/drivers/staging/r8188eu/core/rtw_br_ext.c b/drivers/staging/r8188eu/core/rtw_br_ext.c > [] > > @@ -612,14 +612,14 @@ void dhcp_flag_bcast(struct adapter *priv, struct sk_buff *skb) > > if (!priv->ethBrExtInfo.dhcp_bcst_disable) { > > __be16 protocol = *((__be16 *)(skb->data + 2 * ETH_ALEN)); > > > > - if (protocol == __constant_htons(ETH_P_IP)) { /* IP */ > > + if (protocol == htons(ETH_P_IP)) { /* IP */ > > struct iphdr *iph = (struct iphdr *)(skb->data + ETH_HLEN); > > > > if (iph->protocol == IPPROTO_UDP) { /* UDP */ > > struct udphdr *udph = (struct udphdr *)((size_t)iph + (iph->ihl << 2)); > > > > - if ((udph->source == __constant_htons(CLIENT_PORT)) && > > - (udph->dest == __constant_htons(SERVER_PORT))) { /* DHCP request */ > > + if ((udph->source == htons(CLIENT_PORT)) && > > + (udph->dest == htons(SERVER_PORT))) { /* DHCP request */ > > OK, this bit seems fine > > > struct dhcpMessage *dhcph = > > (struct dhcpMessage *)((size_t)udph + sizeof(struct udphdr)); > > IMO: this existing code however is ugly. > Casting a pointer to a size_t isn't great. Hello Joe, Other thank looking ugly, is there any impact / risk associated with such casting? I tried to look for the reasons myself but did not find anything relevant or to the point. Thank you, ./drv > > Perhaps: > > struct dhcpMessage *dhcp; > > dhcp = (void *)udhp + sizeof(struct udphdr); > > in a separate patch. > > > u32 cookie = be32_to_cpu((__be32)dhcph->cookie); > > And dhcph->cookie already is a __be32 so the cast is pointless. > > drivers/staging/r8188eu/core/rtw_br_ext.c-598- __be32 cookie; >
diff --git a/drivers/staging/r8188eu/core/rtw_br_ext.c b/drivers/staging/r8188eu/core/rtw_br_ext.c index 290affe50d0b..334360de23da 100644 --- a/drivers/staging/r8188eu/core/rtw_br_ext.c +++ b/drivers/staging/r8188eu/core/rtw_br_ext.c @@ -612,14 +612,14 @@ void dhcp_flag_bcast(struct adapter *priv, struct sk_buff *skb) if (!priv->ethBrExtInfo.dhcp_bcst_disable) { __be16 protocol = *((__be16 *)(skb->data + 2 * ETH_ALEN)); - if (protocol == __constant_htons(ETH_P_IP)) { /* IP */ + if (protocol == htons(ETH_P_IP)) { /* IP */ struct iphdr *iph = (struct iphdr *)(skb->data + ETH_HLEN); if (iph->protocol == IPPROTO_UDP) { /* UDP */ struct udphdr *udph = (struct udphdr *)((size_t)iph + (iph->ihl << 2)); - if ((udph->source == __constant_htons(CLIENT_PORT)) && - (udph->dest == __constant_htons(SERVER_PORT))) { /* DHCP request */ + if ((udph->source == htons(CLIENT_PORT)) && + (udph->dest == htons(SERVER_PORT))) { /* DHCP request */ struct dhcpMessage *dhcph = (struct dhcpMessage *)((size_t)udph + sizeof(struct udphdr)); u32 cookie = be32_to_cpu((__be32)dhcph->cookie);