* 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: [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: [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: [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: 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: 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
* ath10k firmware in linux-firmware
From: Tim Gardner @ 2013-09-30 15:16 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
Kalle - Do you have a time frame for when you might request that ath10k
firmware be merged into upstream linux-firmware now that the driver has
been merged into the 3.11 kernel?
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: [PATCH] cfg80211: parse dfs region for internal regdb option
From: Johannes Berg @ 2013-09-30 14:31 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless, linville, rodrigue, mcgrof
In-Reply-To: <1379399136-3181-1-git-send-email-janusz.dziedzic@tieto.com>
On Tue, 2013-09-17 at 08:25 +0200, Janusz Dziedzic 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
Looks good to me, Luis?
johannes
^ permalink raw reply
* Re: [RFC] mac80211: correctly close cancelled scans
From: Johannes Berg @ 2013-09-30 14:30 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <1379396919-11983-1-git-send-email-emmanuel.grumbach@intel.com>
On Tue, 2013-09-17 at 08:48 +0300, Emmanuel Grumbach wrote:
> __ieee80211_scan_completed is called from a worker. This
> means that the following flow is possible.
>
> * driver calls ieee80211_scan_completed
> * mac80211 cancels the scan (that is already complete)
> * __ieee80211_scan_complete runs
>
> When scan_work will finally run, it will see that the scan
> hasn't been aborted and might even trigger another scan on
> another band. This leads to a situation where cfg80211's
> scan is not done and no further scan can be issued.
>
> Fix this by setting a new flag when a HW scan is being
> cancelled so that no other scan will be triggered.
I'll apply this
> + if (local->ops->cancel_hw_scan) {
> drv_cancel_hw_scan(local,
> rcu_dereference_protected(local->scan_sdata,
> lockdep_is_held(&local->mtx)));
> + }
WIthout the extra braces.
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: don't start p2p device while in RFKILL
From: Johannes Berg @ 2013-09-30 14:29 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <1379421036-6206-1-git-send-email-emmanuel.grumbach@intel.com>
On Tue, 2013-09-17 at 15:30 +0300, Emmanuel Grumbach wrote:
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> v2: Check the rfkill before adding the interface
I'll apply a fixed version that removes the check from the netdev
notifier where it would now be duplicate.
johannes
^ permalink raw reply
* Re: [PATCH 1/4] cfg80211: export reg_initiator_name()
From: Johannes Berg @ 2013-09-30 14:29 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1379607490-18972-2-git-send-email-mcgrof@do-not-panic.com>
On Thu, 2013-09-19 at 11:18 -0500, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
>
> Drivers can now use this to parse the regulatory request and
> be more verbose when needed.
Do drivers actually have to care about the initiator though?
johannes
^ permalink raw reply
* Re: Kernel panic in ieee80211_calculate_rx_timestamp
From: Johannes Berg @ 2013-09-30 14:27 UTC (permalink / raw)
To: Thomas Lindroth; +Cc: linux-wireless
In-Reply-To: <523B3BEA.9000100@gmail.com>
On Thu, 2013-09-19 at 20:01 +0200, Thomas Lindroth wrote:
> I recently got a ath9k_htc based dongle and running kismet for a few
> hours results in a kernel panic (divide error) in
> ieee80211_calculate_rx_timestamp with kernel 3.11.0.
>
> The problem seems to occur when the call to cfg80211_calculate_bitrate
> returns 0. I've used this patch to temporarily works around the problem.
Seems fair, but maybe it should print out the rate info so you can see
what was actually received - most likely this is a driver bug though.
If you submit a patch that can be applied with signed-off-by etc. I can
apply it.
johannes
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-next tree
From: Larry Finger @ 2013-09-30 14:26 UTC (permalink / raw)
To: Thierry Reding; +Cc: John W. Linville, linux-wireless, linux-next, linux-kernel
In-Reply-To: <1380540373-25352-11-git-send-email-treding@nvidia.com>
On 09/30/2013 06:26 AM, Thierry Reding wrote:
> Today's linux-next merge of the wireless-next tree got conflicts in
>
> drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
>
> I fixed it up (see below). Please check if the resolution looks correct.
>
> Thanks,
> Thierry
> ---
> diff --cc drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
> index f8973e5,80a0893..bb319b0
> --- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
> +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
> @@@ -217,10 -222,10 +215,9 @@@ void _rtl92ce_phy_lc_calibrate(struct i
> void rtl92c_phy_set_rfpath_switch(struct ieee80211_hw *hw, bool bmain);
> bool rtl92c_phy_config_rf_with_headerfile(struct ieee80211_hw *hw,
> enum radio_path rfpath);
> -bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw,
> - u32 rfpath);
> +bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw, u32 rfpath);
> - bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
> bool rtl92ce_phy_set_rf_power_state(struct ieee80211_hw *hw,
> - enum rf_pwrstate rfpwr_state);
> + enum rf_pwrstate rfpwr_state);
> void rtl92ce_phy_set_rf_on(struct ieee80211_hw *hw);
> bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
> void rtl92c_phy_set_io(struct ieee80211_hw *hw);
Thierry,
Yes, your fix is correct.
Larry
^ permalink raw reply
* Re: NetworkManager not connecting anymore
From: Arend van Spriel @ 2013-09-30 14:20 UTC (permalink / raw)
To: Dan Williams; +Cc: Arend van Spriel, linux-wireless
In-Reply-To: <1380549653.6136.4.camel@dcbw.foobar.com>
On 09/30/13 16:00, Dan Williams wrote:
> On Sun, 2013-09-29 at 11:11 +0200, Arend van Spriel wrote:
>> With a recent update on my Ubuntu 12.10 laptop, wireless connection is no
>> longer working with NetworkManager. It is working when using wpa_supplicant
>> directly. The nm-applet indicates 'device not ready' for the Wireless
>> Networks. Attached is the syslog upon inserting the wireless driver module,
>> which is brcmsmac. Not sure if the state change below correlates to the
>> nm-applet status.
>>
>> NetworkManager[1121]:<info> (wlan0): device state change: unmanaged ->
>> unavailable (reason 'managed') [10 20 2]
>
> 'unavailable' could mean a couple things:
>
> 1) supplicant isn't running or can't be contacted via D-Bus
Hi Dan,
Thanks for explaining. 1) seems to be the issue. 'ps -ae | grep wpa' did
not return anything. I decided to remove and install wpa_supplicant.
Sometimes the helpdesk approach works ;-)
Regards,
Arend
^ permalink raw reply
* Re: NetworkManager not connecting anymore
From: Dan Williams @ 2013-09-30 14:00 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <CAJ65rDzRUZcZG5+iz2TeQLW7YS+T5xD+M-BxpJp23N=W4dn1+g@mail.gmail.com>
On Sun, 2013-09-29 at 11:11 +0200, Arend van Spriel wrote:
> With a recent update on my Ubuntu 12.10 laptop, wireless connection is no
> longer working with NetworkManager. It is working when using wpa_supplicant
> directly. The nm-applet indicates 'device not ready' for the Wireless
> Networks. Attached is the syslog upon inserting the wireless driver module,
> which is brcmsmac. Not sure if the state change below correlates to the
> nm-applet status.
>
> NetworkManager[1121]: <info> (wlan0): device state change: unmanaged ->
> unavailable (reason 'managed') [10 20 2]
'unavailable' could mean a couple things:
1) supplicant isn't running or can't be contacted via D-Bus
2) rfkill is blocking wifi
3) the driver returned ENOENT in response to the dev_open() call,
indicating that it does not have any firmware available
The logs you've posted don't look complete; do you get *anything* else
shown? You can also:
killall -TERM NetworkManager
NetworkManager --no-daemon --log-level=debug
to get more information.
Let me know,
Dan
^ permalink raw reply
* Re: [PATCH] ti-connectivity: add wl1251 firmware and license
From: Felipe Balbi @ 2013-09-30 13:32 UTC (permalink / raw)
To: Ben Hutchings
Cc: balbi, Luca Coelho, Linux Kernel Mailing List, linux-wireless,
Pavel Machek
In-Reply-To: <1380512269.1441.10.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Mon, Sep 30, 2013 at 04:37:49AM +0100, Ben Hutchings wrote:
> On Wed, 2013-09-25 at 08:23 -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Sep 25, 2013 at 02:07:58PM +0300, Luca Coelho wrote:
> [...]
> > > Ah, and I forgot to say that you should update the WHENCE file
> > > accordingly too. Check the wl12xx and wl18xx drivers for examples.
> >
> > I'll send a pull request, but how about this ? I don't think we can
> > change the license. It seems like the other firmwares are using the
> > older license, I'd argue those should be changed to the new one, but
> > that's another discussion.
> [...]
>
> I haven't seen this pull request, so it looks like there is nothing for
> me to apply at the moment.
yeah, give me a couple more days, I need to finish something up here.
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Oleksij Rempel @ 2013-09-30 13:27 UTC (permalink / raw)
To: Bruno Randolf, linux-wireless, nbd, sujith; +Cc: Ingo Randolf
In-Reply-To: <524954BE.8060603@einfach.org>
Am 30.09.2013 12:38, schrieb Bruno Randolf:
> On 09/30/2013 10:28 AM, Oleksij Rempel wrote:
>> It works at least for me, as AP and as STA...
>
> Thanks, good to hear! :)
>
>> Check:
>> - PCIe related power managment - ASPM.
>
> That sounds most suspicious. Will try to see what can be done in the
> BIOS or if disabling ASPM in the kernel helps.
>
>> - WiFi related PM. "iw dev wlan0 get power_save"
>
> That would only affect STA and IBSS mode, right?
>
>> - defect device?
>
> Having the same problem on two setups... maybe but it's unlikely...
>
>>> I have a AR9287 PCI-Express card which is behaving more than weird with
>>> kernel 3.2 and with the current (3.10.4-1) backports drivers: It can't
>>> connect to APs (many reconnects), with hostap it _seems_ to work as an
>>> AP, but no beacons are seen and no stations can connect, similar in
>>> ad-hoc mode, and when bringing the interface down the whole system
>>> freezes...
>>
>> Is it regression? Are there any working kernel version?
>
> I have tried with 3.2 clean (Ubuntu 12.04 default) and with the
> mentioned backports version. If you point me to a known working
> backports version I can try it.
I use 3.11 right now. In case of PCIe issue, backport wont help you.
Test completely new kernel.
What is your host hardware?
>>> Or - can anyone recommend a good half size PCI-Express card that works
>>> well with ath9k?
>>
>> If you wont to bay some new toy, then take a look here:
>> http://wikidevi.com/wiki/Atheros
>> I would take AR9462, there are some interesting highlights ;) (suddenly
>> I do not have it right now)
>
> integrated bluetooth 4.0; 8bit Spectral Scan?
Here are some descriptions:
http://wikidevi.com/wiki/Atheros_WiFi_Support
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-09-30 12:52 UTC (permalink / raw)
To: linville; +Cc: simon.wunderlich, linux-wireless, johannes
Allow management frame injection on DFS channels if the channel has been CAC
checked and is available
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
---
net/mac80211/tx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 3456c04..edb1d3e 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
* radar detection by itself. We can do that later by adding a
* monitor flag interfaces used for AP support.
*/
- if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
- IEEE80211_CHAN_PASSIVE_SCAN)))
+ if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
+ IEEE80211_CHAN_NO_IBSS))) ||
+ ((chan->flags & IEEE80211_CHAN_RADAR) &&
+ chan->dfs_state != NL80211_DFS_AVAILABLE))
goto fail_rcu;
ieee80211_xmit(sdata, skb, chan->band);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Hans Verkuil @ 2013-09-30 11:57 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel, Mauro Carvalho Chehab, Greg Kroah-Hartman
In-Reply-To: <E1VMm13-0007hO-9l@rmk-PC.arm.linux.org.uk>
On 09/19/2013 11:44 PM, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Regards,
Hans
> ---
> drivers/staging/media/dt3155v4l/dt3155v4l.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> index 90d6ac4..081407b 100644
> --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
> +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> int err;
> struct dt3155_priv *pd;
>
> - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> - if (err)
> - return -ENODEV;
> - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (err)
> return -ENODEV;
> pd = kzalloc(sizeof(*pd), GFP_KERNEL);
>
^ permalink raw reply
* linux-next: manual merge of the wireless-next tree
From: Thierry Reding @ 2013-09-30 11:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, linux-next, linux-kernel
In-Reply-To: <1380540373-25352-1-git-send-email-treding@nvidia.com>
Today's linux-next merge of the wireless-next tree got conflicts in
drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
index f8973e5,80a0893..bb319b0
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
@@@ -217,10 -222,10 +215,9 @@@ void _rtl92ce_phy_lc_calibrate(struct i
void rtl92c_phy_set_rfpath_switch(struct ieee80211_hw *hw, bool bmain);
bool rtl92c_phy_config_rf_with_headerfile(struct ieee80211_hw *hw,
enum radio_path rfpath);
-bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw,
- u32 rfpath);
+bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw, u32 rfpath);
- bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
bool rtl92ce_phy_set_rf_power_state(struct ieee80211_hw *hw,
- enum rf_pwrstate rfpwr_state);
+ enum rf_pwrstate rfpwr_state);
void rtl92ce_phy_set_rf_on(struct ieee80211_hw *hw);
bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
void rtl92c_phy_set_io(struct ieee80211_hw *hw);
^ permalink raw reply
* Re: [PATCH 3.12] mac80211: fix a tx power handling regression
From: Felix Fietkau @ 2013-09-30 10:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380537498.14467.10.camel@jlt4.sipsolutions.net>
On 2013-09-30 12:38 PM, Johannes Berg wrote:
> On Mon, 2013-09-30 at 11:43 +0200, Felix Fietkau wrote:
>> On 2013-09-30 11:09 AM, Johannes Berg wrote:
>> > On Sun, 2013-09-29 at 14:48 +0200, Felix Fietkau wrote:
>> >> commit 1ea6f9c0d48b11b6ec3ec4b5579ec74fc3951cf8
>> >> "mac80211: handle TX power per virtual interface"
>> >>
>> >> This commit added support for tracking tx power configuration for
>> >> multiple interfaces, however instead of using the maximum value of all
>> >> virtual interfaces, it uses the minimum.
>> >
>> > I'm not sure it should be using the maximum? What if the AP required
>> > lowering TX power by way of TPC for example?
>> Shouldn't that only affect the virtual interface that is connected to
>> that AP?
> Yes, but not all drivers support per-interface TX power I guess?
>
>> If there's a regulatory requirement to use lower tx power, it should be
>> tracked as a limit somewhere else instead of implicitly being handled
>> via vif tx power configuration.
>
> Not sure I see why? It's an absolute value after we do the calculations
> in that interface that has the TPC.
Maybe we need to rework this somehow, but in the mean time, this patch
fixes a serious regression that I've been looking into for a while now.
I haven't worked out the exact conditions that trigger this yet, but
often when an AP VLAN gets destroyed and recreated, or when a new
temporary interface is brought up and then down again, the tx power for
*all* interfaces gets reset to the lowest possible level.
- Felix
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Bruno Randolf @ 2013-09-30 10:38 UTC (permalink / raw)
To: Oleksij Rempel, linux-wireless, nbd, sujith; +Cc: Ingo Randolf
In-Reply-To: <5249443E.3080700@rempel-privat.de>
On 09/30/2013 10:28 AM, Oleksij Rempel wrote:
> It works at least for me, as AP and as STA...
Thanks, good to hear! :)
> Check:
> - PCIe related power managment - ASPM.
That sounds most suspicious. Will try to see what can be done in the
BIOS or if disabling ASPM in the kernel helps.
> - WiFi related PM. "iw dev wlan0 get power_save"
That would only affect STA and IBSS mode, right?
> - defect device?
Having the same problem on two setups... maybe but it's unlikely...
>> I have a AR9287 PCI-Express card which is behaving more than weird with
>> kernel 3.2 and with the current (3.10.4-1) backports drivers: It can't
>> connect to APs (many reconnects), with hostap it _seems_ to work as an
>> AP, but no beacons are seen and no stations can connect, similar in
>> ad-hoc mode, and when bringing the interface down the whole system
>> freezes...
>
> Is it regression? Are there any working kernel version?
I have tried with 3.2 clean (Ubuntu 12.04 default) and with the
mentioned backports version. If you point me to a known working
backports version I can try it.
>> Or - can anyone recommend a good half size PCI-Express card that works
>> well with ath9k?
>
> If you wont to bay some new toy, then take a look here:
> http://wikidevi.com/wiki/Atheros
> I would take AR9462, there are some interesting highlights ;) (suddenly
> I do not have it right now)
integrated bluetooth 4.0; 8bit Spectral Scan?
Thanks!
bruno
^ permalink raw reply
* Re: [PATCH 3.12] mac80211: fix a tx power handling regression
From: Johannes Berg @ 2013-09-30 10:38 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <524947C0.7060607@openwrt.org>
On Mon, 2013-09-30 at 11:43 +0200, Felix Fietkau wrote:
> On 2013-09-30 11:09 AM, Johannes Berg wrote:
> > On Sun, 2013-09-29 at 14:48 +0200, Felix Fietkau wrote:
> >> commit 1ea6f9c0d48b11b6ec3ec4b5579ec74fc3951cf8
> >> "mac80211: handle TX power per virtual interface"
> >>
> >> This commit added support for tracking tx power configuration for
> >> multiple interfaces, however instead of using the maximum value of all
> >> virtual interfaces, it uses the minimum.
> >
> > I'm not sure it should be using the maximum? What if the AP required
> > lowering TX power by way of TPC for example?
> Shouldn't that only affect the virtual interface that is connected to
> that AP?
Yes, but not all drivers support per-interface TX power I guess?
> If there's a regulatory requirement to use lower tx power, it should be
> tracked as a limit somewhere else instead of implicitly being handled
> via vif tx power configuration.
Not sure I see why? It's an absolute value after we do the calculations
in that interface that has the TPC.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Run deferred scan if last roc_list item is not started
From: Johannes Berg @ 2013-09-30 10:37 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20130930093605.GA23614@w1.fi>
On Mon, 2013-09-30 at 12:36 +0300, Jouni Malinen wrote:
> mac80211 scan processing could get stuck if roc work for pending, but
> not started when a scan request was deferred due to such roc item.
> Normally the deferred scan would be started from
> ieee80211_start_next_roc(), but ieee80211_sw_roc_work() calls that only
> if the finished ROC was started. Fix this by calling
> ieee80211_run_deferred_scan() in the case the last ROC was not actually
> started.
>
> This issue was hit relatively easily in P2P find operations where Listen
> state (remain-on-channel) and Search state (scan) are repeated in a
> loop.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 3.12 2/2] mac80211: update sta->last_rx on acked tx frames
From: Johannes Berg @ 2013-09-30 10:34 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <52494861.8010007@openwrt.org>
On Mon, 2013-09-30 at 11:46 +0200, Felix Fietkau wrote:
> On 2013-09-30 11:10 AM, Johannes Berg wrote:
> > On Sun, 2013-09-29 at 21:39 +0200, Felix Fietkau wrote:
> >> When clients are idle for too long, hostapd sends nullfunc frames for
> >> probing. When those are acked by the client, the idle time needs to be
> >> updated.
> >>
> >> To make this work (and to avoid unnecessary probing), update sta->last_rx
> >> whenever an ACK was received for a tx packet. Only do this if the flag
> >> IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
> >
> > Why that last bit? If we got an ack status, wouldn't it be OK to do
> > either way? Or are you saying drivers are lying more often than not
> > otherwise?
> I added that just in case, some drivers might not be fully reliable wrt.
> reporting the ACK status.
Ok, I'll apply it.
johannes
^ 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