Re: [PATCH 3/5] ath9k_htc: Handle FATAL events

[Sujith <m.sujith@gmail.com>]

Vasanthakumar Thiagarajan wrote:
> On Tue, Dec 28, 2010 at 01:42:03PM +0530, Sujith wrote:
> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> > 
> > The device has to be reset when a FATAL event is received.
> > Not doing so would leave the card in a non-working state.
> > 
> > Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> > ---
> >  drivers/net/wireless/ath/ath9k/htc.h          |    6 ++-
> >  drivers/net/wireless/ath/ath9k/htc_drv_init.c |    8 ++-
> >  drivers/net/wireless/ath/ath9k/htc_drv_main.c |   57 ++++++++++++++++++++++++-
> >  drivers/net/wireless/ath/ath9k/wmi.c          |   18 +++++++-
> >  drivers/net/wireless/ath/ath9k/wmi.h          |    3 +-
> >  5 files changed, 84 insertions(+), 8 deletions(-)
> > 
> > +void ath9k_htc_reset(struct ath9k_htc_priv *priv)
> > +{
> > +	struct ath_hw *ah = priv->ah;
> > +	struct ath_common *common = ath9k_hw_common(ah);
> > +	struct ieee80211_channel *channel = priv->hw->conf.channel;
> > +	struct ath9k_hw_cal_data *caldata;
> > +	enum htc_phymode mode;
> > +	__be16 htc_mode;
> > +	u8 cmd_rsp;
> > +	int ret;
> > +
> > +	mutex_lock(&priv->mutex);
> 
> This will result in a deadlock with the one in ath9k_htc_stop().

Indeed yes, nice catch.
There is no need to lock the cancellation stuff anyway,
I'll just move them outside the lock.

Thanks for the review.

Sujith