* cfg80211 rfkill interface
From: Arend Van Spriel @ 2011-01-10 19:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
Hi Johannes,
I am looking into implementing rfkill into our brcm80211 open-source driver. Our driver detects disable switch by an interrupt, but switching back does not give an interrupt. For the latter I wanted to use the rfkill_poll callback and wiphy_rfkill_start_polling. However, I tried a wiphy_rfkill_stop_polling in the rfkill_poll callback when rf is unblocked, and this resulted in a system hang. So I moved the wiphy_rfkill_stop_polling to the start callback. Does that make sense or is there another way you would recommend?
Gr. AvS
^ permalink raw reply
* Re: Locking problem reported for mainline
From: Christian Lamparter @ 2011-01-10 19:18 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4D2B59EA.4000200@lwfinger.net>
On Monday 10 January 2011 20:11:38 Larry Finger wrote:
> On 01/10/2011 12:13 PM, Christian Lamparter wrote:
> > Does this patch help?
> >
> > ---
> > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> > index a6701ed..8f13a83 100644
> > --- a/net/mac80211/rx.c
> > +++ b/net/mac80211/rx.c
>
> Did not compile. In ieee80211_release_reorder_frame at lines 552 and 554, rx is
> not defined.
>
Oops,
you are right. Fixed the copy&paste error, so this one should compile.
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a6701ed..936b932 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -549,7 +549,9 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
tid_agg_rx->reorder_buf[index] = NULL;
status = IEEE80211_SKB_RXCB(skb);
status->rx_flags |= IEEE80211_RX_DEFERRED_RELEASE;
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&local->rx_skb_queue.lock);
no_frame:
tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
@@ -780,7 +782,9 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
return;
dont_reorder:
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&local->rx_skb_queue.lock);
}
static ieee80211_rx_result debug_noinline
^ permalink raw reply related
* Re: Locking problem reported for mainline
From: Larry Finger @ 2011-01-10 19:11 UTC (permalink / raw)
To: Christian Lamparter; +Cc: wireless
In-Reply-To: <201101101913.17311.chunkeey@googlemail.com>
On 01/10/2011 12:13 PM, Christian Lamparter wrote:
> Does this patch help?
>
> ---
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index a6701ed..8f13a83 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -549,7 +549,9 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
> tid_agg_rx->reorder_buf[index] = NULL;
> status = IEEE80211_SKB_RXCB(skb);
> status->rx_flags |= IEEE80211_RX_DEFERRED_RELEASE;
> - skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_lock(&rx->local->rx_skb_queue.lock);
> + __skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_unlock(&rx->local->rx_skb_queue.lock);
>
> no_frame:
> tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
> @@ -780,7 +782,9 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
> return;
>
> dont_reorder:spin_lock(&rx->local->rx_skb_queue.lock);
> - skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_lock(&rx->local->rx_skb_queue.lock);
> + __skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_unlock(&rx->local->rx_skb_queue.lock);
> }
>
> static ieee80211_rx_result debug_noinline
Did not compile. In ieee80211_release_reorder_frame at lines 552 and 554, rx is
not defined.
Larry
^ permalink raw reply
* Re: RTL8187L: Can only "enable" hw radio switch after Windows boot
From: Hin-Tak Leung @ 2011-01-10 19:10 UTC (permalink / raw)
To: Larry Finger, Klaas De Craemer; +Cc: linux-wireless, Herton Ronaldo Krzesinski
In-Reply-To: <AANLkTi=iDFiuxKiCXCf54uAf4f1Vk-meNf=4J94Bn4a0@mail.gmail.com>
--- On Mon, 10/1/11, Klaas De Craemer <klaasdc@gmail.com> wrote:
> Hello all,
>
> I can add to this that the rtl8187 driver seems to perform
> worse then
> its Windows counterpart (for this device anyway). Today,
> the Linux
> driver could not even connect anymore to the AP. Issuing
> "iwconfig
> wlan0 apname" just doesn't do anything. I could connect to
> another,
> more closer AP in Linux however.
> I'm very annoyed to announce that, despite the loss in
> flexibility, we
> will be moving this box to Windows because the wireless
> connection
> then "just works".
> I'll still check the list and I will remain available to
> test anything
> that could help the Linux driver though.
I would suggest you having a go at studying the windows driver under ndiswrapper, and using the kernel debugfs to study how the windows driver communicate with the device via USB and compared that with what the native driver is doing. That was how I got to be associated with the native driver - spotting what it was doing wrong/different from how the vendor linux driver was doing; the same should work with ndiswrapper+windows driver. (it did for a little bit, from personal experience).
There is no magic to it - if you want the driver to work for you, you can spend some time on it. You know the windows driver works "better" (for you), and there is a way to study the windows driver via ndiswrapper and compared that with the native driver, so it is do-able, just time and patience.
AFAIK, none of us have any special secret knowledge about the RTL8187L, much beyond what's publicly avaialable - i.e. the Realtek "official" driver code and a few spec sheets, and studying the windows driver via ndiswrapper; and AFAIK none of us are paid to work on the Realtek driver - Herton probably are paid to work on linux-things (given the e-mail address) but presumably not specifically on any one driver; I just happened to own a laptop with such a device built-in and Larry seems to be more or less of the same situation.
P.S. I am annoyed by the "I am very annoyed..." part of your e-mail message.
^ permalink raw reply
* Re: RTL8187L: Can only "enable" hw radio switch after Windows boot
From: Klaas De Craemer @ 2011-01-10 18:24 UTC (permalink / raw)
To: Larry Finger; +Cc: htl10, linux-wireless, Herton Ronaldo Krzesinski
In-Reply-To: <AANLkTikS6ypimsFK8sgGdRyyTbarXLbYb=h8nMKpcv_v@mail.gmail.com>
Hello all,
I can add to this that the rtl8187 driver seems to perform worse then
its Windows counterpart (for this device anyway). Today, the Linux
driver could not even connect anymore to the AP. Issuing "iwconfig
wlan0 apname" just doesn't do anything. I could connect to another,
more closer AP in Linux however.
I'm very annoyed to announce that, despite the loss in flexibility, we
will be moving this box to Windows because the wireless connection
then "just works".
I'll still check the list and I will remain available to test anything
that could help the Linux driver though.
Regards,
Klaas
On Thu, Jan 6, 2011 at 19:07, Klaas De Craemer <klaasdc@gmail.com> wrote:
> Would there be any progress on this? I'm still having the same issue
> on humid days.
>
> Klaas
>
> On Wed, Nov 24, 2010 at 01:33, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 11/23/2010 03:06 PM, Klaas De Craemer wrote:
>>>
>>> Don't worry, I live in Belgium and temperatures in winter rarely get
>>> below -10 °C. I might just jam an USB cup heater in the enclosure...
>>>
>>> If you think there is anything I can help you with, please let me
>>> know. For now I'll try some more test variations to see if I can find
>>> more clues.
>>
>> I got drivers for XP and Linux from the Alfa site. I selected the high-power
>> version, which should match your device.
>>
>> I don't know what version is in the Windows version, but the Linux version has
>> rtl8187_linux_26.1025.0328.2007, which is pretty old. I have
>> rtl8187L_linux_26.1038.0626.2009, rtl8187L_linux_26.1039.0104.2010, and
>> rtl8187L_linux_26.1040.0820.2010 on my disk. At this point, I'm not sure which
>> version was used to generate the in-kernel Linux driver. Perhaps Herton
>> remembers, but it had to be something about the 2007 time frame.
>>
>> I had to build a new Windows XP system in a virtual machine. The one I already
>> had won't run on the machine I have now and the original is in the shop. Access
>> to the new host is restricted to mornings.
>>
>> Larry
>>
>
^ permalink raw reply
* Re: Locking problem reported for mainline
From: Christian Lamparter @ 2011-01-10 18:13 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4D2A9309.7000500@lwfinger.net>
On Monday 10 January 2011 06:03:05 Larry Finger wrote:
> I have updated my "Linus" tree to the latest state as of Jan. 9, 2011.
> Uname -r reports
>
> 2.6.37-Linus-03737-g0c21e3a-dirty
>
> The logged messages are listed below.
>
> [ 25.660371] =================================
> [ 25.660376] [ INFO: inconsistent lock state ]
> [ 25.660379] 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660382] ---------------------------------
> [ 25.660384] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [ 25.660388] kworker/0:0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [ 25.660390] (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812a2746>]
> skb_queue_tail+0x26/0x60
> [ 25.660401] {HARDIRQ-ON-W} state was registered at:
> [ 25.660403] [<ffffffff8107f305>] __lock_acquire+0xb25/0x1cc0
> [ 25.660409] [<ffffffff81080a73>] lock_acquire+0x93/0x130
> [ 25.660413] [<ffffffff813446cc>] _raw_spin_lock+0x2c/0x40
> [ 25.660418] [<ffffffffa02b3777>] ieee80211_rx_handlers+0x27/0x1c80 [mac80211]
> [ 25.660444] [<ffffffffa02b5608>]
> ieee80211_prepare_and_rx_handle+0x238/0x900 [mac80211]
> [ 25.660455] [<ffffffffa02b5fea>] ieee80211_rx+0x31a/0x940 [mac80211]
> [ 25.660465] [<ffffffffa029cd51>] ieee80211_tasklet_handler+0xc1/0xd0 [mac80211]
> [ 25.660474] [<ffffffff8104f993>] tasklet_action+0x73/0x120
> [ 25.660479] [<ffffffff8105048e>] __do_softirq+0xce/0x200
> [ 25.660546] irq event stamp: 393974
> [ 25.660548] hardirqs last enabled at (393971): [<ffffffff8100c03a>]
> default_idle+0x5a/0xf0
> [ 25.660553] hardirqs last disabled at (393972): [<ffffffff81345227>]
> save_args+0x67/0x70
> [ 25.660557] softirqs last enabled at (393974): [<ffffffff810501de>]
> _local_bh_enable+0xe/0x10
> [ 25.660562] softirqs last disabled at (393973): [<ffffffff8105062d>]
> irq_enter+0x6d/0x80
> [ 25.660566]
> [ 25.660567] other info that might help us debug this:
> [ 25.660570] 1 lock held by kworker/0:0/0:
> [ 25.660572] #0: (&(&rtlpriv->locks.irq_th_lock)->rlock){-.-...}, at:
> [<ffffffffa02f0daf>] _rtl_pci_interrupt+0x5f/0x890 [rtlwifi]
> [ 25.660585]
> [ 25.660586] stack backtrace:
> [ 25.660589] Pid: 0, comm: kworker/0:0 Tainted: G W
> 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660592] Call Trace:
> [ 25.660594] <IRQ> [<ffffffff8107e152>] ? print_usage_bug+0x182/0x1d0
> [ 25.660601] [<ffffffff8107e571>] ? mark_lock+0x3d1/0x640
> [ 25.660605] [<ffffffff8107f3bd>] ? __lock_acquire+0xbdd/0x1cc0
> [ 25.660610] [<ffffffff811d2aae>] ? check_unmap+0x3be/0x7e0
> [ 25.660615] [<ffffffff8107bc2d>] ? trace_hardirqs_off+0xd/0x10
> [ 25.660619] [<ffffffff81080a73>] ? lock_acquire+0x93/0x130
> [ 25.660622] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660627] [<ffffffff810af978>] ? rcu_start_gp+0x258/0x350
> [ 25.660630] [<ffffffff813447cc>] ? _raw_spin_lock_irqsave+0x3c/0x60
> [ 25.660634] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660637] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660647] [<ffffffffa029e166>] ? ieee80211_tx_status_irqsafe+0x36/0xb0
> [mac80211]
> [ 25.660653] [<ffffffffa02f0b90>] ? _rtl_pci_tx_isr+0x180/0x340 [rtlwifi]
> [ 25.660659] [<ffffffffa02f0e75>] ? _rtl_pci_interrupt+0x125/0x890 [rtlwifi]
Does this patch help?
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a6701ed..8f13a83 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -549,7 +549,9 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
tid_agg_rx->reorder_buf[index] = NULL;
status = IEEE80211_SKB_RXCB(skb);
status->rx_flags |= IEEE80211_RX_DEFERRED_RELEASE;
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&rx->local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&rx->local->rx_skb_queue.lock);
no_frame:
tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
@@ -780,7 +782,9 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
return;
dont_reorder:
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&rx->local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&rx->local->rx_skb_queue.lock);
}
static ieee80211_rx_result debug_noinline
^ permalink raw reply related
* wl12xx tree has been rebased
From: Luciano Coelho @ 2011-01-10 16:56 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I have rebased the wl12xx-next branch on the latest wireless-next tree
and the master branch on the latest wireless-testing tree. I did this
to avoid having to do too much manual merging.
Please update your relevant trees.
--
Cheers,
Luca.
^ permalink raw reply
* What pieces are needed for wl1271..what directories, files, configs, etc..
From: Brzezowski, Karen @ 2011-01-10 16:44 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Brzezowski, Karen
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 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........
I would greatly appreciate ANY help, guidance, advice.........all this is VERY new to me..
I also have to figure out how to use the chip for ANT+.......?????????
THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU
Karen
^ permalink raw reply
* Re: Locking problem reported for mainline
From: Stanislaw Gruszka @ 2011-01-10 16:06 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4D2A9309.7000500@lwfinger.net>
On Sun, Jan 09, 2011 at 11:03:05PM -0600, Larry Finger wrote:
> I have updated my "Linus" tree to the latest state as of Jan. 9, 2011. Uname -r
> reports
>
> 2.6.37-Linus-03737-g0c21e3a-dirty
>
> The logged messages are listed below.
I think this is a false positive, because for lockdep
local->rx_skb_queue->lock and local->skb_queue->lock
is the same lock (struct sk_buff_head->lock). Hence warn when we do
not spin_lock_irq in ieee80211_rx_handlers(), but take lock
from interrupt handler in ieee80211_tx_status_irqsafe()-> skb_queue_tail()
Stanislaw
> =======================================================================
>
> [ 25.660371] =================================
> [ 25.660376] [ INFO: inconsistent lock state ]
> [ 25.660379] 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660382] ---------------------------------
> [ 25.660384] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [ 25.660388] kworker/0:0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [ 25.660390] (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812a2746>]
> skb_queue_tail+0x26/0x60
> [ 25.660401] {HARDIRQ-ON-W} state was registered at:
> [ 25.660403] [<ffffffff8107f305>] __lock_acquire+0xb25/0x1cc0
> [ 25.660409] [<ffffffff81080a73>] lock_acquire+0x93/0x130
> [ 25.660413] [<ffffffff813446cc>] _raw_spin_lock+0x2c/0x40
> [ 25.660418] [<ffffffffa02b3777>] ieee80211_rx_handlers+0x27/0x1c80 [mac80211]
> [ 25.660444] [<ffffffffa02b5608>]
> ieee80211_prepare_and_rx_handle+0x238/0x900 [mac80211]
> [ 25.660455] [<ffffffffa02b5fea>] ieee80211_rx+0x31a/0x940 [mac80211]
> [ 25.660465] [<ffffffffa029cd51>] ieee80211_tasklet_handler+0xc1/0xd0 [mac80211]
> [ 25.660474] [<ffffffff8104f993>] tasklet_action+0x73/0x120
> [ 25.660479] [<ffffffff8105048e>] __do_softirq+0xce/0x200
> [ 25.660483] [<ffffffff81003ccc>] call_softirq+0x1c/0x30
> [ 25.660488] [<ffffffff81005e25>] do_softirq+0x85/0xc0
> [ 25.660492] [<ffffffff810506cd>] irq_exit+0x8d/0xa0
> [ 25.660496] [<ffffffff81005971>] do_IRQ+0x61/0xe0
> [ 25.660500] [<ffffffff813452d3>] ret_from_intr+0x0/0xf
> [ 25.660504] [<ffffffff81179cd7>] sysfs_permission+0x47/0x80
> [ 25.660510] [<ffffffff81126bfa>] link_path_walk+0x1ea/0xdb0
> [ 25.660515] [<ffffffff81127568>] link_path_walk+0xb58/0xdb0
> [ 25.660519] [<ffffffff81127ab6>] do_path_lookup+0x56/0x130
> [ 25.660523] [<ffffffff81127f92>] user_path_at+0x52/0xa0
> [ 25.660526] [<ffffffff8111e634>] vfs_fstatat+0x34/0x70
> [ 25.660532] [<ffffffff8111e6a6>] vfs_stat+0x16/0x20
> [ 25.660536] [<ffffffff8111ea4f>] sys_newstat+0x1f/0x40
> [ 25.660540] [<ffffffff81002d7b>] system_call_fastpath+0x16/0x1b
> [ 25.660546] irq event stamp: 393974
> [ 25.660548] hardirqs last enabled at (393971): [<ffffffff8100c03a>]
> default_idle+0x5a/0xf0
> [ 25.660553] hardirqs last disabled at (393972): [<ffffffff81345227>]
> save_args+0x67/0x70
> [ 25.660557] softirqs last enabled at (393974): [<ffffffff810501de>]
> _local_bh_enable+0xe/0x10
> [ 25.660562] softirqs last disabled at (393973): [<ffffffff8105062d>]
> irq_enter+0x6d/0x80
> [ 25.660566]
> [ 25.660567] other info that might help us debug this:
> [ 25.660570] 1 lock held by kworker/0:0/0:
> [ 25.660572] #0: (&(&rtlpriv->locks.irq_th_lock)->rlock){-.-...}, at:
> [<ffffffffa02f0daf>] _rtl_pci_interrupt+0x5f/0x890 [rtlwifi]
> [ 25.660585]
> [ 25.660586] stack backtrace:
> [ 25.660589] Pid: 0, comm: kworker/0:0 Tainted: G W
> 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660592] Call Trace:
> [ 25.660594] <IRQ> [<ffffffff8107e152>] ? print_usage_bug+0x182/0x1d0
> [ 25.660601] [<ffffffff8107e571>] ? mark_lock+0x3d1/0x640
> [ 25.660605] [<ffffffff8107f3bd>] ? __lock_acquire+0xbdd/0x1cc0
> [ 25.660610] [<ffffffff811d2aae>] ? check_unmap+0x3be/0x7e0
> [ 25.660615] [<ffffffff8107bc2d>] ? trace_hardirqs_off+0xd/0x10
> [ 25.660619] [<ffffffff81080a73>] ? lock_acquire+0x93/0x130
> [ 25.660622] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660627] [<ffffffff810af978>] ? rcu_start_gp+0x258/0x350
> [ 25.660630] [<ffffffff813447cc>] ? _raw_spin_lock_irqsave+0x3c/0x60
> [ 25.660634] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660637] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660647] [<ffffffffa029e166>] ? ieee80211_tx_status_irqsafe+0x36/0xb0
> [mac80211]
> [ 25.660653] [<ffffffffa02f0b90>] ? _rtl_pci_tx_isr+0x180/0x340 [rtlwifi]
> [ 25.660659] [<ffffffffa02f0e75>] ? _rtl_pci_interrupt+0x125/0x890 [rtlwifi]
> [ 25.660665] [<ffffffff810ab299>] ? handle_IRQ_event+0x49/0x170
> [ 25.660670] [<ffffffff810ada52>] ? handle_fasteoi_irq+0x92/0x110
> [ 25.660674] [<ffffffff81005d44>] ? handle_irq+0x44/0xa0
> [ 25.660677] [<ffffffff81005968>] ? do_IRQ+0x58/0xe0
> [ 25.660681] [<ffffffff813452d3>] ? ret_from_intr+0x0/0xf
> [ 25.660683] <EOI> [<ffffffff8100c03c>] ? default_idle+0x5c/0xf0
> [ 25.660690] [<ffffffff8100c03a>] ? default_idle+0x5a/0xf0
> [ 25.660694] [<ffffffff8100c124>] ? c1e_idle+0x54/0x100
> [ 25.660698] [<ffffffff810011eb>] ? cpu_idle+0x5b/0x120
> [ 25.660703] [<ffffffff8133dd72>] ? start_secondary+0x190/0x194
> --
> 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: 5GHz 802.11n USB Adapter
From: Helmut Schaa @ 2011-01-10 16:03 UTC (permalink / raw)
To: Kalle Valo; +Cc: Jason Andryuk, linux-wireless
In-Reply-To: <87mxn9fl6m.fsf@purkki.adurom.net>
Am Montag, 10. Januar 2011 schrieb Kalle Valo:
> Helmut Schaa <helmut.schaa@googlemail.com> writes:
>
> > Am Samstag, 8. Januar 2011 schrieb Jason Andryuk:
> >> Are there any limitations for rt2800usb devices? The wiki is short on
> >> information as is rt2x00.serialmonkey.com. Does rt2800usb support AP
> >> mode like rt2800pci?
> >
> > rt2800usb does not support bc- and mc- buffering (rt2800pci does). Hence,
> > powersaving stations might experience problems when using rt2800usb in AP
> > mode.
>
> If some hardware models don't support broadcast/multicast buffering in
> that case the driver shouldn't allow AP mode, at least not in mainline
> kernels. We shouldn't break the standarnd knowingly.
>
> From a quick grep it looks like rt2800usb enables AP mode. Is that the
> case or did I misunderstood something?
You're right, rt2800usb enables AP mode despite the lack of proper
mc- and bc buffering.
Helmut
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update information for the wl12xx driver
From: Luciano Coelho @ 2011-01-10 16:04 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1294675330-11691-1-git-send-email-coelho@ti.com>
On Mon, 2011-01-10 at 17:02 +0100, Coelho, Luciano wrote:
> From: Luciano Coelho <coelho@ti.com>
>
> Update maintainer's email address, webpage and align with renaming of
> files.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
I have applied this in the wl12xx tree and will send in the next pull
request.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v4 00/18] AP mode support for wl12xx
From: Luciano Coelho @ 2011-01-10 16:03 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless@vger.kernel.org, Luciano Coelho
In-Reply-To: <1293665533-7599-1-git-send-email-arik@wizery.com>
On Thu, 2010-12-30 at 00:31 +0100, Arik Nemtsov wrote:
> These patches add access point mode support to the wl12xx driver.
> This mode uses a separate firmware and has a different initialization
> sequence.
>
> In all instances, the flow has been split according to the operating
> mode of the driver (AP/STA), so as not to affect STA mode functionality.
>
> v1->2: rebased on latest wl12xx tree
> v2->3: refactoring
> v3->4: cross-patch fix
Applied the series, thanks Arik!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] wl12xx: fix some sparse warnings
From: Luciano Coelho @ 2011-01-10 16:02 UTC (permalink / raw)
To: Eliad Peller; +Cc: Luciano Coelho, linux-wireless@vger.kernel.org
In-Reply-To: <1293017932-9806-1-git-send-email-eliad@wizery.com>
On Wed, 2010-12-22 at 12:38 +0100, Eliad Peller wrote:
> Note that wl1271_write32() calls cpu_to_le32() by itself, so calling
> wl1271_write32(addr, cpu_to_le32(val)) is in fact a bug on BE systems.
>
> Fix the following sparse warnings:
>
> drivers/net/wireless/wl12xx/cmd.c:662:16: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/wl12xx/cmd.c:662:16: expected unsigned short [unsigned] [addressable] [usertype] llc_type
> drivers/net/wireless/wl12xx/cmd.c:662:16: got restricted __be16 [usertype] <noident>
> drivers/net/wireless/wl12xx/cmd.c:674:17: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/wl12xx/cmd.c:674:17: expected unsigned int [unsigned] [addressable] [usertype] sender_ip
> drivers/net/wireless/wl12xx/cmd.c:674:17: got restricted __be32 [usertype] ip_addr
> drivers/net/wireless/wl12xx/rx.c:202:4: warning: incorrect type in argument 3 (different base types)
> drivers/net/wireless/wl12xx/rx.c:202:4: expected unsigned int [unsigned] [usertype] val
> drivers/net/wireless/wl12xx/rx.c:202:4: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/wl12xx/acx.c:1247:23: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/wl12xx/acx.c:1247:23: expected restricted __le32 [usertype] ht_capabilites
> drivers/net/wireless/wl12xx/acx.c:1247:23: got unsigned long
> drivers/net/wireless/wl12xx/acx.c:1250:24: warning: invalid assignment: |=
> drivers/net/wireless/wl12xx/acx.c:1250:24: left side has type restricted __le32
> drivers/net/wireless/wl12xx/acx.c:1250:24: right side has type unsigned long
> drivers/net/wireless/wl12xx/acx.c:1253:24: warning: invalid assignment: |=
> drivers/net/wireless/wl12xx/acx.c:1253:24: left side has type restricted __le32
> drivers/net/wireless/wl12xx/acx.c:1253:24: right side has type unsigned long
> drivers/net/wireless/wl12xx/acx.c:1256:24: warning: invalid assignment: |=
> drivers/net/wireless/wl12xx/acx.c:1256:24: left side has type restricted __le32
> drivers/net/wireless/wl12xx/acx.c:1256:24: right side has type unsigned long
>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Applied, thank you!
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] MAINTAINERS: update information for the wl12xx driver
From: coelho @ 2011-01-10 16:02 UTC (permalink / raw)
To: linux-wireless
From: Luciano Coelho <coelho@ti.com>
Update maintainer's email address, webpage and align with renaming of
files.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
MAINTAINERS | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ff19c30..92394cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6540,12 +6540,12 @@ S: Maintained
F: drivers/net/wireless/wl1251/*
WL1271 WIRELESS DRIVER
-M: Luciano Coelho <luciano.coelho@nokia.com>
+M: Luciano Coelho <coelho@ti.com>
L: linux-wireless@vger.kernel.org
-W: http://wireless.kernel.org
+W: http://wireless.kernel.org/en/users/Drivers/wl12xx
T: git git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
S: Maintained
-F: drivers/net/wireless/wl12xx/wl1271*
+F: drivers/net/wireless/wl12xx/
F: include/linux/wl12xx.h
WL3501 WIRELESS PCMCIA CARD DRIVER
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] wl12xx: BA receiver support
From: Luciano Coelho @ 2011-01-10 15:44 UTC (permalink / raw)
To: Shahar Levi; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1294062164-3459-3-git-send-email-shahar_levi@ti.com>
On Mon, 2011-01-03 at 14:42 +0100, Shahar Levi wrote:
> Add new ampdu_action ops to support receiver BA.
> The BA initiator session management in FW independently.
>
> Signed-off-by: Shahar Levi <shahar_levi@ti.com>
> ---
Some comments.
> diff --git a/drivers/net/wireless/wl12xx/acx.c b/drivers/net/wireless/wl12xx/acx.c
> index 54fd68d..f33ab50 100644
> --- a/drivers/net/wireless/wl12xx/acx.c
> +++ b/drivers/net/wireless/wl12xx/acx.c
> @@ -1359,6 +1359,42 @@ out:
> return ret;
> }
>
> +/* setup BA session receiver setting in the FW. */
> +int wl1271_acx_set_ba_receiver_session(struct wl1271 *wl, u8 tid_index,
> + u16 *ssn, u8 policy)
You don't modify ssn here, so why pass it as a pointer? Use u16 directly
here instead.
Actually it's even worse. As stated in mac80211.h, ssn can be NULL
here, so you would be accessing a NULL pointer in that case.
I see that you check "policy", which indicates whether ssn is valid or
not, but why not make it cleaner by checking if ssn is NULL and setting
it to zero before passing instead?
> + acx->enable = policy;
Also, because of this, it would make more sense if policy was a boolean
and was called "enable" instead.
> diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
> index c44462d..04b69ab 100644
> --- a/drivers/net/wireless/wl12xx/main.c
> +++ b/drivers/net/wireless/wl12xx/main.c
> @@ -2251,6 +2251,64 @@ static int wl1271_op_get_survey(struct ieee80211_hw *hw, int idx,
> return 0;
> }
>
> +int wl1271_op_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> + enum ieee80211_ampdu_mlme_action action,
> + struct ieee80211_sta *sta, u16 tid, u16 *ssn)
> +{
> + struct wl1271 *wl = hw->priv;
> + int ret;
> +
> + mutex_lock(&wl->mutex);
> +
> + if (unlikely(wl->state == WL1271_STATE_OFF)) {
> + ret = -EAGAIN;
> + goto out;
> + }
> +
> + ret = wl1271_ps_elp_wakeup(wl, false);
> + if (ret < 0)
> + goto out;
> +
> + switch (action) {
> + case IEEE80211_AMPDU_RX_START:
> + if ((wl->ba_allowed) && (wl->ba_support)) {
I'm a bit confused. What is ba_allowed, actually? In the previous patch
you always call wl1271_set_ba_policies() which always sets it to true.
So it seems quite useless.
> + ret = wl1271_acx_set_ba_receiver_session(wl, tid, ssn,
> + true);
> + if (!ret)
> + wl->ba_rx_bitmap |= BIT(tid);
> + } else
> + ret = -EPERM;
The indentation is wrong here. And -EPERM is definitely not the right
return code for this. It should probably -ENOTSUPP or something like
that.
> + /*
> + * The BA initiator session management in FW independently.
> + * Falling break here on purpose for all TX APDU commands.
> + */
> + case IEEE80211_AMPDU_TX_START:
> + case IEEE80211_AMPDU_TX_STOP:
> + case IEEE80211_AMPDU_TX_OPERATIONAL:
> + ret = -EINVAL;
> + break;
-EINVAL? Actually, should mac80211 even call us with these actions? I
don't remember now, did you implement the way to prevent mac80211 from
trying to to AMPDU_TX by itself?
> +
> + default:
> + wl1271_error("Incorrect ampdu action id=%x\n", action);
> + ret = -ENODEV;
-ENODEV? All these error codes look quite random to me. Can you explain
your choices?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH RESEND 11/11] ath9k: Implement rx copy-break.
From: Felix Fietkau @ 2011-01-10 15:19 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1294643513-18820-12-git-send-email-greearb@candelatech.com>
On 2011-01-10 12:11 AM, greearb@candelatech.com wrote:
> From: Ben Greear<greearb@candelatech.com>
>
> This saves us constantly allocating large, multi-page
> skbs. It should fix the order-1 allocation errors reported,
> and in a 60-vif scenario, this significantly decreases CPU
> utilization, and latency, and increases bandwidth.
>
> Signed-off-by: Ben Greear<greearb@candelatech.com>
I think we should use Jouni's approach instead of this patch, as it also
fixes order-1 allocations, but with less data copying involved.
- Felix
^ permalink raw reply
* Re: [PATCH v5 1/2] wl12xx: BA initiator support
From: Luciano Coelho @ 2011-01-10 15:00 UTC (permalink / raw)
To: Shahar Levi; +Cc: linux-wireless@vger.kernel.org, Luciano Coelho
In-Reply-To: <1294062164-3459-2-git-send-email-shahar_levi@ti.com>
On Mon, 2011-01-03 at 14:42 +0100, Shahar Levi wrote:
> Add 80211n BA initiator session support wl1271 driver.
> Include BA supported FW version auto detection mechanism.
> BA initiator session management included in FW independently.
>
> Signed-off-by: Shahar Levi <shahar_levi@ti.com>
> ---
Some comments...
> diff --git a/drivers/net/wireless/wl12xx/acx.c b/drivers/net/wireless/wl12xx/acx.c
> index cc4068d..54fd68d 100644
> --- a/drivers/net/wireless/wl12xx/acx.c
> +++ b/drivers/net/wireless/wl12xx/acx.c
> @@ -1309,6 +1309,56 @@ out:
> return ret;
> }
>
> +/* Configure BA session initiator\receiver parameters setting in the FW. */
Please use forward slash here instead of backslash, ie. use
"initiator/receiver".
> diff --git a/drivers/net/wireless/wl12xx/acx.h b/drivers/net/wireless/wl12xx/acx.h
> index 9cbc3f4..df48468 100644
> --- a/drivers/net/wireless/wl12xx/acx.h
> +++ b/drivers/net/wireless/wl12xx/acx.h
> @@ -1051,6 +1051,40 @@ struct wl1271_acx_ht_information {
> u8 padding[3];
> } __packed;
>
> +#define BA_WIN_SIZE 8
Should this be DEFAULT_BA_WIN_SIZE?
> diff --git a/drivers/net/wireless/wl12xx/boot.c b/drivers/net/wireless/wl12xx/boot.c
> index 4a9f929..cd42e12 100644
> --- a/drivers/net/wireless/wl12xx/boot.c
> +++ b/drivers/net/wireless/wl12xx/boot.c
> @@ -101,6 +101,39 @@ static void wl1271_boot_set_ecpu_ctrl(struct wl1271 *wl, u32 flag)
> wl1271_write32(wl, ACX_REG_ECPU_CONTROL, cpu_ctrl);
> }
>
> +static void wl1271_save_fw_ver(struct wl1271 *wl)
This function name is not very informative. Why not call it
wl1271_parse_fw_ver() instead?
> +{
> + char fw_ver_str[ETHTOOL_BUSINFO_LEN];
This is weird, but it seem to be what is used in cfg80211 (as Shahar
pointed out on IRC). IMHO it should be ETHTOOL_FWVERS_LEN instead, both
here and in cfg80211.
In any case, this is a bit confusing here, because we don't use the
fw_version in the wiphy struct (we probably should). Let's keep it like
this for now and maybe later we can change.
Also, I don't see why you need a local copy here.
> + char *fw_ver_point;
> + int ret, i;
> +
> + /* copy the fw version to temp str */
> + strncpy(fw_ver_str, wl->chip.fw_ver_str, sizeof(fw_ver_str));
> +
> + for (i = (WL12XX_NUM_FW_VER - 1); i > 0; --i) {
> + /* find the last '.' */
> + fw_ver_point = strrchr(fw_ver_str, '.');
> +
> + /* read version number */
> + ret = strict_strtoul(fw_ver_point+1, 10, &(wl->chip.fw_ver[i]));
> + if (ret < 0) {
> + wl1271_warning("fw version incorrect value");
> + memset(wl->chip.fw_ver, 0, sizeof(wl->chip.fw_ver));
> + return;
> + }
> +
> + /* clean '.' */
> + *fw_ver_point = '\0';
> + }
> +
> + ret = strict_strtoul(fw_ver_point-1, 10, &(wl->chip.fw_ver[0]));
> + if (ret < 0) {
> + wl1271_warning("fw version incorrect value");
> + memset(wl->chip.fw_ver, 0, sizeof(wl->chip.fw_ver));
> + return;
> + }
> +}
Instead of all this manual parsing, why don't you use sscanf? I think
the following could do the work very nicely:
ret = sscanf(wl->chip.fw_ver_str + WL12XX_FW_VER_OFFSET,
"%lu.%lu.%lu.%lu.%lu", &wl->chip.fw_ver[0],
&wl->chip.fw_ver[1], &wl->chip.fw_ver[2]
&wl->chip.fw_ver[3], &wl->chip.fw_ver[4]);
Wouldn't something like this be much simpler? (or you could use %u if
you agree on using unsigned int, see below)
> static int wl1271_boot_upload_firmware_chunk(struct wl1271 *wl, void *buf,
> diff --git a/drivers/net/wireless/wl12xx/conf.h b/drivers/net/wireless/wl12xx/conf.h
> index a16b361..41df771 100644
> --- a/drivers/net/wireless/wl12xx/conf.h
> +++ b/drivers/net/wireless/wl12xx/conf.h
> @@ -1090,6 +1090,12 @@ struct conf_rf_settings {
> u8 tx_per_channel_power_compensation_5[CONF_TX_PWR_COMPENSATION_LEN_5];
> };
>
> +#define CONF_BA_INACTIVITY_TIMEOUT 10000
If this is a CONFigurable value, it should be in conf.h and in the
configuration parameters in main.c, shouldn't it?
> diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
> index 062247e..c44462d 100644
> --- a/drivers/net/wireless/wl12xx/main.c
> +++ b/drivers/net/wireless/wl12xx/main.c
> @@ -233,7 +233,7 @@ static struct conf_drv_settings default_conf = {
> .avg_weight_rssi_beacon = 20,
> .avg_weight_rssi_data = 10,
> .avg_weight_snr_beacon = 20,
> - .avg_weight_snr_data = 10
> + .avg_weight_snr_data = 10,
> },
> .scan = {
> .min_dwell_time_active = 7500,
> @@ -252,6 +252,9 @@ static struct conf_drv_settings default_conf = {
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> },
> },
> + .ht = {
> + .inactivity_timeout = CONF_BA_INACTIVITY_TIMEOUT,
> + },
Ah, I see. You are using that macro here, but I guess you could use the
value directly, since this is all configuration stuff, so no need to use
defines, unless the values mean something specific. Here it is just a
measure of time, so a number can be used directly (like in the
min_dwell_time_active).
> diff --git a/drivers/net/wireless/wl12xx/wl12xx.h b/drivers/net/wireless/wl12xx/wl12xx.h
> index 01711fe..7b34393 100644
> --- a/drivers/net/wireless/wl12xx/wl12xx.h
> +++ b/drivers/net/wireless/wl12xx/wl12xx.h
> @@ -38,6 +38,11 @@
> #define DRIVER_NAME "wl1271"
> #define DRIVER_PREFIX DRIVER_NAME ": "
>
> +#define WL12XX_BA_SUPPORT_FW_SUB_VER 339
> +#define WL12XX_BA_SUPPORT_FW_COST_VER1 33
> +#define WL12XX_BA_SUPPORT_FW_COST_VER2_START 50
> +#define WL12XX_BA_SUPPORT_FW_COST_VER2_END 60
This defines are very confusing. Can you explain a bit? What about
"COST" version 0 (like 6.0.0.0.343), will that branch never support BA?
Where do the 50 to 60 come from? And what is 33? This kind of magic
should be explained.
> @@ -161,10 +166,13 @@ struct wl1271_partition_set {
>
> struct wl1271;
>
> +#define WL12XX_NUM_FW_VER 5
> +
WL12XX_FW_VER_OFFSET sounds better to me. And it shouldn't it be 4,
which is the "Rev " prefix?
> /* FIXME: I'm not sure about this structure name */
> struct wl1271_chip {
> u32 id;
> - char fw_ver[21];
> + char fw_ver_str[ETHTOOL_BUSINFO_LEN];
> + unsigned long fw_ver[WL12XX_NUM_FW_VER];
Why not unsigned int? (and then use %u.%u... as I mentioned earlier).
--
Cheers,
Luca.
^ permalink raw reply
* RE: hostapd hangs on quit, multi-BSSID scenario
From: Chaoxing Lin @ 2011-01-10 14:51 UTC (permalink / raw)
To: 'Jouni Malinen'; +Cc: 'linux-wireless@vger.kernel.org'
In-Reply-To: <20110109172629.GA12229@jm.kir.nu>
Thanks very much.
It works very well now.
-----Original Message-----
From: Jouni Malinen [mailto:j@w1.fi]
Sent: Sunday, January 09, 2011 12:26 PM
To: Chaoxing Lin
Cc: 'linux-wireless@vger.kernel.org'
Subject: Re: hostapd hangs on quit, multi-BSSID scenario
On Fri, Jan 07, 2011 at 05:44:30PM +0000, Chaoxing Lin wrote:
> When I run hostapd with 8+1 BSSID over one radio (ath9160), it runs well. All 9 BSS accepts clients.
> But when I "Ctrl + C" or "killall hostapd", hostapd daemon can NOT gracefully shut down. It hangs forever. I have to "Ctrl + C" again. Then it quits and print message like "
> ^Celoop: could not process SIGINT or SIGTERM in two seconds. Looks like there
> is a bug that ends up in a busy loop that prevents clean shutdown.
> Killing program forcefully.
Fixed here:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=8546ea19301f31e5faf58a0f154773c3123e6474
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] ath9k: Implement rx copy-break.
From: Jouni Malinen @ 2011-01-10 12:40 UTC (permalink / raw)
To: Christian Lamparter
Cc: Ben Greear, Felix Fietkau, linux-wireless, ath9k-devel
In-Reply-To: <201101092114.55534.chunkeey@googlemail.com>
On Sun, Jan 09, 2011 at 09:14:53PM +0100, Christian Lamparter wrote:
> On Sunday 09 January 2011 19:13:04 Jouni Malinen wrote:
> > For the order-1 allocation issues, it would be interesting to see if
> > someone could take a look at using paged skbs or multiple RX descriptors
> > with shorter skbs (and copying only for the case where a long frame is
> > received so that only the A-MSDU RX case would suffer from extra
> > copying).
>
> Well, here's a shot at paged rx. It'll only work when PAGE_SIZE > buf_size
> (which will be true for most system, I guess)
Thanks!
For the multiple RX descriptors (fragmented buffer for DMA) part, here's
a very preliminary patch to show how it could be done in ath9k for
anyone who might want to experiment more in this area. This version is
obviously only helping with large allocations (it uses half the buffer
size). The extra copying is there for large A-MSDU case. Though, I did
add some concept code to use skb frag_list to allow such a frame be
delivered to mac80211 without needing any extra allocation/copying. That
is commented out for now, if mac80211 can be made to handle A-MSDU RX
processing with fragmented data (which should be relatively simple
change, I'd hope), there should be no need for doing the extra copy in
ath9k. (And likewise, I was too lazy to handle the EDMA case for now..)
The version here is limited to at maximum two fragments. If desired,
this could be further extended to handle multiple fragments to get the
default RX skb allocation shorter than 2k (i.e., to cover the normal
1500 MTU). I'm not sure whether that would result in noticeable benefit,
but it could help in saving some memory when there are multiple skbs
queued in various places in the networking stack. Likewise, the maximum
A-MSDU receive length could be extended with this approach without
having to use even longer individual buffers for RX.
---
drivers/net/wireless/ath/ath9k/hw.h | 2
drivers/net/wireless/ath/ath9k/main.c | 5 +
drivers/net/wireless/ath/ath9k/recv.c | 102 +++++++++++++++++++++++++++++-----
3 files changed, 95 insertions(+), 14 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/hw.h 2011-01-10 13:03:16.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath/ath9k/hw.h 2011-01-10 13:15:39.000000000 +0200
@@ -852,6 +852,8 @@ struct ath_hw {
/* Enterprise mode cap */
u32 ent_mode;
+
+ struct sk_buff *rx_frag;
};
static inline struct ath_common *ath9k_hw_common(struct ath_hw *ah)
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/main.c 2011-01-10 13:14:26.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath/ath9k/main.c 2011-01-10 13:15:05.000000000 +0200
@@ -1320,6 +1320,11 @@ static void ath9k_stop(struct ieee80211_
} else
sc->rx.rxlink = NULL;
+ if (ah->rx_frag) {
+ dev_kfree_skb_any(ah->rx_frag);
+ ah->rx_frag = NULL;
+ }
+
/* disable HAL and put h/w to sleep */
ath9k_hw_disable(ah);
ath9k_hw_configpcipowersave(ah, 1, 1);
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/recv.c 2011-01-10 12:24:08.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath/ath9k/recv.c 2011-01-10 14:29:29.000000000 +0200
@@ -324,8 +324,19 @@ int ath_rx_init(struct ath_softc *sc, in
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA) {
return ath_rx_edma_init(sc, nbufs);
} else {
- common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN,
+ /*
+ * Use a buffer that allows a full frame to be received in at
+ * most two buffers with scattering DMA. This is needed for
+ * A-MSDU; other cases will fit in a single buffer. This will
+ * allow the skbs to fit in a single page to avoid issues with
+ * higher order allocation.
+ */
+ common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN / 2,
min(common->cachelsz, (u16)64));
+#if 0 /* TESTING - force two fragments even without A-MSDU */
+ common->rx_bufsize = roundup(2800 / 2,
+ min(common->cachelsz, (u16)64));
+#endif
ath_dbg(common, ATH_DBG_CONFIG, "cachelsz %u rxbufsize %u\n",
common->cachelsz, common->rx_bufsize);
@@ -863,16 +874,6 @@ static bool ath9k_rx_accept(struct ath_c
return false;
/*
- * rs_more indicates chained descriptors which can be used
- * to link buffers together for a sort of scatter-gather
- * operation.
- * reject the frame, we don't support scatter-gather yet and
- * the frame is probably corrupt anyway
- */
- if (rx_stats->rs_more)
- return false;
-
- /*
* The rx_stats->rs_status will not be set until the end of the
* chained descriptors so it can be ignored if rs_more is set. The
* rs_more will be false at the last element of the chained
@@ -1022,6 +1023,9 @@ static int ath9k_rx_skb_preprocess(struc
if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error))
return -EINVAL;
+ if (rx_stats->rs_more)
+ return 0; /* Only use data from the last fragment */
+
ath9k_process_rssi(common, hw, hdr, rx_stats);
if (ath9k_process_rate(common, hw, rx_stats, rx_status))
@@ -1674,7 +1678,16 @@ int ath_rx_tasklet(struct ath_softc *sc,
if (!skb)
continue;
- hdr = (struct ieee80211_hdr *) (skb->data + rx_status_len);
+ /*
+ * Take frame header from the first fragment and RX status from
+ * the last one.
+ */
+ if (ah->rx_frag)
+ hdr = (struct ieee80211_hdr *)
+ (ah->rx_frag->data + rx_status_len);
+ else
+ hdr = (struct ieee80211_hdr *)
+ (skb->data + rx_status_len);
rxs = IEEE80211_SKB_RXCB(skb);
hw = ath_get_virt_hw(sc, hdr);
@@ -1718,12 +1731,14 @@ int ath_rx_tasklet(struct ath_softc *sc,
common->rx_bufsize,
dma_type);
+ /* FIX: for fragmented frames, only one rx_status_len */
skb_put(skb, rs.rs_datalen + ah->caps.rx_status_len);
if (ah->caps.rx_status_len)
skb_pull(skb, ah->caps.rx_status_len);
- ath9k_rx_skb_postprocess(common, skb, &rs,
- rxs, decrypt_error);
+ if (!ah->rx_frag && !rs.rs_more)
+ ath9k_rx_skb_postprocess(common, skb, &rs,
+ rxs, decrypt_error);
/* We will now give hardware our shiny new allocated skb */
bf->bf_mpdu = requeue_skb;
@@ -1740,6 +1755,65 @@ int ath_rx_tasklet(struct ath_softc *sc,
break;
}
+ if (rs.rs_more) {
+ /*
+ * rs_more indicates chained descriptors which can be
+ * used to link buffers together for a sort of
+ * scatter-gather operation.
+ */
+ if (ah->rx_frag) {
+ printk(KERN_DEBUG "%s:dropped prev rx_frag\n",
+ __func__);
+ dev_kfree_skb_any(ah->rx_frag);
+ }
+ ah->rx_frag = skb;
+ goto requeue;
+ }
+ if (ah->rx_frag) {
+#if 1
+ struct sk_buff *nskb;
+ /*
+ * This is the final fragment of the frame - merge with
+ * previously received data.
+ */
+ nskb = skb_copy_expand(ah->rx_frag, 0, skb->len,
+ GFP_ATOMIC);
+ dev_kfree_skb_any(ah->rx_frag);
+ ah->rx_frag = NULL;
+ if (nskb == NULL) {
+ dev_kfree_skb_any(skb);
+ goto requeue;
+ }
+ skb_copy_from_linear_data(skb, skb_put(nskb, skb->len),
+ skb->len);
+ /* Take RX status for the last fragment */
+ memcpy(nskb->cb, skb->cb, sizeof(skb->cb));
+ dev_kfree_skb_any(skb);
+ skb = nskb;
+#else
+ /*
+ * TODO: This should really be optimized by using
+ * skb frag_list etc. to avoid new allocation and
+ * copying of data here. The fragmentation case will
+ * only happen when receiving A-MSDU aggregates and
+ * mac80211 will end up re-allocating and splitting
+ * those anyway. Once mac80211 is able to do this based
+ * on multiple fragments, alloc+copy code above can
+ * be replaced with something like following.
+ */
+ /* Take RX status for the last fragment */
+ memcpy(ah->rx_frag->cb, skb->cb, sizeof(skb->cb));
+ /* Link the fragments together using frag_list */
+ skb_frag_list_init(ah->rx_frag);
+ skb_frag_add_head(ah->rx_frag, skb);
+ skb = ah->rx_frag;
+ ah->rx_frag = NULL;
+#endif
+ rxs = IEEE80211_SKB_RXCB(skb);
+ ath9k_rx_skb_postprocess(common, skb, &rs,
+ rxs, decrypt_error);
+ }
+
/*
* change the default rx antenna if rx diversity chooses the
* other antenna 3 times in a row.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH 2.6.35] mac80211: fix hard lockup in sta_addba_resp_timer_expired
From: Stanislaw Gruszka @ 2011-01-10 12:38 UTC (permalink / raw)
To: Andi Kleen, stable, Kyle McMartin, kernel; +Cc: Johannes Berg, linux-wireless
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().
Resolve https://bugzilla.redhat.com/show_bug.cgi?id=667459
Reported-and-tested-by: Mathieu Chouquet-Stringer <mathieu-acct@csetco.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
net/mac80211/agg-tx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index f935490..72ab63d 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -138,7 +138,7 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
sta->sta.addr, tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
- del_timer_sync(&tid_tx->addba_resp_timer);
+ del_timer(&tid_tx->addba_resp_timer);
state = &sta->ampdu_mlme.tid_state_tx[tid];
--
1.7.3.4
^ permalink raw reply related
* [PATCH] hostap_cs: fix sleeping function called from invalid context
From: Stanislaw Gruszka @ 2011-01-10 11:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Dominik Brodowski, Tim Gardner, stable
pcmcia_request_irq() and pcmcia_enable_device() are intended
to be called from process context (first function allocate memory
with GFP_KERNEL, second take a mutex). We can not take spin lock
and call them.
It's safe to move spin lock after pcmcia_enable_device() as we
still hold off IRQ until dev->base_addr is 0 and driver will
not proceed with interrupts when is not ready.
Patch resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=643758
Reported-and-tested-by: rbugz@biobind.com
Cc: stable@kernel.org # 2.6.34+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
Stable note: patch does not apply on 2.6.34 and 2.6.35,
I will post separate patches when this one gets mainline
drivers/net/wireless/hostap/hostap_cs.c | 15 ++++++---------
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
index bd8a413..2176ede 100644
--- a/drivers/net/wireless/hostap/hostap_cs.c
+++ b/drivers/net/wireless/hostap/hostap_cs.c
@@ -518,22 +518,21 @@ static int prism2_config(struct pcmcia_device *link)
hw_priv->link = link;
/*
- * Make sure the IRQ handler cannot proceed until at least
- * dev->base_addr is initialized.
+ * We enable IRQ here, but IRQ handler will not proceed
+ * until dev->base_addr is set below. This protect us from
+ * receive interrupts when driver is not initialized.
*/
- spin_lock_irqsave(&local->irq_init_lock, flags);
-
ret = pcmcia_request_irq(link, prism2_interrupt);
if (ret)
- goto failed_unlock;
+ goto failed;
ret = pcmcia_enable_device(link);
if (ret)
- goto failed_unlock;
+ goto failed;
+ spin_lock_irqsave(&local->irq_init_lock, flags);
dev->irq = link->irq;
dev->base_addr = link->resource[0]->start;
-
spin_unlock_irqrestore(&local->irq_init_lock, flags);
local->shutdown = 0;
@@ -546,8 +545,6 @@ static int prism2_config(struct pcmcia_device *link)
return ret;
- failed_unlock:
- spin_unlock_irqrestore(&local->irq_init_lock, flags);
failed:
kfree(hw_priv);
prism2_release((u_long)link);
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] rt2x00: Fix and fine-tune rf registers for RT3070/RT3071/RT3090
From: Ivo van Doorn @ 2011-01-10 10:28 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, users
In-Reply-To: <201101101127.45155.IvDoorn@gmail.com>
From: RA-Jay Hung <jay_hung@ralinktech.com>
Basically fix and fine-tune RT3070/RT3071/RT3090 chip RF initial value
when call rt2800_init_rfcsr
Signed-off-by: RA-Jay Hung <jay_hung@ralinktech.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800.h | 6 ++++++
drivers/net/wireless/rt2x00/rt2800lib.c | 25 +++++++++++++++++--------
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index 4c55e85..c7e615c 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -1805,6 +1805,12 @@ struct mac_iveiv_entry {
#define RFCSR30_RF_CALIBRATION FIELD8(0x80)
/*
+ * RFCSR 31:
+ */
+#define RFCSR31_RX_AGC_FC FIELD8(0x1f)
+#define RFCSR31_RX_H20M FIELD8(0x20)
+
+/*
* RF registers
*/
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index e2a528d..a25be62 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2436,6 +2436,10 @@ static u8 rt2800_init_rx_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field8(&bbp, BBP4_BANDWIDTH, 2 * bw40);
rt2800_bbp_write(rt2x00dev, 4, bbp);
+ rt2800_rfcsr_read(rt2x00dev, 31, &rfcsr);
+ rt2x00_set_field8(&rfcsr, RFCSR31_RX_H20M, bw40);
+ rt2800_rfcsr_write(rt2x00dev, 31, rfcsr);
+
rt2800_rfcsr_read(rt2x00dev, 22, &rfcsr);
rt2x00_set_field8(&rfcsr, RFCSR22_BASEBAND_LOOPBACK, 1);
rt2800_rfcsr_write(rt2x00dev, 22, rfcsr);
@@ -2510,7 +2514,7 @@ static int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
- rt2800_rfcsr_write(rt2x00dev, 7, 0x70);
+ rt2800_rfcsr_write(rt2x00dev, 7, 0x60);
rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
rt2800_rfcsr_write(rt2x00dev, 10, 0x41);
rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
@@ -2602,12 +2606,12 @@ static int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_register_write(rt2x00dev, LDO_CFG0, reg);
} else if (rt2x00_rt(rt2x00dev, RT3071) ||
rt2x00_rt(rt2x00dev, RT3090)) {
+ rt2800_rfcsr_write(rt2x00dev, 31, 0x14);
+
rt2800_rfcsr_read(rt2x00dev, 6, &rfcsr);
rt2x00_set_field8(&rfcsr, RFCSR6_R2, 1);
rt2800_rfcsr_write(rt2x00dev, 6, rfcsr);
- rt2800_rfcsr_write(rt2x00dev, 31, 0x14);
-
rt2800_register_read(rt2x00dev, LDO_CFG0, ®);
rt2x00_set_field32(®, LDO_CFG0_BGSEL, 1);
if (rt2x00_rt_rev_lt(rt2x00dev, RT3071, REV_RT3071E) ||
@@ -2619,6 +2623,10 @@ static int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2x00_set_field32(®, LDO_CFG0_LDO_CORE_VLEVEL, 0);
}
rt2800_register_write(rt2x00dev, LDO_CFG0, reg);
+
+ rt2800_register_read(rt2x00dev, GPIO_SWITCH, ®);
+ rt2x00_set_field32(®, GPIO_SWITCH_5, 0);
+ rt2800_register_write(rt2x00dev, GPIO_SWITCH, reg);
} else if (rt2x00_rt(rt2x00dev, RT3390)) {
rt2800_register_read(rt2x00dev, GPIO_SWITCH, ®);
rt2x00_set_field32(®, GPIO_SWITCH_5, 0);
@@ -2670,10 +2678,11 @@ static int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_rfcsr_read(rt2x00dev, 17, &rfcsr);
rt2x00_set_field8(&rfcsr, RFCSR17_TX_LO1_EN, 0);
- if (rt2x00_rt_rev_lt(rt2x00dev, RT3071, REV_RT3071E) ||
+ if (rt2x00_rt(rt2x00dev, RT3070) ||
+ rt2x00_rt_rev_lt(rt2x00dev, RT3071, REV_RT3071E) ||
rt2x00_rt_rev_lt(rt2x00dev, RT3090, REV_RT3090E) ||
rt2x00_rt_rev_lt(rt2x00dev, RT3390, REV_RT3390E)) {
- if (test_bit(CONFIG_EXTERNAL_LNA_BG, &rt2x00dev->flags))
+ if (!test_bit(CONFIG_EXTERNAL_LNA_BG, &rt2x00dev->flags))
rt2x00_set_field8(&rfcsr, RFCSR17_R, 1);
}
rt2x00_eeprom_read(rt2x00dev, EEPROM_TXMIXER_GAIN_BG, &eeprom);
@@ -2686,6 +2695,7 @@ static int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
if (rt2x00_rt(rt2x00dev, RT3090)) {
rt2800_bbp_read(rt2x00dev, 138, &bbp);
+ /* Turn off unused DAC1 and ADC1 to reduce power consumption */
rt2x00_eeprom_read(rt2x00dev, EEPROM_NIC_CONF0, &eeprom);
if (rt2x00_get_field16(eeprom, EEPROM_NIC_CONF0_RXPATH) == 1)
rt2x00_set_field8(&bbp, BBP138_RX_ADC1, 0);
@@ -2719,10 +2729,9 @@ static int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 21, rfcsr);
}
- if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT3071)) {
+ if (rt2x00_rt(rt2x00dev, RT3070)) {
rt2800_rfcsr_read(rt2x00dev, 27, &rfcsr);
- if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F) ||
- rt2x00_rt_rev_lt(rt2x00dev, RT3071, REV_RT3071E))
+ if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F))
rt2x00_set_field8(&rfcsr, RFCSR27_R1, 3);
else
rt2x00_set_field8(&rfcsr, RFCSR27_R1, 0);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] rt2x00: Fix radio off hang issue for PCIE interface
From: Ivo van Doorn @ 2011-01-10 10:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, users
From: RA-Jay Hung <jay_hung@ralinktech.com>
PCI/PCIE radio off behavior is different from SOC/USB.
They mainly use MCU command to disable DMA, TX/RX and enter power saving mode.
Signed-off-by: RA-Jay Hung <jay_hung@ralinktech.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 6 -----
drivers/net/wireless/rt2x00/rt2800pci.c | 36 ++++++++----------------------
2 files changed, 10 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 54917a2..e2a528d 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2810,10 +2810,7 @@ void rt2800_disable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 0);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_DMA_BUSY, 0);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 0);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_RX_DMA_BUSY, 0);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_WRITEBACK_DONE, 1);
rt2800_register_write(rt2x00dev, WPDMA_GLO_CFG, reg);
/* Wait for DMA, ignore error */
@@ -2823,9 +2820,6 @@ void rt2800_disable_radio(struct rt2x00_dev *rt2x00dev)
rt2x00_set_field32(®, MAC_SYS_CTRL_ENABLE_TX, 0);
rt2x00_set_field32(®, MAC_SYS_CTRL_ENABLE_RX, 0);
rt2800_register_write(rt2x00dev, MAC_SYS_CTRL, reg);
-
- rt2800_register_write(rt2x00dev, PWR_PIN_CFG, 0);
- rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0);
}
EXPORT_SYMBOL_GPL(rt2800_disable_radio);
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index aa97971..bfc2fc5 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -475,39 +475,23 @@ static int rt2800pci_enable_radio(struct rt2x00_dev *rt2x00dev)
static void rt2800pci_disable_radio(struct rt2x00_dev *rt2x00dev)
{
- u32 reg;
-
- rt2800_disable_radio(rt2x00dev);
-
- rt2800_register_write(rt2x00dev, PBF_SYS_CTRL, 0x00001280);
-
- rt2800_register_read(rt2x00dev, WPDMA_RST_IDX, ®);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX0, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX1, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX2, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX3, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX4, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX5, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DRX_IDX0, 1);
- rt2800_register_write(rt2x00dev, WPDMA_RST_IDX, reg);
-
- rt2800_register_write(rt2x00dev, PBF_SYS_CTRL, 0x00000e1f);
- rt2800_register_write(rt2x00dev, PBF_SYS_CTRL, 0x00000e00);
+ if (rt2x00_is_soc(rt2x00dev)) {
+ rt2800_disable_radio(rt2x00dev);
+ rt2800_register_write(rt2x00dev, PWR_PIN_CFG, 0);
+ rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0);
+ }
}
static int rt2800pci_set_state(struct rt2x00_dev *rt2x00dev,
enum dev_state state)
{
- /*
- * Always put the device to sleep (even when we intend to wakeup!)
- * if the device is booting and wasn't asleep it will return
- * failure when attempting to wakeup.
- */
- rt2800_mcu_request(rt2x00dev, MCU_SLEEP, 0xff, 0xff, 2);
-
if (state == STATE_AWAKE) {
- rt2800_mcu_request(rt2x00dev, MCU_WAKEUP, TOKEN_WAKUP, 0, 0);
+ rt2800_mcu_request(rt2x00dev, MCU_WAKEUP, TOKEN_WAKUP, 0, 0x02);
rt2800pci_mcu_status(rt2x00dev, TOKEN_WAKUP);
+ } else if (state == STATE_SLEEP) {
+ rt2800_register_write(rt2x00dev, H2M_MAILBOX_STATUS, 0xffffffff);
+ rt2800_register_write(rt2x00dev, H2M_MAILBOX_CID, 0xffffffff);
+ rt2800_mcu_request(rt2x00dev, MCU_SLEEP, 0x01, 0xff, 0x01);
}
return 0;
--
1.7.2.3
^ permalink raw reply related
* Re: 2.6.37-rc8: Reported regressions from 2.6.36
From: David Miller @ 2011-01-10 8:08 UTC (permalink / raw)
To: rjw
Cc: linux-kernel, maciej.rutecki, florian, akpm, torvalds,
kernel-testers, netdev, linux-acpi, linux-pm, linux-scsi,
linux-wireless, dri-devel
In-Reply-To: <96DQe4a_2tH.A.cFB.l27GNB@chimera>
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
> Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
> Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
> Date : 2010-12-08 21:09 (22 days old)
> Message-ID : <4CFFF3F3.90100@goop.org>
> References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
This bug is intended to be fixed by:
commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb
Author: David S. Miller <davem@davemloft.net>
Date: Wed Jan 5 15:38:53 2011 -0800
af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks.
unix_release() can asynchornously set socket->sk to NULL, and
it does so without holding the unix_state_lock() on "other"
during stream connects.
However, the reverse mapping, sk->sk_socket, is only transitioned
to NULL under the unix_state_lock().
Therefore make the security hooks follow the reverse mapping instead
of the forward mapping.
Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Kernel 2.6.37-rc5 rc7 Oops
From: David Miller @ 2011-01-10 8:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: torvalds, alex.arnautu96, linux-kernel, linux-wireless
In-Reply-To: <1293652965.7150.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Dec 2010 21:02:45 +0100
> Le mercredi 29 décembre 2010 à 11:23 -0800, Linus Torvalds a écrit :
>> On Wed, Dec 29, 2010 at 4:26 AM, Alex Arnautu <alex.arnautu96@gmail.com> wrote:
>> >
>> > I get an oops with 2.6.37-rc5 and 2.6.37-rc7-git1.
>> > http://www.fotoshack.us/fotos/19044P271210_15.14_[01].jpg
>>
>> Hmm. Davem added to the list of people involved. This _may_ be fixed
>> by the "always clone skbs" commit in -rc8 (commit 173021072), but
>> David can make a better judgment call.
>>
>
> Very unlikely, as commit 173021072 only fix a bug in case mirred is
> used.
This should be taken to the wireless list (now CC:'d) as the rt2xxx
driver and the wireless stack are both in that backtrace.
^ 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