* [PATCH] staging: wilc1000: use kernel define byte order macros
@ 2017-03-21 19:55 Perry Hooker
2017-03-21 20:19 ` Dan Carpenter
0 siblings, 1 reply; 9+ messages in thread
From: Perry Hooker @ 2017-03-21 19:55 UTC (permalink / raw)
To: gregkh; +Cc: aditya.shankar, ganesh.krishna, devel, linux-kernel, 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,
¶ms->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,
¶ms->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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-21 19:55 [PATCH] staging: wilc1000: use kernel define byte order macros Perry Hooker
@ 2017-03-21 20:19 ` Dan Carpenter
2017-03-21 21:40 ` Robert Perry Hooker
0 siblings, 1 reply; 9+ messages in thread
From: Dan Carpenter @ 2017-03-21 20:19 UTC (permalink / raw)
To: Perry Hooker; +Cc: gregkh, devel, aditya.shankar, linux-kernel, ganesh.krishna
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-21 20:19 ` Dan Carpenter
@ 2017-03-21 21:40 ` Robert Perry Hooker
2017-03-22 9:24 ` Dan Carpenter
0 siblings, 1 reply; 9+ messages in thread
From: Robert Perry Hooker @ 2017-03-21 21:40 UTC (permalink / raw)
To: Dan Carpenter; +Cc: gregkh, devel, aditya.shankar, linux-kernel, ganesh.krishna
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-21 21:40 ` Robert Perry Hooker
@ 2017-03-22 9:24 ` Dan Carpenter
2017-03-23 1:53 ` Robert Perry Hooker
0 siblings, 1 reply; 9+ messages in thread
From: Dan Carpenter @ 2017-03-22 9:24 UTC (permalink / raw)
To: Robert Perry Hooker
Cc: devel, gregkh, ganesh.krishna, linux-kernel, aditya.shankar
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-22 9:24 ` Dan Carpenter
@ 2017-03-23 1:53 ` Robert Perry Hooker
2017-03-23 8:33 ` Dan Carpenter
0 siblings, 1 reply; 9+ messages in thread
From: Robert Perry Hooker @ 2017-03-23 1:53 UTC (permalink / raw)
To: Dan Carpenter; +Cc: devel, gregkh, ganesh.krishna, linux-kernel, aditya.shankar
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-23 1:53 ` Robert Perry Hooker
@ 2017-03-23 8:33 ` Dan Carpenter
2017-03-23 22:15 ` Robert Perry Hooker
0 siblings, 1 reply; 9+ messages in thread
From: Dan Carpenter @ 2017-03-23 8:33 UTC (permalink / raw)
To: Robert Perry Hooker
Cc: devel, gregkh, ganesh.krishna, linux-kernel, aditya.shankar
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-23 8:33 ` Dan Carpenter
@ 2017-03-23 22:15 ` Robert Perry Hooker
2017-03-24 8:57 ` Dan Carpenter
0 siblings, 1 reply; 9+ messages in thread
From: Robert Perry Hooker @ 2017-03-23 22:15 UTC (permalink / raw)
To: Dan Carpenter; +Cc: devel, gregkh, ganesh.krishna, linux-kernel, aditya.shankar
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-23 22:15 ` Robert Perry Hooker
@ 2017-03-24 8:57 ` Dan Carpenter
2017-04-10 19:36 ` perry
0 siblings, 1 reply; 9+ messages in thread
From: Dan Carpenter @ 2017-03-24 8:57 UTC (permalink / raw)
To: Robert Perry Hooker
Cc: devel, gregkh, aditya.shankar, linux-kernel, ganesh.krishna
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] staging: wilc1000: use kernel define byte order macros
2017-03-24 8:57 ` Dan Carpenter
@ 2017-04-10 19:36 ` perry
0 siblings, 0 replies; 9+ messages in thread
From: perry @ 2017-04-10 19:36 UTC (permalink / raw)
To: Dan Carpenter; +Cc: devel, gregkh, aditya.shankar, linux-kernel, ganesh.krishna
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-04-10 19:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-21 19:55 [PATCH] staging: wilc1000: use kernel define byte order macros Perry Hooker
2017-03-21 20:19 ` Dan Carpenter
2017-03-21 21:40 ` Robert Perry Hooker
2017-03-22 9:24 ` Dan Carpenter
2017-03-23 1:53 ` Robert Perry Hooker
2017-03-23 8:33 ` Dan Carpenter
2017-03-23 22:15 ` Robert Perry Hooker
2017-03-24 8:57 ` Dan Carpenter
2017-04-10 19:36 ` perry
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.