* Re: rt61pci: WEP broken in current wireless-testing
From: Gertjan van Wingerde @ 2010-05-07 5:57 UTC (permalink / raw)
To: Pavel Roskin; +Cc: John W. Linville, linux-wireless
In-Reply-To: <20100506211435.1nfaq83vkg4ccc0g-cebfxv@webmail.spamcop.net>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On 05/07/10 03:14, Pavel Roskin wrote:
> Quoting "John W. Linville" <linville@tuxdriver.com>:
>
>> When you get to this, you probably should use wireless-next-2.6
>> (or wireless-2.6) for the bisection. The pulls from linux-2.6 in
>> wireless-testing make bisection much more painful than necessary
>> (as long as the problem is actually evident in the other kernels).
>
> I know it's painful!
>
>> You can use the 'master-<date>' tags as guidelines for matching
>> wireless-testing versions to representative wireless-next-2.6 (or
>> wireless-2.6) tree versions.
>
> Thank you for the tips!
>
Hi,
It might be that one of my recent patches broke this. Can you try the
attached patch?
---
Gertjan
[-- Attachment #2: rt61pci-wep-fix.diff --]
[-- Type: text/plain, Size: 529 bytes --]
diff --git a/drivers/net/wireless/rt2x00/rt2x00crypto.c b/drivers/net/wireless/rt2x00/rt2x00crypto.c
index d291c78..583dacd 100644
--- a/drivers/net/wireless/rt2x00/rt2x00crypto.c
+++ b/drivers/net/wireless/rt2x00/rt2x00crypto.c
@@ -128,6 +128,7 @@ void rt2x00crypto_tx_remove_iv(struct sk_buff *skb, struct txentry_desc *txdesc)
/* Pull buffer to correct size */
skb_pull(skb, txdesc->iv_len);
+ txdesc->length -= txdesc->iv_len;
/* IV/EIV data has officially been stripped */
skbdesc->flags |= SKBDESC_IV_STRIPPED;
^ permalink raw reply related
* Re: The case of the bogus SSID
From: pigiron @ 2010-05-07 2:56 UTC (permalink / raw)
To: Steve deRosier; +Cc: linux-wireless
In-Reply-To: <t2j446ae9281005061112z6eee4126z673947eb02dc4f12@mail.gmail.com>
On Thu, 6 May 2010 11:12:15 -0700 Steve deRosier <steve@cozybit.com> wrote:
> On Wed, May 5, 2010 at 10:01 AM, pigiron <pigiron@gmx.com> wrote:
> > I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the
> > ieee80211.h file, and recently the same 52 was also assigned to
> > WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
> >
>
> I can't answer the rest of your question, but AFAIK, the element IDs
> for 802.11s mesh haven't been approved yet as the 802.11s draft
> contains a note to that effect. The current ANA database sheet I
> could find (Feb 2010) does have 52 assigned to Neighbor Report, and
> the mesh element IDs are nowhere to be found.
>
> - Steve
I agree. The 802.11k-2008 standard has already been approved with Element ID
52 = Neighbor Report, so it's probably almost a guarantee that 802.11s won't be
assigning 52 to anything in the future.
I'm kind of stuck on this problem. I could probably find out what's causing the
failure and create a patch... but the patch wouldn't be "The Right Thing To
Do(tm)" if the router isn't supposed to be spewing that data to begin with.
And at this point I've sort of convinced myself that the router is misbehaving.
When I combine Table 7-15 in the 802.11k-2008 standard with the same table in
the 802.11-2007 standard (Table 7-15 describes a "Probe Response frame body"), I
just can't find a way for it to contain a Neighbor Report.
I've had to code to a lot of standards/specifications over the years, but this
is my first trip into the 802.11 world... so I guess I'm just looking for some
confirmation from someone who has been living in the wireless world for awhile.
That, and I'd have to do a *bunch* of war driving to prove that no other routers
spew a Neighbor Report.
^ permalink raw reply
* [PATCH 1/3] ath9k_common: move the rate status setting into ath9k_process_rate()
From: Luis R. Rodriguez @ 2010-05-07 2:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
This has no real functional change, this just moves the setting the
the mac80211 rate index into ath9k_process_rate(). This allows us
to eventually make ath9k_process_rate() return a negative value
in case we have detected a specific case rate situation which should
have been ignored.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/common.c | 40 +++++++++++++++++++++----------
1 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index b4424a6..9a33c3a 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -102,11 +102,11 @@ static bool ath9k_rx_accept(struct ath_common *common,
return true;
}
-static u8 ath9k_process_rate(struct ath_common *common,
- struct ieee80211_hw *hw,
- struct ath_rx_status *rx_stats,
- struct ieee80211_rx_status *rxs,
- struct sk_buff *skb)
+static int ath9k_process_rate(struct ath_common *common,
+ struct ieee80211_hw *hw,
+ struct ath_rx_status *rx_stats,
+ struct ieee80211_rx_status *rxs,
+ struct sk_buff *skb)
{
struct ieee80211_supported_band *sband;
enum ieee80211_band band;
@@ -122,25 +122,33 @@ static u8 ath9k_process_rate(struct ath_common *common,
rxs->flag |= RX_FLAG_40MHZ;
if (rx_stats->rs_flags & ATH9K_RX_GI)
rxs->flag |= RX_FLAG_SHORT_GI;
- return rx_stats->rs_rate & 0x7f;
+ rxs->rate_idx = rx_stats->rs_rate & 0x7f;
+ return 0;
}
for (i = 0; i < sband->n_bitrates; i++) {
- if (sband->bitrates[i].hw_value == rx_stats->rs_rate)
- return i;
+ if (sband->bitrates[i].hw_value == rx_stats->rs_rate) {
+ rxs->rate_idx = i;
+ return 0;
+ }
if (sband->bitrates[i].hw_value_short == rx_stats->rs_rate) {
rxs->flag |= RX_FLAG_SHORTPRE;
- return i;
+ rxs->rate_idx = i;
+ return 0;
}
}
- /* No valid hardware bitrate found -- we should not get here */
+ /*
+ * No valid hardware bitrate found -- we should not get here
+ * because hardware has already validated this frame as OK.
+ */
ath_print(common, ATH_DBG_XMIT, "unsupported hw bitrate detected "
"0x%02x using 1 Mbit\n", rx_stats->rs_rate);
if ((common->debug_mask & ATH_DBG_XMIT))
print_hex_dump_bytes("", DUMP_PREFIX_NONE, skb->data, skb->len);
- return 0;
+ rxs->rate_idx = 0;
+ return 0;
}
static void ath9k_process_rssi(struct ath_common *common,
@@ -202,13 +210,19 @@ int ath9k_cmn_rx_skb_preprocess(struct ath_common *common,
struct ath_hw *ah = common->ah;
memset(rx_status, 0, sizeof(struct ieee80211_rx_status));
+
+ /*
+ * everything but the rate is checked here, the rate check is done
+ * separately to avoid doing two lookups for a rate for each frame.
+ */
if (!ath9k_rx_accept(common, skb, rx_status, rx_stats, decrypt_error))
return -EINVAL;
ath9k_process_rssi(common, hw, skb, rx_stats);
- rx_status->rate_idx = ath9k_process_rate(common, hw,
- rx_stats, rx_status, skb);
+ if (ath9k_process_rate(common, hw, rx_stats, rx_status, skb))
+ return -EINVAL;
+
rx_status->mactime = ath9k_hw_extend_tsf(ah, rx_stats->rs_tstamp);
rx_status->band = hw->conf.channel->band;
rx_status->freq = hw->conf.channel->center_freq;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] mac80211: set IEEE80211_TX_CTL_FIRST_FRAGMENT for beacons
From: John W. Linville @ 2010-05-07 2:35 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <20100507001319.GA6990@tuxdriver.com>
On Thu, May 06, 2010 at 08:13:20PM -0400, John W. Linville wrote:
> On Thu, May 06, 2010 at 03:01:25PM -0700, Luis R. Rodriguez wrote:
> > On Thu, May 6, 2010 at 11:45 AM, John W. Linville
> > <linville@tuxdriver.com> wrote:
> >
> > Why though?
>
> Because it is correct, appropriate, and zero additional cost. And
> because if you use the same tx path for beacons as you use for normal
> frames and if in that path you manage the sequence number in software
> you should be checking that flag before bumping the sequence number.
That isn't worded too clearly... If you manage the sequence number
in software then you should be checking that flag before bumping
the sequence number. If you use the same tx path for beacons as is
used for normal frames and you don't set that flag for beacons,
then beacons will reuse the sequence number from the previous frame.
Does that make sense?
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 3/3] ath9k_hw: Update initvals for AR9003 for xb113
From: Luis R. Rodriguez @ 2010-05-07 2:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Tom Hammel, Enis Akay
In-Reply-To: <1273200074-9127-1-git-send-email-lrodriguez@atheros.com>
Generated using the new shiny intivals-tool [1]:
initvals -w -f ar9003 > ar9003_initvals.h
The respective checksums are:
0x000000005a76829d ar9300_2p0_radio_postamble
0x000000009d90cb74 ar9300Modes_lowest_ob_db_tx_gain_table_2p0
0x00000000e0bc2c84 ar9300Modes_fast_clock_2p0
0x00000000852fca34 ar9300_2p0_radio_core
0x0000000000000000 ar9300Common_rx_gain_table_merlin_2p0
0x0000000078658fb5 ar9300_2p0_mac_postamble
0x0000000023235333 ar9300_2p0_soc_postamble
0x0000000054d41904 ar9200_merlin_2p0_radio_core
0x00000000618455d4 ar9300_2p0_baseband_postamble
0x000000009aa590a4 ar9300_2p0_baseband_core
0x000000004783d946 ar9300Modes_high_power_tx_gain_table_2p0
0x000000006681db44 ar9300Modes_high_ob_db_tx_gain_table_2p0
0x000000001f318700 ar9300Common_rx_gain_table_2p0
0x000000009990cb74 ar9300Modes_low_ob_db_tx_gain_table_2p0
0x00000000c9d66d40 ar9300_2p0_mac_core
0x0000000039139500 ar9300Common_wo_xlna_rx_gain_table_2p0
0x00000000a0c54980 ar9300_2p0_soc_preamble
0x00000000292e2544 ar9300PciePhy_pll_on_clkreq_disable_L1_2p0
0x000000002d3e2544 ar9300PciePhy_clkreq_enable_L1_2p0
0x00000000293e2544 ar9300PciePhy_clkreq_disable_L1_2p0
[1] http://wireless.kernel.org/en/users/Drivers/ath9k_hw/initvals-tool
Cc: Tom Hammel <thammel@atheros.com>
Cc: Enis Akay <Enis.Akay@Atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 204 +++++++++++-----------
1 files changed, 102 insertions(+), 102 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_initvals.h b/drivers/net/wireless/ath/ath9k/ar9003_initvals.h
index a131cd1..ef6116e 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_initvals.h
@@ -541,7 +541,7 @@ static const u32 ar9300_2p0_mac_postamble[][5] = {
static const u32 ar9300_2p0_soc_postamble[][5] = {
/* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */
- {0x00007010, 0x00000023, 0x00000023, 0x00000022, 0x00000022},
+ {0x00007010, 0x00000023, 0x00000023, 0x00000023, 0x00000023},
};
static const u32 ar9200_merlin_2p0_radio_core[][2] = {
@@ -588,12 +588,12 @@ static const u32 ar9200_merlin_2p0_radio_core[][2] = {
static const u32 ar9300_2p0_baseband_postamble[][5] = {
/* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */
- {0x00009810, 0xd00a8005, 0xd00a8005, 0xd00a8005, 0xd00a8005},
+ {0x00009810, 0xd00a8005, 0xd00a8005, 0xd00a8005, 0xd00a800b},
{0x00009820, 0x206a022e, 0x206a022e, 0x206a012e, 0x206a012e},
{0x00009824, 0x5ac640d0, 0x5ac640d0, 0x5ac640d0, 0x5ac640d0},
{0x00009828, 0x06903081, 0x06903081, 0x06903881, 0x06903881},
{0x0000982c, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4},
- {0x00009830, 0x0000059c, 0x0000059c, 0x0000059c, 0x0000059c},
+ {0x00009830, 0x0000059c, 0x0000059c, 0x0000059c, 0x00000b9c},
{0x00009c00, 0x00000044, 0x000000c4, 0x000000c4, 0x00000044},
{0x00009e00, 0x0372161e, 0x0372161e, 0x037216a0, 0x037216a0},
{0x00009e04, 0x00802020, 0x00802020, 0x00802020, 0x00802020},
@@ -744,7 +744,7 @@ static const u32 ar9300_2p0_baseband_core[][2] = {
{0x0000a408, 0x0e79e5c6},
{0x0000a40c, 0x00820820},
{0x0000a414, 0x1ce739ce},
- {0x0000a418, 0x7d001dce},
+ {0x0000a418, 0x2d001dce},
{0x0000a41c, 0x1ce739ce},
{0x0000a420, 0x000001ce},
{0x0000a424, 0x1ce739ce},
@@ -756,7 +756,7 @@ static const u32 ar9300_2p0_baseband_core[][2] = {
{0x0000a43c, 0x00000000},
{0x0000a440, 0x00000000},
{0x0000a444, 0x00000000},
- {0x0000a448, 0x07000080},
+ {0x0000a448, 0x04000080},
{0x0000a44c, 0x00000001},
{0x0000a450, 0x00010000},
{0x0000a458, 0x00000000},
@@ -777,7 +777,7 @@ static const u32 ar9300_2p0_baseband_core[][2] = {
{0x0000a638, 0x00000000},
{0x0000a63c, 0x00000000},
{0x0000a640, 0x00000000},
- {0x0000a644, 0x3ffd9d74},
+ {0x0000a644, 0x3fad9d74},
{0x0000a648, 0x0048060a},
{0x0000a64c, 0x00000637},
{0x0000a670, 0x03020100},
@@ -835,9 +835,9 @@ static const u32 ar9300_2p0_baseband_core[][2] = {
static const u32 ar9300Modes_high_power_tx_gain_table_2p0[][5] = {
/* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */
- {0x0000a410, 0x000050db, 0x000050db, 0x000050d9, 0x000050d9},
- {0x0000a500, 0x00020220, 0x00020220, 0x00000000, 0x00000000},
- {0x0000a504, 0x06020223, 0x06020223, 0x04000002, 0x04000002},
+ {0x0000a410, 0x000050d9, 0x000050d9, 0x000050d9, 0x000050d9},
+ {0x0000a500, 0x00002220, 0x00002220, 0x00000000, 0x00000000},
+ {0x0000a504, 0x06002223, 0x06002223, 0x04000002, 0x04000002},
{0x0000a508, 0x0a022220, 0x0a022220, 0x08000004, 0x08000004},
{0x0000a50c, 0x0f022223, 0x0f022223, 0x0b000200, 0x0b000200},
{0x0000a510, 0x14022620, 0x14022620, 0x0f000202, 0x0f000202},
@@ -848,28 +848,28 @@ static const u32 ar9300Modes_high_power_tx_gain_table_2p0[][5] = {
{0x0000a524, 0x28023042, 0x28023042, 0x1f000a02, 0x1f000a02},
{0x0000a528, 0x2c023044, 0x2c023044, 0x23000a04, 0x23000a04},
{0x0000a52c, 0x2f023644, 0x2f023644, 0x26000a20, 0x26000a20},
- {0x0000a530, 0x34043643, 0x34043643, 0x2a000e20, 0x2a000e20},
- {0x0000a534, 0x38043a44, 0x38043a44, 0x2e000e22, 0x2e000e22},
- {0x0000a538, 0x3b043e45, 0x3b043e45, 0x31000e24, 0x31000e24},
- {0x0000a53c, 0x40063e46, 0x40063e46, 0x34001640, 0x34001640},
- {0x0000a540, 0x44083e46, 0x44083e46, 0x38001660, 0x38001660},
- {0x0000a544, 0x46083e66, 0x46083e66, 0x3b001861, 0x3b001861},
- {0x0000a548, 0x4b0a3e69, 0x4b0a3e69, 0x3e001a81, 0x3e001a81},
- {0x0000a54c, 0x4f0a5e66, 0x4f0a5e66, 0x42001a83, 0x42001a83},
- {0x0000a550, 0x540a7e66, 0x540a7e66, 0x44001c84, 0x44001c84},
- {0x0000a554, 0x570a7e89, 0x570a7e89, 0x48001ce3, 0x48001ce3},
- {0x0000a558, 0x5c0e7e8a, 0x5c0e7e8a, 0x4c001ce5, 0x4c001ce5},
- {0x0000a55c, 0x60127e8b, 0x60127e8b, 0x50001ce9, 0x50001ce9},
- {0x0000a560, 0x65127ecc, 0x65127ecc, 0x54001ceb, 0x54001ceb},
- {0x0000a564, 0x6b169ecd, 0x6b169ecd, 0x56001eec, 0x56001eec},
- {0x0000a568, 0x70169f0e, 0x70169f0e, 0x56001eec, 0x56001eec},
- {0x0000a56c, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a570, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a574, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a578, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a57c, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a580, 0x00820220, 0x00820220, 0x00800000, 0x00800000},
- {0x0000a584, 0x06820223, 0x06820223, 0x04800002, 0x04800002},
+ {0x0000a530, 0x34025643, 0x34025643, 0x2a000e20, 0x2a000e20},
+ {0x0000a534, 0x38025a44, 0x38025a44, 0x2e000e22, 0x2e000e22},
+ {0x0000a538, 0x3b025e45, 0x3b025e45, 0x31000e24, 0x31000e24},
+ {0x0000a53c, 0x41025e4a, 0x41025e4a, 0x34001640, 0x34001640},
+ {0x0000a540, 0x48025e6c, 0x48025e6c, 0x38001660, 0x38001660},
+ {0x0000a544, 0x4e025e8e, 0x4e025e8e, 0x3b001861, 0x3b001861},
+ {0x0000a548, 0x53025eb2, 0x53025eb2, 0x3e001a81, 0x3e001a81},
+ {0x0000a54c, 0x59025eb5, 0x59025eb5, 0x42001a83, 0x42001a83},
+ {0x0000a550, 0x5f025ef6, 0x5f025ef6, 0x44001c84, 0x44001c84},
+ {0x0000a554, 0x62025f56, 0x62025f56, 0x48001ce3, 0x48001ce3},
+ {0x0000a558, 0x66027f56, 0x66027f56, 0x4c001ce5, 0x4c001ce5},
+ {0x0000a55c, 0x6a029f56, 0x6a029f56, 0x50001ce9, 0x50001ce9},
+ {0x0000a560, 0x70049f56, 0x70049f56, 0x54001ceb, 0x54001ceb},
+ {0x0000a564, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a568, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a56c, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a570, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a574, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a578, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a57c, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a580, 0x00802220, 0x00802220, 0x00800000, 0x00800000},
+ {0x0000a584, 0x06802223, 0x06802223, 0x04800002, 0x04800002},
{0x0000a588, 0x0a822220, 0x0a822220, 0x08800004, 0x08800004},
{0x0000a58c, 0x0f822223, 0x0f822223, 0x0b800200, 0x0b800200},
{0x0000a590, 0x14822620, 0x14822620, 0x0f800202, 0x0f800202},
@@ -880,42 +880,42 @@ static const u32 ar9300Modes_high_power_tx_gain_table_2p0[][5] = {
{0x0000a5a4, 0x28823042, 0x28823042, 0x1f800a02, 0x1f800a02},
{0x0000a5a8, 0x2c823044, 0x2c823044, 0x23800a04, 0x23800a04},
{0x0000a5ac, 0x2f823644, 0x2f823644, 0x26800a20, 0x26800a20},
- {0x0000a5b0, 0x34843643, 0x34843643, 0x2a800e20, 0x2a800e20},
- {0x0000a5b4, 0x38843a44, 0x38843a44, 0x2e800e22, 0x2e800e22},
- {0x0000a5b8, 0x3b843e45, 0x3b843e45, 0x31800e24, 0x31800e24},
- {0x0000a5bc, 0x40863e46, 0x40863e46, 0x34801640, 0x34801640},
- {0x0000a5c0, 0x4c8a3065, 0x44883e46, 0x44883e46, 0x38801660},
- {0x0000a5c4, 0x46883e66, 0x46883e66, 0x3b801861, 0x3b801861},
- {0x0000a5c8, 0x4b8a3e69, 0x4b8a3e69, 0x3e801a81, 0x3e801a81},
- {0x0000a5cc, 0x4f8a5e66, 0x4f8a5e66, 0x42801a83, 0x42801a83},
- {0x0000a5d0, 0x548a7e66, 0x548a7e66, 0x44801c84, 0x44801c84},
- {0x0000a5d4, 0x578a7e89, 0x578a7e89, 0x48801ce3, 0x48801ce3},
- {0x0000a5d8, 0x5c8e7e8a, 0x5c8e7e8a, 0x4c801ce5, 0x4c801ce5},
- {0x0000a5dc, 0x60927e8b, 0x60927e8b, 0x50801ce9, 0x50801ce9},
- {0x0000a5e0, 0x65927ecc, 0x65927ecc, 0x54801ceb, 0x54801ceb},
- {0x0000a5e4, 0x6b969ecd, 0x6b969ecd, 0x56801eec, 0x56801eec},
- {0x0000a5e8, 0x70969f0e, 0x70969f0e, 0x56801eec, 0x56801eec},
- {0x0000a5ec, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5f0, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5f4, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5f8, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5fc, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
+ {0x0000a5b0, 0x34825643, 0x34825643, 0x2a800e20, 0x2a800e20},
+ {0x0000a5b4, 0x38825a44, 0x38825a44, 0x2e800e22, 0x2e800e22},
+ {0x0000a5b8, 0x3b825e45, 0x3b825e45, 0x31800e24, 0x31800e24},
+ {0x0000a5bc, 0x41825e4a, 0x41825e4a, 0x34801640, 0x34801640},
+ {0x0000a5c0, 0x48825e6c, 0x48825e6c, 0x38801660, 0x38801660},
+ {0x0000a5c4, 0x4e825e8e, 0x4e825e8e, 0x3b801861, 0x3b801861},
+ {0x0000a5c8, 0x53825eb2, 0x53825eb2, 0x3e801a81, 0x3e801a81},
+ {0x0000a5cc, 0x59825eb5, 0x59825eb5, 0x42801a83, 0x42801a83},
+ {0x0000a5d0, 0x5f825ef6, 0x5f825ef6, 0x44801c84, 0x44801c84},
+ {0x0000a5d4, 0x62825f56, 0x62825f56, 0x48801ce3, 0x48801ce3},
+ {0x0000a5d8, 0x66827f56, 0x66827f56, 0x4c801ce5, 0x4c801ce5},
+ {0x0000a5dc, 0x6a829f56, 0x6a829f56, 0x50801ce9, 0x50801ce9},
+ {0x0000a5e0, 0x70849f56, 0x70849f56, 0x54801ceb, 0x54801ceb},
+ {0x0000a5e4, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5e8, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5ec, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5f0, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5f4, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5f8, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5fc, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
{0x00016044, 0x056db2e6, 0x056db2e6, 0x056db2e6, 0x056db2e6},
- {0x00016048, 0xad241a61, 0xad241a61, 0xad241a61, 0xad241a61},
+ {0x00016048, 0xae481a61, 0xae481a61, 0xae481a61, 0xae481a61},
{0x00016068, 0x6eb6db6c, 0x6eb6db6c, 0x6eb6db6c, 0x6eb6db6c},
{0x00016444, 0x056db2e6, 0x056db2e6, 0x056db2e6, 0x056db2e6},
- {0x00016448, 0xad241a61, 0xad241a61, 0xad241a61, 0xad241a61},
+ {0x00016448, 0xae481a61, 0xae481a61, 0xae481a61, 0xae481a61},
{0x00016468, 0x6eb6db6c, 0x6eb6db6c, 0x6eb6db6c, 0x6eb6db6c},
{0x00016844, 0x056db2e6, 0x056db2e6, 0x056db2e6, 0x056db2e6},
- {0x00016848, 0xad241a61, 0xad241a61, 0xad241a61, 0xad241a61},
+ {0x00016848, 0xae481a61, 0xae481a61, 0xae481a61, 0xae481a61},
{0x00016868, 0x6eb6db6c, 0x6eb6db6c, 0x6eb6db6c, 0x6eb6db6c},
};
static const u32 ar9300Modes_high_ob_db_tx_gain_table_2p0[][5] = {
/* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */
- {0x0000a410, 0x000050db, 0x000050db, 0x000050d9, 0x000050d9},
- {0x0000a500, 0x00020220, 0x00020220, 0x00000000, 0x00000000},
- {0x0000a504, 0x06020223, 0x06020223, 0x04000002, 0x04000002},
+ {0x0000a410, 0x000050d9, 0x000050d9, 0x000050d9, 0x000050d9},
+ {0x0000a500, 0x00002220, 0x00002220, 0x00000000, 0x00000000},
+ {0x0000a504, 0x06002223, 0x06002223, 0x04000002, 0x04000002},
{0x0000a508, 0x0a022220, 0x0a022220, 0x08000004, 0x08000004},
{0x0000a50c, 0x0f022223, 0x0f022223, 0x0b000200, 0x0b000200},
{0x0000a510, 0x14022620, 0x14022620, 0x0f000202, 0x0f000202},
@@ -926,28 +926,28 @@ static const u32 ar9300Modes_high_ob_db_tx_gain_table_2p0[][5] = {
{0x0000a524, 0x28023042, 0x28023042, 0x1f000a02, 0x1f000a02},
{0x0000a528, 0x2c023044, 0x2c023044, 0x23000a04, 0x23000a04},
{0x0000a52c, 0x2f023644, 0x2f023644, 0x26000a20, 0x26000a20},
- {0x0000a530, 0x34043643, 0x34043643, 0x2a000e20, 0x2a000e20},
- {0x0000a534, 0x38043a44, 0x38043a44, 0x2e000e22, 0x2e000e22},
- {0x0000a538, 0x3b043e45, 0x3b043e45, 0x31000e24, 0x31000e24},
- {0x0000a53c, 0x40063e46, 0x40063e46, 0x34001640, 0x34001640},
- {0x0000a540, 0x44083e46, 0x44083e46, 0x38001660, 0x38001660},
- {0x0000a544, 0x46083e66, 0x46083e66, 0x3b001861, 0x3b001861},
- {0x0000a548, 0x4b0a3e69, 0x4b0a3e69, 0x3e001a81, 0x3e001a81},
- {0x0000a54c, 0x4f0a5e66, 0x4f0a5e66, 0x42001a83, 0x42001a83},
- {0x0000a550, 0x540a7e66, 0x540a7e66, 0x44001c84, 0x44001c84},
- {0x0000a554, 0x570a7e89, 0x570a7e89, 0x48001ce3, 0x48001ce3},
- {0x0000a558, 0x5c0e7e8a, 0x5c0e7e8a, 0x4c001ce5, 0x4c001ce5},
- {0x0000a55c, 0x60127e8b, 0x60127e8b, 0x50001ce9, 0x50001ce9},
- {0x0000a560, 0x65127ecc, 0x65127ecc, 0x54001ceb, 0x54001ceb},
- {0x0000a564, 0x6b169ecd, 0x6b169ecd, 0x56001eec, 0x56001eec},
- {0x0000a568, 0x70169f0e, 0x70169f0e, 0x56001eec, 0x56001eec},
- {0x0000a56c, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a570, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a574, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a578, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a57c, 0x75169f4f, 0x75169f4f, 0x56001eec, 0x56001eec},
- {0x0000a580, 0x00820220, 0x00820220, 0x00800000, 0x00800000},
- {0x0000a584, 0x06820223, 0x06820223, 0x04800002, 0x04800002},
+ {0x0000a530, 0x34025643, 0x34025643, 0x2a000e20, 0x2a000e20},
+ {0x0000a534, 0x38025a44, 0x38025a44, 0x2e000e22, 0x2e000e22},
+ {0x0000a538, 0x3b025e45, 0x3b025e45, 0x31000e24, 0x31000e24},
+ {0x0000a53c, 0x41025e4a, 0x41025e4a, 0x34001640, 0x34001640},
+ {0x0000a540, 0x48025e6c, 0x48025e6c, 0x38001660, 0x38001660},
+ {0x0000a544, 0x4e025e8e, 0x4e025e8e, 0x3b001861, 0x3b001861},
+ {0x0000a548, 0x53025eb2, 0x53025eb2, 0x3e001a81, 0x3e001a81},
+ {0x0000a54c, 0x59025eb5, 0x59025eb5, 0x42001a83, 0x42001a83},
+ {0x0000a550, 0x5f025ef6, 0x5f025ef6, 0x44001c84, 0x44001c84},
+ {0x0000a554, 0x62025f56, 0x62025f56, 0x48001ce3, 0x48001ce3},
+ {0x0000a558, 0x66027f56, 0x66027f56, 0x4c001ce5, 0x4c001ce5},
+ {0x0000a55c, 0x6a029f56, 0x6a029f56, 0x50001ce9, 0x50001ce9},
+ {0x0000a560, 0x70049f56, 0x70049f56, 0x54001ceb, 0x54001ceb},
+ {0x0000a564, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a568, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a56c, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a570, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a574, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a578, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a57c, 0x7504ff56, 0x7504ff56, 0x56001eec, 0x56001eec},
+ {0x0000a580, 0x00802220, 0x00802220, 0x00800000, 0x00800000},
+ {0x0000a584, 0x06802223, 0x06802223, 0x04800002, 0x04800002},
{0x0000a588, 0x0a822220, 0x0a822220, 0x08800004, 0x08800004},
{0x0000a58c, 0x0f822223, 0x0f822223, 0x0b800200, 0x0b800200},
{0x0000a590, 0x14822620, 0x14822620, 0x0f800202, 0x0f800202},
@@ -958,34 +958,34 @@ static const u32 ar9300Modes_high_ob_db_tx_gain_table_2p0[][5] = {
{0x0000a5a4, 0x28823042, 0x28823042, 0x1f800a02, 0x1f800a02},
{0x0000a5a8, 0x2c823044, 0x2c823044, 0x23800a04, 0x23800a04},
{0x0000a5ac, 0x2f823644, 0x2f823644, 0x26800a20, 0x26800a20},
- {0x0000a5b0, 0x34843643, 0x34843643, 0x2a800e20, 0x2a800e20},
- {0x0000a5b4, 0x38843a44, 0x38843a44, 0x2e800e22, 0x2e800e22},
- {0x0000a5b8, 0x3b843e45, 0x3b843e45, 0x31800e24, 0x31800e24},
- {0x0000a5bc, 0x40863e46, 0x40863e46, 0x34801640, 0x34801640},
- {0x0000a5c0, 0x44883e46, 0x44883e46, 0x38801660, 0x38801660},
- {0x0000a5c4, 0x46883e66, 0x46883e66, 0x3b801861, 0x3b801861},
- {0x0000a5c8, 0x4b8a3e69, 0x4b8a3e69, 0x3e801a81, 0x3e801a81},
- {0x0000a5cc, 0x4f8a5e66, 0x4f8a5e66, 0x42801a83, 0x42801a83},
- {0x0000a5d0, 0x548a7e66, 0x548a7e66, 0x44801c84, 0x44801c84},
- {0x0000a5d4, 0x578a7e89, 0x578a7e89, 0x48801ce3, 0x48801ce3},
- {0x0000a5d8, 0x5c8e7e8a, 0x5c8e7e8a, 0x4c801ce5, 0x4c801ce5},
- {0x0000a5dc, 0x60927e8b, 0x60927e8b, 0x50801ce9, 0x50801ce9},
- {0x0000a5e0, 0x65927ecc, 0x65927ecc, 0x54801ceb, 0x54801ceb},
- {0x0000a5e4, 0x6b969ecd, 0x6b969ecd, 0x56801eec, 0x56801eec},
- {0x0000a5e8, 0x70969f0e, 0x70969f0e, 0x56801eec, 0x56801eec},
- {0x0000a5ec, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5f0, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5f4, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5f8, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
- {0x0000a5fc, 0x75969f4f, 0x75969f4f, 0x56801eec, 0x56801eec},
+ {0x0000a5b0, 0x34825643, 0x34825643, 0x2a800e20, 0x2a800e20},
+ {0x0000a5b4, 0x38825a44, 0x38825a44, 0x2e800e22, 0x2e800e22},
+ {0x0000a5b8, 0x3b825e45, 0x3b825e45, 0x31800e24, 0x31800e24},
+ {0x0000a5bc, 0x41825e4a, 0x41825e4a, 0x34801640, 0x34801640},
+ {0x0000a5c0, 0x48825e6c, 0x48825e6c, 0x38801660, 0x38801660},
+ {0x0000a5c4, 0x4e825e8e, 0x4e825e8e, 0x3b801861, 0x3b801861},
+ {0x0000a5c8, 0x53825eb2, 0x53825eb2, 0x3e801a81, 0x3e801a81},
+ {0x0000a5cc, 0x59825eb5, 0x59825eb5, 0x42801a83, 0x42801a83},
+ {0x0000a5d0, 0x5f825ef6, 0x5f825ef6, 0x44801c84, 0x44801c84},
+ {0x0000a5d4, 0x62825f56, 0x62825f56, 0x48801ce3, 0x48801ce3},
+ {0x0000a5d8, 0x66827f56, 0x66827f56, 0x4c801ce5, 0x4c801ce5},
+ {0x0000a5dc, 0x6a829f56, 0x6a829f56, 0x50801ce9, 0x50801ce9},
+ {0x0000a5e0, 0x70849f56, 0x70849f56, 0x54801ceb, 0x54801ceb},
+ {0x0000a5e4, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5e8, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5ec, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5f0, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5f4, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5f8, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
+ {0x0000a5fc, 0x7584ff56, 0x7584ff56, 0x56801eec, 0x56801eec},
{0x00016044, 0x056db2e4, 0x056db2e4, 0x056db2e4, 0x056db2e4},
- {0x00016048, 0x8c001a61, 0x8c001a61, 0x8c001a61, 0x8c001a61},
+ {0x00016048, 0x8e481a61, 0x8e481a61, 0x8e481a61, 0x8e481a61},
{0x00016068, 0x6db6db6c, 0x6db6db6c, 0x6db6db6c, 0x6db6db6c},
{0x00016444, 0x056db2e4, 0x056db2e4, 0x056db2e4, 0x056db2e4},
- {0x00016448, 0x8c001a61, 0x8c001a61, 0x8c001a61, 0x8c001a61},
+ {0x00016448, 0x8e481a61, 0x8e481a61, 0x8e481a61, 0x8e481a61},
{0x00016468, 0x6db6db6c, 0x6db6db6c, 0x6db6db6c, 0x6db6db6c},
{0x00016844, 0x056db2e4, 0x056db2e4, 0x056db2e4, 0x056db2e4},
- {0x00016848, 0x8c001a61, 0x8c001a61, 0x8c001a61, 0x8c001a61},
+ {0x00016848, 0x8e481a61, 0x8e481a61, 0x8e481a61, 0x8e481a61},
{0x00016868, 0x6db6db6c, 0x6db6db6c, 0x6db6db6c, 0x6db6db6c},
};
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/3] ath9k: Rate processing fix and initval update for AR9003
From: Luis R. Rodriguez @ 2010-05-07 2:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
Three patches in this series. Two are related to the problem
Kalle reported earlier but it should not help him given that
we know his rates *are* 802.11n based. This still seems best
to do. The last one is an register initialization update for
ath9k for AR9003 for XB113.
Luis R. Rodriguez (3):
ath9k_common: move the rate status setting into ath9k_process_rate()
ath9k_common: drop incomming frames with an invalid hardware rate
ath9k_hw: Update initvals for AR9003 for xb113
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 204 +++++++++++-----------
drivers/net/wireless/ath/ath9k/common.c | 39 +++--
2 files changed, 128 insertions(+), 115 deletions(-)
^ permalink raw reply
* [PATCH 2/3] ath9k_common: drop incomming frames with an invalid hardware rate
From: Luis R. Rodriguez @ 2010-05-07 2:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1273200074-9127-1-git-send-email-lrodriguez@atheros.com>
ath9k_common (used by ath9k and ath9k_htc) trusts the frames
blessed by hardware as OK are infact correct even if the rate
seen by the driver is unrecognized. ath9k_common just treats
these frames in mac80211 as frames as frames under 1 mbps rate.
It seems this might not be the best thing to do as other parts of
the frame might not be valid so just drop these frames for now.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/common.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 9a33c3a..b22f9c9 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -147,8 +147,7 @@ static int ath9k_process_rate(struct ath_common *common,
if ((common->debug_mask & ATH_DBG_XMIT))
print_hex_dump_bytes("", DUMP_PREFIX_NONE, skb->data, skb->len);
- rxs->rate_idx = 0;
- return 0;
+ return -EINVAL;
}
static void ath9k_process_rssi(struct ath_common *common,
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/3] ath9k_common: move the rate status setting into ath9k_process_rate()
From: Luis R. Rodriguez @ 2010-05-07 2:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1273200074-9127-1-git-send-email-lrodriguez@atheros.com>
This has no real functional change, this just moves the setting the
the mac80211 rate index into ath9k_process_rate(). This allows us
to eventually make ath9k_process_rate() return a negative value
in case we have detected a specific case rate situation which should
have been ignored.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/common.c | 40 +++++++++++++++++++++----------
1 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index b4424a6..9a33c3a 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -102,11 +102,11 @@ static bool ath9k_rx_accept(struct ath_common *common,
return true;
}
-static u8 ath9k_process_rate(struct ath_common *common,
- struct ieee80211_hw *hw,
- struct ath_rx_status *rx_stats,
- struct ieee80211_rx_status *rxs,
- struct sk_buff *skb)
+static int ath9k_process_rate(struct ath_common *common,
+ struct ieee80211_hw *hw,
+ struct ath_rx_status *rx_stats,
+ struct ieee80211_rx_status *rxs,
+ struct sk_buff *skb)
{
struct ieee80211_supported_band *sband;
enum ieee80211_band band;
@@ -122,25 +122,33 @@ static u8 ath9k_process_rate(struct ath_common *common,
rxs->flag |= RX_FLAG_40MHZ;
if (rx_stats->rs_flags & ATH9K_RX_GI)
rxs->flag |= RX_FLAG_SHORT_GI;
- return rx_stats->rs_rate & 0x7f;
+ rxs->rate_idx = rx_stats->rs_rate & 0x7f;
+ return 0;
}
for (i = 0; i < sband->n_bitrates; i++) {
- if (sband->bitrates[i].hw_value == rx_stats->rs_rate)
- return i;
+ if (sband->bitrates[i].hw_value == rx_stats->rs_rate) {
+ rxs->rate_idx = i;
+ return 0;
+ }
if (sband->bitrates[i].hw_value_short == rx_stats->rs_rate) {
rxs->flag |= RX_FLAG_SHORTPRE;
- return i;
+ rxs->rate_idx = i;
+ return 0;
}
}
- /* No valid hardware bitrate found -- we should not get here */
+ /*
+ * No valid hardware bitrate found -- we should not get here
+ * because hardware has already validated this frame as OK.
+ */
ath_print(common, ATH_DBG_XMIT, "unsupported hw bitrate detected "
"0x%02x using 1 Mbit\n", rx_stats->rs_rate);
if ((common->debug_mask & ATH_DBG_XMIT))
print_hex_dump_bytes("", DUMP_PREFIX_NONE, skb->data, skb->len);
- return 0;
+ rxs->rate_idx = 0;
+ return 0;
}
static void ath9k_process_rssi(struct ath_common *common,
@@ -202,13 +210,19 @@ int ath9k_cmn_rx_skb_preprocess(struct ath_common *common,
struct ath_hw *ah = common->ah;
memset(rx_status, 0, sizeof(struct ieee80211_rx_status));
+
+ /*
+ * everything but the rate is checked here, the rate check is done
+ * separately to avoid doing two lookups for a rate for each frame.
+ */
if (!ath9k_rx_accept(common, skb, rx_status, rx_stats, decrypt_error))
return -EINVAL;
ath9k_process_rssi(common, hw, skb, rx_stats);
- rx_status->rate_idx = ath9k_process_rate(common, hw,
- rx_stats, rx_status, skb);
+ if (ath9k_process_rate(common, hw, rx_stats, rx_status, skb))
+ return -EINVAL;
+
rx_status->mactime = ath9k_hw_extend_tsf(ah, rx_stats->rs_tstamp);
rx_status->band = hw->conf.channel->band;
rx_status->freq = hw->conf.channel->center_freq;
--
1.6.3.3
^ permalink raw reply related
* Re: rt61pci: WEP broken in current wireless-testing
From: Pavel Roskin @ 2010-05-07 1:14 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100506134335.GA4167@tuxdriver.com>
Quoting "John W. Linville" <linville@tuxdriver.com>:
> When you get to this, you probably should use wireless-next-2.6
> (or wireless-2.6) for the bisection. The pulls from linux-2.6 in
> wireless-testing make bisection much more painful than necessary
> (as long as the problem is actually evident in the other kernels).
I know it's painful!
> You can use the 'master-<date>' tags as guidelines for matching
> wireless-testing versions to representative wireless-next-2.6 (or
> wireless-2.6) tree versions.
Thank you for the tips!
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mac80211: set IEEE80211_TX_CTL_FIRST_FRAGMENT for beacons
From: John W. Linville @ 2010-05-07 0:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <k2t43e72e891005061501h91e475f6q6cb8bc7c3bbec990@mail.gmail.com>
On Thu, May 06, 2010 at 03:01:25PM -0700, Luis R. Rodriguez wrote:
> On Thu, May 6, 2010 at 11:45 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
>
> Why though?
Because it is correct, appropriate, and zero additional cost. And
because if you use the same tx path for beacons as you use for normal
frames and if in that path you manage the sequence number in software
you should be checking that flag before bumping the sequence number.
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: [RFC/RFT] ssb: resolve alternate SPROM offset for 14e4:4315
From: Michael Buesch @ 2010-05-06 22:44 UTC (permalink / raw)
To: Larry Finger; +Cc: b43-dev, linux-wireless
In-Reply-To: <4BE2C009.8020002@lwfinger.net>
On Thursday 06 May 2010 15:11:37 Larry Finger wrote:
> Is it OK to read the chipcommon capabilities here?
Yeah. That register exists on all revisions.
Only add stuff to ssb_bus_scan that really _needs_ to be done that early.
Anything else should be done later.
--
Greetings, Michael.
^ permalink raw reply
* Re: 2.6.33.2: Turn tx power off/on for Atheros card
From: Luis R. Rodriguez @ 2010-05-06 22:16 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: linux-wireless, netdev
In-Reply-To: <g2wf69abfc31005060752w6876439cm45f5be68001c8382@mail.gmail.com>
On Thu, May 6, 2010 at 7:52 AM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> On Wed, May 5, 2010 at 12:26 PM, Yegor Yefremov
> <yegorslists@googlemail.com> wrote:
>> I'm using kernel 2.6.33.2 with AR2413 WLAN card. Issuing
>>
>> iwconfig wlan0 txpower off
>>
>> turns txpower off. I can see this status by iwconfig wlan0 and the
>> communication with AP terminates. But when I turn the txpower on
>>
>> iwconfig wlan0 txpower on
>>
>> nothing happens. Though iwconfig shows the previous tx power value.
>> Only ifconfig wlan0 down and then up recovers the transmission.
>>
>> Is it a known bug or I'm doing something wrong?
>
> I made some debugging and found out that after iwconfig wlan0 txpower
> off dev_close() will be invoked, so that local->open_count will be 0.
> The next time txpower on will be called, it will be checked if
> local->open_count > 0 and this conditions fails, so no hardware
> configuration will be made.
>
> I've made a quick and dirty hack, that opens the wireless device by
> enabling the txpower, if it was closed before. Is there any proper
> solution? Is it really necessary to close device to tunr txpower off?
Depends on the type of interfaces you have. For a monitor device it
makes no sense to close the device as you should be able to still RX.
It also is possible to TX over a monitor device using frame injection
so technically setting tx power to off would just mute it and would
seem useful.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: set IEEE80211_TX_CTL_FIRST_FRAGMENT for beacons
From: Luis R. Rodriguez @ 2010-05-06 22:01 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1273171517-6264-1-git-send-email-linville@tuxdriver.com>
On Thu, May 6, 2010 at 11:45 AM, John W. Linville
<linville@tuxdriver.com> wrote:
Why though?
Luis
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: add offload channel switch support
From: Luis R. Rodriguez @ 2010-05-06 21:58 UTC (permalink / raw)
To: wey-yi.w.guy; +Cc: johannes, linux-wireless
In-Reply-To: <1273159552-5579-1-git-send-email-wey-yi.w.guy@intel.com>
On Thu, May 6, 2010 at 8:25 AM, <wey-yi.w.guy@intel.com> wrote:
> From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>
> Adding support to offload the channel switch operation to driver if
> driver can support the function.
Can you please reword this a little, maybe, "This adds support for a
driver specific channel switch callback to be used by drivers which
might require a finer grain control of the operation, typically if you
have a respective firmware API call".
> The original approach, mac80211 utilize the mac_config callback function
Do you mean the mac80211 config() callback?
> and set the CHANNEL_CHANGE flag which is difficult to separate the true
> channel switch request from all the other channel changes condition;
Good point, but why is this needed? More below.
> with this offload approach, driver has more control on how to handle the
> channel switch request from AP, also can provide more accurate timing
> calculation
Is the current timing insufficient, and if so can you provide more
details. If the real reason for this callback is not timing
considerations is the real reason a firmware API thing? If so it
doesn't hurt to just say that to avoid confusing developer in deciding
which approach to take.
> The drivers like to support the channel switch offloading function
Maybe: "The drivers that require a dedicated channel switch callback"...
> will have
> to provide the mactime information (at least for mgmt and action frames)
Might be good to specify why, or at least in the documentation code below.
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
> v2: use "mactime" instead of timestamp in the frame body, the driver has to provide the mactime if need to support the channel switch function
> ---
> include/net/mac80211.h | 32 ++++++++++++++++++++++++++++
> net/mac80211/driver-ops.h | 11 +++++++++
> net/mac80211/driver-trace.h | 49 +++++++++++++++++++++++++++++++++++++++++++
> net/mac80211/ieee80211_i.h | 3 +-
> net/mac80211/mlme.c | 48 ++++++++++++++++++++++++++++++++++++++---
> 5 files changed, 138 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 2879c8e..dc5ae23 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -708,6 +708,26 @@ struct ieee80211_conf {
> };
>
> /**
> + * struct ieee80211_channel_switch - holds the channel switch data
> + *
> + * The information provided in this structure is required for channel switch
> + * operation.
> + *
> + * @timestamp: value in microseconds of the 64-bit Time Synchronization
> + * Function (TSF) timer when the channel switch ie received.
Might be good to indicate this is derived from the rx status mactime
and the beacon interval from the BSS.
> + * @block_tx: set to true if no more future frames transmission within the BSS
> + * until the scheduled channel switch
> + * @channel: pointer to ieee80211_channel contain then new channel information
> + * @count: specified the number of TBTT's until the channel switch event.
> + */
> +struct ieee80211_channel_switch {
> + u64 timestamp;
> + bool block_tx;
> + struct ieee80211_channel *channel;
> + u8 count;
> +};
> +
> +/**
> * struct ieee80211_vif - per-interface data
> *
> * Data in this structure is continually present for driver
> @@ -1694,6 +1714,8 @@ struct ieee80211_ops {
> int (*testmode_cmd)(struct ieee80211_hw *hw, void *data, int len);
> #endif
> void (*flush)(struct ieee80211_hw *hw, bool drop);
> + void (*channel_switch)(struct ieee80211_hw *hw,
> + struct ieee80211_channel_switch *ch_switch);
> };
>
> /**
> @@ -2444,6 +2466,16 @@ void ieee80211_cqm_rssi_notify(struct ieee80211_vif *vif,
> enum nl80211_cqm_rssi_threshold_event rssi_event,
> gfp_t gfp);
>
> +/**
> + * ieee80211_chswitch_done - Complete channel switch process
> + * @vif: &struct ieee80211_vif pointer from the add_interface callback.
> + * @is_seccess: make the channel switch successful or not
Typo, is_seccess, not success. Also, I don't get what this is for, can
you elaborate?
> + *
> + * Complete the channel switch post-process: set the new operational channel
> + * and wake up the suspended queues.
I don't get it.. who calls this and why, under what conditions?
If drivers have to call this once they are done with the channel
switch operation callback then you might want to specify that and/or
check for the existance of the op upon it being called and warn if it
is not.
> + */
> +void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool is_success);
> +
> /* Rate control API */
>
> /**
> diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
> index 997008e..5662bb5 100644
> --- a/net/mac80211/driver-ops.h
> +++ b/net/mac80211/driver-ops.h
> @@ -373,4 +373,15 @@ static inline void drv_flush(struct ieee80211_local *local, bool drop)
> if (local->ops->flush)
> local->ops->flush(&local->hw, drop);
> }
> +
> +static inline void drv_channel_switch(struct ieee80211_local *local,
> + struct ieee80211_channel_switch *ch_switch)
> +{
> + might_sleep();
> +
> + local->ops->channel_switch(&local->hw, ch_switch);
> +
> + trace_drv_channel_switch(local, ch_switch);
> +}
> +
> #endif /* __MAC80211_DRIVER_OPS */
> diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
> index ce734b5..cd1ae9f 100644
> --- a/net/mac80211/driver-trace.h
> +++ b/net/mac80211/driver-trace.h
> @@ -774,6 +774,34 @@ TRACE_EVENT(drv_flush,
> )
> );
>
> +TRACE_EVENT(drv_channel_switch,
> + TP_PROTO(struct ieee80211_local *local,
> + struct ieee80211_channel_switch *ch_switch),
> +
> + TP_ARGS(local, ch_switch),
> +
> + TP_STRUCT__entry(
> + LOCAL_ENTRY
> + __field(u64, timestamp)
> + __field(bool, block_tx)
> + __field(u16, freq)
> + __field(u8, count)
> + ),
> +
> + TP_fast_assign(
> + LOCAL_ASSIGN;
> + __entry->timestamp = ch_switch->timestamp;
> + __entry->block_tx = ch_switch->block_tx;
> + __entry->freq = ch_switch->channel->center_freq;
> + __entry->count = ch_switch->count;
> + ),
> +
> + TP_printk(
> + LOCAL_PR_FMT " new freq:%u count:%d",
> + LOCAL_PR_ARG, __entry->freq, __entry->count
> + )
> +);
> +
> /*
> * Tracing for API calls that drivers call.
> */
> @@ -992,6 +1020,27 @@ TRACE_EVENT(api_sta_block_awake,
> )
> );
>
> +TRACE_EVENT(api_chswitch_done,
> + TP_PROTO(struct ieee80211_sub_if_data *sdata, bool is_success),
> +
> + TP_ARGS(sdata, is_success),
> +
> + TP_STRUCT__entry(
> + VIF_ENTRY
> + __field(bool, is_success)
> + ),
> +
> + TP_fast_assign(
> + VIF_ASSIGN;
> + __entry->is_success = is_success;
> + ),
> +
> + TP_printk(
> + VIF_PR_FMT " chswitch:%d",
> + VIF_PR_ARG, __entry->is_success
> + )
> +);
> +
> /*
> * Tracing for internal functions
> * (which may also be called in response to driver calls)
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 4e73660..be9dda9 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -999,7 +999,8 @@ int ieee80211_max_network_latency(struct notifier_block *nb,
> unsigned long data, void *dummy);
> void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
> struct ieee80211_channel_sw_ie *sw_elem,
> - struct ieee80211_bss *bss);
> + struct ieee80211_bss *bss,
> + u64 timestamp);
> void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata);
> void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata);
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 358226f..19b53a8 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -340,7 +340,11 @@ static void ieee80211_chswitch_work(struct work_struct *work)
> goto out;
>
> sdata->local->oper_channel = sdata->local->csa_channel;
If the new driver callback for channel switch failed this operation
channel is still being set to the csa_channel. This *only* works
because on the channels witch done routine you write below you
overwrite the csa_channel variable to the existing operation channel.
This seem rather hackish... if the channel switch callback failed why
would we call the work to do the channel switch?
> - ieee80211_hw_config(sdata->local, IEEE80211_CONF_CHANGE_CHANNEL);
> + if (!sdata->local->ops->channel_switch) {
> + /* call "hw_config" only if doing sw channel switch */
> + ieee80211_hw_config(sdata->local,
> + IEEE80211_CONF_CHANGE_CHANNEL);
> + }
Notice how the existing implementation also addresses quiescing in the
timer, how will you address this with this new driver API?
> /* XXX: shouldn't really modify cfg80211-owned data! */
> ifmgd->associated->channel = sdata->local->oper_channel;
> @@ -352,6 +356,22 @@ static void ieee80211_chswitch_work(struct work_struct *work)
> mutex_unlock(&ifmgd->mtx);
> }
>
> +void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool is_success)
> +{
> + struct ieee80211_sub_if_data *sdata;
> + struct ieee80211_if_managed *ifmgd;
> +
> + sdata = vif_to_sdata(vif);
> + ifmgd = &sdata->u.mgd;
> +
> + trace_api_chswitch_done(sdata, is_success);
> + if (!is_success)
> + sdata->local->csa_channel = sdata->local->oper_channel;
If this routine is to be called by drivers once they complete the
channel switch operation why do we continue by queuing the channel
switch work below?
> +
> + ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
> +}
> +EXPORT_SYMBOL(ieee80211_chswitch_done);
> +
> static void ieee80211_chswitch_timer(unsigned long data)
> {
> struct ieee80211_sub_if_data *sdata =
> @@ -368,7 +388,8 @@ static void ieee80211_chswitch_timer(unsigned long data)
>
> void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
> struct ieee80211_channel_sw_ie *sw_elem,
> - struct ieee80211_bss *bss)
> + struct ieee80211_bss *bss,
> + u64 timestamp)
> {
> struct cfg80211_bss *cbss =
> container_of((void *)bss, struct cfg80211_bss, priv);
> @@ -396,6 +417,23 @@ void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
>
> sdata->local->csa_channel = new_ch;
>
> + if (sdata->local->ops->channel_switch) {
> + /* use driver's channel switch callback */
> + struct ieee80211_channel_switch ch_switch;
> + memset(&ch_switch, 0, sizeof(ch_switch));
> + ch_switch.timestamp = timestamp;
If timestamp is 0 (when the driver does not set it) then this is all
busted and I can see a few bug reports coming out due to it. These bug
reports could be avoided if you check for the timestamp to be
reasonable here and fail otherwise, in fact if the we know the channel
switch operation is busted we may just want to disassociate given the
DFS considerations are sensitive. What do you think?
> + if (sw_elem->mode) {
> + ch_switch.block_tx = true;
> + ieee80211_stop_queues_by_reason(&sdata->local->hw,
> + IEEE80211_QUEUE_STOP_REASON_CSA);
> + }
> + ch_switch.channel = new_ch;
> + ch_switch.count = sw_elem->count;
> + ifmgd->flags |= IEEE80211_STA_CSA_RECEIVED;
> + drv_channel_switch(sdata->local, &ch_switch);
> + return;
> + }
> + /* mac80211 handle channel switch */
> if (sw_elem->count <= 1) {
> ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
> } else {
> @@ -1315,7 +1353,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
> ETH_ALEN) == 0)) {
> struct ieee80211_channel_sw_ie *sw_elem =
> (struct ieee80211_channel_sw_ie *)elems->ch_switch_elem;
> - ieee80211_sta_process_chanswitch(sdata, sw_elem, bss);
> + ieee80211_sta_process_chanswitch(sdata, sw_elem,
> + bss, rx_status->mactime);
> }
> }
>
> @@ -1647,7 +1686,8 @@ static void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
>
> ieee80211_sta_process_chanswitch(sdata,
> &mgmt->u.action.u.chan_switch.sw_elem,
> - (void *)ifmgd->associated->priv);
> + (void *)ifmgd->associated->priv,
> + rx_status->mactime);
> break;
> }
> mutex_unlock(&ifmgd->mtx);
I'd appreciate more feedback on the why this is being done. Its not
clear to me how we are limited by the current implementation. If you
have a firmware API need that is different and I think that should be
made clear, but if you do need it we need to ensure both methods are
properly documented and their different use cases outlined. I also
think the way these method are split are rather hacky right now.
Luis
^ permalink raw reply
* realtek drivers
From: Xose Vazquez Perez @ 2010-05-06 21:43 UTC (permalink / raw)
To: linux-wireless
hi,
FYI realtek released new drivers recently:
-rw-rw-r-- 1 20016 20016 1862991 Mar 25 08:17 rtl8192SU_usb_linux_v2.6.0006.20100226.zip
-rw-rw-r-- 1 20016 20016 1862541 Mar 25 08:16 rtl8191SU_usb_linux_v2.6.0006.20100226.zip
-rw-rw-r-- 1 20016 20016 1862991 Mar 25 08:15 rtl8188SU_usb_linux_v2.6.0006.20100226.zip
-rw-rw-r-- 1 20016 20016 1905119 Mar 11 03:17 rtl8192se_linux_2.6.0015.0127.2010.tar.gz
-rw-rw-r-- 1 20016 20016 1846373 Feb 09 05:43 rtl8192se_linux_2.6.0014.0115.2010.tar.gz
-rw-rw-r-- 1 20016 20016 1984437 Jan 27 05:53 rtl8187L_linux_26.1039.0104.2010.release.tar.gz
-rw-rw-r-- 1 20016 20016 1983546 Jan 27 05:52 rtl8185_linux_26.1031.1207.2009.release.tar.gz
-rw-rw-r-- 1 20016 20016 1806355 Dec 22 09:50 rtl8192se_linux_2.6.0013.1204.2009.tar.gz
-rw-rw-r-- 1 20016 20016 2073232 Jun 26 2009 rtl8187L_linux_26.1038.0626.2009.zip
-rw-rw-r-- 1 20016 20016 1847342 Jun 26 2009 rtl8185_linux_26.1030.0625.2009.zip
-rw-rw-r-- 1 20016 20016 707005 Dec 21 2007 rtl8185_linux_26[1].1027.0823.2007.tar.gz
-rw-r--r-- 1 20016 20016 708559 Apr 16 2007 rtl8187_linux_26.1025.0328.2007.tar.gz
-rw-r--r-- 1 20016 20016 794171 Oct 03 2006 rtl8187_linux_26.1010.zip
-rw-r--r-- 1 20016 20016 687957 Sep 26 2006 rtl8185_linux_26.1010.0531.2006.tar.gz
-rw-r--r-- 1 20016 20016 225734 Sep 14 2006 rtl8180_linuxdrv_v15_rh73.zip
-rw-r--r-- 1 20016 20016 711675 Sep 14 2006 rtl8180_linuxdrv_v15_fedora3.zip
-rw-r--r-- 1 20016 20016 240588 Sep 14 2006 rtl8180_linuxdrv_v15_rh90.zip
-rw-r--r-- 1 20016 20016 447810 Sep 14 2006 linux26x-8187(110).zip
get them here: ftp://WebUser:fH7s5YL@66.104.77.132/cn/wlan/
--
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Ivo Van Doorn @ 2010-05-06 21:06 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005062059.08360.helmut.schaa@googlemail.com>
On Thu, May 6, 2010 at 8:59 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
>> On Thu, May 6, 2010 at 8:38 PM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>> > Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
>> >> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
>> >> <helmut.schaa@googlemail.com> wrote:
>> >> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
>> >> > used by the Ralink driver nor specified in 802.11.
>> >> >
>> >> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
>> >> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
>> >> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
>> >> > for CCK SIFS value.
>> >> >
>> >> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
>> >> > Ralink drivers).
>> >>
>> >> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
>> >> Perhaps we should remove it in there, and no longer pass it from
>> >> rt2x00lib. That way there can't be any confusion about which drivers
>> >> uses the sifs field and whcih do not.
>> >
>> > Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
>> > value, so we could just leave the define in rt2x00.h and remove the sifs value
>> > from the config_erp calback and use the define in all other places?
>>
>> Well I would still remove the define in that case. I think some of the
>> legacy drivers
>> work with different SIFS values but always accepted the value which we used in
>> the define. So I would still remove the define, and then each driver
>> is free to set
>> the value as used in the legacy drivers.
>
> Sure. No objections from my side.
I'll write a patch for this, this weekend along with some other updates. :)
Ivo
^ permalink raw reply
* [PATCH 2/2] rtl8180: add software-based support for IBSS mode
From: John W. Linville @ 2010-05-06 20:49 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Device documentation suggests that hardware support for beaconing
is available. But I implemented software-based beacon generation
as an experiment and it seems better to have that working now rather
than waiting for something better to materialize.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180.h | 8 +++
drivers/net/wireless/rtl818x/rtl8180_dev.c | 82 ++++++++++++++++++++++++----
2 files changed, 80 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180.h b/drivers/net/wireless/rtl818x/rtl8180.h
index b92d678..4baf0cf 100644
--- a/drivers/net/wireless/rtl818x/rtl8180.h
+++ b/drivers/net/wireless/rtl818x/rtl8180.h
@@ -55,6 +55,14 @@ struct rtl8180_tx_ring {
struct sk_buff_head queue;
};
+struct rtl8180_vif {
+ struct ieee80211_hw *dev;
+
+ /* beaconing */
+ struct delayed_work beacon_work;
+ bool enable_beacon;
+};
+
struct rtl8180_priv {
/* common between rtl818x drivers */
struct rtl818x_csr __iomem *map;
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index a6fb9a6..56dc816 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -663,10 +663,59 @@ static void rtl8180_stop(struct ieee80211_hw *dev)
rtl8180_free_tx_ring(dev, i);
}
+static u64 rtl8180_get_tsf(struct ieee80211_hw *dev)
+{
+ struct rtl8180_priv *priv = dev->priv;
+
+ return rtl818x_ioread32(priv, &priv->map->TSFT[0]) |
+ (u64)(rtl818x_ioread32(priv, &priv->map->TSFT[1])) << 32;
+}
+
+void rtl8180_beacon_work(struct work_struct *work)
+{
+ struct rtl8180_vif *vif_priv =
+ container_of(work, struct rtl8180_vif, beacon_work.work);
+ struct ieee80211_vif *vif =
+ container_of((void *)vif_priv, struct ieee80211_vif, drv_priv);
+ struct ieee80211_hw *dev = vif_priv->dev;
+ struct ieee80211_mgmt *mgmt;
+ struct sk_buff *skb;
+ int err = 0;
+
+ /* don't overflow the tx ring */
+ if (ieee80211_queue_stopped(dev, 0))
+ goto resched;
+
+ /* grab a fresh beacon */
+ skb = ieee80211_beacon_get(dev, vif);
+
+ /*
+ * update beacon timestamp w/ TSF value
+ * TODO: make hardware update beacon timestamp
+ */
+ mgmt = (struct ieee80211_mgmt *)skb->data;
+ mgmt->u.beacon.timestamp = cpu_to_le64(rtl8180_get_tsf(dev));
+
+ /* TODO: use actual beacon queue */
+ skb_set_queue_mapping(skb, 0);
+
+ err = rtl8180_tx(dev, skb);
+ WARN_ON(err);
+
+resched:
+ /*
+ * schedule next beacon
+ * TODO: use hardware support for beacon timing
+ */
+ schedule_delayed_work(&vif_priv->beacon_work,
+ usecs_to_jiffies(1024 * vif->bss_conf.beacon_int));
+}
+
static int rtl8180_add_interface(struct ieee80211_hw *dev,
struct ieee80211_vif *vif)
{
struct rtl8180_priv *priv = dev->priv;
+ struct rtl8180_vif *vif_priv;
/*
* We only support one active interface at a time.
@@ -676,6 +725,7 @@ static int rtl8180_add_interface(struct ieee80211_hw *dev,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ case NL80211_IFTYPE_ADHOC:
break;
default:
return -EOPNOTSUPP;
@@ -683,6 +733,12 @@ static int rtl8180_add_interface(struct ieee80211_hw *dev,
priv->vif = vif;
+ /* Initialize driver private area */
+ vif_priv = (struct rtl8180_vif *)&vif->drv_priv;
+ vif_priv->dev = dev;
+ INIT_DELAYED_WORK(&vif_priv->beacon_work, rtl8180_beacon_work);
+ vif_priv->enable_beacon = false;
+
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
rtl818x_iowrite32(priv, (__le32 __iomem *)&priv->map->MAC[0],
le32_to_cpu(*(__le32 *)vif->addr));
@@ -716,8 +772,11 @@ static void rtl8180_bss_info_changed(struct ieee80211_hw *dev,
u32 changed)
{
struct rtl8180_priv *priv = dev->priv;
+ struct rtl8180_vif *vif_priv;
int i;
+ vif_priv = (struct rtl8180_vif *)&vif->drv_priv;
+
if (changed & BSS_CHANGED_BSSID) {
for (i = 0; i < ETH_ALEN; i++)
rtl818x_iowrite8(priv, &priv->map->BSSID[i],
@@ -732,7 +791,16 @@ static void rtl8180_bss_info_changed(struct ieee80211_hw *dev,
}
if (changed & BSS_CHANGED_ERP_SLOT && priv->rf->conf_erp)
- priv->rf->conf_erp(dev, info);
+ priv->rf->conf_erp(dev, info);
+
+ if (changed & BSS_CHANGED_BEACON_ENABLED)
+ vif_priv->enable_beacon = info->enable_beacon;
+
+ if (changed & (BSS_CHANGED_BEACON_ENABLED | BSS_CHANGED_BEACON)) {
+ cancel_delayed_work_sync(&vif_priv->beacon_work);
+ if (vif_priv->enable_beacon)
+ schedule_work(&vif_priv->beacon_work.work);
+ }
}
static u64 rtl8180_prepare_multicast(struct ieee80211_hw *dev, int mc_count,
@@ -773,14 +841,6 @@ static void rtl8180_configure_filter(struct ieee80211_hw *dev,
rtl818x_iowrite32(priv, &priv->map->RX_CONF, priv->rx_conf);
}
-static u64 rtl8180_get_tsf(struct ieee80211_hw *dev)
-{
- struct rtl8180_priv *priv = dev->priv;
-
- return rtl818x_ioread32(priv, &priv->map->TSFT[0]) |
- (u64)(rtl818x_ioread32(priv, &priv->map->TSFT[1])) << 32;
-}
-
static const struct ieee80211_ops rtl8180_ops = {
.tx = rtl8180_tx,
.start = rtl8180_start,
@@ -916,7 +976,9 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
dev->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
IEEE80211_HW_RX_INCLUDES_FCS |
IEEE80211_HW_SIGNAL_UNSPEC;
- dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
+ dev->vif_data_size = sizeof(struct rtl8180_vif);
+ dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_ADHOC);
dev->queues = 1;
dev->max_signal = 65;
--
1.6.6.1
^ permalink raw reply related
* [PATCH 1/2] rtl8180: assign sequence numbers in the driver
From: John W. Linville @ 2010-05-06 20:26 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
This is a step towards support for beaconing modes of operation.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180.h | 3 +++
drivers/net/wireless/rtl818x/rtl8180_dev.c | 10 ++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180.h b/drivers/net/wireless/rtl818x/rtl8180.h
index de3844f..b92d678 100644
--- a/drivers/net/wireless/rtl818x/rtl8180.h
+++ b/drivers/net/wireless/rtl818x/rtl8180.h
@@ -78,6 +78,9 @@ struct rtl8180_priv {
u32 anaparam;
u16 rfparam;
u8 csthreshold;
+
+ /* sequence # */
+ u16 seqno;
};
void rtl8180_write_phy(struct ieee80211_hw *dev, u8 addr, u32 data);
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index a93eedc..a6fb9a6 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -234,6 +234,7 @@ static irqreturn_t rtl8180_interrupt(int irq, void *dev_id)
static int rtl8180_tx(struct ieee80211_hw *dev, struct sk_buff *skb)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct rtl8180_priv *priv = dev->priv;
struct rtl8180_tx_ring *ring;
struct rtl8180_tx_desc *entry;
@@ -285,6 +286,14 @@ static int rtl8180_tx(struct ieee80211_hw *dev, struct sk_buff *skb)
}
spin_lock_irqsave(&priv->lock, flags);
+
+ if (info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ) {
+ if (info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT)
+ priv->seqno += 0x10;
+ hdr->seq_ctrl &= cpu_to_le16(IEEE80211_SCTL_FRAG);
+ hdr->seq_ctrl |= cpu_to_le16(priv->seqno);
+ }
+
idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries;
entry = &ring->desc[idx];
@@ -299,6 +308,7 @@ static int rtl8180_tx(struct ieee80211_hw *dev, struct sk_buff *skb)
__skb_queue_tail(&ring->queue, skb);
if (ring->entries - skb_queue_len(&ring->queue) < 2)
ieee80211_stop_queue(dev, prio);
+
spin_unlock_irqrestore(&priv->lock, flags);
rtl818x_iowrite8(priv, &priv->map->TX_DMA_POLLING, (1 << (prio + 4)));
--
1.6.6.1
^ permalink raw reply related
* [PATCH] mac80211: set IEEE80211_TX_CTL_FIRST_FRAGMENT for beacons
From: John W. Linville @ 2010-05-06 18:45 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Also simplify the flags assignment into a single statement at the
end of ieee80211_beacon_get_tim.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/tx.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index f3841f4..6bd2492 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2251,8 +2251,9 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
info->control.vif = vif;
- info->flags |= IEEE80211_TX_CTL_CLEAR_PS_FILT;
- info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
+ info->flags |= (IEEE80211_TX_CTL_CLEAR_PS_FILT |
+ IEEE80211_TX_CTL_ASSIGN_SEQ |
+ IEEE80211_TX_CTL_FIRST_FRAGMENT);
out:
rcu_read_unlock();
return skb;
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Helmut Schaa @ 2010-05-06 18:59 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <m2wa32f33a41005061151h6aa62957qde225d5d8654a631@mail.gmail.com>
Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
> On Thu, May 6, 2010 at 8:38 PM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
> >> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
> >> <helmut.schaa@googlemail.com> wrote:
> >> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> >> > used by the Ralink driver nor specified in 802.11.
> >> >
> >> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> >> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> >> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> >> > for CCK SIFS value.
> >> >
> >> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> >> > Ralink drivers).
> >>
> >> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
> >> Perhaps we should remove it in there, and no longer pass it from
> >> rt2x00lib. That way there can't be any confusion about which drivers
> >> uses the sifs field and whcih do not.
> >
> > Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
> > value, so we could just leave the define in rt2x00.h and remove the sifs value
> > from the config_erp calback and use the define in all other places?
>
> Well I would still remove the define in that case. I think some of the
> legacy drivers
> work with different SIFS values but always accepted the value which we used in
> the define. So I would still remove the define, and then each driver
> is free to set
> the value as used in the legacy drivers.
Sure. No objections from my side.
Helmut
^ permalink raw reply
* Re: [PATCH 3/3] rt2x00: rt2800: use correct txop value in tx descriptor
From: Helmut Schaa @ 2010-05-06 18:57 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <4BE30B3B.2000900@gmail.com>
Am Donnerstag 06 Mai 2010 schrieb Gertjan van Wingerde:
> On 05/06/10 12:29, Helmut Schaa wrote:
[...]
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > index 1056c92..5483fec 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> > __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> > if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> > __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> > +
> > + txdesc->txop = TXOP_HTTXOP;
> > }
>
> I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time
> using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP?
>From what I saw in the ralink driver IFS_BACKOFF is only used for management frames, IFS_SIFS only
for subsequent frames in a fragment burst and IFS_HTTXOPS for "normal" data frames. But that's
just the result of a _quick_ review. So I might be wrong here as well :)
To be honest I don't really know what the device does in case IFS_HTTXOPS is set but that was
the value we've passed to the driver before ;) (==IFS_BACKOFF on all other ralink chips) and it
works quite well. I also tried IFS_BACKOFF and I wasn't able to see a difference when using
legacy (11b & 11g) rates (neither on the device itself nor with a second machine monitoring
the traffic).
But I agree that we have to dig further on when to use which value but nevertheless the patch
shouldn't cause any harm but is meant as a base for further improvements.
If you want to we can also wait with this one until we completely figured out what to do?
Helmut
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Ivo Van Doorn @ 2010-05-06 18:51 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005062038.24982.helmut.schaa@googlemail.com>
On Thu, May 6, 2010 at 8:38 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
>> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
>> > used by the Ralink driver nor specified in 802.11.
>> >
>> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
>> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
>> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
>> > for CCK SIFS value.
>> >
>> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
>> > Ralink drivers).
>>
>> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
>> Perhaps we should remove it in there, and no longer pass it from
>> rt2x00lib. That way there can't be any confusion about which drivers
>> uses the sifs field and whcih do not.
>
> Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
> value, so we could just leave the define in rt2x00.h and remove the sifs value
> from the config_erp calback and use the define in all other places?
Well I would still remove the define in that case. I think some of the
legacy drivers
work with different SIFS values but always accepted the value which we used in
the define. So I would still remove the define, and then each driver
is free to set
the value as used in the legacy drivers.
> Nevertheless, I'm not sure why the rt2800 devices don't like the 10us CCK
> SIFS value (which is defined in 802.11) but I wasn't able to get CTS to self
> working correctly with it set to 10 (the actual data frame was sent out
> way too late after the CTS frame, somtimes with delays >100us). Using the 16us
> also for CCK (as the ralink drivers do) results in perfect CTS & data frame
> timing. Maybe it's a hardware issue and the (ralink) driver just works around
> it?
Yes, I expect it to be case. This kind of odd values are used in the
legacy drivers
for other settings as well.
Ivo
^ permalink raw reply
* Re: [PATCH] iwlwifi: recalculate average tpt if not current
From: reinette chatre @ 2010-05-06 18:50 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
Adel Gadllah
In-Reply-To: <20100506182232.GB4167@tuxdriver.com>
Hi John,
On Thu, 2010-05-06 at 11:22 -0700, John W. Linville wrote:
> On Thu, May 06, 2010 at 09:11:08AM -0700, reinette chatre wrote:
> > I noticed this patch in your wireless-next-2.6 pull request. Since it is
> > addressing a system hang issue, could it perhaps be included in
> > wireless-2.6 also? I should have included the bug report reference for
> > this purpose, sorry ... it is
> > https://bugzilla.redhat.com/show_bug.cgi?id=588021
>
> I didn't send it that way because a) that code has been there for a
> really long time; and b) the reporter couldn't reliably reproduce
> the bug and therefore can't reliably test the fix. While I agree
> that the fix looks harmless, no update is zero-risk.
>
> Can you reliably hit that code? Has it been tested enough that we
> should risk holding-up 2.6.34's release for it?
Good point ... we have not seen this BUG being hit before and it seems
to have been there since 2.6.28. In addition to the report in RedHat
bugzilla there is a lkml thread that seems to be related to this code
also (http://lkml.org/lkml/2010/5/3/229 ) ... but that reporter did not
seem to test this patch and my last reply to that thread bounced to his
email address.
We thus seem to have two recent reports of users hitting the BUG, which
may mean some other recent change in driver causes this BUG to be hit,
not really just the presence of the BUG code itself.
As far as testing goes ... this patch has just been merged and will from
now on be included in our regression testing. Unfortunately this had not
been exercised much yet since I just merged.
I guess we will proceed with the "wait and see" here and forward this
patch to stable if the BUG is encountered again.
Reinette
^ permalink raw reply
* Re: [PATCH] compat-wireless: updates for orinoco
From: Luis R. Rodriguez @ 2010-05-06 18:49 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Johannes Berg, Hauke Mehrtens, linux-wireless@vger.kernel.org
In-Reply-To: <20100505222347.GC32666@tux>
On Wed, May 05, 2010 at 03:23:47PM -0700, Luis Rodriguez wrote:
> On Tue, May 04, 2010 at 11:45:03PM -0700, Johannes Berg wrote:
> > On Tue, 2010-05-04 at 16:26 -0700, Luis R. Rodriguez wrote:
> >
> > > void netdev_attach_ops(struct net_device *dev,
> > > const struct net_device_ops *ops)
> > > {
> > > #define SET_NETDEVOP(_op) (_op ? _op : NULL)
> >
> > isn't that like the dumbest macro ever?
>
> That's subjective, I am lazy.
You're right this is dumb :P
Luis
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Helmut Schaa @ 2010-05-06 18:38 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <s2ma32f33a41005061001w5e7258f0p3715ec238a00a4f4@mail.gmail.com>
Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> > used by the Ralink driver nor specified in 802.11.
> >
> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> > for CCK SIFS value.
> >
> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> > Ralink drivers).
>
> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
> Perhaps we should remove it in there, and no longer pass it from
> rt2x00lib. That way there can't be any confusion about which drivers
> uses the sifs field and whcih do not.
Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
value, so we could just leave the define in rt2x00.h and remove the sifs value
from the config_erp calback and use the define in all other places?
Nevertheless, I'm not sure why the rt2800 devices don't like the 10us CCK
SIFS value (which is defined in 802.11) but I wasn't able to get CTS to self
working correctly with it set to 10 (the actual data frame was sent out
way too late after the CTS frame, somtimes with delays >100us). Using the 16us
also for CCK (as the ralink drivers do) results in perfect CTS & data frame
timing. Maybe it's a hardware issue and the (ralink) driver just works around
it?
Helmut
^ 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