- 24 Aug, 2011 40 commits
-
-
Larry Finger authored
This patch also removes the now unused code from rtl8192ce/def.h. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Chaoming Li <chaoming_li@realsil.com.cn> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
Signed-off-by:
-
Larry Finger authored
In preparation for fixing the rate-mapping situation, place a driver-agnostic version in rtlwifi. This one contains the updated rate incormation. Signed-off-by:
-
Julia Lawall authored
Test the just-initialized value rather than some other one. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ identifier x,y,f!={PTR_ERR,ERR_PTR,ERR_CAST}; statement S; @@ x = f(...); ( if (\(x == NULL\|IS_ERR(x)\)) S | *if (\(y == NULL\|IS_ERR(y)\)) { ... when != x return ...; } ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Acked-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Michael Büsch authored
This removes the "FWxx" ID strings from the b43 and b43legacy drivers. They were once used to match a specific driver revision to a set of firmware files. However, this is hardly useful today. Additionally, the IDs are not updated and maintained properly, so they might mislead users. Signed-off-by:
Michael Buesch <m@bues.ch> Acked-by:
-
Rajkumar Manoharan authored
The Walsh bit is disabled for regulatory consideration. FCC limit for walsh enable is lower than that for walsh disable. So disabling walsh bit will not limit tx power/affect tx power even in cases where we are not FCC limited (most client cards). If the tx power is not FCC limited, then enabling/disabling walsh bit will not affect Avg. EVM/overall performance in any visible manner. Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
Rajkumar Manoharan authored
In congested network, having all rate reties at MCS rates is failing to transmit the frame offenly. By the time reaching the success rate set, the application gets timed out. One such scenario is that authentication time out during 4-Way handshake. This patch uses a legacy rate as last retry sequnce for unaggregated frames or if the first selected rate's PER is ~80% of max limit. And also observed from the tx status that the frame was trasmitted successfully by using legacy rates. Signed-off-by:
-
Rajkumar Manoharan authored
Cc: stable@kernel.org Signed-off-by:
-
Mohammed Shafi Shajakhan authored
this useful for debugging and to keep track of success/failure of frames such as ACK, RTS and FCS error count in a noisy environment Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Christian Lamparter authored
The firmware keeps track of channel usage. This data can be used by the automatic channel selection to find the best channel. Survey data from wlan4 frequency: 5200 MHz [in use] noise: -91 dBm channel active time: 811909 ms channel busy time: 63395 ms channel transmit time: 59636 ms Survey data from wlan4 frequency: 5210 MHz noise: -91 dBm channel active time: 121 ms channel busy time: 119 ms channel transmit time: 0 ms Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Aloisio Almeida Jr authored
Update MAINTAINERS with NFC subsystem and drivers entry. Signed-off-by:
Aloisio Almeida Jr <aloisio.almeida@openbossa.org> Signed-off-by:
-
Samuel Ortiz authored
We can have the NFC core layer allocating the tx head and tail room for the drivers and avoid 1 or more SKBs copy on write on the Tx path. Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Dan Carpenter authored
The u32 would never be less than zero so the error handling would break. I changed it to s32 to match how bcma_erom_get_mst_port() is declared. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Bill Jordan authored
Prevent 8 bytes from being truncated from MGMT packets when using TKIP. Signed-off-by:
Bill Jordan <bjordan@rajant.com> Signed-off-by:
-
Rafał Miłecki authored
We have resolved all the known issues with DMA mode, however some users (or distros) are still forcing PIO mode by config files. Without debugging enabled it's not noticable at all. Add the warning for them. Cc: Gregory Bellier <gregory.bellier@gmail.com> Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Acked-by:
-
Alex Hacker authored
The EIFS value read from AR_D_GBL_IFS_EIFS register in core clocks and then written back as microsecond value. Signed-off-by:
Alex Hacker <hacker@epn.ru> Acked-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Christian Lamparter authored
All AR9170 hardware have a 16-Bit random number generator. The documentation claims the values are suitable for "security keys". The "throughput" is around 320Kibit/s. It's slow, but it does work without introducing any special offload firmware commands. Signed-off-by:
-
Christian Lamparter authored
The firmware keeps track of channel usage. This data can be used by the automatic channel selection to find the *best* channel. Survey data from wlan22 frequency: 2412 MHz [in use] noise: -86 dBm channel active time: 3339608 ms channel busy time: 270982 ms channel transmit time: 121515 ms Survey data from wlan22 frequency: 2417 MHz noise: -86 dBm channel active time: 70 ms channel busy time: 2 ms channel transmit time: 1 ms Signed-off-by:
-
Christian Lamparter authored
Import new headers from our firmware branch: git://git.kernel.org/pub/scm/linux/kernel/git/chr/carl9170fw.gitSigned-off-by:
-
Christian Lamparter authored
AR9170_PWR_REG_PLL_ADDAC is used to set the main clock divisor which affects the AHB/CPU speed. Because this would interfere with the firmware internal timekeeping, the function has to be moved into the firmware. Signed-off-by:
-
Dan Carpenter authored
There was an extra semicolon so the if condition wasn't used. We checked "priv->dev" twice instead of "priv->mesh_dev". Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Rafał Miłecki authored
They were taken from MMIO dump with few RegExps and vim. Signed-off-by:
-
Rafał Miłecki authored
Analog is switched on right after reading PHY version: read16 0xfaafc3e0 -> 0xa801 phy_read(0x043b) -> 0x0000 phy_write(0x043b) <- 0x0000 Switched off after after killing radio: >>> Switch Radio(OFF) end phy_read(0x043c) -> 0x0000 phy_write(0x043c) <- 0x0007 phy_read(0x043b) -> 0x0000 phy_write(0x043b) <- 0x0007 Signed-off-by:
-
Rafał Miłecki authored
wl reads radio version, then disables it. That's how we found it in MMIO dump: radio_read(0x0000) -> 0x0031 <-- RADIO READ WITHOUT 0x200 SET! radio_read(0x0001) -> 0x0064 <-- RADIO READ WITHOUT 0x200 SET! radio_read(0x0002) -> 0x0020 <-- RADIO READ WITHOUT 0x200 SET! read32 0xfaafc120 -> 0x04000400 phy_read(0x044d) -> 0x0000 phy_write(0x044d) <- 0x0000 phy_read(0x044c) -> 0x1fff phy_write(0x044c) <- 0x1fff phy_read(0x04b7) -> 0x0000 phy_write(0x04b7) <- 0x0000 phy_read(0x04b1) -> 0x0000 phy_write(0x04b1) <- 0x0000 phy_read(0x04b0) -> 0x7dff phy_write(0x04b0) <- 0x7dff phy_read(0x04fa) -> 0x0000 phy_write(0x04fa) <- 0x0000 phy_read(0x04f9) -> 0x007f phy_write(0x04f9) <- 0x007f Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Some hardware with 64-bit DMA uses lower address word for setting routing (translation) bit. Add workaround for such boards. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Felix Fietkau authored
On embedded hardware it's normal to not have a PCI device for the PCI bridge that the wifi card is attached to. pdev->bus->self will be NULL in that case. In that case, simply return without emitting an useless kernel stack trace. Signed-off-by:
-
Rajkumar Manoharan authored
Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k/dump_nfcal Signed-off-by:
-
Rajkumar Manoharan authored
While switching b/w HT20/40, the current channel's nf values are updated into history buffer. Since the current channel's channel type, channel flag got updated before reading nf value from hw. This channel type mismatch is causing invalid readings when hw is on ht20 but getnf tries to read on extn chains. Signed-off-by:
-
Rajkumar Manoharan authored
Before doing hw reset the current channel's noisefloor readings are updated into history buffer. The extension chain's readings are considered only if the current channel was configured in HT40. While moving from HT40 to HT20, the extn chain's readings are skipped though the current channel is in ht40. This patch updates extn chain reading based on channel flag. Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rajkumar Manoharan authored
The chainmasks were already configured at process_ini before doing init calibration. Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rajkumar Manoharan authored
Once RXEOL was disabled, it never be enabled again. This patch re-enables rxeol at the end of rx tasklet. Signed-off-by:
-
Rajkumar Manoharan authored
Whenever RXEOL is received, both RXORN and RXEOL got cleared to avoid rx overrun interrupt storm. This was handled only for edma chips. The same scenario was also observered with AR9280, doing frequent channel type switch b/w HT20/40 with bidi traffic that is causing failure to stop rx dma. This patch clears the RXEOL & RXORN interrupts for all chips. ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x000062c0 ath: Could not stop RX, we could be confusing the DMA engine when we start RX up ------------[ cut here ]------------ WARNING: at drivers/net/wireless/ath/ath9k/recv.c:532 ath_stoprecv+0x110/0x120 [ath9k]() Call Trace: [<ffffffff8104a55a>] warn_slowpath_common+0x7a/0xb0 [<ffffffff8104a5a5>] warn_slowpath_null+0x15/0x20 [<ffffffffa0560380>] ath_stoprecv+0x110/0x120 [ath9k] [<ffffffffa055e6fa>] ath_reset+0x6a/0x200 [ath9k] Signed-off-by:
-
