From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Date: Fri, 22 Jan 2010 23:42:23 +0100 Subject: [ath9k-devel] D-Link DWA-547 completely freezes system In-Reply-To: <20100122222304.GL2283@tux> References: <1264111259.10053.6.camel@mj> <43e72e891001211426p603c7108y513787a61a88da4c@mail.gmail.com> <1264128820.3766.8.camel@ct> <1264182734.12386.12.camel@mj> <4B59EDEA.3090001@dti2.net> <1264198663.9056.11.camel@mj> <20100122222304.GL2283@tux> Message-ID: <4B5A29CF.8000402@openwrt.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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