Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The changes that were made to rtl8192ce when rtl8192cu was added broke
HT40. The errors included a typo in rtlwifi, a missing routine in
rtl8192ce and a missing callback of that routine in rtl8192c-common.

This patch fixes the regression reported in Bug #35082.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In order to provide multiple interfaces for a single device,
the driver will be required to advertise all possible
interface configurations to the stack.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We free name "dev" for something generic (like dev abstraction layer).
Additionaly code is cleaner now, especially magic dev->dev-dev chains.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* use proc_mkdir_mode() instead of create_proc_entry(S_IFDIR|...),
  export proc_mkdir_mode() for that, oh well.
* don't supply S_IFREG to proc_create_data(), it's unnecessary
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: <stable@kernel.org>
Reported-by: NMark Davis <marked86@gmail.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mwifiex was using its own implementation of converting 802.11n
AMSDU to 802.3s.  This patch removes mwifiex specific
implementation and uses existing ieee80211_amsdu_to_8023s
routine.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the devices that have already stripped IEEE 802.11
header from the AMSDU SKB can not use ieee80211_amsdu_to_8023s
routine. This patch enhances ieee80211_amsdu_to_8023s() API by
changing mandatory removing of IEEE 802.11 header from AMSDU
to optional.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

we are not doing anything by tracking the number of pending frames.
bail out when we first find a pending frame in any one of the 10 queues.
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn 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: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn 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: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

old_assoc not used, remove it
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When the PAN context is active, but unused, it
may still block scans that take more dwell time
than its beacon interval (which is odd). Work
around this problem by using a default beacon
interval of 200 so scans will fit between.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

gcc is warning that a few variables in rate
scaling are set but never otherwise used.
This pointed out a few simplifications.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Before send the RXON command with associated flag set, always do disassociate
first to make sure uCode is in the correct state.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If fail to enqueue host command, clear the STATUS_hcmD_ACTIVE bit
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Add support in testmode for setting fixed rate
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Add the capability to dump eeprom through testmode request
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Adding testmode trace/debug capability
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

No functional changes, just logging more information when uCode crash, also
change change the format.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The current "huge" command handling is a bit
confusing, and very limited since only one
command may be huge at a time. Additionally,
we often copy data around quite pointlessly
since we could instead map the existing scan
buffer for example and use it directly.

This patch makes that possible. The first
change is that multiple buffers may be given
to each command (this change was prepared
earlier so callsites don't need to change).
Each of those can be mapped attached to a TB
in the TFD, and the command header can use a
TB (the first one) in the TFD as well.

Doing this allows getting rid of huge commands
in favour of mapping existing buffers. The
beacon transmission is also optimised to not
copy the SKB at all but use multiple TBs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The pad argument to iwlagn_txq_free_tfd
isn't used, remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

All of these functions no longer need to be
accessed indirectly since they're shared in
all AGN devices.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

In a subsequent patch, I want to make commands use
multiple TBs in a TFD. This is a simple change to
prepare the data structures for this, with as of
now still just a single TB supported.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.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: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano 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: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano 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: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano 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: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Additionally, add wow_enabled field to wl, to indicate
whether wowlan was configured.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano 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: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

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