- 11 Dec, 2012 5 commits
-
-
Gabor Juhos authored
Due to my recent commit (ath9k: allow to load EEPROM content via firmware API) smatch complains about that the 'pdata' variable in 'ath9k_hw_init' can be NULL and it is dereferenced before checking that. That is absolutely correct. Check the 'pdata' variable before using it to avoid a NULL pointer dereference. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Thomas Pedersen authored
This is true for at least AR5213, and shouldn't be different for other ath5k PHYs. Tested on AR2413 and AR5414. Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Tested-by:
Bob Copeland <me@bobcopeland.com> Acked-by:
Nick Kossifidis <mickflemm@gmail.com> Signed-off-by:
-
Thomas Pedersen authored
Accurate RX timestamp reporting is important for proper IBSS merging, mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF is recorded is needed to sync with the beacon timestamp field. Tested with AR9271. Signed-off-by:
-
Thomas Pedersen authored
Accurate RX timestamp reporting is important for proper IBSS merging, mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF is recorded is needed to sync with the beacon timestamp field. Tested with AR9280. Signed-off-by:
-
John W. Linville authored
Someone who physically disassembled the device confirms that its chipset is Ralink RT5370n. (Fixed-up after having already merged original patch. -- JWL) Signed-off-by:
Maia Kozheva <sikon@ubuntu.com> Reviewed-by:
Xose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by:
-
- 10 Dec, 2012 35 commits
-
-
Felix Fietkau authored
ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for tx packets passed to the driver from mac80211 Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Felix Fietkau authored
ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for tx packets passed to the driver from mac80211 Signed-off-by:
-
Gabor Juhos authored
The calibration data for devices w/o a separate EEPROM chip can be specified via the 'eeprom_data' field of 'ath9k_platform_data'. The 'eeprom_data' is usually filled from board specific setup functions. It is easy if the EEPROM data is mapped to the memory, but it can be complicated if it is stored elsewhere. The patch adds support for loading of the EEPROM data via the firmware API to avoid this limitation. Signed-off-by:
-
Gabor Juhos authored
The 'ath9k_hw_nvram_read' function takes a 'struct ath_common *' as its first argument. Almost each of its caller has a 'struct ath_hw *' parameter in their argument list, and that is dereferenced in order to get the 'struct ath_common' pointer. Change the first argument of 'ath9k_hw_nvram_read' to be a 'struct ath_hw *', and remove the dereference calls from the callers. Also change the type of the first argument of the ar9300_eeprom_read_{byte,word} functions. Signed-off-by: -
Gabor Juhos authored
Show the EEPROM offset of the failed read operation in 'ath9k_hw_nvram_read'. The debug message is more informative this way. Signed-off-by:
-
Gabor Juhos authored
The fill_eeprom functions are printing the same debug message in case the 'ath9k_hw_nvram_read' function fails. Remove the duplicated code from fill_eeprom functions and add the ath_dbg call directly into 'ath9k_hw_nvram_read'. Signed-off-by:
-
Felix Fietkau authored
While AR_PHY_CCA_NOM_VAL_* does contain the expected internal noise floor for a chip measured in clean air, it refers to the lowest expected reading. Depending on the frequency, this measurement can vary by about 6db, thus causing a higher reported channel noise and signal strength. Factor in the 6db offset when converting internal noisefloor to channel noise. This patch makes the reported values more accurate for all chips without affecting NF calibration behavior. Signed-off-by:
-
Rafał Miłecki authored
We were using wrong IRQ number so clearing wasn't working at all. Depending on a platform this could result in a one device having two interrupts assigned. On BCM4706 this resulted in all IRQs being broken. Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: stable@vger.kernel.org Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
Assign the training power for PAPRD based on the chip. Signed-off-by:
-
Sujith Manoharan authored
Add a HW capability to indicate whether PAPRD is enabled for the card, since PAPRD could be enabled in the EEPROM, but disabled in the driver. This makes things clearer. Signed-off-by:
-
Sujith Manoharan authored
Retraining of PAPRD based on agc2_pwr is required for chips other than AR9485. Signed-off-by:
-
Sujith Manoharan authored
* Remove unneeded memset. All the values in the PAPRD gain table are filled, so there is no need to zero out the arrays. * Use GFP_KERNEL in ar9003_paprd_create_curve This is called from the PAPRD work, so the atomic variant is not needed. * Change return type of ar9003_paprd_setup_gain_table Signed-off-by:
-
Sujith Manoharan authored
Move the PowerSave wrappers outside ath_paprd_activate(), since they are already being used in ath_paprd_calibrate(). Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
-
Sujith Manoharan authored
The PAPRD training control registers have to be programmed with values that depend on the chip. This patch ensures that the correct values are chosen for the chip in use. Signed-off-by:
-
Sujith Manoharan authored
Various PAPRD registers are at addresses that are different from those for the rest of the chips in the AR9003 family. Fix them. Signed-off-by:
-
Gabor Juhos authored
Trying to access the OTP memory on the AR9340 causes a data bus error like this: Data bus error, epc == 86e84164, ra == 86e84164 Oops[#1]: Cpu 0 $ 0 : 00000000 00000061 deadc0de 00000000 $ 4 : b8115f18 00015f18 00000007 00000004 $ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c $12 : 7c7c3c7c 001f0041 00000000 7c7c7c3c $16 : 86ee0000 00015f18 00000000 00000007 $20 : 00000004 00000064 00000004 86d71c44 $24 : 00000000 86e6ca00 $28 : 86d70000 86d71b20 86ece0c0 86e84164 Hi : 00000000 Lo : 00000064 epc : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Tainted: G O ra : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Status: 1100d403 KERNEL EXL IE Cause : 4080801c PrId : 0001974c (MIPS 74Kc) Modules linked in: ath9k(O+) ath9k_common(O) ath9k_hw(O) ath(O) ar934x_nfc mac80211(O) usbcore usb_common scsi_mod nls_base nand nand_ecc nand_ids crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_blkcipher cryptomgr aead crypto_hash crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio Process insmod (pid: 459, threadinfo=86d70000, task=87942140, tls=779ac440) Stack : 802fb500 000200da 804db150 804e0000 87816130 86ee0000 00010000 86d71b88 86d71bc0 00000004 00000003 86e9fcd0 80305300 0002c0d0 86e74c50 800b4c20 000003e8 00000001 00000000 86ee0000 000003ff 86e9fd64 80305300 80123938 fffffffc 00000004 000058bc 00000000 86ea0000 86ee0000 000001ff 878d6000 99999999 86e9fdc0 86ee0fcc 86e9e664 0000c0d0 86ee0000 0000700000007000 ... Call Trace: [<86e84164>] ath9k_hw_wait+0x58/0xb0 [ath9k_hw] [<86e9fcd0>] ath9k_hw_setup_statusring+0x16b8/0x1c7c [ath9k_hw] Code: 0000a812 0040f809 00000000 <00531024> 1054000b 24020001 0c05b5dc 2404000a 26520001 The cause of the error is that the OTP register offsets are different on the AR9340 than the actually used values. Cc: <stable@vger.kernel.org> # 3.0+ Signed-off-by: -
Maia Kozheva authored
D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a Ralink chipset supported by the rt2800usb driver. Currently, to work around the problem (it's missing in all present kernel versions, up to and including 3.7.x), I had to add this to /etc/rc.local: echo 2001 3c1e >> /sys/bus/usb/drivers/rt2800usb/new_id After that, the device works without problems. Been using it for over a week with no bugs in sight. The attached patch is trivial and simply adds the new USB ID to the list of devices handled by rt2800usb. Signed-off-by:
-
Cong Ding authored
Use WARN rather than printk followed by WARN_ON(1), for conciseness. Signed-off-by:
Cong Ding <dinggnu@gmail.com> Signed-off-by:
-
Christian Lamparter authored
This patch fixes a regression which was introduced by: "carl9170: split up carl9170_handle_mpdu" Previously, the ieee80211_rx_status was kept on the stack of carl9170_handle_mpdu. Now it's passed into the function as a pointer parameter. Hence, the old memcpy call needs to be fixed. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Hauke Mehrtens authored
This device can be found on some embedded devices connected to a Broadcom SoC like the BCM4718. I tested this with my Netgear WNDR3400 v1. Signed-off-by:
-
Hauke Mehrtens authored
As described in the documentation of bcma_wflush16 in drivers/net /wireless/brcm80211/brcmsmac/types.h some PCIe controllers of Broadcom SoCs are broken. The PCIe controller on these SoCs are mostly used to connect some additional wifi device to the SoC and some of these wifi devices are supported by brcmsmac. For my BCM43224 connected to the broken PCIe controller of the BCM4718 I need an extra read after write in brcms_b_write_objmem() to prevent a Data bus error. This fixes the problem reading tsf_random later. Signed-off-by:
-
Sujith Manoharan authored
Commit "ath9k: Fix the 'xmit' debugfs file" changed the the array size of ath_stats.txstats to IEEE80211_NUM_ACS, which is wrong because the HW queue number is used to update the statistics. Revert back to using ATH9K_NUM_TX_QUEUES. Reported-by:
-
Rafał Miłecki authored
Signed-off-by: -
Larry Finger authored
Recent versions of udev cause synchronous firmware loading from the probe routine to fail because the request to user space times out. The original fix for b43legacy (commit a3ea2c76) moved the firmware load from the probe routine to a work queue, but it still used synchronous firmware loading. This method is OK when b43legacy is built as a module; however, it fails when the driver is compiled into the kernel. This version changes the code to load the initial firmware file using request_firmware_nowait(). A completion event is used to hold the work queue until that file is available. The remaining firmware files are read synchronously. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> (V3.4+) Signed-off-by:
-
Hauke Mehrtens authored
This adds support for bcma wifi core revision 17 which is found on BCM4716/4717/4718 SoCs. The firmware version 610.812 for brcmsmac found in linux-firmware does not support these cores, but a firmware generated with b43-fwcutter from the proprietary broadcom wireless driver works with these chips. This wifi core contains a revision 5 N-PHY and a revision 7 radio of type 0x2056. Signed-off-by:
-
Felix Fietkau authored
This reverts commit f74b9d36. Turns out reverting commit a240dc7b "ath9k_hw: Updated AR9003 tx gain table for 5GHz" was not enough to bring the tx power back to normal levels on devices like the Buffalo WZR-HP-G450H, this one needs to be reverted as well. This revert improves tx power by ~10 db on that device Signed-off-by:
-
Arend van Spriel authored
Get rid of WL_CONN(...) macro in favor of brcmf_dbg(CONN,...) Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
Get rid of WL_SCAN(...) macro in favor of brcmf_dbg(SCAN,...) Reviewed-by:
-
Arend van Spriel authored
Get rid of WL_TRACE(...) macro in favor of brcmf_dbg(TRACE,...) Reviewed-by:
-
Arend van Spriel authored
Get rid of WL_INFO() in favor of brcmf_dbg(INFO,...). Reviewed-by:
-
Arend van Spriel authored
Getting rid of wl_cfg80211 specific error log macro. Reviewed-by:
-
Arend van Spriel authored
The source file wl_cfg80211.c has its own debug macros and levels. This patch maps the macros to the ones used in the rest of the brcmfmac driver. Reviewed-by:
-
Arend van Spriel authored
The call to brcmf_dbg(ERROR, ...) only resulted in a log message when compiled with -DDEBUG. Error messages are valuable for resolving issues so this patch replaces it with brcmf_err(...) so they always end up in the log. Reviewed-by:
-
