[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1AWcq2-_aZjWpvE0KeXZGornqQKeRx2oExK05a05bs2A@mail.gmail.com>
Date: Sun, 7 May 2017 20:39:37 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Karim Eshapa <karim.eshapa@...il.com>
Cc: gregkh <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers:staging:wlan-ng:hfa384x_usb: Fixing sparse warnings.
On Sun, Apr 30, 2017 at 6:26 PM, Karim Eshapa <karim.eshapa@...il.com> wrote:
> 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 <karim.eshapa@...il.com>
>>> ---
>>> 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.
It sounds like the correct fix would be to change the type of the members
in p80211_caphdr.
Arnd
Powered by blists - more mailing lists