2009/8/12 Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx>: > On Wed, Aug 12, 2009 at 10:21 AM, Bob Copeland<me@xxxxxxxxxxxxxxx> wrote: >> On Wed, Aug 12, 2009 at 12:56 PM, Luis R. >> Rodriguez<lrodriguez@xxxxxxxxxxx> 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. 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. -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
