- 14 4月, 2014 10 次提交
-
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
All the supported firmwares have this flag set. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 13 4月, 2014 14 次提交
-
-
由 Emmanuel Grumbach 提交于
This firmware is not supported any more. A few code paths specific to old firmware can be removed. We can now assume that a few TLV flags are always set since we won't load firmware that didn't support the corresponding features. This will be done in a separate patch. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
While the scan_cmd should really be allocated in init (and we do fail init in case the allocation failed), it doesn't mean we should lock up the machine if something really bad happened. Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eyal Shapira 提交于
Collect accumulated stats of tx attempts and successes per rate and column for debugging purposes. These stats can be read via debugfs file drv_tx_stats and can also be reset by writing to this file. Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Monam Agarwal 提交于
rcu_assign_pointer() ensures that the initialization of a structure is carried out before storing a pointer to that structure. However, in the case that NULL is assigned there's no structure to initialize so using RCU_INIT_POINTER instead is safe and more efficient. Signed-off-by: NMonam Agarwal <monamagarwal123@gmail.com> [rewrite commit log] Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
The firmware doesn't support broadcast filtering on P2P client. Trying to enable it makes the firmware assert. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eytan Lifshitz 提交于
When NIC is exiting from thermal throttling state (i.e. after heating and then cooling down), tx-backoff values are assigned to be zero, instead of being restored to the minimal value. Fixed. Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eytan Lifshitz 提交于
When NIC exit thermal throttling while having minimal tx-backoff restriction, the warning message that indicate about that state won't show up. Fixed. Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
The Rx FIFO includes valuable data - dump it when the FW asserts. Also - free the SRAM and Rx FIFO when we create the file, and don't collect new SRAM / Rx FIFO if the previous file hasn't been collected through debugfs yet. Also - add a comment to saying that the ASSERT output should not be modified since we have automatic scripts that monitor this output. Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
Now that mac80211 calls pre_rcu_remove and we set the fw_id_to_mac_id pointer to -ENOENT before the station is removed, we don't need to set fw_id_to_mac_id to -EINVAL when the station is really removed. Leave fw_id_to_mac_id to be -ENOENT which will let the drain worker (iwl_mvm_sta_drained_wk) know that this station is not to be drained. We don't need to drain this station since it is our AP in managed mode and we flush all its frames synchronously anyway. Setting the AP station to -EINVAL could lead to confusion since internal stations are also reserved with -EINVAL, this confusion showed up in the logs as: Drained sta 0, but it is internal? Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
The firmware tells us if an Rx packet was beamformed or not. Propagate this data to mac80211's rx_status.vht_flags. The main user of this data is the radiotap header. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Johannes Berg 提交于
Use the new NAPI infrastructure added to mac80211 to get GRO. We don't really implement NAPI since we don't have a real poll function and we never schedule a NAPI poll. Instead of this, we collect all the packets we got from a single interrupt and then call napi_gro_flush(). This allows us to benefit from GRO. In half duplex medium like WiFi, its main advantage is that it reduces the number of TCP Acks, hence improving the TCP Rx performance. Since we call the Rx path with a spinlock held, remove the might_sleep mention from the op_mode's API. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Reviewed-by: NIdo Yariv <ido@wizery.com> [Squash different patches and rewrite the commit message] Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eliad Peller 提交于
Allow fixing the tx power reduction through debugfs file. The change doesn't take affect immediately, but will be considered the next time tpc is evaluated. Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eliad Peller 提交于
Implement Adaptive Tx Power Control algorithm. ATPC basically tries to decrease the tx power as much as possible while the throughput is not being hurt. Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 10 4月, 2014 1 次提交
-
-
由 Eliad Peller 提交于
The fw recently added an option to set tx power reduction per station (in the lq_cmd command), and get the tx power reduction used (in the tx_resp struct). Use them and propogate this value up to mac80211's tx response (in order to use it later in the rate-scaling algorithm). Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 06 4月, 2014 2 次提交
-
-
由 Eran Harary 提交于
Number of channels changed from 40 to 50 Signed-off-by: NEran Harary <eran.harary@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Avri Altman 提交于
Today, the driver logic looks for the conditions to disable power management albeit power management should be enabled in a very few distinct cases. This patch changes the driver logic to enable power management once the required conditions met. While at it, make some housekeeping and support a few additional use cases: a) Add support for a standalone p2p client: Power management should be enabled for a P2P client MAC only if the firmware supports it (TLV flag is set). Instead we used the DCM flag, therefore we didn't cover use cases that did not include the DCM flag. b) Add support to Same-Channel-Mode (SCM): If both clients share the same channel (SCM), and there are no other active vifs in the system, power management should be enabled only if the firmware supports this (TLV flag is set). c) Fix power management logic for GO/AP: Today, when we detect an active GO / AP MAC - we disable power management for all the vifs altogether. Actually, the correct behavior is to enable power management on a client if on a different channel (based on the firmware capabilities). d) Housekeeping - Along with that, this patch includes some code-reorganizing: Today the logic of disabling power is scattered across several functions, specifically in the iterator. For the sake of both readability and scalability, we moved this logic to its applicable function, leaving the iterator gather information only. Furthermore, as power management is a MAC-related attribute, we moved the power management member to the iwl_mvm_vif structure. Signed-off-by: NAvri Altman <avri.altman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 19 3月, 2014 10 次提交
-
-
由 Emmanuel Grumbach 提交于
This fixes the build for powerpc: After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/wireless/iwlwifi/mvm/debugfs.c: In function 'iwl_dbgfs_fw_error_dump_release': drivers/net/wireless/iwlwifi/mvm/debugfs.c:161:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] vfree(file->private_data); ^ Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
The current firmware advertises support for uAPSD, but critical bugs force us to disable the feature. When a fixed firmware will be available, we will be able to re-enable uAPSD. Cc: <stable@vger.kernel.org> [3.13+] Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Johannes Berg 提交于
If the low-latency update is called but there's no change then ignore the update instead of triggering all the required work. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Johannes Berg 提交于
Remove a spurious blank line in the quota code. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
mvmsta could have been NULL / ERR. Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Alexander Bondar 提交于
In case of system low latency configure passive scan to be fragmented. Set the following scan parameters for both immediate and scheduled scan: - passive scan fragment duration = 20ms - out-of-channel time = 70ms - suspend time = 105ms Restructure channel's active/passive dwell time configuration to better suit the above change. The idea is that under low latency traffic passive scan is fragmented, i.e. that dwell on a particular channel will be fragmented. Each fragment dwell time is 20ms and fragments period is 105ms. Skipping to next channel will be delayed by the same period (105ms). So suspend_time parameter describing both fragments and channels skipping periods is set to 105ms. This value is chosen so that overall passive scan duration will not be too long. Max_out_time in this case is set to 70ms, so for active scanning operating channel will be left for 70ms while for passive still for 20ms (fragment dwell). Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Alexander Bondar 提交于
Some scan parameters should be dependent on traffic conditions. Centralize conditions verification in one function and obtain scan max out-of-channel and suspend time in that new function. Rely on bound interfaces indication instead of association state to calculate scan parameters. If no bound interfaces use default values for out-of-channel and suspend time parameters. Additionally, get rid of NL80211_SCAN_FLAG_LOW_PRIORITY checks since no use case for this exists so far. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> [reword commit log a bit] Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Johannes Berg 提交于
The firmware decided to not implement this API in this way, so for now remove setting the field completely. This will allow the firmware to change how to use this field later. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
In order to debug the firmware, we need to be able to set the BT priority of WiFi packets. This priority is set based on the type of the packet (control frames, EAPOL etc...). For debugging purposes, allow to override this priority by a debugfs controlled value. Enable this feature that needs this priority to be able to test it. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
When the firmware asserts, the driver will dump the firmware state to an internal buffer. This buffer is kept aside until it is dumped through debugfs. Once an external application fetched the data, the buffer is freed and a new buffer can be allocated in case another assert occurs. A udev event is sent to trigger an external application. A simple rule like: DRIVER=="iwlwifi", ACTION=="change", RUN+="/sbin/dump_sram.sh" can fetch the data from debugfs. Here is my dump_sram.sh: phyname=$(basename ${DEVPATH}) date=$(date +%F_%H_%M) filename=/var/log/iwl-sram-${phyname}-${date}.bin cat /sys/kernel/debug/ieee80211/${phyname}/iwlwifi/iwlmvm/fw_error_dump > ${filename} The current SRAM size is 80KB so, currently: $ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin -rw-r--r-- 1 emmanuel emmanuel 81K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin and after compression: $ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin.xz -rw-r--r-- 1 emmanuel emmanuel 13K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin.xz Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 16 3月, 2014 3 次提交
-
-
由 Eliad Peller 提交于
Enable protocol offloading (arp and NS) on D0i3. The offloading allows the fw answer NS and arp requests without waking up the host. Since protocol offloading is saved between D0i3 entries, we have to explicitly disable it in case we don't want it. Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Arik Nemtsov 提交于
In order to restore the qos seq number on d0i3 exit, we need to read it from the wowlan status. However, in order to make sure we use correct seq num for tx frames, we need to defer any outgoing frames, and re-enqueue them only after the seq num is configured correctly. Sync new Tx aggregations with D0i3 so that the correct seq num is used for them. Wait synchronously for D0i3 exit before starting a new Tx agg. Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eliad Peller 提交于
Configure the QoS counters when entering D0i3. The fw might use them later when performing protocol offloading (we'll update the the counters back on d0i3 exit in a following patch). Non-QoS counter is handled internally in the fw, so no need to configure it. Also, add support for a new version of WOWLAN_CONFIG_CMD Signed-off-by: NEliad Peller <eliad@wizery.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-