- 11 Nov, 2014 8 commits
-
-
Emmanuel Grumbach authored
When we need only one antenna, we should refrain from using the antenna that is shared with BT if BT load is high. Fix this. Reviewed-by:
Eyal Shapira <eyal@wizery.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eyal Shapira authored
When Tx STBC is being used and RS switches to a search column using the alternate antenna from the current one there is a problem with using rs_rate_match to figure out which table is the active and which one is the search one. The root cause is because in STBC the antenna mask in the ucode rate is set to ANT_AB and in this specific scenario it matches both the active and search table (e.g. SISO_ANT_A and SISO_ANT_B). This leads to tx stats being updated in the wrong table and later on to getting stuck in a test window and not moving on to other columns. If this happens during the initial search cycle we never end it and therefore never enable aggregation which leads naturally to severe througput degradation. Fix it by deducing which table is which by knowing whether we're in a search or not like it's being done in rs_rate_scale_perform Signed-off-by:
Eyal Shapira <eyalx.shapira@intel.com> Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Eliad Peller authored
Other contexts might call iwl_mvm_ref_sync() right before we set IWL_MVM_STATUS_IN_D0I3, and then assume the fw/bus is not in d0i3 state. However, since we currently don't check for held references in the d0i3_enter flow, we might enter d0i3 although there is an active reference. Solve it by aborting the d0i3 enter flow if there is an active reference. Since users are assumed to use iwl_mvm_ref_sync, which takes a ref before checking the flag, we don't need further locking. Signed-off-by:
Eliad Peller <eliadx.peller@intel.com> Reviewed-by:
-
Eyal Shapira authored
This was taken care of in case we're doing STBC with HT but not when working with VHT. Signed-off-by:
-
Liad Kaufman authored
Even if running the driver with param init_dbg=1 - on INIT image error - iwl_trans_stop_device() was still called. This patch fixes that and calls iwl_trans_stop_device() on INIT image failure only if init_dbg=0. Signed-off-by:
Liad Kaufman <liad.kaufman@intel.com> Signed-off-by:
-
Johannes Berg authored
The variable 'tid' is already defined in this function, so use just 't' for the new one. As we return from the function just overwriting 'tid' would be acceptable, but less obvious to the reader. Signed-off-by:
-
Arik Nemtsov authored
Mostly functions related to building Tx-commands for sending to FW. Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
-
Johannes Berg authored
The status variable should be unsigned as the function call requires a u32 not int pointer, fix that. Signed-off-by:
-
- 03 Nov, 2014 1 commit
-
-
Eyal Shapira authored
iwl_trans_update_sf can fail and this wasn't handled. Fix this. Signed-off-by:
-
- 31 Oct, 2014 1 commit
-
-
Emmanuel Grumbach authored
Fix my mistake while sending Johannes's commit aadede6e Author: Johannes Berg <johannes.berg@intel.com> Date: Thu Oct 9 17:01:36 2014 +0200 iwlwifi: mvm: port to devcoredump framework Signed-off-by:
-
- 29 Oct, 2014 26 commits
-
-
Eliad Peller authored
The scan reference wasn't released in case of offloaded scan, causing the refcount to go wrong and prevent the device from going into d0i3. Signed-off-by:
-
Eyal Shapira authored
STBC is enabled on HT/VHT SISO rates in case we don't care about power consumption and it won't hurt BT. This is done only in case the peer and our chip support STBC of course. While at it fixed a bug which was causing bw and ldpc flags to be set incorrectly in the rate scale table in case we are switching to a legacy Tx column. This had no real impact. Signed-off-by:
-
David Spinadel authored
Scan condition iterator assumes that an interface is associated if phy_ctxt is assigned, but this isn't the sutuation in P2P device. OTOH P2P device is never associated so we can simply ignore it. Signed-off-by:
David Spinadel <david.spinadel@intel.com> Signed-off-by:
-
Johannes Berg authored
iwlwifi features a debug mechanism that allows to dump binary data which is helpful to debug the firmware. Until now, this data was made available for the userspace through debugfs. For this exact purpose, devcoredump was created. Move to the new infrastructure. Signed-off-by:
-
Eyal Shapira authored
These chips support STBC in both Tx and Rx. Given that we've added STBC Tx support enable it. Signed-off-by:
-
Joe Perches authored
Precedence of & and >> is not the same and is not left to right. shift has higher precedence and should be done after the mask. Add parentheses around the mask. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Luciano Coelho authored
We used to need to include some headers in order to read the registers and do all the calculations by ourselves, but this is not done anymore (i.e. we let the firmware do this for us), so we don't need to include those headers anymore. Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Johannes Berg authored
For WMM-AC we may have to be changing QoS parameters while the queues are being flushed. This is not relevant in the "drop" case, but matters when we wait for the device to finish the transmissions. To allow this, do the actual waiting without holding the mutex. Signed-off-by:
-
Johannes Berg authored
The warning gives no information about the frame, and presents the flags so that one might think they're the frame. Clarify and add more information. Signed-off-by:
-
Emmanuel Grumbach authored
This makes it easier to tune the values during the testing. Signed-off-by: -
Arik Nemtsov authored
It is unused and won't be available in some future invocations of the function. Signed-off-by:
-
Max Stepanov authored
The MVM_FW_BCAST_FILTER_PASS_ALL option defined in iwl-dbg-cfg.ini configuration file allows to enable/disable FW broadcast filtering. If MVM_FW_BCAST_FILTER_PASS_ALL is not defined in iwl-dbg-cfg.ini or its value is 0, the mvm broadcast filtering is enabled. Setting MVM_FW_BCAST_FILTER_PASS_ALL=1 in iwl-dbg-cfg.ini blocks sending of BCAST_FILTER_CMD to FW. Signed-off-by:
Max Stepanov <Max.Stepanov@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
This is were it really needs to be. Signed-off-by: -
Eran Harary authored
In the new format the "CSS section" has the same TLV type as the "mem section". So we need to run the secured flow for all the 8000 products. Signed-off-by:
Eran Harary <eran.harary@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
When the ARC is reset when we exit from Sx in case we had WoWLAN running, we can't access the prph before we reset the NIC. Reviewed-by:
-
Emmanuel Grumbach authored
Otherwise we have no way to know that the buffer hasn't been allocated. Signed-off-by: -
Gregory Greenman authored
A few slave bus devices show better performance when we reduce the size of the Tx A-MPDU. Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
-
Luciano Coelho authored
Getting the BSS station vif is something that may be needed by other parts of the code. So, instead of having an iterator specifically for d3, change it into a generic one in utils.c. Additionally, add a iwl_mvm_get_bss_vif() function to make it easier to retrieving it. Signed-off-by:
-
Luciano Coelho authored
Before we get all the chain (ie. mac80211, cfg80211, nl80211 and userspace) changed to support net-detect, we can use this debugfs entry for easy testing and as a proof of concept. Signed-off-by:
-
Luciano Coelho authored
The net-detect feature will require a scan offload to be started in the same way it is done now for scheduled scan. Spin a new function off of the sched_scan_start op code for reuse. Additionally, restructure the function a bit for more readability. Signed-off-by:
-
Luciano Coelho authored
Instead of checking if we are associated when suspending with wowlan enabled in the interface iterator, allow it to return an unassociated vif and move the check to the main suspend function. This will be needed by netdetect, since it should also work when we are not associated but the vif is active. Signed-off-by:
-
Luciano Coelho authored
Take the WoWLAN handling code out of the main suspend function, dividing it into three parts: get_config (which is used before the firmware is switched), switch_to_d3 (which handles the rebooting of the hardware with the D3 firmware) and config (which configures the D3 firmware for WoWLAN operation). This is necessary to prepare for the net-detect implementation, which will use only the switch_to_d3 part of this flow. Signed-off-by:
-
Luciano Coelho authored
We use ieee80211_iter_keys() which requires the rtnl to be held. If we don't lock the rtnl, like we do when we suspend during a d3 test, we get the following splat: RTNL: assertion failed at net/mac80211/key.c (566) CPU: 1 PID: 26529 Comm: cat Tainted: G W O 3.10.29-dev #1 Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012 e7b15008 e7b15008 e68adc1c c168aa62 e68adc54 f91f20b6 f923700c f9236fd8 00000236 00000000 ece23874 00000000 f94941e0 00000000 e43b8e48 e7b15008 00000000 e8b69e78 e68adcc0 f9493ab9 e68adc68 00000000 e43b8e48 e7b15008 Call Trace: [<c168aa62>] dump_stack+0x16/0x18 [<f91f20b6>] ieee80211_iter_keys+0x166/0x170 [mac80211] [<f94941e0>] ? iwl_mvm_query_wakeup_reasons+0x5f0/0x5f0 [iwlmvm] [<f9493ab9>] iwl_mvm_setup_connection_keep.isra.5+0x99/0x1d0 [iwlmvm] [<f9165e28>] ? cfg80211_report_wowlan_wakeup+0x308/0x510 [cfg80211] [<f9493fe5>] iwl_mvm_query_wakeup_reasons+0x3f5/0x5f0 [iwlmvm] [<c116125a>] ? init_object+0x3a/0x70 [<f8a5b8ee>] ? iwl_trans_pcie_d3_resume+0x1be/0x3a0 [iwlwifi] [<f94956da>] __iwl_mvm_resume+0x14a/0x180 [iwlmvm] [<f9495736>] iwl_mvm_d3_test_release+0x26/0xc0 [iwlmvm] [<c117a64d>] __fput+0xad/0x210 [<c117a7bd>] ____fput+0xd/0x10 [<c10601a1>] task_work_run+0x81/0xb0 [<c1040fa5>] do_exit+0x255/0xac0 [<c104e511>] ? dequeue_signal+0x31/0x1a0 [<c1041888>] do_group_exit+0x38/0xa0 [<c10a6cfb>] ? trace_hardirqs_on+0xb/0x10 [<c1051c31>] get_signal_to_deliver+0x1e1/0x8e0 [<c104bd52>] ? try_to_del_timer_sync+0x42/0x60 [<c104bd70>] ? try_to_del_timer_sync+0x60/0x60 [<c168dc82>] ? schedule_timeout+0x102/0x2a0 [<c10011ba>] do_signal+0x3a/0x8e0 [<c104b190>] ? __internal_add_timer+0xb0/0xb0 [<c168de7a>] ? schedule_timeout_interruptible+0x1a/0x20 [<c104ce39>] ? msleep_interruptible+0x39/0x40 [<f94939a9>] ? iwl_mvm_d3_test_read+0x49/0x70 [iwlmvm] [<c11797fc>] ? vfs_read+0x8c/0x160 [<c11243af>] ? SyS_fadvise64_64+0x15f/0x2b0 [<f9493960>] ? iwl_mvm_wowlan_program_keys+0x4a0/0x4a0 [iwlmvm] [<c1179a57>] ? SyS_read+0x57/0xa0 [<c1001acf>] do_notify_resume+0x6f/0xa0 [<c1692500>] work_notifysig+0x29/0x31 Fix this by hold the rtnl lock when calling __iwl_mvm_resume() in the d3 test wake up path. Signed-off-by:
-
Emmanuel Grumbach authored
mac80211 will never call rate_control_tx_status with a NULL pointer for sta. Remove the superfluous check. This check misled smatch. Signed-off-by: -
Eyal Shapira authored
The current TLC isn't optimized for low latency and some devices have issues with MIMO. This kind of combo creates latency issues. Allow to temporarily disable MIMO for tests in order to solve the latency issues without the added complexity of MIMO. Signed-off-by:
-
Emmanuel Grumbach authored
-
- 23 Oct, 2014 4 commits
-
-
Emmanuel Grumbach authored
iwl_poll_bit may return a strictly positive value when the poll doesn't match on the first try. This was caught when WoWLAN started failing upon resume even if the poll_bit actually succeeded. Also change a wrong print. If we reach the end of iwl_pcie_prepare_card_hw, it means that we couldn't get the devices. Reviewed-by:
-
Emmanuel Grumbach authored
This reverts commit aa11bbf3. This commit was causing connection issues and is not needed if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default. Regardless of the issues mentioned above, this patch added the following WARNING: WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:190 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]() Got an HT rate for a non data frame 0x8 CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G O 3.17.0+ #6 Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07/02/2014 0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52 0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600 0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020 Call Trace: [<ffffffff814fa911>] ? dump_stack+0x41/0x51 [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90 [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50 [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm] [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm] [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm] [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211] [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211] [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80211] [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0 [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0 [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0 [<ffffffff8142f670>] ? ether_setup+0x70/0x70 [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110 [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40 [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0 [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60 [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0 [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180 [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70 [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f ---[ end trace cc19a150d311fc63 ]--- which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=85691 CC: <stable@vger.kernel.org> [3.13+] Signed-off-by:
-
Emmanuel Grumbach authored
When mac80211 wants to ensure that a frame is sent, it calls the flush() callback. Until now, iwldvm implemented this by waiting that all the frames are sent (ACKed or timeout). In case of weak signal, this can take a significant amount of time, delaying the next connection (in case of roaming). Many users have reported that the flush would take too long leading to the following error messages to be printed: iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2 iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201 iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00 [snip] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000 [snip] iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [9,9] [snip] Instead of waiting for these packets, simply drop them. This significantly improves the responsiveness of the network. Note that all the queues are flushed, but the VO one. This is not typically used by the applications and it likely contains management frames that are useful for connection or roaming. This bug is tracked here: https://bugzilla.kernel.org/show_bug.cgi?id=56581 But it is duplicated in distributions' trackers. A simple search in Ubuntu's database led to these bugs: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809 Cc: <stable@vger.kernel.org> Depends-on: 77be2c54 ("mac80211: add vif to flush call") Signed-off-by:
-
Matti Gottlieb authored
Don't add the time event to the list. We added it several times the same time event, which leads to an infinite loop when walking the list. Since we (currently) don't support more than one ROC for STA vif at a time, enforce this and don't add the time event to any list. We were also missing the locking of the mutex which led to a lockdep splat - fix that. Signed-off-by:
Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by:
-
