Re: [PATCH] staging: wilc1000: use kernel define byte order macros

[Robert Perry Hooker]

Well, yes, all data is 'endian' one way or another, right? I guess the byte 
order of the tx/rx_buffers is host-endian
(which could be big), or _maybe_ network-endian...

Regards,
Perry

On Thu, 2017-03-23 at 11:33 +0300, Dan Carpenter wrote:
> On Wed, Mar 22, 2017 at 07:53:28PM -0600, Robert Perry Hooker wrote:
> > I don't think buff is an ieee80211_hdr struct. I think it's the rx_buffer 
> > allocated at wilc_wlan.c:1417.
> > 
> 
> The rx_buffer is going to end up filled with endian data, right?
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: wilc1000: use kernel define byte order macros

[Robert Perry Hooker]

I don't think buff is an ieee80211_hdr struct. I think it's the rx_buffer 
allocated at wilc_wlan.c:1417.

Regards,
Perry

On Wed, 2017-03-22 at 12:24 +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 03:40:10PM -0600, Robert Perry Hooker wrote:
> > Thanks for taking a look, Dan. Sorry if I missed the mark here.
> > 
> > Can you tell me a bit more about the bug this would introduce?
> > 
> > I see that ieee80211_is_action is defined like this: static inline bool 
> > ieee80211_is_action(__le16 fc)
> > 
> > ...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID = 0).
> > 
> > Is there an issue with calling cpu_to_le16 on a u8 that isn't encountered 
> > by implicitly casting a u8 to __le16? Or 
> > am I
> > missing something else?
> > 
> 
> Oh...  Hm.  You're right.  I just was thinking that since buff was a
> little endian buffer but it's only reading a u8.  It should probably
> be reading a le16...  The buff likely is just a regular ieee80211_hdr
> struct.
> 
> So you're fixing a bug, but probably not in the right way.  We should
> instead just say "struct ieee80211_hdr *hdr = buff;" and instead of
> treating it like an array of u8.  Probably it requires testing...
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: wilc1000: use kernel define byte order macros

[Robert Perry Hooker]

Thanks for taking a look, Dan. Sorry if I missed the mark here.

Can you tell me a bit more about the bug this would introduce?

I see that ieee80211_is_action is defined like this: static inline bool 
ieee80211_is_action(__le16 fc)

...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID = 0).

Is there an issue with calling cpu_to_le16 on a u8 that isn't encountered by 
implicitly casting a u8 to __le16? Or am I
missing something else?

Regards,
Perry

On Tue, 2017-03-21 at 23:19 +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 01:55:40PM -0600, Perry Hooker wrote:
> > This commit fixes the following sparse warnings:
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:1473:45: warning: 
> > incorrect type in argument 1 (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2006:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2011:52: warning: 
> > incorrect type in assignment (different base > > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2012:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2078:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2083:52: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2084:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > 
> > Signed-off-by: Perry Hooker 
> > ---
> >  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +---
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > index a37896f..d1c75c7 100644
> > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > @@ -1470,7 +1470,7 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 
> > *buff, u32 size)
> > } else {
> > s32Freq = ieee80211_channel_to_frequency(curr_channel, 
> > NL80211_BAND_2GHZ);
> >  
> > -   if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > +   if (ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> 
> Nah...  You're just introducing bugs here.  Please be more careful.
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel