[ath9k-devel] [RFC 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang

[Valo, Kalle]

QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a state in
which a read of AR_CFG always returns 0xdeadbeef. This should not happen
when when the power_mode of the device is ATH9K_PM_AWAKE.
This problem is not yet detected by any other workaround in ath9k. No way
is known to reproduce the problem easily.

[...]

+void ath_hw_hang_work(struct work_struct *work)
+{
+ struct ath_softc *sc = container_of(work, struct ath_softc,
+ hw_hang_work.work);
+
+ if (ath_hw_hang_deadbeef(sc))
+ goto requeue_worker;
+
+ ieee80211_queue_delayed_work(sc->hw, &sc->hw_hang_work,
+ msecs_to_jiffies(ATH_HANG_WORK_INTERVAL));
+}

The goto doesn't make any sense, either me or the function is missing
something :)

[Sven Eckelmann]

Post by Valo, Kalle

QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a state in
which a read of AR_CFG always returns 0xdeadbeef. This should not happen
when when the power_mode of the device is ATH9K_PM_AWAKE.
This problem is not yet detected by any other workaround in ath9k. No way
is known to reproduce the problem easily.

[...]

+void ath_hw_hang_work(struct work_struct *work)
+{
+ struct ath_softc *sc = container_of(work, struct ath_softc,
+ hw_hang_work.work);
+
+ if (ath_hw_hang_deadbeef(sc))
+ goto requeue_worker;
+
+ ieee80211_queue_delayed_work(sc->hw, &sc->hw_hang_work,
+ msecs_to_jiffies(ATH_HANG_WORK_INTERVAL));
+}

The goto doesn't make any sense, either me or the function is missing
something :)

It is just for the next patch. And yes, could be done differently.

Kind regards,
Sven