ath9k-devel.lists.ath9k.org archive mirror
 help / color / mirror / Atom feed
* [ath9k-devel] [RFC 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang
       [not found] <20161114144226.15748-1-sven.eckelmann@open-mesh.com>
@ 2016-11-16 16:16 ` Valo, Kalle
  2016-11-17  7:23   ` Sven Eckelmann
  0 siblings, 1 reply; 2+ messages in thread
From: Valo, Kalle @ 2016-11-16 16:16 UTC (permalink / raw)
  To: ath9k-devel

Sven Eckelmann <sven.eckelmann@open-mesh.com> writes:

> From: Simon Wunderlich <simon.wunderlich@open-mesh.com>
>
> 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.
>
> Signed-off-by: Simon Wunderlich <simon.wunderlich@open-mesh.com>
> [sven.eckelmann at open-mesh.com: port to recent ath9k, add commit message]
> Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>

[...]

> +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;
> +
> +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 :)

-- 
Kalle Valo

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [ath9k-devel] [RFC 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang
  2016-11-16 16:16 ` [ath9k-devel] [RFC 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang Valo, Kalle
@ 2016-11-17  7:23   ` Sven Eckelmann
  0 siblings, 0 replies; 2+ messages in thread
From: Sven Eckelmann @ 2016-11-17  7:23 UTC (permalink / raw)
  To: ath9k-devel

On Mittwoch, 16. November 2016 16:16:42 CET Valo, Kalle wrote:
> Sven Eckelmann <sven.eckelmann@open-mesh.com> writes:
> 
> > From: Simon Wunderlich <simon.wunderlich@open-mesh.com>
> >
> > 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.
> >
> > Signed-off-by: Simon Wunderlich <simon.wunderlich@open-mesh.com>
> > [sven.eckelmann at open-mesh.com: port to recent ath9k, add commit message]
> > Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
> 
> [...]
> 
> > +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;
> > +
> > +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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20161117/acc1b70e/attachment.pgp 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-11-17  7:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20161114144226.15748-1-sven.eckelmann@open-mesh.com>
2016-11-16 16:16 ` [ath9k-devel] [RFC 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang Valo, Kalle
2016-11-17  7:23   ` Sven Eckelmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).