Re: ath10k stuck on 6Mbps and spam syslog

Dear Ben, Thank you for your reply. The fact that stock ath10k firmware does not report tx-rate explains why the station dump shows 6Mbps but the iperf test reach 14.6 (even if it is really under the expected data rate...). About the syslog spam, this is the code of the function that seems to

Re: [PATCH 1/3] mac80211: filter multicast data packets on AP / AP_VLAN

[snip] I think this makes sense, but it's not clear to me why you add two counters and keep the old one? It seems to me that it would be sufficient to have a single counter per AP/VLAN interface? The usage in __ieee80211_request_smps_ap() can just be removed since it goes to iterate the stations

Re: ath10k mesh mode issue

Hi Chun-Yeoh, These https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh are the staeps that i followed to set-up the mesh. Thanks! Matteo 2016-09-29 17:10 GMT+02:00 Yeoh Chun-Yeow : > Try refer the following for latest mesh setup using ath10k: >

Re: [PATCH 2/3] mac80211: multicast to unicast conversion

> +static ssize_t ieee80211_if_fmt_unicast( > + const struct ieee80211_sub_if_data *sdata, char *buf, int > buflen) That's a very ... unusual way to break the lines here - please either break after the first argument, or before the function name. You should see lots of examples for both.

Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces

A few more things: First of all - there's nothing specific to "AP interfaces", which you say in the subject, as far as I can tell? That should be removed? On Wed, 2016-09-28 at 17:14 +0200, Michael Braun wrote: > When using WPA security, the station and thus the required key is > identified by

Re: [PATCH 3/3] mac80211: cache the only AP_VLAN station

On Sun, 2016-09-25 at 18:39 +0200, Michael Braun wrote: > If an AP_VLAN is only used with one station, cache a pointer to this > station to avoid lookup. This should speed up station lookup when "should speed up"? Do you have numbers to back that up? Read this as - you need to do more to

Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding

On 2016-09-30 00:41, Arnd Bergmann wrote: > On Thursday 29 September 2016, Felix Fietkau wrote: >> On 2016-09-08 12:54, Kalle Valo wrote: >> > Felix Fietkau writes: >> > >> >> Signed-off-by: Felix Fietkau >> >> --- >> >> .../bindings/net/wireless/mediatek,mt76.txt

Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

Hi Toke, Sorry for the delay reviewing this. I think I still have a few comments/questions. > +static inline bool txq_has_queue(struct ieee80211_txq *txq) > +{ > + struct txq_info *txqi = to_txq_info(txq); > + return !(skb_queue_empty(>frags) && !txqi->tin.backlog_packets); > +} Tiny

Re: [PATCH] brcmfmac: implement more accurate skb tracking

On 29-9-2016 23:57, Rafał Miłecki wrote: > On 27 September 2016 at 11:24, Arend Van Spriel > wrote: >> On 26-9-2016 14:38, Rafał Miłecki wrote: >>> On 26 September 2016 at 14:13, Rafał Miłecki wrote: On 26 September 2016 at 13:46, Arend Van

Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices

On Fri, 2016-09-23 at 21:59 +0200, Toke Høiland-Jørgensen wrote: > Small devices can run out of memory from queueing too many packets. > If VHT is not supported by the PHY, having more than 4 MBytes of > total queue in the TXQ intermediate queues is not needed, and so we > can safely limit the

[PATCH 1/3] cw1200: Don't leak memory if krealloc failes

The call to krealloc() in wsm_buf_reserve() directly assigns the newly returned memory to buf->begin. This is all fine except when krealloc() failes we loose the ability to free the old memory pointed to by buf->begin. If we just create a temporary variable to assign memory to and assign the

Re: [PATCH 1/3] cw1200: Don't leak memory if krealloc failes

> + tmp = krealloc(buf->begin, size, GFP_KERNEL | GFP_DMA); > + if (tmp) { > I think that check is inverted? johannes

Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices

Johannes Berg writes: > On Fri, 2016-09-23 at 21:59 +0200, Toke Høiland-Jørgensen wrote: >> Small devices can run out of memory from queueing too many packets. >> If VHT is not supported by the PHY, having more than 4 MBytes of >> total queue in the TXQ intermediate

Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

Applied, with the nits fixed as discussed. Come to think of it, if somebody is bored ;-) perhaps a hwsim option to use TXQs (should be optional I guess) would be nice so we can exercise this code with the wpa_supplicant hwsim tests. That would have caught the TKIP issues etc. pretty early on too,

Re: [PATCH] ath10k: Fix spinlock use in coverage class hack

Benjamin Berg writes: > ath10k_hw_qca988x_set_coverage_class needs to hold both conf_mutex and > the data_lock spin lock for parts of the function. However, data_lock > is only needed while storing the coverage_class to store the value that > the card is configured to.

Re: [PATCH 2/2] Revert "staging: wilc1000: Replace kthread with workqueue for host interface"

On Fri, Sep 30, 2016 at 03:43:18PM +0530, Aditya Shankar wrote: > This reverts commit 2518ac59eb27 ("staging: wilc1000: Replace kthread > with workqueue for host interface") > > This commit breaks wilc1000 driver init. A crash was seen > everytime the wlan interface was brought up and wilc device

Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

Johannes Berg writes: > Applied, with the nits fixed as discussed. Awesome, thanks! > Come to think of it, if somebody is bored ;-) perhaps a hwsim option > to use TXQs (should be optional I guess) would be nice so we can > exercise this code with the wpa_supplicant

Re: pull-request: wireless-drivers-next 2016-09-29

David Miller writes: > From: Kalle Valo > Date: Thu, 29 Sep 2016 19:57:28 +0300 > ... >> Or actually I had one problem. While doing a test merge I noticed that >> net-next fails to compile for me, but I don't think this is anything >> wireless related:

[PATCH v2] ath10k: allow setting coverage class

From: Benjamin Berg Unfortunately ath10k does not generally allow modifying the coverage class with the stock firmware and Qualcomm has so far refused to implement this feature so that it can be properly supported in ath10k. If we however know the registers that need

Re: [PATCH] mac80211: fix CMD_FRAME for AP_VLAN

>  net/mac80211/offchannel.c | 5 - >  1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c > index 55a9c5b..2afd329 100644 > --- a/net/mac80211/offchannel.c > +++ b/net/mac80211/offchannel.c > @@ -819,7 +819,10 @@ int

Re: [PATCH 1/3] cw1200: Don't leak memory if krealloc failes

On Fri, Sep 30, 2016 at 02:29:39PM +0200, Johannes Berg wrote: > > > + tmp = krealloc(buf->begin, size, GFP_KERNEL | GFP_DMA); > > + if (tmp) { > > > I think that check is inverted? > > johannes Fu.. you're right, of cause it's !tmp. I'll resend. Thanks, Johannes -- Johannes

Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

Johannes Berg writes: >> Not sure if you want a v10, or if you're satisfied with the above >> comments and will just fix up the nits on merging? >> > > I'll fix it up. Thanks! Cool, thanks :) -Toke

Re: [PATCH v9 1/2] mac80211: Move ieee802111_tx_dequeue() to later in tx.c

On Thu, 2016-09-22 at 19:04 +0200, Toke Høiland-Jørgensen wrote: > The TXQ path restructure requires ieee80211_tx_dequeue() to call TX > handlers and parts of the xmit_fast path. Move the function to later > in tx.c in preparation for this. > Applied. johannes

Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

Johannes Berg writes: > Hi Toke, > > Sorry for the delay reviewing this. > > I think I still have a few comments/questions. No worries. And not terribly surprised ;) >> +static inline bool txq_has_queue(struct ieee80211_txq *txq) >> +{ >> +struct txq_info *txqi =

[PATCH v2] cw1200: Don't leak memory if krealloc failes

The call to krealloc() in wsm_buf_reserve() directly assigns the newly returned memory to buf->begin. This is all fine except when krealloc() failes we loose the ability to free the old memory pointed to by buf->begin. If we just create a temporary variable to assign memory to and assign the

Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

> Because I need to run it anyway for the xmit_fast path on dequeue. I > thought doing it this way simplifies the code (at the cost of the > handler getting called twice when xmit_fast is not active). Ok, that's fair. > > I *think* it should commute with the rate control handler, but even > >

Re: [PATCH 1/3] cw1200: Don't leak memory if krealloc failes

Hello. On 9/30/2016 3:11 PM, Johannes Thumshirn wrote: The call to krealloc() in wsm_buf_reserve() directly assigns the newly returned memory to buf->begin. This is all fine except when krealloc() failes we loose the ability to free the old memory pointed to by Fails. buf->begin. If we

Re: [PATCH 1/3] cw1200: Don't leak memory if krealloc failes

On Fri, Sep 30, 2016 at 03:56:45PM +0300, Sergei Shtylyov wrote: > Hello. > > On 9/30/2016 3:11 PM, Johannes Thumshirn wrote: > > > The call to krealloc() in wsm_buf_reserve() directly assigns the newly > > returned memory to buf->begin. This is all fine except when krealloc() > > failes we

Re: [PATCH 0/4] ath10k: fix mesh sync operation

On Wed, 2016-09-28 at 16:56 -0700, Thomas Pedersen wrote: > This patchset introduces a new ieee80211_op offset_tsf(), which gives > the driver a s64 TSF offset for TSF adjustment. This is more accurate > than programming absolute TSF since programming delay is avoided. > You were lucky we have

Re: [PATCH] cfg80211: Add support for static WEP in the driver

On Thu, 2016-09-22 at 23:16 +0300, Luca Coelho wrote: > From: David Spinadel > > Add support for drivers that implement static WEP internally, i.e. > expose connection keys to the driver in connect flow and don't > upload the keys after the connection. > Applied.

Re: [PATCH v3 1/9] cfg80211: add start / stop NAN commands

All applied. johannes

Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices

> > I kinda see the logic here - we really don't need to queue as much > > if we can't possibly transmit it out quickly - but it seems to me > > we should also throw in some kind of limit that's relative to the > > amount of memory you have on the system? > > Yes, ideally. That goes for FQ-CoDel

pull-request: mac80211-next 2016-09-30

Hi Dave, Last pull request before the merge window, since it's about to open :) It seems that everyone finally agreed on the NAN (neighbor awareness networking) APIs, so we have that, along with some other things. Let me know if there's any problem. Thanks, johannes The following changes

[PATCH 2/2] rtl8xxxu: Fix rtl8192eu driver reload issue

From: Jes Sorensen The 8192eu suffered from two issues when reloading the driver. The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and 23 didn't get set in rtl8192e_enable_rf(). In addition it also seems prone to issues when setting REG_RF_CTRL to 0

[PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue

From: Jes Sorensen The generic disable_rf() function clears bits 22 and 23 in REG_RX_WAIT_CCA, however we did not re-enable them again in rtl8723b_enable_rf() This resolves the problem for me with 8723bu devices not working again after reloading the driver.

[PATCH 0/2] rtl8xxxu: Fix driver reload issues with 8723bu and 8192eu

From: Jes Sorensen Hi, These two patches fix issues where rtl8723bu and rtl8192eu dongles would stop receving data if one reloaded the driver module, requiring it to be physically removed and reinserted. Both issues are applicable to 4.9. The first patch for 8723bu is

Re: RTL8192EU on rtl8xxxu driver breaks every few minutes

"Franc[e]sco" writes: > Oops, forgot to forward the previous reply to the mailing list. > > I have attached the output of iw link > > the AP is an asus dsl-n55u router in 2.4 GHz mode, using WPA2-Personal > with AES encryption. It's also running a second 5GHz wireless

Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices

Johannes Berg writes: >> > I kinda see the logic here - we really don't need to queue as much >> > if we can't possibly transmit it out quickly - but it seems to me >> > we should also throw in some kind of limit that's relative to the >> > amount of memory you have on

Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding

On Friday 30 September 2016, Felix Fietkau wrote: > >> >> + pcie0 { > >> >> + mt76@0,0 { > >> >> + reg = <0x 0 0 0 0>; > > > > Maybe have an examplep of a real register address other than zero? > This is a real example referring to the first device on a PCI bus. > I

Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding

On Friday 30 September 2016, Felix Fietkau wrote: > >> >> >> + device_type = "pci"; > >> >> >> + mediatek,mtd-eeprom = < 0x8000>; > >> >> >> + mediatek,2ghz = <0>; > >> > > >> > It's not clear what the possible values for the 2ghz property are, > >>

Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding

On 2016-09-30 16:36, Arnd Bergmann wrote: > On Friday 30 September 2016, Felix Fietkau wrote: >> >> >> + pcie0 { >> >> >> + mt76@0,0 { >> >> >> + reg = <0x 0 0 0 0>; >> > >> > Maybe have an examplep of a real register address other than zero? >> This is a real example