Re: [PATCH 3/3] ath10k: fix station count enforcement

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> The number of peers isn't directly translatable to
> the number of stations because ath10k needs to
> reserve a few extra peers for special cases like
> multi-vif concurrency.
>
> The previous limit was 126 and 15 stations in AP
> mode for 10.x and main firmware branches
> respectively. The limit is now 128 and 16 which
> was the original intention.
>
> Signed-off-by: Michal Kazior 

[...]

> +static void ath10k_core_init_max_sta_count(struct ath10k *ar)
> +{
> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features)) {
> + ar->max_num_peers = TARGET_10X_NUM_PEERS;
> + ar->max_num_stations = TARGET_10X_NUM_STATIONS;
> + } else {
> + ar->max_num_peers = TARGET_NUM_PEERS;
> + ar->max_num_stations = TARGET_NUM_STATIONS;
> + }
> +}
> +
>  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
>  {
>   int status;
> @@ -939,6 +950,8 @@ int ath10k_core_start(struct ath10k *ar, enum 
> ath10k_firmware_mode mode)
>   else
>   ar->free_vdev_map = (1LL << TARGET_NUM_VDEVS) - 1;
>  
> + ath10k_core_init_max_sta_count(ar);

I don't see the need to call this during every firmware start as these
are not changed afterwards. I think it would be better to call this once
just after ath10k_core_fetch_firmware_files() is called.

-- 
Kalle Valo

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

Re: [PATCH 1/2] ath10k: move create-ht-cap methods above set-antenna.

2014-11-25 Thread Kalle Valo 
gree...@candelatech.com writes:

> From: Ben Greear 
>
> We will need to use these in set-antenna, so move them
> so that we do not have to define the method signatures.
>
> Signed-off-by: Ben Greear 

I'm dropping these two patches. Please resend once we figure out how to
handle the band updated.

-- 
Kalle Valo

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

Re: [PATCH 3/3] ath10k: fix station count enforcement

2014-11-25 Thread Michal Kazior 
On 25 November 2014 at 09:01, Kalle Valo  wrote:
> Michal Kazior  writes:
>
>> The number of peers isn't directly translatable to
>> the number of stations because ath10k needs to
>> reserve a few extra peers for special cases like
>> multi-vif concurrency.
>>
>> The previous limit was 126 and 15 stations in AP
>> mode for 10.x and main firmware branches
>> respectively. The limit is now 128 and 16 which
>> was the original intention.
>>
>> Signed-off-by: Michal Kazior 
>
> [...]
>
>> +static void ath10k_core_init_max_sta_count(struct ath10k *ar)
>> +{
>> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features)) {
>> + ar->max_num_peers = TARGET_10X_NUM_PEERS;
>> + ar->max_num_stations = TARGET_10X_NUM_STATIONS;
>> + } else {
>> + ar->max_num_peers = TARGET_NUM_PEERS;
>> + ar->max_num_stations = TARGET_NUM_STATIONS;
>> + }
>> +}
>> +
>>  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
>>  {
>>   int status;
>> @@ -939,6 +950,8 @@ int ath10k_core_start(struct ath10k *ar, enum 
>> ath10k_firmware_mode mode)
>>   else
>>   ar->free_vdev_map = (1LL << TARGET_NUM_VDEVS) - 1;
>>
>> + ath10k_core_init_max_sta_count(ar);
>
> I don't see the need to call this during every firmware start as these
> are not changed afterwards. I think it would be better to call this once
> just after ath10k_core_fetch_firmware_files() is called.

Hmm.. It makes sense but now that I think about it the max number of
peers should actually depend on WMI_SERVICE_IRAM_TIDS which is known
after booting firmware. However since only 10.x was released with the
service enabled we used fw_features. So.. yeah. I can move the
function call if you want though.


Michał

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

Re: [PATCH v2 1/2] ath10k: add register access debugfs interface

2014-11-25 Thread Kalle Valo 
Kalle Valo  writes:

> +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);
> +}

I just realised that we need to check ar->state to make sure that
firmware is running. Because of that I'll need to change the data_lock
to conf_mutex as well.

> +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;
> +
> + spin_lock_bh(&ar->data_lock);
> + reg_addr = ar->debug.reg_addr;
> + spin_unlock_bh(&ar->data_lock);
> +
> + ret = kstrtou32_from_user(user_buf, count, 0, ®_val);
> + if (ret)
> + return ret;
> +
> + ath10k_hif_write32(ar, reg_addr, reg_val);
> +
> + return count;
> +}

And same here as well. I'll send v3.

-- 
Kalle Valo

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

Re: [PATCH v2 2/2] ath10k: add memory dump debugfs interface

2014-11-25 Thread Kalle Valo 
Kalle Valo  writes:

> +static ssize_t ath10k_mem_value_read(struct file *file,
> +  char __user *user_buf,
> +  size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar = file->private_data;
> + u8 *buf;
> + int ret;
> +
> + if (*ppos < 0)
> + return -EINVAL;
> +
> + if (!count)
> + return 0;
> +
> + buf = vmalloc(count);
> + if (!buf)
> + return -ENOMEM;
> +
> + ret = ath10k_hif_diag_read(ar, *ppos, buf, count);
> + if (ret) {
> + ath10k_warn(ar, "failed to read address 0x%08x via diagnose 
> window from debugfs: %d\n",
> + (u32)(*ppos), ret);
> + goto read_err;
> + }
> +

[...]

> +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;
> + int ret;
> +
> + if (*ppos < 0)
> + return -EINVAL;
> +
> + if (!count)
> + return 0;
> +
> + buf = vmalloc(count);
> + if (!buf)
> + return -ENOMEM;
> +
> + ret = copy_from_user(buf, user_buf, count);
> + if (ret)
> + goto err_free_copy;
> +
> + ret = ath10k_hif_diag_write(ar, *ppos, buf, count);
> + if (ret) {
> + ath10k_warn(ar, "failed to write address 0x%08x via diagnose 
> window from debugfs: %d\n",
> + (u32)(*ppos), ret);
> + goto err_free_copy;
> + }

In these two functions we also need to check ar->state.

-- 
Kalle Valo

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

Re: [PATCH 3/3] ath10k: fix station count enforcement

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

>>>  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
>>>  {
>>>   int status;
>>> @@ -939,6 +950,8 @@ int ath10k_core_start(struct ath10k *ar, enum 
>>> ath10k_firmware_mode mode)
>>>   else
>>>   ar->free_vdev_map = (1LL << TARGET_NUM_VDEVS) - 1;
>>>
>>> + ath10k_core_init_max_sta_count(ar);
>>
>> I don't see the need to call this during every firmware start as these
>> are not changed afterwards. I think it would be better to call this once
>> just after ath10k_core_fetch_firmware_files() is called.
>
> Hmm.. It makes sense but now that I think about it the max number of
> peers should actually depend on WMI_SERVICE_IRAM_TIDS which is known
> after booting firmware. However since only 10.x was released with the
> service enabled we used fw_features. So..

I think this is good enough for now. We can always improve this later.

> yeah. I can move the function call if you want though.

Please do that. To keep things simple I would like to have the absolute
minimum in start() calls.

-- 
Kalle Valo

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

Re: [PATCH v2 1/2] ath10k: add register access debugfs interface

2014-11-25 Thread Michal Kazior 
On 25 November 2014 at 09:39, Kalle Valo  wrote:
> Kalle Valo  writes:
>
>> +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);
>> +}
>
> I just realised that we need to check ar->state to make sure that
> firmware is running. Because of that I'll need to change the data_lock
> to conf_mutex as well.

Hmm.. It could actually work without firmware running. It just reads MMIO.

The problem I see now is the target may not be awake (Bartosz recently
fixed suspend bug by moving ath10k_pci_wake/sleep back to
hif_power_up) and accessing target registers without it being fully
awake can lead to host memory corruption. I guess ar->state will do
for now because getting this to work otherwise is going to be a little
tricky.


Michał

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

Re: [PATCH v2 2/2] ath10k: add memory dump debugfs interface

2014-11-25 Thread Michal Kazior 
On 25 November 2014 at 09:41, Kalle Valo  wrote:
> Kalle Valo  writes:
>
>> +static ssize_t ath10k_mem_value_read(struct file *file,
>> +  char __user *user_buf,
>> +  size_t count, loff_t *ppos)
>> +{
[...]
>> +static ssize_t ath10k_mem_value_write(struct file *file,
>> +   const char __user *user_buf,
>> +   size_t count, loff_t *ppos)
[...]
> In these two functions we also need to check ar->state.

It should work but the pci_wake (I've mentioned in the other mail) is
tricky though.


Michał

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

Re: [PATCH] ath10k: don't drop corrupted mgmt frames

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -1381,6 +1381,8 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k 
> *ar,
>  {
>   struct sk_buff *msdu;
>   struct htt_rx_desc *rxd;
> + bool is_mgmt;
> + bool has_fcs_err;
>  
>   msdu = skb_peek(amsdu);
>   rxd = (void *)msdu->data - sizeof(*rxd);
> @@ -1394,12 +1396,19 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k 
> *ar,
>   return false;
>   }
>  
> + is_mgmt = !!(rxd->attention.flags &
> +  __cpu_to_le32(RX_ATTENTION_FLAGS_MGMT_TYPE));
> + has_fcs_err = !!(rxd->attention.flags &
> +  __cpu_to_le32(RX_ATTENTION_FLAGS_FCS_ERR));

I think I asked this before in some other patch, but isn't '!!' operator
useless here? is_mgmt is a boolean so the compiler should convert it
correctly without '!!' anyway, right?

-- 
Kalle Valo

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

Experimenting with patchwork

2014-11-25 Thread Kalle Valo 
Hi,

to make it easier to handle the patchflow I'm experimenting with
patchwork at the moment. From patch submitters point of view nothing
changes at the moment, except one can easily check the state of his
patch from patchwork:

https://patchwork.kernel.org/project/ath10k/list/

Let's see how this goes. Feel free to send comments if this is helpful
or not.

-- 
Kalle Valo

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

Re: [PATCH] ath10k: don't drop corrupted mgmt frames

2014-11-25 Thread Michal Kazior 
On 25 November 2014 at 10:04, Kalle Valo  wrote:
> Michal Kazior  writes:
[...]
>> @@ -1394,12 +1396,19 @@ static bool ath10k_htt_rx_amsdu_allowed(struct 
>> ath10k *ar,
>>   return false;
>>   }
>>
>> + is_mgmt = !!(rxd->attention.flags &
>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_MGMT_TYPE));
>> + has_fcs_err = !!(rxd->attention.flags &
>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_FCS_ERR));
>
> I think I asked this before in some other patch, but isn't '!!' operator
> useless here? is_mgmt is a boolean so the compiler should convert it
> correctly without '!!' anyway, right?

If I remove `!!` I get:

 warning: incorrect type in assignment (different base types)
expected bool [unsigned] [usertype] is_mgmt
got restricted __le32

I could do a temporary `u32 attention` to get rid of the `!!`. You
want me to update it?


Michał

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

Re: [PATCH] ath10k: don't drop corrupted mgmt frames

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> On 25 November 2014 at 10:04, Kalle Valo  wrote:
>> Michal Kazior  writes:
> [...]
>>> @@ -1394,12 +1396,19 @@ static bool ath10k_htt_rx_amsdu_allowed(struct 
>>> ath10k *ar,
>>>   return false;
>>>   }
>>>
>>> + is_mgmt = !!(rxd->attention.flags &
>>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_MGMT_TYPE));
>>> + has_fcs_err = !!(rxd->attention.flags &
>>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_FCS_ERR));
>>
>> I think I asked this before in some other patch, but isn't '!!' operator
>> useless here? is_mgmt is a boolean so the compiler should convert it
>> correctly without '!!' anyway, right?
>
> If I remove `!!` I get:
>
>  warning: incorrect type in assignment (different base types)
> expected bool [unsigned] [usertype] is_mgmt
> got restricted __le32

Oh. Sorry, my bad.

> I could do a temporary `u32 attention` to get rid of the `!!`. You
> want me to update it?

Please don't, this is fine.

-- 
Kalle Valo

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

Re: [PATCH 2/2] ath10k: re-config ht_caps when chainmask is modified.

2014-11-25 Thread Felix Fietkau 
On 2014-11-24 11:53, Kalle Valo wrote:
> Kalle Valo  writes:
> 
>>> @@ -2537,6 +2560,17 @@ static int __ath10k_set_antenna(struct ath10k *ar, 
>>> u32 tx_ant, u32 rx_ant)
>>> ar->cfg_tx_chainmask = tx_ant;
>>> ar->cfg_rx_chainmask = rx_ant;
>>>  
>>> +   ht_cap = ath10k_get_ht_cap(ar, true);
>>> +   vht_cap = ath10k_create_vht_cap(ar, true);
>>> +
>>> +   if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY)
>>> +   ar->mac.sbands[IEEE80211_BAND_2GHZ].ht_cap = ht_cap;
>>> +
>>> +   if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
>>> +   ar->mac.sbands[IEEE80211_BAND_5GHZ].ht_cap = ht_cap;
>>> +   ar->mac.sbands[IEEE80211_BAND_5GHZ].vht_cap = vht_cap;
>>> +   }
>>
>> So this modifies stryct wiphy::bands after we have called
>> ieee80211_register_hw(). Is this something which both cfg80211 and
>> mac80211 support? I didn't find the documentation mentioning anything
>> about this so I got a bit worried.
> 
> Johannes mentioned me that this is not supported so I am reluctant to
> take these. Unless I'm missing something, of course.
FWIW, ath9k has been doing the same for a long time now. Antenna
settings can only be changed while the device is stopped, so it should
be safe.

- Felix

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

[PATCH v3 0/2] ath10k: firmware memory debugfs interface

2014-11-25 Thread Kalle Valo 
Hi,

this is v3 of Yanbo's firmware memory debugfs interface.

Changelog:

v3:

* check ath10k state and return an error if firmware is not running

* switch to use conf_mutex because using ar->state

* fix copy_from_user() error handling

v2:

* split patches into two

* simplify the commit logs

* remove extra #include "hif.h" from debug.c

---

Yanbo Li (2):
  ath10k: add register access debugfs interface
  ath10k: add memory dump debugfs interface


 drivers/net/wireless/ath/ath10k/core.h  |1 
 drivers/net/wireless/ath/ath10k/debug.c |  239 +++
 drivers/net/wireless/ath/ath10k/hif.h   |   37 +
 drivers/net/wireless/ath/ath10k/pci.c   |3 
 4 files changed, 280 insertions(+)


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

[PATCH v3 1/2] ath10k: add register access debugfs interface

2014-11-25 Thread Kalle Valo 
From: Yanbo Li 

Debugfs files reg_addr and reg_val are used for reading and writing to the
firmware (target) registers. reg_addr contains the address to be accessed,
which also needs to be set first, and reg_value is when used for reading and
writing the actual value in ASCII.

To read a value from the firmware register 0x10:

# echo 0x10 > reg_addr
# cat reg_value
0x0010:0x02d3

To write value 0x2400 to address 0x10:

# echo 0x10 > reg_addr
# echo  0x2400 > reg_value
#

Signed-off-by: Yanbo Li 
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/core.h  |1 
 drivers/net/wireless/ath/ath10k/debug.c |  125 +++
 drivers/net/wireless/ath/ath10k/hif.h   |   26 ++
 drivers/net/wireless/ath/ath10k/pci.c   |2 
 4 files changed, 154 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd34e823..f5f2dcd2b65d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -320,6 +320,7 @@ struct ath10k_debug {
/* protected by conf_mutex */
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 f10721da4980..d0397d119862 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -928,6 +928,125 @@ 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;
+
+   mutex_lock(&ar->conf_mutex);
+   reg_addr = ar->debug.reg_addr;
+   mutex_unlock(&ar->conf_mutex);
+
+   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;
+
+   mutex_lock(&ar->conf_mutex);
+   ar->debug.reg_addr = reg_addr;
+   mutex_unlock(&ar->conf_mutex);
+
+   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;
+   int ret;
+
+   mutex_lock(&ar->conf_mutex);
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   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);
+
+   ret = simple_read_from_buffer(user_buf, count, ppos, buf, len);
+
+exit:
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+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;
+
+   mutex_lock(&ar->conf_mutex);
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   reg_addr = ar->debug.reg_addr;
+
+   ret = kstrtou32_from_user(user_buf, count, 0, ®_val);
+   if (ret)
+   goto exit;
+
+   ath10k_hif_write32(ar, reg_addr, reg_val);
+
+   ret = count;
+
+exit:
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static const struct file_operations fops_reg_value = {
+   .read = ath10k_reg_value_read,
+   .write = ath10k_reg_value_write,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 static int ath10k_debug_htt_stats_req(struct ath10k *ar)
 {
u64 cookie;
@@ -1629,6 +1748

[PATCH v3 2/2] ath10k: add memory dump debugfs interface

2014-11-25 Thread Kalle Valo 
From: Yanbo Li 

Add mem_val debugfs file for dumping the firmware (target) memory and also for
writing to the memory. The firmware memory is accessed through one file which
uses position of the file as the firmware memory address. For example, with dd
use skip parameter for the address.

Beucase target memory width is 32 bits it's strongly recommended to use
blocksize divisable with 4 when using this interface. For example, when using
dd use bs=4 to set the block size to 4 and remember to divide both count and
skip values with four.

To read 4 kB chunk from address 0x40:

dd if=mem_value bs=4 count=1024 skip=1048576 | xxd -g1

To write value 0x01020304 to address 0x400400:

echo 0x01020304 | xxd -r | dd of=mem_value bs=4 seek=1048832

To read 4 KB chunk of memory and then write back after edit:

dd if=mem_value of=tmp.bin bs=4 count=1024 skip=1048576
emacs tmp.bin
dd if=tmp.bin of=mem_value bs=4 count=1024 seek=1048576

Signed-off-by: Yanbo Li 
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/debug.c |  114 +++
 drivers/net/wireless/ath/ath10k/hif.h   |   11 +++
 drivers/net/wireless/ath/ath10k/pci.c   |1 
 3 files changed, 126 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index d0397d119862..ff831ca507f7 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1047,6 +1047,117 @@ static const struct file_operations fops_reg_value = {
.llseek = default_llseek,
 };
 
+static ssize_t ath10k_mem_value_read(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   u8 *buf;
+   int ret;
+
+   if (*ppos < 0)
+   return -EINVAL;
+
+   if (!count)
+   return 0;
+
+   mutex_lock(&ar->conf_mutex);
+
+   buf = vmalloc(count);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto exit;
+   }
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   ret = ath10k_hif_diag_read(ar, *ppos, buf, count);
+   if (ret) {
+   ath10k_warn(ar, "failed to read address 0x%08x via diagnose 
window fnrom debugfs: %d\n",
+   (u32)(*ppos), ret);
+   goto exit;
+   }
+
+   ret = copy_to_user(user_buf, buf, count);
+   if (ret) {
+   ret = -EFAULT;
+   goto exit;
+   }
+
+   count -= ret;
+   *ppos += count;
+   ret = count;
+
+exit:
+   vfree(buf);
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+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;
+   int ret;
+
+   if (*ppos < 0)
+   return -EINVAL;
+
+   if (!count)
+   return 0;
+
+   mutex_lock(&ar->conf_mutex);
+
+   buf = vmalloc(count);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto exit;
+   }
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   ret = copy_from_user(buf, user_buf, count);
+   if (ret) {
+   ret = -EFAULT;
+   goto exit;
+   }
+
+   ret = ath10k_hif_diag_write(ar, *ppos, buf, count);
+   if (ret) {
+   ath10k_warn(ar, "failed to write address 0x%08x via diagnose 
window from debugfs: %d\n",
+   (u32)(*ppos), ret);
+   goto exit;
+   }
+
+   *ppos += count;
+   ret = count;
+
+exit:
+   vfree(buf);
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static const struct file_operations fops_mem_value = {
+   .read = ath10k_mem_value_read,
+   .write = ath10k_mem_value_write,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 static int ath10k_debug_htt_stats_req(struct ath10k *ar)
 {
u64 cookie;
@@ -1754,6 +1865,9 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("reg_value", S_IRUSR | S_IWUSR,
ar->debug.debugfs_phy, ar, &fops_reg_value);
 
+   debugfs_create_file("mem_value", S_IRUSR | S_IWUSR,
+   ar->debug.debugfs_phy, ar, &fops_mem_value);
+
debugfs_create_file("chip_id", S_IRUSR, ar->debug.debugfs_phy,
ar, &fops_chip_id);
 
diff --git a/drivers/net/wireless/ath/ath10k/hif.h 
b/drivers/net/wireless/ath/ath10k/hif.h
index bad071906540..6ac552304546 100644
--- a/drive

[PATCH v2 3/3] ath10k: fix station count enforcement

2014-11-25 Thread Michal Kazior 
The number of peers isn't directly translatable to
the number of stations because ath10k needs to
reserve a few extra peers for special cases like
multi-vif concurrency.

The previous limit was 126 and 15 stations in AP
mode for 10.x and main firmware branches
respectively. The limit is now 128 and 16 which
was the original intention.

Signed-off-by: Michal Kazior 
---

Notes:
v2:
 * move ath10k_core_init_max_sta_count() call to
   ath10k_core_probe_fw() before ath10k_core_stat() [Kalle]

 drivers/net/wireless/ath/ath10k/core.c  | 13 +++
 drivers/net/wireless/ath/ath10k/core.h  |  4 +++
 drivers/net/wireless/ath/ath10k/debug.c |  5 +--
 drivers/net/wireless/ath/ath10k/hw.h| 15 ++---
 drivers/net/wireless/ath/ath10k/mac.c   | 60 ++---
 drivers/net/wireless/ath/ath10k/wmi.c   |  2 +-
 6 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f660553..7762061 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -799,6 +799,17 @@ static void ath10k_core_restart(struct work_struct *work)
mutex_unlock(&ar->conf_mutex);
 }
 
+static void ath10k_core_init_max_sta_count(struct ath10k *ar)
+{
+   if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features)) {
+   ar->max_num_peers = TARGET_10X_NUM_PEERS;
+   ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+   } else {
+   ar->max_num_peers = TARGET_NUM_PEERS;
+   ar->max_num_stations = TARGET_NUM_STATIONS;
+   }
+}
+
 int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
 {
int status;
@@ -1035,6 +1046,8 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
return ret;
}
 
+   ath10k_core_init_max_sta_count(ar);
+
mutex_lock(&ar->conf_mutex);
 
ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL);
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index be7e50b6..ab3b656 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -562,6 +562,10 @@ struct ath10k {
 
/* protected by conf_mutex */
int num_peers;
+   int num_stations;
+
+   int max_num_peers;
+   int max_num_stations;
 
struct work_struct offchan_tx_work;
struct sk_buff_head offchan_tx_queue;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index f10721d..49930e2 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -123,7 +123,7 @@ EXPORT_SYMBOL(ath10k_info);
 
 void ath10k_print_driver_info(struct ath10k *ar)
 {
-   ath10k_info(ar, "%s (0x%08x, 0x%08x) fw %s api %d htt %d.%d wmi 
%d.%d.%d.%d cal %s\n",
+   ath10k_info(ar, "%s (0x%08x, 0x%08x) fw %s api %d htt %d.%d wmi 
%d.%d.%d.%d cal %s max_sta %d\n",
ar->hw_params.name,
ar->target_version,
ar->chip_id,
@@ -135,7 +135,8 @@ void ath10k_print_driver_info(struct ath10k *ar)
ar->fw_version_minor,
ar->fw_version_release,
ar->fw_version_build,
-   ath10k_cal_mode_str(ar->cal_mode));
+   ath10k_cal_mode_str(ar->cal_mode),
+   ar->max_num_stations);
ath10k_info(ar, "debug %d debugfs %d tracing %d dfs %d testmode %d\n",
config_enabled(CONFIG_ATH10K_DEBUG),
config_enabled(CONFIG_ATH10K_DEBUGFS),
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index 392c250..dfedfd0 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -97,11 +97,13 @@ struct ath10k_pktlog_hdr {
 #define TARGET_DMA_BURST_SIZE  0
 #define TARGET_MAC_AGGR_DELIM  0
 #define TARGET_AST_SKID_LIMIT  16
-#define TARGET_NUM_PEERS   16
+#define TARGET_NUM_STATIONS16
+#define TARGET_NUM_PEERS   ((TARGET_NUM_STATIONS) + \
+(TARGET_NUM_VDEVS))
 #define TARGET_NUM_OFFLOAD_PEERS   0
 #define TARGET_NUM_OFFLOAD_REORDER_BUFS 0
 #define TARGET_NUM_PEER_KEYS   2
-#define TARGET_NUM_TIDS(2 * ((TARGET_NUM_PEERS) + 
(TARGET_NUM_VDEVS)))
+#define TARGET_NUM_TIDS((TARGET_NUM_PEERS) * 2)
 #define TARGET_TX_CHAIN_MASK   (BIT(0) | BIT(1) | BIT(2))
 #define TARGET_RX_CHAIN_MASK   (BIT(0) | BIT(1) | BIT(2))
 #define TARGET_RX_TIMEOUT_LO_PRI   100
@@ -132,12 +134,15 @@ struct ath10k_pktlog_hdr {
 #define TARGET_10X_DMA_BURST_SIZE  0
 #define TARGET_10X_MAC_AGGR_DELIM  0
 #de

[PATCH v2 1/3] ath10k: add missing goto

2014-11-25 Thread Michal Kazior 
This prevents warning spamming if peer creation
fails during sta_state in some cases.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 1245ac8..7b5a888 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3559,9 +3559,11 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
   arvif->vdev_id, sta->addr, ar->num_peers);
 
ret = ath10k_peer_create(ar, arvif->vdev_id, sta->addr);
-   if (ret)
+   if (ret) {
ath10k_warn(ar, "failed to add peer %pM for vdev %d 
when adding a new sta: %i\n",
sta->addr, arvif->vdev_id, ret);
+   goto exit;
+   }
 
if (vif->type == NL80211_IFTYPE_STATION) {
WARN_ON(arvif->is_started);
-- 
1.8.5.3


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

[PATCH v2 2/3] ath10k: clean up num_peers locking

2014-11-25 Thread Michal Kazior 
The var was supposed to be protected by data_lock
but it wasn't so in all instances. It's actually
not necessary to have a spinlock protected
num_peers so drop it.

All instances of num_peers are already within
conf_mutex sections so use that.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/core.h | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd3..be7e50b6 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -560,7 +560,7 @@ struct ath10k {
struct list_head peers;
wait_queue_head_t peer_mapping_wq;
 
-   /* number of created peers; protected by data_lock */
+   /* protected by conf_mutex */
int num_peers;
 
struct work_struct offchan_tx_work;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 7b5a888..3312e75 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -339,9 +339,8 @@ static int ath10k_peer_create(struct ath10k *ar, u32 
vdev_id, const u8 *addr)
addr, vdev_id, ret);
return ret;
}
-   spin_lock_bh(&ar->data_lock);
+
ar->num_peers++;
-   spin_unlock_bh(&ar->data_lock);
 
return 0;
 }
@@ -432,9 +431,7 @@ static int ath10k_peer_delete(struct ath10k *ar, u32 
vdev_id, const u8 *addr)
if (ret)
return ret;
 
-   spin_lock_bh(&ar->data_lock);
ar->num_peers--;
-   spin_unlock_bh(&ar->data_lock);
 
return 0;
 }
@@ -471,8 +468,9 @@ static void ath10k_peer_cleanup_all(struct ath10k *ar)
list_del(&peer->list);
kfree(peer);
}
-   ar->num_peers = 0;
spin_unlock_bh(&ar->data_lock);
+
+   ar->num_peers = 0;
 }
 
 //
-- 
1.8.5.3


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

Re: [PATCH 1/2] ath10k: move create-ht-cap methods above set-antenna.

2014-11-25 Thread Ben Greear 
On 11/25/2014 12:08 AM, Kalle Valo wrote:
> gree...@candelatech.com writes:
> 
>> From: Ben Greear 
>>
>> We will need to use these in set-antenna, so move them
>> so that we do not have to define the method signatures.
>>
>> Signed-off-by: Ben Greear 
> 
> I'm dropping these two patches. Please resend once we figure out how to
> handle the band updated.

It might be a while...I'm working on some other tasks these days
and don't have time to respin ath10k patches at the moment.

If someone else wants to work on getting them upstream, please be
my guest.

Per Felix's comment, maybe my patches were actually OK as they are

Thanks,
Ben

-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

[PATCH 1/2] ath10k: add new pdev parameters for fw 10.2

2014-11-25 Thread Peter Oh 
New pdev paramters have been added to firmware 10.2,
hence update wmi interfaces to sync with.

Signed-off-by: Peter Oh 
---
 drivers/net/wireless/ath/ath10k/wmi.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index a38d788..8fa0192 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2707,6 +2707,9 @@ enum wmi_10x_pdev_param {
WMI_10X_PDEV_PARAM_SET_MCAST2UCAST_MODE,
WMI_10X_PDEV_PARAM_SET_MCAST2UCAST_BUFFER,
WMI_10X_PDEV_PARAM_REMOVE_MCAST2UCAST_BUFFER,
+   WMI_10X_PDEV_PEER_STA_PS_STATECHG_ENABLE,
+   WMI_10X_PDEV_PARAM_RTS_FIXED_RATE,
+   WMI_10X_PDEV_PARAM_CAL_PERIOD
 };
 
 struct wmi_pdev_set_param_cmd {
-- 
1.9.1


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

[PATCH 2/2] ath10k: add new wmi interface of NF cal period

2014-11-25 Thread Peter Oh 
Introduce a new wmi interface controls noise floor (NF) calibration
period via debugfs as firmware has introduced it on v10.2.

It allows users to modify frequency of NF calibration in millisecond
and changes RSSI reporting frequency consequently.
Short calibration period will trigger more frequent NF calibration,
so that RSSI reported in receive frames is more realistic.

Till now calibration was done at 30 seconds.

Signed-off-by: Peter Oh 
---
 drivers/net/wireless/ath/ath10k/core.h  |  1 +
 drivers/net/wireless/ath/ath10k/debug.c | 64 +
 drivers/net/wireless/ath/ath10k/wmi.c   |  2 ++
 drivers/net/wireless/ath/ath10k/wmi.h   |  1 +
 4 files changed, 68 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd3..5de988c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -320,6 +320,7 @@ struct ath10k_debug {
/* protected by conf_mutex */
u32 fw_dbglog_mask;
u32 pktlog_filter;
+   u32 fw_cal_period;
 
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 f10721d..d8426fd 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1381,6 +1381,67 @@ static const struct file_operations fops_cal_data = {
.llseek = default_llseek,
 };
 
+static ssize_t ath10k_read_cal_period(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   unsigned int len;
+   char buf[32];
+
+   len = scnprintf(buf, sizeof(buf), "%d\n",
+   ar->debug.fw_cal_period);
+
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_write_cal_period(struct file *file,
+  const char __user *user_buf,
+  size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   unsigned long period;
+   int ret;
+
+   ret = kstrtoul_from_user(user_buf, count, 0, &period);
+   if (ret)
+   return ret;
+   /* period unit in millisecond */
+   if (period < 1 || period > 6)
+   return -EINVAL;
+
+   mutex_lock(&ar->conf_mutex);
+
+   ar->debug.fw_cal_period = period;
+
+   if (ar->state == ATH10K_STATE_ON) {
+   ret = ath10k_wmi_pdev_set_param
+   (ar, ar->wmi.pdev_param->cal_period,
+   ar->debug.fw_cal_period);
+   if (ret) {
+   ath10k_warn
+   (ar, "cal period cfg failed from debugfs: %d\n",
+   ret);
+   goto exit;
+   }
+   }
+
+   ret = count;
+
+exit:
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static const struct file_operations fops_cal_period = {
+   .read = ath10k_read_cal_period,
+   .write = ath10k_write_cal_period,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 int ath10k_debug_start(struct ath10k *ar)
 {
int ret;
@@ -1645,6 +1706,9 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("cal_data", S_IRUSR, ar->debug.debugfs_phy,
ar, &fops_cal_data);
 
+   debugfs_create_file("cal_period", S_IRUSR | S_IWUSR,
+   ar->debug.debugfs_phy, ar, &fops_cal_period);
+
if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED)) {
debugfs_create_file("dfs_simulate_radar", S_IWUSR,
ar->debug.debugfs_phy, ar,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index c300a53..b144b39 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -434,6 +434,7 @@ static struct wmi_pdev_param_map wmi_pdev_param_map = {
.fast_channel_reset = WMI_PDEV_PARAM_UNSUPPORTED,
.burst_dur = WMI_PDEV_PARAM_UNSUPPORTED,
.burst_enable = WMI_PDEV_PARAM_UNSUPPORTED,
+   .cal_period = WMI_PDEV_PARAM_UNSUPPORTED,
 };
 
 static struct wmi_pdev_param_map wmi_10x_pdev_param_map = {
@@ -486,6 +487,7 @@ static struct wmi_pdev_param_map wmi_10x_pdev_param_map = {
.fast_channel_reset = WMI_10X_PDEV_PARAM_FAST_CHANNEL_RESET,
.burst_dur = WMI_10X_PDEV_PARAM_BURST_DUR,
.burst_enable = WMI_10X_PDEV_PARAM_BURST_ENABLE,
+   .cal_period = WMI_10X_PDEV_PARAM_CAL_PERIOD,
 };
 
 /* firmware 10.2 specific mappings */
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 8fa0192..fe35ba9 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/dr

IBSS mode is now supported by CT firmware.

2014-11-25 Thread Ben Greear 
A company that wishes to remain anonymous is sponsoring my
effort to add IBSS (ADHOC) support to my 10.1.467 CT firmware.

The kernel driver must be patched to enable IBSS mode when
CT firmware is detected.

The firmware was improved by copying some of the missing IBSS
code from the 999.x firmware branch.

I still cannot get WPA2 encryption to work, but open authentication
seems to work fine.  I still have a good bit more testing to do.
I cannot get ath9k to do encryption in IBSS mode either, so I
probably am mis-configuring something.

If someone wants to try this out, please download the appropriate
firmware binary from here:

http://www.candelatech.com/downloads/ath10k-fw-beta/

Either hack your own kernel, or grab my latest 3.17 kernel:

git clone git://dmz2.candelatech.com/linux-3.17.dev.y

I'm interested to know results if someone tries it out.

Thanks,
Ben

-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: IBSS mode is now supported by CT firmware.

2014-11-25 Thread Yeoh Chun-Yeow 
On Wed, Nov 26, 2014 at 8:59 AM, Ben Greear  wrote:
> A company that wishes to remain anonymous is sponsoring my
> effort to add IBSS (ADHOC) support to my 10.1.467 CT firmware.
>

Great!

> The kernel driver must be patched to enable IBSS mode when
> CT firmware is detected.
>

Where can I find the patches?

---
ChunYeow

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

Re: IBSS mode is now supported by CT firmware.

2014-11-25 Thread Ben Greear 
On 11/25/2014 05:21 PM, Yeoh Chun-Yeow wrote:
> On Wed, Nov 26, 2014 at 8:59 AM, Ben Greear  wrote:
>> A company that wishes to remain anonymous is sponsoring my
>> effort to add IBSS (ADHOC) support to my 10.1.467 CT firmware.
>>
> 
> Great!
> 
>> The kernel driver must be patched to enable IBSS mode when
>> CT firmware is detected.
>>
> 
> Where can I find the patches?

My 3.17 kernel:

git clone git://dmz2.candelatech.com/linux-3.17.dev.y

or, browse gitweb:

http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.17.dev.y/.git;a=summary


I'll also backport to my 3.14 tree when I get a chance,
but it is not done yet.

Probably not worth trying to post for upstream inclusion
since it needs the CT feature flag...

Thanks,
Ben


-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: IBSS mode is now supported by CT firmware.

2014-11-25 Thread Yeoh Chun-Yeow 
Is this the only patch we need to enable IBSS mode?
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.17.dev.y/.git;a=commit;h=af9dabe5f23e2ad8f8603a5156ebe9227340e9e3

Please advice. Thanks


ChunYeow

On Wed, Nov 26, 2014 at 9:39 AM, Ben Greear  wrote:
> On 11/25/2014 05:21 PM, Yeoh Chun-Yeow wrote:
>> On Wed, Nov 26, 2014 at 8:59 AM, Ben Greear  wrote:
>>> A company that wishes to remain anonymous is sponsoring my
>>> effort to add IBSS (ADHOC) support to my 10.1.467 CT firmware.
>>>
>>
>> Great!
>>
>>> The kernel driver must be patched to enable IBSS mode when
>>> CT firmware is detected.
>>>
>>
>> Where can I find the patches?
>
> My 3.17 kernel:
>
> git clone git://dmz2.candelatech.com/linux-3.17.dev.y
>
> or, browse gitweb:
>
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.17.dev.y/.git;a=summary
>
>
> I'll also backport to my 3.14 tree when I get a chance,
> but it is not done yet.
>
> Probably not worth trying to post for upstream inclusion
> since it needs the CT feature flag...
>
> Thanks,
> Ben
>
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>

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

Re: IBSS mode is now supported by CT firmware.

2014-11-25 Thread Ben Greear 
On 11/25/2014 05:48 PM, Yeoh Chun-Yeow wrote:
> Is this the only patch we need to enable IBSS mode?
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.17.dev.y/.git;a=commit;h=af9dabe5f23e2ad8f8603a5156ebe9227340e9e3
> 
> Please advice. Thanks

Sort of, but that is patching a previous patch of mine that is not upstream.

So, you are going to have to go crawling through the code a bit
to find out how to do a similar action in your code base.

Thanks,
Ben


-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: IBSS mode is now supported by CT firmware.

2014-11-25 Thread Dave Taht 
On Tue, Nov 25, 2014 at 4:59 PM, Ben Greear  wrote:
> A company that wishes to remain anonymous is sponsoring my
> effort to add IBSS (ADHOC) support to my 10.1.467 CT firmware.

Oh, wonderful. I would love to get babeld running on this stuff on
adhoc mode

> The kernel driver must be patched to enable IBSS mode when
> CT firmware is detected.
>
> The firmware was improved by copying some of the missing IBSS
> code from the 999.x firmware branch.
>
> I still cannot get WPA2 encryption to work, but open authentication
> seems to work fine.  I still have a good bit more testing to do.
> I cannot get ath9k to do encryption in IBSS mode either, so I
> probably am mis-configuring something.
>
> If someone wants to try this out, please download the appropriate
> firmware binary from here:
>
> http://www.candelatech.com/downloads/ath10k-fw-beta/
>
> Either hack your own kernel, or grab my latest 3.17 kernel:
>
> git clone git://dmz2.candelatech.com/linux-3.17.dev.y
>
> I'm interested to know results if someone tries it out.
>
> Thanks,
> Ben
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>
>
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

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

Re: IBSS mode is now supported by CT firmware.

2014-11-25 Thread Yeoh Chun-Yeow 
Ok. Thanks. Will take a try on this later.

---
ChunYeow

On Wed, Nov 26, 2014 at 9:50 AM, Ben Greear  wrote:
> On 11/25/2014 05:48 PM, Yeoh Chun-Yeow wrote:
>> Is this the only patch we need to enable IBSS mode?
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.17.dev.y/.git;a=commit;h=af9dabe5f23e2ad8f8603a5156ebe9227340e9e3
>>
>> Please advice. Thanks
>
> Sort of, but that is patching a previous patch of mine that is not upstream.
>
> So, you are going to have to go crawling through the code a bit
> to find out how to do a similar action in your code base.
>
> Thanks,
> Ben
>
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>

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

Re: [PATCH v2 06/10] ath10k: use configured nss instead of max nss.

2014-11-25 Thread Kalle Valo 
gree...@candelatech.com writes:

> From: Ben Greear 
>
> When re-associating a station, the nss was set back to
> maximum value even if user had configured small number
> of tx chains.  So, pay attention to user's config in
> this case as well.
>
> Signed-off-by: Ben Greear 

Thanks, applied.

-- 
Kalle Valo

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

Re: [PATCH v2 05/10] ath10k: apply chainmask settings to vdev on creation.

2014-11-25 Thread Kalle Valo 
gree...@candelatech.com writes:

> From: Ben Greear 
>
> It appears it takes more than just setting the
> hardware's chainmask to make things work well.  Without
> this patch, a vdev would only use 1x1 rates when chainmask
> was set to 0x3.
>
> Setting the 'nss' (number of spatial streams) on the vdev
> helps the firmware's rate-control algorithm work properly.
>
> Tested on CT firmware, but probably this works (and
> is required) on normal firmware.
>
> Signed-off-by: Ben Greear 
> ---
>
> v2:  Add warning if chainmask is set to probably-invalid configuration.
>   Also, from a quick test, it appears you cannot even set the chainmask
>   using 'iw' when vdevs are active.

Thanks, applied.

-- 
Kalle Valo

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

Re: [PATCH] ath10k: remove extra_tx_headroom

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> Comment was out-of-date. The headroom is no longer
> necessary because HTT Tx fragment list is stored
> in dma pool item associated with each sk_buff.
>
> Signed-off-by: Michal Kazior 

Thanks, applied.

-- 
Kalle Valo

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

Re: [PATCH 1/3] ath10k: fix offchan reliability

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> New firmware revisions don't need peer creation
> when doing offchannel tx. Earlier revisions would
> queue and never release frames without a peer.
>
> This prevent new firmware revisions from stopping
> replenishing wmi-htc tx credits and improves
> reliability of offchannel tx which would sometimes
> silently fail.
>
> Signed-off-by: Michal Kazior 

Thanks, all three patches applied.

-- 
Kalle Valo

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

Re: [PATCH] ath10k: don't drop corrupted mgmt frames

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> Some firmware revisions don't seem to deilver
> management frames with FCS error via WMI so narrow
> down the HTT rule to not drop corrupted management
> frames.
>
> This basically increases number of frames ath10k
> reports while sniffing.
>
> Signed-off-by: Michal Kazior 

Thanks, applied.

-- 
Kalle Valo

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

Re: [PATCH] ath10k: don't drop corrupted mgmt frames

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> Some firmware revisions don't seem to deilver
> management frames with FCS error via WMI so narrow
> down the HTT rule to not drop corrupted management
> frames.
>
> This basically increases number of frames ath10k
> reports while sniffing.
>
> Signed-off-by: Michal Kazior 

Thanks, applied.

-- 
Kalle Valo

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

Re: [PATCH v2 1/3] ath10k: Fix shared WEP

2014-11-25 Thread Kalle Valo 
Sujith Manoharan  writes:

> From: Sujith Manoharan 
>
> When static keys are used in shared WEP, when a
> station is associated, message 3 is sent with an
> encrypted payload. But, for subsequent
> authentications that are triggered without a
> deauth, the auth frame is decrypted by the HW.
>
> To handle this, check if the WEP keys have already
> been set for the peer and if so, mark the
> frame as decrypted. This scenario can happen
> when a station changes its default TX key and initiates
> a new authentication sequence.
>
> Signed-off-by: Sujith Manoharan 

Thanks, all three applied.

-- 
Kalle Valo

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

Re: [PATCH v3 0/2] ath10k: firmware memory debugfs interface

2014-11-25 Thread Kalle Valo 
Kalle Valo  writes:

> this is v3 of Yanbo's firmware memory debugfs interface.
>
> Changelog:
>
> v3:
>
> * check ath10k state and return an error if firmware is not running
>
> * switch to use conf_mutex because using ar->state
>
> * fix copy_from_user() error handling
>
> v2:
>
> * split patches into two
>
> * simplify the commit logs
>
> * remove extra #include "hif.h" from debug.c
>
> ---
>
> Yanbo Li (2):
>   ath10k: add register access debugfs interface
>   ath10k: add memory dump debugfs interface

Thanks Yanbo, both patches applied.

-- 
Kalle Valo

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

Re: [PATCH v2 1/3] ath10k: add missing goto

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> This prevents warning spamming if peer creation
> fails during sta_state in some cases.
>
> Signed-off-by: Michal Kazior 

Thanks, all three patches applied.

-- 
Kalle Valo

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

Re: [PATCH 2/2] ath10k: add new wmi interface of NF cal period

2014-11-25 Thread Kalle Valo 
Peter Oh  writes:

> Introduce a new wmi interface controls noise floor (NF) calibration
> period via debugfs as firmware has introduced it on v10.2.
>
> It allows users to modify frequency of NF calibration in millisecond
> and changes RSSI reporting frequency consequently.
> Short calibration period will trigger more frequent NF calibration,
> so that RSSI reported in receive frames is more realistic.
>
> Till now calibration was done at 30 seconds.
>
> Signed-off-by: Peter Oh 

There was a trivial conflict in struct ath10k_debug, please double check
my conflict resolution:

https://github.com/kvalo/ath/commit/1abcc1aa6046231a55a296ea78ab2f374f6f791b

-- 
Kalle Valo

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

Re: [PATCH] ath10k: Do not limit RTS threshold value to 2347

2014-11-25 Thread Kalle Valo 
Ben Greear  writes:

> On 11/24/2014 03:57 AM, Vivek Natarajan wrote:
>> Increase the rts threshold from the legacy value of 2347 to support higher
>> threshold limit.
>
> Does any firmware actually support RTS?  It didn't work last I tested
> it on 10.1.

Vivek?

-- 
Kalle Valo

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

Re: [PATCH 1/3] ath10k: embed supported chip ids in hw_params

2014-11-25 Thread Kalle Valo 
Michal Kazior  writes:

> This will make it easier to extend and maintain
> list of supported hardware.
>
> As a requirement this moves chip_id checking a
> little later because target_version isn't known
> until BMI can be queried.
>
> Signed-off-by: Michal Kazior 

The reason why I originally added the chip_id check was that QCA988X hw
1.0 failed badly (ath10k might have even crashed, don't remember
anymore) and I added this chip_id as an ugly workaround to detect hw1.0
early. Most likely with this patch the problem comes back again.

I don't know what's a good solution, need to think more. Any ideas?

-- 
Kalle Valo

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

RE: [PATCH] ath10k: Do not limit RTS threshold value to 2347

2014-11-25 Thread Natarajan, Vivekanandan 
It works with the 10.2 firmware.

Moreover, the issue reported here was rts_threshold displayed in debugfs was 
different than the one that we had configured to the firmware(2347) .

Thanks

From: Ben Greear 
Sent: Tuesday, November 25, 2014 12:05 AM
To: Natarajan, Vivekanandan
Cc: Valo, Kalle; ath10k@lists.infradead.org
Subject: Re: [PATCH] ath10k: Do not limit RTS threshold value to 2347

On 11/24/2014 03:57 AM, Vivek Natarajan wrote:
> Increase the rts threshold from the legacy value of 2347 to support higher
> threshold limit.

Does any firmware actually support RTS?  It didn't work last I tested
it on 10.1.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: [PATCH 1/3] ath10k: embed supported chip ids in hw_params

2014-11-25 Thread Michal Kazior 
On 26 November 2014 at 08:21, Kalle Valo  wrote:
> Michal Kazior  writes:
>
>> This will make it easier to extend and maintain
>> list of supported hardware.
>>
>> As a requirement this moves chip_id checking a
>> little later because target_version isn't known
>> until BMI can be queried.
>>
>> Signed-off-by: Michal Kazior 
>
> The reason why I originally added the chip_id check was that QCA988X hw
> 1.0 failed badly (ath10k might have even crashed, don't remember
> anymore) and I added this chip_id as an ugly workaround to detect hw1.0
> early. Most likely with this patch the problem comes back again.

Hmm.. good point. I think it mostly failed during firmware transfer to
target but since BMI also needs CE then it might as well fail mid-way.


> I don't know what's a good solution, need to think more. Any ideas?

Hmm.. I have a couple of ideas:

1. Don't use BMI to read target_version. Instead use a register
(assuming there is one). This implies each transport (we have pci only
now) would need to be able to read it somehow unless we support a
fallback to BMI if it wasn't prepped by the transport.

2. Have a dedicatd pci-specific structure:

 struct ath10k_pci_supported_chip {
   u16 dev_id;
   u32 chip_id;
 };

 struct ath10k_pci_supported_chip ath10k_pci_supported_chips[] = {
   { QCA988X_2_0_DEVICE_ID, QCA988X_HW_2_0_CHIP_ID_REV },
   // ...
 };

Probably the simplest and has least impact.

3. Don't use target_version to decide hw_params. Use pci device id
instead. This is a bit of a problem because ath10k_hw_params_list is
in core and is supposed to be transport-agnostic (but should it really
be? I can imagine theoretical usb transport could have devices
reporting identical target_version as a pci one but would need
different firmware files to be used). This probably needs more
thinking through.


Michał

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