* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Johannes Berg @ 2010-12-07 18:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, Amod Bodas, pstew@google.com,
stable@kernel.org
In-Reply-To: <AANLkTi=Sj7YpKzFHQtf2MdUcRDTzfXszbK7gGg_yup1Y@mail.gmail.com>
On Tue, 2010-12-07 at 10:04 -0800, Luis R. Rodriguez wrote:
> On Tue, Dec 7, 2010 at 9:32 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Tue, 2010-12-07 at 07:59 -0800, Luis R. Rodriguez wrote:
> >
> >> @@ -301,7 +301,7 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
> >> }
> >>
> >> mutex_lock(&local->mtx);
> >> - ieee80211_recalc_idle(local);
> >> + ieee80211_recalc_idle_force(local);
> >> mutex_unlock(&local->mtx);
> >
> > This is the change that I don't think is necessary.
>
> Without this resume fails.
In what situation? When you just suspend while things are up&running, or
if you suspend with interfaces down? It doesn't make sense anyway, so
something's going on in the rest of the scan code -- we should be
canceling scans properly when going down and when suspending, well
before any of this becomes relevant.
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Luis R. Rodriguez @ 2010-12-07 18:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, Amod Bodas, pstew@google.com,
stable@kernel.org
In-Reply-To: <1291743121.3607.50.camel@jlt3.sipsolutions.net>
On Tue, Dec 7, 2010 at 9:32 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2010-12-07 at 07:59 -0800, Luis R. Rodriguez wrote:
>
>> @@ -301,7 +301,7 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
>> }
>>
>> mutex_lock(&local->mtx);
>> - ieee80211_recalc_idle(local);
>> + ieee80211_recalc_idle_force(local);
>> mutex_unlock(&local->mtx);
>
> This is the change that I don't think is necessary.
Without this resume fails.
Luis
^ permalink raw reply
* DFS implementation on mac80211
From: Luis R. Rodriguez @ 2010-12-07 18:03 UTC (permalink / raw)
To: linux-wireless; +Cc: Kathy Giori
Its time to start designing DFS upstream. To kick this off we will
start pushing some design documentation soon and welcome anyone who is
interested to join our weekly IRC meetings Tuesdays at 9am PST time on
irc.freenode.net #linux-wireless. The page which we'll use to dump
info is:
http://wireless.kernel.org/en/developers/DFS
Luis
^ permalink raw reply
* [PATCH] ath9k: Show some live tx-queue values in debugfs.
From: greearb @ 2010-12-07 17:55 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Ben Greear
From: Ben Greear <greearb@candelatech.com>
I thought this might help track down stuck queues, etc.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 3586c43... 5075faa... M drivers/net/wireless/ath/ath9k/debug.c
drivers/net/wireless/ath/ath9k/debug.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 3586c43..5075faa 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -589,6 +589,16 @@ static const struct file_operations fops_wiphy = {
sc->debug.stats.txstats[WME_AC_VO].elem); \
} while(0)
+#define PRX(str, elem) \
+do { \
+ len += snprintf(buf + len, size - len, \
+ "%s%13u%11u%10u%10u\n", str, \
+ (unsigned int)(sc->tx.txq[WME_AC_BE].elem), \
+ (unsigned int)(sc->tx.txq[WME_AC_BK].elem), \
+ (unsigned int)(sc->tx.txq[WME_AC_VI].elem), \
+ (unsigned int)(sc->tx.txq[WME_AC_VO].elem)); \
+} while(0)
+
static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -619,6 +629,12 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
PR("TX-Pkts-All: ", tx_pkts_all);
PR("TX-Bytes-All: ", tx_bytes_all);
+ PRX("axq-qnum: ", axq_qnum);
+ PRX("axq-depth: ", axq_depth);
+ PRX("axq-stopped ", stopped);
+ PRX("tx-in-progress ", axq_tx_inprogress);
+ PRX("pending-frames ", pending_frames);
+
if (len > size)
len = size;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] iwlwifi: minor txp entries fix
From: Wey-Yi Guy @ 2010-12-07 17:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
In-Reply-To: <1291743428-19642-1-git-send-email-wey-yi.w.guy@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
use le16_to_cpup instead of cpu_to_le16p
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index e777740..cb7d429 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -272,15 +272,17 @@ iwlcore_eeprom_enh_txp_read_element(struct iwl_priv *priv,
void iwlcore_eeprom_enhanced_txpower(struct iwl_priv *priv)
{
struct iwl_eeprom_enhanced_txpwr *txp_array, *txp;
- int idx, entries;
+ int idx;
+ u16 entries;
__le16 *txp_len;
s8 max_txp_avg, max_txp_avg_halfdbm;
BUILD_BUG_ON(sizeof(struct iwl_eeprom_enhanced_txpwr) != 8);
/* the length is in 16-bit words, but we want entries */
- txp_len = (__le16 *) iwlagn_eeprom_query_addr(priv, EEPROM_TXP_SZ_OFFS);
- entries = cpu_to_le16p(txp_len) * 2 / EEPROM_TXP_ENTRY_LEN;
+ txp_len = (__le16 *)
+ iwlagn_eeprom_query_addr(priv, EEPROM_TXP_SZ_OFFS);
+ entries = le16_to_cpup(txp_len) * 2 / EEPROM_TXP_ENTRY_LEN;
txp_array = (void *) iwlagn_eeprom_query_addr(priv, EEPROM_TXP_OFFS);
for (idx = 0; idx < entries; idx++) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] iwlagn: implement layout-agnostic EEPROM reading
From: Wey-Yi Guy @ 2010-12-07 17:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Johannes Berg, Wey-Yi Guy
In-Reply-To: <1291743428-19642-1-git-send-email-wey-yi.w.guy@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
The current EEPROM reading code has some layout
assumptions that now turned out to be false with
some newer versions of the EEPROM. Luckily, we
can avoid all such assumptions by using data in
the EEPROM itself, so implement using that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 264 ++++++-------------------
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 6 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 15 ++
3 files changed, 79 insertions(+), 206 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 9651060..e777740 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -106,78 +106,6 @@
*
*********************************************************************/
-/**
- * struct iwl_txpwr_section: eeprom section information
- * @offset: indirect address into eeprom image
- * @count: number of "struct iwl_eeprom_enhanced_txpwr" in this section
- * @band: band type for the section
- * @is_common - true: common section, false: channel section
- * @is_cck - true: cck section, false: not cck section
- * @is_ht_40 - true: all channel in the section are HT40 channel,
- * false: legacy or HT 20 MHz
- * ignore if it is common section
- * @iwl_eeprom_section_channel: channel array in the section,
- * ignore if common section
- */
-struct iwl_txpwr_section {
- u32 offset;
- u8 count;
- enum ieee80211_band band;
- bool is_common;
- bool is_cck;
- bool is_ht40;
- u8 iwl_eeprom_section_channel[EEPROM_MAX_TXPOWER_SECTION_ELEMENTS];
-};
-
-/**
- * section 1 - 3 are regulatory tx power apply to all channels based on
- * modulation: CCK, OFDM
- * Band: 2.4GHz, 5.2GHz
- * section 4 - 10 are regulatory tx power apply to specified channels
- * For example:
- * 1L - Channel 1 Legacy
- * 1HT - Channel 1 HT
- * (1,+1) - Channel 1 HT40 "_above_"
- *
- * Section 1: all CCK channels
- * Section 2: all 2.4 GHz OFDM (Legacy, HT and HT40) channels
- * Section 3: all 5.2 GHz OFDM (Legacy, HT and HT40) channels
- * Section 4: 2.4 GHz 20MHz channels: 1L, 1HT, 2L, 2HT, 10L, 10HT, 11L, 11HT
- * Section 5: 2.4 GHz 40MHz channels: (1,+1) (2,+1) (6,+1) (7,+1) (9,+1)
- * Section 6: 5.2 GHz 20MHz channels: 36L, 64L, 100L, 36HT, 64HT, 100HT
- * Section 7: 5.2 GHz 40MHz channels: (36,+1) (60,+1) (100,+1)
- * Section 8: 2.4 GHz channel: 13L, 13HT
- * Section 9: 2.4 GHz channel: 140L, 140HT
- * Section 10: 2.4 GHz 40MHz channels: (132,+1) (44,+1)
- *
- */
-static const struct iwl_txpwr_section enhinfo[] = {
- { EEPROM_LB_CCK_20_COMMON, 1, IEEE80211_BAND_2GHZ, true, true, false },
- { EEPROM_LB_OFDM_COMMON, 3, IEEE80211_BAND_2GHZ, true, false, false },
- { EEPROM_HB_OFDM_COMMON, 3, IEEE80211_BAND_5GHZ, true, false, false },
- { EEPROM_LB_OFDM_20_BAND, 8, IEEE80211_BAND_2GHZ,
- false, false, false,
- {1, 1, 2, 2, 10, 10, 11, 11 } },
- { EEPROM_LB_OFDM_HT40_BAND, 5, IEEE80211_BAND_2GHZ,
- false, false, true,
- { 1, 2, 6, 7, 9 } },
- { EEPROM_HB_OFDM_20_BAND, 6, IEEE80211_BAND_5GHZ,
- false, false, false,
- { 36, 64, 100, 36, 64, 100 } },
- { EEPROM_HB_OFDM_HT40_BAND, 3, IEEE80211_BAND_5GHZ,
- false, false, true,
- { 36, 60, 100 } },
- { EEPROM_LB_OFDM_20_CHANNEL_13, 2, IEEE80211_BAND_2GHZ,
- false, false, false,
- { 13, 13 } },
- { EEPROM_HB_OFDM_20_CHANNEL_140, 2, IEEE80211_BAND_5GHZ,
- false, false, false,
- { 140, 140 } },
- { EEPROM_HB_OFDM_HT40_BAND_1, 2, IEEE80211_BAND_5GHZ,
- false, false, true,
- { 132, 44 } },
-};
-
/******************************************************************************
*
* EEPROM related functions
@@ -303,153 +231,77 @@ static s8 iwl_get_max_txpower_avg(struct iwl_priv *priv,
return (max_txpower_avg & 0x01) + (max_txpower_avg >> 1);
}
-/**
- * iwl_update_common_txpower: update channel tx power
- * update tx power per band based on EEPROM enhanced tx power info.
- */
-static s8 iwl_update_common_txpower(struct iwl_priv *priv,
- struct iwl_eeprom_enhanced_txpwr *enhanced_txpower,
- int section, int element, s8 *max_txpower_in_half_dbm)
+static void
+iwlcore_eeprom_enh_txp_read_element(struct iwl_priv *priv,
+ struct iwl_eeprom_enhanced_txpwr *txp,
+ s8 max_txpower_avg)
{
- struct iwl_channel_info *ch_info;
- int ch;
- bool is_ht40 = false;
- s8 max_txpower_avg; /* (dBm) */
-
- /* it is common section, contain all type (Legacy, HT and HT40)
- * based on the element in the section to determine
- * is it HT 40 or not
- */
- if (element == EEPROM_TXPOWER_COMMON_HT40_INDEX)
- is_ht40 = true;
- max_txpower_avg =
- iwl_get_max_txpower_avg(priv, enhanced_txpower,
- element, max_txpower_in_half_dbm);
-
- ch_info = priv->channel_info;
-
- for (ch = 0; ch < priv->channel_count; ch++) {
- /* find matching band and update tx power if needed */
- if ((ch_info->band == enhinfo[section].band) &&
- (ch_info->max_power_avg < max_txpower_avg) &&
- (!is_ht40)) {
- /* Update regulatory-based run-time data */
- ch_info->max_power_avg = ch_info->curr_txpow =
- max_txpower_avg;
+ int ch_idx;
+ bool is_ht40 = txp->flags & IWL_EEPROM_ENH_TXP_FL_40MHZ;
+ enum ieee80211_band band;
+
+ band = txp->flags & IWL_EEPROM_ENH_TXP_FL_BAND_52G ?
+ IEEE80211_BAND_5GHZ : IEEE80211_BAND_2GHZ;
+
+ for (ch_idx = 0; ch_idx < priv->channel_count; ch_idx++) {
+ struct iwl_channel_info *ch_info = &priv->channel_info[ch_idx];
+
+ /* update matching channel or from common data only */
+ if (txp->channel != 0 && ch_info->channel != txp->channel)
+ continue;
+
+ /* update matching band only */
+ if (band != ch_info->band)
+ continue;
+
+ if (ch_info->max_power_avg < max_txpower_avg && !is_ht40) {
+ ch_info->max_power_avg = max_txpower_avg;
+ ch_info->curr_txpow = max_txpower_avg;
ch_info->scan_power = max_txpower_avg;
}
- if ((ch_info->band == enhinfo[section].band) && is_ht40 &&
- (ch_info->ht40_max_power_avg < max_txpower_avg)) {
- /* Update regulatory-based run-time data */
+
+ if (is_ht40 && ch_info->ht40_max_power_avg < max_txpower_avg)
ch_info->ht40_max_power_avg = max_txpower_avg;
- }
- ch_info++;
}
- return max_txpower_avg;
}
-/**
- * iwl_update_channel_txpower: update channel tx power
- * update channel tx power based on EEPROM enhanced tx power info.
- */
-static s8 iwl_update_channel_txpower(struct iwl_priv *priv,
- struct iwl_eeprom_enhanced_txpwr *enhanced_txpower,
- int section, int element, s8 *max_txpower_in_half_dbm)
-{
- struct iwl_channel_info *ch_info;
- int ch;
- u8 channel;
- s8 max_txpower_avg; /* (dBm) */
-
- channel = enhinfo[section].iwl_eeprom_section_channel[element];
- max_txpower_avg =
- iwl_get_max_txpower_avg(priv, enhanced_txpower,
- element, max_txpower_in_half_dbm);
-
- ch_info = priv->channel_info;
- for (ch = 0; ch < priv->channel_count; ch++) {
- /* find matching channel and update tx power if needed */
- if (ch_info->channel == channel) {
- if ((ch_info->max_power_avg < max_txpower_avg) &&
- (!enhinfo[section].is_ht40)) {
- /* Update regulatory-based run-time data */
- ch_info->max_power_avg = max_txpower_avg;
- ch_info->curr_txpow = max_txpower_avg;
- ch_info->scan_power = max_txpower_avg;
- }
- if ((enhinfo[section].is_ht40) &&
- (ch_info->ht40_max_power_avg < max_txpower_avg)) {
- /* Update regulatory-based run-time data */
- ch_info->ht40_max_power_avg = max_txpower_avg;
- }
- break;
- }
- ch_info++;
- }
- return max_txpower_avg;
-}
+#define EEPROM_TXP_OFFS (0x00 | INDIRECT_ADDRESS | INDIRECT_TXP_LIMIT)
+#define EEPROM_TXP_ENTRY_LEN sizeof(struct iwl_eeprom_enhanced_txpwr)
+#define EEPROM_TXP_SZ_OFFS (0x00 | INDIRECT_ADDRESS | INDIRECT_TXP_LIMIT_SIZE)
-/**
- * iwlcore_eeprom_enhanced_txpower: process enhanced tx power info
- */
void iwlcore_eeprom_enhanced_txpower(struct iwl_priv *priv)
{
- int eeprom_section_count = 0;
- int section, element;
- struct iwl_eeprom_enhanced_txpwr *enhanced_txpower;
- u32 offset;
- s8 max_txpower_avg; /* (dBm) */
- s8 max_txpower_in_half_dbm; /* (half-dBm) */
-
- /* Loop through all the sections
- * adjust bands and channel's max tx power
- * Set the tx_power_user_lmt to the highest power
- * supported by any channels and chains
- */
- for (section = 0; section < ARRAY_SIZE(enhinfo); section++) {
- eeprom_section_count = enhinfo[section].count;
- offset = enhinfo[section].offset;
- enhanced_txpower = (struct iwl_eeprom_enhanced_txpwr *)
- iwl_eeprom_query_addr(priv, offset);
+ struct iwl_eeprom_enhanced_txpwr *txp_array, *txp;
+ int idx, entries;
+ __le16 *txp_len;
+ s8 max_txp_avg, max_txp_avg_halfdbm;
+
+ BUILD_BUG_ON(sizeof(struct iwl_eeprom_enhanced_txpwr) != 8);
+
+ /* the length is in 16-bit words, but we want entries */
+ txp_len = (__le16 *) iwlagn_eeprom_query_addr(priv, EEPROM_TXP_SZ_OFFS);
+ entries = cpu_to_le16p(txp_len) * 2 / EEPROM_TXP_ENTRY_LEN;
+
+ txp_array = (void *) iwlagn_eeprom_query_addr(priv, EEPROM_TXP_OFFS);
+ for (idx = 0; idx < entries; idx++) {
+ txp = &txp_array[idx];
+
+ /* skip invalid entries */
+ if (!(txp->flags & IWL_EEPROM_ENH_TXP_FL_VALID))
+ continue;
+
+ max_txp_avg = iwl_get_max_txpower_avg(priv, txp_array, idx,
+ &max_txp_avg_halfdbm);
/*
- * check for valid entry -
- * different version of EEPROM might contain different set
- * of enhanced tx power table
- * always check for valid entry before process
- * the information
+ * Update the user limit values values to the highest
+ * power supported by any channel
*/
- if (!(enhanced_txpower->flags || enhanced_txpower->channel) ||
- enhanced_txpower->delta_20_in_40)
- continue;
+ if (max_txp_avg > priv->tx_power_user_lmt)
+ priv->tx_power_user_lmt = max_txp_avg;
+ if (max_txp_avg_halfdbm > priv->tx_power_lmt_in_half_dbm)
+ priv->tx_power_lmt_in_half_dbm = max_txp_avg_halfdbm;
- for (element = 0; element < eeprom_section_count; element++) {
- if (enhinfo[section].is_common)
- max_txpower_avg =
- iwl_update_common_txpower(priv,
- enhanced_txpower, section,
- element,
- &max_txpower_in_half_dbm);
- else
- max_txpower_avg =
- iwl_update_channel_txpower(priv,
- enhanced_txpower, section,
- element,
- &max_txpower_in_half_dbm);
-
- /* Update the tx_power_user_lmt to the highest power
- * supported by any channel */
- if (max_txpower_avg > priv->tx_power_user_lmt)
- priv->tx_power_user_lmt = max_txpower_avg;
-
- /*
- * Update the tx_power_lmt_in_half_dbm to
- * the highest power supported by any channel
- */
- if (max_txpower_in_half_dbm >
- priv->tx_power_lmt_in_half_dbm)
- priv->tx_power_lmt_in_half_dbm =
- max_txpower_in_half_dbm;
- }
+ iwlcore_eeprom_enh_txp_read_element(priv, txp, max_txp_avg);
}
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index b555edd..554afb7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -569,6 +569,12 @@ static u32 eeprom_indirect_address(const struct iwl_priv *priv, u32 address)
case INDIRECT_REGULATORY:
offset = iwl_eeprom_query16(priv, EEPROM_LINK_REGULATORY);
break;
+ case INDIRECT_TXP_LIMIT:
+ offset = iwl_eeprom_query16(priv, EEPROM_LINK_TXP_LIMIT);
+ break;
+ case INDIRECT_TXP_LIMIT_SIZE:
+ offset = iwl_eeprom_query16(priv, EEPROM_LINK_TXP_LIMIT_SIZE);
+ break;
case INDIRECT_CALIBRATION:
offset = iwl_eeprom_query16(priv, EEPROM_LINK_CALIBRATION);
break;
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 310e345..e3a279d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -120,6 +120,17 @@ struct iwl_eeprom_channel {
s8 max_power_avg; /* max power (dBm) on this chnl, limit 31 */
} __packed;
+enum iwl_eeprom_enhanced_txpwr_flags {
+ IWL_EEPROM_ENH_TXP_FL_VALID = BIT(0),
+ IWL_EEPROM_ENH_TXP_FL_BAND_52G = BIT(1),
+ IWL_EEPROM_ENH_TXP_FL_OFDM = BIT(2),
+ IWL_EEPROM_ENH_TXP_FL_40MHZ = BIT(3),
+ IWL_EEPROM_ENH_TXP_FL_HT_AP = BIT(4),
+ IWL_EEPROM_ENH_TXP_FL_RES1 = BIT(5),
+ IWL_EEPROM_ENH_TXP_FL_RES2 = BIT(6),
+ IWL_EEPROM_ENH_TXP_FL_COMMON_TYPE = BIT(7),
+};
+
/**
* iwl_eeprom_enhanced_txpwr structure
* This structure presents the enhanced regulatory tx power limit layout
@@ -188,6 +199,8 @@ struct iwl_eeprom_enhanced_txpwr {
#define EEPROM_LINK_CALIBRATION (2*0x67)
#define EEPROM_LINK_PROCESS_ADJST (2*0x68)
#define EEPROM_LINK_OTHERS (2*0x69)
+#define EEPROM_LINK_TXP_LIMIT (2*0x6a)
+#define EEPROM_LINK_TXP_LIMIT_SIZE (2*0x6b)
/* agn regulatory - indirect access */
#define EEPROM_REG_BAND_1_CHANNELS ((0x08)\
@@ -391,6 +404,8 @@ struct iwl_eeprom_calib_info {
#define INDIRECT_CALIBRATION 0x00040000
#define INDIRECT_PROCESS_ADJST 0x00050000
#define INDIRECT_OTHERS 0x00060000
+#define INDIRECT_TXP_LIMIT 0x00070000
+#define INDIRECT_TXP_LIMIT_SIZE 0x00080000
#define INDIRECT_ADDRESS 0x00100000
/* General */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] iwlagn: rename enhanced txpower fields
From: Wey-Yi Guy @ 2010-12-07 17:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Johannes Berg, Wey-Yi Guy
In-Reply-To: <1291743428-19642-1-git-send-email-wey-yi.w.guy@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
Some fields we didn't previously use from the
enhanced TX power structure will be needed in
the next patch, so rename them to their correct
names to be able to use them and change code
reading them accordingly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 3 ++-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 10 ++++++----
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index a650bab..9651060 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -419,7 +419,8 @@ void iwlcore_eeprom_enhanced_txpower(struct iwl_priv *priv)
* always check for valid entry before process
* the information
*/
- if (!enhanced_txpower->common || enhanced_txpower->reserved)
+ if (!(enhanced_txpower->flags || enhanced_txpower->channel) ||
+ enhanced_txpower->delta_20_in_40)
continue;
for (element = 0; element < eeprom_section_count; element++) {
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index d9b5906..310e345 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -127,21 +127,23 @@ struct iwl_eeprom_channel {
* Enhanced regulatory tx power portion of eeprom image can be broken down
* into individual structures; each one is 8 bytes in size and contain the
* following information
- * @common: (desc + channel) not used by driver, should _NOT_ be "zero"
+ * @flags: entry flags
+ * @channel: channel number
* @chain_a_max_pwr: chain a max power in 1/2 dBm
* @chain_b_max_pwr: chain b max power in 1/2 dBm
* @chain_c_max_pwr: chain c max power in 1/2 dBm
- * @reserved: not used, should be "zero"
+ * @delta_20_in_40: 20-in-40 deltas (hi/lo)
* @mimo2_max_pwr: mimo2 max power in 1/2 dBm
* @mimo3_max_pwr: mimo3 max power in 1/2 dBm
*
*/
struct iwl_eeprom_enhanced_txpwr {
- __le16 common;
+ u8 flags;
+ u8 channel;
s8 chain_a_max;
s8 chain_b_max;
s8 chain_c_max;
- s8 reserved;
+ u8 delta_20_in_40;
s8 mimo2_max;
s8 mimo3_max;
} __packed;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/3] iwlwifi fix for 2.6.37
From: Wey-Yi Guy @ 2010-12-07 17:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
The original method used to parsing EEPROM Tx Power Table was hardcode and
not forward compatible with newer devices. Fix it here to be layout agnostic
Johannes Berg (2):
iwlagn: rename enhanced txpower fields
iwlagn: implement layout-agnostic EEPROM reading
Wey-Yi Guy (1):
iwlwifi: minor txp entries fix
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
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 265 ++++++-------------------
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 6 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 25 ++-
3 files changed, 87 insertions(+), 209 deletions(-)
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Johannes Berg @ 2010-12-07 17:32 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, Amod Bodas, pstew@google.com,
stable@kernel.org
In-Reply-To: <20101207155916.GA1855@tux>
On Tue, 2010-12-07 at 07:59 -0800, Luis R. Rodriguez wrote:
> @@ -301,7 +301,7 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
> }
>
> mutex_lock(&local->mtx);
> - ieee80211_recalc_idle(local);
> + ieee80211_recalc_idle_force(local);
> mutex_unlock(&local->mtx);
This is the change that I don't think is necessary.
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Johannes Berg @ 2010-12-07 17:31 UTC (permalink / raw)
To: Paul Stewart
Cc: Luis R. Rodriguez, linville, linux-wireless, amod.bodas, stable
In-Reply-To: <AANLkTinXPOgOJB0ntHra4B_V0z9Qux2yrdiuqkyW7WuJ@mail.gmail.com>
On Tue, 2010-12-07 at 09:28 -0800, Paul Stewart wrote:
> > Actually I believe it happens _during_ ifdown, but when the running bit
> > is already cleared, so I guess this is about right -- although it
> > shouldn't matter since the recalc_idle in do_stop should catch it later.
>
> So the scenario is as follows. If you down an interface
> ieee80211_do_stop() first decrements local->open_count, then later
> calls __ieee80211_recalc_idle, et al. This means that later in this
> call graph if ieee80211_hw_config() finally gets called, open_count is
> already 0 and therefore drv_config is never called. Luis' reference
> to scan_completed() above is probable in reference to older versions
> of compat where ieee80211_stop() called ieee80211_scan_cancel()
> directly. My admittedly casual look at wireless-testing seems to
> imply that path may not exist in current compat, although my tests
> seem to indicate the same class of problem still exists.
Yeah I can see how a problem like this happens -- but I think the change
in scan_finished() is pointless because it'll be handled during
do_stop() anyway.
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Paul Stewart @ 2010-12-07 17:28 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, linville, linux-wireless, amod.bodas, stable
In-Reply-To: <1291735415.3607.46.camel@jlt3.sipsolutions.net>
On Tue, Dec 7, 2010 at 7:23 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2010-12-07 at 07:20 -0800, Paul Stewart wrote:
>> On Tue, Dec 7, 2010 at 1:38 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > On Mon, 2010-12-06 at 18:48 -0800, Luis R. Rodriguez wrote:
>> >> --- a/net/mac80211/pm.c
>> >> +++ b/net/mac80211/pm.c
>> >> @@ -301,7 +301,7 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
>> >> }
>> >>
>> >> mutex_lock(&local->mtx);
>> >> - ieee80211_recalc_idle(local);
>> >> + ieee80211_recalc_idle_force(local);
>> >
>> > Does this really occur afterwards closing interfaces?
>>
>> It appears possible using wpa_supplicant with nl80211, at least using
>> the new DBus API.
>
> Actually I believe it happens _during_ ifdown, but when the running bit
> is already cleared, so I guess this is about right -- although it
> shouldn't matter since the recalc_idle in do_stop should catch it later.
So the scenario is as follows. If you down an interface
ieee80211_do_stop() first decrements local->open_count, then later
calls __ieee80211_recalc_idle, et al. This means that later in this
call graph if ieee80211_hw_config() finally gets called, open_count is
already 0 and therefore drv_config is never called. Luis' reference
to scan_completed() above is probable in reference to older versions
of compat where ieee80211_stop() called ieee80211_scan_cancel()
directly. My admittedly casual look at wireless-testing seems to
imply that path may not exist in current compat, although my tests
seem to indicate the same class of problem still exists.
--
Paul
^ permalink raw reply
* Re: [PATCH 2/2] ath9k_htc: Fix suspend/resume
From: Luis R. Rodriguez @ 2010-12-07 17:25 UTC (permalink / raw)
To: Sujith; +Cc: John W. Linville, linux-wireless
In-Reply-To: <19709.62713.669075.259794@gargle.gargle.HOWL>
On Tue, Dec 7, 2010 at 12:48 AM, Sujith <m.sujith@gmail.com> wrote:
> Luis R. Rodriguez wrote:
>> Hm, well I was thinking more along the lines of what
>> ath9k_htc_config() already does with IEEE80211_CONF_CHANGE_IDLE when
>> enabling the radio. That seems right.
>
> Not sure, maybe ath9k has issues handling CONF_IDLE.
Well ath9k was fine with enabling the radio, the issue was with it not
getting a now we're idle notification later on in certain cases.
Luis
^ permalink raw reply
* Re: [PATCH] ath9k: Check for NULL sta in ath_tx_start
From: Ben Greear @ 2010-12-07 17:13 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Vasanth Thiagarajan, Luis R. Rodriguez, greearb@gmail.com,
linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
In-Reply-To: <20101207083147.GA19720@vasanth-laptop>
On 12/07/2010 12:31 AM, Vasanthakumar Thiagarajan wrote:
> On Tue, Dec 07, 2010 at 01:19:22PM +0530, Ben Greear wrote:
>> On 12/06/2010 11:42 PM, Vasanthakumar Thiagarajan wrote:
>>> On Tue, Dec 07, 2010 at 11:06:24AM +0530, Ben Greear wrote:
>>>> On 12/06/2010 09:21 PM, Luis R. Rodriguez wrote:
>>>>> On Mon, Dec 6, 2010 at 9:13 PM,<greearb@gmail.com> wrote:
>>>>>> From: Ben Greear<greearb@candelatech.com>
>>>>>>
>>>>>> It can be NULL according to docs, and logging showed it
>>>>>> to be NULL in practice.
>>>>>>
>>>>>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>>>>>
>>>>> Does this fix an oops? If so can you explain and provide the trace and
>>>>> resubmit and cc stable in the commit log?
>>>>
>>>> I think it fixes the TID corruption I posted about earlier. It seems
>>>> so obvious though, that I'm curious why no one else sees problems,
>>>> and why I didn't see more crashes in my setup.
>>>>
>>>> (The paprd code appears to send with null STA, for instance, and my
>>>> printks showed lots of NULL stas in my 16-sta test setup, though I
>>>> don't think I'm using the paprd code path.)
>>>
>>> paprd is used only with>= AR9003.
>>
>> Whoever coded it up hopefully had that hardware...so why didn't
>> they see lots of crashes?
>
> I myself tested it lot of times, but did not see any crash, weird.
Looks like the offending change when in recently (11/4/10, one of Felix's
patches).
That is probably why no one else is hitting this yet, and it
isn't needed for stable I'm guessing....
Thanks,
Ben
>
> Vasanth
>
>>
>> Thanks,
>> Ben
>>
>>>
>>> Vasanth
>>
>>
>> --
>> Ben Greear<greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
> --
> 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
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [linux-next] next-20101207: Better now, but modinfo ath5k
From: Sedat Dilek @ 2010-12-07 16:20 UTC (permalink / raw)
To: John W. Linville
Cc: wireless, LKML, Stephen Rothwell, Nick Kossifidis, Bruno Randolf,
ath5k-devel
In-Reply-To: <20101207155924.GC2700@tuxdriver.com>
On Tue, Dec 7, 2010 at 4:59 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Dec 07, 2010 at 04:57:08PM +0100, Sedat Dilek wrote:
>> On Tue, Dec 7, 2010 at 3:26 PM, John W. Linville <linville@tuxdriver.com> wrote:
>> > On Tue, Dec 07, 2010 at 12:24:14PM +0100, Sedat Dilek wrote:
>> >
>> >> I have already reported on linux-wireless (short: l-w) ML that after
>> >> especially the merge of "AHB Bus support" patchset (see [2]) my ath5k
>> >> was not working as expected in daily use (also modinfo).
>> >>
>> >> I am not sure if it is the driver but reverting the 9 commits in my
>> >> local linux-next GIT seemed to "stabilize" a bit the Internet
>> >> connection.
>> >> The patchset from Nick (see below) definitely helped to stabilize ath5k.
>> >
>> > I imagine that these are the "9 commits" you mean:
>> >
>> >> git rev-list c30ae13..4cebb34
>> > 4cebb34caa5122216a1e2451eae9e0fc47ec2589
>> > a0b907ee2a71052fefdf6151764095f3f97b3275
>> > c31b5c9c806b1fbdc9e98885d897664a0d482989
>> > e7aecd327d80b2f156b54769013aaccb2a20645a
>> > 8efa5d7d6ad307ae2d220def37ca89594062c40d
>> > 4aa5d783c9e1c72e4950ff34f388077ccecac74a
>> > e5b046d86fac609f636d127a38de94a175c7e83b
>> > 132b1c3ee38ea6fa0501004fd0f19acb554e5a44
>> > aeae4ac9090462ea38387dcdbac4f01b944af6a4
>> >
>> > Most of those look fairly harmless so long as you don't define
>> > CONFIG_ATHEROS_AR231X. Just to narrow things down...if you only revert
>> > the first 8 (i.e. leave aeae4ac alone), do you still have problems?
>> > Or does it still "stabilize"?
>> >
>> > That patch converts the driver to the generic DMA API. It seems
>> > OK at first glance, but I suspect it is the only one likely to be
>> > effecting your situation.
>> >
>> > John
>> > --
>> > John W. Linville Someday the world will need a hero, and you
>> > linville@tuxdriver.com might be all we have. Be ready.
>> >
>>
>> Before jumping to another problem, I had a quick look into the
>> appropriate Kconfig file, as you say I have not CONFIG_ATHEROS_AR231X
>> set and that's why AHB support is not selected/built, instead
>>
>> CC [M] drivers/net/wireless/ath/ath5k/pci.o
>>
>> is built.
>>
>> Unfortunately, I can't cleanly revert. Sorry, I can't help.
>
> I don't quite understand -- you said you were reverting them before,
> but now I ask you to revert one _less_ patch (i.e. the last one to
> be reverted anyway) and you can't do it?
>
> John
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
>
After AHB-support patches went into linux-next (next-20101207), there
are now new ath5k patches touching
"drivers/net/wireless/ath/ath5k/base.c" on top.
For example the patchset from Nick, this would mean revert them, too.
Doing so, won't give you a clear answer.
BTW, 0008 patch has a big change:
drivers/net/wireless/ath/ath5k/base.c | 344 +++++++++++++------------------
Another solution would be to take a previous linux-next where those
patches were not in.
As you say by yourself 0001..0008 do not hurt, it's 0009 patch (first
in patchset) you are speculating on.
As I have archived my "compiled" build-trees, I can look at them.
AFAICS linux-next (next-20101203) should have wireless-next-2.6
(master-2010-12-02) [1] included.
Also, I have to find the fitting linux-image binary and install it,
hope I have not purged it from hdd.
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=shortlog;h=refs/tags/master-2010-12-02
$ ls revert-ath5k-patches/000*
revert-ath5k-patches/0001-Revert-ath5k-Fix-reset-and-interrupts-for-AHB-type-o.patch
revert-ath5k-patches/0002-Revert-ath5k-Add-AHB-bus-support.patch
revert-ath5k-patches/0003-Revert-ath5k-Add-initial-registers-values-for-radio-.patch
revert-ath5k-patches/0004-Revert-ath5k-Add-a-function-to-read-chipset-s-MAC-re.patch
revert-ath5k-patches/0005-Revert-ath5k-Check-if-pci-pdev-struct-is-initialized.patch
revert-ath5k-patches/0006-Revert-ath5k-Use-generic-eeprom-read-from-common-ath.patch
revert-ath5k-patches/0007-Revert-ath5k-Move-PCI-bus-functions-to-separate-file.patch
revert-ath5k-patches/0008-Revert-ath5k-Introduce-ath5k_init_softc-function-as-.patch
revert-ath5k-patches/0009-Revert-ath5k-Use-Generic-DMA-for-later-support-of-AH.patch
^ permalink raw reply
* Re: [linux-next] next-20101207: Better now, but modinfo ath5k
From: John W. Linville @ 2010-12-07 15:59 UTC (permalink / raw)
To: sedat.dilek
Cc: wireless, LKML, Stephen Rothwell, Nick Kossifidis, Bruno Randolf,
ath5k-devel
In-Reply-To: <AANLkTinjx-+Fv-1CKx6pJwx2FcxiH7skEsqDQtETtBUT@mail.gmail.com>
On Tue, Dec 07, 2010 at 04:57:08PM +0100, Sedat Dilek wrote:
> On Tue, Dec 7, 2010 at 3:26 PM, John W. Linville <linville@tuxdriver.com> wrote:
> > On Tue, Dec 07, 2010 at 12:24:14PM +0100, Sedat Dilek wrote:
> >
> >> I have already reported on linux-wireless (short: l-w) ML that after
> >> especially the merge of "AHB Bus support" patchset (see [2]) my ath5k
> >> was not working as expected in daily use (also modinfo).
> >>
> >> I am not sure if it is the driver but reverting the 9 commits in my
> >> local linux-next GIT seemed to "stabilize" a bit the Internet
> >> connection.
> >> The patchset from Nick (see below) definitely helped to stabilize ath5k.
> >
> > I imagine that these are the "9 commits" you mean:
> >
> >> git rev-list c30ae13..4cebb34
> > 4cebb34caa5122216a1e2451eae9e0fc47ec2589
> > a0b907ee2a71052fefdf6151764095f3f97b3275
> > c31b5c9c806b1fbdc9e98885d897664a0d482989
> > e7aecd327d80b2f156b54769013aaccb2a20645a
> > 8efa5d7d6ad307ae2d220def37ca89594062c40d
> > 4aa5d783c9e1c72e4950ff34f388077ccecac74a
> > e5b046d86fac609f636d127a38de94a175c7e83b
> > 132b1c3ee38ea6fa0501004fd0f19acb554e5a44
> > aeae4ac9090462ea38387dcdbac4f01b944af6a4
> >
> > Most of those look fairly harmless so long as you don't define
> > CONFIG_ATHEROS_AR231X. Just to narrow things down...if you only revert
> > the first 8 (i.e. leave aeae4ac alone), do you still have problems?
> > Or does it still "stabilize"?
> >
> > That patch converts the driver to the generic DMA API. It seems
> > OK at first glance, but I suspect it is the only one likely to be
> > effecting your situation.
> >
> > John
> > --
> > John W. Linville Someday the world will need a hero, and you
> > linville@tuxdriver.com might be all we have. Be ready.
> >
>
> Before jumping to another problem, I had a quick look into the
> appropriate Kconfig file, as you say I have not CONFIG_ATHEROS_AR231X
> set and that's why AHB support is not selected/built, instead
>
> CC [M] drivers/net/wireless/ath/ath5k/pci.o
>
> is built.
>
> Unfortunately, I can't cleanly revert. Sorry, I can't help.
I don't quite understand -- you said you were reverting them before,
but now I ask you to revert one _less_ patch (i.e. the last one to
be reverted anyway) and you can't do it?
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 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Luis R. Rodriguez @ 2010-12-07 15:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, Amod Bodas, pstew@google.com,
stable@kernel.org
In-Reply-To: <1291737298.3607.48.camel@jlt3.sipsolutions.net>
On Tue, Dec 07, 2010 at 07:54:58AM -0800, Johannes Berg wrote:
> On Tue, 2010-12-07 at 07:51 -0800, Luis R. Rodriguez wrote:
>
> > >> >> drv_stop(local);
> > >> >> + ieee80211_recalc_idle_force(local);
>
> > > Because you can't call into drivers after you stop them? Shouldn't this
> > > be obvious?
> >
> > That makes sense, but mac80211 is the one who tells the driver when
> > its idle or non-idle, if we stop the device do we want it to handle an
> > idle check itself? This change would only force out an idle change
> > notification, nothing else.
>
> I don't get what you're saying at all. Can you look at the code lines I
> quoted again?
Yes, I did. Anyway here is a v2 with the changes you outlined incorporated.
>From d8983b423b24037e8e847fa45778d9313af3e057 Mon Sep 17 00:00:00 2001
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Date: Mon, 6 Dec 2010 18:04:03 -0800
Subject: [PATCH v2] mac80211: fix issuing idle calls when device open count is 0
There are a few places where mac80211 may issue a hw config
but the hw config will be ignored and got into a black hole if
the device count is already 0. Further hw config calls will also
be discarded as the device is already marked as idle, in these
cases mac80211 assumes the radio is idle but the driver never
really got the notification. We need to ensure that places that
will call a hw reconfig with open_count set to 0 will send the
notification to the driver. This forces these checks in a few
other key missing places.
Without this suspend and resume is broken on devices which require
notifying the driver to become idle once the open_count already
has reached 0. This fixes suspend/resume when using new DBus APIs
are used which idle the device in places which had not yet gotten
widely tested.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/mac80211/ieee80211_i.h | 16 +++++++++++++++-
net/mac80211/iface.c | 4 ++--
net/mac80211/scan.c | 2 +-
net/mac80211/util.c | 1 +
4 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index ae32349..873ec88 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1132,8 +1132,21 @@ int ieee80211_if_change_type(struct ieee80211_sub_if_data *sdata,
enum nl80211_iftype type);
void ieee80211_if_remove(struct ieee80211_sub_if_data *sdata);
void ieee80211_remove_interfaces(struct ieee80211_local *local);
+
u32 __ieee80211_recalc_idle(struct ieee80211_local *local);
-void ieee80211_recalc_idle(struct ieee80211_local *local);
+void ieee80211_recalc_idle_check(struct ieee80211_local *local, bool force);
+
+static inline void ieee80211_recalc_idle(struct ieee80211_local *local)
+{
+ ieee80211_recalc_idle_check(local, false);
+}
+
+static inline void ieee80211_recalc_idle_force(struct ieee80211_local *local)
+
+{
+ ieee80211_recalc_idle_check(local, true);
+}
+
void ieee80211_adjust_monitor_flags(struct ieee80211_sub_if_data *sdata,
const int offset);
@@ -1211,6 +1224,7 @@ void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
/* Suspend/resume and hw reconfiguration */
int ieee80211_reconfig(struct ieee80211_local *local);
+void ieee80211_recalc_idle_force(struct ieee80211_local *local);
void ieee80211_stop_device(struct ieee80211_local *local);
#ifdef CONFIG_PM
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 36b7000..2803a7a 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1320,7 +1320,7 @@ u32 __ieee80211_recalc_idle(struct ieee80211_local *local)
return 0;
}
-void ieee80211_recalc_idle(struct ieee80211_local *local)
+void ieee80211_recalc_idle_check(struct ieee80211_local *local, bool force)
{
u32 chg;
@@ -1328,7 +1328,7 @@ void ieee80211_recalc_idle(struct ieee80211_local *local)
chg = __ieee80211_recalc_idle(local);
mutex_unlock(&local->iflist_mtx);
if (chg)
- ieee80211_hw_config(local, chg);
+ __ieee80211_hw_config(local, chg, force);
}
static int netdev_notify(struct notifier_block *nb,
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index fb274db..30cd2a0 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -301,7 +301,7 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
}
mutex_lock(&local->mtx);
- ieee80211_recalc_idle(local);
+ ieee80211_recalc_idle_force(local);
mutex_unlock(&local->mtx);
ieee80211_mlme_notify_scan_completed(local);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index e497476..a4184eb 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1120,6 +1120,7 @@ void ieee80211_stop_device(struct ieee80211_local *local)
cancel_work_sync(&local->reconfig_filter);
flush_workqueue(local->workqueue);
+ ieee80211_recalc_idle_force(local);
drv_stop(local);
}
--
1.7.3.2.90.gd4c43
^ permalink raw reply related
* Re: [linux-next] next-20101207: Better now, but modinfo ath5k
From: Sedat Dilek @ 2010-12-07 15:57 UTC (permalink / raw)
To: John W. Linville
Cc: wireless, LKML, Stephen Rothwell, Nick Kossifidis, Bruno Randolf,
ath5k-devel
In-Reply-To: <20101207142639.GB2700@tuxdriver.com>
On Tue, Dec 7, 2010 at 3:26 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Dec 07, 2010 at 12:24:14PM +0100, Sedat Dilek wrote:
>
>> I have already reported on linux-wireless (short: l-w) ML that after
>> especially the merge of "AHB Bus support" patchset (see [2]) my ath5k
>> was not working as expected in daily use (also modinfo).
>>
>> I am not sure if it is the driver but reverting the 9 commits in my
>> local linux-next GIT seemed to "stabilize" a bit the Internet
>> connection.
>> The patchset from Nick (see below) definitely helped to stabilize ath5k.
>
> I imagine that these are the "9 commits" you mean:
>
>> git rev-list c30ae13..4cebb34
> 4cebb34caa5122216a1e2451eae9e0fc47ec2589
> a0b907ee2a71052fefdf6151764095f3f97b3275
> c31b5c9c806b1fbdc9e98885d897664a0d482989
> e7aecd327d80b2f156b54769013aaccb2a20645a
> 8efa5d7d6ad307ae2d220def37ca89594062c40d
> 4aa5d783c9e1c72e4950ff34f388077ccecac74a
> e5b046d86fac609f636d127a38de94a175c7e83b
> 132b1c3ee38ea6fa0501004fd0f19acb554e5a44
> aeae4ac9090462ea38387dcdbac4f01b944af6a4
>
> Most of those look fairly harmless so long as you don't define
> CONFIG_ATHEROS_AR231X. Just to narrow things down...if you only revert
> the first 8 (i.e. leave aeae4ac alone), do you still have problems?
> Or does it still "stabilize"?
>
> That patch converts the driver to the generic DMA API. It seems
> OK at first glance, but I suspect it is the only one likely to be
> effecting your situation.
>
> John
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
>
Before jumping to another problem, I had a quick look into the
appropriate Kconfig file, as you say I have not CONFIG_ATHEROS_AR231X
set and that's why AHB support is not selected/built, instead
CC [M] drivers/net/wireless/ath/ath5k/pci.o
is built.
Unfortunately, I can't cleanly revert. Sorry, I can't help.
- Sedat -
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch 0001-Revert-Add-ath5k-Use-capabilities-information-for-th.patch
patching file drivers/net/wireless/ath/ath5k/base.c
patching file drivers/net/wireless/ath/ath5k/qcu.c
Now at patch 0001-Revert-Add-ath5k-Use-capabilities-information-for-th.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0001-Revert-ath5k-Fix-reset-and-interrupts-for-AHB-type-o.patch
patching file drivers/net/wireless/ath/ath5k/base.c
patching file drivers/net/wireless/ath/ath5k/reset.c
Now at patch revert-ath5k-patches/0001-Revert-ath5k-Fix-reset-and-interrupts-for-AHB-type-o.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0002-Revert-ath5k-Add-AHB-bus-support.patch
patching file drivers/net/wireless/ath/ath5k/Kconfig
patching file drivers/net/wireless/ath/ath5k/Makefile
patching file drivers/net/wireless/ath/ath5k/ahb.c
patching file drivers/net/wireless/ath/ath5k/ath5k.h
patching file drivers/net/wireless/ath/ath5k/base.c
patching file drivers/net/wireless/ath/ath5k/led.c
patching file drivers/net/wireless/ath/ath5k/reg.h
Now at patch revert-ath5k-patches/0002-Revert-ath5k-Add-AHB-bus-support.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0003-Revert-ath5k-Add-initial-registers-values-for-radio-.patch
patching file drivers/net/wireless/ath/ath5k/initvals.c
Now at patch revert-ath5k-patches/0003-Revert-ath5k-Add-initial-registers-values-for-radio-.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0004-Revert-ath5k-Add-a-function-to-read-chipset-s-MAC-re.patch
patching file drivers/net/wireless/ath/ath5k/ath5k.h
patching file drivers/net/wireless/ath/ath5k/attach.c
patching file drivers/net/wireless/ath/ath5k/pci.c
Now at patch revert-ath5k-patches/0004-Revert-ath5k-Add-a-function-to-read-chipset-s-MAC-re.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0005-Revert-ath5k-Check-if-pci-pdev-struct-is-initialized.patch
patching file drivers/net/wireless/ath/ath5k/attach.c
patching file drivers/net/wireless/ath/ath5k/led.c
patching file drivers/net/wireless/ath/ath5k/reset.c
patching file drivers/net/wireless/ath/ath5k/sysfs.c
Now at patch revert-ath5k-patches/0005-Revert-ath5k-Check-if-pci-pdev-struct-is-initialized.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0006-Revert-ath5k-Use-generic-eeprom-read-from-common-ath.patch
patching file drivers/net/wireless/ath/ath5k/ath5k.h
patching file drivers/net/wireless/ath/ath5k/eeprom.c
patching file drivers/net/wireless/ath/ath5k/eeprom.h
patching file drivers/net/wireless/ath/ath5k/pci.c
Now at patch revert-ath5k-patches/0006-Revert-ath5k-Use-generic-eeprom-read-from-common-ath.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0007-Revert-ath5k-Move-PCI-bus-functions-to-separate-file.patch
patching file drivers/net/wireless/ath/ath5k/Makefile
patching file drivers/net/wireless/ath/ath5k/ath5k.h
patching file drivers/net/wireless/ath/ath5k/base.c
Hunk #5 succeeded at 3636 (offset 9 lines).
patching file drivers/net/wireless/ath/ath5k/pci.c
Now at patch revert-ath5k-patches/0007-Revert-ath5k-Move-PCI-bus-functions-to-separate-file.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none$
LC_ALL=C quilt -f push
Applying patch revert-ath5k-patches/0008-Revert-ath5k-Introduce-ath5k_init_softc-function-as-.patch
patching file drivers/net/wireless/ath/ath5k/ath5k.h
patching file drivers/net/wireless/ath/ath5k/attach.c
patching file drivers/net/wireless/ath/ath5k/base.c
Hunk #4 FAILED at 2338.
Hunk #5 succeeded at 2530 (offset 1 line).
Hunk #6 succeeded at 2736 (offset 9 lines).
Hunk #7 succeeded at 2745 (offset 9 lines).
Hunk #8 succeeded at 2886 (offset 9 lines).
Hunk #9 succeeded at 2904 (offset 9 lines).
Hunk #10 succeeded at 2916 (offset 9 lines).
Hunk #11 succeeded at 2938 (offset 9 lines).
Hunk #12 succeeded at 3583 (offset 9 lines).
Hunk #13 succeeded at 3617 (offset 9 lines).
Hunk #14 succeeded at 3713 (offset 9 lines).
Hunk #15 succeeded at 3868 (offset 9 lines).
1 out of 15 hunks FAILED -- saving rejects to file
drivers/net/wireless/ath/ath5k/base.c.rej
patching file drivers/net/wireless/ath/ath5k/base.h
patching file drivers/net/wireless/ath/ath5k/eeprom.c
Applied patch revert-ath5k-patches/0008-Revert-ath5k-Introduce-ath5k_init_softc-function-as-.patch
(forced; needs refresh)
- EOT -
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Johannes Berg @ 2010-12-07 15:54 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, amod.bodas, pstew, stable
In-Reply-To: <AANLkTimiw074uXxe3nPTNZ0j+NtZbHJU1bwiGsFUXMJ4@mail.gmail.com>
On Tue, 2010-12-07 at 07:51 -0800, Luis R. Rodriguez wrote:
> >> >> drv_stop(local);
> >> >> + ieee80211_recalc_idle_force(local);
> > Because you can't call into drivers after you stop them? Shouldn't this
> > be obvious?
>
> That makes sense, but mac80211 is the one who tells the driver when
> its idle or non-idle, if we stop the device do we want it to handle an
> idle check itself? This change would only force out an idle change
> notification, nothing else.
I don't get what you're saying at all. Can you look at the code lines I
quoted again?
johannes
^ permalink raw reply
* [PATCH v2] ath9k: Remove dead code in recv.c
From: Mohammed Shafi Shajakhan @ 2010-12-07 15:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, lrodriguez, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
The structure struct ieee80211_rx_status *rxs is no longer needed to be
passed to ath_rx_send_to_mac80211 function
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 262c815..a14515a 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -660,8 +660,7 @@ static void ath_rx_ps(struct ath_softc *sc, struct sk_buff *skb)
}
static void ath_rx_send_to_mac80211(struct ieee80211_hw *hw,
- struct ath_softc *sc, struct sk_buff *skb,
- struct ieee80211_rx_status *rxs)
+ struct ath_softc *sc, struct sk_buff *skb)
{
struct ieee80211_hdr *hdr;
@@ -1618,7 +1617,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
/*
- * The hw can techncically differ from common->hw when using ath9k
+ * The hw can technically differ from common->hw when using ath9k
* virtual wiphy so to account for that we iterate over the active
* wiphys and find the appropriate wiphy and therefore hw.
*/
@@ -1727,7 +1726,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
bf->bf_buf_addr = 0;
ath_print(common, ATH_DBG_FATAL,
"dma_mapping_error() on RX\n");
- ath_rx_send_to_mac80211(hw, sc, skb, rxs);
+ ath_rx_send_to_mac80211(hw, sc, skb);
break;
}
@@ -1753,7 +1752,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB)
ath_ant_comb_scan(sc, &rs);
- ath_rx_send_to_mac80211(hw, sc, skb, rxs);
+ ath_rx_send_to_mac80211(hw, sc, skb);
requeue:
if (edma) {
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Luis R. Rodriguez @ 2010-12-07 15:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, amod.bodas, pstew, stable
In-Reply-To: <1291736887.3607.47.camel@jlt3.sipsolutions.net>
On Tue, Dec 7, 2010 at 7:48 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2010-12-07 at 07:44 -0800, Luis R. Rodriguez wrote:
>
>> >> drv_stop(local);
>> >> + ieee80211_recalc_idle_force(local);
>> >
>> > That one definitely can't be after drv_stop().
>>
>> OK why though?
>
> Because you can't call into drivers after you stop them? Shouldn't this
> be obvious?
That makes sense, but mac80211 is the one who tells the driver when
its idle or non-idle, if we stop the device do we want it to handle an
idle check itself? This change would only force out an idle change
notification, nothing else.
Luis
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Johannes Berg @ 2010-12-07 15:48 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, amod.bodas, pstew, stable
In-Reply-To: <AANLkTikrLweKeSR-=XziaJ5rqDRf_Ny=mg1OD=jC4nqA@mail.gmail.com>
On Tue, 2010-12-07 at 07:44 -0800, Luis R. Rodriguez wrote:
> >> drv_stop(local);
> >> + ieee80211_recalc_idle_force(local);
> >
> > That one definitely can't be after drv_stop().
>
> OK why though?
Because you can't call into drivers after you stop them? Shouldn't this
be obvious?
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Luis R. Rodriguez @ 2010-12-07 15:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, amod.bodas, pstew, stable
In-Reply-To: <1291714709.3607.2.camel@jlt3.sipsolutions.net>
On Tue, Dec 7, 2010 at 1:38 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2010-12-06 at 18:48 -0800, Luis R. Rodriguez wrote:
>> There are a few places where mac80211 may issue a hw config
>> but the hw config will be ignored and got into a black hole if
>> the device count is already 0. Further hw config calls will also
>> be discarded as the device is already marked as idle, in these
>> cases mac80211 assumes the radio is idle but the driver never
>> really got the notification. We need to ensure that places that
>> will call a hw reconfig with open_count set to 0 will send the
>> notification to the driver. This forces these checks in a few
>> other key missing places.
>>
>> Without this suspend and resume is broken on devices which require
>> notifying the driver to become idle once the open_count already
>> has reached 0. This fixes suspend/resume when using new DBus APIs
>> are used which idle the device in places which had not yet gotten
>> widely tested.
>>
>> Cc: stable@kernel.org
>> Cc: Paul Stewart <pstew@google.com>
>> Cc: Amod Bodas <amod.bodas@atheros.com>
>> Cc: Johannes Berg <johannes.berg@intel.com>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> net/mac80211/ieee80211_i.h | 1 +
>> net/mac80211/iface.c | 16 ++++++++++++++--
>> net/mac80211/pm.c | 2 ++
>> net/mac80211/scan.c | 2 +-
>> net/mac80211/util.c | 1 +
>> 5 files changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
>> index ae32349..78ab6ff 100644
>> --- a/net/mac80211/ieee80211_i.h
>> +++ b/net/mac80211/ieee80211_i.h
>> @@ -1211,6 +1211,7 @@ void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
>>
>> /* Suspend/resume and hw reconfiguration */
>> int ieee80211_reconfig(struct ieee80211_local *local);
>> +void ieee80211_recalc_idle_force(struct ieee80211_local *local);
>> void ieee80211_stop_device(struct ieee80211_local *local);
>>
>> #ifdef CONFIG_PM
>> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
>> index 36b7000..a590bae 100644
>> --- a/net/mac80211/iface.c
>> +++ b/net/mac80211/iface.c
>> @@ -1320,7 +1320,8 @@ u32 __ieee80211_recalc_idle(struct ieee80211_local *local)
>> return 0;
>> }
>>
>> -void ieee80211_recalc_idle(struct ieee80211_local *local)
>> +static void ieee80211_recalc_idle_check(struct ieee80211_local *local,
>> + bool force)
>> {
>> u32 chg;
>>
>> @@ -1328,7 +1329,18 @@ void ieee80211_recalc_idle(struct ieee80211_local *local)
>> chg = __ieee80211_recalc_idle(local);
>> mutex_unlock(&local->iflist_mtx);
>> if (chg)
>> - ieee80211_hw_config(local, chg);
>> + __ieee80211_hw_config(local, chg, force);
>> +}
>> +
>> +void ieee80211_recalc_idle(struct ieee80211_local *local)
>> +{
>> + ieee80211_recalc_idle_check(local, false);
>> +}
>
> I think I'd probably prefer an inline too.
OK
>> --- a/net/mac80211/pm.c
>> +++ b/net/mac80211/pm.c
>> @@ -98,6 +98,8 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>> if (local->open_count)
>> ieee80211_stop_device(local);
>>
>> + ieee80211_recalc_idle_force(local);
>
> Err? You just added a call to stop_device() too,
What if open_count is 0?
> and at the wrong place as well...
I'll fix thanks.
>> @@ -1121,6 +1121,7 @@ void ieee80211_stop_device(struct ieee80211_local *local)
>>
>> flush_workqueue(local->workqueue);
>> drv_stop(local);
>> + ieee80211_recalc_idle_force(local);
>
> That one definitely can't be after drv_stop().
OK why though?
Luis
^ permalink raw reply
* [PATCH] ath9k: Parse DTIM period from mac80211
From: Mohammed Shafi Shajakhan @ 2010-12-07 15:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, lrodriguez, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
With the current save power save implementation we assume a dtim period
of 1.This value is assigned based on a sanity check in the driver
eventhough we had not parsed it from mac80211.This patch obtains the actual
DTIM period from AP by parsing it from mac80211.Yet for handling
multicast traffic we may still have it as fixed rather than parsing it
from mac80211 .This does not breaks power save or anything as the sleep
duration is currently fixed in the driver.This patch may serve to improve
power save in the future by using dtim period for sleep duration and using
correct dtim period adhoc mode.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 ++-
drivers/net/wireless/ath/ath9k/init.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 071d0c9..f42f909 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -721,7 +721,8 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
IEEE80211_HW_HAS_RATE_CONTROL |
IEEE80211_HW_RX_INCLUDES_FCS |
IEEE80211_HW_SUPPORTS_PS |
- IEEE80211_HW_PS_NULLFUNC_STACK;
+ IEEE80211_HW_PS_NULLFUNC_STACK |
+ IEEE80211_HW_NEED_DTIM_PERIOD;
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) |
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 918308a..1a33b11 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -641,7 +641,8 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_SPECTRUM_MGMT |
- IEEE80211_HW_REPORTS_TX_ACK_STATUS;
+ IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+ IEEE80211_HW_NEED_DTIM_PERIOD;
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Johannes Berg @ 2010-12-07 15:23 UTC (permalink / raw)
To: Paul Stewart
Cc: Luis R. Rodriguez, linville, linux-wireless, amod.bodas, stable
In-Reply-To: <AANLkTinZK_xMJUDaDWzOpW7FXUERUNS3Y0btx=WS9KR1@mail.gmail.com>
On Tue, 2010-12-07 at 07:20 -0800, Paul Stewart wrote:
> On Tue, Dec 7, 2010 at 1:38 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Mon, 2010-12-06 at 18:48 -0800, Luis R. Rodriguez wrote:
> >> --- a/net/mac80211/pm.c
> >> +++ b/net/mac80211/pm.c
> >> @@ -301,7 +301,7 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
> >> }
> >>
> >> mutex_lock(&local->mtx);
> >> - ieee80211_recalc_idle(local);
> >> + ieee80211_recalc_idle_force(local);
> >
> > Does this really occur afterwards closing interfaces?
>
> It appears possible using wpa_supplicant with nl80211, at least using
> the new DBus API.
Actually I believe it happens _during_ ifdown, but when the running bit
is already cleared, so I guess this is about right -- although it
shouldn't matter since the recalc_idle in do_stop should catch it later.
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: fix issuing idle calls when device open count is 0
From: Paul Stewart @ 2010-12-07 15:20 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, linville, linux-wireless, amod.bodas, stable
In-Reply-To: <1291714709.3607.2.camel@jlt3.sipsolutions.net>
On Tue, Dec 7, 2010 at 1:38 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2010-12-06 at 18:48 -0800, Luis R. Rodriguez wrote:
>> --- a/net/mac80211/pm.c
>> +++ b/net/mac80211/pm.c
>> @@ -301,7 +301,7 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
>> }
>>
>> mutex_lock(&local->mtx);
>> - ieee80211_recalc_idle(local);
>> + ieee80211_recalc_idle_force(local);
>
> Does this really occur afterwards closing interfaces?
It appears possible using wpa_supplicant with nl80211, at least using
the new DBus API.
--
Paul
^ 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