* Re: [RFC] ath9k: add HT40 spectral scan capability
From: Simon Wunderlich @ 2013-09-30 16:04 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linville, linux-wireless, mcgrof, simon.wunderlich
In-Reply-To: <1380206258-16452-1-git-send-email-lorenzo.bianconi83@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 10710 bytes --]
Hey Lorenzo,
thanks for your work. Please find a few comments inline:
On Thu, Sep 26, 2013 at 04:37:38PM +0200, Lorenzo Bianconi wrote:
> Add spectral scan feature on HT40 channels for ath9k. This patch extends
> previous capability added by Simon Wunderlich
>
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 47 +++++++----
> drivers/net/wireless/ath/ath9k/calib.c | 10 +--
> drivers/net/wireless/ath/ath9k/calib.h | 3 +-
> drivers/net/wireless/ath/ath9k/hw.c | 2 +-
> drivers/net/wireless/ath/ath9k/link.c | 3 +-
> drivers/net/wireless/ath/ath9k/recv.c | 142 ++++++++++++++++++++++-----------
> 6 files changed, 139 insertions(+), 68 deletions(-)
>
> [...]
> diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
> index 5e8219a..d09eaeb 100644
> --- a/drivers/net/wireless/ath/ath9k/calib.c
> +++ b/drivers/net/wireless/ath/ath9k/calib.c
> @@ -63,13 +63,13 @@ static s16 ath9k_hw_get_default_nf(struct ath_hw *ah,
> return ath9k_hw_get_nf_limits(ah, chan)->nominal;
> }
>
> -s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan)
> +s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
> + s16 nf)
> {
> s8 noise = ATH_DEFAULT_NOISE_FLOOR;
>
> - if (chan && chan->noisefloor) {
> - s8 delta = chan->noisefloor -
> - ATH9K_NF_CAL_NOISE_THRESH -
> + if (nf) {
> + s8 delta = nf - ATH9K_NF_CAL_NOISE_THRESH -
> ath9k_hw_get_default_nf(ah, chan);
> if (delta > 0)
> noise += delta;
> @@ -394,7 +394,7 @@ bool ath9k_hw_getnf(struct ath_hw *ah, struct ath9k_channel *chan)
> caldata->nfcal_pending = false;
> ath9k_hw_update_nfcal_hist_buffer(ah, caldata, nfarray);
> chan->noisefloor = h[0].privNF;
> - ah->noise = ath9k_hw_getchan_noise(ah, chan);
> + ah->noise = ath9k_hw_getchan_noise(ah, chan, chan->noisefloor);
> return true;
> }
> EXPORT_SYMBOL(ath9k_hw_getnf);
> diff --git a/drivers/net/wireless/ath/ath9k/calib.h b/drivers/net/wireless/ath/ath9k/calib.h
> index 3d70b8c..b8ed95e 100644
> --- a/drivers/net/wireless/ath/ath9k/calib.h
> +++ b/drivers/net/wireless/ath/ath9k/calib.h
> @@ -116,7 +116,8 @@ void ath9k_init_nfcal_hist_buffer(struct ath_hw *ah,
> void ath9k_hw_bstuck_nfcal(struct ath_hw *ah);
> void ath9k_hw_reset_calibration(struct ath_hw *ah,
> struct ath9k_cal_list *currCal);
> -s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan);
> +s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
> + s16 nf);
I'm not entirely sure how these noise changes are connected to the patch. It appears you
use it later, but maybe it would be good to put this in a separate patch?
> [...]
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index 4ee472a..525f07c 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -972,14 +972,13 @@ static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
> {
> #ifdef CONFIG_ATH9K_DEBUGFS
> struct ath_hw *ah = sc->sc_ah;
> - u8 bins[SPECTRAL_HT20_NUM_BINS];
> - u8 *vdata = (u8 *)hdr;
> - struct fft_sample_ht20 fft_sample;
> + u8 type, num_bins, *data, *vdata = (u8 *) hdr;
> + struct fft_sample fft_data;
If you keep the variable name fft_sample, you can save quite a lot renames below. And that
would make it easier for this patch to review.
> struct ath_radar_info *radar_info;
> - struct ath_ht20_mag_info *mag_info;
> int len = rs->rs_datalen;
> int dc_pos;
> - u16 length, max_magnitude;
> + u16 length, fft_len;
> + enum nl80211_channel_type chtype;
>
> /* AR9280 and before report via ATH9K_PHYERR_RADAR, AR93xx and newer
> * via ATH9K_PHYERR_SPECTRAL. Haven't seen ATH9K_PHYERR_FALSE_RADAR_EXT
> @@ -997,45 +996,53 @@ static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
> if (!(radar_info->pulse_bw_info & SPECTRAL_SCAN_BITMASK))
> return 0;
>
> - /* Variation in the data length is possible and will be fixed later.
> - * Note that we only support HT20 for now.
> - *
> - * TODO: add HT20_40 support as well.
> - */
> - if ((len > SPECTRAL_HT20_TOTAL_DATA_LEN + 2) ||
> - (len < SPECTRAL_HT20_TOTAL_DATA_LEN - 1))
> + chtype = cfg80211_get_chandef_type(&sc->hw->conf.chandef);
> + if ((chtype == NL80211_CHAN_HT40MINUS) ||
> + (chtype == NL80211_CHAN_HT40PLUS)) {
> + type = FFT_SAMPLE_HT20_40;
> + num_bins = SPECTRAL_HT20_40_NUM_BINS;
> + fft_len = SPECTRAL_HT20_40_TOTAL_DATA_LEN;
> + data = (u8 *) fft_data.ht20_40.data;
> + } else {
> + type = FFT_SAMPLE_HT20;
> + num_bins = SPECTRAL_HT20_NUM_BINS;
> + fft_len = SPECTRAL_HT20_TOTAL_DATA_LEN;
> + data = (u8 *) fft_data.ht20.data;
> + }
> +
> + /* variation in the data length is possible and will be fixed later */
> + if ((len > fft_len + 2) || (len < fft_len - 1))
> return 1;
>
> - fft_sample.tlv.type = ATH_FFT_SAMPLE_HT20;
> - length = sizeof(fft_sample) - sizeof(fft_sample.tlv);
> - fft_sample.tlv.length = __cpu_to_be16(length);
> + fft_data.tlv.type = __cpu_to_be32(type);
> + length = sizeof(fft_data) - sizeof(fft_data.tlv);
> + fft_data.tlv.length = __cpu_to_be16(length);
>
> - 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;
> + fft_data.freq = __cpu_to_be16(ah->curchan->chan->center_freq);
> + fft_data.tsf = __cpu_to_be64(tsf);
>
> - switch (len - SPECTRAL_HT20_TOTAL_DATA_LEN) {
> + switch (len - fft_len) {
> case 0:
> /* length correct, nothing to do. */
> - memcpy(bins, vdata, SPECTRAL_HT20_NUM_BINS);
> + memcpy(data, vdata, num_bins);
> break;
> case -1:
> /* first byte missing, duplicate it. */
> - memcpy(&bins[1], vdata, SPECTRAL_HT20_NUM_BINS - 1);
> - bins[0] = vdata[0];
> + memcpy(&data[1], vdata, num_bins - 1);
> + data[0] = vdata[0];
> break;
> case 2:
> /* MAC added 2 extra bytes at bin 30 and 32, remove them. */
> - memcpy(bins, vdata, 30);
> - bins[30] = vdata[31];
> - memcpy(&bins[31], &vdata[33], SPECTRAL_HT20_NUM_BINS - 31);
> + memcpy(data, vdata, 30);
> + data[30] = vdata[31];
> + memcpy(&data[31], &vdata[33], num_bins - 31);
> break;
> case 1:
> /* MAC added 2 extra bytes AND first byte is missing. */
> - bins[0] = vdata[0];
> - memcpy(&bins[0], vdata, 30);
> - bins[31] = vdata[31];
> - memcpy(&bins[32], &vdata[33], SPECTRAL_HT20_NUM_BINS - 32);
> + data[0] = vdata[0];
> + memcpy(&data[1], vdata, 30);
> + data[31] = vdata[31];
> + memcpy(&data[32], &vdata[33], num_bins - 32);
I hope you tested whether this byte shuffling works as expected for HT40?
> break;
> default:
> return 1;
> @@ -1044,23 +1051,68 @@ static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
> /* DC value (value in the middle) is the blind spot of the spectral
> * sample and invalid, interpolate it.
> */
> - dc_pos = SPECTRAL_HT20_NUM_BINS / 2;
> - bins[dc_pos] = (bins[dc_pos + 1] + bins[dc_pos - 1]) / 2;
Same for the DC value here ...
> -
> - /* mag data is at the end of the frame, in front of radar_info */
> - mag_info = ((struct ath_ht20_mag_info *)radar_info) - 1;
> -
> - /* copy raw bins without scaling them */
> - memcpy(fft_sample.data, bins, SPECTRAL_HT20_NUM_BINS);
> - fft_sample.max_exp = mag_info->max_exp & 0xf;
> -
> - max_magnitude = spectral_max_magnitude(mag_info->all_bins);
> - fft_sample.max_magnitude = __cpu_to_be16(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 = __cpu_to_be64(tsf);
> + dc_pos = num_bins / 2;
> + data[dc_pos] = (data[dc_pos + 1] + data[dc_pos - 1]) / 2;
> +
> + if ((chtype == NL80211_CHAN_HT40MINUS) ||
> + (chtype == NL80211_CHAN_HT40PLUS)) {
> + u16 lower_max_mag, upper_max_mag;
> + s16 nf_ext;
> + struct ath_ht20_40_mag_info *mag_info;
> + struct ath9k_hw_cal_data *caldata = ah->caldata;
> +
> + if (caldata)
> + nf_ext = ath9k_hw_getchan_noise(ah, ah->curchan,
> + caldata->nfCalHist[3].privNF);
> + else
> + nf_ext = ATH_DEFAULT_NOISE_FLOOR;
> +
> + mag_info = ((struct ath_ht20_40_mag_info *)radar_info) - 1;
> + lower_max_mag = spectral_max_magnitude(mag_info->lower_bins);
> + upper_max_mag = spectral_max_magnitude(mag_info->upper_bins);
> +
> + if (chtype == NL80211_CHAN_HT40PLUS) {
> + fft_data.ht20_40.lower_rssi =
> + fix_rssi_inv_only(rs->rs_rssi_ctl0);
> + fft_data.ht20_40.upper_rssi =
> + fix_rssi_inv_only(rs->rs_rssi_ext0);
> + fft_data.ht20_40.lower_nf = ah->noise;
> + fft_data.ht20_40.upper_nf = nf_ext;
> + } else {
> + fft_data.ht20_40.lower_rssi =
> + fix_rssi_inv_only(rs->rs_rssi_ext0);
> + fft_data.ht20_40.upper_rssi =
> + fix_rssi_inv_only(rs->rs_rssi_ctl0);
> + fft_data.ht20_40.lower_nf = nf_ext;
> + fft_data.ht20_40.upper_nf = ah->noise;
> + }
> + fft_data.ht20_40.lower_max_mag = __cpu_to_be16(lower_max_mag);
> + fft_data.ht20_40.lower_max_idx =
> + spectral_max_index(mag_info->lower_bins);
> + fft_data.ht20_40.lower_bitmap_w =
> + spectral_bitmap_weight(mag_info->lower_bins);
> + fft_data.ht20_40.upper_max_mag = __cpu_to_be16(upper_max_mag);
> + fft_data.ht20_40.upper_max_idx =
> + spectral_max_index(mag_info->upper_bins);
> + fft_data.ht20_40.upper_bitmap_w =
> + spectral_bitmap_weight(mag_info->upper_bins);
> + fft_data.ht20_40.max_exp = mag_info->max_exp & 0xf;
Could you please try to use some local variables here? I think this could
avoid a few of these ugly multi-line assignments ...
> + } else {
> + u16 max_mag;
> + struct ath_ht20_mag_info *mag_info;
> +
> + mag_info = ((struct ath_ht20_mag_info *)radar_info) - 1;
> + max_mag = spectral_max_magnitude(mag_info->all_bins);
> + fft_data.ht20.rssi = fix_rssi_inv_only(rs->rs_rssi_ctl0);
> + fft_data.ht20.nf = ah->noise;
> + fft_data.ht20.max_mag = __cpu_to_be16(max_mag);
> + fft_data.ht20.max_idx = spectral_max_index(mag_info->all_bins);
> + fft_data.ht20.bitmap_w =
> + spectral_bitmap_weight(mag_info->all_bins);
> + fft_data.ht20.max_exp = mag_info->max_exp & 0xf;
> + }
>
> - ath_debug_send_fft_sample(sc, &fft_sample.tlv);
> + ath_debug_send_fft_sample(sc, &fft_data.tlv);
> return 1;
> #else
> return 0;
> --
> 1.8.1.2
>
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Bruno Randolf @ 2013-09-30 16:12 UTC (permalink / raw)
To: Oleksij Rempel, linux-wireless, nbd, sujith; +Cc: Ingo Randolf
In-Reply-To: <52497C2E.1060406@rempel-privat.de>
On 09/30/2013 02:27 PM, Oleksij Rempel wrote:
>>> Check:
>>> - PCIe related power managment - ASPM.
Hmm, disabling ASPM in the BIOS and per kernel command line
(pcie_aspm=off) did not help.
> I use 3.11 right now. In case of PCIe issue, backport wont help you.
> Test completely new kernel.
I'll try 3.11 later.
> What is your host hardware?
Its a Advantech MIO-2261N (Atom N260).
Thanks,
bruno
^ permalink raw reply
* Re: [RFC] ath9k: add HT40 spectral scan capability
From: Lorenzo Bianconi @ 2013-09-30 16:19 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20130930160437.GA15780@pandem0nium>
Thanks Simon for your suggestions. I will review the patch.
Cheers,
Lorenzo
2013/9/30 Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>:
> Hey Lorenzo,
>
> thanks for your work. Please find a few comments inline:
>
> On Thu, Sep 26, 2013 at 04:37:38PM +0200, Lorenzo Bianconi wrote:
>> Add spectral scan feature on HT40 channels for ath9k. This patch extends
>> previous capability added by Simon Wunderlich
>>
>> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath9k/ath9k.h | 47 +++++++----
>> drivers/net/wireless/ath/ath9k/calib.c | 10 +--
>> drivers/net/wireless/ath/ath9k/calib.h | 3 +-
>> drivers/net/wireless/ath/ath9k/hw.c | 2 +-
>> drivers/net/wireless/ath/ath9k/link.c | 3 +-
>> drivers/net/wireless/ath/ath9k/recv.c | 142 ++++++++++++++++++++++-----------
>> 6 files changed, 139 insertions(+), 68 deletions(-)
>>
>> [...]
>> diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
>> index 5e8219a..d09eaeb 100644
>> --- a/drivers/net/wireless/ath/ath9k/calib.c
>> +++ b/drivers/net/wireless/ath/ath9k/calib.c
>> @@ -63,13 +63,13 @@ static s16 ath9k_hw_get_default_nf(struct ath_hw *ah,
>> return ath9k_hw_get_nf_limits(ah, chan)->nominal;
>> }
>>
>> -s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan)
>> +s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
>> + s16 nf)
>> {
>> s8 noise = ATH_DEFAULT_NOISE_FLOOR;
>>
>> - if (chan && chan->noisefloor) {
>> - s8 delta = chan->noisefloor -
>> - ATH9K_NF_CAL_NOISE_THRESH -
>> + if (nf) {
>> + s8 delta = nf - ATH9K_NF_CAL_NOISE_THRESH -
>> ath9k_hw_get_default_nf(ah, chan);
>> if (delta > 0)
>> noise += delta;
>> @@ -394,7 +394,7 @@ bool ath9k_hw_getnf(struct ath_hw *ah, struct ath9k_channel *chan)
>> caldata->nfcal_pending = false;
>> ath9k_hw_update_nfcal_hist_buffer(ah, caldata, nfarray);
>> chan->noisefloor = h[0].privNF;
>> - ah->noise = ath9k_hw_getchan_noise(ah, chan);
>> + ah->noise = ath9k_hw_getchan_noise(ah, chan, chan->noisefloor);
>> return true;
>> }
>> EXPORT_SYMBOL(ath9k_hw_getnf);
>> diff --git a/drivers/net/wireless/ath/ath9k/calib.h b/drivers/net/wireless/ath/ath9k/calib.h
>> index 3d70b8c..b8ed95e 100644
>> --- a/drivers/net/wireless/ath/ath9k/calib.h
>> +++ b/drivers/net/wireless/ath/ath9k/calib.h
>> @@ -116,7 +116,8 @@ void ath9k_init_nfcal_hist_buffer(struct ath_hw *ah,
>> void ath9k_hw_bstuck_nfcal(struct ath_hw *ah);
>> void ath9k_hw_reset_calibration(struct ath_hw *ah,
>> struct ath9k_cal_list *currCal);
>> -s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan);
>> +s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
>> + s16 nf);
>
> I'm not entirely sure how these noise changes are connected to the patch. It appears you
> use it later, but maybe it would be good to put this in a separate patch?
>> [...]
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
>> index 4ee472a..525f07c 100644
>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>> @@ -972,14 +972,13 @@ static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
>> {
>> #ifdef CONFIG_ATH9K_DEBUGFS
>> struct ath_hw *ah = sc->sc_ah;
>> - u8 bins[SPECTRAL_HT20_NUM_BINS];
>> - u8 *vdata = (u8 *)hdr;
>> - struct fft_sample_ht20 fft_sample;
>> + u8 type, num_bins, *data, *vdata = (u8 *) hdr;
>> + struct fft_sample fft_data;
>
> If you keep the variable name fft_sample, you can save quite a lot renames below. And that
> would make it easier for this patch to review.
>
>> struct ath_radar_info *radar_info;
>> - struct ath_ht20_mag_info *mag_info;
>> int len = rs->rs_datalen;
>> int dc_pos;
>> - u16 length, max_magnitude;
>> + u16 length, fft_len;
>> + enum nl80211_channel_type chtype;
>>
>> /* AR9280 and before report via ATH9K_PHYERR_RADAR, AR93xx and newer
>> * via ATH9K_PHYERR_SPECTRAL. Haven't seen ATH9K_PHYERR_FALSE_RADAR_EXT
>> @@ -997,45 +996,53 @@ static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
>> if (!(radar_info->pulse_bw_info & SPECTRAL_SCAN_BITMASK))
>> return 0;
>>
>> - /* Variation in the data length is possible and will be fixed later.
>> - * Note that we only support HT20 for now.
>> - *
>> - * TODO: add HT20_40 support as well.
>> - */
>> - if ((len > SPECTRAL_HT20_TOTAL_DATA_LEN + 2) ||
>> - (len < SPECTRAL_HT20_TOTAL_DATA_LEN - 1))
>> + chtype = cfg80211_get_chandef_type(&sc->hw->conf.chandef);
>> + if ((chtype == NL80211_CHAN_HT40MINUS) ||
>> + (chtype == NL80211_CHAN_HT40PLUS)) {
>> + type = FFT_SAMPLE_HT20_40;
>> + num_bins = SPECTRAL_HT20_40_NUM_BINS;
>> + fft_len = SPECTRAL_HT20_40_TOTAL_DATA_LEN;
>> + data = (u8 *) fft_data.ht20_40.data;
>> + } else {
>> + type = FFT_SAMPLE_HT20;
>> + num_bins = SPECTRAL_HT20_NUM_BINS;
>> + fft_len = SPECTRAL_HT20_TOTAL_DATA_LEN;
>> + data = (u8 *) fft_data.ht20.data;
>> + }
>> +
>> + /* variation in the data length is possible and will be fixed later */
>> + if ((len > fft_len + 2) || (len < fft_len - 1))
>> return 1;
>>
>> - fft_sample.tlv.type = ATH_FFT_SAMPLE_HT20;
>> - length = sizeof(fft_sample) - sizeof(fft_sample.tlv);
>> - fft_sample.tlv.length = __cpu_to_be16(length);
>> + fft_data.tlv.type = __cpu_to_be32(type);
>> + length = sizeof(fft_data) - sizeof(fft_data.tlv);
>> + fft_data.tlv.length = __cpu_to_be16(length);
>>
>> - 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;
>> + fft_data.freq = __cpu_to_be16(ah->curchan->chan->center_freq);
>> + fft_data.tsf = __cpu_to_be64(tsf);
>>
>> - switch (len - SPECTRAL_HT20_TOTAL_DATA_LEN) {
>> + switch (len - fft_len) {
>> case 0:
>> /* length correct, nothing to do. */
>> - memcpy(bins, vdata, SPECTRAL_HT20_NUM_BINS);
>> + memcpy(data, vdata, num_bins);
>> break;
>> case -1:
>> /* first byte missing, duplicate it. */
>> - memcpy(&bins[1], vdata, SPECTRAL_HT20_NUM_BINS - 1);
>> - bins[0] = vdata[0];
>> + memcpy(&data[1], vdata, num_bins - 1);
>> + data[0] = vdata[0];
>> break;
>> case 2:
>> /* MAC added 2 extra bytes at bin 30 and 32, remove them. */
>> - memcpy(bins, vdata, 30);
>> - bins[30] = vdata[31];
>> - memcpy(&bins[31], &vdata[33], SPECTRAL_HT20_NUM_BINS - 31);
>> + memcpy(data, vdata, 30);
>> + data[30] = vdata[31];
>> + memcpy(&data[31], &vdata[33], num_bins - 31);
>> break;
>> case 1:
>> /* MAC added 2 extra bytes AND first byte is missing. */
>> - bins[0] = vdata[0];
>> - memcpy(&bins[0], vdata, 30);
>> - bins[31] = vdata[31];
>> - memcpy(&bins[32], &vdata[33], SPECTRAL_HT20_NUM_BINS - 32);
>> + data[0] = vdata[0];
>> + memcpy(&data[1], vdata, 30);
>> + data[31] = vdata[31];
>> + memcpy(&data[32], &vdata[33], num_bins - 32);
>
> I hope you tested whether this byte shuffling works as expected for HT40?
>
>> break;
>> default:
>> return 1;
>> @@ -1044,23 +1051,68 @@ static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
>> /* DC value (value in the middle) is the blind spot of the spectral
>> * sample and invalid, interpolate it.
>> */
>> - dc_pos = SPECTRAL_HT20_NUM_BINS / 2;
>> - bins[dc_pos] = (bins[dc_pos + 1] + bins[dc_pos - 1]) / 2;
>
> Same for the DC value here ...
>
>> -
>> - /* mag data is at the end of the frame, in front of radar_info */
>> - mag_info = ((struct ath_ht20_mag_info *)radar_info) - 1;
>> -
>> - /* copy raw bins without scaling them */
>> - memcpy(fft_sample.data, bins, SPECTRAL_HT20_NUM_BINS);
>> - fft_sample.max_exp = mag_info->max_exp & 0xf;
>> -
>> - max_magnitude = spectral_max_magnitude(mag_info->all_bins);
>> - fft_sample.max_magnitude = __cpu_to_be16(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 = __cpu_to_be64(tsf);
>> + dc_pos = num_bins / 2;
>> + data[dc_pos] = (data[dc_pos + 1] + data[dc_pos - 1]) / 2;
>> +
>> + if ((chtype == NL80211_CHAN_HT40MINUS) ||
>> + (chtype == NL80211_CHAN_HT40PLUS)) {
>> + u16 lower_max_mag, upper_max_mag;
>> + s16 nf_ext;
>> + struct ath_ht20_40_mag_info *mag_info;
>> + struct ath9k_hw_cal_data *caldata = ah->caldata;
>> +
>> + if (caldata)
>> + nf_ext = ath9k_hw_getchan_noise(ah, ah->curchan,
>> + caldata->nfCalHist[3].privNF);
>> + else
>> + nf_ext = ATH_DEFAULT_NOISE_FLOOR;
>> +
>> + mag_info = ((struct ath_ht20_40_mag_info *)radar_info) - 1;
>> + lower_max_mag = spectral_max_magnitude(mag_info->lower_bins);
>> + upper_max_mag = spectral_max_magnitude(mag_info->upper_bins);
>> +
>> + if (chtype == NL80211_CHAN_HT40PLUS) {
>> + fft_data.ht20_40.lower_rssi =
>> + fix_rssi_inv_only(rs->rs_rssi_ctl0);
>> + fft_data.ht20_40.upper_rssi =
>> + fix_rssi_inv_only(rs->rs_rssi_ext0);
>> + fft_data.ht20_40.lower_nf = ah->noise;
>> + fft_data.ht20_40.upper_nf = nf_ext;
>> + } else {
>> + fft_data.ht20_40.lower_rssi =
>> + fix_rssi_inv_only(rs->rs_rssi_ext0);
>> + fft_data.ht20_40.upper_rssi =
>> + fix_rssi_inv_only(rs->rs_rssi_ctl0);
>> + fft_data.ht20_40.lower_nf = nf_ext;
>> + fft_data.ht20_40.upper_nf = ah->noise;
>> + }
>> + fft_data.ht20_40.lower_max_mag = __cpu_to_be16(lower_max_mag);
>> + fft_data.ht20_40.lower_max_idx =
>> + spectral_max_index(mag_info->lower_bins);
>> + fft_data.ht20_40.lower_bitmap_w =
>> + spectral_bitmap_weight(mag_info->lower_bins);
>> + fft_data.ht20_40.upper_max_mag = __cpu_to_be16(upper_max_mag);
>> + fft_data.ht20_40.upper_max_idx =
>> + spectral_max_index(mag_info->upper_bins);
>> + fft_data.ht20_40.upper_bitmap_w =
>> + spectral_bitmap_weight(mag_info->upper_bins);
>> + fft_data.ht20_40.max_exp = mag_info->max_exp & 0xf;
>
>
> Could you please try to use some local variables here? I think this could
> avoid a few of these ugly multi-line assignments ...
>
>> + } else {
>> + u16 max_mag;
>> + struct ath_ht20_mag_info *mag_info;
>> +
>> + mag_info = ((struct ath_ht20_mag_info *)radar_info) - 1;
>> + max_mag = spectral_max_magnitude(mag_info->all_bins);
>> + fft_data.ht20.rssi = fix_rssi_inv_only(rs->rs_rssi_ctl0);
>> + fft_data.ht20.nf = ah->noise;
>> + fft_data.ht20.max_mag = __cpu_to_be16(max_mag);
>> + fft_data.ht20.max_idx = spectral_max_index(mag_info->all_bins);
>> + fft_data.ht20.bitmap_w =
>> + spectral_bitmap_weight(mag_info->all_bins);
>> + fft_data.ht20.max_exp = mag_info->max_exp & 0xf;
>> + }
>>
>> - ath_debug_send_fft_sample(sc, &fft_sample.tlv);
>> + ath_debug_send_fft_sample(sc, &fft_data.tlv);
>> return 1;
>> #else
>> return 0;
>> --
>> 1.8.1.2
>>
>
> Cheers,
> Simon
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [RFC] ath9k: add HT40 spectral scan capability
From: Simon Wunderlich @ 2013-09-30 16:48 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linville, linux-wireless, mcgrof, simon.wunderlich
In-Reply-To: <1380206258-16452-1-git-send-email-lorenzo.bianconi83@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]
On Thu, Sep 26, 2013 at 04:37:38PM +0200, Lorenzo Bianconi wrote:
> Add spectral scan feature on HT40 channels for ath9k. This patch extends
> previous capability added by Simon Wunderlich
>
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 47 +++++++----
> drivers/net/wireless/ath/ath9k/calib.c | 10 +--
> drivers/net/wireless/ath/ath9k/calib.h | 3 +-
> drivers/net/wireless/ath/ath9k/hw.c | 2 +-
> drivers/net/wireless/ath/ath9k/link.c | 3 +-
> drivers/net/wireless/ath/ath9k/recv.c | 142 ++++++++++++++++++++++-----------
> 6 files changed, 139 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 2ee35f6..b44955e 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -875,32 +875,49 @@ static inline u8 spectral_bitmap_weight(u8 *bins)
> * TODO: this might need rework when switching to nl80211-based
> * interface.
> */
> -enum ath_fft_sample_type {
> - ATH_FFT_SAMPLE_HT20 = 1,
> +enum fft_sample_type {
> + FFT_SAMPLE_HT20 = 1,
> + FFT_SAMPLE_HT20_40,
> };
>
> struct fft_sample_tlv {
> - u8 type; /* see ath_fft_sample */
> + enum fft_sample_type type;
> __be16 length;
> /* type dependent data follows */
> } __packed;
>
> -struct fft_sample_ht20 {
> +struct fft_sample {
> struct fft_sample_tlv tlv;
> -
> - u8 max_exp;
> -
> __be16 freq;
> - s8 rssi;
> - s8 noise;
> -
> - __be16 max_magnitude;
> - u8 max_index;
> - u8 bitmap_weight;
> -
> __be64 tsf;
>
> - u8 data[SPECTRAL_HT20_NUM_BINS];
> + union {
> + struct {
> + s8 rssi;
> + s8 nf;
> +
> + u8 data[SPECTRAL_HT20_NUM_BINS];
> + __be16 max_mag;
> + u8 max_idx;
> + u8 bitmap_w;
> + u8 max_exp;
> + } ht20;
> + struct {
> + s8 lower_rssi;
> + s8 upper_rssi;
> + s8 lower_nf;
> + s8 upper_nf;
> +
> + u8 data[SPECTRAL_HT20_40_NUM_BINS];
> + __be16 lower_max_mag;
> + __be16 upper_max_mag;
> + u8 lower_max_idx;
> + u8 upper_max_idx;
> + u8 lower_bitmap_w;
> + u8 upper_bitmap_w;
> + u8 max_exp;
> + } ht20_40;
> + };
> } __packed;
One more thing: please don't change the format for HT20 - there are already userspace
programs which rely on the order of the parameters as they are now. This is why we have
added the TLVs in the first place - you can just add a new type for HT40 (as you did),
but keep the format of other formats (HT20).
Thanks,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 12/12] wlcore: always register dummy hardirq
From: Luca Coelho @ 2013-09-30 16:48 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEeer+NTKwWc5GkjZQdswSkPfsGhinvpcK2BbarqjCeA5A@mail.gmail.com>
On Wed, 2013-09-11 at 09:48 +0200, Eliad Peller wrote:
> On Tue, Sep 10, 2013 at 10:50 AM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> >> From: Arik Nemtsov <arik@wizery.com>
> >>
> >> This keeps the kernel happy when using edge-irqs and requesting a
> >> threaded irq.
> >>
> >> Signed-off-by: Arik Nemtsov <arik@wizery.com>
> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> ---
> >
> > Ouch, I think this is not going to fit at all with the DT patches I
> > sent.
> >
> this is quite minor patch (only making sure we always define hardirq
> when threaded_irq is used. i don't think it should conflict (at least
> logically) with DT patches...
It will. Just take a look at my DT patch series. Anyway, I'll apply
this for now and whoever (if ever) take over my DT series, will have to
make sure it still works. :P
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2 10/11] wl18xx: print new RDL versions during boot
From: Luca Coelho @ 2013-09-30 16:57 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1379432490-22157-10-git-send-email-eliad@wizery.com>
On Tue, 2013-09-17 at 18:41 +0300, Eliad Peller wrote:
> From: Victor Goldenshtein <victorg@ti.com>
>
> Extract and print info for the new RDL 5, 6, 7 and 8.
> Replace const struct with function which translates
> the RDL number to string.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Barak Bercovitz <barak@wizery.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
> v1->v2: split UNTRIMMED/UNKNOWN
>
> drivers/net/wireless/ti/wl18xx/main.c | 42 ++++++++++++++++++++++++++++++-----
> drivers/net/wireless/ti/wl18xx/reg.h | 20 ++++++++---------
> 2 files changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wl18xx/main.c b/drivers/net/wireless/ti/wl18xx/main.c
> index b47eb62..d0daca1 100644
> --- a/drivers/net/wireless/ti/wl18xx/main.c
> +++ b/drivers/net/wireless/ti/wl18xx/main.c
> @@ -1228,16 +1228,48 @@ static u32 wl18xx_ap_get_mimo_wide_rate_mask(struct wl1271 *wl,
> }
> }
>
> +static const char *wl18xx_rdl_name(enum wl18xx_rdl_num rdl_num)
> +{
> + switch (rdl_num) {
> + case RDL_1_HP:
> + return "183xH";
> + case RDL_2_SP:
> + return "183x or 180x";
> + case RDL_3_HP:
> + return "187xH";
> + case RDL_4_SP:
> + return "187x";
> + case RDL_5_SP:
> + return "RDL11 - Not Supported";
> + case RDL_6_SP:
> + return "180xD";
> + case RDL_7_SP:
> + return "RDL13 - Not Supported (1893Q)";
> + case RDL_8_SP:
> + return "18xxQ";
> + case RDL_NONE:
> + return "UNTRIMMED";
> + default:
> + return "UNKNOWN";
> + }
> +}
I see you kept the function. I prefer the array, but I'm not going to
block this patch for such a small thing. ;)
It looks better now, with the untrimmed case separate from unknown.
--
Luca.
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Weedy @ 2013-09-30 18:10 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-wireless
In-Reply-To: <52492FB0.3010201@einfach.org>
On Mon, Sep 30, 2013 at 4:00 AM, Bruno Randolf <br1@einfach.org> wrote:
> Or - can anyone recommend a good half size PCI-Express card that works well
> with ath9k?
http://www.ebay.com/itm/450M-Apple-AirPort-Extreme-Atheros-AR5BXB112-AR9380-N-card-NOT-AR5BXB92-AR5BXB72-/110965122470?ssPageName=ADME:L:OC:CA:3160
This is the current macbook pro card. Atheros talks about a half
length version without the high power amps but I don't know the part
number. And my laptop takes full sized cards :D
http://www.ebay.ca/sch/i.html?_sacat=0&_from=R40&_nkw=Atheros+half+AR5B22&_sop=15
This is the ARM based chromebook card. It includes bluetooth.
I own both cards and they work fine in linux and windows7. Atheros
bluetooth w7 drivers are a bitch.
I run gentoo so my kernel is hand rolled, maybe something in your
distro kernel is breaking stuff?
^ permalink raw reply
* pull request: TI wireless drivers 2013-09-30 (for 3.13)
From: Luca Coelho @ 2013-09-30 18:51 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Eliad Peller
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
Hi John,
Here are some patches intended for 3.13. Eliad is upstreaming a bunch
of patches that have been pending in the internal tree. Mostly bugfixes
and other small improvements.
Please let me know if you have any problems with it!
The following changes since commit 772eb433357704ec3d6e0daa727d9ec3e85f50c1:
rt2x00: Fix rf register for RT3070 (2013-09-26 15:17:30 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git for-linville
for you to fetch changes up to f2cede49ae7b9f51a6fe97ada16c27e4d03d05a3:
wlcore: always register dummy hardirq (2013-09-30 21:12:22 +0300)
----------------------------------------------------------------
Arik Nemtsov (3):
wlcore: ROC on AP channel before auth reply
wlcore: re-enable idle handling
wlcore: always register dummy hardirq
Eliad Peller (2):
wlcore: remove unsupported channels
wlcore: clarify and fix regulatory domain bit translation
Victor Goldenshtein (4):
wlcore: cleanup scan debug prints
wlcore: fix unsafe dereference of the wlvif
wl18xx: fix boot process in high temperature environment
wl18xx: print new RDL versions during boot
Yair Shapira (2):
wlcore: add new plt power-mode: CHIP_AWAKE
wlcore: disable elp sleep while in plt mode
drivers/net/wireless/ti/wl18xx/main.c | 95 ++++++++++++++++++++++++++++++---
drivers/net/wireless/ti/wl18xx/reg.h | 33 ++++++++----
drivers/net/wireless/ti/wlcore/cmd.c | 58 +++++++++++---------
drivers/net/wireless/ti/wlcore/main.c | 156 +++++++++++++++++++++++++++++++++++++++++++++---------
drivers/net/wireless/ti/wlcore/ps.c | 4 ++
drivers/net/wireless/ti/wlcore/scan.c | 27 +++++-----
drivers/net/wireless/ti/wlcore/testmode.c | 13 ++++-
drivers/net/wireless/ti/wlcore/tx.c | 27 +++++++---
drivers/net/wireless/ti/wlcore/tx.h | 3 ++
drivers/net/wireless/ti/wlcore/wlcore.h | 2 +
drivers/net/wireless/ti/wlcore/wlcore_i.h | 11 ++++
11 files changed, 342 insertions(+), 87 deletions(-)
--
Cheers,
Luca.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/3] ath10k: implement FW IE support
From: Kalle Valo @ 2013-09-30 19:05 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130927164636.2570.24076.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> FW IE format is needed for ath10k automatically detect what features the
> firmware image supports. This is important especially with 10.x firmwares which
> has a different interface.
>
> Please review.
>
> v2:
>
> * added accidentally dropped board file loading (michal)
>
> * check that ATH10K_FW_IE_FW_IMAGE is available, fail otherwise
>
> v3:
>
> * resend with changes really listed in v2
>
> ---
>
> Kalle Valo (3):
> ath10k: rename board_data in struct ath10k
> ath10k: store separate pointers for firmware data
> ath10k: implement firmware IE container support
All three applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/4] ath10k: split tid calculation from tx function
From: Kalle Valo @ 2013-09-30 19:08 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380292706-3609-2-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Why?
And empty commit logs are evil...
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/4] ath10k: split vdev_id calculation from tx function
From: Kalle Valo @ 2013-09-30 19:10 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380292706-3609-3-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Empty commit log.
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 25 +++++++++++++++----------
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 7415a60..4b7c949 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -1421,6 +1421,19 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)
> return ieee80211_get_qos_ctl(hdr)[0] & IEEE80211_QOS_CTL_TID_MASK;
> }
>
> +static u8 ath10k_tx_h_get_vdev_id(struct ath10k *ar,
> + struct ieee80211_tx_info *info)
> +{
> + if (info->control.vif)
> + return ath10k_vif_to_arvif(info->control.vif)->vdev_id;
> +
> + if (ar->monitor_enabled)
> + return ar->monitor_vdev_id;
> +
> + ath10k_warn("could not resolve vdev id\n");
> + return 0;
> +}
Empty line before return would be nice.
--
Kalle Valo
^ permalink raw reply
* Idea: wifi-over-ethernet (bear with me)
From: Erik Elmore @ 2013-09-30 19:40 UTC (permalink / raw)
To: linux-wireless
Hello, linux-wireless. I have an idea that I'd like to get some
feedback from you all. I admit this idea is weird/flawed/broken and
seemingly useless, but I do have a practical application in mind, so
please hear me out.
Imagine two physical locations, site 1 and 2, that are well outside of
normal wifi range of each other. Each site has a device that listens
for a subset of wifi frames and then sends them over a distribution
network to its counterpart at the other site. Each device will also
re-transmit frames received via the distribution network. Let's call
these devices listener1 and listener2.
Each site also contains one client device that wants to form an ad-hoc
network with the one in the other site. Assuming that listener1 and
listener2 are configured to forward frames having a TA belonging to
the client device in their site, is it feasible for these devices to
form an ad-hoc network with the help of the listener devices?
I do have a proof-of-concept in the works. It's not quite right yet,
but some things seem to work (sorta).
I welcome any comments, including those that call my sanity into question.
Thanks!
+=
Erik Elmore
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: John W. Linville @ 2013-09-30 20:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380532074.14467.2.camel@jlt4.sipsolutions.net>
On Mon, Sep 30, 2013 at 11:07:54AM +0200, Johannes Berg wrote:
> On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > The merge b35c8097 seems to have lost commit eabc4ac5d,
> > put the code back.
> >
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>
> Ah, forgot to say - John, I think you should apply this as a patch,
> having it in my pull request seems odd. But if you're of another opinion
> I can stick it into my next -next pull request too.
OK -- does this need to be treated as a fix? Or is -next OK?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] cfg80211: parse dfs region for internal regdb option
From: Luis R. Rodriguez @ 2013-09-30 20:56 UTC (permalink / raw)
To: Janusz Dziedzic, Johannes Berg; +Cc: linux-wireless, John W. Linville
In-Reply-To: <1379399136-3181-1-git-send-email-janusz.dziedzic@tieto.com>
On Mon, Sep 16, 2013 at 11:25 PM, Janusz Dziedzic
<janusz.dziedzic@tieto.com> wrote:
> Add support for parsing and setting the dfs region (ETSI, FCC, JP)
> when the internal regulatory database is used. Before this
> the DFS region was being ignored even if present on the used
> db.txt
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
It'd be nice to automate the list somehow in the future.
Luis
^ permalink raw reply
* Re: [RFC] ath9k: add HT40 spectral scan capability
From: Luis R. Rodriguez @ 2013-09-30 21:11 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: Lorenzo Bianconi, linville, linux-wireless, rodrigue
In-Reply-To: <20130930164840.GB15780@pandem0nium>
On Mon, Sep 30, 2013 at 06:48:40PM +0200, Simon Wunderlich wrote:
> On Thu, Sep 26, 2013 at 04:37:38PM +0200, Lorenzo Bianconi wrote:
>
> One more thing: please don't change the format for HT20 -
> there are already userspace programs which rely on the order
> of the parameters as they are now.
Great, where are these userpace programs?
Luis
^ permalink raw reply
* Re: [RFC] ath9k: add HT40 spectral scan capability
From: Lorenzo Bianconi @ 2013-09-30 21:25 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Simon Wunderlich, John Linville, linux-wireless
In-Reply-To: <20130930211115.GA29102@pogo>
Simon developed this UI:
https://github.com/simonwunderlich/FFT_eval
I developed a new one using qt-qwt (not compiled statically) in order
to support scan on HT40 channels:
https://github.com/LorenzoBianconi/ath_spectral
It is not finalized yet since I have to review it using Simon's
suggestions for the new format of "fft_sample" data structure.
Cheers,
Lorenzo
2013/9/30 Luis R. Rodriguez <rodrigue@qca.qualcomm.com>:
> On Mon, Sep 30, 2013 at 06:48:40PM +0200, Simon Wunderlich wrote:
>> On Thu, Sep 26, 2013 at 04:37:38PM +0200, Lorenzo Bianconi wrote:
>>
>> One more thing: please don't change the format for HT20 -
>> there are already userspace programs which rely on the order
>> of the parameters as they are now.
>
> Great, where are these userpace programs?
>
> Luis
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [RFC] ath9k: add HT40 spectral scan capability
From: Luis R. Rodriguez @ 2013-09-30 21:47 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Simon Wunderlich, John Linville, linux-wireless
In-Reply-To: <CAA2SeNJ47Rur8u5CeoQrULQRsKaiWATV8DA0VuSjrEB2B3=+VQ@mail.gmail.com>
On Mon, Sep 30, 2013 at 2:25 PM, Lorenzo Bianconi
<lorenzo.bianconi83@gmail.com> wrote:
> Simon developed this UI:
> https://github.com/simonwunderlich/FFT_eval
> I developed a new one using qt-qwt (not compiled statically) in order
> to support scan on HT40 channels:
> https://github.com/LorenzoBianconi/ath_spectral
> It is not finalized yet since I have to review it using Simon's
> suggestions for the new format of "fft_sample" data structure.
OK great! Then agreed with you. Can you please document spectral scan
progress somewhere here:
http://wireless.kernel.org/en/users/Drivers/ath9k
Maybe a new section? Pointers to the applications would be great too!
Luis
^ permalink raw reply
* Re: [RFC] ath9k: add HT40 spectral scan capability
From: Lorenzo Bianconi @ 2013-09-30 22:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Simon Wunderlich, John Linville, linux-wireless
In-Reply-To: <CAB=NE6VrOTUmpEpwM=4-p6smhDdi32S4en9TmzLUZH5rGTj9Hg@mail.gmail.com>
Ok, I will review the patch first and then I will upgrade the UI and
documentation
Regards,
Lorenzo
2013/9/30 Luis R. Rodriguez <mcgrof@do-not-panic.com>:
> On Mon, Sep 30, 2013 at 2:25 PM, Lorenzo Bianconi
> <lorenzo.bianconi83@gmail.com> wrote:
>> Simon developed this UI:
>> https://github.com/simonwunderlich/FFT_eval
>> I developed a new one using qt-qwt (not compiled statically) in order
>> to support scan on HT40 channels:
>> https://github.com/LorenzoBianconi/ath_spectral
>> It is not finalized yet since I have to review it using Simon's
>> suggestions for the new format of "fft_sample" data structure.
>
> OK great! Then agreed with you. Can you please document spectral scan
> progress somewhere here:
>
> http://wireless.kernel.org/en/users/Drivers/ath9k
>
> Maybe a new section? Pointers to the applications would be great too!
>
> Luis
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: brcmsmac causes soft lockup in 3.12-rc1
From: Adam Honse @ 2013-09-30 23:32 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20130925180057.GA11394@mail.catnarok.net>
Same here, using the 3.12.0-rc2 or newer from Ubuntu kernel PPA and my
BCM4313 works flawlessly, something it's never done before. Great
work!
On Wed, Sep 25, 2013 at 1:00 PM, Michael Stolovitzsky
<emestee@catnarok.net> wrote:
> On 13-09-24, Arend van Spriel wrote:
>> On 09/24/2013 02:52 AM, Michael Stolovitzsky wrote:
>> >On Mon, Sep 23, 2013 at 10:13:49AM +0200, Arend van Spriel wrote:
>> >>On 09/22/2013 12:34 AM, Michael Stolovitzsky wrote:
>> >>>Hi,
>> >>>
>> >>>On 3.12-rc1, modprobe brcmsmac causes a soft lockup (trace #1), effectively killing the box. This is a Lenovo S206
>> >>>with BCM4313 (14e4:4727), which I believe is a bluetooth combo board. After a while,
>> >>>RCU scheduler code detects a lockup (trace #2).
>> >>>
> [...]
>> >>
>> >>A fix for this problem has been submitted to John. I think it is in
>> >>transit to mainline so probably will be in 3.12-rc2.
>> >>
>> >>Here the URL of the patch:
>> >>
>> >>https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/patch/?id=aaa2ced15ad8dca8048666c9f70736424d696a6b
>> >>
>> >
> [...]
>> The patch is in 3.12-rc2. There have been more reports on that, but
>> it still needs to be investigated. Can you provide content of
>> /sys/kernel/debug/brcmsmac/bcma*/hardware? You need to have
>> CONFIG_BRCMDBG selected.
>>
>
> Here you go:
>
> board vendor: 14e4
> board type: 587
> board revision: 1307
> board flags: 402201
> board flags2: 884
> firmware revision: 262032c
>
> Once again thank you. On 3.12.0-rc2, brcmsmac seems to work fine, which has never happened before, and makes me
> very happy. Now I am getting new bug messages that I have to look at.
> --
> 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
^ permalink raw reply
* Re: Idea: wifi-over-ethernet (bear with me)
From: Julian Calaby @ 2013-10-01 0:42 UTC (permalink / raw)
To: Erik Elmore; +Cc: linux-wireless
In-Reply-To: <CA+=D8wmgsBimQhSYDqWbuzwM544YrX1Gj9gsmftQUHoD+QYeZw@mail.gmail.com>
Hi Erik,
On Tue, Oct 1, 2013 at 5:40 AM, Erik Elmore <erik@erikelmore.com> wrote:
> Hello, linux-wireless. I have an idea that I'd like to get some
> feedback from you all. I admit this idea is weird/flawed/broken and
> seemingly useless, but I do have a practical application in mind, so
> please hear me out.
>
> Imagine two physical locations, site 1 and 2, that are well outside of
> normal wifi range of each other. Each site has a device that listens
> for a subset of wifi frames and then sends them over a distribution
> network to its counterpart at the other site. Each device will also
> re-transmit frames received via the distribution network. Let's call
> these devices listener1 and listener2.
>
> Each site also contains one client device that wants to form an ad-hoc
> network with the one in the other site. Assuming that listener1 and
> listener2 are configured to forward frames having a TA belonging to
> the client device in their site, is it feasible for these devices to
> form an ad-hoc network with the help of the listener devices?
Firstly, what's the big plan? - I can't see any useful reason to
"tunnel" ad-hoc networks between two points, assuming that you did
have all the hardware and software working properly, what is the end
goal here, why do you need to have two devices at remote locations
form an ad-hoc network with each other? What goal do you have in mind
that wouldn't work with a normal managed network?
Just so you know, this sort of setup is almost painfully easy to
achieve if you use managed networks. - You could simply have a VPN or
tunnelling setup of some type between the two access points and have
that bridged into the wireless network. This would be 100% transparent
as far as clients on the network would be concerned. My previous job
had a network that worked somewhat like that with VPNs connecting
three offices with WiFi, two data centres and several remote clients
into a "single" big network.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH 0/2] nl80211/cfg80211: Support PMF on drivers with integrated AP SME
From: clanctot @ 2013-10-01 0:43 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Chet Lanctot, linville, linux-wireless, Johannes Berg
In-Reply-To: <20130926110934.GA5070@w1.fi>
> On Tue, Sep 17, 2013 at 12:31:34PM -0700, Chet Lanctot wrote:
>> These patches represent a small number of changes to the
>> nl80211/cfg80211 interface to support Protected Management Frames
>> (PMF, 802.11w) on an AP. Specifically, these changes are needed for
>> drivers that have the AP SME integrated.
>>
>> Support is added for drivers that do not implement the SA Query
>> procedure
>> that is part of PMF. Instead, the need for upper layer software to
>> do this procedure is advertised. And support is added so that whether
>> PMF should be used for station connections is communicated to the
>> driver.
>
> The patches here have some issues in not compiling and formatting
> (trailing whitespace) and as such, cannot be applied as-is. I'd expect a
> new version to be posted to address those issues.
>
> That said, if there is any feedback on the general direction used here,
> that would obviously be welcome even before the updated patches are
> posted.
>
> --
> Jouni Malinen PGP id EFC895FA
>
Thank you Jouni for your comments.
You are correct, a new version of the patches will be sent out that
address the compiling and formatting issues. I am also getting feedback
from others, and I will incorporate that feedback as well before sending
out the updated patches.
- Chet Lanctot
^ permalink raw reply
* Re: Idea: wifi-over-ethernet (bear with me)
From: Erik Elmore @ 2013-10-01 3:39 UTC (permalink / raw)
To: Julian Calaby; +Cc: linux-wireless
In-Reply-To: <CAGRGNgXy37rXWou4sWDfUe+UhpXqxLanhSaH0MPNw_oV+mYbOA@mail.gmail.com>
There are a few big ideas, but the one big idea that got me started on
this line of thought was to make it possible for devices that only
support ad-hoc networks to function over great distances.
On Mon, Sep 30, 2013 at 8:42 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
> Hi Erik,
>
> On Tue, Oct 1, 2013 at 5:40 AM, Erik Elmore <erik@erikelmore.com> wrote:
>> Hello, linux-wireless. I have an idea that I'd like to get some
>> feedback from you all. I admit this idea is weird/flawed/broken and
>> seemingly useless, but I do have a practical application in mind, so
>> please hear me out.
>>
>> Imagine two physical locations, site 1 and 2, that are well outside of
>> normal wifi range of each other. Each site has a device that listens
>> for a subset of wifi frames and then sends them over a distribution
>> network to its counterpart at the other site. Each device will also
>> re-transmit frames received via the distribution network. Let's call
>> these devices listener1 and listener2.
>>
>> Each site also contains one client device that wants to form an ad-hoc
>> network with the one in the other site. Assuming that listener1 and
>> listener2 are configured to forward frames having a TA belonging to
>> the client device in their site, is it feasible for these devices to
>> form an ad-hoc network with the help of the listener devices?
>
> Firstly, what's the big plan? - I can't see any useful reason to
> "tunnel" ad-hoc networks between two points, assuming that you did
> have all the hardware and software working properly, what is the end
> goal here, why do you need to have two devices at remote locations
> form an ad-hoc network with each other? What goal do you have in mind
> that wouldn't work with a normal managed network?
>
> Just so you know, this sort of setup is almost painfully easy to
> achieve if you use managed networks. - You could simply have a VPN or
> tunnelling setup of some type between the two access points and have
> that bridged into the wireless network. This would be 100% transparent
> as far as clients on the network would be concerned. My previous job
> had a network that worked somewhat like that with VPNs connecting
> three offices with WiFi, two data centres and several remote clients
> into a "single" big network.
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: julian.calaby@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
> .Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: Johannes Berg @ 2013-10-01 7:28 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20130930203206.GM10994@tuxdriver.com>
On Mon, 2013-09-30 at 16:32 -0400, John W. Linville wrote:
> On Mon, Sep 30, 2013 at 11:07:54AM +0200, Johannes Berg wrote:
> > On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
> > > From: Johannes Berg <johannes.berg@intel.com>
> > >
> > > The merge b35c8097 seems to have lost commit eabc4ac5d,
> > > put the code back.
> > >
> > > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> >
> > Ah, forgot to say - John, I think you should apply this as a patch,
> > having it in my pull request seems odd. But if you're of another opinion
> > I can stick it into my next -next pull request too.
>
> OK -- does this need to be treated as a fix? Or is -next OK?
I believe the merge damage only occurred during merging wireless.git (or
one of its upstreams) into wireless-next.git.
johannes
^ permalink raw reply
* iwlegacy: iwl4965 reload firmware issue.
From: Matt Chen @ 2013-10-01 8:17 UTC (permalink / raw)
To: linux-wireless; +Cc: kvoz123
Hi guys,
Recently a user reported a issue happened in his Intel 4965 wifi
issue. The issue happened to him is as below :
1. Boot system
2. Wait for 10 min
3. Look at dmesg output
412.869861] iwl4965 0000:03:00.0: Microcode SW error detected. Restarting
0x82000000.
[ 412.869867] iwl4965 0000:03:00.0: Loaded firmware version: 228.61.2.24
[ 412.869882] iwl4965 0000:03:00.0: Start IWL Error Log Dump:
[ 412.869884] iwl4965 0000:03:00.0: Status: 0x000213E4, count: 5
[ 412.870053] iwl4965 0000:03:00.0: Desc Time
data1 data2 line
[ 412.870056] iwl4965 0000:03:00.0: FH49_ERROR (0x000C)
1661571581 0x00000008 0x03130000 208
[ 412.870058] iwl4965 0000:03:00.0: pc blink1 blink2 ilink1 ilink2
hcmd
[ 412.870060] iwl4965 0000:03:00.0: 0x0046C 0x07A10 0x004C2 0x006DA 0x07A5A
0x2B0001C
[ 412.870062] iwl4965 0000:03:00.0: FH register values:
[ 412.870076] iwl4965 0000:03:00.0: FH49_RSCSR_CHNL0_STTS_WPTR_REG:
0X132c1e00
[ 412.870090] iwl4965 0000:03:00.0: FH49_RSCSR_CHNL0_RBDCB_BASE_REG:
0X0133bfe0
[ 412.870103] iwl4965 0000:03:00.0: FH49_RSCSR_CHNL0_WPTR:
0X000000f8
[ 412.870117] iwl4965 0000:03:00.0: FH49_MEM_RCSR_CHNL0_CONFIG_REG:
0X00819000
[ 412.870131] iwl4965 0000:03:00.0: FH49_MEM_RSSR_SHARED_CTRL_REG:
0X0000003c
[ 412.870144] iwl4965 0000:03:00.0: FH49_MEM_RSSR_RX_STATUS_REG:
0X03130000
[ 412.870158] iwl4965 0000:03:00.0: FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV:
0X00000000
[ 412.870171] iwl4965 0000:03:00.0: FH49_TSSR_TX_STATUS_REG:
0X07ff0002
[ 412.870185] iwl4965 0000:03:00.0: FH49_TSSR_TX_ERROR_REG:
0X00000000
[ 412.870282] ieee80211 phy0: Hardware restart was requested
I traced the path, found it happened in
drivers/net/wireless/iwlegacy/4965-mac.c: il4965_irq_tasklet(), which
is handling the interrupt from pci bus. Also found it happenes in :
/* Error detected by uCode */
if (inta & CSR_INT_BIT_SW_ERR) {
IL_ERR("Microcode SW error detected. " " Restarting 0x%X.\n", inta);
il->isr_stats.sw++;
il_irq_handle_error(il);
handled |= CSR_INT_BIT_SW_ERR;
}
The restart path is through il_irq_handle_error(il). My question is if
this is a firmware issue, driver issue or hardware issue ?
Thanks.
^ permalink raw reply
* [PATCH 0/4] brcm: rename firmware files and add new files
From: Arend van Spriel @ 2013-10-01 8:53 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Linux Wireless, Arend van Spriel
This series renames the firmware files to match the required filenames in
the brcmfmac driver. Previously, these files needed to be copied/linked to
a generic name that was used in the driver. So for older kernels this is still
needed.
Also included are new firmware files for BCM43241 and BCM4335. The brcmfmac
driver lists some more firmware files, but firmware is not yet released for
those chips.
Arend van Spriel (4):
brcm: rename firmware names expressing host interface type
brcm: add firmware file for BCM43241 SDIO chipset
brcm: add firmware for newer version of BCM43241 SDIO chipset
brcm: add firmware file for the BCM4335 SDIO chipset
WHENCE | 9 ++++++---
brcm/brcmfmac43241b0-sdio.bin | Bin 0 -> 455745 bytes
brcm/brcmfmac43241b4-sdio.bin | Bin 0 -> 403855 bytes
brcm/{brcmfmac4329.bin => brcmfmac4329-sdio.bin} | Bin 253748 -> 253748 bytes
brcm/{brcmfmac4330.bin => brcmfmac4330-sdio.bin} | Bin 222126 -> 222126 bytes
brcm/{brcmfmac4334.bin => brcmfmac4334-sdio.bin} | Bin 451566 -> 451566 bytes
brcm/brcmfmac4335-sdio.bin | Bin 0 -> 569291 bytes
7 files changed, 6 insertions(+), 3 deletions(-)
create mode 100644 brcm/brcmfmac43241b0-sdio.bin
create mode 100644 brcm/brcmfmac43241b4-sdio.bin
rename brcm/{brcmfmac4329.bin => brcmfmac4329-sdio.bin} (100%)
rename brcm/{brcmfmac4330.bin => brcmfmac4330-sdio.bin} (100%)
rename brcm/{brcmfmac4334.bin => brcmfmac4334-sdio.bin} (100%)
create mode 100644 brcm/brcmfmac4335-sdio.bin
--
1.7.10.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox