- 24 Oct, 2012 7 commits
-
-
Kalle Valo authored
ATH6KL_FW_CAPABILITY_STA_P2PDEV_DUPLEX was checked in cfg80211.c which is a bit awkward when adding more callsites to the scan functions. Refactor the code to wmi.c so that it's transparent to the callers. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Kalle Valo authored
To make it easier to refactor the scan commands move ath6kl_wmi_startscan_cmd() before the beginscan function. No functional changes. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Thomas Pedersen authored
The ath6kl firmware can monitor a connection and report when a certain TX failure threshold is crossed. Support this configuration and event reporting on compatible firmwares. Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Bala Shanmugam authored
Add support for AR6004 hardware with version 1.3 and has id 0x31c8088a. Signed-off-by: Bala Shanmugam <bkamatch@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Pandiyarajan Pitchaimuthu authored
In ath6kl_read_fwlogs(), return value from ath6kl_diag_read()is not used to bail out in case of any errors in reading fw log. No real issue is observed because of this, reported by source code analyzer. kvalo: fix a long line warning Signed-off-by: Pandiyarajan Pitchaimuthu <c_ppitch@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Aarthi Thiruvengadam authored
Firmware and driver generate MAC addresses for the second and third interfaces. In addition to the existing algorithm, flip bit 7 of 5th octet. Since both firmware and driver individually generate the MAC addresses, introduce a new firmware capability bit to keep them compatible. Signed-off-by: Aarthi Thiruvengadam <athiruve@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Thomas Pedersen authored
The ath6kl firmware can filter scan results based on rssi. This is useful to limit hosts wakeups on scheduled scans. Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
- 23 Oct, 2012 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessJohn W. Linville authored
Conflicts: drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c net/mac80211/mlme.c
-
- 19 Oct, 2012 32 commits
-
-
Alan Cox authored
It's not used or called but please make it go away before someone copies or uses it Signed-off-by: Alan "minus lunch" Cox <alan@linux.intel.com> Acked-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
The parameter buflen is unsigned so the condition buflen < 0 is always false. The patch fixes the if statement checking the buffer length. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Franky Lin authored
Following sparse warning is fixed: drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:2518:21: warning: symbol 'brcmf_find_wpaie' was not declared. Should it be static? drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:3768:1: warning: symbol 'brcmf_set_management_ie' was not declared. Should it be static? Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
Sparse complains that we use zero instead of NULL here. In fact, the initialization is wrong and should be removed. Doing these kinds of bogus initializations means that GCC can't detect unitialized variables and leads to bugs. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
As of now the ANI cycle is executed only when the chip is awake. On idle state case, the station wakes up from network sleep for beacon reception. Since most of the time, ANI cycle is not syncing with beacon wakeup, ANI cycle is ignored. Approx 5 mins once, the calibration is performed. This could affect the connection stability when the station is idle for long. Even though the OFDM and CCK phy error rates are too high, ANI is unable to tune its immunity level as quick enough due to rare execution. Here the experiment shows that OFDM and CCK levels are at default even on higher phy error rate. listenTime=44 OFDM:3 errs=121977/s CCK:2 errs=440818/s ofdm_turn=1 This change ensures that ANI calibration will be exectued atleast once for every 10 seconds. The below result shows improvements and immunity levels are adopted quick enough. listenTime=557 OFDM:4 errs=752/s CCK:4 errs=125/s ofdm_turn=0 Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch changes the way the driver deals with command responses and traps which are sent through the special interrupt input endpoint 3. While the carl9170 firmware does not use this endpoint for command responses or traps, the firmware loader on the device does. It uses it to notify the host about 'watchdog triggered' in case the firmware/hardware has crashed. Note: Even without this patch, the driver is still able to detect the mishap and reset the device. But previously it did that because the trap event caused an out-of-order message sequence number error, which also triggered a reset. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Andrei Emeltchenko authored
Make output more readable and remove unneeded function call. ... mwifiex_sdio mmc0:0001:1: last_cmd_index = 3 last_cmd_id: 00000000: 16 00 cd 00 83 00 df 00 28 00 ........(. ... would be changed to: ... mwifiex_sdio mmc0:0001:1: last_cmd_index = 3 mwifiex_sdio mmc1:0001:1: last_cmd_id: 16 00 cd 00 83 00 df 00 28 00 ... Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
DBG_CMD_NUM is the number of commands, not the actual bytes of data for printing. Also remove the duplicated DBG_CMD_NUM definition. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Some rt2800 devices don't have their calibrated max eirp tx power in their calibration data. For those devices reduce tx power according to difference between regulatory max channel power and requested tx power. This patch is based on Helmut Schaa work. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Preparation for use regulatory max channel power in TX power delta calculations. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Don use TX_PWR_CFG_0 register value of OFDM 6M tx power as criterion since it can be changed. The same do vendor driver (see AsicAdjustSingleSkuTxPower and AsicGetTxPowerOffset functions from 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
We skip compensate calculation for non 11b rates on 2.4GHz band. I do not see that on vendor driver (2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Based on AsicAdjustTxPower function from vendor driver (2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO) limit per rate TX power values we program into TX_PWR_CFG_ registers. Note that on some configurations (devices/rates) is allowed to use bigger values than 0xc, but we use safe maximum value for now. Further work need to be done to allow use bigger values than 0xc. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
TX power delta can be negative. TX_PWR_CFG_ registers allow to set delta only in range between 0 dBm and 15 dBm (4 bits for each rate). Se we need to use BBP_R1 to configure negative deltas. Not utilize +6 dBm increasing BBP_R1 option for safety reason. For now, this can be used for devices, which export maximum allowed TX power value. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sven Eckelmann authored
All defines for REG_WRITE in Atheros wireless drivers use the order "ah", "register" and "value". hw.c is the only file using the order "ah", "value" and "register". drivers/net/wireless/ath/ath9k/hw.h:#define REG_WRITE(_ah, _reg, _val) \ drivers/net/wireless/ath/key.c:#define REG_WRITE(_ah, _reg, _val) (common->ops->write)(_ah, _val, _reg) This inconsistent definition can easily lead to implementation errors. The modification doesn't change the behavior of the driver or the generated code. Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Andy Shevchenko authored
The patch changes a bit trace output format in the rtl_cam_program_entry() to print prefix and the actual data on the same line. Moreover the %*phC outputs each byte as 2 hex digits, which is slightly different to the original %x. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> ACKed-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
In ezusb_read_ltv() we had a comparison "(bufsize < 0)" which was never true because bufsize was unsigned. I looked at the implications of that. If we passed a negative number to ezusb_access_ltv() then it would be used as the size parameter of the memcpy() because that function uses min_t(int, exp_len, ans_size). But fortunately when I looked at the callers, bufsize is not controlled by the user and it's never negative. So these signedness mistakes have no impact. I removed the always false check from ezusb_read_ltv() and I changed the types in ezusb_access_ltv() and made the variables unsigned. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Before it was tried to initialize the deactivated PCIe core in client mode, but this causes the SoC to hang. Just do not initialize it at all and ignore the core it is not working and nothing is connected to it when the specific bit is set in the boardflags. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Peter Senna Tschudin authored
This patch remove a semicolon after if(...) that is preventing the error check to work correctly. Removing this semicolon will change the code behavior, but this is intended. The semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r1@ position p; @@ if (...);@p @script:python@ p0 << r1.p; @@ // Emacs org-mode output cocci.print_main("", p0) cocci.print_secs("", p0) // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
BT_OP_SCAN is applicable only for pre-MCI WLAN/BT combo chips and using it for MCI-based cards is incorrect. Fix this by cleaning up its usage. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
The BCM4706 has two PCIe host controller on the bcma bus. For PCIe client mode it is assumed that there is only one PCIe controller so the PCIe driver, like b43 and brcmsmac are accessing the first PCIe controller when they want to issue a operation on the host controller. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Sometimes the PCIe card indicates that it has a sprom somewhere and we are able to read the memory region, but it is empty and not valid. In these cases we should try to use the fallback sprom as a last chance. This is the case for the PCIe cards in my ASUS RT-N66U (BCM4706 + 2 times BCM4331) and I have heard of someone having the same problem with an other PCIe card connected to an other Broadcom SoC. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
This is a preparing step for adding serial flash support. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
This makes the code more readable Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
There are some devices which are able to boot from nand flash and other are using a serial flash for booting. Add a bool to indicate that the device is booted from that flash chip and not from some other chip also connected to the SoC. This is needed to find the nvram, as it is stored on the flash the devices booted from. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
The PCIe host driver and the chip common initialisation accesses the sprom struct, but it is not initialized when these functions are run. Move the sprom parsing up in to do it earlier. As we need the chip common core rev and some other attributes from the chip common core, the early initialization is done before accessing the sprom. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-