All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 4/5] ath10k: protect wep tx key setup
Date: Wed, 14 May 2014 22:50:48 +0300	[thread overview]
Message-ID: <87d2fgcf6v.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <1399637749-13489-5-git-send-email-michal.kazior@tieto.com> (Michal Kazior's message of "Fri, 9 May 2014 14:15:48 +0200")

Michal Kazior <michal.kazior@tieto.com> writes:

> All configuration sequences should be protected
> with conf_mutex to avoid concurrent/conflicting
> requests.
>
> This should make sure that wep tx key setup is not
> performed while hw is restarted (at least).

Locks and mutexes should protect data, not thread of execution. What are
we exactly protecting here, arvif->def_wep_key_idx?

The patch makes sense, I'm just trying to understand the idea behind the
implementation.

> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -1888,8 +1888,10 @@ static void ath10k_tx_wep_key_work(struct work_struct *work)
>  						wep_key_work);
>  	int ret, keyidx = arvif->def_wep_key_newidx;
>  
> +	mutex_lock(&arvif->ar->conf_mutex);
> +
>  	if (arvif->def_wep_key_idx == keyidx)
> -		return;
> +		goto unlock;

BTW, shouldn't we also check the state and bail out if the state is not
ON (and possibly RESTARTED)? How can this work otherwise?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: <ath10k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 4/5] ath10k: protect wep tx key setup
Date: Wed, 14 May 2014 22:50:48 +0300	[thread overview]
Message-ID: <87d2fgcf6v.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <1399637749-13489-5-git-send-email-michal.kazior@tieto.com> (Michal Kazior's message of "Fri, 9 May 2014 14:15:48 +0200")

Michal Kazior <michal.kazior@tieto.com> writes:

> All configuration sequences should be protected
> with conf_mutex to avoid concurrent/conflicting
> requests.
>
> This should make sure that wep tx key setup is not
> performed while hw is restarted (at least).

Locks and mutexes should protect data, not thread of execution. What are
we exactly protecting here, arvif->def_wep_key_idx?

The patch makes sense, I'm just trying to understand the idea behind the
implementation.

> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -1888,8 +1888,10 @@ static void ath10k_tx_wep_key_work(struct work_struct *work)
>  						wep_key_work);
>  	int ret, keyidx = arvif->def_wep_key_newidx;
>  
> +	mutex_lock(&arvif->ar->conf_mutex);
> +
>  	if (arvif->def_wep_key_idx == keyidx)
> -		return;
> +		goto unlock;

BTW, shouldn't we also check the state and bail out if the state is not
ON (and possibly RESTARTED)? How can this work otherwise?

-- 
Kalle Valo

  parent reply	other threads:[~2014-05-14 19:51 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 12:15 [PATCH 0/5] ath10k: recovery fixes 2014-05-09 Michal Kazior
2014-05-09 12:15 ` Michal Kazior
2014-05-09 12:15 ` [PATCH 1/5] ath10k: clean up start() callback Michal Kazior
2014-05-09 12:15   ` Michal Kazior
2014-05-14 19:07   ` Kalle Valo
2014-05-14 19:07     ` Kalle Valo
2014-05-09 12:15 ` [PATCH 2/5] ath10k: perform hw restart lazily Michal Kazior
2014-05-09 12:15   ` Michal Kazior
2014-05-09 12:15 ` [PATCH 3/5] ath10k: drain tx before restarting hw Michal Kazior
2014-05-09 12:15   ` Michal Kazior
2014-05-09 12:15 ` [PATCH 4/5] ath10k: protect wep tx key setup Michal Kazior
2014-05-09 12:15   ` Michal Kazior
2014-05-14 19:17   ` Kalle Valo
2014-05-14 19:17     ` Kalle Valo
2014-05-14 19:50   ` Kalle Valo [this message]
2014-05-14 19:50     ` Kalle Valo
2014-05-15  6:04     ` Michal Kazior
2014-05-15  6:04       ` Michal Kazior
2014-05-09 12:15 ` [PATCH 5/5] ath10k: dont configure bssid for ap mode Michal Kazior
2014-05-09 12:15   ` Michal Kazior
2014-05-14 18:58   ` Kalle Valo
2014-05-14 18:58     ` Kalle Valo
2014-05-15  8:41 ` [PATCH v2 0/5] ath10k: recovery fixes 2014-05-09 Michal Kazior
2014-05-15  8:41   ` Michal Kazior
2014-05-15  8:42   ` [PATCH v2 1/5] ath10k: clean up start() callback Michal Kazior
2014-05-15  8:42     ` Michal Kazior
2014-05-15  8:42   ` [PATCH v2 2/5] ath10k: perform hw restart lazily Michal Kazior
2014-05-15  8:42     ` Michal Kazior
2014-05-15  8:42   ` [PATCH v2 3/5] ath10k: drain tx before restarting hw Michal Kazior
2014-05-15  8:42     ` Michal Kazior
2014-05-15 13:18     ` Kalle Valo
2014-05-15 13:18       ` Kalle Valo
2014-05-16 14:37       ` Kalle Valo
2014-05-16 14:37         ` Kalle Valo
2014-05-23  8:27     ` Kalle Valo
2014-05-23  8:27       ` Kalle Valo
2014-05-23  8:38       ` Michal Kazior
2014-05-23  8:38         ` Michal Kazior
2014-05-23  8:45         ` Kalle Valo
2014-05-23  8:45           ` Kalle Valo
2014-05-23  9:06           ` Michal Kazior
2014-05-23  9:06             ` Michal Kazior
2014-05-23 10:31             ` Kalle Valo
2014-05-23 10:31               ` Kalle Valo
2014-05-23 10:37               ` Michal Kazior
2014-05-23 10:37                 ` Michal Kazior
2014-05-23 13:03             ` Johannes Berg
2014-05-23 13:03               ` Johannes Berg
2014-05-26  5:48               ` Michal Kazior
2014-05-26  5:48                 ` Michal Kazior
2014-05-26  6:29                 ` Johannes Berg
2014-05-26  6:29                   ` Johannes Berg
2014-05-26  9:40     ` Kalle Valo
2014-05-26  9:40       ` Kalle Valo
2014-05-26  9:43       ` Michal Kazior
2014-05-26  9:43         ` Michal Kazior
2014-05-15  8:42   ` [PATCH v2 4/5] ath10k: protect wep tx key setup Michal Kazior
2014-05-15  8:42     ` Michal Kazior
2014-05-15  8:42   ` [PATCH v2 5/5] ath10k: dont configure bssid for ap mode Michal Kazior
2014-05-15  8:42     ` Michal Kazior
2014-05-27  9:29   ` [PATCH v2 0/5] ath10k: recovery fixes 2014-05-09 Kalle Valo
2014-05-27  9:29     ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d2fgcf6v.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michal.kazior@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.