some times the rssi control descriptor for the main antenna may be
negative like that of alternate antenna, hence before  incrementing
packet counts/rssi of main/alternate antenna make sure both main_rssi
and alt_rssi are positive only. this avoids wrong selection of antenna
due to diversity

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

configure fast diversity bias based on the antenna diversity group and
based on main/alt LNA configurations. also configure main antenna and
alternate antenna to gain-table 0 for diversity group 2(AR9485)

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

for the diversity group 2(AR9485) we swap the LNA's of main/ALT antenna
based on alternate antenna's rssi average in comparision with main
antenna's rssi, while for AR9285(antenna diversity group 0)we still
follow the older method of looking at the packet count in alternate
antenna

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

AR9285 belongs to diversity group 0 and AR9485 belongs to diversity
group 2. Based on the diversity group we configure certain antenna
diversity paramaters such as lna1_lna2_delta and fast diversity
bias values. For AR9485 we have some gain table parameter which
selects the gain table 0/1 for main and alternate antenna

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

these are the two important modules that will be called by the antenna
diversity algorithm module in the rx. this will continuosly configure
the hardware based on the current diversity status obtained
from the algorithm

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

* enable LNA-diversity, fast-diversity for AR9485 based  on
  the value read from EEPROM content
* if antenna diversity/combining is supported, set LNA1 for the main
  antenna and LNA2 for the alternate antenna based on the new diversity
  algorithm

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

define few registers and macros to configure/enable Antenna diversity
parameters in AR9485

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

read antenna diversity and combining information from the EEPROM.
Enable antenna diversity/combining feature only when both LNA
diversity and fast diversity are supported

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Tested-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

this is necessary to support Antenna diversity and combining in new chip
sets such as AR9485, previously Antenna diversity support is available
only in AR9285

Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The list_for_each_entry loop can fail, in which case the list element is
not removed from the list rfkill_fds.  Since this list is not accessed by
the loop, the addition of &data->list into the list is just moved after the
loop.

The sematic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression E,E1,E2;
identifier l;
@@

*list_add(&E->l,E1);
... when != E1
    when != list_del(&E->l)
    when != list_del_init(&E->l)
    when != E = E2
*kfree(E);// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This adds sparse RCU annotations to most of
mac80211, only the mesh code remains to be
done.

Due the the previous patches, the annotations
are pretty simple. The only thing that this
actually changes is removing the RCU usage of
key->sta in debugfs since this pointer isn't
actually an RCU-managed pointer (it only has
a single assignment done before the key even
goes live). As that is otherwise harmless, I
decided to make it part of this patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

During my quest to make mac80211 not have any RCU
warnings from sparse, I came across the a-MPDU code
again and it wasn't quite clear why it isn't racy.
So instead of assigning the tid_tx array with just
the spinlock held in ieee80211_start_tx_ba_session
use a separate temporary array protected only by
the spinlock and protect all assignments to the
"live" array by both the spinlock and the mutex so
that other code is easily verified to be correct.

Due to pointer assignment atomicity I don't think
this is a real issue, but I'm not sure, especially
on Alpha the current code might be problematic.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add the ability to advertise interface combinations in nl80211.
This allows the driver to indicate what the combinations are
that it supports. "Combinations" of just a single interface are
implicit, as previously. Note that cfg80211 will enforce that
the restrictions are met, but not for all drivers yet (once all
drivers are updated, we can remove the flag and enforce for all).

When no combinations are actually supported, an empty list will
be exported so that userspace can know if the kernel exported
this info or not (although it isn't clear to me what tools using
the info should do if the kernel didn't export it).

Since some interface types are purely virtual/software and don't
fit the restrictions, those are exposed in a new list of pure SW
types, not subject to restrictions. This mainly exists to handle
AP-VLAN and monitor interfaces in mac80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following
warning:

In file included from arch/x86/include/asm/uaccess.h:573,
                 from include/net/checksum.h:25,
                 from include/linux/skbuff.h:28,
                 from drivers/net/wireless/iwlwifi/iwl-agn-rs.c:28:
In function 'copy_from_user',
    inlined from 'rs_sta_dbgfs_scale_table_write' at
    drivers/net/wireless/iwlwifi/iwl-agn-rs.c:3099:
arch/x86/include/asm/uaccess_64.h:65:
warning: call to 'copy_from_user_overflow' declared with
attribute warning: copy_from_user() buffer size is not provably
correct

presumably due to buf_size being signed causing GCC to fail to
see that buf_size can't become negative.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following
warning:

In file included from arch/x86/include/asm/uaccess.h:573,
                 from include/net/checksum.h:25,
                 from include/linux/skbuff.h:28,
                 from drivers/net/wireless/iwlegacy/iwl-4965-rs.c:28:
In function 'copy_from_user',
    inlined from 'iwl4965_rs_sta_dbgfs_scale_table_write' at
    drivers/net/wireless/iwlegacy/iwl-4965-rs.c:2616:
arch/x86/include/asm/uaccess_64.h:65:
warning: call to 'copy_from_user_overflow' declared with
attribute warning: copy_from_user() buffer size is not provably
correct

presumably due to buf_size being signed causing GCC to fail to
see that buf_size can't become negative.

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/ssb/main.c:1336: error: 'SSB_PCICORE_BCAST_ADDR' undeclared (first use in this function)
drivers/ssb/main.c:1337: error: 'SSB_PCICORE_BCAST_DATA' undeclared (first use in this function)
drivers/ssb/main.c:1349: error: 'struct ssb_pcicore' has no member named 'dev'
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When operating as station, enter psm before suspending
the device into wowlan state.

Add a new completion event to signal when psm was entered
successfully.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Since wowlan requires the ability to stay awake while the host
is suspended, declare support for NL80211_WOW_TRIGGER_ANYTHING
if the MMC_PM_KEEP_POWER capability is being supported.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

When WoW is enabled, the interface will stay up and the chip will
be powered on, so we have to flush/cancel any remaining work, and
prevent the irq handler from scheduling a new work until the system
is resumed.

Add 2 new flags:
* WL1271_FLAG_SUSPENDED - the system is (about to be) suspended.
* WL1271_FLAG_PENDING_WORK - there is a pending irq work which
   should be scheduled when the system is being resumed.

In order to wake-up the system while getting an irq, we initialize
the device as wakeup device, and calling pm_wakeup_event() upon
getting the interrupt (while the system is about to be suspended)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

if a wow trigger was configured, set the MMC_PM_KEEP_POWER flag
on suspend, so our power will be kept while the system is suspended.

We needed to set this flag on each suspend attempt (when we want
to keep power)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Additionally, add wow_enabled field to wl, to indicate
whether wowlan was configured.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

set the sdio interrupt as wake_up interrupt, so we will be able
to wake up the suspended system (Wake-On-Wireless)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

This flag is not used anymore, remove it from the list.
Signed-off-by: Luciano Coelho <coelho@ti.com>

The current firmware only supports scheduled scan in station mode and
when idle.  To prevent the firmware from crashing, return -EOPNOTSUPP
when sched_scan start is called in an invalid state.
Signed-off-by: Luciano Coelho <coelho@ti.com>

Add the sched_scanning value to the driver_status debugfs entry.
Signed-off-by: Luciano Coelho <coelho@ti.com>

This patch adds the mac80211 operations for scheduled scan and the
scheduled scan results reporting.
Signed-off-by: Luciano Coelho <coelho@ti.com>

Add firmware command structures, definitions and code to to configure,
start and stop scheduled scans.
Signed-off-by: Luciano Coelho <coelho@ti.com>

Subscribe and listen to PERIODIC_SCAN_REPORT_EVENT_ID and
PERIODIC_SCAN_COMPLETE_EVENT_ID in preparation for the scheduled scan
implementation.
Signed-off-by: Luciano Coelho <coelho@ti.com>

Add the structures and values for driver-configured scheduled scan
parameters.
Signed-off-by: Luciano Coelho <coelho@ti.com>

Set the spectrum management bit in the hw flags so that mac80211 will
set the WLAN_CAPABILITY_SPECTRUM_MGMT bit in association requests
(which in practice means that we support 802.11h spectrum management).

[Reworded the commit log -- Luca.]
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

This patch adds a beacon filter rule to pass up the beacons that
contain changed HT information elements.  These beacons need to be
passed to mac80211 so that it can act on such changes.

[Reworded commit log -- Luca.]
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Simplify wl1271_ssid_set by re-using cfg80211_find_ie instead of
reimplementing it.

Additionally, add a length check to prevent a potential buffer overflow.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

There's no need to have table functions in one
file and all users in another, move the functions
to the right file and make them static. Also move
a static variable to the beginning of the file to
make it easier to find.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When sched_scan_stopped was called by the driver, mac80211 calls
cfg80211, which in turn was calling mac80211 back with a flag
"driver_initiated".  This flag was used so that mac80211 would do the
necessary cleanup but would not call the driver.  This was enough to
prevent the bounce back between the driver and mac80211, but not
between mac80211 and cfg80211.

To fix this, we now do the cleanup in mac80211 before calling
cfg80211.  To help with locking issues, the workqueue was moved from
cfg80211 to mac80211.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

A few configuration functions correctly do
rcu_read_lock() but don't correctly reference
some pointers protected by RCU. Fix that.

Cc: stable@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The code here is only not racy because all the
places that assign the pointers it uses are
holding the sta_mtx as well as the key_mtx and
so can't race against this because this code
holds the sta_mtx. But that's not intuitive,
so fix it to hold the key_mtx.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The code in ieee80211_del_key() doesn't acquire the
key_mtx properly when it dereferences the keys. It
turns out that isn't actually necessary since the
key_mtx itself seems to be redundant since all key
manipulations are done under the RTNL, but as long
as we have the key_mtx we should use it the right
way too.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The code here to RCU-dereference a pointer that's
on the stack is totally pointless, RCU isn't magic
(like say Java's weak references are), so the code
can't work like whoever wrote it thought it might.

Remove it so readers don't get confused. Note that
it seems that a bug is there anyway: I don't see
any code that cancels the timer when a mesh path
struct is destroyed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

XB113 (AR9380) 3x3 SB 5G only cards were failing to connect to APs
due to incorrect xpabiaslevel configuration. fix it.

Cc: stable@kernel.org
Cc: Ray Li <ray.li@greenwavereality.com>
Cc: Kathy Giori <kathy.giori@atheros.com>
Cc: Aeolus Yang <aeolus.yang@atheros.com>
Cc: compat@orbit-lab.org
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>