* [PATCH 03/21] iwlwifi: correct atomic bitops usage
From: Reinette Chatre @ 2010-04-16 21:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Johannes Berg, Reinette Chatre
In-Reply-To: <1271454758-14351-1-git-send-email-reinette.chatre@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
With atomic bitops, test_and_{set,clear}_bit
should be used instead of separate test_bit
and set_bit/clear_bit.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-scan.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index 3904bb4..7982b19 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -68,9 +68,8 @@ int iwl_scan_cancel(struct iwl_priv *priv)
}
if (test_bit(STATUS_SCANNING, &priv->status)) {
- if (!test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
+ if (!test_and_set_bit(STATUS_SCAN_ABORTING, &priv->status)) {
IWL_DEBUG_SCAN(priv, "Queuing scan abort.\n");
- set_bit(STATUS_SCAN_ABORTING, &priv->status);
queue_work(priv->workqueue, &priv->abort_scan);
} else
@@ -227,13 +226,13 @@ static void iwl_rx_scan_complete_notif(struct iwl_priv *priv,
jiffies_to_msecs(elapsed_jiffies
(priv->scan_pass_start, jiffies)));
- /* If a request to abort was given, or the scan did not succeed
+ /*
+ * If a request to abort was given, or the scan did not succeed
* then we reset the scan state machine and terminate,
- * re-queuing another scan if one has been requested */
- if (test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
+ * re-queuing another scan if one has been requested
+ */
+ if (test_and_clear_bit(STATUS_SCAN_ABORTING, &priv->status))
IWL_DEBUG_INFO(priv, "Aborted scan completed.\n");
- clear_bit(STATUS_SCAN_ABORTING, &priv->status);
- }
if (!priv->is_internal_short_scan)
priv->next_scan_jiffies = 0;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 01/21] iwlwifi: set correct single/dual stream mask
From: Reinette Chatre @ 2010-04-16 21:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1271454758-14351-1-git-send-email-reinette.chatre@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Even the initial single/dual stream values will be overridden later when
issue link quality command; but still make sense not to use hard-code
value during initialization. Single/Dual stream mask are used to indicate the
best antenna for SISO/MIMO; different NIC has different tx antenna
configuration; so the parameter need to based on the valid tx antenna.
1x2 device: single tx antenna available, only SISO is valid
configuration, but still need to set up MIMO configuration, so set it up
with antenna A & B as default.
2x2 device: two tx antenna available, dual_stream will use both valid
antenna.
3x3 device: three tx antenna available, skip the first antenna and
choice the second and third antenna for dual_stream.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 13 +++++++++++--
drivers/net/wireless/iwlwifi/iwl-sta.c | 12 +++++++++++-
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 3c1cd41..5bc406c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2557,8 +2557,17 @@ void iwl_rs_rate_init(struct iwl_priv *priv, struct ieee80211_sta *sta, u8 sta_i
lq_sta->active_mimo3_rate);
/* These values will be overridden later */
- lq_sta->lq.general_params.single_stream_ant_msk = ANT_A;
- lq_sta->lq.general_params.dual_stream_ant_msk = ANT_AB;
+ lq_sta->lq.general_params.single_stream_ant_msk =
+ first_antenna(priv->hw_params.valid_tx_ant);
+ lq_sta->lq.general_params.dual_stream_ant_msk =
+ priv->hw_params.valid_tx_ant &
+ ~first_antenna(priv->hw_params.valid_tx_ant);
+ if (!lq_sta->lq.general_params.dual_stream_ant_msk) {
+ lq_sta->lq.general_params.dual_stream_ant_msk = ANT_AB;
+ } else if (num_of_ant(priv->hw_params.valid_tx_ant) == 2) {
+ lq_sta->lq.general_params.dual_stream_ant_msk =
+ priv->hw_params.valid_tx_ant;
+ }
/* as default allow aggregation for all tids */
lq_sta->tx_agg_tid_en = IWL_AGG_ALL_TID;
diff --git a/drivers/net/wireless/iwlwifi/iwl-sta.c b/drivers/net/wireless/iwlwifi/iwl-sta.c
index d86ecd2..09d9c4d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-sta.c
+++ b/drivers/net/wireless/iwlwifi/iwl-sta.c
@@ -451,7 +451,17 @@ static void iwl_sta_init_lq(struct iwl_priv *priv, const u8 *addr, bool is_ap)
link_cmd.general_params.single_stream_ant_msk =
first_antenna(priv->hw_params.valid_tx_ant);
- link_cmd.general_params.dual_stream_ant_msk = 3;
+
+ link_cmd.general_params.dual_stream_ant_msk =
+ priv->hw_params.valid_tx_ant &
+ ~first_antenna(priv->hw_params.valid_tx_ant);
+ if (!link_cmd.general_params.dual_stream_ant_msk) {
+ link_cmd.general_params.dual_stream_ant_msk = ANT_AB;
+ } else if (num_of_ant(priv->hw_params.valid_tx_ant) == 2) {
+ link_cmd.general_params.dual_stream_ant_msk =
+ priv->hw_params.valid_tx_ant;
+ }
+
link_cmd.agg_params.agg_dis_start_th = LINK_QUAL_AGG_DISABLE_START_DEF;
link_cmd.agg_params.agg_time_limit =
cpu_to_le16(LINK_QUAL_AGG_TIME_LIMIT_DEF);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 02/21] iwlwifi: remove scan_bands logic
From: Reinette Chatre @ 2010-04-16 21:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Johannes Berg, Reinette Chatre
In-Reply-To: <1271454758-14351-1-git-send-email-reinette.chatre@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
Since mac80211 will now never request scanning
multiple bands, we can remove all the associated
logic and scan a single band only in each scan.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-dev.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 59 ++++++++-------------------
drivers/net/wireless/iwlwifi/iwl3945-base.c | 16 +++----
3 files changed, 25 insertions(+), 52 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index b2d94c7..ee4cb02 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -1054,7 +1054,7 @@ struct iwl_priv {
unsigned long scan_pass_start;
unsigned long scan_start_tsf;
void *scan;
- int scan_bands;
+ enum ieee80211_band scan_band;
struct cfg80211_scan_request *scan_request;
bool is_internal_short_scan;
u8 scan_tx_ant[IEEE80211_NUM_BANDS];
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index c3b06c4..3904bb4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -223,29 +223,16 @@ static void iwl_rx_scan_complete_notif(struct iwl_priv *priv,
clear_bit(STATUS_SCAN_HW, &priv->status);
IWL_DEBUG_INFO(priv, "Scan pass on %sGHz took %dms\n",
- (priv->scan_bands & BIT(IEEE80211_BAND_2GHZ)) ?
- "2.4" : "5.2",
+ (priv->scan_band == IEEE80211_BAND_2GHZ) ? "2.4" : "5.2",
jiffies_to_msecs(elapsed_jiffies
(priv->scan_pass_start, jiffies)));
- /* Remove this scanned band from the list of pending
- * bands to scan, band G precedes A in order of scanning
- * as seen in iwl_bg_request_scan */
- if (priv->scan_bands & BIT(IEEE80211_BAND_2GHZ))
- priv->scan_bands &= ~BIT(IEEE80211_BAND_2GHZ);
- else if (priv->scan_bands & BIT(IEEE80211_BAND_5GHZ))
- priv->scan_bands &= ~BIT(IEEE80211_BAND_5GHZ);
-
/* If a request to abort was given, or the scan did not succeed
* then we reset the scan state machine and terminate,
* re-queuing another scan if one has been requested */
if (test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
IWL_DEBUG_INFO(priv, "Aborted scan completed.\n");
clear_bit(STATUS_SCAN_ABORTING, &priv->status);
- } else {
- /* If there are more bands on this scan pass reschedule */
- if (priv->scan_bands)
- goto reschedule;
}
if (!priv->is_internal_short_scan)
@@ -259,12 +246,6 @@ static void iwl_rx_scan_complete_notif(struct iwl_priv *priv,
jiffies_to_msecs(elapsed_jiffies(priv->scan_start, jiffies)));
queue_work(priv->workqueue, &priv->scan_completed);
-
- return;
-
-reschedule:
- priv->scan_pass_start = jiffies;
- queue_work(priv->workqueue, &priv->request_scan);
}
void iwl_setup_rx_scan_handlers(struct iwl_priv *priv)
@@ -489,10 +470,13 @@ int iwl_mac_hw_scan(struct ieee80211_hw *hw,
{
unsigned long flags;
struct iwl_priv *priv = hw->priv;
- int ret, i;
+ int ret;
IWL_DEBUG_MAC80211(priv, "enter\n");
+ if (req->n_channels == 0)
+ return -EINVAL;
+
mutex_lock(&priv->mutex);
spin_lock_irqsave(&priv->lock, flags);
@@ -526,10 +510,8 @@ int iwl_mac_hw_scan(struct ieee80211_hw *hw,
goto out_unlock;
}
- priv->scan_bands = 0;
- for (i = 0; i < req->n_channels; i++)
- priv->scan_bands |= BIT(req->channels[i]->band);
-
+ /* mac80211 will only ask for one band at a time */
+ priv->scan_band = req->channels[0]->band;
priv->scan_request = req;
ret = iwl_scan_initiate(priv);
@@ -575,11 +557,7 @@ static void iwl_bg_start_internal_scan(struct work_struct *work)
goto unlock;
}
- priv->scan_bands = 0;
- if (priv->band == IEEE80211_BAND_5GHZ)
- priv->scan_bands |= BIT(IEEE80211_BAND_5GHZ);
- else
- priv->scan_bands |= BIT(IEEE80211_BAND_2GHZ);
+ priv->scan_band = priv->band;
IWL_DEBUG_SCAN(priv, "Start internal short scan...\n");
set_bit(STATUS_SCANNING, &priv->status);
@@ -727,11 +705,6 @@ static void iwl_bg_request_scan(struct work_struct *data)
goto done;
}
- if (!priv->scan_bands) {
- IWL_DEBUG_HC(priv, "Aborting scan due to no requested bands\n");
- goto done;
- }
-
if (!priv->scan) {
priv->scan = kmalloc(sizeof(struct iwl_scan_cmd) +
IWL_MAX_SCAN_SIZE, GFP_KERNEL);
@@ -798,9 +771,8 @@ static void iwl_bg_request_scan(struct work_struct *data)
scan->tx_cmd.sta_id = priv->hw_params.bcast_sta_id;
scan->tx_cmd.stop_time.life_time = TX_CMD_LIFE_TIME_INFINITE;
-
- if (priv->scan_bands & BIT(IEEE80211_BAND_2GHZ)) {
- band = IEEE80211_BAND_2GHZ;
+ switch (priv->scan_band) {
+ case IEEE80211_BAND_2GHZ:
scan->flags = RXON_FLG_BAND_24G_MSK | RXON_FLG_AUTO_DETECT_MSK;
chan_mod = le32_to_cpu(priv->active_rxon.flags & RXON_FLG_CHANNEL_MODE_MSK)
>> RXON_FLG_CHANNEL_MODE_POS;
@@ -811,8 +783,8 @@ static void iwl_bg_request_scan(struct work_struct *data)
rate_flags = RATE_MCS_CCK_MSK;
}
scan->good_CRC_th = 0;
- } else if (priv->scan_bands & BIT(IEEE80211_BAND_5GHZ)) {
- band = IEEE80211_BAND_5GHZ;
+ break;
+ case IEEE80211_BAND_5GHZ:
rate = IWL_RATE_6M_PLCP;
/*
* If active scaning is requested but a certain channel
@@ -827,13 +799,16 @@ static void iwl_bg_request_scan(struct work_struct *data)
*/
if (priv->cfg->off_channel_workaround)
rx_ant = ANT_BC;
- } else {
+ break;
+ default:
IWL_WARN(priv, "Invalid scan band count\n");
goto done;
}
+ band = priv->scan_band;
+
priv->scan_tx_ant[band] =
- iwl_toggle_tx_ant(priv, priv->scan_tx_ant[band]);
+ iwl_toggle_tx_ant(priv, priv->scan_tx_ant[band]);
rate_flags |= iwl_ant_idx_to_flags(priv->scan_tx_ant[band]);
scan->tx_cmd.rate_n_flags = iwl_hw_set_rate_n_flags(rate, rate_flags);
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 24e9694..e266695 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -2852,11 +2852,6 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
goto done;
}
- if (!priv->scan_bands) {
- IWL_DEBUG_HC(priv, "Aborting scan due to no requested bands\n");
- goto done;
- }
-
if (!priv->scan) {
priv->scan = kmalloc(sizeof(struct iwl3945_scan_cmd) +
IWL_MAX_SCAN_SIZE, GFP_KERNEL);
@@ -2934,12 +2929,14 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
/* flags + rate selection */
- if (priv->scan_bands & BIT(IEEE80211_BAND_2GHZ)) {
+ switch (priv->scan_band) {
+ case IEEE80211_BAND_2GHZ:
scan->flags = RXON_FLG_BAND_24G_MSK | RXON_FLG_AUTO_DETECT_MSK;
scan->tx_cmd.rate = IWL_RATE_1M_PLCP;
scan->good_CRC_th = 0;
band = IEEE80211_BAND_2GHZ;
- } else if (priv->scan_bands & BIT(IEEE80211_BAND_5GHZ)) {
+ break;
+ case IEEE80211_BAND_5GHZ:
scan->tx_cmd.rate = IWL_RATE_6M_PLCP;
/*
* If active scaning is requested but a certain channel
@@ -2948,8 +2945,9 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
*/
scan->good_CRC_th = is_active ? IWL_GOOD_CRC_TH : 0;
band = IEEE80211_BAND_5GHZ;
- } else {
- IWL_WARN(priv, "Invalid scan band count\n");
+ break;
+ default:
+ IWL_WARN(priv, "Invalid scan band\n");
goto done;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 00/21] iwlwifi updates for 2.6.35
From: Reinette Chatre @ 2010-04-16 21:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
We include a variety of changes. For statistics display in debugfs we add
some generic functions that will help us add similar functions for all
devices soon. Included are a few cleanups to the scanning code, removing
unnecessary code and making code synchronous when it can sleep. We include
some preparation work for the support of new hardware. The rest is small
stand alone cleanups.
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
Abhijeet Kolekar (1):
iwlwifi: add debugfs ops to iwlwifi
Johannes Berg (11):
iwlwifi: remove scan_bands logic
iwlwifi: correct atomic bitops usage
iwlwifi: remove next_scan_jiffies
iwlwifi: remove scan_pass_start
iwlwifi: rename priv->scan to priv->scan_cmd
iwlwifi: trigger scan synchronously
iwlwifi: make BT coex config a virtual method
iwlwifi: rename TX_CMD_FLG_BT_DIS_MSK
iwlwifi: don't check monitor for scanning
iwlwifi: remove monitor check
iwlwifi: make scan antenna forcing more generic
Shanyu Zhao (2):
iwlwifi: bring up 6000 Series 2x2 AGN Gen2 adapters
iwlwifi: remove redundant iwl_dump_lq_cmd()
Wey-Yi Guy (7):
iwlwifi: set correct single/dual stream mask
iwlwifi: more generic eeprom defines
iwlwifi: remove duplicated debug functions
iwlwifi: add hw revision for 6000g2 NIC
iwlwifi: PA type for 6000g2 series
iwlwifi: sanity check for turn on aggregation tid
iwlwifi: more code clean up for agn devices
drivers/net/wireless/iwlwifi/Makefile | 1 +
drivers/net/wireless/iwlwifi/iwl-1000.c | 6 +
drivers/net/wireless/iwlwifi/iwl-3945.c | 2 +
drivers/net/wireless/iwlwifi/iwl-3945.h | 3 +
drivers/net/wireless/iwlwifi/iwl-4965.c | 15 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 11 +
drivers/net/wireless/iwlwifi/iwl-6000.c | 33 +-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 834 ++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.h | 56 ++
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 2 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 403 +++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 47 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 42 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 36 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 50 +--
drivers/net/wireless/iwlwifi/iwl-agn.h | 3 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 42 +--
drivers/net/wireless/iwlwifi/iwl-core.h | 18 +-
drivers/net/wireless/iwlwifi/iwl-csr.h | 1 +
drivers/net/wireless/iwlwifi/iwl-debug.h | 2 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 775 +---------------------
drivers/net/wireless/iwlwifi/iwl-dev.h | 9 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 32 +-
drivers/net/wireless/iwlwifi/iwl-prph.h | 80 ++--
drivers/net/wireless/iwlwifi/iwl-scan.c | 500 +--------------
drivers/net/wireless/iwlwifi/iwl-sta.c | 13 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 87 +--
28 files changed, 1599 insertions(+), 1506 deletions(-)
create mode 100644 drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-agn-debugfs.h
^ permalink raw reply
* [PATCH 1/2] iwlwifi: fix scan races
From: Reinette Chatre @ 2010-04-16 21:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Johannes Berg, Reinette Chatre
In-Reply-To: <1271454614-14272-1-git-send-email-reinette.chatre@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
When an internal scan is started, nothing protects the
is_internal_short_scan variable which can cause crashes,
cf. https://bugzilla.kernel.org/show_bug.cgi?id=15667.
Fix this by making the short scan request use the mutex
for locking, which requires making the request go to a
work struct so that it can sleep.
Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 1 +
drivers/net/wireless/iwlwifi/iwl-core.c | 1 -
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
drivers/net/wireless/iwlwifi/iwl-scan.c | 31 ++++++++++++++++++++-----------
5 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index e4c2e1e..ba0fdba 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -3330,6 +3330,7 @@ static void iwl_cancel_deferred_work(struct iwl_priv *priv)
cancel_delayed_work_sync(&priv->init_alive_start);
cancel_delayed_work(&priv->scan_check);
+ cancel_work_sync(&priv->start_internal_scan);
cancel_delayed_work(&priv->alive_start);
cancel_work_sync(&priv->beacon_update);
del_timer_sync(&priv->statistics_periodic);
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 894bcb8..1459cdb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -3357,7 +3357,6 @@ static void iwl_force_rf_reset(struct iwl_priv *priv)
*/
IWL_DEBUG_INFO(priv, "perform radio reset.\n");
iwl_internal_short_hw_scan(priv);
- return;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 732590f..36940a9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -506,7 +506,7 @@ void iwl_init_scan_params(struct iwl_priv *priv);
int iwl_scan_cancel(struct iwl_priv *priv);
int iwl_scan_cancel_timeout(struct iwl_priv *priv, unsigned long ms);
int iwl_mac_hw_scan(struct ieee80211_hw *hw, struct cfg80211_scan_request *req);
-int iwl_internal_short_hw_scan(struct iwl_priv *priv);
+void iwl_internal_short_hw_scan(struct iwl_priv *priv);
int iwl_force_reset(struct iwl_priv *priv, int mode);
u16 iwl_fill_probe_req(struct iwl_priv *priv, struct ieee80211_mgmt *frame,
const u8 *ie, int ie_len, int left);
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 6054c5f..ef1720a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -1296,6 +1296,7 @@ struct iwl_priv {
struct work_struct tt_work;
struct work_struct ct_enter;
struct work_struct ct_exit;
+ struct work_struct start_internal_scan;
struct tasklet_struct irq_tasklet;
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index bd2f7c4..5062f4e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -469,6 +469,8 @@ EXPORT_SYMBOL(iwl_init_scan_params);
static int iwl_scan_initiate(struct iwl_priv *priv)
{
+ WARN_ON(!mutex_is_locked(&priv->mutex));
+
IWL_DEBUG_INFO(priv, "Starting scan...\n");
set_bit(STATUS_SCANNING, &priv->status);
priv->is_internal_short_scan = false;
@@ -546,24 +548,31 @@ EXPORT_SYMBOL(iwl_mac_hw_scan);
* internal short scan, this function should only been called while associated.
* It will reset and tune the radio to prevent possible RF related problem
*/
-int iwl_internal_short_hw_scan(struct iwl_priv *priv)
+void iwl_internal_short_hw_scan(struct iwl_priv *priv)
{
- int ret = 0;
+ queue_work(priv->workqueue, &priv->start_internal_scan);
+}
+
+static void iwl_bg_start_internal_scan(struct work_struct *work)
+{
+ struct iwl_priv *priv =
+ container_of(work, struct iwl_priv, start_internal_scan);
+
+ mutex_lock(&priv->mutex);
if (!iwl_is_ready_rf(priv)) {
- ret = -EIO;
IWL_DEBUG_SCAN(priv, "not ready or exit pending\n");
- goto out;
+ goto unlock;
}
+
if (test_bit(STATUS_SCANNING, &priv->status)) {
IWL_DEBUG_SCAN(priv, "Scan already in progress.\n");
- ret = -EAGAIN;
- goto out;
+ goto unlock;
}
+
if (test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
IWL_DEBUG_SCAN(priv, "Scan request while abort pending\n");
- ret = -EAGAIN;
- goto out;
+ goto unlock;
}
priv->scan_bands = 0;
@@ -576,9 +585,8 @@ int iwl_internal_short_hw_scan(struct iwl_priv *priv)
set_bit(STATUS_SCANNING, &priv->status);
priv->is_internal_short_scan = true;
queue_work(priv->workqueue, &priv->request_scan);
-
-out:
- return ret;
+ unlock:
+ mutex_unlock(&priv->mutex);
}
EXPORT_SYMBOL(iwl_internal_short_hw_scan);
@@ -964,6 +972,7 @@ void iwl_setup_scan_deferred_work(struct iwl_priv *priv)
INIT_WORK(&priv->scan_completed, iwl_bg_scan_completed);
INIT_WORK(&priv->request_scan, iwl_bg_request_scan);
INIT_WORK(&priv->abort_scan, iwl_bg_abort_scan);
+ INIT_WORK(&priv->start_internal_scan, iwl_bg_start_internal_scan);
INIT_DELAYED_WORK(&priv->scan_check, iwl_bg_scan_check);
}
EXPORT_SYMBOL(iwl_setup_scan_deferred_work);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] iwlwifi: correct 6000 EEPROM regulatory address
From: Reinette Chatre @ 2010-04-16 21:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Shanyu Zhao, Reinette Chatre
In-Reply-To: <1271454614-14272-1-git-send-email-reinette.chatre@intel.com>
From: Shanyu Zhao <shanyu.zhao@intel.com>
For 6000 series, the 2.4G HT40 band regulatory settings address in EEPROM
was off by 2.
Before the fix, you'll see this in dmesg:
[79535.788877] ieee80211 phy8: U iwl_mod_ht40_chan_info HT40 Ch. 7 [2.4GHz]
WIDE (0x61 0dBm): Ad-Hoc not supported
[79535.788880] ieee80211 phy8: U iwl_mod_ht40_chan_info HT40 Ch. 11 [2.4GHz]
WIDE (0x61 0dBm): Ad-Hoc not supported
And after the fix:
[91132.688706] ieee80211 phy14: U iwl_mod_ht40_chan_info HT40 Ch. 7 [2.4GHz]
IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported
[91132.688709] ieee80211 phy14: U iwl_mod_ht40_chan_info HT40 Ch. 11 [2.4GHz]
IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported
Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-6000.c | 4 ++--
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 4 ++++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index c4844ad..92b3e64 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -259,7 +259,7 @@ static struct iwl_lib_ops iwl6000_lib = {
EEPROM_5000_REG_BAND_3_CHANNELS,
EEPROM_5000_REG_BAND_4_CHANNELS,
EEPROM_5000_REG_BAND_5_CHANNELS,
- EEPROM_5000_REG_BAND_24_HT40_CHANNELS,
+ EEPROM_6000_REG_BAND_24_HT40_CHANNELS,
EEPROM_5000_REG_BAND_52_HT40_CHANNELS
},
.verify_signature = iwlcore_eeprom_verify_signature,
@@ -323,7 +323,7 @@ static struct iwl_lib_ops iwl6050_lib = {
EEPROM_5000_REG_BAND_3_CHANNELS,
EEPROM_5000_REG_BAND_4_CHANNELS,
EEPROM_5000_REG_BAND_5_CHANNELS,
- EEPROM_5000_REG_BAND_24_HT40_CHANNELS,
+ EEPROM_6000_REG_BAND_24_HT40_CHANNELS,
EEPROM_5000_REG_BAND_52_HT40_CHANNELS
},
.verify_signature = iwlcore_eeprom_verify_signature,
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 4e1ba82..8171c70 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -203,6 +203,10 @@ struct iwl_eeprom_enhanced_txpwr {
#define EEPROM_5000_REG_BAND_52_HT40_CHANNELS ((0x92)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 22 bytes */
+/* 6000 regulatory - indirect access */
+#define EEPROM_6000_REG_BAND_24_HT40_CHANNELS ((0x80)\
+ | INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 14 bytes */
+
/* 6000 and up regulatory tx power - indirect access */
/* max. elements per section */
#define EEPROM_MAX_TXPOWER_SECTION_ELEMENTS (8)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/2] iwlwifi fixes for 2.6.34
From: Reinette Chatre @ 2010-04-16 21:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
We include two fixes for 2.6.34. A scan race resulting in system crashes is
fixed with "iwlwifi: fix scan races" - this issue is tracked in
https://bugzilla.kernel.org/show_bug.cgi?id=15667 . The second fixes how
regulatory information is read from the 6000 series EEPROM. Channels that
were previously wrongly identified as not supporting IBSS are now correctly
identified as now supporting IBSS.
These patches are also available from wireless-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
Johannes Berg (1):
iwlwifi: fix scan races
Shanyu Zhao (1):
iwlwifi: correct 6000 EEPROM regulatory address
drivers/net/wireless/iwlwifi/iwl-6000.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 1 +
drivers/net/wireless/iwlwifi/iwl-core.c | 1 -
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 4 +++
drivers/net/wireless/iwlwifi/iwl-scan.c | 31 ++++++++++++++++++----------
7 files changed, 29 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: compat-wireless doesn't compile against 2.6.32 on Ubuntu beta
From: Pavel Roskin @ 2010-04-16 21:50 UTC (permalink / raw)
To: Andrey Semyonov; +Cc: linux-wireless
In-Reply-To: <t2wd01f95791004151011n1a5077a3oca9f7b641b311ac2@mail.gmail.com>
On Thu, 2010-04-15 at 21:11 +0400, Andrey Semyonov wrote:
> I get this when trying to compile current drivers:
>
>
> /usr/local/src/compat-wireless-2010-04-14# make
> make -C /lib/modules/2.6.32-19-generic/build
> M=/usr/local/src/compat-wireless-2010-04-14 modules
> make[1]: Вход в каталог `/usr/src/linux-headers-2.6.32-19-generic'
> CC [M] /usr/local/src/compat-wireless-2010-04-14/net/mac80211/main.o
> /usr/local/src/compat-wireless-2010-04-14/net/mac80211/main.c: In
> function 'ieee80211_alloc_hw':
> /usr/local/src/compat-wireless-2010-04-14/net/mac80211/main.c:394:
> error: implicit declaration of function '__hw_addr_init'
I confirm the problem. Basically, the bleeding edge compat-wireless is
useless now. Perhaps we need a check to to prevent broken tarballs from
being uploaded. It's better than force users to search for the last
working tarball.
compat-wireless-2.6.34-rc4 should be OK for Linux 2.6.27 and newer,
although it lacks some fixes needed for older kernels. It also lacks
the experimental wireless code that is not scheduled for Linux 2.6.34.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 2/2] iwmc3200wifi: check sparse endianness annotations
From: Pavel Roskin @ 2010-04-16 21:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: Zhu Yi, linville, linux-wireless, Samuel Ortiz
In-Reply-To: <1271451466.8043.0.camel@jlt3.sipsolutions.net>
On Fri, 2010-04-16 at 22:57 +0200, Johannes Berg wrote:
> We've done it on other drivers -- we can't do it for all of the kernel
> because that would drown people in warnings, but for those drivers that
> _should_ be clean it ought to be fine to add it by default.
Oh, I see, there are several precedents.
That said, there are not many warnings added by __CHECK_ENDIAN__. In my
x86_64 configuration, sparse produces 2316 lines of output without
__CHECK_ENDIAN__ and 3526 lines with __CHECK_ENDIAN__, a 52% increase.
That's hardly "drowning".
Also, the warnings about endianess are perhaps the most useful of all
sparse warnings.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] wireless: rt2x00: rt2800usb: delete Allwin devices
From: Gertjan van Wingerde @ 2010-04-16 21:19 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: John W. Linville, Ivo Van Doorn, linux-wireless, users
In-Reply-To: <20100416134326.GD8554@tuxdriver.com>
On 04/16/10 15:43, John W. Linville wrote:
> On Fri, Apr 16, 2010 at 01:17:07PM +0200, Ivo Van Doorn wrote:
>> On Fri, Apr 16, 2010 at 12:16 PM, Xose Vazquez Perez
>> <xose.vazquez@gmail.com> wrote:
>>> Common sense says:
>>> (0x8516, 0x2070) is RT2070
>>> (0x8516, 0x2770) is RT2770
>>> (0x8516, 0x2870) is RT2870
>>> [...]
>>>
>>> but Allwin doesn't sell USB dongles nor PCI boards, only voip-routers
>>> http://www.allwin.com.tw/eng/modules/tinyd0/content/index.php?id=1
>>
>> But how about the case where the company name is wrong and the ID's are valid?
>> That means we only should update the comment, rather then deleting the ID's.
>
> Or the case where someone ports Linux to those voip routers...
And finally, these devices are still mentioned in the Ralink windows driver,
so we must assume that they actually exist.
However, the common sense approach may be appropriate, so moving these devices
to the correct section does seem okay.
---
Gertjan.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] ath5k/ath9k: Fix 64 bits TSF reads
From: Pavel Roskin @ 2010-04-16 21:13 UTC (permalink / raw)
To: Benoit Papillault; +Cc: lrodriguez, ath5k-devel, linux-wireless, ath9k-devel
In-Reply-To: <1271369246-6892-1-git-send-email-benoit.papillault@free.fr>
On Fri, 2010-04-16 at 00:07 +0200, Benoit Papillault wrote:
> It follows the logic mentionned by Derek, with only 2 register reads
> needed at each additional steps instead of 3 (the minimum number of
> register reads is still 3).
I would prefer an approach whereas tsf_upper2 or tsf_upper1 is chosen
based on whether tsf_lower is more or less than 0x80000000 if
(tsf_upper2 - tsf_upper1) is 1. If the difference is not 0 or 1, either
the hardware is broken or the kernel was stuck for so long (71 minutes!)
that getting the exact tsf should be the least worry. That's when
WARN_ON would be appropriate.
The problem with overengineered code is that it doesn't break when it's
better to break and expose the problem :-)
But it's just a suggestion, not a NACK. It's better to have some fix
than no fix at all.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 2/2] iwmc3200wifi: check sparse endianness annotations
From: Johannes Berg @ 2010-04-16 20:57 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Zhu Yi, linville, linux-wireless, Samuel Ortiz
In-Reply-To: <1271451350.16507.2.camel@mj>
On Fri, 2010-04-16 at 16:55 -0400, Pavel Roskin wrote:
> On Fri, 2010-04-16 at 09:28 +0800, Zhu Yi wrote:
> > From: Samuel Ortiz <sameo@linux.intel.com>
> >
> > Add -D__CHECK_ENDIAN__ to driver ccflags so that sparse will
> > always check endianness by default.
>
> I believe it's wrong. I would be fine with enabling __CHECK_ENDIAN__
> for the whole kernel by default (perhaps with an option to disable it).
> But there is no reason why some particular drivers need that check more
> than the rest of the kernel.
We've done it on other drivers -- we can't do it for all of the kernel
because that would drown people in warnings, but for those drivers that
_should_ be clean it ought to be fine to add it by default.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] iwmc3200wifi: check sparse endianness annotations
From: Pavel Roskin @ 2010-04-16 20:55 UTC (permalink / raw)
To: Zhu Yi; +Cc: linville, linux-wireless, Samuel Ortiz
In-Reply-To: <1271381324-21044-2-git-send-email-yi.zhu@intel.com>
On Fri, 2010-04-16 at 09:28 +0800, Zhu Yi wrote:
> From: Samuel Ortiz <sameo@linux.intel.com>
>
> Add -D__CHECK_ENDIAN__ to driver ccflags so that sparse will
> always check endianness by default.
I believe it's wrong. I would be fine with enabling __CHECK_ENDIAN__
for the whole kernel by default (perhaps with an option to disable it).
But there is no reason why some particular drivers need that check more
than the rest of the kernel.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: timeout in zd1211rw with zotac mini-itx (geforce 9300)
From: Gábor Stefanik @ 2010-04-16 20:51 UTC (permalink / raw)
To: Tsuwei Chen; +Cc: zd1211-devs, linux-wireless
In-Reply-To: <k2r8108ad761004161334x894f9298xf3728846ff69b36b@mail.gmail.com>
On Fri, Apr 16, 2010 at 10:34 PM, Tsuwei Chen <tsuwei@gmail.com> wrote:
> Has anyone use the zd1211 usb adapter with mini-itx board based on
> geforce 9300? I have been experience some annoying issues ever since I
> got this motherboard. The problem is that sometime the card just
> cannot be switched on. It complains about ioread32() error -110. And I
> have spent a few days and try a few different combination, and here is
> what I have found so far:
>
> 1, with 1 wifi adapter directly plugged into the board, the wifi
> adapter works fine most of the time (have seen a couple failure, but
> is hard to reproduce)
> 2. with 1 wifi adapter, plugged in through a USB hub, the driver
> complains ioread32 error. I've try 2 USB hubs: a cheap 4-port USB
> dongle and also the USB hubs built into my DELL monitor. Both showed
> the same problem.
> 3. If I plugged in 2 wifi adapters directly to the board, more than
> 50% of chance one of the wifi adapter would fail during the 'ifconifg
> up'.
>
> I tried to dig our more on this. I am using kernel 2.6.24-26 (ubuntu).
Please try a more recent kernel - 2.6.24 contains
zd1211rw-ieee80211softmac, which is no longer developed.
> I had turned on the debug message output and I have traced out that
> the failure was first detected in the zd_mac_open(). Probably around
> the call to zd_chip_switch_radio_on(). The error message is printed in
> the zd_usb_ioread16v(), and probably indicate the driver is
> experiencing a timeout while it is trying to read the register from
> the adapter.
>
> What exactly does this mean? Why adding a usb hub cause such a huge
> differnce? Has anyone experienced similar problem before? Any pointer
> that can help me solve this problem is appreciated.
>
> BTW, I never had this problem before when I was still using a regular
> HP desktop PC, even with the same version of kernel and same USB hub.
> I switched to mini-itx because I am building a small system. So if
> anyone is currently using this adapter with a mini-ITX board, please
> also let me know which model you use.
>
> TIA,
> Tsuwei
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* timeout in zd1211rw with zotac mini-itx (geforce 9300)
From: Tsuwei Chen @ 2010-04-16 20:34 UTC (permalink / raw)
To: zd1211-devs; +Cc: linux-wireless
Has anyone use the zd1211 usb adapter with mini-itx board based on
geforce 9300? I have been experience some annoying issues ever since I
got this motherboard. The problem is that sometime the card just
cannot be switched on. It complains about ioread32() error -110. And I
have spent a few days and try a few different combination, and here is
what I have found so far:
1, with 1 wifi adapter directly plugged into the board, the wifi
adapter works fine most of the time (have seen a couple failure, but
is hard to reproduce)
2. with 1 wifi adapter, plugged in through a USB hub, the driver
complains ioread32 error. I've try 2 USB hubs: a cheap 4-port USB
dongle and also the USB hubs built into my DELL monitor. Both showed
the same problem.
3. If I plugged in 2 wifi adapters directly to the board, more than
50% of chance one of the wifi adapter would fail during the 'ifconifg
up'.
I tried to dig our more on this. I am using kernel 2.6.24-26 (ubuntu).
I had turned on the debug message output and I have traced out that
the failure was first detected in the zd_mac_open(). Probably around
the call to zd_chip_switch_radio_on(). The error message is printed in
the zd_usb_ioread16v(), and probably indicate the driver is
experiencing a timeout while it is trying to read the register from
the adapter.
What exactly does this mean? Why adding a usb hub cause such a huge
differnce? Has anyone experienced similar problem before? Any pointer
that can help me solve this problem is appreciated.
BTW, I never had this problem before when I was still using a regular
HP desktop PC, even with the same version of kernel and same USB hub.
I switched to mini-itx because I am building a small system. So if
anyone is currently using this adapter with a mini-ITX board, please
also let me know which model you use.
TIA,
Tsuwei
^ permalink raw reply
* Re: [RFC PATCH] mac80211: Prevent running sta_cleanup timer unnecessarily
From: Johannes Berg @ 2010-04-16 20:17 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1271403308-23416-2-git-send-email-juuso.oikarinen@nokia.com>
On Fri, 2010-04-16 at 10:35 +0300, Juuso Oikarinen wrote:
> The sta_cleanup timer is used to periodically expire buffered frames from the
> tx buf. The timer is executing periodically, regardless of the need for it.
> This is wasting resources.
>
> Fix this simply by not restarting the sta_cleanup timer if the tx buffer was
> empty. Restart the timer when there is some more tx-traffic.
>
> Cc: Janne Ylälehto <janne.ylalehto@nokia.com>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> net/mac80211/sta_info.c | 13 ++++++++++---
> net/mac80211/tx.c | 7 +++++++
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index ff0eb94..3de7a22 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -575,7 +575,7 @@ static int sta_info_buffer_expired(struct sta_info *sta,
> }
>
>
> -static void sta_info_cleanup_expire_buffered(struct ieee80211_local *local,
> +static bool sta_info_cleanup_expire_buffered(struct ieee80211_local *local,
> struct sta_info *sta)
> {
> unsigned long flags;
> @@ -583,7 +583,7 @@ static void sta_info_cleanup_expire_buffered(struct ieee80211_local *local,
> struct ieee80211_sub_if_data *sdata;
>
> if (skb_queue_empty(&sta->ps_tx_buf))
> - return;
> + return false;
>
> for (;;) {
> spin_lock_irqsave(&sta->ps_tx_buf.lock, flags);
> @@ -608,6 +608,8 @@ static void sta_info_cleanup_expire_buffered(struct ieee80211_local *local,
> if (skb_queue_empty(&sta->ps_tx_buf))
> sta_info_clear_tim_bit(sta);
> }
> +
> + return true;
> }
>
> static int __must_check __sta_info_destroy(struct sta_info *sta)
> @@ -755,15 +757,20 @@ static void sta_info_cleanup(unsigned long data)
> {
> struct ieee80211_local *local = (struct ieee80211_local *) data;
> struct sta_info *sta;
> + bool timer_needed = false;
>
> rcu_read_lock();
> list_for_each_entry_rcu(sta, &local->sta_list, list)
> - sta_info_cleanup_expire_buffered(local, sta);
> + if (sta_info_cleanup_expire_buffered(local, sta))
> + timer_needed = true;
> rcu_read_unlock();
>
> if (local->quiescing)
> return;
>
> + if (!timer_needed)
> + return;
> +
> local->sta_cleanup.expires =
> round_jiffies(jiffies + STA_INFO_CLEANUP_INTERVAL);
> add_timer(&local->sta_cleanup);
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 2cb7726..e2aa972 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -429,6 +429,7 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
> struct sta_info *sta = tx->sta;
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
> + struct ieee80211_local *local = tx->local;
> u32 staflags;
>
> if (unlikely(!sta ||
> @@ -476,6 +477,12 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
> info->control.vif = &tx->sdata->vif;
> info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
> skb_queue_tail(&sta->ps_tx_buf, tx->skb);
> +
> + if (!timer_pending(&local->sta_cleanup))
> + mod_timer(&local->sta_cleanup,
> + round_jiffies(jiffies +
> + STA_INFO_CLEANUP_INTERVAL));
> +
Why bother to check !timer_pending?
johannes
^ permalink raw reply
* Re: 2.6.33 iwl5350 firmware crash
From: reinette chatre @ 2010-04-16 20:07 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org, stable
In-Reply-To: <1271442365.14052.13562.camel@rchatre-DESK>
On Fri, 2010-04-16 at 11:26 -0700, reinette chatre wrote:
> On Thu, 2010-04-15 at 14:08 -0700, Andrew Lutomirski wrote:
> > [74944.425130] iwlagn 0000:03:00.0: Microcode SW error detected.
> > Restarting 0x2000000.
> > [74944.425154] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
> > [74944.425160] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
> > [74944.425291] iwlagn 0000:03:00.0: Desc
> > Time data1 data2 line
> > [74944.425301] iwlagn 0000:03:00.0: NMI_INTERRUPT_WDG (#04)
> > 1638059893 0x00000002 0x07030000 3664
>
> [...]
>
> > [74981.401945] ------------[ cut here ]------------
> > [74981.401980] WARNING: at net/mac80211/agg-tx.c:152
> > ___ieee80211_stop_tx_ba_session+0x87/0x8c [mac80211]()
>
>
> Please see https://bugzilla.kernel.org/show_bug.cgi?id=15374 - it has
> patches that will help aggregation recovery after this NMI problem.
> Unfortunately there is nothing we can do at this time to the firmware
> error. I'll try to get these patches into 2.6.34 today.
The patches are already included in 2.6.34. I did try to get this
included into 2.6.33 and submitted it to stable on 03/18/2010,
unfortunately it was not accepted.
Reinette
^ permalink raw reply
* RE: Power consumption on 802.11 / ASPM / device measurements
From: David Quan @ 2010-04-16 20:03 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless
Cc: linux-kernel@vger.kernel.org, yanmin.zhang@intel.com,
shaohua.li@intel.com, Sameer Nanda, Jonathan May
In-Reply-To: <n2q43e72e891004161253wbb9afe61y539206f010e91a78@mail.gmail.com>
it is a very complicated issue.
Different system have different limitation.
it is not a one size fits all.
So we let the BIOS of each system with the different chipset control this, and we work with that team
to make sure the correct settings work together for both RC and endpoint.
It should not be controlled by the endpoint as endpoint can get plug into many different systems and endpoint
will not know the limitations of each system/chipset in the system.
I highly recommend you all not to touch the aspm settings from the endpoint, point of view and let the system bios
do what it has been programmed to do.
David
-----Original Message-----
From: Luis R. Rodriguez [mailto:mcgrof@gmail.com]
Sent: Friday, April 16, 2010 12:54 PM
To: linux-wireless
Cc: linux-kernel@vger.kernel.org; yanmin.zhang@intel.com; shaohua.li@intel.com; Sameer Nanda; Jonathan May; David Quan
Subject: Power consumption on 802.11 / ASPM / device measurements
We've been accumulating a few power consumption related documents on
the wireless wiki for a while now. One which I saw was missing was for
actual power consumption and review of new PCI-E features which should
be taken into consideration when debugging power consumption or
reviewing it. ASPM is something that I can say I found little to no
documentation for when looking into it so I've done a brain dump of
what I recall from it, the code review of it, and some e-mail
exchanges I've had with Jonathan May @ Atheros.
I've stashed together all the power consumption docs at:
http://wireless.kernel.org/en/users/Documentation/Power-consumption
You'll see there some ASPM docs now and some ath9k specific power
consumption metrics/ASPM details. Please review and enhance as you see
fit.
Yanmin, Shaohua, I see CONFIG_PCIEASPM still marked as experimental,
I'm curious if this is still really that experimental and if there are
plans for it go out of experimental. Also I am little puzzled with
some of the aspm.c code, I see we fill the pci device struct with
capability stuff via pcie_aspm_cap_init() but I also see ASPM
capability stuff exposed on kernels without CONFIG_PCIEASPM (albeit I
see it always disabled on my system at home), so are we filling the
capability elsewhere? I think there are some boxes without this kernel
config enabled and where ASPM capability info is exposed and does show
up as enabled, could be wrong.
Also curious -- how often are BIOSes buggy enough for ASPM to get
disabled by mistake on the modern devices? And for systems that have
no Bios (*cough* ChromeOS) how is this handled?
Luis
^ permalink raw reply
* Re: [PATCH v3 09/97] ath9k_hw: Move some RF ops to the private callbacks
From: Luis R. Rodriguez @ 2010-04-16 19:56 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <20100416194335.GF8554@tuxdriver.com>
On Fri, Apr 16, 2010 at 12:43 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Thu, Apr 15, 2010 at 05:38:14PM -0400, Luis R. Rodriguez wrote:
>> The PHY split is easier done in a few steps. First move
>> the RF ops to the private ops and rename them accordingly.
>> We split PHY stuff up first for the AR5008 and AR9002
>> families. There are some callbacks that AR9002 share
>> with the AR5008 familiy so we set those first, if AR9002
>> has some different callbacks it will override them upon
>> hardware init.
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> drivers/net/wireless/ath/ath9k/Makefile | 3 +-
>> drivers/net/wireless/ath/ath9k/ani.c | 1 +
>> .../net/wireless/ath/ath9k/{phy.c => ar5008_phy.c} | 884 ++++++++++----------
>
> In general, it is better to do renames in a separate patch -- the
> fixups are easier in cases where something else hit that file before
> your patch is applied. It might also help if you based big patches
> (or big series) on wireless-next-2.6 instead of wireless-testing, as I
> need to apply them to wireless-next-2.6 before I can send them to Dave.
>
> In this case, a patch that wireless-testing picked-up from linux-2.6
> and which isn't in wireless-next-2.6 (and probably not net-next-2.6
> either) causes this patch to fail to apply to wirless-next-2.6.
> I'll fix it up, in the interest of putting this series behind us...
Thanks for addressing it on your end this time, next time we'll rebase
on top of wireless-next-2.6 when doing a larger series. I don't expect
this to happen quite often though. This was just a new hardware
family, which happens so far about every what, 4-5 years?
Thanks!!!
Luis
^ permalink raw reply
* Power consumption on 802.11 / ASPM / device measurements
From: Luis R. Rodriguez @ 2010-04-16 19:53 UTC (permalink / raw)
To: linux-wireless
Cc: linux-kernel, yanmin.zhang, shaohua.li, Sameer Nanda,
Jonathan May, David Quan
We've been accumulating a few power consumption related documents on
the wireless wiki for a while now. One which I saw was missing was for
actual power consumption and review of new PCI-E features which should
be taken into consideration when debugging power consumption or
reviewing it. ASPM is something that I can say I found little to no
documentation for when looking into it so I've done a brain dump of
what I recall from it, the code review of it, and some e-mail
exchanges I've had with Jonathan May @ Atheros.
I've stashed together all the power consumption docs at:
http://wireless.kernel.org/en/users/Documentation/Power-consumption
You'll see there some ASPM docs now and some ath9k specific power
consumption metrics/ASPM details. Please review and enhance as you see
fit.
Yanmin, Shaohua, I see CONFIG_PCIEASPM still marked as experimental,
I'm curious if this is still really that experimental and if there are
plans for it go out of experimental. Also I am little puzzled with
some of the aspm.c code, I see we fill the pci device struct with
capability stuff via pcie_aspm_cap_init() but I also see ASPM
capability stuff exposed on kernels without CONFIG_PCIEASPM (albeit I
see it always disabled on my system at home), so are we filling the
capability elsewhere? I think there are some boxes without this kernel
config enabled and where ASPM capability info is exposed and does show
up as enabled, could be wrong.
Also curious -- how often are BIOSes buggy enough for ASPM to get
disabled by mistake on the modern devices? And for systems that have
no Bios (*cough* ChromeOS) how is this handled?
Luis
^ permalink raw reply
* Re: [PATCH v3 09/97] ath9k_hw: Move some RF ops to the private callbacks
From: John W. Linville @ 2010-04-16 19:43 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1271367582-992-10-git-send-email-lrodriguez@atheros.com>
On Thu, Apr 15, 2010 at 05:38:14PM -0400, Luis R. Rodriguez wrote:
> The PHY split is easier done in a few steps. First move
> the RF ops to the private ops and rename them accordingly.
> We split PHY stuff up first for the AR5008 and AR9002
> families. There are some callbacks that AR9002 share
> with the AR5008 familiy so we set those first, if AR9002
> has some different callbacks it will override them upon
> hardware init.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/Makefile | 3 +-
> drivers/net/wireless/ath/ath9k/ani.c | 1 +
> .../net/wireless/ath/ath9k/{phy.c => ar5008_phy.c} | 884 ++++++++++----------
In general, it is better to do renames in a separate patch -- the
fixups are easier in cases where something else hit that file before
your patch is applied. It might also help if you based big patches
(or big series) on wireless-next-2.6 instead of wireless-testing, as I
need to apply them to wireless-next-2.6 before I can send them to Dave.
In this case, a patch that wireless-testing picked-up from linux-2.6
and which isn't in wireless-next-2.6 (and probably not net-next-2.6
either) causes this patch to fail to apply to wirless-next-2.6.
I'll fix it up, in the interest of putting this series behind us...
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: [ath9k_htc] Current patches against 2.6.34-rc3-git4
From: Luis R. Rodriguez @ 2010-04-16 19:18 UTC (permalink / raw)
To: sedat.dilek; +Cc: Sujith, linux-wireless@vger.kernel.org, Vivek Natarajan
In-Reply-To: <m2y2d0a357f1004161107h2881b448ta8aebbc7fbc40486@mail.gmail.com>
On Fri, Apr 16, 2010 at 11:07 AM, Sedat Dilek
<sedat.dilek@googlemail.com> wrote:
> Thanks for the informations.
>
> Compat-wireless is broken ATM (see IRC backlog below).
>
> From #linux-wireless/freenode (German local-time - UTC+2):
> ...
> [06:52:54] <mcgrof> User-level discussions about wireless LANs on
> Linux | compat-wireless-2.6 only available for kernels >= 2.6.23
> (bleeding edge broken right now though)
> ...
> [19:13:41] <jensp> fivetwentysix: He says that he removed the atheros
> driver from compat-wireless and replaced it with
> http://git.kernel.org/?p=linux/kernel/git/mcgrof/ath9k_htc.git;a=summary
disregard that tree, its there just for historical purposes now.
> ...
>
> I was more interested in following the ath9k_htc development -
> especially against Linus-tree.
>
> A GIT repository like in [1] w/could be helpful and if it is
> "official" (don't know the status, last commit was before 7 weeks)
> worth updating in [2]?
I've noted elsewhere that what we need to do is to backport these
patches from linux-next:
22bedad3ce112d5ca1eaf043d4990fa2ed698c87 net: convert multicast list
to list_head
2f787b0b76bf5de2eaa3ca3a29d89123ae03c856 mac80211: Ensure initializing
private mc_list in prepare_multicast()
You can get compat-wireless working by reverting these patches (to
what does apply). Its what I would do to backpor t it. We cannot add
the new stuff as the new stuff relies on new changes to internal data
structures, so the way to properly backport this is to ifdef around
the new code and add the reverted code for older kernels.
I haven't had time to do this yet as it involves changes not only on
mac80211 but also on a few other drivers like libertas, etc. It should
be fairly easy to do just haven't had time yet.
Luis
^ permalink raw reply
* Re: Survey mode
From: John W. Linville @ 2010-04-16 18:47 UTC (permalink / raw)
To: Holger Schurig; +Cc: Luis R. Rodriguez, linux-wireless, Ivan Seskar
In-Reply-To: <201004162043.07085.holgerschurig@gmail.com>
On Fri, Apr 16, 2010 at 08:43:06PM +0200, Holger Schurig wrote:
> > Luiz:
> > Holger, are these in PATCH form or were they RFCs?
>
> Both patches work for me, so they're [PATCH]. If John want's them "extra", I
> can make sure they apply to linux-wl and repost them.
Sounds like people want them? If so, a repost would be nice...
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: Survey mode
From: Holger Schurig @ 2010-04-16 18:43 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless; +Cc: Ivan Seskar
In-Reply-To: <z2p43e72e891004161046o81e032ddm20ce1e3528af0684@mail.gmail.com>
> Luiz:
> Holger, are these in PATCH form or were they RFCs?
Both patches work for me, so they're [PATCH]. If John want's them "extra", I
can make sure they apply to linux-wl and repost them.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: 2.6.33 iwl5350 firmware crash
From: reinette chatre @ 2010-04-16 18:26 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <g2rcb0375e11004151408m4a74639cz28e6129054824543@mail.gmail.com>
On Thu, 2010-04-15 at 14:08 -0700, Andrew Lutomirski wrote:
> [74944.425130] iwlagn 0000:03:00.0: Microcode SW error detected.
> Restarting 0x2000000.
> [74944.425154] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
> [74944.425160] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
> [74944.425291] iwlagn 0000:03:00.0: Desc
> Time data1 data2 line
> [74944.425301] iwlagn 0000:03:00.0: NMI_INTERRUPT_WDG (#04)
> 1638059893 0x00000002 0x07030000 3664
[...]
> [74981.401945] ------------[ cut here ]------------
> [74981.401980] WARNING: at net/mac80211/agg-tx.c:152
> ___ieee80211_stop_tx_ba_session+0x87/0x8c [mac80211]()
Please see https://bugzilla.kernel.org/show_bug.cgi?id=15374 - it has
patches that will help aggregation recovery after this NMI problem.
Unfortunately there is nothing we can do at this time to the firmware
error. I'll try to get these patches into 2.6.34 today.
Reinette
^ 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