* Compat-wireless release for 2010-06-30 is baked
From: Compat-wireless cronjob account @ 2010-06-30 19:02 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
4570588..85e0e99 history -> origin/history
+ 1b72384...7a6353a master -> origin/master (forced update)
5904b3b..984bc96 stable -> origin/stable
* [new tag] next-20100630 -> next-20100630
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
494378 - Total upstream lines of code being pulled
^ permalink raw reply
* pull request: wireless-2.6 2010-06-30
From: John W. Linville @ 2010-06-30 18:53 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
David,
Here are a few more fixes intended for 2.6.35. Included are a couple of
small regression fixes for iwlwifi, one that causes connection stalls with
802.11n on some devices and another which could disable multicast traffic.
Also included is an ath9k fix which avoids a null pointer dereference
resulting from a timer leak.
Please let me know if there are problems!
John
---
The following changes since commit d3ead2413cb99d3e6265577b12537434e229d8c2:
Guillaume Gaudonville (1):
ixgbe: skip non IPv4 packets in ATR filter
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (1):
iwlwifi: fix multicast
Vasanthakumar Thiagarajan (1):
ath9k: Fix bug in starting ani
Wey-Yi Guy (1):
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 6 +-----
drivers/net/wireless/iwlwifi/iwl-core.c | 7 ++++++-
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index fbb7dec..5ea8773 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -445,6 +445,7 @@ void ath_deinit_leds(struct ath_softc *sc);
#define SC_OP_TSF_RESET BIT(11)
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
+#define SC_OP_ANI_RUN BIT(14)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index abfa049..1e2a68e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -336,6 +336,10 @@ set_timer:
static void ath_start_ani(struct ath_common *common)
{
unsigned long timestamp = jiffies_to_msecs(jiffies);
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
+
+ if (!(sc->sc_flags & SC_OP_ANI_RUN))
+ return;
common->ani.longcal_timer = timestamp;
common->ani.shortcal_timer = timestamp;
@@ -872,11 +876,13 @@ static void ath9k_bss_assoc_info(struct ath_softc *sc,
/* Reset rssi stats */
sc->sc_ah->stats.avgbrssi = ATH_RSSI_DUMMY_MARKER;
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
} else {
ath_print(common, ATH_DBG_CONFIG, "Bss Info DISASSOC\n");
common->curaid = 0;
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
}
}
@@ -1478,8 +1484,10 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
if (vif->type == NL80211_IFTYPE_AP ||
vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MONITOR)
+ vif->type == NL80211_IFTYPE_MONITOR) {
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
+ }
out:
mutex_unlock(&sc->mutex);
@@ -1500,6 +1508,7 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&sc->mutex);
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
/* Reclaim beacon resources */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
index 44ef5d9..01658cf 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
@@ -212,11 +212,7 @@ static void iwlagn_chain_noise_reset(struct iwl_priv *priv)
static void iwlagn_rts_tx_cmd_flag(struct ieee80211_tx_info *info,
__le32 *tx_flags)
{
- if ((info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) ||
- (info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT))
- *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
- else
- *tx_flags &= ~TX_CMD_FLG_RTS_CTS_MSK;
+ *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
}
/* Calc max signal level (dBm) among 3 possible receivers */
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 426e955..5bbc529 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1314,7 +1314,6 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
changed_flags, *total_flags);
CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
- CHK(FIF_ALLMULTI, RXON_FILTER_ACCEPT_GRP_MSK);
CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
@@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
mutex_unlock(&priv->mutex);
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
*total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
}
--
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 related
* RE: wl1271 firmware
From: Levi, Shahar @ 2010-06-30 13:42 UTC (permalink / raw)
To: Pazzo Da Legare; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinOcy-n6EVzAasAJO1I2yNeWOiaCid0tGdxnuwa@mail.gmail.com>
Hi pz,
I am checking the way to access the FW and NVS file of wl1271.
Let me find more details on that and get back to you.
Regards,
Shahar
-----Original Message-----
From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Pazzo Da Legare
Sent: Wednesday, June 30, 2010 2:27 PM
To: linux-wireless@vger.kernel.org
Subject: wl1271 firmware
Hi all,
I'm looking for wl1271 firmwares. I found wl1271-fw.bin but I cannot
find wl1271-nvs.bin needed to use the wl1271's driver.
Could you please indicate where I can get it?
Thank in advance,
pz
--
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
^ permalink raw reply
* wl1271 firmware
From: Pazzo Da Legare @ 2010-06-30 11:26 UTC (permalink / raw)
To: linux-wireless
Hi all,
I'm looking for wl1271 firmwares. I found wl1271-fw.bin but I cannot
find wl1271-nvs.bin needed to use the wl1271's driver.
Could you please indicate where I can get it?
Thank in advance,
pz
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:57 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20100630105118.GB2192@vasanth-laptop>
On Wed, Jun 30, 2010 at 04:21:19PM +0530, Vasanth Thiagarajan wrote:
> On Wed, Jun 30, 2010 at 03:56:11PM +0530, Johannes Berg wrote:
> > On Wed, 2010-06-30 at 12:17 +0200, Johannes Berg wrote:
> > > On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > > > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > > > on off channel during sw scanning,
> >
> > > That doesn't seem to make sense, since we treat driver and scan stop
> > > status separately via wake_queue_by_reason()
> >
> > IOW, the above assertion would seem to be false already.
>
> Sorry, I mean the existing code assumes that ieee80211_wake_queue() while
> operating on off channel during scanning.
I mean the existing code assumes that ieee80211_wake_queue() is not
supposed to be called while operating on off channel during
scanning as it is not right to pass packets to the drivers when
hw is on different channel.
Vasanth
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:51 UTC (permalink / raw)
To: Johannes Berg
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1277893571.7823.9.camel@jlt3.sipsolutions.net>
On Wed, Jun 30, 2010 at 03:56:11PM +0530, Johannes Berg wrote:
> On Wed, 2010-06-30 at 12:17 +0200, Johannes Berg wrote:
> > On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > > on off channel during sw scanning,
>
> > That doesn't seem to make sense, since we treat driver and scan stop
> > status separately via wake_queue_by_reason()
>
> IOW, the above assertion would seem to be false already.
Sorry, I mean the existing code assumes that ieee80211_wake_queue() while
operating on off channel during scanning.
Vasanth
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:47 UTC (permalink / raw)
To: Johannes Berg
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1277893026.7823.7.camel@jlt3.sipsolutions.net>
On Wed, Jun 30, 2010 at 03:47:06PM +0530, Johannes Berg wrote:
> On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > on off channel during sw scanning, but there is no clear way for
> > the driver to know that it is operating on off channel during scanning.
> > There are cases (unavailablity/availability of tx buffers in ath9k, for
> > example) where driver needs to stop/restart tx queues during background
> > scanning state, this might result in waking up the corresponding netif
> > tx queue when the device is on off channel which is not desired. This
> > patches fixes this by checking SCAN_OFF_CHANNEL bit in scanning before
> > restarting the tx queue.
> >
> > Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> > ---
> > net/mac80211/util.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> > index a54cf14..1938a67 100644
> > --- a/net/mac80211/util.c
> > +++ b/net/mac80211/util.c
> > @@ -277,7 +277,8 @@ static void __ieee80211_wake_queue(struct ieee80211_hw *hw, int queue,
> >
> > __clear_bit(reason, &local->queue_stop_reasons[queue]);
> >
> > - if (local->queue_stop_reasons[queue] != 0)
> > + if ((local->queue_stop_reasons[queue] != 0) ||
> > + test_bit(SCAN_OFF_CHANNEL, &local->scanning))
> > /* someone still has this queue stopped */
> > return;
>
> That doesn't seem to make sense, since we treat driver and scan stop
> status separately via wake_queue_by_reason()
I dont know if I explained the issue properly. The issue here is
waking up the queues by driver during scan, particularly when
operating on off channel. With ath9k, there is a possibility that
ieee80211_wake_queue() can be called while moving from operational
channel (during channel set in driver). In this case driver still
needs to be allowed to clear the bit in queue_stop_reasons[] but
not wake up the tx queue.
Vasanth
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Johannes Berg @ 2010-06-30 10:26 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1277893026.7823.7.camel@jlt3.sipsolutions.net>
On Wed, 2010-06-30 at 12:17 +0200, Johannes Berg wrote:
> On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > on off channel during sw scanning,
> That doesn't seem to make sense, since we treat driver and scan stop
> status separately via wake_queue_by_reason()
IOW, the above assertion would seem to be false already.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Johannes Berg @ 2010-06-30 10:17 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1277892907-2401-1-git-send-email-vasanth@atheros.com>
On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> Drivers are not supposed to call ieee80211_wake_queue() while operating
> on off channel during sw scanning, but there is no clear way for
> the driver to know that it is operating on off channel during scanning.
> There are cases (unavailablity/availability of tx buffers in ath9k, for
> example) where driver needs to stop/restart tx queues during background
> scanning state, this might result in waking up the corresponding netif
> tx queue when the device is on off channel which is not desired. This
> patches fixes this by checking SCAN_OFF_CHANNEL bit in scanning before
> restarting the tx queue.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> ---
> net/mac80211/util.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index a54cf14..1938a67 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -277,7 +277,8 @@ static void __ieee80211_wake_queue(struct ieee80211_hw *hw, int queue,
>
> __clear_bit(reason, &local->queue_stop_reasons[queue]);
>
> - if (local->queue_stop_reasons[queue] != 0)
> + if ((local->queue_stop_reasons[queue] != 0) ||
> + test_bit(SCAN_OFF_CHANNEL, &local->scanning))
> /* someone still has this queue stopped */
> return;
That doesn't seem to make sense, since we treat driver and scan stop
status separately via wake_queue_by_reason()
johannes
^ permalink raw reply
* [PATCH 2/2] ath9k: Call ieee80211_wake_queue() during ATH_WIPHY_SCAN state also
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Along with "mac80211: Dont allow to wake up netif tx queues while on off channel"
this patch fixes a tx hang issue which shows up when starting a background scanning.
The cause for hang is a missed call to ieee80211_wake_queue() after the tx queue
was stopped due to tx buffer shortage.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/virtual.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index 89423ca..2c2f193 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -703,7 +703,8 @@ void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
spin_lock_bh(&sc->wiphy_lock);
/* Start the primary wiphy */
- if (sc->pri_wiphy->state == ATH_WIPHY_ACTIVE) {
+ if ((sc->pri_wiphy->state == ATH_WIPHY_ACTIVE) ||
+ (sc->pri_wiphy->state == ATH_WIPHY_SCAN)) {
ieee80211_wake_queue(hw, skb_queue);
goto unlock;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:15 UTC (permalink / raw)
To: linville; +Cc: johannes, linux-wireless
Drivers are not supposed to call ieee80211_wake_queue() while operating
on off channel during sw scanning, but there is no clear way for
the driver to know that it is operating on off channel during scanning.
There are cases (unavailablity/availability of tx buffers in ath9k, for
example) where driver needs to stop/restart tx queues during background
scanning state, this might result in waking up the corresponding netif
tx queue when the device is on off channel which is not desired. This
patches fixes this by checking SCAN_OFF_CHANNEL bit in scanning before
restarting the tx queue.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
net/mac80211/util.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index a54cf14..1938a67 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -277,7 +277,8 @@ static void __ieee80211_wake_queue(struct ieee80211_hw *hw, int queue,
__clear_bit(reason, &local->queue_stop_reasons[queue]);
- if (local->queue_stop_reasons[queue] != 0)
+ if ((local->queue_stop_reasons[queue] != 0) ||
+ test_bit(SCAN_OFF_CHANNEL, &local->scanning))
/* someone still has this queue stopped */
return;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ath9k_htc: Add LED support for AR7010
From: Sujith @ 2010-06-30 9:16 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc.h | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 34 ++++++++++++++++++++++---
drivers/net/wireless/ath/ath9k/reg.h | 23 +++++++++++++++++
4 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index 58f52a1..3756400 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -287,6 +287,7 @@ struct ath9k_debug {
#define ATH_LED_PIN_DEF 1
#define ATH_LED_PIN_9287 8
#define ATH_LED_PIN_9271 15
+#define ATH_LED_PIN_7010 12
#define ATH_LED_ON_DURATION_IDLE 350 /* in msecs */
#define ATH_LED_OFF_DURATION_IDLE 250 /* in msecs */
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 05445d8..e38ca66 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -931,6 +931,8 @@ void ath9k_init_leds(struct ath9k_htc_priv *priv)
priv->ah->led_pin = ATH_LED_PIN_9287;
else if (AR_SREV_9271(priv->ah))
priv->ah->led_pin = ATH_LED_PIN_9271;
+ else if (AR_DEVID_7010(priv->ah))
+ priv->ah->led_pin = ATH_LED_PIN_7010;
else
priv->ah->led_pin = ATH_LED_PIN_DEF;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1ed1440..3c76ecb 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2176,6 +2176,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9271(ah))
pCap->num_gpio_pins = AR9271_NUM_GPIO;
+ else if (AR_DEVID_7010(ah))
+ pCap->num_gpio_pins = AR7010_NUM_GPIO;
else if (AR_SREV_9285_10_OR_LATER(ah))
pCap->num_gpio_pins = AR9285_NUM_GPIO;
else if (AR_SREV_9280_10_OR_LATER(ah))
@@ -2316,8 +2318,15 @@ void ath9k_hw_cfg_gpio_input(struct ath_hw *ah, u32 gpio)
BUG_ON(gpio >= ah->caps.num_gpio_pins);
- gpio_shift = gpio << 1;
+ if (AR_DEVID_7010(ah)) {
+ gpio_shift = gpio;
+ REG_RMW(ah, AR7010_GPIO_OE,
+ (AR7010_GPIO_OE_AS_INPUT << gpio_shift),
+ (AR7010_GPIO_OE_MASK << gpio_shift));
+ return;
+ }
+ gpio_shift = gpio << 1;
REG_RMW(ah,
AR_GPIO_OE_OUT,
(AR_GPIO_OE_OUT_DRV_NO << gpio_shift),
@@ -2333,7 +2342,11 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah, u32 gpio)
if (gpio >= ah->caps.num_gpio_pins)
return 0xffffffff;
- if (AR_SREV_9300_20_OR_LATER(ah))
+ if (AR_DEVID_7010(ah)) {
+ u32 val;
+ val = REG_READ(ah, AR7010_GPIO_IN);
+ return (MS(val, AR7010_GPIO_IN_VAL) & AR_GPIO_BIT(gpio)) == 0;
+ } else if (AR_SREV_9300_20_OR_LATER(ah))
return MS_REG_READ(AR9300, gpio) != 0;
else if (AR_SREV_9271(ah))
return MS_REG_READ(AR9271, gpio) != 0;
@@ -2353,10 +2366,16 @@ void ath9k_hw_cfg_output(struct ath_hw *ah, u32 gpio,
{
u32 gpio_shift;
- ath9k_hw_gpio_cfg_output_mux(ah, gpio, ah_signal_type);
+ if (AR_DEVID_7010(ah)) {
+ gpio_shift = gpio;
+ REG_RMW(ah, AR7010_GPIO_OE,
+ (AR7010_GPIO_OE_AS_OUTPUT << gpio_shift),
+ (AR7010_GPIO_OE_MASK << gpio_shift));
+ return;
+ }
+ ath9k_hw_gpio_cfg_output_mux(ah, gpio, ah_signal_type);
gpio_shift = 2 * gpio;
-
REG_RMW(ah,
AR_GPIO_OE_OUT,
(AR_GPIO_OE_OUT_DRV_ALL << gpio_shift),
@@ -2366,6 +2385,13 @@ EXPORT_SYMBOL(ath9k_hw_cfg_output);
void ath9k_hw_set_gpio(struct ath_hw *ah, u32 gpio, u32 val)
{
+ if (AR_DEVID_7010(ah)) {
+ val = val ? 0 : 1;
+ REG_RMW(ah, AR7010_GPIO_OUT, ((val&1) << gpio),
+ AR_GPIO_BIT(gpio));
+ return;
+ }
+
if (AR_SREV_9271(ah))
val = ~val;
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index 47be667..633e3d9 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -882,6 +882,7 @@
#define AR_SREV_9271_11(_ah) \
(AR_SREV_9271(_ah) && \
((_ah)->hw_version.macRev == AR_SREV_REVISION_9271_11))
+
#define AR_SREV_9300(_ah) \
(((_ah)->hw_version.macVersion == AR_SREV_VERSION_9300))
#define AR_SREV_9300_20(_ah) \
@@ -896,6 +897,10 @@
(AR_SREV_9285_12_OR_LATER(_ah) && \
((REG_READ(_ah, AR_AN_SYNTH9) & 0x7) == 0x1))
+#define AR_DEVID_7010(_ah) \
+ (((_ah)->hw_version.devid == 0x7010) || \
+ ((_ah)->hw_version.devid == 0x9018))
+
#define AR_RADIO_SREV_MAJOR 0xf0
#define AR_RAD5133_SREV_MAJOR 0xc0
#define AR_RAD2133_SREV_MAJOR 0xd0
@@ -993,6 +998,7 @@ enum {
#define AR9287_NUM_GPIO 11
#define AR9271_NUM_GPIO 16
#define AR9300_NUM_GPIO 17
+#define AR7010_NUM_GPIO 16
#define AR_GPIO_IN_OUT 0x4048
#define AR_GPIO_IN_VAL 0x0FFFC000
@@ -1007,6 +1013,8 @@ enum {
#define AR9271_GPIO_IN_VAL_S 16
#define AR9300_GPIO_IN_VAL 0x0001FFFF
#define AR9300_GPIO_IN_VAL_S 0
+#define AR7010_GPIO_IN_VAL 0x0000FFFF
+#define AR7010_GPIO_IN_VAL_S 0
#define AR_GPIO_OE_OUT (AR_SREV_9300_20_OR_LATER(ah) ? 0x4050 : 0x404c)
#define AR_GPIO_OE_OUT_DRV 0x3
@@ -1015,6 +1023,21 @@ enum {
#define AR_GPIO_OE_OUT_DRV_HI 0x2
#define AR_GPIO_OE_OUT_DRV_ALL 0x3
+#define AR7010_GPIO_OE 0x52000
+#define AR7010_GPIO_OE_MASK 0x1
+#define AR7010_GPIO_OE_AS_OUTPUT 0x0
+#define AR7010_GPIO_OE_AS_INPUT 0x1
+#define AR7010_GPIO_IN 0x52004
+#define AR7010_GPIO_OUT 0x52008
+#define AR7010_GPIO_SET 0x5200C
+#define AR7010_GPIO_CLEAR 0x52010
+#define AR7010_GPIO_INT 0x52014
+#define AR7010_GPIO_INT_TYPE 0x52018
+#define AR7010_GPIO_INT_POLARITY 0x5201C
+#define AR7010_GPIO_PENDING 0x52020
+#define AR7010_GPIO_INT_MASK 0x52024
+#define AR7010_GPIO_FUNCTION 0x52028
+
#define AR_GPIO_INTR_POL (AR_SREV_9300_20_OR_LATER(ah) ? 0x4058 : 0x4050)
#define AR_GPIO_INTR_POL_VAL 0x0001FFFF
#define AR_GPIO_INTR_POL_VAL_S 0
--
1.7.1
^ permalink raw reply related
* Re: ATH5k - Signal measurement reports wrong values - thanks for a fix
From: Bruno Randolf @ 2010-06-30 7:26 UTC (permalink / raw)
To: Jaroslav Fojtik; +Cc: linux-wireless, Nick Kossifidis
In-Reply-To: <4C2AEF25.1702.2DF7E2@jafojtik.seznam.cz>
On Wed June 30 2010 16:15:49 Jaroslav Fojtik wrote:
> > > Before this patch there were short peeks from -78dB to -71dB.
> > > After patch there are short measurement drops from -62dB to -70dB.
> > >
> > > The week charting simply averages it:
> > > http://78.108.103.11:11080/cgi-bin/rodga_1week_big.cgi
> >
> > i guess this must be the same situation as before, no?
>
> Just repeat:
> ## Before this patch there were short peeks from -78dB to -71dB.
>
> ## After patch there are short measurement drops from -62dB to -70dB.
i meant: did you see the same kind of drops with the older compat-wireless
versions, before you reported the problem?
> > how many antennas do you have attached to your device?
>
> One miniPCI device has only one antenna attached. Second U.FL. connector
> is empty.
>
> > it might be interesting to check if you get more consistent
> > signal measurements by disabling antenna
> > diversity, setting it to a fixed antenna. you can do this by using a
> > debugfs file "echo fixed-a > /sys/kernel/debug/ath5k/phy0/antenna" (or
> > "fixed-b")...
>
> I have found that "fixed-b" is a right connector. There is a stupid
> question why? When I am using "out" and not "aux". I just guess that "out"
> should be 'a' and 'aux' should be 'b'.
yes, i have noticed the same thing on some cards. maybe a wrong setting in
eeprom, or some bug in ath5k.
> Please again have a look at:
> http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
>
> It looks like signal power jumped to -46dB.
> It seems that ATH5k never switched to "fixed-b" and I has been receiving
> garbage from empty U.FL. It is a miracle that it has been worked.
i have also had problems with diversity in ath5k when there is only one
antenna attached and in this case i always need to set a fixed antenna for
optimal performance.
> MadWiFi is much more intelligent. It tests both inputs and selects better
> one.
glad to hear it works for you; i had many inconsistencies with antenna
diversity on madwifi as well..
bruno
PS: CC'ing nick, maybe he has some idea?
^ permalink raw reply
* Re: ATH5k - Signal measurement reports wrong values - thanks for a fix
From: Jaroslav Fojtik @ 2010-06-30 7:15 UTC (permalink / raw)
To: Bruno Randolf, linux-wireless
In-Reply-To: <201006281021.47132.br1@einfach.org>
Dear Bruno,
> > Anyway, when you look at the magenta line here:
> > http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
> >
> > There are big drops in measured signal. Did you fix all places?
> >
> > Before this patch there were short peeks from -78dB to -71dB.
> > After patch there are short measurement drops from -62dB to -70dB.
> >
> > The week charting simply averages it:
> > http://78.108.103.11:11080/cgi-bin/rodga_1week_big.cgi
>
> i guess this must be the same situation as before, no?
Just repeat:
## Before this patch there were short peeks from -78dB to -71dB.
## After patch there are short measurement drops from -62dB to -70dB.
MadWiFi does not produce such drops.
> how many antennas do you have attached to your device?
One miniPCI device has only one antenna attached. Second U.FL. connector
is empty.
> it might be interesting to check if you get more consistent
> signal measurements by disabling antenna
> diversity, setting it to a fixed antenna. you can do this by using a debugfs
> file "echo fixed-a > /sys/kernel/debug/ath5k/phy0/antenna" (or "fixed-b")...
I have found that "fixed-b" is a right connector. There is a stupid question why?
When I am using "out" and not "aux". I just guess that "out" should be 'a'
and 'aux' should be 'b'.
Please again have a look at:
http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
It looks like signal power jumped to -46dB.
It seems that ATH5k never switched to "fixed-b" and I has been receiving
garbage from empty U.FL. It is a miracle that it has been worked.
MadWiFi is much more intelligent. It tests both inputs and selects better one.
> btw: when the signal measurement was low, did you see any negative impact on
> the thruput as well?
Nope.
http://78.108.103.11:11080/cgi-bin/pktloss_1day_big.cgi
But the line is so overpowered that I would not notify 8dB drop.
regards
Jara
> bruno
^ permalink raw reply
* [PATCHv2] mac82011: Allow selection of minstrel_ht as default rc algorithm
From: Helmut Schaa @ 2010-06-30 6:48 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Felix Fietkau, Luis R. Rodriguez
Allow selection of minstrel_ht as default rate control algorithm. At
the moment minstrel_ht can only be requested by the driver code but
not selected as default in make menuconfig. Fix this by using
minstrel_ht when minstrel was selected as default and minstrel_ht
is available.
This change won't affect legacy devices as minstrel_ht falls back to
minstrel in that case.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
net/mac80211/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 83eec7a..4d6f865 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -69,6 +69,7 @@ endchoice
config MAC80211_RC_DEFAULT
string
+ default "minstrel_ht" if MAC80211_RC_DEFAULT_MINSTREL && MAC80211_RC_MINSTREL_HT
default "minstrel" if MAC80211_RC_DEFAULT_MINSTREL
default "pid" if MAC80211_RC_DEFAULT_PID
default ""
--
1.6.4.2
^ permalink raw reply related
* Re: [ath5k-devel] ath5k Register Question
From: Benoit Papillault @ 2010-06-30 6:05 UTC (permalink / raw)
To: Jono; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTinTDPyeV2QWWmXskp4504nxPIm1neJdxdLat51p@mail.gmail.com>
Le 30/06/2010 05:44, Jono a écrit :
> Hi,
>
> I'm not sure if this is the right place to ask, but I'm looking for
> information on a specific register on Atheros cards.
>
> I've been told that there is a register that Atheros chips update with
> information about how much of a set period has been detected as 'CCA'
> time. Unfortunately, I cannot find this information in the source
> code. The only register I found that matches this even closely appears
> to only be used during noise calibration, and not updated
> continuously.
>
> Any help would be greatly appreciated!
>
> Thank you,
>
> --
> Jonathan Guerin
Look for Profile Count Registers in ath5k/reg.h. Busy count is probably
what you need.
Regards,
Benoit
^ permalink raw reply
* Re: Problem with firmware load on ipw2200
From: Pavel Roskin @ 2010-06-30 5:46 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4C29F711.1090306@lwfinger.net>
On Tue, 2010-06-29 at 08:37 -0500, Larry Finger wrote:
> I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
> stuck. The system is failing to load the firmware with error -2 (File or
> directory not found). The difficulty is that the required files are
> present with the correct permissions.
>
> What system component might be missing and/or borked to get this symptom?
Older versions of compat-wireless had a race condition in the firmware
code that could cause that. From the log of the compat repository:
commit 524449c0184d44773d4947db8cd3bfd98a0a215f
Author: Grazvydas Ignotas <notasas@gmail.com>
Date: Thu Apr 22 16:54:02 2010 +0300
compat: fix uevent_suppress on 2.6.29 or older kernels
Missing uevent_suppress is causing two uevents instead of one, which is
confusing udev and sometimes causing firmware load to fail due to race
condition, so let's add it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
--
Regards,
Pavel Roskin
^ permalink raw reply
* ath5k Register Question
From: Jono @ 2010-06-30 3:44 UTC (permalink / raw)
To: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTikC3saJNwAFhHvSyJNqVF1fGPcVfn-hwGpR5V30@mail.gmail.com>
Hi,
I'm not sure if this is the right place to ask, but I'm looking for
information on a specific register on Atheros cards.
I've been told that there is a register that Atheros chips update with
information about how much of a set period has been detected as 'CCA'
time. Unfortunately, I cannot find this information in the source
code. The only register I found that matches this even closely appears
to only be used during noise calibration, and not updated
continuously.
Any help would be greatly appreciated!
Thank you,
--
Jonathan Guerin
^ permalink raw reply
* [PATCH] ath9k: fix TSF after reset on AR913x
From: Felix Fietkau @ 2010-06-30 0:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville, Björn Smedman
When issuing a reset, the TSF value is lost in the hardware because of
the 913x specific cold reset. As with some AR9280 cards, the TSF needs
to be preserved in software here.
Additionally, there's an issue that frequently prevents a successful
TSF write directly after the chip reset. In this case, repeating the
TSF write after the initval-writes usually works.
This patch detects failed TSF writes and recovers from them, taking
into account the delay caused by the initval writes.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Cc: stable@kernel.org
---
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1280,7 +1280,8 @@ int ath9k_hw_reset(struct ath_hw *ah, st
macStaId1 = REG_READ(ah, AR_STA_ID1) & AR_STA_ID1_BASE_RATE_11B;
/* For chips on which RTC reset is done, save TSF before it gets cleared */
- if (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ if (AR_SREV_9100(ah) ||
+ (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL)))
tsf = ath9k_hw_gettsf64(ah);
saveLedState = REG_READ(ah, AR_CFG_LED) &
@@ -1312,7 +1313,7 @@ int ath9k_hw_reset(struct ath_hw *ah, st
}
/* Restore TSF */
- if (tsf && AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ if (tsf)
ath9k_hw_settsf64(ah, tsf);
if (AR_SREV_9280_10_OR_LATER(ah))
@@ -1325,6 +1326,17 @@ int ath9k_hw_reset(struct ath_hw *ah, st
if (r)
return r;
+ /*
+ * Some AR91xx SoC devices frequently fail to accept TSF writes
+ * right after the chip reset. When that happens, write a new
+ * value after the initvals have been applied, with an offset
+ * based on measured time difference
+ */
+ if (AR_SREV_9100(ah) && (ath9k_hw_gettsf64(ah) < tsf)) {
+ tsf += 1500;
+ ath9k_hw_settsf64(ah, tsf);
+ }
+
/* Setup MFP options for CCMP */
if (AR_SREV_9280_20_OR_LATER(ah)) {
/* Mask Retry(b11), PwrMgt(b12), MoreData(b13) to 0 in mgmt
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 23:56 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTimhHK461U_qguBGuJjppy5RP2tx5ApasJWVLgr4@mail.gmail.com>
On 2010-06-30 12:50 AM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau <nbd@openwrt.org>:
>> I had a similar thought about the multiple invocations thing. I think
>> that's a good approach in general, but we need to ensure that we make it
>> safe.
>> The main point of this function is to detect baseband hangs. If we
>> experience such a hang, I'm not sure we will always get enough
>> interrupts to do multiple consecutive tests.
>> One way to make it safe would be to reschedule the tasklet each time we
>> ignore the result of the ath9k_hw_check_alive(), that way we keep the
>> detection time low as well. Maybe we could also use a timer for leaving
>> 10 ms time between attempts.
>
> The xmit logic has sc->tx_complete_work that periodically checks if
> the tx is hung and resets the chip if so. Maybe we could refactor that
> into a common periodic health checkup task in main.c that could call
> into both xmit.c and recv.c? Or does ath9k_hw_check_alive() have to
> run in the interrupt context in some way?
I'd like to keep them separate. I think a tx queue hang is very rare,
and the check only runs every second or so, whereas the baseband hang
check needs to run very frequently, as in some situations, the hangs can
probably occur frequently as well.
- Felix
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 22:50 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4C2A6BA4.8080000@openwrt.org>
2010/6/29 Felix Fietkau <nbd@openwrt.org>:
> I had a similar thought about the multiple invocations thing. I think
> that's a good approach in general, but we need to ensure that we make it
> safe.
> The main point of this function is to detect baseband hangs. If we
> experience such a hang, I'm not sure we will always get enough
> interrupts to do multiple consecutive tests.
> One way to make it safe would be to reschedule the tasklet each time we
> ignore the result of the ath9k_hw_check_alive(), that way we keep the
> detection time low as well. Maybe we could also use a timer for leaving
> 10 ms time between attempts.
The xmit logic has sc->tx_complete_work that periodically checks if
the tx is hung and resets the chip if so. Maybe we could refactor that
into a common periodic health checkup task in main.c that could call
into both xmit.c and recv.c? Or does ath9k_hw_check_alive() have to
run in the interrupt context in some way?
> - Felix
/Björn
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 21:54 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTikQz34vgfweDrzH_9_a-BU4dPXbX2UGR61jtJ9n@mail.gmail.com>
On 2010-06-29 11:40 PM, Björn Smedman wrote:
> 2010/6/29 Björn Smedman <bjorn.smedman@venatech.se>:
>> Yes, hw reset is due to reg = 0x01702400 every 4 - 40 seconds or so:
>> ...
>
> When the chip is really stuck, does 'reg' (at 'return false') change
> over time? If I add a second requirement that ath9k_hw_check_alive()
> must fail three times in a row (in different invocations of
> ath9k_tasklet()) before we reset the chip the ap seems fine. I
> sometimes get several of these reg = 0x01702400 every second but only
> one or at the max two in a row.
>
> Under load I sometimes see some reg = 0x00f02400 as well. I also see
> an occasional reset now and then (about once a minute) that must be
> caused by something else.
>
> Any insight into what these reg values mean? Do you think they can
> safely be ignored as per above?
I had a similar thought about the multiple invocations thing. I think
that's a good approach in general, but we need to ensure that we make it
safe.
The main point of this function is to detect baseband hangs. If we
experience such a hang, I'm not sure we will always get enough
interrupts to do multiple consecutive tests.
One way to make it safe would be to reschedule the tasklet each time we
ignore the result of the ath9k_hw_check_alive(), that way we keep the
detection time low as well. Maybe we could also use a timer for leaving
10 ms time between attempts.
Another thing that I'm working on right now is to ensure that the TSF
gets preserved across resets. For some AR9280 based cards the code
already preserves TSF in software over the chip reset, I could simply
extend that to cover SoC as well.
But before I post such a patch, I'll do a test on AR9160 - to see if it
would be better to make the TSF preserve unconditional.
- Felix
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 21:40 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTikw3l6FIxLtIwxofGaqGQD_b7LO25uu-JV45UL6@mail.gmail.com>
2010/6/29 Björn Smedman <bjorn.smedman@venatech.se>:
> Yes, hw reset is due to reg = 0x01702400 every 4 - 40 seconds or so:
> ...
When the chip is really stuck, does 'reg' (at 'return false') change
over time? If I add a second requirement that ath9k_hw_check_alive()
must fail three times in a row (in different invocations of
ath9k_tasklet()) before we reset the chip the ap seems fine. I
sometimes get several of these reg = 0x01702400 every second but only
one or at the max two in a row.
Under load I sometimes see some reg = 0x00f02400 as well. I also see
an occasional reset now and then (about once a minute) that must be
caused by something else.
Any insight into what these reg values mean? Do you think they can
safely be ignored as per above?
/Björn
^ permalink raw reply
* Re: [ath9k-devel] ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Benoit Papillault @ 2010-06-29 21:23 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Björn Smedman, ath9k-devel, linux-wireless
In-Reply-To: <4C29DCC1.2060707@openwrt.org>
Le 29/06/2010 13:45, Felix Fietkau a écrit :
> On 2010-06-29 8:08 AM, Benoit Papillault wrote:
>> Le 29/06/2010 00:55, Felix Fietkau a écrit :
>>> On 2010-06-29 12:31 AM, Björn Smedman wrote:
>>>> Hi all,
>>>>
>>>> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
>>>> value goes up and down rather randomly and only the lower 24 bits or
>>>> so seem to ever be used (see below for details).
>>>>
>>>> The only thing running on phy0 is a single ap interface (and the
>>>> monitor companion that hostapd sets up). I was expecting tsf to
>>>> increase monotonically until all 64 bits had been used.
>>>>
>>>> For a moment I thought it might be the kernel snprintf (on mips)
>>>> playing a trick on me so I tried the following patch. But the result
>>>> is the same.
>>> IMHO the most likely problem source is stuck beacons. Please compile the
>>> driver with the debug option enabled and load it with
>>> insmod ath9k debug=0x00000100
>>>
>>> - Felix
>>
>> Humm... I observed a similar behavior a while ago because only the 15
>> lower bits of rstamp were used when being extended (but rstamp is 32
>> bits in fact). If so, it has been fixed by Felix in the following commit :
> Nope, different issue. The TSF extending applies only to rx timestamps,
> however Björn has been observing weird TSF values from the hw register.
> The Rx TSF timestamp is pretty much irrelevant in AP mode.
>
> - Felix
>
Ah, right and.. right! :-)
Sorry for the noise.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH] iwlwifi: do not export iwl_leds_background
From: John W. Linville @ 2010-06-29 20:32 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1277842739.4197.54.camel@rchatre-DESK>
On Tue, Jun 29, 2010 at 01:18:59PM -0700, reinette chatre wrote:
> On Tue, 2010-06-29 at 12:39 -0700, John W. Linville wrote:
> > It is only used from within the iwlcore module.
> >
> > Reported-by: Johannes Berg <johannes@sipsolutions.net>
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-led.c b/drivers/net/wireless/iwlwifi/iwl-led.c
> > index db5bfcb..486244b 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-led.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl-led.c
> > @@ -214,7 +214,6 @@ void iwl_leds_background(struct iwl_priv *priv)
> > priv->last_blink_time = jiffies;
> > priv->last_blink_rate = blink_idx;
> > }
> > -EXPORT_SYMBOL(iwl_leds_background);
> >
> > void iwl_leds_init(struct iwl_priv *priv)
> > {
>
> Nack.
>
> Please take a closer look at how it is used ... it is used in iwl-core.h
> in an inline (iwl_update_stats) function that is used by both iwlagn and
> iwl3945.
OK
--
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
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