Re: odd msg using kvalo firmware-5.bin w/ KillerAC 1535(QCA6174)

[Mohammed Shafi Shajakhan (Mohammed Shafi)]

Hi,

my quick analysis suggests this belongs to
'WMI_TLV_GRP_STATS' 

WMI_TLV_STATS_EXT_EVENTID = WMI_TLV_EV(WMI_TLV_GRP_STATS), equals to 90112 
(0x16000)
WMI_TLV_IFACE_LINK_STATS_EVENTID, 90113
WMI_TLV_PEER_LINK_STATS_EVENTID, 90114
WMI_TLV_RADIO_LINK_STATS_EVENTID, 90015
  ?
WMI_TLV_NLO_MATCH_EVENTID = WMI_TLV_EV(WMI_TLV_GRP_NLO_OFL),

but this should be a harmless warning message indicating the host had not 
implemented
any action for this particular event.

For example in 10.2 wmi.c


   case WMI_10_2_GPIO_INPUT_EVENTID:
case WMI_10_2_PEER_RATECODE_LIST_EVENTID:
case WMI_10_2_GENERIC_BUFFER_EVENTID:
case WMI_10_2_MCAST_BUF_RELEASE_EVENTID:
case WMI_10_2_MCAST_LIST_AGEOUT_EVENTID:
case WMI_10_2_WDS_PEER_EVENTID:
ath10k_dbg(ar, ATH10K_DBG_WMI,
   "received event id %d not implemented\n", id);
break;



From: ath10k  on behalf of Michael Scott 

Sent: 20 April 2017 00:07
To: ath10k@lists.infradead.org
Cc: Kalle Valo
Subject: odd msg using kvalo firmware-5.bin w/ KillerAC 1535(QCA6174)

I am currently testing a QCA6174-based M.2/NGFF card (KillerAC 1535) w/
linux-next kernel.  When I use the firmware-5.bin from Kalle Valo's
github: https://github.com/kvalo/ath10k-firmware, I see the following
message occasionally in dmesg:
ath10k_pci :01:00.0: Unknown eventid: 90118

If I revert back to firmware-4.bin, that message goes away.

(Spoke with kvalo on IRC and passing this info along to the list)

- Mike

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath: Fix updating radar flags for coutry code India

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

As per latest regulatory update for India, channel 52, 56, 60, 64
is no longer restricted to DFS. Enabling DFS/no infra flags in driver
results in applying all DFS related restrictions (like doing CAC etc
before this channel moves to 'available state') for these channels
even though the country code is programmed as 'India' in he hardware,
fix this by relaxing the frequency range while applying RADAR flags
only if the country code is programmed to India. If the frequency range
needs to modified based on different country code, ath_is_radar_freq
can be extended/modified dynamically.

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/regd.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 43afa83..e25bfdf 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -254,8 +254,12 @@ bool ath_is_49ghz_allowed(u16 regdomain)
 EXPORT_SYMBOL(ath_is_49ghz_allowed);
 
 /* Frequency is one where radar detection is required */
-static bool ath_is_radar_freq(u16 center_freq)
+static bool ath_is_radar_freq(u16 center_freq,
+ struct ath_regulatory *reg)
+
 {
+   if (reg->country_code == CTRY_INDIA)
+   return (center_freq >= 5500 && center_freq <= 5700);
return (center_freq >= 5260 && center_freq <= 5700);
 }
 
@@ -306,7 +310,7 @@ static void ath_force_no_ir_freq(struct wiphy *wiphy, u16 
center_freq)
enum nl80211_reg_initiator initiator,
struct ieee80211_channel *ch)
 {
-   if (ath_is_radar_freq(ch->center_freq) ||
+   if (ath_is_radar_freq(ch->center_freq, reg) ||
(ch->flags & IEEE80211_CHAN_RADAR))
return;
 
@@ -395,8 +399,9 @@ static void ath_force_no_ir_freq(struct wiphy *wiphy, u16 
center_freq)
}
 }
 
-/* Always apply Radar/DFS rules on freq range 5260 MHz - 5700 MHz */
-static void ath_reg_apply_radar_flags(struct wiphy *wiphy)
+/* Always apply Radar/DFS rules on freq range 5500 MHz - 5700 MHz */
+static void ath_reg_apply_radar_flags(struct wiphy *wiphy,
+ struct ath_regulatory *reg)
 {
struct ieee80211_supported_band *sband;
struct ieee80211_channel *ch;
@@ -409,7 +414,7 @@ static void ath_reg_apply_radar_flags(struct wiphy *wiphy)
 
for (i = 0; i < sband->n_channels; i++) {
ch = >channels[i];
-   if (!ath_is_radar_freq(ch->center_freq))
+   if (!ath_is_radar_freq(ch->center_freq, reg))
continue;
/* We always enable radar detection/DFS on this
 * frequency range. Additionally we also apply on
@@ -506,7 +511,7 @@ void ath_reg_notifier_apply(struct wiphy *wiphy,
struct ath_common *common = container_of(reg, struct ath_common,
 regulatory);
/* We always apply this */
-   ath_reg_apply_radar_flags(wiphy);
+   ath_reg_apply_radar_flags(wiphy, reg);
 
/*
 * This would happen when we have sent a custom regulatory request
@@ -654,7 +659,7 @@ static u16 ath_regd_get_default_country(u16 rd)
}
 
wiphy_apply_custom_regulatory(wiphy, regd);
-   ath_reg_apply_radar_flags(wiphy);
+   ath_reg_apply_radar_flags(wiphy, reg);
ath_reg_apply_world_flags(wiphy, NL80211_REGDOM_SET_BY_DRIVER, reg);
return 0;
 }
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix spectral scan for QCA99X0 family of chipsets

[Mohammed Shafi Shajakhan (Mohammed Shafi)]

Hello Adrian,

For reference, would you mind pulling out what hte format of the edge
detection dword is?

[shafi] Sorry I did not dig into the DWORD carrying some radar related info,
as this gets discarded anyway for spectral processing. If you think the 
discarded
data is going to be useful in some way ??, let me get the dump for you. But feel
free to experiment with this patch !

This is anyway needed for fixing spectral scan ...

If you look into this patch more closely it just extends what Raja had fixed
long time back for QCA99X0 alone
https://patchwork.kernel.org/patch/7040681/

regards,
shafi


On 10 April 2017 at 07:26, Mohammed Shafi Shajakhan
<moham...@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
>
> spectral_bin length (number of bins per fft sample) is usually
> a value where (2^n = value), n is an integer.  All of the QCA99X0
> family of chipsets seems to report a spectral_bin length of
> 2^n + 'm' bytes, where m = 4, 12 based on the chipset. This 'm'
> bytes seems to carry some radar related info which is currenly
> discarded only for 'bin_len = 68' bytes. Extend this discarding of
> irrelevant 'bin_len' for QCA9984, QCA9888, IPQ4019 as well by
> introducing a hardware parameter 'spectral_bin_discard'. Also
> for QCA988X based family of chipsets which doesn't seem to have this
> issue and also for some of the hardware which I have not tested
> like QCA6174/QCA9377 the existing behaviour is retained as it is.
>
> Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> ---
>
>  drivers/net/wireless/ath/ath10k/core.c | 12 
>  drivers/net/wireless/ath/ath10k/hw.h   |  3 +++
>  drivers/net/wireless/ath/ath10k/spectral.c | 25 +
>  3 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 5736f79..b543c84 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -71,6 +71,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +   .spectral_bin_discard = 0,
> },
> {
> .id = QCA9887_HW_1_0_VERSION,
> @@ -91,6 +92,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +   .spectral_bin_discard = 0,
> },
> {
> .id = QCA6174_HW_2_1_VERSION,
> @@ -110,6 +112,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +   .spectral_bin_discard = 0,
> },
> {
> .id = QCA6174_HW_2_1_VERSION,
> @@ -129,6 +132,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +   .spectral_bin_discard = 0,
> },
> {
> .id = QCA6174_HW_3_0_VERSION,
> @@ -148,6 +152,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +   .spectral_bin_discard = 0,
> },
> {
> .id = QCA6174_HW_3_2_VERSION,
> @@ -168,6 +173,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +   .spectral_bin_discard = 0,
> },
> {
> .id = QCA99X0_HW_2_0_DEV_VERSION,
> @@ -193,6 +199,7 @@
> .sw_decrypt_mcast_mgmt = true,
> .hw_ops = _ops,
> .decap_align_bytes = 1,
> +   .spectral_bin_discard = 4,
> },
> {
> .id = QCA9984_HW_1_0_DEV_VERSION,
> @@ -219,6 +226,7 @@
> .sw_decrypt_mcast_mgmt = true,
> .hw_ops = _ops,
> .decap_align_bytes = 1,
> +   .spectral_bin_discard = 12,
> },
> {
> .id = QCA9888_HW_2_0_DEV_VERSION,
> @@ -244,6 +252,7 @@
> .sw_decrypt_mcast_mgmt = true,
> .hw_ops = _ops,
> .decap_align_bytes = 1,
> +   .spectral_bin_discard = 12,
> },
> {
> .id = QCA9377_HW_1_0_DEV_VERSION,
> @@ -263,6 +272,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +   .spectral_bin_discard = 0,
> },
> {
> .id = QCA9377_HW_1_1_DEV_VERSION,
> @@ -282,6 +292,7 @@
> },
> .hw_ops = _ops,
> .decap_align_bytes = 4,
> +

[PATCH v2] ath10k: Fix spectral scan for QCA99X0 family of chipsets

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

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

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v2: fixed spelling mistake in commit log]

 drivers/net/wireless/ath/ath10k/core.c |   12 
 drivers/net/wireless/ath/ath10k/hw.h   |3 +++
 drivers/net/wireless/ath/ath10k/spectral.c |   25 +
 3 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f450ebb..d023084 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -71,6 +71,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA9887_HW_1_0_VERSION,
@@ -91,6 +92,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -110,6 +112,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -129,6 +132,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_3_0_VERSION,
@@ -148,6 +152,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_3_2_VERSION,
@@ -170,6 +175,7 @@
.hw_clk = qca6174_clk,
.target_cpu_freq = 17600,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -195,6 +201,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 4,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -221,6 +228,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 12,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -246,6 +254,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 12,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -265,6 +274,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -286,6 +296,7 @@
.hw_clk = qca6174_clk,
.target_cpu_freq = 17600,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA4019_HW_1_0_DEV_VERSION,
@@ -312,6 +323,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 4,
},
 };
 
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index d370b57..6db2568 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -447,6 +447,9 @@ struct ath10k_hw_params {
/* hw specific clock control parameters */
const struct ath10k_hw_clk_params *hw_clk;
int target_cpu_freq;
+
+   /* Number of bytes to be discarded for each FFT sample */
+   int spectral_bin_discard;
 };
 
 struct htt_rx_desc;
diff --git a/drivers/net/wireless/ath/ath10k/spectral.c 
b/drivers/net/wireless/ath/ath10k/spectral.c
index c061d69..3fd5d7d 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -56,6 +56,21 @@ static uint8_t get_max_exp(s8 max_index, u16 max_magnitude, 
si

[PATCH] ath10k: Fix spectral scan for QCA99X0 family of chipsets

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

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

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---

 drivers/net/wireless/ath/ath10k/core.c | 12 
 drivers/net/wireless/ath/ath10k/hw.h   |  3 +++
 drivers/net/wireless/ath/ath10k/spectral.c | 25 +
 3 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 5736f79..b543c84 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -71,6 +71,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA9887_HW_1_0_VERSION,
@@ -91,6 +92,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -110,6 +112,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -129,6 +132,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_3_0_VERSION,
@@ -148,6 +152,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA6174_HW_3_2_VERSION,
@@ -168,6 +173,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -193,6 +199,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 4,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -219,6 +226,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 12,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -244,6 +252,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 12,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -263,6 +272,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -282,6 +292,7 @@
},
.hw_ops = _ops,
.decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
},
{
.id = QCA4019_HW_1_0_DEV_VERSION,
@@ -308,6 +319,7 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = _ops,
.decap_align_bytes = 1,
+   .spectral_bin_discard = 4,
},
 };
 
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index f0fda0f..8a0f9db 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -416,6 +416,9 @@ struct ath10k_hw_params {
 
/* Number of bytes used for alignment in rx_hdr_status of rx desc. */
int decap_align_bytes;
+
+   /* Number of bytes to be discarded for each FFT sample */
+   int spectral_bin_discard;
 };
 
 struct htt_rx_desc;
diff --git a/drivers/net/wireless/ath/ath10k/spectral.c 
b/drivers/net/wireless/ath/ath10k/spectral.c
index c061d69..3fd5d7d 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -56,6 +56,21 @@ static uint8_t get_max_exp(s8 max_index, u16 max_magnitude, 
size_t bin_len,
return max_exp;
 }
 
+static inline size_t ath10k_spectral_fix_bin_size(struc

[PATCH] ath10k: Fix compile time sanity check for CE4 buffer size

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

In 'ath10k_ce_alloc_pipe' the compile time sanity check to
ensure that there is sufficient buffers in CE4 for HTT Tx
MSDU descriptors, but this did not take into account of the
case with 'peer flow control' enabled, fix this.

Cc: Michal Kazior <michal.kaz...@tieto.com>
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[thanks to Michal for the suggestion]

 drivers/net/wireless/ath/ath10k/ce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index 9ac0a73..ee1090c 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1051,7 +1051,7 @@ int ath10k_ce_alloc_pipe(struct ath10k *ar, int ce_id,
 */
BUILD_BUG_ON(2 * TARGET_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
-   BUILD_BUG_ON(2 * TARGET_10X_NUM_MSDU_DESC >
+   BUILD_BUG_ON(2 * TARGET_10_4_NUM_MSDU_DESC_PFC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
BUILD_BUG_ON(2 * TARGET_TLV_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Remove obselete Copy Engine comments

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Remove obselete Copy Engine comments referring to the function
ath10k_ce_sendlist_send as this function was removed long time back
by the commit 2e761b5a5222 ("ath10k: remove ce_sendlist_send").

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/ce.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index 4045657..9ac0a73 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -261,8 +261,7 @@ static inline void ath10k_ce_engine_int_status_clear(struct 
ath10k *ar,
 }
 
 /*
- * Guts of ath10k_ce_send, used by both ath10k_ce_send and
- * ath10k_ce_sendlist_send.
+ * Guts of ath10k_ce_send.
  * The caller takes responsibility for any needed locking.
  */
 int ath10k_ce_send_nolock(struct ath10k_ce_pipe *ce_state,
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Enable a HTC debug message during insufficient tx credits

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Add an ath10k HTC debug message when insufficient tx credits
are available to send the WMI commands. This is very useful
in debugging issues like 'tx credit starvation' that could
possibly happen with multiclient setup with constant roaming

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
b/drivers/net/wireless/ath/ath10k/htc.c
index 9f6a915..f56f604 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -119,6 +119,9 @@ int ath10k_htc_send(struct ath10k_htc *htc,
credits = DIV_ROUND_UP(skb->len, htc->target_credit_size);
spin_lock_bh(>tx_lock);
if (ep->tx_credits < credits) {
+   ath10k_dbg(ar, ATH10K_DBG_HTC,
+  "htc insufficient credits ep %d required %d 
available %d\n",
+  eid, credits, ep->tx_credits);
spin_unlock_bh(>tx_lock);
ret = -EAGAIN;
goto err_pull;
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: cancel coverage class work during stop and restart

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

It seems set_coverage_class_work is not cancelled anywhere,
though I could not find a crash/warning  with this existing
design, its safer to cancel it during stop() and also before
restarting the hardware.

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[comments updated, thanks Kalle]

 drivers/net/wireless/ath/ath10k/core.c | 7 +++
 drivers/net/wireless/ath/ath10k/mac.c  | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index ba8768d..e653717 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1610,6 +1610,13 @@ static void ath10k_core_restart(struct work_struct *work)
wake_up(>wmi.tx_credits_wq);
wake_up(>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(>set_coverage_class_work);
+
mutex_lock(>conf_mutex);
 
switch (ar->state) {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 3029f25..6470ed3 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4684,6 +4684,7 @@ static void ath10k_stop(struct ieee80211_hw *hw)
}
mutex_unlock(>conf_mutex);
 
+   cancel_work_sync(>set_coverage_class_work);
cancel_delayed_work_sync(>scan.timeout);
cancel_work_sync(>restart_work);
 }
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Fix NAPI enable/disable symmetry for AHB interface

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Move NAPI enable to 'ath10k_ahb_hif_start' from
'ath10k_ahb_hif_power_up'. This is to maintain the symmetry
of calling napi_enable() from ath10k_ahb_hif_start() so that it
matches with  napi_disable() being called from ath10k_pci_hif_stop().

This change is based on the crash fix from Kalle for PCI interface in
commit 1427228d5869 ("ath10k: fix napi crash during rmmod when probe
firmware fails").

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/ahb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/ahb.c 
b/drivers/net/wireless/ath/ath10k/ahb.c
index 45226db..da770af 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -640,6 +640,7 @@ static int ath10k_ahb_hif_start(struct ath10k *ar)
 {
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot ahb hif start\n");
 
+   napi_enable(>napi);
ath10k_ce_enable_interrupts(ar);
ath10k_pci_enable_legacy_irq(ar);
 
@@ -692,7 +693,6 @@ static int ath10k_ahb_hif_power_up(struct ath10k *ar)
ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
goto err_ce_deinit;
}
-   napi_enable(>napi);
 
return 0;
 
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k - spectral scan - and - channel change

[Mohammed Shafi Shajakhan]

On Wed, Mar 15, 2017 at 11:14:19AM +, Will Kerr wrote:
> > [shafi] hmmm interesting .. looks like you need to bring the interface up,
> > before doing this, the WMI command may respond error
> 
> I thought it was, at least now when I try:
> 
> AP mode:
> (its OK)
> 
> Monitor Mode:
> root@OpenWrt:~# ifconfig wlan0 up
> root@OpenWrt:~# echo disable > 
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> ash: write error: No such device

[shafi] may sound dumb (need to check), first cd to 
cd /sys/kernel/debug/ieee80211/phy0/ath10k
echo disable > spectral_scan_ctl

> 
> 
> 
> > iw phy0 info
> * 5560 MHz [112] (24.0 dBm) (no IR, radar detection)
> DFS state: usable (for 4036 sec)
> 
> 
> 
> > shafi] just check 'ap-force' is supported (or) not
> 
> I dont think it is supported on my ArcherC7 openWRT for some reason:
> AP mode: 
> root@OpenWrt:~# ifconfig wlan0 up
> root@OpenWrt:~# iw  wlan0 scan
> command failed: Device or resource busy (-16)
> root@OpenWrt:~# iw  wlan0 scan ap-force
> command failed: Device or resource busy (-16)
> 
> Monitor Mode:
> root@OpenWrt:~# ifconfig wlan0 up
> root@OpenWrt:~# iw  wlan0 scan
> command failed: Operation not supported (-122)
> root@OpenWrt:~# iw  wlan0 scan ap-force
> command failed: Operation not supported (-122)
>

[shafi] good to see if you have latest hostapd and ath10k backports

> 
> > [shafi] i have not tried in monitor i can give a try some time ..
> That would be great, if you could confirm my problem.. e.g. in Monitor Mode:
> 
> root@OpenWrt:~# ifconfig wlan0 up
> root@OpenWrt:~# echo background > 
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> ash: write error: No such device
> root@OpenWrt:~# echo trigger > 
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> ash: write error: Invalid argument
> root@OpenWrt:~# cat  /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> disableroot@OpenWrt:~#
> 
> 
> 
> > you can fine tune the below script ...
> I ran it, and it fails on the iw wlan0 scan ap-force part ...
> (...)
> + iw dev wlan0 scan ap-force
> command failed: Device or resource busy (-16)
> (...)
> 
> 
> 
> 
> 
> The reason I am trying to do both (control spectral_scan_ctl and change 
> channels) is because it works fine in ath9k monitor mode..
> 
>

[shafi] ok, we can check that , i think for ath9k the complete support is in
driver (no firmware)
> 
> 
> - Original Message -
> From: Mohammed Shafi Shajakhan <moham...@codeaurora.org>
> To: Will Kerr <willjk...@yahoo.co.uk>
> Cc: "ath10k@lists.infradead.org" <ath10k@lists.infradead.org>; Shajakhan 
> Mohammed Shafi (Mohammed Shafi) <moham...@qti.qualcomm.com>
> Sent: Tuesday, 14 March 2017, 16:23
> Subject: Re: ath10k - spectral scan - and - channel change
> 
> > Thank you for looking into this.. I'm really sorry for the confusion, my 
> > second email reversed what the problem really is. Now clarified **below**:
> > 
> > Is it possible to control spectral_scan_ctl whilst in **Monitor mode**?
> > my result:
> > 
> > root at OpenWrt:~# echo disable > 
> > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> > ash: write error: No such device
> 
> [shafi] hmmm interesting .. looks like you need to bring the interface up,
> before doing this, the WMI command may respond error
> 
> > 
> > or 
> > 
> > change channel whilst in **AP mode**?
> > my result:
> > 
> > root at OpenWrt:~# iw dev wlan0 set channel 112
> > command failed: Device or resource busy (-16)
> 
> [shafi] again you need to bring the interface up and also check if this 
> channel
> is not disabled 
> 
> iw phy0 info
> 
> > 
> > 
> > 
> > and to your questions:
> > (1)
> > following  
> > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral - yes, I 
> > am able to obtain the spectral_scan0 data OK whilst in AP mode (although I 
> > was not able to do root@OpenWrt:~# iw dev wlan0 scan .. command failed: 
> > Device or resource busy (-16), I dont know why, I was still able to get 
> > scan data OK)
> 
> [shafi] just check 'ap-force' is supported (or) not
> 
> > 
> > (2)
> > I get the same result for the below 3 commands if its set to AP mode, 
> > Monitor mode, or off (according to the setup in openWRT). I'm sorry, I dont 
> > know if there are more commands I should try to confirm things..
> 
> 
> [shafi] i have not tried in monitor i can give a try some time ..
> you can fine tune the below script ...
> before sending spectr

Re: ath10k - spectral scan - and - channel change

[Mohammed Shafi Shajakhan]

> Thank you for looking into this.. I'm really sorry for the confusion, my 
> second email reversed what the problem really is. Now clarified **below**:
> 
> Is it possible to control spectral_scan_ctl whilst in **Monitor mode**?
> my result:
> 
> root at OpenWrt:~# echo disable > 
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> ash: write error: No such device

[shafi] hmmm interesting .. looks like you need to bring the interface up,
before doing this, the WMI command may respond error

> 
> or 
> 
> change channel whilst in **AP mode**?
> my result:
> 
> root at OpenWrt:~# iw dev wlan0 set channel 112
> command failed: Device or resource busy (-16)

[shafi] again you need to bring the interface up and also check if this channel
is not disabled 

iw phy0 info

> 
> 
> 
> and to your questions:
> (1)
> following  https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral 
> - yes, I am able to obtain the spectral_scan0 data OK whilst in AP mode 
> (although I was not able to do root@OpenWrt:~# iw dev wlan0 scan .. command 
> failed: Device or resource busy (-16), I dont know why, I was still able to 
> get scan data OK)

[shafi] just check 'ap-force' is supported (or) not

> 
> (2)
> I get the same result for the below 3 commands if its set to AP mode, Monitor 
> mode, or off (according to the setup in openWRT). I'm sorry, I dont know if 
> there are more commands I should try to confirm things..


[shafi] i have not tried in monitor i can give a try some time ..
you can fine tune the below script ...
before sending spectral commands

1. make sure the interface is up
2. the channel is properly set
3. the mode is properly set
4. in AP mode 'ap-force' scan option is used ..


set -x

echo 0x2 > /sys/module/ath10k_core/parameters/debug_mask
dmesg -n8

echo "=="
echo "Dumping existing spectral scan data"
sleep 1

cat /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_scan_ctl
cat /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_bins
cat /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_count

sleep 3


spectral_bin=$1
spectral_count=$2
ifconfig wlan1 up
sleep 2
echo $spectral_bin > /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_bins
echo $spectral_count > /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_count
echo manual > /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_scan_ctl
echo trigger > /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_scan_ctl
iw dev wlan1 scan ap-force
sleep 1
cp /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_scan0
/tmp/sample-$spectral_bin.fft
echo disable > /sys/kernel/debug/ieee80211/phy1/ath10k/spectral_scan_ctl

sleep 2
ls -lart /tmp/sample**
set +x



> 
> root@OpenWrt:~# iw phy0 info
> Wiphy phy0
> max # scan SSIDs: 16
> max scan IEs length: 199 bytes
> Retry short limit: 7
> Retry long limit: 4
> Coverage class: 0 (up to 0m)
> Device supports AP-side u-APSD.
> Available Antennas: TX 0x7 RX 0x7
> Configured Antennas: TX 0x7 RX 0x7
> Supported interface modes:
> * managed
> * AP
> * AP/VLAN
> * monitor
> ...
> ...
> ...
> (plus more, that I removed )
> 
> root@OpenWrt:~# dmesg | grep phy0
> root@OpenWrt:~#
> 
> root@OpenWrt:~# ls /sys/kernel/debug/ieee80211/phy0/ath10k/spectral*
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_bins
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_count
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> 
> 
> Thank you, Will
> 
> 
> 
> 
> 
> 
> - Forwarded Message -
> From: "Shajakhan, Mohammed Shafi (Mohammed Shafi)" 
> To: "ath10k@lists.infradead.org" ; Will Kerr 
> 
> Sent: Monday, 6 March 2017, 18:15
> Subject: Re: ath10k - spectral scan - and - channel change
> 
> please follow
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral
> 
> please check if phy0 does exists ?
> 
> From: ath10k  on behalf of Will Kerr 
> 
> Sent: 06 March 2017 22:27
> To: ath10k@lists.infradead.org
> Subject: Re: ath10k - spectral scan - and - channel change
> 
> pinging and compacting the Q just in case the experts have an idea on this..
> 
> 
> Is it possible to control spectral_scan_ctl whilst in AP mode?
> my result:
> 
> root@OpenWrt:~# echo disable > 
> /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> ash: write error: No such device
> 
> or
> 
> 
> change channel whilst in Monitor mode?
> my result:
> 
> root@OpenWrt:~# iw dev wlan0 set channel 112
> command failed: Device or resource busy (-16)
> 
> Thanks Will.
> 
> 
> 
> 
> 
> 
> From: Will Kerr 
> To: "ath10k@lists.infradead.org" 
> Sent: Friday, 24 February 2017, 6:49
> Subject: ath10k - spectral scan - and - channel change
> 
> 
> Hello, I searched the mail archives but couldn't 

[PATCH] ath10k: Fix typo in wmi header file

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Fix typo(spelling mistake) in wmi.h

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 386aa51..ddbd541 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3182,7 +3182,7 @@ struct wmi_10_4_phyerr_event {
 
 struct phyerr_radar_report {
__le32 reg0; /* RADAR_REPORT_REG0_* */
-   __le32 reg1; /* REDAR_REPORT_REG1_* */
+   __le32 reg1; /* RADAR_REPORT_REG1_* */
 } __packed;
 
 #define RADAR_REPORT_REG0_PULSE_IS_CHIRP_MASK  0x8000
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Fix fetching channel during potential radar detection

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Fetch target operating channel during potential radar detection when
the interface is just brought up, but no channel is assigned from
userspace. In this scenario rx_channel may not be having a valid pointer
hence fetch the target operating channel to avoid warnings as below
which can be triggered by the commands with DFS testing over longer run

comamnds:
iw wlan1 set type mesh
ifconfig wlan1 up (valid tgt_oper_chan only)
iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan)
iw wlan1 cac trigger freq 5280 HT20
iw wlan1 cac trigger freq 5300 HT20

Once the CAC expires, current channel context will be removed and
we are only left with the fallback option of using 'target operating
channel'

Firmware and driver log:
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
count_false=4
ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6,
count_false=11
ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6,
count_false=4
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
count_false=4
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
treating as radar
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
treating as radar

Call trace:

WARNING: CPU: 1 PID: 2145 at
backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265
cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]()

 Workqueue: phy1 ieee80211_dfs_radar_detected_work
[mac80211]
[] (warn_slowpath_null) from []
(cfg80211_set_dfs_state+0x3c/0x88 [cfg80211])
[] (cfg80211_set_dfs_state [cfg80211]) from
[] (cfg80211_radar_event+0xc4/0x140 [cfg80211])
[] (cfg80211_radar_event [cfg80211]) from
[] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211])
[] (ieee80211_dfs_radar_detected_work
[mac80211]) from [] (process_one_work+0x298/0x4a4)

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2f1743e..1f83276 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3643,6 +3643,11 @@ static void ath10k_dfs_radar_report(struct ath10k *ar,
 
spin_lock_bh(>data_lock);
ch = ar->rx_channel;
+
+   /* fetch target operating channel during channel change */
+   if (!ch)
+   ch = ar->tgt_oper_chan;
+
spin_unlock_bh(>data_lock);
 
if (!ch) {
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k QCA988x firmware not supporting monitor mode

[Mohammed Shafi Shajakhan]

On Wed, Mar 01, 2017 at 10:38:48AM +0530, KAVITA MATHUR wrote:
> 
> 
> Hi!
> 
> We are using Atheros QCA9880 mPCIe module with ath10k drivers and firmware.
> 
> Kernel: 3.12
> Backports: 4.4
> Firmware:10.2.4.70.59-2

[shafi] worth trying updated firmware
https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA988X/hw2.0/

> 
> We are not able to run the wlan1 interface in monitor mode. The following 
> error comes
> when we do
> iw phy phy1 interface add wlan1 type monitor
> ifconfig wlan1 up

[shafi] can you please confirm the below fix is already available
(its cced to stable though)
https://patchwork.kernel.org/patch/8481281/

and if you see still see the issue in latest backports
http://buildbot.w1.fi/backports-wireless-testing/

please revert back

> 
> ath10k_pci 0001:03:00.0: firmware crashed! (uuid n/a)
> ath10k_pci 0001:03:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff sub :) 
> fw
> 10.2.4.70.59-2 fwapi 5 bdapi 1 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 
> 128 raw 0
> hwcrypto 1 features no-p2p,raw-mode
> ath10k_pci 0001:03:00.0: debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
> ath10k_pci 0001:03:00.0: firmware register dump:
> ath10k_pci 0001:03:00.0: [00]: 0x4100016C 0x 0x0097F8D5 0x
> ath10k_pci 0001:03:00.0: [04]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [08]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [12]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [16]: 0x 0x 0x 0x0097F8D5
> ath10k_pci 0001:03:00.0: [20]: 0x 0x00401930 0x 0x
> ath10k_pci 0001:03:00.0: [24]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [28]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [32]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [36]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [40]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [44]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [48]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [52]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: [56]: 0x 0x 0x 0x
> ath10k_pci 0001:03:00.0: failed to set 2g txpower 0: -108
> ath10k_pci 0001:03:00.0: failed to setup tx power 0: -108
> ath10k_pci 0001:03:00.0: failed to recalc tx power: -108
> [ cut here ]
> WARNING: at fb83c3b8 [verbose debug info unavailable]
> Modules linked in: ath10k_pci(O) ath10k_core(O) mac80211(O) ath(O) 
> cfg80211(O) compat(O)
> uio_pdrv_genirq
> CPU: 0 PID: 17173 Comm: ifconfig Tainted: G   O 3.12.37-rt51+ #23
> task: e6415500 ti: ef02a000 task.ti: ef02a000
> NIP: fb83c3b8 LR: fb83c3a8 CTR: c00788f0
> REGS: ef02bcb0 TRAP: 0700   Tainted: G   O  (3.12.37-rt51+)
> MSR: 00029002   CR: 84008482  XER: 2000
> 
> GPR00: fb83c3a8 ef02bd60 e6415500 ff94 eb865a40 0152  
> GPR08:  0001  00021002 84ad2e42 10025578 1010 
> GPR16:  1000acb4 1001d264 1001d264 1001d1f8 ef98200c  e0e44000
> GPR24: e0e44480  0001  e0e44704 e0e4 ff94 ef7ccba0
> NIP [fb83c3b8] ieee80211_add_virtual_monitor+0xd8/0x1c0 [mac80211]
> LR [fb83c3a8] ieee80211_add_virtual_monitor+0xc8/0x1c0 [mac80211]
> Call Trace:
> [ef02bd60] [fb83c3a8] ieee80211_add_virtual_monitor+0xc8/0x1c0 [mac80211] 
> (unreliable)
> [ef02bd80] [fb83d168] ieee80211_do_open+0x4e8/0xa30 [mac80211]
> [ef02bdc0] [c04d73a8] __dev_open+0xe8/0x160
> [ef02bdf0] [c04d76a0] __dev_change_flags+0xa0/0x180
> [ef02be10] [c04d785c] dev_change_flags+0x1c/0x70
> [ef02be30] [c057d930] devinet_ioctl+0x600/0x8e0
> [ef02be90] [c04ba6f4] sock_ioctl+0x224/0x2e0
> [ef02beb0] [c0115150] do_vfs_ioctl+0x410/0x7a0
> [ef02bf10] [c0115520] SyS_ioctl+0x40/0x80
> [ef02bf40] [c000fb04] ret_from_syscall+0x0/0x3c
> --- Exception: c01 at 0xff4ff8c
> LR = 0xffed2c0
> Instruction dump:
> 3928 913d038c 7fa3eb78 93dd000c 4bffe349 7fe3fb78 7fa4eb78 4bfee2cd
> 7c690034 5529d97e 7c7e1b78 69290001 <0f09> 2f89 7fa3eb78 40de00a0
> ---[ end trace c9df4859ac192be7 ]---
> ieee80211 phy1: Hardware restart was requested
> SIOCSIFFLAGS: Cannot send after transport endpoint shutdown
> 
> Please help me to set monitor mode on WiFi node.
> 
> Disclaimer:
> 
> --
> 
> This email and any files transmitted with it are confidential and intended 
> solely for
> 
> the use of the individual or entity to whom they are addressed.  If you are 
> not the
> 
> intended recipient you are notified that disclosing, copying, distributing or 
> taking
> 
> any action in reliance on the contents of this information is strictly 
> prohibited. The
> 
> sender does not accept liability for any errors or omissions in the contents 
> of this
> 
> message, 

Re: Recent driver changes destabilized QCA9377 connection quality

[Mohammed Shafi Shajakhan]

Hi,

On Sun, Feb 26, 2017 at 04:40:42PM +0100, Tobias Predel wrote:
> Hello,
> 
> as I still encounter some stability issues with my beloved QCA9377 chipset on 
> Linux, I decided to recompile the ath10k kernel module according to [1] in 
> order to enable debugging and tracing (see [2]) instead of bisecting the 
> commits because I don't have the ressource to do that in sufficient time.

[shafi] good to mention the stability issues in more details

also good to play around with backports as well

http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ (if you want to
try between stable releases)
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/backports
http://buildbot.w1.fi/backports-wireless-testing/ (latest)

> 
> Boundary conditions (additional information is provided below):
> 
> - Kernel version: 4.9.11
> - Firmware files from https://github.com/kvalo/ath10k-firmware (the untested 
> one just cause a firmware crash so I guess that one is for another type) 
> 
> My kernel ring puffer is flooded with two interesting types of messages and 
> that is why I wanted to ask if these indicate "normal" behaviour or not.
> 
> (1) PCI related messages to and fro all over the time
> 
> [  872.134559] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.134572] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> [  872.134585] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.134598] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> [  872.134614] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.134629] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> [  872.134645] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.134657] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> [  872.134670] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.195874] ath10k_pci :02:00.0: pci ps timer refcount 0 awake 1
> [  872.195891] ath10k_pci :02:00.0: pci ps sleep reg refcount 0 awake 1
> [  872.337625] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 0
> [  872.337644] ath10k_pci :02:00.0: pci ps wake reg refcount 0 awake 0
> [  872.337707] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.337727] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> [  872.337739] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.337749] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> [  872.337758] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.337768] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> [  872.337781] ath10k_pci :02:00.0: pci ps sleep refcount 1 awake 1
> [  872.337791] ath10k_pci :02:00.0: pci ps wake refcount 0 awake 1
> ...

[shafi] if you suspect PCI PS, you can try to disable it
ath10k: disable PCI PS for QCA988X and QCA99X0
https://patchwork.kernel.org/patch/7277361/

but if this helps, its not a regression

> 
> (2) Many FCS (frame check sequence) errors paired with "len 0"?
> 
> [  872.338194] ath10k_pci :02:00.0: rx skb 88003765ec00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1470 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  872.952364] ath10k_pci :02:00.0: rx skb 880011356400 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1476 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  873.259564] ath10k_pci :02:00.0: rx skb 88001ce2fd00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1479 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  874.181195] ath10k_pci :02:00.0: rx skb 88004b26be00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1488 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  874.488037] ath10k_pci :02:00.0: rx skb 88004b26bb00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1491 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  874.795505] ath10k_pci :02:00.0: rx skb 880037856e00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1496 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> ...

[shafi] These logs will flood your console, make sure the flooding of the same
does not causes more issues, i would first recommend to enable fewer debug lots
at first and then increment it progressively

> 
> (3) Some probably (?) ordinary messages in minority like
> [  873.566518] ath10k_pci :02:00.0: pci rx ce pipe 5 len 60
> [  873.566529] ath10k_pci :02:00.0: htt rx, msg_type: 0x1
> ...
> 
> I would really appreciate if someone could just confirm whether the debug 
> messages hint to firmware/driver issues or not. Thanks for your help!
> 
> Some additional information:
> 
> - iwconfig wlp2s0 power off/off doesn't change a lot, the same messages from 
> above keep appearing
> 
> - 

[PATCH] ath10k: Disallow DFS simulation if DFS channel is not enabled

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall
not be available for use even though the hardware may have the capability
to support DFS. With this configuration (DFS disabled in hostapd) trying to
bring up ath10k device in DFS channel for AP mode fails and trying to
simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining
invalid channel and this should be avoided in the driver itself rather than
false propogating RADAR detection to mac80211/cfg80211. Fix this by
checking for the first vif 'is_started' state(should work for client mode
as well) as all the vifs shall be configured for the same channel

sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar

WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60
Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[] (warn_slowpath_null) from
[] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[] (cfg80211_radar_event [cfg80211]) from
[] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[] (ieee80211_dfs_radar_detected_work [mac80211]) from
[] (process_one_work+0x20c/0x32c)

WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc
 Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[] (warn_slowpath_null) from
[] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[] (cfg80211_radar_event [cfg80211]) from
[] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[] (ieee80211_dfs_radar_detected_work [mac80211]) from
[] (process_one_work+0x20c/0x32c)

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[thanks Kalle, Jouni and Tamizh for the first level review]

 drivers/net/wireless/ath/ath10k/debug.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index fb0ade3..ac9090b 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1997,6 +1997,15 @@ static ssize_t ath10k_write_simulate_radar(struct file 
*file,
   size_t count, loff_t *ppos)
 {
struct ath10k *ar = file->private_data;
+   struct ath10k_vif *arvif;
+
+   /* Just check for for the first vif alone, as all the vifs will be
+* sharing the same channel and if the channel is disabled, all the
+* vifs will share the same 'is_started' state.
+*/
+   arvif = list_first_entry(>arvifs, typeof(*arvif), list);
+   if (!arvif->is_started)
+   return -EINVAL;
 
ieee80211_radar_detected(ar->hw);
 
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2] ath10k: Fix a warning during channel switch with multiple vaps

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Doing a channel switch via hostapd_cli seems to update
the new channel context for each VAP's appropriately as below
in 'ath10k_mac_update_vif_chan', hence we can safely suppress the
warning that shows up during this operation and dump the warning only
if no vaps are available for channel switch

hostapd_cli -i wlan0 chan_switch 5 5200
OK

ath10k_pci : mac chanctx switch n_vifs 3 mode 1
ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0

Call Trace:

WARNING: 
backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126
[] (warn_slowpath_null) from []
(ath10k_reconfig_complete+0xe4/0x25c [ath10k_core])
[] (ath10k_reconfig_complete [ath10k_core])
[] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core])
[] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core])
[] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211])
[] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211])
[] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211])
[] (ieee80211_vif_use_reserved_context [mac80211])
[] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211])

Fixes: d7bf4b4aba05 ("ath10k: fix ar->rx_channel updating logic")
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d1b7edb..b416958 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7085,7 +7085,7 @@ static int ath10k_ampdu_action(struct ieee80211_hw *hw,
lockdep_assert_held(>data_lock);
 
WARN_ON(ctx && vifs);
-   WARN_ON(vifs && n_vifs != 1);
+   WARN_ON(vifs && !n_vifs);
 
/* FIXME: Sort of an optimization and a workaround. Peers and vifs are
 * on a linked list now. Doing a lookup peer -> vif -> chanctx for each
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Fix a warning during channel switch with multiple vaps

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Doing a channel switch via hostapd_cli seems to update
the new channel context for each VAP's appropriately as below
in 'ath10k_mac_update_vif_chan', hence we can safely suppress the
warning that shows up during this operation and dump the warning only
if no vaps are available for channel switch

hostapd_cli -i wlan0 chan_switch 5 5200
OK

ath10k_pci : mac chanctx switch n_vifs 3 mode 1
ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0

Call Trace:

WARNING: 
backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126
[] (warn_slowpath_null) from []
(ath10k_reconfig_complete+0xe4/0x25c [ath10k_core])
[] (ath10k_reconfig_complete [ath10k_core])
[] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core])
[] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core])
[] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211])
[] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211])
[] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211])
[] (ieee80211_vif_use_reserved_context [mac80211])
[] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211])

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d1b7edb..b416958 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7085,7 +7085,7 @@ static int ath10k_ampdu_action(struct ieee80211_hw *hw,
lockdep_assert_held(>data_lock);
 
WARN_ON(ctx && vifs);
-   WARN_ON(vifs && n_vifs != 1);
+   WARN_ON(vifs && !n_vifs);
 
/* FIXME: Sort of an optimization and a workaround. Peers and vifs are
 * on a linked list now. Doing a lookup peer -> vif -> chanctx for each
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

[Mohammed Shafi Shajakhan]

Hi Kalle,

the change suggested by you helps, and the device probe, scan
is successful as well. Still good to have this change part of your
basic sanity and regression testing !

regards,
shafi

On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote:
> Kalle Valo <kv...@qca.qualcomm.com> writes:
> 
> > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes:
> >
> >> From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >>
> >> This fixes the below crash when ath10k probe firmware fails,
> >> NAPI polling tries to access a rx ring resource which was never
> >> allocated, fix this by disabling NAPI right away once the probe
> >> firmware fails by calling 'ath10k_hif_stop'. Its good to note
> >> that the error is never propogated to 'ath10k_pci_probe' when
> >> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
> >> PCI related things seems to be ok
> >>
> >> BUG: unable to handle kernel NULL pointer dereference at (null)
> >> IP:  __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >>
> >> Call Trace:
> >>
> >> [] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
> >> [ath10k_core]
> >> [] ath10k_htt_txrx_compl_task+0x433/0x17d0
> >> [ath10k_core]
> >> [] ? __wake_up_common+0x4d/0x80
> >> [] ? cpu_load_update+0xdc/0x150
> >> [] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
> >> [] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
> >> [] net_rx_action+0x20f/0x370
> >>
> >> Reported-by: Ben Greear <gree...@candelatech.com>
> >> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> >> Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> > Is there an easy way to reproduce this bug? I don't see it on my x86
> > laptop with qca988x and I call rmmod all the time. I would like to test
> > this myself.
> >
> >> --- a/drivers/net/wireless/ath/ath10k/core.c
> >> +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
> >>ath10k_core_free_firmware_files(ar);
> >>  
> >>  err_power_down:
> >> +  ath10k_hif_stop(ar);
> >>ath10k_hif_power_down(ar);
> >>  
> >>return ret;
> >
> > This breaks the symmetry, we should not be calling ath10k_hif_stop() if
> > we haven't called ath10k_hif_start() from the same function. This can
> > just create a bigger mess later, for example with other bus support like
> > sdio or usb. In theory it should enough that we call
> > ath10k_hif_power_down() and pci.c does the rest correctly "behind the
> > scenes".
> >
> > I investigated this a bit and I think the real cause is that we call
> > napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
> > ath10k_pci_hif_stop(). Does anyone remember why?
> >
> > I was expecting that we would call napi_enable()/napi_disable() either
> > in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
> > mixed like it's currently.
> 
> So below is something I was thinking of, now napi_enable() is called
> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
> that work?
> 
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>  
>   ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>  
> + napi_enable(>napi);
> +
>   ath10k_pci_irq_enable(ar);
>   ath10k_pci_rx_post(ar);
>  
> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>   ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
>   goto err_ce;
>   }
> - napi_enable(>napi);
>  
>   return 0;
> 
> -- 
> Kalle Valo

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

[Mohammed Shafi Shajakhan]

Hi Kalle,

sorry for the delay

On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote:
> Kalle Valo <kv...@qca.qualcomm.com> writes:
> 
> > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes:
> >
> >> From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >>
> >> This fixes the below crash when ath10k probe firmware fails,
> >> NAPI polling tries to access a rx ring resource which was never
> >> allocated, fix this by disabling NAPI right away once the probe
> >> firmware fails by calling 'ath10k_hif_stop'. Its good to note
> >> that the error is never propogated to 'ath10k_pci_probe' when
> >> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
> >> PCI related things seems to be ok
> >>
> >> BUG: unable to handle kernel NULL pointer dereference at (null)
> >> IP:  __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >>
> >> Call Trace:
> >>
> >> [] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
> >> [ath10k_core]
> >> [] ath10k_htt_txrx_compl_task+0x433/0x17d0
> >> [ath10k_core]
> >> [] ? __wake_up_common+0x4d/0x80
> >> [] ? cpu_load_update+0xdc/0x150
> >> [] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
> >> [] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
> >> [] net_rx_action+0x20f/0x370
> >>
> >> Reported-by: Ben Greear <gree...@candelatech.com>
> >> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> >> Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> > Is there an easy way to reproduce this bug? I don't see it on my x86
> > laptop with qca988x and I call rmmod all the time. I would like to test
> > this myself.
> >
> >> --- a/drivers/net/wireless/ath/ath10k/core.c
> >> +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
> >>ath10k_core_free_firmware_files(ar);
> >>  
> >>  err_power_down:
> >> +  ath10k_hif_stop(ar);
> >>ath10k_hif_power_down(ar);
> >>  
> >>return ret;
> >
> > This breaks the symmetry, we should not be calling ath10k_hif_stop() if
> > we haven't called ath10k_hif_start() from the same function. This can
> > just create a bigger mess later, for example with other bus support like
> > sdio or usb. In theory it should enough that we call
> > ath10k_hif_power_down() and pci.c does the rest correctly "behind the
> > scenes".
> >
> > I investigated this a bit and I think the real cause is that we call
> > napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
> > ath10k_pci_hif_stop(). Does anyone remember why?
> >
> > I was expecting that we would call napi_enable()/napi_disable() either
> > in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
> > mixed like it's currently.
> 
> So below is something I was thinking of, now napi_enable() is called
> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
> that work?
> 
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>  
>   ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>  
> + napi_enable(>napi);
> +
>   ath10k_pci_irq_enable(ar);
>   ath10k_pci_rx_post(ar);
>  
> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>   ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
>   goto err_ce;
>   }
> - napi_enable(>napi);
>  
>   return 0;
>

[shafi] I think I tried this change some time back, but it had some regression
during device start up, let me check this once and get back to you.

regards,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Fix per station tx bit rate reporting

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Not clearing the previous tx bit rate status
results in a ambigous tx bit rate reporting to
mac80211/cfg80211, for example the previous bit
rate status would have been marked as legacy rate
, while the current rate would have been an HT/VHT
rate with the tx bit rate flags set and this results
in exporting tx bitrate as legacy rate but with HT/VHT
rate flags set, fix this by clearing the tx bitrate
status for each event. This also fixes the below
warning when we do:

iw dev wlan#N station dump

WARNING: net/wireless/util.c:1222 cfg80211

[] (warn_slowpath_null) from []
(cfg80211_calculate_bitrate+0x110/0x1f4 [cfg80211])
[] (cfg80211_calculate_bitrate [cfg80211]) from
[] (nl80211_put_sta_rate+0x44/0x1dc [cfg80211])
[] (nl80211_put_sta_rate [cfg80211]) from
[] (nl80211_set_interface+0x724/0xd70 [cfg80211])
[] (nl80211_set_interface [cfg80211]) from
[] (nl80211_dump_station+0xdc/0x100 [cfg80211])
[] (nl80211_dump_station [cfg80211])

Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0bc7fe8..74b66e5 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2231,6 +2231,8 @@ static inline bool is_valid_legacy_rate(u8 rate)
return;
}
 
+   memset(>txrate, 0, sizeof(arsta->txrate));
+
if (txrate.flags == WMI_RATE_PREAMBLE_CCK ||
txrate.flags == WMI_RATE_PREAMBLE_OFDM) {
rate = ATH10K_HW_LEGACY_RATE(peer_stats->ratecode);
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 firmware crash

[Mohammed Shafi Shajakhan]

On Tue, Jan 10, 2017 at 08:54:34PM +0500, Sergey Stepanov wrote:
> Hello, all
> 
> Thanks for helping, finally I got this thing working.

[shafi] It would be good if you let us know what did you fix to make this
working ? Is the one suggested by Adrian ?

> 
> 2017-01-10 20:44 GMT+05:00 Adrian Chadd :
> > hiya,
> >
> > Have you pushed the channel list into the firmware? You (a) nede to
> > push a channel list early on, way before you create vdevs, and (b) it
> > needs to match the band (2g, 5g, 2g/5g) that the firmware expects.
> > pushing 2g channels to a 5g band causes the firmware to panic upon
> > vdev create/up.
> >
> >
> >
> > -adrian

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 firmware crash

[Mohammed Shafi Shajakhan]

Hello,

Any luck trying the updated one ?
https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA9984/hw1.0/firmware-5.bin_10.4-3.3-00102

Btw, are you using backports (or) ath.git ? Have you made any private changes ?

regards,
shafi

On Tue, Jan 10, 2017 at 10:58:48AM +0500, Sergey Stepanov wrote:
> Hi,
> 
> Thanks for reply.
> Actually the firmware crashes twice: during probing and during driver
> registering,
> Here are these logs:
> 
> ath10k_debug_print_hwfw_info(): qca9984/qca9994 hw1.0 target
> 0x0100 chip_id 0x sub 168c:cafe
> ath10k_debug_print_hwfw_info(): firmware ver 10.4-3.3-00092 api 5
> features no-p2p,mfp,peer-flow-ctrl,btcoex-param
> ath10k_core_pre_cal_download(): boot did not find a pre
> calibration file, try DT next: -2
> ath10k_core_pre_cal_download(): boot using calibration mode pre-cal-dt
> ath10k_core_get_board_id_from_ot(): boot upload otp to 0x1234 len 9000
> for board id
> ath10k_bmi_fast_download(): bmi fast download address 0x1234
> buffer 0x0x10595254 length 9000
> ath10k_bmi_lz_stream_start()  : bmi lz stream start address 0x1234
> ath10k_bmi_lz_data()  : bmi lz data buffer 0x0x10595254 length 
> 9000
> ath10k_bmi_lz_stream_start()  : bmi lz stream start address 0x0
> ath10k_bmi_execute()  : bmi execute address 0x1234 param 0x10
> ath10k_bmi_execute()  : bmi execute result 0x400
> ath10k_core_get_board_id_from_ot(): boot get otp board id result
> 0x0400 board_id 1 chip_id 0
> ath10k_core_create_board_name()   : boot using board name
> 'bus=pci,bmi-chip-id=0,bmi-board-id=1'
> ath10k_core_parse_bd_ie_board()   : board name: len=36
> ath10k_core_parse_bd_ie_board()   : 62 75 73 3D 70 63 69 2C 62 6D 69
> 2D 63 68 69 70
> ath10k_core_parse_bd_ie_board()   : 2D 69 64 3D 30 2C 62 6D 69 2D 62
> 6F 61 72 64 2D
> ath10k_core_parse_bd_ie_board()   : 69 64 3D 31
> ath10k_core_parse_bd_ie_board()   : boot found match for name
> 'bus=pci,bmi-chip-id=0,bmi-board-id=1'
> ath10k_core_parse_bd_ie_board()   : boot found board data for
> 'bus=pci,bmi-chip-id=0,bmi-board-id=1'
> ath10k_core_fetch_board_file(): using board api 2
> ath10k_bmi_start(): bmi start
> ath10k_bmi_write_memory() : bmi write address 0x400800 length 4
> ath10k_bmi_read_memory()  : bmi read address 0x400810 length 4
> ath10k_bmi_write_memory() : bmi write address 0x400810 length 4
> ath10k_bmi_write_memory() : bmi write address 0x400844 length 4
> ath10k_bmi_write_memory() : bmi write address 0x400904 length 4
> ath10k_bmi_write_memory() : bmi write address 0x4008bc length 4
> ath10k_core_pre_cal_download(): boot did not find a pre
> calibration file, try DT next: -2
> ath10k_core_pre_cal_download(): boot using calibration mode pre-cal-dt
> ath10k_core_get_board_id_from_ot(): boot upload otp to 0x1234 len 9000
> for board id
> ath10k_bmi_fast_download(): bmi fast download address 0x1234
> buffer 0x0x10595254 length 9000
> ath10k_bmi_lz_stream_start()  : bmi lz stream start address 0x1234
> ath10k_bmi_lz_data()  : bmi lz data buffer 0x0x10595254 length 
> 9000
> ath10k_bmi_lz_stream_start()  : bmi lz stream start address 0x0
> ath10k_bmi_execute()  : bmi execute address 0x1234 param 0x10
> ath10k_bmi_execute()  : bmi execute result 0x400
> ath10k_core_get_board_id_from_ot(): boot get otp board id result
> 0x0400 board_id 1 chip_id 0
> ath10k_bmi_read_memory()  : bmi read address 0x4008ac length 4
> ath10k_push_board_ext_data()  : boot push board extended data addr 0x0
> ath10k_bmi_read_memory()  : bmi read address 0x400854 length 4
> ath10k_bmi_write_memory() : bmi write address 0xc length 12064
> ath10k_bmi_write_memory() : bmi write address 0x400858 length 4
> ath10k_download_and_run_otp() : boot upload otp to 0x1234 len 9000
> ath10k_bmi_fast_download(): bmi fast download address 0x1234
> buffer 0x0x10595254 length 9000
> ath10k_bmi_lz_stream_start()  : bmi lz stream start address 0x1234
> ath10k_bmi_lz_data()  : bmi lz data buffer 0x0x10595254 length 
> 9000
> ath10k_bmi_lz_stream_start()  : bmi lz stream start address 0x0
> ath10k_bmi_execute()  : bmi execute address 0x1234 param 0x700
> ath10k_bmi_execute()  : bmi execute result 0x0
> ath10k_download_and_run_otp() : boot otp execute result 0
> ath10k_core_pre_cal_config()  : pre cal configuration done successfully
> ath10k_swap_code_seg_configure()  : boot found firmware code swap binary
> ath10k_bmi_write_memory() : bmi write address 0x422108 length 208
> ath10k_download_fw()  : boot uploading firmware image
> 0x10597584K len 374947
> ath10k_bmi_fast_download(): bmi fast download address 0x1234
> buffer 0x0x10597584 length 374947
> ath10k_bmi_lz_stream_start()  : bmi lz stream start address 

Re: QCA8994 booting failed

[Mohammed Shafi Shajakhan]

On Tue, Jan 03, 2017 at 06:03:13PM +0530, K.Mani wrote:
> I'm using Annapurna board(Alpine soc V1) on kernel-linux-3.10.20 openWRT.
> The board has two QCA9984 wlan boards(2.4 & 5 Ghz). I downloaded the
> firmware files from net.
> Used, insmod ath10k_core.ko skip_otp=1 also tried without skip_otp param
> 
> The wlan 5.0Ghz board bootsup & connects to ssid, pings perfectly.
> But the 2.4Ghz board fails to bootup, stating "failed to fetch board file".

kindly try the board-2.bin
https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA9984/hw1.0/
> 
> [  209.550433] ath10k_pci 0001:01:00.0: bmi lz stream start address 0x0
> [  209.550669] ath10k_pci 0001:01:00.0: bmi execute address 0x1234 param 0x10
> [  210.942841] ath10k_pci 0001:01:00.0: bmi execute result 0x1000
> [  210.942848] ath10k_pci 0001:01:00.0: boot get otp board id result
> 0x1000 board_id 4 chip_id 0
> [  210.942856] ath10k_pci 0001:01:00.0: boot using board name
> 'bus=pci,bmi-chip-id=0,bmi-board-id=4'
> [  210.942930] ath10k_pci 0001:01:00.0: board name
> [  210.942938] ath10k_pci 0001:01:00.0: : 62 75 73 3d 70 63 69
> 2c 62 6d 69 2d 63 68 69 70  bus=pci,bmi-chip
> [  210.942944] ath10k_pci 0001:01:00.0: 0010: 2d 69 64 3d 30 2c 62
> 6d 69 2d 62 6f 61 72 64 2d  -id=0,bmi-board-
> [  210.942950] ath10k_pci 0001:01:00.0: 0020: 69 64 3d 31
> id=1
> [  210.942957] ath10k_pci 0001:01:00.0: failed to fetch board data for
> bus=pci,bmi-chip-id=0,bmi-board-id=4 from
> ath10k/QCA9984/hw1.0/board-2.n
> [  271.089644] ath10k_pci 0001:01:00.0: failed to fetch board data
> [  271.09] ath10k_pci 0001:01:00.0: failed to fetch board file: -2
> 
> One difference I found from the bootlogs
> For 5.0Ghz log shows, bmi execute result 0x400
> But 2.4Ghz log shows, bmi execute result 0x1000
> Could this be the issue, if so how to fix it?
> 
> Help needed.
> 
> Thanks
> Mani
> 
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [1/2] ath10k: add accounting for the extended peer statistics

[Mohammed Shafi Shajakhan]

Hi Christian / Kalle,

On Fri, Dec 30, 2016 at 03:35:10PM +0100, Christian Lamparter wrote:
> On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo  wrote:
> > Christian Lamparter  wrote:
> >> The 10.4 firmware adds extended peer information to the
> >> firmware's statistics payload. This additional info is
> >> stored as a separate data field and the elements are
> >> stored in their own "peers_extd" list.
> >>
> >> These elements can pile up in the same way as the peer
> >> information elements. This is because the
> >> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> >> pull the same amount (num_peer_stats) for every statistic
> >> data unit.
> >>
> >> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> >> Signed-off-by: Christian Lamparter 
> >
> > My understanding is that I should skip this patch 1. Please let me know if
> > I misunderstood. But I'm still plannning to apply patch 2.
> 
> I added Mohammed (I hope, he can reply to the open question when he
> returns), Since I'm not sure what he wants or not.
> 
> As far as I'm aware, the "extended" boolean serves no purpose
> because it was only used in once place in debugfs_sta which was
> removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
> and "ath10k_sta_update_extd_stats_rx_duration" have been unified).

[shafi] We will wait for Kalle to review from the de-ferred stage
and get his opinion as well(regarding the design change).
I have no concerns as long this does not changes the existing behaviour.
thank you !

regards,
shafi


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

[Mohammed Shafi Shajakhan]

Hi Christian,


On Thu, Dec 22, 2016 at 06:58:41PM +0100, Christian Lamparter wrote:
> Hello Shafi,
> 
> On Thursday, December 22, 2016 9:18:01 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan 
> > > wrote:
> > > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > > > The 10.4 firmware adds extended peer information to the
> > > > > firmware's statistics payload. This additional info is
> > > > > stored as a separate data field. During review of
> > > > > "ath10k: add accounting for the extended peer statistics" [0]
> > > > > 
> > > > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > > > lists are of little use:"... there is not much use in appending
> > > > > the extended peer stats (which gets periodically updated) to the
> > > > > linked list '>debug.fw_stats.peers_extd)' and should we get
> > > > > rid of the below (and the required cleanup as well)
> > > > > 
> > > > > list_splice_tail_init(_extd,
> > > > > >debug.fw_stats.peers_extd);
> > > > > 
> > > > > since rx_duration is getting updated periodically to the per sta
> > > > > information."
> > > > > 
> > > > > This patch replaces the extended peers list with a lookup and
> > > > > puts the retrieved data (rx_duration) into the existing
> > > > > ath10k_fw_stats_peer entry that was created earlier.
> > > > 
> > > > [shafi] Its good to maintain the extended stats variable
> > > > and retain the two different functions to update rx_duration.
> > > > 
> > > > a) extended peer stats supported - mainly for 10.4
> > > > b) extender peer stats not supported - for 10.2
> > > Well, I have to ask why you want to retain the two different
> > > functions to update the same arsta->rx_duration? I think a
> > > little bit of code that helps to explain what's on your mind
> > > (or how you would do it) would help immensely in this case.
> > > Since I have the feeling that this is the problem here. 
> > > So please explain it in C(lang).
> > 
> > [shafi] I see you prefer to stuff the 'rx_duration' from
> > the extended stats to the existing global 'ath10k_peer_stats'
> > The idea of extended stats is, ideally its not going to stop
> > for 'rx_duration' . Extended stats is maintained as a seperate
> > list / entry for addition of new fields as well
> I'm guessing you are trying to say here:
> 
> replace:
> 
> dst->rx_duration = __le32_to_cpu(src->rx_duration); 
> 
> with
> 
> dst->rx_duration += __le32_to_cpu(src->rx_duration);
> 
> in ath10k_wmi_10_4_op_pull_fw_stats()?

[shafi] oh no sorry, I am trying to say more members related
to stats shall be added in extended stats structure . The extended
stats structure is specifically introduced for adding more stats related
variables.

> 
> Is this correct? If so then can you tell me why 
> ath10k_wmi_10_4_op_pull_fw_stats()
> is using for (i = 0; i < num_peer_stats; i++) to iterate over the extended 
> peer
> stats instead of looking up the number of extended peer items. Because this 
> does
> imply that there are the "same" (and every peer stat has a matching extended 
> peer stat)... (This will be important for the comment below - so ***).
> Of course, if this isn't true then this is a bug and should be fixed because
> otherwise the ath10k_wmi_10_4_op_pull_fw_stats functions might return -EPROTO
> at some point which causes a "failed to pull fw stats: -71" and 
> unprocessed/lost
> stats.

[shafi] sorry i am not sure I got you, have you come across this error, please
let me know ?

> > > 
> > > > > [0] 
> > > > > <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunk...@googlemail.com>
> > > > > Cc: Mohammed Shafi Shajakhan <moham...@codeaurora.org>
> > > > > Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
> > > > > ---
> > > > >  drivers/net/wireless/ath/ath10k/core.h|  2 --
> > > > >  drivers/net/wireless/ath/ath10k/debug.c   | 17 --
> > > > >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 
> > > > > ++---
> > > > >  drivers/net/wireless/ath/ath10k/wmi.c | 34 
> > > &g

[PATCH] ath10k: Enable advertising support for channel 169, 5Ghz

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Enable advertising support for channel 169, 5Ghz so that
based on the regulatory domain(country code) this channel
shall be active for use. For example in countries like India
this channel shall be available for use with latest regulatory updates

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.h | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 756e876..a19cef2 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,7 @@
 #define WMI_READY_TIMEOUT (5 * HZ)
 #define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
 #define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
-#define ATH10K_NUM_CHANS 39
+#define ATH10K_NUM_CHANS 40
 
 /* Antenna noise floor */
 #define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 481842b..7d2f0ae 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7559,6 +7559,7 @@ struct ath10k_mac_change_chanctx_arg {
CHAN5G(157, 5785, 0),
CHAN5G(161, 5805, 0),
CHAN5G(165, 5825, 0),
+   CHAN5G(169, 5845, 0),
 };
 
 struct ath10k *ath10k_mac_create(size_t priv_size)
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Remove passing unused argument for ath10k_mac_tx

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

'ath10k_mac_tx' does not seems to use the per station table
entry pointer 'sta' (struct ieee80211_sta), hence remove passing
this unused argument

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 7d2f0ae..d0d3059 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3493,7 +3493,6 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
  */
 static int ath10k_mac_tx(struct ath10k *ar,
 struct ieee80211_vif *vif,
-struct ieee80211_sta *sta,
 enum ath10k_hw_txrx_mode txmode,
 enum ath10k_mac_tx_path txpath,
 struct sk_buff *skb)
@@ -3635,7 +3634,7 @@ void ath10k_offchan_tx_work(struct work_struct *work)
txmode = ath10k_mac_tx_h_get_txmode(ar, vif, sta, skb);
txpath = ath10k_mac_tx_h_get_txpath(ar, skb, txmode);
 
-   ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+   ret = ath10k_mac_tx(ar, vif, txmode, txpath, skb);
if (ret) {
ath10k_warn(ar, "failed to transmit offchannel frame: 
%d\n",
ret);
@@ -3822,7 +3821,7 @@ int ath10k_mac_tx_push_txq(struct ieee80211_hw *hw,
spin_unlock_bh(>htt.tx_lock);
}
 
-   ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+   ret = ath10k_mac_tx(ar, vif, txmode, txpath, skb);
if (unlikely(ret)) {
ath10k_warn(ar, "failed to push frame: %d\n", ret);
 
@@ -4103,7 +4102,7 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
spin_unlock_bh(>htt.tx_lock);
}
 
-   ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+   ret = ath10k_mac_tx(ar, vif, txmode, txpath, skb);
if (ret) {
ath10k_warn(ar, "failed to transmit frame: %d\n", ret);
if (is_htt) {
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

[Mohammed Shafi Shajakhan]

Hi Christian,

once again sorry for the delay

> 
> On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > The 10.4 firmware adds extended peer information to the
> > > firmware's statistics payload. This additional info is
> > > stored as a separate data field. During review of
> > > "ath10k: add accounting for the extended peer statistics" [0]
> > > 
> > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > lists are of little use:"... there is not much use in appending
> > > the extended peer stats (which gets periodically updated) to the
> > > linked list '>debug.fw_stats.peers_extd)' and should we get
> > > rid of the below (and the required cleanup as well)
> > > 
> > > list_splice_tail_init(_extd,
> > > >debug.fw_stats.peers_extd);
> > > 
> > > since rx_duration is getting updated periodically to the per sta
> > > information."
> > > 
> > > This patch replaces the extended peers list with a lookup and
> > > puts the retrieved data (rx_duration) into the existing
> > > ath10k_fw_stats_peer entry that was created earlier.
> > 
> > [shafi] Its good to maintain the extended stats variable
> > and retain the two different functions to update rx_duration.
> > 
> > a) extended peer stats supported - mainly for 10.4
> > b) extender peer stats not supported - for 10.2
> Well, I have to ask why you want to retain the two different
> functions to update the same arsta->rx_duration? I think a
> little bit of code that helps to explain what's on your mind
> (or how you would do it) would help immensely in this case.
> Since I have the feeling that this is the problem here. 
> So please explain it in C(lang).

[shafi] I see you prefer to stuff the 'rx_duration' from
the extended stats to the existing global 'ath10k_peer_stats'
The idea of extended stats is, ideally its not going to stop
for 'rx_duration' . Extended stats is maintained as a seperate
list / entry for addition of new fields as well

> 
> > > [0] 
> > > <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunk...@googlemail.com>
> > > Cc: Mohammed Shafi Shajakhan <moham...@codeaurora.org>
> > > Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
> > > ---
> > >  drivers/net/wireless/ath/ath10k/core.h|  2 --
> > >  drivers/net/wireless/ath/ath10k/debug.c   | 17 --
> > >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 
> > > ++---
> > >  drivers/net/wireless/ath/ath10k/wmi.c | 34 
> > > ---
> > >  4 files changed, 28 insertions(+), 57 deletions(-)
> > > 
> > > diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> > > b/drivers/net/wireless/ath/ath10k/core.h
> > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > >  };
> > >  
> > >  struct ath10k_fw_stats {
> > > - bool extended;
> > >   struct list_head pdevs;
> > >   struct list_head vdevs;
> > >   struct list_head peers;
> > > - struct list_head peers_extd;
> > >  };
> > >  
> > >  #define ATH10K_TPC_TABLE_TYPE_FLAG   1
> > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> > > b/drivers/net/wireless/ath/ath10k/debug.c
> > > index 82a4c67f3672..89f7fde77cdf 100644
> > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct 
> > > list_head *head)
> > >   }
> > >  }
> > >  
> > > -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> > > -{
> > > - struct ath10k_fw_extd_stats_peer *i, *tmp;
> > > -
> > > - list_for_each_entry_safe(i, tmp, head, list) {
> > > - list_del(>list);
> > > - kfree(i);
> > > - }
> > > -}
> > > -
> > >  static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> > >  {
> > >   spin_lock_bh(>data_lock);
> > >   ar->debug.fw_stats_done = false;
> > > - ar->debug.fw_stats.extended = false;
> > 
> &g

[PATCH v2] ath10k: Fix crash during rmmod when probe firmware fails

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails by calling 'ath10k_hif_stop'. Its good to note
that the error is never propogated to 'ath10k_pci_probe' when
ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
PCI related things seems to be ok

BUG: unable to handle kernel NULL pointer dereference at (null)
IP:  __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
__ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]

Call Trace:

[] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
[ath10k_core]
[] ath10k_htt_txrx_compl_task+0x433/0x17d0
[ath10k_core]
[] ? __wake_up_common+0x4d/0x80
[] ? cpu_load_update+0xdc/0x150
[] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
[] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
[] net_rx_action+0x20f/0x370

Reported-by: Ben Greear <gree...@candelatech.com>
Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f7ea4de..15bccc9 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
ath10k_core_free_firmware_files(ar);
 
 err_power_down:
+   ath10k_hif_stop(ar);
ath10k_hif_power_down(ar);
 
return ret;
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

[Mohammed Shafi Shajakhan]

On Mon, Dec 19, 2016 at 10:19:57PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Christian,
> 
> On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > The 10.4 firmware adds extended peer information to the
> > firmware's statistics payload. This additional info is
> > stored as a separate data field. During review of
> > "ath10k: add accounting for the extended peer statistics" [0]
> > 
> > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > lists are of little use:"... there is not much use in appending
> > the extended peer stats (which gets periodically updated) to the
> > linked list '>debug.fw_stats.peers_extd)' and should we get
> > rid of the below (and the required cleanup as well)
> > 
> > list_splice_tail_init(_extd,
> > >debug.fw_stats.peers_extd);
> > 
> > since rx_duration is getting updated periodically to the per sta
> > information."
> 
> [shafi] thanks !
> 
> > 
> > This patch replaces the extended peers list with a lookup and
> > puts the retrieved data (rx_duration) into the existing
> > ath10k_fw_stats_peer entry that was created earlier.
> 
> [shafi] Its good to maintain the extended stats variable
> and retain the two different functions to update rx_duration.
> 
> a) extended peer stats supported - mainly for 10.4
> b) extender peer stats not supported - for 10.2
> 
> 
> > 
> > [0] 
> > <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunk...@googlemail.com>
> > Cc: Mohammed Shafi Shajakhan <moham...@codeaurora.org>
> > Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.h|  2 --
> >  drivers/net/wireless/ath/ath10k/debug.c   | 17 --
> >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 
> > ++---
> >  drivers/net/wireless/ath/ath10k/wmi.c | 34 
> > ---
> >  4 files changed, 28 insertions(+), 57 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> > b/drivers/net/wireless/ath/ath10k/core.h
> > index 09ff8b8a6441..3fffbbb18c25 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> >  };
> >  
> >  struct ath10k_fw_stats {
> > -   bool extended;
> > struct list_head pdevs;
> > struct list_head vdevs;
> > struct list_head peers;
> > -   struct list_head peers_extd;
> >  };
> >  
> >  #define ATH10K_TPC_TABLE_TYPE_FLAG 1
> > diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> > b/drivers/net/wireless/ath/ath10k/debug.c
> > index 82a4c67f3672..89f7fde77cdf 100644
> > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct 
> > list_head *head)
> > }
> >  }
> >  
> > -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> > -{
> > -   struct ath10k_fw_extd_stats_peer *i, *tmp;
> > -
> > -   list_for_each_entry_safe(i, tmp, head, list) {
> > -   list_del(>list);
> > -   kfree(i);
> > -   }
> > -}
> > -
> >  static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> >  {
> > spin_lock_bh(>data_lock);
> > ar->debug.fw_stats_done = false;
> > -   ar->debug.fw_stats.extended = false;
> 
> [shafi] this looks fine, but not removing the 'extended' variable 
> from ath10k_fw_stats structure, I see the design for 'rx_duration'
> arguably some what convoluted !
> 
> *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> *Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, )'
> {certainly 'stats' object is for this particular update only, and freed
> up later)
> *Update immediately using 'ath10k_sta_update_rx_duration'
> 
> 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> for 10.2 and 10.4 (the later supporting extended peer stats)
> 
> 
> 
> > ath10k_fw_stats_pdevs_free(>debug.fw_stats.pdevs);
> > ath10k_fw_stats_vdevs_free(>debug.fw_stats.vdevs);
> > ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
> > -   ath10k_fw_extd_stats_peers_free(>debug.fw_stats.peers_extd);
> > spin_unlock_bh(>data_lock);
> >  }
> >  
> > @@ -348,7 +336,6 @@ void ath10k_debug_fw_s

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

[Mohammed Shafi Shajakhan]

Hi Christian,

On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> The 10.4 firmware adds extended peer information to the
> firmware's statistics payload. This additional info is
> stored as a separate data field. During review of
> "ath10k: add accounting for the extended peer statistics" [0]
> 
> Mohammed Shafi Shajakhan commented that the extended peer statistics
> lists are of little use:"... there is not much use in appending
> the extended peer stats (which gets periodically updated) to the
> linked list '>debug.fw_stats.peers_extd)' and should we get
> rid of the below (and the required cleanup as well)
> 
> list_splice_tail_init(_extd,
> >debug.fw_stats.peers_extd);
> 
> since rx_duration is getting updated periodically to the per sta
> information."

[shafi] thanks !

> 
> This patch replaces the extended peers list with a lookup and
> puts the retrieved data (rx_duration) into the existing
> ath10k_fw_stats_peer entry that was created earlier.

[shafi] Its good to maintain the extended stats variable
and retain the two different functions to update rx_duration.

a) extended peer stats supported - mainly for 10.4
b) extender peer stats not supported - for 10.2


> 
> [0] 
> <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunk...@googlemail.com>
> Cc: Mohammed Shafi Shajakhan <moham...@codeaurora.org>
> Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.h|  2 --
>  drivers/net/wireless/ath/ath10k/debug.c   | 17 --
>  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++---
>  drivers/net/wireless/ath/ath10k/wmi.c | 34 
> ---
>  4 files changed, 28 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> b/drivers/net/wireless/ath/ath10k/core.h
> index 09ff8b8a6441..3fffbbb18c25 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
>  };
>  
>  struct ath10k_fw_stats {
> - bool extended;
>   struct list_head pdevs;
>   struct list_head vdevs;
>   struct list_head peers;
> - struct list_head peers_extd;
>  };
>  
>  #define ATH10K_TPC_TABLE_TYPE_FLAG   1
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> b/drivers/net/wireless/ath/ath10k/debug.c
> index 82a4c67f3672..89f7fde77cdf 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct list_head 
> *head)
>   }
>  }
>  
> -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> -{
> - struct ath10k_fw_extd_stats_peer *i, *tmp;
> -
> - list_for_each_entry_safe(i, tmp, head, list) {
> - list_del(>list);
> - kfree(i);
> - }
> -}
> -
>  static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
>  {
>   spin_lock_bh(>data_lock);
>   ar->debug.fw_stats_done = false;
> - ar->debug.fw_stats.extended = false;

[shafi] this looks fine, but not removing the 'extended' variable 
from ath10k_fw_stats structure, I see the design for 'rx_duration'
arguably some what convoluted !

*We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
*Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, )'
{certainly 'stats' object is for this particular update only, and freed
up later)
*Update immediately using 'ath10k_sta_update_rx_duration'

'ath10k_wmi_pull_fw_stats' has a slightly different implementation
for 10.2 and 10.4 (the later supporting extended peer stats)



>   ath10k_fw_stats_pdevs_free(>debug.fw_stats.pdevs);
>   ath10k_fw_stats_vdevs_free(>debug.fw_stats.vdevs);
>   ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
> - ath10k_fw_extd_stats_peers_free(>debug.fw_stats.peers_extd);
>   spin_unlock_bh(>data_lock);
>  }
>  
> @@ -348,7 +336,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
> struct sk_buff *skb)
>   INIT_LIST_HEAD();
>   INIT_LIST_HEAD();
>   INIT_LIST_HEAD();
> - INIT_LIST_HEAD(_extd);
>  
>   spin_lock_bh(>data_lock);
>   ret = ath10k_wmi_pull_fw_stats(ar, skb, );
> @@ -411,8 +398,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
> struct sk_buff *skb)
>  
>   list_splice_tail_init(, >debug.fw_stats.peers);
>   list_splice_tail_init(, >debug.fw_stats.vdevs);
> - list_splice_tail_init(_extd,
> -   

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

[Mohammed Shafi Shajakhan]

Hi Christian,

> On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote:
> > I am also thinking, as of now there is not much use in appending
> > the extended peer stats (which gets periodically ) to the linked list
> > '>debug.fw_stats.peers_extd)'  and should we get rid of the below
> > (and the required cleanup as well) 
> > 
> > list_splice_tail_init(_extd,
> > >debug.fw_stats.peers_extd);
> > 
> > 
> > since rx_duration is getting updated periodically to the per sta
> > information. Kindly let me know your thoughts about this.
> 
> Yes, of course. I see what your are trying to do and I think it's much better
> to get rid of peers_extd and ath10k_fw_extd_stats_peers_free.
>
[shafi] Feel free to post the change and I can test the same for you(next week) 
!
Let me know if you are busy on something else, I can take this up.
As discussed, the fix to free 'extd stats' when number of peers exceeds the 
range
is definitely needed. Thank you for looking into this.

thanks,
shafi


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

[Mohammed Shafi Shajakhan]

Hi Christian,

I am also thinking, as of now there is not much use in appending
the extended peer stats (which gets periodically ) to the linked list
'>debug.fw_stats.peers_extd)'  and should we get rid of the below
(and the required cleanup as well) 

list_splice_tail_init(_extd,
>debug.fw_stats.peers_extd);


since rx_duration is getting updated periodically to the per sta
information. Kindly let me know your thoughts about this.

regards,
shafi

On Thu, Dec 15, 2016 at 09:56:59PM +0530, Mohammed Shafi Shajakhan wrote:
> Hello Christian,
> 
> On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> > On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan 
> > wrote:
> > > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan 
> > > > wrote:
> > > > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct 
> > > > > > ath10k *ar, struct sk_buff *skb)
> > > > > > goto free;
> > > > > > }
> > > > > >  
> > > > > > +   if (!list_empty())
> > > > > 
> > > > > [shafi] sorry please correct me if i am wrong, for 'extended peer 
> > > > > stats' we are checking
> > > > > for normal 'peer stats' ? Is this the fix intended, i had started a 
> > > > > build to
> > > > > check your change and we will keep you posted, does this fix 
> > > > > displaying
> > > > > 'rx_duration' in ath10k fw_stats.
> > > > The idea is not to queue any "extended peer stats" when there where no 
> > > > "peer stats" to
> > > > begin with. Because otherwise, the function is still vulnerable to OOM 
> > > > since the 
> > > > extended peers stats will be queued unchecked (not that this is 
> > > > currently a problem).
> > > 
> > > [shafi] list_splice_tail_init should still check for non-empty 
> > > 'peers_extd' list
> > > and append if required ? please let me know if i am still missing 
> > > something
> > Well, you can also count the entries in peers_extd and delete the old 
> > entries
> > if they start to overflow. If you want to do it differently, please go 
> > ahead.
> >
> [shafi] sorry for the delay (got stuck up with something else), I will add 
> some prints explicitly
> and keep you posted ASAP. Since the extended peer stats gets updated 
> periodically I
> would like to confirm the debug linked list associated to the extended peer
> stats does not overflows and potentially cause OOM.
> 
> regards,
> shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: boot kernel panic with QCA6174 and kernel 4.8

[Mohammed Shafi Shajakhan]

Hi,

On Wed, Dec 07, 2016 at 09:40:29AM +0100, Alexandre Maloteaux wrote:
> Hi
> Since recent kernel upgrade on Arch linux ;  im facing  boot kernel
> panics with the ath10k_pci and QCA6174 802.11ac Wireless Network Adapter
> on an Eurocom P5 Pro laptop.
> 
> This is the main call stack dump :
> 
> ath10k_print_driver_info(ath10k_core)
> ath10k_pcl_fw_crashed_dump (ath10k_pci)
> ath10k_pcl.tasklet

[shafi] If you have the source of the same and with the help of gdb we
can get the exact line

> 
> So far i can circumvent the kernel panic by appending
> modprobe.blacklist=ath10k_pci  to the kernel command line.
> Once the Os is booted i can load the module with modprobe without
> triggering the kernel panic.
> 
> I also unpacked the initrd and the firmware file are not located in
> lib/firmware.

[shafi] interesting your log (image file) seems to show the firmware is crashed
? if the firmware is missing you can give a try with this
https://patchwork.kernel.org/patch/9412085/ but the call trace looks completely
different, if the f/w is not there

long time back we fixed a race https://patchwork.kernel.org/patch/9167045/ but
it should be available in 4.8.11

> 
> I could not setup kdump so early in the boot process so i have attached
> a screenshot of the on screen dump.
> 
> lspci :
> 06:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
> Network Adapter (rev 20)
> 
> uname -r
> 4.8.11-1-ARCH
> 
> Best Regards


> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

[Mohammed Shafi Shajakhan]

Hi Christian,

On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> The 10.4 firmware adds extended peer information to the
> firmware's statistics payload. This additional info is
> stored as a separate data field and the elements are
> stored in their own "peers_extd" list.
> 
> These elements can pile up in the same way as the peer
> information elements. This is because the
> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> pull the same amount (num_peer_stats) for every statistic
> data unit.
> 
> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> Signed-off-by: Christian Lamparter 
> ---
>  drivers/net/wireless/ath/ath10k/debug.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> b/drivers/net/wireless/ath/ath10k/debug.c
> index 82a4c67f3672..4acd9eb65910 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
> struct sk_buff *skb)
>* prevent firmware from DoS-ing the host.
>*/
>   ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
> + 
> ath10k_fw_extd_stats_peers_free(>debug.fw_stats.peers_extd);

[shafi] thanks for fixing this !

>   ath10k_warn(ar, "dropping fw peer stats\n");
>   goto free;
>   }
> @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
> struct sk_buff *skb)
>   goto free;
>   }
>  
> + if (!list_empty())

[shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are 
checking
for normal 'peer stats' ? Is this the fix intended, i had started a build to
check your change and we will keep you posted, does this fix displaying
'rx_duration' in ath10k fw_stats.

> + list_splice_tail_init(_extd,
> +   >debug.fw_stats.peers_extd);
> +
>   list_splice_tail_init(, >debug.fw_stats.peers);
>   list_splice_tail_init(, >debug.fw_stats.vdevs);
> - list_splice_tail_init(_extd,
> -   >debug.fw_stats.peers_extd);
>   }
>  
>   complete(>debug.fw_stats_complete);

thanks,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Avoid potential page alloc BUG_ON in tx free path

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
have NULL pointer checks to avoid crash if they are called twice
but this is as of now not sufficient as these pointers are not assigned
to NULL once the contiguous DMA memory allocation is freed, fix this.
Though this may not be hit with the explicity check of state variable
'tx_mem_allocated' check, good to have this addressed as well.

Below BUG_ON is hit when the above scenario is simulated
with kernel debugging enabled

 page:f6d09a00 count:0 mapcount:-127 mapping:  (null)
index:0x0
 flags: 0x4000()
 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)
== 0)
 [ cut here ]
 kernel BUG at ./include/linux/mm.h:445!
 invalid opcode:  [#1] SMP DEBUG_PAGEALLOC
 EIP is at put_page_testzero.part.88+0xd/0xf
 Call Trace:
  [] __free_pages+0x3c/0x40
  [] free_pages+0x3e/0x50
  [] dma_generic_free_coherent+0x24/0x30
  [] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140

  [] ath10k_htt_tx_destroy+0x29/0xa0

  [] ath10k_core_destroy+0x60/0x80 [ath10k_core]
  [] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
  [] pci_device_remove+0x38/0xb0
  [] __device_release_driver+0x72/0x100
  [] driver_detach+0x97/0xa0
  [] bus_remove_driver+0x40/0x80
  [] driver_unregister+0x2a/0x60
  [] pci_unregister_driver+0x18/0x70
  [] ath10k_pci_exit+0xd/0x2be [ath10k_pci]
  [] SyS_delete_module+0x158/0x210
  [] ? __might_fault+0x41/0xa0
  [] ? __might_fault+0x8b/0xa0
  [] do_fast_syscall_32+0x9b/0x1c0
  [] sysenter_past_esp+0x45/0x74

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 27e49db..86b427f 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -239,6 +239,7 @@ static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt 
*htt)
 
size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
dma_free_coherent(ar->dev, size, htt->txbuf.vaddr, htt->txbuf.paddr);
+   htt->txbuf.vaddr = NULL;
 }
 
 static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
@@ -268,6 +269,7 @@ static void ath10k_htt_tx_free_cont_frag_desc(struct 
ath10k_htt *htt)
  size,
  htt->frag_desc.vaddr,
  htt->frag_desc.paddr);
+   htt->frag_desc.vaddr = NULL;
 }
 
 static int ath10k_htt_tx_alloc_cont_frag_desc(struct ath10k_htt *htt)
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k firmware crashes in mesh mode on QCA9880

[Mohammed Shafi Shajakhan]

https://patchwork.kernel.org/patch/9437519/
(sorry missed this in the previous thread)

On Sat, Dec 03, 2016 at 06:13:58PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Benjamin,
> 
> On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:
> > Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:
> > 
> > [  131.568989] ath10k_pci :01:00.0: firmware crashed! (uuid
> > 1838347e-9380-4a26-ac9d-2963ee95968b)
> > [  131.578124] ath10k_pci :01:00.0: qca988x hw2.0 target
> > 0x4100016c chip_id 0x043202ff sub :
> > [  131.587491] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> > tracing 0 dfs 1 testmode 1
> > [  131.600521] ath10k_pci :01:00.0: firmware ver 10.2.4.70.58
> > api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
> > [  131.610899] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> > crc32 bebc7c08
> > [  131.618325] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> > 2 cal file max-sta 128 raw 0 hwcrypto 1
> > [  131.629965] ath10k_pci :01:00.0: firmware register dump:
> > [  131.635728] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
> > 0x009A45AF 0x00955B31
> > [  131.643761] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130
> > 0x0002 0x00439E98
> > [  131.651806] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074
> > 0x00407120 0x004436CC
> > [  131.659852] ath10k_pci :01:00.0: [12]: 0x0009 0x
> > 0x009A3550 0x009A355E
> > [  131.667892] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A31D6
> > 0x 0x
> > [  131.675936] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4
> > 0x0040AC60 0x0040AC09
> > [  131.683968] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24
> > 0x0040 0xC09A45AF
> > [  131.692013] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84
> > 0x0044110C 0x00442074
> > [  131.700056] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4
> > 0x0044110C 0x00407120
> > [  131.708100] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> > 0x0040AC14 0x1580
> > [  131.716143] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04
> > 0x009C6458 0x004436CC
> > [  131.724175] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64
> > 0x004208FC 0x00439E4C
> > [  131.732220] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84
> > 0x004208FC 0x00425874
> > [  131.740263] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4
> > 0x00424FE8 0x0002
> > [  131.748306] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14
> > 0x0004 0x004039D0
> > [  131.857076] ieee80211 phy0: Hardware restart was requested
> > [  131.862705] ath10k_pci :01:00.0: failed to synchronize
> > monitor vdev 1 stop: -143
> > [  131.870594] ath10k_pci :01:00.0: failed to stop monitor vdev: -143
> 
> [shafi] request to try with the latest backports and ath.git
> Also worth trying this fix in ath10k (once the next firmware version)
> is available. I will keep you posted. thank you !
> 
> > 
> > ~Benjamin
> > 
> > On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
> > >Hi,
> > >
> > >On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> > >>When we try to transmit traffic (ping) between two meshed ath10k
> > >>devices running latest lede we keep experiencing ath10k firmware
> > >>crashes. This seems to only happen when running in 802.11n/ac mode
> > >>but not in 802.11a/g mode. Also, from the station dumps it appears
> > >>that management traffic is flowing between the devices, however when
> > >>we try to send unicast data traffic the firmware crashes
> > >>immediately.
> > >[shafi] Did you get a chance to try with the below firmware as well
> > >https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
> > >
> > >>Platform: Archer C7 AC1750 v2
> > >>Software Image: LEDE (HEAD, r2299) Commit: 
> > >>https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
> > >>
> > >>Crypto: wpa_supplicant
> > >>wpa_supplicant-wlan0.conf
> > >>network={
> > >>ssid="bmorgan_lede_mesh"
> > >>key_mgmt=SAE
> > >>mode=5
> > >>frequency=5180
> > >>psk="meshpassword"
> > >>}
> > >>
> > >>Backports Verstion:
> > >>[9.818007] Loading modules backported from Linux version
> > >>wt-2016-10-03-1-g6fcb1a6
> > &g

Re: ath10k firmware crashes in mesh mode on QCA9880

[Mohammed Shafi Shajakhan]

Hi Benjamin,

On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:
> Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:
> 
> [  131.568989] ath10k_pci :01:00.0: firmware crashed! (uuid
> 1838347e-9380-4a26-ac9d-2963ee95968b)
> [  131.578124] ath10k_pci :01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub :
> [  131.587491] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [  131.600521] ath10k_pci :01:00.0: firmware ver 10.2.4.70.58
> api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
> [  131.610899] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [  131.618325] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> 2 cal file max-sta 128 raw 0 hwcrypto 1
> [  131.629965] ath10k_pci :01:00.0: firmware register dump:
> [  131.635728] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
> 0x009A45AF 0x00955B31
> [  131.643761] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130
> 0x0002 0x00439E98
> [  131.651806] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [  131.659852] ath10k_pci :01:00.0: [12]: 0x0009 0x
> 0x009A3550 0x009A355E
> [  131.667892] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A31D6
> 0x 0x
> [  131.675936] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [  131.683968] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24
> 0x0040 0xC09A45AF
> [  131.692013] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84
> 0x0044110C 0x00442074
> [  131.700056] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4
> 0x0044110C 0x00407120
> [  131.708100] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> 0x0040AC14 0x1580
> [  131.716143] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04
> 0x009C6458 0x004436CC
> [  131.724175] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64
> 0x004208FC 0x00439E4C
> [  131.732220] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84
> 0x004208FC 0x00425874
> [  131.740263] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4
> 0x00424FE8 0x0002
> [  131.748306] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x0004 0x004039D0
> [  131.857076] ieee80211 phy0: Hardware restart was requested
> [  131.862705] ath10k_pci :01:00.0: failed to synchronize
> monitor vdev 1 stop: -143
> [  131.870594] ath10k_pci :01:00.0: failed to stop monitor vdev: -143

[shafi] request to try with the latest backports and ath.git
Also worth trying this fix in ath10k (once the next firmware version)
is available. I will keep you posted. thank you !

> 
> ~Benjamin
> 
> On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
> >Hi,
> >
> >On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> >>When we try to transmit traffic (ping) between two meshed ath10k
> >>devices running latest lede we keep experiencing ath10k firmware
> >>crashes. This seems to only happen when running in 802.11n/ac mode
> >>but not in 802.11a/g mode. Also, from the station dumps it appears
> >>that management traffic is flowing between the devices, however when
> >>we try to send unicast data traffic the firmware crashes
> >>immediately.
> >[shafi] Did you get a chance to try with the below firmware as well
> >https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
> >
> >>Platform: Archer C7 AC1750 v2
> >>Software Image: LEDE (HEAD, r2299) Commit: 
> >>https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
> >>
> >>Crypto: wpa_supplicant
> >>wpa_supplicant-wlan0.conf
> >>network={
> >>ssid="bmorgan_lede_mesh"
> >>key_mgmt=SAE
> >>mode=5
> >>frequency=5180
> >>psk="meshpassword"
> >>}
> >>
> >>Backports Verstion:
> >>[9.818007] Loading modules backported from Linux version
> >>wt-2016-10-03-1-g6fcb1a6
> >>[9.825736] Backport generated by backports.git
> >>backports-20160324-9-g0e38f5c
> >>
> >>​​Ath10k Initialization on Station A (dmesg)
> >>[9.896715] PCI: Enabling device :01:00.0 ( -> 0002)
> >>[9.902622] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode
> >>1 irq_mode 0 reset_mode 0
> >>[   10.123734] ath10k_pci :01:00.0: Direct firmware load for
> >>ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
> >>[   10.134620] ath10k_pci :01:00.0: Falling back to user helper
> >>[   10.287680] f

Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

On Thu, Dec 01, 2016 at 10:35:38AM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes:
> 
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> > During firmware crash (or) user requested manual restart
> > the system gets into a soft lock up state because of the
> > below root cause.
> >
> > During user requested hardware restart / firmware crash
> > the system goes into a soft lockup state as 'napi_synchronize'
> > is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> > bit) and it sleeps into infinite loop as it waits for
> > 'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> > 'ath10k_hif_stop' is called twice as below (resulting in calling
> > 'napi_synchronize' after 'napi_disable')
> >
> > 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> > -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> > 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> >
> > Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> > as it makes more sense before informing mac80211 to restart h/w
> > Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> >
> > Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> > ---
> > [v2 Added Fixes ]
> 
> I'll also add:
> 
> Cc: <sta...@vger.kernel.org> # v4.9
>
thank you Kalle.

regards,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k firmware crashes in mesh mode on QCA9880

[Mohammed Shafi Shajakhan]

Hi,

On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> When we try to transmit traffic (ping) between two meshed ath10k
> devices running latest lede we keep experiencing ath10k firmware
> crashes. This seems to only happen when running in 802.11n/ac mode
> but not in 802.11a/g mode. Also, from the station dumps it appears
> that management traffic is flowing between the devices, however when
> we try to send unicast data traffic the firmware crashes
> immediately.

[shafi] Did you get a chance to try with the below firmware as well
https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58

> 
> Platform: Archer C7 AC1750 v2
> Software Image: LEDE (HEAD, r2299) Commit: 
> https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
> 
> Crypto: wpa_supplicant
> wpa_supplicant-wlan0.conf
> network={
> ssid="bmorgan_lede_mesh"
> key_mgmt=SAE
> mode=5
> frequency=5180
> psk="meshpassword"
> }
> 
> Backports Verstion:
> [9.818007] Loading modules backported from Linux version
> wt-2016-10-03-1-g6fcb1a6
> [9.825736] Backport generated by backports.git
> backports-20160324-9-g0e38f5c
> 
> ​​Ath10k Initialization on Station A (dmesg)
> [9.896715] PCI: Enabling device :01:00.0 ( -> 0002)
> [9.902622] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode
> 1 irq_mode 0 reset_mode 0
> [   10.123734] ath10k_pci :01:00.0: Direct firmware load for
> ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
> [   10.134620] ath10k_pci :01:00.0: Falling back to user helper
> [   10.287680] firmware ath10k!pre-cal-pci-:01:00.0.bin:
> firmware_loading_store: map pages failed
> [   10.622789] ath10k_pci :01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub :
> [   10.632184] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [   10.645231] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54
> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [   10.655660] ath10k_pci :01:00.0: Direct firmware load for
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [   10.666264] ath10k_pci :01:00.0: Falling back to user helper
> [   10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin:
> firmware_loading_store: map pages failed
> [   11.011123] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [   12.155224] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> 2 cal file max-sta 128 raw 0 hwcrypto 1
> 
> Station A (wlan0):
> 18:A6:F7:23:6E:66
> 10.230.5.41
> 
> Station B (wlan0):
> 18:a6:f7:26:0f:21
> 10.230.5.42
> 
> Station Dump on Station A before ping:
> Station 18:a6:f7:26:0f:21 (on wlan0)
> inactive time:340 ms
> rx bytes:2472
> rx packets:28
> tx bytes:1204
> tx packets:9
> tx retries:0
> tx failed:0
> rx drop misc:1
> signal: -14 dBm
> signal avg:-14 dBm
> Toffset:18142530 us
> tx bitrate:6.0 MBit/s
> rx bitrate:6.0 MBit/s
> rx duration:1524 us
> mesh llid:0
> mesh plid:0
> mesh plink:ESTAB
> mesh local PS mode:ACTIVE
> mesh peer PS mode:UNKNOWN
> mesh non-peer PS mode:ACTIVE
> authorized:yes
> authenticated:yes
> associated:yes
> preamble:long
> WMM/WME:yes
> MFP:yes
> TDLS peer:no
> DTIM period:2
> beacon interval:1000
> connected time:10 seconds
> 
> ​Crash Log on Station B (10.230.5.42)
> [245.483888] ath10k_pci :01:00.0: firmware crashed! (uuid
> 2bab5ee9-08ff-4a17-95b1-636d212acebc)
> [245.493020] ath10k_pci :01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub :
> [245.502384] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [245.515436] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54 api
> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [245.525812] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [245.533232] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal file max-sta 128 raw 0 hwcrypto 1
> [245.544876] ath10k_pci :01:00.0: firmware register dump:
> [245.550633] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
> 0x009A4577 0x00955B31
> [245.558676] ath10k_pci :01:00.0: [04]: 0x009A4577 0x00060130
> 0x0002 0x00439E98
> [245.566715] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [245.574749] ath10k_pci :01:00.0: [12]: 0x0009 0x
> 0x009A3518 0x009A3526
> [245.582793] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D
> 0x 0x
> [245.590836] ath10k_pci :01:00.0: [20]: 0x409A4577 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [245.598882] ath10k_pci :01:00.0: [24]: 0x809A44BA 0x0040AB24
> 0x0040 0xC09A4577
> [245.606923] ath10k_pci :01:00.0: [28]: 0x809A39DE 0x0040AB84
> 0x0044110C 0x00442074
> [245.614955] ath10k_pci :01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> 0x0044110C 0x00407120
> [245.623000] ath10k_pci :01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> 0x0040AC14 0x1580
> [245.631043] ath10k_pci :01:00.0: [40]: 

Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

[Mohammed Shafi Shajakhan]

Hi Adrian,

On Wed, Nov 30, 2016 at 10:27:25AM -0800, Adrian Chadd wrote:
> Heh, I had to do something like this for freebsd too for my ath10k
> port. So thanks. :)

[shafi] thanks :):)

> 
> Suggestion - take a look at where tasklets, completions, locks, etc
> are all re-allocated multiple times, once upon initial VAP bringup. I
> had to also undo this in FreeBSD, as we don't allow re-init of tasks,
> completions, callouts and locks without first freeing/zero'ing them
> appropriately. :)
> 
>
[shafi] sure, I just added some basic debug prints

In ath10k_htt_tx_start and init tx_lock and pending_tx
In ath10k_htt_tx_start and tx mem allocated set to true

In ath10k_htt_tx_start and init tx_lock and pending_tx (initialized second time)
In ath10k_htt_tx_start and tx mem is already allocated
In ath10k_htt_tx_destroy and tx mem allocated set to false

But I see 'ath10k_htt_tx_stop' is called when the interface is brought down
and in that scenario we need to do 'idr_init(>pending_tx) ' ?
while doing a tx_lock might be a duplicate. Also if i understand correctly
the existing ath10k already calls tx buffer allocation twice via

4   2145  core.c <>
   ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL,

5   4471  mac.c <>
   ret = ath10k_core_start(ar,
   ATH10K_FIRMWARE_MODE_NORMAL,

Also there is a suggestion to enhance this patch using DMA API's
(thanks Michal) and we will work on this once this goes fine
without any issues

regards,
shafi

> 
> 
> 
> On 30 November 2016 at 01:50, Mohammed Shafi Shajakhan
> <moham...@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> > 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
> >  [] (__dma_alloc_buffer.isra.23) from
> > [] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> > [] (__alloc_remap_buffer.isra.26) from
> > [] (__dma_alloc+0x224/0x2b8)
> > [] (__dma_alloc) from []
> > (arm_dma_alloc+0x84/0x90)
> > [] (arm_dma_alloc) from []
> > (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> > [] (ath10k_htt_tx_alloc [ath10k_core]) from
> > [] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> > [] (ath10k_core_start [ath10k_core]) from
> > [] (ath10k_start+0xbc/0x56c [ath10k_core])
> > [] (ath10k_start [ath10k_core]) from
> > [] (drv_start+0x40/0x5c [mac80211])
> > [] (drv_start [mac80211]) from []
> > (ieee80211_do_open+0x170/0x82c [mac80211])
> > [] (ieee80211_do_open [mac80211]) from
> > [] (__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 <moham...@qti.qualcomm.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.c   |  5 +--
> >  drivers/net/wireless/ath/ath10k/htt.h|  6 +++-
> >  drivers/net/wireless/ath/ath10k/htt_tx.c | 54 
> > +---
> >  3 files changed, 51 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> > b/drivers/net/wireless/ath/ath10k/core.c
> > index 5bc6847..f7ea4de 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote:
> Is this something for stable?  And if so, how far back should it be applied?

@Kalle,

[shafi] kindly suggest. If i am not wrong this is only needed for 4.9

> 
> I'll add this patch to my 4.9 tree and test it...
>

[shafi] thanks a lot Ben.

> 
> On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> >During firmware crash (or) user requested manual restart
> >the system gets into a soft lock up state because of the
> >below root cause.
> >
> >During user requested hardware restart / firmware crash
> >the system goes into a soft lockup state as 'napi_synchronize'
> >is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> >bit) and it sleeps into infinite loop as it waits for
> >'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> >'ath10k_hif_stop' is called twice as below (resulting in calling
> >'napi_synchronize' after 'napi_disable')
> >
> >'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> >-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> >'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> >
> >Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> >as it makes more sense before informing mac80211 to restart h/w
> >Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> >
> >Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >---
> >[thanks to Kalle and Michal for their inputs]
> >
> > drivers/net/wireless/ath/ath10k/core.c | 2 +-
> > drivers/net/wireless/ath/ath10k/mac.c  | 1 -
> > 2 files changed, 1 insertion(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> >b/drivers/net/wireless/ath/ath10k/core.c
> >index 7005e2a..5bc6847 100644
> >--- a/drivers/net/wireless/ath/ath10k/core.c
> >+++ b/drivers/net/wireless/ath/ath10k/core.c
> >@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct 
> >*work)
> > switch (ar->state) {
> > case ATH10K_STATE_ON:
> > ar->state = ATH10K_STATE_RESTARTING;
> >-ath10k_hif_stop(ar);
> >+ath10k_halt(ar);
> > ath10k_scan_finish(ar);
> > ieee80211_restart_hw(ar->hw);
> > break;
> >diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> >b/drivers/net/wireless/ath/ath10k/mac.c
> >index 717b2fa..481842b 100644
> >--- a/drivers/net/wireless/ath/ath10k/mac.c
> >+++ b/drivers/net/wireless/ath/ath10k/mac.c
> >@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
> > ar->state = ATH10K_STATE_ON;
> > break;
> > case ATH10K_STATE_RESTARTING:
> >-ath10k_halt(ar);
> > ar->state = ATH10K_STATE_RESTARTED;
> > break;
> > case ATH10K_STATE_ON:
> >
> 
> 
> -- 
> Ben Greear <gree...@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

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
 [] (__dma_alloc_buffer.isra.23) from
[] (__alloc_remap_buffer.isra.26+0x14/0xb8)
[] (__alloc_remap_buffer.isra.26) from
[] (__dma_alloc+0x224/0x2b8)
[] (__dma_alloc) from []
(arm_dma_alloc+0x84/0x90)
[] (arm_dma_alloc) from []
(ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
[] (ath10k_htt_tx_alloc [ath10k_core]) from
[] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
[] (ath10k_core_start [ath10k_core]) from
[] (ath10k_start+0xbc/0x56c [ath10k_core])
[] (ath10k_start [ath10k_core]) from
[] (drv_start+0x40/0x5c [mac80211])
[] (drv_start [mac80211]) from []
(ieee80211_do_open+0x170/0x82c [mac80211])
[] (ieee80211_do_open [mac80211]) from
[] (__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 <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c   |  5 +--
 drivers/net/wireless/ath/ath10k/htt.h|  6 +++-
 drivers/net/wireless/ath/ath10k/htt_tx.c | 54 +---
 3 files changed, 51 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 5bc6847..f7ea4de 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1857,7 +1857,7 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode,
goto err_wmi_detach;
}
 
-   status = ath10k_htt_tx_alloc(>htt);
+   status = ath10k_htt_tx_start(>htt);
if (status) {
ath10k_err(ar, "failed to alloc htt tx: %d\n", status);
goto err_wmi_detach;
@@ -2052,7 +2052,7 @@ void ath10k_core_stop(struct ath10k *ar)
ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
 
ath10k_hif_stop(ar);
-   ath10k_htt_tx_free(>htt);
+   ath10k_htt_tx_stop(>htt);
ath10k_htt_rx_free(>htt);
ath10k_wmi_detach(ar);
 }
@@ -2385,6 +2385,7 @@ void ath10k_core_destroy(struct ath10k *ar)
destroy_workqueue(ar->workqueue_aux);
 
ath10k_debug_destroy(ar);
+   ath10k_htt_tx_destroy(>htt);
ath10k_wmi_free_host_mem(ar);
ath10k_mac_destroy(ar);
 }
diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09..96bf7bf 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1692,6 +1692,8 @@ struct ath10k_htt {
enum htt_tx_mode_switch_mode mode;
enum htt_q_depth_type type;
} tx_q_state;
+
+   bool tx_mem_allocated;
 };
 
 #define RX_HTT_HDR_STATUS_LEN 64
@@ -1754,7 +1756,9 @@ struct htt_rx_desc {
 int ath10k_htt_init(struct ath10k *ar);
 int ath10k_htt_setup(struct ath10k_htt *htt);
 
-int ath10k_htt_tx_alloc(struct ath10k_htt *htt);
+int ath10k_htt_tx_start(struct ath10k_htt *htt);
+void ath10k_htt_tx_stop(struct ath10k_htt *htt);
+void ath10k_htt_tx_destroy(struct ath10k_htt *htt);
 void ath10k_htt_tx_free(struct ath10k_htt *htt);
 
 int ath10k_htt_rx_alloc(struct ath10k_htt *htt);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ccbc8c03..27e49db 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -350,21 +350,15 @@ static int ath10k_htt_tx_alloc_txdone_fifo(struct 
ath10k_htt *htt)
return ret;
 }
 
-int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
+static int ath

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

On Tue, Nov 29, 2016 at 04:43:48PM -0800, Ben Greear wrote:
> I have not seen this hang since adding this patch, so
> hopefully it has resolved the problem.

thanks Ben ! I had updated the commit log with Fixes tag
https://patchwork.kernel.org/patch/9453609/

> 
> On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> >During firmware crash (or) user requested manual restart
> >the system gets into a soft lock up state because of the
> >below root cause.
> >
> >During user requested hardware restart / firmware crash
> >the system goes into a soft lockup state as 'napi_synchronize'
> >is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> >bit) and it sleeps into infinite loop as it waits for
> >'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> >'ath10k_hif_stop' is called twice as below (resulting in calling
> >'napi_synchronize' after 'napi_disable')
> >
> >'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> >-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> >'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> >
> >Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> >as it makes more sense before informing mac80211 to restart h/w
> >Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> >
> >Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >---
> >[thanks to Kalle and Michal for their inputs]
> >
> > drivers/net/wireless/ath/ath10k/core.c | 2 +-
> > drivers/net/wireless/ath/ath10k/mac.c  | 1 -
> > 2 files changed, 1 insertion(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> >b/drivers/net/wireless/ath/ath10k/core.c
> >index 7005e2a..5bc6847 100644
> >--- a/drivers/net/wireless/ath/ath10k/core.c
> >+++ b/drivers/net/wireless/ath/ath10k/core.c
> >@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct 
> >*work)
> > switch (ar->state) {
> > case ATH10K_STATE_ON:
> > ar->state = ATH10K_STATE_RESTARTING;
> >-ath10k_hif_stop(ar);
> >+ath10k_halt(ar);
> > ath10k_scan_finish(ar);
> > ieee80211_restart_hw(ar->hw);
> > break;
> >diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> >b/drivers/net/wireless/ath/ath10k/mac.c
> >index 717b2fa..481842b 100644
> >--- a/drivers/net/wireless/ath/ath10k/mac.c
> >+++ b/drivers/net/wireless/ath/ath10k/mac.c
> >@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
> > ar->state = ATH10K_STATE_ON;
> > break;
> > case ATH10K_STATE_RESTARTING:
> >-ath10k_halt(ar);
> > ar->state = ATH10K_STATE_RESTARTED;
> > break;
> > case ATH10K_STATE_ON:
> >
> 
> 
> -- 
> Ben Greear <gree...@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v2 Added Fixes ]

 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..5bc6847 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fa..481842b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[thanks to Kalle and Michal for their inputs]

 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..5bc6847 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fa..481842b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Kernel deadlock when ath10k firmware crashes in hacked 4.7+ kernel.

[Mohammed Shafi Shajakhan]

Hi Ben,

Is this completely sorted out (after changing the locking
to the original existing code ) ?

  spin_lock_bh(>txqs_lock);
  rcu_read_lock();

regards,
shafi

On Wed, Nov 09, 2016 at 05:02:09PM -0800, Ben Greear wrote:
> I should have looked a bit longer.  I was still running the patch
> that acquired rcu-lock before the spinlock in the tx-push-pending.
> 
> I tried with that set to the normal way, and now it did not
> hang.  I'll do some more testing in case I just got lucky.
> 
> Thanks,
> Ben
> 
> On 11/09/2016 04:07 PM, Ben Greear wrote:
> >I have been seeing this for a while, but finally took some time to get some
> >debug info.  This is with modified 4.7 kernel and ath10k firmware for 9984 
> >NIC.
> >But, I suspect this could be a more general problem.
> >
> >An easy way I can reproduce this is to associate a station and then try
> >to change its MTU to 2000.  Firmware crashes due to an assert that I have not
> >debugged yet, but worse, the kernel hangs trying to cleanup.
> >
> >Some notes on the decode below:  I have a counter that makes sure the 
> >tx_push_pending
> >bails out after 2000 loops, and I do not see that printout hit, so it does 
> >not appear
> >to be looping forever in that method.  Maybe something is calling it in a 
> >tight loop
> >though.
> >
> >Maybe we need to abort and clean up the push-pending logic somehow when 
> >firmware has crashed?
> >
> >Suggestions are welcome, and I can gather more debug and reproduce this 
> >easily.
> >
> >
> >Type "apropos word" to search for commands related to "word"...
> >Reading symbols from ./drivers/net/wireless/ath/ath10k/ath10k_core.ko...done.
> >(gdb) l *(ath10k_mac_tx_push_pending+0x6c)
> >0xd4ec is in ath10k_mac_tx_push_pending 
> >(/home/greearb/git/linux-4.7.dev.y/drivers/net/wireless/ath/ath10k/mac.c:4344).
> >4339int loop_max = 2000;
> >4340
> >4341rcu_read_lock();
> >4342spin_lock_bh(>txqs_lock);
> >4343
> >4344last = list_last_entry(>txqs, struct ath10k_txq, list);
> >4345while (!list_empty(>txqs)) {
> >4346artxq = list_first_entry(>txqs, struct ath10k_txq, list);
> >4347txq = container_of((void *)artxq, struct ieee80211_txq,
> >4348   drv_priv);
> >(gdb) l *(ath10k_sta_state+0x1be)
> >0x91ee is in ath10k_sta_state 
> >(/home/greearb/git/linux-4.7.dev.y/drivers/net/wireless/ath/ath10k/mac.c:4212).
> >4207struct ath10k_skb_cb *cb;
> >4208struct sk_buff *msdu;
> >4209struct ieee80211_txq *txq_tmp;
> >4210int msdu_id;
> >4211
> >4212if (!txq)
> >4213return;
> >4214
> >4215spin_lock_bh(>txqs_lock);
> >4216if (!list_empty(>list))
> >(gdb) l *(ath10k_htt_txrx_compl_task+0x54f)
> >0x1ff3f is in ath10k_htt_txrx_compl_task 
> >(/home/greearb/git/linux-4.7.dev.y/include/linux/compiler.h:222).
> >217})
> >218
> >219static __always_inline
> >220void __read_once_size(const volatile void *p, void *res, int size)
> >221{
> >222__READ_ONCE_SIZE;
> >223}
> >224
> >225#ifdef CONFIG_KASAN
> >226/*
> >(gdb)
> >
> >ath10k_pci :05:00.0: firmware crashed! (uuid 
> >adf694ed-1c76-4449-a1de-dd2a8ee596b1)
> >ath10k_pci :05:00.0: firmware register dump:
> >ath10k_pci :05:00.0: [00]: 0x000A 0x15B3 0x0099773F 0x00975B31
> >ath10k_pci :05:00.0: [04]: 0x0099773F 0x00060130 0x 0x
> >ath10k_pci :05:00.0: [08]: 0x00446134 0x0045FA74 0x00446BBC 0x009CF074
> >ath10k_pci :05:00.0: [12]: 0x0009 0x 0x00973ABC 0x00973AD2
> >ath10k_pci :05:00.0: [16]: 0x00973AB0 0x009B76E9 0x009606BB 0x
> >ath10k_pci :05:00.0: [20]: 0x4099773F 0x004066AC 0x0001 0x0047B7D0
> >ath10k_pci :05:00.0: [24]: 0x809977FA 0x0040670C 0x00418B10 0xC099773F
> >ath10k_pci :05:00.0: [28]: 0x80997818 0x0040672C 0x0045FA74 0x00446134
> >ath10k_pci :05:00.0: [32]: 0x8099CA3F 0x0040675C 0x0045FA74 0x0002
> >ath10k_pci :05:00.0: [36]: 0x8098C1E8 0x0040677C 0x 0x0045FA74
> >ath10k_pci :05:00.0: [40]: 0x809B052E 0x0040680C 0x004316B8 0x0043083C
> >ath10k_pci :05:00.0: [44]: 0x809B1E58 0x004068CC 0x00426E5C 0x014A
> >ath10k_pci :05:00.0: [48]: 0x809B1EB2 0x0040690C 0x0040697C 0x00975A00
> >ath10k_pci :05:00.0: [52]: 0x809AFA34 0x0040693C 0x0001 0x0040697C
> >ath10k_pci :05:00.0: [56]: 0x809AF162 0x0040695C 0x0042298C 0x004229B0
> >ath10k_pci :05:00.0: ath10k_pci ATH10K_DBG_BUFFER:
> >ath10k: []: 9C9C 14086402 71103332 AF21F004 3B2C 0042D990 
> >0019 9C9C
> >ath10k: [0008]: 14085854 5112 000F3F54 0001 00B3 004567DC 
> >9C9C 14085854
> >ath10k: [0016]: 5112 000F3F9C 0001 00B2 004567DC 9C9D 
> >10085852 00434198
> >ath10k: [0024]: 004567DC   9C9D 10085858 3112 
> >00434198 000A
> >ath10k: [0032]:  9C9D 17FC0001 0099773F 15B3 15B3 
> >0040659C 91104569
> >ath10k_pci :05:00.0: 

Re: [BUG] Kernel crashes with ath10k radio and Nexus 5X clients

[Mohammed Shafi Shajakhan]

Hi Timo,

sorry had I missed the exact kernel crash call trace ?
I could see only the warnings, can you please post the call
trace of the kernel crash please ?

regards,
shafi

On Sun, Nov 20, 2016 at 02:35:27AM +0100, Timo Sigurdsson wrote:
> Hi Adrian,
> 
> sure - here's the bug report on kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=188201
> 
> Regards,
> 
> Timo
> 
> 
> Adrian Chadd schrieb am 18.11.2016 22:22:
> 
> > hiya!
> > 
> > Can you file a kernel.org bug mentioning this?
> > 
> > thanks!
> > 
> > 
> > -a
> > 
> > 
> > On 18 November 2016 at 01:30, Timo Sigurdsson
> >  wrote:
> >> Hi again,
> >>
> >> in the meantime, I have some more information to add to the issue 
> >> mentioned in
> >> my email quoted further down below.
> >>
> >> Ben Greear approached me off-list and suggested to try the Candela Tech 
> >> ath10k
> >> driver and firmware and see if the issue occurs with that as well. So, for 
> >> the
> >> last 3 weeks I've been testing the CT driver and firmware and I can happily
> >> report that the issue with the driver crashing after a while when a Nexus 
> >> 5X
> >> device is connected is not occuring with the current BETA 18
> >> firmware-2-ct-full-community.bin. So, this really seems like a regression 
> >> in
> >> the official API level 5 ath10k firmware blobs.
> >>
> >> The CT firmware is not perfect either, since it seems to suffer from a
> >> different
> >> bug that has been resolved in the official firmwares, and that is that 
> >> after a
> >> reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only 
> >> after a
> >> hard reset or "cold boot" it will come up. That's an issue I had with older
> >> official firmwares as well, but it has been resolved with the recent API 
> >> level
> >> 5 firmwares.
> >>
> >> Nevertheless, for the time being, I will stick to the CT firmware because I
> >> can
> >> work around the reboot issue and having the 5GHz wifi working for my Nexus 
> >> 5X
> >> clients is more important.
> >>
> >> Over the next weeks, I will test different combinations of ath10k(-ct) 
> >> driver
> >> and firmware to see if there's a combination that resolves all issues. This
> >> morning I flashed a LEDE build with the official ath10k driver and the CT
> >> firmware binary.
> >>
> >> But of course, if someone has more suggestions on what I could try or what
> >> information I could collect to help resolve the issue related to the Nexus 
> >> 5X
> >> clients in the official firmware binaries, I think that would be beneficial
> >> for a larger audience.
> >>
> >> Regards,
> >>
> >> Timo
> >>
> >> P.S.: Please include my email address in any reply, since I'm not 
> >> subscribed
> >> to the mailing list. Thank you.
> >>
> >>
> >> Timo Sigurdsson schrieb am 29.10.2016 22:19:
> >>
> >>> Hi everybody,
> >>>
> >>> I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE 
> >>> (r1952,
> >>> Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for 
> >>> the
> >>> fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel 
> >>> or
> >>> ath10k driver will crash after a while. 5Ghz wifi will be dead after that
> >>> until I reboot the system.
> >>>
> >>> This issue has been reported before [1] and it also has been declared as
> >>> solved with newer firmwares [2] (but reopened by other users). However, 
> >>> even
> >>> with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository 
> >>> the
> >>> issue is far from resolved. I have tried many different firmware revisions
> >>> over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can 
> >>> could
> >>> only find that the issue sometimes takes longer to trigger with some
> >>> firmwares
> >>> (which might just be random), but it would always occur at some point with
> >>> API
> >>> level 5 firmwares. With API level 2 firmwares (which I testesd when I was
> >>> still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had
> >>> other connectivity issues with these older firmwares that made this
> >>> combination no fun to use either. But this shows that the firmware itself
> >>> makes the difference here.
> >>>
> >>> I actually have two Nexus 5X on my network (my wife's and my own). I can
> >>> trigger the crash with either one of them. And if both Nexus 5X are 
> >>> connected
> >>> to the 5Ghz radio, then the issue triggers much faster (can be as low as 
> >>> 15
> >>> minutes). My workaround is to let the Nexus 5X devices only connect to the
> >>> 2.4GHz radio. This way, the device can runs for weeks without any issue or
> >>> crash, but of course I would prefer the actual bug being fixed rather 
> >>> than to
> >>> circumvent it.
> >>>
> >>> I'm appending a syslog from my access point with a crash happening while 
> >>> one
> >>> Nexus 5X was connected to the 5GHz radio starting from the time the system
> >>> booted. I randomized the MAC addresses. but left the first two characters
> >>> unique 

[PATCH] ath10k: Fix crash during rmmod when probe firmware fails

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails

BUG: unable to handle kernel NULL pointer dereference at (null)
IP:  __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
__ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]

Call Trace:

[] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
[ath10k_core]
[] ath10k_htt_txrx_compl_task+0x433/0x17d0
[ath10k_core]
[] ? __wake_up_common+0x4d/0x80
[] ? cpu_load_update+0xdc/0x150
[] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
[] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
[] net_rx_action+0x20f/0x370

Reported-by: Ben Greear <gree...@candelatech.com>
Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..8187eb2 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2165,6 +2165,8 @@ err_free_firmware_files:
 
 err_power_down:
ath10k_hif_power_down(ar);
+   napi_synchronize(>napi);
+   napi_disable(>napi);
 
return ret;
 }
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9888 fails to work with latest linux-ath tree, crashes kernel on rmmod.

[Mohammed Shafi Shajakhan]

On Mon, Oct 24, 2016 at 06:53:06AM -0700, Ben Greear wrote:
> Thanks for fixing this.  Once I got the right board-2.bin file, the 9886 
> (9888?) NIC
> I was using worked pretty well.  Minus a firmware assert in my firmware I'm 
> tracking
> down

[shafi] thanks Ben, i am able to re-create the issue easily by removing the
firmware files from /lib/firmware/ath10k/QCA988X (or) QCA9888 and doing an rmmod

regards,
shafi

> 
> On 10/24/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> >Hi Ben,
> >
> >I had confirmed that the change is addressing the crash, thanks for 
> >reporting.
> >I will soon send the change properly for everyone to review.
> >
> >regards,
> >shafi
> >
> >On Mon, Oct 24, 2016 at 02:02:26PM +0530, Mohammed Shafi Shajakhan wrote:
> >>Hi Ben,
> >>
> >>I think its best to do 'napi_disable' in 'hif_power_down' because
> >>'hif_power_up does 'napi_enable'.
> >>
> >>regards,
> >>shafi
> >>
> >>On Thu, Oct 20, 2016 at 11:51:44AM +0530, Mohammed Shafi Shajakhan wrote:
> >>>Hi,
> >>>
> >>>On Wed, Oct 19, 2016 at 02:42:39PM -0700, Ben Greear wrote:
> >>>>Code-aura's board-2.bin for 9888 seems to fix the most obvious errors,
> >>>>but that does not excuse crashing the kernel on rmmod
> >>>
> >>>i guess it could be crashing @ idx = 
> >>>__le32_to_cpu(*htt->rx_ring.alloc_idx.vaddr); in 
> >>>'__ath10k_htt_rx_ring_fill_n'
> >>>because 'ath10k_htt_rx_alloc' would be never called if loading board-2.bin
> >>>fails!!
> >>>
> >>>should we check for 'ATH10K_FLAG_CORE_REGISTERED' in the 
> >>>ath10k_pci_napi_poll and just bail
> >>>out ? is it clean ? or should we do 'napi_disable(>napi);' in the error
> >>>case of ath10k probe failure
> >>>
> >>>
> >>>>
> >>>>Thanks,
> >>>>Ben
> >>>>
> >>>>On 10/19/2016 01:18 PM, Ben Greear wrote:
> >>>>>Stock firmware, stock driver.  Should it be loading board-2.bin?
> >>>>>
> >>>>>
> >>>>>dmesg|grep ath10k
> >>>>>
> >>>>>[5.386372] ath10k_pci :05:00.0: pci probe 168c:0056 :
> >>>>>[5.387695] ath10k_pci :05:00.0: boot pci_mem 0xc90005c0
> >>>>>[5.388087] ath10k_pci :05:00.0: pci irq msi oper_irq_mode 2 
> >>>>>irq_mode 0 reset_mode 0
> >>>>>[5.388117] ath10k_pci :05:00.0: boot qca99x0 chip reset
> >>>>>[5.388118] ath10k_pci :05:00.0: boot cold reset
> >>>>>[5.431228] ath10k_pci :05:00.0: boot cold reset complete
> >>>>>[5.431230] ath10k_pci :05:00.0: boot waiting target to initialise
> >>>>>[5.431234] ath10k_pci :05:00.0: boot target indicator 2
> >>>>>[5.431240] ath10k_pci :05:00.0: boot target initialised
> >>>>>[5.431241] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> >>>>>(cold)
> >>>>>[5.431251] ath10k_pci :05:00.0: boot hif power up
> >>>>>[5.431260] ath10k_pci :05:00.0: boot qca99x0 chip reset
> >>>>>[5.431262] ath10k_pci :05:00.0: boot cold reset
> >>>>>[5.475237] ath10k_pci :05:00.0: boot cold reset complete
> >>>>>[5.475239] ath10k_pci :05:00.0: boot waiting target to initialise
> >>>>>[5.475243] ath10k_pci :05:00.0: boot target indicator 2
> >>>>>[5.475249] ath10k_pci :05:00.0: boot target initialised
> >>>>>[5.475250] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> >>>>>(cold)
> >>>>>[5.475271] ath10k_pci :05:00.0: boot init ce src ring id 0 
> >>>>>entries 16 base_addr 88021e427000
> >>>>>[5.475289] ath10k_pci :05:00.0: boot ce dest ring id 1 entries 
> >>>>>512 base_addr 88021e428000
> >>>>>[5.475306] ath10k_pci :05:00.0: boot ce dest ring id 2 entries 
> >>>>>128 base_addr 88021e42a000
> >>>>>[5.475328] ath10k_pci :05:00.0: boot init ce src ring id 3 
> >>>>>entries 32 base_addr 88021e42b000
> >>>>>[5.475352] ath10k_pci :05:00.0: boot init ce src ring id 4 
> >>>>>entries 8192 base_addr 88021e46
> >>>&

Re: QCA9888 fails to work with latest linux-ath tree, crashes kernel on rmmod.

[Mohammed Shafi Shajakhan]

Hi Ben,

I had confirmed that the change is addressing the crash, thanks for reporting.
I will soon send the change properly for everyone to review.

regards,
shafi

On Mon, Oct 24, 2016 at 02:02:26PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Ben,
> 
> I think its best to do 'napi_disable' in 'hif_power_down' because
> 'hif_power_up does 'napi_enable'.
> 
> regards,
> shafi
> 
> On Thu, Oct 20, 2016 at 11:51:44AM +0530, Mohammed Shafi Shajakhan wrote:
> > Hi,
> > 
> > On Wed, Oct 19, 2016 at 02:42:39PM -0700, Ben Greear wrote:
> > > Code-aura's board-2.bin for 9888 seems to fix the most obvious errors,
> > > but that does not excuse crashing the kernel on rmmod
> > 
> > i guess it could be crashing @ idx = 
> > __le32_to_cpu(*htt->rx_ring.alloc_idx.vaddr); in 
> > '__ath10k_htt_rx_ring_fill_n'
> > because 'ath10k_htt_rx_alloc' would be never called if loading board-2.bin
> > fails!!
> > 
> > should we check for 'ATH10K_FLAG_CORE_REGISTERED' in the 
> > ath10k_pci_napi_poll and just bail
> > out ? is it clean ? or should we do 'napi_disable(>napi);' in the error
> > case of ath10k probe failure
> > 
> > 
> > > 
> > > Thanks,
> > > Ben
> > > 
> > > On 10/19/2016 01:18 PM, Ben Greear wrote:
> > > >Stock firmware, stock driver.  Should it be loading board-2.bin?
> > > >
> > > >
> > > >dmesg|grep ath10k
> > > >
> > > >[5.386372] ath10k_pci :05:00.0: pci probe 168c:0056 :
> > > >[5.387695] ath10k_pci :05:00.0: boot pci_mem 0xc90005c0
> > > >[5.388087] ath10k_pci :05:00.0: pci irq msi oper_irq_mode 2 
> > > >irq_mode 0 reset_mode 0
> > > >[5.388117] ath10k_pci :05:00.0: boot qca99x0 chip reset
> > > >[5.388118] ath10k_pci :05:00.0: boot cold reset
> > > >[5.431228] ath10k_pci :05:00.0: boot cold reset complete
> > > >[5.431230] ath10k_pci :05:00.0: boot waiting target to initialise
> > > >[5.431234] ath10k_pci :05:00.0: boot target indicator 2
> > > >[5.431240] ath10k_pci :05:00.0: boot target initialised
> > > >[5.431241] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> > > >(cold)
> > > >[5.431251] ath10k_pci :05:00.0: boot hif power up
> > > >[5.431260] ath10k_pci :05:00.0: boot qca99x0 chip reset
> > > >[5.431262] ath10k_pci :05:00.0: boot cold reset
> > > >[5.475237] ath10k_pci :05:00.0: boot cold reset complete
> > > >[5.475239] ath10k_pci :05:00.0: boot waiting target to initialise
> > > >[5.475243] ath10k_pci :05:00.0: boot target indicator 2
> > > >[5.475249] ath10k_pci :05:00.0: boot target initialised
> > > >[5.475250] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> > > >(cold)
> > > >[5.475271] ath10k_pci :05:00.0: boot init ce src ring id 0 
> > > >entries 16 base_addr 88021e427000
> > > >[5.475289] ath10k_pci :05:00.0: boot ce dest ring id 1 entries 
> > > >512 base_addr 88021e428000
> > > >[5.475306] ath10k_pci :05:00.0: boot ce dest ring id 2 entries 
> > > >128 base_addr 88021e42a000
> > > >[5.475328] ath10k_pci :05:00.0: boot init ce src ring id 3 
> > > >entries 32 base_addr 88021e42b000
> > > >[5.475352] ath10k_pci :05:00.0: boot init ce src ring id 4 
> > > >entries 8192 base_addr 88021e46
> > > >[5.475370] ath10k_pci :05:00.0: boot ce dest ring id 5 entries 
> > > >512 base_addr 88021e42c000
> > > >[5.475391] ath10k_pci :05:00.0: boot init ce src ring id 7 
> > > >entries 2 base_addr 88021e42e000
> > > >[5.475408] ath10k_pci :05:00.0: boot ce dest ring id 7 entries 2 
> > > >base_addr 88021e42f000
> > > >[5.475425] ath10k_pci :05:00.0: boot ce dest ring id 8 entries 
> > > >128 base_addr 88021e471000
> > > >[5.486663] ath10k_pci :05:00.0: Hardware name qca9888 hw2.0 
> > > >version 0x100
> > > >[5.491339] ath10k_pci :05:00.0: Direct firmware load for 
> > > >ath10k/pre-cal-pci-:05:00.0.bin failed with error -2
> > > >[5.491358] ath10k_pci :05:00.0: Direct firmware load for 
> > > >ath10k/cal-pci-:05:00.0.bin failed with error -2
> > > >[5.491361] ath10k_pci 

Re: QCA9888 fails to work with latest linux-ath tree, crashes kernel on rmmod.

[Mohammed Shafi Shajakhan]

Hi Ben,

I think its best to do 'napi_disable' in 'hif_power_down' because
'hif_power_up does 'napi_enable'.

regards,
shafi

On Thu, Oct 20, 2016 at 11:51:44AM +0530, Mohammed Shafi Shajakhan wrote:
> Hi,
> 
> On Wed, Oct 19, 2016 at 02:42:39PM -0700, Ben Greear wrote:
> > Code-aura's board-2.bin for 9888 seems to fix the most obvious errors,
> > but that does not excuse crashing the kernel on rmmod
> 
> i guess it could be crashing @ idx = 
> __le32_to_cpu(*htt->rx_ring.alloc_idx.vaddr); in '__ath10k_htt_rx_ring_fill_n'
> because 'ath10k_htt_rx_alloc' would be never called if loading board-2.bin
> fails!!
> 
> should we check for 'ATH10K_FLAG_CORE_REGISTERED' in the ath10k_pci_napi_poll 
> and just bail
> out ? is it clean ? or should we do 'napi_disable(>napi);' in the error
> case of ath10k probe failure
> 
> 
> > 
> > Thanks,
> > Ben
> > 
> > On 10/19/2016 01:18 PM, Ben Greear wrote:
> > >Stock firmware, stock driver.  Should it be loading board-2.bin?
> > >
> > >
> > >dmesg|grep ath10k
> > >
> > >[5.386372] ath10k_pci :05:00.0: pci probe 168c:0056 :
> > >[5.387695] ath10k_pci :05:00.0: boot pci_mem 0xc90005c0
> > >[5.388087] ath10k_pci :05:00.0: pci irq msi oper_irq_mode 2 
> > >irq_mode 0 reset_mode 0
> > >[5.388117] ath10k_pci :05:00.0: boot qca99x0 chip reset
> > >[5.388118] ath10k_pci :05:00.0: boot cold reset
> > >[5.431228] ath10k_pci :05:00.0: boot cold reset complete
> > >[5.431230] ath10k_pci :05:00.0: boot waiting target to initialise
> > >[5.431234] ath10k_pci :05:00.0: boot target indicator 2
> > >[5.431240] ath10k_pci :05:00.0: boot target initialised
> > >[5.431241] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> > >(cold)
> > >[5.431251] ath10k_pci :05:00.0: boot hif power up
> > >[5.431260] ath10k_pci :05:00.0: boot qca99x0 chip reset
> > >[5.431262] ath10k_pci :05:00.0: boot cold reset
> > >[5.475237] ath10k_pci :05:00.0: boot cold reset complete
> > >[5.475239] ath10k_pci :05:00.0: boot waiting target to initialise
> > >[5.475243] ath10k_pci :05:00.0: boot target indicator 2
> > >[5.475249] ath10k_pci :05:00.0: boot target initialised
> > >[5.475250] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> > >(cold)
> > >[5.475271] ath10k_pci :05:00.0: boot init ce src ring id 0 entries 
> > >16 base_addr 88021e427000
> > >[5.475289] ath10k_pci :05:00.0: boot ce dest ring id 1 entries 512 
> > >base_addr 88021e428000
> > >[5.475306] ath10k_pci :05:00.0: boot ce dest ring id 2 entries 128 
> > >base_addr 88021e42a000
> > >[5.475328] ath10k_pci :05:00.0: boot init ce src ring id 3 entries 
> > >32 base_addr 88021e42b000
> > >[5.475352] ath10k_pci :05:00.0: boot init ce src ring id 4 entries 
> > >8192 base_addr 88021e46
> > >[5.475370] ath10k_pci :05:00.0: boot ce dest ring id 5 entries 512 
> > >base_addr 88021e42c000
> > >[5.475391] ath10k_pci :05:00.0: boot init ce src ring id 7 entries 
> > >2 base_addr 88021e42e000
> > >[5.475408] ath10k_pci :05:00.0: boot ce dest ring id 7 entries 2 
> > >base_addr 88021e42f000
> > >[5.475425] ath10k_pci :05:00.0: boot ce dest ring id 8 entries 128 
> > >base_addr 88021e471000
> > >[5.486663] ath10k_pci :05:00.0: Hardware name qca9888 hw2.0 
> > >version 0x100
> > >[5.491339] ath10k_pci :05:00.0: Direct firmware load for 
> > >ath10k/pre-cal-pci-:05:00.0.bin failed with error -2
> > >[5.491358] ath10k_pci :05:00.0: Direct firmware load for 
> > >ath10k/cal-pci-:05:00.0.bin failed with error -2
> > >[5.491361] ath10k_pci :05:00.0: trying fw api 5
> > >[5.517095] ath10k_pci :05:00.0: found fw version 10.4-3.2-00072
> > >[5.517098] ath10k_pci :05:00.0: found fw timestamp 1464346445
> > >[5.517099] ath10k_pci :05:00.0: found otp image ie (8975 B)
> > >[5.517101] ath10k_pci :05:00.0: found fw image ie (351748 B)
> > >[5.517102] ath10k_pci :05:00.0: found firmware features ie (2 B)
> > >[5.517103] ath10k_pci :05:00.0: Enabling feature bit: 3
> > >[5.517105] ath10k_pci :05:00.0: Enabling feature bit: 12
> > >[5.517106] ath10k_pci :05:00.0: Enabli

Re: QCA9888 fails to work with latest linux-ath tree, crashes kernel on rmmod.

[Mohammed Shafi Shajakhan]

Hi,

On Wed, Oct 19, 2016 at 02:42:39PM -0700, Ben Greear wrote:
> Code-aura's board-2.bin for 9888 seems to fix the most obvious errors,
> but that does not excuse crashing the kernel on rmmod

i guess it could be crashing @ idx = 
__le32_to_cpu(*htt->rx_ring.alloc_idx.vaddr); in '__ath10k_htt_rx_ring_fill_n'
because 'ath10k_htt_rx_alloc' would be never called if loading board-2.bin
fails!!

should we check for 'ATH10K_FLAG_CORE_REGISTERED' in the ath10k_pci_napi_poll 
and just bail
out ? is it clean ? or should we do 'napi_disable(>napi);' in the error
case of ath10k probe failure


> 
> Thanks,
> Ben
> 
> On 10/19/2016 01:18 PM, Ben Greear wrote:
> >Stock firmware, stock driver.  Should it be loading board-2.bin?
> >
> >
> >dmesg|grep ath10k
> >
> >[5.386372] ath10k_pci :05:00.0: pci probe 168c:0056 :
> >[5.387695] ath10k_pci :05:00.0: boot pci_mem 0xc90005c0
> >[5.388087] ath10k_pci :05:00.0: pci irq msi oper_irq_mode 2 irq_mode 
> >0 reset_mode 0
> >[5.388117] ath10k_pci :05:00.0: boot qca99x0 chip reset
> >[5.388118] ath10k_pci :05:00.0: boot cold reset
> >[5.431228] ath10k_pci :05:00.0: boot cold reset complete
> >[5.431230] ath10k_pci :05:00.0: boot waiting target to initialise
> >[5.431234] ath10k_pci :05:00.0: boot target indicator 2
> >[5.431240] ath10k_pci :05:00.0: boot target initialised
> >[5.431241] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> >(cold)
> >[5.431251] ath10k_pci :05:00.0: boot hif power up
> >[5.431260] ath10k_pci :05:00.0: boot qca99x0 chip reset
> >[5.431262] ath10k_pci :05:00.0: boot cold reset
> >[5.475237] ath10k_pci :05:00.0: boot cold reset complete
> >[5.475239] ath10k_pci :05:00.0: boot waiting target to initialise
> >[5.475243] ath10k_pci :05:00.0: boot target indicator 2
> >[5.475249] ath10k_pci :05:00.0: boot target initialised
> >[5.475250] ath10k_pci :05:00.0: boot qca99x0 chip reset complete 
> >(cold)
> >[5.475271] ath10k_pci :05:00.0: boot init ce src ring id 0 entries 
> >16 base_addr 88021e427000
> >[5.475289] ath10k_pci :05:00.0: boot ce dest ring id 1 entries 512 
> >base_addr 88021e428000
> >[5.475306] ath10k_pci :05:00.0: boot ce dest ring id 2 entries 128 
> >base_addr 88021e42a000
> >[5.475328] ath10k_pci :05:00.0: boot init ce src ring id 3 entries 
> >32 base_addr 88021e42b000
> >[5.475352] ath10k_pci :05:00.0: boot init ce src ring id 4 entries 
> >8192 base_addr 88021e46
> >[5.475370] ath10k_pci :05:00.0: boot ce dest ring id 5 entries 512 
> >base_addr 88021e42c000
> >[5.475391] ath10k_pci :05:00.0: boot init ce src ring id 7 entries 2 
> >base_addr 88021e42e000
> >[5.475408] ath10k_pci :05:00.0: boot ce dest ring id 7 entries 2 
> >base_addr 88021e42f000
> >[5.475425] ath10k_pci :05:00.0: boot ce dest ring id 8 entries 128 
> >base_addr 88021e471000
> >[5.486663] ath10k_pci :05:00.0: Hardware name qca9888 hw2.0 version 
> >0x100
> >[5.491339] ath10k_pci :05:00.0: Direct firmware load for 
> >ath10k/pre-cal-pci-:05:00.0.bin failed with error -2
> >[5.491358] ath10k_pci :05:00.0: Direct firmware load for 
> >ath10k/cal-pci-:05:00.0.bin failed with error -2
> >[5.491361] ath10k_pci :05:00.0: trying fw api 5
> >[5.517095] ath10k_pci :05:00.0: found fw version 10.4-3.2-00072
> >[5.517098] ath10k_pci :05:00.0: found fw timestamp 1464346445
> >[5.517099] ath10k_pci :05:00.0: found otp image ie (8975 B)
> >[5.517101] ath10k_pci :05:00.0: found fw image ie (351748 B)
> >[5.517102] ath10k_pci :05:00.0: found firmware features ie (2 B)
> >[5.517103] ath10k_pci :05:00.0: Enabling feature bit: 3
> >[5.517105] ath10k_pci :05:00.0: Enabling feature bit: 12
> >[5.517106] ath10k_pci :05:00.0: Enabling feature bit: 13
> >[5.517107] ath10k_pci :05:00.0: features
> >[5.517109] ath10k_pci :05:00.0: : 08 30 00 00 00 00 00 00
> >  .0..
> >[5.517111] ath10k_pci :05:00.0: found fw ie wmi op version 6
> >[5.517112] ath10k_pci :05:00.0: found fw ie htt op version 4
> >[5.517113] ath10k_pci :05:00.0: found fw code swap image ie (204335 
> >B)
> >[5.517114] ath10k_pci :05:00.0: using fw api 5
> >[5.517118] ath10k_pci :05:00.0: qca9888 hw2.0 target 0x0100 
> >chip_id 0x sub :
> >[5.517119] ath10k_pci :05:00.0: kconfig debug 1 debugfs 1 tracing 1 
> >dfs 1 testmode 1
> >[5.517645] ath10k_pci :05:00.0: firmware ver 10.4-3.2-00072 api 5 
> >features no-p2p,mfp,peer-flow-ctrl crc32 b1da0716
> >[5.517647] ath10k_pci :05:00.0: boot did not find a pre calibration 
> >file, try DT next: -2
> >[5.517648] ath10k_pci :05:00.0: unable to load pre cal data 

[PATCH v3 1/2] ath10k: clean up HTT tx buffer allocation and free

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

cleanup 'ath10k_htt_tx_alloc' by introducing the API's
'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
re-use them whereever needed

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_tx.c |   75 --
 1 file changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ae5b33f..ab2ee90 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -229,6 +229,32 @@ void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, 
u16 msdu_id)
idr_remove(>pending_tx, msdu_id);
 }
 
+static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt *htt)
+{
+   struct ath10k *ar = htt->ar;
+   size_t size;
+
+   if (!htt->txbuf.vaddr)
+   return;
+
+   size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+   dma_free_coherent(ar->dev, size, htt->txbuf.vaddr, htt->txbuf.paddr);
+}
+
+static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
+{
+   struct ath10k *ar = htt->ar;
+   size_t size;
+
+   size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+   htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size, >txbuf.paddr,
+ GFP_KERNEL);
+   if (!htt->txbuf.vaddr)
+   return -ENOMEM;
+
+   return 0;
+}
+
 static void ath10k_htt_tx_free_cont_frag_desc(struct ath10k_htt *htt)
 {
size_t size;
@@ -310,10 +336,26 @@ static int ath10k_htt_tx_alloc_txq(struct ath10k_htt *htt)
return 0;
 }
 
+static void ath10k_htt_tx_free_txdone_fifo(struct ath10k_htt *htt)
+{
+   WARN_ON(!kfifo_is_empty(>txdone_fifo));
+   kfifo_free(>txdone_fifo);
+}
+
+static int ath10k_htt_tx_alloc_txdone_fifo(struct ath10k_htt *htt)
+{
+   int ret;
+   size_t size;
+
+   size = roundup_pow_of_two(htt->max_num_pending_tx);
+   ret = kfifo_alloc(>txdone_fifo, size, GFP_KERNEL);
+   return ret;
+}
+
 int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
 {
struct ath10k *ar = htt->ar;
-   int ret, size;
+   int ret;
 
ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
   htt->max_num_pending_tx);
@@ -321,13 +363,9 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
spin_lock_init(>tx_lock);
idr_init(>pending_tx);
 
-   size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
-   htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
- >txbuf.paddr,
- GFP_KERNEL);
-   if (!htt->txbuf.vaddr) {
-   ath10k_err(ar, "failed to alloc tx buffer\n");
-   ret = -ENOMEM;
+   ret = ath10k_htt_tx_alloc_cont_txbuf(htt);
+   if (ret) {
+   ath10k_err(ar, "failed to alloc cont tx buffer: %d\n", ret);
goto free_idr_pending_tx;
}
 
@@ -343,8 +381,7 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
goto free_frag_desc;
}
 
-   size = roundup_pow_of_two(htt->max_num_pending_tx);
-   ret = kfifo_alloc(>txdone_fifo, size, GFP_KERNEL);
+   ret = ath10k_htt_tx_alloc_txdone_fifo(htt);
if (ret) {
ath10k_err(ar, "failed to alloc txdone fifo: %d\n", ret);
goto free_txq;
@@ -359,10 +396,7 @@ free_frag_desc:
ath10k_htt_tx_free_cont_frag_desc(htt);
 
 free_txbuf:
-   size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
-   dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
+   ath10k_htt_tx_free_cont_txbuf(htt);
 
 free_idr_pending_tx:
idr_destroy(>pending_tx);
@@ -388,22 +422,13 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, 
void *skb, void *ctx)
 
 void ath10k_htt_tx_free(struct ath10k_htt *htt)
 {
-   int size;
-
idr_for_each(>pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
idr_destroy(>pending_tx);
 
-   if (htt->txbuf.vaddr) {
-   size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
-   dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
-   }
-
+   ath10k_htt_tx_free_cont_txbuf(htt);
ath10k_htt_tx_free_txq(htt);
ath10k_htt_tx_free_cont_frag_desc(htt);
-   WARN_ON(!kfifo_is_empty(>txdone_fifo));
-   kfifo_free(>txdone_fifo);
+   ath10k_htt_tx_free_txdone_fifo(htt);
 }
 
 void ath10k_htt_htc_tx_compl

[PATCH v3 2/2] ath10k: Remove extraneous error message in tx alloc

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc'
as the caller 'ath10k_htt_tx_alloc' already dumps a proper error
message

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_tx.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ab2ee90..ccbc8c03 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -282,10 +282,8 @@ static int ath10k_htt_tx_alloc_cont_frag_desc(struct 
ath10k_htt *htt)
htt->frag_desc.vaddr = dma_alloc_coherent(ar->dev, size,
  >frag_desc.paddr,
  GFP_KERNEL);
-   if (!htt->frag_desc.vaddr) {
-   ath10k_err(ar, "failed to alloc fragment desc memory\n");
+   if (!htt->frag_desc.vaddr)
return -ENOMEM;
-   }
 
return 0;
 }
-- 
1.7.9.5


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/2] ath10k: clean up HTT tx buffer allocation and free

[Mohammed Shafi Shajakhan]

Hi Kalle,

On Tue, Oct 11, 2016 at 01:36:22PM +0200, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> > 
> > cleanup 'ath10k_htt_tx_alloc' by introducing the API's
> > 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
> > re-use them whereever needed
> > 
> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> 
> Applies but fails to build:

[shafi] sorry for the trouble again, I just figured out I had a private patch by
mistake  and it worked for me, I will make sure that v3 is properly rebased
without any errors.

> 
> drivers/net/wireless/ath/ath10k/htt_tx.c: In function ‘ath10k_htt_tx_free’:
> drivers/net/wireless/ath/ath10k/htt_tx.c:424:19: error: ‘struct ath10k_htt’ 
> has no member named ‘txrx_compl_task’
> make[5]: *** [drivers/net/wireless/ath/ath10k/htt_tx.o] Error 1
> make[4]: *** [drivers/net/wireless/ath/ath10k] Error 2
> make[3]: *** [drivers/net/wireless/ath] Error 2
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [drivers] Error 2
> 
> 2 patches set to Changes Requested.
> 
> 9363863 [v2,1/2] ath10k: clean up HTT tx buffer allocation and free
> 9363861 [v2,2/2] ath10k: Remove extraneous error message in tx alloc
> 
> -- 
> https://patchwork.kernel.org/patch/9363863/
> 
> Documentation about submitting wireless patches and checking status
> from patchwork:
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2 2/2] ath10k: Remove extraneous error message in tx alloc

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc'
as the caller 'ath10k_htt_tx_alloc' already dumps a proper error
message

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v2 rebased over top of tree]

 drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 786fbd7..4255c1a 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -283,10 +283,8 @@ static int ath10k_htt_tx_alloc_cont_frag_desc(struct 
ath10k_htt *htt)
htt->frag_desc.vaddr = dma_alloc_coherent(ar->dev, size,
  >frag_desc.paddr,
  GFP_KERNEL);
-   if (!htt->frag_desc.vaddr) {
-   ath10k_err(ar, "failed to alloc fragment desc memory\n");
+   if (!htt->frag_desc.vaddr)
return -ENOMEM;
-   }
 
return 0;
 }
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2 1/2] ath10k: clean up HTT tx buffer allocation and free

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

cleanup 'ath10k_htt_tx_alloc' by introducing the API's
'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
re-use them whereever needed

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v2 rebased over top of tree]

 drivers/net/wireless/ath/ath10k/htt_tx.c | 76 ++--
 1 file changed, 52 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ae5b33f..786fbd7 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -229,6 +229,33 @@ void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, 
u16 msdu_id)
idr_remove(>pending_tx, msdu_id);
 }
 
+static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt *htt)
+{
+   size_t size;
+
+   if (!htt->txbuf.vaddr)
+   return;
+
+   size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+   dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
+ htt->txbuf.paddr);
+}
+
+static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
+{
+   struct ath10k *ar = htt->ar;
+   size_t size;
+
+   size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+   htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
+ >txbuf.paddr,
+ GFP_KERNEL);
+   if (!htt->txbuf.vaddr)
+   return -ENOMEM;
+
+   return 0;
+}
+
 static void ath10k_htt_tx_free_cont_frag_desc(struct ath10k_htt *htt)
 {
size_t size;
@@ -310,10 +337,26 @@ static int ath10k_htt_tx_alloc_txq(struct ath10k_htt *htt)
return 0;
 }
 
+static void ath10k_htt_tx_free_txdone_fifo(struct ath10k_htt *htt)
+{
+   WARN_ON(!kfifo_is_empty(>txdone_fifo));
+   kfifo_free(>txdone_fifo);
+}
+
+static int ath10k_htt_tx_alloc_txdone_fifo(struct ath10k_htt *htt)
+{
+   int ret;
+   size_t size;
+
+   size = roundup_pow_of_two(htt->max_num_pending_tx);
+   ret = kfifo_alloc(>txdone_fifo, size, GFP_KERNEL);
+   return ret;
+}
+
 int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
 {
struct ath10k *ar = htt->ar;
-   int ret, size;
+   int ret;
 
ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
   htt->max_num_pending_tx);
@@ -321,13 +364,9 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
spin_lock_init(>tx_lock);
idr_init(>pending_tx);
 
-   size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
-   htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
- >txbuf.paddr,
- GFP_KERNEL);
-   if (!htt->txbuf.vaddr) {
-   ath10k_err(ar, "failed to alloc tx buffer\n");
-   ret = -ENOMEM;
+   ret = ath10k_htt_tx_alloc_cont_txbuf(htt);
+   if (ret) {
+   ath10k_err(ar, "failed to alloc cont tx buffer: %d\n", ret);
goto free_idr_pending_tx;
}
 
@@ -343,8 +382,7 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
goto free_frag_desc;
}
 
-   size = roundup_pow_of_two(htt->max_num_pending_tx);
-   ret = kfifo_alloc(>txdone_fifo, size, GFP_KERNEL);
+   ret = ath10k_htt_tx_alloc_txdone_fifo(htt);
if (ret) {
ath10k_err(ar, "failed to alloc txdone fifo: %d\n", ret);
goto free_txq;
@@ -359,10 +397,7 @@ free_frag_desc:
ath10k_htt_tx_free_cont_frag_desc(htt);
 
 free_txbuf:
-   size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
-   dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
+   ath10k_htt_tx_free_cont_txbuf(htt);
 
 free_idr_pending_tx:
idr_destroy(>pending_tx);
@@ -388,22 +423,15 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, 
void *skb, void *ctx)
 
 void ath10k_htt_tx_free(struct ath10k_htt *htt)
 {
-   int size;
+   tasklet_kill(>txrx_compl_task);
 
idr_for_each(>pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
idr_destroy(>pending_tx);
 
-   if (htt->txbuf.vaddr) {
-   size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
-   dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
-   }
-
+   ath10k_htt_tx_free_cont_txbuf(htt);
ath10k_htt_tx_free_txq(htt);
ath10k_htt_tx_free_cont_frag_desc(htt);
-   WARN_ON(!kfifo_is_empt

Re: [1/2] ath10k: clean up HTT tx buffer allocation and free

[Mohammed Shafi Shajakhan]

On Thu, Oct 06, 2016 at 09:31:41AM +0200, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> > 
> > cleanup 'ath10k_htt_tx_alloc' by introducing the API's
> > 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
> > re-use them whereever needed
> > 
> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> 
> Patch 1 doesn't apply and the conflict was not trivial

[shafi] oops will rebase it, not sure how i missed it :-(

> 
> error: patch failed: drivers/net/wireless/ath/ath10k/htt_tx.c:388
> error: drivers/net/wireless/ath/ath10k/htt_tx.c: patch does not apply
> stg import: Diff does not apply cleanly
> error: patch failed: drivers/net/wireless/ath/ath10k/htt_tx.c:283
> error: drivers/net/wireless/ath/ath10k/htt_tx.c: patch does not apply
> stg import: Diff does not apply cleanly
> 
> 2 patches set to Changes Requested.
> 
> 9361741 [1/2] ath10k: clean up HTT tx buffer allocation and free
> 9361743 [2/2] ath10k: Remove extraneous error message in tx alloc
> 
> -- 
> https://patchwork.kernel.org/patch/9361741/
> 
> Documentation about submitting wireless patches and checking status
> from patchwork:
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k: Cleanup calling ath10k_htt_rx_h_unchain

[Mohammed Shafi Shajakhan]

On Tue, Oct 04, 2016 at 05:30:17PM +0200, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> > 
> > 'ath10k_htt_rx_h_unchain' is need to be called only if the return
> > value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> > change makes it more explicit and avoids doing a skb_peek, fetching
> > rx descriptor pointer, checking rx msdu decap format for the case of
> > ret = 0 (unchained msdus). Found this change during code walk through,
> > not sure if this addresses any issue.
> > 
> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> 
> Failed to apply to pending branch
> 
> error: patch failed: drivers/net/wireless/ath/ath10k/htt_rx.c:1550
> error: drivers/net/wireless/ath/ath10k/htt_rx.c: patch does not apply
> stg import: Diff does not apply cleanly

[shafi] thanks, will rebase/fix this and send a v2
> 
> Patch set to Changes Requested.
> 
> -- 
> https://patchwork.kernel.org/patch/9351833/
> 
> Documentation about submitting wireless patches and checking status
> from patchwork:
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 2/2] ath10k: Remove extraneous error message in tx alloc

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc'
as the caller 'ath10k_htt_tx_alloc' already dumps a proper error
message

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 786fbd7..4255c1a 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -283,10 +283,8 @@ static int ath10k_htt_tx_alloc_cont_frag_desc(struct 
ath10k_htt *htt)
htt->frag_desc.vaddr = dma_alloc_coherent(ar->dev, size,
  >frag_desc.paddr,
  GFP_KERNEL);
-   if (!htt->frag_desc.vaddr) {
-   ath10k_err(ar, "failed to alloc fragment desc memory\n");
+   if (!htt->frag_desc.vaddr)
return -ENOMEM;
-   }
 
return 0;
 }
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Cleanup calling ath10k_htt_rx_h_unchain

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

'ath10k_htt_rx_h_unchain' is need to be called only if the return
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
change makes it more explicit and avoids doing a skb_peek, fetching
rx descriptor pointer, checking rx msdu decap format for the case of
ret = 0 (unchained msdus). Found this change during code walk through,
not sure if this addresses any issue.

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7ae9349..e51dace 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1459,8 +1459,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu)
 }
 
 static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
-   struct sk_buff_head *amsdu,
-   bool chained)
+   struct sk_buff_head *amsdu)
 {
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -1471,9 +1470,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
decap = MS(__le32_to_cpu(rxd->msdu_start.common.info1),
   RX_MSDU_START_INFO1_DECAP_FORMAT);
 
-   if (!chained)
-   return;
-
/* FIXME: Current unchaining logic can only handle simple case of raw
 * msdu chaining. If decapping is other than raw the chaining may be
 * more complex and this isn't handled by the current code. Don't even
@@ -1550,7 +1546,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt 
*htt)
}
 
ath10k_htt_rx_h_ppdu(ar, , rx_status, 0x);
-   ath10k_htt_rx_h_unchain(ar, , ret > 0);
+
+   /* only for ret = 1 indicates chained msdus */
+   if (ret > 0)
+   ath10k_htt_rx_h_unchain(ar, );
+
ath10k_htt_rx_h_filter(ar, , rx_status);
ath10k_htt_rx_h_mpdu(ar, , rx_status);
ath10k_htt_rx_h_deliver(ar, , rx_status);
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v4] ath10k: Cleanup calling ath10k_htt_rx_h_unchain

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

'ath10k_htt_rx_h_unchain' is need to be called only if the return
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
change makes it more explicit and avoids doing a skb_peek, fetching
rx descriptor pointer, checking rx msdu decap format for the case of
ret = 0 (unchained msdus). Found this change during code walk through,
not sure if this addresses any issue.

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7ae9349..e51dace 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1459,8 +1459,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu)
 }
 
 static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
-   struct sk_buff_head *amsdu,
-   bool chained)
+   struct sk_buff_head *amsdu)
 {
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -1471,9 +1470,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
decap = MS(__le32_to_cpu(rxd->msdu_start.common.info1),
   RX_MSDU_START_INFO1_DECAP_FORMAT);
 
-   if (!chained)
-   return;
-
/* FIXME: Current unchaining logic can only handle simple case of raw
 * msdu chaining. If decapping is other than raw the chaining may be
 * more complex and this isn't handled by the current code. Don't even
@@ -1550,7 +1546,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt 
*htt)
}
 
ath10k_htt_rx_h_ppdu(ar, , rx_status, 0x);
-   ath10k_htt_rx_h_unchain(ar, , ret > 0);
+
+   /* only for ret = 1 indicates chained msdus */
+   if (ret > 0)
+   ath10k_htt_rx_h_unchain(ar, );
+
ath10k_htt_rx_h_filter(ar, , rx_status);
ath10k_htt_rx_h_mpdu(ar, , rx_status);
ath10k_htt_rx_h_deliver(ar, , rx_status);
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v5] ath10k: Fix broken NULL func data frame status for 10.4

[Mohammed Shafi Shajakhan]

On Thu, Sep 08, 2016 at 05:09:03AM +, Valo, Kalle wrote:
> "Shajakhan, Mohammed Shafi (Mohammed Shafi)" 
> writes:
> > please revert this patch, Raj suggested this patch introduced a
> > regression in sending NULL func frames :(
> >
> > We will fix the wrong tx status report for NULL func frames
> > appropriately (if needed in ath10k firmware) Sorry for the regression,
> > kindly revert it until a proper fix is figured out.
> 
> Like we discussed privately, it is better that you send the revert (or a
> fix if you find one) yourself. Then we have a proper commit log etc.
>
[shafi] thanks Kalle, agreed the revert is under hold (to fix this properly
and not make use of this workaround)

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Remove unnecessary error code assignment

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

The error assigned does not seems to be used anywhere,
fixes nothing just a small cleanup

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index eb2831c..3117a71 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3544,7 +3544,6 @@ void ath10k_wmi_event_host_swba(struct ath10k *ar, struct 
sk_buff *skb)
ath10k_warn(ar, "failed to map beacon: %d\n",
ret);
dev_kfree_skb_any(bcn);
-   ret = -EIO;
goto skip;
}
 
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v5] ath10k: Fix broken NULL func data frame status for 10.4

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Older firmware with HTT delivers incorrect tx status for null func
frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
Also this workaround results in reporting of incorrect null func status
for 10.4. Fix this is by introducing a firmware feature flag for 10.4
so that this workaround is skipped and proper tx status for null func
frames are reported

Signed-off-by: Tamizh chelvam <c_tr...@qti.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v5 based on the review comments from Michal]

 drivers/net/wireless/ath/ath10k/core.c |1 +
 drivers/net/wireless/ath/ath10k/core.h |7 +++
 drivers/net/wireless/ath/ath10k/mac.c  |2 ++
 3 files changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index e889829..798b3f8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -304,6 +304,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
[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",
 };
 
 static unsigned int ath10k_core_get_fw_feature_str(char *buf,
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf..54e40f3 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -551,6 +551,13 @@ enum ath10k_fw_features {
 */
ATH10K_FW_FEATURE_BTCOEX_PARAM = 14,
 
+   /* Older firmware with HTT delivers incorrect tx status for null func
+* frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
+* Also this workaround results in reporting of incorrect null func
+* status for 10.4. This flag is used to skip the workaround.
+*/
+   ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR = 15,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
 };
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index fb8e38d..7508ef8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3255,6 +3255,8 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
if (ar->htt.target_version_major < 3 &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
+ ar->running_fw->fw_file.fw_features) &&
+   !test_bit(ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR,
  ar->running_fw->fw_file.fw_features))
return ATH10K_HW_TXRX_MGMT;
 
-- 
1.7.9.5


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 3/3] ath10k: Improve logging message.

[Mohammed Shafi Shajakhan]

Hi Ben,

On Thu, Aug 18, 2016 at 06:26:35PM -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> Helps to know the sta pointer.
> 
> Signed-off-by: Ben Greear 
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index d96c06e..82bc0da 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -6491,8 +6491,8 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
>* Existing station deletion.
>*/
>   ath10k_dbg(ar, ATH10K_DBG_MAC,
> -"mac vdev %d peer delete %pM (sta gone)\n",
> -arvif->vdev_id, sta->addr);
> +"mac vdev %d peer delete %pM (sta gone) sta: %p\n",
> +arvif->vdev_id, sta->addr, sta);

good to rebase over Maharaja's change (%p to %pK) 
https://patchwork.kernel.org/patch/9263691/

>  
>   ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
>   if (ret)
> -- 
> 2.4.11
> 
> 
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Remove driver log suggesting QCA9887 support is experimental

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Support for QCA9887 is no longer experimental and if there are any issues
we need to address them

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index f06dd39..f3d943c 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3144,7 +3144,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
pci_hard_reset = ath10k_pci_qca988x_chip_reset;
break;
case QCA9887_1_0_DEVICE_ID:
-   dev_warn(>dev, "QCA9887 support is still experimental, 
there are likely bugs. You have been warned.\n");
hw_rev = ATH10K_HW_QCA9887;
pci_ps = false;
pci_soft_reset = ath10k_pci_warm_reset;
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

On Wed, Jul 20, 2016 at 02:22:29PM +0200, Michal Kazior wrote:
> On 20 July 2016 at 13:43, Shajakhan, Mohammed Shafi (Mohammed Shafi)
>  wrote:
> > Michal,
> >
> > Can you please let me know if this change is fine or not ?
> > I am waiting infinitely for  your reply long time
> 
> Sorry. I was absent for a while and this email slipped by.

[shafi] ah ok, i thought you had blacklisted this change :)

> 
> Quoting your other email:
> 
> > is this patch is good to go (or) should i re-work  ?
> > I had replied to Michal's comment of introducing a new firmware
> > feature flag will not address the issue in older firmware / code.
> > Let me know if i had missed something very obvious.
> 
> I couldn't really find any conclusion to this thread in my inbox.
> 
> The hw_params approach is definitely wrong. The ACK problem is
> firmware-specific, not hardware-specific.

[shafi] sure let me see if i can figure out an alternative way that shall be
accepted by you and Kalle

> 
> I'm fine with removing the workaround completely if 636 is guaranteed
> to not be broken, including AP and P2P GO operation. The client
> operation will probably work since wmi-roam event is used for HW
> connection monitoring.

[shafi] sorry i am not sure how to validate that, so i will keep this workaround

> 
> Nullfunc tx-status ack/noack reports could be probably fixed up using
> sta kickout events (with short timeouts) as a fallback. This would
> make it easier for users because otherwise they'd need to enable
> disassoc_low_ack in hostapd (which is probably impossible with
> wpa_supplicant for p2p, no?).
> 
>
[shafi] let me check this, i think we usually don't enable disassoc_low_ack to
avoid kicking out stations frequently.

shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[RESEND PATCH v4] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
NULL func status (always acked/successs !!) when hostapd does a
PROBE_CLIENT via nullfunc frames when the station is powered off
abruptly (inactive timer probes client via null func after the inactive
time reaches beyond the threshold). Fix this by disabling the workaround
introduced by the change ("ath10k: fix beacon loss handling ") for
QCA99X0 and later chipsets. The normal tx path provides the proper
status for NULL data frames. As of now disable this workaround for
chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
completely get rid of this workaround for all the chipsets

Signed-off-by: Tamizh chelvam <c_tr...@qti.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 3 +++
 drivers/net/wireless/ath/ath10k/core.h | 1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index dcc76b6..8687aaa 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
{
@@ -204,6 +205,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
{
@@ -262,6 +264,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..d3dfda0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -750,6 +750,7 @@ struct ath10k {
const char *board;
size_t board_size;
size_t board_ext_size;
+   bool disable_null_func_workaround;
} fw;
} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..f1e9672 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3236,6 +3236,7 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
 * mode though because AP don't sleep.
 */
if (ar->htt.target_version_major < 3 &&
+   !ar->hw_params.fw.disable_null_func_workaround &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
  ar->running_fw->fw_file.fw_features))
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

Hi Michal / Kalle / Ben,

is this patch is good to go (or) should i re-work  ?
I had replied to Michal's comment of introducing a new firmware
feature flag will not address the issue in older firmware / code.
Let me know if i had missed something very obvious.


On Tue, Jul 05, 2016 at 08:21:01AM -0700, Ben Greear wrote:
> On 06/30/2016 03:25 AM, Valo, Kalle wrote:
> >Ben Greear  writes:
> >
> >>Is there a better way than posting to the ath10k mailing list?  There are 
> >>quite
> >>a few more of my patches that are stuck in pending or ignored state.  If you
> >>could review some of them and add them to your testing trees then it might 
> >>help
> >>them go upstream.
> >
> >Yes, as you seem to test with your custom ath10k and custom firmware
> >review and testing feedback from others is more than welcome. That way I
> >can have more confidence that the patch really works with the mainline
> >version.
> >
> >The problem with your patches is that you dump more responsibility on
> >me. I have no idea if they work with the mainline kernel, or if they
> >break something, so I need to personally test the patch and that takes
> >time. Basically I have a rule if that I need to use more than two
> >minutes on a patch it goes to the Deferred queue and I'll go through
> >that less often than the normal patch queue.
> 
> I can do some testing with stock firmware, but stock firmware is often quite 
> limited
> so I cannot do the more interesting test cases that we use internally.
> Some of my patches are for fixing edge cases that cannot be easily reproduced,
> and that code really needs to be reviewed for correctness more by looking at
> the code than by trying to run some exhaustive test case.
> 
> I think if there were a specific maintainer for ath10k that could take a more
> active role, especially with regard to keeping a fairly wide variety of test 
> rigs
> around to run regression tests, then it would help all involved.  I think 
> this person
> needs access to firmware source so that they can more easily verify the driver
> matches the firmware:  Many of the regressions and bug fixes, for instance 
> with
> stats, would be much easier to clean up if you look at firmware while 
> developing
> the driver bits.
>

regards,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

On Thu, Jun 30, 2016 at 11:09:31AM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <moham...@codeaurora.org> writes:
> 
> > Hi Kalle,
> >
> > On Thu, Jun 30, 2016 at 10:49:02AM +, Valo, Kalle wrote:
> >> Kalle Valo <kv...@qca.qualcomm.com> writes:
> >> 
> >> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
> >> >> ath10k_hw_params_list[] = {
> >> >> .board = QCA4019_HW_1_0_BOARD_DATA_FILE,
> >> >> .board_size = QCA4019_BOARD_DATA_SZ,
> >> >> .board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> >> >> +   .extd_peer_stats = true,
> >> >> },
> >> >> },
> >> >>  };
> >> >
> >> > This is not a hardware feature so hw_params is not really the right
> >> > place to handle this. In the pending branch I tried to solve this a bit
> >> > differently:
> >> >
> >> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ecf4daadc7677518ec7185dbddab959ac6e2db96
> >> >
> >> > I added a bool "extended" to struct ath10k_fw_stats which is used to
> >> > detect if extended stats are used. Would that work? Please note that I
> >> > have only compile tested the patch.
> >
> > [shafi] thanks for taking time to do this, the change looks fine to me !
> > since 'ath10k_sta_update_rx_duration' is called right after 
> > 'ath10k_wmi_pull_fw_stats'
> > this should properly update the rx_duration based on the current data
> 
> Could you also run some tests to make sure? I don't trust my own code :)
>
[shafi] sure no problem, will do that, thanks for fixing this properly

regards,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

Hi Kalle,

On Thu, Jun 30, 2016 at 10:49:02AM +, Valo, Kalle wrote:
> Kalle Valo  writes:
> 
> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
> >> ath10k_hw_params_list[] = {
> >>.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
> >>.board_size = QCA4019_BOARD_DATA_SZ,
> >>.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> >> +  .extd_peer_stats = true,
> >>},
> >>},
> >>  };
> >
> > This is not a hardware feature so hw_params is not really the right
> > place to handle this. In the pending branch I tried to solve this a bit
> > differently:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ecf4daadc7677518ec7185dbddab959ac6e2db96
> >
> > I added a bool "extended" to struct ath10k_fw_stats which is used to
> > detect if extended stats are used. Would that work? Please note that I
> > have only compile tested the patch.

[shafi] thanks for taking time to do this, the change looks fine to me !
since 'ath10k_sta_update_rx_duration' is called right after 
'ath10k_wmi_pull_fw_stats'
this should properly update the rx_duration based on the current data

> 
> Here's a diff of what I did:
> 
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 58932c09efc5..b734345ab598 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -180,7 +180,6 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>   .board_size = QCA99X0_BOARD_DATA_SZ,
>   .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> - .extd_peer_stats = true,
>   },
>   },
>   {
> @@ -203,7 +202,6 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA9984_HW_1_0_BOARD_DATA_FILE,
>   .board_size = QCA99X0_BOARD_DATA_SZ,
>   .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> - .extd_peer_stats = true,
>   },
>   },
>   {
> @@ -261,7 +259,6 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>   .board_size = QCA4019_BOARD_DATA_SZ,
>   .board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> - .extd_peer_stats = true,
>   },
>   },
>  };
> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> b/drivers/net/wireless/ath/ath10k/core.h
> index 73a0b1ae1559..3707d8a707a2 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -263,6 +263,7 @@ struct ath10k_fw_stats_pdev {
>  };
>  
>  struct ath10k_fw_stats {
> + bool extended;
>   struct list_head pdevs;
>   struct list_head vdevs;
>   struct list_head peers;
> @@ -754,7 +755,6 @@ struct ath10k {
>   const char *board;
>   size_t board_size;
>   size_t board_ext_size;
> - bool extd_peer_stats;
>   } fw;
>   } hw_params;
>  
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> b/drivers/net/wireless/ath/ath10k/debug.c
> index 001c0a144614..355e1ae665f9 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -327,6 +327,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
>  {
>   spin_lock_bh(>data_lock);
>   ar->debug.fw_stats_done = false;
> + ar->debug.fw_stats.extended = false;
>   ath10k_fw_stats_pdevs_free(>debug.fw_stats.pdevs);
>   ath10k_fw_stats_vdevs_free(>debug.fw_stats.vdevs);
>   ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
> diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c 
> b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> index af3d49af9eab..0da8a57e0ba7 100644
> --- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> +++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> @@ -19,14 +19,14 @@
>  #include "debug.h"
>  
>  static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
> -  struct list_head *head)
> +  struct ath10k_fw_stats 
> *stats)
>  {
> - struct ieee80211_sta *sta;
>   struct ath10k_fw_extd_stats_peer *peer;
> + struct ieee80211_sta *sta;
>   struct ath10k_sta *arsta;
>  
>   rcu_read_lock();
> - list_for_each_entry(peer, head, list) {
> + list_for_each_entry(peer, >peers_extd, list) {
>   sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
>  NULL);
>   if (!sta)
> @@ -38,13 +38,14 @@ static void 
> 

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

Hello Michal/ Kalle,

On Tue, Jun 28, 2016 at 08:48:38AM +0200, Michal Kazior wrote:
> On 27 June 2016 at 16:36, Mohammed Shafi Shajakhan
> <moham...@codeaurora.org> wrote:
> > Hi Michal,
> >
> > thanks for the review ..
> >
> > On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
> >> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
> >> <moham...@qti.qualcomm.com> wrote:
> >> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >> >
> >> > For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
> >> > NULL func status (always acked/successs !!) when hostapd does a
> >> > PROBE_CLIENT via nullfunc frames when the station is powered off
> >> > abruptly (inactive timer probes client via null func after the inactive
> >> > time reaches beyond the threshold). Fix this by disabling the workaround
> >> > (getting the ACK status of NULL func frames by sending via HTT mgmt-tx
> >> >  path) introduced by the change ("ath10k: fix beacon loss handling ")
> >> > for QCA99X0 and later chipsets. The normal tx path provides the proper
> >> > ACK status for NULL data frames. As of now disable this workaround for
> >> > chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
> >> > completely get rid of this workaround for all the chipsets
> >> >
> >> > Signed-off-by: Tamizh chelvam <c_tr...@qti.qualcomm.com>
> >> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >> > ---
> >> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
> >> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++
> >> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
> >> >  3 files changed, 10 insertions(+)
> >> >
> >> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> >> > b/drivers/net/wireless/ath/ath10k/core.c
> >> > index 689d6ce..9978e4a 100644
> >> > --- a/drivers/net/wireless/ath/ath10k/core.c
> >> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
> >> > ath10k_hw_params_list[] = {
> >> > .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
> >> > .board_size = QCA99X0_BOARD_DATA_SZ,
> >> > .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> >> > +   .disable_null_func_workaround = true,
> >>
> >> Tx completion (bugs) are firmware specific, not hardware. This should
> >> be expressed via features bits in ath10k FW API, no?
> >>
> >>
> > [shafi] Are you suggesting me to introduce something like
> > "ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?
> >
> > Also how about getting this workaround completely if Ben had fixed this in 
> > his tree,
> > will this affect older 10.2.4 ?
> 
> There's still 636.
> 
> We could probably get rid of this as long as:
>  - ath10k can express the need to use Probe Requests for AP probing
> (in client mode) and beacon loss handling purposes instead of NullFunc
> to mac80211
>  - everyone uses hostapd with disassoc_low_ack=1 with affected
> firmware revisions
>  - supplicant uses disassoc_low_ack=1 for p2p go
>  - I have no idea about mesh/ibss but they might require some work as well
> 
> Otherwise you'll introduce regressions.
>

[shafi] sure then we will disable this for 10.4 (QCA99X0 and later)

*firmware feature requires a new firmware updated this feature, so the bug
will be present for all the older firmware, please correct me if my
understanding is wrong

*We discussed wmi_op_version is not the way to go (in the sense just disable it
for 10.4 alone)

Let me know if there is any other suggestion (the existing change though bit
cleanly is very explicit regarding the chipsets that this workaround is not
needed), thank you !

regards,
shafi


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

Hi Michal,

thanks for the review ..

On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
> <moham...@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> > For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
> > NULL func status (always acked/successs !!) when hostapd does a
> > PROBE_CLIENT via nullfunc frames when the station is powered off
> > abruptly (inactive timer probes client via null func after the inactive
> > time reaches beyond the threshold). Fix this by disabling the workaround
> > (getting the ACK status of NULL func frames by sending via HTT mgmt-tx
> >  path) introduced by the change ("ath10k: fix beacon loss handling ")
> > for QCA99X0 and later chipsets. The normal tx path provides the proper
> > ACK status for NULL data frames. As of now disable this workaround for
> > chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
> > completely get rid of this workaround for all the chipsets
> >
> > Signed-off-by: Tamizh chelvam <c_tr...@qti.qualcomm.com>
> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++
> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
> >  3 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> > b/drivers/net/wireless/ath/ath10k/core.c
> > index 689d6ce..9978e4a 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
> > ath10k_hw_params_list[] = {
> > .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
> > .board_size = QCA99X0_BOARD_DATA_SZ,
> > .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> > +   .disable_null_func_workaround = true,
> 
> Tx completion (bugs) are firmware specific, not hardware. This should
> be expressed via features bits in ath10k FW API, no?
> 
>
[shafi] Are you suggesting me to introduce something like
"ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?

Also how about getting this workaround completely if Ben had fixed this in his 
tree,
will this affect older 10.2.4 ?

regards,
shafi


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

Hello Ben,

On Thu, Jun 23, 2016 at 10:12:01AM -0700, Ben Greear wrote:
> On 06/23/2016 09:40 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> >For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
> >NULL func status (always acked/successs !!) when hostapd does a
> >PROBE_CLIENT via nullfunc frames when the station is powered off
> >abruptly (inactive timer probes client via null func after the inactive
> >time reaches beyond the threshold). Fix this by disabling the workaround
> >(getting the ACK status of NULL func frames by sending via HTT mgmt-tx
> >  path) introduced by the change ("ath10k: fix beacon loss handling ")
> >for QCA99X0 and later chipsets. The normal tx path provides the proper
> >ACK status for NULL data frames. As of now disable this workaround for
> >chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
> >completely get rid of this workaround for all the chipsets
> 
> Did you see my fix for the tx-status that Kalle posted about recently?
> That fixed my problem with 9980, but I normally test status with tx over
> the htt mgt path instead of wmi path, so possibly that makes a difference.

[shafi] Yes Kalle suggested to try your change (BTW we were not aware that you
already discovered this problem !!), https://patchwork.kernel.org/patch/8460831/
but ..


"[ 747.803652] ath10k_pci :01:00.0: htt tx completion msdu_id 0 discard 0
no_ack 0 success 1"

"[ 747.803843] ath10k_pci 0001:01:00.0: htt tx completion msdu_id 0 discard 0
no_ack 0 success 1"

to be more precise looks like we hit this path for MSG type 0xE,( management Tx
completion indication) path(status ok ??) for null func frame without ACK

case HTT_MGMT_TX_STATUS_OK:
tx_done.status = HTT_TX_COMPL_STATE_ACK;
break;


a) The success bit being 'set' without the fix so the change you had mentioned 
may not help
for the upstreamed f/w, should we  give a shot with your change as well to
confirm it ?

b) and also the workaround is for older firmware which got fixed in
10.2.4 and 10.4, if you can help us that 10.1 also reports NULL func frame
status properly via normal data path, we can probably get rid of this workaround
once and for all ? thoughts ?

regards,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 1/2] ath10k: Replace warning with an error message if HTT op version is unset

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Print an ath10k error message rather a call trace when HTT op version is
not found from firmware META data (IE). This should be sufficient to figure
out what went wrong.

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index dfb3db0..689d6ce 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1675,7 +1675,7 @@ static int ath10k_core_init_firmware_features(struct 
ath10k *ar)
case ATH10K_FW_WMI_OP_VERSION_10_4:
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
-   WARN_ON(1);
+   ath10k_err(ar, "htt op version not found from fw meta 
data");
return -EINVAL;
}
}
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Bug with: ath10k: enable parsing per station rx duration for 10.4?

[Mohammed Shafi Shajakhan]

On Tue, Jun 21, 2016 at 07:10:28AM -0700, Ben Greear wrote:
> 
> 
> On 06/20/2016 10:18 PM, Mohammed Shafi Shajakhan wrote:
> >Hi Ben,
> >
> >thanks for reporting ...
> >
> >On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote:
> >>I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 
> >>firmware, and I think
> >>I may have found a regression.
> >
> >[shafi] let me know what is the issue.. some steps to recreate the issue.
> 
> ethtool -S wlan0
> or similar should reproduce it.
> 
> You would see stats timeout messages in dmesg, and with a bit more debugging,
> you notice that the driver is basically busy-spinning trying to get stats over
> WMI and/or it is giving errors because skb pull fails because there actually 
> is
> not extd stats struct.

https://patchwork.kernel.org/patch/9149357/
 should help (Kalle had a cleaned up version in his pending branch
> 
> >>
> >>My 10.4.3-ish firmware source has a bunch of:
> >>
> >>if (stats_id == WMI_REQUEST_PEER_STAT)
> >>logic in it.  In other words, it is not using that id as a bitfield.
> >
> >[shafi] will check this.
> 
> I fixed my firmware to treat it as a bitfield, and to specifically un-set the 
> EXTD stats
> bit, and now it works with my 4.7.  Firmware fix should be backwards 
> compatible.
> 
> 
> >>Now, I can fix the firmware, but I am guessing that at least some stock
> >>10.4 firmware has this same issue, and of course any older firmware
> >>that does not have this change will still be broken.
> >>
> >>So, do you want to back out this patch below, at least the part where it 
> >>sends
> >>in 0x9 as the stats_id?
> >
> >[shafi] request if you can check this please, there was some misunderstanding
> >in the design when this feature got enabled in 10.4, we fixed it in
> >https://patchwork.kernel.org/patch/9149357/
> 
> That might have fixed it, but it is not in 4.7, so I didn't have it
> in my tree when testing yesterday.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <gree...@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Bug with: ath10k: enable parsing per station rx duration for 10.4?

[Mohammed Shafi Shajakhan]

Hi Ben,

thanks for reporting ...

On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote:
> I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 
> firmware, and I think
> I may have found a regression.

[shafi] let me know what is the issue.. some steps to recreate the issue.
> 
> My 10.4.3-ish firmware source has a bunch of:
> 
> if (stats_id == WMI_REQUEST_PEER_STAT)
> logic in it.  In other words, it is not using that id as a bitfield.

[shafi] will check this.

> 
> Now, I can fix the firmware, but I am guessing that at least some stock
> 10.4 firmware has this same issue, and of course any older firmware
> that does not have this change will still be broken.
> 
> So, do you want to back out this patch below, at least the part where it sends
> in 0x9 as the stats_id?

[shafi] request if you can check this please, there was some misunderstanding
in the design when this feature got enabled in 10.4, we fixed it in
https://patchwork.kernel.org/patch/9149357/

> 
> Or, is all available upstream 10.4 firmware OK with this and I should just 
> fix mine?
> 
> Or possibly, this is all my fault and I somehow screwed up when rebasing

[shafi] i will check this and get back to you by end of day.

regards,
shafi
> 
> 
> Author: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>  2016-03-16 
> 05:43:34
> Committer: Kalle Valo <kv...@qca.qualcomm.com>  2016-04-04 07:02:47
> Parent: 47771902a9beb23859805721f1d98d03dee5da7c (ath10k: introduce Extended 
> Resource Config support for 10.4)
> Child:  59465fe46ef1c2caf2c1beca828c4f29d28b98ca (ath10k: speedup htt rx 
> descriptor processing for tx completion)
> Branches: master, master.stgit, remotes/origin/master, 
> remotes/origin/master.stgit
> Follows: v4.5-rc5
> Precedes: v4.7-rc1
> 
> ath10k: enable parsing per station rx duration for 10.4
> 
> Rx duration support for per station is part of extended peer
> stats, enable provision to parse the same and provide backward
> compatibility based on the 'stats_id' event
> 
> Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kv...@qca.qualcomm.com>
> 
> 
> 
> @@ -1615,7 +1615,8 @@ static int ath10k_core_init_firmware_features(struct 
> ath10k *ar)
>   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_STAT_PEER;
> + ar->fw_stats_req_mask = WMI_10_4_STAT_PEER |
> + WMI_10_4_STAT_PEER_EXTD;
>   ar->max_spatial_stream = ar->hw_params.max_spatial_stream;
> 
>   if (test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
> 
> 
> -- 
> Ben Greear <gree...@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> 
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix a typo in spectral code commments

[Mohammed Shafi Shajakhan]

On Thu, Jun 16, 2016 at 11:59:59AM -0400, Bob Copeland wrote:
> On Tue, Jun 14, 2016 at 11:03:54AM +0530, Mohammed Shafi Shajakhan wrote:
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> > 
> > Found this obvious typo while going through the spectral
> > code design in ath10k
> 
> > /* TODO: As experiments with an analogue sender and various
> > -* configuaritions (fft-sizes of 64/128/256 and 20/40/80 Mhz)
> > +* configurations (fft-sizes of 64/128/256 and 20/40/80 Mhz)
> >  * show, the particular configuration of 80 MHz/64 bins does
> >  * not match with the other smaples at all. Until the reason
> >  * for that is found, don't report these samples.
> 
> Also "smaples" :)

[shafi]  goodness me will that as well !

> 
> -- 
> Bob Copeland %% http://bobcopeland.com/

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v4 2/2] ath10k: Remove debugfs support for Per STA total rx duration

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

cfg80211/nl80211 interface changes for per STA total rx-duration and
very basic 'ath10k_sta_statistics'  mac80211 callback is implemented
to extend support for per station statistics from the driver.

Also provision in 'iw dev wlan#N station dump' to parse rx-duration
is supported. So its safer to remove the debugfs entry for per STA
rx-duration

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v4 rebased over pending branch]

 drivers/net/wireless/ath/ath10k/debugfs_sta.c | 24 
 1 file changed, 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c 
b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 60e5da0..9955fea 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -293,28 +293,6 @@ static const struct file_operations fops_delba = {
.llseek = default_llseek,
 };
 
-static ssize_t ath10k_dbg_sta_read_rx_duration(struct file *file,
-  char __user *user_buf,
-  size_t count, loff_t *ppos)
-{
-   struct ieee80211_sta *sta = file->private_data;
-   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
-   char buf[100];
-   int len = 0;
-
-   len = scnprintf(buf, sizeof(buf),
-   "%llu usecs\n", arsta->rx_duration);
-
-   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
-}
-
-static const struct file_operations fops_rx_duration = {
-   .read = ath10k_dbg_sta_read_rx_duration,
-   .open = simple_open,
-   .owner = THIS_MODULE,
-   .llseek = default_llseek,
-};
-
 void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_sta *sta, struct dentry *dir)
 {
@@ -323,6 +301,4 @@ void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
debugfs_create_file("addba", S_IWUSR, dir, sta, _addba);
debugfs_create_file("addba_resp", S_IWUSR, dir, sta, _addba_resp);
debugfs_create_file("delba", S_IWUSR, dir, sta, _delba);
-   debugfs_create_file("rx_duration", S_IRUGO, dir, sta,
-   _rx_duration);
 }
-- 
1.9.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Fix a typo in spectral code commments

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Found this obvious typo while going through the spectral
code design in ath10k

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/spectral.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/spectral.c 
b/drivers/net/wireless/ath/ath10k/spectral.c
index 4671cfb..4510906 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -101,7 +101,7 @@ int ath10k_spectral_process_fft(struct ath10k *ar,
break;
case 80:
/* TODO: As experiments with an analogue sender and various
-* configuaritions (fft-sizes of 64/128/256 and 20/40/80 Mhz)
+* configurations (fft-sizes of 64/128/256 and 20/40/80 Mhz)
 * show, the particular configuration of 80 MHz/64 bins does
 * not match with the other smaples at all. Until the reason
 * for that is found, don't report these samples.
-- 
1.7.9.5


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] ath10k: Remove unneccessary WARN_ON_ONCE in rx during ACS

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

The below warning message seems to hit occasionally with the following
combination (IPQ4019 + ACS scan) where we receive packets as a self peer
when hostapd does ACS when we bring up AP mode . ath10k has the below
fall back mechanism to fetch current operating channel in rx (it will
check for the next channel tracking variable if the current one is NULL)

[scan channel] --> [rx channel] --> [peer channel] -->
[vdev channel] -->  [any vdev channel] --> [target oper channel]

'scan channel' and 'target operating channel' are directly fetched from
firmware events. All the others should be updated by mac80211.

During ACS scan we wouldn't have a valid channel context
assigned from mac80211 ('ar->rx_channel'), and also relying on
('ar->scan_channel') is not helpful (it becomes NULL when it goes to
BSS channel and also when the scan event is completed). In short we
cannot always rely on these two channel tracking variables.

'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of
the current operating even while we are doing ACS scan and etc. Hence
remove this un-necessary warning message and continue with
target_operating channel. At the worst case scenario when the target
operating channel is invalid (NULL) we already have an ath10k warning
message to notify we really don't have a proper channel configured in
rx to update the rx status("no channel configured; ignoring frame(s)!")

WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803
[] (warn_slowpath_null) from []
(ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core])
[] (ath10k_htt_rx_h_channel [ath10k_core]) from
[] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core])
[] (ath10k_htt_rx_h_ppdu [ath10k_core]) from
[] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core])
[] (ath10k_htt_txrx_compl_task [ath10k_core])

Fixes:3b0499e9ce42 ("ath10k: reduce warning messages during rx without proper 
channel context")
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---

[updated commit log - Michal Kazior]

 drivers/net/wireless/ath/ath10k/htt_rx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7bf1909..aa44c09 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -748,7 +748,7 @@ ath10k_htt_rx_h_peer_channel(struct ath10k *ar, struct 
htt_rx_desc *rxd)
if (WARN_ON_ONCE(!arvif))
return NULL;
 
-   if (WARN_ON_ONCE(ath10k_mac_vif_chan(arvif->vif, )))
+   if (ath10k_mac_vif_chan(arvif->vif, ))
return NULL;
 
return def.chan;
-- 
1.7.9.5


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 0/2] ath10k: Add support for QCA9887

[Mohammed Shafi Shajakhan]

Hi Sven,

On Tue, Jun 07, 2016 at 06:54:54PM +0200, Sven Eckelmann wrote:
> On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote:
> [...]
> > [shafi] it would be helpful if you can share your basic test results (if its
> > possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz.
> > Or both of them were tried ?
> 
> * 5GHz-only (I have no 2.4GHz capable card)
> * card is able to scan
> * card is able to create an AP
> * data can be transferred via AP and client (bidirectional connection)
> * performance was more like 15 Mibit/s for 1x1 HT20 11n devices instead of
>   something like 35-40 Mibit/s

[shafi] sure thanks a lot, this is a good start, i will keep you posted
with my findings and results.

> 
> I cannot give you any more detailed, current performance test results because
> they were done months ago and are most likely not relevant to describe the
> current state. Please ask Kalle if you want to know why the old tests were
> done many, many months ago.

[shafi] sure, hopefully we can get this sorted out. Thank you for the patches
and support.

> 
> Please ask Marek when you want to have tests done with the current
> mac8011+ath10k.

[shafi] thanks

> 
> Kind regards,
>   Sven



___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system

[Mohammed Shafi Shajakhan]

On Thu, Jun 02, 2016 at 08:21:41AM -0700, Ben Greear wrote:
> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
> >Kalle Valo  writes:
> >
> >>there's a regression in ath10k:
> >>
> >>https://bugzilla.kernel.org/show_bug.cgi?id=119151
> >>
> >>Reporter bisected it to this:
> >>
> >>5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
> >>commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
> >>Author: Rajkumar Manoharan 
> >>Date:   Tue Mar 22 17:22:19 2016 +0530
> >>
> >>ath10k: combine txrx and replenish task
> >>
> >>Since tx completion and rx indication processing are moved out
> >>of txrx tasklet and rx ring lock contention also removed from txrx
> >>for rx_ind messages, it would be efficient to combine both replenish
> >>and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
> >>(low and high end systems). With this adjustment in AP135, TCP DL is
> >>improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
> >>to 803 Mbps. Also no watchdog are observed on UDP BiDi.
> >>
> >>Signed-off-by: Rajkumar Manoharan 
> >>Signed-off-by: Kalle Valo 
> >
> >Adding Mike, the bug reporter.
> 
> 
> I found a lot of problems with this code as well, and the 5 patches
> starting from the URL below fixed the issues for me.
> 
> They are stuck as 'NA' in patchwork, but I don't know why.
> 
> http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html
> 
> You probably need this patch as well, or ath10k will crash when you
> enable the debug-mask:
> 
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/151890
> 
> It is also 'NA' in patchwork.

[shafi] i think this is already in the pending branch
https://patchwork.kernel.org/patch/9073471/

> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
> 
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v3 2/2] ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

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

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

This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v2: Enabled the fix for QCA9984 - thanks Kalle]
[v3: removed patch id]

 drivers/net/wireless/ath/ath10k/core.c |3 +++
 drivers/net/wireless/ath/ath10k/core.h |6 +
 drivers/net/wireless/ath/ath10k/hw.h   |   10 
 drivers/net/wireless/ath/ath10k/mac.c  |   39 ++--
 4 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index a003980..2692243 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -148,6 +148,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -170,6 +171,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.has_shifted_cc_wraparound = true,
.otp_exe_param = 0x001,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 125000,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..04cea23 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -716,6 +716,12 @@ struct ath10k {
 */
bool continuous_frag_desc;
 
+   /* CCK hardware rate table mapping for the newer chipsets
+* like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+* are in a proper order with respect to the rate/preamble
+*/
+   bool cck_rate_map_rev2;
+
u32 channel_counters_freq_hz;
 
/* Mgmt tx descriptors threshold for limiting probe response
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91c..4ed5be9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -326,6 +326,16 @@ enum ath10k_hw_rate_cck {
ATH10K_HW_RATE_CCK_SP_2M,
 };
 
+enum ath10k_hw_rate_rev2_cck {
+   ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
+   ATH10K_HW_RATE_REV2_CCK_LP_2M,
+   ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+   ATH10K_HW_RATE_REV2_CCK_LP_11M,
+   ATH10K_HW_RATE_REV2_CCK_SP_2M,
+   ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+   ATH10K_HW_RATE_REV2_CCK_SP_11M,
+};
+
 enum ath10k_hw_4addr_pad {
ATH10K_HW_4ADDR_PAD_AFTER,
ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 1dd415d..e7162db 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -62,6 +62,32 @@ static struct ieee80211_rate ath10k_rates[] = {
{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
 };
 
+static struct ieee80211_rate ath10k_rates_rev2[] = {
+   { .bitrate = 10,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_1M },
+   { .bitrate = 20,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_2M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_2M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+   { .bitrate = 55,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+   

Re: [PATCH v2 1/2] ath10k: remove duplicate and unused rx rate flags

[Mohammed Shafi Shajakhan]

On Thu, Jun 02, 2016 at 01:45:15PM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes:
> 
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> > All these flags are not used and their use is completely
> > covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
> > and RX_PPDU_START_RATE_FLAG
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> > Patchwork-Id: 9129361
> > Signed-off-by: Kalle Valo <kv...@qca.qualcomm.com>
> 
> I guess you took this patch from the pending branch? :) The Patchwork-Id
> line is something which my script adds for patches in the pending
> branch, and removes them before applying them to ath-next, but this line
> should not be visible when submitting patches.
>
[shafi] yes i am sorry :-( will send v3.

regards,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2 1/2] ath10k: remove duplicate and unused rx rate flags

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

All these flags are not used and their use is completely
covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
and RX_PPDU_START_RATE_FLAG

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
Patchwork-Id: 9129361
Signed-off-by: Kalle Valo <kv...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/rx_desc.h |   39 -
 1 file changed, 39 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h 
b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 9ceebea..034e7a5 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -656,26 +656,6 @@ struct rx_msdu_end {
  * Reserved: HW should fill with zero.  FW should ignore.
  */
 
-#define RX_PPDU_START_SIG_RATE_SELECT_OFDM 0
-#define RX_PPDU_START_SIG_RATE_SELECT_CCK  1
-
-#define RX_PPDU_START_SIG_RATE_OFDM_48 0
-#define RX_PPDU_START_SIG_RATE_OFDM_24 1
-#define RX_PPDU_START_SIG_RATE_OFDM_12 2
-#define RX_PPDU_START_SIG_RATE_OFDM_6  3
-#define RX_PPDU_START_SIG_RATE_OFDM_54 4
-#define RX_PPDU_START_SIG_RATE_OFDM_36 5
-#define RX_PPDU_START_SIG_RATE_OFDM_18 6
-#define RX_PPDU_START_SIG_RATE_OFDM_9  7
-
-#define RX_PPDU_START_SIG_RATE_CCK_LP_11  0
-#define RX_PPDU_START_SIG_RATE_CCK_LP_5_5 1
-#define RX_PPDU_START_SIG_RATE_CCK_LP_2   2
-#define RX_PPDU_START_SIG_RATE_CCK_LP_1   3
-#define RX_PPDU_START_SIG_RATE_CCK_SP_11  4
-#define RX_PPDU_START_SIG_RATE_CCK_SP_5_5 5
-#define RX_PPDU_START_SIG_RATE_CCK_SP_2   6
-
 #define HTT_RX_PPDU_START_PREAMBLE_LEGACY0x04
 #define HTT_RX_PPDU_START_PREAMBLE_HT0x08
 #define HTT_RX_PPDU_START_PREAMBLE_HT_WITH_TXBF  0x09
@@ -711,25 +691,6 @@ struct rx_msdu_end {
 /* No idea what this flag means. It seems to be always set in rate. */
 #define RX_PPDU_START_RATE_FLAG BIT(3)
 
-enum rx_ppdu_start_rate {
-   RX_PPDU_START_RATE_OFDM_48M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_48M,
-   RX_PPDU_START_RATE_OFDM_24M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_24M,
-   RX_PPDU_START_RATE_OFDM_12M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_12M,
-   RX_PPDU_START_RATE_OFDM_6M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_6M,
-   RX_PPDU_START_RATE_OFDM_54M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_54M,
-   RX_PPDU_START_RATE_OFDM_36M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_36M,
-   RX_PPDU_START_RATE_OFDM_18M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_18M,
-   RX_PPDU_START_RATE_OFDM_9M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_9M,
-
-   RX_PPDU_START_RATE_CCK_LP_11M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_11M,
-   RX_PPDU_START_RATE_CCK_LP_5_5M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_5_5M,
-   RX_PPDU_START_RATE_CCK_LP_2M   = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_2M,
-   RX_PPDU_START_RATE_CCK_LP_1M   = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_1M,
-   RX_PPDU_START_RATE_CCK_SP_11M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_SP_11M,
-   RX_PPDU_START_RATE_CCK_SP_5_5M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_SP_5_5M,
-   RX_PPDU_START_RATE_CCK_SP_2M   = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_SP_2M,
-};
-
 struct rx_ppdu_start {
struct {
u8 pri20_mhz;
-- 
1.7.9.5


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2 2/2] ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

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

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

This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards

Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v2: Enabled the fix for QCA9984 - thanks Kalle]

 drivers/net/wireless/ath/ath10k/core.c |3 +++
 drivers/net/wireless/ath/ath10k/core.h |6 +
 drivers/net/wireless/ath/ath10k/hw.h   |   10 
 drivers/net/wireless/ath/ath10k/mac.c  |   39 ++--
 4 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index a003980..2692243 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -148,6 +148,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -170,6 +171,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.has_shifted_cc_wraparound = true,
.otp_exe_param = 0x001,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 125000,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..04cea23 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -716,6 +716,12 @@ struct ath10k {
 */
bool continuous_frag_desc;
 
+   /* CCK hardware rate table mapping for the newer chipsets
+* like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+* are in a proper order with respect to the rate/preamble
+*/
+   bool cck_rate_map_rev2;
+
u32 channel_counters_freq_hz;
 
/* Mgmt tx descriptors threshold for limiting probe response
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91c..4ed5be9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -326,6 +326,16 @@ enum ath10k_hw_rate_cck {
ATH10K_HW_RATE_CCK_SP_2M,
 };
 
+enum ath10k_hw_rate_rev2_cck {
+   ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
+   ATH10K_HW_RATE_REV2_CCK_LP_2M,
+   ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+   ATH10K_HW_RATE_REV2_CCK_LP_11M,
+   ATH10K_HW_RATE_REV2_CCK_SP_2M,
+   ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+   ATH10K_HW_RATE_REV2_CCK_SP_11M,
+};
+
 enum ath10k_hw_4addr_pad {
ATH10K_HW_4ADDR_PAD_AFTER,
ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 1dd415d..e7162db 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -62,6 +62,32 @@ static struct ieee80211_rate ath10k_rates[] = {
{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
 };
 
+static struct ieee80211_rate ath10k_rates_rev2[] = {
+   { .bitrate = 10,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_1M },
+   { .bitrate = 20,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_2M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_2M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+   { .bitrate = 55,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+ .flags = IEEE80211_RATE_SH

[PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

10.4 'extended peer stats' will be not be appended with normal peer stats
data and they shall be coming in separate chunks. Fix this by maintaining
a separate linked list 'extender peer stats' for 10.4 and update
rx_duration for per station statistics. Also parse through beacon filter
(if enabled), to make sure we parse the extended peer stats properly.
This issue was exposed when more than one client is connected and
extended peer stats for 10.4 is enabled

The order for the stats is as below
S - standard peer stats, E- extended peer stats, B - beacon filter stats

{S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}

Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---
[v1: addressed line wrap around comment from Kalle]
[v2: fixed ; in dummy inline function definition - thanks Sven Eckelmann]
[v3: removed wmi-op-version suggested by Kalle, introduced fw specifi hw param 
for extd_stats]

 drivers/net/wireless/ath/ath10k/core.c|3 ++
 drivers/net/wireless/ath/ath10k/core.h|9 +
 drivers/net/wireless/ath/ath10k/debug.c   |   18 -
 drivers/net/wireless/ath/ath10k/debug.h   |8 ++--
 drivers/net/wireless/ath/ath10k/debugfs_sta.c |   32 ++-
 drivers/net/wireless/ath/ath10k/wmi.c |   53 ++---
 drivers/net/wireless/ath/ath10k/wmi.h |   14 ++-
 7 files changed, 117 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 9ccb69c..bfa96ac 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .extd_peer_stats = true,
},
},
{
@@ -203,6 +204,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .extd_peer_stats = true,
},
},
{
@@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+   .extd_peer_stats = true,
},
},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index bbc4e0f..da9b2a9 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -165,6 +165,13 @@ struct ath10k_fw_stats_peer {
u32 rx_duration;
 };
 
+struct ath10k_fw_extd_stats_peer {
+   struct list_head list;
+
+   u8 peer_macaddr[ETH_ALEN];
+   u32 rx_duration;
+};
+
 struct ath10k_fw_stats_vdev {
struct list_head list;
 
@@ -259,6 +266,7 @@ struct ath10k_fw_stats {
struct list_head pdevs;
struct list_head vdevs;
struct list_head peers;
+   struct list_head peers_extd;
 };
 
 #define ATH10K_TPC_TABLE_TYPE_FLAG 1
@@ -752,6 +760,7 @@ struct ath10k {
const char *board;
size_t board_size;
size_t board_ext_size;
+   bool extd_peer_stats;
} fw;
} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 8fbb8f2..001c0a1 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -313,6 +313,16 @@ static void ath10k_fw_stats_peers_free(struct list_head 
*head)
}
 }
 
+static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
+{
+   struct ath10k_fw_extd_stats_peer *i, *tmp;
+
+   list_for_each_entry_safe(i, tmp, head, list) {
+   list_del(>list);
+   kfree(i);
+   }
+}
+
 static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
 {
spin_lock_bh(>data_lock);
@@ -320,6 +330,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
ath10k_fw_stats_pdevs_free(>debug.fw_stats.pdevs);
ath10k_fw_stats_vdevs_free(>debug.fw_stats.vdevs);
ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
+   ath10k_fw_extd_stats_peers_free(>debug.fw_stats.peers_extd);
spin_unlock_bh(>data_lock);
 }
 
@@ -334,6 +345,7 @@ void ath10k_

Re: [PATCH v2] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

On Wed, Jun 01, 2016 at 01:00:40PM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <moham...@codeaurora.org> writes:
> 
> > Hello,
> >
> > On Tue, May 31, 2016 at 06:57:52PM +, Valo, Kalle wrote:
> >> Mohammed Shafi Shajakhan <moham...@codeaurora.org> writes:
> >> 
> >> >> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> >> >> > +struct ath10k_fw_stats *stats)
> >> >> > +{
> >> >> > + struct ath10k_fw_file *fw_file = >normal_mode_fw.fw_file;
> >> >> > +
> >> >> > + if (fw_file->wmi_op_version < ATH10K_FW_WMI_OP_VERSION_10_4)
> >> >> > + ath10k_sta_update_stats_rx_duration(ar, >peers);
> >> >> > + else
> >> >> > + ath10k_sta_update_extd_stats_rx_duration(ar,
> >> >> > +  
> >> >> > >peers_extd);
> >> >> > +}
> >> >> 
> >> >> _Ideally_ wmi_op_version should be used only in ath10k_wmi_attach() and
> >> >> nowhere else. Isn't there any other way to detect this scenario? For
> >> >> example, what if you store stats_id to struct ath10k_fw_stats and do
> >> >> something like this:
> >> >> 
> >> >> if (stats->stats_id & WMI_10_4_STAT_PEER_EXTD)
> >> >> ath10k_sta_update_extd_stats_rx_duration(ar,
> >> >>  >peers_extd);
> >> >> else
> >> >> ath10k_sta_update_stats_rx_duration(ar, >peers);
> >> >> 
> >> >> Would that work?
> >> >
> >> > [shafi] I am also thinking to re-use (ar->fw_stats_req_mask & 
> >> > WMI_10_4_STAT_PEER_EXTD)
> >> > it might work, but will it conflict vdev stats WMI_STAT_VDEV (though its 
> >> > not currently
> >> > supported for 10.2 )
> >> 
> >> Can you describe more how they conflict?
> >
> > [shafi] 'WMI_STAT_VDEV' and 'WMI_10_4_STAT_PEER_EXTD' are having the same 
> > value
> > BIT(3), though as of now we are only 'WMI_10_4_STAT_PEER_EXTD' for 10.4
> 
> Ah. But that's easy to solve, for example you could use a bool instead.
>
[shafi] sure thanks will do the same, i had a similar change in my mind as well
!

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

Hello,

On Tue, May 31, 2016 at 06:57:52PM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <moham...@codeaurora.org> writes:
> 
> >> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> >> > +   struct ath10k_fw_stats *stats)
> >> > +{
> >> > +struct ath10k_fw_file *fw_file = >normal_mode_fw.fw_file;
> >> > +
> >> > +if (fw_file->wmi_op_version < ATH10K_FW_WMI_OP_VERSION_10_4)
> >> > +ath10k_sta_update_stats_rx_duration(ar, >peers);
> >> > +else
> >> > +ath10k_sta_update_extd_stats_rx_duration(ar,
> >> > + 
> >> > >peers_extd);
> >> > +}
> >> 
> >> _Ideally_ wmi_op_version should be used only in ath10k_wmi_attach() and
> >> nowhere else. Isn't there any other way to detect this scenario? For
> >> example, what if you store stats_id to struct ath10k_fw_stats and do
> >> something like this:
> >> 
> >> if (stats->stats_id & WMI_10_4_STAT_PEER_EXTD)
> >>ath10k_sta_update_extd_stats_rx_duration(ar,
> >> >peers_extd);
> >> else
> >>ath10k_sta_update_stats_rx_duration(ar, >peers);
> >> 
> >> Would that work?
> >
> > [shafi] I am also thinking to re-use (ar->fw_stats_req_mask & 
> > WMI_10_4_STAT_PEER_EXTD)
> > it might work, but will it conflict vdev stats WMI_STAT_VDEV (though its 
> > not currently
> > supported for 10.2 )
> 
> Can you describe more how they conflict?

[shafi] 'WMI_STAT_VDEV' and 'WMI_10_4_STAT_PEER_EXTD' are having the same value
BIT(3), though as of now we are only 'WMI_10_4_STAT_PEER_EXTD' for 10.4

> 
> > let me know your thoughts about this, seems extended stats was
> > implemented for 10.4 wmi version so i made it explicit
> 
> I don't like hard coding features like this based on wmi_op_version as
> that might create problems managing the firmware interfaces in the
> future. The simplest is if we can automatically runtime detect if
> firmware uses the extended version or not.
>
[shafi] Sure i come up with something else to address this in v3.

regards
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

Hi Kalle,

thanks for the review


On Tue, May 31, 2016 at 12:18:49PM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes:
> 
> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> >
> > 10.4 'extended peer stats' will be not be appended with normal peer stats
> > data and they shall be coming in separate chunks. Fix this by maintaining
> > a separate linked list 'extender peer stats' for 10.4 and update
> > rx_duration for per station statistics. Also parse through beacon filter
> > (if enabled), to make sure we parse the extended peer stats properly.
> > This issue was exposed when more than one client is connected and
> > extended peer stats for 10.4 is enabled
> >
> > The order for the stats is as below
> > S - standard peer stats, E- extended peer stats, B - beacon filter stats
> >
> > {S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
> >
> > Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 
> > 10.4")
> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
> 
> [...]
> 
> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> > +  struct ath10k_fw_stats *stats)
> > +{
> > +   struct ath10k_fw_file *fw_file = >normal_mode_fw.fw_file;
> > +
> > +   if (fw_file->wmi_op_version < ATH10K_FW_WMI_OP_VERSION_10_4)
> > +   ath10k_sta_update_stats_rx_duration(ar, >peers);
> > +   else
> > +   ath10k_sta_update_extd_stats_rx_duration(ar,
> > +>peers_extd);
> > +}
> 
> _Ideally_ wmi_op_version should be used only in ath10k_wmi_attach() and
> nowhere else. Isn't there any other way to detect this scenario? For
> example, what if you store stats_id to struct ath10k_fw_stats and do
> something like this:
> 
> if (stats->stats_id & WMI_10_4_STAT_PEER_EXTD)
>   ath10k_sta_update_extd_stats_rx_duration(ar,
>>peers_extd);
> else
>   ath10k_sta_update_stats_rx_duration(ar, >peers);
> 
> Would that work?

[shafi] I am also thinking to re-use (ar->fw_stats_req_mask & 
WMI_10_4_STAT_PEER_EXTD)
it might work, but will it conflict vdev stats WMI_STAT_VDEV (though its not 
currently
supported for 10.2 ) let me know your thoughts about this, seems extended stats
was implemented for 10.4 wmi version so i made it explicit

> 
> -- 
> Kalle Valo--
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v1] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

Hi Kalle,

On Tue, May 31, 2016 at 11:09:38AM +, Valo, Kalle wrote:
> "Shajakhan, Mohammed Shafi (Mohammed Shafi)" 
> writes:
> > seems the change got merged in pending branch
> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending=2a872321e07506e339fc1b3ca81aa3e88628cd6e
> >
> > Request if you can send the patch to address this(incase the patch cannot 
> > be dropped)
> > and the v2 version cannot be picked
> 
> The pending branches (pending and pending-master) are just for build and
> runtime testing, they can be freely modified or dropped. v2 is now in
> pending branch and I'm looking at the patch right now.
>

[shafi] sure thanks for the clarification !

regards,
shafi

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v1] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

On Fri, May 27, 2016 at 10:12:45AM +0200, Sven Eckelmann wrote:
> On Wednesday 11 May 2016 11:54:30 Mohammed Shafi Shajakhan wrote:
> >  #else
> > -static inline void ath10k_sta_update_rx_duration(struct ath10k *ar,
> > -struct list_head *peer)
> > +static inline
> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> > +  struct ath10k_fw_stats *stats);
> >  {
> >  }
> 
> Please remove the ";" for the "static inline" version. I can also
> submit a patch in case patches in ath.git/pending cannot be dropped
> anymore.

[shafi] thanks a lot fixed it ! sorry for the typo, sent a v2 for
the same, kindly review the same.

> 
> Kind regards,
>   Sven



___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

10.4 'extended peer stats' will be not be appended with normal peer stats
data and they shall be coming in separate chunks. Fix this by maintaining
a separate linked list 'extender peer stats' for 10.4 and update
rx_duration for per station statistics. Also parse through beacon filter
(if enabled), to make sure we parse the extended peer stats properly.
This issue was exposed when more than one client is connected and
extended peer stats for 10.4 is enabled

The order for the stats is as below
S - standard peer stats, E- extended peer stats, B - beacon filter stats

{S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}

Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
---

[v1: Fixed line wrap around suggested by Kalle)

 drivers/net/wireless/ath/ath10k/core.h|8 
 drivers/net/wireless/ath/ath10k/debug.c   |   18 -
 drivers/net/wireless/ath/ath10k/debug.h   |8 ++--
 drivers/net/wireless/ath/ath10k/debugfs_sta.c |   34 +++-
 drivers/net/wireless/ath/ath10k/wmi.c |   53 ++---
 drivers/net/wireless/ath/ath10k/wmi.h |   14 ++-
 6 files changed, 115 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..7ea6bc4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -165,6 +165,13 @@ struct ath10k_fw_stats_peer {
u32 rx_duration;
 };
 
+struct ath10k_fw_extd_stats_peer {
+   struct list_head list;
+
+   u8 peer_macaddr[ETH_ALEN];
+   u32 rx_duration;
+};
+
 struct ath10k_fw_stats_vdev {
struct list_head list;
 
@@ -259,6 +266,7 @@ struct ath10k_fw_stats {
struct list_head pdevs;
struct list_head vdevs;
struct list_head peers;
+   struct list_head peers_extd;
 };
 
 #define ATH10K_TPC_TABLE_TYPE_FLAG 1
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index e251155..c07eb3f 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -313,6 +313,16 @@ static void ath10k_fw_stats_peers_free(struct list_head 
*head)
}
 }
 
+static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
+{
+   struct ath10k_fw_extd_stats_peer *i, *tmp;
+
+   list_for_each_entry_safe(i, tmp, head, list) {
+   list_del(>list);
+   kfree(i);
+   }
+}
+
 static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
 {
spin_lock_bh(>data_lock);
@@ -320,6 +330,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
ath10k_fw_stats_pdevs_free(>debug.fw_stats.pdevs);
ath10k_fw_stats_vdevs_free(>debug.fw_stats.vdevs);
ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
+   ath10k_fw_extd_stats_peers_free(>debug.fw_stats.peers_extd);
spin_unlock_bh(>data_lock);
 }
 
@@ -334,6 +345,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
struct sk_buff *skb)
INIT_LIST_HEAD();
INIT_LIST_HEAD();
INIT_LIST_HEAD();
+   INIT_LIST_HEAD(_extd);
 
spin_lock_bh(>data_lock);
ret = ath10k_wmi_pull_fw_stats(ar, skb, );
@@ -354,7 +366,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
struct sk_buff *skb)
 * delivered which is treated as end-of-data and is itself discarded
 */
if (ath10k_peer_stats_enabled(ar))
-   ath10k_sta_update_rx_duration(ar, );
+   ath10k_sta_update_rx_duration(ar, );
 
if (ar->debug.fw_stats_done) {
if (!ath10k_peer_stats_enabled(ar))
@@ -396,6 +408,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
struct sk_buff *skb)
 
list_splice_tail_init(, >debug.fw_stats.peers);
list_splice_tail_init(, >debug.fw_stats.vdevs);
+   list_splice_tail_init(_extd,
+ >debug.fw_stats.peers_extd);
}
 
complete(>debug.fw_stats_complete);
@@ -407,6 +421,7 @@ free:
ath10k_fw_stats_pdevs_free();
ath10k_fw_stats_vdevs_free();
ath10k_fw_stats_peers_free();
+   ath10k_fw_extd_stats_peers_free(_extd);
 
spin_unlock_bh(>data_lock);
 }
@@ -2320,6 +2335,7 @@ int ath10k_debug_create(struct ath10k *ar)
INIT_LIST_HEAD(>debug.fw_stats.pdevs);
INIT_LIST_HEAD(>debug.fw_stats.vdevs);
INIT_LIST_HEAD(>debug.fw_stats.peers);
+   INIT_LIST_HEAD(>debug.fw_stats.peers_extd);
 
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/debug.h 
b/drivers/net/wireless/ath/ath10k/debug.h
index 75c89e3..1a722be 100644
--- a/drivers/net/wireless/a

[PATCH] ath10k: Fix error while writing 'simulate_fw_crash' debugfs

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>

Fix invalid argument error while writing 'simulate_fw_crash',
though the funcionality is working fine we get an error 'invalid
argument' because 'count' value is not returned properly
(no reason to reduce the count value for removing the newline)

Fixes the below write error:

/sys/kernel/debug/ieee80211/phy0/ath10k# echo hw-restart >
simulate_fw_crash
-bash: echo: write error: Invalid argument

Also move the 'conf_mutex' as it is really not required for
fetching the userspace buffer.

Reported-by: Maharaja Kennadyrajan <c_mke...@qti.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
Signed-off-by: Maharaja Kennadyrajan <c_mke...@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/debug.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index e251155..54cb629 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -609,25 +609,23 @@ static ssize_t ath10k_write_simulate_fw_crash(struct file 
*file,
char buf[32];
int ret;
 
-   mutex_lock(>conf_mutex);
-
simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count);
 
/* make sure that buf is null terminated */
buf[sizeof(buf) - 1] = 0;
 
+   /* drop the possible '\n' from the end */
+   if (buf[count - 1] == '\n')
+   buf[count - 1] = 0;
+
+   mutex_lock(>conf_mutex);
+
if (ar->state != ATH10K_STATE_ON &&
ar->state != ATH10K_STATE_RESTARTED) {
ret = -ENETDOWN;
goto exit;
}
 
-   /* drop the possible '\n' from the end */
-   if (buf[count - 1] == '\n') {
-   buf[count - 1] = 0;
-   count--;
-   }
-
if (!strcmp(buf, "soft")) {
ath10k_info(ar, "simulating soft firmware crash\n");
ret = ath10k_wmi_force_fw_hang(ar, WMI_FORCE_FW_HANG_ASSERT, 0);
-- 
1.7.9.5


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] ath10k: add QCA9887 chipset support

[Mohammed Shafi Shajakhan]

On Mon, May 23, 2016 at 11:52:11AM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Sven,
> 
> On Fri, May 20, 2016 at 04:41:11PM +0200, Sven Eckelmann wrote:
> > Add the hardware name, revision, firmware names and update the pci_id
> > table.
> > 
> > QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
> > he firmware interface are currently unknown.
> > 
> > Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.c  | 20 
> >  drivers/net/wireless/ath/ath10k/hw.h| 10 ++
> >  drivers/net/wireless/ath/ath10k/pci.c   | 20 ++--
> >  drivers/net/wireless/ath/ath10k/targaddrs.h |  3 +++
> >  4 files changed, 51 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> > b/drivers/net/wireless/ath/ath10k/core.c
> > index 49af624..0f4a4f6 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -69,6 +69,25 @@ static const struct ath10k_hw_params 
> > ath10k_hw_params_list[] = {
> > },
> > },
> > {
> > +   .id = QCA9887_HW_1_0_VERSION,
> > +   .dev_id = QCA9887_1_0_DEVICE_ID,
> > +   .name = "qca9887 hw1.0",
> > +   .patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
> > +   .uart_pin = 7,
> > +   .has_shifted_cc_wraparound = true,
> > +   .otp_exe_param = 0,
> > +   .channel_counters_freq_hz = 88000,
> > +   .max_probe_resp_desc_thres = 0,
> > +   .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
> > +   .cal_data_len = 2116,
> 
> [shafi] i think we can re-use QCA988X_CAL_DATA_LEN instead of a new h/w param

sorry ignore this comment, i was looking into some old code, this change looks
fine to me

> 
> > +   .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,
> > +   },
> > +   },
> > +   {
> > .id = QCA6174_HW_2_1_VERSION,
> > .dev_id = QCA6164_2_1_DEVICE_ID,
> > .name = "qca6164 hw2.1",
> > @@ -2062,6 +2081,7 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
> > struct device *dev,
> >  
> > switch (hw_rev) {
> > case ATH10K_HW_QCA988X:
> > +   case ATH10K_HW_QCA9887:
> > ar->regs = _regs;
> > ar->hw_values = _values;
> > break;
> > diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
> > b/drivers/net/wireless/ath/ath10k/hw.h
> > index aedd898..9108831 100644
> > --- a/drivers/net/wireless/ath/ath10k/hw.h
> > +++ b/drivers/net/wireless/ath/ath10k/hw.h
> > @@ -27,6 +27,7 @@
> >  #define QCA6174_2_1_DEVICE_ID   (0x003e)
> >  #define QCA99X0_2_0_DEVICE_ID   (0x0040)
> >  #define QCA9377_1_0_DEVICE_ID   (0x0042)
> > +#define QCA9887_1_0_DEVICE_ID   (0x0050)
> >  
> >  /* QCA988X 1.0 definitions (unsupported) */
> >  #define QCA988X_HW_1_0_CHIP_ID_REV 0x0
> > @@ -38,6 +39,13 @@
> >  #define QCA988X_HW_2_0_BOARD_DATA_FILE "board.bin"
> >  #define QCA988X_HW_2_0_PATCH_LOAD_ADDR 0x1234
> >  
> > +/* QCA9887 1.0 definitions */
> > +#define QCA9887_HW_1_0_VERSION 0x4100016d
> > +#define QCA9887_HW_1_0_CHIP_ID_REV 0
> > +#define QCA9887_HW_1_0_FW_DIR  ATH10K_FW_DIR "/QCA9887/hw1.0"
> > +#define QCA9887_HW_1_0_BOARD_DATA_FILE "board.bin"
> > +#define QCA9887_HW_1_0_PATCH_LOAD_ADDR 0x1234
> > +
> >  /* QCA6174 target BMI version signatures */
> >  #define QCA6174_HW_1_0_VERSION 0x0500
> >  #define QCA6174_HW_1_1_VERSION 0x0501
> > @@ -195,6 +203,7 @@ enum ath10k_hw_rev {
> > ATH10K_HW_QCA99X0,
> > ATH10K_HW_QCA9377,
> > ATH10K_HW_QCA4019,
> > +   ATH10K_HW_QCA9887,
> >  };
> >  
> >  struct ath10k_hw_regs {
> > @@ -247,6 +256,7 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, 
> > struct survey_info *survey,
> > u32 cc, u32 rcc, u32 cc_prev, u32 rcc_prev);
> >  
> >  #define QCA_REV_988X(ar) ((ar)->hw_rev == ATH10K_HW_QCA988X)
> > +#define QCA_REV_9887(ar) ((ar)->hw_rev == ATH10K_HW_QCA9887)
> >  #define QCA_REV_6174(ar) ((ar)->hw_