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

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

[Perry Hooker]

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 <perry.hooker@gmail.com>
---
 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]))) {
 			if (priv->bCfgScanning && time_after_eq(jiffies, (unsigned long)pstrWFIDrv->p2p_timeout)) {
 				netdev_dbg(dev, "Receiving action wrong ch\n");
 				return;
@@ -2003,13 +2003,16 @@ static int add_station(struct wiphy *wiphy, struct net_device *dev,
 			strStaParams.ht_supported = false;
 		} else {
 			strStaParams.ht_supported = true;
-			strStaParams.ht_capa_info = params->ht_capa->cap_info;
+			strStaParams.ht_capa_info =
+				le16_to_cpu(params->ht_capa->cap_info);
 			strStaParams.ht_ampdu_params = params->ht_capa->ampdu_params_info;
 			memcpy(strStaParams.ht_supp_mcs_set,
 			       &params->ht_capa->mcs,
 			       WILC_SUPP_MCS_SET_SIZE);
-			strStaParams.ht_ext_params = params->ht_capa->extended_ht_cap_info;
-			strStaParams.ht_tx_bf_cap = params->ht_capa->tx_BF_cap_info;
+			strStaParams.ht_ext_params =
+				le16_to_cpu(params->ht_capa->extended_ht_cap_info);
+			strStaParams.ht_tx_bf_cap =
+				le32_to_cpu(params->ht_capa->tx_BF_cap_info);
 			strStaParams.ht_ante_sel = params->ht_capa->antenna_selection_info;
 		}
 
@@ -2075,13 +2078,16 @@ static int change_station(struct wiphy *wiphy, struct net_device *dev,
 			strStaParams.ht_supported = false;
 		} else {
 			strStaParams.ht_supported = true;
-			strStaParams.ht_capa_info = params->ht_capa->cap_info;
+			strStaParams.ht_capa_info =
+				le16_to_cpu(params->ht_capa->cap_info);
 			strStaParams.ht_ampdu_params = params->ht_capa->ampdu_params_info;
 			memcpy(strStaParams.ht_supp_mcs_set,
 			       &params->ht_capa->mcs,
 			       WILC_SUPP_MCS_SET_SIZE);
-			strStaParams.ht_ext_params = params->ht_capa->extended_ht_cap_info;
-			strStaParams.ht_tx_bf_cap = params->ht_capa->tx_BF_cap_info;
+			strStaParams.ht_ext_params =
+				le16_to_cpu(params->ht_capa->extended_ht_cap_info);
+			strStaParams.ht_tx_bf_cap =
+				le32_to_cpu(params->ht_capa->tx_BF_cap_info);
 			strStaParams.ht_ante_sel = params->ht_capa->antenna_selection_info;
 		}
 
-- 
2.4.11

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

[Dan Carpenter]

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 <perry.hooker@gmail.com>
> ---
>  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

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 <perry.hooker@gmail.com>
> > ---
> >  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
> 

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

[Dan Carpenter]

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

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
> 

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

[Dan Carpenter]

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

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
> 

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

[Dan Carpenter]

On Thu, Mar 23, 2017 at 04:15:06PM -0600, Robert Perry Hooker wrote:
> 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...

The good news is this code is Open Source[tm] so we don't need to guess.
It's full of little endian data.

regards,
dan carpenter

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

[perry]

Hi Dan,

Can you clarify why the rx_buffer always holds little-endian data? It looks to me like this buffer is filled by
wilc_sdio_cmd53(), which uses sdio_memcpy_toio(), which ultimately sets the data with sg_set_buf(). This function
appears to use host-endian byte ordering.

Regards,
Perry

On Fri, 2017-03-24 at 11:57 +0300, Dan Carpenter wrote:
> On Thu, Mar 23, 2017 at 04:15:06PM -0600, Robert Perry Hooker wrote:
> > 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...
> 
> The good news is this code is Open Source[tm] so we don't need to guess.
> It's full of little endian data.
> 
> regards,
> dan carpenter
>