Re: [Regression, 3.2-rc1] ath9k broken on AR928X

[Felix Fietkau <nbd@openwrt.org>]

On 2011-11-27 4:32 AM, Rafael J. Wysocki wrote:
> On Friday, November 25, 2011, Rafael J. Wysocki wrote:
>> On Thursday, November 24, 2011, Linus Torvalds wrote:
>> > Hey, since most of the US will be in a food-induced coma tomorrow, I
>> > just *know* that doing a new release candidate is a good idea.
>> > 
>> > One quarter arch updates, two quarters drivers, and one quarter random
>> > changes. Shake vigorously and serve cold..
>> > 
>> > And maybe the rest of the world can try to make up for the lack of any
>> > expected US participation? Hmm?
>> 
>> Well, unfortunately, this kernel is unusable on my Acer Ferrari One.
>> 
>> First off, it hangs solid every time several seconds or at last a few
>> minutes after boot.  I haven't been able to collect any debug data from
>> it yet, but one of the symptoms is black screen with (unmovable) mouse
>> cursor (this only happens when X has been started, but the box hangs without
>> X too).
>> 
>> Second, the wireless is apparently unable to associate with the AP
>> (that 3.1-rc10 works with correctly on the same box).
>> 
>> Tomorrow I'll try to identify the offending commits.
> 
> Well, it took more time than I had hoped. :-(
> 
> Bisection turns up:
> 
> commit 2577c6e8f2320f1d2f09be122efef5b9118efee4
> Author: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
> Date:   Tue Sep 13 22:38:18 2011 +0530
> 
>     ath9k_hw: Add support for AR946/8x chipsets.
>     
>     This patch adds support for AR946/8x chipets.
>     
>     Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> which I think is wrong for at lest two reasons.  Not that I understand
> what it actually does to the driver, but first, it does much more than the
> changelog says and, second, it is practically impossible to revert
> because of the number of commits on top depending on it.  Quite frankly,
> it is about to make it to my list of examples of how things should _not_ be
> done in the kernel.
> 
> The commit immediately preceding it doesn't show any symptoms of failure, so
> I'm quite convinced this one really introduced the problem for me.
> 
> The chip in the affected box is (according to "lspci -v"):
> 
> 09:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
>         Subsystem: Foxconn International, Inc. Device e01f
>         Flags: bus master, fast devsel, latency 0, IRQ 19
>         Memory at f0000000 (64-bit, non-prefetchable) [size=64K]
>         Capabilities: [40] Power Management version 2
>         Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
>         Capabilities: [60] Express Legacy Endpoint, MSI 00
>         Capabilities: [90] MSI-X: Enable- Count=1 Masked-
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [140] Virtual Channel
>         Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
>         Kernel driver in use: ath9k
> 
> Thanks,
> Rafael

Looking at the diff, the only thing I can find that would break AR928x
is this (in the function ath9k_set_power_sleep in hw.c):

        /* Clear Bit 14 of AR_WA after putting chip into Full Sleep mode. */
-       if (AR_SREV_9300_20_OR_LATER(ah))
-               REG_WRITE(ah, AR_WA,
-                         ah->WARegVal & ~AR_WA_D3_L1_DISABLE);
+       if (!AR_SREV_9480(ah))
+               REG_WRITE(ah, AR_WA, ah->WARegVal & ~AR_WA_D3_L1_DISABLE);
 }


Please try changing the if line to:
if (AR_SREV_9300_20_OR_LATER(ah) && !AR_SREV_9480(ah))

Apparently later changes even removed this check. I'll take a look at the
history to figure out what's going on, this could probably explain other
regressions on pre-AR9380 chips as well.

- Felix