2009/8/13 Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx>: > On Wed, Aug 12, 2009 at 7:13 PM, Nick Kossifidis<mickflemm@xxxxxxxxx> wrote: >> 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. > > 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 > ACK ;-) -- 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
