Re: [ath5k-devel] ath5k tx completion
On 7 November 2013 06:20, Bob Copeland m...@bobcopeland.com wrote: On Wed, Nov 06, 2013 at 09:17:46AM -0800, Adrian Chadd wrote: The TL;DR version - you need to keep the the final descriptor around for each hardware queue. The legacy madwifi/freebsd way of doing it was to keep the last descriptor that was handled. This wasn't enough. It needs to be per TX queue. You also must never program TxDP after you've programmed it once - you can only program it again after you've completely torn down TX DMA for the particular queue. This is a goldmine -- thank you for taking the time to write it up! I believe we can clean up ath5k's transmit loop a lot now... You're very welcome. I spent quite a lot of time waist deep in this crap. It turns out I had to go to the hardware guys and wade through the verilog to figure out what the hell was actually going on. * read-and-clear bugs * PHY register read problems, and why ANI may occasionally look whacked One thing at a time for me... but do we even want to know? :) If you want to avoid crazy crashes and hangs, yes? :) Also, ask me about key cache corruption too. -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] wcn36xx: Fix logging macro with unnecessary semicolon
On Thu, 2013-11-07 at 07:32 +, Eugene Krasnikov wrote: Hi Joe, Hi Eugene. I personally like the idea of making some kind of framework on top of printing because all ath drivers are using the same printing approach and combining all that code in one place will reduce amount of code in each particular driver. As a true engineer i like when it's less code = less work to do = less bugs:) Suggestion is to send a patch with semicolon fix only It's a one line fix, and pretty trivial to do yourself if you want it. I do think though the slightly odd wcn36xx_level uses of: -#define wcn36xx_err(fmt, arg...) \ - printk(KERN_ERR pr_fmt(ERROR fmt), ##arg); - -#define wcn36xx_warn(fmt, arg...) \ - printk(KERN_WARNING pr_fmt(WARNING fmt), ##arg) - -#define wcn36xx_info(fmt, arg...) \ - printk(KERN_INFO pr_fmt(fmt), ##arg) - [] +#define wcn36xx_err(fmt, ...) \ + pr_err(ERROR fmt, ##__VA_ARGS__) +#define wcn36xx_warn(fmt, ...) \ + pr_warn(WARNING fmt, ##__VA_ARGS__) +#define wcn36xx_info(fmt, ...) \ + pr_info(fmt, ##__VA_ARGS__) should still be converted to more normal pr_level like I did. I don't believe that prefixing of ERROR and WARNING to pr_err and pr_warn actually gain anything as the same level information can be got already with dmesg -r via the 3 and 4 prefixes or dmesg -l3 -l4 have a second round of convincing ath guys to change printing code. How does that sound? Luis? Kalle? Other Qualcomm/Atheros folk? One of the nominal benefits of separating the ath_level macros by subsystem was perf/tracing. I believe some of the ath subsystems have integrated the dmesg and tracing code. I'm not sure how separable those may be here or if it's even desirable to separate them. I'd guess not. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] wcn36xx: Fix logging macro with unnecessary semicolon
Hi Joe, I personally like the idea of making some kind of framework on top of printing because all ath drivers are using the same printing approach and combining all that code in one place will reduce amount of code in each particular driver. As a true engineer i like when it's less code = less work to do = less bugs:) Suggestion is to send a patch with semicolon fix only and have a second round of convincing ath guys to change printing code. How does that sound? On Wed, Nov 6, 2013 at 5:55 PM, Joe Perches j...@perches.com wrote: On Wed, 2013-11-06 at 07:49 +, Eugene Krasnikov wrote: Hm... when it comes to semicolon the patch seems to be good. When it comes to dynamic debugging i think we should have a separate discussion about that. I personally like the whole idea about dynamic debug but if you want to change it i would suggest to have some kind of framework for all ath drivers(or maybe all wireless drivers). Because obviously you can find common code in every driver that defines it's own debug functions/debug levels and so on. Why not to make a framework with standard API/levels? You need to bring that up with the Atheros folk. I've tried. The view seemed to be it was more trouble than it was worth. -- Best regards, Eugene ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Use of atheros devices
I was wondering.. (feel free to skip this without trolling).. What is your use for atheros cards? (Devs also) Small/Big network, station/adhoc/ap/other ? Links, turbo, encryption, embedded devices, routers, x86?.. etc.. I'm sure lot of people following group is curious. Thanks for your time. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
