- 10 3月, 2016 12 次提交
-
-
由 Johannes Berg 提交于
The firmware/hardware only supports checking AES-CMAC on RX, not using it on TX. For station mode this is fine, since it's the only thing it will ever do. For AP mode, it never receives such frames, but must be able to transmit them. This is currently broken since we try to enable them for hardware crypto (for RX only) and then treat them as TX_CMD_SEC_EXT, leading to FIFO underruns during TX so the frames never go out to the air. To fix this, simply use software on TX in AP (and IBSS) mode. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
Newer firmware versions put different data in the memory which is read by the driver upon firmware crash. Just change the variable names in the code and the name of the data in the log that we print withouth any functional change. On older firmware, there will be a mismatch between the names that are printed and the content itself, but that's harmless. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Gregory Greenman 提交于
When trying to reach high Rx throughput of more than 500Mbps on a device with a relatively weak CPU (Atom x5-Z8500), CPU utilization may become a bottleneck. Analysis showed that we are looping in iwl_pcie_rx_handle for very long periods which led to starvation of other threads (iwl_pcie_rx_handle runs with _bh disabled). We were handling Rx and allocating new buffers and the new buffers were ready quickly enough to be available before we had finished handling all the buffers available in the hardware. As a consequence, we called iwl_pcie_rxq_restock to refill the hardware with the new buffers, and start again handling new buffers without exiting the function. Since we read the hardware pointer again when we goto restart, new buffers were handled immediately instead of exiting the function. This patch avoids refilling RBs inside rx handling loop, unless an emergency situation is reached. It also doesn't read the hardware pointer again unless we are in an emergency (unlikely) case. This significantly reduce the maximal time we spend in iwl_pcie_rx_handle with _bh disabled. Signed-off-by: NGregory Greenman <gregory.greenman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Chaya Rachel Ivgi 提交于
iwl_mvm_tcool_get_cur_state is the function that returns the cooling state index to the sysfs handler. This function returns mvm->cooling_dev.cur_state but that variable was set to the budget and not the cooling state index. Fix that. Add a missing blank line while at it. Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
mac80211 advertises this feature for all its drivers. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
We need to track the next packet that we will reclaim in order to know when the Tx queues are empty. This is useful when we open or tear down an A-MPDU session which requires to switch queue. The next packet being reclaimed is identified by its WiFi sequence number and this is relevant only when we use QoS. QoS NDPs do have a TID but have a meaningless sequence number. The spec mandates the receiver to ignore the sequence number in this case, allowing the transmitter to put any sequence number. Our implementation leaves it 0. When we reclaim a QoS NDP, we can't update the next_relcaim counter since the sequence number of the QoS NDP itself is invalid. We used to update the next_reclaim based on the sequence number of the QoS NDP which reset it to 1 (0 + 1) and because of this, we never knew when the queue got empty. This had to sad consequence to stuck the A-MPDU state machine in a transient state. To fix this, don't update next_reclaim when we reclaim a QoS NDP. Alesya saw this bug when testing u-APSD. Because the A-MPDU state machine was stuck in EMPTYING_DELBA, we updated mac80211 that we still have frames for that station when it got back to sleep. mac80211 then wrongly set the TIM bit in the beacon and requested to release non-existent frames from the A-MPDU queue. This led to a situation where the client was trying to poll frames but we had no frames to send. Reported-by: NAlesya Shapira <alesya.shapira@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
From 9000 family on, we need to get HW address from host CSR registers. OEM can override it by fusing the override registers - read those first, and if those are 0 - read the OTP registers instead. In addition - bail out if no valid mac address is present. Make it shared for all NICs. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
We kick the allocator when we have 2 RBDs that don't have attached RBs, and the allocator allocates 8 RBs meaning that it needs another 6 RBDs to attach the RBs to. The design is that allocator should always have enough RBDs to fulfill requests, so we give in advance 6 RBDs to the allocator so that when it is kicked, it gets additional 2 RBDs and has enough RBDs. These RBDs were taken from the Rx queue itself, meaning that each Rx queue didn't have the maximal number of RBDs, but MAX - 6. Change initial number of RBDs in the system to include both queue size and allocator reserves. Note the multi-queue is always 511 instead of 512 to avoid a full queue since we cannot detect this state easily enough in the 9000 arch. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Chaya Rachel Ivgi 提交于
When running async rx handler the framework holds the mvm->mutex before starting the async handler, that might cause a deadlock in case the handler calls to ops that lock the mutex as well. Add support for running async rx handler without hold the mutex before activating the handler. Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Matti Gottlieb 提交于
Currently when the FW sends start/stop aux roc time event notification with an error status, the driver returns an error value, but does not remove the time event, and does not notify the stack above that the time event is over. This causes problems that the stack above assumes we are still in the middle of a time event, and therefore can block different events, such as scanning. On FW failure notification, cleanup the time event parameters and notify the stack above that the time event is over. Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
Our hardware de-aggregates AMSDUs but copies the mac header as it to the de-aggregated MPDUs. We need to turn off the AMSDU bit in the QoS control ourselves. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Chaya Rachel Ivgi 提交于
Add debugfs entries to get the ctdp budget average and to stop ctdp. Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 07 3月, 2016 8 次提交
-
-
由 Sara Sharon 提交于
Before authentication, we start a time event during which we wait for a beacon in order to sync our timers. If we didn't hear the beacon during this time - we abandon the connection. However, in congested environment, it was observed we might not hear beacons in that time slot. Extend the time event to give the connection a better chance. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
The amsdu enum values are off by 1 bit. Fix it. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Chaya Rachel Ivgi 提交于
The call to iwl_mvm_thermal_initialize() was too early in the function. Unregister will be performed when goto out_unregister is called, but as the code was - out_free may be called and leave without unregistering from thermal. Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
It makes it slightly easier to follow. Pass the pointer to the transport which allows to read WFMP_MAC_ADDR_X register only when needed and to use IWL_ERR instead of the less commonly used IWL_ERR_DEV logger macro. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
Thermal zone device registration can fail, and in this case we don't want to remove WiFi functionality. This is why the thermal zone registration function is void, and the flows continue even if the thermal zone device registration failed. Same applies for the cooling device. This means that we at least need to remember that the thermal zone device didn't register properly and take the minimal precautions to avoid panic'ing when we access it. This was missing. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
128 byte chunk size is supported only on PCIe and not on IOSF. For now, change it back to 64 byte. Reported-by: NOren Givon <oren.givon@intel.com> Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
Change the code to move rxbs directly from the allocator's list to the queue's free list. This makes the code more readable, saves the interim array and the double loop over the free RBs. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luca Coelho 提交于
The pci driver keeps any unbound device in active state and forbids runtime PM. When our driver gets probed, we take control of the state. When the device is released (i.e. during unbind or module removal), we should return the state to what it was before. To do so, we need to forbid RTPM in the driver remove op. Additionally, remove an unnecessary pm_runtime_disable() call, move the initial ref_count setting to a better place and add some comments explaining what is going on. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 02 3月, 2016 8 次提交
-
-
由 Emmanuel Grumbach 提交于
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Liad Kaufman 提交于
Add a wrapper function to allow stopping SW queues from MVM as well. Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luca Coelho 提交于
If d0i3 is supported, we have released the initial transport reference in iwl_op_mode_mvm_start(), so we should take it back in iwl_op_mode_mvm_stop() to keep it balanced. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Andrei Otcheretianski 提交于
Add module parameter that disables VHT capabilities. Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luca Coelho 提交于
If d0i3 is not supported by the firmware (or if it's disabled via module parameters) we shouldn't release the initial transport reference, so that we won't enter runtime suspend. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Liad Kaufman 提交于
Do not allow entrance into DQA flows until feature is completely ready and merged. Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
In 9000 series A0 step the closed_rb_num is not wrapping around properly. The queue is wrapping around as it should, so we can W/A it by wrapping the closed_rb_num in the driver. While at it, extend RX logging and add error handling of other cases HW values may cause us to access invalid memory locations. Add also a proper masking of vid value read from HW - this should not have actual affect, but better to be on the safe side. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Chaya Rachel Ivgi 提交于
Leaving ucode_loaded to true after stop_device() has been called is a recipe for problems. Flows that are not sync'ed with the driver life cycle (like debugfs hooks and thermal hooks) must check that the firmware is loaded before they interact with it. Therefore we need to keep this variable updated with the real status of the firmware. Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 29 2月, 2016 2 次提交
-
-
由 Golan Ben-Ami 提交于
Till today, the ucode consisted of two d0 images - regular, in which the usniffer wasn't enabled, and usniffer, in which the usniffer logs were enabled. Lately, the two images were unified, so there is only one d0 image, in which the usniffer logs are enabled. Add new TLV capability for supporting the consolidated images (set 2, bit 13). Signed-off-by: NGolan Ben-Ami <golan.ben.ami@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Matti Gottlieb 提交于
Currently when entering D3 with WOWLAN configured, we enable in the configuration flags beacon storing, and do not disable beacon filtering, and do not wake up from a magic packet. Having both enabled is wrong (should not have both enabled), and causes problems in the RX queues in the FW, causing the FW not to recognize the magic packet when it comes. Disable beacon storing in wowlan configuration. Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 28 2月, 2016 10 次提交
-
-
由 Emmanuel Grumbach 提交于
iwl_mvm_enable_agg_txq has only one user. Kill it and adapt the call site. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
To ensure that the SNAP/TCP/IP headers are DW aligned, the firmware may add 2-byte pad at the end of the mac header - after the IV, before the SNAP. In that case the mpdu descriptor pad bit will be turned on. Driver should take it into consideration, and remove the padding before passing the packet to mac80211. Do that. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Avri Altman 提交于
Beacon abort (ba) is set while sending power command, but only after at least one beacon_filter command was successfully sent. If we heard a beacon before starting association, this order is maintained and ba is properly set. However, if the first beacon is received after association, we send the power command upon association, configure the beacon filtering when the first beacon arrives, and in that case, beacon abort is not set. So identify this, and send a power command post the beacon_filter command if needed. Signed-off-by: NAvri Altman <avri.altman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Avri Altman 提交于
Older versions of the firmware don't support U-APSD for P2P Client. Forbid U-APSD for P2P Client when an old firmware is being used. Signed-off-by: NAvri Altman <avri.altman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Beni Lev 提交于
Allow to publish RRM capabilities without the need to support a minimal capability set. Since some RRM features(e.g. neighbor report) are fw independent, set this capability unconditionally. Signed-off-by: NBeni Lev <beni.lev@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
* Remove uneeded includes: iwl-csr.h and devcoredump aren't used in mac80211.c. * Remove uneeded empty line Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
When the device is in d0i3/d3 we will not receive the VHT MU-MIMO group id management frame. Instead, firmware will notify us upon exit on the current status and we can in turn update mac80211. Support this notification. While at it, also check as a precaution that the vif is indeed the VHT MU-MIMO owner before updating the firmware. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
Commit 69c7fda4 removed the users of iwl_mvm_tid_data.reduced_tpc. Due to a conflict, I forgot to commit the hunk that removed the field itself. Do this know. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
In multi rx queue HW, without execessive locking, there is no sync between the ctrl path (default queue) and the rest of the rx queues. This might cause issues on certain situations. For example, in case a delBA was processed on a default queue but out of order packets still wait for processing on the other queue. The solution is to introduce internal messaging between the CTRL path and the other rx queues. The driver will send a message to the firmware, which will echo it to all the requested queues. The message will be in order inside the queue. This way we can avoid CTRL path and RSS queues races. Add support for this messaging mechanism. As the firmware is agnostic to the data sent, add internal representation of the data as well. Although currently only delBA flow will use it, the internal representation will enable generic use of this infrastructure for future uses. Next patch will utilize this messaging mechanism for the reorder buffer delBA flow. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Sara Sharon 提交于
Next hardware will direct TCP/UDP streams to different cores. Packets belonging to the same stream will be directed to the same core. The result is that duplicates will be always directed to the same rx queue were the first packet was received. This enabled parallelizing the duplicate packet detection across the different cores, without sharing data between the rx queues. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-