Here's a new mac80211 driver for Qualcomm Atheros 802.11ac QCA98xx devices.
A major difference from ath9k is that there's now a firmware and
that's why we had to implement a new driver.

The wiki page for the driver is:

http://wireless.kernel.org/en/users/Drivers/ath10k

The driver has had many authors, they are listed here alphabetically:

Bartosz Markowski <bartosz.markowski@tieto.com>
Janusz Dziedzic <janusz.dziedzic@tieto.com>
Kalle Valo <kvalo@qca.qualcomm.com>
Marek Kwaczynski <marek.kwaczynski@tieto.com>
Marek Puzyniak <marek.puzyniak@tieto.com>
Michal Kazior <michal.kazior@tieto.com>
Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is only really useful for people who are bringing up new hardware
designs and have access to the proprietary vendor tools that interface
with this mode.

It'll live out of tree until it's rewritten to use a less kludgy interface.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This can live on as an out-of-tree patch for those that care.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Support for rt2800 device is broken since my
'rt2x00: rt2x00dev: use rt2x00dev->tx->limit'
patch. The changelog of that commit says that the
TX data queue is initialized already when the
rt2x00lib_probe_hw() function is called.

However as Jakub noticed it, this statement is not
correct. The queue->limit field is initialized in
the rt2x00queue_alloc_entries routine and that is
not yet called when rt2x00lib_probe_hw() runs.
Because the value of tx->limit contains zero, the
driver tries to allocate a kernel fifo with zero
size and kfifo_alloc rejects that with -EINVAL.

  PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
  ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3071, rev 021c detected
  ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0008 detected
  ieee80211 phy1: rt2x00lib_probe_dev: Error - Failed to initialize hw
  rt2800pci: probe of 0000:01:00.0 failed with error -22

Move the data_queue field initialization from
the rt2x00queue_alloc_entries routine into the
rt2x00queue_init function. The initialization
code is not strictly related to the allocation,
and the change ensures that the queue_data fields
can be used in the probe routines.

The patch also introduces a helper function in
order to be able to get the correct data_queue_desc
structure for a given queue. This helper is only
needed temporarily and it will be removed later.
Reported-by: NJakub Kicinski <moorray@wp.pl>
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

GCC 4.8 is spitting out uninitialized-variable warnings against
"drivers/net/wireless/rtlwifi/rtl8192de/dm.c".

drivers/net/wireless/rtlwifi/rtl8192de/dm.c:941:31:
error: 'ofdm_index_old[1]' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
     rtlpriv->dm.ofdm_index[i] = ofdm_index_old[i];

This patch adds initialization to the variable and properly sets its value.
Signed-off-by: NYunlian Jiang <yunlian@google.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Check for allocation failures and return -ENOMEM.  The caller
already expects it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This has only one caller and rates[] is an array with
IEEE80211_TX_MAX_RATES (4) elements.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The optional debugfs interface to the vendor's engineering tools wasn't
bounds checking at all, which made it trivial to perform a buffer
overflow if this interface was compiled in and then explicitly enabled
at runtime.

This patch checks both the length supplied as part of the data to ensure
it is sane, and also the amount of data compared to the remaining buffer
space.  If either is too large, fail immediately.

(This bug was spotted by Dan Carpenter <dan.carpenter@oracle.com>)
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

goto after return is wrong.

The other code in this block needs to set an
error value then goto an error release block.

This one doesn't need to release anything and
was likely a copy/paste remainder.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-By: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The Thermal Throttling code could do that, fix it.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In multicast, there is no retries nor RTS since there is no
specific recipient that can ACK or send CTS. This means
that we must not use the rate scale table for multicast
frames.
This true for any frame that doesn't have a valid
ieee80211_sta pointer.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In unassociated BSS STA mode FW verifies both power save and power
management flags to decide on switching power off. The driver currently
sets power management flag according to mac80211 decision. As result, in
unassociated mode power management flag is down and power consumption is
high. Change power management enablement. When unassociated in BPS and
LP power save modes enable power management regardless of mac80211
decision. Rely on mac80211 decision if associated. Add power management
state update during associated/disassociated modes transitions.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently vif_count verification for power management enablement appear
in different places. Move these verifications to one place in
iwl_mvm_update_power_mode().
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The AP mode needs to use the MCAST fifo for the MCAST
frames sent after the DTIM. This fifo needs to be
configured with the same parameters as the VOICE FIFO.

A separate SCD queue is mapped to this fifo - the cab_queue
(cab stands for Content After Beacon). This queue isn't
connected to any station, but rather to the MAC context.
This queue should (and is already) be set as the MCAST
queue - this is part of the of MAC context command.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since SCAN related handlers are much less likely than
beacon related handlers, reorder between them.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

According to the FW implementation, the quota command should
have a valid entry for each active binding (where 'active' in
this context means that the binding is known to the FW). In case
the binding should not get any quota, the 'quota' should be set
to zero.

Not setting an 0 quota for an active binding when all the MACs
in the binding are idle, i.e., not associated in case of managed
interface, will result in preventing the FW scheduler from entering
IDLE state and the FW from transitioning to low PS.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When CMD_SEND_IN_RFKILL is set, it is perfectly legitimate
to send a host command while RFKILL is asserted. In this
case, the host command sending functions should return 0
even if RFKILL is asserted.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Another step in the rate control / BT Coex integration
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Otherwise WiFi would kill BT.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This holds for existing BA agreements.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There was a typo in the Loose LUT for BT Coex.
Fix that.
Reported-by: NRoi Cohen <roi.cohen@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Move message to debug mode to reduce log spam under heavy tx (iperf) load.
This message prints in ht debug mode only:
brcms_c_ampdu_dotxstatus_complete: Pkt tx suppressed, illegal channel
possibly 153
Signed-off-by: NJohn Greene <jogreene@redhat.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ANI state can be maintained globally instead of per-channel.
This reduces memory usage and since default values are used
during a scan run, per-channel state is not required.
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 macros ATH9K_ANI_USE_OFDM_WEAK_SIG can be removed.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The check "enable_ani" is not required since it is always
set to true and the logic for disabling/enabling ANI via
debugfs is done at a higher layer.
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 only card with which WoW has been tested and verified is
AR9462. Do not enable it for all cards since WoW is really quirky
and needs to be tested properly with each chip.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Process and update the internal RSSI average, which
is used by ANI, after verifying that the received
frame has valid rate information.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pci_enable_device() will set device power state to D0,
so it's no need to do it again in ipw2100_pci_init_one().
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

My previous patch just moved the file, but it also needed to be renamed
to conform to proper conventions.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Based on discussions with And Bergmann, this patch changes the SDIO
platform code to default to supporting the Sagrad devices, allowing for
it to be overridden in board setup code.  This renders the cw1200_sagrad
module suplerflous, so it is now removed.

It also moves the documentation that was in the cw1200_sagrad source to
the platform header.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The only advantage of 'struct resource' is that it lets us assign names
as part of the platform data.  Unfortunately since we are using platform
data, we are already limited to a single instance of each driver,
rendering this moot.

So, replace the struct resources with ints, resulting in cleaner code.

This was based on a suggestion from Arnd Bergmann.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

(As suggested by Arnd Bergmann)
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This avoids problems when building on SPARC targets due to the driver
calling the bus abstraction layer 'sbus'.  Not that any SBUS-sporting
SPARC targets are likely to have an SDIO controller, but this is the
correct thing to do.

See http://kisskb.ellerman.id.au/kisskb/buildresult/8846508/Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>