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.
Luis
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
