* Re: LIBIPW
From: Randy Dunlap @ 2011-01-25 18:06 UTC (permalink / raw)
To: James; +Cc: linux-wireless Mailing List
In-Reply-To: <4D3F0DBC.90302@lockie.ca>
On Tue, January 25, 2011 9:51 am, James wrote:
> /usr/src/compat-wireless-2011-01-24 $ sudo make
> /usr/src/compat-wireless-2011-01-24/config.mk:202: "WARNING:
> CONFIG_CFG80211_WEXT will be deactivated or not working because kernel
> was compiled with CONFIG_WIRELESS_EXT=n. Tools using wext interface like
> iwconfig will not work. To activate it build your kernel e.g. with
> CONFIG_LIBIPW=m."
>
>
> $ sudo grep LIBIPW ../linux/.config
> ''
>
>
> What does LIBIPW depend on?
> I don't even see a choice to turn it on.
It's not a user-visible prompted symbol.
It's selected by IPW2100 or IPW2200.
Also, the help text for LIBIPW (in 2.6.37) says:
This option enables the hardware independent IEEE 802.11
networking stack. This component is deprecated in favor of the
mac80211 component.
--
~Randy
^ permalink raw reply
* LIBIPW
From: James @ 2011-01-25 17:51 UTC (permalink / raw)
To: linux-wireless Mailing List
/usr/src/compat-wireless-2011-01-24 $ sudo make
/usr/src/compat-wireless-2011-01-24/config.mk:202: "WARNING:
CONFIG_CFG80211_WEXT will be deactivated or not working because kernel
was compiled with CONFIG_WIRELESS_EXT=n. Tools using wext interface like
iwconfig will not work. To activate it build your kernel e.g. with
CONFIG_LIBIPW=m."
$ sudo grep LIBIPW ../linux/.config
''
What does LIBIPW depend on?
I don't even see a choice to turn it on.
^ permalink raw reply
* Re: [PATCH] brcm80211: fix error report string
From: Gustavo F. Padovan @ 2011-01-25 17:00 UTC (permalink / raw)
To: Brett Rudley
Cc: Rafał Miłecki, Henry Ptasinski, Dowan Kim,
vossen@broadcom.com, Arend Van Spriel,
linux-wireless@vger.kernel.org
In-Reply-To: <7A94256FD72B884D9E7C55586C3CBCEE13CD6E8FB6@SJEXCHCCR01.corp.ad.broadcom.com>
Hi Brett,
* Brett Rudley <brudley@broadcom.com> [2011-01-24 13:57:46 -0800]:
> > -----Original Message-----
> > From: Rafał Miłecki [mailto:zajec5@gmail.com]
> > Sent: Monday, January 24, 2011 1:17 PM
> > To: Gustavo F. Padovan
> > Cc: Brett Rudley; Henry Ptasinski; Dowan Kim; vossen@broadcom.com; Arend
> > Van Spriel; linux-wireless@vger.kernel.org
> > Subject: Re: [PATCH] brcm80211: fix error report string
> >
> > 2011/1/24 Gustavo F. Padovan <padovan@profusion.mobi>:
> > > Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> > > ---
> > > drivers/staging/brcm80211/sys/wlc_mac80211.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/staging/brcm80211/sys/wlc_mac80211.c
> > b/drivers/staging/brcm80211/sys/wlc_mac80211.c
> > > index 5eb41d6..ee1bcc5 100644
> > > --- a/drivers/staging/brcm80211/sys/wlc_mac80211.c
> > > +++ b/drivers/staging/brcm80211/sys/wlc_mac80211.c
> > > @@ -6910,7 +6910,7 @@ prep_mac80211_status(struct wlc_info *wlc,
> > d11rxhdr_t *rxh, struct sk_buff *p,
> > > preamble = 0;
> > > if (IS_CCK(rspec)) {
> > > if (rxh->PhyRxStatus_0 & PRXS0_SHORTH)
> > > - WL_ERROR("Short CCK\n");
> > > + WL_ERROR("%s: Short CCK\n, __func__");
> >
> > I have no idea how WL_ERROR works, but are you sure of that?
> >
> > You wrote:
> > "%s: Short CCK\n, __func__"
> >
> > Didn't you mean:
> > "%s: Short CCK\n", __func__
> > ?
> >
>
> Rafal's suggestion is correct, the patch was incorrect.
> (Good eyes, Rafal)
I just sent a corrected one yesterday in this thread.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* [PATCH wireless-2.6.38] MAINTAINERS: remove Reinette Chatre as iwlwifi maintainer
From: Wey-Yi Guy @ 2011-01-25 16:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre, Wey-Yi Guy
From: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
this patch is also available from wireless-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 23d0436..c9ec9d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3209,7 +3209,6 @@ F: drivers/net/wimax/i2400m/
F: include/linux/wimax/i2400m.h
INTEL WIRELESS WIFI LINK (iwlwifi)
-M: Reinette Chatre <reinette.chatre@intel.com>
M: Wey-Yi Guy <wey-yi.w.guy@intel.com>
M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
--
1.7.0.4
^ permalink raw reply related
* [PATCH] wl12xx: add debugfs entry for dtim_interval
From: Eliad Peller @ 2011-01-25 15:31 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
When configuring ACX_WAKE_UP_CONDITIONS (before entering psm), we
tell the firmware to wake up once in N DTIMs (or beacons).
Allow control of this value via debugfs (for debugging purposes).
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/wl12xx/debugfs.c | 60 +++++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/debugfs.c b/drivers/net/wireless/wl12xx/debugfs.c
index 36e7ec1..1edc89f 100644
--- a/drivers/net/wireless/wl12xx/debugfs.c
+++ b/drivers/net/wireless/wl12xx/debugfs.c
@@ -293,6 +293,65 @@ static const struct file_operations gpio_power_ops = {
.llseek = default_llseek,
};
+static ssize_t dtim_interval_read(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct wl1271 *wl = file->private_data;
+
+ return wl1271_format_buffer(user_buf, count, ppos, "%d\n",
+ wl->conf.conn.listen_interval);
+}
+
+static ssize_t dtim_interval_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct wl1271 *wl = file->private_data;
+ char buf[10];
+ size_t len;
+ unsigned long value;
+ int ret;
+
+ len = min(count, sizeof(buf) - 1);
+ if (copy_from_user(buf, user_buf, len))
+ return -EFAULT;
+ buf[len] = '\0';
+
+ ret = strict_strtoul(buf, 0, &value);
+ if (ret < 0) {
+ wl1271_warning("illegal value for dtim_interval");
+ return -EINVAL;
+ }
+
+ if (value < 1 || value > 10) {
+ wl1271_warning("dtim value is not in valid range");
+ return -ERANGE;
+ }
+
+ mutex_lock(&wl->mutex);
+
+ wl->conf.conn.listen_interval = value;
+ /* for some reason there are different event types for 1 and >1 */
+ if (value == 1)
+ wl->conf.conn.wake_up_event = CONF_WAKE_UP_EVENT_DTIM;
+ else
+ wl->conf.conn.wake_up_event = CONF_WAKE_UP_EVENT_N_DTIM;
+
+ /*
+ * we don't reconfigure ACX_WAKE_UP_CONDITIONS now, so it will only
+ * take effect on the next time we enter psm.
+ */
+ mutex_unlock(&wl->mutex);
+ return count;
+}
+
+static const struct file_operations dtim_interval_ops = {
+ .read = dtim_interval_read,
+ .write = dtim_interval_write,
+ .open = wl1271_open_file_generic,
+ .llseek = default_llseek,
+};
+
static int wl1271_debugfs_add_files(struct wl1271 *wl,
struct dentry *rootdir)
{
@@ -401,6 +460,7 @@ static int wl1271_debugfs_add_files(struct wl1271 *wl,
DEBUGFS_ADD(excessive_retries, rootdir);
DEBUGFS_ADD(gpio_power, rootdir);
+ DEBUGFS_ADD(dtim_interval, rootdir);
entry = debugfs_create_x32("debug_level", 0600, rootdir,
&wl12xx_debug_level);
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC] iwl3945: remove check_plcp_health
From: John W. Linville @ 2011-01-25 15:14 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Wey-Yi Guy, Abhijeet Kolekar, linux-wireless,
Intel Linux Wireless
In-Reply-To: <20110125093507.GA6429@redhat.com>
On Tue, Jan 25, 2011 at 10:35:28AM +0100, Stanislaw Gruszka wrote:
> This patch helps some users currently complaining about iwl3945
> performance.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=654599
> https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/+index?comments=all
>
> Patch does not helps all users, but they seems to be affected
> by different bug or bugs.
>
> Patch effectively reverts commit a29576a7844326c5223f4d4adbfd3f4d64173d4c
> "iwl3945: add plcp error checking". It is minimal fix intended to
> -stable posting. I will post cleaning up patch, if fix will be accepted.
>
> ---
> drivers/net/wireless/iwlwifi/iwl-3945.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
> index 8cacb4e..eb916d7 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-3945.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
> @@ -2832,7 +2832,6 @@ static struct iwl_lib_ops iwl3945_lib = {
> .config_ap = iwl3945_config_ap,
> .manage_ibss_station = iwl3945_manage_ibss_station,
> .recover_from_tx_stall = iwl_bg_monitor_recover,
> - .check_plcp_health = iwl3945_good_plcp_health,
>
> .debugfs_ops = {
> .rx_stats_read = iwl3945_ucode_rx_stats_read,
Did you experiment with different values for
IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF for iwl3945?
Should we simply revert commit a29576a7844326c5223f4d4adbfd3f4d64173d4c
instead?
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: mini PCI express WLAN card
From: Josef Windorfer @ 2011-01-25 15:11 UTC (permalink / raw)
To: Dennis Borgmann; +Cc: linux-wireless
Unfortunately, I don't know the chipset, but it's a 802.11n-card.
I will buy this board and try to run the ath9k driver and post my experiences here! ;-)
thanks.
Greets Josef
> ----- Original Message -----
> From: Dennis Borgmann
> Sent: 01/25/11 01:35 PM
> To: Josef Windorfer
> Subject: Re: mini PCI express WLAN card
>
> Hello Josef!
>
> Do you know the chipset, which is used in your card? As far as I can
> see, it seems to be a 802.11n-card, which would mean, you need ath9k. As
> soon as you know the chipset, check this page:
>
> http://wireless.kernel.org/en/users/Drivers/ath9k#supported_chipsets
>
> If yours is within this list, the device should work.
>
> Kind regards,
> Dennis Borgmann
>
> Josef Windorfer schrieb:
> > Hi all,
> >
> > I want to buy the mainboard ZOTAC G41-ITX with an mini PCI express WLAN card.
> >
> > I have only a few information about the card (from the manufacturer).
> > It's an Atheros card with either AzureWave WiFi Modul AW NE771 or AzureWave WiFi AR5 B 91.
> >
> > Is there a driver support in linux available?
> > I'm not realy successful by searching google.
> >
> > Thanks!
> >
> > Greets Josef
> > --
> > 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
* Re: [PATCH] staging: brcm80211: bugfix for softmac crash on multi cpu configurations
From: Greg KH @ 2011-01-25 11:41 UTC (permalink / raw)
To: Roland Vossen
Cc: devel@linuxdriverproject.org, linux-wireless@vger.kernel.org
In-Reply-To: <400C43189542CE41BC0A5B252FC90136952F08D15D@SJEXCHCCR02.corp.ad.broadcom.com>
On Tue, Jan 25, 2011 at 03:24:38AM -0800, Roland Vossen wrote:
> >Should this also go to the .37 stable kernel tree?
>
> Yes it should. Should I send you a patch for the .37 stable kernel tree ?
Not at the moment, I'll just mark it for the stable tree, and if it
doesn't apply there properly, I'll email you asking for an updated
version.
For more details about the stable kernel process, see the file,
Documentation/stable_kernel_rules.txt
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] iwl3945: remove check_plcp_health
From: wwguy @ 2011-01-25 14:56 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Kolekar, Abhijeet, linux-wireless@vger.kernel.org,
Intel Linux Wireless
In-Reply-To: <20110125093507.GA6429@redhat.com>
On Tue, 2011-01-25 at 01:35 -0800, Stanislaw Gruszka wrote:
> This patch helps some users currently complaining about iwl3945
> performance.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=654599
> https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/+index?comments=all
>
> Patch does not helps all users, but they seems to be affected
> by different bug or bugs.
>
> Patch effectively reverts commit a29576a7844326c5223f4d4adbfd3f4d64173d4c
> "iwl3945: add plcp error checking". It is minimal fix intended to
> -stable posting. I will post cleaning up patch, if fix will be accepted.
>
> ---
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Agree, maybe I am wrong, but I don't think this plcp checking never
being fully tested for 3945
Wey
^ permalink raw reply
* Re: [PATCH] cfg80211: Allow non-zero indexes for device specific pair-wise ciphers
From: Johannes Berg @ 2011-01-25 13:57 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville, linux-wireless
In-Reply-To: <1295963224.18570.367.camel@wimaxnb.nmp.nokia.com>
On Tue, 2011-01-25 at 15:47 +0200, Juuso Oikarinen wrote:
> I would be surprised to see WAPI used with CCMP though - or any other
> voluntary manner for that matter - although it is possible ;)
:)
> So you think this patch is ok as is, or do I need to find some other
> way?
I guess it's fine -- I was trying to figure out what they tried to do
with the key index but the WAPI "standard" is kinda vague on that ...
johannes
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix error handling in ath5k_hw_dma_stop
From: Stanislaw Gruszka @ 2011-01-25 13:52 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, mickflemm, Bruno Randolf, jirislaby,
lrodriguez
In-Reply-To: <1295929904-11806-1-git-send-email-me@bobcopeland.com>
On Mon, Jan 24, 2011 at 11:31:43PM -0500, Bob Copeland wrote:
> Review spotted a problem with the error handling in ath5k_hw_dma_stop:
> a successful return from ath5k_hw_stop_tx_dma will be treated as
> an error, so we always bail out of the loop after processing a single
> active queue. As a result, we may not actually stop some queues during
> reset.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> These two patches fix some buglets I found when reviewing some old code.
>
> drivers/net/wireless/ath/ath5k/dma.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
> index 0064be7..e828b98 100644
> --- a/drivers/net/wireless/ath/ath5k/dma.c
> +++ b/drivers/net/wireless/ath/ath5k/dma.c
> @@ -838,7 +838,7 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
> for (i = 0; i < qmax; i++) {
> err = ath5k_hw_stop_tx_dma(ah, i);
> /* -EINVAL -> queue inactive */
> - if (err != -EINVAL)
> + if (err && err != -EINVAL)
> return err;
> }
Patch is good, but does not make code fully correct. When last queue
is inactive, we return -EINVAL from ath5_hw_dma_stop(). So we need
also:
if (err && err != -EINVAL)
return err;
+ err = 0;
}
But perhaps, would be better just return 0 from
ath5k_hw_stop_tx_dma() when queue is inactive.
I think that could fix "ath5k phy0: can't reset hardware (-5)"
bugs reported in a few places, so patch should go to stable
as well.
Stanislaw
^ permalink raw reply
* Re: [PATCH] cfg80211: Allow non-zero indexes for device specific pair-wise ciphers
From: Juuso Oikarinen @ 2011-01-25 13:47 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1295951230.3650.8.camel@jlt3.sipsolutions.net>
On Tue, 2011-01-25 at 11:27 +0100, ext Johannes Berg wrote:
> On Tue, 2011-01-25 at 12:21 +0200, juuso.oikarinen@nokia.com wrote:
> > From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> >
> > Some vendor specific cipher suites require non-zero key indexes for pairwise
> > keys, but as of currently, the cfg80211 does not allow it.
>
> Well, technically, that is incorrect -- just adding a vendor-specific
> cipher to 802.11-2007 (11i) will uphold that requirement. Using
> different mechanisms like WAPI might run afoul of this check... But
> technically WAPI could also use CCMP etc. and then you might have to use
> non-zero even for CCMP, so this code would again be wrong.
I guess thats right. I was assuming this was for SMS-4 only, but I guess
it extends to other ciphers too in association with WAPI.
> OTOH, I don't really see a good way to capture this in code...
I would be surprised to see WAPI used with CCMP though - or any other
voluntary manner for that matter - although it is possible ;)
So you think this patch is ok as is, or do I need to find some other
way?
-Juuso
^ permalink raw reply
* [PATCH] ath9k_htc: fix race conditions when stop device
From: Stanislaw Gruszka @ 2011-01-25 13:15 UTC (permalink / raw)
To: Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian
Cc: ath9k-devel, linux-wireless, Sujith, stable
We do not kill any scheduled tasklets when stopping device, that may
cause usage of resources after free. Disable interrupts, kill tasklets
and then works in correct order.
Cc: stable@kernel.org
Tested-by: Sujith <m.sujith@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 ---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 21 +++++++++++++++------
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 8e04586..a7bc26d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -142,9 +142,6 @@ static void ath9k_deinit_priv(struct ath9k_htc_priv *priv)
{
ath9k_htc_exit_debug(priv->ah);
ath9k_hw_deinit(priv->ah);
- tasklet_kill(&priv->swba_tasklet);
- tasklet_kill(&priv->rx_tasklet);
- tasklet_kill(&priv->tx_tasklet);
kfree(priv->ah);
priv->ah = NULL;
}
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index f14f37d..a702089 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1026,12 +1026,6 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
int ret = 0;
u8 cmd_rsp;
- /* Cancel all the running timers/work .. */
- cancel_work_sync(&priv->fatal_work);
- cancel_work_sync(&priv->ps_work);
- cancel_delayed_work_sync(&priv->ath9k_led_blink_work);
- ath9k_led_stop_brightness(priv);
-
mutex_lock(&priv->mutex);
if (priv->op_flags & OP_INVALID) {
@@ -1045,8 +1039,23 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
WMI_CMD(WMI_DISABLE_INTR_CMDID);
WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
WMI_CMD(WMI_STOP_RECV_CMDID);
+
+ tasklet_kill(&priv->swba_tasklet);
+ tasklet_kill(&priv->rx_tasklet);
+ tasklet_kill(&priv->tx_tasklet);
+
skb_queue_purge(&priv->tx_queue);
+ mutex_unlock(&priv->mutex);
+
+ /* Cancel all the running timers/work .. */
+ cancel_work_sync(&priv->fatal_work);
+ cancel_work_sync(&priv->ps_work);
+ cancel_delayed_work_sync(&priv->ath9k_led_blink_work);
+ ath9k_led_stop_brightness(priv);
+
+ mutex_lock(&priv->mutex);
+
/* Remove monitor interface here */
if (ah->opmode == NL80211_IFTYPE_MONITOR) {
if (ath9k_htc_remove_monitor_interface(priv))
--
1.7.1
^ permalink raw reply related
* [PATCH] ath9k: fix race conditions when stop device
From: Stanislaw Gruszka @ 2011-01-25 13:08 UTC (permalink / raw)
To: Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian
Cc: ath9k-devel, linux-wireless, Ben Greear, stable
We do not kill any scheduled tasklets when stopping device, that may
cause usage of resources after free. Moreover we enable interrupts
in tasklet function, so we could potentially end with interrupts
enabled when driver is not ready to receive them.
I think patch should fix Ben's kernel crash from:
http://marc.info/?l=linux-wireless&m=129438358921501&w=2
Cc: stable@kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ath/ath9k/init.c | 5 -----
drivers/net/wireless/ath/ath9k/main.c | 9 +++++++++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 767d8b8..b3254a3 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -598,8 +598,6 @@ err_btcoex:
err_queues:
ath9k_hw_deinit(ah);
err_hw:
- tasklet_kill(&sc->intr_tq);
- tasklet_kill(&sc->bcon_tasklet);
kfree(ah);
sc->sc_ah = NULL;
@@ -807,9 +805,6 @@ static void ath9k_deinit_softc(struct ath_softc *sc)
ath9k_hw_deinit(sc->sc_ah);
- tasklet_kill(&sc->intr_tq);
- tasklet_kill(&sc->bcon_tasklet);
-
kfree(sc->sc_ah);
sc->sc_ah = NULL;
}
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index c03184e..42cfd96 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1320,6 +1320,9 @@ static void ath9k_stop(struct ieee80211_hw *hw)
spin_lock_bh(&sc->sc_pcu_lock);
+ /* prevent tasklets to enable interrupts once we disable them */
+ ah->imask &= ~ATH9K_INT_GLOBAL;
+
/* make sure h/w will not generate any interrupt
* before setting the invalid flag. */
ath9k_hw_disable_interrupts(ah);
@@ -1337,6 +1340,12 @@ static void ath9k_stop(struct ieee80211_hw *hw)
spin_unlock_bh(&sc->sc_pcu_lock);
+ /* we can now sync irq and kill any running tasklets, since we already
+ * disabled interrupts and not holding a spin lock */
+ synchronize_irq(sc->irq);
+ tasklet_kill(&sc->intr_tq);
+ tasklet_kill(&sc->bcon_tasklet);
+
ath9k_ps_restore(sc);
sc->ps_idle = true;
--
1.7.1
^ permalink raw reply related
* Re: mini PCI express WLAN card
From: Dennis Borgmann @ 2011-01-25 12:35 UTC (permalink / raw)
To: Josef Windorfer; +Cc: linux-wireless
In-Reply-To: <20110125114419.139360@gmx.com>
Hello Josef!
Do you know the chipset, which is used in your card? As far as I can
see, it seems to be a 802.11n-card, which would mean, you need ath9k. As
soon as you know the chipset, check this page:
http://wireless.kernel.org/en/users/Drivers/ath9k#supported_chipsets
If yours is within this list, the device should work.
Kind regards,
Dennis Borgmann
Josef Windorfer schrieb:
> Hi all,
>
> I want to buy the mainboard ZOTAC G41-ITX with an mini PCI express WLAN card.
>
> I have only a few information about the card (from the manufacturer).
> It's an Atheros card with either AzureWave WiFi Modul AW NE771 or AzureWave WiFi AR5 B 91.
>
> Is there a driver support in linux available?
> I'm not realy successful by searching google.
>
> Thanks!
>
> Greets Josef
> --
> 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
* Re: [PATCH 2/2] ath5k: remove debug_dump_skb() functions
From: Nick Kossifidis @ 2011-01-25 12:28 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, Bruno Randolf, jirislaby, lrodriguez
In-Reply-To: <1295929976-11858-2-git-send-email-me@bobcopeland.com>
2011/1/25 Bob Copeland <me@bobcopeland.com>:
> Now that rx and tx dumps go through the tracing infrastructure,
> we no longer need to keep these routines around.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/debug.c | 20 --------------------
> drivers/net/wireless/ath/ath5k/debug.h | 10 ----------
> 2 files changed, 0 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
> index d2f84d7..0230f30 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -308,8 +308,6 @@ static const struct {
> { ATH5K_DEBUG_CALIBRATE, "calib", "periodic calibration" },
> { ATH5K_DEBUG_TXPOWER, "txpower", "transmit power setting" },
> { ATH5K_DEBUG_LED, "led", "LED management" },
> - { ATH5K_DEBUG_DUMP_RX, "dumprx", "print received skb content" },
> - { ATH5K_DEBUG_DUMP_TX, "dumptx", "print transmit skb content" },
> { ATH5K_DEBUG_DUMPBANDS, "dumpbands", "dump bands" },
> { ATH5K_DEBUG_DMA, "dma", "dma start/stop" },
> { ATH5K_DEBUG_ANI, "ani", "adaptive noise immunity" },
> @@ -1036,24 +1034,6 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
> }
>
> void
> -ath5k_debug_dump_skb(struct ath5k_softc *sc,
> - struct sk_buff *skb, const char *prefix, int tx)
> -{
> - char buf[16];
> -
> - if (likely(!((tx && (sc->debug.level & ATH5K_DEBUG_DUMP_TX)) ||
> - (!tx && (sc->debug.level & ATH5K_DEBUG_DUMP_RX)))))
> - return;
> -
> - snprintf(buf, sizeof(buf), "%s %s", wiphy_name(sc->hw->wiphy), prefix);
> -
> - print_hex_dump_bytes(buf, DUMP_PREFIX_NONE, skb->data,
> - min(200U, skb->len));
> -
> - printk(KERN_DEBUG "\n");
> -}
> -
> -void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
> {
> struct ath5k_desc *ds = bf->desc;
> diff --git a/drivers/net/wireless/ath/ath5k/debug.h b/drivers/net/wireless/ath/ath5k/debug.h
> index 3e34428..b0355ae 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.h
> +++ b/drivers/net/wireless/ath/ath5k/debug.h
> @@ -116,8 +116,6 @@ enum ath5k_debug_level {
> ATH5K_DEBUG_CALIBRATE = 0x00000020,
> ATH5K_DEBUG_TXPOWER = 0x00000040,
> ATH5K_DEBUG_LED = 0x00000080,
> - ATH5K_DEBUG_DUMP_RX = 0x00000100,
> - ATH5K_DEBUG_DUMP_TX = 0x00000200,
> ATH5K_DEBUG_DUMPBANDS = 0x00000400,
> ATH5K_DEBUG_DMA = 0x00000800,
> ATH5K_DEBUG_ANI = 0x00002000,
> @@ -152,10 +150,6 @@ void
> ath5k_debug_dump_bands(struct ath5k_softc *sc);
>
> void
> -ath5k_debug_dump_skb(struct ath5k_softc *sc,
> - struct sk_buff *skb, const char *prefix, int tx);
> -
> -void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf);
>
> #else /* no debugging */
> @@ -182,10 +176,6 @@ static inline void
> ath5k_debug_dump_bands(struct ath5k_softc *sc) {}
>
> static inline void
> -ath5k_debug_dump_skb(struct ath5k_softc *sc,
> - struct sk_buff *skb, const char *prefix, int tx) {}
> -
> -static inline void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf) {}
>
> #endif /* ifdef CONFIG_ATH5K_DEBUG */
> --
> 1.7.1.1
>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: use tracing for packet tx/rx dump
From: Nick Kossifidis @ 2011-01-25 12:28 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, Bruno Randolf, jirislaby, lrodriguez
In-Reply-To: <1295929976-11858-1-git-send-email-me@bobcopeland.com>
2011/1/25 Bob Copeland <me@bobcopeland.com>:
> This adds a few tracepoints to ath5k driver transmit and
> receive callbacks in order to record packet traffic.
> We record the entire packet in the trace buffer so that
> the data can be extracted with trace-cmd and external
> plugins.
>
> Compared to the previous debugging calls, this approach
> removes an out-of-line function call from the tx and rx
> paths in the compiled-in-but-disabled case, while
> improving the ability to process the logged data.
>
> A new option, CONFIG_ATH5K_TRACER, is added so that one
> may disable the tracepoints completely.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
>
> drivers/net/wireless/ath/ath5k/Kconfig | 11 +++
> drivers/net/wireless/ath/ath5k/base.c | 16 +++--
> drivers/net/wireless/ath/ath5k/trace.h | 107 ++++++++++++++++++++++++++++++++
> 3 files changed, 128 insertions(+), 6 deletions(-)
> create mode 100644 drivers/net/wireless/ath/ath5k/trace.h
>
> diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
> index e079331..e18a9aa 100644
> --- a/drivers/net/wireless/ath/ath5k/Kconfig
> +++ b/drivers/net/wireless/ath/ath5k/Kconfig
> @@ -40,6 +40,17 @@ config ATH5K_DEBUG
>
> modprobe ath5k debug=0x00000400
>
> +config ATH5K_TRACER
> + bool "Atheros 5xxx tracer"
> + depends on ATH5K
> + depends on EVENT_TRACING
> + ---help---
> + Say Y here to enable tracepoints for the ath5k driver
> + using the kernel tracing infrastructure. Select this
> + option if you are interested in debugging the driver.
> +
> + If unsure, say N.
> +
> config ATH5K_AHB
> bool "Atheros 5xxx AHB bus support"
> depends on (ATHEROS_AR231X && !PCI)
> diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
> index 14377ac..9c59cb6 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -61,6 +61,9 @@
> #include "debug.h"
> #include "ani.h"
>
> +#define CREATE_TRACE_POINTS
> +#include "trace.h"
> +
> int ath5k_modparam_nohwcrypt;
> module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
> MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
> @@ -1384,7 +1387,7 @@ ath5k_receive_frame(struct ath5k_softc *sc, struct sk_buff *skb,
> sc->sbands[sc->curchan->band].bitrates[rxs->rate_idx].hw_value_short)
> rxs->flag |= RX_FLAG_SHORTPRE;
>
> - ath5k_debug_dump_skb(sc, skb, "RX ", 0);
> + trace_ath5k_rx(sc, skb);
>
> ath5k_update_beacon_rssi(sc, skb, rs->rs_rssi);
>
> @@ -1529,7 +1532,7 @@ ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
> unsigned long flags;
> int padsize;
>
> - ath5k_debug_dump_skb(sc, skb, "TX ", 1);
> + trace_ath5k_tx(sc, skb, txq);
>
> /*
> * The hardware expects the header padded to 4 byte boundaries.
> @@ -1578,7 +1581,7 @@ drop_packet:
>
> static void
> ath5k_tx_frame_completed(struct ath5k_softc *sc, struct sk_buff *skb,
> - struct ath5k_tx_status *ts)
> + struct ath5k_txq *txq, struct ath5k_tx_status *ts)
> {
> struct ieee80211_tx_info *info;
> int i;
> @@ -1630,6 +1633,7 @@ ath5k_tx_frame_completed(struct ath5k_softc *sc, struct sk_buff *skb,
> else
> sc->stats.antenna_tx[0]++; /* invalid */
>
> + trace_ath5k_tx_complete(sc, skb, txq, ts);
> ieee80211_tx_status(sc->hw, skb);
> }
>
> @@ -1666,7 +1670,7 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
>
> dma_unmap_single(sc->dev, bf->skbaddr, skb->len,
> DMA_TO_DEVICE);
> - ath5k_tx_frame_completed(sc, skb, &ts);
> + ath5k_tx_frame_completed(sc, skb, txq, &ts);
> }
>
> /*
> @@ -1808,8 +1812,6 @@ ath5k_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
> goto out;
> }
>
> - ath5k_debug_dump_skb(sc, skb, "BC ", 1);
> -
> ath5k_txbuf_free_skb(sc, avf->bbuf);
> avf->bbuf->skb = skb;
> ret = ath5k_beacon_setup(sc, avf->bbuf);
> @@ -1904,6 +1906,8 @@ ath5k_beacon_send(struct ath5k_softc *sc)
> sc->opmode == NL80211_IFTYPE_MESH_POINT)
> ath5k_beacon_update(sc->hw, vif);
>
> + trace_ath5k_tx(sc, bf->skb, &sc->txqs[sc->bhalq]);
> +
> ath5k_hw_set_txdp(ah, sc->bhalq, bf->daddr);
> ath5k_hw_start_tx_dma(ah, sc->bhalq);
> ATH5K_DBG(sc, ATH5K_DEBUG_BEACON, "TXDP[%u] = %llx (%p)\n",
> diff --git a/drivers/net/wireless/ath/ath5k/trace.h b/drivers/net/wireless/ath/ath5k/trace.h
> new file mode 100644
> index 0000000..2de68ad
> --- /dev/null
> +++ b/drivers/net/wireless/ath/ath5k/trace.h
> @@ -0,0 +1,107 @@
> +#if !defined(__TRACE_ATH5K_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define __TRACE_ATH5K_H
> +
> +#include <linux/tracepoint.h>
> +#include "base.h"
> +
> +#ifndef CONFIG_ATH5K_TRACER
> +#undef TRACE_EVENT
> +#define TRACE_EVENT(name, proto, ...) \
> +static inline void trace_ ## name(proto) {}
> +#endif
> +
> +struct sk_buff;
> +
> +#define PRIV_ENTRY __field(struct ath5k_softc *, priv)
> +#define PRIV_ASSIGN __entry->priv = priv
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM ath5k
> +
> +TRACE_EVENT(ath5k_rx,
> + TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb),
> + TP_ARGS(priv, skb),
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(unsigned long, skbaddr)
> + __dynamic_array(u8, frame, skb->len)
> + ),
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->skbaddr = (unsigned long) skb;
> + memcpy(__get_dynamic_array(frame), skb->data, skb->len);
> + ),
> + TP_printk(
> + "[%p] RX skb=%lx", __entry->priv, __entry->skbaddr
> + )
> +);
> +
> +TRACE_EVENT(ath5k_tx,
> + TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
> + struct ath5k_txq *q),
> +
> + TP_ARGS(priv, skb, q),
> +
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(unsigned long, skbaddr)
> + __field(u8, qnum)
> + __dynamic_array(u8, frame, skb->len)
> + ),
> +
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->skbaddr = (unsigned long) skb;
> + __entry->qnum = (u8) q->qnum;
> + memcpy(__get_dynamic_array(frame), skb->data, skb->len);
> + ),
> +
> + TP_printk(
> + "[%p] TX skb=%lx q=%d", __entry->priv, __entry->skbaddr,
> + __entry->qnum
> + )
> +);
> +
> +TRACE_EVENT(ath5k_tx_complete,
> + TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
> + struct ath5k_txq *q, struct ath5k_tx_status *ts),
> +
> + TP_ARGS(priv, skb, q, ts),
> +
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(unsigned long, skbaddr)
> + __field(u8, qnum)
> + __field(u8, ts_status)
> + __field(s8, ts_rssi)
> + __field(u8, ts_antenna)
> + ),
> +
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->skbaddr = (unsigned long) skb;
> + __entry->qnum = (u8) q->qnum;
> + __entry->ts_status = ts->ts_status;
> + __entry->ts_rssi = ts->ts_rssi;
> + __entry->ts_antenna = ts->ts_antenna;
> + ),
> +
> + TP_printk(
> + "[%p] TX end skb=%lx q=%d stat=%x rssi=%d ant=%x",
> + __entry->priv, __entry->skbaddr, __entry->qnum,
> + __entry->ts_status, __entry->ts_rssi, __entry->ts_antenna
> + )
> +);
> +
> +#endif /* __TRACE_ATH5K_H */
> +
> +#ifdef CONFIG_ATH5K_TRACER
> +
> +#undef TRACE_INCLUDE_PATH
> +#define TRACE_INCLUDE_PATH ../../drivers/net/wireless/ath/ath5k
> +#undef TRACE_INCLUDE_FILE
> +#define TRACE_INCLUDE_FILE trace
> +
> +#include <trace/define_trace.h>
> +
> +#endif
> --
> 1.7.1.1
>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 2/2] ath5k: correct endianness of frame duration
From: Nick Kossifidis @ 2011-01-25 12:26 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, Bruno Randolf, jirislaby, lrodriguez
In-Reply-To: <1295929904-11806-2-git-send-email-me@bobcopeland.com>
2011/1/25 Bob Copeland <me@bobcopeland.com>:
> The ath5k version of ieee80211_generic_frame_duration() returns
> an __le16 for standard modes but a cpu-endian int for turbo/half/
> quarter rates. Make it always return cpu-endian values.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/pcu.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
> index e5f2b96..a702817 100644
> --- a/drivers/net/wireless/ath/ath5k/pcu.c
> +++ b/drivers/net/wireless/ath/ath5k/pcu.c
> @@ -86,7 +86,7 @@ int ath5k_hw_get_frame_duration(struct ath5k_hw *ah,
> if (!ah->ah_bwmode) {
> dur = ieee80211_generic_frame_duration(sc->hw,
> NULL, len, rate);
> - return dur;
> + return le16_to_cpu(dur);
> }
>
> bitrate = rate->bitrate;
> @@ -265,8 +265,6 @@ static inline void ath5k_hw_write_rate_duration(struct ath5k_hw *ah)
> * what rate we should choose to TX ACKs. */
> tx_time = ath5k_hw_get_frame_duration(ah, 10, rate);
>
> - tx_time = le16_to_cpu(tx_time);
> -
> ath5k_hw_reg_write(ah, tx_time, reg);
>
> if (!(rate->flags & IEEE80211_RATE_SHORT_PREAMBLE))
> --
> 1.7.1.1
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix error handling in ath5k_hw_dma_stop
From: Nick Kossifidis @ 2011-01-25 12:24 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, Bruno Randolf, jirislaby, lrodriguez
In-Reply-To: <1295929904-11806-1-git-send-email-me@bobcopeland.com>
2011/1/25 Bob Copeland <me@bobcopeland.com>:
> Review spotted a problem with the error handling in ath5k_hw_dma_stop:
> a successful return from ath5k_hw_stop_tx_dma will be treated as
> an error, so we always bail out of the loop after processing a single
> active queue. As a result, we may not actually stop some queues during
> reset.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> These two patches fix some buglets I found when reviewing some old code.
>
> drivers/net/wireless/ath/ath5k/dma.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
> index 0064be7..e828b98 100644
> --- a/drivers/net/wireless/ath/ath5k/dma.c
> +++ b/drivers/net/wireless/ath/ath5k/dma.c
> @@ -838,7 +838,7 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
> for (i = 0; i < qmax; i++) {
> err = ath5k_hw_stop_tx_dma(ah, i);
> /* -EINVAL -> queue inactive */
> - if (err != -EINVAL)
> + if (err && err != -EINVAL)
> return err;
> }
>
> --
> 1.7.1.1
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* mini PCI express WLAN card
From: Josef Windorfer @ 2011-01-25 11:38 UTC (permalink / raw)
To: linux-wireless
Hi all,
I want to buy the mainboard ZOTAC G41-ITX with an mini PCI express WLAN card.
I have only a few information about the card (from the manufacturer).
It's an Atheros card with either AzureWave WiFi Modul AW NE771 or AzureWave WiFi AR5 B 91.
Is there a driver support in linux available?
I'm not realy successful by searching google.
Thanks!
Greets Josef
^ permalink raw reply
* RE: [PATCH] staging: brcm80211: bugfix for softmac crash on multi cpu configurations
From: Roland Vossen @ 2011-01-25 11:24 UTC (permalink / raw)
To: Greg KH; +Cc: devel@linuxdriverproject.org, linux-wireless@vger.kernel.org
In-Reply-To: <20110125111813.GA14763@suse.de>
>Should this also go to the .37 stable kernel tree?
Yes it should. Should I send you a patch for the .37 stable kernel tree ?
Thanks, Roland.
^ permalink raw reply
* Re: [PATCH] staging: brcm80211: bugfix for softmac crash on multi cpu configurations
From: Greg KH @ 2011-01-25 11:18 UTC (permalink / raw)
To: Roland Vossen; +Cc: devel, linux-wireless
In-Reply-To: <1295952716-16161-1-git-send-email-rvossen@broadcom.com>
On Tue, Jan 25, 2011 at 11:51:56AM +0100, Roland Vossen wrote:
> Solved a locking issue that resulted in driver crashes with the 43224 and 43225
> chips. The problem has been reported on several fora. Root cause was two fold:
> hardware was being manipulated by two unsynchronized threads, and a scan
> operation could interfere with an ongoing dynamic calibration process. Fix was
> to invoke a lock on wl_ops_config() operation and to set internal flags when a
> scan operation is started and stopped.
>
> Please add this to the staging-linus branch.
Should this also go to the .37 stable kernel tree?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] staging: brcm80211: bugfix for softmac crash on multi cpu configurations
From: Roland Vossen @ 2011-01-25 10:51 UTC (permalink / raw)
To: gregkh; +Cc: devel, linux-wireless
Solved a locking issue that resulted in driver crashes with the 43224 and 43225
chips. The problem has been reported on several fora. Root cause was two fold:
hardware was being manipulated by two unsynchronized threads, and a scan
operation could interfere with an ongoing dynamic calibration process. Fix was
to invoke a lock on wl_ops_config() operation and to set internal flags when a
scan operation is started and stopped.
Please add this to the staging-linus branch.
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Roland Vossen <rvossen@broadcom.com>
---
drivers/staging/brcm80211/sys/wl_mac80211.c | 12 ++++++++++--
drivers/staging/brcm80211/sys/wlc_mac80211.c | 13 +++++++++++++
drivers/staging/brcm80211/sys/wlc_pub.h | 2 ++
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/brcm80211/sys/wl_mac80211.c b/drivers/staging/brcm80211/sys/wl_mac80211.c
index f123588..cd8392b 100644
--- a/drivers/staging/brcm80211/sys/wl_mac80211.c
+++ b/drivers/staging/brcm80211/sys/wl_mac80211.c
@@ -263,9 +263,7 @@ ieee_set_channel(struct ieee80211_hw *hw, struct ieee80211_channel *chan,
switch (type) {
case NL80211_CHAN_HT20:
case NL80211_CHAN_NO_HT:
- WL_LOCK(wl);
err = wlc_set(wl->wlc, WLC_SET_CHANNEL, chan->hw_value);
- WL_UNLOCK(wl);
break;
case NL80211_CHAN_HT40MINUS:
case NL80211_CHAN_HT40PLUS:
@@ -285,6 +283,7 @@ static int wl_ops_config(struct ieee80211_hw *hw, u32 changed)
int err = 0;
int new_int;
+ WL_LOCK(wl);
if (changed & IEEE80211_CONF_CHANGE_LISTEN_INTERVAL) {
WL_NONE("%s: Setting listen interval to %d\n",
__func__, conf->listen_interval);
@@ -341,6 +340,7 @@ static int wl_ops_config(struct ieee80211_hw *hw, u32 changed)
}
config_out:
+ WL_UNLOCK(wl);
return err;
}
@@ -459,13 +459,21 @@ wl_ops_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta, bool set)
static void wl_ops_sw_scan_start(struct ieee80211_hw *hw)
{
+ struct wl_info *wl = hw->priv;
WL_NONE("Scan Start\n");
+ WL_LOCK(wl);
+ wlc_scan_start(wl->wlc);
+ WL_UNLOCK(wl);
return;
}
static void wl_ops_sw_scan_complete(struct ieee80211_hw *hw)
{
+ struct wl_info *wl = hw->priv;
WL_NONE("Scan Complete\n");
+ WL_LOCK(wl);
+ wlc_scan_stop(wl->wlc);
+ WL_UNLOCK(wl);
return;
}
diff --git a/drivers/staging/brcm80211/sys/wlc_mac80211.c b/drivers/staging/brcm80211/sys/wlc_mac80211.c
index a130386..e37e805 100644
--- a/drivers/staging/brcm80211/sys/wlc_mac80211.c
+++ b/drivers/staging/brcm80211/sys/wlc_mac80211.c
@@ -8461,3 +8461,16 @@ static void wlc_txq_free(struct wlc_info *wlc, struct osl_info *osh,
kfree(qi);
}
+
+/*
+ * Flag 'scan in progress' to withold dynamic phy calibration
+ */
+void wlc_scan_start(struct wlc_info *wlc)
+{
+ wlc_phy_hold_upd(wlc->band->pi, PHY_HOLD_FOR_SCAN, true);
+}
+
+void wlc_scan_stop(struct wlc_info *wlc)
+{
+ wlc_phy_hold_upd(wlc->band->pi, PHY_HOLD_FOR_SCAN, false);
+}
diff --git a/drivers/staging/brcm80211/sys/wlc_pub.h b/drivers/staging/brcm80211/sys/wlc_pub.h
index 146a690..aff4130 100644
--- a/drivers/staging/brcm80211/sys/wlc_pub.h
+++ b/drivers/staging/brcm80211/sys/wlc_pub.h
@@ -570,6 +570,8 @@ extern void wlc_enable_mac(struct wlc_info *wlc);
extern u16 wlc_rate_shm_offset(struct wlc_info *wlc, u8 rate);
extern u32 wlc_get_rspec_history(struct wlc_bsscfg *cfg);
extern u32 wlc_get_current_highest_rate(struct wlc_bsscfg *cfg);
+extern void wlc_scan_start(struct wlc_info *wlc);
+extern void wlc_scan_stop(struct wlc_info *wlc);
static inline int wlc_iovar_getuint(struct wlc_info *wlc, const char *name,
uint *arg)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/2] ath5k: correct endianness of frame duration
From: Bruno Randolf @ 2011-01-25 10:47 UTC (permalink / raw)
To: Bob Copeland; +Cc: linville, linux-wireless, mickflemm, jirislaby, lrodriguez
In-Reply-To: <20110125103803.GA2239@hash.localnet>
On Tue January 25 2011 19:38:03 Bob Copeland wrote:
> On Tue, Jan 25, 2011 at 02:23:31PM +0900, Bruno Randolf wrote:
> > > The ath5k version of ieee80211_generic_frame_duration() returns
> > > an __le16 for standard modes but a cpu-endian int for turbo/half/
> > > quarter rates. Make it always return cpu-endian values.
> >
> > I wonder what effect this has in ath5k_hw_set_ifs_intervals() where
> > ack_tx_time was little endian before...
>
> Good point, I didn't think about that. My guess is EIFS would have
> been much too large on big endian arches before the patch. But then
> EIFS resets after successful rx so maybe our many BE users (heh)
> wouldn't have noticed except on very idle channels...
Allright, just the EIFS is affected - shouldn't be a big deal. Anyhow it's
correct now and was wrong before.
But you meant on a very busy channel, right?
I'm on a BE board ;) I can try to see what difference it makes tomorrow.
bruno
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Johannes Berg @ 2011-01-25 10:42 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295950241.3650.3.camel@jlt3.sipsolutions.net>
On Tue, 2011-01-25 at 11:10 +0100, Johannes Berg wrote:
> On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
>
> > Well a wiphy flag won't do here. Probe requests may be filtered in
> > some modes (AP-mode) but needed in others (p2p?).
> > I think flexibility is a nice added bonus here. A FW can decide to
> > handle most standard probe-requests and simply not pass them up.
> > Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
> >
> > The current patches leave this policy in the hands of the driver/fw.
>
> That is _very_ dangerous. If the user has older firmware that doesn't
> know about WSC2, how would the user know not to configure WSC2 in
> hostapd? That needs to be known to hostapd so it can verify this
> situation. For P2P, we already know whether or not P2P is supported, but
> that's rather vague in case there will ever be a revision of the P2P
> spec with say different IEs.
>
> Additionally, a "regular AP" (not P2P, not WSC) would still want to
> reply to probe requests from WSC/P2P devices with the normal template.
>
> IMHO it would be smarter to rework the firmware to only reply to probe
> requests if the probe response is configured. Then, if WSC, P2P, or
> similar technologies are in use on the interface, hostapd can simply
> decide to not configure the probe response and have host-based
> processing. Would that be a change you could still make?
Of course, firmware can reply to non-p2p/non-wsc2 probe requests with a
static probe response template.
The question is how much knowledge you want to put into the firmware
about those protocols. If you want to put all knowledge in there, then
at least you need to indicate to hostapd which protocols the firmware
knows not to reply to.
Also, a way to turn off this behaviour would still be good for future
protocol changes. If P2P changes in 3 years, I'm sure this firmware
won't be updated to match since you'll be a few hardware generations
ahead. Then, being able to turn off the offload completely would allow
users to take advantage of new protocols without changing hardware. Of
course, you may want to force users to buy new hardware that way -- but
in that case we *still* need the advertisement of what's possible so
users know right away that they need to buy new hardware and don't try
to configure something that just fails in strange ways.
johannes
^ 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