* [PATCH 1/2] ath9k: Fix inconsistency between txq->stopped and the actual queue state
From: Vasanthakumar Thiagarajan @ 2010-07-22 9:24 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Sometimes txq state(txq->stopped) can be marked as started but the actual
queue may not be started (in ATH_WIPHY_SCAN state, for example). Fix this.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/virtual.c | 6 +++++-
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 6e486a5..998ae2c 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -687,7 +687,7 @@ bool ath9k_all_wiphys_idle(struct ath_softc *sc);
void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle);
void ath_mac80211_stop_queue(struct ath_softc *sc, u16 skb_queue);
-void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue);
+bool ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue);
void ath_start_rfkill_poll(struct ath_softc *sc);
extern void ath9k_rfkill_poll_state(struct ieee80211_hw *hw);
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index 89423ca..fd20241 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -695,16 +695,18 @@ void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle)
idle ? "idle" : "not-idle");
}
/* Only bother starting a queue on an active virtual wiphy */
-void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
+bool ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
{
struct ieee80211_hw *hw = sc->pri_wiphy->hw;
unsigned int i;
+ bool txq_started = false;
spin_lock_bh(&sc->wiphy_lock);
/* Start the primary wiphy */
if (sc->pri_wiphy->state == ATH_WIPHY_ACTIVE) {
ieee80211_wake_queue(hw, skb_queue);
+ txq_started = true;
goto unlock;
}
@@ -718,11 +720,13 @@ void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
hw = aphy->hw;
ieee80211_wake_queue(hw, skb_queue);
+ txq_started = true;
break;
}
unlock:
spin_unlock_bh(&sc->wiphy_lock);
+ return txq_started;
}
/* Go ahead and propagate information to all virtual wiphys, it won't hurt */
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 0644f1e..21aa5bd 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2077,8 +2077,8 @@ static void ath_wake_mac80211_queue(struct ath_softc *sc, struct ath_txq *txq)
spin_lock_bh(&txq->axq_lock);
if (txq->stopped && sc->tx.pending_frames[qnum] < ATH_MAX_QDEPTH) {
- ath_mac80211_start_queue(sc, qnum);
- txq->stopped = 0;
+ if (ath_mac80211_start_queue(sc, qnum))
+ txq->stopped = 0;
}
spin_unlock_bh(&txq->axq_lock);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ath9k: Fix stop in tx date traffic after scan
From: Vasanthakumar Thiagarajan @ 2010-07-22 9:25 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, johannes
When moving off channel during background scanning, driver
can not clear IEEE80211_QUEUE_STOP_REASON_DRIVER which was
set earliar due to a shortage in tx buffer, this will lead
to a situation where no data frames will be passed down to
driver when the hw is put back into operating channel. This
patch make sure no txq is stopped after moving to operating
channel after scan. This issue is seen only when NM is used
and exposed by the following commit
Author: Felix Fietkau <nbd@openwrt.org>
Date: Tue Jun 1 21:33:13 2010 +0200
ath9k: fix queue stop/start based on the number of pending frames
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
This is not a clean fix for this issue, but best available
from driver. For a decent fix from driver, the following
changes in mac80211 may be required
1. Make ieee80211_wake_queue() callable when moving to off channel
also just to clear IEEE80211_QUEUE_STOP_REASON_DRIVER or
2. For drivers which does not support hw scan, add a way to
tell them if the hw is being configured into operating channel
(driver can detect this, but this would be a hack in driver)
so that the driver can wake up the stopped queues after the
hw is configured back to operating channel.
Johannes, if the above mac80211 changes make any sense, I'll send
a new set of patches to fix this problem.
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 6 ++++++
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 998ae2c..d8d8804 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -692,4 +692,5 @@ bool ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue);
void ath_start_rfkill_poll(struct ath_softc *sc);
extern void ath9k_rfkill_poll_state(struct ieee80211_hw *hw);
+void ath_wake_mac80211_queue(struct ath_softc *sc, struct ath_txq *txq);
#endif /* ATH9K_H */
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 6cf0410..7a0d633 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1491,6 +1491,7 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
struct ieee80211_conf *conf = &hw->conf;
struct ath_hw *ah = sc->sc_ah;
bool disable_radio;
+ int i;
mutex_lock(&sc->mutex);
@@ -1605,6 +1606,11 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
mutex_unlock(&sc->mutex);
return -EINVAL;
}
+
+ for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
+ if (ATH_TXQ_SETUP(sc, i))
+ ath_wake_mac80211_queue(sc, &sc->tx.txq[i]);
+ }
}
skip_chan_change:
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 21aa5bd..5bfec95 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2067,7 +2067,7 @@ static void ath_tx_rc_status(struct ath_buf *bf, struct ath_tx_status *ts,
tx_info->status.rates[tx_rateindex].count = ts->ts_longretry + 1;
}
-static void ath_wake_mac80211_queue(struct ath_softc *sc, struct ath_txq *txq)
+void ath_wake_mac80211_queue(struct ath_softc *sc, struct ath_txq *txq)
{
int qnum;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: Fix stop in tx date traffic after scan
From: Johannes Berg @ 2010-07-22 9:56 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1279790703-11521-1-git-send-email-vasanth@atheros.com>
On Thu, 2010-07-22 at 02:25 -0700, Vasanthakumar Thiagarajan wrote:
> When moving off channel during background scanning, driver
> can not clear IEEE80211_QUEUE_STOP_REASON_DRIVER which was
> set earliar due to a shortage in tx buffer, this will lead
> to a situation where no data frames will be passed down to
> driver when the hw is put back into operating channel. This
> patch make sure no txq is stopped after moving to operating
> channel after scan. This issue is seen only when NM is used
> and exposed by the following commit
>
> Author: Felix Fietkau <nbd@openwrt.org>
> Date: Tue Jun 1 21:33:13 2010 +0200
> ath9k: fix queue stop/start based on the number of pending frames
>
> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> ---
>
> This is not a clean fix for this issue, but best available
> from driver. For a decent fix from driver, the following
> changes in mac80211 may be required
>
> 1. Make ieee80211_wake_queue() callable when moving to off channel
> also just to clear IEEE80211_QUEUE_STOP_REASON_DRIVER or
>
> 2. For drivers which does not support hw scan, add a way to
> tell them if the hw is being configured into operating channel
> (driver can detect this, but this would be a hack in driver)
> so that the driver can wake up the stopped queues after the
> hw is configured back to operating channel.
>
> Johannes, if the above mac80211 changes make any sense, I'll send
> a new set of patches to fix this problem.
Really, that all doesn't make a whole lot of sense to me.
Just go and implement flush() and all these issues will go away and you
will stop thinking that you need to touch queues from channel switching.
They have nothing to do with each other.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Fix stop in tx date traffic after scan
From: Vasanthakumar Thiagarajan @ 2010-07-22 10:11 UTC (permalink / raw)
To: Johannes Berg
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1279792601.12439.1.camel@jlt3.sipsolutions.net>
> Just go and implement flush() and all these issues will go away and you
> will stop thinking that you need to touch queues from channel switching.
> They have nothing to do with each other.
I thought about it also, but i'll hit the same issue
when ieee80211_scan_state_leave_oper_channel() flushes
the hw tx queues where driver is not supposed to wake
up the queues as drv_flush() is called only after stopping
all queues.
Vasanth
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Fix stop in tx date traffic after scan
From: Johannes Berg @ 2010-07-22 10:14 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <20100722101142.GA4355@vasanth-laptop>
On Thu, 2010-07-22 at 15:41 +0530, Vasanthakumar Thiagarajan wrote:
> > Just go and implement flush() and all these issues will go away and you
> > will stop thinking that you need to touch queues from channel switching.
> > They have nothing to do with each other.
>
>
> I thought about it also, but i'll hit the same issue
> when ieee80211_scan_state_leave_oper_channel() flushes
> the hw tx queues where driver is not supposed to wake
> up the queues as drv_flush() is called only after stopping
> all queues.
I don't get it. The driver can start/stop queues at _any_ time it wants
to. Regardless of what mac80211 is doing, all that goes via
IEEE80211_QUEUE_STOP_REASON_DRIVER which is never touched by mac80211
itself.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Fix stop in tx date traffic after scan
From: Vasanthakumar Thiagarajan @ 2010-07-22 10:20 UTC (permalink / raw)
To: Johannes Berg
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1279793694.12439.4.camel@jlt3.sipsolutions.net>
On Thu, Jul 22, 2010 at 03:44:54PM +0530, Johannes Berg wrote:
> On Thu, 2010-07-22 at 15:41 +0530, Vasanthakumar Thiagarajan wrote:
> > > Just go and implement flush() and all these issues will go away and you
> > > will stop thinking that you need to touch queues from channel switching.
> > > They have nothing to do with each other.
> >
> >
> > I thought about it also, but i'll hit the same issue
> > when ieee80211_scan_state_leave_oper_channel() flushes
> > the hw tx queues where driver is not supposed to wake
> > up the queues as drv_flush() is called only after stopping
> > all queues.
>
> I don't get it. The driver can start/stop queues at _any_ time it wants
> to. Regardless of what mac80211 is doing, all that goes via
> IEEE80211_QUEUE_STOP_REASON_DRIVER which is never touched by mac80211
> itself.
My understanding is, if driver wakes up the queues when operating on
a off-channel, it would get data frames from upper layer for
transmission but it should not send out these frames as the hw is on
non-operating channel.
Vasanth
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Fix stop in tx date traffic after scan
From: Johannes Berg @ 2010-07-22 10:32 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <20100722102049.GB4355@vasanth-laptop>
On Thu, 2010-07-22 at 15:50 +0530, Vasanthakumar Thiagarajan wrote:
> On Thu, Jul 22, 2010 at 03:44:54PM +0530, Johannes Berg wrote:
> > On Thu, 2010-07-22 at 15:41 +0530, Vasanthakumar Thiagarajan wrote:
> > > > Just go and implement flush() and all these issues will go away and you
> > > > will stop thinking that you need to touch queues from channel switching.
> > > > They have nothing to do with each other.
> > >
> > >
> > > I thought about it also, but i'll hit the same issue
> > > when ieee80211_scan_state_leave_oper_channel() flushes
> > > the hw tx queues where driver is not supposed to wake
> > > up the queues as drv_flush() is called only after stopping
> > > all queues.
> >
> > I don't get it. The driver can start/stop queues at _any_ time it wants
> > to. Regardless of what mac80211 is doing, all that goes via
> > IEEE80211_QUEUE_STOP_REASON_DRIVER which is never touched by mac80211
> > itself.
>
> My understanding is, if driver wakes up the queues when operating on
> a off-channel, it would get data frames from upper layer for
> transmission but it should not send out these frames as the hw is on
> non-operating channel.
Ok, that seems to be true, but only because we don't properly manage the
interface queue stop in mac80211. Should be an easy fix there.
johannes
^ permalink raw reply
* Re: [patch -next] ath5k: snprintf() returns largish values
From: Dan Carpenter @ 2010-07-22 10:44 UTC (permalink / raw)
To: Jiri Slaby
Cc: Luis R. Rodriguez, Nick Kossifidis, Bob Copeland,
John W. Linville, Bruno Randolf, linux-wireless, ath5k-devel,
kernel-janitors
In-Reply-To: <4C4807AD.5090302@gmail.com>
On Thu, Jul 22, 2010 at 10:56:13AM +0200, Jiri Slaby wrote:
> On 07/22/2010 10:52 AM, Dan Carpenter wrote:
> > snprintf() returns the number of characters that would have been written
> > (not counting the NUL character). So we can't use it as the limiter to
> > simple_read_from_buffer() without capping it first at sizeof(buf).
>
> Doesn't scnprintf make more sense here?
>
Not really... It's nice to pass a negative number as the buffer size to
snprintf() instead of having to make that a special case.
regards,
dan carpenter
> thanks,
> --
> js
^ permalink raw reply
* potential null deref in minstrel_ht_update_caps()?
From: Dan Carpenter @ 2010-07-22 11:09 UTC (permalink / raw)
To: nbd; +Cc: linux-wireless
This is a smatch thing.
net/mac80211/rc80211_minstrel_ht.c +639 minstrel_ht_update_caps(15)
warn: variable dereferenced before check 'sta'
631 struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
632 struct ieee80211_local *local = hw_to_local(mp->hw);
633 u16 sta_cap = sta->ht_cap.cap;
^^^^^^^^^^^^^^^
Dereferenced here.
634 int ack_dur;
635 int stbc;
636 int i;
637
638 /* fall back to the old minstrel for legacy stations */
639 if (sta && !sta->ht_cap.ht_supported) {
^^^
Checked here.
640 msp->is_ht = false;
641 memset(&msp->legacy, 0, sizeof(msp->legacy));
It seems like a bug, but I'm not sure how to deal with it.
regards,
dan carpenter
^ permalink raw reply
* [patch net-next] mac80211: freeing the wrong variable
From: Dan Carpenter @ 2010-07-22 11:14 UTC (permalink / raw)
To: Felix Fietkau
Cc: Johannes Berg, David S. Miller, John W. Linville, Ming Lei,
linux-wireless, kernel-janitors
The intent was to free "msp->ratelist" here. "msp->sample_table" is
always NULL at this point.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index b5ace24..0ec0584 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -748,7 +748,7 @@ minstrel_ht_alloc_sta(void *priv, struct ieee80211_sta *sta, gfp_t gfp)
return msp;
error1:
- kfree(msp->sample_table);
+ kfree(msp->ratelist);
error:
kfree(msp);
return NULL;
^ permalink raw reply related
* Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
From: Roger Quadros @ 2010-07-22 11:16 UTC (permalink / raw)
To: ext Mark Brown
Cc: Ohad Ben-Cohen, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org, Kalle Valo,
Pandita Vikram, linux@arm.linux.org.uk, Nicolas Pitre,
Tony Lindgren, San Mehat, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20100721175930.GD10930@sirena.org.uk>
On 07/21/2010 08:59 PM, ext Mark Brown wrote:
> On Wed, Jul 21, 2010 at 08:33:44PM +0300, Ohad Ben-Cohen wrote:
>
>> +static struct regulator_consumer_supply zoom_vmmc3_supply = {
>> + .supply = "vmmc",
>> +};
>
> This looks like a misconfiguration on the consumer - I'd strongly expect
> the consumer to have a dev_name specified also with the name being in
> terms of the consumer device.
you need to add something like
.dev_name = "mmci-omap-hs.2"
regards,
-roger
^ permalink raw reply
* [patch -next] wireless: remove unneeded variable from regulatory_hint_11d()
From: Dan Carpenter @ 2010-07-22 11:26 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, David S. Miller, Luis R. Rodriguez,
Benoit PAPILLAULT, linux-wireless, kernel-janitors
The "rd" variable isn't needed any more since 4f366c5dabcb
"wireless: only use alpha2 regulatory information from country IE"
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 48baf28..ec4e76f 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1492,7 +1492,6 @@ void regulatory_hint_11d(struct wiphy *wiphy,
u8 *country_ie,
u8 country_ie_len)
{
- struct ieee80211_regdomain *rd = NULL;
char alpha2[2];
enum environment_cap env = ENVIRON_ANY;
struct regulatory_request *request;
@@ -1529,7 +1528,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
if (!request)
- goto free_rd_out;
+ goto out;
request->wiphy_idx = get_wiphy_idx(wiphy);
request->alpha2[0] = alpha2[0];
@@ -1543,8 +1542,6 @@ void regulatory_hint_11d(struct wiphy *wiphy,
return;
-free_rd_out:
- kfree(rd);
out:
mutex_unlock(®_mutex);
}
^ permalink raw reply related
* Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
From: Roger Quadros @ 2010-07-22 11:35 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Tony Lindgren, Nicolas Pitre, Pandita Vikram,
Kalle Valo
In-Reply-To: <1279733634-21974-19-git-send-email-ohad@wizery.com>
On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote:
> Add support for an SDIO device to stay powered off even without
> the presence of an SDIO function driver. A host should explicitly
> ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO
> function driver should know it needs to call sdio_claim_power
> before accessing the device.
>
> Signed-off-by: Ohad Ben-Cohen<ohad@wizery.com>
Shouldn't this be the default behaviour? If there is no function driver for any
of the functions of the card, then sdio core shold power off the card.
I don't see a need for a special capability flag for this.
in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability
flag, it seems more like a request from the board to keep the card powered off.
regards,
-roger
^ permalink raw reply
* [PATCH] mac80211: remove bogus rcu_read_lock()
From: Johannes Berg @ 2010-07-22 11:58 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Another remnant of the previous key locking scheme
needs to be removed -- this causes a warning
otherwise as ieee80211_set_default_mgmt_key will
acquire a mutex.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/cfg.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- wireless-testing.orig/net/mac80211/cfg.c 2010-07-22 12:24:38.000000000 +0200
+++ wireless-testing/net/mac80211/cfg.c 2010-07-22 13:56:19.000000000 +0200
@@ -324,15 +324,10 @@ static int ieee80211_config_default_mgmt
struct net_device *dev,
u8 key_idx)
{
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- rcu_read_lock();
-
- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
ieee80211_set_default_mgmt_key(sdata, key_idx);
- rcu_read_unlock();
-
return 0;
}
^ permalink raw reply
* [PATCH] cfg80211: fix IBSS default management key
From: Johannes Berg @ 2010-07-22 11:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
When wireless extensions are used to control
an encrypted IBSS, we erroneously can try to
set the default management key. Fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/ibss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- wireless-testing.orig/net/wireless/ibss.c 2010-07-22 12:28:15.000000000 +0200
+++ wireless-testing/net/wireless/ibss.c 2010-07-22 12:28:27.000000000 +0200
@@ -247,8 +247,10 @@ int cfg80211_ibss_wext_join(struct cfg80
if (!netif_running(wdev->netdev))
return 0;
- if (wdev->wext.keys)
+ if (wdev->wext.keys) {
wdev->wext.keys->def = wdev->wext.default_key;
+ wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
+ }
wdev->wext.ibss.privacy = wdev->wext.default_key != -1;
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Bob Copeland @ 2010-07-22 12:04 UTC (permalink / raw)
To: Kalle Valo
Cc: Luciano Coelho, ext John W. Linville,
linux-wireless@vger.kernel.org
In-Reply-To: <4C47F706.4060102@iki.fi>
On Thu, Jul 22, 2010 at 3:45 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
>>> @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
>>> if (control->control.hw_key &&
>>> control->control.hw_key->alg == ALG_TKIP) {
>>> int hdrlen;
>>> - u16 fc;
>>> + __le16 fc;
>>> + u16 length;
>>> u8 *pos;
[...]
>>> + length = le16_to_cpu(tx_hdr->length) + WL1251_TKIP_IV_SPACE;
>>> + tx_hdr->length = cpu_to_le16(length);
>>
>> ...which is treated correctly here.
>
> This is different. Here we are adding something to a __le16 value, not
> calculating with pointers.
Just throwing in my 2 cents, unless there's some other reason to add the
length temporary, here you can just do:
le16_add_cpu(&tx_hdr->length, WL1251_TKIP_IV_SPACE);
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [patch -next] libertas: precedence bug
From: Dan Carpenter @ 2010-07-22 12:21 UTC (permalink / raw)
To: Dan Williams
Cc: John W. Linville, Holger Schurig, David S. Miller,
Amitkumar Karwar, Stephen Hemminger, libertas-dev, linux-wireless,
kernel-janitors
Negate has precedence over comparison so the original test was always
false. (Neither 0 nor 1 are equal to NL80211_IFTYPE_MONITOR).
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/libertas/tx.c b/drivers/net/wireless/libertas/tx.c
index 411a3bb..8000ca6 100644
--- a/drivers/net/wireless/libertas/tx.c
+++ b/drivers/net/wireless/libertas/tx.c
@@ -180,7 +180,7 @@ void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count)
{
struct tx_radiotap_hdr *radiotap_hdr;
- if (!priv->wdev->iftype == NL80211_IFTYPE_MONITOR ||
+ if (priv->wdev->iftype != NL80211_IFTYPE_MONITOR ||
priv->currenttxskb == NULL)
return;
^ permalink raw reply related
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Johannes Berg @ 2010-07-22 12:34 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: ilw, linux-wireless
In-Reply-To: <20100721184040.GA22968@comet.dominikbrodowski.net>
Hi,
> [82970.511341] ------------[ cut here ]------------
> [82970.511365] WARNING: at net/mac80211/scan.c:262 ieee80211_scan_completed+0x137/0x1d0()
You don't happen to have a way of reproducing this? I have been
suspecting races in this area, and came up with this patch to fix them,
but haven't really validated it yet:
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-hw-scan-locking.patch
johannes
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: John W. Linville @ 2010-07-22 13:21 UTC (permalink / raw)
To: Kalle Valo; +Cc: Luciano Coelho, linux-wireless@vger.kernel.org
In-Reply-To: <4C47F706.4060102@iki.fi>
On Thu, Jul 22, 2010 at 09:45:10AM +0200, Kalle Valo wrote:
> On 07/22/2010 08:34 AM, Luciano Coelho wrote:
> >> @@ -467,7 +467,7 @@ static int wl1251_boot_upload_nvs(struct wl1251 *wl)
> >> val = (nvs_ptr[0] | (nvs_ptr[1] << 8)
> >> | (nvs_ptr[2] << 16) | (nvs_ptr[3] << 24));
> >>
> >> - val = cpu_to_le32(val);
> >> + val = (u32 __force) cpu_to_le32(val);
> >
> > This will work, but such casts always make me a bit suspicious. I think
> > this is fine for now
>
> This line was very suspicious already from beginning, I can't remember
> why it was added and I don't see why it's needed here.
It certainly is a bit strange, and rather ugly as well. I agree that
the write should probably just take the le32 instead, but I was more
interested in silencing sparse than in rewriting a driver for which
I have not hardware. :-)
I could drop that hunk for the time being?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: John W. Linville @ 2010-07-22 13:16 UTC (permalink / raw)
To: Bob Copeland; +Cc: Kalle Valo, Luciano Coelho, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimh-2cuWdJKgf2TUkCQmGXDC0-86xVhbA-kiPGR@mail.gmail.com>
On Thu, Jul 22, 2010 at 08:04:02AM -0400, Bob Copeland wrote:
> On Thu, Jul 22, 2010 at 3:45 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> >>> @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
> >>> if (control->control.hw_key &&
> >>> control->control.hw_key->alg == ALG_TKIP) {
> >>> int hdrlen;
> >>> - u16 fc;
> >>> + __le16 fc;
> >>> + u16 length;
> >>> u8 *pos;
> [...]
> >>> + length = le16_to_cpu(tx_hdr->length) + WL1251_TKIP_IV_SPACE;
> >>> + tx_hdr->length = cpu_to_le16(length);
> >>
> >> ...which is treated correctly here.
> >
> > This is different. Here we are adding something to a __le16 value, not
> > calculating with pointers.
>
> Just throwing in my 2 cents, unless there's some other reason to add the
> length temporary, here you can just do:
>
> le16_add_cpu(&tx_hdr->length, WL1251_TKIP_IV_SPACE);
Ah, thanks! I thought there was something like that, but I couldn't remember. :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Dominik Brodowski @ 2010-07-22 13:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: ilw, linux-wireless
In-Reply-To: <1279802055.12439.16.camel@jlt3.sipsolutions.net>
>
> > [82970.511341] ------------[ cut here ]------------
> > [82970.511365] WARNING: at net/mac80211/scan.c:262 ieee80211_scan_completed+0x137/0x1d0()
>
> You don't happen to have a way of reproducing this? I have been
> suspecting races in this area, and came up with this patch to fix them,
No, but as it happened again today, I would be willing to test it out.
> but haven't really validated it yet:
>
> http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-hw-scan-locking.patch
patching file drivers/net/wireless/iwlwifi/iwl-core.c
Hunk #1 succeeded at 2103 (offset 102 lines).
Hunk #2 FAILED at 2015.
Hunk #3 succeeded at 2120 (offset 97 lines).
1 out of 3 hunks FAILED -- saving rejects to file
drivers/net/wireless/iwlwifi/iwl-core.c.rej
:(
Best,
Dominik
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Johannes Berg @ 2010-07-22 14:07 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: ilw, linux-wireless
In-Reply-To: <20100722134048.GA28231@isilmar-3.linta.de>
On Thu, 2010-07-22 at 15:40 +0200, Dominik Brodowski wrote:
> > http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-hw-scan-locking.patch
>
> patching file drivers/net/wireless/iwlwifi/iwl-core.c
> Hunk #1 succeeded at 2103 (offset 102 lines).
> Hunk #2 FAILED at 2015.
> Hunk #3 succeeded at 2120 (offset 97 lines).
> 1 out of 3 hunks FAILED -- saving rejects to file
> drivers/net/wireless/iwlwifi/iwl-core.c.rej
Oh, it's against wireless-testing, which apparently has some other mods
there. I'll have to see if any other patch needs to go into .35 too.
johannes
^ permalink raw reply
* Re: minstrel_tx_status mac80211 WARNINGs in vanilla 2.6.34.1
From: John W. Linville @ 2010-07-22 14:47 UTC (permalink / raw)
To: Sven Geggus; +Cc: netdev, linux-wireless, nbd
In-Reply-To: <20100722123000.GA16657@geggus.net>
On Thu, Jul 22, 2010 at 02:30:01PM +0200, Sven Geggus wrote:
> Hello,
>
> running vanilla 2.6.34.1 I get the following warnings in kernel log:
>
> WARNING: at net/mac80211/rc80211_minstrel.c:70 minstrel_tx_status+0x67/0xd1 [mac80211]()
> Hardware name: SCENIC E300/E600
> Modules linked in: i915 drm_kms_helper drm video backlight output lp loop
> snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
> snd_seq_dummy zd1211rw snd_seq_oss usbhid mac80211 option cfg80211
> snd_seq_midi usbserial snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> snd_seq_device snd parport_pc ehci_hcd uhci_hcd soundcore intel_agp parport
> usbcore nls_base snd_page_alloc agpgart rng_core floppy sg
> Pid: 0, comm: swapper Tainted: G W 2.6.34.1 #3
> Call Trace:
> [<c102af25>] warn_slowpath_common+0x60/0x90
> [<c102af62>] warn_slowpath_null+0xd/0x10
> [<f83cbd48>] minstrel_tx_status+0x67/0xd1 [mac80211]
> [<f83b6eb1>] ieee80211_tx_status+0x1f6/0x5ac [mac80211]
> [<c1261533>] ? skb_dequeue+0x45/0x4c
> [<f83b6896>] ieee80211_tasklet_handler+0x61/0xd6 [mac80211]
> [<c102ed7d>] tasklet_action+0x62/0x9f
> [<c102f331>] __do_softirq+0x77/0xe5
> [<c102f3c5>] do_softirq+0x26/0x2b
> [<c102f52f>] irq_exit+0x29/0x66
> [<c1003e90>] do_IRQ+0x85/0x9b
> [<c1002d29>] common_interrupt+0x29/0x30
> [<c10083ac>] ? default_idle+0x2d/0x42
> [<c1001a9b>] cpu_idle+0x44/0x71
> [<c12e00de>] rest_init+0x96/0x98
> [<c1498862>] start_kernel+0x2a5/0x2aa
> [<c14980b7>] i386_start_kernel+0xb7/0xbf
> ---[ end trace f22ceacef336878f ]---
>
> Wireless driver is zd1211rw.
>
> Did not test with older kernel because this device has not been in user on
> this machine before.
>
> WLAN does however seem to work anyway.
Well, I just took a quick look -- so, I'm not 100% sure...
But, it looks to me like zd1211rw is reporting tx status on a rate
that minstrel didn't expect it to use. It seems like the hardware
is pre-wired to do retries on sequentially lower rates, which seems
a bit incompatible with minstrel's worldview.
Felix, can we accomodate this? The "WLAN does however seem to work
anyway" seems to suggest things work, so can we at least not yell
about it?
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] mac80211: fix sta assignment
From: Johannes Berg @ 2010-07-22 15:11 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
I just had the following:
WARNING: at drivers/net/wireless/iwlwifi/iwl-agn-tx.c:574 iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]()
Call Trace:
<IRQ> [<ffffffff8105c5df>] warn_slowpath_common+0x7f/0xc0
[<ffffffff8105c63a>] warn_slowpath_null+0x1a/0x20
[<ffffffffa0290b46>] iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]
[<ffffffffa027076c>] iwl_mac_tx+0x5c/0x260 [iwlagn]
[<ffffffffa01bdf5b>] __ieee80211_tx+0x10b/0x1a0 [mac80211]
[<ffffffffa01bfb86>] ieee80211_tx_pending+0x186/0x2d0 [mac80211]
[<ffffffff81062ea5>] tasklet_action+0x125/0x130
[<ffffffff810634a6>] __do_softirq+0x106/0x270
[<ffffffff8100c09c>] call_softirq+0x1c/0x30
iwlagn 0000:02:00.0: Attempting to modify non-existing station 107
Note that 107 == 0x6b which is slab poison.
The reason is that mac80211 passed a freed station
pointer to mac80211, because as it happened iwlwifi
reset itself while mac80211 was disconnecting from
the network.
It turns out that we do take care to look up the
station pointer in ieee80211_tx_pending_skb, but
then don't use it, which obviously is a bug. Fix
this by removing the ieee80211_tx_h_sta handler
and assigning the station pointer directly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/tx.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
--- wireless-testing.orig/net/mac80211/tx.c 2010-07-22 16:55:47.000000000 +0200
+++ wireless-testing/net/mac80211/tx.c 2010-07-22 16:59:49.000000000 +0200
@@ -576,17 +576,6 @@ ieee80211_tx_h_select_key(struct ieee802
}
static ieee80211_tx_result debug_noinline
-ieee80211_tx_h_sta(struct ieee80211_tx_data *tx)
-{
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
-
- if (tx->sta && tx->sta->uploaded)
- info->control.sta = &tx->sta->sta;
-
- return TX_CONTINUE;
-}
-
-static ieee80211_tx_result debug_noinline
ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
@@ -1307,6 +1296,11 @@ static int __ieee80211_tx(struct ieee802
break;
}
+ if (sta && sta->uploaded)
+ info->control.sta = &sta->sta;
+ else
+ info->control.sta = NULL;
+
ret = drv_tx(local, skb);
if (WARN_ON(ret != NETDEV_TX_OK && skb->len != len)) {
dev_kfree_skb(skb);
@@ -1346,7 +1340,6 @@ static int invoke_tx_handlers(struct iee
CALL_TXH(ieee80211_tx_h_check_assoc);
CALL_TXH(ieee80211_tx_h_ps_buf);
CALL_TXH(ieee80211_tx_h_select_key);
- CALL_TXH(ieee80211_tx_h_sta);
if (!(tx->local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL))
CALL_TXH(ieee80211_tx_h_rate_ctrl);
^ permalink raw reply
* Re: wl1271 firmware
From: Pazzo Da Legare @ 2010-07-22 15:41 UTC (permalink / raw)
To: Luciano Coelho
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <1279780848.2322.31.camel@powerslave>
Dear Luciano,
Dear All,
I enabled the DEBUG_LEVEL as you advice me but I have no additional
information....
[ 186.230000] wl1271_sdio mmc0:0001:2: firmware: requesting
wl1271-fw.bin
[ 186.420000] wl1271_sdio mmc0:0001:2: firmware: requesting
wl1271-nvs.bin
[ 186.860000] wl1271: firmware booted (Rev 6.1.0.0.310)
[ 186.880000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 187.380000] wl1271: ERROR ELP wakeup timeout!
[ 187.880000] wl1271: ERROR ELP wakeup timeout!
Pazzo
2010/7/22 Luciano Coelho <luciano.coelho@nokia.com>:
> Hi Pazzo,
>
>
> On Wed, 2010-07-21 at 19:27 +0200, ext Pazzo Da Legare wrote:
>> Dear All again,
>>
>> I've just test with compact-wireless-2010-07-20 but I've the same problem:
>>
>> root@hawkboard:~# ifconfig wlan0 192.168.0.1 up
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> root@hawkboard:~# [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>>
>> looking at dmesg:
>>
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>> Do you have any clue?
>
> I'm not sure what this is, but usually an ERROR ELP wakeup timeout means
> that the firmware has crashed.
>
> Could you enable the following DEBUG flags in wl1271.h and send the logs
> again? Maybe they provide more clues...
>
> #define DEBUG_LEVEL (DEBUG_BOOT | DEBUG_ACX | DEBUG_CMD | DEBUG_PSM | \
> DEBUG_IRQ | DEBUG_EVENT)
>
>
> --
> Cheers,
> Luca.
>
>
^ 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