@@ -476,7 +476,7 @@ static void ath5k_hw_set_sleep_clock(struct ath5k_hw *ah, bool enable)
(ah->ah_mac_version == (AR5K_SREV_AR2417 >> 4))) {
ath5k_hw_reg_write(ah, 0x26, AR5K_PHY_SLMT);
ath5k_hw_reg_write(ah, 0x0d, AR5K_PHY_SCAL);
- ath5k_hw_reg_write(ah, 0x07, AR5K_PHY_SCLOCK);
+ ath5k_hw_reg_write(ah, 0x0C, AR5K_PHY_SCLOCK);
ath5k_hw_reg_write(ah, 0x3f, AR5K_PHY_SDELAY);
AR5K_REG_WRITE_BITS(ah, AR5K_PCICFG,
AR5K_PCICFG_SLEEP_CLOCK_RATE, 0x02);
@@ -490,8 +490,10 @@ static void ath5k_hw_set_sleep_clock(struct ath5k_hw *ah, bool enable)
}
/* Enable sleep clock operation */
+#if 0
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG,
AR5K_PCICFG_SLEEP_CLOCK_EN);
+#endif
} else {
The AR5K_PHY_SCLOCK brings the old value (before the commit in question)
back, I have no idea what is it. Leaving the new value causes the second
run of hostapd to make the driver fail, the chip seems to not respond.
It seems the value itself may be correct (as it works with 2.6.31+) but
there is some additional bug fixed after 2.6.30, gitk show several
candidate patches for this.
Only disabling AR5K_PCICFG write makes the data abort go away.
----------------------------------------------
2.6.31 and Linus-current only need the AR5K_PCICFG change:
@@ -489,9 +489,10 @@ static void ath5k_hw_set_sleep_clock(struct ath5k_hw *ah, bool enable)
}
/* Enable sleep clock operation */
+#if 0
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG,
AR5K_PCICFG_SLEEP_CLOCK_EN);
-
+#endif
} else {
/* Disable sleep clock operation and