- 15 Nov, 2010 40 commits
-
-
Felix Fietkau authored
The current ath9k tx queue handling code showed a few issues that could lead to locking issues, tx stalls due to stopped queues, and maybe even DMA issues. The main source of these issues is that in some places the queue is selected via skb queue mapping in places where this mapping may no longer be valid. One such place is when data frames are transmitted via the CAB queue (for powersave buffered frames). This is made even worse by a lookup WMM AC values from the assigned tx queue (which is undefined for the CAB queue). This messed up the pending frame counting, which in turn caused issues with queues getting stopped, but not woken again. To fix these issues, this patch removes an unnecessary abstraction separating a driver internal queue number from the skb queue number (not to be confused with the hardware queue number). It seems that this abstraction may have been necessary because of tx queue preinitialization from the initvals. This patch avoids breakage here by pushing the software <-> hardware queue mapping to the function that assigns the tx queues and redefining the WMM AC definitions to match the numbers used by mac80211 (also affects ath9k_htc). To ensure consistency wrt. pending frame count tracking, these counters are moved to the ath_txq struct, updated with the txq lock held, but only where the tx queue selected by the skb queue map actually matches the tx queue used by the driver for the frame. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Reported-by:
Björn Smedman <bjorn.smedman@venatech.se> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
maximilian attems authored
The Mandriva patch seems to stem from 2.6.14, so much for their upstreaming effort. Didn't find another Linux reference of it, just an omnious "USB\VID_1044&PID_8004" from GigabyteZD1201U.INF for Gigabyte GN-WLBZ101 802.11b USB Adapter, which matches the Mandriva patch comment. Aboves file also lists an "USB\VID_1044&PID_8006", which I have kept appart as this "Gigabyte GN-WBZB-M 802.11b USB Adapter" didn't show up in googling. Signed-off-by:
maximilian attems <max@stro.at> Signed-off-by:
-
maximilian attems authored
"These USB ID came from Palnex <http://www.planex.co.jp/> Worked fine." says Mandriva patch for their 2.6.32 and earlier. Web has evidence for both id's to work, so just add them upstream: http://www.mail-archive.com/zd1211-devs@lists.sourceforge.net/msg00507.html http://ubuntuforums.org/showthread.php?t=473046Signed-off-by:
Go Taniguchi <go@turbolinux.co.jp> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
Current 8187B initialization misses anaparam registers restore after 8187 reset. This causes ANAPARAM register to stay zeroed out (ANAPARAM2 kept its value on my tests). To avoid this, call rtl8187_set_anaparam right after chip reset (to be on the safe side, as it makes sure we restore all ANAPARAM registers). Signed-off-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: seno <senada@t-online.de> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
Usually you set RTL818X_CONFIG3_ANAPARAM_WRITE when you are going to change/write ANAPARAM registers. But in current initialization of RTL8187B there is a place where ANAPARAM_WRITE bit is set without any ANAPARAM register being written, without reason, so remove it. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
There are repeated calls for anaparam on/off sequence in the code. Consolidate the common code in rtl8187_set_anaparam and use it where needed. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
The GNTSel bit should only concern pci devices by looking at RTL8180 spec, which is not the case of 8187B. Also testing shows that trying to set this bit fails, a subsequent read from the register after trying to set it shows that the bit isn't set, seems the hardware ignores it, which makes sense. This setting was a left over from Realtek sources. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
On 8187B start, comment about pll reset, and move it out of ANAPARAM write sequence, so that code is more readable. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
The table with misc register initialization was setting it, and later on we would set it again with a explicity call to rtl818x_iowrite16_idx. Remove duplicate initialization from the register table. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
We were using wrong address for BRSR (Basic Rate Set Register) while initializing its value, comparing with Realtek sources, for 8187B case. Also, the same register is initialized in rtl8187b_reg_table, so remove the duplicate initialization from the table. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
On 8187B path, we set a initial value for beacon interval and atim window on initialization. But this isn't needed, since same setup is done on rtl8187_config. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
This removes redundant write to Auto Rate Fallback Register on RTL8187B. The same value was being written twice in the same function. Avoid this removing the duplicate initialization on rtl8187b_reg_table, and also add comment for this write (information from Realtek source). Signed-off-by:
-
Nishant Sarmukadam authored
AP firmware uses xmitcontrol to differentiate between AMPDU and non-AMPDU frames. As the support for AMPDU is not yet added, set xmitcontrol to non-AMPDU for all tx frames for AP firmware. This field will be set to indicate ampdu/non-ampdu frames when tx AMPDU support is added. Signed-off-by:
Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by:
Brian Cavagnolo <brian@cozybit.com> Acked-by:
Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by:
-
Christian Lamparter authored
Previously, the beacon rate was fixed to either: * 1Mb/s [2.4GHz band] * 6Mb/s [5GHz band] This limitation has been addressed and now the beacon rate is selected by ieee80211_tx_info's rate control info, almost like any ordinary data frame. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Christian Lamparter authored
This patch fixes a possible lengthy stall if the device is operating as an experimental 11n AP and an STA [during heavy txrx action] suddenly signalized to go off-channel (old NetworkManager), or (sleep - which is unlikely, because then it wouldn't be *active* at all!?). Because the driver has to manage the BA Window, the sudden PSM transition can leave active uplink BA sessions to the STA in a bad state and a proper cleanup is needed. Signed-off-by:
-
Christian Lamparter authored
RX Stress tests of unidirectional bulk traffic with bitrates of up to 220Mbit/s have revealed that the fatal-event recovery logic [which was solely triggered by an out-of-rx-buffer situation] is too aggressive. The new method now "pings" the device and then decides - based on the response - whenever a restart is needed or not. Signed-off-by:
-
Christian Lamparter authored
This patch changes the initial aMPDU density and factor settings to match those of Otus. Signed-off-by:
-
Christian Lamparter authored
This patch imports all shared header changes from carl9170fw.git. * add some strategic __aligned(4). This allows the compiler generate optimized code for architectures which can't access (unaligned/packed) data efficiently. ("ath9k_hw: optimize all descriptor access functions") * add a forgotten __CARL9170FW__ ifdef around a private firmware-internal struct. * GET_VAL macro helper Very useful for extracting data out of the bit-packed PHY registers. * cosmetic changes e.g.: _CCA_MINCCA_ to just _CCA_MIN_. * version bump 1.8.8.3 -> 1.9.0. Signed-off-by: -
Blaise Gassend authored
Up to now mac80211_hwsim has been reporting an rssi of -50. This patch improves the model slightly by returning txpower-50. This makes it easy to stimulate tests that need to see a varying rssi. Signed-off-by:
Blaise Gassend <blaise@willowgarage.com> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Clearing the per packet TX AGC for the RTL8187B device appears to increase its overall TX power. This allows the device to associate and a connection to be established using APs a little further away. This is in accordance to what is done for RTL8187L devices and also what Realtek drivers do. Tested-by:
Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by:
-
Eliad Peller authored
add RECOVER testmode command. this command triggers a recovery sequence (by enqueueing a recovery_work). Signed-off-by:
Eliad Peller <eliad@wizery.com> Reviewed-by:
Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by:
-
Eliad Peller authored
unmask the WL1271_ACX_INTR_WATCHDOG interrupt. when getting it - enqueue a recovery work and bail out. Signed-off-by:
-
Eliad Peller authored
refactor wl1271_debugfs by using a format© function, instead of duplicating the code for each generated function. this change reduces about 3Kb from wl1271.ko Signed-off-by:
-
Eliad Peller authored
set wl->vif to the newly created interface only after the firmware booted successfully. on the way - make the function flow more clear. Signed-off-by:
-
Juuso Oikarinen authored
Check the state of the interface on op_* function so we don't try to access the hardware in when its off. The mac80211 may call these in some corner cases related, for instance, to the hardware recovery procedure. These accesses cause a kernel crash on at least some SDIO devices, because the bus is not properly claimed in that scenario. Signed-off-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by:
-
Juuso Oikarinen authored
In scan_complete_work, because the mutex is released before accessing the scan->failed flag, it is possible for unfounded hardware recovery rounds to be executed. Fix this. Signed-off-by:
-
Juuso Oikarinen authored
The wl1271_rx function loops through packets in an aggregated buffer. Each packet in the buffer is handled by a call to wl1271_rx_handle_data, which will fail if skb memory allocation fails or production mode is enabled. These failures currently prevent the rx counters to be incremented, thus causing the rx loop to run forever. Fix this by ignoring error codes reported wl1271_rx_handle_data function. This essentially means that frames will be dropped in production mode, which is the intetion, and frames will be dropped if memory allocation fails, which is a decent way to recover from that situation. Signed-off-by:
Tuomas Katila <ext-tuomas.2.katila@nokia.com> Reviewed-by:
-
Nicolas Kaiser authored
wl1271_ps_elp_sleep() is void and cannot return a value. Signed-off-by:
Nicolas Kaiser <nikai@nikai.net> Reviewed-by:
-
Luciano Coelho authored
This bug was being triggered by a call to acx_rate_policies in tx_work without calling ps_elp_wakeup first. If we have full PSM enabled, this happens rather often, immediately after association. Reported-by:
-
Teemu Paasikivi authored
While scanning, it is possible that beacon and probe response frames are received on other band than configured to the driver. In rx status handling this has caused "Unsupported RX rate from HW" warnings. This patch changes the wl1271_rate_to_index function to take the band of the received frame as a parameter instead of using value configuret to wl->band. Signed-off-by:
Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Reviewed-by:
-
Shahar Levi authored
Add 11n ability in scan, connection and using MCS rates. The configuration is temporary due to the code incomplete and still in testing process. That plans to be remove in the future. Signed-off-by:
Shahar Levi <shahar_levi@ti.com> Reviewed-by:
-
Shahar Levi authored
Added ACX command to the FW for 11n support. Signed-off-by:
-
Shahar Levi authored
Two acx commands: ht_capabilities & ht_information, 11n sta capabilities macro. Signed-off-by:
-
Ido Yariv authored
The number of entries in the TX queue is compared to the low watermark value each time TX completion interrupts are handled. However, the fact that a TX completion arrived does not necessarily mean there are any less skbs in the TX queue. In addition, a TX completion interrupt does not necessarily mean that there are any new available TX blocks. Thus, queuing TX work when the low watermark is reached might not be needed. Fix this by moving the low watermark handling to the TX work function, and avoid queuing TX work in this case. Signed-off-by:
Ido Yariv <ido@wizery.com> Reviewed-by:
-
Ido Yariv authored
On each TX descriptor allocation, a free entry is found by traversing the TX descriptors array. Improve this by holding a bitmap of all TX descriptors, and using efficient bit operations to search for free entries. Signed-off-by:
-
Ido Yariv authored
While wl1271_irq_work handles RX directly (by calling wl1271_rx), a different work is scheduled for transmitting packets. The IRQ work might handle more than one interrupt during a single call, including multiple TX completion interrupts. This might starve TX, since no packets are transmitted until all interrupts are handled. Fix this by calling the TX work function directly, instead of deferring it. Signed-off-by:
-
Ido Yariv authored
In case the aggregation buffer is too small to hold all available packets, the buffer is transferred to the FW and no more packets are aggregated. Although there may be enough available TX blocks, no additional packets will be handled by the current TX work. Fix this by flushing the aggregation buffer when it's full, and continue transferring packets as long as there are enough available TX blocks. Signed-off-by:
-
Gery Kahn authored
Cosmetic cleanup for ref_clock code while configured by board. Signed-off-by:
Gery Kahn <geryk@ti.com> Signed-off-by:
-
Wey-Yi Guy authored
For 130 series device, 6000g2b uCode will be used, no need to have additional defines for 130 devices, so remove those. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
