- 20 Jun, 2012 2 commits
-
-
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:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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 9 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:
-
Bing Zhao authored
Currently the scan time per channel for active scanning is set to 200ms. It takes quite a while to finsh scanning on all channels, especially with a dual band configuration. Change the per channel scan time settings to the following values: passive scan: 110ms active scan: 30ms specific scan: 30ms Above settings have been tested on x86 and arm platforms. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-nextJohn W. Linville authored
Conflicts: drivers/net/wireless/iwlwifi/iwl-eeprom.c
-
-
Ilan Peer authored
The iwl-test flows were based on the cfg80211 testmode APIs. To remove this coupling, the op mode (during the initialization of the iwl_test object) is responsible to set the callbacks that should be used by iwl-test to allocate skbs for events and replies and to send events and replies. The current op modes implement these callbacks based on the cfg80211 testmode APIs. Reviewed-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Ilan Peer authored
Create an object that will enacpsulate the testmode functionality that is common to all op modes. * Copy definitions from dvm/dev.h * Copy the testmode logic from dvm/testmode.c * Link iwl-test object into the iwlwifi module * Modify DVM to use iwl-test object Reviewed-by:
Amit Beka <amit.beka@intel.com> Reviewed-by:
-
- 08 Jun, 2012 3 commits
-
-
John W. Linville authored
CC drivers/net/wireless/ti/wl18xx/main.o drivers/net/wireless/ti/wl18xx/main.c: In function ‘wl18xx_conf_init’: drivers/net/wireless/ti/wl18xx/main.c:1024:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat] drivers/net/wireless/ti/wl18xx/main.c:1024:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Wformat] Signed-off-by: -
Stanislaw Gruszka authored
commit 24398e39 Author: Johannes Berg <johannes.berg@intel.com> Date: Wed Mar 28 10:58:36 2012 +0200 mac80211: set HT channel before association removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config, which is required by iwl4965 driver, otherwise that driver does not configure channel properly and is not able to associate. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Sasha Levin authored
llcp_sock_getname() might get called before the LLCP socket was created. This condition isn't checked, and llcp_sock_getname will simply deref a NULL ptr in that case. This exists starting with d646960f ("NFC: Initial LLCP support"). Signed-off-by:
Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
-
