- 12 May, 2010 2 commits
-
-
Wey-Yi Guy authored
Check the mode in channel switch ie for either 0 or 1 on transmission. A channel switch mode set to 1 means that the STA in a BSS to which the frame containing the element is addressed shall transmit no further frames within the BSS until the scheduled channel switch. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This adds support for offloading the channel switch operation to devices that support such, typically by having specific firmware API for it. The reasons for this could be that the firmware provides better timing or that regulatory enforcement done by the device requires special handling of CSAs. In order to allow drivers to specify the timing to the device, the new channel_switch callback will pass through the received frame's mactime, where available. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
- 11 May, 2010 7 commits
-
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Don't send them for further processing. Signed-off-by:
-
Luis R. Rodriguez authored
These changes include: * For PAPRD, the TXRF3.capdiv5G, TXRF3.rdiv5G and TXRF3.rdiv2G are set to 0x0, the TXRF6.capdiv2G is set to 0x2 for all three chains. * The d2cas5G/d3cas5G/d4cas5G was updated to 4/4/4 in lowest_ob_db Tx gain table. * To improve DPPM, three parameters were updated (Released from Madhan): 1. RANGE_OSDAC is set to 0x1 for 2G, 0x0 for 5G 2. offsetC1 is set to 0xc 3. inv_clk320_adc is set to 0x1 * To reduce PHY error(from spur), cycpwr_thr1 and cycpwr_thr1_ext are increased to 0x8 at 2G. * The 2G Rx gain tables are updated with mixer gain setting 3,1,0. The new checksums yield: initvals -f ar9003 0x00000000c2bfa7d5 ar9300_2p0_radio_postamble 0x00000000ada2b114 ar9300Modes_lowest_ob_db_tx_gain_table_2p0 0x00000000e0bc2c84 ar9300Modes_fast_clock_2p0 0x00000000056eaf74 ar9300_2p0_radio_core 0x0000000000000000 ar9300Common_rx_gain_table_merlin_2p0 0x0000000078658fb5 ar9300_2p0_mac_postamble 0x0000000023235333 ar9300_2p0_soc_postamble 0x0000000054d41904 ar9200_merlin_2p0_radio_core 0x00000000748572cf ar9300_2p0_baseband_postamble 0x000000009aa5a0a4 ar9300_2p0_baseband_core 0x000000003df9a326 ar9300Modes_high_power_tx_gain_table_2p0 0x000000001cfba124 ar9300Modes_high_ob_db_tx_gain_table_2p0 0x0000000011302700 ar9300Common_rx_gain_table_2p0 0x00000000e3eab114 ar9300Modes_low_ob_db_tx_gain_table_2p0 0x00000000c9d66d40 ar9300_2p0_mac_core 0x000000001e1d0800 ar9300Common_wo_xlna_rx_gain_table_2p0 0x00000000a0c54980 ar9300_2p0_soc_preamble 0x00000000292e2544 ar9300PciePhy_pll_on_clkreq_disable_L1_2p0 0x000000002d3e2544 ar9300PciePhy_clkreq_enable_L1_2p0 0x00000000293e2544 ar9300PciePhy_clkreq_disable_L1_2p0 Cc: Don Breslin <don.breslin@atheros.com> Signed-off-by:Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
Jumbo frames are not supported, and if they are seen it is likely a bogus frame so just silently discard them instead of warning on them all time. Also, instead of dropping them immediately though move the check *after* we check for all sort of frame errors. This should enable us to discard these frames if the hardware picks other bogus items first. Lets see if we still get those jumbo counters increasing still with this. Jumbo frames would happen if we tell hardware we can support a small 802.11 chunks of DMA'd frame, hardware would split RX'd frames into parts and we'd have to reconstruct them in software. This is done with USB due to the bulk size but with ath5k we already provide a good limit to hardware and this should not be happening. This is reported quite often and if it fills the logs then this needs to be addressed and to avoid spurious reports. Cc: stable@kernel.org Signed-off-by:
-
Dan Carpenter authored
The goto and the break are equivelent. I removed the goto in memory of Edsger Dijkstra who famously hated gotos and who would have been eighty years old next Tuesday. Signed-off-by:
Dan Carpenter <error27@gmail.com> Acked-by:
Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by:
-
Dan Carpenter authored
The "(wl == NULL)" test doesn't work here because "wl" is always non-null. The intent of the code is to return if the interface was not supported by the driver. Signed-off-by:
-
Dan Carpenter authored
We should start the loop consistently with the "wl_lock" lock held. Signed-off-by:
-
- 10 May, 2010 31 commits
-
-
Johannes Berg authored
During a hw restart, mac80211 will attempt to reconfigure all stations. Currently, that fails and leads to warnings because we still have the stations marked active. Therefore, clear all stations when doing down. Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com>
-
Johannes Berg authored
Remove the check before invoking iwl_set_ht_add_station(), since neither of the conditions in this check makes sense, as either we pass in a NULL ht_info (first branch) or in the IBSS case an ht_info with ht_enabled=false. Signed-off-by:
-
Johannes Berg authored
This function is now only used for the special IBSS BSSID station, so rename it to indicate this. The new name is iwl_add_bssid_station. Signed-off-by:
-
Johannes Berg authored
4965 code is the only thing that now still needs iwl_find_station(), so move it there and make it static. Everything else can rely on the station data passed by mac80211. Signed-off-by:
-
Johannes Berg authored
With the station ID being stored in the station struct, which mac80211 gives us for TKIP phase 1 key updates, we can also remove the use of iwl_find_station() in that code path. Signed-off-by:
-
Johannes Berg authored
With the station ID being stored in the station struct, which mac80211 gives us for aggregation callbacks, we can also remove the use of iwl_find_station() in those code paths. Signed-off-by:
-
Johannes Berg authored
Since we now store the station ID in each station struct, many places need not look at the station table any more since they can just pull the station ID out of the struct. Remove iwl_get_sta_id() and use iwl_sta_id() instead as appropriate. This reduces the amount of code needed to find the right station significantly, and works since mac80211 passes the station only after it has been fully initialised, ie. even if TX races with station addition it will only be passed to TX once the addition is complete. Signed-off-by:
-
Johannes Berg authored
In places where the station struct is guaranteed to exist (presumably), use this helper to get the station ID out of it (and warn if there's no station struct after all). Signed-off-by:
-
Johannes Berg authored
mac80211 allows us to store private data per station, so put the station ID there. This allows us to avoid the station ID lookup when removing regular stations. To also be able to avoid the lookup to remove the special IBSS BSSID station, track its ID in the per-vif private data. Signed-off-by:
-
Wey-Yi Guy authored
Provide comments for newly added cfg parameters Signed-off-by:
-
Wey-Yi Guy authored
Move "tx power per chain" into ucode_tx_stats, it is debugging information provided by uCode as part of statistics notification. The "tx power per chain" parameters are optional parameters which only supported by 6000 series device today; those are reserved fields for all the other devices. Signed-off-by:
-
Reinette Chatre authored
When station is using an HT channel to communicate to AP and communication is lost then driver will first be notified that channel is not an HT channel anymore before AP station is removed. A consequence of that is that the driver will know that it is not communicating on HT anymore, but the rate scaling table is still under the impression it is operating in HT. Any time after driver has been notified channel is not HT anymore there will thus be a firmware SYSASSERT when the current active LQ command is sent. A workaround for this issue is to not send a LQ command in the short time between being notified channel is not HT anymore and rate scaling table being updated. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2173Signed-off-by:
-
Johannes Berg authored
Currently, the broadcast station is managed along with the interface type, rather than always being present. That leads to a bug with injection -- it is currently not possible to inject frames when the only virtual interface is a monitor, because in that the required broadcast station is missing. Additionally, allocating and deallocating the broadcast station's LQ all the time is wasteful, and the code to support this is fairly complex. So this changes completely the way we manage the broadcast station. Rather than manage it along with any interface, we now allocate it when we bring the device up, and remove it again when we bring the device down. When we bring the device up, we don't immediately program the broadcast station into it, instead we just mark it active and rely on the next restore cycle to upload it to the device. This works because an unassociated RXON is always required at least once to set up device parameters, which implies a reprogramming of stations into the device. As we now manage all stations properly, there no longer is a need for forcing a clearing of them via iwl_clear_ucode_stations(), which can become a lot simpler. Signed-off-by:
-
Johannes Berg authored
Rename iwl_sta_init_lq to iwl_sta_alloc_lq and move sending it out into the caller. Signed-off-by:
-
Johannes Berg authored
The "is_ap" argument to iwl_sta_init_lq is never true, so it and the corresponding code can be removed. However, it needs to have the station ID because it is also used for the IBSS BSSID station, and that doesn't have the broadcast ID. Signed-off-by:
-
Johannes Berg authored
The bssid member of struct iwl_priv is now only used by 3945 code, so note that. It shouldn't be used by any other code in the future. Signed-off-by:
-
Johannes Berg authored
Pass the virtual interface pointer to iwl_ht_conf() so it doesn't need to rely on iw_mode and other global variables. Signed-off-by:
-
Johannes Berg authored
This check is not useful, since we now no longer dereference priv->vif at this spot. Signed-off-by:
-
Johannes Berg authored
Most of the TX aggregation handling can be passed the virtual interface directly instead of having to rely on priv->vif. Signed-off-by:
-
Johannes Berg authored
Rather than keeping every bit of information around in priv and the virtual interface, add a virtual interface to many functions and use the information directly from it. This removes beacon_int, assoc_capability and assoc_id from struct iwl_priv. Signed-off-by:
-
Johannes Berg authored
Since iwl_configure_filter can now sleep since the mac80211 callback was changed, we can now apply filter flags changes directly. Also, while at it, make the code a bit more generic with a local macro. There's no need to check changed_flags since we apply all at the same time anyway. Signed-off-by:
-
Johannes Berg authored
We need not check iw_mode, since we have the vif pointer available. Signed-off-by:
-
Johannes Berg authored
This function is only needed by 4965, so it need not be in core code and can be made static. Signed-off-by:
-
Johannes Berg authored
We never use that member of struct iwl_priv. Signed-off-by:
-
Abhijeet Kolekar authored
Add plcp error checking for 3945. After threshold of plcp is reached , it resets the radio Signed-off-by:
Abhijeet Kolekar <abhijeet.kolekar@intel.com> Signed-off-by:
-
Johannes Berg authored
The old firmware file type does not allow indicating any firmware capabilities, which we frequently want to make things easier. This implements a new firmware type that is based on a TLV structure, and adds a TLV for the maximum length of probe requests in scans. Signed-off-by:
-
Johannes Berg authored
Currently the first four bytes in a firmware file indicate the major, minor and api versions as well as the serial number. These combined can never be zero, so we can use that special case for a new, future, file format. This patch simply shuffles the code and prepares for that new format. Signed-off-by:
-
Johannes Berg authored
It doesn't belong into firmware loading, it should instead be printed after loading the EEPROM. Signed-off-by:
-
Johannes Berg authored
AGN devices all use the same ucode operations, except for 4965, because 4965 uses only v1 file headers. Therefore, we can remove all the indirection we have here and just code the API distinction in place, with a small special case for 4965. Signed-off-by:
-
Johannes Berg authored
As these function pointers will always point to the 3945 functions, we can just call them directly and avoid the indirection. Signed-off-by:
-
Johannes Berg authored
We currently display the build number only if debugging is enabled, but it is really helpful so show it all the time. Also store it so it can be retrieved later via ethtool. Signed-off-by:
-
