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: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Preparation for use regulatory max channel power in TX power delta
calculations.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Acked-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
ACKed-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The include file linux/ieee80211.h contains three definitions for
the same thing in enum ieee80211_eid due to historic changes:

/* Information Element IDs */
enum ieee80211_eid {
    :
    WLAN_EID_WPA = 221,
    WLAN_EID_GENERIC = 221,
    WLAN_EID_VENDOR_SPECIFIC = 221,
    :
};

The standard refers to this as "vendor specific" element so the
other two definitions are better not used. This patch changes the
wireless drivers to use one definition, ie. WLAN_EID_VENDOR_SPECIFIC.

Cc: Jouni Malinen <j@w1.fi>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> [ipw2x00]
Signed-off-by: NArend van Spriel <arend@broadcom.com>
[change libipw as well]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The next patch will introduce a flag that is set
by default in cfg80211 so drivers and mac80211
need to use |= to set features they have so that
they don't clear the already-set feature.

We could set the flag in wiphy_register() instead
of wiphy_new() to avoid this patch, but then the
drivers couldn't *unset* flags they don't want to
use even though the implementation is generic.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This can happen when we shut down suddenly an interface.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Once in bus enumeration is enough, no need to print it
again when the op_mode loads.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Doing the opposite is wrong, the SCD wouldn't like someone
to clear its data while the queue is still active.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of hardcoding the expression, use the macro
provided in the previous patch.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When we disable a queue, we don't want the SCD to remember anything
about this queue (what packet was transmitted but not acked, what
packed was acked etc...).
Wipe out all this data in its SRAM.

Constify the arguments to iwl_write_targ_mem_dwords on the way.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove a number of variables that are assigned, but not used.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When tracing in iwlwifi, we get all data. Most of
the time, we don't need it, and it just takes up
a lot of extra space in the trace.

Make this optional by recording the data into two
separate trace events if it is needed. Without it,
record only the content of non-data and EAPOL TX
frames.

As a result, tracing without the data tracepoints
will record meta information including the 802.11
headers for all frames but will not record the
contents of data frames to reduce trace overhead.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When warning about a command that is too large,
print out the command name/ID to help figure
out which place is attempting to send a command
that is too large.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch fixes the following bug:

usb 1-1.1: restart device (8)
BUG: sleeping function called from invalid context at drivers/usb/core/urb.c:654
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
 (usb_poison_urb+0x1c/0xf8)
 (usb_poison_anchored_urbs+0x48/0x78)
 (carl9170_usb_handle_tx_err+0x128/0x150)
 (carl9170_usb_reset+0xc/0x20)
 (carl9170_handle_command_response+0x298/0xea8)
 (carl9170_usb_tasklet+0x68/0x184)
 (tasklet_hi_action+0x84/0xdc)

this only happens if the device is plugged in an USB port,
the driver is loaded but inactive (e.g. the wlan interface
is down). If the device is active everything is fine.
Signed-off-by: NRonald Wahl <ronald.wahl@raritan.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The dereference should be moved below the NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Driver gets LINK_LOST, DEAUTHENTICATED and DISASSOCIATED events
from firmware when connection is lost in different scenarios.
Currently we are using common code WLAN_REASON_DEAUTH_LEAVING
for these cases.

This patch adds support to parse an actual reason code from
firmware event body and send it to cfg80211.
WLAN_REASON_DEAUTH_LEAVING code is used if deauth is initiated
by our device.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds support to send correct reason code got from
firmware when association attempt fails. Also, the error message
displayed for association failure due to network incompatibility
is modified. Current message "cannot find ssid.." misleads user.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

scan_processing flag should be reset when scan request is failed
due to some reasons Ex. memory allocation failure etc. Otherwise
further scan requests will be blocked.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are cases we cannot scan when request is received.
For example, during WPA group key negociation the scan request
will be blocked. We should return an error code to cfg80211
because cfg80211_scan_done will never be called.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NPaul Stewart <pstew@chromium.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This should be register 66 instead of 62.
(probably happened by copy&past'ing from the lines below)
Signed-off-by: NDaniel Golle <dgolle@allnet.de>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Using ieee80211_free_txskb for tx frames is required, since mac80211 clones
skbs for which socket tx status is requested.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Ensure that drv_start() always returns true, as a failing hw start usually
eventually leads to crashes when there's still a station entry present.
Call a power-on reset after a resume and after a hw reset failure to bring
the hardware back to life again.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath_pci_aspm_init is only called on card init, so PCI registers get reset
after a suspend/resume cycle.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The WLAN/BT weights have to set correctly before BTCOEX
is initialized. Currently, this is not done for all chips
in the AR9003 family. This patch fixes this issue by setting
the weights in the init path. While at it, rename ar9462_wlan_weights
to mci_wlan_weights since it is common to both AR9462 and AR9565.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Convert cpu_to_le16(le16_to_cpu(E1) + E2) to use le16_add_cpu().

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>