[PATCH] ath10k: fix reporting channel survey data

When user requests for survey dump data, driver is providing wrong survey information. This information we sent is the survey data that we have collected during previous user request. This issue occurs because we request survey dump for wrong channel. With this change, we correctly display the

Re: [PATCH v5] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

On Thu, Sep 1, 2016 at 12:03 PM, Toke Høiland-Jørgensen wrote: > @@ -1481,33 +1506,57 @@ struct sk_buff *ieee80211_tx_dequeue(struct > ieee80211_hw *hw, > { > struct ieee80211_local *local = hw_to_local(hw); > struct txq_info *txqi = container_of(txq, struct

Re: Ath10k probe response error related to mac80211 commit.

> If someone has any idea of why this patch might trigger it, please > let me know. > I'll keep digging in the meantime... >  >  Revert "mac80211: don't advertise NL80211_FEATURE_FULL_AP_CLIENT_STATE" > With a sufficiently recent hostapd/wpa_supplicant, the patch will cause a station entry

[PATCH] ath9k: bring back direction setting in ath9k_{start_stop}

A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup led_pin initial") that broken the WLAN status led on my laptop with AR9287 after suspending and resuming. Steps to reproduce: * Suspend (laptop) * Resume (laptop) * Observe that the WLAN led no longer turns ON/OFF depending on

Re: [PATCH v5] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

> To avoid having to deal with fragmentation on dequeue, the split is > set to be after the fragmentation handler. This means that some > reordering of TX handlers is necessary, and some handlers had to be > made aware of fragmentation due to this reordering. Come to think of it, that's actually

Re: Ath10k probe response error related to mac80211 commit.

On 09/01/2016 11:53 AM, Johannes Berg wrote: On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote: Could easily be that others are corrupted too, but since probe resp is bad, the association will not proceed. makes sense. Heh, I spent 4 days tracking this down, so I wanted to be precise in

Re: Ath10k probe response error related to mac80211 commit.

On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote: >  > Could easily be that others are corrupted too, but since probe resp > is bad, the association will not proceed. makes sense. > Heh, I spent 4 days tracking this down, so I wanted to be precise in > my bug report :) Ahrg, ouch. Sorry

Re: [PATCH v5] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

On Thu, 2016-09-01 at 20:30 +0200, Toke Høiland-Jørgensen wrote: > > seq=1,frag=0 > > seq=2,frag=0 > > seq=2,frag=1 > > seq=2,frag=1 > > > > if reordering happened? > > (assuming the last line was supposed to read 'seq=1,frag=1') I did actually mean seq=2,frag=1, since the seqno assignment

Re: [PATCH v5] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

Johannes Berg writes: >> To avoid having to deal with fragmentation on dequeue, the split is >> set to be after the fragmentation handler. This means that some >> reordering of TX handlers is necessary, and some handlers had to be >> made aware of fragmentation due to

Re: Ath10k probe response error related to mac80211 commit.

On 09/01/2016 11:53 AM, Johannes Berg wrote: On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote: Could easily be that others are corrupted too, but since probe resp is bad, the association will not proceed. makes sense. Heh, I spent 4 days tracking this down, so I wanted to be precise in

Re: Ath10k probe response error related to mac80211 commit.

On 09/01/2016 11:01 AM, Johannes Berg wrote: If someone has any idea of why this patch might trigger it, please let me know. I'll keep digging in the meantime... Revert "mac80211: don't advertise NL80211_FEATURE_FULL_AP_CLIENT_STATE" With a sufficiently recent hostapd/wpa_supplicant,

RE: [PATCH] mwifiex: handle edmac vendor command

Hi Kalle, > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: Thursday, September 01, 2016 8:23 PM > To: Amitkumar Karwar > Cc: linux-wireless@vger.kernel.org > Subject: Re: [PATCH] mwifiex: handle edmac vendor command > > Amitkumar Karwar writes: > > >> From: Kalle

Ath10k probe response error related to mac80211 commit.

I have a variant of the ath10k 10.1 firmware that puts all frames, including management, over the normal htt packet transport. This has worked fine for many kernels, but for reasons that currently escape me, the patch below breaks this firmware. On air, I see corrupted probe responses, seems

Re: linux-4.8-rcX: ath9k traceback

Mimi Zohar writes: > There weren't any problems on linux-4.7 kernels. I'm getting the > following traceback on linux-4.8-rc1/-rc4 kernels. Let me know if you > need any additional information. > > [ 64.006529] WARNING: CPU: 3 PID: 94 at >

[PATCH] ath10k: Remove unnecessary error code assignment

From: Mohammed Shafi Shajakhan The error assigned does not seems to be used anywhere, fixes nothing just a small cleanup Signed-off-by: Mohammed Shafi Shajakhan --- drivers/net/wireless/ath/ath10k/wmi.c | 1 - 1 file changed, 1 deletion(-)

[PATCH v5] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

The TXQ intermediate queues can cause packet reordering when more than one flow is active to a single station. Since some of the wifi-specific packet handling (notably sequence number and encryption handling) is sensitive to re-ordering, things break if they are applied before the TXQ. This

Re: [PATCH] drivers: staging: rtl823au: hal: Remove pointless test

On Wed, Aug 31, 2016 at 09:32:56PM +0200, Matthias Beyer wrote: > Pinging here as nobody responded yet. > > Maybe this was overlooked. Nope, it was only a week, staging patches are at the bottom of my queue, please give me time to get to them, I process them usually ever few weeks... thanks,

Re: [PATCH 1/6] rtl8723au: remove declaration of unimplemented functions

On Sat, Aug 27, 2016 at 02:40:44PM +0200, Luca Ceresoli wrote: > Signed-off-by: Luca Ceresoli > Cc: Larry Finger > Cc: Jes Sorensen > Cc: Greg Kroah-Hartman > Cc:

Re: [PATCH] mwifiex: handle edmac vendor command

Amitkumar Karwar writes: >> From: Kalle Valo [mailto:kv...@codeaurora.org] >> Sent: Tuesday, May 24, 2016 1:53 AM >> To: Amitkumar Karwar >> Cc: linux-wireless@vger.kernel.org >> Subject: Re: [PATCH] mwifiex: handle edmac vendor command >> >> Amitkumar Karwar

[PATCH v3 2/2] wcn36xx: Implement firmware assisted scan

Using the software based channel scan mechanism from mac80211 keeps us offline for 10-15 second, we should instead issue a start_scan/end_scan on each channel reducing this time. Signed-off-by: Bjorn Andersson --- Changes since v2: - None

[PATCH v3 1/2] wcn36xx: Transition driver to SMD client

The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD channel, as such it should be a SMD client. This patch makes this transition, now that we have the necessary frameworks available. Signed-off-by: Bjorn Andersson --- Changes since v2: - Correct the

Re: pull-request: iwlwifi-next 2016-08-30-2

Luca Coelho writes: > This is a v2 of my pull request with the potential below array bounds > access, reported by kbuild bot, fixed. > >> Another pull request, this time intended for 4.9.  I have a lot of >> patches to send, but I'll send smaller batches this time. :) >> >>

Re: pull-request: iwlwifi 2016-08-29

Luca Coelho writes: > Here are 4 patches intended for 4.8.  They are all very small and low > risk, but fix some actual issues.  More details in the tag description. > > Let me know if everything's fine (or not). :) > > Luca. > > > The following changes since commit

Re: [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

Johannes Berg writes: >> Yeah, was going to do that anyway. But since I'm touching the code >> anyway, this might be an opportunity to avoid constructs like this: >> >> if (!invoke_tx_handlers(tx)) >>   /* continue sending the packet */ >> >> Most other succeed/fail

Re: [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

> Yeah, was going to do that anyway. But since I'm touching the code > anyway, this might be an opportunity to avoid constructs like this: > > if (!invoke_tx_handlers(tx)) >   /* continue sending the packet */ > > Most other succeed/fail functions seem to be of type bool, so it > would help

Re: [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

Johannes Berg writes: >> > They have three possible values ... :) >> >> Ah, no, not the handlers themselves. Meant the invoke_tx_handlers() >> function (or all three of them after my patch; hence the plural). To >> avoid the "0 means true" confusion you alluded to :)

Re: [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

> > They have three possible values ... :) > > Ah, no, not the handlers themselves. Meant the invoke_tx_handlers() > function (or all three of them after my patch; hence the plural). To > avoid the "0 means true" confusion you alluded to :) > Ah. Actually, even I got confused and thought the

Re: [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

Johannes Berg writes: >> > > +static int invoke_tx_handlers(struct ieee80211_tx_data *tx) >> > > +{ >> > > +return invoke_tx_handlers_early(tx) || >> > > invoke_tx_handlers_late(tx); >> > > +} >> > >> > Ugh, please, no, don't be tricky where it's not

Re: [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

> > > +static int invoke_tx_handlers(struct ieee80211_tx_data *tx) > > > +{ > > > + return invoke_tx_handlers_early(tx) || > > > invoke_tx_handlers_late(tx); > > > +} > > > > Ugh, please, no, don't be tricky where it's not necessary. Now > > every > > person reading this has to first look up the

Re: [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

Johannes Berg writes: >> +static int invoke_tx_handlers(struct ieee80211_tx_data *tx) >> +{ >> +return invoke_tx_handlers_early(tx) || >> invoke_tx_handlers_late(tx); >> +} > > Ugh, please, no, don't be tricky where it's not necessary. Now every > person reading