* [PATCH 3/3] wlcore: limit base for output buffer in dev_mem_read
From: Vladimir Murzin @ 2013-09-12 15:32 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: coelho, linville, Vladimir Murzin
In-Reply-To: <1378999943-1968-1-git-send-email-murzin.v@gmail.com>
dev_mem_read tries to speed up things a bit by limiting output
buffer which can not exceed WLCORE_MAX_BLOCK_SIZE. However,
WLCORE_MAX_BLOCK_SIZE is based on PAGE_SIZE which may vary.
Use 4K size base for buffer explicitly.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
drivers/net/wireless/ti/wlcore/debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c b/drivers/net/wireless/ti/wlcore/debugfs.c
index e17630c..6b413a7 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -38,7 +38,8 @@
/* ms */
#define WL1271_DEBUGFS_STATS_LIFETIME 1000
-#define WLCORE_MAX_BLOCK_SIZE ((size_t)(4*PAGE_SIZE))
+#define WLCORE_PAGE_SIZE 4096
+#define WLCORE_MAX_BLOCK_SIZE ((size_t)(4*WLCORE_PAGE_SIZE))
/* debugfs macros idea from mac80211 */
int wl1271_format_buffer(char __user *userbuf, size_t count,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/8] ath10k: boot, bmi and mac debug message cleanup
From: Kalle Valo @ 2013-09-12 16:12 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130908145435.3136.49168.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Simple message log cleanup. Please review.
>
> ---
>
> Kalle Valo (8):
> ath10k: add BMI log level
> ath10k: rename ATH10K_DBG_CORE to BOOT
> ath10k: cleanup debug messages in core.c
> ath10k: add boot debug messages to pci.c and ce.c
> ath10k: add boot debug messages to htc.c
> ath10k: add boot messages to htt.c
> ath10k: clean mac.c debug messages
> ath10k: print phymode as a string
Applied.
Kalle
^ permalink raw reply
* Re: [PATCH] ath10k: Calculate correct peer PHY mode for VHT
From: Kalle Valo @ 2013-09-12 16:13 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130908151955.9228.15022.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> The peer PHY mode for 11ac operation needs to be determined
> properly based on the channel bandwidth being used. Fix
> this so that the proper mode is given to the firmware.
>
> kvalo: earlier we used 11na-ht20 in STA mode for 11ac AP peer, this
> patch changes that to 11ac-vht80. I didn't notice any change in
> throughput in my tests, but nevertheless it's the right thing
> to do.
>
> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Applied. Thanks Sujith.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: delete struct ce_sendlist
From: Kalle Valo @ 2013-09-12 16:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130908153611.4572.43965.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> struct ce_sendlist is useless as we always add just one buffer onto it.
> And most importantly, it's ugly as it doesn't use skb properly.
>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 06/12] wireless: ath10k: remove unnecessary pci_set_drvdata()
From: Kalle Valo @ 2013-09-12 16:23 UTC (permalink / raw)
To: Jingoo Han; +Cc: 'John W. Linville', linux-wireless, ath10k
In-Reply-To: <00b701ceae18$69cd1860$3d674920$%han@samsung.com>
Jingoo Han <jg1.han@samsung.com> writes:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/7] ath10k: improve TX path
From: Kalle Valo @ 2013-09-12 16:48 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1378821003-22925-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> This patchset addresses two issues:
>
> * system/userspace starvation on heavy briding
> UDP TX
> * unstable/inconsistent UDP TX throughput
>
> In short the patchset simplifies TX path by
> removing HTC TX workers, makes WMI commands block
> and makes ath10k more responsive to queues
> becoming full. This contributes to both improved
> throughput and makes the system more responsive
> under heavy UDP TX load.
This looks very good, it's great that we can get rid of the TX workers.
Please submit v2 and I'll apply these.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 5/7] ath10k: improve beacon submission latency
From: Kalle Valo @ 2013-09-12 16:47 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1378821003-22925-6-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> The patch prevents beacon misses in some case of
> heavy load on a system.
>
> If a beacon can't be transmitted directly from an
> SWBA event it will be left in arvif->beacon and
> transmission will be retried once TX credits
> become available.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> static void ath10k_wmi_op_ep_tx_credits(struct ath10k *ar)
> {
> + ath10k_wmi_tx_beacons_nowait(ar);
> wake_up(&ar->wmi.tx_credits_wq);
> }
>
> @@ -131,6 +174,7 @@ static int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb,
> int ret = -EINVAL;
>
> wait_event_timeout(ar->wmi.tx_credits_wq, ({
> + ath10k_wmi_tx_beacons_nowait(ar);
> ret = ath10k_wmi_cmd_send_nowait(ar, skb, cmd_id);
> (ret != -EAGAIN);
Please add a short comment to both calls of
ath10k_wmi_tx_beacons_nowait(). Something like "first transmit all
pending beacons" or similar.
--
Kalle Valo
^ permalink raw reply
* iee80211_scan_work crash in 3.11.0+ kernel.
From: Ben Greear @ 2013-09-12 18:32 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
This kernel has our standard set of patches, but nothing much beyond
what we ran in the 3.9 kernel for some time without seeing this particular
crash, so I am thinking it might be something new in 3.11. I do have my
scan-one-channel patch in this tree, so it's possible it is somehow
to blame.
This happened on restart of our user-space app, which would have been
restarting supplicant/hostapd and re-configuring interfaces. It should
not have been actually creating or deleting any network devices as they
were already created.
This crash was in a kernel w/out debugging symbols, but after re-building with
debugging, it decodes to here:
(gdb) l *(ieee80211_scan_work+0x321)
0x8e11 is in ieee80211_scan_work (/home/greearb/git/linux-3.11.dev.y/net/mac80211/scan.c:608).
603 {
604 /*
605 * TODO: channel switching also consumes quite some time,
606 * add that delay as well to get a better estimation
607 */
608 if (chan->flags & IEEE80211_CHAN_PASSIVE_SCAN)
609 return IEEE80211_PASSIVE_CHANNEL_TIME;
610 return IEEE80211_PROBE_DELAY + IEEE80211_CHANNEL_TIME;
611 }
612
(gdb)
Maybe scan_channel_idx is out of bounds somehow?
My 3.11 tree is at:
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.11.dev.y/.git;a=summary
[518743.539126] BUG: unable to handle kernel paging request at 00003b43
[518743.540019] IP: [<f861be11>] ieee80211_scan_work+0x321/0x3e0 [mac80211]
[518743.540019] *pdpt = 0000000016113001 *pde = 0000000000000000
[518743.540019] Oops: 0000 [#1] PREEMPT SMP
[518743.540019] Modules linked in: ipt_MASQUERADE iptable_nat iptable_raw xt_CT veth nfnetlink_log nfnetlink nf_conntrack]
[518743.540019] CPU: 0 PID: 565 Comm: kworker/u4:0 Tainted: G C O 3.11.0+ #20
[518743.645757] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 05/31/20
[518743.645757] Workqueue: phy0 ieee80211_scan_work [mac80211]
[518743.645757] task: f1f54d40 ti: effd8000 task.ti: effd8000
[518743.645757] EIP: 0060:[<f861be11>] EFLAGS: 00010202 CPU: 0
[518743.645757] EIP is at ieee80211_scan_work+0x321/0x3e0 [mac80211]
[518743.645757] EAX: 00003b3b EBX: f463c360 ECX: 1ee6d214 EDX: f465b400
[518743.645757] ESI: 00000000 EDI: 00000001 EBP: effd9ef8 ESP: effd9ec8
[518743.645757] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[518743.645757] CR0: 8005003b CR2: 00003b43 CR3: 2ff88000 CR4: 000007e0
[518743.645757] Stack:
[518743.645757] 0001d7cb f79db400 f463cf2c f463ceb0 f463ce78 f463ce80 1ee6d110 f536eaec
[518743.645757] 00000000 f463cf2c f1ff1a80 00000080 effd9f30 c0471d1a c0487f9d f79db400
[518743.645757] f1f54d40 c0c3e980 efc7eb2a f496f695 f496f600 00001000 f5004400 f1ff1a80
[518743.645757] Call Trace:
[518743.645757] [<c0471d1a>] process_one_work+0x11a/0x400
[518743.645757] [<c0487f9d>] ? try_to_wake_up+0x1bd/0x220
[518743.645757] [<c0472f5f>] worker_thread+0xff/0x3c0
[518743.645757] [<c0477ff4>] kthread+0xa4/0xb0
[518743.645757] [<c0472e60>] ? manage_workers+0x2a0/0x2a0
[518743.645757] [<c0480000>] ? SyS_setgroups+0xb0/0xf0
[518743.645757] [<c09d35b7>] ret_from_kernel_thread+0x1b/0x28
[518743.645757] [<c0477f50>] ? kthread_freezable_should_stop+0x50/0x50
[518743.645757] Code: 01 00 00 00 8b 45 e4 e8 8e cf 3a c8 8b 8b c4 0b 00 00 8b 93 94 0b 00 00 89 4d e8 8b 83 a4 0b 00 00 0
[518743.645757] EIP: [<f861be11>] ieee80211_scan_work+0x321/0x3e0 [mac80211] SS:ESP 0068:effd9ec8
[518743.645757] CR2: 0000000000003b43
[518743.963077] ---[ end trace 7b4bcf9767616f77 ]---
[518743.971245] BUG: unable to handle kernel paging request at ffffffec
[518743.972018] IP: [<c0477a3f>] kthread_data+0xf/0x20
[518743.972018] *pdpt = 0000000000d85001 *pde = 00000000379fd067 *pte = 0000000000000000
[518743.972018] Oops: 0000 [#2] PREEMPT SMP
[518743.972018] Modules linked in: ipt_MASQUERADE iptable_nat iptable_raw xt_CT veth nfnetlink_log nfnetlink nf_conntrack]
[518743.972018] CPU: 0 PID: 565 Comm: kworker/u4:0 Tainted: G D C O 3.11.0+ #20
[518743.972018] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 05/31/20
[518743.972018] task: f1f54d40 ti: effd8000 task.ti: effd8000
[518743.972018] EIP: 0060:[<c0477a3f>] EFLAGS: 00010002 CPU: 0
[518743.972018] EIP is at kthread_data+0xf/0x20
[518743.972018] EAX: 00000000 EBX: 00000000 ECX: f79db400 EDX: 00000000
[518743.972018] ESI: 00000000 EDI: f1f54d40 EBP: effd9c90 ESP: effd9c88
[518743.972018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[518743.972018] CR0: 8005003b CR2: 00000014 CR3: 36fee000 CR4: 000007e0
[518743.972018] Stack:
[518743.972018] c04704e0 f1f54d40 effd9d20 c09cac99 c0c937d4 00000086 00000086 effd9cc4
[518743.972018] f1f54d40 c0d7e400 c0d7e400 c0d7e400 c0d7e400 f5b10b80 00000235 f79db400
[518743.972018] f1f54d40 effd9cec 00000246 c0457098 00000246 0035df80 f1f54d40 f1f54d40
[518743.972018] Call Trace:
[518743.972018] [<c04704e0>] ? wq_worker_sleeping+0x10/0x80
[518743.972018] [<c09cac99>] __schedule+0x5c9/0x7d0
[518743.972018] [<c0457098>] ? __cleanup_sighand+0x28/0x30
[518743.972018] [<c04de8bc>] ? call_rcu+0x1c/0x20
[518743.972018] [<c045a87f>] ? release_task+0x2bf/0x410
[518743.972018] [<c04c2901>] ? cgroup_exit+0x31/0xf0
[518743.972018] [<c09cb043>] schedule+0x23/0x60
[518743.972018] [<c045bb77>] do_exit+0x5f7/0x980
[518743.972018] [<c09c86f3>] ? printk+0x3d/0x3f
[518743.972018] [<c09cdf16>] oops_end+0x96/0xd0
[518743.972018] [<c044bb38>] no_context+0xd8/0x1f0
[518743.972018] [<c044bd08>] __bad_area_nosemaphore+0xb8/0x160
[518743.972018] [<c044bdc7>] bad_area_nosemaphore+0x17/0x20
[518743.972018] [<c09d017d>] __do_page_fault+0x33d/0x4a0
[518743.972018] [<c0490f05>] ? dequeue_task_fair+0x65/0x590
[518743.972018] [<c048c0b6>] ? __dequeue_entity+0x26/0x50
[518743.972018] [<c0410b0e>] ? __switch_to+0xee/0x3b0
[518743.972018] [<c09d02e0>] ? __do_page_fault+0x4a0/0x4a0
[518743.972018] [<c09d02ed>] do_page_fault+0xd/0x10
[518743.972018] [<c09cd6bf>] error_code+0x67/0x6c
[518743.972018] [<f861be11>] ? ieee80211_scan_work+0x321/0x3e0 [mac80211]
[518743.972018] [<c0471d1a>] process_one_work+0x11a/0x400
[518743.972018] [<c0487f9d>] ? try_to_wake_up+0x1bd/0x220
[518743.972018] [<c0472f5f>] worker_thread+0xff/0x3c0
[518743.972018] [<c0477ff4>] kthread+0xa4/0xb0
[518743.972018] [<c0472e60>] ? manage_workers+0x2a0/0x2a0
[518743.972018] [<c0480000>] ? SyS_setgroups+0xb0/0xf0
[518743.972018] [<c09d35b7>] ret_from_kernel_thread+0x1b/0x28
[518743.972018] [<c0477f50>] ? kthread_freezable_should_stop+0x50/0x50
[518743.972018] Code: 8d 74 26 00 64 a1 ac 7f d7 c0 8b 80 9c 02 00 00 5d 8b 40 e4 c1 e8 02 83 e0 01 c3 90 55 89 e5 3e 8d e
[518743.972018] EIP: [<c0477a3f>] kthread_data+0xf/0x20 SS:ESP 0068:effd9c88
[518743.972018] CR2: 00000000ffffffec
[518743.972018] ---[ end trace 7b4bcf9767616f78 ]---
[518743.972018] Fixing recursive fault but reboot is needed!
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Daniel Wagner @ 2013-09-12 18:38 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
Hi John,
On 09/09/2013 09:23 PM, John W. Linville wrote:
> On Thu, Sep 05, 2013 at 11:04:52AM -0500, Dan Williams wrote:
>> On Thu, 2013-09-05 at 09:39 -0400, John W. Linville wrote:
>>> On Thu, Aug 08, 2013 at 03:04:29PM -0400, John W. Linville wrote:
>>>> Sorry, forgot to copy linux-bluetooth and linux-nfc...
>>>>
>>>> On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
>>>>> Greetings!
>>>>>
>>>>> This is a reminder that we will have a Linux Wireless Mini-Summit in
>>>>> New Orleans this year on 19-20 September. This will immediately follow
>>>>> LinuxCon and will run concurrently with Linux Plumber's Conference.
>>>>> This event includes Linux developers for wireless LAN (802.11),
>>>>> Bluetooth, and NFC technologies. Both kernel and userland developers
>>>>> are welcomed and heartily encouraged to attend!
>>>>>
>>>>> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>>>>>
>>>>> The link above is a Wiki. We are using it to collect discussion
>>>>> topics and to negotiate agenda/scheduling options for the event.
>>>>> Please go there to record your intent to attend the event and to
>>>>> propopse topics for discussion.
>>>>>
>>>>> Please be aware that in order to attend the event above one must
>>>>> register for either LinuxCon or for Linux Plumbers Conference.
>>>>> Act now, before those events fill-up and close their registrations!
>>>>>
>>>>> We are allotted one "large" room (up to ~80 people "theater style"), and
>>>>> two "small" rooms (up to ~25 people) for this event. Based on history
>>>>> and the numbers of contributors, the larger room will primarily be
>>>>> for the 802.11 discussions and any "plenary" topics while the smaller
>>>>> rooms will be for Bluetooth, NFC, and any "breakout" topics.
>>>>>
>>>>> So...thoughts? Topics to discuss?
>>>
>>> Ping? We're now just 2 weeks away!
>>>
>>> Is our topic list complete? It looks a bit light...
>>>
>>> Anyone have any input on scheduling the topics? Are there any
>>> overlapping LPC sessions that it would make sense to work around?
>>
>> I'm attending though I haven't put my name on the wiki yet.
>>
>> Random thoughts; it doesn't look like any of these are covered in the
>> regular LinuxConf or LPC sessions.
>>
>> 1) State of the Union (maybe by multiple people in the same session per
>> their expertise), since perhaps not everyone doing eg 802.11 stuff knows
>> what's happening in BT or NFC land, or not everyone working on a
>> specific driver may know what new stuff their driver might need to be
>> fixed up for. Maybe 5 minutes or less for things like:
>>
>> * what's under the most active development right now?
>> * upcoming new driver, hardware, and new capabilities
>> * new 802.11 standards
>> * and what's coming up in the next year from the standards orgs
>> * what people will start working on soon
>> * what will 3.13 or 3.14 look like from a wireless perspective?
>> * 11s mesh status?
>> * anything interesting in wpa_supplicant land?
>> * anything new/interesting on the Android front?
>>
>> 2) Bluetooth - update about what's new and what's coming up in Bluez
>> land, and interaction with kernel 802.11 if any,
>>
>> 3) NFC - update about what's new and what's coming up in NFC land, where
>> it's getting used, what the stack looks like
>>
>> 4) What are users having the most problems with and how these problems
>> be fixed better/more quickly? Are they driver bugs? Are they stack
>> bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
>> development processes that's not working as smoothly as it could be?
>
> Thanks, Dan -- those all look like decent discussion points.
> I've added most of the points above to the topic list:
>
> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>
> Now, we need a few volunteers...
>
> Gustavo, can you do a session on Bluetooth developments?
>
> Samuel, can you cover NFC?
>
> Jouni, would you mind doing your usual update on the standards
> activities? Also, is there anything new/interesting to report on
> wpa_suppliant and/or hostapd?
>
> Johannes, would you cover your vision for mac80211 for the next year
> or so? Anything in progress now that needs to be discussed?
>
> Who should cover any Android topics?
>
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
>
> Seth, Stanislaw, etc -- anyone want to cover issues dealing with
> supporting wireless in distributions?
>
> Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> to share?
Not much news from the user front, though I could give a short
update what's happening on ConnMan if you like.
cheers,
daniel
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: John W. Linville @ 2013-09-12 18:48 UTC (permalink / raw)
To: Daniel Wagner
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <52320A22.1040609@monom.org>
On Thu, Sep 12, 2013 at 08:38:26PM +0200, Daniel Wagner wrote:
> Hi John,
>
> On 09/09/2013 09:23 PM, John W. Linville wrote:
> >Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> >to share?
>
> Not much news from the user front, though I could give a short
> update what's happening on ConnMan if you like.
I think that Patrik Flykt is going to handle that...
Surely there is some infotainment angle to be discussed?? :-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Dan Williams @ 2013-09-12 19:26 UTC (permalink / raw)
To: John W. Linville
Cc: Daniel Wagner, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130912184835.GC14253@tuxdriver.com>
On Thu, 2013-09-12 at 14:48 -0400, John W. Linville wrote:
> On Thu, Sep 12, 2013 at 08:38:26PM +0200, Daniel Wagner wrote:
> > Hi John,
> >
> > On 09/09/2013 09:23 PM, John W. Linville wrote:
>
> > >Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> > >to share?
> >
> > Not much news from the user front, though I could give a short
> > update what's happening on ConnMan if you like.
>
> I think that Patrik Flykt is going to handle that...
>
> Surely there is some infotainment angle to be discussed?? :-)
I can do a short update on NetworkManager too, but there's no
infotainment angle to it at all :)
Dan
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Daniel Wagner @ 2013-09-12 19:31 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130912184835.GC14253@tuxdriver.com>
On 09/12/2013 08:48 PM, John W. Linville wrote:
>> On 09/09/2013 09:23 PM, John W. Linville wrote:
>>> Dan Williams, Daniel Wagner, etc -- anyone got some user stories
>>> to share?
>>
>> Not much news from the user front, though I could give a short
>> update what's happening on ConnMan if you like.
>
> I think that Patrik Flykt is going to handle that...
Great.
> Surely there is some infotainment angle to be discussed?? :-)
Sure, if that is of any interest. There is also the automotive
uconf during the LPC which wireless (BT and Wifi) is shortly
discussed. Repeating/summarizing wouldn't be a problem, I guess.
cheers,
daniel
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Timothy Rundle @ 2013-09-12 23:02 UTC (permalink / raw)
Cc: linux-wireless
In-Reply-To: <5230CDF1.1040905@lwfinger.net>
I finally got some free time to go through all the patches. My results
were similar to Mark's, but I do not get the watchdog messages, though
I am pretty sure watchdog is disabled on my PC. I did even try
installing openSUSE 12.3, but did not have any success. It didn't
even find my wireless network. I manually configured the network via
network-manager, but still no luck.
Let me know if you need anything else from me.
On Wed, Sep 11, 2013 at 4:09 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 09/10/2013 03:04 PM, Mark Cave-Ayland wrote:
>
>> Interesting. Perhaps there is something different in the initial
>> programming of
>> the radio that causes it to crash on my particular hardware revision? As
>> before,
>> please let me know if there is anything else you require.
>
>
> From the log data, you have the same revision as I do.
>
> I am now running a kernel built with your configuration. I needed to make a
> couple of changes as it did not have one of the modules my disk system
> needs, and nouveau caused kernel panics, but we are now operational. Outside
> of the whole system being slow due to only one 2.0 GHz CPU, the wireless
> connection seems to be stable. At least, there have been no disconnects in
> the first half hour.
>
> Larry
>
>
^ permalink raw reply
* start_next_roc splat in 3.11.0+
From: Ben Greear @ 2013-09-12 23:08 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Was bringing up 128 stations configured for HotSpot 2.0 (wpa2, 802.1x, etc)
on a relatively slow machine.
I doubt it has much to do with how they are configured however.
The warning that hit is here:
roc = list_first_entry(&local->roc_list, struct ieee80211_roc_work,
list);
if (WARN_ON_ONCE(roc->started))
return;
This is running my normal set of patches.
[ 133.530413] ------------[ cut here ]------------
[ 133.541409] WARNING: CPU: 1 PID: 7246 at /home/greearb/git/linux-3.11.dev.y/net/mac80211/offchannel.c:269 ieee80211_start_next_roc+0x1f1/0x210 [mac80211]()
[ 133.565902] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 8021q garp stp mrp llc fuse macvlan wanlink(O) pktgen
iTCO_wdt gpio_ich iTCO_vendor_support arc4 pcspkr serio_raw i2c_i801 snd_hda_codec_realtek lpc_ich joydev ath9k_htc ath9k snd_hda_intel ath9k_common
snd_hda_codec snd_hwdep ath9k_hw ath mac80211 snd_seq snd_seq_device cfg80211 snd_pcm rfkill r8169 mii snd_page_alloc snd_timer snd soundcore uinput i915 video
i2c_algo_bit drm_kms_helper drm i2c_core [last unloaded: iptable_nat]
[ 133.643933] CPU: 1 PID: 7246 Comm: ip Tainted: G C O 3.11.0+ #21
[ 133.659832] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 05/31/2010
[ 133.679989] 0000010d efa6b964 c09c877c f849d0e4 efa6b994 c0459804 c0b65c08 00000001
[ 133.694895] 00001c4e f849d0e4 0000010d f844a711 f844a711 f7774360 f7774360 00000001
[ 133.708929] efa6b9a4 c0459842 00000009 00000000 efa6b9dc f844a711 efd14c30 f7774e78
[ 133.723050] Call Trace:
[ 133.731352] [<c09c877c>] dump_stack+0x4c/0x78
[ 133.741687] [<c0459804>] warn_slowpath_common+0x84/0xa0
[ 133.752888] [<f844a711>] ? ieee80211_start_next_roc+0x1f1/0x210 [mac80211]
[ 133.765706] [<f844a711>] ? ieee80211_start_next_roc+0x1f1/0x210 [mac80211]
[ 133.778334] [<c0459842>] warn_slowpath_null+0x22/0x30
[ 133.789153] [<f844a711>] ieee80211_start_next_roc+0x1f1/0x210 [mac80211]
[ 133.801612] [<f846879e>] ? ieee80211_queue_work+0x2e/0x40 [mac80211]
[ 133.813715] [<f848759d>] ? ieee80211_mesh_notify_scan_completed+0x7d/0x90 [mac80211]
[ 133.827250] [<f844983a>] __ieee80211_scan_completed+0xca/0x1f0 [mac80211]
[ 133.839946] [<f8449a49>] ieee80211_scan_cancel+0xe9/0x190 [mac80211]
[ 133.852084] [<c0459fa8>] ? put_online_cpus+0x48/0x70
[ 133.862866] [<f8453547>] ieee80211_do_stop+0x647/0x700 [mac80211]
[ 133.874749] [<c09009d6>] ? dev_deactivate_many+0x1e6/0x210
[ 133.885858] [<f8453667>] ieee80211_stop+0x17/0x20 [mac80211]
[ 133.897063] [<c08e3049>] __dev_close_many+0x69/0xb0
[ 133.907875] [<c08fbe5e>] ? netpoll_rx_disable+0x3e/0x50
[ 133.918588] [<c08e30c6>] __dev_close+0x36/0x70
[ 133.928541] [<c08e2302>] __dev_change_flags+0x82/0x150
[ 133.939080] [<c0916554>] ? ip_local_deliver+0x44/0x90
[ 133.949514] [<c08e4033>] dev_change_flags+0x23/0x60
[ 133.959742] [<c08f17a4>] do_setlink+0x224/0x7a0
[ 133.969666] [<c06be142>] ? nla_parse+0x22/0xd0
[ 133.979333] [<c08f4b72>] rtnl_newlink+0x532/0x5b0
[ 133.989164] [<c06444fc>] ? security_capable+0x1c/0x30
[ 133.999259] [<c0461e4a>] ? ns_capable+0x2a/0x60
[ 134.008797] [<c08f2129>] rtnetlink_rcv_msg+0x179/0x1f0
[ 134.019120] [<c05596bd>] ? __kmalloc_track_caller+0x2d/0x170
[ 134.029897] [<c0515e66>] ? find_get_page+0x66/0xb0
[ 134.040175] [<c08d877b>] ? __alloc_skb+0x6b/0x180
[ 134.050340] [<c08f1fb0>] ? rtnetlink_rcv+0x30/0x30
[ 134.060039] [<c090b016>] netlink_rcv_skb+0x86/0xb0
[ 134.069626] [<c08f1f9c>] rtnetlink_rcv+0x1c/0x30
[ 134.078854] [<c090ad86>] netlink_unicast+0xe6/0x140
[ 134.088397] [<c090ba72>] netlink_sendmsg+0x242/0x620
[ 134.097907] [<c0452203>] ? __kunmap_atomic+0x83/0xa0
[ 134.107349] [<c051c780>] ? get_page_from_freelist+0x250/0x500
[ 134.117435] [<c08d147a>] sock_sendmsg+0xaa/0xe0
[ 134.126226] [<c08cf608>] ? copy_from_user+0x8/0x10
[ 134.135068] [<c08dba2b>] ? verify_iovec+0x5b/0xb0
[ 134.143761] [<c08d2285>] ___sys_sendmsg+0x2c5/0x2e0
[ 134.152498] [<c052244d>] ? lru_cache_add+0xd/0x10
[ 134.160935] [<c053adc3>] ? handle_pte_fault+0x493/0xae0
[ 134.169849] [<c08d7e30>] ? skb_dequeue+0x50/0x70
[ 134.178135] [<c053b601>] ? handle_mm_fault+0x1f1/0x300
[ 134.186733] [<c08d241e>] __sys_sendmsg+0x3e/0x70
[ 134.194841] [<c08d2466>] SyS_sendmsg+0x16/0x20
[ 134.202652] [<c08d27af>] SyS_socketcall+0x11f/0x2e0
[ 134.210877] [<c0566f7d>] ? ____fput+0xd/0x10
[ 134.218528] [<c09d364d>] sysenter_do_call+0x12/0x28
[ 134.226767] ---[ end trace 2b5f2f9c64702e82 ]---
[ 134.251401] ath: wiphy0: Failed to stop TX DMA, queues=0x005!
[ 134.280969] ath: wiphy0: Failed to stop TX DMA, queues=0x004!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [PATCH] check the power management bit in MAC Header on Action Frame.
From: 기상원 (SW Ki) @ 2013-09-13 3:22 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, C1-G2-6 Team
RGVhciBKb2hhbm5lcywNCg0KSSBoYXZlIGZvdW5kIG9uZSBwcm9ibGVtIGluIHRoZSBtYWM4MDIx
MSByeCByb3V0aW5lIGR1cmluZyBtYWtpbmcgdGhlIFdpRmktRGlyZWN0IENlcnRpZmljYXRpb24u
IA0KVGhlIFN0ZXAgNCBvZiA2LjEuOSBmb3IgIkdPVVQgaGFuZGxpbmcgUDJQIFByZXNlbnNjZSBS
ZXF1ZXN0IiBtdXN0IGhhdmUgZm9sbG93aW5nIHJlc3VsdC4NCsKgICJTTihTbmlmZmVyKTogUDJQ
IFByZXNlbnNjZSBSZXNwb25zZSBuZWVkcyB0byBjb21iYWNrIHdpdGhpbiAxMDBtcy4gSWYgbm8g
cmVzcG9uc2UgaXMgcmVjZWl2ZWQgd2l0aGluIHRoaXMgdGhpZSwgRkFJTCB0ZXN0LiINCg0KVW5m
b3J0dW5hdGVseSwgVGhlIEdPVVQgaGFzIFByZXNlbnNjZSBSZXNwb25zZSBwYWNrZXQgdHJhbnNt
aXNzaW9uIGFmdGVyIDIwMG1zLiBUaGVuIE91ciBEVVQgZG8gbm90IHBhc3MgdGhpcyB0ZXN0LiAu
DQoNClNvLCBJIGhhdmUgb2JzZXJ2ZWQgcGFja2V0cyB0aHJvdWdoIHNuaWZmZXIgZm9yIHRoaXMg
dGVzdCBzdGVwLg0KSSBzYXcgdGhlIE5VTEwgUGFja2V0IHRoYXQgaW5jbHVkZSB0aGUgcG93ZXIg
bWFuYWdlbWVudCBiaXQgc2V0IHRvICcxJyBiZWZvcmUgc2VuZGluZyB0aGUgUHJlc2Vuc2NlIFJl
cXVlc3QgdGhhdCBpbmNsdWRlIFBNIGJpdCBzZXQgdG8gJzAnLg0KKFRoZSB0aW1lIGludGVydmFs
IGJldHdlZW4gdHdvIHBhY2tldHMgaXMgYWJvdXQgMm1zLikNCg0KDQpkaWZmIC11ck4gb3JpZy9t
YWM4MDIxMS9yeC5jIG5ldy9tYWM4MDIxMS9yeC5jDQotLS0gb3JpZy9tYWM4MDIxMS9yeC5jwqAg
MjAxMy0wOS0xMyAxMjoxNzo1OS4wMDAwMDAwMDAgKzA5MDANCisrKyBuZXcvbWFjODAyMTEvcngu
Y8KgwqAgMjAxMy0wOS0xMyAxMjoxNzowMi4wMDAwMDAwMDAgKzA5MDANCkBAIC0xMzI1LDcgKzEz
MjUsNyBAQA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICogZG96ZS0+d2FrZSB0cmFuc2l0aW9uIGZvciB0aGUgcHJvYmUgcmVxdWVzdCwNCsKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAqIGFuZCB0aGF0IGlzIGNs
ZWFybHkgdW5kZXNpcmFibGUuDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgKi8NCi3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBpZiAoaWVlZTgwMjExX2lzX2RhdGEoaGRyLT5mcmFtZV9jb250cm9sKSAmJg0KK8KgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmICgoaWVlZTgwMjExX2lz
X2RhdGEoaGRyLT5mcmFtZV9jb250cm9sKSB8fCBpZWVlODAyMTFfaXNfYWN0aW9uKGhkci0+ZnJh
bWVfY29udHJvbCkpICYmDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgIWllZWU4MDIxMV9oYXNfcG0oaGRyLT5mcmFtZV9jb250cm9sKSkNCsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIGFwX3N0YV9wc19lbmQoc3RhKTsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9
IGVsc2Ugew0KDQoNCg0KSSBjYW4gc2VlIFByZXNlbnNjZSBSZXNwb25zZSB3aXRoaW4gMzBtcyBh
ZnRlciBhcHBseWluZyB0aGUgYmVsb3cgcGF0Y2guDQooVGhhdCBpcyBzdWNjZXNzIHJlc3VsdCBm
b3IgU3RlcCA0IG9mIDYuMS45KQ0KDQpDb3VsZCB5b3UgcmV2aWV3IG15IHBhdGNoIGNvZGUuDQpC
ZXN0IFJlZ2FyZHMsIFNhbmd3b24sIGtpDQo=
^ permalink raw reply
* [PATCH] iwlwifi: do not dump stack whet triggering firmware restart
From: Stanislaw Gruszka @ 2013-09-13 8:45 UTC (permalink / raw)
To: ilw; +Cc: linux-wireless
We send REPLY_ERROR command to the device to force microcode error
and restart firmware. This is not a problem, so do not dump stack
on such situation.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlwifi/pcie/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
index f45eb29..ec49033 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -1546,7 +1546,8 @@ static int iwl_pcie_send_hcmd_sync(struct iwl_trans *trans,
if (test_bit(STATUS_FW_ERROR, &trans_pcie->status)) {
IWL_ERR(trans, "FW error in SYNC CMD %s\n",
get_cmd_string(trans_pcie, cmd->id));
- dump_stack();
+ if (cmd->id != REPLY_ERROR)
+ dump_stack();
ret = -EIO;
goto cancel;
}
--
1.8.3.1
^ permalink raw reply related
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-13 9:01 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <5230CDF1.1040905@lwfinger.net>
On 11/09/13 21:09, Larry Finger wrote:
> I am now running a kernel built with your configuration. I needed to
> make a couple of changes as it did not have one of the modules my disk
> system needs, and nouveau caused kernel panics, but we are now
> operational. Outside of the whole system being slow due to only one 2.0
> GHz CPU, the wireless connection seems to be stable. At least, there
> have been no disconnects in the first half hour.
Thanks for testing Larry. Last night I finished building an SMP-capable
kernel with the same configuration and I see no change in behaviour. So
I think we can rule this out as a possible cause.
ATB,
Mark.
^ permalink raw reply
* Re: [PATCH] iwlwifi: do not dump stack whet triggering firmware restart
From: Johannes Berg @ 2013-09-13 9:15 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: ilw, linux-wireless, emmanuel.grumbach
In-Reply-To: <1379061930-2007-1-git-send-email-sgruszka@redhat.com>
On Fri, 2013-09-13 at 10:45 +0200, Stanislaw Gruszka wrote:
> We send REPLY_ERROR command to the device to force microcode error
> and restart firmware. This is not a problem, so do not dump stack
> on such situation.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> drivers/net/wireless/iwlwifi/pcie/tx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
> index f45eb29..ec49033 100644
> --- a/drivers/net/wireless/iwlwifi/pcie/tx.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
> @@ -1546,7 +1546,8 @@ static int iwl_pcie_send_hcmd_sync(struct iwl_trans *trans,
> if (test_bit(STATUS_FW_ERROR, &trans_pcie->status)) {
> IWL_ERR(trans, "FW error in SYNC CMD %s\n",
> get_cmd_string(trans_pcie, cmd->id));
> - dump_stack();
> + if (cmd->id != REPLY_ERROR)
> + dump_stack();
Hmm, we changed this code like below, is this still relevant?
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Wed Sep 11 14:16:20 2013 +0300
iwlwifi: pcie: restart the driver when a command times out
This should really not happen. If it does, restarting is the
only way to recover since the driver and the firmware might
very well be out of sync. Moreover, iwl_op_mode_nic_error
will print data that might help debugging.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
index d92baa7..32f179f 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -1535,7 +1535,6 @@ static int iwl_pcie_send_hcmd_sync(struct iwl_trans *trans,
"Error sending %s: time out after %dms.\n",
get_cmd_string(trans_pcie, cmd->id),
jiffies_to_msecs(HOST_COMPLETE_TIMEOUT));
- dump_stack();
IWL_ERR(trans,
"Current CMD queue read_ptr %d write_ptr %d\n",
@@ -1546,6 +1545,9 @@ static int iwl_pcie_send_hcmd_sync(struct iwl_trans *trans,
"Clearing HCMD_ACTIVE for command %s\n",
get_cmd_string(trans_pcie, cmd->id));
ret = -ETIMEDOUT;
+
+ iwl_op_mode_nic_error(trans->op_mode);
+
goto cancel;
}
}
johannes
^ permalink raw reply related
* rtl8192cu: testing with EdiMax USB
From: Mark Cave-Ayland @ 2013-09-13 9:29 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
Hi all,
So talking to some colleagues at work, I managed to find someone else
who uses the EdiMax USB dongle and persuaded them to lend it to me for
the weekend in order to see whether it could be related to a hardware
difference with my OEM dongle.
I've just tested with the EdiMax USB dongle which reports as "Bus 004
Device 004: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n
Wireless Adapter [Realtek RTL8188CUS]" in lsusb, which I believe is
exactly the same hardware that Larry is using. And again I still see the
problem with disassociation.
I spent a bit more time tinkering further with debug=0x5, forgetting
that I had left your last diagnostic patch applied. Based upon when the
beacon output disappears in the logs (after updating the power
registers), it does seem likely that is a power-related problem.
The two power-related messages that stand out to me are:
1) Repeated output of "pHalData->bHwRadioOff and eRfPowerStateToSet do
not match: pHalData->bHwRadioOff 0, eRfPowerStateToSet 0" messages
2) rtl92c_dm_txpower_tracking_callback_thermalmeter() seems to be called
X seconds before the "AP off for X seconds" messages
Larry - I've sent you the complete debug off-list from the EdiMax, so it
should be a like-for-like comparison with your setup. Hopefully
comparing with your output will help you work out exactly what the
problem is.
ATB,
Mark.
^ permalink raw reply
* Re: [PATCH] iwlwifi: do not dump stack whet triggering firmware restart
From: Stanislaw Gruszka @ 2013-09-13 9:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: ilw, linux-wireless, emmanuel.grumbach
In-Reply-To: <1379063754.14883.10.camel@jlt4.sipsolutions.net>
On Fri, Sep 13, 2013 at 11:15:54AM +0200, Johannes Berg wrote:
> On Fri, 2013-09-13 at 10:45 +0200, Stanislaw Gruszka wrote:
> Hmm, we changed this code like below, is this still relevant?
Nope, please drop.
Stanislaw
^ permalink raw reply
* [RFC 0/5] mac80211/iwlwifi: quiesce before restart hw
From: Stanislaw Gruszka @ 2013-09-13 10:36 UTC (permalink / raw)
To: ilw; +Cc: linux-wireless
Here is continuation of short discussion I started here:
http://marc.info/?l=linux-wireless&m=137724899704012&w=2
I made patches which do quiesce and that can be used by iwlwifi
restart procedure to avoid calling iwlwifi methods by mac80211
while firmware is not alive.
But honestly, I'm not happy with that work. It does not fix root of the
problem (microcode errors/hangs) and seems to be just to much
complication to avoid warnings, which are consequence of firmware
malfunction. So I just prefer to remove WARN_ONCE(trans->state !=
IWL_TRANS_FW_ALIVE) and replace it by ordinary IWL_WARN(), which
does not generate auto bug reports.
Regarding firmware problems debugging, perhaps ftrace can be used
for that. iwlwifi has already tracing capabilities. Allow to gather
log using trace-cmd and call tracing_off() when firmware error will
happen, perhaps will allow to debug firmware problems efficiently.
If you think that's right we could add WARN_ONCE on firmware error
to have automatic bug reports. Then we could ask user for the trace
to debug and solve the issue. Would that work for you?
Stanislaw Gruszka (5):
Revert "mac80211: cleanup suspend/resume on mesh mode"
Revert "mac80211: cleanup suspend/resume on ibss mode"
Revert "mac80211: cleanup suspend/resume on managed mode"
mac80211: add generic quiesce procedure
iwlwifi: quiesce mac80211 before fw restart
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 1 +
drivers/net/wireless/iwlwifi/dvm/main.c | 4 +-
include/net/mac80211.h | 10 +++++
net/mac80211/ibss.c | 27 +++++++++++-
net/mac80211/ieee80211_i.h | 9 ++++
net/mac80211/main.c | 33 +++++++++++++++
net/mac80211/mesh.c | 55 +++++++++++++++++++++++-
net/mac80211/mesh.h | 12 ++++++
net/mac80211/mesh_plink.c | 27 +++++++++++-
net/mac80211/mlme.c | 65 +++++++++++++++++++++++++++--
net/mac80211/sta_info.h | 2 +
net/mac80211/util.c | 19 ++++++++-
12 files changed, 254 insertions(+), 10 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [RFC 1/5] Revert "mac80211: cleanup suspend/resume on mesh mode"
From: Stanislaw Gruszka @ 2013-09-13 10:36 UTC (permalink / raw)
To: ilw; +Cc: linux-wireless
In-Reply-To: <1379068568-27552-1-git-send-email-sgruszka@redhat.com>
This reverts commit 690205f18fd069898c70d743f498ba42798e5c4e.
---
net/mac80211/ieee80211_i.h | 2 ++
net/mac80211/mesh.c | 57 ++++++++++++++++++++++++++++++++++++++++++++--
net/mac80211/mesh.h | 12 ++++++++++
net/mac80211/mesh_plink.c | 27 +++++++++++++++++++++-
net/mac80211/sta_info.h | 2 ++
5 files changed, 97 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index b618651..4b7ef89 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -543,6 +543,8 @@ struct ieee80211_if_mesh {
struct timer_list mesh_path_timer;
struct timer_list mesh_path_root_timer;
+ unsigned long timers_running;
+
unsigned long wrkq_flags;
unsigned long mbss_changed;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 707ac61..e131293 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -13,6 +13,10 @@
#include "ieee80211_i.h"
#include "mesh.h"
+#define TMR_RUNNING_HK 0
+#define TMR_RUNNING_MP 1
+#define TMR_RUNNING_MPR 2
+
static int mesh_allocated;
static struct kmem_cache *rm_cache;
@@ -46,6 +50,11 @@ static void ieee80211_mesh_housekeeping_timer(unsigned long data)
set_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags);
+ if (local->quiescing) {
+ set_bit(TMR_RUNNING_HK, &ifmsh->timers_running);
+ return;
+ }
+
ieee80211_queue_work(&local->hw, &sdata->work);
}
@@ -472,8 +481,15 @@ static void ieee80211_mesh_path_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
(struct ieee80211_sub_if_data *) data;
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee80211_local *local = sdata->local;
- ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+ if (local->quiescing) {
+ set_bit(TMR_RUNNING_MP, &ifmsh->timers_running);
+ return;
+ }
+
+ ieee80211_queue_work(&local->hw, &sdata->work);
}
static void ieee80211_mesh_path_root_timer(unsigned long data)
@@ -481,10 +497,16 @@ static void ieee80211_mesh_path_root_timer(unsigned long data)
struct ieee80211_sub_if_data *sdata =
(struct ieee80211_sub_if_data *) data;
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee80211_local *local = sdata->local;
set_bit(MESH_WORK_ROOT, &ifmsh->wrkq_flags);
- ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+ if (local->quiescing) {
+ set_bit(TMR_RUNNING_MPR, &ifmsh->timers_running);
+ return;
+ }
+
+ ieee80211_queue_work(&local->hw, &sdata->work);
}
void ieee80211_mesh_root_setup(struct ieee80211_if_mesh *ifmsh)
@@ -602,6 +624,35 @@ static void ieee80211_mesh_rootpath(struct ieee80211_sub_if_data *sdata)
round_jiffies(TU_TO_EXP_TIME(interval)));
}
+#ifdef CONFIG_PM
+void ieee80211_mesh_quiesce(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+
+ /* use atomic bitops in case all timers fire at the same time */
+
+ if (del_timer_sync(&ifmsh->housekeeping_timer))
+ set_bit(TMR_RUNNING_HK, &ifmsh->timers_running);
+ if (del_timer_sync(&ifmsh->mesh_path_timer))
+ set_bit(TMR_RUNNING_MP, &ifmsh->timers_running);
+ if (del_timer_sync(&ifmsh->mesh_path_root_timer))
+ set_bit(TMR_RUNNING_MPR, &ifmsh->timers_running);
+}
+
+void ieee80211_mesh_restart(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+
+ if (test_and_clear_bit(TMR_RUNNING_HK, &ifmsh->timers_running))
+ add_timer(&ifmsh->housekeeping_timer);
+ if (test_and_clear_bit(TMR_RUNNING_MP, &ifmsh->timers_running))
+ add_timer(&ifmsh->mesh_path_timer);
+ if (test_and_clear_bit(TMR_RUNNING_MPR, &ifmsh->timers_running))
+ add_timer(&ifmsh->mesh_path_root_timer);
+ ieee80211_mesh_root_setup(ifmsh);
+}
+#endif
+
static int
ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
{
@@ -810,6 +861,8 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data *sdata)
local->fif_other_bss--;
atomic_dec(&local->iff_allmultis);
ieee80211_configure_filter(local);
+
+ sdata->u.mesh.timers_running = 0;
}
static void
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 2bc7fd2..6fd6ed6 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -315,6 +315,8 @@ void mesh_path_timer(unsigned long data);
void mesh_path_flush_by_nexthop(struct sta_info *sta);
void mesh_path_discard_frame(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb);
+void mesh_path_quiesce(struct ieee80211_sub_if_data *sdata);
+void mesh_path_restart(struct ieee80211_sub_if_data *sdata);
void mesh_path_tx_root_frame(struct ieee80211_sub_if_data *sdata);
bool mesh_action_is_path_sel(struct ieee80211_mgmt *mgmt);
@@ -359,12 +361,22 @@ static inline bool mesh_path_sel_is_hwmp(struct ieee80211_sub_if_data *sdata)
void ieee80211_mesh_notify_scan_completed(struct ieee80211_local *local);
+void ieee80211_mesh_quiesce(struct ieee80211_sub_if_data *sdata);
+void ieee80211_mesh_restart(struct ieee80211_sub_if_data *sdata);
+void mesh_plink_quiesce(struct sta_info *sta);
+void mesh_plink_restart(struct sta_info *sta);
void mesh_path_flush_by_iface(struct ieee80211_sub_if_data *sdata);
void mesh_sync_adjust_tbtt(struct ieee80211_sub_if_data *sdata);
void ieee80211s_stop(void);
#else
static inline void
ieee80211_mesh_notify_scan_completed(struct ieee80211_local *local) {}
+static inline void ieee80211_mesh_quiesce(struct ieee80211_sub_if_data *sdata)
+{}
+static inline void ieee80211_mesh_restart(struct ieee80211_sub_if_data *sdata)
+{}
+static inline void mesh_plink_quiesce(struct sta_info *sta) {}
+static inline void mesh_plink_restart(struct sta_info *sta) {}
static inline bool mesh_path_sel_is_hwmp(struct ieee80211_sub_if_data *sdata)
{ return false; }
static inline void mesh_path_flush_by_iface(struct ieee80211_sub_if_data *sdata)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 6b65d50..2b18cc6 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -540,8 +540,10 @@ static void mesh_plink_timer(unsigned long data)
*/
sta = (struct sta_info *) data;
- if (sta->sdata->local->quiescing)
+ if (sta->sdata->local->quiescing) {
+ sta->plink_timer_was_running = true;
return;
+ }
spin_lock_bh(&sta->lock);
if (sta->ignore_plink_timer) {
@@ -602,6 +604,29 @@ static void mesh_plink_timer(unsigned long data)
}
}
+#ifdef CONFIG_PM
+void mesh_plink_quiesce(struct sta_info *sta)
+{
+ if (!ieee80211_vif_is_mesh(&sta->sdata->vif))
+ return;
+
+ /* no kernel mesh sta timers have been initialized */
+ if (sta->sdata->u.mesh.security != IEEE80211_MESH_SEC_NONE)
+ return;
+
+ if (del_timer_sync(&sta->plink_timer))
+ sta->plink_timer_was_running = true;
+}
+
+void mesh_plink_restart(struct sta_info *sta)
+{
+ if (sta->plink_timer_was_running) {
+ add_timer(&sta->plink_timer);
+ sta->plink_timer_was_running = false;
+ }
+}
+#endif
+
static inline void mesh_plink_timer_set(struct sta_info *sta, int timeout)
{
sta->plink_timer.expires = jiffies + (HZ * timeout / 1000);
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 4208dbd..3e750c7 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -282,6 +282,7 @@ struct sta_ampdu_mlme {
* @plink_state: peer link state
* @plink_timeout: timeout of peer link
* @plink_timer: peer link watch timer
+ * @plink_timer_was_running: used by suspend/resume to restore timers
* @t_offset: timing offset relative to this host
* @t_offset_setpoint: reference timing offset of this sta to be used when
* calculating clockdrift
@@ -388,6 +389,7 @@ struct sta_info {
__le16 reason;
u8 plink_retries;
bool ignore_plink_timer;
+ bool plink_timer_was_running;
enum nl80211_plink_state plink_state;
u32 plink_timeout;
struct timer_list plink_timer;
--
1.8.3.1
^ permalink raw reply related
* [RFC 3/5] Revert "mac80211: cleanup suspend/resume on managed mode"
From: Stanislaw Gruszka @ 2013-09-13 10:36 UTC (permalink / raw)
To: ilw; +Cc: linux-wireless
In-Reply-To: <1379068568-27552-1-git-send-email-sgruszka@redhat.com>
This reverts commit 9b7d72c1041ec5b20b24af487a98f71d8ff1555e.
Conflicts:
net/mac80211/ieee80211_i.h
net/mac80211/mlme.c
---
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/mlme.c | 63 ++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 96ac8f8..c5878af 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -402,6 +402,7 @@ struct ieee80211_if_managed {
u16 aid;
+ unsigned long timers_running; /* used for quiesce/restart */
bool powersave; /* powersave requested for this iface */
bool broken_ap; /* AP is broken -- turn off powersave */
bool have_beacon;
@@ -1313,6 +1314,8 @@ void ieee80211_recalc_ps_vif(struct ieee80211_sub_if_data *sdata);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata);
+void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata);
+void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 86e4ad5..b308855 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -92,6 +92,9 @@ MODULE_PARM_DESC(probe_wait_ms,
*/
#define IEEE80211_SIGNAL_AVE_MIN_COUNT 4
+#define TMR_RUNNING_TIMER 0
+#define TMR_RUNNING_CHANSW 1
+
/*
* We can have multiple work items (and connection probing)
* scheduling this timer, but we need to take care to only
@@ -988,8 +991,14 @@ static void ieee80211_chswitch_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
(struct ieee80211_sub_if_data *) data;
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+
+ if (sdata->local->quiescing) {
+ set_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running);
+ return;
+ }
- ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.chswitch_work);
+ ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
}
static void
@@ -1922,6 +1931,8 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
del_timer_sync(&sdata->u.mgd.timer);
del_timer_sync(&sdata->u.mgd.chswitch_timer);
+ sdata->u.mgd.timers_running = 0;
+
sdata->vif.bss_conf.dtim_period = 0;
sdata->vif.bss_conf.beacon_rate = NULL;
@@ -3315,8 +3326,15 @@ static void ieee80211_sta_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
(struct ieee80211_sub_if_data *) data;
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+ struct ieee80211_local *local = sdata->local;
+
+ if (local->quiescing) {
+ set_bit(TMR_RUNNING_TIMER, &ifmgd->timers_running);
+ return;
+ }
- ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+ ieee80211_queue_work(&local->hw, &sdata->work);
}
static void ieee80211_sta_connection_lost(struct ieee80211_sub_if_data *sdata,
@@ -3661,6 +3679,37 @@ static void ieee80211_restart_sta_timer(struct ieee80211_sub_if_data *sdata)
}
#ifdef CONFIG_PM
+void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+
+ /*
+ * Stop timers before deleting work items, as timers
+ * could race and re-add the work-items. They will be
+ * re-established on connection.
+ */
+ del_timer_sync(&ifmgd->conn_mon_timer);
+ del_timer_sync(&ifmgd->bcn_mon_timer);
+
+ /*
+ * we need to use atomic bitops for the running bits
+ * only because both timers might fire at the same
+ * time -- the code here is properly synchronised.
+ */
+
+ cancel_work_sync(&ifmgd->request_smps_work);
+
+ cancel_work_sync(&ifmgd->monitor_work);
+ cancel_work_sync(&ifmgd->beacon_connection_loss_work);
+ cancel_work_sync(&ifmgd->csa_connection_drop_work);
+ if (del_timer_sync(&ifmgd->timer))
+ set_bit(TMR_RUNNING_TIMER, &ifmgd->timers_running);
+
+ if (del_timer_sync(&ifmgd->chswitch_timer))
+ set_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running);
+ cancel_work_sync(&ifmgd->chswitch_work);
+}
+
void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
@@ -3682,6 +3731,16 @@ void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
return;
}
sdata_unlock(sdata);
+
+ if (test_and_clear_bit(TMR_RUNNING_TIMER, &ifmgd->timers_running))
+ add_timer(&ifmgd->timer);
+ if (test_and_clear_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running))
+ add_timer(&ifmgd->chswitch_timer);
+ ieee80211_sta_reset_beacon_monitor(sdata);
+
+ mutex_lock(&sdata->local->mtx);
+ ieee80211_restart_sta_timer(sdata);
+ mutex_unlock(&sdata->local->mtx);
}
#endif
--
1.8.3.1
^ permalink raw reply related
* [RFC 4/5] mac80211: add generic quiesce procedure
From: Stanislaw Gruszka @ 2013-09-13 10:36 UTC (permalink / raw)
To: ilw; +Cc: linux-wireless
In-Reply-To: <1379068568-27552-1-git-send-email-sgruszka@redhat.com>
Add function ieee80211_quiesce() end export it to allow be used by
drivers. It is intended to be used before restart_hw to stop mac80211
timers/works . Reverse quiesce on ieee80211_reconfig().
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
include/net/mac80211.h | 10 ++++++++++
net/mac80211/ibss.c | 2 --
net/mac80211/main.c | 33 +++++++++++++++++++++++++++++++++
net/mac80211/mesh.c | 2 --
net/mac80211/mlme.c | 2 --
net/mac80211/util.c | 19 ++++++++++++++++++-
6 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4be8785..a428ee7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3054,6 +3054,16 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw);
void ieee80211_free_hw(struct ieee80211_hw *hw);
/**
+ * ieee80211_quiesce - quiesce hardware
+ *
+ * Call this function to stop pending mac80211 activities before
+ * restarting hardware by ieee80211_restart_hw().
+ *
+ * @hw: the hardware to quiesce
+ */
+void ieee80211_quiesce(struct ieee80211_hw *hw);
+
+/**
* ieee80211_restart_hw - restart hardware completely
*
* Call this function when the hardware was restarted for some reason
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 91d1b29..bf2b5a9 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1166,7 +1166,6 @@ static void ieee80211_ibss_timer(unsigned long data)
ieee80211_queue_work(&local->hw, &sdata->work);
}
-#ifdef CONFIG_PM
void ieee80211_ibss_quiesce(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
@@ -1184,7 +1183,6 @@ void ieee80211_ibss_restart(struct ieee80211_sub_if_data *sdata)
ifibss->timer_running = false;
}
}
-#endif
void ieee80211_ibss_setup_sdata(struct ieee80211_sub_if_data *sdata)
{
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 21d5d44..978f364 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -263,6 +263,39 @@ static void ieee80211_restart_work(struct work_struct *work)
rtnl_unlock();
}
+/* return value indicates whether the driver should be further notified */
+void ieee80211_quiesce(struct ieee80211_hw *hw)
+{
+ struct ieee80211_local *local = hw_to_local(hw);
+ struct ieee80211_sub_if_data *sdata;
+
+ local->quiescing = true;
+
+ list_for_each_entry(sdata, &local->interfaces, list) {
+ if (!ieee80211_sdata_running(sdata))
+ continue;
+
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
+ ieee80211_sta_quiesce(sdata);
+ break;
+ case NL80211_IFTYPE_ADHOC:
+ ieee80211_ibss_quiesce(sdata);
+ break;
+ case NL80211_IFTYPE_MESH_POINT:
+ ieee80211_mesh_quiesce(sdata);
+ break;
+ default:
+ break;
+ }
+
+ cancel_work_sync(&sdata->work);
+ }
+
+ local->quiescing = false;
+}
+EXPORT_SYMBOL(ieee80211_quiesce);
+
void ieee80211_restart_hw(struct ieee80211_hw *hw)
{
struct ieee80211_local *local = hw_to_local(hw);
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index e131293..b950d8d 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -624,7 +624,6 @@ static void ieee80211_mesh_rootpath(struct ieee80211_sub_if_data *sdata)
round_jiffies(TU_TO_EXP_TIME(interval)));
}
-#ifdef CONFIG_PM
void ieee80211_mesh_quiesce(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
@@ -651,7 +650,6 @@ void ieee80211_mesh_restart(struct ieee80211_sub_if_data *sdata)
add_timer(&ifmsh->mesh_path_root_timer);
ieee80211_mesh_root_setup(ifmsh);
}
-#endif
static int
ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index b308855..66cec97 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3678,7 +3678,6 @@ static void ieee80211_restart_sta_timer(struct ieee80211_sub_if_data *sdata)
}
}
-#ifdef CONFIG_PM
void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
@@ -3742,7 +3741,6 @@ void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
ieee80211_restart_sta_timer(sdata);
mutex_unlock(&sdata->local->mtx);
}
-#endif
/* interface setup */
void ieee80211_sta_setup_sdata(struct ieee80211_sub_if_data *sdata)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index e1b34a1..ee5a0b4 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1742,11 +1742,28 @@ int ieee80211_reconfig(struct ieee80211_local *local)
list_for_each_entry(sdata, &local->interfaces, list) {
if (!ieee80211_sdata_running(sdata))
continue;
- if (sdata->vif.type == NL80211_IFTYPE_STATION)
+
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
ieee80211_sta_restart(sdata);
+ break;
+ case NL80211_IFTYPE_ADHOC:
+ ieee80211_ibss_restart(sdata);
+ break;
+ case NL80211_IFTYPE_MESH_POINT:
+ ieee80211_mesh_restart(sdata);
+ break;
+ default:
+ break;
+ }
}
mod_timer(&local->sta_cleanup, jiffies + 1);
+
+ mutex_lock(&local->sta_mtx);
+ list_for_each_entry(sta, &local->sta_list, list)
+ mesh_plink_restart(sta);
+ mutex_unlock(&local->sta_mtx);
#else
WARN_ON(1);
#endif
--
1.8.3.1
^ permalink raw reply related
* [RFC 2/5] Revert "mac80211: cleanup suspend/resume on ibss mode"
From: Stanislaw Gruszka @ 2013-09-13 10:36 UTC (permalink / raw)
To: ilw; +Cc: linux-wireless
In-Reply-To: <1379068568-27552-1-git-send-email-sgruszka@redhat.com>
This reverts commit a61829437e68c8b2036cf5005ed0e875451c9120.
---
net/mac80211/ibss.c | 29 ++++++++++++++++++++++++++++-
net/mac80211/ieee80211_i.h | 4 ++++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index a12afe7..91d1b29 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1155,9 +1155,36 @@ static void ieee80211_ibss_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
(struct ieee80211_sub_if_data *) data;
+ struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
+ struct ieee80211_local *local = sdata->local;
- ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+ if (local->quiescing) {
+ ifibss->timer_running = true;
+ return;
+ }
+
+ ieee80211_queue_work(&local->hw, &sdata->work);
+}
+
+#ifdef CONFIG_PM
+void ieee80211_ibss_quiesce(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
+
+ if (del_timer_sync(&ifibss->timer))
+ ifibss->timer_running = true;
+}
+
+void ieee80211_ibss_restart(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
+
+ if (ifibss->timer_running) {
+ add_timer(&ifibss->timer);
+ ifibss->timer_running = false;
+ }
}
+#endif
void ieee80211_ibss_setup_sdata(struct ieee80211_sub_if_data *sdata)
{
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4b7ef89..96ac8f8 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -492,6 +492,8 @@ struct ieee80211_if_ibss {
u32 basic_rates;
+ bool timer_running;
+
bool fixed_bssid;
bool fixed_channel;
bool privacy;
@@ -1329,6 +1331,8 @@ void ieee80211_ibss_rx_no_sta(struct ieee80211_sub_if_data *sdata,
int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
struct cfg80211_ibss_params *params);
int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata);
+void ieee80211_ibss_quiesce(struct ieee80211_sub_if_data *sdata);
+void ieee80211_ibss_restart(struct ieee80211_sub_if_data *sdata);
void ieee80211_ibss_work(struct ieee80211_sub_if_data *sdata);
void ieee80211_ibss_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb);
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox