[PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[Tomas Winkler]

Use directly put_unaligned_leX instead of put_unaligned(cpu_to_leX

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-rx.c |   37 +++++++++++++++-----------------
 1 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
index d062d4d..6a465d5 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -29,6 +29,7 @@
 
 #include <linux/etherdevice.h>
 #include <net/mac80211.h>
+#include <asm/unaligned.h>
 #include "iwl-eeprom.h"
 #include "iwl-dev.h"
 #include "iwl-core.h"
@@ -829,23 +830,22 @@ static void iwl_add_radiotap(struct iwl_priv *priv,
 	iwl4965_rt->rt_hdr.it_pad = 0;
 
 	/* total header + data */
-	put_unaligned(cpu_to_le16(sizeof(*iwl4965_rt)),
-		      &iwl4965_rt->rt_hdr.it_len);
+	put_unaligned_le16(sizeof(*iwl4965_rt), &iwl4965_rt->rt_hdr.it_len);
 
 	/* Indicate all the fields we add to the radiotap header */
-	put_unaligned(cpu_to_le32((1 << IEEE80211_RADIOTAP_TSFT) |
-				  (1 << IEEE80211_RADIOTAP_FLAGS) |
-				  (1 << IEEE80211_RADIOTAP_RATE) |
-				  (1 << IEEE80211_RADIOTAP_CHANNEL) |
-				  (1 << IEEE80211_RADIOTAP_DBM_ANTSIGNAL) |
-				  (1 << IEEE80211_RADIOTAP_DBM_ANTNOISE) |
-				  (1 << IEEE80211_RADIOTAP_ANTENNA)),
-		      &iwl4965_rt->rt_hdr.it_present);
+	put_unaligned_le32((1 << IEEE80211_RADIOTAP_TSFT) |
+			   (1 << IEEE80211_RADIOTAP_FLAGS) |
+			   (1 << IEEE80211_RADIOTAP_RATE) |
+			   (1 << IEEE80211_RADIOTAP_CHANNEL) |
+			   (1 << IEEE80211_RADIOTAP_DBM_ANTSIGNAL) |
+			   (1 << IEEE80211_RADIOTAP_DBM_ANTNOISE) |
+			   (1 << IEEE80211_RADIOTAP_ANTENNA),
+			   &(iwl4965_rt->rt_hdr.it_present));
 
 	/* Zero the flags, we'll add to them as we go */
 	iwl4965_rt->rt_flags = 0;
 
-	put_unaligned(cpu_to_le64(tsf), &iwl4965_rt->rt_tsf);
+	put_unaligned_le64(tsf, &iwl4965_rt->rt_tsf);
 
 	iwl4965_rt->rt_dbmsignal = signal;
 	iwl4965_rt->rt_dbmnoise = noise;
@@ -853,17 +853,14 @@ static void iwl_add_radiotap(struct iwl_priv *priv,
 	/* Convert the channel frequency and set the flags */
 	put_unaligned(cpu_to_le16(stats->freq), &iwl4965_rt->rt_channelMHz);
 	if (!(phy_flags_hw & RX_RES_PHY_FLAGS_BAND_24_MSK))
-		put_unaligned(cpu_to_le16(IEEE80211_CHAN_OFDM |
-					  IEEE80211_CHAN_5GHZ),
-			      &iwl4965_rt->rt_chbitmask);
+		put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_5GHZ,
+				   &iwl4965_rt->rt_chbitmask);
 	else if (phy_flags_hw & RX_RES_PHY_FLAGS_MOD_CCK_MSK)
-		put_unaligned(cpu_to_le16(IEEE80211_CHAN_CCK |
-					  IEEE80211_CHAN_2GHZ),
-			      &iwl4965_rt->rt_chbitmask);
+		put_unaligned_le16(IEEE80211_CHAN_CCK | IEEE80211_CHAN_2GHZ,
+				   &iwl4965_rt->rt_chbitmask);
 	else	/* 802.11g */
-		put_unaligned(cpu_to_le16(IEEE80211_CHAN_OFDM |
-					  IEEE80211_CHAN_2GHZ),
-			      &iwl4965_rt->rt_chbitmask);
+		put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ,
+				   &iwl4965_rt->rt_chbitmask);
 
 	if (rate == -1)
 		iwl4965_rt->rt_rate = 0;
-- 
1.5.4.1

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[Bruno Randolf]

On Thursday 10 July 2008 13:28:42 Tomas Winkler wrote:
> Use directly put_unaligned_leX instead of put_unaligned(cpu_to_leX
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>

hi!

what about using the generic function to add the radiotap header from 
mac80211? it should be flexible enough to handle all devices by now.

bruno

> ---
>  drivers/net/wireless/iwlwifi/iwl-rx.c |   37
> +++++++++++++++----------------- 1 files changed, 17 insertions(+), 20
> deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c
> b/drivers/net/wireless/iwlwifi/iwl-rx.c index d062d4d..6a465d5 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-rx.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
> @@ -29,6 +29,7 @@
>
>  #include <linux/etherdevice.h>
>  #include <net/mac80211.h>
> +#include <asm/unaligned.h>
>  #include "iwl-eeprom.h"
>  #include "iwl-dev.h"
>  #include "iwl-core.h"
> @@ -829,23 +830,22 @@ static void iwl_add_radiotap(struct iwl_priv *priv,
>  	iwl4965_rt->rt_hdr.it_pad = 0;
>
>  	/* total header + data */
> -	put_unaligned(cpu_to_le16(sizeof(*iwl4965_rt)),
> -		      &iwl4965_rt->rt_hdr.it_len);
> +	put_unaligned_le16(sizeof(*iwl4965_rt), &iwl4965_rt->rt_hdr.it_len);
>
>  	/* Indicate all the fields we add to the radiotap header */
> -	put_unaligned(cpu_to_le32((1 << IEEE80211_RADIOTAP_TSFT) |
> -				  (1 << IEEE80211_RADIOTAP_FLAGS) |
> -				  (1 << IEEE80211_RADIOTAP_RATE) |
> -				  (1 << IEEE80211_RADIOTAP_CHANNEL) |
> -				  (1 << IEEE80211_RADIOTAP_DBM_ANTSIGNAL) |
> -				  (1 << IEEE80211_RADIOTAP_DBM_ANTNOISE) |
> -				  (1 << IEEE80211_RADIOTAP_ANTENNA)),
> -		      &iwl4965_rt->rt_hdr.it_present);
> +	put_unaligned_le32((1 << IEEE80211_RADIOTAP_TSFT) |
> +			   (1 << IEEE80211_RADIOTAP_FLAGS) |
> +			   (1 << IEEE80211_RADIOTAP_RATE) |
> +			   (1 << IEEE80211_RADIOTAP_CHANNEL) |
> +			   (1 << IEEE80211_RADIOTAP_DBM_ANTSIGNAL) |
> +			   (1 << IEEE80211_RADIOTAP_DBM_ANTNOISE) |
> +			   (1 << IEEE80211_RADIOTAP_ANTENNA),
> +			   &(iwl4965_rt->rt_hdr.it_present));
>
>  	/* Zero the flags, we'll add to them as we go */
>  	iwl4965_rt->rt_flags = 0;
>
> -	put_unaligned(cpu_to_le64(tsf), &iwl4965_rt->rt_tsf);
> +	put_unaligned_le64(tsf, &iwl4965_rt->rt_tsf);
>
>  	iwl4965_rt->rt_dbmsignal = signal;
>  	iwl4965_rt->rt_dbmnoise = noise;
> @@ -853,17 +853,14 @@ static void iwl_add_radiotap(struct iwl_priv *priv,
>  	/* Convert the channel frequency and set the flags */
>  	put_unaligned(cpu_to_le16(stats->freq), &iwl4965_rt->rt_channelMHz);
>  	if (!(phy_flags_hw & RX_RES_PHY_FLAGS_BAND_24_MSK))
> -		put_unaligned(cpu_to_le16(IEEE80211_CHAN_OFDM |
> -					  IEEE80211_CHAN_5GHZ),
> -			      &iwl4965_rt->rt_chbitmask);
> +		put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_5GHZ,
> +				   &iwl4965_rt->rt_chbitmask);
>  	else if (phy_flags_hw & RX_RES_PHY_FLAGS_MOD_CCK_MSK)
> -		put_unaligned(cpu_to_le16(IEEE80211_CHAN_CCK |
> -					  IEEE80211_CHAN_2GHZ),
> -			      &iwl4965_rt->rt_chbitmask);
> +		put_unaligned_le16(IEEE80211_CHAN_CCK | IEEE80211_CHAN_2GHZ,
> +				   &iwl4965_rt->rt_chbitmask);
>  	else	/* 802.11g */
> -		put_unaligned(cpu_to_le16(IEEE80211_CHAN_OFDM |
> -					  IEEE80211_CHAN_2GHZ),
> -			      &iwl4965_rt->rt_chbitmask);
> +		put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ,
> +				   &iwl4965_rt->rt_chbitmask);
>
>  	if (rate == -1)
>  		iwl4965_rt->rt_rate = 0;

Re: [PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[Tomas Winkler]

On Thu, Jul 10, 2008 at 2:42 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Thursday 10 July 2008 13:28:42 Tomas Winkler wrote:
>> Use directly put_unaligned_leX instead of put_unaligned(cpu_to_leX
>>
>> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>
> hi!
>
> what about using the generic function to add the radiotap header from
> mac80211? it should be flexible enough to handle all devices by now.
>
Why not go ahead.
Tomas

Re: [PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

On Thu, 2008-07-10 at 15:25 +0300, Tomas Winkler wrote:

> > what about using the generic function to add the radiotap header from
> > mac80211? it should be flexible enough to handle all devices by now.

> Why not go ahead.

I always thought you were adding 11n stuff, but if that's not the case
(and we may make mac80211 do that at some point) then that'd be a nice
code removal.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[Tomas Winkler]

On Thu, Jul 10, 2008 at 4:52 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2008-07-10 at 15:25 +0300, Tomas Winkler wrote:
>
>> > what about using the generic function to add the radiotap header from
>> > mac80211? it should be flexible enough to handle all devices by now.
>
>> Why not go ahead.
>
> I always thought you were adding 11n stuff, but if that's not the case
> (and we may make mac80211 do that at some point) then that'd be a nice
> code removal.

I have never really looked into radio tap so I don't want to make any
statements here. If the 11n part can be done in mac80211 why not.
Tomas

Re: [PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[Bruno Randolf]

On Thursday 10 July 2008 16:47:57 Tomas Winkler wrote:
> On Thu, Jul 10, 2008 at 4:52 PM, Johannes Berg
>
> <johannes@sipsolutions.net> wrote:
> > On Thu, 2008-07-10 at 15:25 +0300, Tomas Winkler wrote:
> >> > what about using the generic function to add the radiotap header from
> >> > mac80211? it should be flexible enough to handle all devices by now.
> >>
> >> Why not go ahead.
> >
> > I always thought you were adding 11n stuff, but if that's not the case
> > (and we may make mac80211 do that at some point) then that'd be a nice
> > code removal.
>
> I have never really looked into radio tap so I don't want to make any
> statements here. If the 11n part can be done in mac80211 why not.

hi!

i'm currently working on a patch removing iwl's own radiotap header. while 
doing that i noticed, that we currently don't have a field in 
ieee80211_rx_status for the modulation used. for example iwl knows if the 
frame was demodulated using CCK (RX_RES_PHY_FLAGS_MOD_CCK_MSK), thus it's 
able to differentiate between B and G modes. in mac80211 we can't do that 
right now.

i guess we could deduct the modulation from the rate

1, 2, 5.5, 11	-> CCK
everything else	-> OFDM

but i'm not sure if this is always true. is there any hardware that also does 
PBCC? also what about CCK-OFDM modes (b/g interoperability), do we have any 
way to identify these?

what do you think, should we explicitly make a modulation field in rx_status 
or should we implicitly deduct the modulation from the rates?

bruno

Re: [PATCH 1/1] iwlwif: remove compilation warnings iwl_add_radiotap

[Tomas Winkler]

On Sat, Jul 12, 2008 at 3:57 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Thursday 10 July 2008 16:47:57 Tomas Winkler wrote:
>> On Thu, Jul 10, 2008 at 4:52 PM, Johannes Berg
>>
>> <johannes@sipsolutions.net> wrote:
>> > On Thu, 2008-07-10 at 15:25 +0300, Tomas Winkler wrote:
>> >> > what about using the generic function to add the radiotap header from
>> >> > mac80211? it should be flexible enough to handle all devices by now.
>> >>
>> >> Why not go ahead.
>> >
>> > I always thought you were adding 11n stuff, but if that's not the case
>> > (and we may make mac80211 do that at some point) then that'd be a nice
>> > code removal.
>>
>> I have never really looked into radio tap so I don't want to make any
>> statements here. If the 11n part can be done in mac80211 why not.
>
> hi!
>
> i'm currently working on a patch removing iwl's own radiotap header. while
> doing that i noticed, that we currently don't have a field in
> ieee80211_rx_status for the modulation used. for example iwl knows if the
> frame was demodulated using CCK (RX_RES_PHY_FLAGS_MOD_CCK_MSK), thus it's
> able to differentiate between B and G modes. in mac80211 we can't do that
> right now.
>
> i guess we could deduct the modulation from the rate
>
> 1, 2, 5.5, 11   -> CCK
> everything else -> OFDM
>
> but i'm not sure if this is always true. is there any hardware that also does
> PBCC? also what about CCK-OFDM modes (b/g interoperability), do we have any
> way to identify these?
>
> what do you think, should we explicitly make a modulation field in rx_status
> or should we implicitly deduct the modulation from the rates?

I believe you can safely assume  CCK from rate in WiFi. Both PBCC and
CCK/OFDM are optional by the spec meaning nobody really going to
implement. I suggest to focus on the main pass and deal with the
corner cases only if needed.
Tomas

>
> bruno
>