Re: [ath9k-devel] ath9k channel switch

2015-04-08 Thread Adrian Chadd
Hi, You can do a fast channel switch under very specific conditions. It includes but isn't limited to being on the same band (ie, no fast cc between 2/5ghz.) -adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org

[PATCH] ath9k: fix per-packet tx power configuration

2015-04-08 Thread Lorenzo Bianconi
Do not use ieee80211_vif pointer in ath_get_rate_txpower() since it has been overwritten by setup_frame_info() and it will result in a corrupted tx power configuration. Set per-packet tx power in setup_frame_info() according to current vif tx power. Signed-off-by: Lorenzo Bianconi --- drivers/ne

Re: [PATCH 1/2] mac80211_hwsim: Set VHT capabilities only for the 5.2 GHz band

2015-04-08 Thread Ben Greear
On 04/08/2015 11:29 AM, Peer, Ilan wrote: > Hi Ben, > >> -Original Message- >> From: Ben Greear [mailto:gree...@candelatech.com] >> Sent: Tuesday, April 07, 2015 19:08 >> To: Peer, Ilan >> Cc: linux-wireless@vger.kernel.org >> Subject: Re: [PATCH 1/2] mac80211_hwsim: Set VHT capabilities o

Re: [PATCH 1/2] mac80211_hwsim: Set VHT capabilities only for the 5.2 GHz band

2015-04-08 Thread Johannes Berg
On Wed, 2015-04-08 at 18:29 +, Peer, Ilan wrote: > > I saw a patch on ath10k list that enabled VHT for 2.4Ghz for that > > driver/firmware...are you sure it is absolutely not supported? > According to the 802.11ac amendment: "The IEEE 802.11 VHT STA operates > in frequency bands below 6 GHz e

RE: [PATCH 1/2] mac80211_hwsim: Set VHT capabilities only for the 5.2 GHz band

2015-04-08 Thread Peer, Ilan
Hi Ben, > -Original Message- > From: Ben Greear [mailto:gree...@candelatech.com] > Sent: Tuesday, April 07, 2015 19:08 > To: Peer, Ilan > Cc: linux-wireless@vger.kernel.org > Subject: Re: [PATCH 1/2] mac80211_hwsim: Set VHT capabilities only for the > 5.2 GHz band > > On 04/07/2015 09:05

Re: [PATCH] brcmsmac: Move each system tracepoints to their own header

2015-04-08 Thread Steven Rostedt
On Wed, 8 Apr 2015 09:32:44 +0200 Arend van Spriel wrote: > On 04/07/15 18:11, Steven Rostedt wrote: > > > > Every tracing file must have its own TRACE_SYSTEM defined. > > The brcmsmac tracepoint header broke this and added in the middle > > of the file: > > > > #undef TRACE_SYSTEM > > #defin

Re: [PATCH 4/5] wil6210: stop_ap to leave interface closed

2015-04-08 Thread Kalle Valo
Johannes Berg writes: "closed" is rather misleading, since you most certainly should *not* >>do dev_close() [and don't, but how should I know reading the commit >>log?] johannes >>> >>> Yes, I see. >>> I meant that actually stop_ap leaves device in state similar to >>nd

Re: [PATCH] iwlwifi: Move each system tracepoints to their own header

2015-04-08 Thread Johannes Berg
On Tue, 2015-04-07 at 12:13 -0400, Steven Rostedt wrote: > Every tracing file must have its own TRACE_SYSTEM defined. > The iwlwifi tracepoint header broke this and added in the middle > of the file: [...] > Unfortunately, this broke new code in the ftrace infrastructure. > Moving each of these TRA

Re: [PATCH] brcmsmac: Move each system tracepoints to their own header

2015-04-08 Thread Arend van Spriel
On 04/07/15 18:11, Steven Rostedt wrote: Every tracing file must have its own TRACE_SYSTEM defined. The brcmsmac tracepoint header broke this and added in the middle of the file: #undef TRACE_SYSTEM #define TRACE_SYSTEM brcmsmac #undef TRACE_SYSTEM #define TRACE_SYSTEM brcmsmac_tx #

[PATCH] cfg80211: don't allow disabling WEXT if it's required

2015-04-08 Thread Johannes Berg
From: Johannes Berg The change to only export WEXT symbols when required could break the build if CONFIG_CFG80211_WEXT was explicitly disabled while a driver like orinoco selected it. Fix this by hiding the symbol when it's required so it can't be disabled in that case. Fixes: 2afe38d15cee ("cf