On Thu, Aug 27, 2009 at 4:14 PM, Luis R. Rodriguez<mcg...@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 2:39 PM, Bob Copeland<m...@bobcopeland.com> wrote:
>> On Thu, Aug 27, 2009 at 11:25:03AM -0700, Luis R. Rodriguez wrote:
>>> > Well, we also don't use the turbo modes at all and that's where the
>>> > error is (IIRC) so it shouldn't have any impact. :)
>>>
>>> Again, why don't we just remove all that fucking turbo cruft?
>>
>> OK with me since no one seems to care enough to implement mac80211
>> support.  I left some of the #defines in place as they are useful
>> documentation.  Approx. 80 of the lines removed are comments.
>>
>>   text    data     bss     dec     hex filename
>>  136746     480      56  137282   21842 ath5k_old.ko
>>  134913     480      56  135449   21119 ath5k_new.ko
>>
>> Disclaimer: only barely tested.
>
> Sexy, thanks!
>
> Acked-by: Luis R. Rodriguez <lrodrig...@atheros.com>
>
>>        { AR5K_PHY(14),
>> -          { 0x00000007, 0x00000007, 0x0000000b, 0x0000000b } },
>> +          { 0x00000007, 0x0000000b, 0x0000000b } },
>
> Apart from this one initval all other ar5211_ini_mode[] values between
> 802.11a and 802.11g are the same! Which means we could potentially
> save (35 lines here * 4 bytes) + (3 entries for AR5K_PHY(14) * 4) =
> 152 bytes here if we just converge 11a and 11g as just OFDM data for
> this ini array and remove AR5K_PHY(14) entry and deal with it as a
> final write. I wonder if AR5K_PHY(14) (0x9838) was a typo for 11a or
> 11g. I'll try to dig to see what this is, perhaps its not a good idea
> to move this out and set this later, not sure if this is inline for
> the rf buffer trigger stuff, I'll poke.
>
> All other ini arrays differ in more than 1 line so probably not worth mucking.

OK so upon review here is what I can determine from the above:

AR5211 supports 802.11a and 802.11b, so I suspect the 11g stuff was
kept there for testing purposes, all of that is actually unused. I say
we remove 11g stuff for AR5211 as well and save ourselves those bytes.

And for the record -- reordering the mode stuff seems fine except care
must be taken to ensure all those writes are done prior to
AR5K_PHY_ACT aka 0x981c aka AR5K_PHY(7).

The rf buffer stuff I mentioned earlier would not apply here as that
is related to other stuff.

  Luis
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Reply via email to