By default the firmware uses 1Mbps and 6Mbps rate for management packets
in 2G and 5G bands respectively. But when the user selects different
basic rates from the userspace, we need to send the management
packets at the lowest basic rate selected by the user.

This change makes use of WMI_VDEV_PARAM_MGMT_RATE param for configuring the
management packets rate to the firmware.

Chipsets Tested : QCA988X, QCA9887, QCA9984
FW Tested 	: 10.2.4-1.0-41, 10.4-3.6.104
Signed-off-by: Sriram R <srirrama@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

>From commit "ath10k: add per target config of max_num_peers",
the num_peers value in struct ath10k_hw_params is used to override
the value obtained from the WMI op version in the firmware file.

Currently, only high latency devices (USB and SDIO) need to use this
value, since the value obtained from the WMI op version is not
applicable for these devices.

Many devices in ath10k_hw_params_list have the wrong value set.

An example of this is the QCA9880 hw2.0 chipset that had (before this
patch) num_peers set to TARGET_TLV_NUM_PEERS although the firmware
uses WMI version ATH10K_FW_WMI_OP_VERSION_10_2_4.

Using the wrong value for the QCA9880 chip results in a fw crash:

ath10k_pci 0000:01:00.0: firmware crashed! (guid ddf39880-3e64-4edf-b4e4-979d31724503)
ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 0
ath10k_pci 0000:01:00.0: firmware ver 10.2.4-1.0-00037 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 a4a52adb
ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
ath10k_pci 0000:01:00.0: htt-ver 0.0 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
ath10k_pci 0000:01:00.0: firmware register dump:
ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009B54B7 0x00955B31
ath10k_pci 0000:01:00.0: [04]: 0x009B54B7 0x00060530 0x00000011 0x00400000
ath10k_pci 0000:01:00.0: [08]: 0x000001B8 0x00000007 0x00443138 0x00955A00
ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 0x009B548E 0x009B54AB
ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094078E 0x00000000 0x00000000
ath10k_pci 0000:01:00.0: [20]: 0x409B54B7 0x0040AC64 0x00400000 0x00000087
ath10k_pci 0000:01:00.0: [24]: 0x809A3831 0x0040ACC4 0x000001B1 0xC09B54B7
ath10k_pci 0000:01:00.0: [28]: 0x809A2F08 0x0040AD04 0x00410410 0x00000001
ath10k_pci 0000:01:00.0: [32]: 0x80988856 0x0040AD24 0x00410410 0x00000001
ath10k_pci 0000:01:00.0: [36]: 0x8098AF64 0x0040AD44 0x00410410 0x00000001
ath10k_pci 0000:01:00.0: [40]: 0x809B5DEC 0x0040AD84 0x00410410 0x00410FF4
ath10k_pci 0000:01:00.0: [44]: 0x809B1F20 0x0040ADA4 0x00400000 0x00416C54
ath10k_pci 0000:01:00.0: [48]: 0x809C0295 0x0040ADE4 0x0040AE08 0x00411DC8
ath10k_pci 0000:01:00.0: [52]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
ath10k_pci 0000:01:00.0: [56]: 0x80948E2C 0x0040AEA4 0x0041F290 0x004123D4
ath10k_pci 0000:01:00.0: Copy Engine register dump:
ath10k_pci 0000:01:00.0: [00]: 0x00057400  10  10   3   3
ath10k_pci 0000:01:00.0: [01]: 0x00057800   3   3   8   9
ath10k_pci 0000:01:00.0: [02]: 0x00057c00   2   2   1   2
ath10k_pci 0000:01:00.0: [03]: 0x00058000   1   1   2   1
ath10k_pci 0000:01:00.0: [04]: 0x00058400   0   0  40   0
ath10k_pci 0000:01:00.0: [05]: 0x00058800   1   1   0   1
ath10k_pci 0000:01:00.0: [06]: 0x00058c00   0   0   0   0
ath10k_pci 0000:01:00.0: [07]: 0x00059000   0   0   0   0
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The hw_params value will only be used if it was explicitly set in the
global hw_params array.

This makes it possible to have the num_peers member unset.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Since commit 9d580466 ("ath10k: retrieve MAC address from system
firmware if provided"), we support pulling our MAC address from system
firmware. Along with this, we should admit that it's possible for system
firmware to be screwed up as well, omitting the MAC address there.

Provide a fallback, such that we choose a randomly-generated MAC
address, with the local assignment bit set.

This is not a preferred mode of operation and really should only serve
the purpose of keeping the system chugging along while someone figures
out what's wrong with the system. Grepping through other wireless
drivers shows very similar fallback logic though, so why not?

  git grep eth_random_addr drivers/net/wireless/
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The tx_status for management frames is being filled
incorrectly in the flags of skb_cb. This incorrect
flag setting causes the upper layers to consider that
the particular frame was not transmitted properly,
leading to improper behavior.

Set the IEEE80211_TX_STAT_ACK flag in the info flags
of skb_cb, to indicate the successful transmission of
the management frame.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1

Fixes: dc405152Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The vdev-start-response message should cause the
completion to fire, even in the error case.  Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.

Add some warning text to print out the invalid status
code to aid debugging, and propagate failure code.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This is done in order not to trig the below warning in
ieee80211_rx_napi:

WARN_ON_ONCE(softirq_count() == 0);

ieee80211_rx_napi requires that softirq's are disabled during
execution.

The High latency bus drivers (SDIO and USB) sometimes call the wmi
ep_rx_complete callback from non softirq context, resulting in a trigger
of the above warning.

Calling ieee80211_rx_ni with softirq's already disabled (e.g., from
softirq context) should be safe as the local_bh_disable and
local_bh_enable functions (called from ieee80211_rx_ni) are fully
reentrant.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Special HTT RX handling for high latency interfaces.

Since no DMA physical addresses are used in the RX ring
config message (this is not supported by the high latency
devices), no RX ring is allocated.
All RX skb's are allocated by the driver and passed directly
to mac80211 in the HTT RX indication handler.

A nice side effect of this is that no huge buffer will be
allocated with dma_alloc_coherent. On embedded systems with
limited memory resources, the allocation of the RX ring is
prone to fail.

Some tweaks made to "make it work":

Removal of protected bit in 802.11 header frame control field.
The chipset seems to do hw decryption but the frame_control
protected bit is still set.

This is necessary for mac80211 not to drop the frame.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Add HTT TX function for HL interfaces.
Intended for SDIO and USB.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Special HTT RX ring config message used by high latency
devices.

The main difference between HL and LL is that HL devices
do not use shared memory between device and host and thus,
no host paddr's are added to the RX config message.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Initial (empty) HTT RX ops for high latency devices.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Initial HTT TX ops for high latency devices.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Several DMA related functions (such as the dma_map_xxx functions)
are not used with high latency devices and don't need to be invoked
in this case.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This patch makes sure the value of max_num_peers matches
num_peers in hw_params (if set to a non zero value).

hw_params->num_peers is used in the TLV WMI init command.
If ar->max_num_peers is not set to the same value, there is a risk
that the user creates more peers than the maximum number of peers
supported by the device.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

As TARGET_TLV_NUM_TIDS is calculated like this:

	#define TARGET_TLV_NUM_TIDS ((TARGET_TLV_NUM_PEERS) * 2)

... it is better to use the per device hw_params.num_peers value in
the TLV init message (if set), rather than using a hard coded value.

This makes the value used in the TLV init message match the hw_param
value.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The bus type is used together with the other hw parameters
to find a matching entry in ath10k_hw_params_list for the device.

This is necessary since HL devices can have the same dev_id and
target_version as a corresponding LL device (same chipset) and
yet use a totally different configuration.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Add dev_type parameter to struct ath10k_bus_params.

The dev type specifies if the device is a high latency device (usb and
sdio) or low latency device (pci, ahb and snoc)

The setup of high latency chips is sometimes different than
for chips using low latency interfaces.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This struct is used as argument to ath10k_core_register in order to
make it easier to add more bus parameters in the future.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Downloading firmware via BMI protocol takes too long time. For example,
a ~700K bytes firmware takes about 500ms to download via BMI protocol.
This is too long especially in suspend and resume scenario where firmware
is re-downloaded unless WoWLAN is enabled. Downloading firmware via diag CE
can reduce the time to ~40ms for a ~700K bytes firmware binary.

Ath10k driver parses the firmware to segments and downloads the segments
to the specified address directly. If the firmware is compressed or has
unsupported segments, ath10k driver will try BMI download again.

It's tested with QCA6174 hw3.2 and
firmware-6.bin_WLAN.RM.4.4.1-00111-QCARMSWP-1. QCA9377 is also affected.
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

To download firmware via diag interface, driver needs to write the target
memory space below 1M. It means the bit20 should be zero for the converted
address if the target memory space is below 1M. Otherwise, bit20 is one if
the target address is larger or equal to 1M space.

As downloading firmware via diag interface is only required for qca6174
and qca9377, a new specific function is introduced to convert the target
address to ce address: ath10k_pci_qca6174_targ_cpu_to_ce_addri().
This function supports to convert any target address to ce address.

It's tested with QCA6174 hw3.2 and
firmware-6.bin_WLAN.RM.4.4.1-00111-QCARMSWP-1. QCA9377 is also affected.
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Delay 1ms is too long for both diag read and write operations.
This is observed when writing a big memory buffer to target or
reading a big memory buffer from target. Take writing/reading
512k bytes as example, the delay itself is 256ms as the maximum
length of every write/read is 2k size.

Reduce the delay to 50us for read and write operations.

Take the ath10k_pci_targ_cpu_to_ce_addr() out of loop and put it
in the beginning of the loop for ath10k_pci_diag_read_mem().

The ath10k_pci_targ_cpu_to_ce_addr() is to convert the address
from target cpu's perspective to CE's perspective, so it makes
no sense to convert a CE's perspective address again in the loop.
It's a wrong implementation but happens to work.

If the target address is below 1M space, then the convert in the loop
from the second time becomes wrong because the previously converted address
is larger than 1M. The counterpart ath10k_pci_diag_write_mem() has the
correct implementation.

With this change, ath10k_pci_diage_read_mem() works correctly no matter
the target address is below 1M or above 1M.

It's tested with QCA6174 hw3.2 and
firmware-6.bin_WLAN.RM.4.4.1-00111-QCARMSWP-1. QCA9377 is also affected.
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Average ack rssi value is weighted average of ack rssi for
no of msdu's has been sent.
This feature is enabled by the host driver if firmware is capable.
After receiving event from host, firmware allocates the necessary
memory to store the ack_rssi for data packets during the init time.

After each successful transmission, If tx completion status is OK
and 24th bit is set in HTT message header then host will fetch the
ack_rssi else host can ignore the ack_rssi field.
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

array "ctl_power_table" access index "pream" is initialized with -1 and
is raised as a static analysis tool issue.
[drivers\net\wireless\ath\ath10k\wmi.c:4719] ->
[drivers\net\wireless\ath\ath10k\wmi.c:4730]: (error) Array index -1 is
out of bounds.

Since the "pream" index for accessing ctl_power_table array is initialized
with -1, there is a chance of memory access violation for the cases below.
1) wmi_pdev_tpc_final_table_event change frequency is between 2483 and 5180
2) pream_idx is out of the enumeration ranges of wmi_tpc_pream_2ghz,
wmi_tpc_pream_5ghz
Signed-off-by: K.T.VIJAYAKUMAAR <vijay.bvb@samsung.com>
[kvalo@codeaurora.org: clean up the warning message]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This patch adds 'tx_stats' in per station debugfs entry.

Use this command to dump tx_stats:
cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/
    stations/<MACADDR>/tx_stats
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This patch adds per station tx statistics support.

Per station tx stats include
 - pkts/bytes transmitted at all possible rates(mcs/nss/bw/gi).
 - ACK fails count
 - ampdu bytes/pkts transmitted at all possible rates(mcs/nss/bw/gi).
 - BA fails count

Tested on QCA9984/QCA4019/QCA988x
Firmware: 10.4-3.5.3-00057
	  10.2.4-1.0-00037
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This patch adds debugfs entry to enable/disable extended
tx statistics. Extended tx statistics are from peer stats
feature.
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Get the legacy rate index to update the pkts/bytes counter
against each possible tx rate.
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The comparison of cid >= 0 is always true because cid is of type u8
(8 bits, unsigned).

Fix this by removing such comparison and updating the type of
variable cid to u8 in the caller function.

Addresses-Coverity-ID: 1473079 ("Unsigned compared against 0")
Fixes: b9010f10 ("wil6210: add FT roam support for AP and station")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

WCN3990 target uses separate htc service for pktlog.
Add pktlog service request and support for pktlog
rx path handling.

Testing:
    Tested on WCN3990 and QCA6174 HW.
    Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1,
               WLAN.RM.4.4.1-00109-QCARMSWPZ-1
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Existing copy engine interrupt enable logic assumes that last
CE is using polling mode and due to this interrupt for last copy engine
are always disabled. WCN3990 uses last CE for pktlog and
interrupt remains disabled with existing logic.

To mitigate this issue, introduce CE_ATTR_POLL flag and control
the interrupt based on the flag which can be set in ce_attr.

Testing:
    Tested on WCN3990 and QCA6174 HW.
    Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1,
               WLAN.RM.4.4.1-00109-QCARMSWPZ-1
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

To support dual-band variant of QCA9984, new extended board data (eBDF)
is introduced since existing board data ran out of space.

Below is the brief implementation & design detail,
----------------------------------------------------

1. New OTP changes to inform eBDF support in existing OTP download to
fetch board ID and chip ID. This is backward compatible and older
card sends 0 by default for eBDF support bit (bit 18 of OTP response) we
check in ath10k driver.

2. If eBDF is supported, then we need to fetch eBDF ID which is bundled
in downloaded board data. So again OTP is executed for knowing the eBDF ID.
This is done once we set 'board_data_initialized' bit. If eBDF ID
returned is zero, we continue booting with previous board data downloaded.

3. Based on the eBDF ID fetched, ath10k driver tries to download the
extended board data to a new offset ahead of already downloaded board
data address.

4. A new BD IE type, ATH10K_BD_IE_BOARD_EXT is added to differentiate in
bundling eBDF separately in board-2.bin and also to parse through
board bundle for eBDF download in ath10k boot.

5. If eBDF is not present in the board-2.bin bundle or when board ID is
zero, we do a fallback boot to "eboard.bin" in the same QCA9984/hw1.0 dir.
This is same as done to existing "board.bin" if board ID is not present
in board-2.bin bundle.

Current design is that eBDF size will be 2KB and eBDF ID will be
byte value.

Tested the above changes with dual-band variant of QCA9984 card. OTP
update needed for the test will be part of next FW release 10.4-3.6-xxxx.

Below are the logs with ath10k BOOT debugs enabled.

First OTP response :
---------------------
..
boot upload otp to 0x1234 len 9478 for board id
boot get otp board id result 0x00040400 board_id 1 chip_id 0 ext_bid_support 1
..

Second OTP response :
---------------------
..
boot upload otp to 0x1234 len 9478 for ext board id
boot get otp ext board id result 0x00000005 ext_board_id 5
boot using eboard name 'bus=pci,bmi-chip-id=0,bmi-eboard-id=5'
..

Extended board data download:
------------------------------
..
board name
00000000: 62 75 73 3d 70 63 69 2c 62 6d 69 2d 63 68 69 70  bus=pci,bmi-chip
00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 65 62 6f 61 72 64  -id=0,bmi-eboard
00000020: 2d 69 64 3d 35                                   -id=5
boot found match for name 'bus=pci,bmi-chip-id=0,bmi-eboard-id=5'
boot found eboard data for 'bus=pci,bmi-chip-id=0,bmi-eboard-id=5'
using board api 2
boot writing ext board data to addr 0xc3000
..

Fallback Extended board data download from "eboard.bin":
---------------------------------------------------------
..
board name
00000000: 62 75 73 3d 70 63 69 2c 62 6d 69 2d 63 68 69 70  bus=pci,bmi-chip
00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d  -id=0,bmi-board-
00000020: 69 64 3d 31 30                                   id=10
failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-eboard-id=5 from ath10k/QCA9984/hw1.0/board-2.bin
boot fw request 'ath10k/QCA9984/hw1.0/eboard.bin': 0
using board api 1
boot writing ext board data to addr 0xc3000
..
Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Just moving functions down in the file, no functional changes.
Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ATH10K_SNOC builds just fine with COMPILE_TEST, so make that possible.
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.

Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

If there are some tx packets pending in firmware, and then system
enters suspend, firmware will fail for wow enable. This will trigger
mac80211 to stop ath10k and download firmware again, then it is
non-wow suspend.

After add the waiting htt tx complete, then firmware will have some
time window to send or flush the pending tx packets.

Tested with QCA6174 PCI with firmware
WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 PCI.
It's not a regression with new firmware releases.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Devices may provide their own MAC address via system firmware (e.g.,
device tree), especially in the case where the device doesn't have a
useful EEPROM on which to store its MAC address (e.g., for integrated
Wifi).

Use the generic device helper to retrieve the MAC address, and (if
present) honor it above the MAC address advertised by the card.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath.git patches for 4.20. Major changes:

ath10k

* limit available channels via DT ieee80211-freq-limit

wil6210

* add 802.11r Fast Roaming support for AP and station modes

* add support for channel 4

Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in
the RX and TX path. These filtered channel can in theory still be used by
the hardware but the signal strength is reduced so much that it makes no
sense.

There is already a DT property to limit the available channels but ath10k
has to manually call this functionality to limit the currrently set wiphy
channels further.
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Check rx_buff_mgmt is allocated before accessing its internal fields.
Signed-off-by: Dedy Lansky <dlansky@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This feature is needed for enterprise APs and clients to enable
fast roaming as defined in 802.11r between APs in the same ESS.

On AP side, this feature is supported only when disable_ap_sme
is enabled.
Signed-off-by: Ahmad Masri <amasri@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>