On 2011-11-23 10:18 PM, Mohammed Shafi Shajakhan wrote: > Hi Felix, > > thanks for your review. > On Wednesday 23 November 2011 07:59 PM, Felix Fietkau wrote: >> On 2011-11-22 11:22 PM, Mohammed Shafi Shajakhan wrote: >>> From: Mohammed Shafi Shajakhan<moham...@qca.qualcomm.com> >>> >>> to be used by MCI specific changes >>> >>> Cc: Wilson Tsao<wt...@qca.qualcomm.com> >>> Cc: Senthil Balasubramanian<senth...@qca.qualcomm.com> >>> Signed-off-by: Rajkumar Manoharan<rmano...@qca.qualcomm.com> >>> Signed-off-by: Mohammed Shafi Shajakhan<moham...@qca.qualcomm.com> >> NACK. ath_reset can no longer be called in tasklet context (which you >> seem to be doing in the next patch). >> Replace your ath_reset() call with: >> ieee80211_queue_work(sc->hw,&sc->hw_reset_work); >> >> - Felix > > just like in ath9k_flush, i like to have the chip reset immediately > rather than queuing at as a work. > in chip reset we have: > *we have BT calibration > *sync up with BT state > *2g_5g change > *LNA transfer > and few other things > > when BT asks for calibration i understand we have to immediately give > preference to it. > please let me know if i had missed something and also if queuing > ath_reset actually helps us in some way. > i will revert this back once i test queue_work does no harm. Doing reset from tasklet context created several nasty stability issues that were hard to track down, and the potential gain from doing reset 'immediately' that way is purely theoretical. Resets should be rare in normal operation, as they're also expensive. The main problem when running reset from a tasklet is that there is no way of gracefully shutting down ongoing workqueue activity, so the result of the reset could be that the work items mess up the state right after the reset is done.
- Felix _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
