Re: [POC/GIT] mac80211 multicast rate selection (help wanted!)

On Fri, Aug 18, 2017 at 03:49:39PM -0700, Ben Greear wrote: > On 08/18/2017 03:29 PM, David Lamparter wrote: > > I've taken up an hacking endeavour in trying to improve multicast on > > wifi, specifically to get it off the stupid 1 MBit rate. Before anyone > > yells "that's not allowed by the

Re: [POC/GIT] mac80211 multicast rate selection (help wanted!)

On Sat, Aug 19, 2017 at 12:58:11AM +0200, Matteo Croce wrote: > Il giorno sab, 19/08/2017 alle 00.29 +0200, David Lamparter ha scritto: > > So, from some completely unrelated datacenter work, I have hacked up > > the bridge to hand back down to the driver detailed info on > > multicast receivers.

Re: [POC/GIT] mac80211 multicast rate selection (help wanted!)

Il giorno sab, 19/08/2017 alle 00.29 +0200, David Lamparter ha scritto: > Hello Linux Wireless hackers, > > > I've taken up an hacking endeavour in trying to improve multicast on > wifi, specifically to get it off the stupid 1 MBit rate. Before > anyone > yells "that's not allowed by the spec"

Re: [POC/GIT] mac80211 multicast rate selection (help wanted!)

On 08/18/2017 03:29 PM, David Lamparter wrote: Hello Linux Wireless hackers, I've taken up an hacking endeavour in trying to improve multicast on wifi, specifically to get it off the stupid 1 MBit rate. Before anyone yells "that's not allowed by the spec" - it actually is, please refer to

[POC/GIT] mac80211 multicast rate selection (help wanted!)

Hello Linux Wireless hackers, I've taken up an hacking endeavour in trying to improve multicast on wifi, specifically to get it off the stupid 1 MBit rate. Before anyone yells "that's not allowed by the spec" - it actually is, please refer to section 9.7.5 of 802.11-2012. ("... using one of the

Re: ath9k driver - is it possible to disable tx/rx radio chains?

Hi Thank you so much. You made my day! The command works. Im looking forward to test it out :-) I also have two of these card. they don’t have the same bitmap, but I assume they work the same way? qca9882 chipset with 2 chains available using ath10k driver: Available Antennas: TX 0x3

Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

On Fri, 2017-08-18 at 20:16 +0300, Luca Coelho wrote: > Hi Dariusz, > > On Fri, 2017-08-18 at 14:48 +0200, Dariusz Gadomski wrote: > > Hi, > > > > There is a “Wi-Fi Direct Client Policy” setting in some Cisco AP hardware > > [1]. > > I am unaware how that works exactly behind the scenes (except

Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

Hi Dariusz, On Fri, 2017-08-18 at 14:48 +0200, Dariusz Gadomski wrote: > Hi, > > There is a “Wi-Fi Direct Client Policy” setting in some Cisco AP hardware [1]. > I am unaware how that works exactly behind the scenes (except for some hints > at > [2]), but I have noticed that with that setting

[PATCH 22/24] iwlwifi: mvm: remove useless argument in iwl_nvm_init()

From: Luca Coelho We always call iwl_nvm_init() with read_nvm_from_nic == true, so this argument is useless. Remove it. Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 5 +-

[PATCH 20/24] iwlwifi: add workaround to disable wide channels in 5GHz

From: Luca Coelho The OTP in some SKUs have erroneously allowed 40MHz and 80MHz channels in the 5.2GHz band. The firmware has been modified to not allow this in those SKUs, so the driver needs to do the same otherwise the firmware will assert when we try to use it.

[PATCH 11/24] iwlwifi: mvm: remove session protection to allow channel switch

From: Avraham Stern If a time event is already scheduled when trying to schedule one for channel switch, the code assumes the channel switch is already scheduled and no further action is required. However, it is possible that the scheduled time event is actually for

[PATCH 23/24] iwlwifi: mvm: remove useless check for mvm->cfg in iwl_parse_nvm_section()

From: Luca Coelho At this point we have already copied the cfg pointer to mvm and we have been dereferencing this pointer many times before, so it will never be NULL or we would have crashed. Remove the useless check. Signed-off-by: Luca Coelho

[PATCH 18/24] iwlwifi: update channel flags parser

From: Luca Coelho There are some new flags in the channel flags that we don't know about. Also, the "WIDE" flag is very confusing, because it actually means 20MHz bandwidth, which is not very wide. Add the new flags and rename the confusing one. Signed-off-by: Luca

[PATCH 19/24] iwlwifi: mvm: change open and close criteria of a BA session

From: Gregory Greenman Tx BA session should be started according to the current throughput without any dependence on the internal rate scaling state. The criteria for opening a BA session will be 10 frames per second. Sending frequent del BAs can cause inter-op

[PATCH 24/24] iwlwifi: use big-endian for the hw section of the nvm

From: Luca Coelho Unlike the other sections of the NVM, the hw section is in big-endian. To read a value from it, we had to cast it to __be16. Fix that by using __be16 * for the entire section. Signed-off-by: Luca Coelho ---

[PATCH 13/24] iwlwifi: move BT_MBOX_PRINT macro to common header

From: Luca Coelho Move the BT_MBOX_PRINT() macro from mvm/debugfs.c to fw/api/coex.h so it can be reused and remove duplicate definition of BT_MBOX_MSG(), keeping only the one already in coex.h. Signed-off-by: Luca Coelho ---

[PATCH 21/24] iwlwifi: fw: fix lar_enabled endian problem in iwl_fw_get_nvm

From: Luca Coelho We read the regulatory.lar_enabled field in iwl_fw_get_nvm() and store it in nvm->lar_enabled, taking care of endianness. But then later we read it again to pass the value to iwl_init_sbands() without handling endianness. To solve this, simply reuse

[PATCH 16/24] iwlwifi: distinguish different RF modules in A000 devices

From: Tzipi Peres Newer versions of A000 devices come with two diffenent RF modules. The PCI_ID, the subsystem ID and the RF ID are identical in these two cases, so we need to differentiate them by using the CSR_HW_RF_ID register- in order to load the appropriate firmware.

[PATCH 15/24] iwlwifi: mvm: Fix channel switch in case of count <= 1

From: Ilan Peer The code did not consider the case that the channel switch counter is <= 1, which would result with an inaccurate calculation of the time event apply time. As the specification states that in case of counter == 0 the switch occurs at any time after the

[PATCH 17/24] iwlwifi: pci: add new PCI ID for 7265D

From: Luca Coelho We have a new PCI subsystem ID for 7265D. Add it to the list. Cc: sta...@vger.kernel.org Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 14/24] iwlwifi: Demote messages about fw flags size to info

From: João Paulo Rechi Vita These messages are not reporting a real error, just the fact that the firmware knows about more flags than the driver. Currently these messages are presented to the user during boot if there is no bootsplash covering the console, even when booting

[PATCH 12/24] iwlwifi: mvm: don't send BAR on flushed frames

From: Emmanuel Grumbach When we flush a queue, the packets will have a 'failed' status but we shouldn't send a BAR. This check was missing. Because of that, when we got an ampdu_action with IEEE80211_AMPDU_TX_STOP_FLUSH, we started the following ping pong with the

[PATCH 10/24] iwlwifi: mvm: update the firmware API in TX

From: Emmanuel Grumbach The firmware team is now re-using a bit that hasn't been used for a few generations. Re-use for TX_ON_AIR drop. This bit will be set by the firmware to indicate that a frame in an A-MPDU was dropped but not because of the already mapped

[PATCH 07/24] iwlwifi: mvm: include more debug data when we get an unexpected baid

From: Emmanuel Grumbach When we get a valid baid in a received frame, we need to check that we are aware of this baid. If not, we check that the OLD_SN bit set. If that's not the case, we issue a WARNING. Print more data when that happens. Signed-off-by: Emmanuel

[PATCH 02/24] iwlwifi: mvm: consider RFKILL during INIT as success

From: Luca Coelho There's no need to differentiate an INIT that ended early because of RFKILL from one that succeded. Additionally, if INIT fails later, during calibration, due to RFKILL, we can just return success and continue as if we were already in RFKILL to start

[PATCH 05/24] iwlwifi: pcie: support short Tx queues for A000 device family

From: Emmanuel Grumbach This allows to modify TFD_TX_CMD_SLOTS to a power of 2 which is smaller than 256. Note that we still need to set values to wrap at 256 into the scheduler's write pointer, but all the rest of the code can use shorter transmit queues.

[PATCH 06/24] iwlwifi: mvm: add command name for FRAME_RELEASE

From: Emmanuel Grumbach This name was missing in the list. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 1 + 1 file changed, 1 insertion(+)

[PATCH 04/24] iwlwifi: mvm: support new Coex firmware API

From: Emmanuel Grumbach The firmware now adds more information about time sharing with the Bluetooth core. Adapt the API structures and add the new fields in the debugfs hooks. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho

[PATCH 08/24] iwlwifi: mvm: group all dummy SAR function declarations together

From: Luca Coelho We have some of the SAR dummy functions when ACPI is not set declared in mvm.h and some declared in fw.c. Group them all together in fw.c for consistency and to avoid static/non-static issues. Signed-off-by: Luca Coelho ---

[PATCH 09/24] iwlwifi: mvm: use mvmsta consistently in rs.c

From: Luca Coelho We use mvmsta for the sta->drv_priv in mvm, but in rs.c we have a bunch of instances using sta_priv, which is probably due to it being copied from dvm. Change all occurrences to mvmsta for consistency with the rest of the driver Signed-off-by: Luca

[PATCH 00/24] iwlwifi: updates intended for v4.14 2017-08-18

From: Luca Coelho Hi, Here's one more set of patches for v4.14. These are the changes: * Work for the upcoming A000 device family continues; * Improvements in debugging; * A couple of improvements in block-ack sessions; * Some fixes for channel switch; * A workaround

[PATCH 01/24] iwlwifi: mvm: remove the corunning support

From: Emmanuel Grumbach The corunning block was supposed to help in coex scenarios. It required the driver to configure the firmware based on the coupling between the two antennas of the devices. This was never in use and the configuration sent by the driver has

[PATCH 03/24] iwlwifi: call iwl_remove_notification from iwl_wait_notification

From: Luca Coelho The iwl_wait_notification() function removes the wait entry from the list. To make it clearer that it's doing the same thing as iwl_remove_notification(), call the latter instead of having duplicate code. Signed-off-by: Luca Coelho

Re: [PATCH] rtlwifi: make a couple arrays larger

On 08/18/2017 03:05 AM, Dan Carpenter wrote: This is a static checker fix. "cal_num" is 10. We're declaring the tx_dt[] and rx_td[] arrays as 3 element arrays. The static checker complains that we do: tx_dt[cal] = (vdf_y[1]>>20)-(vdf_y[0]>>20); "cal" is the iterator and it is in the

Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

Hi, There is a “Wi-Fi Direct Client Policy” setting in some Cisco AP hardware [1]. I am unaware how that works exactly behind the scenes (except for some hints at [2]), but I have noticed that with that setting set to “Deny” I am observing issues when trying to connect from a machine with an

[PATCH 1/2] mac80211: add documentation to ieee80211_rx_ba_offl()

From: Luca Coelho Add documentation to ieee80211_rx_ba_offl() function and, while at it, rename the bit argument to tid, for consistency. Signed-off-by: Luca Coelho --- include/net/mac80211.h | 8 +++- net/mac80211/agg-rx.c | 4 ++-- 2

[PATCH 2/2] mac80211: flush hw_roc_start work before cancelling the ROC

From: Avraham Stern When HW ROC is supported it is possible that after the HW notified that the ROC has started, the ROC was cancelled and another ROC was added while the hw_roc_start worker is waiting on the mutex (since cancelling the ROC and adding another one also

[PATCH 0/2] mac80211 patches from our internal tree 2017-08-18

From: Luca Coelho Here are two pending mac80211 patches from our internal tree. Please review. Cheers, Luca. Avraham Stern (1): mac80211: flush hw_roc_start work before cancelling the ROC Luca Coelho (1): mac80211: add documentation to ieee80211_rx_ba_offl()

[PATCH v4 12/19] nl80211: add an option to allow MFP without requiring it

From: Emmanuel Grumbach The user space can now allow the kernel to associate to an AP that requires MFP or that doesn't have MFP enabled in the same NL80211_CMD_CONNECT command, by using a new NL80211_MFP_OPTIONAL flag. The driver / firmware will decide whether to

Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

Hi Jörg, On Thu, Jun 1, 2017 at 3:37 AM, Jörg Krause wrote: > I'm experiencing low throughput with a BCM43362 wifi chip attached via > SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm > getting now a TCP throughput of 12.5 Mbps for the wifi

[PATCH] rtlwifi: make a couple arrays larger

This is a static checker fix. "cal_num" is 10. We're declaring the tx_dt[] and rx_td[] arrays as 3 element arrays. The static checker complains that we do: tx_dt[cal] = (vdf_y[1]>>20)-(vdf_y[0]>>20); "cal" is the iterator and it is in the 0-9 range so it looks like we could corrupt

Re: ath9k driver - is it possible to disable tx/rx radio chains?

On 18/08/17 01:32, Håvard Rabbe wrote: > Hi > I’m using wifi card with AR9280 chipset that uses the ath9k driver. > > The card has 2 available radio chains and I’m only going to connect 1 antenna. > > Is it possible to disable the radio chain im not using? > > > Best Regards, > > Håvard Rabbe