Re: [ath5k-devel] [PATCH 0/3] ath: advance ath.ko with one more helper

[Nick Kossifidis <mickflemm@gmail.com>]

2009/8/13 Luis R. Rodriguez <lrodriguez@atheros.com>:
> On Wed, Aug 12, 2009 at 7:13 PM, Nick Kossifidis<mickflemm@gmail.com> wrote:
>> 2009/8/12 Luis R. Rodriguez <lrodriguez@atheros.com>:
>>> On Wed, Aug 12, 2009 at 10:21 AM, Bob Copeland<me@bobcopeland.com> wrote:
>>>> On Wed, Aug 12, 2009 at 12:56 PM, Luis R.
>>>> Rodriguez<lrodriguez@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
>

ACK ;-)


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick