For QCA6174 hw3.0, since WLAN.RM.4.4-00022-QCARMSWPZ-2, it starts to
support the board ID information from otp, with some devices released on
the market that didn't calibrated with OTP, will have 0 for board ID
information, which cause the backward compatibility issue and was fixed
in commit 'd2e202c0 ("ath10k: ignore configuring the incorrect board_id")'

So bump the fw api version to differentiate the latest firmware support.
Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

spectral_bin length (number of bins per fft sample) is usually
a value where (2^n = value), n is an integer.  All of the QCA99X0
family of chipsets seems to report a spectral_bin length of
2^n + 'm' bytes, where m = 4, 12 based on the chipset. This 'm'
bytes seems to carry some radar related info which is currently
discarded only for 'bin_len = 68' bytes. Extend this discarding of
irrelevant 'bin_len' for QCA9984, QCA9888, IPQ4019 as well by
introducing a hardware parameter 'spectral_bin_discard'. Also
for QCA988X based family of chipsets which doesn't seem to have this
issue and also for some of the hardware which I have not tested
like QCA6174/QCA9377 the existing behaviour is retained as it is.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Fix output from checkpatch.pl like:

 Block comments use a trailing */ on a separate line
Signed-off-by: NMarcin Rokicki <marcin.rokicki@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Len Brown reported the system resume time is taking more than 2 seconds in
bug - https://bugzilla.kernel.org/show_bug.cgi?id=185621.

The reason of the 2 seconds is due to the firmware download time.

The chip is booted up in the default reference clock speed to handle the
firmware download to chip memory and advanced to the support higher speed
clock to run the firmware after all. The default reference clock in the
hardware is slow so that the firmware download time is taking up to 2
seconds for a 600KB firmware file.

	[76796.349701] ath10k_pci : boot uploading firmware image len 688691
	[76798.334612] ath10k_pci : htt tx max num pending tx 1056

The resolution here is to enable the higher speed clock if the hardware
supported before the firmware download at BMI stage, so that the hardware
can handle the firmare download in a more efficient way. This can help to
improve the firmware download time from 2 seconds to around 500ms for the
same 600KB firmware file.

	[322858.577919] ath10k_pci boot uploading firmware image len 688691
	[322859.093094] ath10k_pci htt tx max num pending tx 1056

The steps to advance to the higher speed clock is very hardware specific,
so adding the hardware ops for the hardware that can support this.
Reported-by: NLen Brown <lenb@kernel.org>
Tested-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

To make it easier to handle minimum and maximum firmware API numbers convert
the firmware fetch functionality to a loop. If no firmware image is found print
an error with minimum and maximum API numbers and the name of firmware
directory. This is needed when we switch to using request_firmware_direct()
which doesn't print any errors anymore.

Also add a new function for creating the fw file name dynamically which makes it
easier to add new bus support, for example SDIO and USB, later.
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
[kvalo@qca.qualcomm.com: remove sdio/usb part, new error message, clarify commit log]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Dump Copy Engine source and destination ring addresses.
This is useful information to debug firmware crashes, assertes or hangs over long run
assessing the Copy Engine Register status. This also enables dumping CE
register status in debugfs Crash Dump file.

Screenshot:

ath10k_pci 0000:02:00.0: simulating hard firmware crash
ath10k_pci 0000:02:00.0: firmware crashed! (uuid 84901ff5-d33c-456e-93ee-0165dea643cf)
ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
ath10k_pci 0000:02:00.0: firmware register dump:
ath10k_pci 0000:02:00.0: [00]: 0x4100016C 0x00000000 0x009A0F2A 0x00000000
ath10k_pci 0000:02:00.0: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [16]: 0x00000000 0x00000000 0x00000000 0x009A0F2A
ath10k_pci 0000:02:00.0: [20]: 0x00000000 0x00401930 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: Copy Engine register dump:
ath10k_pci 0000:02:00.0: [00]: 0x00057400   7   7   3   3
ath10k_pci 0000:02:00.0: [01]: 0x00057800  18  18  85  86
ath10k_pci 0000:02:00.0: [02]: 0x00057c00  49  49  48  49
ath10k_pci 0000:02:00.0: [03]: 0x00058000  16  16  17  16
ath10k_pci 0000:02:00.0: [04]: 0x00058400   4   4  44   4
ath10k_pci 0000:02:00.0: [05]: 0x00058800  12  12  11  12
ath10k_pci 0000:02:00.0: [06]: 0x00058c00   3   3   3   3
ath10k_pci 0000:02:00.0: [07]: 0x00059000   0   0   0   0
ieee80211 phy0: Hardware restart was requested
ath10k_pci 0000:02:00.0: device successfully recovered
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: simplify the implementation]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The correct number for QCA9377 chip is 33 VDEVs.
This impacts also QCA6174 chip and it's max VDEV number.
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.

This is a hack and might cause subtle problems but as it's not enabled by
default (only when user space changes the coverage class explicitly) it should
not cause new problems for existing setups. But still this should be considered
as an experimental feature and used with caution.

This patch implements the support for first generation cards (QCA9880, QCA9887
and so on) which are based on a core that is similar to ath9k. The registers
are modified in place and need to be re-written every time the firmware sets
them. To achieve this the register status is verified after certain WMI events
from the firmware.

The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.

Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.
Signed-off-by: NBenjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
rx_hdr_status is not padded to align in 4-byte boundary. Define a
new hw_params field to handle different alignment behaviour between
different hw. This patch fixes improper retrieval of rfc1042 header
with QCA4019. This patch along with "ath10k: Properly remove padding
from the start of rx payload" will fix traffic failure in ethernet
decap mode for QCA4019.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Correct some trivial comment typos.
Remove unnecessary parentheses in a long line.
Signed-off-by: NJoe Perches <joe@perches.com>
[kvalo@qca.qualcomm.com: drop the change for return]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

hw_4addr_pad was added to handle different types of padding
in 4-address rx frame. But this padding is not very specific
to 4-address, it can happen even with three address + ethernet
decap mode. Since the  padding information can be obtained
through Rx desc for QCA99X0 and newer chips, this hw_param
is not needed any more.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In QCA99X0 (QCA99X0, QCA9984, QCA9888 and QCA4019) family chips,
hw adds padding at the begining of the rx payload to make L3
header 4-byte aligned. In the chips doing this type of padding,
the number of bytes padded will be indicated through msdu_end:info1.
Define a hw_rx_desc_ops wrapper to retrieve the number of padded
bytes and use this while doing undecap. This should fix padding
related issues with ethernt decap format with QCA99X0, QCA9984,
QCA9888 and QCA4019 hw.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[Rename operations to hw_ops for other purposes]
Signed-off-by: NBenjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

There are slight differences in Rx hw descriptor information
among different chips. So far driver does not use those new
information for any functionalities, but there is one important
information which is available from QCA99X0 onwards to indicate
the number of bytes that hw padded at the begining of the rx
payload and this information is needed to undecap the rx
packet. Add an abstraction for Rx desc to make use of the
new desc information available. The callback that this patch
defines to retrieve the padding bytes will be used in follow-up
patch.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[Rename operations to hw_ops for other purposes]
Signed-off-by: NBenjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This is to prepare for rx descriptor abstraction where we'll
be dereferencing ath10k_hw_params member in hw.h. Moreover
hw.h looks more suitable to house ath10k_hw_params definition
than core.h
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

QCA9888 shares the same configuration with QCA99X0
with NSS=2.
Signed-off-by: NAnilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

rtc_state_cold_reset_mask is unused in ath10k_hw_regs.
instead fixed delays are used.
Signed-off-by: NAnilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It is expected that all pktlog events for 10.4 firmware based solutions
should come through CE8 where as in case of 10.2 firmware based solutions,
it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG).

But from experiments with 10.4 based solutions, it is observed that pktlog
event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event.
Currently, we always parse with 10.2 pktlog header which will lead to
pktlog decoding issues (payload length mismatch exceptions)

For trace points, it is required to provide only the payload size. So
fixing this by simplifying the payload size calculation without the use of
ath10k pktlog headers.

While there, remove the unused ath10k pktlog headers.
Signed-off-by: NAshok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In QCA4019, cycle counter wraparound is not tied to rx
clear counter. Each counter would wraparound individually
and after wraparound the respective counter will be reset
to 0x7fffffff while other counter still running unaffected.
Define a new wraparound type for this behaviour and handle
it separately so that rx clear counter wraparound is also
handled just like cycle counter. With this type of
wraparound we can accurately compute and report channel
active/busy time when any of the counter overflows.

Fixes: ee9ca147 ("ath10k: Fix survey reporting with QCA4019")
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

QCA988X hw implements a different cycle counter wraparound
behaviour when compared to QCA4019. To properly handle different
wraparound logic for these chipsets replace already available
bool hw_params member, has_shifted_cc_wraparound, with an
enum which could be extended to handle different wraparound
behaviour. This patch keeps the existing logic functionally
same and a prepares cycle counter wraparound handling to
extend for other chips.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: change also QCA9887 wrap type]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below

ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,

This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The QCA9887 stores its calibration data (board.bin) inside the EEPROM of
the target. This has to be downloaded manually to allow the device to
initialize correctly.
Signed-off-by: NSven Eckelmann <sven.eckelmann@open-mesh.com>
[kvalo@qca.qualcomm.com: handle -EOPNOTSUPP and s/fetch_board_data/fetch_cal_eeprom]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add the hardware name, revision, firmware names and update the pci_id
table.

QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
he firmware interface are currently unknown.
Signed-off-by: NSven Eckelmann <sven.eckelmann@open-mesh.com>
[kvalo@qca.qualcomm.com: add a warning about experimental support]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

QCA9984 shares the same configuration with QCA99X0.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This has ben deprecated years ago, I haven't heard anyone using it since and
most likely it won't even work anymore. So just remove all of it.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

ath10k_download_cal_dt() compares obtained cal data content length
against QCA988X_CAL_DATA_LEN (2116 bytes). It was written by keeping
qca988x in mind. In fact, cal data length is more chip specific.
To make ath10k_download_cal_dt() more generic and reusable for other
chipsets (like qca4019), cal data length is moved to hw_params.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The number of HTT Tx descriptors and qcache peer
limit aren't hw-specific. In fact they are
firmware specific and should not be placed in
hw_params.

The QCA4019 limits were submitted with the peer
flow control firmware only and to my understanding
there's no non-peer-flow-ctrl QCA4019 firmware.

However QCA99X0 is planned to run firmware
supporting the feature as well. Therefore this
patch enables QCA99X0 to use 2500 tx descriptors
whenever possible instead of just 1424.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

To enable per peer stats feature we are reducing the number of peers.
Firmware has introduced tx stats feature. We have memory limitation in
firmware to add these additional bytes.

These are the new variables introduced in the firmware.
========		=======================
Variable	      	Bytes required/per rate
========		=======================
TX success packets 	1
TX failed packets	1
Retry packets		1
Success bytes		2
TX failed bytes		2
Retry bytes		2
Tx duration		4
Rate			1
Bw and AMPDU flags	1
Total			16 (because of allocation in word pattern)

Firmware sends these tx_stats in pktlog.
If we consider 4 feedbacks at a time, Frimware need about ~1K memory for coding
and 8192 bytes required / per rate [ 4*16*128(peers)].
To accommodate this firmware needs to reduce 10 peers.

This fixes a firmware crash with firmware-5.bin_10.2.4.70.22-2.
Signed-off-by: NAnilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Some of the parameter like tx/rx chain mask, number of htt tx desc,
qcache active peer count, etc goes via wmi init cmd to qca4019 firmware
are different.

To make use of 10.4 gen_init function for qca4019, change wmi service
ready handler and 10.4 wmi init functions to adapt qca4019 specific
init values.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add a new entry in hw_params_list for qca4019 with list of
it's own details.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Like how pci.c exposes hif ops for the bus specific operation,
expose similar hif ops table for ahb with all required functions
linked to it. Many ath10k_pci_* functions are reused here in hif ops
table. If something is not sharable, new functions are added for ahb
and linked to hif ops table.

Finally, make ath10k_ahb_probe/remove() to perform what is expected
out of it.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

New register table is added for qca4019 to tell about it's
register mapping details.

Nothing much other than this.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

qca4019 uses ahb instead of pci where it slightly differs in device
enumeration, clock control, reset control, etc. Good thing is that
ahb also uses copy engine for the data transaction. So, the most of
the stuff implemented in pci.c/ce.c are reusable in ahb case too.

Device enumeration in ahb case comes through platform driver/device
model. All resource details like irq, memory map, clocks, etc for
qca4019 can be fetched from of_node of platform device.

Simply flow would look like,

 device tree => platform device (kernel) => platform driver (ath10k)

Device tree entry will have all qca4019 resource details and the same
info will be passed to kernel. Kernel will prepare new platform device
for that entry and expose DT info to of_node in platform device.
Later, ath10k would register platform driver with unique compatible name
and then kernels binds to corresponding compatible entry & calls ath10k
ahb probe functions. From there onwards, ath10k will take control of it
and move forward.

New bool flag CONFIG_ATH10K_AHB is added in Kconfig to conditionally
enable ahb support in ath10k. On enabling this flag, ath10k_pci.ko
will have ahb support. This patch adds only basic skeleton and few
macros to support ahb in the context of qca4019.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The QCA99X0 4 addresses RX packets pad 2 bytes at the beginning of
MSDU instead the end of ieee80211 header to keep alignment. The currently RX
data path can't parse the header correctly in this case. This patch fixes it
for QCA99X0.
Signed-off-by: NYanbo Li <yanbol@qca.qualcomm.com>
[kvalo@qca.qualcomm.com: checkpatch fixes and naming changes]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add new BMI target version and chip id revision. Register it
on supported chips list.
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

A follow up patch introducing a QCA9377 hw1.0 support will need
this device identification helper for an explicit distinction of
HWs, as apparently both QCA6174 hw3.0 and QCA9377 share the same BMI
target version (0x0502000x). For the QCA9377 hw1.1 previously
added we were just lucky we did not overlap with the same chip_id_rev.
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

When introducing the original QCA9377 support, the chip target
version was wrongly picked. The chip advertising itself with
bmi target value equal to 0x05020001 is in fact a 1.1 revision.
I realized this once I got a real 1.1 hw to play with.
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This patch adds pktlog support for 10.4 fw versions.
Signed-off-by: NVivek Natarajan <nataraja@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add the hardware name, revision and update the pci_id table.

Currently there're two HW ref. designs available I'm aware of,
with 1.0.2 and 1.1 chip revisions. I've access and been using
the first one so far and this patch cover only it.

QCA9377 inherits most of the stuff (e.g. fw interfaces)
from QCA61x4 design, so the integration was pretty straightforward.
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add WMI-TLV and FW API support in ath10k testmode.
Ath10k can get right wmi command format from UTF image
to communicate UTF firmware.
Signed-off-by: NAlan Liu <alanliu@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

QCA6174 needs different board files based on board type. To make it easier to
distribute multiple board files and automatically choose correct board file
create a simple TLV file format following the same principles as with FW IEs.
The file is named board-2.bin and contain multiple board files. Each board file
then can have multiple names.

ath10k searches for file board-N.bin (where N is the interface version number
for the board file, just like we for firmware files) in /lib/firmware/*, for
example for qca99x0 it will try to find it here:

/lib/firmware/ath10k/QCA99X0/hw2.0/board-2.bin

If ath10k doesn't find board-2.bin then it will fallback to the old board.bin file.

This patch adds a simple name scheme using pci device id which for now will be
used by qca6174:

bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x

This removes the old method of having subsystem ids in ar->spec_board_id and
using that in the board file name.
Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: simplified the file format, rewrote commit log, other smaller changes]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>