- 28 Jan, 2011 16 commits
-
-
Sujith Manoharan authored
Commit "ath9k_hw: move AR9280 PCI EEPROM fix to eeprom_def.c" changed the behavior of INI overriding which is needed only for PCI cards. Revert to the original check. Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
Commit "ath9k_hw: Relocate Opmode initialization" moved the opmode initialization before the STA_ID1 register was programmed with defaults. This changed the original behaviour because the re-programming code doesn't take into account the existing value in the register. Both ath9k and ath9k_htc were not affected by this change because the opmode is re-initialized after every reset, when RX is started. Revert to the original behavior, except keep it outside the REGWRITE block. This would help remove extraneous opmode calls in the driver core. Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Juuso Oikarinen authored
Some vendor specific cipher suites require non-zero key indexes for pairwise keys, but as of currently, the cfg80211 does not allow it. As validating they cipher parameters for vendor specific cipher suites is the job of the driver or hardware/firmware, change the cfg80211 to allow also non-zero pairwise key indexes for vendor specific ciphers. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bob Copeland authored
Now that rx and tx dumps go through the tracing infrastructure, we no longer need to keep these routines around. Signed-off-by: Bob Copeland <me@bobcopeland.com> Acked-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bob Copeland authored
This adds a few tracepoints to ath5k driver transmit and receive callbacks in order to record packet traffic. We record the entire packet in the trace buffer so that the data can be extracted with trace-cmd and external plugins. Compared to the previous debugging calls, this approach removes an out-of-line function call from the tx and rx paths in the compiled-in-but-disabled case, while improving the ability to process the logged data. A new option, CONFIG_ATH5K_TRACER, is added so that one may disable the tracepoints completely. Signed-off-by: Bob Copeland <me@bobcopeland.com> Acked-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
IEEE80211_WEP_NKID is not used in ath9k any more since the key handling code has been moved to ath/. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
This enables 4.9GHz frequencies in ath5k if they are allowed as indicated by the regulatory domain code. Currently this is MKK9_MKKC (0xfe). Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
This adds a helper function to ath/regd.c which can be asked if 4.9GHz channels are allowed for a given regulatory domain code. This keeps the knowledge of regdomains and defines like MKK9_MKKC in one place. I'm passing the regdomain code instead of the ath_regulatory structure because this needs to be called quite early in the driver inititalization where ath_regulatory is not available yet in ath5k. I'm using MKK9_MKKC only because this is the regdomain in the 802.11j enabled sample cards we got from our vendor. I found some hints in HAL code that this is used by Atheros to indicate 4.9GHz channels support and that there might be other domain codes as well, but as I don't have any documentation I'm just putting in what I need right now. It can be extended later. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Shorten some lines and make code more readable. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Various places printing tx queue information used various different ways to get a tx queue index for printing statistics. Most of these ways were wrong. ATH_TXQ_AC_* cannot be used as an index for sc->tx.txq, because it is only used internally for queue assignment. One place used WME_AC_* as a queue index for sc->debug.stats.txstats, however this array uses the ath9k_hw queue number as well. Fix all of this by always using the ath9k_hw queue number as an index, and always looking it up by going through sc->tx.txq_map. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
It does not make much sense to keep the current virtual wiphy implementation any longer - it adds significant complexity, has very few users and is still very experimental. At some point in time, it will be replaced by a proper implementation in mac80211. By making the code easier to read and maintain, removing virtual wiphy support helps with fixing the remaining driver issues and adding further improvements. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Instead of spreading ath_wake_mac80211_queue() calls over multiple places in the tx path that process the tx queue for completion, call it only where the pending frames counter gets decremented, eliminating some redundant checks. To prevent queue draining from waking the queues prematurely (e.g. during a hardware reset), reset the queue stop state when draining all queues, as the caller in main.c will run ieee80211_wake_queues(hw) anyway. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
-
- 27 Jan, 2011 4 commits
-
-
Felix Fietkau authored
The commit 'ath9k: Add more information to debugfs xmit file.' added more debug counters to ath9k and also added some lines of code to ath9k_hw. Since ath9k_hw is also used by ath9k_htc, its code must not depend on ath9k data structures. In this case it was not fatal, but it's still wrong, so the code needs to be moved back to ath9k. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
"mac80211 will properly assign sequence numbers to QoS-data frames but cannot do so correctly for non-QoS-data and management frames because beacons need them from that counter as well and mac80211 cannot guarantee proper sequencing." Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch syncs up the header files with the project's main firmware carl9170fw.git. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 26 Jan, 2011 3 commits
-
-
Mohammed Shafi Shajakhan authored
Remove unused macros and cleanup buffer_type enumeration Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
For events that include only the local struct as their parameter, we can use DECLARE_EVENT_CLASS and save quite some binary size across segments as well lines of code. text data bss dec hex filename 375745 19296 916 395957 60ab5 mac80211.ko.before 367473 17888 916 386277 5e4e5 mac80211.ko.after -8272 -1408 0 -9680 -25d0 delta Some more tracepoints with identical arguments could be combined like this but for now this is the one that benefits most. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Merge branch 'wireless-next-2.6' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6
-
- 25 Jan, 2011 3 commits
-
-
Bruno Randolf authored
Remove useless test_bit - it's not going to happen because of the way this function is called only when that bit is set. And fix some whitespace. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
We need to read and backup AR_WA register value permanently and reading this after the chip is awakened results in this register being zeroed out. This seems to fix the ASPM with L1 enabled issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. Cc: Stable Kernel <stable@kernel.org> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Cc: Stable Kernel <stable@kernel.org> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 24 Jan, 2011 14 commits
-
-
Eliad Peller authored
The auto-arp feature sometimes has unexpected side effects (e.g. firmware crashes, no ARP replies, etc.) disable it until it will be solved. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Juuso Oikarinen authored
The passive scan channel dwell time currently used is 30-60TU. A typical beacon interval for AP's is 100TU. This leads to a ~30% worst-case probability of finding an AP via passive scanning. For 5GHz bands for DFS frequencies passive scanning is the only scanning option. Hence for these, the probability of finding an AP is very low. To fix this, increase the passive channel scan dwell times (also the early leave value, as 5GHz channels are still typically very silent.) Use a value of 100TU, because that covers most typical AP configurations. Based on testing the probability of finding an AP (100TU beacon interval) on a single scan round are as follows (based on 100 iterations): dwell min/max (TU) | probability ---------------------+------------ 30/60 | 35% 60/60 | 56% 80/80 | 77% 100/100 | 100% Total scan times now and after the change: Region | Before (s) | After (s) -------+------------+---------- 00 | 0.77 | 1.48 FI | 0.95 | 2.01 US | 0.91 | 1.76 Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Eliad Peller authored
Return values were assigned to incorrect var / weren't assigned. fix it, and defer mutex_lock after the sanity checks. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Levi, Shahar authored
Add new ampdu_action ops to support receiver BA. The BA initiator session management in FW independently. Signed-off-by: Shahar Levi <shahar_levi@ti.com> Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Levi, Shahar authored
Add 80211n BA initiator session support wl1271 driver. Include BA supported FW version auto detection mechanism. BA initiator session management included in FW independently. Signed-off-by: Shahar Levi <shahar_levi@ti.com> Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Arik Nemtsov authored
Channel 14 is only supported in Japan (JP country code in regdb). The FW limits tranmissions to CCK only on this channel. Tested in both STA and AP modes to work correctly. Signed-off-by: Arik Nemtsov <arik@wizery.com> Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Arik Nemtsov authored
In wl12xx cards AP-mode requires a separate FW file. Add this file to the module info. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Juuso Oikarinen authored
PLT mode start/stop is controlled from userspace. When removing module, the PLT mode state is however not checked, and not cleared. There is the possibility of some unwanted state to left linger and there is even the possiblity of a kernel crash if for instance IRQ work is running when the module is removed. Fix this by stopping PLT mode on module removal, if still running. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Eliad Peller authored
pointed out by sparse warnings: CHECK drivers/net/wireless/wl12xx/cmd.c drivers/net/wireless/wl12xx/cmd.c:987:20: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/cmd.c:987:20: expected restricted __le16 [usertype] aging_period drivers/net/wireless/wl12xx/cmd.c:987:20: got int CHECK drivers/net/wireless/wl12xx/tx.c drivers/net/wireless/wl12xx/tx.c:197:2: warning: cast from restricted __le16 drivers/net/wireless/wl12xx/tx.c:197:2: warning: cast from restricted __le16 drivers/net/wireless/wl12xx/tx.c:197:2: warning: cast from restricted __le16 CHECK drivers/net/wireless/wl12xx/acx.c drivers/net/wireless/wl12xx/acx.c:816:23: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/acx.c:816:23: expected restricted __le32 [usertype] rate_policy_idx drivers/net/wireless/wl12xx/acx.c:816:23: got unsigned char [unsigned] [usertype] idx Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Luciano Coelho authored
The wl12xx chips do the AMDPU aggregation work in the firmware, but it supports a maximum of 8 frames per block. Configure the mac80211 hw structure accordingly. Signed-off-by: Luciano Coelho <coelho@ti.com> Tested-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
-
Guy Eilam authored
changed the visibility of the debug_level module parameter in the filesystem to be readable and writable to the root user. It is now accessible under /sys/module/wl12xx/parameters removed the debug_level debugfs file that was created under /sys/kernel/debug/... Signed-off-by: Guy Eilam <guy@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Luciano Coelho authored
We were calling ieee80211_find_sta() and the sta returned by it without locking the RCU, which is required by mac80211. Fix this and reorganize slightly the area of the code where the sta is used. Reported-by: Jonathan DE CESCO <jonathanc@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Luciano Coelho authored
When 11a is not supported, we were modifying the global structure that contains the bands supported by the driver. This causes problems when having more one wl12xx device in the same system because they all use the same global. This also causes problems when the wl12xx_sdio module is removed and the wl12xx module remains. Fix this problem by copying the band structure into the wl12xx instance. Reported-by: Arik Nemtsov <arik@wizery.com> Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luciano Coelho <coelho@ti.com>
-
Eliad Peller authored
wl12xx "rejoins" upon every BSS_CHANGED_BSSID notification. However, there is no need to rejoin after disassociation, so just filter out the case when the new bssid is 00:00:00:00:00:00. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
-