- 31 3月, 2010 2 次提交
-
-
由 Shanyu Zhao 提交于
Previously in interrupt handling tasklet, iwlwifi driver only clear/ack those interrupts that are enabled by the driver through inta_mask. If the hardware generates unattended interrupts, driver will not ack them, defeating the interrupt coalescing feature. This results in high number of interrupts per second and high CPU utilization. This patch addresses this issue by acking those unattended interrupts in the tasklet. Local test showed an order of magnitude improvement in terms of the number of interrupts without sacrificing networking throughput. This is a workaround for hardware issue. Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Reinette Chatre 提交于
Commit "cfg80211: convert bools into flags" mistakenly modified iwlwifi's regulatory settings instead of just converting it. Fix this. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2172Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> CC: stable@kernel.org
-
- 10 3月, 2010 1 次提交
-
-
由 Reinette Chatre 提交于
This reverts commit 21b2d8bd. As explained by Johannes: When we build a probe request frame in the buffer with the SSID, we could arrive over the limit of 200 bytes. When we build it in the buffer without the SSID (wildcard) we don't arrive over 200 bytes, but the ucode still allows direct probe in addition because it has an internal buffer that is larger when it inserts the SSID... Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
- 03 3月, 2010 1 次提交
-
-
由 Johannes Berg 提交于
At the wireless summit in Portland we discussed a way of loading firmware asynchronously from ->probe() before registration to mac80211, in order to register with the wireless subsystems with complete information in cases where firmware is required to know parameters. This is not yet the case in iwlwifi, but for some new features we're working on it will be the case since those will only be supported by new firmware images. Hence, to start with, convert iwlwifi to load firmware asynchronously from probe, unbinding the device when firmware loading fails, and only registering with the wireless subsystems after firmware has been loaded successfully. Future patches will hook into this to register the new firmware capabilities, depending on the firmware API version. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 24 2月, 2010 1 次提交
-
-
由 Reinette Chatre 提交于
This reverts commit 1db5950f. The goal of "iwlwifi: Monitor and recover the aggregation TX flow failure" is to first detect when data transmission stalls and then to recover from this situation with a reset of the radio or the firmware, depending on how bad the transmission failures are. Unfortunately we have found that this change causes excessive resets with its current detection algorithm. It also performs its recovery action when none is really needed, like when we are not associated. Revert this change until the issues have been addressed. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
- 20 2月, 2010 2 次提交
-
-
由 Wey-Yi Guy 提交于
Use different timing duration check for different type of force reset, force reset request can come from different source and based on different reason; one type of reset request should not block other type of reset request. Adding structure to keep track of different force reset request. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Until now it was only possible to have one synchronous command running at any time. If a synchronous command is in progress when a second request arrives then the second command will fail. Create a new mutex specific for this purpose to only allow one synchronous command at a time, but enable other commands to wait instead of fail if a synchronous command is in progress. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 2月, 2010 2 次提交
-
-
由 Trieu 'Andrew' Nguyen 提交于
This change monitors the tx statistics to detect the drop in throughput. When the throughput drops, the ratio of the actual_ack_count and the expected_ ack_count also drops. At the same time, the aggregated ba_timeout (the number of ba timeout retries) also rises. If the actual_ack_count/expected_ack_count ratio is 0 and the number of ba timeout retries rises to 16, no tx packets (tcp, udp, or ping - icmp) can be delivered. The driver recovers from this situation by reseting the uCode firmware. If the actual_ack_count/expected_ ack_count ratio drops below 50% (but not 0) and the aggregated ba_timeout retries just exceed 5 (but not 16), then the driver can reset the radio to bring the throughput up. Signed-off-by: NTrieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Reinette Chatre 提交于
To ensure that card is in a sane state during probe we add a reset call. This change was prompted by users of kdump who was not able to bring up the wireless driver in the kdump kernel. The problem here was that the primary kernel, which is not running at the time, left the wireless card up and running. When the kdump kernel starts it is thus possible to immediately receive interrupts from firmware after registering interrupt, but without being ready to deal with interrupts from firmware yet. Reported-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
- 09 2月, 2010 2 次提交
-
-
由 Kalle Valo 提交于
get_tx_stats() will be removed from mac80211. Compile-tested only. Cc: Zhu Yi <yi.zhu@intel.com> Signed-off-by: NKalle Valo <kalle.valo@iki.fi> Acked-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Samuel Ortiz 提交于
When running directed active scans we currently end up sending both the SSID probe requests and an additional broadcast one. This is due to the fact that we always leave the probe request template SSID IE length to 0. Instead we should set it to the first SSID to scan, and fill the direct_scan array with the remaining SSIDs to scan for. This way we only send what we've been asked to: a broadcast probe request when no directed scan is requested, and directed probe requests otherwise. Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 1月, 2010 3 次提交
-
-
由 Johannes Berg 提交于
There's no need to queue a work struct from within a work struct, just move the code to execute directly. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
Change in uCode to include a unique identifier as part of sysassert, in order to tell the difference, add the "ADVANCED SYSASSERT" description when dump nic error to indicate the difference. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Daniel Halperin 提交于
In hostap AP mode, every time the client sends the AP a packet the STA_NOTIFY_AWAKE code is sent from mac80211. This results in a command being sent to the uCode even if the client was not asleep. The following simple patch has fixed the issue for me without any degradation that I can find. Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
- 26 1月, 2010 5 次提交
-
-
由 Reinette Chatre 提交于
In iwlagn the support for spectrum measurement command has been disabled since v2.6.29 without any requests for it. In addition to this when this command is indeed enabled it has been found to trigger firmware SYSASSERT on at least 4965 and 5100 hardware (see http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1952 ). Since then this code has been bitrotting and cannot just be enabled without porting. Remove support for spectrum measurement command from iwlagn. It can be added back if there is a future need and the firmware problem it triggers has been fixed. Support for the spectrim measurement notification remains as it has been enabled all the time. In addition to this remove the 3945 spectrum measurement command Kconfig option and make this command always supported. The code added by this enabling is minimal and only run when user triggers a spectrum measurement request via sysfs. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
sparse correctly warns about symbol not being static, make static to shut it up. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
It is better to first notify cfg80211 about the hw rfkill state (so the rfkill device that will be registered won't have the wrong state while being registered), and the power/tt variable init can (and probably should) also be done first. Also rename iwl_setup_mac to iwl_mac_setup_register to better describe what it really does. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Add function pointer for broadcast station addition so that we can call it in from iwlcore at a later time. We only distinguish between iwlagn and iwl3945 broadcast station addition. For the iwl3945 station addition we add that function to iwlcore since that is where most station functionality resides, making it part of iwl3945 will require significant code reorganization that will dilute station management functionality. This seems to be an efficient solution. It may seem as though we are removing error checking when adding the 3945 broadcast station but this error checking was never really necessary since the function returns the station id and the broadcast station id is always set. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Add support to configure missed beacon threshold, by default, if receive "missed beacon" notification from uCode and has more than 5 consecutive beacon missed, then perform sensitivity calibration; with this change, allow user to adjust the missed beacon threshold from debugfs in case more sensitivity calibration required for better performance in noisy environment The default value (=5) should be good enough for the normal condition, but for very noisy environment, more sensitivity calibration could help improve the throughput, so by setting the missed beacon threshold to lower number, user might experience better performance result. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 1月, 2010 1 次提交
-
-
由 Johannes Berg 提交于
When a TKIP key is updated, we should pass the station pointer instead of just the address, since drivers can use that to store their own data. We also need to pass the virtual interface pointer. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 1月, 2010 2 次提交
-
-
由 Reinette Chatre 提交于
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
When dumping event log in debugfs, iwl_dump_nic_event_log() should return the correct error code instead of let the calling function makes it own assumption. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Wey-Yi Guy 提交于
mac80211 do not check the return code now, what if mac80211 does start using the return code? IEEE80211_AMPDU_TX_OPERATIONAL is a valid action, just iwlwifi driver do not need to take any action for it; so instead of return "-EINVAL", it is a good program practice to return "-EOPNOTSUPP" to make sure mac80211 will not get wrong impression. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 1月, 2010 1 次提交
-
-
由 Alexey Dobriyan 提交于
Use DEFINE_PCI_DEVICE_TABLE() so we get place PCI ids table into correct section in every case. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 23 12月, 2009 1 次提交
-
-
由 Johannes Berg 提交于
Instead of hard-coding the SM PS mode per hardware, this makes iwlwifi support the new mac80211 API for controlling the SM PS mode. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 12月, 2009 5 次提交
-
-
由 Wey-Yi Guy 提交于
This feature enables the on-screen uCode event log dump. The original method will append the event log to syslog; with this capability, we also enable the user to write script to capture the events which provide additional flexibility to help uCode debugging Method 1) change to debugfs directory (sys/kernel/debug/phyX/iwlagn/data) 2) #cat log_event Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
In order to help uCode debugging, adding the capability to provide continuous uCode event logging function. uCode events is located in round-robin event queue and filled by uCode, by enable continuous event logging, driver check the write pointer and log the newly added events in iwl_bg_ucode_trace() timer function. There is still possibility of missing events if event queue being wrapped before next event dump; but with this capability, we can have much better understanding of the uCode behavior during runtime; it can help to debug the uCode related issues. Methods to enable/disable the continuous event log: step 1: enable ucode trace timer "echo 1 > /sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing" step 2: start ftrace sudo ./trace-cmd record -e iwlwifi_ucode:* sleep 1d step 3: stop ftrace sudo ./trace-cmd report trace.dat step 4: disable ucode trace timer "echo 0 > /sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing" use "ucode_tracing" debugfs file to display number of event queue wrapped when driver attempt the continuous event logging. If event queue being wrapped more than once when driver has opportunity to log the event; it indicated there are events missing in the event log trace. This continuous event log function only available for 4965 and newer NICs. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Change name from RF_CARD_DISABLED to CT_CARD_DISABLED to match the indication from uCode, also log the debug message when the condition detected in iwl_rx_card_state_notif() Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Recent powersaving work resulted in power management ops being called during EEPROM initialization. The lock used by these functions is not initialized at this time. Ensure lock is initialized before it is used. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
When trigger event log dumping from debugfs, the entire event log should be dumped and the size should match the number of events being dump. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 12月, 2009 1 次提交
-
-
由 Wey-Yi Guy 提交于
error_event_table_ptr is only set upon receipt of REPLY_ALIVE. Until then both event log and error log will fail. Add information to indicate which uCode encounter the failure case. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 24 11月, 2009 6 次提交
-
-
由 Wey-Yi Guy 提交于
To help iwlagn uCode debugging, event log will dump to syslog when driver detect uCode error occurred, but this only happen when compile with CONFIG_IWLWIFI_DEBUG and debug flag is enabled; which is not always the case. Also, there is another problem, if the flag is set, the entire event log buffer will be dump to syslog, it can flood the syslog and make it very difficult to debug the problem. Change the default to only dump last 20 entries of event log to syslog unless the following condition meets: 1. both compile with CONFIG_IWLWIFI_DEBUG and debug flag is enabled, and then dump the entire event buffer to syslog. 2. dump event log request from debugfs Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Acked-by: NBen Cahill <ben.m.cahill@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
uCode error log contain information as to what the error was and where it occurred necessary to debug any uCode issues. Always log the information without special debug flag, this can help to capture the important information when error happened. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Acked-by: NBen Cahill <ben.m.cahill@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Update the PCI_ID list for 5xx0 series. Remove all the PCI_IDs which never made into production or not longer in production. Also make sure the supported bands(a/b/g/n) match specified PCI_IDs Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Setting "Spatial multiplexing Power Save" as part of per device configuration parameter. Report to uCode based on priv->conf setting, so driver can have more control of how different devices should operate in power save mode. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
LED blinking rate is based on tx/rx traffic, the most reasonable place to do it is after update the traffic byte counts This fixes the recent LED blinking breakage on 3945 introduced by "iwlwifi: separate led function from statistic notification" Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ben Cahill 提交于
CSR_INT_COALESCING previously had only one, but now has two single-byte fields. With only one single-byte field (lowest order byte) it was okay to write via iwl_write32(), but now with two, an iwl_write32() to the lower order field clobbers the other field (odd-address CSR_INT_PERIODIC_REG, offset 0x5), and an iwl_write32() to CSR_INT_PERIODIC_REG could clobber the lowest byte of the next-higher register (CSR_INT, offset 0x8). Fortunately, no bad side effects have been produced by the iwl_write32() usage, due to order of execution (low order byte was always written before higher order byte), and the fact that writing "0" to the low byte of the next higher register has no effect (only action is when writing "1"s). Nonetheless, this cleans up the accesses so no bad side effects might occur in the future, if execution order changes, or more bit fields get added to CSR_INT_COALESCING. Add some comments regarding periodic interrupt usage. Signed-off-by: NBen Cahill <ben.m.cahill@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 11月, 2009 1 次提交
-
-
由 Johannes Berg 提交于
We've accumulated a number of options for wiphys which make more sense as flags as we keep adding more. Convert the existing ones. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 19 11月, 2009 2 次提交
-
-
由 Johannes Berg 提交于
The entire aggregation code currently operates on the hw pointer and station addresses, but that needs to change to make stations purely per-vif; As one step preparing for that make the aggregation code callable with the station, or by the combination of virtual interface and station address. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Using the new mac80211 functionality, this makes iwlwifi handle unicast PS buffering correctly. The device works like this: * when a station goes to sleep, the microcode notices this and marks the station as asleep * when the station is marked asleep, the microcode refuses to transmit to the station and rejects all frames queued to it with the failure status code TX_STATUS_FAIL_DEST_PS (a previous patch handled this correctly) * when we need to send frames to the station _although_ it is asleep, we need to tell the ucode how many, and this is asynchronous with sending so we cannot just send the frames, we need to wait for all other frames to be flushed, and then update the counter before sending out the poll response frames. This is handled partially in the driver and partially in mac80211. In order to do all this correctly, we need to * keep track of how many frames are pending for each associated client station (avoid doing it for other stations to avoid the atomic ops) * tell mac80211 that we driver-block the PS status while there are still frames pending on the queues, and once they are all rejected (due to the dest sta being in PS) unblock mac80211 Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-