- 25 Jun, 2012 4 commits
-
-
Johannes Berg authored
The dwell time for scanning is currently limited so that it fits into the timings inside the ucode when that is tracking DTIM/beacon periods for the AP(s) it's connected to. However, when it's connected to two APs, those may be in lockstep, for example if they both have a DTIM interval of 100 TU, then one could be 50 TU after the other, leaving only 50 TU free to be used by scanning. Since we can't know how far apart they are the only option is to restrict to 1/2 of the minium of the two APs. In theory, it would be possible to not use 1/2 of the minimum but take into account that if they have different intervals then there will be a bit more time since they can't be in lockstep, but as they will have 100 TU intervals in practice that complex calculation will probably just result in hard-to-find bugs. Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
__get_str() is identical to (char *)__get_dynamic_array() that is in the code now, substitute __get_str to make the code more readable. Reviewed-by:
-
Johannes Berg authored
There's one message that goes just over the limit of 100 characters, so bump the limit to 110 to get rid of the warning from that. Reviewed-by:
-
Emmanuel Grumbach authored
Since the op_mode defines the queue mapping, let it do it completely through the API functions. Signed-off-by:
-
- 21 Jun, 2012 3 commits
-
-
Johannes Berg authored
Currently when mac80211 asks to change the interface type, we will accept it for both the BSS and PAN contexts. This is not terribly complicated today, but with the addition of the P2P Device abstraction the PAN context handling will get more complex, so restrict mac_change_interface to the BSS context. Also fix a small locking issue and use is_active instead of the vif pointer to check if the other context is activated, guarding exclusive interface types on the BSS context (IBSS) against the PAN context being used for something else. Reviewed-by:
-
Johannes Berg authored
When the first interface is active, then scanning on it or the second interface can take a little longer than 7s (I observed around 8s.) Bump the timeout to 15s to avoid aborting a scan that is still running, just taking more time. Reviewed-by:
-
Johannes Berg authored
My previous commit to shorten the radio reset time caused issues as the firmware checks the active dwell time against the quiet time, asserting that the dwell is >= quiet time. This isn't really needed in case of passive scanning like here, but of course we need to pass that check. To fix this, override the quiet time to be the same as the radio reset dwell time. Reviewed-by:
-
- 20 Jun, 2012 3 commits
-
-
Johannes Berg authored
Now that the eeprom parsing code overrides the sku field directly with 11n_disable parameters, there's no longer a need to keep a copy of this field. Reviewed-by:
-
Johannes Berg authored
The effect of using a short single-channel scan to reset the radio is that scanning a channel that isn't in use needs to re-tune the radio. This means that the dwell time is irrelevant, so use a shorter time. While at it, clean up the code for this a bit. Reviewed-by:
-
Johannes Berg authored
My commit 26a7ca9a ("iwlwifi: refactor EEPROM reading/parsing") broke the 11n_disable module parameter's BIT(0) to disable all HT operation (using the other bits to disable aggregation only was unaffected). Restore this by overriding the SKU when parsing the EEPROM if the module parameter is set. Reported-by:
Matthijs Kooijman <matthijs@stdin.nl> Reviewed-by:
-
- 18 Jun, 2012 9 commits
-
-
Johannes Berg authored
When the device is doing an internal radio reset scan, ROC can be rejected to the supplicant with busy status which confuses it. One option would be to queue the ROC and handle it later, but since the radio reset scan is very quick we can just wait for it to finish instead. Also add a warning since we shouldn't run into the case of having a scan active when requesting a ROC in any other case since mac80211 will not scan while ROC or ROC while scanning. Reviewed-by:
-
Emmanuel Grumbach authored
This feature needs to be disabled for all NICs. Signed-off-by:
-
Emmanuel Grumbach authored
This variable was accessed without taking the lock. Signed-off-by:
-
Emmanuel Grumbach authored
This is really not needed, we already have a lock inside the accesses to the prph. Signed-off-by:
-
Emmanuel Grumbach authored
This is not needed since notif_wait_lock is never accessed from IRQ. Signed-off-by:
-
Emmanuel Grumbach authored
This is required by the op_mode API. Signed-off-by:
-
Emmanuel Grumbach authored
A few op_mode of the op_mode API functions have requirements on the running context of the caller. Document that. Signed-off-by:
-
Emmanuel Grumbach authored
Signed-off-by:
-
Emmanuel Grumbach authored
Signed-off-by:
-
- 13 Jun, 2012 16 commits
-
-
Emmanuel Grumbach authored
This flow can actually happen due to a corner case in mac80211: the station is deleted before we get a chance to reclaim all the packets in flight in AGG queue. The tid_data for this station is zeroed, and we lose the match with the Tx queue. Signed-off-by:
-
Johannes Berg authored
Since request_module_nowait() can't be backported use request_module() instead -- we don't need the asynchronous behaviour of request_module_nowait() here since we're running in the firmware request work struct. Tested-by:
Donald H Fry <donald.h.fry@intel.com> Reviewed-by:
-
Johannes Berg authored
Due to commit 26a7ca9a ("iwlwifi: refactor EEPROM reading/parsing") adding a new parameter, while commit d2c8b15d ("iwlwifi: use correct supported firmware for 6035 and 6000g2") added a new device structure we need to add the parameter to the new device structure to make 6035 device work. Signed-off-by:
-
Johannes Berg authored
-
Emmanuel Grumbach authored
For AGG queues, we must match between the WiFi sequence number and the TFD number. This is a HW (SCD) requirement. This is a take two of my iwlwifi: add debug in Tx path in AGG flow This will allow us to catch bad cases in which the packets aren't in the right place on the ring. which disappeared during code move. Signed-off-by: -
Emmanuel Grumbach authored
In fragmentation we don't update the write pointer of the HW immediately. So we shouldn't modify the timer in that case. Signed-off-by:
-
Dan Carpenter authored
CMD_SYNC is zero so the if (cmd->flags & CMD_SYNC) is never true and we never check the assertion. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Emmanuel Grumbach authored
Since the queue gets stuck from time to time, we are trying to get as much information as we can when this occurs. Signed-off-by:
-
Brandon Misemer authored
When the driver is built into the kernel instead of a module when the system boots it results in a panic. The order things are built in results in their initialization order when built into the kernel. Wifi has to be initialized before mvm or dvm. Reviewed-by:
Brandon Misemer <brandon.misemer@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
Using the driver_data area in ieee80211_tx_info which resides in the CB overrides the info->control field. Add a comment to prevent mistakes. Signed-off-by:
-
Emmanuel Grumbach authored
This locking isn't needed. The only locking we need is when we access prph registers but there is already a separate lock for that. Since we haven't returned from the mac80211's IEEE80211_AMPDU_TX_OPERATIONAL ampdu_action, we cannot receive any Tx frame for that sta / tid while enabling the queue. Signed-off-by:
-
Emmanuel Grumbach authored
This is not needed, we just need to tell the SCD not to use that queue. We will reconfigure that queue when we will use it again. Clean up a bit the code on the way. Signed-off-by:
-
Emmanuel Grumbach authored
Print some more info from the SCD's SRAM and dump the TRB from the FH. Signed-off-by:
-
Emmanuel Grumbach authored
Change its name to better reflect this. Signed-off-by:
-
Emmanuel Grumbach authored
This macro gets the bufsize in bytes. Signed-off-by:
-
Johannes Berg authored
Add locking to the dynamic loading code to prevent corrupting the list if multiple device ever init at the same time (which cannot happen for multiple PCI devices, but could happen when different busses init concurrently.) Also remove a device from the list when it stops so the list isn't left corrupted, including a fix from Don to not crash when it was never added. Reviewed-by:
-
- 12 Jun, 2012 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessJohn W. Linville authored
Conflicts: MAINTAINERS drivers/net/wireless/iwlwifi/pcie/trans.c
-
- 11 Jun, 2012 4 commits
-
-
Jonas Gorski authored
14e4:432c is found on some bcm63xx devices. The device is working fine with b43. Reported-by:
Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
MSI is enabled by default for most of the 4th generation chips. Add this for AR9462 - this fixes PowerSave operation, the chip was not entering Network-Sleep mode earlier. With proper powering down of the MAC now, power consumption in associated state is reduced considerably. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Amitkumar Karwar authored
Currently 4 channels are scanned per scan command. if scan request is issued by user during Tx traffic, radio will be out of channel for "4 * per_chan_scan_time" for each scan command and will not be able to receive Rx packets. This adds delay in data traffic. We can minimize it by reducing number of channels scanned per scan command in this scenario. We can not always scan 1 channel per scan command due to limitation of number of command buffers. So we add code to decide number of channels scanned per scan command in associated state. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
If scan operation is started when Tx traffic is already running, driver locks Tx queue until it gets completed. With this logic there is a delay for Tx packets. This patch implements new approach to give Tx path higher priority in this case. Driver internally sends multiple synchronous scan commands to firmware when scan is requested by user. Now we will make sure that Tx queue is empty everytime before sending next scan command. If Tx queue isn't empty scan command will be postponsed by 20msec. This rule will be followed until Tx queue becomes empty or timeout of 1 second happens. In case of timeout scan operation will be aborted. Signed-off-by:
-
