* [PATCH] iwlwifi: recalculate average tpt if not current
From: reinette chatre @ 2010-05-03 17:55 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, johannes, Adel Gadllah
In-Reply-To: <1272908934.7879.5748.camel@rchatre-DESK>
From: Reinette Chatre <reinette.chatre@intel.com>
We currently have this check as a BUG_ON, which is being hit by people.
Previously it was an error with a recalculation if not current, return that
code.
The BUG_ON was introduced by:
commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
Author: Guy Cohen <guy.cohen@intel.com>
Date: Tue Sep 9 10:54:54 2008 +0800
iwlwifi: Added support for 3 antennas
... the portion adding the BUG_ON is reverted since we are encountering the error
and BUG_ON was created with assumption that error is not encountered.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index b93e491..75a145c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2070,10 +2070,12 @@ static void rs_rate_scale_perform(struct iwl_priv *priv,
}
/* Else we have enough samples; calculate estimate of
* actual average throughput */
-
- /* Sanity-check TPT calculations */
- BUG_ON(window->average_tpt != ((window->success_ratio *
- tbl->expected_tpt[index] + 64) / 128));
+ if (window->average_tpt != ((window->success_ratio *
+ tbl->expected_tpt[index] + 64) / 128)) {
+ IWL_ERR(priv, "expected_tpt should have been calculated by now\n");
+ window->average_tpt = ((window->success_ratio *
+ tbl->expected_tpt[index] + 64) / 128);
+ }
/* If we are searching for better modulation mode, check success. */
if (lq_sta->search_better_tbl &&
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH V2] mac80211: fix paged defragmentation
From: John W. Linville @ 2010-05-03 18:02 UTC (permalink / raw)
To: Ben Gamari; +Cc: Abhijeet Kolekar, linux-wireless, yi.zhu
In-Reply-To: <87hbmsa4bj.fsf@gmail.com>
On Fri, Apr 30, 2010 at 07:49:52PM -0400, Ben Gamari wrote:
> On Fri, 30 Apr 2010 15:57:59 -0700, Abhijeet Kolekar <abhijeet.kolekar@intel.com> wrote:
> >
> > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> > index 72efbd8..e7217e2 100644
> > --- a/net/mac80211/rx.c
> > +++ b/net/mac80211/rx.c
> > @@ -1255,6 +1255,7 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
> > if (skb_linearize(rx->skb))
> > return RX_DROP_UNUSABLE;
> >
> > + hdr = (struct ieee80211_hdr *)rx->skb->data;
> > seq = (sc & IEEE80211_SCTL_SEQ) >> 4;
> >
> It seems to me that this might deserve a comment describing exactly why
> hdr needs to be set twice in one function. To the uninformed outsider
> the code simply seems redundant. It's unclear semantics like this that
> could cause nasty issues when someone goes back for housecleaning. Just
> a thought.
Not only that, but is there something we need to do to make sure the
compiler doesn't think it can optimize away the second assignment
of hdr?
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 wireless-2.6] iwlwifi: work around passive scan issue
From: John W. Linville @ 2010-05-03 18:07 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linux-wireless, ipw3945-devel, Johannes Berg
In-Reply-To: <1272668402-3722-1-git-send-email-reinette.chatre@intel.com>
On Fri, Apr 30, 2010 at 04:00:02PM -0700, Reinette Chatre wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Some firmware versions don't behave properly when
> passive scanning is requested on radar channels
> without enabling active scanning on receiving a
> good frame. Work around that issue by asking the
> firmware to only enable the active scanning after
> receiving a huge number of good frames, a number
> that can never be reached during our dwell time.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
What is the consequence of this bug? It is very late in the 2.6.34
cycle and it isn't obvious to me that this is something that has to
be fixed in this cycle. I see the comment about "sysassert", but I
don't know if that leads to something inconvenient (like restarting
the firmware) or something much worse?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] compat-wireless: refresh patches
From: Hauke Mehrtens @ 2010-05-03 18:35 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
Make the patches apply cleanly again.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/25-multicast-list_head.patch | 26 +++++++++++++-------------
patches/26-sdio-quirks.patch | 4 ++--
patches/99-change-makefiles.patch | 5 +++--
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/patches/25-multicast-list_head.patch b/patches/25-multicast-list_head.patch
index d18735c..3cfde8a 100644
--- a/patches/25-multicast-list_head.patch
+++ b/patches/25-multicast-list_head.patch
@@ -124,7 +124,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
return mc_filter[0] | ((u64)(mc_filter[1]) << 32);
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
-@@ -2047,17 +2047,35 @@ out:
+@@ -2046,17 +2046,35 @@ out:
return err;
}
@@ -174,7 +174,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
static void ath5k_configure_filter(struct ieee80211_hw *hw,
unsigned int changed_flags,
unsigned int *new_flags,
-@@ -3108,20 +3112,42 @@ unlock:
+@@ -3107,20 +3111,42 @@ unlock:
}
static u64 ath5k_prepare_multicast(struct ieee80211_hw *hw,
@@ -217,7 +217,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
pos ^= (val >> 18) ^ (val >> 12) ^ (val >> 6) ^ val;
pos &= 0x3f;
mfilt[pos / 32] |= (1 << (pos % 32));
-@@ -3130,6 +3156,9 @@ static u64 ath5k_prepare_multicast(struc
+@@ -3129,6 +3155,9 @@ static u64 ath5k_prepare_multicast(struc
* neet to inform below to not reset the mcast */
/* ath5k_hw_set_mcast_filterindex(ah,
* ha->addr[5]); */
@@ -305,7 +305,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
}
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
-@@ -1939,15 +1939,21 @@ struct mwl8k_cmd_mac_multicast_adr {
+@@ -1937,15 +1937,21 @@ struct mwl8k_cmd_mac_multicast_adr {
static struct mwl8k_cmd_pkt *
__mwl8k_cmd_mac_multicast_adr(struct ieee80211_hw *hw, int allmulti,
@@ -327,7 +327,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
if (allmulti || mc_count > priv->num_mcaddrs) {
allmulti = 1;
-@@ -1968,13 +1974,27 @@ __mwl8k_cmd_mac_multicast_adr(struct iee
+@@ -1966,13 +1972,27 @@ __mwl8k_cmd_mac_multicast_adr(struct iee
if (allmulti) {
cmd->action |= cpu_to_le16(MWL8K_ENABLE_RX_ALL_MULTICAST);
} else if (mc_count) {
@@ -355,7 +355,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
}
}
-@@ -3553,7 +3573,11 @@ mwl8k_bss_info_changed(struct ieee80211_
+@@ -3551,7 +3571,11 @@ mwl8k_bss_info_changed(struct ieee80211_
}
static u64 mwl8k_prepare_multicast(struct ieee80211_hw *hw,
@@ -367,7 +367,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
{
struct mwl8k_cmd_pkt *cmd;
-@@ -3564,7 +3588,11 @@ static u64 mwl8k_prepare_multicast(struc
+@@ -3562,7 +3586,11 @@ static u64 mwl8k_prepare_multicast(struc
* we'll end up throwing this packet away and creating a new
* one in mwl8k_configure_filter().
*/
@@ -379,7 +379,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
return (unsigned long)cmd;
}
-@@ -3687,7 +3715,11 @@ static void mwl8k_configure_filter(struc
+@@ -3685,7 +3713,11 @@ static void mwl8k_configure_filter(struc
*/
if (*total_flags & FIF_ALLMULTI) {
kfree(cmd);
@@ -433,7 +433,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
-@@ -724,10 +724,19 @@ static void rtl8180_bss_info_changed(str
+@@ -725,10 +725,19 @@ static void rtl8180_bss_info_changed(str
priv->rf->conf_erp(dev, info);
}
@@ -475,7 +475,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
static void rtl8187_configure_filter(struct ieee80211_hw *dev,
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
-@@ -1305,11 +1305,20 @@ struct wl1271_filter_params {
+@@ -1344,11 +1344,20 @@ struct wl1271_filter_params {
u8 mc_list[ACX_MC_ADDRESS_GROUP_MAX][ETH_ALEN];
};
@@ -494,9 +494,9 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
+ int i;
+#endif
struct wl1271 *wl = hw->priv;
- int i;
-@@ -1323,16 +1332,40 @@ static u64 wl1271_op_prepare_multicast(s
+ if (unlikely(wl->state == WL1271_STATE_OFF))
+@@ -1361,16 +1370,40 @@ static u64 wl1271_op_prepare_multicast(s
}
/* update multicast filtering parameters */
@@ -576,7 +576,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
return hash.low | ((u64)hash.high << 32);
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
-@@ -1642,7 +1642,11 @@ struct ieee80211_ops {
+@@ -1646,7 +1646,11 @@ struct ieee80211_ops {
struct ieee80211_bss_conf *info,
u32 changed);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
diff --git a/patches/26-sdio-quirks.patch b/patches/26-sdio-quirks.patch
index 2fec33d..133e9bb 100644
--- a/patches/26-sdio-quirks.patch
+++ b/patches/26-sdio-quirks.patch
@@ -2,7 +2,7 @@ The quirks attribute is not available on older kernels.
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
-@@ -1003,6 +1003,7 @@ static int if_sdio_probe(struct sdio_fun
+@@ -1005,6 +1005,7 @@ static int if_sdio_probe(struct sdio_fun
if (ret)
goto disable;
@@ -10,7 +10,7 @@ The quirks attribute is not available on older kernels.
/* For 1-bit transfers to the 8686 model, we need to enable the
* interrupt flag in the CCCR register. Set the MMC_QUIRK_LENIENT_FN0
* bit to allow access to non-vendor registers. */
-@@ -1021,6 +1022,7 @@ static int if_sdio_probe(struct sdio_fun
+@@ -1023,6 +1024,7 @@ static int if_sdio_probe(struct sdio_fun
if (ret)
goto release_int;
}
diff --git a/patches/99-change-makefiles.patch b/patches/99-change-makefiles.patch
index ad7ccc5..47f3b5c 100644
--- a/patches/99-change-makefiles.patch
+++ b/patches/99-change-makefiles.patch
@@ -13,7 +13,7 @@ only the wireless stuff.
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
-@@ -2,26 +2,6 @@
+@@ -2,27 +2,7 @@
# Makefile for USB Network drivers
#
@@ -39,7 +39,8 @@ only the wireless stuff.
-obj-$(CONFIG_USB_NET_INT51X1) += int51x1.o
-obj-$(CONFIG_USB_CDC_PHONET) += cdc-phonet.o
-obj-$(CONFIG_USB_IPHETH) += ipheth.o
--
+-obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
+
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -7,31 +7,16 @@ obj-$(CONFIG_IPW2200) += ipw2x00/
--
1.7.0.4
^ permalink raw reply related
* [PATCH] compat: backport usb_alloc_coherent() and usb_free_coherent()
From: Hauke Mehrtens @ 2010-05-03 18:36 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.35.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.35.h b/include/linux/compat-2.6.35.h
index 9132ecb..62c54cf 100644
--- a/include/linux/compat-2.6.35.h
+++ b/include/linux/compat-2.6.35.h
@@ -19,6 +19,8 @@ static inline wait_queue_head_t *sk_sleep(struct sock *sk)
{
return sk->sk_sleep;
}
+#define usb_alloc_coherent usb_buffer_alloc
+#define usb_free_coherent usb_buffer_free
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)) */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] compat: backport usb_alloc_coherent() and usb_free_coherent()
From: Pavel Roskin @ 2010-05-03 19:10 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: lrodriguez, linux-wireless, mcgrof
In-Reply-To: <1272911773-18486-1-git-send-email-hauke@hauke-m.de>
On Mon, 2010-05-03 at 20:36 +0200, Hauke Mehrtens wrote:
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> include/linux/compat-2.6.35.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/compat-2.6.35.h b/include/linux/compat-2.6.35.h
> index 9132ecb..62c54cf 100644
> --- a/include/linux/compat-2.6.35.h
> +++ b/include/linux/compat-2.6.35.h
> @@ -19,6 +19,8 @@ static inline wait_queue_head_t *sk_sleep(struct sock *sk)
> {
> return sk->sk_sleep;
> }
> +#define usb_alloc_coherent usb_buffer_alloc
> +#define usb_free_coherent usb_buffer_free
I believe macros with arguments are preferred.
It really matters in case of simple names that can be reasonably used as
variable names as well (e.g. "max").
In this case, it's more a matter of style and readability.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: kernel BUG in iwl-agn-rs.c:2076, WAS: iwlagn + some accesspoint == hardlock
From: John W. Linville @ 2010-05-03 19:22 UTC (permalink / raw)
To: NilsRadtkelkml; +Cc: linux-kernel, reinette.chatre, linux-wireless
In-Reply-To: <20100503191756.GA3479@localhost>
On Mon, May 03, 2010 at 09:17:56PM +0200, NilsRadtkelkml@Think-Future.de wrote:
> Strangely, as stated in the previous message, this bug does only happen in conjunction at a specific
> geographical position, so far it only happened there that is. How does this correlate with the designated
> code at line 2076 in iwl-agn-rs.c?:
>
> /* Sanity-check TPT calculations */
> BUG_ON(window->average_tpt != ((window->success_ratio *
> tbl->expected_tpt[index] + 64) / 128));
Interestingly enough, we have been discussing this line of code today. Could you try the patch here?
http://marc.info/?l=linux-wireless&m=127290931304496&w=2
Does it address the issue you are experiencing?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH v2] compat: backport usb_alloc_coherent() and usb_free_coherent()
From: Hauke Mehrtens @ 2010-05-03 19:36 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, proski, Hauke Mehrtens
In-Reply-To: <1272913838.2607.5.camel@mj>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
v2: Add arguments to define
include/linux/compat-2.6.35.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.35.h b/include/linux/compat-2.6.35.h
index 9132ecb..9c6e696 100644
--- a/include/linux/compat-2.6.35.h
+++ b/include/linux/compat-2.6.35.h
@@ -20,6 +20,9 @@ static inline wait_queue_head_t *sk_sleep(struct sock *sk)
return sk->sk_sleep;
}
+#define usb_alloc_coherent(dev, size, mem_flags, dma) usb_buffer_alloc(dev, size, mem_flags, dma)
+#define usb_free_coherent(dev, size, addr, dma) usb_buffer_free(dev, size, addr, dma)
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)) */
#endif /* LINUX_26_35_COMPAT_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH] p54: Added get_survey callback in order to get channel noise
From: John W. Linville @ 2010-05-03 20:06 UTC (permalink / raw)
To: linux-wireless; +Cc: chunkeey, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
The code seems correct, but the value reported seems to swing between
127 dBm and -1 dBm?
drivers/net/wireless/p54/main.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index 10a4b16..3da46ef 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -506,6 +506,22 @@ out_unlock:
return ret;
}
+static int p54_get_survey(struct ieee80211_hw *dev, int idx,
+ struct survey_info *survey)
+{
+ struct p54_common *priv = dev->priv;
+ struct ieee80211_conf *conf = &dev->conf;
+
+ if (idx != 0)
+ return -ENOENT;
+
+ survey->channel = conf->channel;
+ survey->filled = SURVEY_INFO_NOISE_DBM;
+ survey->noise = priv->noise;
+
+ return 0;
+}
+
static const struct ieee80211_ops p54_ops = {
.tx = p54_tx_80211,
.start = p54_start,
@@ -522,6 +538,7 @@ static const struct ieee80211_ops p54_ops = {
.configure_filter = p54_configure_filter,
.conf_tx = p54_conf_tx,
.get_stats = p54_get_stats,
+ .get_survey = p54_get_survey,
};
struct ieee80211_hw *p54_init_common(size_t priv_data_len)
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: Kalle Valo @ 2010-05-03 20:29 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, johill, reinette.chatre, Adel Gadllah
In-Reply-To: <1272907549-25847-1-git-send-email-linville@tuxdriver.com>
"John W. Linville" <linville@tuxdriver.com> writes:
> From: Adel Gadllah <adel.gadllah@gmail.com>
>
> Currently it is a BUG_ON() which will hang the machine once triggered.
Related to this: can we have a rule that no wireless driver should
ever use BUG_ON()? I think we could extend this even to cfg80211 and
mac80211.
BUG_ON() is valid whenever there's a risk of corrupting data, for
example on a filesystem, but I really don't see the point of using
them in wireless drivers. They just make things miserable, especially
for the normal users. Printing a warning and handling the case as
gracefully as possible is much better IMHO.
--
Kalle Valo
^ permalink raw reply
* Re: [ANN] Mendiosus rt2800usb project
From: Dan Williams @ 2010-05-03 20:34 UTC (permalink / raw)
To: John W. Linville; +Cc: info, linux-wireless, rt2x00 Users List
In-Reply-To: <20100503165246.GC24781@tuxdriver.com>
On Mon, 2010-05-03 at 12:52 -0400, John W. Linville wrote:
> On Mon, May 03, 2010 at 05:29:00PM +0200, info@mendiosus.nl wrote:
> > The Dutch company Mendiosus is pleased to announce that, with support
> > of an United States based open-source development house, it will
> > be working on the rt2800usb drivers. Development will focus on
> > improving support for the rt2870 and rt2770 chipsets.
> > Besides improvements of the basic functionality development will also
> > focus on adding hardware cryptography and better 11n support.
>
> Excellent! I look forward to seeing some good results from this!
Yeah, this is excellent news. It's been great to see rt2800 and later
chipsets getting a lot of attention recently.
Dan
^ permalink raw reply
* [PATCH 1/4] rt2x00: Remove rt2x00pci.h include from rt2800lib.
From: Gertjan van Wingerde @ 2010-05-03 20:43 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo van Doorn, linux-wireless, users, Gertjan van Wingerde
In-Reply-To: <1272919385-18004-1-git-send-email-gwingerde@gmail.com>
PCI specific code has been remove quite some time ago.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 674609d..7310f34 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -40,9 +40,6 @@
#if defined(CONFIG_RT2X00_LIB_USB) || defined(CONFIG_RT2X00_LIB_USB_MODULE)
#include "rt2x00usb.h"
#endif
-#if defined(CONFIG_RT2X00_LIB_PCI) || defined(CONFIG_RT2X00_LIB_PCI_MODULE)
-#include "rt2x00pci.h"
-#endif
#include "rt2800lib.h"
#include "rt2800.h"
#include "rt2800usb.h"
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Gertjan van Wingerde @ 2010-05-03 20:43 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo van Doorn, linux-wireless, users, Gertjan van Wingerde
In-Reply-To: <1272919385-18004-1-git-send-email-gwingerde@gmail.com>
Now that RT30xx support is at the same level as RT28xx support we can enable
these devices by default.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index 5239e08..eea1ef2 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -87,7 +87,7 @@ if RT2800PCI
config RT2800PCI_RT30XX
bool "rt2800pci - Include support for rt30xx (PCI/PCIe/PCMCIA) devices"
- default n
+ default y
---help---
This adds support for rt30xx wireless chipset family to the
rt2800pci driver.
@@ -156,7 +156,7 @@ if RT2800USB
config RT2800USB_RT30XX
bool "rt2800usb - Include support for rt30xx (USB) devices"
- default n
+ default y
---help---
This adds support for rt30xx wireless chipset family to the
rt2800usb driver.
--
1.7.1
^ permalink raw reply related
* [PATCH 0/4] rt2x00: Assorted fixes and cleanups.
From: Gertjan van Wingerde @ 2010-05-03 20:43 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo van Doorn, linux-wireless, users, Gertjan van Wingerde
Just a random set up fixes and cleanups for rt2x00.
All patches are against wireless-next-2.6.
The 3rd patch doesn't actually fix our HT40 issue for rt2800, but should
be a step in the right direction.
Gertjan van Wingerde (4):
rt2x00: Remove rt2x00pci.h include from rt2800lib.
rt2x00: Enable RT30xx by default.
rt2x00: Fix HT40+/HT40- setting in rt2800.
rt2x00: Register frame length in TX entry descriptor instead of L2PAD.
drivers/net/wireless/rt2x00/Kconfig | 4 ++--
drivers/net/wireless/rt2x00/rt2400pci.c | 4 ++--
drivers/net/wireless/rt2x00/rt2500pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2800.h | 4 ++--
drivers/net/wireless/rt2x00/rt2800lib.c | 7 ++-----
drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 6 ++----
drivers/net/wireless/rt2x00/rt2x00queue.h | 4 ++--
drivers/net/wireless/rt2x00/rt61pci.c | 5 +++--
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
12 files changed, 20 insertions(+), 24 deletions(-)
^ permalink raw reply
* [PATCH 4/4] rt2x00: Register frame length in TX entry descriptor instead of L2PAD.
From: Gertjan van Wingerde @ 2010-05-03 20:43 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo van Doorn, linux-wireless, users, Gertjan van Wingerde
In-Reply-To: <1272919385-18004-1-git-send-email-gwingerde@gmail.com>
And use it consistently in the chipset drivers.
Preparation for further clean ups.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt2400pci.c | 4 ++--
drivers/net/wireless/rt2x00/rt2500pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 6 ++----
drivers/net/wireless/rt2x00/rt2x00queue.h | 4 ++--
drivers/net/wireless/rt2x00/rt61pci.c | 5 +++--
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
9 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 08a4789..6f89891 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1017,8 +1017,8 @@ static void rt2400pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
rt2x00_desc_write(entry_priv->desc, 1, word);
rt2x00_desc_read(txd, 2, &word);
- rt2x00_set_field32(&word, TXD_W2_BUFFER_LENGTH, skb->len);
- rt2x00_set_field32(&word, TXD_W2_DATABYTE_COUNT, skb->len);
+ rt2x00_set_field32(&word, TXD_W2_BUFFER_LENGTH, txdesc->length);
+ rt2x00_set_field32(&word, TXD_W2_DATABYTE_COUNT, txdesc->length);
rt2x00_desc_write(txd, 2, word);
rt2x00_desc_read(txd, 3, &word);
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index d084d70..d9b6304 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1208,7 +1208,7 @@ static void rt2500pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
- rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len);
+ rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, txdesc->length);
rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
rt2x00_desc_write(txd, 0, word);
}
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index c1eec17..c6e6e7b 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1071,7 +1071,7 @@ static void rt2500usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(&word, TXD_W0_NEW_SEQ,
test_bit(ENTRY_TXD_FIRST_FRAGMENT, &txdesc->flags));
rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
- rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len);
+ rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, txdesc->length);
rt2x00_set_field32(&word, TXD_W0_CIPHER, !!txdesc->cipher);
rt2x00_set_field32(&word, TXD_W0_KEY_ID, txdesc->key_idx);
rt2x00_desc_write(txd, 0, word);
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 89281d7..f08b6a3 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -663,7 +663,7 @@ static int rt2800pci_write_tx_data(struct queue_entry* entry,
test_bit(ENTRY_TXD_ENCRYPT, &txdesc->flags) ?
txdesc->key_idx : 0xff);
rt2x00_set_field32(&word, TXWI_W1_MPDU_TOTAL_BYTE_COUNT,
- skb->len - txdesc->l2pad);
+ txdesc->length);
rt2x00_set_field32(&word, TXWI_W1_PACKETID,
skbdesc->entry->queue->qid + 1);
rt2x00_desc_write(txwi, 1, word);
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 2b79d6e..67f8234 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -437,7 +437,7 @@ static void rt2800usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
test_bit(ENTRY_TXD_ENCRYPT, &txdesc->flags) ?
txdesc->key_idx : 0xff);
rt2x00_set_field32(&word, TXWI_W1_MPDU_TOTAL_BYTE_COUNT,
- skb->len - txdesc->l2pad);
+ txdesc->length);
rt2x00_set_field32(&word, TXWI_W1_PACKETID,
skbdesc->entry->queue->qid + 1);
rt2x00_desc_write(txwi, 1, word);
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index a68cf90..59d9459 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -333,12 +333,10 @@ static void rt2x00queue_create_tx_descriptor(struct queue_entry *entry,
txdesc->aifs = entry->queue->aifs;
/*
- * Header and alignment information.
+ * Header and frame information.
*/
+ txdesc->length = entry->skb->len;
txdesc->header_length = ieee80211_get_hdrlen_from_skb(entry->skb);
- if (test_bit(DRIVER_REQUIRE_L2PAD, &rt2x00dev->flags) &&
- (entry->skb->len > txdesc->header_length))
- txdesc->l2pad = L2PAD_SIZE(txdesc->header_length);
/*
* Check whether this frame is to be acked.
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
index f519aba..94a48c1 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.h
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
@@ -285,8 +285,8 @@ enum txentry_desc_flags {
*
* @flags: Descriptor flags (See &enum queue_entry_flags).
* @queue: Queue identification (See &enum data_queue_qid).
+ * @length: Length of the entire frame.
* @header_length: Length of 802.11 header.
- * @l2pad: Amount of padding to align 802.11 payload to 4-byte boundrary.
* @length_high: PLCP length high word.
* @length_low: PLCP length low word.
* @signal: PLCP signal.
@@ -311,8 +311,8 @@ struct txentry_desc {
enum data_queue_qid queue;
+ u16 length;
u16 header_length;
- u16 l2pad;
u16 length_high;
u16 length_low;
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index ac69dbe..8099eca 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -1808,7 +1808,8 @@ static void rt61pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
if (skbdesc->desc_len > TXINFO_SIZE) {
rt2x00_desc_read(txd, 11, &word);
- rt2x00_set_field32(&word, TXD_W11_BUFFER_LENGTH0, skb->len);
+ rt2x00_set_field32(&word, TXD_W11_BUFFER_LENGTH0,
+ txdesc->length);
rt2x00_desc_write(txd, 11, word);
}
@@ -1831,7 +1832,7 @@ static void rt61pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(&word, TXD_W0_KEY_TABLE,
test_bit(ENTRY_TXD_ENCRYPT_PAIRWISE, &txdesc->flags));
rt2x00_set_field32(&word, TXD_W0_KEY_INDEX, txdesc->key_idx);
- rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len);
+ rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, txdesc->length);
rt2x00_set_field32(&word, TXD_W0_BURST,
test_bit(ENTRY_TXD_BURST, &txdesc->flags));
rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, txdesc->cipher);
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 7ebe14b..1399c18 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -1494,7 +1494,7 @@ static void rt73usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(&word, TXD_W0_KEY_TABLE,
test_bit(ENTRY_TXD_ENCRYPT_PAIRWISE, &txdesc->flags));
rt2x00_set_field32(&word, TXD_W0_KEY_INDEX, txdesc->key_idx);
- rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len);
+ rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, txdesc->length);
rt2x00_set_field32(&word, TXD_W0_BURST2,
test_bit(ENTRY_TXD_BURST, &txdesc->flags));
rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, txdesc->cipher);
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] rt2x00: Fix HT40+/HT40- setting in rt2800.
From: Gertjan van Wingerde @ 2010-05-03 20:43 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo van Doorn, linux-wireless, users, Gertjan van Wingerde
In-Reply-To: <1272919385-18004-1-git-send-email-gwingerde@gmail.com>
Inspection of the Ralink vendor driver shows that the TX_BAND_CFG register
and BBP register 3 are about HT40- indication, not about HT40+ indication.
Inverse the meaning of these fields in the code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800.h | 4 ++--
drivers/net/wireless/rt2x00/rt2800lib.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index 4c0b481..2aa0375 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -845,7 +845,7 @@
* TX_BAND_CFG: 0x1 use upper 20MHz, 0x0 use lower 20MHz
*/
#define TX_BAND_CFG 0x132c
-#define TX_BAND_CFG_HT40_PLUS FIELD32(0x00000001)
+#define TX_BAND_CFG_HT40_MINUS FIELD32(0x00000001)
#define TX_BAND_CFG_A FIELD32(0x00000002)
#define TX_BAND_CFG_BG FIELD32(0x00000004)
@@ -1519,7 +1519,7 @@ struct mac_iveiv_entry {
* BBP 3: RX Antenna
*/
#define BBP3_RX_ANTENNA FIELD8(0x18)
-#define BBP3_HT40_PLUS FIELD8(0x20)
+#define BBP3_HT40_MINUS FIELD8(0x20)
/*
* BBP 4: Bandwidth
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 7310f34..6d2c66d 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -867,7 +867,7 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
}
rt2800_register_read(rt2x00dev, TX_BAND_CFG, ®);
- rt2x00_set_field32(®, TX_BAND_CFG_HT40_PLUS, conf_is_ht40_plus(conf));
+ rt2x00_set_field32(®, TX_BAND_CFG_HT40_MINUS, conf_is_ht40_minus(conf));
rt2x00_set_field32(®, TX_BAND_CFG_A, rf->channel > 14);
rt2x00_set_field32(®, TX_BAND_CFG_BG, rf->channel <= 14);
rt2800_register_write(rt2x00dev, TX_BAND_CFG, reg);
@@ -900,7 +900,7 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
rt2800_bbp_write(rt2x00dev, 4, bbp);
rt2800_bbp_read(rt2x00dev, 3, &bbp);
- rt2x00_set_field8(&bbp, BBP3_HT40_PLUS, conf_is_ht40_plus(conf));
+ rt2x00_set_field8(&bbp, BBP3_HT40_MINUS, conf_is_ht40_minus(conf));
rt2800_bbp_write(rt2x00dev, 3, bbp);
if (rt2x00_rt_rev(rt2x00dev, RT2860, REV_RT2860C)) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: Gábor Stefanik @ 2010-05-03 20:48 UTC (permalink / raw)
To: Kalle Valo
Cc: John W. Linville, linux-wireless, johill, reinette.chatre,
Adel Gadllah
In-Reply-To: <87k4rkk9tz.fsf@purkki.valot.fi>
On Mon, May 3, 2010 at 10:29 PM, Kalle Valo <kvalo@adurom.com> wrote:
> "John W. Linville" <linville@tuxdriver.com> writes:
>
>> From: Adel Gadllah <adel.gadllah@gmail.com>
>>
>> Currently it is a BUG_ON() which will hang the machine once triggered.
>
> Related to this: can we have a rule that no wireless driver should
> ever use BUG_ON()? I think we could extend this even to cfg80211 and
> mac80211.
>
> BUG_ON() is valid whenever there's a risk of corrupting data, for
> example on a filesystem, but I really don't see the point of using
> them in wireless drivers. They just make things miserable, especially
> for the normal users. Printing a warning and handling the case as
> gracefully as possible is much better IMHO.
>
One exception I can think of: major misconfiguration can cause a
wireless device to DMA data into sensitive memory locations. When
evidence of this is detected, it might make sense to BUG_ON()
(especially if the bogus DMA operations can be exploited remotely to
overwrite arbitrary memory addresses). However, in that case, the
attacker may have already overwritten panic() with malicious code as
well, so even this case doesn't hold.
The other thing that comes to my mind is when there is a risk of
physically frying the card, but given that BUG_ON() doesn't cut power
to the PCI bus (at least not on x86 - dunno about other platforms),
this one falls down pretty easily too.
> --
> Kalle Valo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH wireless-2.6] iwlwifi: work around passive scan issue
From: reinette chatre @ 2010-05-03 20:50 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Berg, Johannes
In-Reply-To: <20100503180659.GC25748@tuxdriver.com>
Hi John,
On Mon, 2010-05-03 at 11:07 -0700, John W. Linville wrote:
> On Fri, Apr 30, 2010 at 04:00:02PM -0700, Reinette Chatre wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > Some firmware versions don't behave properly when
> > passive scanning is requested on radar channels
> > without enabling active scanning on receiving a
> > good frame. Work around that issue by asking the
> > firmware to only enable the active scanning after
> > receiving a huge number of good frames, a number
> > that can never be reached during our dwell time.
> >
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
>
> What is the consequence of this bug? It is very late in the 2.6.34
> cycle and it isn't obvious to me that this is something that has to
> be fixed in this cycle. I see the comment about "sysassert", but I
> don't know if that leads to something inconvenient (like restarting
> the firmware) or something much worse?
Unfortunately a sysassert does lead to firmware restart.
Reinette
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Pavel Roskin @ 2010-05-03 20:59 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: John W. Linville, Ivo van Doorn, linux-wireless, users
In-Reply-To: <1272919385-18004-3-git-send-email-gwingerde@gmail.com>
On Mon, 2010-05-03 at 22:43 +0200, Gertjan van Wingerde wrote:
> Now that RT30xx support is at the same level as RT28xx support we can enable
> these devices by default.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/Kconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
> index 5239e08..eea1ef2 100644
> --- a/drivers/net/wireless/rt2x00/Kconfig
> +++ b/drivers/net/wireless/rt2x00/Kconfig
> @@ -87,7 +87,7 @@ if RT2800PCI
>
> config RT2800PCI_RT30XX
> bool "rt2800pci - Include support for rt30xx (PCI/PCIe/PCMCIA) devices"
> - default n
> + default y
I believe defaulting booleans to "y" is discouraged, especially for
drivers. Most users don't have any particular hardware device.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: Pavel Roskin @ 2010-05-03 21:01 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Kalle Valo, John W. Linville, linux-wireless, johill,
reinette.chatre, Adel Gadllah
In-Reply-To: <AANLkTimf_aZyUSZInOzUPZ8KRR6oDs3Re4pSGGn541fM@mail.gmail.com>
On Mon, 2010-05-03 at 22:48 +0200, Gábor Stefanik wrote:
> One exception I can think of: major misconfiguration can cause a
> wireless device to DMA data into sensitive memory locations. When
> evidence of this is detected, it might make sense to BUG_ON()
> (especially if the bogus DMA operations can be exploited remotely to
> overwrite arbitrary memory addresses). However, in that case, the
> attacker may have already overwritten panic() with malicious code as
> well, so even this case doesn't hold.
And then there is a case when encryption fails and there is a risk of
transmitting data without encryption or accepting data without
verification.
But generally, I agree.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: Adel Gadllah @ 2010-05-03 21:10 UTC (permalink / raw)
To: Pavel Roskin
Cc: Gábor Stefanik, Kalle Valo, John W. Linville, linux-wireless,
johill, reinette.chatre
In-Reply-To: <1272920504.4907.5.camel@mj>
2010/5/3 Pavel Roskin <proski@gnu.org>:
> On Mon, 2010-05-03 at 22:48 +0200, Gábor Stefanik wrote:
>
>> One exception I can think of: major misconfiguration can cause a
>> wireless device to DMA data into sensitive memory locations. When
>> evidence of this is detected, it might make sense to BUG_ON()
>> (especially if the bogus DMA operations can be exploited remotely to
>> overwrite arbitrary memory addresses). However, in that case, the
>> attacker may have already overwritten panic() with malicious code as
>> well, so even this case doesn't hold.
>
> And then there is a case when encryption fails and there is a risk of
> transmitting data without encryption or accepting data without
> verification.
So kill the connection rather than the whole system.
^ permalink raw reply
* Re: [PATCH] iwlagn: Change the TPT calculations sanity-check to WARN_ON
From: Gábor Stefanik @ 2010-05-03 21:20 UTC (permalink / raw)
To: Adel Gadllah
Cc: Pavel Roskin, Kalle Valo, John W. Linville, linux-wireless,
johill, reinette.chatre
In-Reply-To: <l2m6cf6b73e1005031410t7c6d3148x832ddd405fc482ec@mail.gmail.com>
On Mon, May 3, 2010 at 11:10 PM, Adel Gadllah <adel.gadllah@gmail.com> wrote:
> 2010/5/3 Pavel Roskin <proski@gnu.org>:
>> On Mon, 2010-05-03 at 22:48 +0200, Gábor Stefanik wrote:
>>
>>> One exception I can think of: major misconfiguration can cause a
>>> wireless device to DMA data into sensitive memory locations. When
>>> evidence of this is detected, it might make sense to BUG_ON()
>>> (especially if the bogus DMA operations can be exploited remotely to
>>> overwrite arbitrary memory addresses). However, in that case, the
>>> attacker may have already overwritten panic() with malicious code as
>>> well, so even this case doesn't hold.
>>
>> And then there is a case when encryption fails and there is a risk of
>> transmitting data without encryption or accepting data without
>> verification.
>
> So kill the connection rather than the whole system.
Or maybe just drop the packet, as mac80211 AFAIK usually does. Perhaps
print a WARN_ON to let developers know of the issue. But a BUG_ON is
still excessive - I can't think of any way a WARN_ON + interface down
may fail in preventing unencrypted data leak.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: ar9170-fw II
From: Luis R. Rodriguez @ 2010-05-03 21:39 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Christian Lamparter, linux-wireless
In-Reply-To: <4BDC719E.3060505@dlasys.net>
On Sat, May 1, 2010 at 11:23 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> On 05/01/2010 01:19 PM, Christian Lamparter wrote:
>>
>> Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
>> and a AR900x PHY/Radio. Therefore the phy code and registers
>> are very similar to those #definitions you can find in ath9k.
>> And for the MAC code& registers you can look into zd1211rw,
>> or look into drivers/staging/otus (original vendor driver,
>> shares some code with their windows drivers)
>>
>> AFAICT, there are no technical documents about the AR9170
>> solution available w/o signing a NDA with Atheros
>> (probably because the devices are still produced and sold in high
>> quantities?).
>>
>
> Thanks;
> I did just discover a reasonably good 150p spec. in what I received
> from my client. If I can I will share it. I am under an NDA, but the client also told
> me that they received no cooperation from atheros.
You should be more specific. Atheros did GPL their ar9170 driver after
all, so it is in fact the first hardware vendor to ever have GPL'd
firmware for *any* device driver upstream. Releasing more docs takes
time, you are better off working directly with the upstream Atheros
developers than just subjectively claiming lack of cooperation.
Luis
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Stefan Lippers-Hollmann @ 2010-05-03 22:08 UTC (permalink / raw)
To: Pavel Roskin
Cc: Gertjan van Wingerde, John W. Linville, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <1272920358.4907.3.camel@mj>
Hi
On Monday 03 May 2010, Pavel Roskin wrote:
> On Mon, 2010-05-03 at 22:43 +0200, Gertjan van Wingerde wrote:
> > Now that RT30xx support is at the same level as RT28xx support we can enable
> > these devices by default.
[...]
> > --- a/drivers/net/wireless/rt2x00/Kconfig
> > +++ b/drivers/net/wireless/rt2x00/Kconfig
> > @@ -87,7 +87,7 @@ if RT2800PCI
> >
> > config RT2800PCI_RT30XX
> > bool "rt2800pci - Include support for rt30xx (PCI/PCIe/PCMCIA) devices"
> > - default n
> > + default y
>
> I believe defaulting booleans to "y" is discouraged, especially for
> drivers. Most users don't have any particular hardware device.
[disclaimer, I have no access to any rt30xx USB/ PCI devices, so I'm not
proposing the attached patch, as I can't evaluate the stability of
rt2800pci's rt30xx support myself but merely use it for demonstration
purposes]
RT2800PCI_RT30XX is not a new/ separate module, its only function is to
limit the PCI ID space (to not claim PCI IDs for chipset generations not
yet debugged properly) of rt2800pci.ko; this symbol isn't even used
anywhere else than within the PCI table. A 100% equivalent patch would be
to just drop the config option completely. I doubt that doing that would
meet resistance, as it merely adds previously 'unknown' (to be supported)
PCI IDs.
[However if RT2800PCI_RT30XX is going to be kept, but changed to default
to 'y', I'd propose to drop the 'Support for these devices is
non-functional at the moment and is intended for testers and developers"
paragraph at the same time.]
Regards
Stefan Lippers-Hollmann
rt2x00: claim RT30xx PCI IDs in rt2800pci
Now that RT30xx support is at the same level as RT28xx, it can be enabled
unconditionally.
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index 5239e08..ee088ac 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -85,17 +85,6 @@ config RT2800PCI
if RT2800PCI
-config RT2800PCI_RT30XX
- bool "rt2800pci - Include support for rt30xx (PCI/PCIe/PCMCIA) devices"
- default n
- ---help---
- This adds support for rt30xx wireless chipset family to the
- rt2800pci driver.
- Supported chips: RT3090, RT3091 & RT3092
-
- Support for these devices is non-functional at the moment and is
- intended for testers and developers.
-
config RT2800PCI_RT35XX
bool "rt2800pci - Include support for rt35xx (PCI/PCIe/PCMCIA) devices"
default n
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 0e52f17..9efd4fb 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -1225,12 +1225,10 @@ static DEFINE_PCI_DEVICE_TABLE(rt2800pci_device_table) = {
{ PCI_DEVICE(0x1432, 0x7758), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1432, 0x7768), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1a3b, 0x1059), PCI_DEVICE_DATA(&rt2800pci_ops) },
-#ifdef CONFIG_RT2800PCI_RT30XX
{ PCI_DEVICE(0x1814, 0x3090), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3091), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3092), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1462, 0x891a), PCI_DEVICE_DATA(&rt2800pci_ops) },
-#endif
#ifdef CONFIG_RT2800PCI_RT35XX
{ PCI_DEVICE(0x1814, 0x3060), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3062), PCI_DEVICE_DATA(&rt2800pci_ops) },
^ permalink raw reply related
* Re: [RFC] mac80211: radiotap vendor data
From: Luis R. Rodriguez @ 2010-05-03 22:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Joshua Zhao, Matt Smith
In-Reply-To: <1272734031.8461.0.camel@jlt3.sipsolutions.net>
On Sat, May 1, 2010 at 10:13 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> This allows drivers to add radiotap vendor data
> to any received frame, which will be simply
> passed into userspace and ignored by the kernel.
> Can be used by drivers to convey hw-specific
> information.
Thanks a lot for all your work on this area, on the standardization
part, mac80211 and even for providing a simple example, its really
appreciated! Some comments below.
> Note: 11n shouldn't be done there, in case somebody
> got ideas!!
Well you mean 802.11n standard stuff, I take it, because there are
vendor 802.11n specific stuff.
> Note: didn't test this after the paged RX changes
> ---
> drivers/net/wireless/mac80211_hwsim.c | 17 ++++++++++
> include/net/mac80211.h | 12 +++++++
> net/mac80211/rx.c | 53 ++++++++++++++++++++++++++++++----
> 3 files changed, 77 insertions(+), 5 deletions(-)
>
> --- wireless-testing.orig/include/net/mac80211.h 2010-05-01 08:46:26.000000000 +0200
> +++ wireless-testing/include/net/mac80211.h 2010-05-01 08:47:54.000000000 +0200
> @@ -565,6 +565,13 @@ enum mac80211_rx_flags {
> * @rate_idx: index of data rate into band's supported rates or MCS index if
> * HT rates are use (RX_FLAG_HT)
> * @flag: %RX_FLAG_*
> + * @vendor_radiotap_bitmap: radiotap vendor namespace presence bitmap
> + * @vendor_radiotap_len: radiotap vendor namespace length
> + * @vendor_radiotap_align: radiotap vendor namespace alignment. Note
> + * that the actual data must be at the start of the SKB data
> + * already.
I see your WARN_ON() on the alignment being set to 0 and set it to 1
then. Can you clarify a little more on this here. If there is no
strict alignment requirements why not just treat 0 as 1 then?
> + * @vendor_radiotap_oui: radiotap vendor namespace OUI
> + * @vendor_radiotap_subns: radiotap vendor sub namespace
> */
> struct ieee80211_rx_status {
> u64 mactime;
> @@ -575,6 +582,11 @@ struct ieee80211_rx_status {
> int antenna;
> int rate_idx;
> int flag;
> + u32 vendor_radiotap_bitmap;
> + u16 vendor_radiotap_len;
> + u8 vendor_radiotap_align;
> + u8 vendor_radiotap_oui[3];
> + u8 vendor_radiotap_subns;
> };
>
> /**
> --- wireless-testing.orig/net/mac80211/rx.c 2010-05-01 08:46:26.000000000 +0200
> +++ wireless-testing/net/mac80211/rx.c 2010-05-01 08:47:54.000000000 +0200
> @@ -37,6 +37,8 @@
> static struct sk_buff *remove_monitor_info(struct ieee80211_local *local,
> struct sk_buff *skb)
> {
> + struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
> +
> if (local->hw.flags & IEEE80211_HW_RX_INCLUDES_FCS) {
> if (likely(skb->len > FCS_LEN))
> __pskb_trim(skb, skb->len - FCS_LEN);
> @@ -48,6 +50,9 @@ static struct sk_buff *remove_monitor_in
> }
> }
>
> + if (status->vendor_radiotap_len)
> + __pskb_pull(skb, status->vendor_radiotap_len);
> +
> return skb;
> }
>
> @@ -69,8 +74,8 @@ static inline int should_drop_frame(stru
> }
>
> static int
> -ieee80211_rx_radiotap_len(struct ieee80211_local *local,
> - struct ieee80211_rx_status *status)
> +ieee80211_rx_radiotap_space(struct ieee80211_local *local,
> + struct ieee80211_rx_status *status)
> {
> int len;
>
> @@ -87,6 +92,21 @@ ieee80211_rx_radiotap_len(struct ieee802
> if (len & 1) /* padding for RX_FLAGS if necessary */
> len++;
>
> + if (status->vendor_radiotap_len) {
> + /* allocate extra bitmap */
> + len += 4;
> +
> + if (WARN_ON(status->vendor_radiotap_align == 0))
> + status->vendor_radiotap_align = 1;
> + /* align standard part of vendor namespace */
> + len = ALIGN(len, 2);
> + /* allocate standard part of vendor namespace */
> + len += 6;
> + /* align vendor-defined part */
> + len = ALIGN(len, status->vendor_radiotap_align);
> + /* vendor-defined part is already in skb */
> + }
> +
> return len;
> }
>
> @@ -115,10 +135,18 @@ ieee80211_add_rx_radiotap_header(struct
> (1 << IEEE80211_RADIOTAP_CHANNEL) |
> (1 << IEEE80211_RADIOTAP_ANTENNA) |
> (1 << IEEE80211_RADIOTAP_RX_FLAGS));
> - rthdr->it_len = cpu_to_le16(rtap_len);
> + rthdr->it_len = cpu_to_le16(rtap_len + status->vendor_radiotap_len);
>
> pos = (unsigned char *)(rthdr+1);
>
> + if (status->vendor_radiotap_len) {
> + rthdr->it_present |=
> + cpu_to_le32(BIT(IEEE80211_RADIOTAP_VENDOR_NAMESPACE)) |
> + cpu_to_le32(BIT(IEEE80211_RADIOTAP_EXT));
> + put_unaligned_le32(status->vendor_radiotap_bitmap, pos);
> + pos += 4;
> + }
> +
> /* the order of the following fields is important */
>
> /* IEEE80211_RADIOTAP_TSFT */
> @@ -190,11 +218,26 @@ ieee80211_add_rx_radiotap_header(struct
> /* IEEE80211_RADIOTAP_RX_FLAGS */
> /* ensure 2 byte alignment for the 2 byte field as required */
> if ((pos - (u8 *)rthdr) & 1)
> - pos++;
> + *pos++ = 0;
Why is this needed though? We already memset(rthdr, 0, rtap_len); above.
> if (status->flag & RX_FLAG_FAILED_PLCP_CRC)
> rx_flags |= IEEE80211_RADIOTAP_F_RX_BADPLCP;
> put_unaligned_le16(rx_flags, pos);
> pos += 2;
> +
> + if (status->vendor_radiotap_len) {
> + /* ensure 2 byte alignment for the vendor field as required */
> + if ((pos - (u8 *)rthdr) & 1)
> + *pos++ = 0;
> + *pos++ = status->vendor_radiotap_oui[0];
> + *pos++ = status->vendor_radiotap_oui[1];
> + *pos++ = status->vendor_radiotap_oui[2];
> + *pos++ = status->vendor_radiotap_subns;
> + put_unaligned_le16(status->vendor_radiotap_len, pos);
> + pos += 2;
> + /* align the actual payload as requested */
> + while ((pos - (u8 *)rthdr) & (status->vendor_radiotap_align - 1))
> + *pos++ = 0;
> + }
> }
>
> /*
> @@ -223,7 +266,7 @@ ieee80211_rx_monitor(struct ieee80211_lo
> */
>
> /* room for the radiotap header based on driver features */
> - needed_headroom = ieee80211_rx_radiotap_len(local, status);
> + needed_headroom = ieee80211_rx_radiotap_space(local, status);
>
> if (local->hw.flags & IEEE80211_HW_RX_INCLUDES_FCS)
> present_fcs_len = FCS_LEN;
> --- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 08:46:27.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-05-01 19:04:57.000000000 +0200
> @@ -484,6 +484,7 @@ static bool mac80211_hwsim_tx_frame(stru
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> struct ieee80211_rx_status rx_status;
> + u8 *vendor_data;
>
> if (data->idle) {
> printk(KERN_DEBUG "%s: Trying to TX when idle - reject\n",
> @@ -509,6 +510,20 @@ static bool mac80211_hwsim_tx_frame(stru
> secpath_reset(skb);
> nf_reset(skb);
>
> + vendor_data = skb_push(skb, 4);
> + rx_status.vendor_radiotap_len = 4;
> + rx_status.vendor_radiotap_align = 4;
> + rx_status.vendor_radiotap_oui[0] = 0xff;
> + rx_status.vendor_radiotap_oui[1] = 0xff;
> + rx_status.vendor_radiotap_oui[2] = 0xff;
> + rx_status.vendor_radiotap_subns = 129;
> + rx_status.vendor_radiotap_bitmap = 0x1;
> +
> + *vendor_data++ = 1;
> + *vendor_data++ = 2;
> + *vendor_data++ = 3;
> + *vendor_data++ = 4;
> +
Heh nice, now we just need a sample radiotap vendor extension parser example.
Thanks!!!
Luis
^ 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