After short chat with Ivo, we decided that I'll take maintenance
of rt2x00 driver.

Thanks for Ivo's great work in the past!
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

On AR934x rev 3, settin the ad-hoc flag completely messes up hardware
state - beacons get stuck, almost no packets make it out, hardware is
constantly reset.

When leaving out that flag and setting up the hw like in AP mode, TSF
timers won't be automatically synced, but at least the rest works.

AR934x rev 2 and older are not affected by this bug
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

It is needed for AR934x as well
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Needed for calling vmalloc()/vfree()
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

In a number of places, kmalloc or valloc were used to acquire memory.
To ensure that these locations are correctly initialized, the calls were
changed to kzalloc and vzalloc. The change fixes a problem that was causing
HT operations to be cancelled.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rtlwifi: rtl8188ee: rtl8192com: rtl8192cu: rtl8192ee: rtl8723ae: rtl87323be: rtl8821ae: Use common cmd_send_packet

A locking problem was found in routine _rtl92ee_cmd_send_packet() that led
to system freezes. Upon inspection, several drivers had the same problem;
however, the routines all used the same code. The common code has been
moved into rtlwifi.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Realtek released new drivers on 06/28/2014. These changes implement all their
changes into the kernel version of the driver. In addition, these modifications
are part of the process of unifying the Realtek and kernel code bases.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch updates the driver to match the latest Realtek release, and
it is an important step in getting the internal code source at Realtek to match
the code in the kernel. The primary reason for this is to make it easier for
Realtek to maintain the kernel source without requiring an intermediate like me.

In this process of merging the two source repositories, there are a lot
of changes in both, and this commit is rather large.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Not only does this patch update the driver to match the latest Realtek release,
it is an important step in getting the internal code source at Realtek to match
the code in the kernel. The primary reason for this is to make it easier for
Realtek to maintain the kernel source without requiring an intermediate like me.

In this process of merging the two source repositories, there are a lot
of changes in both, and this commit is rather large.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This driver was entered into staging a few cycles ago because there was
not time to integrate the Realtek version into the support routines in
the kernel. Now that there is an effort to converg the code base from Linux
and the Realtek repo, it is time to move this driver. In addition, all the
updates included in the 06/28/2014 version of the Realtek drivers are
included here.

With this change, it will be necessary to delete the staging driver. That
will be handled in a separate patch. As it impacts the staging tree, such a
patch is sent to a different destination.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The code fails to lock the skb queue, which leads to a number of problems.
This patch also fixes a Sparse warning about using a memset of 1 byte.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: troy_tan@realsil.com.cn
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This will allow us to define GPIO-attached devices (LEDs, buttons) in
the the device tree.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This driver is used by the bcm53xx ARM SoC code. Now it is possible to
give the address of the chipcommon core in device tree and bcma will
search for all the other cores.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We will now dump MAC, APU, CIU, ICU firmware memory segments also
for PCIe interface. Following is the updated userspace script which
reads firmware dump information.

    mwifiex_pcie_fw_dump.sh: #!/bin/bash
    ethtool --set-dump mlan0 0
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/ITCM.log

    ethtool --set-dump mlan0 1
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/DTCM.log

    ethtool --set-dump mlan0 2
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/SQRAM.log

    ethtool --set-dump mlan0 3
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/IRAM.log

    ethtool --set-dump mlan0 4
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/APU.log

    ethtool --set-dump mlan0 5
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/CIU.log

    ethtool --set-dump mlan0 6
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/ICU.log

    ethtool --set-dump mlan0 7
    ethtool --get-dump mlan0
    ethtool --get-dump mlan0 data /tmp/MAC.log
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch takes care of missing error paths in firmware dump.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This driver was entered into staging a few cycles ago because there was
not time to integrate the Realtek version into the support routines in
the kernel. Now that there is an effort to converg the code base from Linux
and the Realtek repo, it is time to move this driver. In addition, all the
updates included in the 06/28/2014 version of the Realtek drivers are
included here.

With this change, it will be necessary to delete the staging driver. That
will be handled in a separate patch. As it impacts the staging tree, such a
patch is sent to a different destination.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Not only does this patch update the driver to match the latest Realtek release,
it is an important step in getting the internal code source at Realtek to match
the code in the kernel. The primary reason for this is to make it easier for
Realtek to maintain the kernel source without requiring an intermediate like me.

In this process of merging the two source repositories, there are a lot
of changes in both, and this commit is rather large.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Addition of the new drivers and the update to a new version for the others
lead to changes in all the core routines.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Realtek released a new version of the drivers on 06/28/2014. This
patch implements the new power-save code. These changes also force
corresponding changes in the drivers.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Each of the routines in the rtlwifi common driver needs to be modified
for the coming changes. This patch prepares core.c, but also touches other
files.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Future patches will move the drivers for RTL8192EE and RTL8821AE
from staging to the regular wireless tree. Here, the necessary features
are added to the PCI driver. Other files are touched due to changes
in the various data structs.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When the rtlwifi family of drivers was converted to use a workqueue when
entering or leaving power save mode (commits a269913c, a5ffbe0a,
41affd52, b9116b9a, and 6539306b), the code began scheduling work from
the callback routine of a different workqueue with a resulting increase in
overhead.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The capability for 802.11ac will soon be added to these drivers. Once
that is done, a bitmask will be too large for the data storage.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Clearing IEEE80211_TX_CTL_PS_RESPONSE in a frame
that is not in the current context doesn't seem right.
Instead make sure that we don't add such frames
to the UAPSD queue by using a local variable.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

There is no reason why frames marked with
IEEE80211_TX_CTL_TX_OFFCHAN have to be sent using
the UAPSD queue. Since mac80211 makes sure that
RoC is done before pushing an offchannel frame
to the driver, we can use the normal TX queues
for transmission.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Since we use IEEE80211_HW_QUEUE_CONTROL now, the
CAB/Offchannel queues are registered as the last
two queues. There is no need to check and reassign
the queues in the TX start()/done() routines.

CAB frames will not reach the tx() callback since
we set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING and
pull the buffered frames during beacon transmission.
We also don't have a special HW queue for handling
off-channel frames.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Two bits control TX power on BBP_R1 register. Correct the mask,
otherwise we clear additional bit on BBP_R1 register, what can have
unknown, possible negative effect.

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Provide ethtool support; with support for interrupt coalescing through
get_coalesce/set_coalesce.
Placeholders for begin/complete will be used by runtime PM
to make sure target is powered up while performing ethtool operations
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

GPIOs can be also used on bcm53xx, however this arch requires different
implementation of IRQ support. It uses different IRQ number (117) and
different masks & acking.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch makes the driver to report signal strength information
to mac80211 for rtl8187se boards.

It differs from my previous RFT patch:
http://marc.info/?l=linux-wireless&m=140155388332534&w=2
because:
- I have now a working rtl8187se card, so I could serve my RFT by myself. :)
- CCK measurement code has changed a bit, but it does basically the same things.
- OFDM measurement method is changed because the older method reported incorrect
  measures, at least for signals stronger than -40dBm).

CCK measurement seems quite good. OFDM seems less accurate, but this is the
same as the "reference" staging driver dose. I wanted not to change things just
to make measures of _one_ (my) card a bit more close to what _I_ (in my setup)
expected..

IMHO results are still good enough to justify reporting signal in dBm rather than in
"unspecified" units, so this is what this patch actually does.

Results of my tests with a working rtl8187se card connected with coaxes and
various RF attenuators to my AP are:

Input (approx) | CCK meas | OFDM meas
--------------------------------------
      -30dBm   |  -32dBm  |  -31dBm
      -40dBm   |  -40dBm  |  -41dBm
      -50dBm   |  -50dBm  |  -55dBm
      -60dBm   |  -59dBm  |  -63dBm
      -70dBm   |  -69dBm  |  -73dBm
      -80dBm   |  -79dBm  |  -83dBm

Also some real-field tests has been done (no coax, packets in the air) for the CCK
measure method, and they resulted in reasonable values.

Thanks-to: Bernhard Schiffner <bernhard@schiffner-limbach.de> [ for real-field tests]
Signed-off-by: andrea.merello <andrea.merello@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When multiple channel contexts are enabled, a p2p interface
that is assigned to a context will have an address that
is different from the device mac address, which is used
by wpa_s as the p2p device ID.

Certain frames like provision requests use the device address
and these get dropped since ath9k_calculate_summary_state()
iterates over only the active interfaces in a context and the
device address is not used.

Fix this by adding the device mac address to the bssid mask.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Some chip IDs are easier to read/understand when printed in a decimal
form. For example on my bcm53xx arch router this patch replaces:
Found chip with id 0xCF12, rev 0x00 and package 0x02
with a:
Found chip with id 53010, rev 0x00 and package 0x02
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Check for scan channel gap only when user_scan_in is not NULL.
user_scan_in is NULL for internal scans and if we check scan channel gap
at this place, it may result into crash.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Using the BSS information stored in mac80211 directly
is racy in certain conditions. For example, in a MCC
setup, if the scheduler is switching channels when
a local deauth is issued, calculation of the opmode/bssid
etc. is incorrect. To avoid this, store the bss params
in the driver and use it.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

AHB bus support was added in v2.6.38, through commit a0b907ee
("ath5k: Add AHB bus support."). That code can only be build if the
Kconfig symbol ATHEROS_AR231X is set. But that symbol has never been
added to the tree. So AHB bus support has always been dead code.

Let's remove all code that depends on ATHEROS_AR231X. If that symbol
ever gets added to the tree the AHB bus support can be re-added too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

Samuel Ortiz <sameo@linux.intel.com> says:

"NFC: 3.18 pull request

This is the NFC pull request for 3.18.

We've had major updates for TI and ST Microelectronics drivers:

For TI's trf7970a driver:

- Target mode support for trf7970a
- Suspend/resume support for trf7970a
- DT properties additions to handle different quirks
- A bunch of fixes for smartphone IOP related issues

For ST Microelectronics' ST21NFCA and ST21NFCB drivers:

- ISO15693 support for st21nfcb
- checkpatch and sparse related warning fixes
- Code cleanups and a few minor fixes

Finally, Marvell add ISO15693 support to the NCI stack, together with a
couple of NCI fixes."
Signed-off-by: John W. Linville <linville@tuxdriver.com>