Adrian Chadd 6f5fe81e02 Fix a corner-case of interrupt handling which resulted in potentially
spurious (and fatal) interrupt errors.

One user reported seeing this:

Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error,
  ISR_RAC 0x0 SYNC_CAUSE 0x2000

SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout;
this shouldn't cause HAL_INT_FATAL to be set.

After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked)
before continuing, regardless of whether any bits in the ISR registers
are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't
treated as fatal, and AR_ISR isn't read or is read and is 0, then
(*masked) wouldn't be cleared. Thus any of the existing bits set
that were passed in would be preserved in the output.

The caller in if_ath - ath_intr() - wasn't setting the masked value
to 0 before calling ath_hal_getisr(), so anything that was present
in that uninitialised variable would be preserved in the case above
of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit
was set, a fatal condition would be interpreted and the chip was
reset.

This patch does the following:

* ath_intr() - set masked to 0 before calling ath_hal_getisr();
* ar5416GetPendingInterrupts() - clear (*masked) before processing
  continues; so if the interrupt source is AR_INTR_SYNC_CAUSE
  and it isn't fatal, the hardware isn't reset via returning
  HAL_INT_FATAL.

This doesn't fix any underlying errors which trigger
AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some
sort - so that likely should be further investigated.
2011-04-23 06:37:09 +00:00
..
2011-04-19 10:57:40 +00:00
2010-07-28 16:24:11 +00:00
2011-02-21 09:01:34 +00:00
2011-02-21 09:01:34 +00:00
2011-04-22 09:44:01 +00:00
2010-10-13 17:38:23 +00:00
2010-10-13 17:38:23 +00:00
2011-02-21 09:01:34 +00:00
2011-03-25 20:53:02 +00:00
2011-02-21 09:01:34 +00:00
2011-04-22 13:56:21 +00:00
2010-01-03 23:26:29 +00:00
2011-02-21 09:01:34 +00:00
2011-04-22 09:41:51 +00:00
2011-04-22 09:39:05 +00:00
2010-10-13 14:41:52 +00:00
2011-04-21 14:39:33 +00:00
2010-01-08 20:40:28 +00:00
2011-04-14 07:14:22 +00:00
2010-05-11 17:14:17 +00:00
2011-02-21 09:01:34 +00:00
2011-03-24 08:56:12 +00:00
2011-04-22 09:22:27 +00:00
2010-01-01 22:47:53 +00:00
2010-01-28 08:41:30 +00:00
2011-04-22 09:59:16 +00:00
2011-04-19 10:57:40 +00:00
2011-04-22 00:44:27 +00:00
2011-02-21 09:01:34 +00:00
2010-11-09 10:59:09 +00:00
2010-12-18 02:54:51 +00:00
2011-04-19 10:57:40 +00:00
2011-04-22 12:46:39 +00:00
2010-11-15 05:25:51 +00:00
2010-01-28 08:41:30 +00:00
2011-02-21 09:01:34 +00:00
2011-03-23 22:06:09 +00:00
2011-02-21 09:01:34 +00:00
2010-11-07 12:29:26 +00:00
2011-02-21 09:01:34 +00:00