iwl7000: remove IDR backport

This was backported to 3.8, but is already in 3.10. Remove it
to avoid many compiler warnings.

Change-Id: Ia5931090ee0f8a158c4c0f7bdd7a329de14e182f
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/182285
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: mwifiex: balance dma map/unmap sizes

Depending on the underlying DMA implementation its
not possible to partially unmap DMA buffers. Moreover
its not possible to understand the intent of passing
0 as the size to dma unmap. The intent of this
driver is unmap the entire skb buffer. The only way
to ensure that the size matches on unmap is to store
both the dma address and the size in the skb ca field.

Introduce a mwifiex_dma_mapping structure which tracks
the dma address and the size. Additionally, provide
a mwifiex_unmap_pci_memory() that utilizes the new
structure. This also provide symmetry within the
internal API.

BUG=chrome-os-partner:24817
BUG=chrome-os-partner:24397
BRANCH=None
TEST=Running with instrumented kernel reveals no more
     0-sized DMA unmaps. And the factory Stress test
     can now pass.

Change-Id: I0cb1fc0059899e1f210f1e5b066add86b0aabbfc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183030
Reviewed-by: Bing Zhao <bzhao@marvell.com>
CHROMIUM: mwifiex: don't leak DMA command skbuffs

The current mwifiex pcie driver assumed that it would get
its cmdrsp_complete() callback called before another command
was sent to unmap the command's skbuff. However, that is not
true. The mwifiex_check_ps_cond() will send a sleep command
to the card without having adapter->curr_cmd set. Within the
workqueue's state machine the adapter's state would be set
to allow commands (curr_cmd = NULL && cmd_sent = false) after
having receieved the response from the sleep command. The
card->cmd_buf would then be overridden with the new command
but the first command's skbuff was not unmapped. This leaks
mapped skbuffs when a bounce buffer is employed.

To rectify this unmap the card->cmd_buf when the response is
received from the card instead of waiting for the
cmdrsp_complete() callback.

BUG=chrome-os-partner:24817
BUG=chrome-os-partner:24397
BRANCH=none
TEST=Ran factory test Stress Runin with stack of patches.
     No more failures.

Change-Id: I548814edd0ac79585f07a17fad1ec2c9b9f344a9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183254
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: update to Core3 version

Update the iwl7000 driver to the latest release cycle. This update
fixes numerous bugs in various places (e.g. powersave), adds support
for new hardware SKUs and adds the following new features:
 * xVT support (configurable) - this is the test and production
   framework for iwlwifi
 * smart FIFO support - this feature reduces host wakeups
 * latency statistics (a mac80211 feature)
 * enable HT/VHT STBC support
 * low-priority scan support
 * multicast filtering support
 * fix scheduled scan support for older wpa_supplicant
 * and probably more small things

(iwlwifi commit 0cca5058afda4cbd7a414d642f0a511955320c6c)

Change-Id: If89c663836073cf1df7e98337d3c8aa95fad32e8
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184351
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: sort and extend element ID list

The element ID list is currently almost sorted by amendment
or similar topic, but the order is difficult to maintain and
not very transparent. Sort the list by ID instead, and add
a lot of missing IDs.

Change-Id: If645be25109f51a7a1021c5dec34cffd0ec350b5
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184778
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: order IEs in probe request correctly

In probe request frames, the VHT IEs should come before any
vendor IEs, but after interworking and similar, so add code
to order them correctly wrt. the IEs passed from userspace.

Change-Id: Ic56cfedc7bc197f1e19c7de0385c040f8a32775a
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184779
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: order IEs in association request correctly

In association request frames, there may be IEs passed from
userspace (such as interworking IEs) between HT and VHT, so
add code to insert those inbetween them.

Change-Id: Idf4d29faba6bf17be6f0aa6da52bb22b6e7db1e0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184830
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: fix cmd and Tx data timeout issue for PCIe cards

We are sending sleep confirm done interrupt in the middle of
sleep handshake. There is a corner case when Tx done interrupt
is received from firmware during sleep handshake due to which
host and firmware power states go out of sync causing cmd and
Tx data timeout problem.

Hence sleep confirm done interrupt is sent at the end of sleep
handshake to fix the problem.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24397
TEST=browse to slashdot.org; open a new Ctrl-T console and run script:
while sleep 10; do ping -f -c 100 www.google.com; done

Change-Id: I208d09eacf4bde8e6220179d71f91914a8126dd0
Reviewed-on: https://chromium-review.googlesource.com/186746
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
mwifiex: re-enable PCIe interrupt after awake event is received

It's found that sometimes the PCIe interrupt isn't re-enabled in
some cases where power save state is transitioning to awake state.
It will cause cmd timeout and/or Tx watchdog timeouts if interrupt
is disabled. This patch ensures that the interrupt is re-enabled.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24397
TEST=browse to slashdot.org; open a new Ctrl-T console and run script:
while sleep 10; do ping -f -c 100 www.google.com; done

Change-Id: I1f9e5dba1db56c1eb3501c77d562d957d6b38890
Reviewed-on: https://chromium-review.googlesource.com/186747
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
mwifiex: change transmit buffer size for 8897

Currently default Tx buffer size configured to firmware is 2K
for all chipsets. This patch changes it to 4K for SD/PCIe/USB
8897 chipsets as per firmware requirements.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24397
TEST=browse to slashdot.org; open a new Ctrl-T console and run script:
while sleep 10; do ping -f -c 100 www.google.com; done

Change-Id: Id860f8b222e724d5ad8e9ad73c939ccc8eb38ece
Reviewed-on: https://chromium-review.googlesource.com/186748
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: remove global variable cmd_wait_q_required

There is a race condition while queuing synchronous command and
asynchronous command requested from different threads, because
the wait_q_enabled flag is set based on a global variable
cmd_wait_q_required.

The issue is fixed by removing this global variable and using a
unified function with an argument 'sync' passed into the
function.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>

BUG=chrome-os-partner:25920
TEST=connect to AP, run suspend_stress_test on console and
system doesn't hang/reboot.

Change-Id: I65ecb5f3496b5ccb3d7b20ab5a72bbd24eb51e0c
Reviewed-on: https://chromium-review.googlesource.com/187326
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Bill Huang <bilhuang@nvidia.com>
Tested-by: Bill Huang <bilhuang@nvidia.com>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
CHROMIUM: mwifiex: Track BA sequence number reset

Some stations reset the sequence number for traffic-ids (TIDs)
as they initiate a block-ACK session.  In order to detect such
behavior, mwifiex must note the starting sequence number given
during the ADDBA request.  If the first received sequence number
after the ADDBA falls outside the receive window for this TID but
after the the ADDBA starting sequence number, we can assume that
this AP has reset its sequence number during the ADDBA.  In this
case we must adjust the input window backward to incorporate this
received sequence number instead of ignoring it.  Otherwise, we
could fail to successfully retrieve an arbitrarily large number
of downstream frames at the beginning of the block-ACK session.

Signed-off-by: Paul Stewart <pstew@chromium.org>

BUG=chrome-os-partner:25630,chromium:297607
TEST=Connect to 802.11n WPA/CCMP AP which resets its TIDs and
ensure initial DHCP response is delivered to userspace.

Change-Id: I7dec7ecf886c8b293e71d050300758fb77c3a3c9
Reviewed-on: https://chromium-review.googlesource.com/187783
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: fix scan offload for BGN SKU

BGN SKU won't scan on 5.2GHz obviously, but the firmware
still expects the driver to reserve space for the the probe
request for the 5.2GHz band.
Fix this by allocating space and leave it empty.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=69541

BUG=chrome-os-partner:26420
TEST=test (scheduled scan) with BGN SKU

Change-Id: I232b899f0c881246f22134f7c0562edc1c175dc2
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/188883
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
CHROMIUM: mwifiex: add placeholder for cfg80211 definitions in kernel 3.9+

For driver backport to work without touching wireless-3.8 stack,
copy over all needed new cfg80211 definitions from kernel 3.9+.

Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26590
TEST=pass compiliation with backport patches applied.

Change-Id: I9e7cae54faee8cc72c41c430fd1e703153140b84
Reviewed-on: https://chromium-review.googlesource.com/188658
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: add 802.11AC support

For STA mode, collect VHT realated IEs from the Beacons or Probe
Responses and append similar VHT related IEs to association
requests.

For AP mode, get VHT related capability information and share it
with cfg80211 at the time of wiphy register. This information is
further used by cfg80211 and hostapd to start an AP with 802.11AC
support.

Currently only 8897 supports 802.11AC.

This is collection of the following patches:

mwifiex: improve readability in 11ac mcsmap to maxrate conversion
mwifiex: make 11ac mcs rate tables global and const
mwifiex: make use of IEEE80211_VHT_MCS_NOT_SUPPORTED
mwifiex: fix wrong 11ac bits setting in fw_cap_info (already upstream)
mwifiex: cleanup VHT cap (already upstream)
mwifiex: add 802.11AC support (already upstream)

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Frank Huang <frankh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:26590
TEST=associate to Buffalo WZR-D1800H AP (5G) and verify the
VHT IE in association request and response from AP in sniffer
captures.

Change-Id: I9829af2f92df9ac3116d18678a3e7f9715cfd41d
Reviewed-on: https://chromium-review.googlesource.com/188659
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: correct bss_mode check while
 appending vht operation IE

priv->bss_mode uses NL80211_IFTYPE_* definitions.
HostCmd_BSS_MODE_IBSS is used in ad-hoc start/join command between
driver and firmware.

Coincidentally both HostCmd_BSS_MODE_IBSS and NL80211_IFTYPE_STATION
are defined as 2. That explains why nobody complained.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:26590
TEST=No functional/behavior change. All existing features still
work as before.

Change-Id: I997bad3b938f83a35aff29d3ed6b2dccc3277fc9
Reviewed-on: https://chromium-review.googlesource.com/189280
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: add support to configure VHT for AP mode

Currently, default VHT configuration from the firmware is used
for the VHT operations. Adding vhtcfg command to configure the
firmware based on input received from cfg.

Enable VHT for AP mode only when cfg80211_ap_settings has a
VHT IE i.e., when ieee80211ac is set to 1 in the hostapd.conf.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:26590
TEST=verify that micro-AP can be started on 2.4GHz and 5GHz
with HT IE in beacon and probe response. Other stations can
associate to uAP. Cannot test VHT on Snow as ieee80211ac=1
is not supported in current hostapd.

Change-Id: I1fa195d0aa88f351356f04e56d80d224645afa23
Reviewed-on: https://chromium-review.googlesource.com/189281
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: use separate AMPDU tx/rx window sizes in 11ac networks

Newer 11ac enabled chipsets have more TX and RX buffers in FW
and hardware; so they may support larger TX and RX window sizes
for BA. Reset BA settings during association, adhoc join/start
or start_ap() if we are joining/creating 11ac network.

Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Sagar Bijwe <bsagar@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:26590
TEST=add pr_info() in nl80211.c nl80211_put_sta_rate().
Associate to Buffalo WZR-D1800H AP (5G) and ping the AP.
Run iw mlan0 link, and then check dmesg to see VHT mcs/nss
debug logs printed in nl80211_put_sta_rate().
Start 11N uAP, other 11N STA can associate to it and data path
is working. Cannot test VHT on Snow as ieee80211ac=1 is not
supported in current hostapd.

Change-Id: I5d650d2d32544de039b55a6c17519b0197a75f53
Reviewed-on: https://chromium-review.googlesource.com/189282
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: remove unsupported code in 11ac

bit12 in fw_cap_info is for testing only.
Remove all related code.

Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26590
TEST=add pr_info() in nl80211.c nl80211_put_sta_rate().
Associate to Buffalo WZR-D1800H AP (5G) and ping the AP.
Run iw mlan0 link, and then check dmesg to see VHT mcs/nss
debug logs printed in nl80211_put_sta_rate().
Start 11N uAP, other 11N STA can associate to it and data path
is working. Cannot test VHT on Snow as ieee80211ac=1 is not
supported in current hostapd.

Change-Id: Id0a1cdf9271abede59e4992ce6c30a09e7920022
Reviewed-on: https://chromium-review.googlesource.com/189283
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: copy AP's HT capability info correctly

While preparing association request, intersection of device's HT
capability information and corresponding fields advertised by AP
is used.

This patch fixes an error while copying this field from AP's
beacon.

Cc: <stable@vger.kernel.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26590
TEST=associate to Buffalo WZR-D1800H AP and pass ping/iperf tests.

Change-Id: I2a682126b55867641ac463f6de472536f1208d20
Reviewed-on: https://chromium-review.googlesource.com/189284
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>