* Re: CARL9170
From: Christian Lamparter @ 2010-06-14 22:32 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linux-wireless
In-Reply-To: <4C169610.5020907@dlasys.net>
On Monday 14 June 2010 22:50:24 David H. Lynch Jr. wrote:
> Many routines are coded to look like interrupt handlers, but the
> code seems to be entirely polled ?
Hardware design decision.
(See "AR9170 STA Programming Guide" - Paragraph 3-3.)
> Am I correct there ? If so do you know if the AR9170-fw code or
> something else might show an example of interrupt handling for the
> AR9170. I must have tx complete interrupts.
Well you have to "poll" the MAC's WLAN Status Registers (0x1c3510?) for
BIT(0)=TX COMP (and BIT(2) = TX FAIL) changes...
Or, if you are only sending one frame at a time, you might be able to poll
0x1c36d4 instead. Also you could decrease the maximum pending tx "interrupt"
timeout in 0x1c3d7c etc...
But if that does not satisfy your need for "real-time responsiveness", you
should contact Stephen Chen @ Atheros directly, maybe he knows a undocumented
feature register which enables real-time interrupt processing.
> Next there are remarks throught the driver and firmware regarding
> cookies.
> I think a cookie is a u8 that uniquely identifies a packet - is
> that correct ?
>
> In the firmware there is a remark somewhere that suguests that the
> cookie AND something else are needed - is that correct or is the cookie
> sufficient ?
This is because of historic reasons. In ar9170usb the driver had
use dirty tricks to get the AC_ID into the firmware's tx report.
So it could do some primitive frame lookup.
carl9170 driver still needs the AC_ID (but now) to reduce the frame lookup cost.
This is somewhat necessary because tx feedback is usually processed in a
critical section and when aggregation is enabled, it can be up to 16 frames
at any time...
regards,
Chr
^ permalink raw reply
* radiotap rate no longer supported in mac80211?
From: Steve deRosier @ 2010-06-14 22:18 UTC (permalink / raw)
To: linux-wireless
I'm trying to support per-packet setting of rate on a packet injection
via the radiotap header. In an earlier version of mac80211 (around
2.6.26), there was code in __ieee80211_parse_tx_radiotap (in
net/mac80211/tx.c) to support the use of the the rate element from the
radiotap header. In current versions of wireless-testing, most of the
code here has been removed and only the flags are parsed.
I want to return the IEEE80211_RADIOTAP_RATE portion of this function
in order to support this. So the questions:
1. Why were all fields other than IEEE80211_RADIOTAP_FLAGS removed?
2. Would it be OK for me to prepare and submit a patch to restore the
rate functionality?
Thanks,
- Steve
^ permalink raw reply
* Re: wireless button problem with atheros on hp machines
From: Leonardo @ 2010-06-14 21:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTimxtFMpJftSdwDK_DRap4Bw0iVPS9Tcwe_vE_f9@mail.gmail.com>
2010/6/13 Luis R. Rodriguez <mcgrof@gmail.com>:
> On Sun, Jun 13, 2010 at 1:49 PM, Leonardo <sombriks@gmail.com> wrote:
>> hello all, i don't know if this is the correct channel to report, but
>> from Slackware 13.0 (2.6.29.6) to 13.1 (2.6.33.4) the wireless button
>> stopped to work properly.
>
> Try 2.6.30, 2.6.31, and 2.6.32 and see if you see the issue on one of
> those. If so then you can use git bisect to find the culprit. I
> realize this can be quite cumbersome, but without more information I'm
> afraid this is as good as it gets. Instead of using Linus' tree you'll
> want to use the linux-2.6-allstable.git tree since that will have the
> extra version kernel revisions.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
>
> Luis
>
Hello currently i'm trying those other kernel versions. I'm grabbing
it from http://www.kernel.org/
for now i have about 3 kernels running ok or almost ok:
2.6.33.4
2.6.29.6
2.6.31.13
29 and 33 are default packages from slackware, and as i related before
by using 2.6.29.6 i get the perfect functionality of wireless
button/led (those hp machines have the led, and if i touch the led it
changes de color.. nvm)
today i got the 31.13 running; i have to say, maybe i have missed
something, because i lost sound and the 3d stuff. also ath5k.ko wasn't
created... but the bluetooth worked as expected, just as 2.6.29.6; i
am almost sure that i missed the kernel configuration, but fortunately
i've made a package (make targz-pkg) so i can fix it.
next i'll try the 2.6.32.15 and then 2.6.34, and with some hope find
when the problem began and report there.
thanks a lot for the guidance,
^ permalink raw reply
* CARL9170
From: David H. Lynch Jr. @ 2010-06-14 20:50 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
I am trying to digest some things in the carl9170 firmware.
Many routines are coded to look like interrupt handlers, but the
code seems to be entirely polled ?
Am I correct there ? If so do you know if the AR9170-fw code or
something else might show an example of interrupt handling for the
AR9170. I must have tx complete interrupts.
Next there are remarks throught the driver and firmware regarding
cookies.
I think a cookie is a u8 that uniquely identifies a packet - is
that correct ?
In the firmware there is a remark somewhere that suguests that the
cookie AND something else are needed - is that correct or is the cookie
sufficient ?
Thank you.
^ permalink raw reply
* Re: [PATCH] iwlwifi: cancel scan watchdog in iwl_bg_abort_scan
From: reinette chatre @ 2010-06-14 20:26 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, Mihai Harpau, stable@kernel.org
In-Reply-To: <1276540554-5336-1-git-send-email-linville@tuxdriver.com>
On Mon, 2010-06-14 at 11:35 -0700, John W. Linville wrote:
> Avoids this:
>
> WARNING: at net/mac80211/scan.c:312 ieee80211_scan_completed+0x5f/0x1f1
> [mac80211]()
> Hardware name: Latitude E5400
> Modules linked in: aes_x86_64 aes_generic fuse ipt_MASQUERADE iptable_nat
> nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand
> acpi_cpufreq freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6
> ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb
> snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec
> snd_hwdep snd_seq snd_seq_device iwlcore snd_pcm dell_wmi sdhci_pci sdhci
> iTCO_wdt tg3 dell_laptop mmc_core i2c_i801 wmi mac80211 snd_timer
> iTCO_vendor_support btusb joydev dcdbas cfg80211 bluetooth snd soundcore
> microcode rfkill snd_page_alloc firewire_ohci firewire_core crc_itu_t
> yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video
> output [last unloaded: scsi_wait_scan]
> Pid: 979, comm: iwlagn Tainted: G W 2.6.33.3-85.fc13.x86_64 #1
> Call Trace:
> [<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f
> [<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11
> [<ffffffffa01bb7d9>] ieee80211_scan_completed+0x5f/0x1f1 [mac80211]
> [<ffffffffa02a23f0>] iwl_bg_scan_completed+0xbb/0x17a [iwlcore]
> [<ffffffff81060d3d>] worker_thread+0x1a4/0x232
> [<ffffffffa02a2335>] ? iwl_bg_scan_completed+0x0/0x17a [iwlcore]
> [<ffffffff81064817>] ? autoremove_wake_function+0x0/0x34
> [<ffffffff81060b99>] ? worker_thread+0x0/0x232
> [<ffffffff810643c7>] kthread+0x7a/0x82
> [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
> [<ffffffff8106434d>] ? kthread+0x0/0x82
> [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10
>
> Reported here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=590436
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> Reported-by: Mihai Harpau <mishu@piatafinanciara.ro>
> Cc: stable@kernel.org
> ---
Great catch. Thank you very much
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* [PATCH 11/14] rt2x00: Update author rt2800lib
From: Ivo van Doorn @ 2010-06-14 20:13 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142212.55156.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
rt2800lib has been under development of the rt2x00 project,
so add it to the author string for the module information.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 6d4df3e..a83477a 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1,9 +1,9 @@
/*
+ Copyright (C) 2010 Ivo van Doorn <IvDoorn@gmail.com>
Copyright (C) 2009 Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Copyright (C) 2009 Gertjan van Wingerde <gwingerde@gmail.com>
Based on the original rt2800pci.c and rt2800usb.c.
- Copyright (C) 2009 Ivo van Doorn <IvDoorn@gmail.com>
Copyright (C) 2009 Alban Browaeys <prahal@yahoo.com>
Copyright (C) 2009 Felix Fietkau <nbd@openwrt.org>
Copyright (C) 2009 Luis Correia <luis.f.correia@gmail.com>
@@ -41,10 +41,6 @@
#include "rt2800lib.h"
#include "rt2800.h"
-MODULE_AUTHOR("Bartlomiej Zolnierkiewicz");
-MODULE_DESCRIPTION("rt2800 library");
-MODULE_LICENSE("GPL");
-
/*
* Register access.
* All access to the CSR registers will go through the methods
@@ -2761,3 +2757,9 @@ const struct ieee80211_ops rt2800_mac80211_ops = {
.rfkill_poll = rt2x00mac_rfkill_poll,
};
EXPORT_SYMBOL_GPL(rt2800_mac80211_ops);
+
+MODULE_AUTHOR(DRV_PROJECT ", Bartlomiej Zolnierkiewicz");
+MODULE_VERSION(DRV_VERSION);
+MODULE_DESCRIPTION("Ralink RT2800 library");
+MODULE_LICENSE("GPL");
+
--
1.6.6.1
^ permalink raw reply related
* [PATCH 13/14] rt2x00: Enable HW crypto by default
From: Ivo van Doorn @ 2010-06-14 20:13 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142213.38654.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
Hardware cryptography seems to be working
on a 11G network with WPA/WPA2 cryptography
enabled. WEP still needs to be tested...
Signed-of-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index afa30ea..165da7b 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -51,7 +51,7 @@
/*
* Allow hardware encryption to be disabled.
*/
-static int modparam_nohwcrypt = 1;
+static int modparam_nohwcrypt = 0;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index c437960..f18c12a 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -45,7 +45,7 @@
/*
* Allow hardware encryption to be disabled.
*/
-static int modparam_nohwcrypt = 1;
+static int modparam_nohwcrypt = 0;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
--
1.6.6.1
^ permalink raw reply related
* [PATCH 14/14] rt2x00: Synchronize WCID initialization with legacy driver
From: Ivo van Doorn @ 2010-06-14 20:14 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142213.57748.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
Legacy rt2870 driver handles WCID differently then we expected,
the BSSID and Cipher value are 3 bit values, while the 4th bit
should be set elsewhere in an extended field.
After this, rt2800usb reports frames have been decrypted
successfully, indicating that the Hardware decryption now is
working correctly.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800.h | 4 ++++
drivers/net/wireless/rt2x00/rt2800lib.c | 31 ++++++++++++++++++++++---------
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index b308421..3ed87ba 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -1436,6 +1436,10 @@ struct mac_iveiv_entry {
#define MAC_WCID_ATTRIBUTE_CIPHER FIELD32(0x0000000e)
#define MAC_WCID_ATTRIBUTE_BSS_IDX FIELD32(0x00000070)
#define MAC_WCID_ATTRIBUTE_RX_WIUDF FIELD32(0x00000380)
+#define MAC_WCID_ATTRIBUTE_CIPHER_EXT FIELD32(0x00000400)
+#define MAC_WCID_ATTRIBUTE_BSS_IDX_EXT FIELD32(0x00000800)
+#define MAC_WCID_ATTRIBUTE_WAPI_MCBC FIELD32(0x00008000)
+#define MAC_WCID_ATTRIBUTE_WAPI_KEY_IDX FIELD32(0xff000000)
/*
* SHARED_KEY_MODE:
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index a83477a..636bfd6 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -554,15 +554,28 @@ static void rt2800_config_wcid_attr(struct rt2x00_dev *rt2x00dev,
offset = MAC_WCID_ATTR_ENTRY(key->hw_key_idx);
- rt2800_register_read(rt2x00dev, offset, ®);
- rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_KEYTAB,
- !!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE));
- rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_CIPHER,
- (crypto->cmd == SET_KEY) * crypto->cipher);
- rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_BSS_IDX,
- (crypto->cmd == SET_KEY) * crypto->bssidx);
- rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_RX_WIUDF, crypto->cipher);
- rt2800_register_write(rt2x00dev, offset, reg);
+ if (crypto->cmd == SET_KEY) {
+ rt2800_register_read(rt2x00dev, offset, ®);
+ rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_KEYTAB,
+ !!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE));
+ /*
+ * Both the cipher as the BSS Idx numbers are split in a main
+ * value of 3 bits, and a extended field for adding one additional
+ * bit to the value.
+ */
+ rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_CIPHER,
+ (crypto->cipher & 0x7));
+ rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_CIPHER_EXT,
+ (crypto->cipher & 0x8) >> 3);
+ rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_BSS_IDX,
+ (crypto->bssidx & 0x7));
+ rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_BSS_IDX_EXT,
+ (crypto->bssidx & 0x8) >> 3);
+ rt2x00_set_field32(®, MAC_WCID_ATTRIBUTE_RX_WIUDF, crypto->cipher);
+ rt2800_register_write(rt2x00dev, offset, reg);
+ } else {
+ rt2800_register_write(rt2x00dev, offset, 0);
+ }
offset = MAC_IVEIV_ENTRY(key->hw_key_idx);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 12/14] rt2x00: Limit TX done looping to number of TX ring entries
From: Ivo van Doorn @ 2010-06-14 20:13 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142213.16315.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
Similar to rt2800pci, remove the check for duplicate
register reading, and instead limit the for-loop to
the maximum number of TX entries inside a queue.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt61pci.c | 23 +++++++++--------------
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index d127011..f7ee31e 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2052,29 +2052,24 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
struct txdone_entry_desc txdesc;
u32 word;
u32 reg;
- u32 old_reg;
int type;
int index;
+ int i;
/*
- * During each loop we will compare the freshly read
- * STA_CSR4 register value with the value read from
- * the previous loop. If the 2 values are equal then
- * we should stop processing because the chance is
- * quite big that the device has been unplugged and
- * we risk going into an endless loop.
+ * TX_STA_FIFO is a stack of X entries, hence read TX_STA_FIFO
+ * at most X times and also stop processing once the TX_STA_FIFO_VALID
+ * flag is not set anymore.
+ *
+ * The legacy drivers use X=TX_RING_SIZE but state in a comment
+ * that the TX_STA_FIFO stack has a size of 16. We stick to our
+ * tx ring size for now.
*/
- old_reg = 0;
-
- while (1) {
+ for (i = 0; i < TX_ENTRIES; i++) {
rt2x00pci_register_read(rt2x00dev, STA_CSR4, ®);
if (!rt2x00_get_field32(reg, STA_CSR4_VALID))
break;
- if (old_reg == reg)
- break;
- old_reg = reg;
-
/*
* Skip this entry when it contains an invalid
* queue identication number.
--
1.6.6.1
^ permalink raw reply related
* [PATCH 10/14] rt2x00: Enable fallback rates for rt61pci and rt73usb
From: Ivo van Doorn @ 2010-06-14 20:12 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142212.27713.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
Explicitly enable the usage of fallback rates for
the transmission of frames with rt61pci and rt73usb hardware.
Note that for txdone reporting, only rt61pci is capable of
reporting the fallback rates, for USB it is not possible
to determine the number of retries. However the device will
use the fallback rates, so it might still help in the performance.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt61pci.c | 22 ++++++++++++++++++++++
drivers/net/wireless/rt2x00/rt73usb.c | 3 +++
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 243df08..d127011 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -931,6 +931,9 @@ static void rt61pci_config_retry_limit(struct rt2x00_dev *rt2x00dev,
u32 reg;
rt2x00pci_register_read(rt2x00dev, TXRX_CSR4, ®);
+ rt2x00_set_field32(®, TXRX_CSR4_OFDM_TX_RATE_DOWN, 1);
+ rt2x00_set_field32(®, TXRX_CSR4_OFDM_TX_RATE_STEP, 0);
+ rt2x00_set_field32(®, TXRX_CSR4_OFDM_TX_FALLBACK_CCK, 0);
rt2x00_set_field32(®, TXRX_CSR4_LONG_RETRY_LIMIT,
libconf->conf->long_frame_max_tx_count);
rt2x00_set_field32(®, TXRX_CSR4_SHORT_RETRY_LIMIT,
@@ -2130,6 +2133,13 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
}
txdesc.retry = rt2x00_get_field32(reg, STA_CSR4_RETRY_COUNT);
+ /*
+ * the frame was retried at least once
+ * -> hw used fallback rates
+ */
+ if (txdesc.retry)
+ __set_bit(TXDONE_FALLBACK, &txdesc.flags);
+
rt2x00pci_txdone(entry, &txdesc);
}
}
@@ -2587,6 +2597,18 @@ static int rt61pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
EEPROM_MAC_ADDR_0));
/*
+ * As rt61 has a global fallback table we cannot specify
+ * more then one tx rate per frame but since the hw will
+ * try several rates (based on the fallback table) we should
+ * still initialize max_rates to the maximum number of rates
+ * we are going to try. Otherwise mac80211 will truncate our
+ * reported tx rates and the rc algortihm will end up with
+ * incorrect data.
+ */
+ rt2x00dev->hw->max_rates = 7;
+ rt2x00dev->hw->max_rate_tries = 1;
+
+ /*
* Initialize hw_mode information.
*/
spec->supported_bands = SUPPORT_BAND_2GHZ;
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 113ad69..d06d90f 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -816,6 +816,9 @@ static void rt73usb_config_retry_limit(struct rt2x00_dev *rt2x00dev,
u32 reg;
rt2x00usb_register_read(rt2x00dev, TXRX_CSR4, ®);
+ rt2x00_set_field32(®, TXRX_CSR4_OFDM_TX_RATE_DOWN, 1);
+ rt2x00_set_field32(®, TXRX_CSR4_OFDM_TX_RATE_STEP, 0);
+ rt2x00_set_field32(®, TXRX_CSR4_OFDM_TX_FALLBACK_CCK, 0);
rt2x00_set_field32(®, TXRX_CSR4_LONG_RETRY_LIMIT,
libconf->conf->long_frame_max_tx_count);
rt2x00_set_field32(®, TXRX_CSR4_SHORT_RETRY_LIMIT,
--
1.6.6.1
^ permalink raw reply related
* [PATCH 09/14] rt2x00: Fix tx status reporting when falling back to the lowest rate
From: Ivo van Doorn @ 2010-06-14 20:12 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142212.02575.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
In some corner cases the reported tx rates/retries didn't match the really
used ones.
The hardware lowers the tx rate on each consecutive retry by 1 (but won't
fall back from MCS to legacy rates) _until_ it reaches the lowest one.
In case the frame wasn't sent succesful the number of retries is 7 and if
a rate index <7 was used the previous code reported negative rate indexes
which were then ignored by the rate control algorithm and mac80211.
Instead, report the remaining number of retries to have happened with
the lowest rate (index 0). This should give the rate control algorithm
slightly more accurate information about the used tx rates/retries.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00dev.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index e7a208d..918451a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -258,11 +258,22 @@ void rt2x00lib_txdone(struct queue_entry *entry,
/*
* Frame was send with retries, hardware tried
* different rates to send out the frame, at each
- * retry it lowered the rate 1 step.
+ * retry it lowered the rate 1 step except when the
+ * lowest rate was used.
*/
for (i = 0; i < retry_rates && i < IEEE80211_TX_MAX_RATES; i++) {
tx_info->status.rates[i].idx = rate_idx - i;
tx_info->status.rates[i].flags = rate_flags;
+
+ if (rate_idx - i == 0) {
+ /*
+ * The lowest rate (index 0) was used until the
+ * number of max retries was reached.
+ */
+ tx_info->status.rates[i].count = retry_rates - i;
+ i++;
+ break;
+ }
tx_info->status.rates[i].count = 1;
}
if (i < (IEEE80211_TX_MAX_RATES - 1))
--
1.6.6.1
^ permalink raw reply related
* [PATCH 08/14] rt2x00: provide mac80211 a suitable max_rates value
From: Ivo van Doorn @ 2010-06-14 20:12 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142211.33421.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
Set up max_rates and max_rate_tries with suitable values even if we do not
support the whole functionality.
As rt2800 has a global fallback table we cannot specify more then one tx rate
per frame but since the hw will try several different rates (based on the
fallback table) we should still initialize max_rates to the maximum number of
rates we are going to try. Otherwise mac80211 will truncate our reported tx
rates and the rc algortihm will end up with incorrect data choosing unsuitable
rates for tx.
This improves throughput on rt2800 devices considerable.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index f158322..6d4df3e 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2497,6 +2497,18 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
rt2x00_eeprom_addr(rt2x00dev,
EEPROM_MAC_ADDR_0));
+ /*
+ * As rt2800 has a global fallback table we cannot specify
+ * more then one tx rate per frame but since the hw will
+ * try several rates (based on the fallback table) we should
+ * still initialize max_rates to the maximum number of rates
+ * we are going to try. Otherwise mac80211 will truncate our
+ * reported tx rates and the rc algortihm will end up with
+ * incorrect data.
+ */
+ rt2x00dev->hw->max_rates = 7;
+ rt2x00dev->hw->max_rate_tries = 1;
+
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &eeprom);
/*
--
1.6.6.1
^ permalink raw reply related
* [PATCH 07/14] rt2x00: Fix typo in rt2800_config_txpower
From: Ivo van Doorn @ 2010-06-14 20:11 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142211.09880.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
Fix typo in rt2800_config_txpower.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index ae20e67..f158322 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1079,7 +1079,7 @@ static void rt2800_config_txpower(struct rt2x00_dev *rt2x00dev,
u8 r1;
rt2800_bbp_read(rt2x00dev, 1, &r1);
- rt2x00_set_field8(®, BBP1_TX_POWER, 0);
+ rt2x00_set_field8(&r1, BBP1_TX_POWER, 0);
rt2800_bbp_write(rt2x00dev, 1, r1);
rt2800_register_read(rt2x00dev, TX_PWR_CFG_0, ®);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 06/14] rt2x00: Fix TX_STA_FIFO handling
From: Ivo van Doorn @ 2010-06-14 20:11 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142210.43525.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
Currently rt2800pci will read TX_STA_FIFO until the previously read value
matches the current value. However, it is obvious that TX_STA_FIFO only
contains values that can easily be the same for multiple consecutive frames
(especially when communicating with only one other STA). Hence, we often
ended up with reading only the first entry and ignoring the rest.
One result was that when the TX_STA_FIFO contained multiple entires, only
the first one was read and properly handled while the others remained in the
tx queue.
Thus, drop this check but introduce a maximum number of reads. All legacy
drivers use the size of the tx ring as limit but state that the TX_STA_FIFO
has only 16 entries. So, let's just stick with the tx ring size for now.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800pci.c | 23 +++++++++--------------
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index eeecedb..afa30ea 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -813,29 +813,24 @@ static void rt2800pci_txdone(struct rt2x00_dev *rt2x00dev)
struct txdone_entry_desc txdesc;
u32 word;
u32 reg;
- u32 old_reg;
int wcid, ack, pid, tx_wcid, tx_ack, tx_pid;
u16 mcs, real_mcs;
+ int i;
/*
- * During each loop we will compare the freshly read
- * TX_STA_FIFO register value with the value read from
- * the previous loop. If the 2 values are equal then
- * we should stop processing because the chance it
- * quite big that the device has been unplugged and
- * we risk going into an endless loop.
+ * TX_STA_FIFO is a stack of X entries, hence read TX_STA_FIFO
+ * at most X times and also stop processing once the TX_STA_FIFO_VALID
+ * flag is not set anymore.
+ *
+ * The legacy drivers use X=TX_RING_SIZE but state in a comment
+ * that the TX_STA_FIFO stack has a size of 16. We stick to our
+ * tx ring size for now.
*/
- old_reg = 0;
-
- while (1) {
+ for (i = 0; i < TX_ENTRIES; i++) {
rt2800_register_read(rt2x00dev, TX_STA_FIFO, ®);
if (!rt2x00_get_field32(reg, TX_STA_FIFO_VALID))
break;
- if (old_reg == reg)
- break;
- old_reg = reg;
-
wcid = rt2x00_get_field32(reg, TX_STA_FIFO_WCID);
ack = rt2x00_get_field32(reg, TX_STA_FIFO_TX_ACK_REQUIRED);
pid = rt2x00_get_field32(reg, TX_STA_FIFO_PID_TYPE);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 05/14] rt2x00: Add comment about BBP1_TX_POWER
From: Ivo van Doorn @ 2010-06-14 20:10 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142210.10378.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
Add a comment about the meaning of BBP1_TX_POWER stating all possible values.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index 16bfaa8..b308421 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -1557,7 +1557,9 @@ struct mac_iveiv_entry {
*/
/*
- * BBP 1: TX Antenna
+ * BBP 1: TX Antenna & Power
+ * POWER: 0 - normal, 1 - drop tx power by 6dBm, 2 - drop tx power by 12dBm,
+ * 3 - increase tx power by 6dBm
*/
#define BBP1_TX_POWER FIELD8(0x07)
#define BBP1_TX_ANTENNA FIELD8(0x18)
--
1.6.6.1
^ permalink raw reply related
* [PATCH 04/14] rt2x00: Fix IEEE80211_TX_CTL_MORE_FRAMES handling
From: Ivo van Doorn @ 2010-06-14 20:10 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142209.42709.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
IEEE80211_TX_CTL_MORE_FRAMES indicates that more frames are queued for tx
but has nothing to do with fragmentation. Hence, don't set ENTRY_TXD_MORE_FRAG
but only ENTRY_TXD_BURST to not kick the tx queues immediately.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00queue.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 35858b1..f916371 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -353,13 +353,18 @@ static void rt2x00queue_create_tx_descriptor(struct queue_entry *entry,
/*
* Check if more fragments are pending
*/
- if (ieee80211_has_morefrags(hdr->frame_control) ||
- (tx_info->flags & IEEE80211_TX_CTL_MORE_FRAMES)) {
+ if (ieee80211_has_morefrags(hdr->frame_control)) {
__set_bit(ENTRY_TXD_BURST, &txdesc->flags);
__set_bit(ENTRY_TXD_MORE_FRAG, &txdesc->flags);
}
/*
+ * Check if more frames (!= fragments) are pending
+ */
+ if (tx_info->flags & IEEE80211_TX_CTL_MORE_FRAMES)
+ __set_bit(ENTRY_TXD_BURST, &txdesc->flags);
+
+ /*
* Beacons and probe responses require the tsf timestamp
* to be inserted into the frame, except for a frame that has been injected
* through a monitor interface. This latter is needed for testing a
--
1.6.6.1
^ permalink raw reply related
* [PATCH 03/14] rt2x00: only set TXDONE_FALLBACK in rt2800pci if the frame was retried
From: Ivo van Doorn @ 2010-06-14 20:09 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142209.09943.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
TXDONE_FALLBACK expresses that fallback rates were used for retries. Hence,
it only makes sense to set the flag if retries > 0.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800pci.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index b5a871e..eeecedb 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -903,8 +903,12 @@ static void rt2800pci_txdone(struct rt2x00_dev *rt2x00dev)
txdesc.retry = 7;
}
- __set_bit(TXDONE_FALLBACK, &txdesc.flags);
-
+ /*
+ * the frame was retried at least once
+ * -> hw used fallback rates
+ */
+ if (txdesc.retry)
+ __set_bit(TXDONE_FALLBACK, &txdesc.flags);
rt2x00pci_txdone(entry, &txdesc);
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH 02/14] rt2x00: don't use TXDONE_FALLBACK as success indicator
From: Ivo van Doorn @ 2010-06-14 20:09 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
In-Reply-To: <201006142208.31736.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
TXDONE_FALLBACK doesn't express if the frame was sent successful or not. It
only tells us that the hw used fallback rates for retries. Hence, don't use
TXDONE_FALLBACK as success indicator.
Before this patch we reported success to the rate control algorithm which
was wrong in a number of cases and might have lead to improper tx rate
selections.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00dev.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 0b8efe8..8faee4c 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -236,8 +236,7 @@ void rt2x00lib_txdone(struct queue_entry *entry,
*/
success =
test_bit(TXDONE_SUCCESS, &txdesc->flags) ||
- test_bit(TXDONE_UNKNOWN, &txdesc->flags) ||
- test_bit(TXDONE_FALLBACK, &txdesc->flags);
+ test_bit(TXDONE_UNKNOWN, &txdesc->flags);
/*
* Update TX statistics.
--
1.6.6.1
^ permalink raw reply related
* [PATCH 01/14] rt2x00: clarify meaning of txdone flags
From: Ivo van Doorn @ 2010-06-14 20:08 UTC (permalink / raw)
To: John W. Linville
Cc: Helmut Schaa, rt2x00 Users List, linux-wireless,
Gertjan van Wingerde
From: Helmut Schaa <helmut.schaa@googlemail.com>
Update the documentation of the available txdone flags to better express
how they should be used.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00queue.h | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
index f791708..55872c4 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.h
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
@@ -213,9 +213,16 @@ struct rxdone_entry_desc {
/**
* enum txdone_entry_desc_flags: Flags for &struct txdone_entry_desc
*
+ * Every txdone report has to contain the basic result of the
+ * transmission, either &TXDONE_UNKNOWN, &TXDONE_SUCCESS or
+ * &TXDONE_FAILURE. The flag &TXDONE_FALLBACK can be used in
+ * conjunction with all of these flags but should only be set
+ * if retires > 0. The flag &TXDONE_EXCESSIVE_RETRY can only be used
+ * in conjunction with &TXDONE_FAILURE.
+ *
* @TXDONE_UNKNOWN: Hardware could not determine success of transmission.
* @TXDONE_SUCCESS: Frame was successfully send
- * @TXDONE_FALLBACK: Frame was successfully send using a fallback rate.
+ * @TXDONE_FALLBACK: Hardware used fallback rates for retries
* @TXDONE_FAILURE: Frame was not successfully send
* @TXDONE_EXCESSIVE_RETRY: In addition to &TXDONE_FAILURE, the
* frame transmission failed due to excessive retries.
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] p54usb: Remove duplicate Medion MD40900 device id
From: Ben Collins @ 2010-06-14 19:16 UTC (permalink / raw)
To: John W. Linville
Cc: Larry Finger, Leann Ogasawara, flamingice, linux-wireless,
Ben Collins
In-Reply-To: <20100614185549.GB2216@tuxdriver.com>
On Mon, 2010-06-14 at 14:55 -0400, John W. Linville wrote:
> On Thu, Jun 10, 2010 at 06:23:19PM -0500, Larry Finger wrote:
> > On 06/10/2010 05:28 PM, Leann Ogasawara wrote:
> > > The Medion MD40900 device id [0x0cde, 0x0006] is defined twice. Remove
> > > the duplicate.
> > >
> > > Originally-by: Ben Collins <ben.collins@ubuntu.com>
> > > Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
> > > ---
> > > drivers/net/wireless/p54/p54usb.c | 1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
> > > index 7307325..d6d8713 100644
> > > --- a/drivers/net/wireless/p54/p54usb.c
> > > +++ b/drivers/net/wireless/p54/p54usb.c
> > > @@ -69,7 +69,6 @@ static struct usb_device_id p54u_table[] __devinitdata = {
> > > {USB_DEVICE(0x0915, 0x2002)}, /* Cohiba Proto board */
> > > {USB_DEVICE(0x0baf, 0x0118)}, /* U.S. Robotics U5 802.11g Adapter*/
> > > {USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
> > > - {USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
> > > {USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
> > > {USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
> > > {USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
> >
> > Do you know for certain that this device is a Version 1 chip, and for
> > that reason, you are removing it from the version 2 list?
> >
> > If not, NACK.
>
> So, I guess you are concerned about the groupings because of the
> different firmwares or something like that? Perhaps a comment that
> says "this could be a version 2 device" is just as handy? Since the
> driver prints the name of the firmware it wants, is there any real
> need for grouping the IDs?
>
> OTOH, is there any actual harm from the duplicate entry? It "seems"
> wrong to me too, but I guess it does no harm...?
>
> Leann and/or Ben, was this just tidying-up? I'm guessing there wasn't
> an actual bug involved?
It was flagged by a script I wrote to detect overlapping drivers. This
driver had dual entries for the same device, so the second was basically
giving depmod another entry to worry about. Trivial, yes, but just
seemed cleaner to not do that in general.
I think we had decided awhile back to just comment out this entry with a
note that says something like "already above, just listing for clarity"
or similar.
--
Bluecherry: http://www.bluecherrydvr.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu : http://www.ubuntu.com/
My Blog : http://ben-collins.blogspot.com/
^ permalink raw reply
* Re: [PATCH] p54usb: Remove duplicate Medion MD40900 device id
From: John W. Linville @ 2010-06-14 18:55 UTC (permalink / raw)
To: Larry Finger; +Cc: Leann Ogasawara, flamingice, linux-wireless, Ben Collins
In-Reply-To: <4C1173E7.6010201@lwfinger.net>
On Thu, Jun 10, 2010 at 06:23:19PM -0500, Larry Finger wrote:
> On 06/10/2010 05:28 PM, Leann Ogasawara wrote:
> > The Medion MD40900 device id [0x0cde, 0x0006] is defined twice. Remove
> > the duplicate.
> >
> > Originally-by: Ben Collins <ben.collins@ubuntu.com>
> > Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
> > ---
> > drivers/net/wireless/p54/p54usb.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
> > index 7307325..d6d8713 100644
> > --- a/drivers/net/wireless/p54/p54usb.c
> > +++ b/drivers/net/wireless/p54/p54usb.c
> > @@ -69,7 +69,6 @@ static struct usb_device_id p54u_table[] __devinitdata = {
> > {USB_DEVICE(0x0915, 0x2002)}, /* Cohiba Proto board */
> > {USB_DEVICE(0x0baf, 0x0118)}, /* U.S. Robotics U5 802.11g Adapter*/
> > {USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
> > - {USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
> > {USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
> > {USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
> > {USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
>
> Do you know for certain that this device is a Version 1 chip, and for
> that reason, you are removing it from the version 2 list?
>
> If not, NACK.
So, I guess you are concerned about the groupings because of the
different firmwares or something like that? Perhaps a comment that
says "this could be a version 2 device" is just as handy? Since the
driver prints the name of the firmware it wants, is there any real
need for grouping the IDs?
OTOH, is there any actual harm from the duplicate entry? It "seems"
wrong to me too, but I guess it does no harm...?
Leann and/or Ben, was this just tidying-up? I'm guessing there wasn't
an actual bug involved?
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] mac80211: Protect Deauthentication frame when using MFP
From: Jouni Malinen @ 2010-06-14 18:55 UTC (permalink / raw)
To: John W. Linville, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <20100611024456.GA3985@jm.kir.nu>
When management frame protection (IEEE 802.11w) is used,
Deauthentication frame needs to be protected when the pairwise key is
configured. mac80211 was removing the station entry (and its keys)
before actually sending out the Deauthentication frame. Fix this by
reordering the code to send the frame before the station entry gets
removed. This matches an earlier change that handled the Disassociation
frame processing, but missed Deauthentication frames.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
---
net/mac80211/mlme.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
v2: Fix a bug that left STA entries behind and broke some reassociation
cases.
--- wireless-testing.orig/net/mac80211/mlme.c 2010-06-14 11:40:07.000000000 -0700
+++ wireless-testing/net/mac80211/mlme.c 2010-06-14 11:41:03.000000000 -0700
@@ -2292,14 +2292,16 @@ int ieee80211_mgd_deauth(struct ieee8021
struct ieee80211_local *local = sdata->local;
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct ieee80211_work *wk;
- const u8 *bssid = req->bss->bssid;
+ u8 bssid[ETH_ALEN];
+ bool assoc_bss = false;
mutex_lock(&ifmgd->mtx);
+ memcpy(bssid, req->bss->bssid, ETH_ALEN);
if (ifmgd->associated == req->bss) {
- bssid = req->bss->bssid;
- ieee80211_set_disassoc(sdata, true);
+ ieee80211_set_disassoc(sdata, false);
mutex_unlock(&ifmgd->mtx);
+ assoc_bss = true;
} else {
bool not_auth_yet = false;
@@ -2345,6 +2347,8 @@ int ieee80211_mgd_deauth(struct ieee8021
ieee80211_send_deauth_disassoc(sdata, bssid, IEEE80211_STYPE_DEAUTH,
req->reason_code, cookie,
!req->local_state_change);
+ if (assoc_bss)
+ sta_info_destroy_addr(sdata, bssid);
ieee80211_recalc_idle(sdata->local);
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH] iwlwifi: cancel scan watchdog in iwl_bg_abort_scan
From: John W. Linville @ 2010-06-14 18:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Mihai Harpau, reinette.chatre, John W. Linville, stable
Avoids this:
WARNING: at net/mac80211/scan.c:312 ieee80211_scan_completed+0x5f/0x1f1
[mac80211]()
Hardware name: Latitude E5400
Modules linked in: aes_x86_64 aes_generic fuse ipt_MASQUERADE iptable_nat
nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand
acpi_cpufreq freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6
ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb
snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec
snd_hwdep snd_seq snd_seq_device iwlcore snd_pcm dell_wmi sdhci_pci sdhci
iTCO_wdt tg3 dell_laptop mmc_core i2c_i801 wmi mac80211 snd_timer
iTCO_vendor_support btusb joydev dcdbas cfg80211 bluetooth snd soundcore
microcode rfkill snd_page_alloc firewire_ohci firewire_core crc_itu_t
yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video
output [last unloaded: scsi_wait_scan]
Pid: 979, comm: iwlagn Tainted: G W 2.6.33.3-85.fc13.x86_64 #1
Call Trace:
[<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f
[<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11
[<ffffffffa01bb7d9>] ieee80211_scan_completed+0x5f/0x1f1 [mac80211]
[<ffffffffa02a23f0>] iwl_bg_scan_completed+0xbb/0x17a [iwlcore]
[<ffffffff81060d3d>] worker_thread+0x1a4/0x232
[<ffffffffa02a2335>] ? iwl_bg_scan_completed+0x0/0x17a [iwlcore]
[<ffffffff81064817>] ? autoremove_wake_function+0x0/0x34
[<ffffffff81060b99>] ? worker_thread+0x0/0x232
[<ffffffff810643c7>] kthread+0x7a/0x82
[<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
[<ffffffff8106434d>] ? kthread+0x0/0x82
[<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10
Reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=590436
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Mihai Harpau <mishu@piatafinanciara.ro>
Cc: stable@kernel.org
---
drivers/net/wireless/iwlwifi/iwl-scan.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index 5d3f51f..386c5f9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -491,6 +491,7 @@ void iwl_bg_abort_scan(struct work_struct *work)
mutex_lock(&priv->mutex);
+ cancel_delayed_work_sync(&priv->scan_check);
set_bit(STATUS_SCAN_ABORTING, &priv->status);
iwl_send_scan_abort(priv);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 5/6] iwlwifi: rename iwl4965_rx_mpdu_res_start
From: Reinette Chatre @ 2010-06-14 18:24 UTC (permalink / raw)
To: linville
Cc: linux-wireless, ipw3945-devel, Emmanuel Grumbach, Reinette Chatre
In-Reply-To: <1276539892-12471-1-git-send-email-reinette.chatre@intel.com>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwl4965_rx_mpdu_res_start is not 4695 specific, so rename it to more
general name iwl_rx_mpdu_res_start.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 4 ++--
drivers/net/wireless/iwlwifi/iwl-commands.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 90bd98c..0e7b066 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -904,7 +904,7 @@ void iwlagn_rx_reply_rx(struct iwl_priv *priv,
struct iwl_rx_packet *pkt = rxb_addr(rxb);
struct iwl_rx_phy_res *phy_res;
__le32 rx_pkt_status;
- struct iwl4965_rx_mpdu_res_start *amsdu;
+ struct iwl_rx_mpdu_res_start *amsdu;
u32 len;
u32 ampdu_status;
u32 rate_n_flags;
@@ -933,7 +933,7 @@ void iwlagn_rx_reply_rx(struct iwl_priv *priv,
return;
}
phy_res = &priv->_agn.last_phy_res;
- amsdu = (struct iwl4965_rx_mpdu_res_start *)pkt->u.raw;
+ amsdu = (struct iwl_rx_mpdu_res_start *)pkt->u.raw;
header = (struct ieee80211_hdr *)(pkt->u.raw + sizeof(*amsdu));
len = le16_to_cpu(amsdu->byte_count);
rx_pkt_status = *(__le32 *)(pkt->u.raw + sizeof(*amsdu) + len);
diff --git a/drivers/net/wireless/iwlwifi/iwl-commands.h b/drivers/net/wireless/iwlwifi/iwl-commands.h
index d5938e4..4984925 100644
--- a/drivers/net/wireless/iwlwifi/iwl-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-commands.h
@@ -1366,7 +1366,7 @@ struct iwl_rx_phy_res {
__le16 reserved3;
} __attribute__ ((packed));
-struct iwl4965_rx_mpdu_res_start {
+struct iwl_rx_mpdu_res_start {
__le16 byte_count;
__le16 reserved;
} __attribute__ ((packed));
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/6] iwlwifi: print warning about disconnected antennas
From: Reinette Chatre @ 2010-06-14 18:24 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Johannes Berg, Reinette Chatre
In-Reply-To: <1276539892-12471-1-git-send-email-reinette.chatre@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
When we detect that not all antennas are
properly connected, we simply disable the
associated chains, but never notify the
user at all. Print out a warning so it is
obvious that happened and we know where
to start looking for related issues.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-calib.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-calib.c b/drivers/net/wireless/iwlwifi/iwl-calib.c
index 7e82277..22fa947 100644
--- a/drivers/net/wireless/iwlwifi/iwl-calib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-calib.c
@@ -846,6 +846,13 @@ void iwl_chain_noise_calibration(struct iwl_priv *priv,
}
}
+ if (active_chains != priv->hw_params.valid_rx_ant &&
+ active_chains != priv->chain_noise_data.active_chains)
+ IWL_WARN(priv,
+ "Detected that not all antennas are connected! "
+ "Connected: %#x, valid: %#x.\n",
+ active_chains, priv->hw_params.valid_rx_ant);
+
/* Save for use within RXON, TX, SCAN commands, etc. */
priv->chain_noise_data.active_chains = active_chains;
IWL_DEBUG_CALIB(priv, "active_chains (bitwise) = 0x%x\n",
--
1.7.0.4
^ permalink raw reply related
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