* Re: [RFC] cfg80211: fix race between sysfs and cfg80211
From: Maxime Bizon @ 2010-07-17 22:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1279394982.3931.0.camel@jlt3.sipsolutions.net>
On Sat, 2010-07-17 at 21:29 +0200, Johannes Berg wrote:
> Maybe we should hold the mutex around the debugfs stuff as well? Then
> tools could even access that race-free, and we can simplify the code by
> having an "out_unlock" label.
device_add() is called before adding the phy to the cfg80211 device
list.
So if a userspace program uses sysfs uevents to detect new phy
devices, and queries nl80211 to get phy info, it can get ENODEV even
though the phy exists in sysfs.
An easy workaround is to hold the cfg80211 mutex until the phy is
present both in sysfs and cfg80211 device list.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
---
net/wireless/core.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6ac70c1..fd164db 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -472,24 +472,22 @@ int wiphy_register(struct wiphy *wiphy)
/* check and set up bitrates */
ieee80211_set_bitrate_flags(wiphy);
+ mutex_lock(&cfg80211_mutex);
+
res = device_add(&rdev->wiphy.dev);
if (res)
- return res;
+ goto out_unlock;
res = rfkill_register(rdev->rfkill);
if (res)
goto out_rm_dev;
- mutex_lock(&cfg80211_mutex);
-
/* set up regulatory info */
wiphy_update_regulatory(wiphy, NL80211_REGDOM_SET_BY_CORE);
list_add_rcu(&rdev->list, &cfg80211_rdev_list);
cfg80211_rdev_list_generation++;
- mutex_unlock(&cfg80211_mutex);
-
/* add to debugfs */
rdev->wiphy.debugfsdir =
debugfs_create_dir(wiphy_name(&rdev->wiphy),
@@ -509,11 +507,15 @@ int wiphy_register(struct wiphy *wiphy)
}
cfg80211_debugfs_rdev_add(rdev);
+ mutex_unlock(&cfg80211_mutex);
return 0;
- out_rm_dev:
+out_rm_dev:
device_del(&rdev->wiphy.dev);
+
+out_unlock:
+ mutex_unlock(&cfg80211_mutex);
return res;
}
EXPORT_SYMBOL(wiphy_register);
--
1.7.1
--
Maxime
^ permalink raw reply related
* [PATCH/RFC 2/3] ath5k: use tracing for packet tx/rx dump
From: Bob Copeland @ 2010-07-17 19:35 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel, Bob Copeland
In-Reply-To: <1279395336-856-1-git-send-email-me@bobcopeland.com>
This adds a few tracepoints to ath5k driver transmit and
receive callbacks in order to record packet traffic.
The advantage of this approach over the previous debug
statements in the kernel printk buffer is that the debug
information is no longer an out-of-line function call,
and the trace can be combined with mac80211 tracepoints.
We record the entire packet in the trace buffer so that
the data can be extracted with external scripts.
The corresponding debug dump functions are removed.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/ath5k_trace.h | 97 ++++++++++++++++++++++++++
drivers/net/wireless/ath/ath5k/base.c | 12 ++-
drivers/net/wireless/ath/ath5k/debug.c | 20 -----
drivers/net/wireless/ath/ath5k/debug.h | 4 -
4 files changed, 105 insertions(+), 28 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/ath5k_trace.h
diff --git a/drivers/net/wireless/ath/ath5k/ath5k_trace.h b/drivers/net/wireless/ath/ath5k/ath5k_trace.h
new file mode 100644
index 0000000..00d9773
--- /dev/null
+++ b/drivers/net/wireless/ath/ath5k/ath5k_trace.h
@@ -0,0 +1,97 @@
+#if !defined(__TRACE_ATH5K_H) || defined(TRACE_HEADER_MULTI_READ)
+#define __TRACE_ATH5K_H
+
+#include <linux/tracepoint.h>
+#include "base.h"
+
+struct sk_buff;
+
+#define PRIV_ENTRY __field(struct ath5k_softc *, priv)
+#define PRIV_ASSIGN __entry->priv = priv
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM ath5k
+
+TRACE_EVENT(ath5k_rx,
+ TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb),
+ TP_ARGS(priv, skb),
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(unsigned long, skbaddr)
+ __dynamic_array(u8, frame, skb->len)
+ ),
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->skbaddr = (unsigned long) skb;
+ memcpy(__get_dynamic_array(frame), skb->data, skb->len);
+ ),
+ TP_printk(
+ "[%p] RX skb=%lx", __entry->priv, __entry->skbaddr
+ )
+);
+
+TRACE_EVENT(ath5k_tx,
+ TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
+ struct ath5k_txq *q),
+
+ TP_ARGS(priv, skb, q),
+
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(unsigned long, skbaddr)
+ __field(u8, qnum)
+ __dynamic_array(u8, frame, skb->len)
+ ),
+
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->skbaddr = (unsigned long) skb;
+ __entry->qnum = (u8) q->qnum;
+ memcpy(__get_dynamic_array(frame), skb->data, skb->len);
+ ),
+
+ TP_printk(
+ "[%p] TX skb=%lx q=%d", __entry->priv, __entry->skbaddr,
+ __entry->qnum
+ )
+);
+
+TRACE_EVENT(ath5k_tx_complete,
+ TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
+ struct ath5k_txq *q, struct ath5k_tx_status *ts),
+
+ TP_ARGS(priv, skb, q, ts),
+
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(unsigned long, skbaddr)
+ __field(u8, qnum)
+ __field(u8, ts_status)
+ __field(s8, ts_rssi)
+ __field(u8, ts_antenna)
+ ),
+
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->skbaddr = (unsigned long) skb;
+ __entry->qnum = (u8) q->qnum;
+ __entry->ts_status = ts->ts_status;
+ __entry->ts_rssi = ts->ts_rssi;
+ __entry->ts_antenna = ts->ts_antenna;
+ ),
+
+ TP_printk(
+ "[%p] TX end skb=%lx q=%d stat=%x rssi=%d ant=%x",
+ __entry->priv, __entry->skbaddr, __entry->qnum,
+ __entry->ts_status, __entry->ts_rssi, __entry->ts_antenna
+ )
+);
+
+#endif /* _TRACE_ATH5K_H */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH ../../drivers/net/wireless/ath/ath5k
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE ath5k_trace
+
+#include <trace/define_trace.h>
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 0d5de25..23a5679 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -61,6 +61,9 @@
#include "debug.h"
#include "ani.h"
+#define CREATE_TRACE_POINTS
+#include "ath5k_trace.h"
+
static int modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
@@ -1962,7 +1965,7 @@ ath5k_receive_frame(struct ath5k_softc *sc, struct sk_buff *skb,
sc->curband->bitrates[rxs->rate_idx].hw_value_short)
rxs->flag |= RX_FLAG_SHORTPRE;
- ath5k_debug_dump_skb(sc, skb, "RX ", 0);
+ trace_ath5k_rx(sc, skb);
ath5k_update_beacon_rssi(sc, skb, rs->rs_rssi);
@@ -2183,6 +2186,7 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
else
sc->stats.antenna_tx[0]++; /* invalid */
+ trace_ath5k_tx_complete(sc, skb, txq, &ts);
ieee80211_tx_status(sc->hw, skb);
spin_lock(&sc->txbuflock);
@@ -2352,6 +2356,8 @@ ath5k_beacon_send(struct ath5k_softc *sc)
if (sc->opmode == NL80211_IFTYPE_AP)
ath5k_beacon_update(sc->hw, sc->vif);
+ trace_ath5k_tx(sc, bf->skb, &sc->txqs[sc->bhalq]);
+
ath5k_hw_set_txdp(ah, sc->bhalq, bf->daddr);
ath5k_hw_start_tx_dma(ah, sc->bhalq);
ATH5K_DBG(sc, ATH5K_DEBUG_BEACON, "TXDP[%u] = %llx (%p)\n",
@@ -2878,7 +2884,7 @@ static int ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
unsigned long flags;
int padsize;
- ath5k_debug_dump_skb(sc, skb, "TX ", 1);
+ trace_ath5k_tx(sc, skb, txq);
if (sc->opmode == NL80211_IFTYPE_MONITOR)
ATH5K_DBG(sc, ATH5K_DEBUG_XMIT, "tx in monitor (scan?)\n");
@@ -3410,8 +3416,6 @@ ath5k_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
goto out;
}
- ath5k_debug_dump_skb(sc, skb, "BC ", 1);
-
ath5k_txbuf_free_skb(sc, sc->bbuf);
sc->bbuf->skb = skb;
ret = ath5k_beacon_setup(sc, sc->bbuf);
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index 2222022..d107cd6 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -305,8 +305,6 @@ static const struct {
{ ATH5K_DEBUG_CALIBRATE, "calib", "periodic calibration" },
{ ATH5K_DEBUG_TXPOWER, "txpower", "transmit power setting" },
{ ATH5K_DEBUG_LED, "led", "LED management" },
- { ATH5K_DEBUG_DUMP_RX, "dumprx", "print received skb content" },
- { ATH5K_DEBUG_DUMP_TX, "dumptx", "print transmit skb content" },
{ ATH5K_DEBUG_DUMPBANDS, "dumpbands", "dump bands" },
{ ATH5K_DEBUG_ANI, "ani", "adaptive noise immunity" },
{ ATH5K_DEBUG_DESC, "desc", "descriptor chains" },
@@ -955,24 +953,6 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
}
void
-ath5k_debug_dump_skb(struct ath5k_softc *sc,
- struct sk_buff *skb, const char *prefix, int tx)
-{
- char buf[16];
-
- if (likely(!((tx && (sc->debug.level & ATH5K_DEBUG_DUMP_TX)) ||
- (!tx && (sc->debug.level & ATH5K_DEBUG_DUMP_RX)))))
- return;
-
- snprintf(buf, sizeof(buf), "%s %s", wiphy_name(sc->hw->wiphy), prefix);
-
- print_hex_dump_bytes(buf, DUMP_PREFIX_NONE, skb->data,
- min(200U, skb->len));
-
- printk(KERN_DEBUG "\n");
-}
-
-void
ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
{
struct ath5k_desc *ds = bf->desc;
diff --git a/drivers/net/wireless/ath/ath5k/debug.h b/drivers/net/wireless/ath/ath5k/debug.h
index 9b22722..c260b00 100644
--- a/drivers/net/wireless/ath/ath5k/debug.h
+++ b/drivers/net/wireless/ath/ath5k/debug.h
@@ -91,8 +91,6 @@ struct ath5k_dbg_info {
* @ATH5K_DEBUG_CALIBRATE: periodic calibration
* @ATH5K_DEBUG_TXPOWER: transmit power setting
* @ATH5K_DEBUG_LED: led management
- * @ATH5K_DEBUG_DUMP_RX: print received skb content
- * @ATH5K_DEBUG_DUMP_TX: print transmit skb content
* @ATH5K_DEBUG_DUMPBANDS: dump bands
* @ATH5K_DEBUG_TRACE: trace function calls
* @ATH5K_DEBUG_DESC: descriptor setup
@@ -114,8 +112,6 @@ enum ath5k_debug_level {
ATH5K_DEBUG_CALIBRATE = 0x00000020,
ATH5K_DEBUG_TXPOWER = 0x00000040,
ATH5K_DEBUG_LED = 0x00000080,
- ATH5K_DEBUG_DUMP_RX = 0x00000100,
- ATH5K_DEBUG_DUMP_TX = 0x00000200,
ATH5K_DEBUG_DUMPBANDS = 0x00000400,
ATH5K_DEBUG_ANI = 0x00002000,
ATH5K_DEBUG_DESC = 0x00004000,
--
1.7.1.1
^ permalink raw reply related
* [PATCH/RFC 1/3] ath5k: log descriptor chains at a new debug level
From: Bob Copeland @ 2010-07-17 19:35 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel, Bob Copeland
In-Reply-To: <1279395336-856-1-git-send-email-me@bobcopeland.com>
Descriptors are currently logged with ATH5K_DEBUG_RESET,
which isn't really apt, and also means we can't see just
the descriptor setup or just the resets. Add a new
debug level just for that.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/debug.c | 5 +++--
drivers/net/wireless/ath/ath5k/debug.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index ebb9c23..2222022 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -309,6 +309,7 @@ static const struct {
{ ATH5K_DEBUG_DUMP_TX, "dumptx", "print transmit skb content" },
{ ATH5K_DEBUG_DUMPBANDS, "dumpbands", "dump bands" },
{ ATH5K_DEBUG_ANI, "ani", "adaptive noise immunity" },
+ { ATH5K_DEBUG_DESC, "desc", "descriptor chains" },
{ ATH5K_DEBUG_ANY, "all", "show all debug levels" },
};
@@ -937,7 +938,7 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
struct ath5k_rx_status rs = {};
int status;
- if (likely(!(sc->debug.level & ATH5K_DEBUG_RESET)))
+ if (likely(!(sc->debug.level & ATH5K_DEBUG_DESC)))
return;
printk(KERN_DEBUG "rxdp %x, rxlink %p\n",
@@ -979,7 +980,7 @@ ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
struct ath5k_tx_status ts = {};
int done;
- if (likely(!(sc->debug.level & ATH5K_DEBUG_RESET)))
+ if (likely(!(sc->debug.level & ATH5K_DEBUG_DESC)))
return;
done = sc->ah->ah_proc_tx_desc(sc->ah, bf->desc, &ts);
diff --git a/drivers/net/wireless/ath/ath5k/debug.h b/drivers/net/wireless/ath/ath5k/debug.h
index 606ae94..9b22722 100644
--- a/drivers/net/wireless/ath/ath5k/debug.h
+++ b/drivers/net/wireless/ath/ath5k/debug.h
@@ -95,6 +95,7 @@ struct ath5k_dbg_info {
* @ATH5K_DEBUG_DUMP_TX: print transmit skb content
* @ATH5K_DEBUG_DUMPBANDS: dump bands
* @ATH5K_DEBUG_TRACE: trace function calls
+ * @ATH5K_DEBUG_DESC: descriptor setup
* @ATH5K_DEBUG_ANY: show at any debug level
*
* The debug level is used to control the amount and type of debugging output
@@ -117,6 +118,7 @@ enum ath5k_debug_level {
ATH5K_DEBUG_DUMP_TX = 0x00000200,
ATH5K_DEBUG_DUMPBANDS = 0x00000400,
ATH5K_DEBUG_ANI = 0x00002000,
+ ATH5K_DEBUG_DESC = 0x00004000,
ATH5K_DEBUG_ANY = 0xffffffff
};
--
1.7.1.1
^ permalink raw reply related
* [PATCH/RFC 0/3] ath5k: add driver tracepoints
From: Bob Copeland @ 2010-07-17 19:35 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel
This series adds some tracepoints for reset and tx/rx, with an
eye toward replacing some of the debug printks we have today.
Stolen form iwlwifi is the idea of logging entire packets so
we can generate pcap files from the traces, via something like:
$ mkdir -p ~/.trace-cmd/plugins
$ cd ~/.trace-cmd/plugins
$ wget 'http://bobcopeland.com/srcs/ath5k_trace.py'
$ trace-cmd record -e mac80211 -e ath5k sleep 500
$ trace-cmd report | less
$ wireshark /tmp/pcap.out
I quite like the result, but I'd be interested to hear others'
opinions on the approach. Right now I think these tracepoints
will be useful in seeing causes of excessive resets, and debugging
queue hangs.
^ permalink raw reply
* [PATCH/RFC 3/3] ath5k: trace resets
From: Bob Copeland @ 2010-07-17 19:35 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel, Bob Copeland
In-Reply-To: <1279395336-856-1-git-send-email-me@bobcopeland.com>
This change adds a tracepoint for ath5k_reset. We record the
reason for each reset and the new channel frequency.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/ath5k_trace.h | 38 +++++++++++++++++
drivers/net/wireless/ath/ath5k/base.c | 56 +++++++-------------------
drivers/net/wireless/ath/ath5k/base.h | 12 ++++++
drivers/net/wireless/ath/ath5k/debug.c | 7 ++-
drivers/net/wireless/ath/ath5k/debug.h | 2 -
5 files changed, 70 insertions(+), 45 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k_trace.h b/drivers/net/wireless/ath/ath5k/ath5k_trace.h
index 00d9773..3a5112d 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k_trace.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k_trace.h
@@ -12,6 +12,44 @@ struct sk_buff;
#undef TRACE_SYSTEM
#define TRACE_SYSTEM ath5k
+TRACE_EVENT(ath5k_reset,
+ TP_PROTO(struct ath5k_softc *priv, struct ieee80211_channel *chan,
+ enum ath5k_reset_reason reason),
+
+ TP_ARGS(priv, chan, reason),
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(u32, reason)
+ __field(u16, freq)
+ ),
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->reason = reason;
+ __entry->freq = chan->center_freq;
+ ),
+ TP_printk(
+ "[%p] reset reason=%d freq=%u", __entry->priv,
+ __entry->reason, __entry->freq
+ )
+);
+
+TRACE_EVENT(ath5k_reset_end,
+ TP_PROTO(struct ath5k_softc *priv, int result),
+
+ TP_ARGS(priv, result),
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(s32, result)
+ ),
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->result = (s32) result;
+ ),
+ TP_printk(
+ "[%p] reset ret=%d", __entry->priv, __entry->result
+ )
+);
+
TRACE_EVENT(ath5k_rx,
TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb),
TP_ARGS(priv, skb),
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 23a5679..44732b5 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -224,7 +224,8 @@ static struct pci_driver ath5k_pci_driver = {
static int ath5k_tx(struct ieee80211_hw *hw, struct sk_buff *skb);
static int ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
struct ath5k_txq *txq);
-static int ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan);
+static int ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
+ enum ath5k_reset_reason ath5k_reset_reason);
static int ath5k_start(struct ieee80211_hw *hw);
static void ath5k_stop(struct ieee80211_hw *hw);
static int ath5k_add_interface(struct ieee80211_hw *hw,
@@ -1120,17 +1121,13 @@ ath5k_setup_bands(struct ieee80211_hw *hw)
static int
ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
{
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
- "channel set, resetting (%u -> %u MHz)\n",
- sc->curchan->center_freq, chan->center_freq);
-
/*
* To switch channels clear any pending DMA operations;
* wait long enough for the RX fifo to drain, reset the
* hardware at the new frequency, and then re-enable
* the relevant bits of the h/w.
*/
- return ath5k_reset(sc, chan);
+ return ath5k_reset(sc, chan, RESET_SET_CHANNEL);
}
static void
@@ -1615,8 +1612,6 @@ ath5k_txq_drainq(struct ath5k_softc *sc, struct ath5k_txq *txq)
*/
spin_lock_bh(&txq->lock);
list_for_each_entry_safe(bf, bf0, &txq->q, list) {
- ath5k_debug_printtxbuf(sc, bf);
-
ath5k_txbuf_free_skb(sc, bf);
spin_lock_bh(&sc->txbuflock);
@@ -1641,18 +1636,9 @@ ath5k_txq_cleanup(struct ath5k_softc *sc)
if (likely(!test_bit(ATH_STAT_INVALID, sc->status))) {
/* don't touch the hardware if marked invalid */
ath5k_hw_stop_tx_dma(ah, sc->bhalq);
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "beacon queue %x\n",
- ath5k_hw_get_txdp(ah, sc->bhalq));
for (i = 0; i < ARRAY_SIZE(sc->txqs); i++)
- if (sc->txqs[i].setup) {
+ if (sc->txqs[i].setup)
ath5k_hw_stop_tx_dma(ah, sc->txqs[i].qnum);
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "txq [%u] %x, "
- "link %p\n",
- sc->txqs[i].qnum,
- ath5k_hw_get_txdp(ah,
- sc->txqs[i].qnum),
- sc->txqs[i].link);
- }
}
for (i = 0; i < ARRAY_SIZE(sc->txqs); i++)
@@ -1693,9 +1679,6 @@ ath5k_rx_start(struct ath5k_softc *sc)
common->rx_bufsize = roundup(IEEE80211_MAX_LEN, common->cachelsz);
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "cachelsz %u rx_bufsize %u\n",
- common->cachelsz, common->rx_bufsize);
-
spin_lock_bh(&sc->rxbuflock);
sc->rxlink = NULL;
list_for_each_entry(bf, &sc->rxbuf, list) {
@@ -2329,8 +2312,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
ATH5K_DBG(sc, ATH5K_DEBUG_BEACON,
"stuck beacon time (%u missed)\n",
sc->bmisscount);
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
- "stuck beacon, resetting\n");
+ sc->reset_reason = RESET_STUCK_BEACON;
ieee80211_queue_work(sc->hw, &sc->reset_work);
}
return;
@@ -2561,8 +2543,6 @@ ath5k_init(struct ath5k_softc *sc)
mutex_lock(&sc->lock);
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "mode %d\n", sc->opmode);
-
/*
* Stop anything previously setup. This is safe
* no matter this is the first time through or not.
@@ -2582,7 +2562,7 @@ ath5k_init(struct ath5k_softc *sc)
AR5K_INT_RXORN | AR5K_INT_TXDESC | AR5K_INT_TXEOL |
AR5K_INT_FATAL | AR5K_INT_GLOBAL | AR5K_INT_MIB;
- ret = ath5k_reset(sc, NULL);
+ ret = ath5k_reset(sc, NULL, RESET_INIT);
if (ret)
goto done;
@@ -2608,9 +2588,6 @@ ath5k_stop_locked(struct ath5k_softc *sc)
{
struct ath5k_hw *ah = sc->ah;
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "invalid %u\n",
- test_bit(ATH_STAT_INVALID, sc->status));
-
/*
* Shutdown the hardware and driver:
* stop output from above
@@ -2686,9 +2663,6 @@ ath5k_stop_hw(struct ath5k_softc *sc)
* on the device (same as initial state after attach) and
* leave it idle (keep MAC/BB on warm reset) */
ret = ath5k_hw_on_hold(sc->ah);
-
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
- "putting device to sleep\n");
}
ath5k_txbuf_free_skb(sc, sc->bbuf);
@@ -2743,8 +2717,7 @@ ath5k_intr(int irq, void *dev_id)
* Fatal errors are unrecoverable.
* Typically these are caused by DMA errors.
*/
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
- "fatal int, resetting\n");
+ sc->reset_reason = RESET_FATAL;
ieee80211_queue_work(sc->hw, &sc->reset_work);
} else if (unlikely(status & AR5K_INT_RXORN)) {
/*
@@ -2758,8 +2731,7 @@ ath5k_intr(int irq, void *dev_id)
*/
sc->stats.rxorn_intr++;
if (ah->ah_mac_srev < AR5K_SREV_AR5212) {
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
- "rx overrun, resetting\n");
+ sc->reset_reason = RESET_RXORN;
ieee80211_queue_work(sc->hw, &sc->reset_work);
}
else
@@ -2829,7 +2801,7 @@ ath5k_tasklet_calibrate(unsigned long data)
* Rfgain is out of bounds, reset the chip
* to load new gain values.
*/
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "calibration, resetting\n");
+ sc->reset_reason = RESET_CALIBRATION;
ieee80211_queue_work(sc->hw, &sc->reset_work);
}
if (ath5k_hw_phy_calibrate(ah, sc->curchan))
@@ -2938,12 +2910,13 @@ drop_packet:
* This should be called with sc->lock.
*/
static int
-ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
+ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
+ enum ath5k_reset_reason reason)
{
struct ath5k_hw *ah = sc->ah;
int ret;
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
+ trace_ath5k_reset(sc, chan, reason);
ath5k_hw_set_imr(ah, 0);
synchronize_irq(sc->pdev->irq);
@@ -2990,8 +2963,9 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
ieee80211_wake_queues(sc->hw);
- return 0;
+ ret = 0;
err:
+ trace_ath5k_reset_end(sc, ret);
return ret;
}
@@ -3001,7 +2975,7 @@ static void ath5k_reset_work(struct work_struct *work)
reset_work);
mutex_lock(&sc->lock);
- ath5k_reset(sc, sc->curchan);
+ ath5k_reset(sc, sc->curchan, sc->reset_reason);
mutex_unlock(&sc->lock);
}
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index dc1241f..cb6e2be 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -140,6 +140,17 @@ struct ath5k_statistics {
unsigned int rxeol_intr;
};
+/* Reset tracing */
+enum ath5k_reset_reason {
+ RESET_INIT,
+ RESET_SET_CHANNEL,
+ RESET_STUCK_BEACON,
+ RESET_FATAL,
+ RESET_RXORN,
+ RESET_CALIBRATION,
+ RESET_DEBUGFS,
+};
+
#if CHAN_DEBUG
#define ATH_CHAN_MAX (26+26+26+200+200)
#else
@@ -192,6 +203,7 @@ struct ath5k_softc {
led_on; /* pin setting for LED on */
struct work_struct reset_work; /* deferred chip reset */
+ enum ath5k_reset_reason reset_reason; /* reason for resetting */
unsigned int rxbufsize; /* rx size based on mtu */
struct list_head rxbuf; /* receive buffer */
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index d107cd6..9ddbfd5 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -278,7 +278,7 @@ static ssize_t write_file_reset(struct file *file,
size_t count, loff_t *ppos)
{
struct ath5k_softc *sc = file->private_data;
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "debug file triggered reset\n");
+ sc->reset_reason = RESET_DEBUGFS;
ieee80211_queue_work(sc->hw, &sc->reset_work);
return count;
}
@@ -297,7 +297,6 @@ static const struct {
const char *name;
const char *desc;
} dbg_info[] = {
- { ATH5K_DEBUG_RESET, "reset", "reset and initialization" },
{ ATH5K_DEBUG_INTR, "intr", "interrupt handling" },
{ ATH5K_DEBUG_MODE, "mode", "mode init/setup" },
{ ATH5K_DEBUG_XMIT, "xmit", "basic xmit operation" },
@@ -931,6 +930,7 @@ ath5k_debug_printrxbuf(struct ath5k_buf *bf, int done,
void
ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
{
+#if 0
struct ath5k_desc *ds;
struct ath5k_buf *bf;
struct ath5k_rx_status rs = {};
@@ -950,11 +950,13 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
ath5k_debug_printrxbuf(bf, status == 0, &rs);
}
spin_unlock_bh(&sc->rxbuflock);
+#endif
}
void
ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
{
+#if 0
struct ath5k_desc *ds = bf->desc;
struct ath5k_hw_5212_tx_desc *td = &ds->ud.ds_tx5212;
struct ath5k_tx_status ts = {};
@@ -971,6 +973,7 @@ ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
td->tx_ctl.tx_control_2, td->tx_ctl.tx_control_3,
td->tx_stat.tx_status_0, td->tx_stat.tx_status_1,
done ? ' ' : (ts.ts_status == 0) ? '*' : '!');
+#endif
}
#endif /* ifdef CONFIG_ATH5K_DEBUG */
diff --git a/drivers/net/wireless/ath/ath5k/debug.h b/drivers/net/wireless/ath/ath5k/debug.h
index c260b00..8a484f2 100644
--- a/drivers/net/wireless/ath/ath5k/debug.h
+++ b/drivers/net/wireless/ath/ath5k/debug.h
@@ -83,7 +83,6 @@ struct ath5k_dbg_info {
/**
* enum ath5k_debug_level - ath5k debug level
*
- * @ATH5K_DEBUG_RESET: reset processing
* @ATH5K_DEBUG_INTR: interrupt handling
* @ATH5K_DEBUG_MODE: mode init/setup
* @ATH5K_DEBUG_XMIT: basic xmit operation
@@ -104,7 +103,6 @@ struct ath5k_dbg_info {
* be combined together by bitwise OR.
*/
enum ath5k_debug_level {
- ATH5K_DEBUG_RESET = 0x00000001,
ATH5K_DEBUG_INTR = 0x00000002,
ATH5K_DEBUG_MODE = 0x00000004,
ATH5K_DEBUG_XMIT = 0x00000008,
--
1.7.1.1
^ permalink raw reply related
* Re: [RFC] cfg80211: fix race between sysfs and cfg80211
From: Johannes Berg @ 2010-07-17 19:29 UTC (permalink / raw)
To: mbizon; +Cc: linux-wireless
In-Reply-To: <1279336415.1941.6.camel@kero>
On Sat, 2010-07-17 at 05:13 +0200, Maxime Bizon wrote:
> device_add() is called before adding the phy to the cfg80211 device
> list.
>
> So if a userspace program uses sysfs uevents to detect new phy
> devices, and queries nl80211 to get phy info, it can get ENODEV even
> though the phy exists in sysfs.
>
> An easy workaround is to hold the cfg80211 mutex until the phy is
> present both in sysfs and cfg80211 device list.
Maybe we should hold the mutex around the debugfs stuff as well? Then
tools could even access that race-free, and we can simplify the code by
having an "out_unlock" label.
johannes
^ permalink raw reply
* Compat-wireless release for 2010-07-17 is baked
From: Compat-wireless cronjob account @ 2010-07-17 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
494061 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5766 - backport from compat module
7213 - total backport code
1.4599 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2465 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100716
compat-wireless release: compat-wireless-2010-07-13-3-g1a05138
^ permalink raw reply
* [PATCH 3/3] iwlwifi: "recover_from_tx_stall" function for 4965
From: Wey-Yi Guy @ 2010-07-17 14:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
In-Reply-To: <1279378516-31290-1-git-send-email-wey-yi.w.guy@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
"Recover from tx stall" function is available for all devices except
4965, here add the functionality to 4965.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 1dd3bc4..3a0d0ad 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2286,6 +2286,7 @@ static struct iwl_lib_ops iwl4965_lib = {
.tx_stats_read = iwl_ucode_tx_stats_read,
.general_stats_read = iwl_ucode_general_stats_read,
},
+ .recover_from_tx_stall = iwl_bg_monitor_recover,
.check_plcp_health = iwl_good_plcp_health,
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] iwlwifi: additional statistic debug counter
From: Wey-Yi Guy @ 2010-07-17 14:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
In-Reply-To: <1279378516-31290-1-git-send-email-wey-yi.w.guy@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Add wait_for_silence_timeout_cnt to statistics_dbg structure
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-commands.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-commands.h b/drivers/net/wireless/iwlwifi/iwl-commands.h
index 74ad10f..83247f7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-commands.h
@@ -3035,7 +3035,8 @@ struct iwl39_statistics_tx {
struct statistics_dbg {
__le32 burst_check;
__le32 burst_count;
- __le32 reserved[4];
+ __le32 wait_for_silence_timeout_cnt;
+ __le32 reserved[3];
} __attribute__ ((packed));
struct iwl39_statistics_div {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/3] iwlwifi update for 2.6.36
From: Wey-Yi Guy @ 2010-07-17 14:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
We add stuck tx queue recovery function for 4965 device
We also include more statistics counters in debugfs to help debugging
Wey-Yi Guy (3):
iwlwifi: additional statistic debug counter
iwlwifi: more statistics counter for agn in debugfs
iwlwifi: "recover_from_tx_stall" function for 4965
these patches are also available from wireless-next-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 7 +++++++
drivers/net/wireless/iwlwifi/iwl-commands.h | 3 ++-
3 files changed, 10 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH 2/3] iwlwifi: more statistics counter for agn in debugfs
From: Wey-Yi Guy @ 2010-07-17 14:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
In-Reply-To: <1279378516-31290-1-git-send-email-wey-yi.w.guy@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Display "wait_for_silence_timeout_cnt" for _agn devices
in debugfs as part of uCode statistics
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c
index 75d6bfc..5e5c512 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c
@@ -813,6 +813,13 @@ ssize_t iwl_ucode_general_stats_read(struct file *file, char __user *user_buf,
delta_dbg->burst_count, max_dbg->burst_count);
pos += scnprintf(buf + pos, bufsz - pos,
" %-30s %10u %10u %10u %10u\n",
+ "wait_for_silence_timeout_count:",
+ le32_to_cpu(dbg->wait_for_silence_timeout_cnt),
+ accum_dbg->wait_for_silence_timeout_cnt,
+ delta_dbg->wait_for_silence_timeout_cnt,
+ max_dbg->wait_for_silence_timeout_cnt);
+ pos += scnprintf(buf + pos, bufsz - pos,
+ " %-30s %10u %10u %10u %10u\n",
"sleep_time:",
le32_to_cpu(general->sleep_time),
accum_general->sleep_time,
--
1.7.0.4
^ permalink raw reply related
* [PATCH] mac80211: fix aggregation action frame handling with AP VLANs
From: Felix Fietkau @ 2010-07-17 13:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville
When aggregation related action frames are enqueued for further work,
and they originate from a STA that is part of an AP VLAN, they are
currently enqueued for the AP interface. This breaks the sta_info_get()
lookup in the actual work function, and because of that, aggregation
sessions are not established for this STA.
Fix this by replacing the sta_info_get call with a call to
sta_info_get_bss.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -756,7 +756,7 @@ static void ieee80211_iface_work(struct
int len = skb->len;
mutex_lock(&local->sta_mtx);
- sta = sta_info_get(sdata, mgmt->sa);
+ sta = sta_info_get_bss(sdata, mgmt->sa);
if (sta) {
switch (mgmt->u.action.u.addba_req.action_code) {
case WLAN_ACTION_ADDBA_REQ:
@@ -797,7 +797,7 @@ static void ieee80211_iface_work(struct
* right, so terminate the session.
*/
mutex_lock(&local->sta_mtx);
- sta = sta_info_get(sdata, mgmt->sa);
+ sta = sta_info_get_bss(sdata, mgmt->sa);
if (sta) {
u16 tid = *ieee80211_get_qos_ctl(hdr) &
IEEE80211_QOS_CTL_TID_MASK;
^ permalink raw reply
* RE: wl1271 firmware
From: Levi, Shahar @ 2010-07-17 12:20 UTC (permalink / raw)
To: Pazzo Da Legare
Cc: linux-wireless@vger.kernel.org, Logan Gunthorpe, Luciano Coelho
In-Reply-To: <AANLkTilHNKeRZX5CMplyriTo2hTPBrz_z1_Zpwoy3SZx@mail.gmail.com>
> -----Original Message-----
> From: Pazzo Da Legare [mailto:pazzodalegare@gmail.com]
> Sent: Saturday, July 17, 2010 12:41 AM
> To: Levi, Shahar; Logan Gunthorpe; Luciano Coelho; linux-
> wireless@vger.kernel.org
> Subject: Re: wl1271 firmware
>
> Dear Shahar,
> Thank you for your help and the news. Could you please indicate a link
> when available?
> Pz
>
Hi Pazzo,
I am still pushing the legal stuff to make it happened. I hope to close that in a few days.
Regards,
Shahar
^ permalink raw reply
* Re: [PATCH] rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()
From: Ivo Van Doorn @ 2010-07-17 10:08 UTC (permalink / raw)
To: Stephen Boyd
Cc: users, John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1279299010-4723-1-git-send-email-bebarino@gmail.com>
On Fri, Jul 16, 2010 at 6:50 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> The rt2x00dev->intf_work workqueue is never initialized when a driver is
> probed for a non-existent device (in this case rt2500usb). On such a
> path we call rt2x00lib_remove_dev() to free any resources initialized
> during the probe before we use INIT_WORK to initialize the workqueue.
> This causes lockdep to get confused since the lock used in the workqueue
> hasn't been initialized yet but is now being acquired during
> cancel_work_sync() called by rt2x00lib_remove_dev().
>
> Fix this by initializing the workqueue first before we attempt to probe
> the device. This should make lockdep happy and avoid breaking any
> assumptions about how the library cleans up after a probe fails.
>
> phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
> Call Trace:
> [<ffffffff8105fe59>] register_lock_class+0x152/0x31f
> [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111
> [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4
> [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf
> [<ffffffff81492aef>] ? _raw_spin_unlock_irqrestore+0x33/0x41
> [<ffffffff810628d5>] lock_acquire+0xd1/0xf7
> [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
> [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e
> [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
> [<ffffffff8104f136>] cancel_work_sync+0xb/0xd
> [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
> [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
> [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52
> [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb]
> [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
> [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e
> [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136
> [<ffffffff812ea167>] __driver_attach+0x4a/0x66
> [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66
> [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89
> [<ffffffff812e9efd>] driver_attach+0x19/0x1b
> [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204
> [<ffffffff812ea41b>] driver_register+0x98/0x109
> [<ffffffff813465dd>] usb_register_driver+0xb2/0x173
> [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb]
> [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb]
> [<ffffffff81000203>] do_one_initcall+0x6d/0x17a
> [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0
> [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* RTL8180L is hitting WARN_ON in net/wireless/scan.c:575
From: Pauli Nieminen @ 2010-07-17 7:30 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm testing 2.6.35-rc4+, I have problem that warning is spamming dmesg
when I have my wifi on. Actual problem caused y that problem is that I
can't scan/connect to any network with 2.6.35.
When I looked the code in warning it might be related to problem that
my wifi reports all signal strength to be 175 or 178 (if I remember
correctly). I'm now using 2.6.35 so I can't check the reported values
from scan results.
lspci:
00:09.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8180L 802.11b MAC [10ec:8180] (rev 20)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC [10ec:8180]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1000 [size=256]
Region 1: Memory at d0004800 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: rtl8180
code line:
if (WARN_ON(wiphy->signal_type == CFG80211_SIGNAL_TYPE_UNSPEC &&
(signal < 0 || signal > 100)))
dmesg:
[ 953.750722] WARNING: at net/wireless/scan.c:575
cfg80211_inform_bss_frame+0x55/0x128 [cfg80211]()
[ 953.750726] Hardware name: Aspire 1350
[ 953.750729] Modules linked in: powernow_k7 cpufreq_userspace
cpufreq_powersave cpufreq_conservative cpufreq_stats parport_pc ppdev
lp parport binfmt_misc fuse ext2 ext4 jbd2 crc16 radeon ttm
drm_kms_helper drm netconsole configfs i2c_algo_bit dm_crypt dm_mod
snd_via82xx snd_via82xx_modem gameport snd_ac97_codec ac97_bus
snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart arc4 snd_seq_midi
ecb snd_rawmidi rtl8180 snd_seq_midi_event mac80211 i2c_viapro
eeprom_93cx6 i2c_core pcmcia snd_seq via_ircc snd_timer snd_seq_device
yenta_socket cfg80211 psmouse pcmcia_rsrc snd irda tpm_tis video
pcspkr processor evdev pcmcia_core serio_raw battery output button
container ac tpm soundcore tpm_bios shpchp rfkill pci_hotplug
snd_page_alloc crc_ccitt ext3 jbd mbcache usbhid sg hid sr_mod sd_mod
cdrom crc_t10dif ata_generic pata_via libata uhci_hcd ehci_hcd usbcore
scsi_mod firewire_ohci floppy thermal via_rhine firewire_core
thermal_sys mii crc_itu_t nls_base [last unloaded: scsi_wait_scan]
[ 953.750817] Pid: 0, comm: swapper Tainted: G W 2.6.35-rc4+ #46
[ 953.750820] Call Trace:
[ 953.750828] [<c102f795>] ? warn_slowpath_common+0x6a/0x7b
[ 953.750839] [<e0e4564f>] ? cfg80211_inform_bss_frame+0x55/0x128 [cfg80211]
[ 953.750846] [<c102f7b3>] ? warn_slowpath_null+0xd/0x10
[ 953.750857] [<e0e4564f>] ? cfg80211_inform_bss_frame+0x55/0x128 [cfg80211]
[ 953.750870] [<e112c487>] ? ieee80211_bss_info_update+0x4a/0x13f [mac80211]
[ 953.750883] [<e112c683>] ? ieee80211_scan_rx+0xfa/0x130 [mac80211]
[ 953.750899] [<e1137dff>] ?
ieee80211_invoke_rx_handlers+0x67/0x166e [mac80211]
[ 953.750905] [<c10079a9>] ? sched_clock+0x9/0xd
[ 953.750911] [<c10471cf>] ? sched_clock_local+0x17/0x11e
[ 953.750920] [<c10454a7>] ? hrtimer_forward+0x10f/0x123
[ 953.750934] [<e11374c2>] ? prepare_for_handlers+0x22/0x25d [mac80211]
[ 953.750948] [<e1139b3f>] ? ieee80211_rx+0x739/0x796 [mac80211]
[ 953.750960] [<e1129444>] ? ieee80211_tasklet_handler+0x48/0xca [mac80211]
[ 953.750967] [<c10339c0>] ? tasklet_action+0x60/0xa4
[ 953.750972] [<c1034425>] ? __do_softirq+0xb1/0x156
[ 953.750977] [<c10344f8>] ? do_softirq+0x2e/0x38
[ 953.750982] [<c10345f6>] ? irq_exit+0x26/0x58
[ 953.750987] [<c10044b2>] ? do_IRQ+0x7d/0x8e
[ 953.750993] [<c10034b0>] ? common_interrupt+0x30/0x38
[ 953.751001] [<e0ecc1a9>] ? acpi_idle_enter_simple+0xef/0x129 [processor]
[ 953.751007] [<c11cce49>] ? cpuidle_idle_call+0x69/0xc0
[ 953.751013] [<c1002202>] ? cpu_idle+0x95/0xaf
[ 953.751018] [<c13bc8c2>] ? start_kernel+0x33a/0x33f
[ 953.751022] ---[ end trace 931bbdec61de23bf ]---
Pauli
^ permalink raw reply
* [RFC] cfg80211: fix race between sysfs and cfg80211
From: Maxime Bizon @ 2010-07-17 3:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
device_add() is called before adding the phy to the cfg80211 device
list.
So if a userspace program uses sysfs uevents to detect new phy
devices, and queries nl80211 to get phy info, it can get ENODEV even
though the phy exists in sysfs.
An easy workaround is to hold the cfg80211 mutex until the phy is
present both in sysfs and cfg80211 device list.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
---
net/wireless/core.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6ac70c1..8952ec4 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -472,15 +472,19 @@ int wiphy_register(struct wiphy *wiphy)
/* check and set up bitrates */
ieee80211_set_bitrate_flags(wiphy);
+ mutex_lock(&cfg80211_mutex);
+
res = device_add(&rdev->wiphy.dev);
- if (res)
+ if (res) {
+ mutex_unlock(&cfg80211_mutex);
return res;
+ }
res = rfkill_register(rdev->rfkill);
- if (res)
+ if (res) {
+ mutex_unlock(&cfg80211_mutex);
goto out_rm_dev;
-
- mutex_lock(&cfg80211_mutex);
+ }
/* set up regulatory info */
wiphy_update_regulatory(wiphy, NL80211_REGDOM_SET_BY_CORE);
--
1.7.1
--
Maxime
^ permalink raw reply related
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-16 23:48 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Johannes Berg, linux-wireless, Florian Klink
In-Reply-To: <1279324150.8881.12.camel@wwguy-huron>
On Fri, 16 Jul 2010 16:49:10 -0700, "Guy, Wey-Yi"
<wey-yi.w.guy@intel.com> wrote:
> Hi Florian,
>
> On Fri, 2010-07-16 at 16:22 -0700, Florian Klink wrote:
>> On Wed, 14 Jul 2010 10:44:21 -0700, "Guy, Wey-Yi"
>> <wey-yi.w.guy@intel.com> wrote:
>> > Hi Florian,
>> >
>> > On Wed, 2010-07-14 at 10:36 -0700, Johannes Berg wrote:
>> >> On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
>> >> > Johannes,
>> >> >
>> >> > On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
>> >> > > Hi,
>> >> > >
>> >> > > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
>> >> > > You can get it here: http://pastebin.com/Q6eCdPZR
>> >> >
>> >> > >
>> >> > >
>> >> > based on the log sent by Florian, I did not see bss_info_change with
>> >> > current BSSID from mac80211. any thought?
>> >> >
>> >> > I am expected to see something like this,
>> >> >
>> >> > [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
>> >> > 0xFD
>> >> > [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
>> >> > 00:25:9c:d0:9f:e1
>> >> > [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
>> >>
>> >> That'd only happen _after_ association, not before, and assoc fails
>> >> here.
>> >>
>> > Could you try different channel instead of channel 12 to see if the
>> > problem still there?
>> >
>> > Thanks
>> > Wey
>> >>
>>
>>
>> Hi,
>>
>> very strange, now I can't reproduce the problem anymore, association
>> works with channel 12 and other ones, too!
>> I have no idea why it's now working...
>>
>> Could this commit affect any link tolerance/timeouts, because I was
>> able to bisect the problem?
>>
> Not sure what happen, but please do let us know if you see the problem
> pop up again. I do not think this patch should affect the link
> tolerance.
>
> Thanks
> Wey
>>
Hi,
okay, but thanks for your time anyway...
:-)
Florian
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Guy, Wey-Yi @ 2010-07-16 23:49 UTC (permalink / raw)
To: Florian Klink; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <a10a4c76a95e1b3694489f0447967b94@imap.flokli.de>
Hi Florian,
On Fri, 2010-07-16 at 16:22 -0700, Florian Klink wrote:
> On Wed, 14 Jul 2010 10:44:21 -0700, "Guy, Wey-Yi"
> <wey-yi.w.guy@intel.com> wrote:
> > Hi Florian,
> >
> > On Wed, 2010-07-14 at 10:36 -0700, Johannes Berg wrote:
> >> On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
> >> > Johannes,
> >> >
> >> > On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
> >> > > Hi,
> >> > >
> >> > > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
> >> > > You can get it here: http://pastebin.com/Q6eCdPZR
> >> >
> >> > >
> >> > >
> >> > based on the log sent by Florian, I did not see bss_info_change with
> >> > current BSSID from mac80211. any thought?
> >> >
> >> > I am expected to see something like this,
> >> >
> >> > [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
> >> > 0xFD
> >> > [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
> >> > 00:25:9c:d0:9f:e1
> >> > [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
> >>
> >> That'd only happen _after_ association, not before, and assoc fails
> >> here.
> >>
> > Could you try different channel instead of channel 12 to see if the
> > problem still there?
> >
> > Thanks
> > Wey
> >>
>
>
> Hi,
>
> very strange, now I can't reproduce the problem anymore, association
> works with channel 12 and other ones, too!
> I have no idea why it's now working...
>
> Could this commit affect any link tolerance/timeouts, because I was
> able to bisect the problem?
>
Not sure what happen, but please do let us know if you see the problem
pop up again. I do not think this patch should affect the link
tolerance.
Thanks
Wey
>
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-16 23:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: Florian Klink, linux-wireless@vger.kernel.org
On Wed, 14 Jul 2010 10:44:21 -0700, "Guy, Wey-Yi"
<wey-yi.w.guy@intel.com> wrote:
> Hi Florian,
>
> On Wed, 2010-07-14 at 10:36 -0700, Johannes Berg wrote:
>> On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
>> > Johannes,
>> >
>> > On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
>> > > Hi,
>> > >
>> > > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
>> > > You can get it here: http://pastebin.com/Q6eCdPZR
>> >
>> > >
>> > >
>> > based on the log sent by Florian, I did not see bss_info_change with
>> > current BSSID from mac80211. any thought?
>> >
>> > I am expected to see something like this,
>> >
>> > [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
>> > 0xFD
>> > [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
>> > 00:25:9c:d0:9f:e1
>> > [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
>>
>> That'd only happen _after_ association, not before, and assoc fails
>> here.
>>
> Could you try different channel instead of channel 12 to see if the
> problem still there?
>
> Thanks
> Wey
>>
Hi,
very strange, now I can't reproduce the problem anymore, association
works with channel 12 and other ones, too!
I have no idea why it's now working...
Could this commit affect any link tolerance/timeouts, because I was
able to bisect the problem?
Florian
^ permalink raw reply
* Re: wl1271 firmware
From: Pazzo Da Legare @ 2010-07-16 21:41 UTC (permalink / raw)
To: Levi, Shahar, Logan Gunthorpe, Luciano Coelho,
linux-wireless@vger.kernel.org
In-Reply-To: <AC090B9732AB2B4DB7FF476E907FE660010685F34E@dnce02.ent.ti.com>
Dear Shahar,
Thank you for your help and the news. Could you please indicate a link
when available?
Pz
2010/7/11, Levi, Shahar <shahar_levi@ti.com>:
>> -----Original Message-----
>> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] On Behalf Of Logan Gunthorpe
>> Sent: Saturday, July 10, 2010 3:20 AM
>> To: Luciano Coelho
>> Cc: linux-wireless@vger.kernel.org
>> Subject: RE: wl1271 firmware
>>
>> Hi Everyone,
>>
>> I too am working with a WL1271 module and have just today got it
>> connected to an Atmel ARM9 development kit (AT91SAM9G45-EKES). So far it
>> appears to work but I have been gated by the firmware and NVS file issues.
>>
>> I have a firmware binary, but it seems to be a newer version
>> (6.1.3.01.5) than what you are using. Does anyone have any idea if this
>> version will work? It seems to be the only one available on TI's
>> website. Additionally, our device manufacturer has been hesitant to
>> provide any support because we are on an unsupported platform and opted
>> to use the open source driver. Are there any other ways to obtain an
>> older version of the firmware?
>>
>> The NVS file is another problem. TI's website has instructions to use a
>> cryptic tool that appears to come with their driver package. There is no
>> source for this tool and for obvious reasons would not work for us.
>>
>> Anyway, I'd like to help in anyway I can. I've taken a look at the
>> twilan.ini file and I see the commonality with wl1271_ini.h. It would be
>> relatively easy to write a tool that parses the INI file and generates
>> the common part of the NVS file. However, I'd have no idea how to
>> generate the device specific calibration or the few fields missing from
>> the INI file.
>>
>> Thanks,
>>
>> Logan
>>
>
> Hi Logan,
> I am pushing to get access to the correct FW and NVS files version in TI
> web. I believe the community wills nave access of those files this week.
> Regarding the tool to generate the NVS file in the correct format, I will
> check that and reply.
> Regards,
> Shahar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Inviato dal mio dispositivo mobile
^ permalink raw reply
* Compat-wireless release for 2010-07-16 is baked
From: Compat-wireless cronjob account @ 2010-07-16 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
4ebcc6c..0442f68 wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
bc3e7ea..91f06bd history -> origin/history
+ 732f7b0...c221ef7 master -> origin/master (forced update)
1c5474a..2f7989e stable -> origin/stable
* [new tag] next-20100716 -> next-20100716
compat-wireless code metrics
494061 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5766 - backport from compat module
7213 - total backport code
1.4599 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2465 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100716
compat-wireless release: compat-wireless-2010-07-13-3-g1a05138
^ permalink raw reply
* Re: [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: Helmut Schaa @ 2010-07-16 18:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: yogeshp, Pradeep Nemavat, Nishant Sarmukadam,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTim2fLLZfD5xrUtioY5mZaF-PgLwrVlMHQHwsL41@mail.gmail.com>
Am Freitag 16 Juli 2010 schrieb Luis R. Rodriguez:
> On Fri, Jul 16, 2010 at 2:16 AM, yogeshp <yogeshp@marvell.com> wrote:
> > Hi Luis,
> > Please see inline comments
> >
> > Luis R. Rodriguez wrote:
> >> On Thu, Jul 15, 2010 at 6:18 AM, yogeshp <yogeshp@marvell.com> wrote:
> >>> BA window size for a successful BA setup is not made available to the driver by
> >>> mac80211. The patch below gets the BA window size from addba response and
> >>> indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
> >
> >> But why do you want that? Your patch and commit log do not mention why
> >> you need this.
> > BA window size from ADDBA response defines how many outstanding MPDUs are allowed for the BA stream by recipient. Since ADDBA response is processed in mac80211 stack, mac80211 should communicate the BA window size to driver (and may be from driver it is further communicated to firmware/hardware) to control the number of outstanding MPDUs while transmitting MPDUs for the stream.
>
> What driver requires this? Your patch does all these changes but do
> not show any secondary patch of a user, so the patch is pointless
> right now.
JFI, rt2800 would also need the BA windows size in its tx path (not only once
but in every tx descriptor). So maybe it would even make sense to move it to
the ieee80211_sta structure? That way rt2800 could also benefit from that
change.
Using the approach as implemented in this patch we would have to store the
value for each STA on our own in rt2x00 although mac80211 has it already
in its own structures.
Just my 2 cents ...
Helmut
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Helmut Schaa @ 2010-07-16 17:44 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Bartlomiej Zolnierkiewicz, Felix Fietkau, John W. Linville,
Ivo Van Doorn, Christoph Egger, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <4C407ED4.6000002@gmail.com>
Am Freitag 16 Juli 2010 schrieb Gertjan van Wingerde:
> On 07/16/10 12:08, Helmut Schaa wrote:
> > On Fri, Jul 16, 2010 at 9:18 AM, Gertjan van Wingerde
> > <gwingerde@gmail.com> wrote:
> >>
> >> On 07/16/10 08:57, Helmut Schaa wrote:
> >>> On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com <mailto:bzolnier@gmail.com>> wrote:
> >>>
> >>> On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
> >>> > On 2010-07-14 3:15 PM, John W. Linville wrote:
> >>> > > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> >>> > >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com <mailto:luis.f.correia@gmail.com>> wrote:
> >>> > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>> wrote:
> >>> > >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >>> > >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >>> > >> >> so all Code depending on that can't ever be selected and, if there's
> >>> > >> >> no plan to add these options, should be cleaned up
> >>> > >> >>
> >>> > >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>>
> >>> > >> >
> >>> > >> > NAK,
> >>> > >> >
> >>> > >> > this is not dead code, it is needed for the Ralink System-on-Chip
> >>> > >> > Platform devices.
> >>> > >> >
> >>> > >> > While I can't fix Kconfig errors and the current KConfig file may be
> >>> > >> > wrong, this code cannot and will not be deleted.
> >>> > >>
> >>> > >> When the config option was introduced, the config options RALINK_RT288X and
> >>> > >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
> >>> > >>
> >>> > >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> >>> > >> isn't dead but actually in use.
> >>> > >
> >>> > > Perhaps Helmut and Felix can send us the missing code?
> >>> > The missing code is a MIPS platform port, which is currently being
> >>> > maintained in OpenWrt, but is not ready for upstream submission yet.
> >>> > I'm not working on this code at the moment, but I think it will be
> >>> > submitted once it's ready.
> >>>
> >>> People are using automatic scripts to catch unused config options nowadays
> >>> so the issue is quite likely to come back again sooner or later..
> >>>
> >>> Would it be possible to improve situation somehow till the missing parts
> >>> get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
> >>> situation to Kconfig (if the config option itself really cannot be removed)
> >>> until all code is ready etc.?
> >>>
> >>>
> >>> Or we could just remove RT2800PCI_SOC completely and build the soc specific
> >>> parts always as part of rt2800pci. I mean it's not much code, just the platform
> >>> driver stuff and the eeprom access.
> >>>
> >>
> >> I'm not sure if that is feasible. Sure, we can reduce the usage of the variable by
> >> unconditionally compiling in the generic SOC code, but we should not unconditionally
> >> register the SOC platform device, which is currently also under the scope of this
> >> Kconfig variable.
> >
> > Ehm, no, the platform device is not registered in rt2800pci at all,
> > it's just the platform
> > driver that gets registered there. The platform device will be
> > registered in the according
> > board init code (that only resides in openwrt at the moment).
> >
>
> OK. Didn't know that. Sounds good then.
>
> However, I've tried this in my local tree, and now compilation fails on the x86 platform
> due to a missing KSEG1ADDR macro. How do you suggest to handle the potentially missing
> macro?
We can convert it to an ioremap call, that should be available on all platforms.
Helmut
^ permalink raw reply
* Re: what's the status of ATHEROS_AR71XX config variable?
From: Luis R. Rodriguez @ 2010-07-16 17:14 UTC (permalink / raw)
To: Felix Fietkau
Cc: Robert P. J. Day, linux-wireless, ath9k-devel, Gabor Juhos,
linux-mips
In-Reply-To: <4C403859.70201@openwrt.org>
On Fri, Jul 16, 2010 at 3:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-16 10:43 AM, Robert P. J. Day wrote:
>>
>> from drivers/net/wireless/ath/ath9k/Makefile:
>>
>> ath9k-$(CONFIG_ATHEROS_AR71XX) += ahb.o
>>
>> but there is no such config variable. so i'm thinking *something*
>> should be removed.
> The platform port for AR71xx hasn't been submitted upstream yet. But the
> code in ahb.c is actively being used in OpenWrt.
>
> I don't know what the status on submitting the code to linux-mips is,
> but I've Cc'd Gabor, he should know ;)
If its actively being supporting and tested, why not submit it now?
Any particular large pending blockers?
Luis
^ permalink raw reply
* Re: [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: Luis R. Rodriguez @ 2010-07-16 17:12 UTC (permalink / raw)
To: yogeshp
Cc: Pradeep Nemavat, Nishant Sarmukadam, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <4C402360.5050502@marvell.com>
On Fri, Jul 16, 2010 at 2:16 AM, yogeshp <yogeshp@marvell.com> wrote:
> Hi Luis,
> Please see inline comments
>
> Luis R. Rodriguez wrote:
>> On Thu, Jul 15, 2010 at 6:18 AM, yogeshp <yogeshp@marvell.com> wrote:
>>> BA window size for a successful BA setup is not made available to the driver by
>>> mac80211. The patch below gets the BA window size from addba response and
>>> indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
>
>> But why do you want that? Your patch and commit log do not mention why
>> you need this.
> BA window size from ADDBA response defines how many outstanding MPDUs are allowed for the BA stream by recipient. Since ADDBA response is processed in mac80211 stack, mac80211 should communicate the BA window size to driver (and may be from driver it is further communicated to firmware/hardware) to control the number of outstanding MPDUs while transmitting MPDUs for the stream.
What driver requires this? Your patch does all these changes but do
not show any secondary patch of a user, so the patch is pointless
right now.
>> When I compile mac80211 with your patch it fails compilation
> I do not see this compilation error, I think the patch did not apply cleanly. I will send out another patch without extra white spaces that should solve the compilation issue. If the change is fine, we can then send patches to fix the compilation issues for other drivers too.
>
..
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox