Re: Proper SET_KEY usage?

On Tue, 10 Jul 2018 at 12:16, Denis Kenzior wrote: > I think we had this conversation before. Up to 802.11-2012, PTK Rekey > was not really explicitly mentioned as possible. There were hints and > stuff, but no explicit language. > > I think in 802.11-2016 they finally explicitly say that this

Re: [PATCH] ath10k: transmit queued frames after waking queues

On Thu, 17 May 2018 at 16:16, Niklas Cassel wrote: > diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c > index cda164f6e9f6..1d3b2d2c3fee 100644 > --- a/drivers/net/wireless/ath/ath10k/txrx.c > +++

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

On Mon, 14 May 2018 at 11:25, Kalle Valo <kv...@codeaurora.org> wrote: > Adrian Chadd <adr...@freebsd.org> writes: > > May we have a little more information about how this is supposed to work? > > > > It looks like we're supposed to send the information about t

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

Hi, May we have a little more information about how this is supposed to work? It looks like we're supposed to send the information about the matched radar pattern back to the firmware for confirmation? What's the intended behaviour from the firmware? Will the firmware have a hard-coded set of

Re: [PATCH v2 4/4] ath10k: Enable sta idle power save

On 23 April 2018 at 08:50, Kalle Valo wrote: > > Adrian was also commenting something similar about adding a debugfs > interface but I don't really see the point right now while we are adding > initial wcn3990 support. If someone wants to run measurements with and > without

Re: [PATCH v2 4/4] ath10k: Enable sta idle power save

Hi, My 2c here. As much as I like power save stuff, I've been bitten enough times by these wifi chips kinda implementing mostly-ok-but-not-that-particular-time power savings stuff and so have had to make it configurable chip by chip. A good example is active state power management in various

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

hi, so it's going to eventually leak? Can we fix the firmware bug too? :) -a On 26 February 2018 at 09:06, wrote: > Hi, > > >> Can you share exactly which resource the firmware ran out of? It would >> seem to >> be a FW bug if it is leaking, so maybe it can be

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

hi! On 25 February 2018 at 22:16, Karthikeyan Periyasamy wrote: > This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159. > > When Ath10k is in AP mode and an unassociated STA sends a VHT action frame > (Operating Mode Notification for the NSS change) periodically

Re: [PATCH 03/11] ath10k_sdio: DMA bounce buffers for read write

[top post for emphasis] Arend is right. You won't be the only driver which has issues with a controller that doesn't handle non-aligned data payloads. Please push it into the stack or the controller side, but not in the driver side. That'll be a forever game of whack-a-mole. -adrian (I'm

Re: [PATCH 03/11] ath10k_sdio: DMA bounce buffers for read write

Hi, I think Kalle is pointing out that maybe it's the SDHCI driver responsibility to do the bounce buffering? -adrian

Re: [PATCH v2] ath10k: Retry pci probe on failure.

[snip] * WMI setup stuff fails locally because of memory fragmentation when you reload the driver. Heh. Sigh. * I also see the PCI wakeup failures, so I'm going to go poke that soon and see what I find. -adrian

Re: [PATCH v2] ath10k: Retry pci probe on failure.

On 13 October 2017 at 05:41, Kalle Valo wrote: > gree...@candelatech.com writes: > >> From: Ben Greear >> >> This works around a problem we see when sometimes the wifi NIC does >> not respond the first time. This seems to happen especially often

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

fwiw - I did this on my in progress ath10k port to freebsd, and I've tested it on Rome and Peregrine. It seems to be the right thing to do during suspend to at least cleanly shut things down. -adrian On 11 October 2017 at 17:38, Brian Norris wrote: > Ping? Any

Re: What should setting rate on 'AP' interface mean?

Hi, IIRC, I think it's the drivers job to determine per-peer fixed rate. -adrian On 10 October 2017 at 11:34, Ben Greear wrote: > I was trying to use 'iw' to set rates on an AP interface, hoping it would > set tx-rates on all of the stations (peers) to the same

Re: [PATCH] ath10k: add configurable debugging.

On 1 June 2017 at 06:24, Kalle Valo <kv...@qca.qualcomm.com> wrote: > Arend van Spriel <arend.vanspr...@broadcom.com> writes: > >> On 31-05-17 14:16, Kalle Valo wrote: >>> Adrian Chadd <adr...@freebsd.org> writes: >>> >>>> This a

Re: [PATCH] ath10k: add configurable debugging.

On 31 May 2017 at 14:28, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: > On 31-05-17 22:23, Adrian Chadd wrote: >> On 31 May 2017 at 13:20, Arend van Spriel <arend.vanspr...@broadcom.com> >> wrote: >>> On 31-05-17 14:16, Kalle Valo wrote: >>&

Re: [PATCH] ath10k: add configurable debugging.

On 31 May 2017 at 13:20, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: > On 31-05-17 14:16, Kalle Valo wrote: >> Adrian Chadd <adr...@freebsd.org> writes: >> >>> This adds a few configurable debugging options: >>> >>> * drive

Re: [PATCH] Per chain RSSI reporting

On 27 May 2017 at 09:07, Ben Greear wrote: > At low encoding rates, especially if it switches to a single-chain encoding, > maybe the on-air signal really is stronger? > > Have you verified in some other manner than the signals reported by ath10k > are > wrong? Hiya, So

Re: [PATCH] Per chain RSSI reporting

[snip] hiya, I have something local that I've been meaning to push up to do this, but with no smoothing. Ideally (!) smoothing is done optionally in mac80211. What do you think about just committing the per-chain RSSI stuff to mac80211 so it shows up right now, and then we figure out how to

Re: [PATCH] ath10k : Fix channel survey dump

On 19 May 2017 at 02:17, Kalle Valo wrote: > Felix Fietkau writes: > >> On 2017-04-26 16:41, Venkateswara Rao Naralasetty wrote: >>> Channel active/busy time are showing incorrect >>> (less than previous or sometimes zero) for >>> successive survey dump

[PATCH] ath10k: add configurable debugging.

. Signed-off-by: Adrian Chadd <adr...@freebsd.org> --- drivers/net/wireless/ath/ath10k/core.c | 2 + drivers/net/wireless/ath/ath10k/core.h | 2 + drivers/net/wireless/ath/ath10k/debug.c | 101 drivers/net/wireless/ath/ath10k/debug.h | 44 +--

Re: [PATCH] ath10k: add configurable debugging.

grr, no. lemme go re-add that and resubmit. thanks! -a On 10 May 2017 at 09:44, Steve deRosier <deros...@gmail.com> wrote: > Hi Adrian, > > On Wed, May 10, 2017 at 9:25 AM, Adrian Chadd <adr...@freebsd.org> wrote: > >> diff --git a/drivers/net/wireless/ath/at

[PATCH] ath10k: add configurable debugging.

. Signed-off-by: Adrian Chadd <adr...@freebsd.org> --- drivers/net/wireless/ath/ath10k/core.c | 2 + drivers/net/wireless/ath/ath10k/core.h | 2 + drivers/net/wireless/ath/ath10k/debug.c | 101 drivers/net/wireless/ath/ath10k/debug.h | 44 +--

Re: [v2,1/3] ath9k: Support channels in licensed bands

On 9 May 2017 at 05:57, Simon Wunderlich wrote: > Hey Kalle, > > it seems like there was some discussion here and I wouldn't expect too many > more opinions ... do you think we can have a decision based on what has been > discussed here? (Note: FreeBSD has had in-tree

[PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

ery time the vdevs are brought down) fragmentation should stop being such a touchy issue. If it is though, using dma_alloc_coherent() use gets us access to the CMB APIs too relatively easily and ideally we would be allocating memory early in boot for exactly these reasons. Signed-off-by: Adrian Ch

Re: [PATCH] ath10k: Fix spectral scan for QCA99X0 family of chipsets

hi! For reference, would you mind pulling out what hte format of the edge detection dword is? Thanks! -adrian On 10 April 2017 at 07:26, Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > spectral_bin length (number of

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

Vendors using ath10k will like this. I mean, I'm using ath10k, and I really like this moving forward. This will make life so much easier in the long run. Everyone else isn't using board-2.bin; they're just copying calibration/board data files over so the reference driver can assemble a board data

Re: Should ath10k enable RX_FLAG_ALLOW_SAME_PN

have you verified with a sniffer that it indeed is an A-MSDU that the hardware is decap'ing for you? (ath9k doesn't do hardware A-MSDU decap.) -adrian On 15 March 2017 at 08:26, Ben Greear wrote: > We notice a strange problem when receiving ath10k frames in > raw mode

Re: [PATCH] ath10k: Update available channel list for 5G radio

hiya, we're working on something similar to this, but based on bmi-id. Why'd you withdraw this patch for now? -a

Re: VHT 160Mhz and nss related config.

.. or give us a legit way to acquire the 2016 spec? :) Curious implementers want to know! -a On 13 February 2017 at 11:21, Ben Greear wrote: > On 02/12/2017 11:06 PM, Johannes Berg wrote: >> >> On Fri, 2017-02-10 at 14:58 -0800, Ben Greear wrote: >>> >>> So, it

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

On 9 February 2017 at 23:37, Joe Perches <j...@perches.com> wrote: > On Thu, 2017-02-09 at 23:14 -0800, Adrian Chadd wrote: > >> If there >> were accessors for the skb data / len fields (like we do for mbufs) >> then porting the code would've involved about 5,000 l

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

On 9 February 2017 at 23:03, Valo, Kalle <kv...@qca.qualcomm.com> wrote: > Ben Greear <gree...@candelatech.com> writes: > >> On 02/07/2017 01:14 AM, Valo, Kalle wrote: >>> Adrian Chadd <adr...@freebsd.org> writes: >>> >>>> Re

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

hiya, Removing this method makes the diff to FreeBSD larger, as "vif" in FreeBSD is a different pointer. (Yes, I have ath10k on freebsd working and I'd like to find a way to reduce the diff moving forward.) -adrian

Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements

hi, On 12 December 2016 at 12:05, Martin Blumenstingl wrote: > > It seems that there are a few devices out there where the whole EEPROM > is swab16'ed which switches the position of the 1-byte fields > opCapFlags and eepMisc. > those still work fine with the

Re: ath10k firmware crashes in mesh mode on QCA9880

: > Hi Adrian, > > I have not done much testing of ath10k and ath9k devices in a single > encrypted mesh recently, but I have a memory of only having this issue > when communicating between ath10k devices. > > Alexis > > On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd <adr...

Re: ath10k firmware crashes in mesh mode on QCA9880

Hi! Hm! So is there a firmware bug if there are 11n only capable nodes in an 11s mesh? -adrian

Re: [PATCH 1/2] mac80211: do not iterate active interfaces when in re-configure

fwiw, I'm facing the same kinds of cleanup problems with my port of (oct 2015) ath10k to freebsd. The oct 2015 ath10k tree doesn't have the firmware per-txq/tid/peer feedback stuff in it, so this hasn't yet bitten me, but there rest of the races have - mostly surrounding handling pending TX

Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

Heh, I had to do something like this for freebsd too for my ath10k port. So thanks. :) Suggestion - take a look at where tasklets, completions, locks, etc are all re-allocated multiple times, once upon initial VAP bringup. I had to also undo this in FreeBSD, as we don't allow re-init of tasks,

Re: Bayesian rate control

On 15 November 2016 at 01:34, Johannes Berg wrote: > >> But there is a per-descriptor TX rate table entry in the driver. >> FreeBSD uses it to implement its rate control for the intel drivers. >> >> What am I missing? :) > > Not sure. But there isn't a per-descriptor

Re: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption

Hiya, maybe the right thing to do is to set a flag that says "please replumb", then do a reset, and have the reset path see if we need to replumb keys and do so? To make locking less terrible, maybe we need to cache the keys in the ath9k driver somewhere so replumbing doesn't require reaching

Re: Bayesian rate control

Hi, On 25 October 2016 at 22:56, Johannes Berg wrote: > >> The intel 7260 and later parts also allow user controllable rate >> control and provide transmit completion feedback, but I don't know >> whether it's enough for your needs. > > Perhaps. However, existing rate

Re: Bayesian rate control

hiya, there's a tplink RTL81xx 11ac NIC that's growing linux and freebsd support. I believe it's software rate controllable. The intel 7260 and later parts also allow user controllable rate control and provide transmit completion feedback, but I don't know whether it's enough for your needs.

Re: [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

[picking a random email to reply to] I /think/ the TSF is only valid for the last frame of an aggregate. 'more' means "this RX frame is split across multiple RX descriptors" "moreaggr" means "there's more subframes in this RX'ed A-MPDU" If you get a TSF in the first frame, it's whatever was

Re: [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

On 7 June 2016 at 04:12, Toke Høiland-Jørgensen wrote: > Toke Høiland-Jørgensen writes: > >>> [snip] >>> >>> I also found one of my notes in my version of this - how can we >>> estimate the duration of an A-MPDU, when we only get hardware >>> de-encapsulated frames?

Re: [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

[snip] I also found one of my notes in my version of this - how can we estimate the duration of an A-MPDU, when we only get hardware de-encapsulated frames? -adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to

[PATCH] [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

-by: Adrian Chadd <adr...@freebsd.org> --- drivers/net/wireless/broadcom/b43/xmit.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/broadcom/b43/xmit.c b/drivers/net/wireless/broadcom/b43/xmit.c index f620126..7edbcdb 100644 --- a/drive

[PATCH] b43: don't fall back to CCK rates on 5GHz OFDM for RTS frames

This fixes a small issue with selecting fallback rates for RTS frames. For OFDM PHY rates in 5GHz mode we shouldn't fall back to CCK. Adrian Chadd (1): [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM. drivers/net/wireless/broadcom/b43/xmit.c | 13 ++--- 1 file

Re: [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

On 15 May 2016 at 07:39, Michael Büsch <m...@bues.ch> wrote: > On Sun, 15 May 2016 07:23:25 -0700 > Adrian Chadd <adr...@freebsd.org> wrote: > >> @@ -438,7 +446,7 @@ int b43_generate_txhdr(struct b43_wldev *dev, >> >> rts_rate

[b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

Author: Adrian Chadd <adr...@freebsd.org> Date: Sun May 15 07:15:54 2016 -0700 [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM. Check the current PHY operating mode (gmode) to see if we should fall back from 6MB OFDM to 11MB CCK. For 5GHz operation this

Re: [PATCH] mac80211: debugfs var for the default aggregation timeout.

On 8 April 2016 at 21:56, Johannes Berg wrote: > On Fri, 2016-04-08 at 21:27 -0400, Avery Pennarun wrote: > >> > Just to be clear, this crash is only from *reading* the agg_status >> > files. I don't know if the crashiness reduces when disabling the >> > aggregation

Re: Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

Hi, ath9k has support for station powersave, and it's driven by mac80211. You should be able to implement that policy in mac80211 and then add hooks so your bluetooth code can get notifications about it. -a -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body

Re: Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

finition should be there though! I just don't know if you'll get them if it's being wired as a BT_ACTIVE pin instead of a GPIO pin.. -adrian > Regards > Sandeep. > > > On Thursday, 31 March 2016 1:32 AM, Adrian Chadd <adr...@freebsd.org> wrote: > > > Hi! > >

Re: Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

Hi! I don't know if you can do simulaneous wlan and BT RX - especially since WLAN RX sometimes requires ACKs to be sent. :) But for multicast, sure. You'd have to check the NIC schematic and antenna switch programming to see if you can do simultaneous wlan RX (with no TXing, eg RTS/CTS, ACK, etc)

Re: Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

On 28 March 2016 at 21:22, sandeep suresh wrote: > Hello Adrian, > Thanks for your response. Currently with 2-wire coexistence, BT has > higher priority when compared to WiFi. You had shared the following > different bitfields that can be configured with

Re: Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

On 27 March 2016 at 09:43, sandeep suresh wrote: > Dear Experts, > > WiFi-BT Coexistence: > To let wireless LAN systems coexist with Bluetooth system, a hardware Packet > Traffic Arbiter (PTA) scheme is used. Here PTA is based on 2-wire > coexistence , BT_ACTIVE and

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

from qca-wifi-1.2: ar5416phy.h:#define AR_PHY_CCA_NOM_VAL_KIWI_2GHZ -120 ar5416phy.h:#define AR_PHY_CCA_MIN_GOOD_VAL_KIWI_2GHZ-127 ar5416phy.h:#define AR_PHY_CCA_MAX_GOOD_VAL_KIWI_2GHZ-110 .. and: ar5416phy.h:#define AR_PHY_CCA_NOM_VAL_MERLIN_2GHZ -112

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

hiya, for what it's worth - this looks okay to me. His noise floor looks about as low as I'd expect on his plots. -adrian On 22 July 2015 at 01:42, Martin Blumenstingl wrote: > The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips. > Using

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

ok, can you re-run this again before the NF patch, so I can compare? And yeah, I can compile up fft_eval for freebsd. I think I've done it once or twice before.. -a On 28 July 2015 at 16:43, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: On Wed, Jul 29, 2015 at 1:37 AM, Adrian

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

On 28 July 2015 at 15:33, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: On Wed, Jul 29, 2015 at 12:22 AM, Adrian Chadd adr...@freebsd.org wrote: Hm, doesn't someone have a graphical frontend for this on linux? Yep, I just found FFT_eval (screenshot: [0] and ath_spectral

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

So the values aren't bad on the 1043nd - they're in 1/2 or 1/4dB, but there's no scalar quantity (ie, it's not in dBm.) The 1043nd calibrates down to around -95 or so, which sounds like it's in dBm but it isn't, and any similarity is just coincidence. It does sound like your AR9227 sees noise.

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

Hm, doesn't someone have a graphical frontend for this on linux? -a On 28 July 2015 at 15:07, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: On Tue, Jul 28, 2015 at 7:25 PM, Adrian Chadd adr...@freebsd.org wrote: So the values aren't bad on the 1043nd - they're in 1/2 or 1/4dB

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

Hi, I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.) can you log the noisefloor calibrated values before and after the patch? I'd like to see how low it calibrrates to. -a On 22 July 2015 at 01:42, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: The

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

: On Tue, Jul 28, 2015 at 1:50 AM, Adrian Chadd adr...@freebsd.org wrote: is it never getting any readings before your patch? NF Readings all look empty... Yes, looks like it. Unfortunately I haven't saved a complete kernel log (with ath9k debug level = 0x4449) but only a few parts. Here

Re: [ath9k-devel] ath9k channel switch

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

Re: [PATCH] ath9k_htc: force FW v1.4.0

Yeah, let's have it warn for a month or two. There's some pending work that will break the API with 1.3 firmware, so it has to happen sooner rather than later. But yeah, maybe warn for about a month would be good. the older firmware is still in the git tree in case people want it. -adrian -- To

Re: [ath9k-devel] AR9462 problems connecting again..

On 26 February 2015 at 02:20, Jouni Malinen j...@w1.fi wrote: On Wed, Feb 25, 2015 at 10:14:45AM -0800, Linus Torvalds wrote: While I realize that people may disagree about the exact details of how to fix this in the long run, may I suggest that in the meantime we at least get the two

Re: [ath9k-devel] AR9462 problems connecting again..

On 25 February 2015 at 10:14, Linus Torvalds torva...@linux-foundation.org wrote: While I realize that people may disagree about the exact details of how to fix this in the long run, may I suggest that in the meantime we at least get the two workaround patches applied? I'm talking about the

Re: [ath9k-devel] AR9462 problems connecting again..

Hi, I thought about doing this for rate probing with FreeBSD's sample rate algorithm, but after actually having to use the damned thing in noisy environments I realised that it just wasn't worth the effort to optimise rate control selection whilst doing EAPOL frames. If we did more useful

Re: AR9462 problems connecting again..

On 23 February 2015 at 13:53, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi wrote: How far is the station from the AP? Would it be possible to see whether the behavior changes if you were within, say, five meters or so? Well, it

Re: AR9462 problems connecting again..

On 22 February 2015 at 10:30, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd adr...@freebsd.org wrote: Just a wild shot - try disabling fast authentication and see if that makes a difference? wpa_supplicant.conf: fast_reauth=0 I recall

Re: AR9462 problems connecting again..

On 21 February 2015 at 15:34, Linus Torvalds torva...@linux-foundation.org wrote: So I've had problems connecting to some networks before on my Chromebook Pixel, but now I'm testing a new Ubiquiti network at home, and can see this issue at home too. I know the wireless works, because other

Please test: ath9k-htc 1.4 firmware images

Hi! I've rolled some updated firmware images for ath9k-htc: https://people.freebsd.org/~adrian/ath9k_htc/1.4/ I'd like to get some wider testing before I submit them to linux-firmware.git for inclusion. So please test them out and let me know if they do / don't work for you. Outside of a

Re: AR9462 problems connecting again..

So the interesting part thus far: 14:07:23.513500: RTM_NEWLINK: operstate=1 ifi_flags=0x1003 ([UP]) 14:07:23.513662: RTM_NEWLINK, IFLA_IFNAME: Interface 'wlp1s0' added 14:07:23.513842: nl80211: if_removed already cleared - ignore event 14:07:23.536309: nl80211: Event message available

Re: AR9462 problems connecting again..

On 22 February 2015 at 15:00, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds torva...@linux-foundation.org wrote: Ugh. When I add -dd to the command line, it has now worked three times in a row, when before it worked once out of ten tries.

Re: [PATCH] ath10k: Replace ioread with wmb for data sync

On 30 January 2015 at 18:06, Sujith Manoharan suj...@msujith.org wrote: Peter Oh wrote: Please refer the email thread that I mentioned about other architectures. (dsb is for ARM and other platforms have the equivalent instruction such as sfence, sync, mf, and dcs). Ok. Also the patch is

Re: [ath5k-devel] Rookie needs helps with ath5k basics

+01:00 Adrian Chadd adr...@freebsd.org: ... because some of the 802.11p NICs are actually ath5k NICs that have the relevant bandpass filters for 5.9GHz and high output amplifiers. -a On 17 February 2014 01:27, Holger Schurig holgerschu...@gmail.com wrote: Okay, I admit that I cannot help

Re: strange MPDU loss pattern

On 30 October 2014 08:48, Ali Abedi a2ab...@uwaterloo.ca wrote: Hi Adrian, We observed that this can happen for any rate for some SNR values. If the SNR is strong enough for the given MCS this won't happen. But when the SNR approaches the transition region when error rate starts to

Re: strange MPDU loss pattern

of the packet. Best, Ali On 25/10/2014 2:30 PM, Adrian Chadd wrote: On 25 October 2014 08:28, Ali Abedi a2ab...@uwaterloo.ca wrote: Hi Adrian, We have a high end spectrum analyzer. So we are sure there is no background interference We run our experiments in the 5 GHZ spectrum

Re: strange MPDU loss pattern

On 24 October 2014 13:42, Ali Abedi a2ab...@uwaterloo.ca wrote: We don't use a rate adaptation at this moment (i.e., fixed rate) and the setup is stationary. So we expect to see relatively stable channel conditions. Even if the channel conditions change during the aggregated frame. The first

Re: [ath9k-devel] Block ACK without frame aggregation

and Kamran, Thanks for your replies. I think we are not referring to the same concept. Can you please have a look at the attache diagram. I need the middle one the immediate BA not delayed BA. Thanks, Ali On 14-10-22 11:18 PM, Adrian Chadd wrote: I don't think mac80211 supports delayed

Re: [ath9k-devel] Block ACK without frame aggregation

I don't think mac80211 supports delayed-BA. :( -adrian On 22 October 2014 08:38, Ali Abedi a2ab...@uwaterloo.ca wrote: Hello, I am interested to know if we can send multiple packets (non-aggregated, single packets) and then ask for a block ACK? I like to know if this functionality has