On 2010-01-22 11:23 PM, Luis R. Rodriguez wrote:
> Adding Ben and Cliff just to keep them in the loop.
>
> Note: this e-mail is on a public mailing list.
>
> On Fri, Jan 22, 2010 at 02:17:43PM -0800, Pavel Roskin wrote:
>> On Fri, 2010-01-22 at 19:26 +0100, Jorge Boncompte [DTI2] wrote:
>>
>> > Hi Pavel, i had done some tests and did found that my SR71-12 does
>> > works if I
>> > change in hw.c::ath9k_hw_init_11a_eeprom_fix()...
>> >
>> > if ((ah->hw_version.devid == AR9280_DEVID_PCI) &&
>> > test_bit(ATH9K_MODE_11A, ah->caps.wireless_modes)) {
>> >
>> > to...
>> >
>> > if (ah->hw_version.devid == AR9280_DEVID_PCI) {
>> >
>> > Unfortunately, I don't know what that 'fix' fixes :-)
>>
>> You patch fixes Ubiquiti SR71-12 for me! And it looks quite reasonable.
>> I'm only getting "deadbeef" from AR_IMR_S2 now, which is exactly what
>> I'm getting with SR71-15.
>>
>> The right fix would be probably to find out when the "fixup" is actually
>> needed.
>>
>> By the way, I'm not very fond of checking PCI ID in the driver when
>> there are other ways to check for the chip revision and capabilities.
>
> I'm baffled, why would initializing some 5 Ghz stuff be required for
> a 2ghz only card. Unless hardware requires this.. we're still looking
> into this.
Looking at the fixups more closely, I'd say that this is not actually 5
GHz specific stuff, but rather a bogus check that was added over time.
When looking back at a much, much older version of ath9k (before it was
merged to the wireless tree), it didn't have any 11a mode capability
check before running the INI fixups.
I think dropping the 11a capability check is the right fix in this case,
as the code that gets called then fixes up a static preinitialized value
from the initval with a value from the eeprom,
and nothing in the fixup code indicates that it's supposed to be 11a
specific.
- Felix
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
