An error occurred fetching the project authors.
- 07 Oct, 2010 3 commits
-
-
Johannes Berg authored
A number of exports, especially related to thermal throttling, are unnecessary because the code lives in the same module that it is used in, so remove them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Rename iwl_mac_beacon_update to iwlcore_beacon_update and make the calling convention a bit different. The old name with _mac_ indicated that it was a mac80211 callback, but that's no longer true. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
The core module doesn't need to carry around the code for chain settings that is used for HT drivers (agn) only. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 06 Oct, 2010 2 commits
-
-
Stanislaw Gruszka authored
This reverts commit 7acc7c68. It was applied to avoid possible warning in ieee80211_restart_hw, however reason of the warning were races in mac80211, currently hopefully fixed. Not reseting device when performing scan is bad for two reasons. When forcing reset from iwl_check_stuck_queue(), in case of fail, reset will be repeated until scan finish. But since firmware is in bad shape, scan only finish after scan_check work (about 7s). So we will delay the reset, what is not good behaviour. When forcing reset from iwl_recover_from_statistics(), we will not repeat the reset, so we will not perform reset at all when needed. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
move paramater definitions to a device paramater structure only leaving the device name, which antennas are used and what firmware file to use in the iwl_cfg structure. this will not completely remove the redundancies but greatly reduce them for devices that only vary by name or antennas. the parameters that are more likely to change within a given device family are left in iwl_cfg. also separate bt param structure added to help reduce more. Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 05 Oct, 2010 1 commit
-
-
Stanislaw Gruszka authored
We can start restarting firmware or RF kill switch can be turned on during call to iwl_mac_add_interface(). That are normal working conditions, so do not print call trace, just print simple message instead. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 17 Sep, 2010 1 commit
-
-
Wey-Yi Guy authored
When uCode error condition detected, driver try to perform either rf reset or firmware reload in order bring device back to working condition. If rf reset is required and scan is in process, there is no need to issue rf reset since scan already reset the rf. If firmware reload is required and scan is in process, skip the reload request. There is a possibility firmware reload during scan cause problem. [ 485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62() [ 485.804049] Hardware name: Latitude E6400 [ 485.804052] ieee80211_restart_hw called with hardware scan in progress [ 485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore] [ 485.804069] Pid: 812, comm: kworker/u:3 Tainted: G W 2.6.36-rc3-wl+ #74 [ 485.804072] Call Trace: [ 485.804079] [<c103019a>] warn_slowpath_common+0x60/0x75 [ 485.804084] [<c1030213>] warn_slowpath_fmt+0x26/0x2a [ 485.804089] [<c145da67>] ieee80211_restart_hw+0x28/0x62 [ 485.804102] [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn] [ 485.804108] [<c10415d5>] process_one_work+0x181/0x25c [ 485.804119] [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn] [ 485.804124] [<c104190a>] worker_thread+0xf9/0x1f2 [ 485.804128] [<c1041811>] ? worker_thread+0x0/0x1f2 [ 485.804133] [<c10451b0>] kthread+0x64/0x69 [ 485.804137] [<c104514c>] ? kthread+0x0/0x69 [ 485.804141] [<c1002df6>] kernel_thread_helper+0x6/0x10 [ 485.804145] ---[ end trace 3d4ebdc02d524bbb ]--- [ 485.804148] WG> 1 [ 485.804153] Pid: 812, comm: kworker/u:3 Tainted: G W 2.6.36-rc3-wl+ #74 [ 485.804156] Call Trace: [ 485.804161] [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62 [ 485.804172] [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn] [ 485.804177] [<c10415d5>] process_one_work+0x181/0x25c [ 485.804188] [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn] [ 485.804192] [<c104190a>] worker_thread+0xf9/0x1f2 [ 485.804197] [<c1041811>] ? worker_thread+0x0/0x1f2 [ 485.804201] [<c10451b0>] kthread+0x64/0x69 [ 485.804205] [<c104514c>] ? kthread+0x0/0x69 [ 485.804209] [<c1002df6>] kernel_thread_helper+0x6/0x10 Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 14 Sep, 2010 2 commits
-
-
Stanislaw Gruszka authored
Currently we force scan complete at the end of iwl_scan_cancel_timeout function. This cause race condition when we can get a new scan request from mac80211 and complete it by iwl_bg_complete from older scan. Change code to force scan complete only when really needed: device goes down, interface is removed or scan timeout occurs. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi W Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
If we do not get notification from hardware about scan complete, after timeout do mac80211 scan completion anyway. This assure we end scan in case of firmware hung. Patch fix one of the causes of wdev_cleanup_work warning reported at https://bugzilla.redhat.com/show_bug.cgi?id=593566Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi W Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 11 Sep, 2010 4 commits
-
-
Johannes Berg authored
The iwl_adjust_beacon_interval function is a bit of black magic, so add comments to it describing what it does. Also, in the case when there's no beacon interval set, program the default into the device (instead of adjusting, which results in the max) since using the max in that case interacts badly with dual-mode/PAN parameters. Also update the PAN parameters accordingly and use the same constant as here. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
In dual-mode, a number of scenarios need to be considered, and the firmware can be very picky about them. Adjust the timing (most importantly the beacon interval) according to the different modes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
When the PAN context is unused, there's no need to continually update it in the device. So track which contexts are active (with the special case that the WLAN context is always active ...) and only send their commands to the device when needed. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
When the beacon interval needs to be changed, all we need to do is send updated timing to the device. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 27 Aug, 2010 13 commits
-
-
Johannes Berg authored
We're now ready to start using multiple contexts. We do this by keeping track of the valid interface types per context (exclusive [ibss] and normal) and checking which context is "free" when a new interface is added. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
It is necessary that the PAN context always use the same beacon interval as the BSS context unless it is in dual-station mode, ie. the PAN context is a station as well, so implement that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Sometimes we need to send RXON timing even when we don't have a virtual interface yet, so pass the context and allow passing one without a virtual interface pointer. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
In order for the microcode to be able to handle multiple interfaces, we need to give it the PAN parameters that state how to allocate the time between the two interfaces. Do this, and update it wherever necessary. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
The PAN functionality requires us to send the timing including a valid DTIM period to the microcode before associating, so request this data from mac80211 and send it to the device. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Only one context can be beaconing at a time, but we need to track which one. Introduce a new variable priv->beacon_ctx to do that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
A lot of HT configuration semantically belongs into the context, even if right now it will never be different between contexts. Move it so we're better prepared for future changes in mac80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
iwlwifi occasionally needs to find the virtual interface pointer to give it to mac80211, but right now it only keeps one. Move it into the context so that we can keep one pointer each. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Since mac80211 doesn't currently enable/disable QoS per interface, we can't yet do it properly, but we can already prepare for it and move the QoS data and command ID into the context struct. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Some commands will have different command IDs for different contexts, so we need to store those IDs in the context structure and use them instead of hardcoding the commands. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
The broadcast station ID is per context, so add a variable for the ID in the context and use it everywhere we previously hardcoded it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
PAN ucode will require a different queue assignment, in particular queue 9 instead of 4 should be used for commands. This is required because the ucode will stop/start queues 4 and 8 depending on the PAN state, since queue 8 will be used for PAN multicast (after DTIM). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
In order to support multiple interfaces, we must move a lot of data into per-context structures so we can use the contexts the device offers. To start with, this makes a lot of code context-aware, more changes will move more things into the context structure. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 25 Aug, 2010 7 commits
-
-
Wey-Yi Guy authored
Current BT traffic load should based on the following conditions: 1. BT On/Off status 2. Channel announcement enable/disable 3. Curren traffic load report from uCode Need to modify rate scale to down-grade from MIMO to SISO if detected high BT traffic load. Also need to make sure not using chain "B" with high BT traffic or if it is in "full concurrency" mode. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
In current implementation, stuck queue timer is fixed to 1 second. Add debugfs file to modify the timer to enhance the flexibility: Set the monitor_period as following: 0: disable stuck queue force reset function 1 - 60000: monitor period (1 - 60 second) Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
Adding the bluetooth full concurrency support for WiFi/BT combo devices. Driver should configure uCode to operate in "full concurrency" mode (via LUT) if both conditions are met: - Antenna Coupling is more than 35dB - WiFi Channel Inhibition Request is hornored by BT Core Currently, there is no antenna coupling information provided by uCode; use module parameter to specified the antenna coupling in dB. When in "full concurrency" mode, driver need to download different LUT to uCode while sending bt configuration command; also, driver need to configure the device operate in 1x1 while in full concurrency mode. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When bluetooth indicated high load, we should use only antenna A in 2.4 GHz for management frames. Add this condition to iwl_toggle_tx_ant() to make sure it'll always be met. Note that scanning has a separate way of forcing the antenna, because we should scan on antenna A only regardless of BT traffic load. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
Disable plcp error checking for 6000g2b devices, with wifi/bt coex; this got trigger too often, disable for now until finding better trigger point. Also extend the firmware reload timer much longer for BT coex to make sure there are will be no mistake to reload firmware too fast and too often. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
IBSS doesn't allow for coexistence, so it should be disabled. Additionally, disable reacting to the BT profile notification when in IBSS mode, it likely won't be sent by the device to start with though. Also, in IBSS mode, BT coexistence isn't as fully-featured and we must use a single antenna only. So instead of peppering the code with new checks, simply pretend we are in high BT traffic load, which has the needed effect of disabling antenna B use. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
6000g2b hardware implements advance bluetooth coexist command, implement base on the new API command strucutre. Also increment the API 5 to support the advance BT/WIfi coex. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 24 Aug, 2010 7 commits
-
-
Wey-Yi Guy authored
iwl_send_card_state() is not being call from anywhere, remove it. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Add ampdu factor and density to .cfg, this allow both parameters can be configure per device based. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
All callers of iwl_setup_rxon_timing() also send the command right away, so rename the function to iwl_send_rxon_timing() and move the sending into it. Also, some callers clear the data, this can be done always and thus moved in as well. Finally, there's no reason for the function to acquire the spinlock, but it should be called with the mutex held, so assert that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Shanyu Zhao authored
Update outdated comments of iwl_set_rxon_channel() to reflect the current signature. Also remove the unnecessary validation of the channel. Those channel info are constructed in iwlwifi driver and mac80211 will never modify the content of the struct. Also everytime before this function is called the channel info has been validated already (as a paranoid check). Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Shanyu Zhao authored
When iwl_mac_config() is called by mac80211, the channel pointer hw->conf->channel can potentially change, resulting in mismatch band and channel number when configuring RXON command. To avoid this situation, save the channel pointer in local variables and validate the channel before using it. Note that priv->mutex is locked during the whole function so the local variables are safe. Same change is applied to iwl_mac_channel_switch() since basically it copies code from iwl_mac_config(). Also removed an outdated comment in the flow. Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Shanyu Zhao authored
A few cases in iwlwifi driver function ieee80211_frequency_to_channel() is called to get channel number from center frequency. This is not needed since the channel number is already saved in hw_value field of struct ieee80211_channel in function iwlcore_init_geos(). So replace those function calls with hw_value field of struct ieee80211_channel. Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
"Thermal Throttling" is an advance feature which only available for newer _agn devices. Move from iwl-core to iwl-agn for better code organization. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-