[ath9k-devel] [PATCH] ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS

in, if DEBUG_FS is not there. Signed-off-by: Christian Lamparter <chunk...@googlemail.com> --- Link to the RFC: <https://patchwork.kernel.org/patch/9501361/>. --- drivers/net/wireless/ath/ath9k/Kconfig | 9 ++-- drivers/net/wireless/ath/ath9k/Makefile | 5 +++--

[ath9k-devel] [RFC] ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS

in, if DEBUG_FS is not there. Signed-off-by: Christian Lamparter <chunk...@googlemail.com> --- Here are some numbers for my WD Range Extender (AR7370 with a AR9300): For both configurations MAC80211_DEBUGFS and ATH_DEBUG is disabled. (if they are enabled, there should be no change). All sizes are in

Re: [ath9k-devel] [PATCH RFC v3 3/3] ath9k: parse the device configuration from an OF node

On Saturday, June 25, 2016 05:08:29 PM Martin Blumenstingl wrote: > On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter > <chunk...@googlemail.com> wrote: > > On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote: > >> This makes it possible to configur

Re: [ath9k-devel] [PATCH RFC v3 3/3] ath9k: parse the device configuration from an OF node

On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote: > This makes it possible to configure ath9k based devices using > devicetree. That makes some out-of-tree "convert devicetree to > ath9k_platform_data glue"-code obsolete. Hm, what about the embedded ath9k pcie chips that need the

Re: [ath9k-devel] [PATCH 2/2] Documentation: dt: net: add ath9k wireless device binding

On Thursday, June 23, 2016 05:13:28 PM Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl You need to CC' the devicetree maintainers: Mark Rutland

Re: [ath9k-devel] [PATCH 1/2] ath9k: parse the device configuration from an OF node

On Thursday, June 23, 2016 05:13:27 PM Martin Blumenstingl wrote: > This makes it possible to configure ath9k based devices using > devicetree. That makes some out-of-tree "convert devicetree to > ath9k_platform_data glue"-code obsolete. > > Signed-off-by: Martin Blumenstingl

[ath9k-devel] [PATCH 2/3] kernel: owl-loader for delayed Atheros ath9k fixup

. However,this isn't possible for devices which have the init code for the Atheros chip stored on NAND in an UBI volume. Hence, this module can be used to initialze the chip when the user-space is ready to extract the init code. Signed-off-by: Christian Lamparter <chunk...@googlemail.com> --- I in

Re: [ath9k-devel] Auth Packet TX Delay

On Monday, March 25, 2013 03:23:53 AM Adrian Chadd wrote: Also, would you please make sure you file a bugzilla.kernel.org ticket so this gets tracked? It's good to know that some combination of fast channel change and warm versus cold reset is making things better/worse. And although a

Re: [ath9k-devel] Auth Packet TX Delay

(Added Marco and me in the CC - please keep it) On Sunday, March 24, 2013 11:40:27 PM Robert Shade wrote: Hm, so it's doing some fast channel changes? Yes, the fastcc does seem to work, it's just that sometimes the chip can get in a bad state when it's not cold reset. Just disable fast

Re: [ath9k-devel] [PATCHv2 2/3] mac80211: mesh power save doze scheduling

On Monday, February 18, 2013 05:08:28 PM Marco Porsch wrote: --- +/** + * ieee80211_mps_sta_tbtt_update - update peer beacon wakeup schedule + * + * @sta: mesh STA + * @mgmt: beacon frame + * @tim: TIM IE of beacon frame + * @tsf_local: current HW TSF + */ +void

Re: [ath9k-devel] ath9k_htc test release: please test

On Thursday 29 November 2012 00:50:59 Adrian Chadd wrote: Hi all, I've done an updated build of the ath9k_htc firmware images. I don't currently have a HTC setup working so this is just a recompilation of the current firmware. http://dev.qca.qualcomm.com/~adrian/htc/20121128/ Please

Re: [ath9k-devel] Anyone doing WiFi throughput tests?

On Tuesday, May 29, 2012 08:23:20 PM Ben Greear wrote: On 05/27/2012 08:08 AM, Ben Greear wrote: On 05/26/2012 09:39 AM, Sujith Manoharan wrote: We started testing with two AR9380 NICs today (one AP, the other STA). I applied Felix's skb optimization patch, and the ath9k memleak fix patch on

Re: [ath9k-devel] Anyone doing WiFi throughput tests?

On Saturday 26 May 2012 17:37:50 Ben Greear wrote: We're using WPEA-127N. We have a dual-core Atom for one system, and a quad-core i7 CPU (and two wifi NICs) in another system.. So far, the Atom with single NIC is benchmarking better in some tests. We were only using one of the NICs in the

Re: [ath9k-devel] [PATCH 2/4] ath9k: set PHYRADAR in RX filter when on DFS channel

On Monday, April 23, 2012 11:12:33 AM Zefir Kurtisi wrote: On 22.04.2012 22:00, Felix Fietkau wrote: On 2012-04-22 9:50 PM, Zefir Kurtisi wrote: From: Zefir Kurtisizefir.kurt...@neratec.com Signed-off-by: Zefir Kurtisizefir.kurt...@neratec.com ---

Re: [ath9k-devel] [RFC 1/2] ath9k: use ieee80211_free_txskb

Christian, On Monday 27 February 2012 09:40 PM, Christian Lamparter wrote: With the new tx status API: mac80211: implement wifi TX status All skb originating from mac80211 needs to be given back to mac80211. Signed-off-by: Christian Lamparterchunk...@googlemail.com --- It's high time

[ath9k-devel] [RFC 2/2] ath9k_htc: use ieee80211_free_txskb

With the new tx status API: mac80211: implement wifi TX status All skb originating from mac80211 needs to be given back to mac80211. Signed-off-by: Christian Lamparter chunk...@googlemail.com --- It compiles, but not tested. --- drivers/net/wireless/ath/ath9k/htc_drv_txrx.c |4 ++-- 1 files

[ath9k-devel] [RFC 1/2] ath9k: use ieee80211_free_txskb

With the new tx status API: mac80211: implement wifi TX status All skb originating from mac80211 needs to be given back to mac80211. Signed-off-by: Christian Lamparter chunk...@googlemail.com --- It's high time we change all calls in the tx-path from dev_kfree_skb into ieee80211_free_txskb

Re: [ath9k-devel] [RFC v2 2/2] ath9k: integrate initial DFS module

On Thursday, November 03, 2011 02:55:53 PM Zefir Kurtisi wrote: This patch integrates the DFS module into ath9k, including * building the module into ath9k_hw * setting up DFS debugfs * defining HW capability flag for DFS support * setting this flag by DFS supporting devices (so far:

Re: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection

On Thursday, October 06, 2011 12:27:03 AM Luis R. Rodriguez wrote: On Tue, Oct 4, 2011 at 6:38 AM, Christian Lamparter chunk...@googlemail.com wrote: On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote: On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter chunk

Re: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection

On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote: On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter chunk...@googlemail.com wrote: On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote: On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi zefir.kurt...@neratec.com

Re: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection

On Tuesday, October 04, 2011 04:17:35 PM Zefir Kurtisi wrote: On 10/04/2011 03:38 PM, Christian Lamparter wrote: On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote: On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter chunk...@googlemail.com wrote: On Monday, October 03, 2011

Re: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection

On Tuesday, October 04, 2011 07:03:10 PM Adrian Chadd wrote: Nope, what I'm saying is that someone's likely just copy/paste'd the we support x and y! from some marketing material and then suggested people use linux/openwrt/ath9k without really looking at it. I'm still curious how they got the

Re: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection

On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote: On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi zefir.kurt...@neratec.com wrote: Signed-off-by: Zefir Kurtisi zefir.kurt...@neratec.com --- drivers/net/wireless/ath/ath9k/main.c | 12 1 files changed, 12

Re: [ath9k-devel] [PATCH] ath9k: fix MGMT packets when using TKIP

On Tuesday, August 23, 2011 11:59:51 PM Bill Jordan wrote: On Mon, Aug 22, 2011 at 4:11 AM, Kalle Valo kv...@adurom.com wrote: Bill Jordan bjor...@rajant.com writes: Prevent 8 bytes from being truncated from MGMT packets when using TKIP. A bit more information in the commit log would

Re: [ath9k-devel] [PATCH net-next 1/2] wireless: Remove casts of void *

On Tuesday 14 June 2011 18:43:51 Joe Perches wrote: On Tue, 2011-06-14 at 12:31 -0400, Pavel Roskin wrote: On 06/14/2011 12:02 AM, Joe Perches wrote: /* Get the message ID */ - msg_id = (__be16 *) ((void *) htc_hdr + -

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: Dump base eeprom header for UB91/94/95

On Friday 29 April 2011 03:19:21 Sujith wrote: Christian Lamparter wrote: On Thursday 28 April 2011 10:58:33 Sujith wrote: From: Sujith Manoharan sujith.manoha...@atheros.com Debugfs file location: debugfs_mnt/ieee80211/phy#/ath9k_htc/base_eeprom If you just want to dump

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: Dump base eeprom header for UB91/94/95

On Thursday 28 April 2011 10:58:33 Sujith wrote: From: Sujith Manoharan sujith.manoha...@atheros.com Debugfs file location: debugfs_mnt/ieee80211/phy#/ath9k_htc/base_eeprom If you just want to dump the eeprom, then why not with a userspace utility? It's pretty easy to write such a thing with

Re: [ath9k-devel] [RFC/WIP 00/33] ath9k_htc AP mode

On Saturday 22 January 2011 04:32:02 Sujith wrote: Sujith wrote: Sujith wrote: What about hardware that doesn't report any kind of TX status information at all ? Currently, there is no way to determine whether the frame has actually gone out, all that can be known is that it

Re: [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page.

On Friday 07 January 2011 01:46:03 gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com Patch is from Eric Dumazet, as described here: https://patchwork.kernel.org/patch/104271/ Reported-by: Michael Guntsche m...@it-loops.com Signed-off-by: Eric Dumazet

Re: [ath9k-devel] [PATCH 2/4] ath9k: move hw code to its own module

On Thursday 24 September 2009 05:07:00 Luis R. Rodriguez wrote: hw code for Atheros 802.11n hardware is commmon between different chipsets. This moves this code into a separate module, the next expected user of this code will be the ath9k_htc module. The ath9k/ dir is now selected by