Re: [ath9k-devel] [PATCH 0/7] ath10k: non-functional cleanups
Michal Kazior michal.kaz...@tieto.com writes: Michal Kazior (7): ath10k: fix code style ath10k: use if() instead of ternary operator ath10k: remove unnecessary void cast ath10k: kill WARN_ONs in htt_rx.c ath10k: use macros instead of if() for value range limiting ath10k: use ath10k_warn() instead of WARN() ath10k: remove old function prototype Thanks, all seven applied. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath10k: add bmi_read32/bmi_write32 function
Michal Kazior michal.kaz...@tieto.com writes:
On 18/04/13 10:08, Janusz Dziedzic wrote:
Add ath10k_bmi_read32/ath10k_bmi_write32 functions
and use them in core layer when read32/write32.
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
drivers/net/wireless/ath/ath10k/bmi.h | 10 ++
drivers/net/wireless/ath/ath10k/core.c | 24
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/bmi.h
b/drivers/net/wireless/ath/ath10k/bmi.h
index e2bd70b..2035d5d 100644
--- a/drivers/net/wireless/ath/ath10k/bmi.h
+++ b/drivers/net/wireless/ath/ath10k/bmi.h
@@ -191,6 +191,16 @@ int ath10k_bmi_read_memory(struct ath10k *ar, u32
address,
void *buffer, u32 length);
int ath10k_bmi_write_memory(struct ath10k *ar, u32 address,
const void *buffer, u32 length);
+static inline int ath10k_bmi_read32(struct ath10k *ar, u32 address,
+void *buffer)
+{
+return ath10k_bmi_read_memory(ar, address, buffer, sizeof(u32));
+}
+static inline int ath10k_bmi_write32(struct ath10k *ar, u32 address,
+ void *buffer)
+{
+return ath10k_bmi_write_memory(ar, address, buffer, sizeof(u32));
+}
I think these functions should do endianess converions so it is not
necessary at call sites anymore.
Also the buffer could be a u32* instead of a void* implicitly stating
what the functions are meant to do.
Yeah, the idea is that the wrappers simplify writing to registers
instead of duplicating the same code in every register access.
I think we can just follow what ath6kl does:
#define ath6kl_bmi_write_hi32(ar, item, val)\
({ \
u32 addr; \
__le32 v; \
\
addr = ath6kl_get_hi_item_addr(ar, HI_ITEM(item)); \
v = cpu_to_le32(val); \
ath6kl_bmi_write(ar, addr, (u8 *) v, sizeof(v)); \
})
#define ath6kl_bmi_read_hi32(ar, item, val) \
({ \
u32 addr, *check_type = val;\
__le32 tmp; \
int ret;\
\
(void) (check_type == val); \
addr = ath6kl_get_hi_item_addr(ar, HI_ITEM(item)); \
ret = ath6kl_bmi_read(ar, addr, (u8 *) tmp, 4);\
*val = le32_to_cpu(tmp);\
ret;\
})
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2 0/5] ath10k: pci memleak fix
Michal Kazior michal.kaz...@tieto.com writes: On 18/04/13 12:29, Kalle Valo wrote: Kalle Valo kv...@qca.qualcomm.com writes: Michal Kazior michal.kaz...@tieto.com writes: The v2 fixes patch 2, and introduces new patches 4 and 5. There were two possible memleaks. Michal Kazior (5): ath10k: drop dead code ath10k: make HTC cancellation a generic thing ath10k: fix HTC tx flushing ath10k: reorder pci shutdown sequences ath10k: fix memory leak during PCI teardown Thanks, all five applied. I'm not sure, but I suspect this set added a new warning: drivers/net/wireless/ath/ath10k/htc.c:341:24: warning: unused variable skb_cb [-Wunused-variable] Yes. My apologies. I must've missed that somehow. It was introduced by patch #2. No worries. Can you send a followup patch to fix that, please? -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 0/3] remaining ath10k_ prefixes for sub-modules
Bartosz Markowski bartosz.markow...@tieto.com writes: After this patch only core, mac and txrx files are not explicitly prefixed. And I think we can leave it like that for now. Bartosz Markowski (3): ath10k: add ath10k_ prefixes into wmi functions ath10k: add ath10k_ prefixes into htt_tx functions ath10k: add ath10k_ prefixes into htt_rx functions Thanks, all applied. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 0/4] small cleanups
Bartosz Markowski bartosz.markow...@tieto.com writes: Bartosz Markowski (4): ath10k: fix indentation ath10k: remove odd 'todo' comment ath10k: remove 'todo' comments ath10k: remove obsolete define Thanks, all four applied. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath10k: split way to long line of code
Bartosz Markowski bartosz.markow...@tieto.com writes: split into functional blocks, to reduce almost 200 char line. Now it's easier to read both, the code and the logs produced. Signed-off-by: Bartosz Markowski bartosz.markow...@tieto.com Now the debug log output is four lines, I don't think that's any better either. I'll split the output into two lines. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath10k: wmi_mgmt_rx setup band
Janusz Dziedzic janusz.dzied...@tieto.com writes: Setup band using wmi_event and phy_mode reported by FW/HW. Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com Both applied, thanks. But the commit logs don't still answer the question why?. Especially the change from user space point of view is important (if there are any). --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -240,6 +240,35 @@ static int wmi_event_scan(struct ath10k *ar, struct sk_buff *skb) return 0; } + +static inline enum ieee80211_band phy_mode_to_band(u32 phy_mode) I also removed the extra new line. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath10k: wmi_mgmt_rx setup band
Kalle Valo kv...@qca.qualcomm.com writes: Janusz Dziedzic janusz.dzied...@tieto.com writes: Setup band using wmi_event and phy_mode reported by FW/HW. Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com Both applied, thanks. Forgot to mention that there were conflicts with both patches. Please check that I didn't do anything stupid when fixing the conflicts. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] mac80211: regression: fd0f979 no long authenticates w/ath9k_htc
Corey Richardson co...@octayn.net writes: On Wed, Mar 6, 2013 at 7:02 AM, Johannes Berg johan...@sipsolutions.net wrote: Do you think you could run trace-cmd to capture what's going on before and after? What should I be recording? The NetworkManager process? I'm unfamiliar with ftrace. You should use trace-cmd. Something like this: trace-cmd record -e mac80211 -e cfg80211 And then send compressed trace.dat to Johannes. More info: http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 4/6] ath9k: Only spectral scan relay file when it was created
Sven Eckelmann s...@narfation.org writes:
The relay file depends on relayfs. Trying to close this file without having
ATH9K_DEBUGFS (and therefore RELAY) activated causes build failures.
Signed-off-by: Sven Eckelmann s...@narfation.org
[...]
+#ifdef CONFIG_ATH9K_DEBUGFS
if (sc-rfs_chan_spec_scan) {
relay_close(sc-rfs_chan_spec_scan);
sc-rfs_chan_spec_scan = NULL;
}
+#endif
Instead of ugly #ifdef you could do something like this:
if (config_enabled(CONFIG_ATH6KL_REGDOMAIN)
I think you could use that elsehwere in your patchset as well, but I
didn't check that carefully.
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Support ethtool getstats api.
Ben Greear gree...@candelatech.com writes: No, there is a check later that does a BUG_ON if our we have screwed up the indexing of the stats. Please, no BUG_ON() calls in wifi drivers. They just make users life miserable. WARN_ON() with a safe bailout is enough. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: validate for non-zero BSSID
Mohammed Shafi Shajakhan moham...@qca.qualcomm.com writes: unassociated state for station. but I observed this when i tested ad-hoc mode. I just started an ad-hoc mode creator and left it for some time with no one joining. i observed there are few frames in rx_tasklet of ath9k driver which seem to be beacons and their BSSID is '0', as our curbssid is also '0' they seem to be wrongly identified as 'my_beacons'. This is a perfect addition to the commit log. Remember that the commit log should especially answer the question why?. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Improve ath_tx_aggr_stop to avoid TID stuck in cleanup state.
Nikolay Martynov mar.ko...@gmail.com writes: From: kolya mar.ko...@gmail.com Please use your full name here. When tx agg is being stopped TID is flushed using ath_tx_flush_tid. It is possible that ath_tx_flush_tid completelly flushes TID (if all packets in this TID have already been retried). If this happened ath_tx_aggr_stop would leave TID in cleanup state permanently. Fix this by making ath_tx_flush_tid remove AGGR_ADDBA_COMPLETE and AGGR_CLEANUP flags from TID status if TID is empty. And word wrap your commits to 72 chars or so. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: rename ath9k_platform.h to ath_platform.h
Hi Sangwook, On 11/16/2011 01:34 PM, Sangwook Lee wrote: On 15 November 2011 16:37, Kalle Valo kv...@adurom.com mailto:kv...@adurom.com wrote: Hi Sangwook, On 11/15/2011 01:23 PM, Sangwook Lee wrote: The patch series proposes to rename ath9k_platform.h to ath_platform.h This header file handles platform data used only for ath9k, but it can used by ath6k as well. We can take wl12xx.h as as a example. Please let us change this file name so that other Atheors WLANs use this file for their own platform data ath9k and ath6kl are very different devices, I'm not sure if sharing a platfrom struct between the two is really a good idea. Most likely there is very little the two drivers can share. What are your plans here? As you know, if ath6kl is not SDIO powered (in most of cases, including mine) we need to use platform struct in order to control reset/power line, because ath6k is designed for mobile and embedded devices. We have been actually planning to do the same, but it's still on our todo list. If you can do this it would be awesome. Also we need to provide some clock configuration from the board file and I'm sure there will be more in the future. But let's start with the power control. so I found out that there is already header file for ath9k's platform struct. How about using the one header file instead of include/linux/ath9k_platform.h , and include/linux/ath6k_platform.h ? I myself was thinking that we would have include/linux/ath6kl.h dedicated just for ath6kl. That would makes things simpler. But since I don't know much about ath9k, if you want to make the separate header file for ath6kl's own struct, It would be fine as well. Yeah, I really would like to use separate file for ath6kl. Kalle ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: rename ath9k_platform.h to ath_platform.h
Hi Sangwook, On 11/15/2011 01:23 PM, Sangwook Lee wrote: The patch series proposes to rename ath9k_platform.h to ath_platform.h This header file handles platform data used only for ath9k, but it can used by ath6k as well. We can take wl12xx.h as as a example. Please let us change this file name so that other Atheors WLANs use this file for their own platform data ath9k and ath6kl are very different devices, I'm not sure if sharing a platfrom struct between the two is really a good idea. Most likely there is very little the two drivers can share. What are your plans here? I myself was thinking that we would have include/linux/ath6kl.h dedicated just for ath6kl. That would makes things simpler. Kalle ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: fix MGMT packets when using TKIP
Bill Jordan bjor...@rajant.com writes: Prevent 8 bytes from being truncated from MGMT packets when using TKIP. A bit more information in the commit log would be nice. Is this is a regression or an old bug? Maybe a stable candidate? -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k ps poll performance
Satanand Burla satanand_bu...@phoenix.com writes: for example with the same wep AP, I get around 150 to 200 Kbps without enabling ps poll. That's very low. What kind of test are you using here? but if I enable ps poll with the above settings, I get only around 20 Kbps and the packet loss is around 20 to 30%. My question is, is this the expected speed drop when turning on ps poll ? Or is this a problem with the driver that still needs to be addressed ? With PS-Poll (ie. timeout is zero) you should still get in range of megabits per second and no packet loss. So something is wrong. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
Luis R. Rodriguez lrodrig...@atheros.com writes:
Devices with external radios have revisions which we can count on.
On single chip solutions these EEPROM values for these radio revision
also exist but are not meaningful as the radios are embedded onto the
same chip. Each single-chip device evolves together as one device.
Signed-off-by: Luis R. Rodriguez lrodrig...@atheros.com
---
Changes hw_name to 60 bytes.
Thanks, much better now.
Another minor comment, sorry that I didn't notice it earlier:
+void ath9k_hw_name(struct ath_hw *ah, char *hw_name)
+{
+ /* chipsets = AR9280 are single-chip */
+ if (AR_SREV_9280_10_OR_LATER(ah)) {
+ sprintf(hw_name,
+ Atheros single-chip AR%s Rev:%x,
+ ath9k_hw_mac_bb_name(ah-hw_version.macVersion),
+ ah-hw_version.macRev);
+ }
+ else {
+ sprintf(hw_name,
+ Atheros AR%s MAC/BB Rev:%x AR%s RF Rev:%x: ,
+ ath9k_hw_mac_bb_name(ah-hw_version.macVersion),
+ ah-hw_version.macRev,
+ ath9k_hw_rf_name((ah-hw_version.analog5GhzRev
+ AR_RADIO_SREV_MAJOR)),
+ ah-hw_version.phyRev);
+ }
+}
I think you should provide the size of hw_name to this function and
use snprintf() to avoid writing out of bounds.
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
Luis R. Rodriguez lrodrig...@atheros.com writes: I think you should provide the size of hw_name to this function and use snprintf() to avoid writing out of bounds. I was going to do this but since I know the users of it and control it seemed to not matter. I'll respin with this added, better to be careful. Yeah, you never know if someone (for example a crazy Finn just after a refreshing sauna) comes along, changes the function a bit to clean it up and creates a subtle bug ;) -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k module-Unable to set channel-since ath comes
Jouni Malinen jouni.mali...@atheros.com writes: On Tue, 2009-05-12 at 01:35 -0700, Davide Pesavento wrote: I've already reported ath9k's issues with PS multiple times [1] [2] [3], but the driver hasn't been fixed yet. You can find a verbose debugging output at [4], I hope that helps in fixing the problem (I can provide even more info if needed and I'm willing to test patches). I submitted a set of patches to resolve some of the PS issues in ath9k. I would expect these to hit wireless-testing.git eventually, but if you are willing to test the changes before that, you can find the patches from http://w1.fi/p/ps/ One thing to note here is that there are still some issues with the timeout=0 case (use of PS-Poll to fetch buffered frames) which is enabled with iwconfig wlan0 power on, so at this point, I would recommend running the test either with the default wireless-testing.git PS mode setting or by enabling power saving with iwconfig wlan0 power timeout 500ms which should result in the same configuration. Most probably that's because mac80211 does not disable power save mode when sending PS-Poll frames. So stlc45xx does not require disable of PSM but then again ath9k requires it, we need to solve this somehow. I have been thinking about separating power save mode and firmware wakeup/sleep modes from each other in mac80211 API. To me it looks like ath9k does more like firmware wakeup/sleep when power save mode is changing. But this is just a wild idea, I have no idea if it's practical or not. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Fix basic connectivity issue
Vasanthakumar Thiagarajan vasa...@atheros.com writes: This patch temporarily fixes a regression introduced by BT coexistence support. There is an instability in connection when BT coexistence is enabled on some h/w. This interim fix introduces a module parameter for BT coexistence configuration. [...] +static int btcoex_enable; +module_param(btcoex_enable, bool, 0); +MODULE_PARM_DESC(btcoex_enable, Enable Bluetooth coexistence support); Somehow I guessed that this was coming :) I still think that a proper nl80211 interface for this is in order. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
