- 24 Aug, 2011 40 commits
-
-
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: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> 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: John W. Linville <linville@tuxdriver.com>
-
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 <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 Carpenter <error27@gmail.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
They were taken from MMIO dump with few RegExps and vim. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <zajec5@gmail.com> 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: John W. Linville <linville@tuxdriver.com>
-
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 <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Michael Buesch <m@bues.ch> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k/dump_nfcal Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
The chainmasks were already configured at process_ini before doing init calibration. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
The WAR which adds extra delimiters when using RTS/CTS with aggregation and non-enterprise AR9003 chips. This extra padding is done after doing all the 4ms limit checks and hence the total aggregate sizes are exceeding the allowed duration. This patch limits the aggregate sizes appropriately after including these extra delimiters. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
Allow userspace to set NL80211_MESHCONF_GATE_ANNOUNCEMENTS attribute, which will advertise this mesh node as being a mesh gate. NL80211_HWMP_ROOTMODE must be set or this will do nothing. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
Allow userspace to set Root Announcement Interval for our mesh interface. Also, RANN interval is now in proper units of TUs. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
This fix allows userspace to mark a meshif as a root node. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
In this implementation, a mesh gate is a root node with a certain bit set in its RANN flags. The mpath to this root node is marked as a path to a gate, and added to our list of known gates for this if_mesh. Once a path discovery process fails, we forward the unresolved frames to a known gate. Thanks to Luis Rodriguez for refactoring and bug fix help. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
Previously, mpaths were never flushed since the mpath is not active once we call this function. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
mesh_queue_preq is invoked invoked from both user (work queue) and softirq (timer) context, so the _bh version of spinlock needs to be used. Also, the mpath->state_lock should be softirq safe as well. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
If we have an mpath whose timer has not been initialized, don't try to delete it. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-