Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"
Sorry to pick up this thread again, it looks this issue still existed in the newer 4.3 kernel. (The EAP frames can not be received by wireless interface due to the bridge interface, http://marc.info/?l=linux-wireless&m=136743495526905&w=2) Wonder is anyone know some update for this issue? Currently the only workaround is make the 4-address AP and STA associated in security mode firstly and then create the bridge, the renew key configuration also need be disable at the hostapd side to avoid renew the key at bridge status. Thanks Yanbo > On Wed, May 1, 2013 at 5:53 PM, Felix Fietkau wrote: > > > > On 2013-05-02 12:49 AM, Stephen Hemminger wrote: > > > On Wed, 01 May 2013 23:06:16 +0200 > > > Felix Fietkau wrote: > > > > > >> On 2013-05-01 10:21 PM, Stephen Hemminger wrote: > > >> > What about using AF_PACKET bound to underlying wireless device and the > > >> > packet type. You can even use BPF to filter. > > >> As far as I know, AF_PACKET only works when not binding it to the packet > > >> type (otherwise it get stolen by the rx handler). > > > > > > You can do AF_PACKET and it gets handle before rx_handler. > > If I don't bind it to a protocol, it ends up in ptype_all, if I do, it > > ends up in &ptype_base. ptype_all is processed before the rx_handler, > > ptype_base is processed after the rx handler. > > Hooking into ptype_all wastes tons of CPU cycles, hooking into > > ptype_base does not solve the problem. > > > > - Felix > > -- > > 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 -- 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
RE: [PATCH] ath10k: Adjust the RX packet pad offset at QCA99X0 4addr mode
> -Original Message- > From: Shajakhan, Mohammed Shafi (Mohammed Shafi) > Sent: Friday, November 20, 2015 5:32 AM > To: Valo, Kalle > Cc: Li, Yanbo; linux-wireless@vger.kernel.org; ath...@lists.infradead.org > Subject: Re: [PATCH] ath10k: Adjust the RX packet pad offset at QCA99X0 > 4addr mode > > Hi Kalle\Yanbo, > > On Mon, Nov 16, 2015 at 10:57:44PM +0200, Kalle Valo wrote: > > "Li, Yanbo" writes: > > > > >> > + /* The padding bytes's location is different on various > chips */ > > >> > + enum ath10k_loc_4addr_pad loc_4addr_pad; > > >> > > >> I think that loc prefix is a bit misleading, it reminds me of > > >> locationing/positioning etc. What about ath10k_hw_4addr_pad? > > >> > > > > > > > > > There is already a FW feature defined as > > > "ATH10K_FW_FEATURE_NO_NWIFI_DECAP_4ADDR_PADDIND" and the > relative > > > string is "no-4addr-pad", if we just remove the "loc" prefix, it may > > > be confuse with this FW feature. > > > > > > How about we change the loc to offset in this case or any better > suggestion? > > > > I did some naming changes in the pending branch: > > > > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=p > > ending&id=42cd3832cd7c78bfeabb639a4086c7838fda5b57 > > > > Please review and let me know what you think. Looks good to me, thanks Kalle. BR /Yanbo -- 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
[PATCH] ath10k: Fix the wrong RX rate idx report at 11G mode
The RX rate idx is not correctly for 11G mode OFDM packet.
Because the bitrate table start with CCK index instead of OFDM.
Signed-off-by: Yanbo Li
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6060dda4e910..9dcf93d1bd24 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -674,7 +674,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
rate &= ~RX_PPDU_START_RATE_FLAG;
sband = &ar->mac.sbands[status->band];
- status->rate_idx = ath10k_mac_hw_rate_to_idx(sband, rate);
+ status->rate_idx = ath10k_mac_hw_rate_to_idx(sband, rate, cck);
break;
case HTT_RX_HT:
case HTT_RX_HT_WITH_TXBF:
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 484c1a10372f..02feb5fe27d5 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -90,7 +90,7 @@ static u8 ath10k_mac_bitrate_to_rate(int bitrate)
}
u8 ath10k_mac_hw_rate_to_idx(const struct ieee80211_supported_band *sband,
-u8 hw_rate)
+u8 hw_rate, bool cck)
{
const struct ieee80211_rate *rate;
int i;
@@ -98,6 +98,9 @@ u8 ath10k_mac_hw_rate_to_idx(const struct
ieee80211_supported_band *sband,
for (i = 0; i < sband->n_bitrates; i++) {
rate = &sband->bitrates[i];
+ if (ath10k_mac_bitrate_is_cck(rate->bitrate) != cck)
+ continue;
+
if (rate->hw_value == hw_rate)
return i;
else if (rate->flags & IEEE80211_RATE_SHORT_PREAMBLE &&
diff --git a/drivers/net/wireless/ath/ath10k/mac.h
b/drivers/net/wireless/ath/ath10k/mac.h
index e3cefe4c7cfd..3b0f0fd2af9e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.h
+++ b/drivers/net/wireless/ath/ath10k/mac.h
@@ -66,7 +66,7 @@ void ath10k_mac_handle_tx_pause_vdev(struct ath10k *ar, u32
vdev_id,
enum wmi_tlv_tx_pause_action action);
u8 ath10k_mac_hw_rate_to_idx(const struct ieee80211_supported_band *sband,
-u8 hw_rate);
+u8 hw_rate, bool cck);
u8 ath10k_mac_bitrate_to_idx(const struct ieee80211_supported_band *sband,
u32 bitrate);
--
1.9.1
--
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
[PATCH V4] ath10k: Debugfs entry to enable/disable WLAN&Blutooth Coexist feature
As some radio have no connection with BT modules, enable the WLAN/Bluetooth
coexist(BTC) feature will has some side effect if the radio's GPIO connect
with any other HW modules. Add the control switcher "btc_feature" at
debugfs and set the feature as disable by default to avoid such case.
The FW support this feature since 10.2.4.54 on 2G-only board, dual band
or 5G boards don't support the feature
To enable this feature, execute:
echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
To disable:
echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
Signed-off-by: Yanbo Li
---
Notes:
Resend cause the patch be missed from the mail list.
No change compare with V3, just rebase on the newest ath tree.
The previous thread can be from:
https://www.mail-archive.com/ath10k@lists.infradead.org/msg02596.html
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 7cc7cdd56c95..6ce3cd28fa86 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -519,6 +519,9 @@ enum ath10k_dev_flags {
/* Disable HW crypto engine */
ATH10K_FLAG_HW_CRYPTO_DISABLED,
+
+ /* Flag for enable the BT/WLAN coexist */
+ ATH10K_FLAG_BTCOEX_ENABLE
};
enum ath10k_cal_mode {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 6cc1aa3449c8..1f27c066c571 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2074,6 +2074,69 @@ static const struct file_operations fops_quiet_period = {
.open = simple_open
};
+static ssize_t ath10k_write_btc_feature(struct file *file,
+ const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ char buf[32];
+ size_t buf_size;
+ bool val;
+ int ret;
+
+ buf_size = min(count, (sizeof(buf) - 1));
+ if (copy_from_user(buf, ubuf, buf_size))
+ return -EFAULT;
+
+ buf[buf_size] = '\0';
+ if (strtobool(buf, &val) != 0) {
+ ath10k_warn(ar, "Wrong BTcoex feature setting\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state != ATH10K_STATE_ON) {
+ ret = -ENETDOWN;
+ goto err_unlock;
+ }
+
+ if (val != test_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags)) {
+ if (val)
+ set_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags);
+ else
+ clear_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags);
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
+
+ ret = count;
+
+err_unlock:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
+static ssize_t ath10k_read_btc_feature(struct file *file, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ char buf[32];
+ struct ath10k *ar = file->private_data;
+ int len = 0;
+
+ mutex_lock(&ar->conf_mutex);
+ len = scnprintf(buf, sizeof(buf) - len, "%d\n",
+ test_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags));
+ mutex_unlock(&ar->conf_mutex);
+
+ return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_btc_feature = {
+ .read = ath10k_read_btc_feature,
+ .write = ath10k_write_btc_feature,
+ .open = simple_open
+};
+
int ath10k_debug_create(struct ath10k *ar)
{
ar->debug.fw_crash_data = vzalloc(sizeof(*ar->debug.fw_crash_data));
@@ -2183,6 +2246,8 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("tpc_stats", S_IRUSR,
ar->debug.debugfs_phy, ar, &fops_tpc_stats);
+ debugfs_create_file("btc_feature", S_IRUGO | S_IWUSR,
+ ar->debug.debugfs_phy, ar, &fops_btc_feature);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 6e7d7a7f6a97..ef4b260beb63 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5301,7 +5301,8 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
cmd = (struct wmi_init_cmd_10_2 *)buf->data;
features = WMI_10_2_RX_BATCH_MODE;
- if (test_bit(WMI_SERVICE_COEX_GPIO, ar->wmi.svc_map))
+ if (test_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags) &&
+ test_bit(WMI_SERVICE_COEX_GPIO, ar->wmi.svc_map))
features |= WMI_10_2_COEX_GPIO;
cmd->resource_config.feature_mask = __cpu_to_le32(features);
--
1.9.1
--
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
RE: [PATCH] ath10k: Adjust the RX packet pad offset at QCA99X0 4addr mode
> -Original Message-
> From: Valo, Kalle
> Sent: Thursday, October 22, 2015 10:25 PM
> To: Li, Yanbo
> Cc: dreamfly...@gmail.com; ath...@lists.infradead.org; linux-
> wirel...@vger.kernel.org
> Subject: Re: [PATCH] ath10k: Adjust the RX packet pad offset at QCA99X0
> 4addr mode
>
> Yanbo Li writes:
>
> > The QCA99X0 4 addresses RX packets pad 2 bytes at the beginning of
> > MSDU instead the end of ieee80211 header to keep align. The currently
> > RX data path can't parse the header correctly in this case. This patch
> > fixes it for QCA99X0
> >
> > Signed-off-by: Yanbo Li
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c
> > b/drivers/net/wireless/ath/ath10k/core.c
> > index 13de3617d5ab..3c1d07c191d5 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -58,6 +58,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> > .otp_exe_param = 0,
> > .channel_counters_freq_hz = 88000,
> > .max_probe_resp_desc_thres = 0,
> > + .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
> > .fw = {
> > .dir = QCA988X_HW_2_0_FW_DIR,
> > .fw = QCA988X_HW_2_0_FW_FILE,
> > @@ -75,6 +76,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> > .otp_exe_param = 0,
> > .channel_counters_freq_hz = 88000,
> > .max_probe_resp_desc_thres = 0,
> > + .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
> > .fw = {
> > .dir = QCA6174_HW_2_1_FW_DIR,
> > .fw = QCA6174_HW_2_1_FW_FILE,
> > @@ -92,6 +94,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> > .otp_exe_param = 0,
> > .channel_counters_freq_hz = 88000,
> > .max_probe_resp_desc_thres = 0,
> > + .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
> > .fw = {
> > .dir = QCA6174_HW_3_0_FW_DIR,
> > .fw = QCA6174_HW_3_0_FW_FILE,
> > @@ -109,6 +112,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> > .otp_exe_param = 0,
> > .channel_counters_freq_hz = 88000,
> > .max_probe_resp_desc_thres = 0,
> > + .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
> > .fw = {
> > /* uses same binaries as hw3.0 */
> > .dir = QCA6174_HW_3_0_FW_DIR,
> > @@ -128,6 +132,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> > .continuous_frag_desc = true,
> > .channel_counters_freq_hz = 15,
> > .max_probe_resp_desc_thres = 24,
> > + .loc_4addr_pad = ATH10K_4ADDR_PAD_PRE,
> > .fw = {
> > .dir = QCA99X0_HW_2_0_FW_DIR,
> > .fw = QCA99X0_HW_2_0_FW_FILE,
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h
> > b/drivers/net/wireless/ath/ath10k/core.h
> > index 7cc7cdd56c95..b4db8bbf85ce 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -646,6 +646,9 @@ struct ath10k {
> > */
> > u32 max_probe_resp_desc_thres;
> >
> > + /* The padding bytes's location is different on various chips */
> > + enum ath10k_loc_4addr_pad loc_4addr_pad;
>
> I think that loc prefix is a bit misleading, it reminds me of
> locationing/positioning etc. What about ath10k_hw_4addr_pad?
>
There is already a FW feature defined as
"ATH10K_FW_FEATURE_NO_NWIFI_DECAP_4ADDR_PADDIND" and
the relative string is "no-4addr-pad", if we just remove the "loc" prefix, it
may be confuse with this FW feature.
How about we change the loc to offset in this case or any better suggestion?
Thanks
BR /Yanbo
--
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
[PATCH] ath10k: Adjust the RX packet pad offset at QCA99X0 4addr mode
The QCA99X0 4 addresses RX packets pad 2 bytes at the beginning of
MSDU instead the end of ieee80211 header to keep align. The currently
RX data path can't parse the header correctly in this case. This
patch fixes it for QCA99X0
Signed-off-by: Yanbo Li
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 13de3617d5ab..3c1d07c191d5 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -58,6 +58,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
+ .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
.fw = {
.dir = QCA988X_HW_2_0_FW_DIR,
.fw = QCA988X_HW_2_0_FW_FILE,
@@ -75,6 +76,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
+ .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
.fw = {
.dir = QCA6174_HW_2_1_FW_DIR,
.fw = QCA6174_HW_2_1_FW_FILE,
@@ -92,6 +94,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
+ .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
.fw = {
.dir = QCA6174_HW_3_0_FW_DIR,
.fw = QCA6174_HW_3_0_FW_FILE,
@@ -109,6 +112,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
+ .loc_4addr_pad = ATH10K_4ADDR_PAD_AFT,
.fw = {
/* uses same binaries as hw3.0 */
.dir = QCA6174_HW_3_0_FW_DIR,
@@ -128,6 +132,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.continuous_frag_desc = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
+ .loc_4addr_pad = ATH10K_4ADDR_PAD_PRE,
.fw = {
.dir = QCA99X0_HW_2_0_FW_DIR,
.fw = QCA99X0_HW_2_0_FW_FILE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 7cc7cdd56c95..b4db8bbf85ce 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -646,6 +646,9 @@ struct ath10k {
*/
u32 max_probe_resp_desc_thres;
+ /* The padding bytes's location is different on various chips */
+ enum ath10k_loc_4addr_pad loc_4addr_pad;
+
struct ath10k_hw_params_fw {
const char *dir;
const char *fw;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6060dda4e910..f25f1d7a3edf 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1114,7 +1114,19 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k
*ar,
*/
/* pull decapped header and copy SA & DA */
- hdr = (struct ieee80211_hdr *)msdu->data;
+ if ((ar->hw_params.loc_4addr_pad == ATH10K_4ADDR_PAD_PRE) &&
+ ieee80211_has_a4(((struct ieee80211_hdr
*)first_hdr)->frame_control)) {
+ /* The QCA99X0 4 address mode pad 2 bytes at the
+* beginning of MSDU
+*/
+ hdr = (struct ieee80211_hdr *)(msdu->data + 2);
+ /* The skb length need be extended 2 as the 2 bytes at the tail
+* be excluded due to the padding
+*/
+ skb_put(msdu, 2);
+ } else
+ hdr = (struct ieee80211_hdr *)(msdu->data);
+
hdr_len = ath10k_htt_rx_nwifi_hdrlen(ar, hdr);
ether_addr_copy(da, ieee80211_get_DA(hdr));
ether_addr_copy(sa, ieee80211_get_SA(hdr));
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index 2d87737e35ff..efbe6fa1f356 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -282,6 +282,11 @@ enum ath10k_hw_rate_cck {
ATH10K_HW_RATE_CCK_SP_2M,
};
+enum ath10k_loc_4addr_pad {
+ ATH10K_4ADDR_PAD_AFT,
+ ATH10K_4ADDR_PAD_PRE,
+};
+
/* Target specific defines for MAIN firmware */
#define TARGET_NUM_VDEVS 8
#define TARGET_NUM_PEER_AST2
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wi
[PATCH v3] ath10k: Debugfs entry to enable/disable WLAN&Blutooth Coexist feature
As some radio have no connection with BT modules, enable the WLAN/Bluetooth
coexist(BTC) feature will has some side effect if the radio's GPIO connect
with any other HW modules. Add the control switcher "btc_feature" at
debugfs and set the feature as disable by default to avoid such case.
The FW support this feature since 10.2.4.54 on 2G-only board, dual band
or 5G boards don't support the feature
To enable this feature, execute:
echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
To disable:
echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
Signed-off-by: Yanbo Li
---
Notes:
V3:
* using dev_flags
* check state on before restart
* Add the FW version and limitation support this feature
drivers/net/wireless/ath/ath10k/core.h | 2 +
drivers/net/wireless/ath/ath10k/debug.c | 65 +
drivers/net/wireless/ath/ath10k/wmi.c | 3 +-
3 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 87376b3283f5..7fc2034ce53d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -481,6 +481,8 @@ enum ath10k_dev_flags {
* waiters should immediately cancel instead of waiting for a time out.
*/
ATH10K_FLAG_CRASH_FLUSH,
+ /* Flag for enable the BT/WLAN coexist */
+ ATH10K_FLAG_BTCOEX_ENABLE
};
enum ath10k_cal_mode {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 8fa606a9c4dd..a5da7c96d81a 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2092,6 +2092,69 @@ static const struct file_operations fops_quiet_period = {
.open = simple_open
};
+static ssize_t ath10k_write_btc_feature(struct file *file,
+ const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ char buf[32];
+ size_t buf_size;
+ bool val;
+ int ret;
+
+ buf_size = min(count, (sizeof(buf) - 1));
+ if (copy_from_user(buf, ubuf, buf_size))
+ return -EFAULT;
+
+ buf[buf_size] = '\0';
+ if (strtobool(buf, &val) != 0) {
+ ath10k_warn(ar, "Wrong BTcoex feature setting\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state != ATH10K_STATE_ON) {
+ ret = -ENETDOWN;
+ goto err_unlock;
+ }
+
+ if (val != test_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags)) {
+ if (val)
+ set_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags);
+ else
+ clear_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags);
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
+
+ ret = count;
+
+err_unlock:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
+static ssize_t ath10k_read_btc_feature(struct file *file, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ char buf[32];
+ struct ath10k *ar = file->private_data;
+ int len = 0;
+
+ mutex_lock(&ar->conf_mutex);
+ len = scnprintf(buf, sizeof(buf) - len, "%d\n",
+ test_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags));
+ mutex_unlock(&ar->conf_mutex);
+
+ return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_btc_feature = {
+ .read = ath10k_read_btc_feature,
+ .write = ath10k_write_btc_feature,
+ .open = simple_open
+};
+
int ath10k_debug_create(struct ath10k *ar)
{
ar->debug.fw_crash_data = vzalloc(sizeof(*ar->debug.fw_crash_data));
@@ -2195,6 +2258,8 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("quiet_period", S_IRUGO | S_IWUSR,
ar->debug.debugfs_phy, ar, &fops_quiet_period);
+ debugfs_create_file("btc_feature", S_IRUGO | S_IWUSR,
+ ar->debug.debugfs_phy, ar, &fops_btc_feature);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 77220b0f0e89..98e0b087d080 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3936,7 +3936,8 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
cmd = (struct wmi_init_cmd_10_2 *)buf->data;
features = WMI_10_2_RX_BATCH_MODE;
- if (test_bit(WMI_SERVICE_COEX_GPIO, ar->wmi.svc_map))
+ if (test_bit(ATH10K_FLAG_BTCOEX_ENABLE, &ar->dev_flags) &&
+ t
Re: [PATCH] ath10k: Debugfs entry to enable/disable BTC feature
On Mon, Jun 8, 2015 at 6:44 AM, Kalle Valo wrote:
> "Li, Yanbo" writes:
>
>>> -Original Message-
>>> From: Valo, Kalle
>>> Sent: Wednesday, May 27, 2015 5:57 AM
>>> To: Li, Yanbo
>>> Cc: dreamfly...@gmail.com; linux-wireless@vger.kernel.org;
>>> michal.kaz...@tieto.com; ath...@lists.infradead.org
>>> Subject: Re: [PATCH] ath10k: Debugfs entry to enable/disable BTC feature
>>>
>>> Yanbo Li writes:
>>>
>>> > As some radio have no connection with BT modules, enable the BTC
>>> > feature will has some side effect if the radio's GPIO connect with any
>>> > other HW modules. Add the control switcher "btc_feature" at debugfs
>>> > and set the feature as disable by default to avoid such case.
>>> >
>>> > To enable this feature, execute:
>>> > echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
>>> > To disable:
>>> > echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
>>>
>>> I suspect "BTC" does not really tell much for most of the people and
>>> acronyms should be always spelled out at least once.
>>>
>>> > Signed-off-by: Yanbo Li
>>> >
>>> > diff --git a/drivers/net/wireless/ath/ath10k/core.h
>>> > b/drivers/net/wireless/ath/ath10k/core.h
>>> > index 8444adf42195..6852e7fc5d5f 100644
>>> > --- a/drivers/net/wireless/ath/ath10k/core.h
>>> > +++ b/drivers/net/wireless/ath/ath10k/core.h
>>> > @@ -720,6 +720,8 @@ struct ath10k {
>>> >u32 fw_cold_reset_counter;
>>> >} stats;
>>> >
>>> > + bool btc_feature;
>>>
>>> Could we use ar->dev_flags instead?
>>
>> This dev_flags currently used to mark some status, like the cradh, CAC
>> running,
>> The BTcoex feature is more likely a HW feature, there are seems different
>> set.
>>
>> Maybe a separately hw_feature_flag is needed as there are some other HW
>> feature
>> That we want to enable/disable from user space.
>
> I think we don't need a separate bitmap, we can use dev_flags just fine
> for this.
>
>>> > +static ssize_t ath10k_write_btc_feature(struct file *file,
>>> > + const char __user *ubuf,
>>> > + size_t count, loff_t *ppos)
>>> > +{
>>> > + struct ath10k *ar = file->private_data;
>>> > + char buf[32];
>>> > + size_t buf_size;
>>> > + bool val;
>>> > +
>>> > + buf_size = min(count, (sizeof(buf) - 1));
>>> > + if (copy_from_user(buf, ubuf, buf_size))
>>> > + return -EFAULT;
>>> > +
>>> > + buf[buf_size] = '\0';
>>> > + if (strtobool(buf, &val) != 0) {
>>> > + ath10k_warn(ar, "Wrong BTC feature setting\n");
>>> > + return -EINVAL;
>>> > + }
>>> > +
>>> > + mutex_lock(&ar->conf_mutex);
>>> > + ar->btc_feature = val;
>>> > + queue_work(ar->workqueue, &ar->restart_work);
>>> > + mutex_unlock(&ar->conf_mutex);
>>>
>>> Shouldn't we test ATH10K_STATE_ON first?
>>
>> The restart process will judge by itself whether the device is on or not,
>> and print below warning in that case:
>>
>> [797424.496190] ath10k_pci :05:00.0: cannot restart a device that
>> hasn't been started
>
> That's just buggy, ath10k should not print anything if a setting is
> changed while interface is down. It's much better we have the check for
> ATH10K_STATE_ON here.
>
Agree, will send v3 include these changes.
BR /Yanbo
--
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
Re: [PATCH] ath10k: Fix survey information reporting
On Fri, Jun 5, 2015 at 2:20 PM, Ben Greear wrote: > On 06/05/2015 02:00 PM, YanBo wrote: >> On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear wrote: >>> I think the wrapping might be even more weird that previously suspected. >>> Here is output from my >>> system. >>> >>> It looks to me that when cycle count overflows, it right-shifts all of these >>> counters one bit. Clever, I guess, but surely a pain in the ass to deal >>> with! >>> >>> >>> while true; do cat /debug/ieee80211/wiphy0/ath10k/fw_stats|head -10|tail >>> -4; date; echo;sleep 1; done >>> >>> TX frame count 131810463 >>> RX frame count 2326362883 >>> RX clear count 2542947851 >>>Cycle count 4180338939 >>> Fri Jun 5 13:13:48 PDT 2015 >>> >>> TX frame count 134407497 >>> RX frame count 2374518035 >>> RX clear count 2595337341 >>>Cycle count 4269010333 >>> Fri Jun 5 13:13:49 PDT 2015 >>> >>> TX frame count 69523007 >>> RX frame count 1229973316 >>> RX clear count 1344131636 >>>Cycle count 2210412416 >>> Fri Jun 5 13:13:50 PDT 2015 >>> >>> TX frame count 72305753 >>> RX frame count 1280184579 >>> RX clear count 1398937635 >>>Cycle count 2299234941 >>> Fri Jun 5 13:13:51 PDT 2015 >>> >>> TX frame count 75050021 >>> RX frame count 1330205664 >>> RX clear count 1453548082 >>>Cycle count 2387901854 >>> Fri Jun 5 13:13:52 PDT 2015 >>> >>> >> The scan count is 32 bits hence, it will wrap rapidly with 24 seconds >> cycle, the new WMI interface will >> supply these count in 64 bits to avoid such issue. > > That is not the problem... you can just sample often to resolve that. > > The problem is that the other 3 are divided by 2 at time when the main > cycle-counter counter wraps. So as far as I can tell, you cannot > actually calculate precise totals from old and new values for the > tx/rx/rx-clear > counters if cycle-counter has wrapped since you last read stats. > > Only way I can see to deal with it is to sample often enough that I can > afford to throw away samples where cycle-count wraps. With this implemented, > I see ath10k 'activity' calculation the same as ath9k. > > This wrap logic is coming out of the hardware registers as far as I > can tell, so I'm not sure that just firmware changes can really resolve > this fully. > > If all they are doing is implementing faster polling in the firmware > itself, that seems like a waste of effort and precious instruction RAM. > Exactly that the FW used to fixed this issue, as it is a HW limitation, they is no better way to correct it without faster polling Thanks BR /Yanbo -- 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
Re: [PATCH] ath10k: Fix survey information reporting
On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear wrote: > I think the wrapping might be even more weird that previously suspected. > Here is output from my > system. > > It looks to me that when cycle count overflows, it right-shifts all of these > counters one bit. Clever, I guess, but surely a pain in the ass to deal with! > > > while true; do cat /debug/ieee80211/wiphy0/ath10k/fw_stats|head -10|tail -4; > date; echo;sleep 1; done > > TX frame count 131810463 > RX frame count 2326362883 > RX clear count 2542947851 >Cycle count 4180338939 > Fri Jun 5 13:13:48 PDT 2015 > > TX frame count 134407497 > RX frame count 2374518035 > RX clear count 2595337341 >Cycle count 4269010333 > Fri Jun 5 13:13:49 PDT 2015 > > TX frame count 69523007 > RX frame count 1229973316 > RX clear count 1344131636 >Cycle count 2210412416 > Fri Jun 5 13:13:50 PDT 2015 > > TX frame count 72305753 > RX frame count 1280184579 > RX clear count 1398937635 >Cycle count 2299234941 > Fri Jun 5 13:13:51 PDT 2015 > > TX frame count 75050021 > RX frame count 1330205664 > RX clear count 1453548082 >Cycle count 2387901854 > Fri Jun 5 13:13:52 PDT 2015 > > The scan count is 32 bits hence, it will wrap rapidly with 24 seconds cycle, the new WMI interface will supply these count in 64 bits to avoid such issue. BR /Yanbo -- 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
Re: [PATCH] ath10k: Fix survey information reporting
On Fri, Jun 5, 2015 at 12:22 PM, Ben Greear wrote: > On 06/05/2015 12:10 PM, YanBo wrote: >> On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear wrote: >>> I applied these and some other related patches to my hacked-upon 4.0.4, but >>> I am seeing some inconsistencies between how ath10k and ath9k >>> reports survey info. I am using my CT firmware based on 10.1. >>> >>> ath9k reports ever-increasing counters for the channel time >>> and busy time. >>> >>> With ath10k, it reports the same values until I do a scan >>> again, and even then, it is not additive. >>> >>> First, should the value only update when we do a scan? >>> >>> And second, should ath10k report ever increasing totals >>> to match ath9k behaviour? >>> >> >> It should be match with ath9k, but the ath10k doesn't accumulate the >> survey count at currently code, >> I drafted a patch to fix this issue, will send to public mailist soon. > > I notice you can get current cycle stats out of the pdev stats as well, > and those update every time you ask firmware for stats. > > It won't be 100% accurate because you don't know when firmware > was off-channel or not, but I guess it will be better for me than > nothing. I certainly don't want to be scanning all the time, > but grabbing firmware stats already happens when you get ethtool > stats, so as long as I poll often enough to catch wraps, I think it > will be good enough. > > I guess to get really accurate values, one would have to hack the > firmware to keep its own accumulated stats and properly deal with > channel changes. > The new FW (from 10.2.4.70 IIRC) add an new WMI interface to supply such kinds of count. BR /Yanbo -- 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
Re: [PATCH] ath10k: Fix survey information reporting
On Fri, Jun 5, 2015 at 10:14 AM, Ben Greear wrote: > I applied these and some other related patches to my hacked-upon 4.0.4, but > I am seeing some inconsistencies between how ath10k and ath9k > reports survey info. I am using my CT firmware based on 10.1. > > ath9k reports ever-increasing counters for the channel time > and busy time. > > With ath10k, it reports the same values until I do a scan > again, and even then, it is not additive. > > First, should the value only update when we do a scan? > > And second, should ath10k report ever increasing totals > to match ath9k behaviour? > It should be match with ath9k, but the ath10k doesn't accumulate the survey count at currently code, I drafted a patch to fix this issue, will send to public mailist soon. BR /Yanbo -- 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
RE: [PATCH v2] ath10k: Debugfs entry to enable/disable WLAN&Blutooth Coexist feature
> -Original Message- > From: Jakub Kiciński [mailto:moorr...@wp.pl] > Sent: Tuesday, June 02, 2015 2:39 AM > To: Li, Yanbo > Cc: Valo, Kalle; dreamfly...@gmail.com; ath...@lists.infradead.org; linux- > wirel...@vger.kernel.org > Subject: Re: [PATCH v2] ath10k: Debugfs entry to enable/disable > WLAN&Blutooth Coexist feature > > On Thu, 28 May 2015 12:19:05 -0700, Yanbo Li wrote: > > As some radio have no connection with BT modules, enable the > > WLAN/Bluetooth > > coexist(BTC) feature will has some side effect if the radio's GPIO > > connect with any other HW modules. Add the control switcher > > "btc_feature" at debugfs and set the feature as disable by default to avoid > such case. > > > > To enable this feature, execute: > > echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature > > To disable: > > echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature > > > > Signed-off-by: Yanbo Li > > IMHO common API for disabling/enabling btcoex is something we would all > benefit from and easy enough to implement properly. Burying it in driver- > specific debugfs is less than appropriate. > > I seem to recall there were plans to discuss btcoex at one of the linux- > wireless summits. If the consensus was to leave it in debugfs then I > apologize for the noise ;) Thanks for your comments, agree with a general BTcoex interface will be good for lots of wlan chip/driver. It worth to be consider to implement such framework in future. BR /Yanbo -- 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
[PATCH 2/2] ath10k: Ignore the adjacent radio's activity when surveying a channel
The overall goal for a scanning radio is to evaluate the outside radio
environment. Some platforms integrate several radios together. When one radio
wants to survey the current channel, the adjacent radio's activity will make
this survey result inaccurate. the switcher can be used to enable the FW to
ignore the survey time slot when the adjacent radio is active, especially for
TX. This skipped scan approach will make the survey result more accurate.
This technique requires a precondition that the scanning and adjacent radio
have some physical connection to make them aware of each other's activity from
within the FW layer, and the FW claimed supporting this capability.
To enable this feature, execute:
echo 2 > /sys/kernel/debug/ieee80211/phyX/ath10k/adjacent_wlan_interfrc
Then run the survey scan and dump the stastics:
iw dev wifiX survey dump
The TX&RX counter showed already deducted the time slot be interfered
To check whether the feature is enabled, execute:
cat /sys/kernel/debug/ieee80211/phyX/ath10k/adjacent_wlan_interfrc
INTERFRC DETECT FOR SURVEY SCAN: Enable/Disable
Signed-off-by: Yanbo Li
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/debug.c | 4
drivers/net/wireless/ath/ath10k/wmi.c | 5 +
drivers/net/wireless/ath/ath10k/wmi.h | 7 +++
4 files changed, 17 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index fb0e8521fc45..164160aaf8a7 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -491,6 +491,7 @@ enum ath10k_cal_mode {
enum ath10k_wlan_interfrc_mask {
ATH10K_SPECTRAL_INTERFRC= 0x0001,
+ ATH10K_SURVEY_INTERFRC = 0x0002,
};
static inline const char *ath10k_cal_mode_str(enum ath10k_cal_mode mode)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 534dfb8ada95..3051cbaebc74 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2190,6 +2190,10 @@ static ssize_t ath10k_read_adjacent_wlan_interfrc(struct
file *file,
interfrc_5g);
len += scnprintf(buf + len, buf_len - len, "2G INTERFRC: %d\n",
interfrc_2g);
+ len += scnprintf(buf + len, buf_len - len,
+"INTERFRC DETECT FOR SURVEY SCAN: %s\n",
+ar->wlan_interfrc_mask & ATH10K_SURVEY_INTERFRC ?
+"Enable" : "Disable");
mutex_unlock(&ar->conf_mutex);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 1fb850817589..dbd394422905 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3942,6 +3942,11 @@ static struct sk_buff
*ath10k_wmi_10_2_op_gen_init(struct ath10k *ar)
ar->wmi.svc_map)))
features |= WMI_10_2_ADJ_RADIO_SPECTRAL_INTERFRC;
+ if ((ar->wlan_interfrc_mask & ATH10K_SURVEY_INTERFRC) &&
+ (test_bit(WMI_SERVICE_ADJ_RADIO_SURVEY_INTERFRC, ar->wmi.svc_map)))
+ features |= WMI_10_2_ADJ_RADIO_SURVEY_INTERFRC;
+
+
cmd->resource_config.feature_mask = __cpu_to_le32(features);
memcpy(&cmd->resource_config.common, &config, sizeof(config));
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 36bb0768d87f..7cbad1932bf5 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -151,6 +151,7 @@ enum wmi_service {
WMI_SERVICE_ATF,
WMI_SERVICE_COEX_GPIO,
WMI_SERVICE_ADJ_RADIO_SPECTRAL_INTERFRC,
+ WMI_SERVICE_ADJ_RADIO_SURVEY_INTERFRC,
/* keep last */
WMI_SERVICE_MAX,
@@ -183,6 +184,7 @@ enum wmi_10x_service {
WMI_10X_SERVICE_ATF,
WMI_10X_SERVICE_COEX_GPIO,
WMI_10X_SERVICE_ADJ_RADIO_SPECTRAL_INTERFRC,
+ WMI_10X_SERVICE_ADJ_RADIO_SURVEY_INTERFRC,
};
enum wmi_main_service {
@@ -302,6 +304,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_ATF);
SVCSTR(WMI_SERVICE_COEX_GPIO);
SVCSTR(WMI_SERVICE_ADJ_RADIO_SPECTRAL_INTERFRC);
+ SVCSTR(WMI_SERVICE_ADJ_RADIO_SURVEY_INTERFRC);
default:
return NULL;
@@ -372,6 +375,9 @@ static inline void wmi_10x_svc_map(const __le32 *in,
unsigned long *out,
WMI_SERVICE_COEX_GPIO, len);
SVCMAP(WMI_10X_SERVICE_ADJ_RADIO_SPECTRAL_INTERFRC,
WMI_SERVICE_ADJ_RADIO_SPECTRAL_INTERFRC, len);
+ SVCMAP(WMI_10X_SERVICE_ADJ_RADIO_SURVEY_INTERFRC,
+ WMI_SERVICE_ADJ_RADIO_SURVEY_INTERFRC, len);
+
}
static inline void wmi_main_svc_map(const __le32 *in, unsigned long *out,
@@ -1973,6 +1979,7 @@ en
[PATCH 1/2] ath10k: Add the adjacent wlan radio interference detecting interface
Some platforms integrate several radios together. When one radio wants to
spectral scan the currently channel, the adjacent radio's activity will
introduce some interference in the spectral scan result. To combat the
problem, enable the FW to set a special mark within the spectral scan
results. Using such a mark the user who is processing the data can identify
whether the data has been introduced to interference by the adjacent radio
during that period. The user can interpret more accurate spectral scan results
given marks where interference occurred.
This technique requires the preconditions that the scanning and adjacent radio
have some physical connection to make them aware of each other's activity
from within the FW layer, and the FW claimed supporting this capability.
To enable this feature, execute:
echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/adjacent_wlan_interfrc
Then run the spectral scan steps.
...
To check whether the spectral scan data be interfered, execute:
cat /sys/kernel/debug/ieee80211/phyX/ath10k/adjacent_wlan_interfrc
INTERFRC DETECT FOR SPEC SCAN: Enable/Disable
5G_interference: X/0
2G_Interference: X/0
X means the interference number in the scan period, 0 means no interference.
These counters will be reset when next round spectral scan be triggered
Signed-off-by: Yanbo Li
---
drivers/net/wireless/ath/ath10k/core.h | 8
drivers/net/wireless/ath/ath10k/debug.c| 65 ++
drivers/net/wireless/ath/ath10k/spectral.c | 14 +++
drivers/net/wireless/ath/ath10k/wmi.c | 6 +++
drivers/net/wireless/ath/ath10k/wmi.h | 10 +
5 files changed, 103 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 4a84e17016c9..fb0e8521fc45 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -489,6 +489,10 @@ enum ath10k_cal_mode {
ATH10K_CAL_MODE_DT,
};
+enum ath10k_wlan_interfrc_mask {
+ ATH10K_SPECTRAL_INTERFRC= 0x0001,
+};
+
static inline const char *ath10k_cal_mode_str(enum ath10k_cal_mode mode)
{
switch (mode) {
@@ -709,6 +713,8 @@ struct ath10k {
/* spectral_mode and spec_config are protected by conf_mutex */
enum ath10k_spectral_mode mode;
struct ath10k_spec_scan config;
+ u32 interfrc_5g;
+ u32 interfrc_2g;
} spectral;
struct {
@@ -729,6 +735,8 @@ struct ath10k {
} stats;
bool btc_feature;
+ /* Detect the adjacent wifi radio interference */
+ enum ath10k_wlan_interfrc_mask wlan_interfrc_mask;
struct ath10k_thermal thermal;
struct ath10k_wow wow;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 820a12bc0dd8..534dfb8ada95 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2142,6 +2142,66 @@ static const struct file_operations fops_btc_feature = {
.open = simple_open
};
+static ssize_t ath10k_write_adjacent_wlan_interfrc(struct file *file,
+ const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u32 flag;
+
+ if (kstrtouint_from_user(ubuf, count, 0, &flag))
+ return -EINVAL;
+
+ mutex_lock(&ar->conf_mutex);
+ if (flag != ar->wlan_interfrc_mask) {
+ ar->wlan_interfrc_mask = flag;
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
+ mutex_unlock(&ar->conf_mutex);
+
+ return count;
+}
+
+#define ATH10K_WLAN_INTFRC_REPORT_SIZE 256
+
+static ssize_t ath10k_read_adjacent_wlan_interfrc(struct file *file,
+ char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ char buf[ATH10K_WLAN_INTFRC_REPORT_SIZE];
+ struct ath10k *ar = file->private_data;
+ unsigned int len = 0;
+ unsigned int buf_len = ATH10K_WLAN_INTFRC_REPORT_SIZE;
+ u32 interfrc_5g, interfrc_2g;
+
+ mutex_lock(&ar->conf_mutex);
+
+ len += scnprintf(buf, buf_len,
+"INTERFRC DETECT FOR SPEC SCAN: %s\n",
+ar->wlan_interfrc_mask & ATH10K_SPECTRAL_INTERFRC ?
+"Enable" : "Disable");
+
+ spin_lock_bh(&ar->data_lock);
+ interfrc_5g = ar->spectral.interfrc_5g;
+ interfrc_2g = ar->spectral.interfrc_2g;
+ spin_unlock_bh(&ar->data_lock);
+
+ len += scnprintf(buf + len, buf_len - len, "5G INTERFRC: %d\n",
+interfrc_5g);
+ len += scnprintf(buf + len, buf_l
[PATCH v2] ath10k: Debugfs entry to enable/disable WLAN&Blutooth Coexist feature
As some radio have no connection with BT modules, enable the WLAN/Bluetooth
coexist(BTC) feature will has some side effect if the radio's GPIO connect
with any other HW modules. Add the control switcher "btc_feature" at
debugfs and set the feature as disable by default to avoid such case.
To enable this feature, execute:
echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
To disable:
echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
Signed-off-by: Yanbo Li
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 70fcdc9c2758..4a84e17016c9 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -728,6 +728,8 @@ struct ath10k {
u32 fw_cold_reset_counter;
} stats;
+ bool btc_feature;
+
struct ath10k_thermal thermal;
struct ath10k_wow wow;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 8fa606a9c4dd..820a12bc0dd8 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2092,6 +2092,56 @@ static const struct file_operations fops_quiet_period = {
.open = simple_open
};
+static ssize_t ath10k_write_btc_feature(struct file *file,
+ const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ char buf[32];
+ size_t buf_size;
+ bool val;
+
+ buf_size = min(count, (sizeof(buf) - 1));
+ if (copy_from_user(buf, ubuf, buf_size))
+ return -EFAULT;
+
+ buf[buf_size] = '\0';
+ if (strtobool(buf, &val) != 0) {
+ ath10k_warn(ar, "Wrong BTC feature setting\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&ar->conf_mutex);
+ if (val != ar->btc_feature) {
+ ar->btc_feature = val;
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
+ mutex_unlock(&ar->conf_mutex);
+
+ return count;
+}
+
+static ssize_t ath10k_read_btc_feature(struct file *file, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ char buf[32];
+ struct ath10k *ar = file->private_data;
+ int len = 0;
+
+ mutex_lock(&ar->conf_mutex);
+ len = scnprintf(buf, sizeof(buf) - len, "%d\n",
+ ar->btc_feature);
+ mutex_unlock(&ar->conf_mutex);
+
+ return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_btc_feature = {
+ .read = ath10k_read_btc_feature,
+ .write = ath10k_write_btc_feature,
+ .open = simple_open
+};
+
int ath10k_debug_create(struct ath10k *ar)
{
ar->debug.fw_crash_data = vzalloc(sizeof(*ar->debug.fw_crash_data));
@@ -2195,6 +2245,8 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("quiet_period", S_IRUGO | S_IWUSR,
ar->debug.debugfs_phy, ar, &fops_quiet_period);
+ debugfs_create_file("btc_feature", S_IRUGO | S_IWUSR,
+ ar->debug.debugfs_phy, ar, &fops_btc_feature);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 0fabe689179c..e3c880230ee6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3933,7 +3933,8 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
cmd = (struct wmi_init_cmd_10_2 *)buf->data;
features = WMI_10_2_RX_BATCH_MODE;
- if (test_bit(WMI_SERVICE_COEX_GPIO, ar->wmi.svc_map))
+ if (ar->btc_feature &&
+ test_bit(WMI_SERVICE_COEX_GPIO, ar->wmi.svc_map))
features |= WMI_10_2_COEX_GPIO;
cmd->resource_config.feature_mask = __cpu_to_le32(features);
--
1.9.1
--
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
RE: [PATCH] ath10k: Debugfs entry to enable/disable BTC feature
> -Original Message-
> From: Valo, Kalle
> Sent: Wednesday, May 27, 2015 5:57 AM
> To: Li, Yanbo
> Cc: dreamfly...@gmail.com; linux-wireless@vger.kernel.org;
> michal.kaz...@tieto.com; ath...@lists.infradead.org
> Subject: Re: [PATCH] ath10k: Debugfs entry to enable/disable BTC feature
>
> Yanbo Li writes:
>
> > As some radio have no connection with BT modules, enable the BTC
> > feature will has some side effect if the radio's GPIO connect with any
> > other HW modules. Add the control switcher "btc_feature" at debugfs
> > and set the feature as disable by default to avoid such case.
> >
> > To enable this feature, execute:
> > echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
> > To disable:
> > echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
>
> I suspect "BTC" does not really tell much for most of the people and
> acronyms should be always spelled out at least once.
>
> > Signed-off-by: Yanbo Li
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h
> > b/drivers/net/wireless/ath/ath10k/core.h
> > index 8444adf42195..6852e7fc5d5f 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -720,6 +720,8 @@ struct ath10k {
> > u32 fw_cold_reset_counter;
> > } stats;
> >
> > + bool btc_feature;
>
> Could we use ar->dev_flags instead?
This dev_flags currently used to mark some status, like the cradh, CAC running,
The BTcoex feature is more likely a HW feature, there are seems different set.
Maybe a separately hw_feature_flag is needed as there are some other HW feature
That we want to enable/disable from user space.
>
> > +static ssize_t ath10k_write_btc_feature(struct file *file,
> > + const char __user *ubuf,
> > + size_t count, loff_t *ppos)
> > +{
> > + struct ath10k *ar = file->private_data;
> > + char buf[32];
> > + size_t buf_size;
> > + bool val;
> > +
> > + buf_size = min(count, (sizeof(buf) - 1));
> > + if (copy_from_user(buf, ubuf, buf_size))
> > + return -EFAULT;
> > +
> > + buf[buf_size] = '\0';
> > + if (strtobool(buf, &val) != 0) {
> > + ath10k_warn(ar, "Wrong BTC feature setting\n");
> > + return -EINVAL;
> > + }
> > +
> > + mutex_lock(&ar->conf_mutex);
> > + ar->btc_feature = val;
> > + queue_work(ar->workqueue, &ar->restart_work);
> > + mutex_unlock(&ar->conf_mutex);
>
> Shouldn't we test ATH10K_STATE_ON first?
The restart process will judge by itself whether the device is on or not, and
print below warning in that case:
[797424.496190] ath10k_pci :05:00.0: cannot restart a device that hasn't
been started
>
> > int ath10k_debug_create(struct ath10k *ar) {
> > ar->debug.fw_crash_data = vzalloc(sizeof(*ar-
> >debug.fw_crash_data));
> > @@ -2195,6 +2243,8 @@ int ath10k_debug_register(struct ath10k *ar)
> > debugfs_create_file("quiet_period", S_IRUGO | S_IWUSR,
> > ar->debug.debugfs_phy, ar, &fops_quiet_period);
> >
> > + debugfs_create_file("btc_feature", S_IRUGO | S_IWUSR,
> > + ar->debug.debugfs_phy, ar,
> > &fops_btc_feature);
>
> At least some of the other drivers use term btcoex for this, I think we should
> be consistent and use the same.
>
> I can do the changes and send v2 for this.
Thanks and agree, I will send the 2v as there are some other tiny change at my
side.
BR /Yanbo
--
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
Re: [RFC 2/2] ath10k: don't disable PS when not connected
On Wed, Apr 15, 2015 at 9:35 PM, Janusz Dziedzic
wrote:
> On 15 April 2015 at 19:10, YanBo wrote:
>> On Tue, Apr 14, 2015 at 10:00 PM, Janusz Dziedzic
>> wrote:
>>> On 15 April 2015 at 00:45, YanBo wrote:
>>>> On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
>>>> wrote:
>>>>> Don't disable PS while we are not connected.
>>>>> In other case we will get higher power consumption.
>>>>>
>>>>> Signed-off-by: Janusz Dziedzic
>>>>> ---
>>>>> drivers/net/wireless/ath/ath10k/mac.c | 8 +++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>>>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>>>> index 52c5b1f..b896dd4 100644
>>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>>> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct
>>>>> ath10k_vif *arvif)
>>>>> enable_ps = false;
>>>>> }
>>>>>
>>>>> - if (enable_ps) {
>>>>> + if (!arvif->is_started) {
>>>>> + /* enable power save mode while not connected,
>>>>> +* in other case after iface up we will get
>>>>> +* higher power consumption - firmware design
>>>>> +*/
>>>>> + psmode = WMI_STA_PS_MODE_ENABLED;
>>>>> + } else if (enable_ps) {
>>>>> psmode = WMI_STA_PS_MODE_ENABLED;
>>>>> param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>>>>>
>>>>> --
>>>>
>>>> What the expectation behavior after we enable the
>>>> WMI_STA_PS_MODE_ENABLED at Idle status?
>>>> Is there any effect for TX or RX chain after set it?
>>>>
>>>
>>> First I think that WMI_STA_PS_MODE_ENABLED is important only when we
>>> are connected.
>>> But, I see current consumption drop in my test environtment from 88mA
>>> to 33mA when:
>>> 1) load driver, iface up
>>> 2) disconnect network, iface down, iface up
>>> So, seems WMI_STA_PS_MODE_ENABLED do something more in FW (not only
>>> standard PS enable/disable when
>>> connected to AP). Probably someone from FW team should answer that, if
>>> that is a feature or a bug.
>>>
>> I guess the chip enter Idle mode power save after set this, did you
>> run the the
>> test on QCA61XX or QCA 98XX? Can it still auto scan to get all the APs
>> around
>> it, cause for IMPS mode it will only looks in its existing profile
>> list and sends a probe request,
>> with SSID specified in profile for what I know
>>
> I see iw scan works correctly after iface up (same scan results like ath9k):
>
> In my laptop I have 3 cards
> wlan0 - ath9k
> wlan1 - QCA9888
> wlan4 - QCA6174
>
> janusz@dell6430:~$ sudo iw wlan0 scan dump|grep SSID |wc -l
> 0
> janusz@dell6430:~$ sudo iw wlan0 scan |grep SSID| wc -l
> 21
> janusz@dell6430:~$ sudo ifconfig wlan0 down
>
> janusz@dell6430:~$ sudo iw wlan1 scan dump|grep SSID|wc -l
> 0
> janusz@dell6430:~$ sudo iw wlan1 scan |grep SSID|wc -l
> 21
> janusz@dell6430:~$ sudo ifconfig wlan1 down
>
> janusz@dell6430:~$ sudo iw wlan4 scan dump|grep SSID|wc -l
> 0
> janusz@dell6430:~$ sudo iw wlan4 scan |grep SSID|wc -l
> 22
>
> Should I run any other scan tests?
>
Thanks for the verification, I also get the confirmation that the card will
leave IMPS mode when scanning, so it works as expected.
BR /Yanbo
--
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
Re: [RFC 2/2] ath10k: don't disable PS when not connected
On Tue, Apr 14, 2015 at 10:00 PM, Janusz Dziedzic
wrote:
> On 15 April 2015 at 00:45, YanBo wrote:
>> On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
>> wrote:
>>> Don't disable PS while we are not connected.
>>> In other case we will get higher power consumption.
>>>
>>> Signed-off-by: Janusz Dziedzic
>>> ---
>>> drivers/net/wireless/ath/ath10k/mac.c | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 52c5b1f..b896dd4 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif
>>> *arvif)
>>> enable_ps = false;
>>> }
>>>
>>> - if (enable_ps) {
>>> + if (!arvif->is_started) {
>>> + /* enable power save mode while not connected,
>>> +* in other case after iface up we will get
>>> +* higher power consumption - firmware design
>>> +*/
>>> + psmode = WMI_STA_PS_MODE_ENABLED;
>>> + } else if (enable_ps) {
>>> psmode = WMI_STA_PS_MODE_ENABLED;
>>> param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>>>
>>> --
>>
>> What the expectation behavior after we enable the
>> WMI_STA_PS_MODE_ENABLED at Idle status?
>> Is there any effect for TX or RX chain after set it?
>>
>
> First I think that WMI_STA_PS_MODE_ENABLED is important only when we
> are connected.
> But, I see current consumption drop in my test environtment from 88mA
> to 33mA when:
> 1) load driver, iface up
> 2) disconnect network, iface down, iface up
> So, seems WMI_STA_PS_MODE_ENABLED do something more in FW (not only
> standard PS enable/disable when
> connected to AP). Probably someone from FW team should answer that, if
> that is a feature or a bug.
>
I guess the chip enter Idle mode power save after set this, did you
run the the
test on QCA61XX or QCA 98XX? Can it still auto scan to get all the APs around
it, cause for IMPS mode it will only looks in its existing profile
list and sends a probe request,
with SSID specified in profile for what I know
BR /Yanbo
--
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
Re: [RFC 2/2] ath10k: don't disable PS when not connected
On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
wrote:
> Don't disable PS while we are not connected.
> In other case we will get higher power consumption.
>
> Signed-off-by: Janusz Dziedzic
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 52c5b1f..b896dd4 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif
> *arvif)
> enable_ps = false;
> }
>
> - if (enable_ps) {
> + if (!arvif->is_started) {
> + /* enable power save mode while not connected,
> +* in other case after iface up we will get
> +* higher power consumption - firmware design
> +*/
> + psmode = WMI_STA_PS_MODE_ENABLED;
> + } else if (enable_ps) {
> psmode = WMI_STA_PS_MODE_ENABLED;
> param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>
> --
What the expectation behavior after we enable the
WMI_STA_PS_MODE_ENABLED at Idle status?
Is there any effect for TX or RX chain after set it?
BR /Yanbo
--
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
Re: [PATCH] ath10k: Change the fw stats access mask
On Mon, Mar 30, 2015 at 6:31 AM, Kalle Valo wrote:
> Yanbo Li writes:
>
>> This fix the regerssion introduced after "ath10k_wmi_requests_stats()
>> call to use more stat bits", both the 10.2.X FW and community FW 10.1.X
>> will return time out when access the fw_stats with the STAT_VDEV and
>> STAT_PDEV. Add the condition to use different fw_stats mask for different
>> FW versions.
>>
>> Fixes:d8c7ef6f("ath10k: implement fw stats for wmi-tlv")
>> Signed-off-by: Yanbo Li
>
> There was a trivial conflict, please check my resolution in the pending
> branch.
>
Checked, looks well, Thanks
BR /Yanbo
--
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
[PATCH 2/2] ath10k: Enable the BT-coex feature
The new 10.2.4 FW support the BT-coex feature with external BT module,
The external BT modules can communicate with it via the GPIO. This patch
check the BT-coex capability of the FW and enable it by default.
Signed-off-by: Yanbo Li
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 54430a1a3f73..bff55188af9b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3960,6 +3960,8 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
cmd = (struct wmi_init_cmd_10_2 *)buf->data;
features = WMI_10_2_RX_BATCH_MODE;
+ if (test_bit(WMI_SERVICE_COEX_GPIO, ar->wmi.svc_map))
+ features |= WMI_10_2_COEX_GPIO;
cmd->resource_config.feature_mask = __cpu_to_le32(features);
memcpy(&cmd->resource_config.common, &config, sizeof(config));
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index a8f39d69eee2..b570dd391efa 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -149,6 +149,7 @@ enum wmi_service {
WMI_SERVICE_MDNS_OFFLOAD,
WMI_SERVICE_SAP_AUTH_OFFLOAD,
WMI_SERVICE_ATF,
+ WMI_SERVICE_COEX_GPIO,
/* keep last */
WMI_SERVICE_MAX,
@@ -179,6 +180,7 @@ enum wmi_10x_service {
WMI_10X_SERVICE_FORCE_FW_HANG,
WMI_10X_SERVICE_SMART_ANTENNA_HW_SUPPORT,
WMI_10X_SERVICE_ATF,
+ WMI_10X_SERVICE_COEX_GPIO,
};
enum wmi_main_service {
@@ -296,6 +298,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_MDNS_OFFLOAD);
SVCSTR(WMI_SERVICE_SAP_AUTH_OFFLOAD);
SVCSTR(WMI_SERVICE_ATF);
+ SVCSTR(WMI_SERVICE_COEX_GPIO);
default:
return NULL;
}
@@ -361,6 +364,8 @@ static inline void wmi_10x_svc_map(const __le32 *in,
unsigned long *out,
WMI_SERVICE_SMART_ANTENNA_HW_SUPPORT, len);
SVCMAP(WMI_10X_SERVICE_ATF,
WMI_SERVICE_ATF, len);
+ SVCMAP(WMI_10X_SERVICE_COEX_GPIO,
+ WMI_SERVICE_COEX_GPIO, len);
}
static inline void wmi_main_svc_map(const __le32 *in, unsigned long *out,
@@ -1957,6 +1962,7 @@ struct wmi_resource_config_10x {
enum wmi_10_2_feature_mask {
WMI_10_2_RX_BATCH_MODE = BIT(0),
WMI_10_2_ATF_CONFIG= BIT(1),
+ WMI_10_2_COEX_GPIO = BIT(3),
};
struct wmi_resource_config_10_2 {
--
1.9.1
--
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
[PATCH 1/2] ath10k: Add the WMI Air Time Fairness service define
Add the FW ATF (Air Time Fairness) service define to keep consistent
with 10.2 FW capability
Signed-off-by: Yanbo Li
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 938e6521776b..a8f39d69eee2 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -148,6 +148,7 @@ enum wmi_service {
WMI_SERVICE_STA_RX_IPA_OFFLOAD_SUPPORT,
WMI_SERVICE_MDNS_OFFLOAD,
WMI_SERVICE_SAP_AUTH_OFFLOAD,
+ WMI_SERVICE_ATF,
/* keep last */
WMI_SERVICE_MAX,
@@ -177,6 +178,7 @@ enum wmi_10x_service {
WMI_10X_SERVICE_SMART_ANTENNA_SW_SUPPORT,
WMI_10X_SERVICE_FORCE_FW_HANG,
WMI_10X_SERVICE_SMART_ANTENNA_HW_SUPPORT,
+ WMI_10X_SERVICE_ATF,
};
enum wmi_main_service {
@@ -293,6 +295,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_STA_RX_IPA_OFFLOAD_SUPPORT);
SVCSTR(WMI_SERVICE_MDNS_OFFLOAD);
SVCSTR(WMI_SERVICE_SAP_AUTH_OFFLOAD);
+ SVCSTR(WMI_SERVICE_ATF);
default:
return NULL;
}
@@ -356,6 +359,8 @@ static inline void wmi_10x_svc_map(const __le32 *in,
unsigned long *out,
WMI_SERVICE_FORCE_FW_HANG, len);
SVCMAP(WMI_10X_SERVICE_SMART_ANTENNA_HW_SUPPORT,
WMI_SERVICE_SMART_ANTENNA_HW_SUPPORT, len);
+ SVCMAP(WMI_10X_SERVICE_ATF,
+ WMI_SERVICE_ATF, len);
}
static inline void wmi_main_svc_map(const __le32 *in, unsigned long *out,
--
1.9.1
--
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
[PATCH] ath10k: Change the fw stats access mask
This fix the regerssion introduced after "ath10k_wmi_requests_stats()
call to use more stat bits", both the 10.2.X FW and community FW 10.1.X
will return time out when access the fw_stats with the STAT_VDEV and
STAT_PDEV. Add the condition to use different fw_stats mask for different
FW versions.
Fixes:d8c7ef6f("ath10k: implement fw stats for wmi-tlv")
Signed-off-by: Yanbo Li
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index c0e454bb6a8d..e1db4d018e90 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -958,6 +958,8 @@ static int ath10k_core_init_firmware_features(struct ath10k
*ar)
ar->max_num_stations = TARGET_NUM_STATIONS;
ar->max_num_vdevs = TARGET_NUM_VDEVS;
ar->htt.max_num_pending_tx = TARGET_NUM_MSDU_DESC;
+ ar->fw_stats_req_mask = WMI_STAT_PDEV | WMI_STAT_VDEV |
+ WMI_STAT_PEER;
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
case ATH10K_FW_WMI_OP_VERSION_10_2:
@@ -966,12 +968,15 @@ static int ath10k_core_init_firmware_features(struct
ath10k *ar)
ar->max_num_stations = TARGET_10X_NUM_STATIONS;
ar->max_num_vdevs = TARGET_10X_NUM_VDEVS;
ar->htt.max_num_pending_tx = TARGET_10X_NUM_MSDU_DESC;
+ ar->fw_stats_req_mask = WMI_STAT_PEER;
break;
case ATH10K_FW_WMI_OP_VERSION_TLV:
ar->max_num_peers = TARGET_TLV_NUM_PEERS;
ar->max_num_stations = TARGET_TLV_NUM_STATIONS;
ar->max_num_vdevs = TARGET_TLV_NUM_VDEVS;
ar->htt.max_num_pending_tx = TARGET_TLV_NUM_MSDU_DESC;
+ ar->fw_stats_req_mask = WMI_STAT_PDEV | WMI_STAT_VDEV |
+ WMI_STAT_PEER;
break;
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index cfd37a6e8931..1545a37c6360 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -514,6 +514,7 @@ struct ath10k {
u32 fw_version_minor;
u16 fw_version_release;
u16 fw_version_build;
+ u32 fw_stats_req_mask;
u32 phy_capability;
u32 hw_min_tx_power;
u32 hw_max_tx_power;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 51cf536fd014..544c22e0a1d8 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -395,10 +395,7 @@ static int ath10k_debug_fw_stats_request(struct ath10k *ar)
reinit_completion(&ar->debug.fw_stats_complete);
- ret = ath10k_wmi_request_stats(ar,
- WMI_STAT_PDEV |
- WMI_STAT_VDEV |
- WMI_STAT_PEER);
+ ret = ath10k_wmi_request_stats(ar, ar->fw_stats_req_mask);
if (ret) {
ath10k_warn(ar, "could not request stats (%d)\n", ret);
return ret;
--
1.9.1
--
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
Re: [RFTv2 2/5] ath10k: fix wmi-htc tx credit starvation
Hi Michal,
What the conclusion about this patch, it looks like this patch not be
merged into ath10K due to introduce some unstable issue, I'v got
another issue that when move the station enter hibernate mode. the AP
will continue report message like before
[ 3958.681293] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
[ 3959.681449] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
[ 3960.681696] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
[ 3961.681877] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
[ 3962.682080] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
[ 3963.682361] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
[ 3964.682550] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
[ 3965.682743] ath10k_pci :01:00.0: Spurious quick kickout for STA
00:03:7f:40:04:5b
and there are also error message like this be happened at early time:
[ 1316.883053] ath10k_pci :01:00.0: SWBA overrun on vdev 0
[ 1316.912357] ath10k_pci :01:00.0: failed to transmit management
frame via WMI: -11
[ 1316.985476] ath10k_pci :01:00.0: SWBA overrun on vdev 0
I suspect it is triggered as you mentioned because the HTC Tx credits
are drained
to 0 and no other commands can be submitted, if the answer is yes,
I'd hear your suggestion about whether this patch still worth to be
continue improve to solve such kinds of issue.
Thanks
BR /Yanbo
On Wed, Apr 9, 2014 at 3:48 AM, Michal Kazior wrote:
> Each WMI management Tx consumes 1 HTC Tx credit
> and doesn't replenish it until the frame is
> actually transmitted out of firmware's Tx queues.
>
> If associated client was asleep and has gone out
> of range then unicast frames won't be released for
> FW/HW queues for a while (10 seconds per
> observation). This means that if more management
> frames are queued then HTC Tx credits are drained
> to 0 and no other commands can be submitted
> including beacons and peer removal.
>
> This could in turn result in clients disconnecting
> due to their beacon loss and may trigger spurious
> sta kickouts because wmi peer removal command may
> never reach firmware during disassociation.
>
> This could happen, e.g. when disconnecting
> client (hostapd inactivity) that has gone away
> while asleep when acting as AP.
>
> As a workaround flush frames that can potentialy
> get stuck in FW Tx queues.
>
> Signed-off-by: Michal Kazior
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 96
> +++
> drivers/net/wireless/ath/ath10k/wmi.c | 5 --
> drivers/net/wireless/ath/ath10k/wmi.h | 3 ++
> 3 files changed, 99 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 58ec5a7..5cfbf88 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2076,9 +2076,67 @@ void ath10k_mgmt_over_wmi_tx_purge(struct ath10k *ar)
> }
> }
>
> +static void ath10k_mgmt_tx_flush(struct ath10k *ar, struct sk_buff *skb)
> +{
> + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
> + struct ieee80211_sta *sta;
> + struct ath10k_vif *arvif;
> + u8 *da = ieee80211_get_DA(hdr);
> + u8 vdev_id = ATH10K_SKB_CB(skb)->vdev_id;
> + u32 bcn_intval = 0;
> + unsigned int msecs;
> + int ret;
> +
> + lockdep_assert_held(&ar->conf_mutex);
> +
> + if (!is_unicast_ether_addr(da))
> + return;
> +
> + rcu_read_lock();
> + sta = ieee80211_find_sta_by_ifaddr(ar->hw, da, NULL);
> + rcu_read_unlock();
> +
> + /*
> +* FW Tx queues can be paused only for associated peers. Since this is
> +* a workaround just assume worst case if station simply entry exists.
> +*/
> + if (!sta)
> + return;
> +
> + list_for_each_entry(arvif, &ar->arvifs, list) {
> + if (arvif->vdev_id == vdev_id) {
> + bcn_intval = arvif->beacon_interval;
> + break;
> + }
> + }
> +
> + if (!bcn_intval)
> + return;
> +
> + /*
> +* Wait 2 beacon intervals before flushing so stations that are
> +* asleep but are actually still in range have a chance to see
> +* updated PVB, wake up and fetch the frame. There's no other way of
> +* synchronizing other than sleeping because there's no tx completion
> +* indication event for WMI management tx.
> +*/
&
[PATCH] ath10k: Enable the MCS8 and MCS9 at 2.4G band
From: Yanbo Li
Enable the MCS8 and MCS9 support for 2.4G band, it will
use these data rate with other devices having the same
capability.
Signed-off-by: Yanbo Li
---
drivers/net/wireless/ath/ath10k/mac.c | 14 --
drivers/net/wireless/ath/ath10k/wmi.h |2 +-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 9524bc5..0b11c9c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1557,6 +1557,10 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
return;
arg->peer_flags |= WMI_PEER_VHT;
+
+ if (ar->hw->conf.chandef.chan->band == IEEE80211_BAND_2GHZ)
+ arg->peer_flags |= WMI_PEER_VHT_2G;
+
arg->peer_vht_caps = vht_cap->cap;
ampdu_factor = (vht_cap->cap &
@@ -1635,7 +1639,12 @@ static void ath10k_peer_assoc_h_phymode(struct ath10k
*ar,
switch (ar->hw->conf.chandef.chan->band) {
case IEEE80211_BAND_2GHZ:
- if (sta->ht_cap.ht_supported) {
+ if (sta->vht_cap.vht_supported) {
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
+ phymode = MODE_11AC_VHT40;
+ else
+ phymode = MODE_11AC_VHT20;
+ } else if (sta->ht_cap.ht_supported) {
if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
phymode = MODE_11NG_HT40;
else
@@ -5215,7 +5224,8 @@ int ath10k_mac_register(struct ath10k *ar)
band->bitrates = ath10k_g_rates;
band->ht_cap = ht_cap;
- /* vht is not supported in 2.4 GHz */
+ /* Enable the VHT support at 2.4 GHz */
+ band->vht_cap = vht_cap;
ar->hw->wiphy->bands[IEEE80211_BAND_2GHZ] = band;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index bd7f29a..6de92e8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4430,7 +4430,7 @@ struct wmi_peer_set_q_empty_callback_cmd {
#define WMI_PEER_SPATIAL_MUX0x0020
#define WMI_PEER_VHT0x0200
#define WMI_PEER_80MHZ 0x0400
-#define WMI_PEER_PMF0x0800
+#define WMI_PEER_VHT_2G 0x0800
/*
* Peer rate capabilities.
--
1.7.9.5
--
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
Re: DFS CAC time
One correct based on the patch, the 5600 should be change with 5590, or else the channel 128 will be disabled in my testing. + (5490 - 5590 @ 80), (27), DFS, AUTO-BW + (5590 - 5650 @ 40), (27), (60), DFS, AUTO-BW + (5650 - 5710 @ 40), (27), DFS, AUTO-BW BR /Yanbo On Fri, Dec 19, 2014 at 8:28 PM, Janusz Dziedzic wrote: > On 19 December 2014 at 12:27, Zefir Kurtisi wrote: >> On 12/18/2014 05:21 PM, Helmut Schaa wrote: >>> Hi, >>> >>> [...] >>> >>> So, every channel has a CAC time of 60 seconds. >>> >>> Checking version 1.7.2 of the ETSI regulation indicates that we might >>> need some modifications to cfg80211: >>> >>> From [1] page 79: >>> >>> "NOTE 1: For channels whose nominal bandwidth falls completely or >>> partly within the >>> band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be >>> 10 minutes. >>> NOTE 2: For channels whose nominal bandwidth falls completely or >>> partly within the >>> band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the >>> range 1 hour to 24 hours." >>> >>> So, for these channels we should select a longer initial CAC time. >>> >>> Is anyone aware of this issue? >>> >>> Thanks, >>> Helmut >>> >>> >>> [1] >>> http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf >>> -- >> >> Hello Helmut, >> >> just forget about those aka 'weather channels' that require a pracitcally >> impossible to achieve radar detection probability rate (99.99% during CAC, >> see >> table D.5). >> >> They should simply be disabled, either at mac layer, or at least in >> ath/regd.c. >> > > You can use internal regdb and set this correctly in db.txt, eg > > + (5490 - 5600 @ 80), (27), DFS, AUTO-BW > + (5600 - 5650 @ 40), (27), (60), DFS, AUTO-BW > + (5650 - 5710 @ 40), (27), DFS, AUTO-BW > > There are also patches for crda/wireless-regdb but not merged, so use > internal regdb. > > BR > Janusz > -- > 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 -- 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
Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests
On Tue, Nov 25, 2014 at 10:18 PM, Johannes Berg wrote: > On Tue, 2014-11-25 at 22:13 +0800, YanBo wrote: > >> > But is all of that really the right way? I'm not completely convinced. >> >> Except set the flag, the HW itself should support this feature, or >> else it also doesn't work, I'd >> send the patch in soon for public review. > > Yeah, but is it really the right way to advertise VHT? In the spec, VHT > means you also have 80 MHz support - do you really think you can/will do > 80 MHz on 2.4 GHz? Seems like all of this will cause more corner cases. > >> > Agree with you that it need a bigger discussion about whether advertise VHT is the suitable/best way to support the VHT at 2.4G feature. We are considered this ways as it is already be used by some vendor like BRCM or Qualcomm Atheros in there full mac product, and there will be IOT issue if there are kinds of different implementation. Thanks BR /Yanbo -- 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
Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests
On Tue, Nov 25, 2014 at 8:07 PM, Johannes Berg wrote: > On Tue, 2014-11-25 at 19:10 +0800, YanBo wrote: > >> We already start the working to support the VHT modulations MCS8 and >> MCS9 support in 2.4G for ath10k devices, >> and it used the band->vht_cap = vht_cap to notification the mac80211, >> if we band it with 80MHz, it is do need another >> new advertisement for this as your said. > > But is all of that really the right way? I'm not completely convinced. Except set the flag, the HW itself should support this feature, or else it also doesn't work, I'd send the patch in soon for public review. > > I guess we can make this check conditional for 5GHz when the VHT support > lands and is discussed. > That is sounds good if it only check for 5GHz for what I know CMIIW. Thanks BR /Yanbo -- 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
Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests
On Tue, Nov 25, 2014 at 7:04 PM, Johannes Berg wrote: > On Tue, 2014-11-25 at 19:00 +0800, YanBo wrote: >> On Tue, Nov 25, 2014 at 6:23 PM, Johannes Berg >> wrote: >> > From: Johannes Berg >> > >> > If there are no channels allowing 80 MHz to be used, then the >> > station isn't really VHT capable even if the driver and device >> > support it in general. In this case, exclude the VHT capability >> > IE from probe request frames. >> > >> >> FYI, there are some new devices could support the VHT even at 20Mhz >> band 2.4G mode. > > So in 2.4 GHz we typically don't have VHT anyway - and realistically you > can't support real "VHT" there, you can only support the new > modulations. I think this will require some custom (vendor-specific) > advertisement though, since VHT advertisement implies 80 MHz support. > > IOW, I think at this point this patch isn't a problem. If we really need > to support VHT modulations in 2.4 GHz (or even have devices that have > VHT modulation support, but no 80 MHz support in 5 GHz) then some new > advertisement will have to be done. > We already start the working to support the VHT modulations MCS8 and MCS9 support in 2.4G for ath10k devices, and it used the band->vht_cap = vht_cap to notification the mac80211, if we band it with 80MHz, it is do need another new advertisement for this as your said. Thanks BR /Yanbo -- 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
Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests
On Tue, Nov 25, 2014 at 6:23 PM, Johannes Berg wrote: > From: Johannes Berg > > If there are no channels allowing 80 MHz to be used, then the > station isn't really VHT capable even if the driver and device > support it in general. In this case, exclude the VHT capability > IE from probe request frames. > FYI, there are some new devices could support the VHT even at 20Mhz band 2.4G mode. BR /Yanbo -- 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
[PATCH] ath10k: Add the target register access and memory dump debugfs interface
The debugfs interface reg_addr®_val used to read and write the target
register.
The interface mmem_val used to dump the targer memory and also can be
used to assign value to target memory
The basic usage explain as below:
Register read/write:
reg_addr (the register address)(read&write)
reg_value (the register value, output is ASCII)(read&write)
Read operation:
1. Write the reg address to reg_addr
IE: echo 0x10 > reg_addr
2. Read the value from reg_value
IE: cat reg_value
Write operation:
1. Write the reg address to reg_addr IE: echo 0x10 > reg_addr
2. Write the value to the reg_value IE: echo 0x2400 > reg_value
Target memory dump:
mem_value (the target memory, access with the length and start address
(read&write)
Read operation:
1: Read 4K(bs*count)) from address 0x40(bs*skip)
dd if=mem_value bs=4 count=1024 skip=1048576 | xxd -g1
2: Read 0x5(bs*count) from address 0x40(bs*skip)
dd if=mem_value bs=4 count=81920 skip=1048576 | xxd -g1
Write operation:
1: Write the 0x01020304 to address 0x400400(bs*seek)
echo 0x01020304 | xxd -r | dd of=mem_value bs=4 seek=1048832
2: Read the memory and then write back after edit
dd if=mem_value bs=4 count=1024 skip=1048576 > tmp.bin
edit the tmp.bin
dd if=tmp.bin of=mem_value bs=4 count=4 seek=1048576
It suggests assign the 4 align number to bs, IE, 4, 8, 16
Cause the target memory width is 32bit
Signed-off-by: Yanbo Li
---
drivers/net/wireless/ath/ath10k/core.h |2 +
drivers/net/wireless/ath/ath10k/debug.c | 189 +++
drivers/net/wireless/ath/ath10k/hif.h | 37 ++
drivers/net/wireless/ath/ath10k/pci.c |3 +
4 files changed, 231 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd3..5cb4fe9 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -321,6 +321,8 @@ struct ath10k_debug {
u32 fw_dbglog_mask;
u32 pktlog_filter;
+ u32 reg_addr;
+
u8 htt_max_amsdu;
u8 htt_max_ampdu;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index a8f5a72..302ad55 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -22,6 +22,7 @@
#include
#include "core.h"
+#include "hif.h"
#include "debug.h"
#include "hif.h"
@@ -929,6 +930,185 @@ static const struct file_operations fops_fw_crash_dump = {
.llseek = default_llseek,
};
+static ssize_t ath10k_reg_addr_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u8 buf[32];
+ unsigned int len = 0;
+ u32 reg_addr;
+
+ spin_lock_bh(&ar->data_lock);
+ reg_addr = ar->debug.reg_addr;
+ spin_unlock_bh(&ar->data_lock);
+
+ len += scnprintf(buf + len, sizeof(buf) - len, "0x%x\n", reg_addr);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_reg_addr_write(struct file *file,
+const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u32 reg_addr;
+ int ret;
+
+ ret = kstrtou32_from_user(user_buf, count, 0, ®_addr);
+ if (ret)
+ return ret;
+
+ if (!IS_ALIGNED(reg_addr, 4))
+ return -EFAULT;
+
+ spin_lock_bh(&ar->data_lock);
+ ar->debug.reg_addr = reg_addr;
+ spin_unlock_bh(&ar->data_lock);
+
+ return count;
+}
+
+static const struct file_operations fops_reg_addr = {
+ .read = ath10k_reg_addr_read,
+ .write = ath10k_reg_addr_write,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
+static ssize_t ath10k_reg_value_read(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u8 buf[48];
+ unsigned int len;
+ u32 reg_addr, reg_val;
+
+ spin_lock_bh(&ar->data_lock);
+ reg_addr = ar->debug.reg_addr;
+ spin_unlock_bh(&ar->data_lock);
+
+ reg_val = ath10k_hif_read32(ar, reg_addr);
+ len = scnprintf(buf, sizeof(buf), "0x%08x:0x%08x\n", reg_addr, reg_val);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_reg_value_write(struct file *file,
+ const char __user *user_buf,
+
RE: [PATCH] Add the target register read/write and memory dump debugfs interface
> -Original Message- > From: John W. Linville [mailto:linvi...@tuxdriver.com] > Sent: Friday, November 21, 2014 3:45 AM > To: Li, Yanbo > Cc: Valo, Kalle; dreamfly...@gmail.com; michal.kaz...@tieto.com; > ath...@lists.infradead.org; linux-wireless@vger.kernel.org > Subject: Re: [PATCH] Add the target register read/write and memory dump > debugfs interface > > The subject should start like "ath10k: ..." > Resend with the prefix, please review base on the new thread. Thanks BR /Yanbo -- 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
[PATCH] Add the target register read/write and memory dump debugfs interface
The debugfs interface reg_addr®_val used to read and write the target
register.
The interface mmem_val used to dump the targer memory and also can be
used to assign value to target memory
The basic usage explain as below:
Register read/write:
reg_addr (the register address)(read&write)
reg_value (the register value, output is ASCII)(read&write)
Read operation:
1. Write the reg address to reg_addr
IE: echo 0x10 > reg_addr
2. Read the value from reg_value
IE: cat reg_value
Write operation:
1. Write the reg address to reg_addr IE: echo 0x10 > reg_addr
2. Write the value to the reg_value IE: echo 0x2400 > reg_value
Target memory dump:
mem_value (the target memory, access with the length and start address
(read&write)
Read operation:
1: Read 4K(bs*count)) from address 0x40(bs*skip)
dd if=mem_value bs=4 count=1024 skip=1048576 | xxd -g1
2: Read 0x5(bs*count) from address 0x40(bs*skip)
dd if=mem_value bs=4 count=81920 skip=1048576 | xxd -g1
Write operation:
1: Write the 0x01020304 to address 0x400400(bs*seek)
echo 0x01020304 | xxd -r | dd of=mem_value bs=4 seek=1048832
2: Read the memory and then write back after edit
dd if=mem_value bs=4 count=1024 skip=1048576 > tmp.bin
edit the tmp.bin
dd if=tmp.bin of=mem_value bs=4 count=4 seek=1048576
It suggests assign the 4 align number to bs, IE, 4, 8, 16
Cause the target memory width is 32bit
Signed-off-by: Yanbo Li
---
drivers/net/wireless/ath/ath10k/core.h |2 +
drivers/net/wireless/ath/ath10k/debug.c | 189 +++
drivers/net/wireless/ath/ath10k/hif.h | 37 ++
drivers/net/wireless/ath/ath10k/pci.c |3 +
4 files changed, 231 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd3..5cb4fe9 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -321,6 +321,8 @@ struct ath10k_debug {
u32 fw_dbglog_mask;
u32 pktlog_filter;
+ u32 reg_addr;
+
u8 htt_max_amsdu;
u8 htt_max_ampdu;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index a8f5a72..302ad55 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -22,6 +22,7 @@
#include
#include "core.h"
+#include "hif.h"
#include "debug.h"
#include "hif.h"
@@ -929,6 +930,185 @@ static const struct file_operations fops_fw_crash_dump = {
.llseek = default_llseek,
};
+static ssize_t ath10k_reg_addr_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u8 buf[32];
+ unsigned int len = 0;
+ u32 reg_addr;
+
+ spin_lock_bh(&ar->data_lock);
+ reg_addr = ar->debug.reg_addr;
+ spin_unlock_bh(&ar->data_lock);
+
+ len += scnprintf(buf + len, sizeof(buf) - len, "0x%x\n", reg_addr);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_reg_addr_write(struct file *file,
+const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u32 reg_addr;
+ int ret;
+
+ ret = kstrtou32_from_user(user_buf, count, 0, ®_addr);
+ if (ret)
+ return ret;
+
+ if (!IS_ALIGNED(reg_addr, 4))
+ return -EFAULT;
+
+ spin_lock_bh(&ar->data_lock);
+ ar->debug.reg_addr = reg_addr;
+ spin_unlock_bh(&ar->data_lock);
+
+ return count;
+}
+
+static const struct file_operations fops_reg_addr = {
+ .read = ath10k_reg_addr_read,
+ .write = ath10k_reg_addr_write,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
+static ssize_t ath10k_reg_value_read(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u8 buf[48];
+ unsigned int len;
+ u32 reg_addr, reg_val;
+
+ spin_lock_bh(&ar->data_lock);
+ reg_addr = ar->debug.reg_addr;
+ spin_unlock_bh(&ar->data_lock);
+
+ reg_val = ath10k_hif_read32(ar, reg_addr);
+ len = scnprintf(buf, sizeof(buf), "0x%08x:0x%08x\n", reg_addr, reg_val);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_reg_value_write(struct file *file,
+ const char __user *user_buf,
+
Re: [PATCH v3] Add the target register read/write and memory dump debugfs interface
On Fri, Oct 24, 2014 at 9:57 PM, Kalle Valo wrote: > > Yanbo Li writes: > > > The debugfs interface reg_addr®_val used to read and write the target > > register. > > The interface mem_addr&mem_val used to dump the targer memory and also > > can be used to assign value to target memory > > I think you got the mail from kbuild bot already, but this patch has a > sparse warning: > > >> drivers/net/wireless/ath/ath10k/debug.c:1182:26: sparse: incorrect type in > >> assignment (different base types) >drivers/net/wireless/ath/ath10k/debug.c:1182:26:expected restricted > __le32 [usertype] >drivers/net/wireless/ath/ath10k/debug.c:1182:26:got unsigned int > [unsigned] [addressable] [usertype] mem_val > Thanks for checking, will fix in local and submit again together with Michal's suggestion. BR /Yanbo -- 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
RE: [PATCH v3] ath10k: Add the target register read/write and memory dump debugfs interface
Hi Michal,
Thanks for your comments. answered as below,
> -Original Message-
> From: Michal Kazior [mailto:michal.kaz...@tieto.com]
> Sent: Tuesday, October 21, 2014 2:56 PM
> To: Li, Yanbo
> Cc: Valo, Kalle; ath10k-devel; Balasubramanian, Senthil Kumar;
> dreamfly...@gmail.com; linux-wireless; ath...@lists.infradead.org
> Subject: Re: [PATCH v3] Add the target register read/write and memory dump
> debugfs interface
>
> You're missing "ath10k: " prefix in the patch subject.
>
Change the subject, :)
>
> On 20 October 2014 18:38, Yanbo Li wrote:
> > The debugfs interface reg_addr®_val used to read and write the
> > target register.
> > The interface mem_addr&mem_val used to dump the targer memory and also
> > can be used to assign value to target memory
> >
> > The basic usage explain as below:
> >
> > Register read/write:
> > reg_addr (the register address)(read&write)
> > reg_value (the register value, output is ASCII)(read&write)
> >
> > Read operation:
> > 1. Write the reg address to reg_addr
> >IE: echo 0x10 > reg_addr
> > 2. Read the value from reg_value
> >IE: cat reg_value
> > Write operation:
> > 1. Write the reg address to reg_addr IE: echo 0x10 > reg_addr 2.
> > Write the value to the reg_value IE: echo 0x2400 > reg_value
> >
> > Target memory dump:
> > mem_addr (the memory address the length also can used as the second
> > paramenter address length) (read&write)
> > mem_value (the content of the memory with the length, output is binary)
> > (read&write)
> > Read operation:
> > 1. Write the address and length to mem_addr
> >IE: echo 0x40 1024 > mem_addr
>
> So mem_addr is actually used to store both _addr_ and _length_. I think length
> could be skipped and be read implicitly from each read() request along with
> the
> offset. This way userspace would be able to determine read length on demand,
> e.g.
> via "dd if=mem_value bs=1024 count=4" (read 4 KiB of data). If you want to see
> hex, you would pipe it through "hexdump" or "xxd" or your other favourite
> hexdump program.
> Or even better - you could drop the mem_addr altogether and expect userspace
> to
> seek & read/write data it wants via, e.g. `dd` program:
>
> dd if=mem_value bs=1 count=1024 skip=$(printf "%d" 0x40) | xxd -g1
> echo 0x01020304 | xxd -r | dd of=mem_value bs=1 seek=$(printf "%d" 0x400400)
>
Agree with you, that will be easy to access and avoid the one variable
(mem_addr)store two different values.
>
> > 2. Read the value from mem value, the output is binary format
> >IE: hexdump mem_value
> > Write operation:
> > 1. Write the start mem address to mem_addr
> >IE: echo 0x40 > mem_addr
> > 2. Dump the binary value to the mem_value
> >IE: echo 0x2400 > mem_value or echo 0x2400 0x3400 ... > mem_addr
> >(the value number should be separated with spacebar)
>
> I don't really like the idea of input being different than the output, but
> maybe that's
> just me.
>
Hmm, I will implement another version to keep the read and write use the same
interface,
the extra effort is the user need edit the binary file to construct the input
number.
>
> [...]
> > +static ssize_t ath10k_mem_value_write(struct file *file,
> > + const char __user *user_buf,
> > + size_t count, loff_t *ppos) {
> > + struct ath10k *ar = file->private_data;
> > + u8 *buf;
> > + __le32 *value;
> > + char *sptr, *token;
> > + int i, ret;
> > + u32 mem_addr;
> > + u32 mem_val;
> > +
> > + mem_addr = ar->debug.mem_addr;
>
> There's double space following "=".
>
Good catch.
>
> [...]
> > + i = 0;
> > + while (sptr) {
> > + if (!sptr)
> > + break;
> > +
> > + token = strsep(&sptr, " ");
> > +
> > + ret = kstrtou32(token, 0, &mem_val);
> > + if (ret)
> > + goto err_free_value;
> > +
> > + value[i] = mem_val;
> > + i++;
> > + }
> > +
> > + ret = ath10k_hif_diag_write(ar, mem_addr, (const void *)value,
> > +
[PATCH v3] Add the target register read/write and memory dump debugfs interface
The debugfs interface reg_addr®_val used to read and write the target
register.
The interface mem_addr&mem_val used to dump the targer memory and also
can be used to assign value to target memory
The basic usage explain as below:
Register read/write:
reg_addr (the register address)(read&write)
reg_value (the register value, output is ASCII)(read&write)
Read operation:
1. Write the reg address to reg_addr
IE: echo 0x10 > reg_addr
2. Read the value from reg_value
IE: cat reg_value
Write operation:
1. Write the reg address to reg_addr IE: echo 0x10 > reg_addr
2. Write the value to the reg_value IE: echo 0x2400 > reg_value
Target memory dump:
mem_addr (the memory address the length also can used as the second
paramenter address length) (read&write)
mem_value (the content of the memory with the length, output is binary)
(read&write)
Read operation:
1. Write the address and length to mem_addr
IE: echo 0x40 1024 > mem_addr
2. Read the value from mem value, the output is binary format
IE: hexdump mem_value
Write operation:
1. Write the start mem address to mem_addr
IE: echo 0x40 > mem_addr
2. Dump the binary value to the mem_value
IE: echo 0x2400 > mem_value or echo 0x2400 0x3400 ... > mem_addr
(the value number should be separated with spacebar)
Signed-off-by: Yanbo Li
---
drivers/net/wireless/ath/ath10k/core.h |6 +
drivers/net/wireless/ath/ath10k/debug.c | 292 +++
drivers/net/wireless/ath/ath10k/hif.h | 35
drivers/net/wireless/ath/ath10k/pci.c |3 +
4 files changed, 336 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index fe531ea..ab97f7a 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -304,6 +304,12 @@ struct ath10k_debug {
u32 fw_dbglog_mask;
+ u32 reg_addr;
+
+ u32 mem_addr;
+ unsigned int mem_len;
+ u32 mem_value;
+
u8 htt_max_amsdu;
u8 htt_max_ampdu;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index c192114..85122db 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -22,6 +22,7 @@
#include
#include "core.h"
+#include "hif.h"
#include "debug.h"
/* ms */
@@ -825,6 +826,285 @@ static const struct file_operations fops_fw_crash_dump = {
.llseek = default_llseek,
};
+static ssize_t ath10k_reg_addr_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u8 buf[32];
+ unsigned int len = 0;
+
+ len += scnprintf(buf + len, sizeof(buf) - len,
+"0x%x\n", ar->debug.reg_addr);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_reg_addr_write(struct file *file,
+const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u32 reg_addr;
+ int ret;
+
+ ret = kstrtou32_from_user(user_buf, count, 0, ®_addr);
+ if (ret)
+ return ret;
+
+ if (!IS_ALIGNED(reg_addr, 4))
+ return -EFAULT;
+
+ ar->debug.reg_addr = reg_addr;
+
+ return count;
+}
+
+static const struct file_operations fops_reg_addr = {
+ .read = ath10k_reg_addr_read,
+ .write = ath10k_reg_addr_write,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
+static ssize_t ath10k_reg_value_read(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u8 buf[48];
+ unsigned int len;
+ u32 reg_addr, reg_val;
+
+ reg_addr = ar->debug.reg_addr;
+
+ reg_val = ath10k_hif_read32(ar, reg_addr);
+ len = scnprintf(buf, sizeof(buf), "0x%08x:0x%08x\n", reg_addr, reg_val);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_reg_value_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ u32 reg_addr, reg_val;
+ int ret;
+
+ reg_addr = ar->debug.reg_addr;
+
+ ret = kstrtou32_from_user(user_buf, count, 0, ®_val);
+ if (ret)
+ return ret;
+
+ ath10k_h
