* Re: ath5k: controlling powersave with iw or iwconfig fails
From: Bob Copeland @ 2011-10-20 14:29 UTC (permalink / raw)
To: Mohammed Shafi
Cc: sedat.dilek, Joerg Pommnitz, linux-wireless@vger.kernel.org,
ath5k-users@lists.ath5k.org
In-Reply-To: <CAD2nsn3zkAgCf=_Y1CUt0X1qw7py4oEJ5sqaod_KYJxo68G1nQ@mail.gmail.com>
On Thu, Oct 20, 2011 at 7:46 AM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 5:03 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>> Which iw version?
>
> looks like its ath5k does not supports station power save.
Yes, that is the reason.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [ath5k-devel] Support for Linux WiFi stack (+wpa_supplicant) in Android
From: Bob Copeland @ 2011-10-20 14:24 UTC (permalink / raw)
To: Dani Camps; +Cc: linux-wireless
In-Reply-To: <1319092629.45912.YahooMailNeo@web29720.mail.ird.yahoo.com>
[trimmed CC because none of the mailing lists are the proper place for
this query, and added l-w back]
On Thu, Oct 20, 2011 at 2:37 AM, Dani Camps <danicamps81@yahoo.com> wrote:
> Dear all,
> I would like to ask whether there is support for the Linux Wi-Fi stack (+
> wpa_supplicant) in Android. In http://bobcopeland.com/android_wifi.html it
> is mentioned that the first Android developer phone uses a driver from TI
> that is GPLd and included within mac80211 (wl12xx).
This is not what my (dated) webpage says -- it says that it is
possible to use wl12xx *instead* of the vendor driver with Android.
Have a look at the AOSP code to know for yourself which drivers
Android uses. Source for drivers is generally available but last time
I looked (and it was quite a while ago) the two main drivers, TI and
broadcom, used their own WEXT ioctls and not cfg80211 etc. Maybe this
has changed since, I don't know.
> PS: Apologies if this is not the best mailing list for this topic, but
> linux-wireless was returning my emails
Try disabling HTML email.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: wwguy @ 2011-10-20 14:10 UTC (permalink / raw)
To: Norbert Preining
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111020045927.GB23044@gamma.logic.tuwien.ac.at>
Hi Norbert,
On Wed, 2011-10-19 at 21:59 -0700, Norbert Preining wrote:
> Hi Wey,
>
> so I am now at the university, and it seems your last patch
> did wonder. Here a log after waking up from suspend at university...
>
Great, this is just a test patch, we will figure out what is the correct
way to handle this and fix the issue for good :-)
Thanks
Wey
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-10-20 13:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <1319118625.3959.16.camel@jlt3.sipsolutions.net>
> Just "iw wlan0 scan" output or so. Basically I just want the BSSID/freq
> to see which APs are on which band.
Ok, no prob, do it Wed.
Bye
N
^ permalink raw reply
* Commanding sleep/awake from mac80211
From: Andrés García Saavedra @ 2011-10-20 13:52 UTC (permalink / raw)
To: linux-wireless
Hi all,
I am testing a custom algorithm whereby I'd like to adaptively command
a STA to sleep/awake. Of course I would like to do so in the higher
level possible (for simplicity). The following is a sort of a summary
of my conclusions on the "state-of-art" on the implementation of such
a thing. I would like to ask you whether i am totally misleaded here.
Thanks in advance!
* mac80211: I can see in mac80211 that the function
ap_sta_ps_start/end() is defined to notify drivers of such transitions
using drv_sta_notify(STA_NOTIFY_AWAKE/SLEEP) callback. This looked
promising but... reading ath5k/ath9k/b43 driver codes, the atheros
ones do not implement these notification handlers at all, and b43 does
not do anything important eventually with them.
So, my guess is that actually the drivers themselves are the ones in
commanding the powersaving mode transitions awake/sleep regardless of
what mac80211 "could say".
* ath5k: seems to not command HW to sleep ever. (Only implemented the
"hw on hold" which is not used within ath5k).
* ath9k: Indeed it schedules sleep/awake timers. This way, it is
ath9k decision regardless what mac80211 say.
* b43: seems to not command HW to sleep ever...
Again, I'd appreciate if someone would point me out whether my
conclusions are correct.
Thanks!
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Johannes Berg @ 2011-10-20 13:50 UTC (permalink / raw)
To: Norbert Preining
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <56FBBFB3-4DC9-4CB6-939A-8F0130EBCB9B@logic.at>
On Thu, 2011-10-20 at 22:45 +0900, Norbert Preining wrote:
> Hi Johannes,
>
> > did you have scan information for these APs?
>
> Unfortunately not, but I can get them when I am back on Wednesday, if you want.
>
> Just let me know what exactely.
Just "iw wlan0 scan" output or so. Basically I just want the BSSID/freq
to see which APs are on which band.
johannes
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-10-20 13:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <1319096418.3959.1.camel@jlt3.sipsolutions.net>
Hi Johannes,
> did you have scan information for these APs?
Unfortunately not, but I can get them when I am back on Wednesday, if you want.
Just let me know what exactely.
Best wishes
Norbert
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-20 13:35 UTC (permalink / raw)
To: v4mp; +Cc: linux-wireless
In-Reply-To: <loom.20111020T114336-286@post.gmane.org>
On 10/20/2011 04:47 AM, v4mp wrote:
>
>
> i'm sorry but i don't know how to recompile kernel to apply this patch,
> i'm using the 3.1.oneric.rc9 for ubuntu precompiled
> can u recompile it with this patch,
> and then send me the compiled kernel to install?
I do not use Ubuntu, thus I cannot compile the kernel for you.
Larry
^ permalink raw reply
* Re: ath5k: controlling powersave with iw or iwconfig fails
From: Mohammed Shafi @ 2011-10-20 11:46 UTC (permalink / raw)
To: sedat.dilek
Cc: Joerg Pommnitz, linux-wireless@vger.kernel.org,
ath5k-users@lists.ath5k.org
In-Reply-To: <CA+icZUXyYSVUA-PTCQB7z167iLAnh83DEJxOGoYB4qxaFkTZog@mail.gmail.com>
On Thu, Oct 20, 2011 at 5:03 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> Which iw version?
looks like its ath5k does not supports station power save.
>
> - Sedat -
>
> On Thu, Oct 20, 2011 at 1:19 PM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
>> Hello all,
>> trying to disable PS on ath5k (Linux 3.0) gives:
>>
>> iw dev wlan0 set power_save off
>> command failed: Operation not supported (-95)
>>
>>
>> Is there any special magic required to disable power saving?
>> It seems to interfere with our amplifier...
>>
>>
>> --
>> Regards
>> Joerg
>>
>> --
>> 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
>>
> --
> 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
>
--
shafi
^ permalink raw reply
* Re: ath5k: controlling powersave with iw or iwconfig fails
From: Joerg Pommnitz @ 2011-10-20 11:46 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: linux-wireless@vger.kernel.org, ath5k-users@lists.ath5k.org
In-Reply-To: <CA+icZUXyYSVUA-PTCQB7z167iLAnh83DEJxOGoYB4qxaFkTZog@mail.gmail.com>
iw is 0.9.22, but I just found part of the answer myself. Controlling PS in
IBSS mode is not supported (I failed to mention the IBSS part in my previous
mail).
Question: Is any power saving going on in IBSS mode at all? I'm seeing lots
of Probe-Requests that I thought were related to PS.
--
Regards
Joerg
----- Ursprüngliche Message -----
> Von: Sedat Dilek <sedat.dilek@googlemail.com>
> An: Joerg Pommnitz <pommnitz@yahoo.com>
> Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>; "ath5k-users@lists.ath5k.org" <ath5k-users@lists.ath5k.org>
> Gesendet: 13:33 Donnerstag, 20.Oktober 2011
> Betreff: Re: ath5k: controlling powersave with iw or iwconfig fails
>
> Which iw version?
>
> - Sedat -
>
> On Thu, Oct 20, 2011 at 1:19 PM, Joerg Pommnitz <pommnitz@yahoo.com>
> wrote:
>> Hello all,
>> trying to disable PS on ath5k (Linux 3.0) gives:
>>
>> iw dev wlan0 set power_save off
>> command failed: Operation not supported (-95)
>>
>>
>> Is there any special magic required to disable power saving?
>> It seems to interfere with our amplifier...
>>
>>
>> --
>> Regards
>> Joerg
>>
>> --
>> 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: ath5k: controlling powersave with iw or iwconfig fails
From: Sedat Dilek @ 2011-10-20 11:33 UTC (permalink / raw)
To: Joerg Pommnitz
Cc: linux-wireless@vger.kernel.org, ath5k-users@lists.ath5k.org
In-Reply-To: <1319109568.26974.YahooMailNeo@web161206.mail.bf1.yahoo.com>
Which iw version?
- Sedat -
On Thu, Oct 20, 2011 at 1:19 PM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
> Hello all,
> trying to disable PS on ath5k (Linux 3.0) gives:
>
> iw dev wlan0 set power_save off
> command failed: Operation not supported (-95)
>
>
> Is there any special magic required to disable power saving?
> It seems to interfere with our amplifier...
>
>
> --
> Regards
> Joerg
>
> --
> 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
* ath5k: controlling powersave with iw or iwconfig fails
From: Joerg Pommnitz @ 2011-10-20 11:19 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, ath5k-users@lists.ath5k.org
Hello all,
trying to disable PS on ath5k (Linux 3.0) gives:
iw dev wlan0 set power_save off
command failed: Operation not supported (-95)
Is there any special magic required to disable power saving?
It seems to interfere with our amplifier...
--
Regards
Joerg
^ permalink raw reply
* Re: Available nl80211 multicast groups
From: Johannes Berg @ 2011-10-20 11:22 UTC (permalink / raw)
To: André Prata; +Cc: linux-wireless
In-Reply-To: <CAGEq-jBnU4gmb+A7ox3O0vwSr0HFkccEqBydH5cqNChZ_hTkDQ@mail.gmail.com>
On Wed, 2011-10-19 at 20:30 +0100, André Prata wrote:
> Hi!
>
> I saw on your code that you resolve the multicas id of several groups
> for the nl80211 family /online/, like "scan" and "mlme". I'd like to
> know if there are defined constants for those IDs (i'm guessing
> they're not).
There's no list it seems -- you'll have to look at nl80211.c.
> Also I wanted to know what other groups exist and what messages I
> should expect from them (no docs, or my bad search skills?).
> Is there a multicast group to get reports on link quality changes, or
> similar, or is that only available through polling?
You can subscribe to such changes though I think only one application
can do that right now and wpa_s will do it.
johannes
^ permalink raw reply
* Re: [PATCH 5/6] mac80211: add WMM IE to mesh frames
From: Johannes Berg @ 2011-10-20 11:16 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, anagar6, devel, linville
In-Reply-To: <1319072606-28291-6-git-send-email-thomas@cozybit.com>
On Wed, 2011-10-19 at 18:03 -0700, Thomas Pedersen wrote:
> Include the WMM IE in mesh peering and beacon frames. This is needed
> tell any potential peers what our WMM / EDCA parameters are.
The goal seems fine but why bother building the WMM IE out of the actual
TX queue configuration? Shouldn't it normally be the other way around?
But I have no idea how QoS is supposed to work in a mesh...
johannes
^ permalink raw reply
* Re: [PATCH 2/3] mac80211: find correct IE offset in mesh beacons
From: Johannes Berg @ 2011-10-20 11:13 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, linville
In-Reply-To: <1319070203-22097-2-git-send-email-thomas@cozybit.com>
> - baselen = (u8 *) mgmt->u.probe_resp.variable - (u8 *) mgmt;
> + switch (stype) {
> + case IEEE80211_STYPE_PROBE_RESP:
> + ies = (u8 *) mgmt->u.probe_resp.variable;
> + break;
> + case IEEE80211_STYPE_BEACON:
> + ies = (u8 *) mgmt->u.beacon.variable;
> + break;
> + default:
> + return;
> + }
> +
Does that really make sense? the offset is the same anyway and we don't
get here with other frames.
johannes
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: v4mp @ 2011-10-20 9:47 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4E9F97B4.5010304@lwfinger.net>
i'm sorry but i don't know how to recompile kernel to apply this patch,
i'm using the 3.1.oneric.rc9 for ubuntu precompiled
can u recompile it with this patch,
and then send me the compiled kernel to install?
^ permalink raw reply
* Re: [PATCH 4/6] mac80211: allow frame aggregation for mesh
From: Christian Lamparter @ 2011-10-20 9:46 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, anagar6, devel, johannes, linville
In-Reply-To: <1319072606-28291-5-git-send-email-thomas@cozybit.com>
On Thursday, October 20, 2011 03:03:24 AM Thomas Pedersen wrote:
> Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
> Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
> ---
> net/mac80211/agg-rx.c | 3 ++-
> net/mac80211/agg-tx.c | 4 +++-
> net/mac80211/ht.c | 3 ++-
> net/mac80211/rx.c | 1 +
> 4 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
> index 2ac0339..36c2836 100644
> --- a/net/mac80211/agg-tx.c
> +++ b/net/mac80211/agg-tx.c
> @@ -378,6 +379,7 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
> * by drivers or the standard.
> */
> if (sdata->vif.type != NL80211_IFTYPE_STATION &&
> + sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
> sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
> sdata->vif.type != NL80211_IFTYPE_AP)
> return -EINVAL;
just a nitpick, but it looks like the comment in agg-tx.c
seems to be a little out of date. Hence, would you mind
removing it as well?
/*
* The aggregation code is not prepared to handle
* anything but STA/AP due to the BSSID handling.
* IBSS could work in the code but isn't supported
* by drivers or the standard.
*/
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
sdata->vif.type != NL80211_IFTYPE_AP)
return -EINVAL;
Regards,
Chr
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Pekka Enberg @ 2011-10-20 9:12 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: Norbert Preining, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1319006699.31823.65.camel@wwguy-huron>
On Wed, Oct 19, 2011 at 9:44 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> As for the problems, I'm using iPhone 3G internet via WiFi sharing and
>> connection seems to die few times a day or if I take the phone far
>> enough from the laptop. I usually turn off the AP for a while and use
>> NetworkManager on the laptop to disable/enable networking to make it
>> come back up.
>>
>> I haven't tested anything but 3.1-rcX kernels on this machine but I
>> can do git bisect too if it comes to that.
>>
> I am just try to understand if you encounter the same problem as
> Norbert. if you can dump the tx_queue
> in /sys/kernel/debug/ieee80211/phX/iwlagn/debug folder and send me the
> log, thsat will be great.
Here's a dump of a very typical issue I'm seeing. I left the office
with my phone and once I came back, my laptop refused to reconnect to
the AP until I restarted wireless networking from NetworkManager. I've
sometimes seen the same symptoms even with laptop and the phone being
physically close to each other.
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/wd_timeout
cat: /sys/kernel/debug/ieee80211/phy0/iwlagn/debug/wd_timeout: Invalid argument
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/rxon_filter_flags
0x0004
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/rxon_flags
0x8005
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/reply_tx_error
Statistics_TX_Error:
DELAY: 0
FEW_BYTES: 0
BT_PRIO: 0
QUIET_PERIOD: 0
CALC_TTAK: 0
INTERNAL_CROSSED_RETRY: 0
SHORT_LIMIT: 0
LONG_LIMIT: 24
FIFO_UNDERRUN: 0
DRAIN_FLOW: 0
RFKILL_FLUSH: 0
LIFE_EXPIRE: 0
DEST_PS: 0
HOST_ABORTED: 0
BT_RETRY: 0
STA_INVALID: 0
FRAG_DROPPED: 0
TID_DISABLE: 0
FIFO_FLUSHED: 0
INSUFFICIENT_CF_POLL: 0
PASSIVE_NO_RX: 1
NO_BEACON_ON_RADAR: 0
UNKNOWN: 0
Statistics_Agg_TX_Error:
UNDERRUN_MSK: 0
BT_PRIO_MSK: 0
FEW_BYTES_MSK: 0
ABORT_MSK: 0
LAST_SENT_TTL_MSK: 0
LAST_SENT_TRY_CNT_MSK: 0
LAST_SENT_BT_KILL_MSK: 0
SCD_QUERY_MSK: 0
TEST_BAD_CRC32_MSK: 0
RESPONSE_MSK: 0
DUMP_TX_MSK: 0
DELAY_TX_MSK: 0
UNKNOWN: 0
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/ucode_bt_stats
Statistics Flag(0x30002):
Operational Frequency: 2.4 GHz
TGj Narrow Band: disabled
Statistics_BT:
current accumulative
hi_priority_tx_req_cnt: 0 0
hi_priority_tx_denied_cnt: 0 0
lo_priority_tx_req_cnt: 0 0
lo_priority_tx_denied_cnt: 0 0
hi_priority_rx_req_cnt: 0 0
hi_priority_rx_denied_cnt: 0 0
lo_priority_rx_req_cnt: 0 0
lo_priority_rx_denied_cnt: 0 0
(rx)num_bt_kills: 0 0
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/ucode_tracing
ucode trace timer is Off
non_wraps_count: 0
wraps_once_count: 0
wraps_more_count: 0
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/chain_noise
active_chains: 3
chain_noise_a: 330
chain_noise_b: 335
chain_noise_c: 0
chain_signal_a: 575
chain_signal_b: 674
chain_signal_c: 0
beacon_count: 16
disconn_array: 0 0 1
delta_gain_code: 4 0 0
radio_write: 1
state: 3
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/sensitivity
auto_corr_ofdm: 80
auto_corr_ofdm_mrc: 128
auto_corr_ofdm_x1: 105
auto_corr_ofdm_mrc_x1: 192
auto_corr_cck: 125
auto_corr_cck_mrc: 160
last_bad_plcp_cnt_ofdm: 0
last_fa_cnt_ofdm: 0
last_bad_plcp_cnt_cck: 0
last_fa_cnt_cck: 0
nrg_curr_state: 0
nrg_prev_state: 0
nrg_value: 0 0 0 0 0 0 0 0 0 0
nrg_silence_rssi: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
nrg_silence_ref: 0
nrg_energy_idx: 0
nrg_silence_idx: 0
nrg_th_cck: 97
nrg_auto_corr_silence_diff: 0
num_in_cck_no_fa: 0
nrg_th_ofdm: 100
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/protection_mode
use rts/cts for aggregation
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/txfifo_flush
cat: /sys/kernel/debug/ieee80211/phy0/iwlagn/debug/txfifo_flush:
Invalid argument
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/ucode_general_stats
Statistics Flag(0x30002):
Operational Frequency: 2.4 GHz
TGj Narrow Band: disabled
Statistics_General: current cumulative delta max
temperature: 32
temperature_m: 3437
ttl_timestamp: 1351982035
burst_check: 0 888 32 33
burst_count: 0 0 0 0
wait_for_silence_timeout_count: 0 101 1 1
sleep_time: 0 0 0 0
slots_out: 0 0 0 0
slots_idle: 0 0 0 0
tx_on_a: 0 0 0 0
tx_on_b: 0 0 0 0
exec_time: 0 0 0 0
probe_time: 0 233 1 1
rx_enable_counter: 0 0 0 0
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/ucode_tx_stats
Statistics Flag(0x30002):
Operational Frequency: 2.4 GHz
TGj Narrow Band: disabled
Statistics_Tx: current cumulative delta max
preamble: 0 69043 5 156
rx_detected_cnt: 0 1175 1 34
bt_prio_defer_cnt: 0 0 0 0
bt_prio_kill_cnt: 0 0 0 0
few_bytes_cnt: 0 0 0 0
cts_timeout: 0 0 0 0
ack_timeout: 0 2410 2 45
expected_ack_cnt: 0 37195 5 81
actual_ack_cnt: 0 34785 3 73
dump_msdu_cnt: 0 64 2 3
abort_nxt_frame_mismatch: 0 0 0 0
abort_missing_nxt_frame: 0 0 0 0
cts_timeout_collision: 0 0 0 0
ack_ba_timeout_collision: 0 146 1 4
agg ba_timeout: 0 0 0 0
agg ba_resched_frames: 0 0 0 0
agg scd_query_agg_frame: 0 0 0 0
agg scd_query_no_agg: 0 0 0 0
agg scd_query_agg: 0 0 0 0
agg scd_query_mismatch: 0 0 0 0
agg frame_not_ready: 0 0 0 0
agg underrun: 0 0 0 0
agg bt_prio_kill: 0 0 0 0
agg rx_ba_rsp_cnt: 0 0 0 0
tx power: (1/2 dB step)
antenna A: 0x1C
antenna B: 0x1C
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/ucode_rx_stats
Statistics Flag(0x30002):
Operational Frequency: 2.4 GHz
TGj Narrow Band: disabled
Statistics_Rx - OFDM: current cumulative delta max
ina_cnt: 4 1739356 3 2107
fina_cnt: 2 1407532 2 773
plcp_err: 2 1241567 2 773
crc32_err: 0 7362 1 85
overrun_err: 0 0 0 0
early_overrun_err: 0 0 0 0
crc32_good: 0 172221 4 283
false_alarm_cnt: 2 354918 1 2139
fina_sync_err_cnt: 0 1490 1 30
sfd_timeout: 0 0 0 0
fina_timeout: 0 0 0 0
unresponded_rts: 0 0 0 0
rxe_frame_lmt_ovrun: 0 121 1 30
sent_ack_cnt: 0 30667 3 72
sent_cts_cnt: 0 0 0 0
sent_ba_rsp_cnt: 0 0 0 0
dsp_self_kill: 0 0 0 0
mh_format_err: 0 0 0 0
re_acq_main_rssi_sum: 0 0 0 0
Statistics_Rx - CCK: current cumulative delta max
ina_cnt: 1 1714491 1 1408
fina_cnt: 1 1713486 1 1407
plcp_err: 1 603100 1 1270
crc32_err: 0 3851 1 27
overrun_err: 0 0 0 0
early_overrun_err: 0 0 0 0
crc32_good: 0 650281 8 112
false_alarm_cnt: 0 0 0 0
fina_sync_err_cnt: 0 1060 1 3
sfd_timeout: 0 0 0 0
fina_timeout: 0 0 0 0
unresponded_rts: 0 0 0 0
rxe_frame_lmt_ovrun: 0 2 1 1
sent_ack_cnt: 0 52 1 5
sent_cts_cnt: 0 0 0 0
sent_ba_rsp_cnt: 0 0 0 0
dsp_self_kill: 0 0 0 0
mh_format_err: 0 0 0 0
re_acq_main_rssi_sum: 0 0 0 0
Statistics_Rx - GENERAL: current cumulative delta max
bogus_cts: 0 2 1 1
bogus_ack: 0 9 1 2
non_bssid_frames: 0 0 0 0
filtered_frames: 0 549185 1 83
non_channel_beacons: 0 0 0 0
channel_beacons: 0 87279 1 1
num_missed_bcon: 0 110 6 10
adc_rx_saturation_time: 0 0 0 0
ina_detect_search_tm: 0 77790045 65535 65535
beacon_silence_rssi_a: 0 32156769 3082 11822
beacon_silence_rssi_b: 0 63539976 6419 12593
beacon_silence_rssi_c: 0 0 0 0
interference_data_flag: 0 1236 1 1
channel_load: 0 988646230 2218 4167874
dsp_false_alarms: 0 163030 18 255
beacon_rssi_a: 0 127134 1 45
beacon_rssi_b: 0 91295 3 45
beacon_rssi_c: 0 0 0 0
beacon_energy_a: 0 215369 5 88
beacon_energy_b: 0 100030 2 91
beacon_energy_c: 0 113982 5 93
Statistics_Rx - OFDM_HT: current cumulative delta max
plcp_err: 0 0 0 0
overrun_err: 0 0 0 0
early_overrun_err: 0 0 0 0
crc32_good: 0 0 0 0
crc32_err: 0 0 0 0
mh_format_err: 0 0 0 0
agg_crc32_good: 0 115 2 30
agg_mpdu_cnt: 0 198 15 44
agg_cnt: 0 69 1 17
unsupport_mcs: 0 356 1 31
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/force_reset
Force reset method 0
number of reset request: 102
number of reset request success: 79
number of reset request reject: 23
reset duration: 3000
Force reset method 1
number of reset request: 0
number of reset request success: 0
number of reset request reject: 0
reset duration: 5000
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/plcp_delta
50
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/missed_beacon
5
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/fh_reg
FH register values:
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X0fff1e00
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X00fff1f0
FH_RSCSR_CHNL0_WPTR: 0X000000d8
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
FH_TSSR_TX_STATUS_REG: 0X07ff0001
FH_TSSR_TX_ERROR_REG: 0X00000000
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/csr
cat: /sys/kernel/debug/ieee80211/phy0/iwlagn/debug/csr: Invalid argument
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/clear_traffic_statistics
cat: /sys/kernel/debug/ieee80211/phy0/iwlagn/debug/clear_traffic_statistics:
Invalid argument
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/clear_ucode_statistics
cat: /sys/kernel/debug/ieee80211/phy0/iwlagn/debug/clear_ucode_statistics:
Invalid argument
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/power_save_status
Power Save Status: PHY
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/tx_queue
hwq 00: read=37 write=37 stop=0 swq_id=0x00 (ac 0/hwq 0)
stop-count: 0
hwq 01: read=0 write=0 stop=0 swq_id=0x05 (ac 1/hwq 1)
stop-count: 0
hwq 02: read=194 write=194 stop=0 swq_id=0x0a (ac 2/hwq 2)
stop-count: 0
hwq 03: read=0 write=0 stop=0 swq_id=0x0f (ac 3/hwq 3)
stop-count: 0
hwq 04: read=0 write=0 stop=0 swq_id=0x13 (ac 3/hwq 4)
hwq 05: read=0 write=0 stop=0 swq_id=0x16 (ac 2/hwq 5)
hwq 06: read=0 write=0 stop=0 swq_id=0x19 (ac 1/hwq 6)
hwq 07: read=0 write=0 stop=0 swq_id=0x1c (ac 0/hwq 7)
hwq 08: read=0 write=0 stop=0 swq_id=0x22 (ac 2/hwq 8)
hwq 09: read=75 write=75 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 10: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 11: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 12: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 13: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 14: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 15: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 16: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 17: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 18: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
hwq 19: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/rx_queue
read: 223
write: 221
free_count: 32
closed_rb_num: 223
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/traffic_log
Tx Queue
q[0]: read_ptr: 37, write_ptr: 37
q[1]: read_ptr: 0, write_ptr: 0
q[2]: read_ptr: 194, write_ptr: 194
q[3]: read_ptr: 0, write_ptr: 0
q[4]: read_ptr: 0, write_ptr: 0
q[5]: read_ptr: 0, write_ptr: 0
q[6]: read_ptr: 0, write_ptr: 0
q[7]: read_ptr: 0, write_ptr: 0
q[8]: read_ptr: 0, write_ptr: 0
q[9]: read_ptr: 75, write_ptr: 75
q[10]: read_ptr: 0, write_ptr: 0
q[11]: read_ptr: 0, write_ptr: 0
q[12]: read_ptr: 0, write_ptr: 0
q[13]: read_ptr: 0, write_ptr: 0
q[14]: read_ptr: 0, write_ptr: 0
q[15]: read_ptr: 0, write_ptr: 0
q[16]: read_ptr: 0, write_ptr: 0
q[17]: read_ptr: 0, write_ptr: 0
q[18]: read_ptr: 0, write_ptr: 0
q[19]: read_ptr: 0, write_ptr: 0
Rx Queue
read: 223, write: 221
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/tx_statistics
Management:
MANAGEMENT_ASSOC_REQ : 1
MANAGEMENT_ASSOC_RESP : 0
MANAGEMENT_REASSOC_REQ : 3
MANAGEMENT_REASSOC_RESP : 0
MANAGEMENT_PROBE_REQ : 0
MANAGEMENT_PROBE_RESP : 0
MANAGEMENT_BEACON : 0
MANAGEMENT_ATIM : 0
MANAGEMENT_DISASSOC : 0
MANAGEMENT_AUTH : 19
MANAGEMENT_DEAUTH : 4
MANAGEMENT_ACTION : 0
Control
CONTROL_BACK_REQ : 0
CONTROL_BACK : 0
CONTROL_PSPOLL : 0
CONTROL_RTS : 0
CONTROL_CTS : 0
CONTROL_ACK : 0
CONTROL_CFEND : 0
CONTROL_CFENDACK : 0
Data:
cnt: 32204
bytes: 5475621
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/rx_statistics
Management:
MANAGEMENT_ASSOC_REQ : 0
MANAGEMENT_ASSOC_RESP : 1
MANAGEMENT_REASSOC_REQ : 0
MANAGEMENT_REASSOC_RESP : 3
MANAGEMENT_PROBE_REQ : 0
MANAGEMENT_PROBE_RESP : 149
MANAGEMENT_BEACON : 106894
MANAGEMENT_ATIM : 0
MANAGEMENT_DISASSOC : 0
MANAGEMENT_AUTH : 4
MANAGEMENT_DEAUTH : 0
MANAGEMENT_ACTION : 0
Control:
CONTROL_BACK_REQ : 0
CONTROL_BACK : 0
CONTROL_PSPOLL : 0
CONTROL_RTS : 0
CONTROL_CTS : 0
CONTROL_ACK : 0
CONTROL_CFEND : 0
CONTROL_CFENDACK : 0
Data:
cnt: 30900
bytes: 18938054
^ permalink raw reply
* [PATCH] ath9k_hw: Fix radio retention for AR9462
From: Rajkumar Manoharan @ 2011-10-20 8:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Rajkumar Manoharan
IQ calibration during fast channel change sometimes failed
with RTT. And also restoring invalid radio retention readings
during init cal could cause failure to set the channel properly.
This patch counts the valid rtt history readings and clears
rtt mask.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 16851cb..a4cd161 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -908,12 +908,15 @@ static bool ar9003_hw_rtt_restore(struct ath_hw *ah, struct ath9k_channel *chan)
int i;
bool restore;
- if (!(ah->caps.hw_caps & ATH9K_HW_CAP_RTT) || !ah->caldata)
+ if (!ah->caldata)
return false;
hist = &ah->caldata->rtt_hist;
+ if (!hist->num_readings)
+ return false;
+
ar9003_hw_rtt_enable(ah);
- ar9003_hw_rtt_set_mask(ah, 0x10);
+ ar9003_hw_rtt_set_mask(ah, 0x00);
for (i = 0; i < AR9300_MAX_CHAINS; i++) {
if (!(ah->rxchainmask & (1 << i)))
continue;
@@ -1070,6 +1073,7 @@ skip_tx_iqcal:
if (is_reusable && (hist->num_readings < RTT_HIST_MAX)) {
u32 *table;
+ hist->num_readings++;
for (i = 0; i < AR9300_MAX_CHAINS; i++) {
if (!(ah->rxchainmask & (1 << i)))
continue;
--
1.7.7
^ permalink raw reply related
* [PATCH] ath9k_hw: Fix regression of register offset for AR9003 chips
From: Rajkumar Manoharan @ 2011-10-20 8:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Rajkumar Manoharan, stable
My recent commits (3782c69d, 324c74a) introduced regression
for register offset selection that based on the macversion.
Not using parentheses in proper manner for ternary operator
leads to select wrong offset for the registers.
This issue was observed with AR9462 chip that immediate disconnect
after the association with the following message
ieee80211 phy3: wlan0: Failed to send nullfunc to AP 00:23:69:12:ea:47
after 500ms, disconnecting.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.h b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
index 2f4023e..70e0103 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
@@ -572,14 +572,14 @@
#define AR_PHY_TXGAIN_TABLE (AR_SM_BASE + 0x300)
-#define AR_PHY_TX_IQCAL_CONTROL_0 (AR_SM_BASE + AR_SREV_9485(ah) ? \
- 0x3c4 : 0x444)
-#define AR_PHY_TX_IQCAL_CONTROL_1 (AR_SM_BASE + AR_SREV_9485(ah) ? \
- 0x3c8 : 0x448)
-#define AR_PHY_TX_IQCAL_START (AR_SM_BASE + AR_SREV_9485(ah) ? \
- 0x3c4 : 0x440)
-#define AR_PHY_TX_IQCAL_STATUS_B0 (AR_SM_BASE + AR_SREV_9485(ah) ? \
- 0x3f0 : 0x48c)
+#define AR_PHY_TX_IQCAL_CONTROL_0 (AR_SM_BASE + (AR_SREV_9485(ah) ? \
+ 0x3c4 : 0x444))
+#define AR_PHY_TX_IQCAL_CONTROL_1 (AR_SM_BASE + (AR_SREV_9485(ah) ? \
+ 0x3c8 : 0x448))
+#define AR_PHY_TX_IQCAL_START (AR_SM_BASE + (AR_SREV_9485(ah) ? \
+ 0x3c4 : 0x440))
+#define AR_PHY_TX_IQCAL_STATUS_B0 (AR_SM_BASE + (AR_SREV_9485(ah) ? \
+ 0x3f0 : 0x48c))
#define AR_PHY_TX_IQCAL_CORR_COEFF_B0(_i) (AR_SM_BASE + \
(AR_SREV_9485(ah) ? \
0x3d0 : 0x450) + ((_i) << 2))
@@ -931,10 +931,10 @@
#define AR_PHY_AIC_SRAM_ADDR_B1 (AR_SM1_BASE + 0x5f0)
#define AR_PHY_AIC_SRAM_DATA_B1 (AR_SM1_BASE + 0x5f4)
-#define AR_PHY_RTT_TABLE_SW_INTF_B(i) (0x384 + (i) ? \
- AR_SM1_BASE : AR_SM_BASE)
-#define AR_PHY_RTT_TABLE_SW_INTF_1_B(i) (0x388 + (i) ? \
- AR_SM1_BASE : AR_SM_BASE)
+#define AR_PHY_RTT_TABLE_SW_INTF_B(i) (0x384 + ((i) ? \
+ AR_SM1_BASE : AR_SM_BASE))
+#define AR_PHY_RTT_TABLE_SW_INTF_1_B(i) (0x388 + ((i) ? \
+ AR_SM1_BASE : AR_SM_BASE))
/*
* Channel 2 Register Map
*/
--
1.7.7
^ permalink raw reply related
* Re: iwlagn is getting very shaky
From: Johannes Berg @ 2011-10-20 7:40 UTC (permalink / raw)
To: Norbert Preining
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111020045927.GB23044@gamma.logic.tuwien.ac.at>
On Thu, 2011-10-20 at 13:59 +0900, Norbert Preining wrote:
> so I am now at the university, and it seems your last patch
> did wonder. Here a log after waking up from suspend at university...
For some value of wonder ...
> [17394.896199] wlan0: associated
> [17394.974620] iwlagn 0000:06:00.0: Encounter TX_STATUS_FAIL_PASSIVE_NO_RX, am I on 5.2G band? (2)
> [17394.976930] iwlagn 0000:06:00.0: Encounter TX_STATUS_FAIL_PASSIVE_NO_RX, am I on 5.2G band? (2)
> [17409.608674] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 0
> [17409.616748] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [17409.816093] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [17410.016083] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [17410.216086] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> [17419.285141] iwlagn 0000:06:00.0: Encounter TX_STATUS_FAIL_PASSIVE_NO_RX, am I on 5.2G band? (0)
> [17419.285315] iwlagn 0000:06:00.0: Encounter TX_STATUS_FAIL_PASSIVE_NO_RX, am I on 5.2G band? (0)
> [17419.286583] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
> [17419.300296] cfg80211: Calling CRDA for country: JP
> [17419.309278] wlan0: authenticate with 00:24:c4:ab:bd:ef (try 1)
> [17419.310105] wlan0: authenticated
> [17419.317900] wlan0: associate with 00:24:c4:ab:bd:ef (try 1)
It seems a bit like the 5 GHz AP (:e0) just fails, and wpa_supplicant
selects a 2.4 GHz AP (:ef) now? Pure conjecture, I guess the AP could
also be on the same channel -- did you have scan information for these
APs?
johannes
^ permalink raw reply
* [PATCH v2 3/3] mac80211: select queue for fwded mesh frames
From: Thomas Pedersen @ 2011-10-20 7:26 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1319070203-22097-1-git-send-email-thomas@cozybit.com>
Set proper queue mapping and timestamp for forwarded mesh frames.
Thanks to Luis Rodriguez for investigating and fixing this.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
v2:
We were already doing this for mcast frames, so don't duplicate
the code.
net/mac80211/rx.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b867bd5..1408472 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1952,13 +1952,15 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
info = IEEE80211_SKB_CB(fwd_skb);
memset(info, 0, sizeof(*info));
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
+ info->control.jiffies = jiffies;
info->control.vif = &rx->sdata->vif;
+ skb_set_queue_mapping(fwd_skb,
+ ieee80211_select_queue(sdata, fwd_skb));
+ ieee80211_set_qos_hdr(sdata, fwd_skb);
+
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(&sdata->u.mesh,
fwded_mcast);
- skb_set_queue_mapping(fwd_skb,
- ieee80211_select_queue(sdata, fwd_skb));
- ieee80211_set_qos_hdr(sdata, fwd_skb);
} else {
int err;
/*
--
1.7.5.4
^ permalink raw reply related
* Re: BUG: All network processes hang (brcmsmac/wpa_supplicant)
From: Arend van Spriel @ 2011-10-20 6:28 UTC (permalink / raw)
To: Nico Schottelius, Eric Dumazet, LKML,
linux-wireless@vger.kernel.org, netdev
In-Reply-To: <20111019214250.GC2432@schottelius.org>
On 10/19/2011 11:42 PM, Nico Schottelius wrote:
>
> I'll soon (Friday) leave the environment permanently,
> thus testing will not be easily possible anymore.
Let's hope we have a conclusion by then.
> If this issue is 5Ghz related only, can I somehow trigger it without an AP
> running in that band / i.e. make the card try to use the 5 Ghz band although
> there is no ap nearby?
>
> Cheers,
>
> Nico
>
The warning is in the receive path so you need some transmitter to sent
packets to you. So you need the AP. If you can provide 'iwconfig' output
when associated it will tell on which channel it is.
Gr. AvS
^ permalink raw reply
* RE: [PATCH] ath6kl: Implement support for listen interval from userspace
From: Panjwani, Rishi @ 2011-10-20 6:02 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1318984591-10037-2-git-send-email-rpanjwan@qca.qualcomm.com>
Kalle,
Please drop this patch as I need to make some changes to it. I will send v2 soon.
Regards,
Rishi
-----Original Message-----
From: Panjwani, Rishi
Sent: Tuesday, October 18, 2011 5:37 PM
To: Valo, Kalle
Cc: linux-wireless@vger.kernel.org; Panjwani, Rishi
Subject: [PATCH] ath6kl: Implement support for listen interval from userspace
In order to allow user space based control of listen interval, we use available debugfs infrastructure. Listen interval implies how frequently we want the WLAN chip to wake up and synchronize the beacons in case it is in sleep mode. The user has to write the listen interval (in msecs) to the listen_interval file in ath6kl debug directory. The minimum value is
15 and maximum is 5000.
Example:
echo "30" > listen_interval
This will make the listen interval approximately 30 msecs.
Signed-off-by: Rishi Panjwani <rpanjwan@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/debug.c | 50 +++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/debug.c b/drivers/net/wireless/ath/ath6kl/debug.c
index 3eaa291..41f36d2 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.c
+++ b/drivers/net/wireless/ath/ath6kl/debug.c
@@ -1488,6 +1488,53 @@ static const struct file_operations fops_bgscan_int = {
.owner = THIS_MODULE,
.llseek = default_llseek,
};
+static ssize_t ath6kl_listen_int_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath6kl *ar = file->private_data;
+ u16 listen_int;
+ char buf[32];
+ ssize_t len;
+
+ len = min(count, sizeof(buf) - 1);
+ if (copy_from_user(buf, user_buf, len))
+ return -EFAULT;
+
+ buf[len] = '\0';
+ if (kstrtou16(buf, 0, &listen_int))
+ return -EINVAL;
+
+ if ((listen_int >= 15) && (listen_int <= 5000)) {
+ ar->listen_intvl_t = listen_int;
+ ath6kl_wmi_listeninterval_cmd(ar->wmi, ar->listen_intvl_t, 0);
+ } else {
+ return -EINVAL;
+ }
+
+ return count;
+}
+
+static ssize_t ath6kl_listen_int_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath6kl *ar = file->private_data;
+ char buf[16];
+ int len;
+
+ len = snprintf(buf, sizeof(buf), "%u\n", ar->listen_intvl_t);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len); }
+
+static const struct file_operations fops_listen_int = {
+ .read = ath6kl_listen_int_read,
+ .write = ath6kl_listen_int_write,
+ .open = ath6kl_debugfs_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
int ath6kl_debug_init(struct ath6kl *ar) { @@ -1571,6 +1618,9 @@ int ath6kl_debug_init(struct ath6kl *ar)
debugfs_create_file("bgscan_interval", S_IWUSR,
ar->debugfs_phy, ar, &fops_bgscan_int);
+ debugfs_create_file("listen_interval", S_IWUSR, ar->debugfs_phy, ar,
+ &fops_listen_int);
+
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: iwlagn is getting very shaky
From: David Rientjes @ 2011-10-20 5:30 UTC (permalink / raw)
To: Norbert Preining
Cc: Guy, Wey-Yi W, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111020031421.GS11060@gamma.logic.tuwien.ac.at>
On Thu, 20 Oct 2011, Norbert Preining wrote:
> No attachment again ... something is filtering here???
>
> Please include it directly in the email
>
Not sure why you're not receiving the inlined patch, you can see it at
https://lkml.org/lkml/2011/10/19/505
^ 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