* RE: PROBLEM: brcm80211 unable to survive suspend/resume cycle
From: Arend Van Spriel @ 2011-01-12 9:26 UTC (permalink / raw)
To: Jon Masters, Brett Rudley
Cc: devel, Linux Kernel Mailing List, linux-wireless@vger.kernel.org
In-Reply-To: <1293028287.6319.171.camel@constitution.bos.jonmasters.org>
Hi Jon,
Brett delegated this problem to me and I have resolved it in the driver. I will post it to the staging-2.6 repository in coming days when stomach flu subsides. Keep your eyes on the devel archives.
Gr. AvS
|-----Original Message-----
|From: devel-bounces@linuxdriverproject.org [mailto:devel-
|bounces@linuxdriverproject.org] On Behalf Of Jon Masters
|Sent: Wednesday, December 22, 2010 3:31 PM
|To: Brett Rudley
|Cc: devel; Linux Kernel Mailing List
|Subject: RE: PROBLEM: brcm80211 unable to survive suspend/resume cycle
|
|On Mon, 2010-11-15 at 23:04 -0500, Jon Masters wrote:
|> On Tue, 2010-11-09 at 10:02 -0800, Brett Rudley wrote:
|> > Hey Jon, thanks for the heads up. I can repro and am looking into
|it.
|>
|> Did you get chance to poke much yet?
|
|Any word on this?
|
|Jon.
|
|
|_______________________________________________
|devel mailing list
|devel@linuxdriverproject.org
|http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
^ permalink raw reply
* Re: Mesh join/leave
From: Johannes Berg @ 2011-01-12 9:03 UTC (permalink / raw)
To: sbrown; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1294780828.2383.0.camel@mythtv.ewol.com>
On Tue, 2011-01-11 at 16:20 -0500, Steve Brown wrote:
> In testing this, the command "iw mesh0 mesh leave" doesn't stop
> beaconing. Beaconing continues with a null mesh id.
>
> Is this the intended behavior?
No, it's not -- what driver are you using?
johannes
^ permalink raw reply
* Re: [RFC/RFT] mac80211: Fix mixed usage of spin_lock and spin_lock_irqsave on same lock
From: Johannes Berg @ 2011-01-12 9:02 UTC (permalink / raw)
To: Larry Finger; +Cc: John W Linville, linux-wireless
In-Reply-To: <4d2d3810.F6Slpvbu6tV67Lp2%Larry.Finger@lwfinger.net>
On Tue, 2011-01-11 at 23:11 -0600, Larry Finger wrote:
> My system has logged the following locking problem:
>
> ==================================================================
> [ INFO: inconsistent lock state ]
> 2.6.37-Linus-03737-g0c21e3a-dirty #251
> ---------------------------------
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> takes:
> (&(&list->lock)->rlock#5){?.-...}, at: skb_queue_tail+0x26/0x60
> {HARDIRQ-ON-W} state was registered at:
> __lock_acquire+0xb25/0x1cc0
> lock_acquire+0x93/0x130
> _raw_spin_lock+0x2c/0x40
> ieee80211_rx_handlers+0x27/0x1c80 [mac80211]
> ieee80211_prepare_and_rx_handle+0x238/0x900 [mac80211]
> ieee80211_rx+0x31a/0x940 [mac80211]
> ieee80211_tasklet_handler+0xc1/0xd0 [mac80211]
> tasklet_action+0x73/0x120
> __do_softirq+0xce/0x200
>
> ==================================================================
>
> The reason is that ieee80211_rx_handlers() locks rx->local->rx_skb_queue.lock
> using spin_lock(), but skb_queue_tail() locks the same entity with
> spin_lock_irqsave().
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> Johannes,
>
> I think this is correct. At least the lockdep warning goes away on my
> machine.
I have to apologize -- I've sorta pushed off looking at this (my excuse
is some important iwlwifi bugs, but ...).
If I look at your original trace again, I see:
[ 25.660384] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
This is a tad confusing, because it then goes to print out something
about ieee80211_rx_handlers(), which only acquires the
local->rx_skb_queue.lock; looking further, however, the current stack
trace is ieee80211_tx_status_irqsafe() which uses only
local->skb_queue[_unreliable]. I think Stanislaw was right on (but why
didn't he offer a fix? :-) ).
While your fix certainly isn't incorrect, I believe it to be unnecessary
to disable IRQs here. The lock can only be taken with BHs disabled, but
this is in a BH or running with BHs disabled. Of course, the invocations
of skb_queue_tail() will still do IRQ locking, but I'm willing to pay
that price, for now, until somebody invents skb_queue_tail_bh() :-)
I believe the patch below should address the lockdep warning without the
IRQ disabling.
johannes
--- wireless-testing.orig/net/mac80211/main.c 2011-01-12 09:58:07.000000000 +0100
+++ wireless-testing/net/mac80211/main.c 2011-01-12 10:02:03.000000000 +0100
@@ -39,6 +39,8 @@ module_param(ieee80211_disable_40mhz_24g
MODULE_PARM_DESC(ieee80211_disable_40mhz_24ghz,
"Disable 40MHz support in the 2.4GHz band");
+static struct lock_class_key ieee80211_rx_skb_queue_class;
+
void ieee80211_configure_filter(struct ieee80211_local *local)
{
u64 mc;
@@ -569,7 +571,15 @@ struct ieee80211_hw *ieee80211_alloc_hw(
spin_lock_init(&local->filter_lock);
spin_lock_init(&local->queue_stop_reason_lock);
- skb_queue_head_init(&local->rx_skb_queue);
+ /*
+ * The rx_skb_queue is only accessed from tasklets,
+ * but other SKB queues are used from within IRQ
+ * context. Therefore, this one needs a different
+ * locking class so our direct, non-irq-safe use of
+ * the queue's lock doesn't throw lockdep warnings.
+ */
+ skb_queue_head_init_class(&local->rx_skb_queue,
+ &ieee80211_rx_skb_queue_class);
INIT_DELAYED_WORK(&local->scan_work, ieee80211_scan_work);
^ permalink raw reply
* Re: [PATCH 1/2] ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro
From: Johannes Berg @ 2011-01-12 8:47 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless, John W. Linville, Amitkumar Karwar, Kiran Divekar,
Frank Huang
In-Reply-To: <1294791265-24020-1-git-send-email-bzhao@marvell.com>
On Tue, 2011-01-11 at 16:14 -0800, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar@marvell.com>
>
> It is defined in include/linux/ieee80211.h. As per IEEE spec.
> bit6 to bit15 in block ack parameter represents buffer size.
> So the bitmask should be 0xFFC0.
Good catch, thanks.
John, can you pick this up?
Cc: stable@kernel.org
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
> ---
> include/linux/ieee80211.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index 6042228..294169e 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -959,7 +959,7 @@ struct ieee80211_ht_info {
> /* block-ack parameters */
> #define IEEE80211_ADDBA_PARAM_POLICY_MASK 0x0002
> #define IEEE80211_ADDBA_PARAM_TID_MASK 0x003C
> -#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFA0
> +#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFC0
> #define IEEE80211_DELBA_PARAM_TID_MASK 0xF000
> #define IEEE80211_DELBA_PARAM_INITIATOR_MASK 0x0800
>
^ permalink raw reply
* Regulatory Domain: User hint + Driver hint
From: Joe Hershberger @ 2011-01-12 8:07 UTC (permalink / raw)
To: linux-wireless
Hi All,
>From reading http://wireless.kernel.org/en/developers/Regulatory/processing_rules
I am under the impression that the Driver hint gives the driver an
opportunity to "lock" the card to a specific regdom based on its
EEPROM. Then any regdom set as a User hint (via "iw reg set ??" or
wpa_supplicant) would be the intersection of the Driver hint and the
User hint.
What I'm seeing from the cfg80211 dbg prints is that the User hint
simply overrides the Driver hint ("cfg80211: Regulatory domain changed
to country"). I also don't see what looks like an intersection when
comparing the resulting rules... it looks like a replacement.
Looking at the code in net/wireless/reg.c in the ignore_request
function, only if (last_request->initiator ==
NL80211_REGDOM_SET_BY_COUNTRY_IE) return REG_INTERSECT; This seems to
disagree with the document. Am I simply misinterpreting the code or
is it broken as is?
Any enlightenment would be greatly appreciated.
I'm using Kernel.org 2.6.35 with ath5k 802.11 PCI card.
Thanks,
-Joe
^ permalink raw reply
* Re: [PATCH] [RFC] ath9k: Fix reporting of RX STBC streams to userspace
From: Vasanthakumar Thiagarajan @ 2011-01-12 5:22 UTC (permalink / raw)
To: Bernhard Walle
Cc: Luis Rodriguez, Jouni Malinen, Vasanth Thiagarajan,
Senthilkumar Balasubramanian, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1294765194-30542-1-git-send-email-walle@corscience.de>
On Tue, Jan 11, 2011 at 10:29:54PM +0530, Bernhard Walle wrote:
> While the driver reports
>
> ath: TX streams 2, RX streams: 2
>
> in the kernel log (with ATH_DBG_CONFIG set in the debug module
> parameter), "iw list" only reported
>
> [...]
> Capabilities: 0x12ce
> HT20/HT40
> SM Power Save disabled
> RX HT40 SGI
> TX STBC
> RX STBC 1-streams
> [...]
>
> The driver seems to set the value as flag while the iw tool interprets
> it as number. This patch fixes that.
Nope. hw supports STBC for one Spatial stream only.
Vasanth
^ permalink raw reply
* [RFC/RFT] mac80211: Fix mixed usage of spin_lock and spin_lock_irqsave on same lock
From: Larry Finger @ 2011-01-12 5:11 UTC (permalink / raw)
To: John W Linville, Johannes Berg; +Cc: linux-wireless
My system has logged the following locking problem:
==================================================================
[ INFO: inconsistent lock state ]
2.6.37-Linus-03737-g0c21e3a-dirty #251
---------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
takes:
(&(&list->lock)->rlock#5){?.-...}, at: skb_queue_tail+0x26/0x60
{HARDIRQ-ON-W} state was registered at:
__lock_acquire+0xb25/0x1cc0
lock_acquire+0x93/0x130
_raw_spin_lock+0x2c/0x40
ieee80211_rx_handlers+0x27/0x1c80 [mac80211]
ieee80211_prepare_and_rx_handle+0x238/0x900 [mac80211]
ieee80211_rx+0x31a/0x940 [mac80211]
ieee80211_tasklet_handler+0xc1/0xd0 [mac80211]
tasklet_action+0x73/0x120
__do_softirq+0xce/0x200
==================================================================
The reason is that ieee80211_rx_handlers() locks rx->local->rx_skb_queue.lock
using spin_lock(), but skb_queue_tail() locks the same entity with
spin_lock_irqsave().
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Johannes,
I think this is correct. At least the lockdep warning goes away on my
machine.
Larry
---
Index: linux-2.6/net/mac80211/rx.c
===================================================================
--- linux-2.6.orig/net/mac80211/rx.c
+++ linux-2.6/net/mac80211/rx.c
@@ -2465,6 +2465,7 @@ static void ieee80211_rx_handlers(struct
{
ieee80211_rx_result res = RX_DROP_MONITOR;
struct sk_buff *skb;
+ unsigned long flags;
#define CALL_RXH(rxh) \
do { \
@@ -2473,14 +2474,14 @@ static void ieee80211_rx_handlers(struct
goto rxh_next; \
} while (0);
- spin_lock(&rx->local->rx_skb_queue.lock);
+ spin_lock_irqsave(&rx->local->rx_skb_queue.lock, flags);
if (rx->local->running_rx_handler)
goto unlock;
rx->local->running_rx_handler = true;
while ((skb = __skb_dequeue(&rx->local->rx_skb_queue))) {
- spin_unlock(&rx->local->rx_skb_queue.lock);
+ spin_unlock_irqrestore(&rx->local->rx_skb_queue.lock, flags);
/*
* all the other fields are valid across frames
@@ -2513,14 +2514,14 @@ static void ieee80211_rx_handlers(struct
rxh_next:
ieee80211_rx_handlers_result(rx, res);
- spin_lock(&rx->local->rx_skb_queue.lock);
+ spin_lock_irqsave(&rx->local->rx_skb_queue.lock, flags);
#undef CALL_RXH
}
rx->local->running_rx_handler = false;
unlock:
- spin_unlock(&rx->local->rx_skb_queue.lock);
+ spin_unlock_irqrestore(&rx->local->rx_skb_queue.lock, flags);
}
static void ieee80211_invoke_rx_handlers(struct ieee80211_rx_data *rx)
^ permalink raw reply
* Re: What pieces are needed for wl1271..what directories, files, configs, etc..
From: Krakowski, Oz @ 2011-01-12 2:53 UTC (permalink / raw)
To: Brzezowski, Karen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <0826983CC0CB074798C42E77D8ACD07F0683E0@pdtms1.pdt.com>
On Tue, Jan 11, 2011 at 1:41 PM, Brzezowski, Karen
<Karen.Brzezowski@pdt.com> wrote:
> ok, so far, I found the Makefile in the wl12xx directory from git clone git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git has 2.6.37-rc6
> in it. so it's the 37-rc6 kernel, correct?
Yes.
>
> Can I use this "stuff" in the 2.6.31 kernel? (I know what's said in the wiki info below..)
Yes, as long as you follow the guidelines described in the wiki page
regarding how to port the driver to older kernel versions - through
compat-wirelss and the additional patches described there.
Compat-wireless is described on the linuxwireless.org website in
length. Check it out here:
http://linuxwireless.org/en/users/Download/stable/
Regards,
Oz.
>
> I just don't know what goes where, how...
>
> :-)
> ________________________________________
> From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] on behalf of Brzezowski, Karen [Karen.Brzezowski@pdt.com]
> Sent: Tuesday, January 11, 2011 1:05 PM
> To: Krakowski, Oz
> Cc: linux-wireless@vger.kernel.org
> Subject: RE: What pieces are needed for wl1271..what directories, files, configs, etc..
>
> Hi Oz,
>
> Thank you for your response. I have been looking at that web page:
> http://linuxwireless.org/en/users/Drivers/wl12xx
>
> when i get the latest driver at
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
>
> Do I take everything that comes in this compressed file and replace it in a Linux kernel?
> Which Linux kernel is this driver code for?
>
> I'm not really sure what the compat-wireless is...we are using the Linux 2.6.31 kernel
> Do I need to get compat-wireless somehow for the 31 kernel?
>
> Then the notes say integrations needs to be gotten for SDIO, Lenient, and platform data pasing..
>
> Then the notes say I need WL127x firmware...
>
> after all that I can build the kernel?
>
> Do you have any example code that uses the interfaces for the wl1271 chip (the APIs)?
>
> I've never ported a driver in Linux before...
> I assumed all it would be is to get the driver directory corresponding to the new chip, adding or replacing it
> in the drivers directory, build it, and voila, i have a driver to test..
>
> I think I should not have assumed that, correct?
>
> ...this is why I'm confused........
> :-)
> thank you for your time!!!!!!!!!!
> Karen
>
> ________________________________________
> From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] on behalf of Krakowski, Oz [ozk@ti.com]
> Sent: Tuesday, January 11, 2011 12:13 AM
> To: Brzezowski, Karen
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: What pieces are needed for wl1271..what directories, files, configs, etc..
>
> Hi Karen,
>
> On Mon, Jan 10, 2011 at 10:44 AM, Brzezowski, Karen
> <Karen.Brzezowski@pdt.com> wrote:
>>
>> Hello all wireless gurus!!
>>
>> I've been watching the linux-wireless mailings on the wl1271...........
>>
>> I've been trying to figure out how to get the wl1271 working with
>> imx233 processor...
>>
>> I think we are moving to Linux 2.6.35 and android gingerbread (2.3)...
>>
>> I"m very confused as to what files/configs/etc..need to be grabbed to get my task going.......
>>
>> I see spi, sdio...not sure where all changes are made for the wl1271...i'm assuming
>> not just in the ...net/wireless/wl1271 directory.......... i have firmware too...........(.bins..)
>>
>> I'm quite confused about the chip and how each part will work (BT, WLAN, and FM)...
>> Do you have any documentation..(for dummies, that would be me!)
>> that would help me understand about the chip..how it communicates to the processor,
>> how it does it's job with respect to BT, WLAN, and FM, etc..
>>
>> I have NO idea where to begin.......I've been googling and reading and I have downloaded
>> your wl12xx git........
>
> If you haven't done so already, suggest you start by going through the
> following wiki page: http://linuxwireless.org/en/users/Drivers/wl12xx
> This should give you an idea of where to get the latest code, how to
> compile it to your kernel (using compat-wireless) and links to the
> relevant patches needed.
> This will get you started with WLAN.
>
>>
>> If you can help me AT ALL to get me up to speed/ to start, what i need to do to connect
>> the wl1271 to the imx233....if not imx233..that whatever you have........
>
> The wiki page does include some basic information needed in order to
> port to different hardware platforms.
>
> Regards,
> Oz.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] ath9k_hw: disable PLL / Clkreq for ASPM for AR9003
From: Luis R. Rodriguez @ 2011-01-12 1:46 UTC (permalink / raw)
To: linville
Cc: linux-wireless, Luis R. Rodriguez, stable, Jack Lee, Carl Huang,
David Quan, Nael Atallah, Sarvesh Shrivastava
This changes the PCIE PHY programming for better interoperability
with ASPM states. Without this AR9003 chipsets will hang when
using ASPM. This reproducible against an Apple Airport Extreme AP
by simply pinging it.
Cc: stable@kernel.org
Cc: Jack Lee <jack.lee@atheros.com>
Cc: Carl Huang <carl.huang@atheros.com>
Cc: David Quan <david.quan@atheros.com>
Cc: Nael Atallah <nael.atallah@atheros.com>
Cc: Sarvesh Shrivastava <sarvesh.shrivastava@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_hw.c b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
index 6137634..06fb2c8 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
@@ -146,8 +146,8 @@ static void ar9003_hw_init_mode_regs(struct ath_hw *ah)
/* Sleep Setting */
INIT_INI_ARRAY(&ah->iniPcieSerdesLowPower,
- ar9300PciePhy_clkreq_enable_L1_2p2,
- ARRAY_SIZE(ar9300PciePhy_clkreq_enable_L1_2p2),
+ ar9300PciePhy_pll_on_clkreq_disable_L1_2p2,
+ ARRAY_SIZE(ar9300PciePhy_pll_on_clkreq_disable_L1_2p2),
2);
/* Fast clock modal settings */
--
1.7.3.2.90.gd4c43
^ permalink raw reply related
* Re: ath9k_hw_check_alive routine
From: Bill Jordan @ 2011-01-12 1:37 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian
In-Reply-To: <4D2BA3CD.4010305@openwrt.org>
On Mon, Jan 10, 2011 at 7:26 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-01-10 1:23 PM, Bill Jordan wrote:
>>
>> This routine is failing a lot on my AR9160. The ((reg& 0x7E7FFFEF) ==
>> 0x00702400) test is the one that always fails. There is no debug
>> messages in this path, so it may not be obvious whether others are
>> experiencing the problem.
>>
>> This forces ath9k_tasklet to reset the hardware. If I increase the
>> count to 500, I can eliminate most of the resets, so the hardware
>> isn't really hung. However, it sometimes takes over 25 milliseconds
>> before the test condition passes.
>>
>> I don't have specs for the radio, and the numeric constants aren't
>> very useful, so I can't tell what condition we are waiting for or why.
>>
>> Can someone with a spec shed some light on this problem?
>
> I just posted a 4-patch series, the last patch of that should take care of
> this problem. Please test.
>
> - Felix
>
I tried your patch. It improved the situation, but it still reset
every couple minutes. It also seems to reset a few times in quick
succession every time it resets. What is the routine testing for? Is
this a test for a stuck transmitter? I'm in a very noisy environment,
and it could take a while to transmit.
Bill Jordan
^ permalink raw reply
* Re: [ath9k-devel] [PATCH] [RFC] ath9k: Fix reporting of RX STBC streams to userspace
From: Felix Fietkau @ 2011-01-12 1:19 UTC (permalink / raw)
To: Bernhard Walle
Cc: lrodriguez, jmalinen, vasanth, senthilkumar, linville, netdev,
ath9k-devel, linux-wireless, linux-kernel
In-Reply-To: <1294765194-30542-1-git-send-email-walle@corscience.de>
On 2011-01-11 9:59 AM, Bernhard Walle wrote:
> While the driver reports
>
> ath: TX streams 2, RX streams: 2
>
> in the kernel log (with ATH_DBG_CONFIG set in the debug module
> parameter), "iw list" only reported
>
> [...]
> Capabilities: 0x12ce
> HT20/HT40
> SM Power Save disabled
> RX HT40 SGI
> TX STBC
> RX STBC 1-streams
> [...]
>
> The driver seems to set the value as flag while the iw tool interprets
> it as number. This patch fixes that.
>
> Signed-off-by: Bernhard Walle<walle@corscience.de>
> ---
> drivers/net/wireless/ath/ath9k/init.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index 639dc93..935b6c3 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -215,17 +215,17 @@ static void setup_ht_cap(struct ath_softc *sc,
> else
> max_streams = 2;
>
> - if (AR_SREV_9280_20_OR_LATER(ah)) {
> - if (max_streams>= 2)
> - ht_info->cap |= IEEE80211_HT_CAP_TX_STBC;
> - ht_info->cap |= (1<< IEEE80211_HT_CAP_RX_STBC_SHIFT);
> - }
> -
> /* set up supported mcs set */
> memset(&ht_info->mcs, 0, sizeof(ht_info->mcs));
> tx_streams = ath9k_cmn_count_streams(common->tx_chainmask, max_streams);
> rx_streams = ath9k_cmn_count_streams(common->rx_chainmask, max_streams);
>
> + if (AR_SREV_9280_20_OR_LATER(ah)) {
> + if (max_streams>= 2)
> + ht_info->cap |= IEEE80211_HT_CAP_TX_STBC;
> + ht_info->cap |= (rx_streams<< IEEE80211_HT_CAP_RX_STBC_SHIFT);
> + }
> +
Are you sure the card can actually receive multiple streams via STBC? As
far as I know, only one stream can be received properly via STBC, more
streams have to be sent without it.
- Felix
^ permalink raw reply
* TCP connections stall when station re-associates.
From: Ben Greear @ 2011-01-12 1:02 UTC (permalink / raw)
To: NetDev, linux-wireless@vger.kernel.org
We're seeing something funny while testing ath9k and ath5k with
multiple VIFs. We are using send-to-self routing rules
and have a TCP connection going between two station interfaces
connected to the same AP. Kernel is ~2.6.37 (wireless-testing from
a few days ago, plus some local patches). We tried commercial
APs and ath9k/ath5k APs running 2.6.37 kernel and hostap with
similar results.
The problem is that when the stations loose association and
re-associate (and maybe other times as well), the TCP connections
often hang. I see buffers in the sendq in netstat, and retransmits
on the wire, but it seems to make no progress.
Here's a pair of sockets with one side in the state:
tcp 0 7312 7.7.1.54:33513 7.7.1.56:33514 ESTABLISHED
tcp 0 0 7.7.1.56:33514 7.7.1.54:33513 ESTABLISHED
Here's a brief snippet from the interface with 7.7.1.56 on it:
51.517954 7.7.1.56 -> 7.7.1.54 TCP 33514 > 33513 [PSH, ACK] Seq=64229 Ack=1 Win=63 Len=12 TSV=8209159 TSER=7621148
51.521719 7.7.1.54 -> 7.7.1.56 TCP 33513 > 33514 [ACK] Seq=13 Ack=64241 Win=377 Len=0 TSV=8209162 TSER=8209159
52.279788 7.7.1.54 -> 7.7.1.56 TCP [TCP Retransmission] 33513 > 33514 [PSH, ACK] Seq=1 Ack=64241 Win=377 Len=12 TSV=8209920 TSER=8209159
The TCP connection is trying to run at 9.6kbps, sending 1460 bytes
per 'send' call.
If I start a UDP connection on the same pair of ports it
runs fine, even while the TCP connection is hung.
I am curious if anyone has any suggestions for debugging
this further, for instance, some way to see why the
TCP connection is not making forward progress.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-01-12 0:24 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, netfilter-devel, linux-wireless, linux-kernel
Mostly driver stuff (as usual), a TCP bind fix, some checksum
offloading cures, and random other small bits all over.
1) Fix signedness bugs in phonet, from Dan Carpenter.
2) Sequence number checking fixes in DCCP from Samuel Jero and
Gerrit Renker.
3) Support both ports of FEC ethernet device properly, from
Shawn Guo.
4) Memory leak fix in hamradio and ATM ambassador driver from Jesper
Juhl.
5) MSI interrupt and statistic handling fixes in bnx2x from Vladislav
Zolotarov and Eilon Greenstein.
6) Autonegotiation and VLAN fixes in sky2 from Stephen Hemminger.
7) Power management fixes in forcedeth from Rafael J. Wysocki.
8) Fix handling of NLM_F_ROOT | NLM_F_MATCH (can be mistaken as
a NLM_F_DUMP request) in genetlink. From Jan Engelhardt.
9) Kernel doc fixes in net/sock.h and net/core/filter.c from Randy
Dunlap
10) Do PHY init, and thus firmware request, at ->open() time to
workaround bootup 60 second delay when r8169 is built statically
into the kernel. From Francois Romieu.
11) Checksumming offload flags are handled improperly, in particular
when VLAN's are nested. From Jesse Gross.
12) Various Intel wired driver fixes from Bruce Allan, Jeff Kirsher,
Dirk Brandewie, Yi Zou, and Alexander Duyck.
13) Software interrupts are disabled way too long when reading counters
(for "iptables -L" output, for example). Fix from Eric Dumazet.
14) bfin_mac driver has to disable checksum offloading when a writeback
cache is in use, since corrupt packets can result, fix from
Sonic Zhang.
15) Firmware version detection and ethtool diag dixes in qlcnic from
Amit Kumar Salecha and Sony Chacko.
16) Mailbox register coherency, and ->open() failure unwinding fixes
in cxgb4vf from Casey Leedom.
17) On user copy failure, we erroneously leave the connection request
parameter size set, in CAIF protocol. Fix from Dan Rosenberg.
18) MLX4 driver needs to be able to allocate different numbers of
TX vs. RX queues, add a helper for that and use it. From Tom
Herbert.
19) Only HTB scheduler handles packet counting in statistics properly
wrt. segmented SKBs. Fix this by creating a helper function and
using it everywhere. From Eric Dumazet.
20) Firewire needs to be able to invalidate specific ARP entries since
it uses ARP to discover private info about firewiare network nodes.
From Maxim Levitsky.
21) IPV6 not handled properly in CAIF, fix from Sjur Braendeland and
Kumar Sanghvi.
22) Firmware parsing function in r8169 needs some minor tweaks, from
Hayes Wang.
23) TCP binding bug fix from Eric Dumazet.
24) ehea RX ring initialization fix on device up from Breno Leitao.
25) AUTH truncation bug fixes in IPSEC from Nicolas Dichtel.
26) AH protocol header parsing needs to reload pointers after
skb COW, also from Nicolas Dichtel.
27) Fix netfilter conntrack race between table dumping and destroy of
entries, from Stephen Hemminger.
28) RCU annotation addition to bridge netfilter broke broute table,
fix from Florian Westphal.
Please pull, thanks a lot!
The following changes since commit 0c21e3aaf6ae85bee804a325aa29c325209180fd:
Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/hch/hfsplus (2011-01-07 17:16:27 -0800)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alexander Duyck (3):
ixgbe: cleanup flow director hash computation to improve performance
ixgbe: further flow director performance optimizations
ixgbe: update ntuple filter configuration
Breno Leitao (1):
ehea: Increase the skb array usage
Bruce Allan (6):
e1000e: cleanup variables set but not used
e1000e: convert calls of ops.[read|write]_reg to e1e_[r|w]phy
e1000e: properly bounds-check string functions
e1000e: use either_crc_le() rather than re-write it
e1000e: power off PHY after reset when interface is down
e1000e: add custom set_d[0|3]_lplu_state function pointer for 82574
Casey Leedom (2):
cxgb4vf: fix mailbox data/control coherency domain race
cxgb4vf: recover from failure in cxgb4vf_open()
Changli Gao (1):
net: ppp: use {get,put}_unaligned_be{16,32}
Dan Carpenter (1):
phonet: some signedness bugs
Dan Rosenberg (1):
caif: don't set connection request param size before copying data
Dang Hongwu (1):
ah: reload pointers to skb data after calling skb_cow_data()
David S. Miller (2):
Merge branch 'dccp' of git://eden-feed.erg.abdn.ac.uk/net-next-2.6
Merge branch 'master' of git://1984.lsi.us.es/net-2.6
Dirk Brandewie (1):
e1000: Add support for the CE4100 reference platform
Eric Dumazet (3):
netfilter: x_tables: dont block BH while reading counters
net_sched: factorize qdisc stats handling
tcp: disallow bind() to reuse addr/port
Florian Westphal (1):
netfilter: ebtables: make broute table work again
Gerrit Renker (1):
dccp: make upper bound for seq_window consistent on 32/64 bit
Jan Engelhardt (1):
netlink: test for all flags of the NLM_F_DUMP composite
Jesper Juhl (2):
hamradio: Resolve memory leak due to missing firmware release in add_mcs()
Madge Ambassador ATM Adapter driver: Always release_firmware() in ucode_init() and don't leak memory.
Jesse Gross (6):
net offloading: Accept NETIF_F_HW_CSUM for all protocols.
net offloading: Generalize netif_get_vlan_features().
net offloading: Pass features into netif_needs_gso().
net offloading: Convert dev_gso_segment() to use precomputed features.
net offloading: Convert skb_need_linearize() to use precomputed features.
net offloading: Convert checksums to use centrally computed features.
Ken Kawasaki (1):
pcnet_cs: add new_id
Kumar Sanghvi (1):
CAIF: Fix IPv6 support in receive path for GPRS/3G
Maxim Levitsky (1):
arp: allow to invalidate specific ARP entries
Mike Frysinger (4):
netdev: bfin_mac: clean up printk messages
netdev: bfin_mac: mark setup_system_regs as static
netdev: bfin_mac: drop unused Mac data
netdev: bfin_mac: let boards set vlan masks
Nicolas Dichtel (2):
xfrm: check trunc_len in XFRMA_ALG_AUTH_TRUNC
ah: update maximum truncated ICV length
Rafael J. Wysocki (1):
forcedeth: Do not use legacy PCI power management
Randy Dunlap (2):
net/sock.h: make some fields private to fix kernel-doc warning(s)
net: fix kernel-doc warning in core/filter.c
Samuel Jero (2):
dccp: fix return value for sequence-invalid packets
dccp: fix bug in updating the GSR
Shawn Guo (6):
net/fec: fix MMFR_OP type in fec_enet_mdio_write
net/fec: remove the use of "index" which is legacy
net/fec: add mac field into platform data and consolidate fec_get_mac
net/fec: improve pm for better suspend/resume
net/fec: add dual fec support for mx28
net/fec: remove config FEC2 as it's used nowhere
Sonic Zhang (1):
netdev: bfin_mac: disable hardware checksum if writeback cache is enabled
Sony Chacko (1):
qlcnic: fix ethtool diagnostics test
Stephen Hemminger (3):
sky2: fix limited auto negotiation
sky2: convert to new VLAN model (v0.2)
netfilter: fix race in conntrack between dump_table and destroy
Tom Herbert (2):
net: Add alloc_netdev_mqs function
mlx4: Call alloc_etherdev to allocate RX and TX queues
Vladislav Zolotarov (4):
bnx2x: Don't prevent RSS configuration in INT#x and MSI interrupt modes.
bnx2x: registers dump fixes
bnx2x: Move to D0 before clearing MSI/MSI-X configuration.
bnx2x: Fix the race on bp->stats_pending.
Yi Zou (1):
ixgbe: make sure per Rx queue is disabled before unmapping the receive buffer
amit salecha (2):
qlcnic: fix flash fw version read
qlcnic: change module parameter permissions
françois romieu (1):
r8169: delay phy init until device opens.
hayeswang (1):
net/r8169: Update the function of parsing firmware
Documentation/networking/dccp.txt | 1 +
drivers/atm/ambassador.c | 19 +-
drivers/net/Kconfig | 9 +-
drivers/net/bfin_mac.c | 74 ++--
drivers/net/bfin_mac.h | 11 +-
drivers/net/bnx2x/bnx2x.h | 1 +
drivers/net/bnx2x/bnx2x_dump.h | 988 +++++++++++++++++++--------------
drivers/net/bnx2x/bnx2x_ethtool.c | 22 +-
drivers/net/bnx2x/bnx2x_init.h | 220 ++++++++
drivers/net/bnx2x/bnx2x_main.c | 70 +--
drivers/net/bnx2x/bnx2x_reg.h | 74 +++
drivers/net/bnx2x/bnx2x_stats.c | 5 +
drivers/net/cxgb4vf/cxgb4vf_main.c | 15 +-
drivers/net/cxgb4vf/t4vf_hw.c | 11 +
drivers/net/e1000/e1000_hw.c | 328 +++++++++---
drivers/net/e1000/e1000_hw.h | 59 ++-
drivers/net/e1000/e1000_main.c | 35 ++
drivers/net/e1000/e1000_osdep.h | 19 +-
drivers/net/e1000e/82571.c | 77 +++-
drivers/net/e1000e/e1000.h | 3 +
drivers/net/e1000e/es2lan.c | 4 +-
drivers/net/e1000e/ethtool.c | 54 ++-
drivers/net/e1000e/hw.h | 1 +
drivers/net/e1000e/ich8lan.c | 77 +--
drivers/net/e1000e/lib.c | 3 +-
drivers/net/e1000e/netdev.c | 53 ++-
drivers/net/e1000e/phy.c | 40 +-
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 6 +-
drivers/net/fec.c | 248 ++++++---
drivers/net/fec.h | 5 +-
drivers/net/forcedeth.c | 34 +-
drivers/net/hamradio/yam.c | 4 +-
drivers/net/ixgbe/ixgbe.h | 21 +-
drivers/net/ixgbe/ixgbe_82599.c | 749 ++++++++++----------------
drivers/net/ixgbe/ixgbe_ethtool.c | 142 ++++--
drivers/net/ixgbe/ixgbe_main.c | 169 +++++--
drivers/net/ixgbe/ixgbe_type.h | 91 ++--
drivers/net/mlx4/en_netdev.c | 3 +-
drivers/net/pcmcia/pcnet_cs.c | 1 +
drivers/net/ppp_async.c | 10 +-
drivers/net/ppp_deflate.c | 9 +-
drivers/net/ppp_generic.c | 9 +-
drivers/net/ppp_mppe.c | 7 +-
drivers/net/ppp_synctty.c | 3 +-
drivers/net/qlcnic/qlcnic.h | 24 +-
drivers/net/qlcnic/qlcnic_ethtool.c | 2 +-
drivers/net/qlcnic/qlcnic_init.c | 63 +++-
drivers/net/qlcnic/qlcnic_main.c | 10 +-
drivers/net/r8169.c | 143 +++++-
drivers/net/sky2.c | 143 +++---
drivers/net/sky2.h | 6 +-
drivers/net/xen-netfront.c | 2 +-
include/linux/bfin_mac.h | 1 +
include/linux/etherdevice.h | 4 +-
include/linux/fec.h | 3 +
include/linux/if_bridge.h | 2 +-
include/linux/netdevice.h | 24 +-
include/linux/netfilter/x_tables.h | 10 +-
include/net/ah.h | 2 +-
include/net/arp.h | 1 +
include/net/phonet/phonet.h | 4 +-
include/net/sch_generic.h | 20 +-
include/net/sock.h | 4 +
net/caif/caif_socket.c | 2 +-
net/caif/chnl_net.c | 18 +-
net/core/dev.c | 149 +++---
net/core/filter.c | 2 +-
net/core/rtnetlink.c | 2 +-
net/dccp/dccp.h | 3 +-
net/dccp/input.c | 2 +-
net/dccp/sysctl.c | 4 +-
net/ethernet/eth.c | 12 +-
net/ipv4/ah4.c | 7 +-
net/ipv4/arp.c | 29 +-
net/ipv4/inet_connection_sock.c | 5 +-
net/ipv4/inet_diag.c | 2 +-
net/ipv4/netfilter/arp_tables.c | 45 +--
net/ipv4/netfilter/ip_tables.c | 45 +--
net/ipv6/ah6.c | 8 +-
net/ipv6/inet6_connection_sock.c | 2 +-
net/ipv6/netfilter/ip6_tables.c | 45 +--
net/netfilter/nf_conntrack_netlink.c | 18 +-
net/netfilter/x_tables.c | 3 +-
net/netlink/genetlink.c | 2 +-
net/phonet/af_phonet.c | 6 +-
net/sched/act_csum.c | 3 +-
net/sched/act_ipt.c | 3 +-
net/sched/act_mirred.c | 3 +-
net/sched/act_nat.c | 3 +-
net/sched/act_pedit.c | 3 +-
net/sched/act_police.c | 3 +-
net/sched/act_simple.c | 3 +-
net/sched/act_skbedit.c | 3 +-
net/sched/sch_atm.c | 6 +-
net/sched/sch_cbq.c | 6 +-
net/sched/sch_drr.c | 8 +-
net/sched/sch_dsmark.c | 3 +-
net/sched/sch_hfsc.c | 6 +-
net/sched/sch_htb.c | 17 +-
net/sched/sch_ingress.c | 3 +-
net/sched/sch_multiq.c | 3 +-
net/sched/sch_netem.c | 6 +-
net/sched/sch_prio.c | 3 +-
net/sched/sch_red.c | 3 +-
net/sched/sch_sfq.c | 3 +-
net/sched/sch_tbf.c | 3 +-
net/sched/sch_teql.c | 3 +-
net/xfrm/xfrm_user.c | 6 +-
109 files changed, 2901 insertions(+), 1867 deletions(-)
^ permalink raw reply
* [PATCH 1/2] ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro
From: Bing Zhao @ 2011-01-12 0:14 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Johannes Berg, Amitkumar Karwar, Kiran Divekar,
Frank Huang, Bing Zhao
From: Amitkumar Karwar <akarwar@marvell.com>
It is defined in include/linux/ieee80211.h. As per IEEE spec.
bit6 to bit15 in block ack parameter represents buffer size.
So the bitmask should be 0xFFC0.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
include/linux/ieee80211.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 6042228..294169e 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -959,7 +959,7 @@ struct ieee80211_ht_info {
/* block-ack parameters */
#define IEEE80211_ADDBA_PARAM_POLICY_MASK 0x0002
#define IEEE80211_ADDBA_PARAM_TID_MASK 0x003C
-#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFA0
+#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFC0
#define IEEE80211_DELBA_PARAM_TID_MASK 0xF000
#define IEEE80211_DELBA_PARAM_INITIATOR_MASK 0x0800
--
1.7.0.2
^ permalink raw reply related
* [PATCH 2/2] mwifiex: remove some crypto definitions
From: Bing Zhao @ 2011-01-12 0:14 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Johannes Berg, Amitkumar Karwar, Kiran Divekar,
Frank Huang, Bing Zhao
In-Reply-To: <1294791265-24020-1-git-send-email-bzhao@marvell.com>
From: Amitkumar Karwar <akarwar@marvell.com>
Use corresponding macros defined in include/linux/ieee80211.h
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/11n.c | 6 +++---
drivers/net/wireless/mwifiex/11n_rxreorder.c | 16 ++++++++--------
drivers/net/wireless/mwifiex/11n_rxreorder.h | 7 -------
drivers/net/wireless/mwifiex/fw.h | 5 +----
drivers/net/wireless/mwifiex/ioctl.h | 6 ++----
drivers/net/wireless/mwifiex/main.h | 14 --------------
drivers/net/wireless/mwifiex/sta_cmd.c | 19 ++++++-------------
drivers/net/wireless/mwifiex/sta_ioctl.c | 2 +-
8 files changed, 21 insertions(+), 54 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/11n.c b/drivers/net/wireless/mwifiex/11n.c
index e4a0314..b1fd5a9 100644
--- a/drivers/net/wireless/mwifiex/11n.c
+++ b/drivers/net/wireless/mwifiex/11n.c
@@ -624,7 +624,7 @@ mwifiex_ret_11n_addba_req(struct mwifiex_private *priv,
& SSN_MASK);
tid = (le16_to_cpu(add_ba_rsp->block_ack_param_set)
- & BLOCKACKPARAM_TID_MASK)
+ & IEEE80211_ADDBA_PARAM_TID_MASK)
>> BLOCKACKPARAM_TID_POS;
if (le16_to_cpu(add_ba_rsp->status_code) == BA_RESULT_SUCCESS) {
tx_ba_tbl = mwifiex_11n_get_tx_ba_stream_tbl(priv,
@@ -1329,9 +1329,9 @@ mwifiex_send_delba(struct mwifiex_private *priv, int tid, u8 *peer_mac,
del_ba_param_set = le16_to_cpu(delba.del_ba_param_set);
if (initiator)
- DELBA_INITIATOR(del_ba_param_set);
+ del_ba_param_set |= IEEE80211_DELBA_PARAM_INITIATOR_MASK;
else
- DELBA_RECIPIENT(del_ba_param_set);
+ del_ba_param_set &= ~IEEE80211_DELBA_PARAM_INITIATOR_MASK;
memcpy(&delba.peer_mac_addr, peer_mac, MWIFIEX_MAC_ADDR_LENGTH);
diff --git a/drivers/net/wireless/mwifiex/11n_rxreorder.c b/drivers/net/wireless/mwifiex/11n_rxreorder.c
index dcfcb99..e783a2e 100644
--- a/drivers/net/wireless/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/mwifiex/11n_rxreorder.c
@@ -415,21 +415,21 @@ mwifiex_cmd_11n_addba_rsp_gen(struct mwifiex_private *priv,
add_ba_rsp->ssn = cmd_addba_req->ssn;
block_ack_param_set = le16_to_cpu(cmd_addba_req->block_ack_param_set);
- tid = (block_ack_param_set & BLOCKACKPARAM_TID_MASK)
+ tid = (block_ack_param_set & IEEE80211_ADDBA_PARAM_TID_MASK)
>> BLOCKACKPARAM_TID_POS;
if (priv->addba_reject[tid])
add_ba_rsp->status_code =
- cpu_to_le16(ADDBA_RSP_STATUS_DECLINED);
+ cpu_to_le16(WLAN_STATUS_REQUEST_DECLINED);
else
add_ba_rsp->status_code = cpu_to_le16(ADDBA_RSP_STATUS_ACCEPT);
- block_ack_param_set &= ~BLOCKACKPARAM_WINSIZE_MASK;
+ block_ack_param_set &= ~IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK;
/* We donot support AMSDU inside AMPDU, hence reset the bit */
block_ack_param_set &= ~BLOCKACKPARAM_AMSDU_SUPP_MASK;
block_ack_param_set |= (priv->add_ba_param.rx_win_size <<
BLOCKACKPARAM_WINSIZE_POS);
add_ba_rsp->block_ack_param_set = cpu_to_le16(block_ack_param_set);
win_size = (le16_to_cpu(add_ba_rsp->block_ack_param_set)
- & BLOCKACKPARAM_WINSIZE_MASK)
+ & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK)
>> BLOCKACKPARAM_WINSIZE_POS;
cmd_addba_req->block_ack_param_set = cpu_to_le16(block_ack_param_set);
@@ -668,15 +668,15 @@ mwifiex_ret_11n_addba_resp(struct mwifiex_private *priv,
block_ack_param_set = le16_to_cpu(add_ba_rsp->block_ack_param_set);
- tid = (block_ack_param_set & BLOCKACKPARAM_TID_MASK)
+ tid = (block_ack_param_set & IEEE80211_ADDBA_PARAM_TID_MASK)
>> BLOCKACKPARAM_TID_POS;
/*
* Check if we had rejected the ADDBA, if yes then do not create
* the stream
*/
if (le16_to_cpu(add_ba_rsp->status_code) == BA_RESULT_SUCCESS) {
- win_size =
- (block_ack_param_set & BLOCKACKPARAM_WINSIZE_MASK)
+ win_size = (block_ack_param_set &
+ IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK)
>> BLOCKACKPARAM_WINSIZE_POS;
PRINTM(MCMND,
@@ -733,7 +733,7 @@ mwifiex_11n_ba_stream_timeout(struct mwifiex_private *priv,
cpu_to_le16((u16) event->tid << DELBA_TID_POS);
delba.del_ba_param_set |= cpu_to_le16(
(u16) event->origninator << DELBA_INITIATOR_POS);
- delba.reason_code = cpu_to_le16(REASON_CODE_STA_TIMEOUT);
+ delba.reason_code = cpu_to_le16(WLAN_REASON_QSTA_TIMEOUT);
mwifiex_prepare_cmd(priv, HostCmd_CMD_11N_DELBA, 0, 0, NULL, &delba);
LEAVE();
diff --git a/drivers/net/wireless/mwifiex/11n_rxreorder.h b/drivers/net/wireless/mwifiex/11n_rxreorder.h
index e9b82cd..fb5c695 100644
--- a/drivers/net/wireless/mwifiex/11n_rxreorder.h
+++ b/drivers/net/wireless/mwifiex/11n_rxreorder.h
@@ -26,22 +26,15 @@
#define MAX_TID_VALUE (2 << 11)
#define TWOPOW11 (2 << 10)
-#define BLOCKACKPARAM_TID_MASK 0x3C
#define BLOCKACKPARAM_TID_POS 2
-#define BLOCKACKPARAM_WINSIZE_MASK 0xffc0
#define BLOCKACKPARAM_AMSDU_SUPP_MASK 0x1
#define BLOCKACKPARAM_WINSIZE_POS 6
#define DELBA_TID_POS 12
#define DELBA_INITIATOR_POS 11
-#define REASON_CODE_STA_DONT_WANT 37
-#define REASON_CODE_STA_TIMEOUT 39
#define TYPE_DELBA_SENT 1
#define TYPE_DELBA_RECEIVE 2
-#define DELBA_INITIATOR(paramset) (paramset = (paramset | (1 << 11)))
-#define DELBA_RECIPIENT(paramset) (paramset = (paramset & ~(1 << 11)))
#define IMMEDIATE_BLOCK_ACK 0x2
-#define ADDBA_RSP_STATUS_DECLINED 37
#define ADDBA_RSP_STATUS_REJECT 1
#define ADDBA_RSP_STATUS_ACCEPT 0
diff --git a/drivers/net/wireless/mwifiex/fw.h b/drivers/net/wireless/mwifiex/fw.h
index d2c39c7..32652a2 100644
--- a/drivers/net/wireless/mwifiex/fw.h
+++ b/drivers/net/wireless/mwifiex/fw.h
@@ -93,9 +93,6 @@ enum KEY_INFO_AES {
KEY_INFO_AES_ENABLED = 0x04
};
-#define WPA_AES_KEY_LEN 16
-#define WPA_TKIP_KEY_LEN 32
-
#define WAPI_KEY_LEN 50
enum KEY_INFO_WAPI {
@@ -468,7 +465,7 @@ struct mwifiex_event_wep_icv_err {
u8 src_mac_addr[MWIFIEX_MAC_ADDR_LENGTH];
u8 wep_key_index;
u8 wep_key_length;
- u8 key[MAX_WEP_KEY_SIZE];
+ u8 key[WLAN_KEY_LEN_WEP104];
};
struct mwifiex_802_11_fixed_ies {
diff --git a/drivers/net/wireless/mwifiex/ioctl.h b/drivers/net/wireless/mwifiex/ioctl.h
index 5ed613d..f71a09c 100644
--- a/drivers/net/wireless/mwifiex/ioctl.h
+++ b/drivers/net/wireless/mwifiex/ioctl.h
@@ -448,9 +448,7 @@ enum {
#define MWIFIEX_KEY_INDEX_UNICAST 0x40000000
#define MWIFIEX_MAX_KEY_LENGTH 32
-#define PN_SIZE 16
-#define MAX_WEP_KEY_SIZE 13
-#define MIN_WEP_KEY_SIZE 5
+#define WAPI_RXPN_LEN 16
#define MWIFIEX_MIN_PASSPHRASE_LENGTH 8
#define MWIFIEX_MAX_PASSPHRASE_LENGTH 63
#define MWIFIEX_MAX_PMK_LENGTH 32
@@ -463,7 +461,7 @@ struct mwifiex_ds_encrypt_key {
u8 key_material[MWIFIEX_MAX_KEY_LENGTH];
u8 mac_addr[MWIFIEX_MAC_ADDR_LENGTH];
u32 is_wapi_key;
- u8 pn[PN_SIZE];
+ u8 wapi_rxpn[WAPI_RXPN_LEN];
};
struct mwifiex_passphrase {
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 5b1d557..eb17ced 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -137,20 +137,6 @@ struct mwifiex_drv_mode {
#define MWIFIEX_MIN_SSID_LENGTH 1
-#define MWIFIEX_KEY_INDEX_UNICAST 0x40000000
-
-#define MWIFIEX_MAX_KEY_LENGTH 32
-
-#define MWIFIEX_MIN_PASSPHRASE_LENGTH 8
-
-#define MWIFIEX_MAX_PASSPHRASE_LENGTH 63
-
-#define MWIFIEX_MAX_PMK_LENGTH 32
-
-#define MAX_WEP_KEY_SIZE 13
-
-#define MIN_WEP_KEY_SIZE 5
-
#define MAX_CHANNEL_BAND_BG 14
#define MAX_FREQUENCY_BAND_BG 2484
diff --git a/drivers/net/wireless/mwifiex/sta_cmd.c b/drivers/net/wireless/mwifiex/sta_cmd.c
index 9a87a2a..4d9abb9 100644
--- a/drivers/net/wireless/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/mwifiex/sta_cmd.c
@@ -539,9 +539,7 @@ mwifiex_cmd_802_11_deauthenticate(struct mwifiex_private *priv,
deauth->mac_addr[3], deauth->mac_addr[4],
deauth->mac_addr[5]);
-/** Reason code 3 = Station is leaving */
-#define REASON_CODE_STA_LEAVING 3
- deauth->reason_code = cpu_to_le16(REASON_CODE_STA_LEAVING);
+ deauth->reason_code = cpu_to_le16(WLAN_REASON_DEAUTH_LEAVING);
LEAVE();
return MWIFIEX_STATUS_SUCCESS;
@@ -567,11 +565,6 @@ mwifiex_cmd_802_11_ad_hoc_stop(struct mwifiex_private *priv,
return MWIFIEX_STATUS_SUCCESS;
}
-/** Length of WEP 40 bit key */
-#define WEP_40_BIT_LEN 5
-/** Length of WEP 104 bit key */
-#define WEP_104_BIT_LEN 13
-
/*
* This function sets WEP key(s) to key parameter TLV(s).
*
@@ -591,8 +584,8 @@ mwifiex_set_keyparamset_wep(struct mwifiex_private *priv,
/* Multi-key_param_set TLV is supported */
for (i = 0; i < NUM_WEP_KEYS; i++) {
- if ((priv->wep_key[i].key_length == WEP_40_BIT_LEN) ||
- (priv->wep_key[i].key_length == WEP_104_BIT_LEN)) {
+ if ((priv->wep_key[i].key_length == WLAN_KEY_LEN_WEP40) ||
+ (priv->wep_key[i].key_length == WLAN_KEY_LEN_WEP104)) {
key_param_set->type =
cpu_to_le16(TLV_TYPE_KEY_MATERIAL);
/** Key_param_set WEP fixed length */
@@ -735,7 +728,7 @@ mwifiex_cmd_802_11_key_material(struct mwifiex_private *priv,
enc_key->key_material,
enc_key->key_len);
memcpy(&key_material->key_param_set.key[2 + enc_key->key_len],
- enc_key->pn, PN_SIZE);
+ enc_key->wapi_rxpn, WAPI_RXPN_LEN);
key_material->key_param_set.length =
cpu_to_le16(WAPI_KEY_LEN + KEYPARAMSET_FIXED_LEN);
@@ -747,7 +740,7 @@ mwifiex_cmd_802_11_key_material(struct mwifiex_private *priv,
sizeof(key_material->action) + S_DS_GEN);
goto done;
}
- if (enc_key->key_len == WPA_AES_KEY_LEN) {
+ if (enc_key->key_len == WLAN_KEY_LEN_CCMP) {
PRINTM(MCMND, "WPA_AES\n");
key_material->key_param_set.key_type_id =
cpu_to_le16(KEY_TYPE_ID_AES);
@@ -765,7 +758,7 @@ mwifiex_cmd_802_11_key_material(struct mwifiex_private *priv,
else /* AES group key: multicast */
key_material->key_param_set.key_info |=
cpu_to_le16(KEY_INFO_AES_MCAST);
- } else if (enc_key->key_len == WPA_TKIP_KEY_LEN) {
+ } else if (enc_key->key_len == WLAN_KEY_LEN_TKIP) {
PRINTM(MCMND, "WPA_TKIP\n");
key_material->key_param_set.key_type_id =
cpu_to_le16(KEY_TYPE_ID_TKIP);
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c b/drivers/net/wireless/mwifiex/sta_ioctl.c
index 35df4c9..04a6154 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -3611,7 +3611,7 @@ mwifiex_sec_ioctl_encrypt_key(struct mwifiex_adapter *adapter,
if (sec->param.encrypt_key.is_wapi_key)
status = mwifiex_sec_ioctl_set_wapi_key(adapter,
ioctl_req);
- else if (sec->param.encrypt_key.key_len > MAX_WEP_KEY_SIZE)
+ else if (sec->param.encrypt_key.key_len > WLAN_KEY_LEN_WEP104)
status = mwifiex_sec_ioctl_set_wpa_key(adapter,
ioctl_req);
else
--
1.7.0.2
^ permalink raw reply related
* Re: [stable] [PATCH 2.6.35] mac80211: fix hard lockup in sta_addba_resp_timer_expired
From: Andi Kleen @ 2011-01-11 23:38 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Andi Kleen, stable, Kyle McMartin, kernel, linux-wireless,
Johannes Berg
In-Reply-To: <20110110123808.GA3683@redhat.com>
On Mon, Jan 10, 2011 at 01:38:21PM +0100, Stanislaw Gruszka wrote:
> Problem is 2.6.35 specific, bug was introduced in backport
> of upstream 44271488b91c9eecf249e075a1805dd887e222d2 commit.
>
> We can not call del_timer_sync(addba_resp_timer) from
> ___ieee80211_stop_tx_ba_session(), as this function can be called from
> that timer callback. To fix, simply use not synchronous del_timer().
Applied to the 2.6.35.11 queue thanks.
-Andi
^ permalink raw reply
* Re: 5GHz 802.11n USB Adapter
From: Kalle Valo @ 2011-01-11 22:10 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Helmut Schaa, Jason Andryuk, linux-wireless, Gertjan van Wingerde,
Johannes Stezenbach
In-Reply-To: <AANLkTi=n49bXON7i9ec_UGLwMpr2+963CGOudkMphnMt@mail.gmail.com>
Ivo Van Doorn <ivdoorn@gmail.com> writes:
>> That would be the best option, but in the mean time we should disable
>> AP mode.
>
> Ok, but please don't restrict only to rt2800usb then. Basically
> _all_ rt2x00 USB drivers are not functioning. Also I assume it means
> that also Mesh mode, Secondary, and Ad-hoc should also be disabled?
AFAIK Mesh and Ad-Hoc don't use power save mode so not not being able
to buffer bc/mc shouldn't be a problem.
--
Kalle Valo
^ permalink raw reply
* Mesh join/leave
From: Steve Brown @ 2011-01-11 21:20 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Johannes Berg
In testing this, the command "iw mesh0 mesh leave" doesn't stop
beaconing. Beaconing continues with a null mesh id.
Is this the intended behavior?
Steve
iw version 0.9.21-35-gba292ae
wireless-testing at commit 315f05c479f8e98e2df0e23a1bc0829b7e374fe9
^ permalink raw reply
* Re: Locking problem reported for mainline
From: Larry Finger @ 2011-01-11 20:52 UTC (permalink / raw)
To: Bob Copeland; +Cc: Christian Lamparter, wireless
In-Reply-To: <AANLkTikPoEjHRXjqVkSopCjUcyp7AauvFAfaVN_8T0qG@mail.gmail.com>
On 01/11/2011 01:45 PM, Bob Copeland wrote:
> On Tue, Jan 11, 2011 at 11:31 AM, Larry Finger
> <Larry.Finger@lwfinger.net> wrote:
>> Is there a document that explains what the meaning of these semantics?
>>
>> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
>> kdostartupconfi/3502 [HC1[1]:SC0[0]:HE0:SE1] takes:
>> (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812995c6>]
>> skb_queue_tail+0x26/0x60
>> {HARDIRQ-ON-W} state was registered at:
>
> I'm not sure about all the HC1[1]:SC0[0] etc stuff, but check out
> Documentation/lockdep-design.txt for the basics.
That one I had read.
> In this case, someone took a lock with interrupts enabled (HARDIRQ-ON-W)
> while someone else took it in a hard IRQ context (IN-HARDIRQ-W) where
> they are normally disabled. The problem of course is:
>
> cpu0:
> spin_lock(&foo);
> do some stuff protected by foo;
>
> ----> interrupt happens here
> spin_lock(&foo); /* darn, deadlock! */
> other stuff;
> spin_unlock(&foo);
> <----
>
> spin_unlock(&foo);
>
> Could be a missing _irqsave() if it's not, as Stanislaw suggested, a false
> positive.
I suspected the message meant mixed interrupts disabled/enabled, but thanks for
the confirmation.
Thanks,
Larry
^ permalink raw reply
* Re: packet injection not working on rt2800usb, ath9k
From: Andy Pyles @ 2011-01-11 20:49 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20110111115207.GA28619@jm.kir.nu>
> I do not know about rt2800usb, but monitor mode and packet injection
> works with ath9k. I'm not sure how packetspammer is doing this, but at
> least use of Linux packet socket and simple radiotap header works fine
> in my tests. In addition, it could be useful to update your ath9k driver
> to make sure you are running with all the latest fixes.
Thanks for the tip! After some debugging, it turns out that my
radiotap header is not getting parsed correctly
in ./net/mac80211/tx.c:__ieee80211_parse_tx_radiotap()
Would you mind sending me the radiotap header you are using?
^ permalink raw reply
* Compat-wireless release for 2011-01-11 is baked
From: Compat-wireless cronjob account @ 2011-01-11 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
* [new branch] akpm-end -> origin/akpm-end
* [new branch] akpm-start -> origin/akpm-start
2a4c30d..5ef1982 history -> origin/history
+ 4c897f2...2cc48ac master -> origin/master (forced update)
0c21e3a..e0e736f stable -> origin/stable
* [new tag] next-20110111 -> next-20110111
compat-wireless code metrics
782546 - Total upstream lines of code being pulled
2103 - backport code changes
1843 - backport code additions
260 - backport code deletions
7279 - backport from compat module
9382 - total backport code
1.1989 - % of code consists of backport work
1531 - Crap changes not yet posted
1488 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1956 - % of crap code
Base tree: linux-next.git
Base tree version: next-20110111
compat-wireless release: compat-wireless-2011-01-06-pc
^ permalink raw reply
* [PATCH] wl12xx: Add channel 14 to list of supported 2ghz channels
From: Arik Nemtsov @ 2011-01-11 19:49 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho, Arik Nemtsov
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
drivers/net/wireless/wl12xx/main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 062247e..a7afdca 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2305,6 +2305,7 @@ static struct ieee80211_channel wl1271_channels[] = {
{ .hw_value = 11, .center_freq = 2462, .max_power = 25 },
{ .hw_value = 12, .center_freq = 2467, .max_power = 25 },
{ .hw_value = 13, .center_freq = 2472, .max_power = 25 },
+ { .hw_value = 14, .center_freq = 2484, .max_power = 25 },
};
/* mapping to indexes for wl1271_rates */
--
1.7.1
^ permalink raw reply related
* Re: Locking problem reported for mainline
From: Bob Copeland @ 2011-01-11 19:45 UTC (permalink / raw)
To: Larry Finger; +Cc: Christian Lamparter, wireless
In-Reply-To: <4D2C85FE.4030709@lwfinger.net>
On Tue, Jan 11, 2011 at 11:31 AM, Larry Finger
<Larry.Finger@lwfinger.net> wrote:
> Is there a document that explains what the meaning of these semantics?
>
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> kdostartupconfi/3502 [HC1[1]:SC0[0]:HE0:SE1] takes:
> (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812995c6>]
> skb_queue_tail+0x26/0x60
> {HARDIRQ-ON-W} state was registered at:
I'm not sure about all the HC1[1]:SC0[0] etc stuff, but check out
Documentation/lockdep-design.txt for the basics.
In this case, someone took a lock with interrupts enabled (HARDIRQ-ON-W)
while someone else took it in a hard IRQ context (IN-HARDIRQ-W) where
they are normally disabled. The problem of course is:
cpu0:
spin_lock(&foo);
do some stuff protected by foo;
----> interrupt happens here
spin_lock(&foo); /* darn, deadlock! */
other stuff;
spin_unlock(&foo);
<----
spin_unlock(&foo);
Could be a missing _irqsave() if it's not, as Stanislaw suggested, a false
positive.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* RE: What pieces are needed for wl1271..what directories, files, configs, etc..
From: Brzezowski, Karen @ 2011-01-11 19:41 UTC (permalink / raw)
To: Brzezowski, Karen, Krakowski, Oz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <0826983CC0CB074798C42E77D8ACD07F0683D3@pdtms1.pdt.com>
ok, so far, I found the Makefile in the wl12xx directory from git clone git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git has 2.6.37-rc6
in it. so it's the 37-rc6 kernel, correct?
Can I use this "stuff" in the 2.6.31 kernel? (I know what's said in the wiki info below..)
I just don't know what goes where, how...
:-)
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] on behalf of Brzezowski, Karen [Karen.Brzezowski@pdt.com]
Sent: Tuesday, January 11, 2011 1:05 PM
To: Krakowski, Oz
Cc: linux-wireless@vger.kernel.org
Subject: RE: What pieces are needed for wl1271..what directories, files, configs, etc..
Hi Oz,
Thank you for your response. I have been looking at that web page:
http://linuxwireless.org/en/users/Drivers/wl12xx
when i get the latest driver at
git clone git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
Do I take everything that comes in this compressed file and replace it in a Linux kernel?
Which Linux kernel is this driver code for?
I'm not really sure what the compat-wireless is...we are using the Linux 2.6.31 kernel
Do I need to get compat-wireless somehow for the 31 kernel?
Then the notes say integrations needs to be gotten for SDIO, Lenient, and platform data pasing..
Then the notes say I need WL127x firmware...
after all that I can build the kernel?
Do you have any example code that uses the interfaces for the wl1271 chip (the APIs)?
I've never ported a driver in Linux before...
I assumed all it would be is to get the driver directory corresponding to the new chip, adding or replacing it
in the drivers directory, build it, and voila, i have a driver to test..
I think I should not have assumed that, correct?
...this is why I'm confused........
:-)
thank you for your time!!!!!!!!!!
Karen
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] on behalf of Krakowski, Oz [ozk@ti.com]
Sent: Tuesday, January 11, 2011 12:13 AM
To: Brzezowski, Karen
Cc: linux-wireless@vger.kernel.org
Subject: Re: What pieces are needed for wl1271..what directories, files, configs, etc..
Hi Karen,
On Mon, Jan 10, 2011 at 10:44 AM, Brzezowski, Karen
<Karen.Brzezowski@pdt.com> wrote:
>
> Hello all wireless gurus!!
>
> I've been watching the linux-wireless mailings on the wl1271...........
>
> I've been trying to figure out how to get the wl1271 working with
> imx233 processor...
>
> I think we are moving to Linux 2.6.35 and android gingerbread (2.3)...
>
> I"m very confused as to what files/configs/etc..need to be grabbed to get my task going.......
>
> I see spi, sdio...not sure where all changes are made for the wl1271...i'm assuming
> not just in the ...net/wireless/wl1271 directory.......... i have firmware too...........(.bins..)
>
> I'm quite confused about the chip and how each part will work (BT, WLAN, and FM)...
> Do you have any documentation..(for dummies, that would be me!)
> that would help me understand about the chip..how it communicates to the processor,
> how it does it's job with respect to BT, WLAN, and FM, etc..
>
> I have NO idea where to begin.......I've been googling and reading and I have downloaded
> your wl12xx git........
If you haven't done so already, suggest you start by going through the
following wiki page: http://linuxwireless.org/en/users/Drivers/wl12xx
This should give you an idea of where to get the latest code, how to
compile it to your kernel (using compat-wireless) and links to the
relevant patches needed.
This will get you started with WLAN.
>
> If you can help me AT ALL to get me up to speed/ to start, what i need to do to connect
> the wl1271 to the imx233....if not imx233..that whatever you have........
The wiki page does include some basic information needed in order to
port to different hardware platforms.
Regards,
Oz.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: What pieces are needed for wl1271..what directories, files, configs, etc..
From: Brzezowski, Karen @ 2011-01-11 19:05 UTC (permalink / raw)
To: Krakowski, Oz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinjGLvWbSnfeNoUkoC2q4jN+uRntSYS6MAvm1vv@mail.gmail.com>
Hi Oz,
Thank you for your response. I have been looking at that web page:
http://linuxwireless.org/en/users/Drivers/wl12xx
when i get the latest driver at
git clone git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
Do I take everything that comes in this compressed file and replace it in a Linux kernel?
Which Linux kernel is this driver code for?
I'm not really sure what the compat-wireless is...we are using the Linux 2.6.31 kernel
Do I need to get compat-wireless somehow for the 31 kernel?
Then the notes say integrations needs to be gotten for SDIO, Lenient, and platform data pasing..
Then the notes say I need WL127x firmware...
after all that I can build the kernel?
Do you have any example code that uses the interfaces for the wl1271 chip (the APIs)?
I've never ported a driver in Linux before...
I assumed all it would be is to get the driver directory corresponding to the new chip, adding or replacing it
in the drivers directory, build it, and voila, i have a driver to test..
I think I should not have assumed that, correct?
...this is why I'm confused........
:-)
thank you for your time!!!!!!!!!!
Karen
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] on behalf of Krakowski, Oz [ozk@ti.com]
Sent: Tuesday, January 11, 2011 12:13 AM
To: Brzezowski, Karen
Cc: linux-wireless@vger.kernel.org
Subject: Re: What pieces are needed for wl1271..what directories, files, configs, etc..
Hi Karen,
On Mon, Jan 10, 2011 at 10:44 AM, Brzezowski, Karen
<Karen.Brzezowski@pdt.com> wrote:
>
> Hello all wireless gurus!!
>
> I've been watching the linux-wireless mailings on the wl1271...........
>
> I've been trying to figure out how to get the wl1271 working with
> imx233 processor...
>
> I think we are moving to Linux 2.6.35 and android gingerbread (2.3)...
>
> I"m very confused as to what files/configs/etc..need to be grabbed to get my task going.......
>
> I see spi, sdio...not sure where all changes are made for the wl1271...i'm assuming
> not just in the ...net/wireless/wl1271 directory.......... i have firmware too...........(.bins..)
>
> I'm quite confused about the chip and how each part will work (BT, WLAN, and FM)...
> Do you have any documentation..(for dummies, that would be me!)
> that would help me understand about the chip..how it communicates to the processor,
> how it does it's job with respect to BT, WLAN, and FM, etc..
>
> I have NO idea where to begin.......I've been googling and reading and I have downloaded
> your wl12xx git........
If you haven't done so already, suggest you start by going through the
following wiki page: http://linuxwireless.org/en/users/Drivers/wl12xx
This should give you an idea of where to get the latest code, how to
compile it to your kernel (using compat-wireless) and links to the
relevant patches needed.
This will get you started with WLAN.
>
> If you can help me AT ALL to get me up to speed/ to start, what i need to do to connect
> the wl1271 to the imx233....if not imx233..that whatever you have........
The wiki page does include some basic information needed in order to
port to different hardware platforms.
Regards,
Oz.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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