From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
To: Sven Eckelmann <sven@open-mesh.com>
Cc: linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Simon Wunderlich <siwu@hrz.tu-chemnitz.de>,
tobias.steinicke@net.t-labs.tu-berlin.de,
mathias.kretschmer@fokus.fraunhofer.de,
zefir.kurtisi@neratec.com
Subject: Re: [PATCH] ath9k: Save spectral scan data in network byteorder
Date: Wed, 16 Jan 2013 09:59:31 +0100 [thread overview]
Message-ID: <20130116085931.GA13648@pandem0nium> (raw)
In-Reply-To: <1358251363-14385-1-git-send-email-sven@open-mesh.com>
[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]
On Tue, Jan 15, 2013 at 01:02:43PM +0100, Sven Eckelmann wrote:
> The sample data received through the spectral scan can be either in big or
> little endian byteorder. This information isn't stored in the output file.
> Therefore it is not possible for the analyzer software to find the correct byte
> order.
>
> It is relative common to get the data from a low end AP in big endian mode and
> transfer it to another computer in little endian mode to analyze it. Therefore,
> it would be better to store it in network (big endian) byte order.
I'd agree that changing the byteorder to the "general" network order format is
a good idea, although we will break compatibility again - which should hopefully
be no problem as the original patch is pretty new anyway.
I was pondering about performance loss when we run spectral on the same machine
(i.e. maybe adding two useless byteswaps per value). OTOH the byteswaps are pretty
cheap and we do some computations anyway, so the performance difference should be quite
small.
Therefore,
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
(I've CCd some more people in the reply so they can scream if they don't like it. ;])
Thanks,
Simon
>
> Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
> Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
> ---
> A patch for FFT_eval was also sent to the author.
>
> drivers/net/wireless/ath/ath9k/recv.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index d7c129b..2fac787 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -1064,8 +1064,9 @@ static void ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
>
> fft_sample.tlv.type = ATH_FFT_SAMPLE_HT20;
> fft_sample.tlv.length = sizeof(fft_sample) - sizeof(fft_sample.tlv);
> + fft_sample.tlv.length = __cpu_to_be16(fft_sample.tlv.length);
>
> - fft_sample.freq = ah->curchan->chan->center_freq;
> + fft_sample.freq = __cpu_to_be16(ah->curchan->chan->center_freq);
> fft_sample.rssi = fix_rssi_inv_only(rs->rs_rssi_ctl0);
> fft_sample.noise = ah->noise;
>
> @@ -1106,13 +1107,16 @@ static void ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
> mag_info = ((struct ath_ht20_mag_info *)radar_info) - 1;
>
> /* Apply exponent and grab further auxiliary information. */
> - for (i = 0; i < SPECTRAL_HT20_NUM_BINS; i++)
> + for (i = 0; i < SPECTRAL_HT20_NUM_BINS; i++) {
> fft_sample.data[i] = bins[i] << mag_info->max_exp;
> + fft_sample.data[i] = __cpu_to_be16(fft_sample.data[i]);
> + }
>
> fft_sample.max_magnitude = spectral_max_magnitude(mag_info->all_bins);
> + fft_sample.max_magnitude = __cpu_to_be16(fft_sample.max_magnitude);
> fft_sample.max_index = spectral_max_index(mag_info->all_bins);
> fft_sample.bitmap_weight = spectral_bitmap_weight(mag_info->all_bins);
> - fft_sample.tsf = tsf;
> + fft_sample.tsf = __cpu_to_be64(tsf);
>
> ath_debug_send_fft_sample(sc, &fft_sample.tlv);
> #endif
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-01-16 8:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-15 12:02 [PATCH] ath9k: Save spectral scan data in network byteorder Sven Eckelmann
2013-01-16 8:59 ` Simon Wunderlich [this message]
2013-01-16 9:53 ` Zefir Kurtisi
2013-01-16 13:18 ` Simon Wunderlich
2013-01-16 16:00 ` Zefir Kurtisi
2013-01-16 18:22 ` Simon Wunderlich
2013-01-16 19:46 ` [RFC] ath9k: Don't preshift spectral scan bins Sven Eckelmann
2013-01-16 21:39 ` [PATCH] ath9k: Save spectral scan data in network byteorder Chadd, Adrian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130116085931.GA13648@pandem0nium \
--to=simon.wunderlich@s2003.tu-chemnitz.de \
--cc=ath9k-devel@lists.ath9k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mathias.kretschmer@fokus.fraunhofer.de \
--cc=siwu@hrz.tu-chemnitz.de \
--cc=sven@open-mesh.com \
--cc=tobias.steinicke@net.t-labs.tu-berlin.de \
--cc=zefir.kurtisi@neratec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).