- 26 Apr, 2011 25 commits
-
-
Chaoming_Li authored
Change rtl8192ce sw and LED routines for addition of RTL8192SE and RTL8192DE. Signed-off-by:
Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Chaoming_Li authored
Change rtl8192ce hw routine for addition of RTL8192SE and RTL8192DE. Signed-off-by:
-
Chaoming_Li authored
Change common PHY routines for addition of RTL8192SE and RTL8192DE code. Signed-off-by:
-
Chaoming_Li authored
Change common firmware routines for addition of RTL8192SE and RTL8192DE code. Signed-off-by:
-
Chaoming_Li authored
rtlwifi: rtl8192c-common: Convert common dynamic management routines for addition of rtl8192se and rtl8192de Convert common dynamic management routines for addition of RTL8192SE and RTL8192DE code. Signed-off-by:
-
Chaoming_Li authored
Convert usb routines for addition of RTL8192SE and RTL8192DE code Signed-off-by:
-
Chaoming_Li authored
Convert regulatory domain routines for addition of RTL8192SE and RTL8192DE code. Signed-off-by:
-
Chaoming_Li authored
Convert rc routines for addition of RTL8192SE and RTL8192DE code Signed-off-by:
-
Chaoming_Li authored
Convert ps routines for addition of RTL8192SE and RTL8192DE code Signed-off-by:
-
Chaoming_Li authored
Convert pci routines for addition of RTL8192SE and RTL8192DE code These changes allow the upper-level driver to specify the BAR to be used as it is different for rtl8192se than for the others. Signed-off-by:
-
Chaoming_Li authored
Convert core routines for addition of RTL8192SE and RTL8192DE code. Additional files are changed to allow compilation. Signed-off-by:
-
Chaoming_Li authored
Change cam routines for addition of RTL8192SE and RTL8192DE code Signed-off-by:
-
Chaoming_Li authored
Change base routines for addition of RTL8192SE and RTL8192DE code. Additional files are modified to allow compilation. Signed-off-by:
-
Chaoming_Li authored
Change wifi.h for addition of RTL8192SE and RTL8192DE code Signed-off-by:
-
Chaoming_Li authored
Change efuse routines for addition of RTL8192SE and RTL8192DE code Signed-off-by:
-
Rajkumar Manoharan authored
These warnings are exposed by gcc 4.6. net/mac80211/sta_info.c: In function 'sta_info_cleanup_expire_buffered': net/mac80211/sta_info.c:590:32: warning: variable 'sdata' set but not used net/mac80211/ibss.c: In function 'ieee80211_rx_mgmt_auth_ibss': net/mac80211/ibss.c:43:34: warning: variable 'status_code' set but not used net/mac80211/work.c: In function 'ieee80211_send_assoc': net/mac80211/work.c:203:9: warning: variable 'len' set but not used net/mac80211/tx.c: In function '__ieee80211_parse_tx_radiotap': net/mac80211/tx.c:1039:35: warning: variable 'sband' set but not used net/mac80211/mesh.c: In function 'ieee80211_mesh_rx_queued_mgmt': net/mac80211/mesh.c:616:28: warning: variable 'ifmsh' set but not used ... Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
-
Christian Lamparter authored
The release timer has to expire "just" after a frame is up for release. Currently, if the timer callback starts on time, the "!time_after" check above will start a new timer instead of releasing the frames. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Christian Lamparter authored
Using the ieee80211_sta_block allows the PS code to handle awake->doze->awake transitions of our clients in a race-free manner. Signed-off-by:
-
Christian Lamparter authored
"For best CPU usage and power consumption, having as few frames as possible percolate through the stack is desirable. Hence, the hardware should filter as much as possible." Note: Not all firmwares include the multicast filter feature and the stack does not filter them either. The ARP filter on the other hand was dropped from the patch since it does not work correctly: Quote from: Max Filippov <jcmvbkbc@gmail.com> <http://www.spinics.net/lists/linux-wireless/msg67466.html> "In the ARP case, when there's no other traffic on p54spi, all ARP requests are dropped. But if there's some egress traffic from p54spi, filter seems to work correctly: only ARP requests that match filter pass through. In the multicast case filter seems to work correctly, but it treats broadcast as subject to that filtering too. By default only 01:00:5e:00:00:01 gets into priv->mc_maclist, so we miss all broadcasts. These two filters seem to interfere: - if we set ARP filter and multicast filter without bc => we miss all ARPs if there's no egress traffic; - if we set ARP filter and multicast filter with bc or don't set mc filter at all => we get all ARPs. This effect does not depend on filter setup order." Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
My 14e4:4315 is SSB_IDLOW_SSBREV_26: read32 0xfaafcff8 -> 0x600422d5 My 14e4:4328 is SSB_IDLOW_SSBREV_24: read32 0xfaafcff8 -> 0x400422c5 My 14e4:432b is SSB_IDLOW_SSBREV_26 again: read32 0xfaafcff8 -> 0x600422d5 For all of them wl driver is using 0x2 reject bit: write32(0xf98) <- 0x00010002 So it seems SSB 2.3 is the exception using another bit. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
ssb_chipco_set_clockmode may want to touch CC registers to control power of the bus. However touching registers without powered_up set causes warnings. Signed-off-by:
-
Adrian Chadd authored
The xpaBiasLvlFreq parameter array is made up of 16 bit words which aren't byte-swapped like the other 16-bit eeprom parameters are. It's only used by the AR9160. Signed-off-by:
Adrian Chadd <adrian@freebsd.org> Signed-off-by:
-
Rajkumar Manoharan authored
Requesting beacon sync up to configure beacon timers properly in hw, has be done after doing beacon config with default values. Setting the flags in beacon config is causing the device to not enter into network sleep on idle state. Signed-off-by:
-
Rajkumar Manoharan authored
On AR9003 chips, doing three IQ calibrations will possibly cause chip in stuck state. In noisy environment, chip could receive a packet during the middle of three calibrations and it causes the conflict of HW access and the eventual failure. It also causes IQ calibration outliers which results in poor Tx EVM. The IQ Cal procedure is after resetting the chip, run IQ cal 3 times per each cal cycle and find the two closest readings and average of two. The advantage of running Tx IQ cal more than once is that we can compare calibration results for the same gain setting over multiple iterations. Most of the cases the IQ failures were observed after first pass. For the AR9485 and later chips, Tx IQ Calibration is performed along with AGC cal. But for pre-AR9485 chips, Tx IQ cal HW has to be separated from the rest of calibration HW to avoid chip hang. After all calibrations are done in HW, we can start SW post-processing. By doing this way, we minimize the SW difference among all chips. The order of calibration (run IQ cal before other calibration) is also needed to avoid chip hang for chips before AR9485. This issue was originally observed with AR9382. During the issue kernel log was filled with following message ath: timeout (100000 us) on reg 0xa640: 0x00000001 & 0x00000001 != 0x00000000 ath: timeout (100000 us) on reg 0xa2c4: 0x00158dd9 & 0x00000001 != 0x00000000 ath: Unable to reset channel (2412 MHz), reset status -5 ath: Unable to set channel Signed-off-by:
-
-
- 25 Apr, 2011 15 commits
-
-
Rafał Miłecki authored
Signed-off-by:
-
Mohammed Shafi Shajakhan authored
This helped the developers to fix an issue of chip not entering network sleep during idle state, previously this was only available as a debug message Signed-off-by:
Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
newer chipsets support auto sleep feature, so remove the unlikely check which does not seems to help anything Signed-off-by:
-
Senthil Balasubramanian authored
We should protect hw_pll handler with power save wrappers and also modularize hw_pll handler properly for better readability. Also add a debug message to track chip resets on pll hang condition. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Senthil Balasubramanian authored
There is no reason why pll work handler should be part of xmit file. move it to main.c so that reading hw check routines are all in the same place. Signed-off-by:
-
Senthil Balasubramanian authored
We need not wake up the chip even before mutex lock is acquired and also that it is required only if we are going to drain the txq. So place the wrappers accordingly and this change is also useful when there are no pending frames in the txq as we do not wake up the chip unnecessarily. Signed-off-by:
-
Senthil Balasubramanian authored
we should program the AR9485 baseband PLL phase shift to 6 and a redundant setting overwrites the correct value. Remove the incorrect and unwnated register setting. Signed-off-by:
-
Senthil Balasubramanian authored
The LED gpio is incorrectly programmed for AR9300 and so the led is not working propelry. AR93xx uses gpio 10 for LED and not the default. Signed-off-by:
-
Amitkumar Karwar authored
Currently mac80211 uses ieee80211_disable_40mhz_24ghz module parameter to allow disabling 40MHz operation in the 2.4GHz band. Move this handling from mac80211 to cfg80211 so that the feature will be more generic. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Hw next tigger time is configured as current_tsf + (timer_period * 10) which is wrong, it should be current_tsf + timer_period. The wrong hw timer configuration would cause btcoex related issues. Signed-off-by:
-
Johannes Berg authored
Currently, the code to tear down BA sessions will execute after queues are stopped, but attempt to send frames, so those frames will just get queued, which isn't intended. Move this code to before to tear down the sessions properly. Additionally, after stopping queues, flush the TX queues in the driver driver to make sure all the frames went out. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Nishant Sarmukadam authored
Tell the firmware to enable the life time expiry of tx packets in the hardware. The hardware will now refer to the timestamp in every tx packet and decide whether the packet needs to be dropped or transmitted. Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by:
-
Nishant Sarmukadam authored
Since queues are not stopped anymore, management frames would be dropped if the corresponding tx queue is full. This can cause issues say when we want to setup an ampdu stream and action frames i.e addba requests keep getting dropped frequently. Fix this by reserving some buffers to allow management frames to go through in queue full conditions. Signed-off-by:
-
Pradeep Nemavat authored
Timestamp tx packets using a HW micro-second timer. This timestamp will be compared to the current timestamp in the hardware and if the difference is greater than 500ms, the packet will be dropped. Signed-off-by:
-
