On Wed, Aug 12, 2009 at 7:13 PM, Nick Kossifidis<mickfl...@gmail.com> wrote: > 2009/8/12 Luis R. Rodriguez <lrodrig...@atheros.com>: >> On Wed, Aug 12, 2009 at 10:21 AM, Bob Copeland<m...@bobcopeland.com> wrote: >>> On Wed, Aug 12, 2009 at 12:56 PM, Luis R. >>> Rodriguez<lrodrig...@atheros.com> wrote: >>>> This adds a common structure where we can start stuffing shared items >>>> and introduces a helper for both ath5k and ath9k's use. >>>> >>>> Luis R. Rodriguez (3): >>>> ath: add common ath_rxbuf_alloc() and make ath9k use it >>>> ath5k: use common ath.ko ath_rxbuf_alloc() >>>> ath5k: use bit shift operators for cache line size >>> >>> Series looks OK to me but I think we can add a 4/4 that would: >>> >>> - include ath/reg.h [don't remember if that's the name right now] >>> in ath.h >>> - move reg structs into ath_common (although, this could be a >>> bad call for ar9170, haven't really checked). >>> >>> Then we only have to deal with one header and one composite struct >>> (for now) as the interface between the modules. >> >> Sure, I was thinking of doing this after this. Is that acceptable? >> >> Luis > > You mean have a common reg.h for both ath5k and ath9k ? Works for me > but we have to deal with some new register ranges and some registers > have moved on ath9k + reg.h on ath9k has no descriptions, comments, it doesn't > include macros for accessing queue registers or tables, mixes eeprom offsets > with register addresses and other macros.
Sorry no I meant ath/reg.h as in regulatory, as that is already party of ath.ko. > My plan was to start merging ath9k hw code on ath5k (not the driver part, > pcu.c, qcu.c, phy.c, eeprom.c etc + registers/eeprom offsets/descriptor > formats) > and then move all that on ath and have both ath5k/ath9k use it. I > believe ath5k hw > code is much cleaner than ath9k and it's a better place to start, i've > seen most hw > code on ath9k and i'm ready to move on if it's O.K. with you. When we update ath9k for new hw support it is easiest if that code matches what we have internally at Atheros. Granted we diverge from that every now and then but I believe those changes can be brought back in that we do and yet keep the internal code working. I believe the changes so far bring clarity and readability. Unfortunately we haven't yet gotten any the changes we've made on ath9k hw access stuff or regulatory merged back in so we keep diverging more and more from our internal codebase. Because of this for now I would not welcome bringing ath9k code to ath5k in any way whatsoever. What I think is reasonable though is to start merging into ath.ko common code which doesn't change much or would mean diverging a lot from ath9k's current style for the hw related stuff. Don't get me wrong, changes are welcomed but the less intrusive the better. "start merging ath9k hw code on ath5k" sounds very intrusive by all means. Lets do this slowly and take it on, on a patch by patch basis. Luis _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
