staging: wilc1000: use kernel define byte order macros

PATCH In review Perry Hooker 2 participants 9 messages Mar 21, 2017 – Apr 10, 2017 Staging

Share & tools

Perry Hooker

author

2017-03-21 20:03 UTC #0 lore raw

PATCH 1/1 staging: wilc1000: use kernel define byte order macros

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 <[email protected]>

---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +13 -7

index a37896f..d1c75c7 100644
@@ -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;
 		}

Signature · 1 line

2.4.11

Dan Carpenter

2017-03-21 20:19 UTC #1 lore raw

Quoted 19 lines · 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 <[email protected]>
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +0 -0
index a37896f..d1c75c7 100644

drivers/staging/wilc1000/wilc_wfi_cfgoperations.c void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, u32 size) · line 1473

Quoted 5 lines

drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +1 -1

@@ -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

Robert Perry Hooker

author

2017-03-21 21:40 UTC #2 lore raw

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

Quoted 37 lines · Dan Carpenter

Quoted 25 lines · 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 <[email protected]>
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +0 -0
index a37896f..d1c75c7 100644
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, u32 size) · line 1473
Quoted 5 lines
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +1 -1
@@ -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

Dan Carpenter

2017-03-22 09:26 UTC #3 lore raw

Quoted 11 lines · 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?

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

Robert Perry Hooker

author

2017-03-23 01:53 UTC #4 lore raw

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

Quoted 26 lines · Dan Carpenter

Quoted 4 lines · 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?
Quoted 8 lines
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

Dan Carpenter

2017-03-23 08:34 UTC #5 lore raw

Quoted 2 lines · 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.

The rx_buffer is going to end up filled with endian data, right?

regards,
dan carpenter

Robert Perry Hooker

author

2017-03-23 22:15 UTC #6 lore raw

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

Quoted 9 lines · Dan Carpenter

Quoted 2 lines · 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.
The rx_buffer is going to end up filled with endian data, right?
regards,
dan carpenter

Dan Carpenter

2017-03-24 08:58 UTC #7 lore raw

Quoted 2 lines · 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...

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

perry

author

2017-04-10 19:36 UTC #8 lore raw

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

Quoted 11 lines · Dan Carpenter

Quoted 3 lines · 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...
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