Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424861AbdD3Q0Q (ORCPT ); Sun, 30 Apr 2017 12:26:16 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36187 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033985AbdD3Q0I (ORCPT ); Sun, 30 Apr 2017 12:26:08 -0400 From: Karim Eshapa To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, Karim Eshapa Subject: RE:[PATCH] drivers:staging:wlan-ng:hfa384x_usb: Fixing sparse warnings. Date: Sun, 30 Apr 2017 18:26:00 +0200 Message-Id: <1493569560-6466-1-git-send-email-karim.eshapa@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1493223340-13794-1-git-send-email-karim.eshapa@gmail.com> References: <1493223340-13794-1-git-send-email-karim.eshapa@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1777 Lines: 39 On Fri, 28 Apr 2017 12:02:58 +0200, Greg KH wrote: > On Wed, Apr 26, 2017 at 06:15:40PM +0200, Karim Eshapa wrote: > >> Fixing sparse warnings incorrect type assignment. >> >> Signed-off-by: Karim Eshapa >> --- >> drivers/staging/wlan-ng/hfa384x_usb.c | 24 ++++++++++++++---------- >> 1 file changed, 14 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c b/drivers/staging/wlan-ng/hfa384x_usb.c >> index 6134eba..cf6bf65 100644 >> --- a/drivers/staging/wlan-ng/hfa384x_usb.c >> +++ b/drivers/staging/wlan-ng/hfa384x_usb.c >> @@ -3511,20 +3511,24 @@ static void hfa384x_int_rxmonitor(struct wlandevice *wlandev, >> datap = skb_put(skb, sizeof(struct p80211_caphdr)); >> caphdr = (struct p80211_caphdr *)datap; >> >> - caphdr->version = htonl(P80211CAPTURE_VERSION); >> - caphdr->length = htonl(sizeof(struct p80211_caphdr)); >> + caphdr->version = __be32_to_cpu(htonl(P80211CAPTURE_VERSION)); >> + caphdr->length = __be32_to_cpu( htonl(sizeof( >> + struct p80211_caphdr))); >> > How do you know this is correct? And why the odd ' ' usage? I can't > take this patch for that reason alone... > Actually using __be32_to_cpu may result in a problem if it's built for le machine. becasue if the network byte order needs to be represented in __be32 such that the header is going through the network in a right order. So, I suggest if we can change the structure's args type into __be32 that I don't trust it if it can force the arg to be big endian as it's defined as __attribute__((bitwise)) that I'm not sure if it's GNU C attribute. that I didn't want from the beginning. Thanks, Karim