Re: [PATCH 3/3] ath10k: fix station count enforcement
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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