1
0
Fork 0
alistair23-linux/drivers/net/wireless/ath/ath10k/core.c

3261 lines
85 KiB
C
Raw Normal View History

// SPDX-License-Identifier: ISC
/*
* Copyright (c) 2005-2011 Atheros Communications Inc.
* Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
* Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
*/
#include <linux/module.h>
#include <linux/firmware.h>
#include <linux/of.h>
#include <linux/property.h>
ath10k: search SMBIOS for OEM board file extension Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" If board data file name extension is set but board-2.bin does not contain board data file for the variant, the driver will fallback to the default board data file not to break backward compatibility. This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") but later reverted in commit 005c3490e9db ("Revert "ath10k: Search SMBIOS for OEM board file extension"". This patch is now otherwise the same as commit f2593cb1b291 except the regression fixed. Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-02-24 15:30:03 -07:00
#include <linux/dmi.h>
#include <linux/ctype.h>
#include <asm/byteorder.h>
#include "core.h"
#include "mac.h"
#include "htc.h"
#include "hif.h"
#include "wmi.h"
#include "bmi.h"
#include "debug.h"
#include "htt.h"
#include "testmode.h"
#include "wmi-ops.h"
#include "coredump.h"
unsigned int ath10k_debug_mask;
EXPORT_SYMBOL(ath10k_debug_mask);
ath10k: enable raw encap mode and software crypto engine This patch enables raw Rx/Tx encap mode to support software based crypto engine. This patch introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. Known limitation: A-MSDU must be disabled for RAW Tx encap mode to perform well when heavy traffic is applied. Testing: (by Michal Kazior <michal.kazior@tieto.com>) a) Performance Testing cryptmode=1 ap=qca988x sta=killer1525 killer1525 -> qca988x 194.496 mbps [tcp1 ip4] killer1525 -> qca988x 238.309 mbps [tcp5 ip4] killer1525 -> qca988x 266.958 mbps [udp1 ip4] killer1525 -> qca988x 477.468 mbps [udp5 ip4] qca988x -> killer1525 301.378 mbps [tcp1 ip4] qca988x -> killer1525 297.949 mbps [tcp5 ip4] qca988x -> killer1525 331.351 mbps [udp1 ip4] qca988x -> killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x -> killer1525 331.447 mbps [tcp1 ip4] qca988x -> killer1525 328.783 mbps [tcp5 ip4] qca988x -> killer1525 375.309 mbps [udp1 ip4] qca988x -> killer1525 403.379 mbps [udp5 ip4] killer1525 -> qca988x 203.689 mbps [tcp1 ip4] killer1525 -> qca988x 222.339 mbps [tcp5 ip4] killer1525 -> qca988x 264.199 mbps [udp1 ip4] killer1525 -> qca988x 479.371 mbps [udp5 ip4] Note: - only open network tested for RAW vs nwifi performance comparison - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) - used iperf - OTA, devices a few cm apart from each other, no shielding - tcpX/udpX, X - means number of threads used Overview: - relative Tx performance drop is seen but is within reasonable and expected threshold (A-MSDU must be disabled with RAW Tx) b) Connectivity Testing cryptmode=1 ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK Note: - each test takes all possible endpoint pairs and pings - each pair-ping flushes arp table - ip6 is used c) Testbed Topology: 1ap1sta: [ap] ---- [sta] endpoints: ap, sta 1ap1sta2br: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] endpoints: veth0, veth2, br0, br1 note: STA works in 4addr mode, AP has wds_sta=1 1ap1sta2br1vlan: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] | | [vlan0_id2] [vlan1_id2] endpoints: vlan0_id2, vlan1_id2 note: STA works in 4addr mode, AP has wds_sta=1 Credits: Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the amsdu issue, contributed a workaround (already squashed into this patch), and contributed the throughput and connectivity tests results. Signed-off-by: David Liu <cfliu.tw@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Tested-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-07-24 11:25:32 -06:00
static unsigned int ath10k_cryptmode_param;
static bool uart_print;
static bool skip_otp;
static bool rawmode;
static bool fw_diag_log;
unsigned long ath10k_coredump_mask = BIT(ATH10K_FW_CRASH_DUMP_REGISTERS) |
BIT(ATH10K_FW_CRASH_DUMP_CE_DATA);
/* FIXME: most of these should be readonly */
module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
ath10k: enable raw encap mode and software crypto engine This patch enables raw Rx/Tx encap mode to support software based crypto engine. This patch introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. Known limitation: A-MSDU must be disabled for RAW Tx encap mode to perform well when heavy traffic is applied. Testing: (by Michal Kazior <michal.kazior@tieto.com>) a) Performance Testing cryptmode=1 ap=qca988x sta=killer1525 killer1525 -> qca988x 194.496 mbps [tcp1 ip4] killer1525 -> qca988x 238.309 mbps [tcp5 ip4] killer1525 -> qca988x 266.958 mbps [udp1 ip4] killer1525 -> qca988x 477.468 mbps [udp5 ip4] qca988x -> killer1525 301.378 mbps [tcp1 ip4] qca988x -> killer1525 297.949 mbps [tcp5 ip4] qca988x -> killer1525 331.351 mbps [udp1 ip4] qca988x -> killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x -> killer1525 331.447 mbps [tcp1 ip4] qca988x -> killer1525 328.783 mbps [tcp5 ip4] qca988x -> killer1525 375.309 mbps [udp1 ip4] qca988x -> killer1525 403.379 mbps [udp5 ip4] killer1525 -> qca988x 203.689 mbps [tcp1 ip4] killer1525 -> qca988x 222.339 mbps [tcp5 ip4] killer1525 -> qca988x 264.199 mbps [udp1 ip4] killer1525 -> qca988x 479.371 mbps [udp5 ip4] Note: - only open network tested for RAW vs nwifi performance comparison - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) - used iperf - OTA, devices a few cm apart from each other, no shielding - tcpX/udpX, X - means number of threads used Overview: - relative Tx performance drop is seen but is within reasonable and expected threshold (A-MSDU must be disabled with RAW Tx) b) Connectivity Testing cryptmode=1 ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK Note: - each test takes all possible endpoint pairs and pings - each pair-ping flushes arp table - ip6 is used c) Testbed Topology: 1ap1sta: [ap] ---- [sta] endpoints: ap, sta 1ap1sta2br: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] endpoints: veth0, veth2, br0, br1 note: STA works in 4addr mode, AP has wds_sta=1 1ap1sta2br1vlan: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] | | [vlan0_id2] [vlan1_id2] endpoints: vlan0_id2, vlan1_id2 note: STA works in 4addr mode, AP has wds_sta=1 Credits: Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the amsdu issue, contributed a workaround (already squashed into this patch), and contributed the throughput and connectivity tests results. Signed-off-by: David Liu <cfliu.tw@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Tested-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-07-24 11:25:32 -06:00
module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
module_param(uart_print, bool, 0644);
module_param(skip_otp, bool, 0644);
module_param(rawmode, bool, 0644);
module_param(fw_diag_log, bool, 0644);
module_param_named(coredump_mask, ath10k_coredump_mask, ulong, 0444);
MODULE_PARM_DESC(debug_mask, "Debugging mask");
MODULE_PARM_DESC(uart_print, "Uart target debugging");
MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode");
ath10k: enable raw encap mode and software crypto engine This patch enables raw Rx/Tx encap mode to support software based crypto engine. This patch introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. Known limitation: A-MSDU must be disabled for RAW Tx encap mode to perform well when heavy traffic is applied. Testing: (by Michal Kazior <michal.kazior@tieto.com>) a) Performance Testing cryptmode=1 ap=qca988x sta=killer1525 killer1525 -> qca988x 194.496 mbps [tcp1 ip4] killer1525 -> qca988x 238.309 mbps [tcp5 ip4] killer1525 -> qca988x 266.958 mbps [udp1 ip4] killer1525 -> qca988x 477.468 mbps [udp5 ip4] qca988x -> killer1525 301.378 mbps [tcp1 ip4] qca988x -> killer1525 297.949 mbps [tcp5 ip4] qca988x -> killer1525 331.351 mbps [udp1 ip4] qca988x -> killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x -> killer1525 331.447 mbps [tcp1 ip4] qca988x -> killer1525 328.783 mbps [tcp5 ip4] qca988x -> killer1525 375.309 mbps [udp1 ip4] qca988x -> killer1525 403.379 mbps [udp5 ip4] killer1525 -> qca988x 203.689 mbps [tcp1 ip4] killer1525 -> qca988x 222.339 mbps [tcp5 ip4] killer1525 -> qca988x 264.199 mbps [udp1 ip4] killer1525 -> qca988x 479.371 mbps [udp5 ip4] Note: - only open network tested for RAW vs nwifi performance comparison - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) - used iperf - OTA, devices a few cm apart from each other, no shielding - tcpX/udpX, X - means number of threads used Overview: - relative Tx performance drop is seen but is within reasonable and expected threshold (A-MSDU must be disabled with RAW Tx) b) Connectivity Testing cryptmode=1 ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK Note: - each test takes all possible endpoint pairs and pings - each pair-ping flushes arp table - ip6 is used c) Testbed Topology: 1ap1sta: [ap] ---- [sta] endpoints: ap, sta 1ap1sta2br: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] endpoints: veth0, veth2, br0, br1 note: STA works in 4addr mode, AP has wds_sta=1 1ap1sta2br1vlan: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] | | [vlan0_id2] [vlan1_id2] endpoints: vlan0_id2, vlan1_id2 note: STA works in 4addr mode, AP has wds_sta=1 Credits: Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the amsdu issue, contributed a workaround (already squashed into this patch), and contributed the throughput and connectivity tests results. Signed-off-by: David Liu <cfliu.tw@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Tested-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-07-24 11:25:32 -06:00
MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software");
MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath");
MODULE_PARM_DESC(coredump_mask, "Bitfield of what to include in firmware crash file");
MODULE_PARM_DESC(fw_diag_log, "Diag based fw log debugging");
static const struct ath10k_hw_params ath10k_hw_params_list[] = {
{
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca988x hw2.0",
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 2116,
.fw = {
.dir = QCA988X_HW_2_0_FW_DIR,
.board = QCA988X_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA988X_BOARD_DATA_SZ,
.board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca988x_ops,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = true,
},
{
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
.name = "qca988x hw2.0 ubiquiti",
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 2116,
.fw = {
.dir = QCA988X_HW_2_0_FW_DIR,
.board = QCA988X_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA988X_BOARD_DATA_SZ,
.board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca988x_ops,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = true,
},
{
.id = QCA9887_HW_1_0_VERSION,
.dev_id = QCA9887_1_0_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca9887 hw1.0",
.patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 2116,
.fw = {
.dir = QCA9887_HW_1_0_FW_DIR,
.board = QCA9887_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA9887_BOARD_DATA_SZ,
.board_ext_size = QCA9887_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca988x_ops,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_3_2_VERSION,
.dev_id = QCA6174_3_2_DEVICE_ID,
.bus = ATH10K_BUS_SDIO,
.name = "qca6174 hw3.2 sdio",
.patch_load_addr = QCA6174_HW_3_0_PATCH_LOAD_ADDR,
.uart_pin = 19,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 0,
.fw = {
.dir = QCA6174_HW_3_0_FW_DIR,
.board = QCA6174_HW_3_0_BOARD_DATA_FILE,
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca6174_sdio_ops,
.hw_clk = qca6174_clk,
.target_cpu_freq = 176000000,
.decap_align_bytes = 4,
.n_cipher_suites = 8,
.num_peers = 10,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.uart_pin_workaround = true,
.tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_2_1_VERSION,
.dev_id = QCA6164_2_1_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca6164 hw2.1",
.patch_load_addr = QCA6174_HW_2_1_PATCH_LOAD_ADDR,
.uart_pin = 6,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_2_1_FW_DIR,
.board = QCA6174_HW_2_1_BOARD_DATA_FILE,
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca988x_ops,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_2_1_VERSION,
.dev_id = QCA6174_2_1_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca6174 hw2.1",
.patch_load_addr = QCA6174_HW_2_1_PATCH_LOAD_ADDR,
.uart_pin = 6,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_2_1_FW_DIR,
.board = QCA6174_HW_2_1_BOARD_DATA_FILE,
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca988x_ops,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_3_0_VERSION,
.dev_id = QCA6174_2_1_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca6174 hw3.0",
.patch_load_addr = QCA6174_HW_3_0_PATCH_LOAD_ADDR,
.uart_pin = 6,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_3_0_FW_DIR,
.board = QCA6174_HW_3_0_BOARD_DATA_FILE,
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca988x_ops,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_3_2_VERSION,
.dev_id = QCA6174_2_1_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca6174 hw3.2",
.patch_load_addr = QCA6174_HW_3_0_PATCH_LOAD_ADDR,
.uart_pin = 6,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 8124,
.fw = {
/* uses same binaries as hw3.0 */
.dir = QCA6174_HW_3_0_FW_DIR,
.board = QCA6174_HW_3_0_BOARD_DATA_FILE,
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
2017-03-08 04:52:04 -07:00
.hw_ops = &qca6174_ops,
.hw_clk = qca6174_clk,
.target_cpu_freq = 176000000,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = true,
.tx_stats_over_pktlog = false,
},
{
.id = QCA99X0_HW_2_0_DEV_VERSION,
.dev_id = QCA99X0_2_0_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca99x0 hw2.0",
.patch_load_addr = QCA99X0_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.otp_exe_param = 0x00000700,
.continuous_frag_desc = true,
.cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 150000,
.max_probe_resp_desc_thres = 24,
.tx_chain_mask = 0xf,
.rx_chain_mask = 0xf,
.max_spatial_stream = 4,
.cal_data_len = 12064,
.fw = {
.dir = QCA99X0_HW_2_0_FW_DIR,
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
.sw_decrypt_mcast_mgmt = true,
.hw_ops = &qca99x0_ops,
.decap_align_bytes = 1,
.spectral_bin_discard = 4,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 11,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
.dev_id = QCA9984_1_0_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca9984/qca9994 hw1.0",
.patch_load_addr = QCA9984_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
.otp_exe_param = 0x00000700,
.continuous_frag_desc = true,
.cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 150000,
.max_probe_resp_desc_thres = 24,
.tx_chain_mask = 0xf,
.rx_chain_mask = 0xf,
.max_spatial_stream = 4,
.cal_data_len = 12064,
.fw = {
.dir = QCA9984_HW_1_0_FW_DIR,
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
.eboard = QCA9984_HW_1_0_EBOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
.ext_board_size = QCA99X0_EXT_BOARD_DATA_SZ,
},
.sw_decrypt_mcast_mgmt = true,
.hw_ops = &qca99x0_ops,
.decap_align_bytes = 1,
.spectral_bin_discard = 12,
.spectral_bin_offset = 8,
/* Can do only 2x2 VHT160 or 80+80. 1560Mbps is 4x4 80Mhz
* or 2x2 160Mhz, long-guard-interval.
*/
.vht160_mcs_rx_highest = 1560,
.vht160_mcs_tx_highest = 1560,
.n_cipher_suites = 11,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
.dev_id = QCA9888_2_0_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca9888 hw2.0",
.patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
.otp_exe_param = 0x00000700,
.continuous_frag_desc = true,
.channel_counters_freq_hz = 150000,
.max_probe_resp_desc_thres = 24,
.tx_chain_mask = 3,
.rx_chain_mask = 3,
.max_spatial_stream = 2,
.cal_data_len = 12064,
.fw = {
.dir = QCA9888_HW_2_0_FW_DIR,
.board = QCA9888_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
.sw_decrypt_mcast_mgmt = true,
.hw_ops = &qca99x0_ops,
.decap_align_bytes = 1,
.spectral_bin_discard = 12,
.spectral_bin_offset = 8,
/* Can do only 1x1 VHT160 or 80+80. 780Mbps is 2x2 80Mhz or
* 1x1 160Mhz, long-guard-interval.
*/
.vht160_mcs_rx_highest = 780,
.vht160_mcs_tx_highest = 780,
.n_cipher_suites = 11,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
.dev_id = QCA9377_1_0_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca9377 hw1.0",
.patch_load_addr = QCA9377_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 6,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 8124,
.fw = {
.dir = QCA9377_HW_1_0_FW_DIR,
.board = QCA9377_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA9377_BOARD_DATA_SZ,
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca988x_ops,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = QCA9377_HW_1_1_DEV_VERSION,
.dev_id = QCA9377_1_0_DEVICE_ID,
.bus = ATH10K_BUS_PCI,
.name = "qca9377 hw1.1",
.patch_load_addr = QCA9377_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 6,
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.cal_data_len = 8124,
.fw = {
.dir = QCA9377_HW_1_0_FW_DIR,
.board = QCA9377_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA9377_BOARD_DATA_SZ,
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
.hw_ops = &qca6174_ops,
.hw_clk = qca6174_clk,
.target_cpu_freq = 176000000,
.decap_align_bytes = 4,
.spectral_bin_discard = 0,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 8,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = true,
.tx_stats_over_pktlog = false,
},
{
.id = QCA4019_HW_1_0_DEV_VERSION,
.dev_id = 0,
.bus = ATH10K_BUS_AHB,
.name = "qca4019 hw1.0",
.patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
.otp_exe_param = 0x0010000,
.continuous_frag_desc = true,
.cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 125000,
.max_probe_resp_desc_thres = 24,
.tx_chain_mask = 0x3,
.rx_chain_mask = 0x3,
.max_spatial_stream = 2,
.cal_data_len = 12064,
.fw = {
.dir = QCA4019_HW_1_0_FW_DIR,
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
},
.sw_decrypt_mcast_mgmt = true,
.hw_ops = &qca99x0_ops,
.decap_align_bytes = 1,
.spectral_bin_discard = 4,
.spectral_bin_offset = 0,
.vht160_mcs_rx_highest = 0,
.vht160_mcs_tx_highest = 0,
.n_cipher_suites = 11,
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.target_64bit = false,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
.per_ce_irq = false,
.shadow_reg_support = false,
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
{
.id = WCN3990_HW_1_0_DEV_VERSION,
.dev_id = 0,
.bus = ATH10K_BUS_SNOC,
.name = "wcn3990 hw1.0",
.continuous_frag_desc = true,
.tx_chain_mask = 0x7,
.rx_chain_mask = 0x7,
.max_spatial_stream = 4,
.fw = {
.dir = WCN3990_HW_1_0_FW_DIR,
},
.sw_decrypt_mcast_mgmt = true,
.hw_ops = &wcn3990_ops,
.decap_align_bytes = 1,
.num_peers = TARGET_HL_TLV_NUM_PEERS,
.n_cipher_suites = 11,
.ast_skid_limit = TARGET_HL_TLV_AST_SKID_LIMIT,
.num_wds_entries = TARGET_HL_TLV_NUM_WDS_ENTRIES,
.target_64bit = true,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL_DUAL_MAC,
.per_ce_irq = true,
.shadow_reg_support = true,
.rri_on_ddr = true,
.hw_filter_reset_required = false,
.fw_diag_ce_download = false,
.tx_stats_over_pktlog = false,
},
};
static const char *const ath10k_core_fw_feature_str[] = {
[ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX] = "wmi-mgmt-rx",
[ATH10K_FW_FEATURE_WMI_10X] = "wmi-10.x",
[ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX] = "has-wmi-mgmt-tx",
[ATH10K_FW_FEATURE_NO_P2P] = "no-p2p",
[ATH10K_FW_FEATURE_WMI_10_2] = "wmi-10.2",
[ATH10K_FW_FEATURE_MULTI_VIF_PS_SUPPORT] = "multi-vif-ps",
[ATH10K_FW_FEATURE_WOWLAN_SUPPORT] = "wowlan",
[ATH10K_FW_FEATURE_IGNORE_OTP_RESULT] = "ignore-otp",
[ATH10K_FW_FEATURE_NO_NWIFI_DECAP_4ADDR_PADDING] = "no-4addr-pad",
[ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT] = "skip-clock-init",
[ATH10K_FW_FEATURE_RAW_MODE_SUPPORT] = "raw-mode",
[ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
[ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
[ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
[ATH10K_FW_FEATURE_BTCOEX_PARAM] = "btcoex-param",
[ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR] = "skip-null-func-war",
[ATH10K_FW_FEATURE_ALLOWS_MESH_BCAST] = "allows-mesh-bcast",
[ATH10K_FW_FEATURE_NO_PS] = "no-ps",
[ATH10K_FW_FEATURE_MGMT_TX_BY_REF] = "mgmt-tx-by-reference",
[ATH10K_FW_FEATURE_NON_BMI] = "non-bmi",
[ATH10K_FW_FEATURE_SINGLE_CHAN_INFO_PER_CHANNEL] = "single-chan-info-per-channel",
ath10k: fix failure to set multiple fixed rate Currently, below fixed rate commands are broken, iw wlanx set bitrates legacy-<2.4|5> ht-mcs-<2.4|5> vht-mcs-<2.4|5> \ <NSS:MCSx> iw wlanx set bitrates legacy-<2.4|5> <legacy rate> ht-mcs-<2.4|5> \ vht-mcs-<2.4|5> <NSS:MCSx> There are two methods to set fixed rate, both failed, - Use vdev fixed rate command This command only support one single rate, but it's broken due to mac80211 change commit e8e4f5280ddd ("mac80211: reject/clear user rate mask if not usable"), which requires user to specify at least one legacy rate. So we can't use this command to set ht/vht single rate any more. - Use peer_assoc command This command can update rx capability for multiple rates, it will work fine for ht mcs rates, as each supported mcs can be advertised in ht_mcs index mask. But this will not work with vht rates because, as per the vht mcs capability advertisement, there are only two bits to indicate the supported mcs. E.g. only support 0-7, 0-8, 0-9. So introduced new WMI command: WMI_PEER_PARAM_FIXED_RATE. After peer assoc, the peer fixed rate cmd will work for that specific peer. Remaining peers will use auto rate. If both vdev fixed rate and peer fixed rates are given, peer fixed rate will take effect to peers for which this cmd is given. Remaining peers in that vdev, will use vdev fixed rate. Tested HW: QCA9984 Tested FW: 10.4-3.9.0.2-00035 Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-05-29 02:13:28 -06:00
[ATH10K_FW_FEATURE_PEER_FIXED_RATE] = "peer-fixed-rate",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
size_t buf_len,
enum ath10k_fw_features feat)
{
/* make sure that ath10k_core_fw_feature_str[] gets updated */
BUILD_BUG_ON(ARRAY_SIZE(ath10k_core_fw_feature_str) !=
ATH10K_FW_FEATURE_COUNT);
if (feat >= ARRAY_SIZE(ath10k_core_fw_feature_str) ||
WARN_ON(!ath10k_core_fw_feature_str[feat])) {
return scnprintf(buf, buf_len, "bit%d", feat);
}
return scnprintf(buf, buf_len, "%s", ath10k_core_fw_feature_str[feat]);
}
void ath10k_core_get_fw_features_str(struct ath10k *ar,
char *buf,
size_t buf_len)
{
size_t len = 0;
int i;
for (i = 0; i < ATH10K_FW_FEATURE_COUNT; i++) {
if (test_bit(i, ar->normal_mode_fw.fw_file.fw_features)) {
if (len > 0)
len += scnprintf(buf + len, buf_len - len, ",");
len += ath10k_core_get_fw_feature_str(buf + len,
buf_len - len,
i);
}
}
}
static void ath10k_send_suspend_complete(struct ath10k *ar)
{
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot suspend complete\n");
complete(&ar->target_suspend);
}
static void ath10k_init_sdio(struct ath10k *ar, enum ath10k_firmware_mode mode)
{
u32 param = 0;
ath10k_bmi_write32(ar, hi_mbox_io_block_sz, 256);
ath10k_bmi_write32(ar, hi_mbox_isr_yield_limit, 99);
ath10k_bmi_read32(ar, hi_acs_flags, &param);
/* Data transfer is not initiated, when reduced Tx completion
* is used for SDIO. disable it until fixed
*/
param &= ~HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET;
/* Alternate credit size of 1544 as used by SDIO firmware is
* not big enough for mac80211 / native wifi frames. disable it
*/
param &= ~HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE;
if (mode == ATH10K_FIRMWARE_MODE_UTF)
param &= ~HI_ACS_FLAGS_SDIO_SWAP_MAILBOX_SET;
else
param |= HI_ACS_FLAGS_SDIO_SWAP_MAILBOX_SET;
ath10k_bmi_write32(ar, hi_acs_flags, param);
/* Explicitly set fwlog prints to zero as target may turn it on
* based on scratch registers.
*/
ath10k_bmi_read32(ar, hi_option_flag, &param);
param |= HI_OPTION_DISABLE_DBGLOG;
ath10k_bmi_write32(ar, hi_option_flag, param);
}
static int ath10k_init_configure_target(struct ath10k *ar)
{
u32 param_host;
int ret;
/* tell target which HTC version it is used*/
ret = ath10k_bmi_write32(ar, hi_app_host_interest,
HTC_PROTOCOL_VERSION);
if (ret) {
ath10k_err(ar, "settings HTC version failed\n");
return ret;
}
/* set the firmware mode to STA/IBSS/AP */
ret = ath10k_bmi_read32(ar, hi_option_flag, &param_host);
if (ret) {
ath10k_err(ar, "setting firmware mode (1/2) failed\n");
return ret;
}
/* TODO following parameters need to be re-visited. */
/* num_device */
param_host |= (1 << HI_OPTION_NUM_DEV_SHIFT);
/* Firmware mode */
/* FIXME: Why FW_MODE_AP ??.*/
param_host |= (HI_OPTION_FW_MODE_AP << HI_OPTION_FW_MODE_SHIFT);
/* mac_addr_method */
param_host |= (1 << HI_OPTION_MAC_ADDR_METHOD_SHIFT);
/* firmware_bridge */
param_host |= (0 << HI_OPTION_FW_BRIDGE_SHIFT);
/* fwsubmode */
param_host |= (0 << HI_OPTION_FW_SUBMODE_SHIFT);
ret = ath10k_bmi_write32(ar, hi_option_flag, param_host);
if (ret) {
ath10k_err(ar, "setting firmware mode (2/2) failed\n");
return ret;
}
/* We do all byte-swapping on the host */
ret = ath10k_bmi_write32(ar, hi_be, 0);
if (ret) {
ath10k_err(ar, "setting host CPU BE mode failed\n");
return ret;
}
/* FW descriptor/Data swap flags */
ret = ath10k_bmi_write32(ar, hi_fw_swap, 0);
if (ret) {
ath10k_err(ar, "setting FW data/desc swap flags failed\n");
return ret;
}
/* Some devices have a special sanity check that verifies the PCI
* Device ID is written to this host interest var. It is known to be
* required to boot QCA6164.
*/
ret = ath10k_bmi_write32(ar, hi_hci_uart_pwr_mgmt_params_ext,
ar->dev_id);
if (ret) {
ath10k_err(ar, "failed to set pwr_mgmt_params: %d\n", ret);
return ret;
}
return 0;
}
static const struct firmware *ath10k_fetch_fw_file(struct ath10k *ar,
const char *dir,
const char *file)
{
char filename[100];
const struct firmware *fw;
int ret;
if (file == NULL)
return ERR_PTR(-ENOENT);
if (dir == NULL)
dir = ".";
snprintf(filename, sizeof(filename), "%s/%s", dir, file);
ret = firmware_request_nowarn(&fw, filename, ar->dev);
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot fw request '%s': %d\n",
filename, ret);
if (ret)
return ERR_PTR(ret);
return fw;
}
static int ath10k_push_board_ext_data(struct ath10k *ar, const void *data,
size_t data_len)
{
u32 board_data_size = ar->hw_params.fw.board_size;
u32 board_ext_data_size = ar->hw_params.fw.board_ext_size;
u32 board_ext_data_addr;
int ret;
ret = ath10k_bmi_read32(ar, hi_board_ext_data, &board_ext_data_addr);
if (ret) {
ath10k_err(ar, "could not read board ext data addr (%d)\n",
ret);
return ret;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot push board extended data addr 0x%x\n",
board_ext_data_addr);
if (board_ext_data_addr == 0)
return 0;
if (data_len != (board_data_size + board_ext_data_size)) {
ath10k_err(ar, "invalid board (ext) data sizes %zu != %d+%d\n",
data_len, board_data_size, board_ext_data_size);
return -EINVAL;
}
ret = ath10k_bmi_write_memory(ar, board_ext_data_addr,
data + board_data_size,
board_ext_data_size);
if (ret) {
ath10k_err(ar, "could not write board ext data (%d)\n", ret);
return ret;
}
ret = ath10k_bmi_write32(ar, hi_board_ext_data_config,
(board_ext_data_size << 16) | 1);
if (ret) {
ath10k_err(ar, "could not write board ext data bit (%d)\n",
ret);
return ret;
}
return 0;
}
static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
{
u32 result, address;
u8 board_id, chip_id;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
bool ext_bid_support;
int ret, bmi_board_id_param;
address = ar->hw_params.patch_load_addr;
if (!ar->normal_mode_fw.fw_file.otp_data ||
!ar->normal_mode_fw.fw_file.otp_len) {
ath10k_warn(ar,
"failed to retrieve board id because of invalid otp\n");
return -ENODATA;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot upload otp to 0x%x len %zd for board id\n",
address, ar->normal_mode_fw.fw_file.otp_len);
ret = ath10k_bmi_fast_download(ar, address,
ar->normal_mode_fw.fw_file.otp_data,
ar->normal_mode_fw.fw_file.otp_len);
if (ret) {
ath10k_err(ar, "could not write otp for board id check: %d\n",
ret);
return ret;
}
if (ar->cal_mode == ATH10K_PRE_CAL_MODE_DT ||
ar->cal_mode == ATH10K_PRE_CAL_MODE_FILE)
bmi_board_id_param = BMI_PARAM_GET_FLASH_BOARD_ID;
else
bmi_board_id_param = BMI_PARAM_GET_EEPROM_BOARD_ID;
ret = ath10k_bmi_execute(ar, address, bmi_board_id_param, &result);
if (ret) {
ath10k_err(ar, "could not execute otp for board id check: %d\n",
ret);
return ret;
}
board_id = MS(result, ATH10K_BMI_BOARD_ID_FROM_OTP);
chip_id = MS(result, ATH10K_BMI_CHIP_ID_FROM_OTP);
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ext_bid_support = (result & ATH10K_BMI_EXT_BOARD_ID_SUPPORT);
ath10k_dbg(ar, ATH10K_DBG_BOOT,
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
"boot get otp board id result 0x%08x board_id %d chip_id %d ext_bid_support %d\n",
result, board_id, chip_id, ext_bid_support);
ar->id.ext_bid_supported = ext_bid_support;
if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0 ||
(board_id == 0)) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"board id does not exist in otp, ignore it\n");
return -EOPNOTSUPP;
}
ar->id.bmi_ids_valid = true;
ar->id.bmi_board_id = board_id;
ar->id.bmi_chip_id = chip_id;
return 0;
}
ath10k: search SMBIOS for OEM board file extension Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" If board data file name extension is set but board-2.bin does not contain board data file for the variant, the driver will fallback to the default board data file not to break backward compatibility. This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") but later reverted in commit 005c3490e9db ("Revert "ath10k: Search SMBIOS for OEM board file extension"". This patch is now otherwise the same as commit f2593cb1b291 except the regression fixed. Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-02-24 15:30:03 -07:00
static void ath10k_core_check_bdfext(const struct dmi_header *hdr, void *data)
{
struct ath10k *ar = data;
const char *bdf_ext;
const char *magic = ATH10K_SMBIOS_BDF_EXT_MAGIC;
u8 bdf_enabled;
int i;
if (hdr->type != ATH10K_SMBIOS_BDF_EXT_TYPE)
return;
if (hdr->length != ATH10K_SMBIOS_BDF_EXT_LENGTH) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"wrong smbios bdf ext type length (%d).\n",
hdr->length);
return;
}
bdf_enabled = *((u8 *)hdr + ATH10K_SMBIOS_BDF_EXT_OFFSET);
if (!bdf_enabled) {
ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not found.\n");
return;
}
/* Only one string exists (per spec) */
bdf_ext = (char *)hdr + hdr->length;
if (memcmp(bdf_ext, magic, strlen(magic)) != 0) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"bdf variant magic does not match.\n");
return;
}
for (i = 0; i < strlen(bdf_ext); i++) {
if (!isascii(bdf_ext[i]) || !isprint(bdf_ext[i])) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"bdf variant name contains non ascii chars.\n");
return;
}
}
/* Copy extension name without magic suffix */
if (strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
sizeof(ar->id.bdf_ext)) < 0) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"bdf variant string is longer than the buffer can accommodate (variant: %s)\n",
bdf_ext);
return;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"found and validated bdf variant smbios_type 0x%x bdf %s\n",
ATH10K_SMBIOS_BDF_EXT_TYPE, bdf_ext);
}
static int ath10k_core_check_smbios(struct ath10k *ar)
{
ar->id.bdf_ext[0] = '\0';
dmi_walk(ath10k_core_check_bdfext, ar);
if (ar->id.bdf_ext[0] == '\0')
return -ENODATA;
return 0;
}
static int ath10k_core_check_dt(struct ath10k *ar)
{
struct device_node *node;
const char *variant = NULL;
node = ar->dev->of_node;
if (!node)
return -ENOENT;
of_property_read_string(node, "qcom,ath10k-calibration-variant",
&variant);
if (!variant)
return -ENODATA;
if (strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)) < 0)
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"bdf variant string is longer than the buffer can accommodate (variant: %s)\n",
variant);
return 0;
}
static int ath10k_download_fw(struct ath10k *ar)
{
u32 address, data_len;
const void *data;
int ret;
address = ar->hw_params.patch_load_addr;
data = ar->running_fw->fw_file.firmware_data;
data_len = ar->running_fw->fw_file.firmware_len;
ret = ath10k_swap_code_seg_configure(ar, &ar->running_fw->fw_file);
if (ret) {
ath10k_err(ar, "failed to configure fw code swap: %d\n",
ret);
return ret;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot uploading firmware image %pK len %d\n",
data, data_len);
/* Check if device supports to download firmware via
* diag copy engine. Downloading firmware via diag CE
* greatly reduces the time to download firmware.
*/
if (ar->hw_params.fw_diag_ce_download) {
ret = ath10k_hw_diag_fast_download(ar, address,
data, data_len);
if (ret == 0)
/* firmware upload via diag ce was successful */
return 0;
ath10k_warn(ar,
"failed to upload firmware via diag ce, trying BMI: %d",
ret);
}
return ath10k_bmi_fast_download(ar, address,
data, data_len);
}
void ath10k_core_free_board_files(struct ath10k *ar)
{
if (!IS_ERR(ar->normal_mode_fw.board))
release_firmware(ar->normal_mode_fw.board);
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
if (!IS_ERR(ar->normal_mode_fw.ext_board))
release_firmware(ar->normal_mode_fw.ext_board);
ar->normal_mode_fw.board = NULL;
ar->normal_mode_fw.board_data = NULL;
ar->normal_mode_fw.board_len = 0;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ar->normal_mode_fw.ext_board = NULL;
ar->normal_mode_fw.ext_board_data = NULL;
ar->normal_mode_fw.ext_board_len = 0;
}
EXPORT_SYMBOL(ath10k_core_free_board_files);
static void ath10k_core_free_firmware_files(struct ath10k *ar)
{
if (!IS_ERR(ar->normal_mode_fw.fw_file.firmware))
release_firmware(ar->normal_mode_fw.fw_file.firmware);
if (!IS_ERR(ar->cal_file))
release_firmware(ar->cal_file);
if (!IS_ERR(ar->pre_cal_file))
release_firmware(ar->pre_cal_file);
ath10k_swap_code_seg_release(ar, &ar->normal_mode_fw.fw_file);
ar->normal_mode_fw.fw_file.otp_data = NULL;
ar->normal_mode_fw.fw_file.otp_len = 0;
ar->normal_mode_fw.fw_file.firmware = NULL;
ar->normal_mode_fw.fw_file.firmware_data = NULL;
ar->normal_mode_fw.fw_file.firmware_len = 0;
ar->cal_file = NULL;
ar->pre_cal_file = NULL;
}
static int ath10k_fetch_cal_file(struct ath10k *ar)
{
char filename[100];
ath10k: incorporate qca4019 cal data download sequence qca4019 calibration data is stored in the host memory and it's mandatory to download it even before reading board id and chip id from the target. Also, there is a need to execute otp (download and run) twice, one after cal data download and another one after board data download. Existing cal data file name 'cal-<bus>-<id>.bin' and device tree entry 'qcom,ath10k-calibration-data' used in ath10k has assumption that it carries other data (like board data) also along with the calibration data. But, qca4019 cal data contains pure calibration data (doesn't include any other info). So, using existing same cal file name and DT entry in qca4019 case would alter the purpose of it. To avoid this, new cal file name 'pre-cal-<bus>-<id>.bin' and new device tree entry name 'qcom,ath10k-pre-calibration-data are introduced. Overall qca4019's firmware download sequence would look like, 1) Download cal data (either from a file or device tree entry) at the address specified by target in the host interest area member "hi_board_data". 2) Download otp and run with 0x10 (PARAM_GET_EEPROM_BOARD_ID) as a argument. At this point, otp will take back up of downloaded cal data content in another location in the target and return valid board id and chip id to the host. 3) Download board data at the address specified by target in host interest area member "hi_board_data". 4) Download otp and run with 0x10000 (PARAM_FLASH_SECTION_ALL) as a argument. Now otp will apply cal data content from it's backup on top of board data download in step 3 and prepare final data base. 5) Download code swap and athwlan binary content. Above sequences are implemented (step 1 to step 4) in the name of pre calibration configuration. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-18 03:44:22 -06:00
/* pre-cal-<bus>-<id>.bin */
scnprintf(filename, sizeof(filename), "pre-cal-%s-%s.bin",
ath10k_bus_str(ar->hif.bus), dev_name(ar->dev));
ar->pre_cal_file = ath10k_fetch_fw_file(ar, ATH10K_FW_DIR, filename);
if (!IS_ERR(ar->pre_cal_file))
goto success;
/* cal-<bus>-<id>.bin */
scnprintf(filename, sizeof(filename), "cal-%s-%s.bin",
ath10k_bus_str(ar->hif.bus), dev_name(ar->dev));
ar->cal_file = ath10k_fetch_fw_file(ar, ATH10K_FW_DIR, filename);
if (IS_ERR(ar->cal_file))
/* calibration file is optional, don't print any warnings */
return PTR_ERR(ar->cal_file);
ath10k: incorporate qca4019 cal data download sequence qca4019 calibration data is stored in the host memory and it's mandatory to download it even before reading board id and chip id from the target. Also, there is a need to execute otp (download and run) twice, one after cal data download and another one after board data download. Existing cal data file name 'cal-<bus>-<id>.bin' and device tree entry 'qcom,ath10k-calibration-data' used in ath10k has assumption that it carries other data (like board data) also along with the calibration data. But, qca4019 cal data contains pure calibration data (doesn't include any other info). So, using existing same cal file name and DT entry in qca4019 case would alter the purpose of it. To avoid this, new cal file name 'pre-cal-<bus>-<id>.bin' and new device tree entry name 'qcom,ath10k-pre-calibration-data are introduced. Overall qca4019's firmware download sequence would look like, 1) Download cal data (either from a file or device tree entry) at the address specified by target in the host interest area member "hi_board_data". 2) Download otp and run with 0x10 (PARAM_GET_EEPROM_BOARD_ID) as a argument. At this point, otp will take back up of downloaded cal data content in another location in the target and return valid board id and chip id to the host. 3) Download board data at the address specified by target in host interest area member "hi_board_data". 4) Download otp and run with 0x10000 (PARAM_FLASH_SECTION_ALL) as a argument. Now otp will apply cal data content from it's backup on top of board data download in step 3 and prepare final data base. 5) Download code swap and athwlan binary content. Above sequences are implemented (step 1 to step 4) in the name of pre calibration configuration. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-18 03:44:22 -06:00
success:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "found calibration file %s/%s\n",
ATH10K_FW_DIR, filename);
return 0;
}
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
static int ath10k_core_fetch_board_data_api_1(struct ath10k *ar, int bd_ie_type)
{
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
const struct firmware *fw;
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
if (bd_ie_type == ATH10K_BD_IE_BOARD) {
if (!ar->hw_params.fw.board) {
ath10k_err(ar, "failed to find board file fw entry\n");
return -EINVAL;
}
ar->normal_mode_fw.board = ath10k_fetch_fw_file(ar,
ar->hw_params.fw.dir,
ar->hw_params.fw.board);
if (IS_ERR(ar->normal_mode_fw.board))
return PTR_ERR(ar->normal_mode_fw.board);
ar->normal_mode_fw.board_data = ar->normal_mode_fw.board->data;
ar->normal_mode_fw.board_len = ar->normal_mode_fw.board->size;
} else if (bd_ie_type == ATH10K_BD_IE_BOARD_EXT) {
if (!ar->hw_params.fw.eboard) {
ath10k_err(ar, "failed to find eboard file fw entry\n");
return -EINVAL;
}
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
fw = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir,
ar->hw_params.fw.eboard);
ar->normal_mode_fw.ext_board = fw;
if (IS_ERR(ar->normal_mode_fw.ext_board))
return PTR_ERR(ar->normal_mode_fw.ext_board);
ar->normal_mode_fw.ext_board_data = ar->normal_mode_fw.ext_board->data;
ar->normal_mode_fw.ext_board_len = ar->normal_mode_fw.ext_board->size;
}
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
return 0;
}
static int ath10k_core_parse_bd_ie_board(struct ath10k *ar,
const void *buf, size_t buf_len,
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
const char *boardname,
int bd_ie_type)
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
{
const struct ath10k_fw_ie *hdr;
bool name_match_found;
int ret, board_ie_id;
size_t board_ie_len;
const void *board_ie_data;
name_match_found = false;
/* go through ATH10K_BD_IE_BOARD_ elements */
while (buf_len > sizeof(struct ath10k_fw_ie)) {
hdr = buf;
board_ie_id = le32_to_cpu(hdr->id);
board_ie_len = le32_to_cpu(hdr->len);
board_ie_data = hdr->data;
buf_len -= sizeof(*hdr);
buf += sizeof(*hdr);
if (buf_len < ALIGN(board_ie_len, 4)) {
ath10k_err(ar, "invalid ATH10K_BD_IE_BOARD length: %zu < %zu\n",
buf_len, ALIGN(board_ie_len, 4));
ret = -EINVAL;
goto out;
}
switch (board_ie_id) {
case ATH10K_BD_IE_BOARD_NAME:
ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "board name", "",
board_ie_data, board_ie_len);
if (board_ie_len != strlen(boardname))
break;
ret = memcmp(board_ie_data, boardname, strlen(boardname));
if (ret)
break;
name_match_found = true;
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot found match for name '%s'",
boardname);
break;
case ATH10K_BD_IE_BOARD_DATA:
if (!name_match_found)
/* no match found */
break;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
if (bd_ie_type == ATH10K_BD_IE_BOARD) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot found board data for '%s'",
boardname);
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ar->normal_mode_fw.board_data = board_ie_data;
ar->normal_mode_fw.board_len = board_ie_len;
} else if (bd_ie_type == ATH10K_BD_IE_BOARD_EXT) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot found eboard data for '%s'",
boardname);
ar->normal_mode_fw.ext_board_data = board_ie_data;
ar->normal_mode_fw.ext_board_len = board_ie_len;
}
ret = 0;
goto out;
default:
ath10k_warn(ar, "unknown ATH10K_BD_IE_BOARD found: %d\n",
board_ie_id);
break;
}
/* jump over the padding */
board_ie_len = ALIGN(board_ie_len, 4);
buf_len -= board_ie_len;
buf += board_ie_len;
}
/* no match found */
ret = -ENOENT;
out:
return ret;
}
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
static int ath10k_core_search_bd(struct ath10k *ar,
const char *boardname,
const u8 *data,
size_t len)
{
size_t ie_len;
struct ath10k_fw_ie *hdr;
int ret = -ENOENT, ie_id;
while (len > sizeof(struct ath10k_fw_ie)) {
hdr = (struct ath10k_fw_ie *)data;
ie_id = le32_to_cpu(hdr->id);
ie_len = le32_to_cpu(hdr->len);
len -= sizeof(*hdr);
data = hdr->data;
if (len < ALIGN(ie_len, 4)) {
ath10k_err(ar, "invalid length for board ie_id %d ie_len %zu len %zu\n",
ie_id, ie_len, len);
return -EINVAL;
}
switch (ie_id) {
case ATH10K_BD_IE_BOARD:
ret = ath10k_core_parse_bd_ie_board(ar, data, ie_len,
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
boardname,
ATH10K_BD_IE_BOARD);
if (ret == -ENOENT)
/* no match found, continue */
break;
/* either found or error, so stop searching */
goto out;
case ATH10K_BD_IE_BOARD_EXT:
ret = ath10k_core_parse_bd_ie_board(ar, data, ie_len,
boardname,
ATH10K_BD_IE_BOARD_EXT);
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
if (ret == -ENOENT)
/* no match found, continue */
break;
/* either found or error, so stop searching */
goto out;
}
/* jump over the padding */
ie_len = ALIGN(ie_len, 4);
len -= ie_len;
data += ie_len;
}
out:
/* return result of parse_bd_ie_board() or -ENOENT */
return ret;
}
static int ath10k_core_fetch_board_data_api_n(struct ath10k *ar,
const char *boardname,
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
const char *fallback_boardname,
const char *filename)
{
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
size_t len, magic_len;
const u8 *data;
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
int ret;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
/* Skip if already fetched during board data download */
if (!ar->normal_mode_fw.board)
ar->normal_mode_fw.board = ath10k_fetch_fw_file(ar,
ar->hw_params.fw.dir,
filename);
if (IS_ERR(ar->normal_mode_fw.board))
return PTR_ERR(ar->normal_mode_fw.board);
data = ar->normal_mode_fw.board->data;
len = ar->normal_mode_fw.board->size;
/* magic has extra null byte padded */
magic_len = strlen(ATH10K_BOARD_MAGIC) + 1;
if (len < magic_len) {
ath10k_err(ar, "failed to find magic value in %s/%s, file too short: %zu\n",
ar->hw_params.fw.dir, filename, len);
ret = -EINVAL;
goto err;
}
if (memcmp(data, ATH10K_BOARD_MAGIC, magic_len)) {
ath10k_err(ar, "found invalid board magic\n");
ret = -EINVAL;
goto err;
}
/* magic is padded to 4 bytes */
magic_len = ALIGN(magic_len, 4);
if (len < magic_len) {
ath10k_err(ar, "failed: %s/%s too small to contain board data, len: %zu\n",
ar->hw_params.fw.dir, filename, len);
ret = -EINVAL;
goto err;
}
data += magic_len;
len -= magic_len;
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
/* attempt to find boardname in the IE list */
ret = ath10k_core_search_bd(ar, boardname, data, len);
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
/* if we didn't find it and have a fallback name, try that */
if (ret == -ENOENT && fallback_boardname)
ret = ath10k_core_search_bd(ar, fallback_boardname, data, len);
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
if (ret == -ENOENT) {
ath10k_err(ar,
"failed to fetch board data for %s from %s/%s\n",
boardname, ar->hw_params.fw.dir, filename);
ret = -ENODATA;
}
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
if (ret)
goto err;
return 0;
err:
ath10k_core_free_board_files(ar);
return ret;
}
static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
size_t name_len, bool with_variant)
{
ath10k: search SMBIOS for OEM board file extension Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" If board data file name extension is set but board-2.bin does not contain board data file for the variant, the driver will fallback to the default board data file not to break backward compatibility. This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") but later reverted in commit 005c3490e9db ("Revert "ath10k: Search SMBIOS for OEM board file extension"". This patch is now otherwise the same as commit f2593cb1b291 except the regression fixed. Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-02-24 15:30:03 -07:00
/* strlen(',variant=') + strlen(ar->id.bdf_ext) */
char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 };
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
if (with_variant && ar->id.bdf_ext[0] != '\0')
scnprintf(variant, sizeof(variant), ",variant=%s",
ar->id.bdf_ext);
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
"bus=%s,bmi-chip-id=%d,bmi-board-id=%d%s",
ath10k_bus_str(ar->hif.bus),
ar->id.bmi_chip_id,
ar->id.bmi_board_id, variant);
goto out;
}
if (ar->id.qmi_ids_valid) {
scnprintf(name, name_len,
"bus=%s,qmi-board-id=%x",
ath10k_bus_str(ar->hif.bus),
ar->id.qmi_board_id);
goto out;
}
scnprintf(name, name_len,
ath10k: search SMBIOS for OEM board file extension Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" If board data file name extension is set but board-2.bin does not contain board data file for the variant, the driver will fallback to the default board data file not to break backward compatibility. This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") but later reverted in commit 005c3490e9db ("Revert "ath10k: Search SMBIOS for OEM board file extension"". This patch is now otherwise the same as commit f2593cb1b291 except the regression fixed. Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-02-24 15:30:03 -07:00
"bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s",
ath10k_bus_str(ar->hif.bus),
ar->id.vendor, ar->id.device,
ath10k: search SMBIOS for OEM board file extension Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" If board data file name extension is set but board-2.bin does not contain board data file for the variant, the driver will fallback to the default board data file not to break backward compatibility. This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") but later reverted in commit 005c3490e9db ("Revert "ath10k: Search SMBIOS for OEM board file extension"". This patch is now otherwise the same as commit f2593cb1b291 except the regression fixed. Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-02-24 15:30:03 -07:00
ar->id.subsystem_vendor, ar->id.subsystem_device, variant);
out:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using board name '%s'\n", name);
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
return 0;
}
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
static int ath10k_core_create_eboard_name(struct ath10k *ar, char *name,
size_t name_len)
{
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
"bus=%s,bmi-chip-id=%d,bmi-eboard-id=%d",
ath10k_bus_str(ar->hif.bus),
ar->id.bmi_chip_id,
ar->id.bmi_eboard_id);
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using eboard name '%s'\n", name);
return 0;
}
/* Fallback if returned board id is zero */
return -1;
}
int ath10k_core_fetch_board_file(struct ath10k *ar, int bd_ie_type)
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
{
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
char boardname[100], fallback_boardname[100];
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
int ret;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
if (bd_ie_type == ATH10K_BD_IE_BOARD) {
ret = ath10k_core_create_board_name(ar, boardname,
sizeof(boardname), true);
if (ret) {
ath10k_err(ar, "failed to create board name: %d", ret);
return ret;
}
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ret = ath10k_core_create_board_name(ar, fallback_boardname,
sizeof(boardname), false);
if (ret) {
ath10k_err(ar, "failed to create fallback board name: %d", ret);
return ret;
}
} else if (bd_ie_type == ATH10K_BD_IE_BOARD_EXT) {
ret = ath10k_core_create_eboard_name(ar, boardname,
sizeof(boardname));
if (ret) {
ath10k_err(ar, "fallback to eboard.bin since board id 0");
goto fallback;
}
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
}
ar->bd_api = 2;
ret = ath10k_core_fetch_board_data_api_n(ar, boardname,
ath10k: search all IEs for variant before falling back commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") added a feature to ath10k that allows Board Data File (BDF) conflicts between multiple devices that use the same device IDs but have different calibration requirements to be resolved by allowing a "variant" string to be stored in SMBIOS [and later device tree, added by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration- variant")] that gets appended to the ID stored in board-2.bin. This original patch had a regression, however. Namely that devices with a variant present in SMBIOS that didn't need custom BDFs could no longer find the default BDF, which has no variant appended. The patch was reverted and re-applied with a fix for this issue in commit 1657b8f84ed9 ("search SMBIOS for OEM board file extension"). But the fix to fall back to a default BDF introduced another issue: the driver currently parses IEs in board-2.bin one by one, and for each one it first checks to see if it matches the ID with the variant appended. If it doesn't, it checks to see if it matches the "fallback" ID with no variant. If a matching BDF is found at any point during this search, the search is terminated and that BDF is used. The issue is that it's very possible (and is currently the case for board-2.bin files present in the ath10k-firmware repository) for the default BDF to occur in an earlier IE than the variant-specific BDF. In this case, the current code will happily choose the default BDF even though a better-matching BDF is present later in the file. This patch fixes the issue by first searching the entire file for the ID with variant, and searching for the fallback ID only if that search fails. It also includes some code cleanup in the area, as ath10k_core_fetch_board_data_api_n() no longer does its own string mangling to remove the variant from an ID, instead leaving that job to a new flag passed to ath10k_core_create_board_name(). I've tested this patch on a QCA4019 and verified that the driver behaves correctly for 1) both fallback and variant BDFs present, 2) only fallback BDF present, and 3) no matching BDFs present. Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-13 08:40:26 -06:00
fallback_boardname,
ATH10K_BOARD_API2_FILE);
if (!ret)
goto success;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
fallback:
ar->bd_api = 1;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ret = ath10k_core_fetch_board_data_api_1(ar, bd_ie_type);
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
if (ret) {
ath10k_err(ar, "failed to fetch board-2.bin or board.bin from %s\n",
ar->hw_params.fw.dir);
ath10k: allow loading device specific board files Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-04-17 03:19:17 -06:00
return ret;
}
success:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "using board api %d\n", ar->bd_api);
return 0;
}
EXPORT_SYMBOL(ath10k_core_fetch_board_file);
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
static int ath10k_core_get_ext_board_id_from_otp(struct ath10k *ar)
{
u32 result, address;
u8 ext_board_id;
int ret;
address = ar->hw_params.patch_load_addr;
if (!ar->normal_mode_fw.fw_file.otp_data ||
!ar->normal_mode_fw.fw_file.otp_len) {
ath10k_warn(ar,
"failed to retrieve extended board id due to otp binary missing\n");
return -ENODATA;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot upload otp to 0x%x len %zd for ext board id\n",
address, ar->normal_mode_fw.fw_file.otp_len);
ret = ath10k_bmi_fast_download(ar, address,
ar->normal_mode_fw.fw_file.otp_data,
ar->normal_mode_fw.fw_file.otp_len);
if (ret) {
ath10k_err(ar, "could not write otp for ext board id check: %d\n",
ret);
return ret;
}
ret = ath10k_bmi_execute(ar, address, BMI_PARAM_GET_EXT_BOARD_ID, &result);
if (ret) {
ath10k_err(ar, "could not execute otp for ext board id check: %d\n",
ret);
return ret;
}
if (!result) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"ext board id does not exist in otp, ignore it\n");
return -EOPNOTSUPP;
}
ext_board_id = result & ATH10K_BMI_EBOARD_ID_STATUS_MASK;
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot get otp ext board id result 0x%08x ext_board_id %d\n",
result, ext_board_id);
ar->id.bmi_eboard_id = ext_board_id;
return 0;
}
static int ath10k_download_board_data(struct ath10k *ar, const void *data,
size_t data_len)
{
u32 board_data_size = ar->hw_params.fw.board_size;
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
u32 eboard_data_size = ar->hw_params.fw.ext_board_size;
u32 board_address;
u32 ext_board_address;
int ret;
ret = ath10k_push_board_ext_data(ar, data, data_len);
if (ret) {
ath10k_err(ar, "could not push board ext data (%d)\n", ret);
goto exit;
}
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ret = ath10k_bmi_read32(ar, hi_board_data, &board_address);
if (ret) {
ath10k_err(ar, "could not read board data addr (%d)\n", ret);
goto exit;
}
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ret = ath10k_bmi_write_memory(ar, board_address, data,
min_t(u32, board_data_size,
data_len));
if (ret) {
ath10k_err(ar, "could not write board data (%d)\n", ret);
goto exit;
}
ret = ath10k_bmi_write32(ar, hi_board_data_initialized, 1);
if (ret) {
ath10k_err(ar, "could not write board data bit (%d)\n", ret);
goto exit;
}
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
if (!ar->id.ext_bid_supported)
goto exit;
/* Extended board data download */
ret = ath10k_core_get_ext_board_id_from_otp(ar);
if (ret == -EOPNOTSUPP) {
/* Not fetching ext_board_data if ext board id is 0 */
ath10k_dbg(ar, ATH10K_DBG_BOOT, "otp returned ext board id 0\n");
return 0;
} else if (ret) {
ath10k_err(ar, "failed to get extended board id: %d\n", ret);
goto exit;
}
ret = ath10k_core_fetch_board_file(ar, ATH10K_BD_IE_BOARD_EXT);
if (ret)
goto exit;
if (ar->normal_mode_fw.ext_board_data) {
ext_board_address = board_address + EXT_BOARD_ADDRESS_OFFSET;
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot writing ext board data to addr 0x%x",
ext_board_address);
ret = ath10k_bmi_write_memory(ar, ext_board_address,
ar->normal_mode_fw.ext_board_data,
min_t(u32, eboard_data_size, data_len));
if (ret)
ath10k_err(ar, "failed to write ext board data: %d\n", ret);
}
exit:
return ret;
}
static int ath10k_download_and_run_otp(struct ath10k *ar)
{
u32 result, address = ar->hw_params.patch_load_addr;
u32 bmi_otp_exe_param = ar->hw_params.otp_exe_param;
int ret;
ret = ath10k_download_board_data(ar,
ar->running_fw->board_data,
ar->running_fw->board_len);
if (ret) {
ath10k_err(ar, "failed to download board data: %d\n", ret);
return ret;
}
/* OTP is optional */
if (!ar->running_fw->fw_file.otp_data ||
!ar->running_fw->fw_file.otp_len) {
ath10k_warn(ar, "Not running otp, calibration will be incorrect (otp-data %pK otp_len %zd)!\n",
ar->running_fw->fw_file.otp_data,
ar->running_fw->fw_file.otp_len);
return 0;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot upload otp to 0x%x len %zd\n",
address, ar->running_fw->fw_file.otp_len);
ret = ath10k_bmi_fast_download(ar, address,
ar->running_fw->fw_file.otp_data,
ar->running_fw->fw_file.otp_len);
if (ret) {
ath10k_err(ar, "could not write otp (%d)\n", ret);
return ret;
}
/* As of now pre-cal is valid for 10_4 variants */
if (ar->cal_mode == ATH10K_PRE_CAL_MODE_DT ||
ar->cal_mode == ATH10K_PRE_CAL_MODE_FILE)
bmi_otp_exe_param = BMI_PARAM_FLASH_SECTION_ALL;
ret = ath10k_bmi_execute(ar, address, bmi_otp_exe_param, &result);
if (ret) {
ath10k_err(ar, "could not execute otp (%d)\n", ret);
return ret;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot otp execute result %d\n", result);
if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
ar->running_fw->fw_file.fw_features)) &&
result != 0) {
ath10k_err(ar, "otp calibration failed: %d", result);
return -EINVAL;
}
return 0;
}
static int ath10k_download_cal_file(struct ath10k *ar,
const struct firmware *file)
{
int ret;
if (!file)
return -ENOENT;
if (IS_ERR(file))
return PTR_ERR(file);
ret = ath10k_download_board_data(ar, file->data, file->size);
if (ret) {
ath10k_err(ar, "failed to download cal_file data: %d\n", ret);
return ret;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot cal file downloaded\n");
return 0;
}
static int ath10k_download_cal_dt(struct ath10k *ar, const char *dt_name)
{
struct device_node *node;
int data_len;
void *data;
int ret;
node = ar->dev->of_node;
if (!node)
/* Device Tree is optional, don't print any warnings if
* there's no node for ath10k.
*/
return -ENOENT;
if (!of_get_property(node, dt_name, &data_len)) {
/* The calibration data node is optional */
return -ENOENT;
}
if (data_len != ar->hw_params.cal_data_len) {
ath10k_warn(ar, "invalid calibration data length in DT: %d\n",
data_len);
ret = -EMSGSIZE;
goto out;
}
data = kmalloc(data_len, GFP_KERNEL);
if (!data) {
ret = -ENOMEM;
goto out;
}
ret = of_property_read_u8_array(node, dt_name, data, data_len);
if (ret) {
ath10k_warn(ar, "failed to read calibration data from DT: %d\n",
ret);
goto out_free;
}
ret = ath10k_download_board_data(ar, data, data_len);
if (ret) {
ath10k_warn(ar, "failed to download calibration data from Device Tree: %d\n",
ret);
goto out_free;
}
ret = 0;
out_free:
kfree(data);
out:
return ret;
}
static int ath10k_download_cal_eeprom(struct ath10k *ar)
{
size_t data_len;
void *data = NULL;
int ret;
ret = ath10k_hif_fetch_cal_eeprom(ar, &data, &data_len);
if (ret) {
if (ret != -EOPNOTSUPP)
ath10k_warn(ar, "failed to read calibration data from EEPROM: %d\n",
ret);
goto out_free;
}
ret = ath10k_download_board_data(ar, data, data_len);
if (ret) {
ath10k_warn(ar, "failed to download calibration data from EEPROM: %d\n",
ret);
goto out_free;
}
ret = 0;
out_free:
kfree(data);
return ret;
}
int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
struct ath10k_fw_file *fw_file)
{
size_t magic_len, len, ie_len;
int ie_id, i, index, bit, ret;
struct ath10k_fw_ie *hdr;
const u8 *data;
__le32 *timestamp, *version;
/* first fetch the firmware file (firmware-*.bin) */
fw_file->firmware = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir,
name);
if (IS_ERR(fw_file->firmware))
return PTR_ERR(fw_file->firmware);
data = fw_file->firmware->data;
len = fw_file->firmware->size;
/* magic also includes the null byte, check that as well */
magic_len = strlen(ATH10K_FIRMWARE_MAGIC) + 1;
if (len < magic_len) {
ath10k_err(ar, "firmware file '%s/%s' too small to contain magic: %zu\n",
ar->hw_params.fw.dir, name, len);
ret = -EINVAL;
goto err;
}
if (memcmp(data, ATH10K_FIRMWARE_MAGIC, magic_len) != 0) {
ath10k_err(ar, "invalid firmware magic\n");
ret = -EINVAL;
goto err;
}
/* jump over the padding */
magic_len = ALIGN(magic_len, 4);
len -= magic_len;
data += magic_len;
/* loop elements */
while (len > sizeof(struct ath10k_fw_ie)) {
hdr = (struct ath10k_fw_ie *)data;
ie_id = le32_to_cpu(hdr->id);
ie_len = le32_to_cpu(hdr->len);
len -= sizeof(*hdr);
data += sizeof(*hdr);
if (len < ie_len) {
ath10k_err(ar, "invalid length for FW IE %d (%zu < %zu)\n",
ie_id, len, ie_len);
ret = -EINVAL;
goto err;
}
switch (ie_id) {
case ATH10K_FW_IE_FW_VERSION:
if (ie_len > sizeof(fw_file->fw_version) - 1)
break;
memcpy(fw_file->fw_version, data, ie_len);
fw_file->fw_version[ie_len] = '\0';
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"found fw version %s\n",
fw_file->fw_version);
break;
case ATH10K_FW_IE_TIMESTAMP:
if (ie_len != sizeof(u32))
break;
timestamp = (__le32 *)data;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "found fw timestamp %d\n",
le32_to_cpup(timestamp));
break;
case ATH10K_FW_IE_FEATURES:
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"found firmware features ie (%zd B)\n",
ie_len);
for (i = 0; i < ATH10K_FW_FEATURE_COUNT; i++) {
index = i / 8;
bit = i % 8;
if (index == ie_len)
break;
if (data[index] & (1 << bit)) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"Enabling feature bit: %i\n",
i);
__set_bit(i, fw_file->fw_features);
}
}
ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "features", "",
fw_file->fw_features,
sizeof(fw_file->fw_features));
break;
case ATH10K_FW_IE_FW_IMAGE:
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"found fw image ie (%zd B)\n",
ie_len);
fw_file->firmware_data = data;
fw_file->firmware_len = ie_len;
break;
case ATH10K_FW_IE_OTP_IMAGE:
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"found otp image ie (%zd B)\n",
ie_len);
fw_file->otp_data = data;
fw_file->otp_len = ie_len;
break;
case ATH10K_FW_IE_WMI_OP_VERSION:
if (ie_len != sizeof(u32))
break;
version = (__le32 *)data;
fw_file->wmi_op_version = le32_to_cpup(version);
ath10k_dbg(ar, ATH10K_DBG_BOOT, "found fw ie wmi op version %d\n",
fw_file->wmi_op_version);
break;
case ATH10K_FW_IE_HTT_OP_VERSION:
if (ie_len != sizeof(u32))
break;
version = (__le32 *)data;
fw_file->htt_op_version = le32_to_cpup(version);
ath10k_dbg(ar, ATH10K_DBG_BOOT, "found fw ie htt op version %d\n",
fw_file->htt_op_version);
break;
case ATH10K_FW_IE_FW_CODE_SWAP_IMAGE:
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"found fw code swap image ie (%zd B)\n",
ie_len);
fw_file->codeswap_data = data;
fw_file->codeswap_len = ie_len;
break;
default:
ath10k_warn(ar, "Unknown FW IE: %u\n",
le32_to_cpu(hdr->id));
break;
}
/* jump over the padding */
ie_len = ALIGN(ie_len, 4);
len -= ie_len;
data += ie_len;
}
if (!test_bit(ATH10K_FW_FEATURE_NON_BMI, fw_file->fw_features) &&
(!fw_file->firmware_data || !fw_file->firmware_len)) {
ath10k_warn(ar, "No ATH10K_FW_IE_FW_IMAGE found from '%s/%s', skipping\n",
ar->hw_params.fw.dir, name);
ret = -ENOMEDIUM;
goto err;
}
return 0;
err:
ath10k_core_free_firmware_files(ar);
return ret;
}
static void ath10k_core_get_fw_name(struct ath10k *ar, char *fw_name,
size_t fw_name_len, int fw_api)
{
switch (ar->hif.bus) {
case ATH10K_BUS_SDIO:
case ATH10K_BUS_USB:
scnprintf(fw_name, fw_name_len, "%s-%s-%d.bin",
ATH10K_FW_FILE_BASE, ath10k_bus_str(ar->hif.bus),
fw_api);
break;
case ATH10K_BUS_PCI:
case ATH10K_BUS_AHB:
case ATH10K_BUS_SNOC:
scnprintf(fw_name, fw_name_len, "%s-%d.bin",
ATH10K_FW_FILE_BASE, fw_api);
break;
}
}
static int ath10k_core_fetch_firmware_files(struct ath10k *ar)
{
int ret, i;
char fw_name[100];
/* calibration file is optional, don't check for any errors */
ath10k_fetch_cal_file(ar);
for (i = ATH10K_FW_API_MAX; i >= ATH10K_FW_API_MIN; i--) {
ar->fw_api = i;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "trying fw api %d\n",
ar->fw_api);
ath10k_core_get_fw_name(ar, fw_name, sizeof(fw_name), ar->fw_api);
ret = ath10k_core_fetch_firmware_api_n(ar, fw_name,
&ar->normal_mode_fw.fw_file);
if (!ret)
goto success;
}
/* we end up here if we couldn't fetch any firmware */
ath10k_err(ar, "Failed to find firmware-N.bin (N between %d and %d) from %s: %d",
ATH10K_FW_API_MIN, ATH10K_FW_API_MAX, ar->hw_params.fw.dir,
ret);
return ret;
success:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "using fw api %d\n", ar->fw_api);
return 0;
}
ath10k: incorporate qca4019 cal data download sequence qca4019 calibration data is stored in the host memory and it's mandatory to download it even before reading board id and chip id from the target. Also, there is a need to execute otp (download and run) twice, one after cal data download and another one after board data download. Existing cal data file name 'cal-<bus>-<id>.bin' and device tree entry 'qcom,ath10k-calibration-data' used in ath10k has assumption that it carries other data (like board data) also along with the calibration data. But, qca4019 cal data contains pure calibration data (doesn't include any other info). So, using existing same cal file name and DT entry in qca4019 case would alter the purpose of it. To avoid this, new cal file name 'pre-cal-<bus>-<id>.bin' and new device tree entry name 'qcom,ath10k-pre-calibration-data are introduced. Overall qca4019's firmware download sequence would look like, 1) Download cal data (either from a file or device tree entry) at the address specified by target in the host interest area member "hi_board_data". 2) Download otp and run with 0x10 (PARAM_GET_EEPROM_BOARD_ID) as a argument. At this point, otp will take back up of downloaded cal data content in another location in the target and return valid board id and chip id to the host. 3) Download board data at the address specified by target in host interest area member "hi_board_data". 4) Download otp and run with 0x10000 (PARAM_FLASH_SECTION_ALL) as a argument. Now otp will apply cal data content from it's backup on top of board data download in step 3 and prepare final data base. 5) Download code swap and athwlan binary content. Above sequences are implemented (step 1 to step 4) in the name of pre calibration configuration. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-18 03:44:22 -06:00
static int ath10k_core_pre_cal_download(struct ath10k *ar)
{
int ret;
ret = ath10k_download_cal_file(ar, ar->pre_cal_file);
if (ret == 0) {
ar->cal_mode = ATH10K_PRE_CAL_MODE_FILE;
goto success;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot did not find a pre calibration file, try DT next: %d\n",
ret);
ret = ath10k_download_cal_dt(ar, "qcom,ath10k-pre-calibration-data");
if (ret) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"unable to load pre cal data from DT: %d\n", ret);
return ret;
}
ar->cal_mode = ATH10K_PRE_CAL_MODE_DT;
success:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using calibration mode %s\n",
ath10k_cal_mode_str(ar->cal_mode));
return 0;
}
static int ath10k_core_pre_cal_config(struct ath10k *ar)
{
int ret;
ret = ath10k_core_pre_cal_download(ar);
if (ret) {
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"failed to load pre cal data: %d\n", ret);
return ret;
}
ret = ath10k_core_get_board_id_from_otp(ar);
if (ret) {
ath10k_err(ar, "failed to get board id: %d\n", ret);
return ret;
}
ret = ath10k_download_and_run_otp(ar);
if (ret) {
ath10k_err(ar, "failed to run otp: %d\n", ret);
return ret;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"pre cal configuration done successfully\n");
return 0;
}
static int ath10k_download_cal_data(struct ath10k *ar)
{
int ret;
ath10k: incorporate qca4019 cal data download sequence qca4019 calibration data is stored in the host memory and it's mandatory to download it even before reading board id and chip id from the target. Also, there is a need to execute otp (download and run) twice, one after cal data download and another one after board data download. Existing cal data file name 'cal-<bus>-<id>.bin' and device tree entry 'qcom,ath10k-calibration-data' used in ath10k has assumption that it carries other data (like board data) also along with the calibration data. But, qca4019 cal data contains pure calibration data (doesn't include any other info). So, using existing same cal file name and DT entry in qca4019 case would alter the purpose of it. To avoid this, new cal file name 'pre-cal-<bus>-<id>.bin' and new device tree entry name 'qcom,ath10k-pre-calibration-data are introduced. Overall qca4019's firmware download sequence would look like, 1) Download cal data (either from a file or device tree entry) at the address specified by target in the host interest area member "hi_board_data". 2) Download otp and run with 0x10 (PARAM_GET_EEPROM_BOARD_ID) as a argument. At this point, otp will take back up of downloaded cal data content in another location in the target and return valid board id and chip id to the host. 3) Download board data at the address specified by target in host interest area member "hi_board_data". 4) Download otp and run with 0x10000 (PARAM_FLASH_SECTION_ALL) as a argument. Now otp will apply cal data content from it's backup on top of board data download in step 3 and prepare final data base. 5) Download code swap and athwlan binary content. Above sequences are implemented (step 1 to step 4) in the name of pre calibration configuration. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-18 03:44:22 -06:00
ret = ath10k_core_pre_cal_config(ar);
if (ret == 0)
return 0;
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"pre cal download procedure failed, try cal file: %d\n",
ret);
ret = ath10k_download_cal_file(ar, ar->cal_file);
if (ret == 0) {
ar->cal_mode = ATH10K_CAL_MODE_FILE;
goto done;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot did not find a calibration file, try DT next: %d\n",
ret);
ret = ath10k_download_cal_dt(ar, "qcom,ath10k-calibration-data");
if (ret == 0) {
ar->cal_mode = ATH10K_CAL_MODE_DT;
goto done;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot did not find DT entry, try target EEPROM next: %d\n",
ret);
ret = ath10k_download_cal_eeprom(ar);
if (ret == 0) {
ar->cal_mode = ATH10K_CAL_MODE_EEPROM;
goto done;
}
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"boot did not find target EEPROM entry, try OTP next: %d\n",
ret);
ret = ath10k_download_and_run_otp(ar);
if (ret) {
ath10k_err(ar, "failed to run otp: %d\n", ret);
return ret;
}
ar->cal_mode = ATH10K_CAL_MODE_OTP;
done:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using calibration mode %s\n",
ath10k_cal_mode_str(ar->cal_mode));
return 0;
}
static int ath10k_init_uart(struct ath10k *ar)
{
int ret;
/*
* Explicitly setting UART prints to zero as target turns it on
* based on scratch registers.
*/
ret = ath10k_bmi_write32(ar, hi_serial_enable, 0);
if (ret) {
ath10k_warn(ar, "could not disable UART prints (%d)\n", ret);
return ret;
}
if (!uart_print) {
if (ar->hw_params.uart_pin_workaround) {
ret = ath10k_bmi_write32(ar, hi_dbg_uart_txpin,
ar->hw_params.uart_pin);
if (ret) {
ath10k_warn(ar, "failed to set UART TX pin: %d",
ret);
return ret;
}
}
return 0;
}
ret = ath10k_bmi_write32(ar, hi_dbg_uart_txpin, ar->hw_params.uart_pin);
if (ret) {
ath10k_warn(ar, "could not enable UART prints (%d)\n", ret);
return ret;
}
ret = ath10k_bmi_write32(ar, hi_serial_enable, 1);
if (ret) {
ath10k_warn(ar, "could not enable UART prints (%d)\n", ret);
return ret;
}
/* Set the UART baud rate to 19200. */
ret = ath10k_bmi_write32(ar, hi_desired_baud_rate, 19200);
if (ret) {
ath10k_warn(ar, "could not set the baud rate (%d)\n", ret);
return ret;
}
ath10k_info(ar, "UART prints enabled\n");
return 0;
}
static int ath10k_init_hw_params(struct ath10k *ar)
{
const struct ath10k_hw_params *uninitialized_var(hw_params);
int i;
for (i = 0; i < ARRAY_SIZE(ath10k_hw_params_list); i++) {
hw_params = &ath10k_hw_params_list[i];
if (hw_params->bus == ar->hif.bus &&
hw_params->id == ar->target_version &&
hw_params->dev_id == ar->dev_id)
break;
}
if (i == ARRAY_SIZE(ath10k_hw_params_list)) {
ath10k_err(ar, "Unsupported hardware version: 0x%x\n",
ar->target_version);
return -EINVAL;
}
ar->hw_params = *hw_params;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "Hardware name %s version 0x%x\n",
ar->hw_params.name, ar->target_version);
return 0;
}
static void ath10k_core_restart(struct work_struct *work)
{
struct ath10k *ar = container_of(work, struct ath10k, restart_work);
int ret;
set_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
/* Place a barrier to make sure the compiler doesn't reorder
* CRASH_FLUSH and calling other functions.
*/
barrier();
ieee80211_stop_queues(ar->hw);
ath10k_drain_tx(ar);
ath10k: use complete() instead complete_all() There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker context scan.started ------------ ath10k_start_scan() lockdep_assert_held(conf_mutex) auth10k_wmi_start_scan() wait_for_completion_timeout(scan.started) ath10k_wmi_event_scan_start_failed() complete(scan.started) ath10k_wmi_event_scan_started() complete(scan.started) scan.completed -------------- ath10k_scan_stop() lockdep_assert_held(conf_mutex) ath10k_wmi_stop_scan() wait_for_completion_timeout(scan.completed) __ath10k_scan_finish() complete(scan.completed) scan.on_channel --------------- ath10k_remain_on_channel() mutex_lock(conf_mutex) ath10k_start_scan() wait_for_completion_timeout(scan.on_channel) ath10k_wmi_event_scan_foreign_chan() complete(scan.on_channel) offchan_tx_completed -------------------- ath10k_offchan_tx_work() mutex_lock(conf_mutex) reinit_completion(offchan_tx_completed) wait_for_completion_timeout(offchan_tx_completed) ath10k_report_offchain_tx() complete(offchan_tx_completed) install_key_done ---------------- ath10k_install_key() lockep_assert_held(conf_mutex) reinit_completion(install_key_done) wait_for_completion_timeout(install_key_done) ath10k_htt_t2h_msg_handler() complete(install_key_done) vdev_setup_done --------------- ath10k_monitor_vdev_start() lockdep_assert_held(conf_mutex) reinit_completion(vdev_setup_done) ath10k_vdev_setup_sync() wait_for_completion_timeout(vdev_setup_done) ath10k_wmi_event_vdev_start_resp() complete(vdev_setup_done) ath10k_monitor_vdev_stop() lockdep_assert_held(conf_mutex) reinit_completion(vdev_setup_done() ath10k_vdev_setup_sync() wait_for_completion_timeout(vdev_setup_done) ath10k_wmi_event_vdev_stopped() complete(vdev_setup_done) thermal.wmi_sync ---------------- ath10k_thermal_show_temp() mutex_lock(conf_mutex) reinit_completion(thermal.wmi_sync) wait_for_completion_timeout(thermal.wmi_sync) ath10k_thermal_event_temperature() complete(thermal.wmi_sync) bss_survey_done --------------- ath10k_mac_update_bss_chan_survey lockdep_assert_held(conf_mutex) reinit_completion(bss_survey_done) wait_for_completion_timeout(bss_survey_done) ath10k_wmi_event_pdev_bss_chan_info() complete(bss_survey_done) All complete() calls happen while the conf_mutex is taken. That means at max one waiter is possible. Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-08-18 07:12:06 -06:00
complete(&ar->scan.started);
complete(&ar->scan.completed);
complete(&ar->scan.on_channel);
complete(&ar->offchan_tx_completed);
complete(&ar->install_key_done);
complete(&ar->vdev_setup_done);
complete(&ar->vdev_delete_done);
ath10k: use complete() instead complete_all() There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker context scan.started ------------ ath10k_start_scan() lockdep_assert_held(conf_mutex) auth10k_wmi_start_scan() wait_for_completion_timeout(scan.started) ath10k_wmi_event_scan_start_failed() complete(scan.started) ath10k_wmi_event_scan_started() complete(scan.started) scan.completed -------------- ath10k_scan_stop() lockdep_assert_held(conf_mutex) ath10k_wmi_stop_scan() wait_for_completion_timeout(scan.completed) __ath10k_scan_finish() complete(scan.completed) scan.on_channel --------------- ath10k_remain_on_channel() mutex_lock(conf_mutex) ath10k_start_scan() wait_for_completion_timeout(scan.on_channel) ath10k_wmi_event_scan_foreign_chan() complete(scan.on_channel) offchan_tx_completed -------------------- ath10k_offchan_tx_work() mutex_lock(conf_mutex) reinit_completion(offchan_tx_completed) wait_for_completion_timeout(offchan_tx_completed) ath10k_report_offchain_tx() complete(offchan_tx_completed) install_key_done ---------------- ath10k_install_key() lockep_assert_held(conf_mutex) reinit_completion(install_key_done) wait_for_completion_timeout(install_key_done) ath10k_htt_t2h_msg_handler() complete(install_key_done) vdev_setup_done --------------- ath10k_monitor_vdev_start() lockdep_assert_held(conf_mutex) reinit_completion(vdev_setup_done) ath10k_vdev_setup_sync() wait_for_completion_timeout(vdev_setup_done) ath10k_wmi_event_vdev_start_resp() complete(vdev_setup_done) ath10k_monitor_vdev_stop() lockdep_assert_held(conf_mutex) reinit_completion(vdev_setup_done() ath10k_vdev_setup_sync() wait_for_completion_timeout(vdev_setup_done) ath10k_wmi_event_vdev_stopped() complete(vdev_setup_done) thermal.wmi_sync ---------------- ath10k_thermal_show_temp() mutex_lock(conf_mutex) reinit_completion(thermal.wmi_sync) wait_for_completion_timeout(thermal.wmi_sync) ath10k_thermal_event_temperature() complete(thermal.wmi_sync) bss_survey_done --------------- ath10k_mac_update_bss_chan_survey lockdep_assert_held(conf_mutex) reinit_completion(bss_survey_done) wait_for_completion_timeout(bss_survey_done) ath10k_wmi_event_pdev_bss_chan_info() complete(bss_survey_done) All complete() calls happen while the conf_mutex is taken. That means at max one waiter is possible. Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-08-18 07:12:06 -06:00
complete(&ar->thermal.wmi_sync);
complete(&ar->bss_survey_done);
wake_up(&ar->htt.empty_tx_wq);
wake_up(&ar->wmi.tx_credits_wq);
wake_up(&ar->peer_mapping_wq);
/* TODO: We can have one instance of cancelling coverage_class_work by
* moving it to ath10k_halt(), so that both stop() and restart() would
* call that but it takes conf_mutex() and if we call cancel_work_sync()
* with conf_mutex it will deadlock.
*/
cancel_work_sync(&ar->set_coverage_class_work);
mutex_lock(&ar->conf_mutex);
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
case ATH10K_STATE_OFF:
/* this can happen if driver is being unloaded
* or if the crash happens during FW probing
*/
ath10k_warn(ar, "cannot restart a device that hasn't been started\n");
break;
case ATH10K_STATE_RESTARTING:
/* hw restart might be requested from multiple places */
break;
case ATH10K_STATE_RESTARTED:
ar->state = ATH10K_STATE_WEDGED;
/* fall through */
case ATH10K_STATE_WEDGED:
ath10k_warn(ar, "device is wedged, will not restart\n");
break;
case ATH10K_STATE_UTF:
ath10k_warn(ar, "firmware restart in UTF mode not supported\n");
break;
}
mutex_unlock(&ar->conf_mutex);
ret = ath10k_coredump_submit(ar);
if (ret)
ath10k_warn(ar, "failed to send firmware crash dump via devcoredump: %d",
ret);
complete(&ar->driver_recovery);
}
ath10k: allow setting coverage class 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: Benjamin Berg <benjamin@sipsolutions.net> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-28 06:11:58 -06:00
static void ath10k_core_set_coverage_class_work(struct work_struct *work)
{
struct ath10k *ar = container_of(work, struct ath10k,
set_coverage_class_work);
if (ar->hw_params.hw_ops->set_coverage_class)
ar->hw_params.hw_ops->set_coverage_class(ar, -1);
}
static int ath10k_core_init_firmware_features(struct ath10k *ar)
{
struct ath10k_fw_file *fw_file = &ar->normal_mode_fw.fw_file;
int max_num_peers;
if (test_bit(ATH10K_FW_FEATURE_WMI_10_2, fw_file->fw_features) &&
!test_bit(ATH10K_FW_FEATURE_WMI_10X, fw_file->fw_features)) {
ath10k_err(ar, "feature bits corrupted: 10.2 feature requires 10.x feature to be set as well");
return -EINVAL;
}
if (fw_file->wmi_op_version >= ATH10K_FW_WMI_OP_VERSION_MAX) {
ath10k_err(ar, "unsupported WMI OP version (max %d): %d\n",
ATH10K_FW_WMI_OP_VERSION_MAX, fw_file->wmi_op_version);
return -EINVAL;
}
ath10k: enable raw encap mode and software crypto engine This patch enables raw Rx/Tx encap mode to support software based crypto engine. This patch introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. Known limitation: A-MSDU must be disabled for RAW Tx encap mode to perform well when heavy traffic is applied. Testing: (by Michal Kazior <michal.kazior@tieto.com>) a) Performance Testing cryptmode=1 ap=qca988x sta=killer1525 killer1525 -> qca988x 194.496 mbps [tcp1 ip4] killer1525 -> qca988x 238.309 mbps [tcp5 ip4] killer1525 -> qca988x 266.958 mbps [udp1 ip4] killer1525 -> qca988x 477.468 mbps [udp5 ip4] qca988x -> killer1525 301.378 mbps [tcp1 ip4] qca988x -> killer1525 297.949 mbps [tcp5 ip4] qca988x -> killer1525 331.351 mbps [udp1 ip4] qca988x -> killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x -> killer1525 331.447 mbps [tcp1 ip4] qca988x -> killer1525 328.783 mbps [tcp5 ip4] qca988x -> killer1525 375.309 mbps [udp1 ip4] qca988x -> killer1525 403.379 mbps [udp5 ip4] killer1525 -> qca988x 203.689 mbps [tcp1 ip4] killer1525 -> qca988x 222.339 mbps [tcp5 ip4] killer1525 -> qca988x 264.199 mbps [udp1 ip4] killer1525 -> qca988x 479.371 mbps [udp5 ip4] Note: - only open network tested for RAW vs nwifi performance comparison - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) - used iperf - OTA, devices a few cm apart from each other, no shielding - tcpX/udpX, X - means number of threads used Overview: - relative Tx performance drop is seen but is within reasonable and expected threshold (A-MSDU must be disabled with RAW Tx) b) Connectivity Testing cryptmode=1 ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK Note: - each test takes all possible endpoint pairs and pings - each pair-ping flushes arp table - ip6 is used c) Testbed Topology: 1ap1sta: [ap] ---- [sta] endpoints: ap, sta 1ap1sta2br: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] endpoints: veth0, veth2, br0, br1 note: STA works in 4addr mode, AP has wds_sta=1 1ap1sta2br1vlan: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] | | [vlan0_id2] [vlan1_id2] endpoints: vlan0_id2, vlan1_id2 note: STA works in 4addr mode, AP has wds_sta=1 Credits: Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the amsdu issue, contributed a workaround (already squashed into this patch), and contributed the throughput and connectivity tests results. Signed-off-by: David Liu <cfliu.tw@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Tested-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-07-24 11:25:32 -06:00
ar->wmi.rx_decap_mode = ATH10K_HW_TXRX_NATIVE_WIFI;
switch (ath10k_cryptmode_param) {
case ATH10K_CRYPT_MODE_HW:
clear_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags);
clear_bit(ATH10K_FLAG_HW_CRYPTO_DISABLED, &ar->dev_flags);
break;
case ATH10K_CRYPT_MODE_SW:
if (!test_bit(ATH10K_FW_FEATURE_RAW_MODE_SUPPORT,
fw_file->fw_features)) {
ath10k: enable raw encap mode and software crypto engine This patch enables raw Rx/Tx encap mode to support software based crypto engine. This patch introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. Known limitation: A-MSDU must be disabled for RAW Tx encap mode to perform well when heavy traffic is applied. Testing: (by Michal Kazior <michal.kazior@tieto.com>) a) Performance Testing cryptmode=1 ap=qca988x sta=killer1525 killer1525 -> qca988x 194.496 mbps [tcp1 ip4] killer1525 -> qca988x 238.309 mbps [tcp5 ip4] killer1525 -> qca988x 266.958 mbps [udp1 ip4] killer1525 -> qca988x 477.468 mbps [udp5 ip4] qca988x -> killer1525 301.378 mbps [tcp1 ip4] qca988x -> killer1525 297.949 mbps [tcp5 ip4] qca988x -> killer1525 331.351 mbps [udp1 ip4] qca988x -> killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x -> killer1525 331.447 mbps [tcp1 ip4] qca988x -> killer1525 328.783 mbps [tcp5 ip4] qca988x -> killer1525 375.309 mbps [udp1 ip4] qca988x -> killer1525 403.379 mbps [udp5 ip4] killer1525 -> qca988x 203.689 mbps [tcp1 ip4] killer1525 -> qca988x 222.339 mbps [tcp5 ip4] killer1525 -> qca988x 264.199 mbps [udp1 ip4] killer1525 -> qca988x 479.371 mbps [udp5 ip4] Note: - only open network tested for RAW vs nwifi performance comparison - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) - used iperf - OTA, devices a few cm apart from each other, no shielding - tcpX/udpX, X - means number of threads used Overview: - relative Tx performance drop is seen but is within reasonable and expected threshold (A-MSDU must be disabled with RAW Tx) b) Connectivity Testing cryptmode=1 ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK Note: - each test takes all possible endpoint pairs and pings - each pair-ping flushes arp table - ip6 is used c) Testbed Topology: 1ap1sta: [ap] ---- [sta] endpoints: ap, sta 1ap1sta2br: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] endpoints: veth0, veth2, br0, br1 note: STA works in 4addr mode, AP has wds_sta=1 1ap1sta2br1vlan: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] | | [vlan0_id2] [vlan1_id2] endpoints: vlan0_id2, vlan1_id2 note: STA works in 4addr mode, AP has wds_sta=1 Credits: Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the amsdu issue, contributed a workaround (already squashed into this patch), and contributed the throughput and connectivity tests results. Signed-off-by: David Liu <cfliu.tw@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Tested-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-07-24 11:25:32 -06:00
ath10k_err(ar, "cryptmode > 0 requires raw mode support from firmware");
return -EINVAL;
}
set_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags);
set_bit(ATH10K_FLAG_HW_CRYPTO_DISABLED, &ar->dev_flags);
break;
default:
ath10k_info(ar, "invalid cryptmode: %d\n",
ath10k_cryptmode_param);
return -EINVAL;
}
ar->htt.max_num_amsdu = ATH10K_HTT_MAX_NUM_AMSDU_DEFAULT;
ar->htt.max_num_ampdu = ATH10K_HTT_MAX_NUM_AMPDU_DEFAULT;
if (rawmode) {
if (!test_bit(ATH10K_FW_FEATURE_RAW_MODE_SUPPORT,
fw_file->fw_features)) {
ath10k_err(ar, "rawmode = 1 requires support from firmware");
return -EINVAL;
}
set_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags);
}
ath10k: enable raw encap mode and software crypto engine This patch enables raw Rx/Tx encap mode to support software based crypto engine. This patch introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. Known limitation: A-MSDU must be disabled for RAW Tx encap mode to perform well when heavy traffic is applied. Testing: (by Michal Kazior <michal.kazior@tieto.com>) a) Performance Testing cryptmode=1 ap=qca988x sta=killer1525 killer1525 -> qca988x 194.496 mbps [tcp1 ip4] killer1525 -> qca988x 238.309 mbps [tcp5 ip4] killer1525 -> qca988x 266.958 mbps [udp1 ip4] killer1525 -> qca988x 477.468 mbps [udp5 ip4] qca988x -> killer1525 301.378 mbps [tcp1 ip4] qca988x -> killer1525 297.949 mbps [tcp5 ip4] qca988x -> killer1525 331.351 mbps [udp1 ip4] qca988x -> killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x -> killer1525 331.447 mbps [tcp1 ip4] qca988x -> killer1525 328.783 mbps [tcp5 ip4] qca988x -> killer1525 375.309 mbps [udp1 ip4] qca988x -> killer1525 403.379 mbps [udp5 ip4] killer1525 -> qca988x 203.689 mbps [tcp1 ip4] killer1525 -> qca988x 222.339 mbps [tcp5 ip4] killer1525 -> qca988x 264.199 mbps [udp1 ip4] killer1525 -> qca988x 479.371 mbps [udp5 ip4] Note: - only open network tested for RAW vs nwifi performance comparison - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) - used iperf - OTA, devices a few cm apart from each other, no shielding - tcpX/udpX, X - means number of threads used Overview: - relative Tx performance drop is seen but is within reasonable and expected threshold (A-MSDU must be disabled with RAW Tx) b) Connectivity Testing cryptmode=1 ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK Note: - each test takes all possible endpoint pairs and pings - each pair-ping flushes arp table - ip6 is used c) Testbed Topology: 1ap1sta: [ap] ---- [sta] endpoints: ap, sta 1ap1sta2br: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] endpoints: veth0, veth2, br0, br1 note: STA works in 4addr mode, AP has wds_sta=1 1ap1sta2br1vlan: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] | | [vlan0_id2] [vlan1_id2] endpoints: vlan0_id2, vlan1_id2 note: STA works in 4addr mode, AP has wds_sta=1 Credits: Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the amsdu issue, contributed a workaround (already squashed into this patch), and contributed the throughput and connectivity tests results. Signed-off-by: David Liu <cfliu.tw@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Tested-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-07-24 11:25:32 -06:00
if (test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) {
ar->wmi.rx_decap_mode = ATH10K_HW_TXRX_RAW;
/* Workaround:
*
* Firmware A-MSDU aggregation breaks with RAW Tx encap mode
* and causes enormous performance issues (malformed frames,
* etc).
*
* Disabling A-MSDU makes RAW mode stable with heavy traffic
* albeit a bit slower compared to regular operation.
*/
ar->htt.max_num_amsdu = 1;
}
/* Backwards compatibility for firmwares without
* ATH10K_FW_IE_WMI_OP_VERSION.
*/
if (fw_file->wmi_op_version == ATH10K_FW_WMI_OP_VERSION_UNSET) {
if (test_bit(ATH10K_FW_FEATURE_WMI_10X, fw_file->fw_features)) {
if (test_bit(ATH10K_FW_FEATURE_WMI_10_2,
fw_file->fw_features))
fw_file->wmi_op_version = ATH10K_FW_WMI_OP_VERSION_10_2;
else
fw_file->wmi_op_version = ATH10K_FW_WMI_OP_VERSION_10_1;
} else {
fw_file->wmi_op_version = ATH10K_FW_WMI_OP_VERSION_MAIN;
}
}
switch (fw_file->wmi_op_version) {
case ATH10K_FW_WMI_OP_VERSION_MAIN:
max_num_peers = TARGET_NUM_PEERS;
ar->max_num_stations = TARGET_NUM_STATIONS;
ar->max_num_vdevs = TARGET_NUM_VDEVS;
ar->htt.max_num_pending_tx = TARGET_NUM_MSDU_DESC;
ar->fw_stats_req_mask = WMI_STAT_PDEV | WMI_STAT_VDEV |
WMI_STAT_PEER;
ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
if (ath10k_peer_stats_enabled(ar)) {
max_num_peers = TARGET_10X_TX_STATS_NUM_PEERS;
ar->max_num_stations = TARGET_10X_TX_STATS_NUM_STATIONS;
} else {
max_num_peers = TARGET_10X_NUM_PEERS;
ar->max_num_stations = TARGET_10X_NUM_STATIONS;
}
ar->max_num_vdevs = TARGET_10X_NUM_VDEVS;
ar->htt.max_num_pending_tx = TARGET_10X_NUM_MSDU_DESC;
ar->fw_stats_req_mask = WMI_STAT_PEER;
ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
break;
case ATH10K_FW_WMI_OP_VERSION_TLV:
max_num_peers = TARGET_TLV_NUM_PEERS;
ar->max_num_stations = TARGET_TLV_NUM_STATIONS;
ar->max_num_vdevs = TARGET_TLV_NUM_VDEVS;
ar->max_num_tdls_vdevs = TARGET_TLV_NUM_TDLS_VDEVS;
if (ar->hif.bus == ATH10K_BUS_SDIO)
ar->htt.max_num_pending_tx =
TARGET_TLV_NUM_MSDU_DESC_HL;
else
ar->htt.max_num_pending_tx = TARGET_TLV_NUM_MSDU_DESC;
ar->wow.max_num_patterns = TARGET_TLV_NUM_WOW_PATTERNS;
ar->fw_stats_req_mask = WMI_TLV_STAT_PDEV | WMI_TLV_STAT_VDEV |
WMI_TLV_STAT_PEER | WMI_TLV_STAT_PEER_EXTD;
ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
ar->wmi.mgmt_max_num_pending_tx = TARGET_TLV_MGMT_NUM_MSDU_DESC;
break;
case ATH10K_FW_WMI_OP_VERSION_10_4:
max_num_peers = TARGET_10_4_NUM_PEERS;
ar->max_num_stations = TARGET_10_4_NUM_STATIONS;
ar->num_active_peers = TARGET_10_4_ACTIVE_PEERS;
ar->max_num_vdevs = TARGET_10_4_NUM_VDEVS;
ar->num_tids = TARGET_10_4_TGT_NUM_TIDS;
ar->fw_stats_req_mask = WMI_10_4_STAT_PEER |
WMI_10_4_STAT_PEER_EXTD |
WMI_10_4_STAT_VDEV_EXTD;
ar->max_spatial_stream = ar->hw_params.max_spatial_stream;
ar->max_num_tdls_vdevs = TARGET_10_4_NUM_TDLS_VDEVS;
if (test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
fw_file->fw_features))
ar->htt.max_num_pending_tx = TARGET_10_4_NUM_MSDU_DESC_PFC;
else
ar->htt.max_num_pending_tx = TARGET_10_4_NUM_MSDU_DESC;
break;
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
default:
WARN_ON(1);
return -EINVAL;
}
if (ar->hw_params.num_peers)
ar->max_num_peers = ar->hw_params.num_peers;
else
ar->max_num_peers = max_num_peers;
/* Backwards compatibility for firmwares without
* ATH10K_FW_IE_HTT_OP_VERSION.
*/
if (fw_file->htt_op_version == ATH10K_FW_HTT_OP_VERSION_UNSET) {
switch (fw_file->wmi_op_version) {
case ATH10K_FW_WMI_OP_VERSION_MAIN:
fw_file->htt_op_version = ATH10K_FW_HTT_OP_VERSION_MAIN;
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
fw_file->htt_op_version = ATH10K_FW_HTT_OP_VERSION_10_1;
break;
case ATH10K_FW_WMI_OP_VERSION_TLV:
fw_file->htt_op_version = ATH10K_FW_HTT_OP_VERSION_TLV;
break;
case ATH10K_FW_WMI_OP_VERSION_10_4:
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
ath10k_err(ar, "htt op version not found from fw meta data");
return -EINVAL;
}
}
return 0;
}
ath10k: fix spurious tx/rx during boot HW Rx filters and masks are not configured properly by firmware during boot sequences. The MAC_PCU_ADDR1 is set to 0s instead of 1s which allows the HW to ACK any frame that passes through MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself is misconfigured on boot as well. The combination of these bugs ended up with the following manifestations: - "no channel configured; ignoring frame(s)!" warnings in the driver - spurious ACKs (transmission) on the air during firmware bootup sequences The former was a long standing and known bug originally though mostly harmless. However Marek recently discovered that this problem also involves ACKing *all* frames the HW receives (including beacons ;). Such frames are delivered to host and generate the former warning as well. This could be a problem with regulatory compliance in some rare cases (e.g. Taiwan which forbids transmissions on channel 36 which is the default bootup channel on 5Ghz band cards). The good news is that it'd require someone else to violate regulatory first to coerce our device to generate and transmit an ACK. The problem could be reproduced in a rather busy environment that has a lot of APs. The likelihood could be increased by injecting an msleep() of 5000 or longer immediately after ath10k_htt_setup() in ath10k_core_start(). The reason why the former warnings were only showing up seldom is because the device was either quickly reset again (i.e. during firmware probing) or wmi vdev was created (which fixes hw and fw states). It is technically possible for host driver to override adequate hw registers however this can't work reliably because the bug root cause lies in incorrect firmware state on boot (internal structure used to program MAC_PCU_ADDR1 is not properly initialized) and only vdev create/delete events can fix it. This is why the patch takes dummy vdev approach. This could be fixed in firmware as well but having this fixed in driver is more robust, most notably when thinking of users of older firmware such as 999.999.0.636. Reported-by: Marek Puzyniak <marek.puzyniak@tieto.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-08-19 04:37:43 -06:00
static int ath10k_core_reset_rx_filter(struct ath10k *ar)
{
int ret;
int vdev_id;
int vdev_type;
int vdev_subtype;
const u8 *vdev_addr;
vdev_id = 0;
vdev_type = WMI_VDEV_TYPE_STA;
vdev_subtype = ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE);
vdev_addr = ar->mac_addr;
ret = ath10k_wmi_vdev_create(ar, vdev_id, vdev_type, vdev_subtype,
vdev_addr);
if (ret) {
ath10k_err(ar, "failed to create dummy vdev: %d\n", ret);
return ret;
}
ret = ath10k_wmi_vdev_delete(ar, vdev_id);
if (ret) {
ath10k_err(ar, "failed to delete dummy vdev: %d\n", ret);
return ret;
}
/* WMI and HTT may use separate HIF pipes and are not guaranteed to be
* serialized properly implicitly.
*
* Moreover (most) WMI commands have no explicit acknowledges. It is
* possible to infer it implicitly by poking firmware with echo
* command - getting a reply means all preceding comments have been
* (mostly) processed.
*
* In case of vdev create/delete this is sufficient.
*
* Without this it's possible to end up with a race when HTT Rx ring is
* started before vdev create/delete hack is complete allowing a short
* window of opportunity to receive (and Tx ACK) a bunch of frames.
*/
ret = ath10k_wmi_barrier(ar);
if (ret) {
ath10k_err(ar, "failed to ping firmware: %d\n", ret);
return ret;
}
return 0;
}
static int ath10k_core_compat_services(struct ath10k *ar)
{
struct ath10k_fw_file *fw_file = &ar->normal_mode_fw.fw_file;
/* all 10.x firmware versions support thermal throttling but don't
* advertise the support via service flags so we have to hardcode
* it here
*/
switch (fw_file->wmi_op_version) {
case ATH10K_FW_WMI_OP_VERSION_10_1:
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
case ATH10K_FW_WMI_OP_VERSION_10_4:
set_bit(WMI_SERVICE_THERM_THROT, ar->wmi.svc_map);
break;
default:
break;
}
return 0;
}
int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
const struct ath10k_fw_components *fw)
{
int status;
u32 val;
lockdep_assert_held(&ar->conf_mutex);
clear_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
ar->running_fw = fw;
if (!test_bit(ATH10K_FW_FEATURE_NON_BMI,
ar->running_fw->fw_file.fw_features)) {
ath10k_bmi_start(ar);
if (ath10k_init_configure_target(ar)) {
status = -EINVAL;
goto err;
}
status = ath10k_download_cal_data(ar);
if (status)
goto err;
/* Some of of qca988x solutions are having global reset issue
* during target initialization. Bypassing PLL setting before
* downloading firmware and letting the SoC run on REF_CLK is
* fixing the problem. Corresponding firmware change is also
* needed to set the clock source once the target is
* initialized.
*/
if (test_bit(ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT,
ar->running_fw->fw_file.fw_features)) {
status = ath10k_bmi_write32(ar, hi_skip_clock_init, 1);
if (status) {
ath10k_err(ar, "could not write to skip_clock_init: %d\n",
status);
goto err;
}
}
status = ath10k_download_fw(ar);
if (status)
goto err;
status = ath10k_init_uart(ar);
if (status)
goto err;
if (ar->hif.bus == ATH10K_BUS_SDIO)
ath10k_init_sdio(ar, mode);
}
ar->htc.htc_ops.target_send_suspend_complete =
ath10k_send_suspend_complete;
status = ath10k_htc_init(ar);
if (status) {
ath10k_err(ar, "could not init HTC (%d)\n", status);
goto err;
}
if (!test_bit(ATH10K_FW_FEATURE_NON_BMI,
ar->running_fw->fw_file.fw_features)) {
status = ath10k_bmi_done(ar);
if (status)
goto err;
}
status = ath10k_wmi_attach(ar);
if (status) {
ath10k_err(ar, "WMI attach failed: %d\n", status);
goto err;
}
status = ath10k_htt_init(ar);
if (status) {
ath10k_err(ar, "failed to init htt: %d\n", status);
goto err_wmi_detach;
}
ath10k: fix Tx DMA alloc failure during continuous wifi down/up With maximum number of vap's configured in a two radio supported systems of ~256 Mb RAM, doing a continuous wifi down/up and intermittent traffic streaming from the connected stations results in failure to allocate contiguous memory for tx buffers. This results in the disappearance of all VAP's and a manual reboot is needed as this is not a crash (or) OOM(for OOM killer to be invoked). To address this allocate contiguous memory for tx buffers one time and re-use them until the modules are unloaded but this results in a slight increase in memory footprint of ath10k when the wifi is down, but the modules are still loaded. Also as of now we use a separate bool 'tx_mem_allocated' to keep track of the one time memory allocation, as we cannot come up with something like 'ath10k_tx_{register,unregister}' before 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc' memory allocation is dependent on the hw_param 'continuous_frag_desc' a) memory footprint of ath10k without the change lsmod | grep ath10k ath10k_core 414498 1 ath10k_pci ath10k_pci 38236 0 b) memory footprint of ath10k with the change ath10k_core 414980 1 ath10k_pci ath10k_pci 38236 0 Memory Failure Call trace: hostapd: page allocation failure: order:6, mode:0xd0 [<c021f150>] (__dma_alloc_buffer.isra.23) from [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8) [<c021f23c>] (__alloc_remap_buffer.isra.26) from [<c021f664>] (__dma_alloc+0x224/0x2b8) [<c021f664>] (__dma_alloc) from [<c021f810>] (arm_dma_alloc+0x84/0x90) [<c021f810>] (arm_dma_alloc) from [<bf954764>] (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core]) [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core]) [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core]) [<bf947eec>] (ath10k_start [ath10k_core]) from [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211]) [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>] (ieee80211_do_open+0x170/0x82c [mac80211]) [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from [<c056afc8>] (__dev_open+0xa0/0xf4) [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR) 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95276kB Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-30 02:50:14 -07:00
status = ath10k_htt_tx_start(&ar->htt);
if (status) {
ath10k_err(ar, "failed to alloc htt tx: %d\n", status);
goto err_wmi_detach;
}
/* If firmware indicates Full Rx Reorder support it must be used in a
* slightly different manner. Let HTT code know.
*/
ar->htt.rx_ring.in_ord_rx = !!(test_bit(WMI_SERVICE_RX_FULL_REORDER,
ar->wmi.svc_map));
status = ath10k_htt_rx_alloc(&ar->htt);
if (status) {
ath10k_err(ar, "failed to alloc htt rx: %d\n", status);
goto err_htt_tx_detach;
}
status = ath10k_hif_start(ar);
if (status) {
ath10k_err(ar, "could not start HIF: %d\n", status);
goto err_htt_rx_detach;
}
status = ath10k_htc_wait_target(&ar->htc);
if (status) {
ath10k_err(ar, "failed to connect to HTC: %d\n", status);
goto err_hif_stop;
}
status = ath10k_hif_swap_mailbox(ar);
if (status) {
ath10k_err(ar, "failed to swap mailbox: %d\n", status);
goto err_hif_stop;
}
if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
status = ath10k_htt_connect(&ar->htt);
if (status) {
ath10k_err(ar, "failed to connect htt (%d)\n", status);
goto err_hif_stop;
}
}
status = ath10k_wmi_connect(ar);
if (status) {
ath10k_err(ar, "could not connect wmi: %d\n", status);
goto err_hif_stop;
}
status = ath10k_htc_start(&ar->htc);
if (status) {
ath10k_err(ar, "failed to start htc: %d\n", status);
goto err_hif_stop;
}
if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
status = ath10k_wmi_wait_for_service_ready(ar);
if (status) {
ath10k_warn(ar, "wmi service ready event not received");
goto err_hif_stop;
}
}
ath10k_dbg(ar, ATH10K_DBG_BOOT, "firmware %s booted\n",
ar->hw->wiphy->fw_version);
if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map) &&
mode == ATH10K_FIRMWARE_MODE_NORMAL) {
val = 0;
if (ath10k_peer_stats_enabled(ar))
val = WMI_10_4_PEER_STATS;
/* Enable vdev stats by default */
val |= WMI_10_4_VDEV_STATS;
if (test_bit(WMI_SERVICE_BSS_CHANNEL_INFO_64, ar->wmi.svc_map))
val |= WMI_10_4_BSS_CHANNEL_INFO_64;
/* 10.4 firmware supports BT-Coex without reloading firmware
* via pdev param. To support Bluetooth coexistence pdev param,
* WMI_COEX_GPIO_SUPPORT of extended resource config should be
* enabled always.
*/
if (test_bit(WMI_SERVICE_COEX_GPIO, ar->wmi.svc_map) &&
test_bit(ATH10K_FW_FEATURE_BTCOEX_PARAM,
ar->running_fw->fw_file.fw_features))
val |= WMI_10_4_COEX_GPIO_SUPPORT;
if (test_bit(WMI_SERVICE_TDLS_EXPLICIT_MODE_ONLY,
ar->wmi.svc_map))
val |= WMI_10_4_TDLS_EXPLICIT_MODE_ONLY;
if (test_bit(WMI_SERVICE_TDLS_UAPSD_BUFFER_STA,
ar->wmi.svc_map))
val |= WMI_10_4_TDLS_UAPSD_BUFFER_STA;
if (test_bit(WMI_SERVICE_TX_DATA_ACK_RSSI,
ar->wmi.svc_map))
val |= WMI_10_4_TX_DATA_ACK_RSSI;
if (test_bit(WMI_SERVICE_REPORT_AIRTIME, ar->wmi.svc_map))
val |= WMI_10_4_REPORT_AIRTIME;
status = ath10k_mac_ext_resource_config(ar, val);
if (status) {
ath10k_err(ar,
"failed to send ext resource cfg command : %d\n",
status);
goto err_hif_stop;
}
}
status = ath10k_wmi_cmd_init(ar);
if (status) {
ath10k_err(ar, "could not send WMI init command (%d)\n",
status);
goto err_hif_stop;
}
status = ath10k_wmi_wait_for_unified_ready(ar);
if (status) {
ath10k_err(ar, "wmi unified ready event not received\n");
goto err_hif_stop;
}
status = ath10k_core_compat_services(ar);
if (status) {
ath10k_err(ar, "compat services failed: %d\n", status);
goto err_hif_stop;
}
ath10k: implement set_base_macaddr to fix rx-bssid mask in multiple APs conf Many integrated QCA9984 WiFis in various IPQ806x platform routers from various vendors (Netgear R7800, ZyXEL NBG6817, TP-LINK C2600, etc.) have either blank, bogus or non-unique MAC-addresses in their calibration data. As a result, OpenWrt utilizes a discouraged binary calibration data patching method that allows to modify the device's MAC-addresses right at the source. This is because the ath10k' firmware extracts the MAC address from the supplied radio/calibration data and issues a response to the ath10k linux driver. Which was designed to take the main MAC in ath10k_wmi_event_ready(). Part of the "setting an alternate MAC" issue was already tackled by a patch from Brian Norris: commit 9d5804662ce1 ("ath10k: retrieve MAC address from system firmware if provided") by allowing the option to specify an alternate MAC-address with the established device_get_mac_address() function which extracts the right address from DeviceTree/fwnode mac-address or local-mac-address properties and saves it for later. However, Ben Greear noted that the Qualcomm's ath10k firmware is liable to not properly calculate its rx-bssid mask in this case. This can cause issues in the popluar "multiple AP with a single ath10k instance" configurations. To improve MAC address handling, Felix Fietkau suggested to call pdev_set_base_macaddr_cmdid before bringing up the first vif and use the first vif MAC address there. Which is in ath10k_core_start(). This patch implement Felix Fietkau's request to "call pdev_set_base_macaddr_cmdid before bringing up the first vif". The pdev_set_base_macaddr_cmdid is already declared for all devices and version. The driver just needed the support code for this function. Tested on: QCA9880/CUS223, firmwares: 10.2.4.13-2, 10.2.4.70.44, 10.2.4-1.0-00041 QCA9887/MR33 firmware:10.2.4-1.0-00033 QCA4019/RT-AC58U firmware: 10.4-3.4-00104, 10.4-3.5.3-00057 QCA9984/R7800 firmware: Candela Technologies (CT) Firmware BugLink: https://lists.openwrt.org/pipermail/openwrt-devel/2018-November/014595.html Fixes: 9d5804662ce1 ("ath10k: retrieve MAC address from system firmware if provided") Cc: Brian Norris <briannorris@chromium.org> Cc: Ben Greear <greearb@candelatech.com> Cc: Felix Fietkau <nbd@nbd.name> Cc: Mathias Kresin <dev@kresin.me> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-08 05:55:28 -07:00
status = ath10k_wmi_pdev_set_base_macaddr(ar, ar->mac_addr);
if (status && status != -EOPNOTSUPP) {
ath10k_err(ar,
"failed to set base mac address: %d\n", status);
goto err_hif_stop;
}
ath10k: fix spurious tx/rx during boot HW Rx filters and masks are not configured properly by firmware during boot sequences. The MAC_PCU_ADDR1 is set to 0s instead of 1s which allows the HW to ACK any frame that passes through MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself is misconfigured on boot as well. The combination of these bugs ended up with the following manifestations: - "no channel configured; ignoring frame(s)!" warnings in the driver - spurious ACKs (transmission) on the air during firmware bootup sequences The former was a long standing and known bug originally though mostly harmless. However Marek recently discovered that this problem also involves ACKing *all* frames the HW receives (including beacons ;). Such frames are delivered to host and generate the former warning as well. This could be a problem with regulatory compliance in some rare cases (e.g. Taiwan which forbids transmissions on channel 36 which is the default bootup channel on 5Ghz band cards). The good news is that it'd require someone else to violate regulatory first to coerce our device to generate and transmit an ACK. The problem could be reproduced in a rather busy environment that has a lot of APs. The likelihood could be increased by injecting an msleep() of 5000 or longer immediately after ath10k_htt_setup() in ath10k_core_start(). The reason why the former warnings were only showing up seldom is because the device was either quickly reset again (i.e. during firmware probing) or wmi vdev was created (which fixes hw and fw states). It is technically possible for host driver to override adequate hw registers however this can't work reliably because the bug root cause lies in incorrect firmware state on boot (internal structure used to program MAC_PCU_ADDR1 is not properly initialized) and only vdev create/delete events can fix it. This is why the patch takes dummy vdev approach. This could be fixed in firmware as well but having this fixed in driver is more robust, most notably when thinking of users of older firmware such as 999.999.0.636. Reported-by: Marek Puzyniak <marek.puzyniak@tieto.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-08-19 04:37:43 -06:00
/* Some firmware revisions do not properly set up hardware rx filter
* registers.
*
* A known example from QCA9880 and 10.2.4 is that MAC_PCU_ADDR1_MASK
* is filled with 0s instead of 1s allowing HW to respond with ACKs to
* any frames that matches MAC_PCU_RX_FILTER which is also
* misconfigured to accept anything.
*
* The ADDR1 is programmed using internal firmware structure field and
* can't be (easily/sanely) reached from the driver explicitly. It is
* possible to implicitly make it correct by creating a dummy vdev and
* then deleting it.
*/
if (ar->hw_params.hw_filter_reset_required &&
mode == ATH10K_FIRMWARE_MODE_NORMAL) {
status = ath10k_core_reset_rx_filter(ar);
if (status) {
ath10k_err(ar,
"failed to reset rx filter: %d\n", status);
goto err_hif_stop;
}
ath10k: fix spurious tx/rx during boot HW Rx filters and masks are not configured properly by firmware during boot sequences. The MAC_PCU_ADDR1 is set to 0s instead of 1s which allows the HW to ACK any frame that passes through MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself is misconfigured on boot as well. The combination of these bugs ended up with the following manifestations: - "no channel configured; ignoring frame(s)!" warnings in the driver - spurious ACKs (transmission) on the air during firmware bootup sequences The former was a long standing and known bug originally though mostly harmless. However Marek recently discovered that this problem also involves ACKing *all* frames the HW receives (including beacons ;). Such frames are delivered to host and generate the former warning as well. This could be a problem with regulatory compliance in some rare cases (e.g. Taiwan which forbids transmissions on channel 36 which is the default bootup channel on 5Ghz band cards). The good news is that it'd require someone else to violate regulatory first to coerce our device to generate and transmit an ACK. The problem could be reproduced in a rather busy environment that has a lot of APs. The likelihood could be increased by injecting an msleep() of 5000 or longer immediately after ath10k_htt_setup() in ath10k_core_start(). The reason why the former warnings were only showing up seldom is because the device was either quickly reset again (i.e. during firmware probing) or wmi vdev was created (which fixes hw and fw states). It is technically possible for host driver to override adequate hw registers however this can't work reliably because the bug root cause lies in incorrect firmware state on boot (internal structure used to program MAC_PCU_ADDR1 is not properly initialized) and only vdev create/delete events can fix it. This is why the patch takes dummy vdev approach. This could be fixed in firmware as well but having this fixed in driver is more robust, most notably when thinking of users of older firmware such as 999.999.0.636. Reported-by: Marek Puzyniak <marek.puzyniak@tieto.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-08-19 04:37:43 -06:00
}
status = ath10k_htt_rx_ring_refill(ar);
if (status) {
ath10k_err(ar, "failed to refill htt rx ring: %d\n", status);
goto err_hif_stop;
}
if (ar->max_num_vdevs >= 64)
ar->free_vdev_map = 0xFFFFFFFFFFFFFFFFLL;
else
ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
INIT_LIST_HEAD(&ar->arvifs);
/* we don't care about HTT in UTF mode */
if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
status = ath10k_htt_setup(&ar->htt);
if (status) {
ath10k_err(ar, "failed to setup htt: %d\n", status);
goto err_hif_stop;
}
}
status = ath10k_debug_start(ar);
if (status)
goto err_hif_stop;
status = ath10k_hif_set_target_log_mode(ar, fw_diag_log);
if (status && status != -EOPNOTSUPP) {
ath10k_warn(ar, "set traget log mode faileds: %d\n", status);
goto err_hif_stop;
}
return 0;
err_hif_stop:
ath10k_hif_stop(ar);
err_htt_rx_detach:
ath10k_htt_rx_free(&ar->htt);
err_htt_tx_detach:
ath10k_htt_tx_free(&ar->htt);
err_wmi_detach:
ath10k_wmi_detach(ar);
err:
return status;
}
EXPORT_SYMBOL(ath10k_core_start);
int ath10k_wait_for_suspend(struct ath10k *ar, u32 suspend_opt)
{
int ret;
unsigned long time_left;
reinit_completion(&ar->target_suspend);
ret = ath10k_wmi_pdev_suspend_target(ar, suspend_opt);
if (ret) {
ath10k_warn(ar, "could not suspend target (%d)\n", ret);
return ret;
}
time_left = wait_for_completion_timeout(&ar->target_suspend, 1 * HZ);
if (!time_left) {
ath10k_warn(ar, "suspend timed out - target pause event never came\n");
return -ETIMEDOUT;
}
return 0;
}
void ath10k_core_stop(struct ath10k *ar)
{
lockdep_assert_held(&ar->conf_mutex);
ath10k_debug_stop(ar);
/* try to suspend target */
if (ar->state != ATH10K_STATE_RESTARTING &&
ar->state != ATH10K_STATE_UTF)
ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
ath10k_hif_stop(ar);
ath10k: fix Tx DMA alloc failure during continuous wifi down/up With maximum number of vap's configured in a two radio supported systems of ~256 Mb RAM, doing a continuous wifi down/up and intermittent traffic streaming from the connected stations results in failure to allocate contiguous memory for tx buffers. This results in the disappearance of all VAP's and a manual reboot is needed as this is not a crash (or) OOM(for OOM killer to be invoked). To address this allocate contiguous memory for tx buffers one time and re-use them until the modules are unloaded but this results in a slight increase in memory footprint of ath10k when the wifi is down, but the modules are still loaded. Also as of now we use a separate bool 'tx_mem_allocated' to keep track of the one time memory allocation, as we cannot come up with something like 'ath10k_tx_{register,unregister}' before 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc' memory allocation is dependent on the hw_param 'continuous_frag_desc' a) memory footprint of ath10k without the change lsmod | grep ath10k ath10k_core 414498 1 ath10k_pci ath10k_pci 38236 0 b) memory footprint of ath10k with the change ath10k_core 414980 1 ath10k_pci ath10k_pci 38236 0 Memory Failure Call trace: hostapd: page allocation failure: order:6, mode:0xd0 [<c021f150>] (__dma_alloc_buffer.isra.23) from [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8) [<c021f23c>] (__alloc_remap_buffer.isra.26) from [<c021f664>] (__dma_alloc+0x224/0x2b8) [<c021f664>] (__dma_alloc) from [<c021f810>] (arm_dma_alloc+0x84/0x90) [<c021f810>] (arm_dma_alloc) from [<bf954764>] (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core]) [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core]) [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core]) [<bf947eec>] (ath10k_start [ath10k_core]) from [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211]) [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>] (ieee80211_do_open+0x170/0x82c [mac80211]) [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from [<c056afc8>] (__dev_open+0xa0/0xf4) [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR) 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95276kB Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-30 02:50:14 -07:00
ath10k_htt_tx_stop(&ar->htt);
ath10k_htt_rx_free(&ar->htt);
ath10k_wmi_detach(ar);
}
EXPORT_SYMBOL(ath10k_core_stop);
/* mac80211 manages fw/hw initialization through start/stop hooks. However in
* order to know what hw capabilities should be advertised to mac80211 it is
* necessary to load the firmware (and tear it down immediately since start
* hook will try to init it again) before registering
*/
static int ath10k_core_probe_fw(struct ath10k *ar)
{
struct bmi_target_info target_info;
int ret = 0;
ret = ath10k_hif_power_up(ar, ATH10K_FIRMWARE_MODE_NORMAL);
if (ret) {
ath10k_err(ar, "could not power on hif bus (%d)\n", ret);
return ret;
}
switch (ar->hif.bus) {
case ATH10K_BUS_SDIO:
memset(&target_info, 0, sizeof(target_info));
ret = ath10k_bmi_get_target_info_sdio(ar, &target_info);
if (ret) {
ath10k_err(ar, "could not get target info (%d)\n", ret);
goto err_power_down;
}
ar->target_version = target_info.version;
ar->hw->wiphy->hw_version = target_info.version;
break;
case ATH10K_BUS_PCI:
case ATH10K_BUS_AHB:
case ATH10K_BUS_USB:
memset(&target_info, 0, sizeof(target_info));
ret = ath10k_bmi_get_target_info(ar, &target_info);
if (ret) {
ath10k_err(ar, "could not get target info (%d)\n", ret);
goto err_power_down;
}
ar->target_version = target_info.version;
ar->hw->wiphy->hw_version = target_info.version;
break;
case ATH10K_BUS_SNOC:
memset(&target_info, 0, sizeof(target_info));
ret = ath10k_hif_get_target_info(ar, &target_info);
if (ret) {
ath10k_err(ar, "could not get target info (%d)\n", ret);
goto err_power_down;
}
ar->target_version = target_info.version;
ar->hw->wiphy->hw_version = target_info.version;
break;
default:
ath10k_err(ar, "incorrect hif bus type: %d\n", ar->hif.bus);
}
ret = ath10k_init_hw_params(ar);
if (ret) {
ath10k_err(ar, "could not get hw params (%d)\n", ret);
goto err_power_down;
}
ret = ath10k_core_fetch_firmware_files(ar);
if (ret) {
ath10k_err(ar, "could not fetch firmware files (%d)\n", ret);
goto err_power_down;
}
BUILD_BUG_ON(sizeof(ar->hw->wiphy->fw_version) !=
sizeof(ar->normal_mode_fw.fw_file.fw_version));
memcpy(ar->hw->wiphy->fw_version, ar->normal_mode_fw.fw_file.fw_version,
sizeof(ar->hw->wiphy->fw_version));
ath10k_debug_print_hwfw_info(ar);
if (!test_bit(ATH10K_FW_FEATURE_NON_BMI,
ar->normal_mode_fw.fw_file.fw_features)) {
ret = ath10k_core_pre_cal_download(ar);
if (ret) {
/* pre calibration data download is not necessary
* for all the chipsets. Ignore failures and continue.
*/
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"could not load pre cal data: %d\n", ret);
}
ath10k: incorporate qca4019 cal data download sequence qca4019 calibration data is stored in the host memory and it's mandatory to download it even before reading board id and chip id from the target. Also, there is a need to execute otp (download and run) twice, one after cal data download and another one after board data download. Existing cal data file name 'cal-<bus>-<id>.bin' and device tree entry 'qcom,ath10k-calibration-data' used in ath10k has assumption that it carries other data (like board data) also along with the calibration data. But, qca4019 cal data contains pure calibration data (doesn't include any other info). So, using existing same cal file name and DT entry in qca4019 case would alter the purpose of it. To avoid this, new cal file name 'pre-cal-<bus>-<id>.bin' and new device tree entry name 'qcom,ath10k-pre-calibration-data are introduced. Overall qca4019's firmware download sequence would look like, 1) Download cal data (either from a file or device tree entry) at the address specified by target in the host interest area member "hi_board_data". 2) Download otp and run with 0x10 (PARAM_GET_EEPROM_BOARD_ID) as a argument. At this point, otp will take back up of downloaded cal data content in another location in the target and return valid board id and chip id to the host. 3) Download board data at the address specified by target in host interest area member "hi_board_data". 4) Download otp and run with 0x10000 (PARAM_FLASH_SECTION_ALL) as a argument. Now otp will apply cal data content from it's backup on top of board data download in step 3 and prepare final data base. 5) Download code swap and athwlan binary content. Above sequences are implemented (step 1 to step 4) in the name of pre calibration configuration. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-18 03:44:22 -06:00
ret = ath10k_core_get_board_id_from_otp(ar);
if (ret && ret != -EOPNOTSUPP) {
ath10k_err(ar, "failed to get board id from otp: %d\n",
ret);
goto err_free_firmware_files;
}
ret = ath10k_core_check_smbios(ar);
if (ret)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "SMBIOS bdf variant name not set.\n");
ret = ath10k_core_check_dt(ar);
if (ret)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "DT bdf variant name not set.\n");
ath10k: search SMBIOS for OEM board file extension Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" If board data file name extension is set but board-2.bin does not contain board data file for the variant, the driver will fallback to the default board data file not to break backward compatibility. This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension") but later reverted in commit 005c3490e9db ("Revert "ath10k: Search SMBIOS for OEM board file extension"". This patch is now otherwise the same as commit f2593cb1b291 except the regression fixed. Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-02-24 15:30:03 -07:00
ath10k: support extended board data download for dual-band QCA9984 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>
2018-09-03 11:07:53 -06:00
ret = ath10k_core_fetch_board_file(ar, ATH10K_BD_IE_BOARD);
if (ret) {
ath10k_err(ar, "failed to fetch board file: %d\n", ret);
goto err_free_firmware_files;
}
ath10k_debug_print_board_info(ar);
}
device_get_mac_address(ar->dev, ar->mac_addr, sizeof(ar->mac_addr));
ret = ath10k_core_init_firmware_features(ar);
if (ret) {
ath10k_err(ar, "fatal problem with firmware features: %d\n",
ret);
goto err_free_firmware_files;
}
if (!test_bit(ATH10K_FW_FEATURE_NON_BMI,
ar->normal_mode_fw.fw_file.fw_features)) {
ret = ath10k_swap_code_seg_init(ar,
&ar->normal_mode_fw.fw_file);
if (ret) {
ath10k_err(ar, "failed to initialize code swap segment: %d\n",
ret);
goto err_free_firmware_files;
}
}
mutex_lock(&ar->conf_mutex);
ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL,
&ar->normal_mode_fw);
if (ret) {
ath10k_err(ar, "could not init core (%d)\n", ret);
goto err_unlock;
}
ath10k_debug_print_boot_info(ar);
ath10k_core_stop(ar);
mutex_unlock(&ar->conf_mutex);
ath10k_hif_power_down(ar);
return 0;
err_unlock:
mutex_unlock(&ar->conf_mutex);
err_free_firmware_files:
ath10k_core_free_firmware_files(ar);
err_power_down:
ath10k_hif_power_down(ar);
return ret;
}
static void ath10k_core_register_work(struct work_struct *work)
{
struct ath10k *ar = container_of(work, struct ath10k, register_work);
int status;
/* peer stats are enabled by default */
set_bit(ATH10K_FLAG_PEER_STATS, &ar->dev_flags);
status = ath10k_core_probe_fw(ar);
if (status) {
ath10k_err(ar, "could not probe fw (%d)\n", status);
goto err;
}
status = ath10k_mac_register(ar);
if (status) {
ath10k_err(ar, "could not register to mac80211 (%d)\n", status);
goto err_release_fw;
}
status = ath10k_coredump_register(ar);
if (status) {
ath10k_err(ar, "unable to register coredump\n");
goto err_unregister_mac;
}
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
status = ath10k_debug_register(ar);
if (status) {
ath10k_err(ar, "unable to initialize debugfs\n");
goto err_unregister_coredump;
}
status = ath10k_spectral_create(ar);
if (status) {
ath10k_err(ar, "failed to initialize spectral\n");
goto err_debug_destroy;
}
status = ath10k_thermal_register(ar);
if (status) {
ath10k_err(ar, "could not register thermal device: %d\n",
status);
goto err_spectral_destroy;
}
set_bit(ATH10K_FLAG_CORE_REGISTERED, &ar->dev_flags);
return;
err_spectral_destroy:
ath10k_spectral_destroy(ar);
err_debug_destroy:
ath10k_debug_destroy(ar);
err_unregister_coredump:
ath10k_coredump_unregister(ar);
err_unregister_mac:
ath10k_mac_unregister(ar);
err_release_fw:
ath10k_core_free_firmware_files(ar);
err:
/* TODO: It's probably a good idea to release device from the driver
* but calling device_release_driver() here will cause a deadlock.
*/
return;
}
int ath10k_core_register(struct ath10k *ar,
const struct ath10k_bus_params *bus_params)
{
ar->bus_param = *bus_params;
queue_work(ar->workqueue, &ar->register_work);
return 0;
}
EXPORT_SYMBOL(ath10k_core_register);
void ath10k_core_unregister(struct ath10k *ar)
{
cancel_work_sync(&ar->register_work);
if (!test_bit(ATH10K_FLAG_CORE_REGISTERED, &ar->dev_flags))
return;
ath10k_thermal_unregister(ar);
/* Stop spectral before unregistering from mac80211 to remove the
* relayfs debugfs file cleanly. Otherwise the parent debugfs tree
* would be already be free'd recursively, leading to a double free.
*/
ath10k_spectral_destroy(ar);
/* We must unregister from mac80211 before we stop HTC and HIF.
* Otherwise we will fail to submit commands to FW and mac80211 will be
* unhappy about callback failures.
*/
ath10k_mac_unregister(ar);
ath10k_testmode_destroy(ar);
ath10k_core_free_firmware_files(ar);
ath10k_core_free_board_files(ar);
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
ath10k_debug_unregister(ar);
}
EXPORT_SYMBOL(ath10k_core_unregister);
struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev,
enum ath10k_bus bus,
enum ath10k_hw_rev hw_rev,
const struct ath10k_hif_ops *hif_ops)
{
struct ath10k *ar;
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
int ret;
ar = ath10k_mac_create(priv_size);
if (!ar)
return NULL;
ar->ath_common.priv = ar;
ar->ath_common.hw = ar->hw;
ar->dev = dev;
ar->hw_rev = hw_rev;
ar->hif.ops = hif_ops;
ar->hif.bus = bus;
switch (hw_rev) {
case ATH10K_HW_QCA988X:
case ATH10K_HW_QCA9887:
ar->regs = &qca988x_regs;
ar->hw_ce_regs = &qcax_ce_regs;
ar->hw_values = &qca988x_values;
break;
case ATH10K_HW_QCA6174:
case ATH10K_HW_QCA9377:
ar->regs = &qca6174_regs;
ar->hw_ce_regs = &qcax_ce_regs;
ar->hw_values = &qca6174_values;
break;
case ATH10K_HW_QCA99X0:
case ATH10K_HW_QCA9984:
ar->regs = &qca99x0_regs;
ar->hw_ce_regs = &qcax_ce_regs;
ar->hw_values = &qca99x0_values;
break;
case ATH10K_HW_QCA9888:
ar->regs = &qca99x0_regs;
ar->hw_ce_regs = &qcax_ce_regs;
ar->hw_values = &qca9888_values;
break;
case ATH10K_HW_QCA4019:
ar->regs = &qca4019_regs;
ar->hw_ce_regs = &qcax_ce_regs;
ar->hw_values = &qca4019_values;
break;
case ATH10K_HW_WCN3990:
ar->regs = &wcn3990_regs;
ar->hw_ce_regs = &wcn3990_ce_regs;
ar->hw_values = &wcn3990_values;
break;
default:
ath10k_err(ar, "unsupported core hardware revision %d\n",
hw_rev);
ret = -ENOTSUPP;
goto err_free_mac;
}
init_completion(&ar->scan.started);
init_completion(&ar->scan.completed);
init_completion(&ar->scan.on_channel);
init_completion(&ar->target_suspend);
init_completion(&ar->driver_recovery);
init_completion(&ar->wow.wakeup_completed);
init_completion(&ar->install_key_done);
init_completion(&ar->vdev_setup_done);
init_completion(&ar->vdev_delete_done);
init_completion(&ar->thermal.wmi_sync);
init_completion(&ar->bss_survey_done);
init_completion(&ar->peer_delete_done);
INIT_DELAYED_WORK(&ar->scan.timeout, ath10k_scan_timeout_work);
ar->workqueue = create_singlethread_workqueue("ath10k_wq");
if (!ar->workqueue)
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
goto err_free_mac;
ar->workqueue_aux = create_singlethread_workqueue("ath10k_aux_wq");
if (!ar->workqueue_aux)
goto err_free_wq;
mutex_init(&ar->conf_mutex);
ath10k: perform crash dump collection in workqueue Commit 25733c4e67df ("ath10k: pci: use mutex for diagnostic window CE polling") introduced a regression where we try to sleep (grab a mutex) in an atomic context: [ 233.602619] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254 [ 233.602626] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0 [ 233.602636] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.1.0-rc2 #4 [ 233.602642] Hardware name: Google Scarlet (DT) [ 233.602647] Call trace: [ 233.602663] dump_backtrace+0x0/0x11c [ 233.602672] show_stack+0x20/0x28 [ 233.602681] dump_stack+0x98/0xbc [ 233.602690] ___might_sleep+0x154/0x16c [ 233.602696] __might_sleep+0x78/0x88 [ 233.602704] mutex_lock+0x2c/0x5c [ 233.602717] ath10k_pci_diag_read_mem+0x68/0x21c [ath10k_pci] [ 233.602725] ath10k_pci_diag_read32+0x48/0x74 [ath10k_pci] [ 233.602733] ath10k_pci_dump_registers+0x5c/0x16c [ath10k_pci] [ 233.602741] ath10k_pci_fw_crashed_dump+0xb8/0x548 [ath10k_pci] [ 233.602749] ath10k_pci_napi_poll+0x60/0x128 [ath10k_pci] [ 233.602757] net_rx_action+0x140/0x388 [ 233.602766] __do_softirq+0x1b0/0x35c [...] ath10k_pci_fw_crashed_dump() is called from NAPI contexts, and firmware memory dumps are retrieved using the diag memory interface. A simple reproduction case is to run this on QCA6174A / WLAN.RM.4.4.1-00132-QCARMSWP-1, which happens to be a way to b0rk the firmware: dd if=/sys/kernel/debug/ieee80211/phy0/ath10k/mem_value bs=4K count=1 of=/dev/null (NB: simulated firmware crashes, via debugfs, don't trigger firmware dumps.) The fix is to move the crash-dump into a workqueue context, and avoid relying on 'data_lock' for most mutual exclusion. We only keep using it here for protecting 'fw_crash_counter', while the rest of the coredump buffers are protected by a new 'dump_mutex'. I've tested the above with simulated firmware crashes (debugfs 'reset' file), real firmware crashes (the 'dd' command above), and a variety of reboot and suspend/resume configurations on QCA6174A. Reported here: http://lkml.kernel.org/linux-wireless/20190325202706.GA68720@google.com Fixes: 25733c4e67df ("ath10k: pci: use mutex for diagnostic window CE polling") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-03-26 14:57:28 -06:00
mutex_init(&ar->dump_mutex);
spin_lock_init(&ar->data_lock);
INIT_LIST_HEAD(&ar->peers);
init_waitqueue_head(&ar->peer_mapping_wq);
init_waitqueue_head(&ar->htt.empty_tx_wq);
init_waitqueue_head(&ar->wmi.tx_credits_wq);
init_completion(&ar->offchan_tx_completed);
INIT_WORK(&ar->offchan_tx_work, ath10k_offchan_tx_work);
skb_queue_head_init(&ar->offchan_tx_queue);
INIT_WORK(&ar->wmi_mgmt_tx_work, ath10k_mgmt_over_wmi_tx_work);
skb_queue_head_init(&ar->wmi_mgmt_tx_queue);
INIT_WORK(&ar->register_work, ath10k_core_register_work);
INIT_WORK(&ar->restart_work, ath10k_core_restart);
ath10k: allow setting coverage class 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: Benjamin Berg <benjamin@sipsolutions.net> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-28 06:11:58 -06:00
INIT_WORK(&ar->set_coverage_class_work,
ath10k_core_set_coverage_class_work);
init_dummy_netdev(&ar->napi_dev);
ret = ath10k_coredump_create(ar);
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
if (ret)
goto err_free_aux_wq;
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
ret = ath10k_debug_create(ar);
if (ret)
goto err_free_coredump;
return ar;
err_free_coredump:
ath10k_coredump_destroy(ar);
err_free_aux_wq:
destroy_workqueue(ar->workqueue_aux);
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
err_free_wq:
destroy_workqueue(ar->workqueue);
err_free_mac:
ath10k_mac_destroy(ar);
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
return NULL;
}
EXPORT_SYMBOL(ath10k_core_create);
void ath10k_core_destroy(struct ath10k *ar)
{
flush_workqueue(ar->workqueue);
destroy_workqueue(ar->workqueue);
flush_workqueue(ar->workqueue_aux);
destroy_workqueue(ar->workqueue_aux);
ath10k: move fw_crash_dump allocation The fw_crash_data was allocated too late. Upon early firmware crash, before registering to mac80211, it was possible to crash the whole system: ath10k_pci 0000:00:05.0: device has crashed during init BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] PGD 0 Oops: 0002 [#1] SMP Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath] CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G O 3.17.0-rc2-wl-ath+ #447 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000 RIP: 0010:[<ffffffffa0058005>] [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP: 0018:ffff88001eb63ce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001 RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200 R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0 R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60 FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0 Stack: ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010 ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010 ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0 Call Trace: [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci] [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci] [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci] [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core] [<ffffffff810689cc>] process_one_work+0x18c/0x3f0 [<ffffffff81069011>] worker_thread+0x121/0x4a0 [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0 [<ffffffff8106daf2>] kthread+0xd2/0xf0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0 [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170 Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b RIP [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core] RSP <ffff88001eb63ce8> CR2: 0000000000000000 ---[ end trace 5d0ed15b050bcc1f ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt To prevent that split debug functions and allocate fw_crash_data earlier. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-09-04 01:13:08 -06:00
ath10k_debug_destroy(ar);
ath10k_coredump_destroy(ar);
ath10k: fix Tx DMA alloc failure during continuous wifi down/up With maximum number of vap's configured in a two radio supported systems of ~256 Mb RAM, doing a continuous wifi down/up and intermittent traffic streaming from the connected stations results in failure to allocate contiguous memory for tx buffers. This results in the disappearance of all VAP's and a manual reboot is needed as this is not a crash (or) OOM(for OOM killer to be invoked). To address this allocate contiguous memory for tx buffers one time and re-use them until the modules are unloaded but this results in a slight increase in memory footprint of ath10k when the wifi is down, but the modules are still loaded. Also as of now we use a separate bool 'tx_mem_allocated' to keep track of the one time memory allocation, as we cannot come up with something like 'ath10k_tx_{register,unregister}' before 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc' memory allocation is dependent on the hw_param 'continuous_frag_desc' a) memory footprint of ath10k without the change lsmod | grep ath10k ath10k_core 414498 1 ath10k_pci ath10k_pci 38236 0 b) memory footprint of ath10k with the change ath10k_core 414980 1 ath10k_pci ath10k_pci 38236 0 Memory Failure Call trace: hostapd: page allocation failure: order:6, mode:0xd0 [<c021f150>] (__dma_alloc_buffer.isra.23) from [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8) [<c021f23c>] (__alloc_remap_buffer.isra.26) from [<c021f664>] (__dma_alloc+0x224/0x2b8) [<c021f664>] (__dma_alloc) from [<c021f810>] (arm_dma_alloc+0x84/0x90) [<c021f810>] (arm_dma_alloc) from [<bf954764>] (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core]) [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core]) [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core]) [<bf947eec>] (ath10k_start [ath10k_core]) from [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211]) [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>] (ieee80211_do_open+0x170/0x82c [mac80211]) [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from [<c056afc8>] (__dev_open+0xa0/0xf4) [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR) 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95276kB Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-30 02:50:14 -07:00
ath10k_htt_tx_destroy(&ar->htt);
ath10k: fix DMA alloc failure for target requested memory chunks During long hours of stress testing like AP interface up/down along with continuous ping flood from a station doing connect/disconnect, it is observed that the system is not able to allocate DMA consistent memory of size > 512KB chunks as requested by firmware in WMI_SERVICE_EVENTID. With the system memory getting fragmented during the run based on the size of the memory requested, the failure to return physically continguous memory of high order can happen. Once the system gets to this situation, bringing up the wifi interface will fail and a system reboot may be needed to make it work again. This problem is obseved with QCA99X0. To fix this issue, allocate the DMA memory requested by firmware during device probe time and keep it during the life time of the device. WMI service ready event handler is changed to allocate the memory chunks if it is not already allocated or if the memory allocated for the previous ready event is not same as the current requested ones. After this patch the memory usage when wifi is inactive will be inceased by few 100KB to 3MB based on the target type. Failure happens with the following stack trace [29557.488773] kworker/u4:1: page allocation failure: order:8, mode:0xd0 [29557.494297] CPU: 0 PID: 8402 Comm: kworker/u4:1 Not tainted 3.14.43 #7 [29557.500793] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core] [29557.508602] [<c021e9b0>] (unwind_backtrace) from [<c021ba90>] (show_stack+0x10/0x14) [29557.516580] [<c021ba90>] (show_stack) from [<c03bdddc>] (dump_stack+0x88/0xcc) [29557.523612] [<c03bdddc>] (dump_stack) from [<c0290e34>] (warn_alloc_failed+0xdc/0x108) [29557.531515] [<c0290e34>] (warn_alloc_failed) from [<c0292d88>] (__alloc_pages_nodemask+0x4f0/0x654) [29557.540485] [<c0292d88>] (__alloc_pages_nodemask) from [<c0222b48>] (__dma_alloc_buffer.isra.20+0x2c/0x104) [29557.550260] [<c0222b48>] (__dma_alloc_buffer.isra.20) from [<c0222c34>] (__alloc_remap_buffer.isra.23+0x14/0xb8) [29557.560413] [<c0222c34>] (__alloc_remap_buffer.isra.23) from [<c022305c>] (__dma_alloc+0x224/0x2b8) [29557.569490] [<c022305c>] (__dma_alloc) from [<c0223208>] (arm_dma_alloc+0x84/0x90) [29557.577010] [<c0223208>] (arm_dma_alloc) from [<bf5159d0>] (ath10k_wmi_event_service_ready_work+0x2f8/0x420 [ath10k_core]) [29557.588055] [<bf5159d0>] (ath10k_wmi_event_service_ready_work [ath10k_core]) from [<c024260c>] (process_one_work+0x20c/0x328) [29557.599305] [<c024260c>] (process_one_work) from [<c02432d0>] (worker_thread+0x228/0x360) [29557.607470] [<c02432d0>] (worker_thread) from [<c0247f88>] (kthread+0xd8/0xec) [29557.614750] [<c0247f88>] (kthread) from [<c0208d18>] (ret_from_fork+0x14/0x3c) [29557.712751] Normal: 696*4kB (UEMR) 512*8kB (UEMR) 367*16kB (UEMR) 404*32kB (UEMR) 455*64kB (UEMR) 424*128kB (UEMR) 379*256kB (UMR) 327*512kB (UMR) 1*1024kB (R) 0*2048kB 0*4096kB = 374544kB Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-08-28 05:51:34 -06:00
ath10k_wmi_free_host_mem(ar);
ath10k_mac_destroy(ar);
}
EXPORT_SYMBOL(ath10k_core_destroy);
MODULE_AUTHOR("Qualcomm Atheros");
MODULE_DESCRIPTION("Core module for Qualcomm Atheros 802.11ac wireless LAN cards.");
MODULE_LICENSE("Dual BSD/GPL");