Re: QCA9984 all devices being de-authenticated and unable to re-connect
Try down this page a bit, you just need to copy the firmware-5.bin and reboot usually. https://www.candelatech.com/ath10k-bugs.php Thanks, Ben On 04/01/2019 04:04 PM, Carlito Nueno wrote: Hi Ben, Can you tell me how I can compile ath10k-ct firmware version present in 18.06.2 into the latest snapshot? I want to try and see if it's firmware related. Awesome to know you had 64+ stations connected to your firmware. Thanks for the help. On Sun, Mar 31, 2019 at 8:06 PM Ben Greear wrote: Hello, You could try using the ath10k-ct firmware that does NOT work for you (18.06.2) in the latest snapshot. If problem still happens, then it is firmware related, and I can then build you a series of images so you can do a bisect to find what commit fixes the issue if you really want to know what is the fix. Otherwise, maybe something else fixed the problem. For what it is worth, we have regularly done 64+ stations connected to our ath10k firmware/driver for years. Thanks, Ben On 03/29/2019 07:02 PM, Carlito Nueno wrote: Hi all, I am using: ath10k-firmware-qca9984 - 2018-12-16-211de167-1 kmod-ath10k - 4.14.109+4.19.23-1-5 ## Problem I am able to associate and authenticate many clients. Max I tested was 15 clients. But when more than 4 clients start to play video stream (youtube, twitch, netflix): 1. all the clients loose internet connectivity 2. all of them are _de-authenticated_ 3. when trying to reconnect, they connect but are _disassociated_ immediately. c2:44:2f:f3:3c:22 -64 dBm / -109 dBm (SNR 45) 40 ms ago RX: 200.0 MBit/s, VHT-MCS 9, 40MHz, VHT-NSS 148 Pkts. TX: 12.0 MBit/s9 Pkts. expected throughput: unknown c2:44:2f:f3:3c:22 -57 dBm / -109 dBm (SNR 52) 10 ms ago RX: 12.0 MBit/s 17 Pkts. TX: 12.0 MBit/s5 Pkts. expected throughput: unknown 4. internet on the AP works. (I am able to ping google.com) ## Firmware and OS this problem occurs - ath10k + 18.06.2 = yes, there is this problem - ath10k + snapshot = yes, there is this problem - ath10k-ct + 18.06.2 = yes, similar problem occurs (https://github.com/greearb/ath10k-ct/issues/82) - ath10k-ct + snapshot = no, works fine ## OpenWRT info ### Release DISTRIB_ID='OpenWrt' DISTRIB_RELEASE='SNAPSHOT' DISTRIB_REVISION='r9753-6df5ab89cf' DISTRIB_TARGET='ar71xx/generic' DISTRIB_ARCH='mips_24kc' DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r9753-6df5ab89cf' DISTRIB_TAINTS='no-all' ### Logs Include: - Full list of OPKGs installed: 2_opkg_installed-txt - Logs up to the point of crash: 3_ath10k_crash-txt - Logs after the crash and trying to reconnect: 4_after_crash_reconnect-txt https://gist.github.com/ironpillow/96ce9173721163a8c8c93113b2a677d7 ### More logs I noticed that the some devices stay connected :man_shrugging: and when these connected devices make a dns request, the request is reaching the DNS server but the AP is not receiving response. I ran ping on *one device* and captured packets on AP (two interfaces): - tcpdump -i wlan0-ap - tcpdump -i br-lan ping google.com: https://gist.github.com/ironpillow/50cb0e2010ac5bc9acc7abc7e20ab910 ping 8.8.8.8: https://gist.github.com/ironpillow/97cb3dd6eb8e9d028a8231f142fae01f Packets are not reaching wifi wlan0-ap interface. I am happy to run more tests. Any advice? ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA9984 all devices being de-authenticated and unable to re-connect
Hi Ben, Can you tell me how I can compile ath10k-ct firmware version present in 18.06.2 into the latest snapshot? I want to try and see if it's firmware related. Awesome to know you had 64+ stations connected to your firmware. Thanks for the help. On Sun, Mar 31, 2019 at 8:06 PM Ben Greear wrote: > > Hello, > > You could try using the ath10k-ct firmware that does NOT work for you > (18.06.2) in > the latest snapshot. If problem still happens, then it is firmware related, > and I can then build you a series of images so you can do a bisect to find > what > commit fixes the issue if you really want to know what is the fix. > > Otherwise, maybe something else fixed the problem. For what it is worth, we > have regularly done 64+ stations connected to our ath10k firmware/driver > for years. > > Thanks, > Ben > > On 03/29/2019 07:02 PM, Carlito Nueno wrote: > > Hi all, > > > > I am using: > > > > ath10k-firmware-qca9984 - 2018-12-16-211de167-1 > > kmod-ath10k - 4.14.109+4.19.23-1-5 > > > > ## Problem > > I am able to associate and authenticate many clients. Max I tested was > > 15 clients. > > But when more than 4 clients start to play video stream (youtube, > > twitch, netflix): > > > > 1. all the clients loose internet connectivity > > 2. all of them are _de-authenticated_ > > > > 3. when trying to reconnect, they connect but are _disassociated_ > > immediately. > > > > c2:44:2f:f3:3c:22 -64 dBm / -109 dBm (SNR 45) 40 ms ago > > RX: 200.0 MBit/s, VHT-MCS 9, 40MHz, VHT-NSS 148 Pkts. > > TX: 12.0 MBit/s9 Pkts. > > expected throughput: unknown > > > > c2:44:2f:f3:3c:22 -57 dBm / -109 dBm (SNR 52) 10 ms ago > > RX: 12.0 MBit/s 17 Pkts. > > TX: 12.0 MBit/s5 Pkts. > > expected throughput: unknown > > > > 4. internet on the AP works. (I am able to ping google.com) > > > > ## Firmware and OS this problem occurs > > - ath10k + 18.06.2 = yes, there is this problem > > - ath10k + snapshot = yes, there is this problem > > - ath10k-ct + 18.06.2 = yes, similar problem occurs > > (https://github.com/greearb/ath10k-ct/issues/82) > > - ath10k-ct + snapshot = no, works fine > > > > ## OpenWRT info > > > > ### Release > > DISTRIB_ID='OpenWrt' > > DISTRIB_RELEASE='SNAPSHOT' > > DISTRIB_REVISION='r9753-6df5ab89cf' > > DISTRIB_TARGET='ar71xx/generic' > > DISTRIB_ARCH='mips_24kc' > > DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r9753-6df5ab89cf' > > DISTRIB_TAINTS='no-all' > > > > ### Logs > > Include: > > - Full list of OPKGs installed: 2_opkg_installed-txt > > - Logs up to the point of crash: 3_ath10k_crash-txt > > - Logs after the crash and trying to reconnect: 4_after_crash_reconnect-txt > > > > https://gist.github.com/ironpillow/96ce9173721163a8c8c93113b2a677d7 > > > > ### More logs > > I noticed that the some devices stay connected :man_shrugging: and > > when these connected devices make a dns request, the request is > > reaching the DNS server but the AP is not receiving response. > > > > I ran ping on *one device* and captured packets on AP (two interfaces): > > - tcpdump -i wlan0-ap > > - tcpdump -i br-lan > > > > ping google.com: > > https://gist.github.com/ironpillow/50cb0e2010ac5bc9acc7abc7e20ab910 > > ping 8.8.8.8: > > https://gist.github.com/ironpillow/97cb3dd6eb8e9d028a8231f142fae01f > > > > Packets are not reaching wifi wlan0-ap interface. > > > > I am happy to run more tests. > > > > Any advice? > > > > ___ > > ath10k mailing list > > ath10k@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/ath10k > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v4 1/3] cfg80211: Add support to set tx power for a station associated
Hi Balaji, I started playing with these patches a bit -- they could be useful for my use case, but I had a question: > + * @power: tx power (in dBm) to be used for sending data traffic. If tx power > + * is not provided, the default per-interface tx power setting will be > + * overriding. Driver should be picking up the lowest tx power, either tx > + * power per-interface or per-station. Should this really dBm? It's a bit asymmetric for WIPHY_TX_POWER_LEVEL to use mBm and this to use dBm, and I might want to adjust in half-dB steps if supported by hardware. Also allocating an s16 is a bit much for dBm. -- Bob Copeland %% https://bobcopeland.com/ ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: Add WMI diag fw logging support for WCN3990
Integrated WiFi chipset ex:WCN399x supports fw logging
using WMI copy engine and shared mem DIAG based fw logging.
By default shared mem DIAG based fw logging is enabled.
To support WMI copy engine based fw logging add QMI
control message to enable WMI copy engine based fw logging.
Enable WMI based fw logging using fw_diag_log module parameter.
insmod ath10k_core.ko fw_diag_log=1
DIAG utility(https://github.com/andersson/diag) implements extraction
of diagnostics related messages between application processor and
various subsystems while shared mem DIAG based fw logging is enabled.
Testing: Tested on WCN3990/QCA6174 HW
Tested FW: WLAN.HL.3.1-00959-QCAHLSWMTPLZ-1
Signed-off-by: Govind Singh
---
drivers/net/wireless/ath/ath10k/core.c | 9 ++
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/hif.h | 15 +
drivers/net/wireless/ath/ath10k/qmi.c | 45 ++
drivers/net/wireless/ath/ath10k/qmi.h | 1 +
drivers/net/wireless/ath/ath10k/snoc.c | 14
6 files changed, 85 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 399b501f3c3c..ebf6071bfe15 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -41,6 +41,7 @@ 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);
@@ -51,6 +52,7 @@ 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");
@@ -59,6 +61,7 @@ MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration
in testmode");
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[] = {
{
@@ -2698,6 +2701,12 @@ int ath10k_core_start(struct ath10k *ar, enum
ath10k_firmware_mode mode,
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:
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 46e9c8c97a4d..bfd2b3e23f54 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -635,6 +635,7 @@ struct ath10k_debug {
u32 nf_cal_period;
void *cal_data;
u32 enable_extd_tx_stats;
+ u8 fw_dbglog_mode;
};
enum ath10k_state {
diff --git a/drivers/net/wireless/ath/ath10k/hif.h
b/drivers/net/wireless/ath/ath10k/hif.h
index 1a59ea0068c2..ee825a78480d 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -23,6 +23,12 @@
#include "bmi.h"
#include "debug.h"
+/* Types of fw logging mode */
+enum ath_dbg_mode {
+ ATH10K_ENABLE_FW_LOG_DIAG,
+ ATH10K_ENABLE_FW_LOG_CE,
+};
+
struct ath10k_hif_sg_item {
u16 transfer_id;
void *transfer_context; /* NULL = tx completion callback not called */
@@ -97,6 +103,7 @@ struct ath10k_hif_ops {
int (*get_target_info)(struct ath10k *ar,
struct bmi_target_info *target_info);
+ int (*set_target_log_mode)(struct ath10k *ar, u8 fw_log_mode);
};
static inline int ath10k_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
@@ -231,4 +238,12 @@ static inline int ath10k_hif_get_target_info(struct ath10k
*ar,
return ar->hif.ops->get_target_info(ar, tgt_info);
}
+static inline int ath10k_hif_set_target_log_mode(struct ath10k *ar,
+u8 fw_log_mode)
+{
+ if (!ar->hif.ops->set_target_log_mode)
+ return -EOPNOTSUPP;
+
+ return ar->hif.ops->set_target_log_mode(ar, fw_log_mode);
+}
#endif /* _HIF_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index 99c140a6628d..ba8f5a8f83d1 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -636,6 +636,51 @@ static int ath10k_qmi_host_cap_send_sync(struct ath10k_qmi
*qmi)
return ret;
}
+int ath10k_qmi_set_fw_log_mode(struct ath10k *ar, u8 fw_log_mode)
+{
+ struct ath10k_snoc *ar_snoc
Re: [PATCH] ath10k: remove iteration in wake_tx_queue
On 2019-03-29 15:47, Erik Stromdahl wrote: On 3/27/19 6:49 PM, Peter Oh wrote: On 03/27/2019 09:29 AM, Erik Stromdahl wrote: Iterating the TX queue and thereby dequeuing all available packets in the queue could result in performance penalties on some SMP systems. Please share the test results and numbers you've run to help others thoughts. I haven't run any tests with ath10k PCIe, but Yibo Zhao had noticed a 10% degradation without this patch. Yibo: Can you provide iperf results etc. that shows the performance gain? My tests are based on ixchariot with cabled setup(two-core AP system). WDS mode--10% deviation: With previous change: UDP DL-1246 Mbps W/O previous change: UDP DL-987 Mbps Normal mode: With previous change: UDP DL-1380 Mbps W/O previous change: UDP DL-1310 Mbps Also attached the aqm status. With previous change: tid ac backlog-bytes backlog-packets new-flows drops marks overlimit collisions tx-bytes tx-packets flags 0 2 0 0 5342229 0 0 0 0 3867657029 5342229 0x0(RUN) 1 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 2 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 3 2 0 0 0 0 0 0 0 0 0 0x0(RUN) 4 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 5 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 6 0 0 0 2 0 0 0 0 144 2 0x0(RUN) 7 0 0 0 2 0 0 0 0 282 2 0x0(RUN) 8 2 0 0 0 0 0 0 0 0 0 0x0(RUN) 9 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 10 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 11 2 0 0 0 0 0 0 0 0 0 0x0(RUN) 12 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 13 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 14 0 0 0 0 0 0 0 0 0 0 0x0(RUN) 15 0 0 0 0 0 0 0 0 0 0 0x0(RUN) we see no difference between tx-packets and new-flows. W/O previous change: tid ac backlog-bytes backlog-packets new-flows drops marks overlimit collisions tx-bytes tx-packets flags 0 2 0 0 2233059 3 0 9236 12 1159661783 6380867 0x0(RUN) 1 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 2 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 3 2 0 0 0 0 0 0 0 0 0 0x0(RUN) 4 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 5 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 6 0 0 0 1 0 0 0 0 144 2 0x0(RUN) 7 0 0 0 1 0 0 0 0 282 2 0x0(RUN) 8 2 0 0 0 0 0 0 0 0 0 0x0(RUN) 9 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 10 3 0 0 0 0 0 0 0 0 0 0x0(RUN) 11 2 0 0 0 0 0 0 0 0 0 0x0(RUN) 12 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 13 1 0 0 0 0 0 0 0 0 0 0x0(RUN) 14 0 0 0 0 0 0 0 0 0 0 0x0(RUN) 15 0 0 0 0 0 0 0 0 0 0 0x0(RUN) new-flows are roughly one-third of the total tx-packets. -- Erik -- Yibo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: remove iteration in wake_tx_queue
Erik Stromdahl writes: > Iterating the TX queue and thereby dequeuing all available packets in the > queue could result in performance penalties on some SMP systems. > > The reason for this is most likely that the per-ac lock (active_txq_lock) > in mac80211 will be held by the CPU iterating the current queue. > > This will lock up other CPUs trying to push new messages on the TX > queue. > > Instead of iterating the queue we fetch just one packet at the time, > resulting in minimal starvation of the other CPUs. Did you test this with Felix' patches reducing the time the lock is held in mac80211? -Toke ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH v3 1/2] dt: bindings: add dt entry for XO calibration support
Add dt binding to get xo calibration data support for wifi rf clock. Signed-off-by: Govind Singh --- Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt index ae661e65354e..81859507db67 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt @@ -81,6 +81,7 @@ Optional properties: Definition: Name of external front end module used. Some valid FEM names for example: "microsemi-lx5586", "sky85703-11" and "sky85803" etc. +- qcom,xo-cal-data: xo cal offset to be configured in xo trim register. Example (to supply PCI based wifi block details): -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH v3 2/2] ath10k: Add xo calibration support for wifi rf clock
PMIC XO is the clock source for wifi rf clock in integrated wifi
chipset ex: WCN3990. Due to board layout errors XO frequency drifts
can cause wifi rf clock inaccuracy.
XO calibration test tree in Factory Test Mode is used to find the
best frequency offset(for example +/-2KHz )by programming XO trim
register. This ensure system clock stays within required 20 ppm
WLAN rf clock.
Retrieve the xo trim offset via system firmware (e.g., device tree),
especially in the case where the device doesn't have a useful EEPROM
on which to store the calibrated XO offset (e.g., for integrated Wifi).
Calibrated XO offset is sent to fw, which compensate the clock drift
by programing the XO trim register.
Signed-off-by: Govind Singh
---
drivers/net/wireless/ath/ath10k/qmi.c | 12
drivers/net/wireless/ath/ath10k/snoc.c | 11 +++
drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
3 files changed, 25 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index 37b3bd629f48..99c140a6628d 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -302,10 +302,16 @@ static int ath10k_qmi_send_cal_report_req(struct
ath10k_qmi *qmi)
struct wlfw_cal_report_resp_msg_v01 resp = {};
struct wlfw_cal_report_req_msg_v01 req = {};
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
struct qmi_txn txn;
int i, j = 0;
int ret;
+ if (ar_snoc->xo_cal_supported) {
+ req.xo_cal_data_valid = 1;
+ req.xo_cal_data = ar_snoc->xo_cal_data;
+ }
+
ret = qmi_txn_init(>qmi_hdl, , wlfw_cal_report_resp_msg_v01_ei,
);
if (ret < 0)
@@ -636,6 +642,7 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi
*qmi)
struct wlfw_ind_register_resp_msg_v01 resp = {};
struct wlfw_ind_register_req_msg_v01 req = {};
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
struct qmi_txn txn;
int ret;
@@ -646,6 +653,11 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi
*qmi)
req.msa_ready_enable_valid = 1;
req.msa_ready_enable = 1;
+ if (ar_snoc->xo_cal_supported) {
+ req.xo_cal_enable_valid = 1;
+ req.xo_cal_enable = 1;
+ }
+
ret = qmi_txn_init(>qmi_hdl, ,
wlfw_ind_register_resp_msg_v01_ei, );
if (ret < 0)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c
b/drivers/net/wireless/ath/ath10k/snoc.c
index 54efe6be8f1d..a7f837f4dc53 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include "ce.h"
@@ -1189,6 +1190,16 @@ static int ath10k_snoc_resource_init(struct ath10k *ar)
ar_snoc->ce_irqs[i].irq_line = res->start;
}
+ ret = device_property_read_u32(>dev, "qcom,xo-cal-data",
+ _snoc->xo_cal_data);
+ ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc xo-cal-data return %d\n", ret);
+ if (ret == 0) {
+ ar_snoc->xo_cal_supported = true;
+ ath10k_dbg(ar, ATH10K_DBG_SNOC, "xo cal data %x\n",
+ ar_snoc->xo_cal_data);
+ }
+ ret = 0;
+
out:
return ret;
}
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h
b/drivers/net/wireless/ath/ath10k/snoc.h
index 2b2f23cf7c5d..25383de8f17d 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -91,6 +91,8 @@ struct ath10k_snoc {
struct ath10k_clk_info *clk;
struct ath10k_qmi *qmi;
unsigned long int flags;
+ bool xo_cal_supported;
+ u32 xo_cal_data;
};
static inline struct ath10k_snoc *ath10k_snoc_priv(struct ath10k *ar)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH v3 0/2] Add xo calibration support for wifi rf clock
PMIC XO is the clock source for wifi rf clock in integrated wifi chipset ex: WCN3990. Due to board layout errors XO frequency drifts can cause wifi rf clock inaccuracy. XO calibration test tree in Factory Test Mode is used to find the best frequency offset(for example +/-2KHz )by programming XO trim register. This ensure system clock stays within required 20 ppm WLAN rf clock. Retrieve the xo trim offset via system firmware (e.g., device tree), especially in the case where the device doesn't have a useful EEPROM on which to store the calibrated XO offset (e.g., for integrated Wifi). Calibrated XO offset is sent to fw, which compensate the clock drift by programing the XO trim register. Testing: Tested on QCS404 platform(WCN3990 HW) Tested FW: WLAN.HL.3.1-00959-QCAHLSWMTPLZ-1 change since v2: Added "qcom," prefix in xo cal prop. change since v1: Added return check for case where xo cal dt is not populated. Govind Singh (2): dt: bindings: add dt entry for XO calibration support ath10k: Add xo calibration support for wifi rf clock .../devicetree/bindings/net/wireless/qcom,ath10k.txt | 1 + drivers/net/wireless/ath/ath10k/qmi.c| 12 drivers/net/wireless/ath/ath10k/snoc.c | 11 +++ drivers/net/wireless/ath/ath10k/snoc.h | 2 ++ 4 files changed, 26 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Ath10k on XPS 9380 regularly disconnects
at 16:37, Kalle Valo wrote: Kai-Heng Feng writes: at 23:43, Kai-Heng Feng wrote: at 01:05, Kalle Valo wrote: + ath10k list - netdev & linux-kernel Kai-Heng Feng writes: There’s an issue that ath10k disconnects at regular basis [1], on Linux kernel 4.18. Unfortunately I can’t reproduce the issue on XPS 9380 at my hand. Is there already a fix in upstream kernel? I'm not aware of any fixes related to this. Is this a regression? In other words, is there a known version of ath10k or firmware which didn't have this problem? We know this issue happen on kernel v4.15 and v4.18, but kernels before v4.15 were not tested. The issue happens with Google Mesh, which has 802.11ac capability. I haven’t been able to reproduce the issue with an 802.11n router (yet). Do I need a special WiFi router which support RX reorder to reproduce the issue? It's introduced by commit c545070e404b (“ath10k: implement rx reorder support”). I don't understand your question at all. As far as I understand, the issue "failed to pop paddr list: -2” happens because ath10k_htt_rx_pop_paddr() fails to find skb in skb_table, hence trigger the warning. Those function are introduced by commit "ath10k: implement rx reorder support”. Since I’ve never seen such issue on my WiFi routers, while it happens to Stephan frequently, so I want to know if the “RX reorder support” is a feature that’s only supported by certain WiFi routers. Kai-Heng -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Ath10k on XPS 9380 regularly disconnects
Kai-Heng Feng writes: > at 23:43, Kai-Heng Feng wrote: > >> at 01:05, Kalle Valo wrote: >> >>> + ath10k list >>> - netdev & linux-kernel >>> >>> Kai-Heng Feng writes: >>> There’s an issue that ath10k disconnects at regular basis [1], on Linux kernel 4.18. Unfortunately I can’t reproduce the issue on XPS 9380 at my hand. Is there already a fix in upstream kernel? >>> >>> I'm not aware of any fixes related to this. Is this a regression? In >>> other words, is there a known version of ath10k or firmware which didn't >>> have this problem? >> >> We know this issue happen on kernel v4.15 and v4.18, but kernels >> before v4.15 were not tested. >> >> The issue happens with Google Mesh, which has 802.11ac capability. >> >> I haven’t been able to reproduce the issue with an 802.11n router (yet). > > Do I need a special WiFi router which support RX reorder to reproduce > the issue? > > It's introduced by commit c545070e404b (“ath10k: implement rx reorder > support”). I don't understand your question at all. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Ath10k on XPS 9380 regularly disconnects
Hi Kalle, at 23:43, Kai-Heng Feng wrote: at 01:05, Kalle Valo wrote: + ath10k list - netdev & linux-kernel Kai-Heng Feng writes: There’s an issue that ath10k disconnects at regular basis [1], on Linux kernel 4.18. Unfortunately I can’t reproduce the issue on XPS 9380 at my hand. Is there already a fix in upstream kernel? I'm not aware of any fixes related to this. Is this a regression? In other words, is there a known version of ath10k or firmware which didn't have this problem? We know this issue happen on kernel v4.15 and v4.18, but kernels before v4.15 were not tested. The issue happens with Google Mesh, which has 802.11ac capability. I haven’t been able to reproduce the issue with an 802.11n router (yet). Do I need a special WiFi router which support RX reorder to reproduce the issue? It's introduced by commit c545070e404b (“ath10k: implement rx reorder support”). Kai-Heng Kai-Heng [1] https://bugs.launchpad.net/bugs/1818881 Relevant information from dmesg: [ 19.346810] ath10k_pci :02:00.0: qca6174 hw3.2 target 0x0503 chip_id 0x00340aff sub 1a56:143a [ 19.346812] ath10k_pci :02:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 0 testmode 0 [ 19.347136] ath10k_pci :02:00.0: firmware ver WLAN.RM.4.4.1-00132-QCARMSWP-1 api 6 features wowlan,ignore-otp,mfp crc32 79f4db86 [...] [77451.338339] WARNING: CPU: 4 PID: 0 at /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/net/wireless/ath/ath10k/htt_rx.c:46 ath10k_htt_rx_pop_paddr.isra.29+0xd9/0xf0 [ath10k_core] [...] [81254.857667] WARNING: CPU: 1 PID: 0 at /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/net/wireless/ath/ath10k/htt_rx.c:46 ath10k_htt_rx_pop_paddr.isra.29+0xd9/0xf0 [ath10k_core] [...] [81390.186167] WARNING: CPU: 2 PID: 0 at /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/net/wireless/ath/ath10k/htt_rx.c:46 ath10k_htt_rx_pop_paddr.isra.29+0xd9/0xf0 [ath10k_core] -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
RE: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash
> -Original Message- > From: Michał Kazior > Sent: Monday, January 7, 2019 4:36 PM > To: Wen Gong > Cc: Wen Gong ; linux-wireless wirel...@vger.kernel.org>; ath10k@lists.infradead.org > Subject: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in > simulate fw crash > That's actually a feature, not a bug. If firmware crashes while driver > is restarting after a crash then its likely going to fail again and > again causing a crash-restart loop which can affect system performance > and responsiveness. It's better to give up and let the system admin > take over. > > If it's still bothering you then please consider a crash counter > threshold so that, e.g. after 5 crash-while-restarting it's going to > give up. However I doubt it's worth the effort. My experience tells me > firmware crashes during recovery are rarely, if at all, transient. > > The simulated fw crash is not representative here. It's a mere tool to > test driver code. > Hi Michal, There have a stress test case for the simulate fw crash, it will simulate fw crash in a very short time for each test, this will trigger the stress test fail. The simulate fw crash process should not be run parallel, after this patch, the Stress test case will pass. > > Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
