From: Johannes Berg <johannes@sipsolutions.net>
To: John Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org,
Ron Rindjunsky <ron.rindjunsky@intel.com>
Subject: [PATCH 1/8] mac80211: clarify use of TX status/RX callbacks
Date: Fri, 22 Feb 2008 12:16:45 +0100 [thread overview]
Message-ID: <20080222111747.671292000@sipsolutions.net> (raw)
In-Reply-To: 20080222111644.183587000@sipsolutions.net
This patch clarifies the use of the irqsafe vs. non-irq-safe
functions and their respective locking requirements.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
include/net/mac80211.h | 37 ++++++++++++++++++++++++++++++++++---
1 file changed, 34 insertions(+), 3 deletions(-)
--- everything.orig/include/net/mac80211.h 2008-02-22 11:45:11.000000000 +0100
+++ everything/include/net/mac80211.h 2008-02-22 11:49:23.000000000 +0100
@@ -38,7 +38,11 @@
* called in hardware interrupt context. The low-level driver must not call any
* other functions in hardware interrupt context. If there is a need for such
* call, the low-level driver should first ACK the interrupt and perform the
- * IEEE 802.11 code call after this, e.g. from a scheduled workqueue function.
+ * IEEE 802.11 code call after this, e.g. from a scheduled workqueue or even
+ * tasklet function.
+ *
+ * NOTE: If the driver opts to use the _irqsafe() functions, it may not also
+ * use the non-irqsafe functions!
*/
/**
@@ -1204,7 +1208,10 @@ void __ieee80211_rx(struct ieee80211_hw
* buffer in @skb must start with an IEEE 802.11 header or a radiotap
* header if %RX_FLAG_RADIOTAP is set in the @status flags.
*
- * This function may not be called in IRQ context.
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other. Calls
+ * to this function and ieee80211_rx_irqsafe() may not be mixed for a
+ * single hardware.
*
* @hw: the hardware this frame came in on
* @skb: the buffer to receive, owned by mac80211 after this call
@@ -1221,7 +1228,10 @@ static inline void ieee80211_rx(struct i
* ieee80211_rx_irqsafe - receive frame
*
* Like ieee80211_rx() but can be called in IRQ context
- * (internally defers to a workqueue.)
+ * (internally defers to a tasklet.)
+ *
+ * Calls to this function and ieee80211_rx() may not be mixed for a
+ * single hardware.
*
* @hw: the hardware this frame came in on
* @skb: the buffer to receive, owned by mac80211 after this call
@@ -1240,6 +1250,11 @@ void ieee80211_rx_irqsafe(struct ieee802
* transmitted. It is permissible to not call this function for
* multicast frames but this can affect statistics.
*
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other. Calls
+ * to this function and ieee80211_tx_status_irqsafe() may not be mixed
+ * for a single hardware.
+ *
* @hw: the hardware the frame was transmitted by
* @skb: the frame that was transmitted, owned by mac80211 after this call
* @status: status information for this frame; the status pointer need not
@@ -1249,6 +1264,22 @@ void ieee80211_rx_irqsafe(struct ieee802
void ieee80211_tx_status(struct ieee80211_hw *hw,
struct sk_buff *skb,
struct ieee80211_tx_status *status);
+
+/**
+ * ieee80211_tx_status_irqsafe - irq-safe transmit status callback
+ *
+ * Like ieee80211_tx_status() but can be called in IRQ context
+ * (internally defers to a tasklet.)
+ *
+ * Calls to this function and ieee80211_tx_status() may not be mixed for a
+ * single hardware.
+ *
+ * @hw: the hardware the frame was transmitted by
+ * @skb: the frame that was transmitted, owned by mac80211 after this call
+ * @status: status information for this frame; the status pointer need not
+ * be valid after this function returns and is not freed by mac80211,
+ * it is recommended that it points to a stack area
+ */
void ieee80211_tx_status_irqsafe(struct ieee80211_hw *hw,
struct sk_buff *skb,
struct ieee80211_tx_status *status);
--
next prev parent reply other threads:[~2008-02-22 14:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-22 11:16 [PATCH 0/8] mac80211 sta info and related changes Johannes Berg
2008-02-22 11:16 ` Johannes Berg [this message]
2008-02-22 11:16 ` [PATCH 2/8] mac80211: safely free beacon in ieee80211_if_reinit Johannes Berg
2008-02-22 11:16 ` [PATCH 3/8] mac80211: split ieee80211_key_alloc Johannes Berg
2008-02-22 11:16 ` [PATCH 4/8] mac80211: RCU-ify STA info structure access Johannes Berg
2008-03-05 1:57 ` Chatre, Reinette
2008-03-05 9:23 ` Johannes Berg
2008-03-05 19:25 ` Chatre, Reinette
2008-02-22 11:16 ` [PATCH 5/8] mac80211: split ieee80211_txrx_data Johannes Berg
2008-02-22 11:16 ` [PATCH 6/8] mac80211: split sta_info_add Johannes Berg
2008-02-22 11:16 ` [PATCH 7/8] mac80211: remove STA infos last_ack stuff Johannes Berg
2008-02-22 11:16 ` [PATCH 8/8] mac80211: clean up sta_info and document locking Johannes Berg
2008-02-22 21:41 ` [PATCH 0/8] mac80211 sta info and related changes Johannes Berg
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=20080222111747.671292000@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=ron.rindjunsky@intel.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 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).