* Re: hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
From: SF Markus Elfring @ 2016-09-26 16:03 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, netdev, Jouni Malinen, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <20160926150656.213D961568@smtp.codeaurora.org>
> 9291771 [2/3] hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
> 9291775 [3/3] hostap: Delete unnecessary initialisations for the variable "ret"
>
> Reason: The benefit is not clear.
How do you think about to reduce the source code a bit at these places?
Regards,
Markus
^ permalink raw reply
* [PATCH] staging: wilc1000: fix sparse warning: symbol was not declared. Should it be static?
From: Matias Mucciolo @ 2016-09-26 16:13 UTC (permalink / raw)
To: Greg Kroah-Hartman, Aditya Shankar, Ganesh Krishna
Cc: devel, linux-wireless, linux-kernel
In-Reply-To: <20160926155220.GA3319@kroah.com>
- Fixed a sparse warning:
wilc_debugfs.c:32:10: warning: symbol 'WILC_DEBUG_LEVEL' was not declared. Should it be static?
Signed-off-by: Matias Mucciolo <mmucciolo@suteba.org.ar>
---
drivers/staging/wilc1000/wilc_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/wilc_debugfs.c b/drivers/staging/wilc1000/wilc_debugfs.c
index b052628..802bb1d 100644
--- a/drivers/staging/wilc1000/wilc_debugfs.c
+++ b/drivers/staging/wilc1000/wilc_debugfs.c
@@ -29,7 +29,7 @@ static struct dentry *wilc_dir;
#define ERR BIT(3)
#define DBG_LEVEL_ALL (DEBUG | INFO | WRN | ERR)
-atomic_t WILC_DEBUG_LEVEL = ATOMIC_INIT(ERR);
+static atomic_t WILC_DEBUG_LEVEL = ATOMIC_INIT(ERR);
EXPORT_SYMBOL_GPL(WILC_DEBUG_LEVEL);
/*
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform (DMA32 issue)
From: Ben Greear @ 2016-09-26 16:53 UTC (permalink / raw)
To: Adrian Chadd, Michal Kazior
Cc: Manoharan, Rajkumar, Rajkumar Manoharan, Sebastian Gottschall,
Valo, Kalle, ath10k@lists.infradead.org, nbd@nbd.name,
linux-wireless@vger.kernel.org, netdev
In-Reply-To: <CAJ-VmomcD8FgA34z3OFKZvc5yq8EsHOTqP=Lg-6gFOAcWys8og@mail.gmail.com>
On 07/20/2016 10:02 AM, Adrian Chadd wrote:
> Hi,
>
> The "right" way for the target CPU to interact with host CPU memory
> (and vice versa, for mostly what it's worth) is to have the copy
> engine copy (ie, "DMA") the pieces between them. This may be for
> diagnostic purposes, but it's not supposed to be used like this for
> doing wifi data exchange, right? :-P
>
> Now, there /may/ be some alignment hilarity in various bits of code
> and/or hardware. Eg, Merlin (AR9280) requires its descriptors to be
> within a 4k block - the code to iterate through the descriptor
> physical address space didn't do a "val = val + offset", it did
> something in verilog like "val = (val & 0xffffc000) | (offset &
> 0x3fff)". This meant if you allocated a descriptor that started just
> before the end of a 4k physmem aligned block, you'd end up with
> exciting results. I don't know if there are any situations like this
> in the ath10k hardware, but I'm sure there will be some gotchas
> somewhere.
>
> In any case, if ath10k is consuming too much bounce buffers, the calls
> to allocate memory aren't working right and should be restricted to 32
> bit addresses. Whether that's by using the DMA memory API (before it's
> mapped) or passing in GFP_DMA32 is a fun debate.
>
> (My test hardware arrived, so I'll test this all out today on
> Peregrine-v2 and see if the driver works.)
I have been running this patch for a while:
ath10k: Use GPF_DMA32 for firmware swap memory.
This fixes OS crash when using QCA 9984 NIC on x86-64 system
without vt-d enabled.
Also tested on ea8500 with 9980, and x86-64 with 9980 and 9880.
All tests were with CT firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
-------------------- drivers/net/wireless/ath/ath10k/wmi.c --------------------
index e20aa39..727b3aa 100644
@@ -4491,7 +4491,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
if (!pool_size)
return -EINVAL;
- vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
+ vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN | GFP_DMA32);
if (!vaddr)
num_units /= 2;
}
It mostly seems to work, but then sometimes I get a splat like this below. It appears
it is invalid to actually do kzalloc with GFP_DMA32 (based on that BUG_ON that
hit in the new_slab method)??
Any idea for a more proper way to do this?
gfp: 4
------------[ cut here ]------------
kernel BUG at /home/greearb/git/linux-4.7.dev.y/mm/slub.c:1508!
invalid opcode: 0000 [#1] PREEMPT SMP
Modules linked in: coretemp hwmon ath9k intel_rapl ath10k_pci x86_pkg_temp_thermal ath9k_common ath10k_core intel_powerclamp ath9k_hw ath kvm iTCO_wdt mac80211
iTCO_vendor_support irqbypass snd_hda_codec_hdmi 6
CPU: 2 PID: 268 Comm: kworker/u8:5 Not tainted 4.7.2+ #16
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
task: ffff880036433a00 ti: ffff880036440000 task.ti: ffff880036440000
RIP: 0010:[<ffffffff8124592a>] [<ffffffff8124592a>] new_slab+0x39a/0x410
RSP: 0018:ffff880036443b58 EFLAGS: 00010092
RAX: 0000000000000006 RBX: 00000000024082c4 RCX: 0000000000000000
RDX: 0000000000000006 RSI: ffff88021e30dd08 RDI: ffff88021e30dd08
RBP: ffff880036443b90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000372 R12: ffff88021dc01200
R13: ffff88021dc00cc0 R14: ffff88021dc01200 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff88021e300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f3e65c1c730 CR3: 0000000001e06000 CR4: 00000000001406e0
Stack:
ffffffff8127a4fc ffff0a01ffffff10 00000000024082c4 ffff88021dc01200
ffff88021dc00cc0 ffff88021dc01200 0000000000000001 ffff880036443c58
ffffffff81247ac6 ffff88021e31b360 ffff880036433a00 ffff880036433a00
Call Trace:
[<ffffffff8127a4fc>] ? __d_lookup+0x9c/0x160
[<ffffffff81247ac6>] ___slab_alloc+0x396/0x4a0
[<ffffffffa0f8e14d>] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 [ath10k_core]
[<ffffffff811f5279>] ? alloc_kmem_pages+0x9/0x10
[<ffffffff8120f203>] ? kmalloc_order+0x13/0x40
[<ffffffffa0f8e14d>] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 [ath10k_core]
[<ffffffff81247bf6>] __slab_alloc.isra.72+0x26/0x40
[<ffffffff81248767>] __kmalloc+0x147/0x1b0
[<ffffffffa0f8e14d>] ath10k_wmi_event_service_ready_work+0x5ad/0x800 [ath10k_core]
[<ffffffff811370a1>] ? dequeue_entity+0x261/0xac0
[<ffffffff8111c2d8>] process_one_work+0x148/0x420
[<ffffffff8111c929>] worker_thread+0x49/0x480
[<ffffffff8111c8e0>] ? rescuer_thread+0x330/0x330
[<ffffffff81121984>] kthread+0xc4/0xe0
[<ffffffff8184d75f>] ret_from_fork+0x1f/0x40
[<ffffffff811218c0>] ? kthread_create_on_node+0x170/0x170
Code: e9 65 fd ff ff 49 8b 57 20 48 8d 42 ff 83 e2 01 49 0f 44 c7 f0 80 08 40 e9 6f fd ff ff 89 c6 48 c7 c7 01 36 c7 81 e8 e8 40 fa ff <0f> 0b ba 00 10 00 00 be
5a 00 00 00 48 89 c7 48 d3 e2 e8 bf 18
RIP [<ffffffff8124592a>] new_slab+0x39a/0x410
RSP <ffff880036443b58>
---[ end trace ea3b0043b2911d93 ]---
static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
{
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
BUG();
}
return allocate_slab(s,
flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node);
}
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [1/9] brcmfmac: ignore 11d configuration errors
From: Kalle Valo @ 2016-09-26 17:38 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Hante Meuleman, Arend van Spriel
In-Reply-To: <1474283399-14385-2-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> From: Hante Meuleman <hante.meuleman@broadcom.com>
>
> 802.11d is not always supported by firmware anymore. Currently the
> AP configuration of 11d will cause an abort if the ioctl set is
> failing. This behavior is not correct and the error should be
> ignored.
>
> Reviewed-by: Arend Van Spriel <arend.vanspriel@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Signed-off-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
9 patches applied to wireless-drivers-next.git, thanks.
b3589dfe0212 brcmfmac: ignore 11d configuration errors
704d1c6b56f4 brcmfmac: rework pointer trickery in brcmf_proto_bcdc_query_dcmd()
bc9816413601 brcmfmac: fix memory leak in brcmf_flowring_add_tdls_peer()
26305d3d7298 brcmfmac: initialize variable in brcmf_sdiod_regrl()
8fa5fdec09cd brcmfmac: remove worker from .ndo_set_mac_address() callback
835680b82f02 brcmfmac: remove unnecessary null pointer check
2b7425f3629b brcmfmac: fix clearing entry IPv6 address
a7ed7828ecda brcmfmac: fix out of bound access on clearing wowl wake indicator
92c313604711 brcmfmac: simplify mapping of auth type
--
https://patchwork.kernel.org/patch/9339033/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/3] mwifiex: fix kernel crash for USB chipsets
From: Kalle Valo @ 2016-09-26 17:40 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Shengzhen Li,
Amitkumar Karwar
In-Reply-To: <1474384744-14096-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Cathy Luo <cluo@marvell.com>
>
> Following crash issue is observed during TCP traffic stress
> test
>
> [ 2253.625439] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s!
> [kworker/u17:1:5191]
> [ 2253.625520] Call Trace:
> [ 2253.625527] [<ffffffffc0b47030>] ? moal_spin_lock+0x30/0x30
> [usb8xxx]
> [ 2253.625533] [<ffffffffc0ac3ceb>] ? wlan_wmm_lists_empty+0xb/0xf0
> [mlan]
> [ 2253.625537] [<ffffffffc0ab0ea3>] mlan_main_process+0x1b3/0x720
> [mlan]
> [ 2253.625540] [<ffffffffc0b337f5>] woal_main_work_queue+0x45/0x80
> [usb8xxx]
> [ 2253.625543] [<ffffffff8108aaf0>] process_one_work+0x150/0x3f0
> [ 2253.625545] [<ffffffff8108b1e1>] worker_thread+0x121/0x520
> [ 2253.625547] [<ffffffff8108b0c0>] ? rescuer_thread+0x330/0x330
> [ 2253.625549] [<ffffffff81090222>] kthread+0xd2/0xf0
> [ 2253.625551] [<ffffffff81090150>] ?
> kthread_create_on_node+0x1c0/0x1c0
> [ 2253.625553] [<ffffffff8179423c>] ret_from_fork+0x7c/0xb0
> [ 2253.625555] [<ffffffff81090150>] ?
> kthread_create_on_node+0x1c0/0x1c0
>
> In mwifiex_usb_tx_complete(), we are updating port->block_status first
> and then freeing the skb attached to that URB. We may end up attaching
> new skb to URB in a corner case and same will be freed. This results in
> the kernel crash. The problem is solved by changing the sequence.
>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Shengzhen Li <szli@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
3 patches applied to wireless-drivers-next.git, thanks.
1afac196c167 mwifiex: fix kernel crash for USB chipsets
5476f8030d9a mwifiex: fix race condition causing tx timeout
ac3b561721e9 mwifiex: code rearrangement in mwifiex_usb_host_to_card()
--
https://patchwork.kernel.org/patch/9341883/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/4] rtl8xxxu: Fix off by one error calculating pubq
From: Kalle Valo @ 2016-09-26 17:42 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, Larry.Finger, Jes Sorensen
In-Reply-To: <1474420769-20086-2-git-send-email-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> This was detected tracing the 8188eu driver, but doesn't seem to make
> any difference when using it.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
4 patches applied to wireless-drivers-next.git, thanks.
3a589fae4a2c rtl8xxxu: Fix off by one error calculating pubq
c0a99bbb1b7a rtl8xxxu: Clean up llt_init() API
2fc5dd27bf9b rtl8xxxu: Use a struct rtl8xxxu_fileops * in rtl8xxxu_init_device()
b42fbed6b8a5 rtl8xxxu: Stop log spam from each successful interrupt
--
https://patchwork.kernel.org/patch/9342651/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: fix memory leak in brcmf_fill_bss_param
From: Kalle Valo @ 2016-09-26 17:49 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Rafał Miłecki, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <20160921062327.28729-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This function is called from get_station callback which means that every
> time user space was getting/dumping station(s) we were leaking 2 KiB.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Fixes: 1f0dc59a6de ("brcmfmac: rework .get_station() callback")
> Cc: stable@vger.kernel.org # 4.2+
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
23e9c128adb2 brcmfmac: fix memory leak in brcmf_fill_bss_param
--
https://patchwork.kernel.org/patch/9342879/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: drop unused fields from struct brcmf_pub
From: Kalle Valo @ 2016-09-26 17:51 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Rafał Miłecki, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Colin Ian King,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <20160923132759.21875-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> They seem to be there from the first day. We calculate these values but
> never use them.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Patch applied to wireless-drivers-next.git, thanks.
2df86ad959c9 brcmfmac: drop unused fields from struct brcmf_pub
--
https://patchwork.kernel.org/patch/9348103/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
From: Kalle Valo @ 2016-09-26 18:01 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Jouni Malinen, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <88d5023a-9a59-ab36-8c6c-a146cae803b5@users.sourceforge.net>
SF Markus Elfring <elfring@users.sourceforge.net> writes:
>> 9291771 [2/3] hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
>> 9291775 [3/3] hostap: Delete unnecessary initialisations for the variable "ret"
>>
>> Reason: The benefit is not clear.
>
> How do you think about to reduce the source code a bit at these places?
hostap is an obsolete driver, it's waste of time doing style fixes to it
as nobody maintains it anymore.
--
Kalle Valo
^ permalink raw reply
* Re: wil6200
From: Vikram @ 2016-09-26 18:05 UTC (permalink / raw)
To: Lior David; +Cc: linux-wireless
In-Reply-To: <a3435bed-4892-4606-44ac-523e47f57b1b@codeaurora.org>
Hi Lior,
On 26 September 2016 at 18:19, Lior David <liord@codeaurora.org> wrote:
> On 9/25/2016 6:15 PM, Vikram wrote:
>> Hi,
>>
>> Could you please let me know as to how to change the mode of wil6200
>> chip from WBE to WiFi?
>>
>> Regards,
>> Vikram
>>
> What is the exact device you are using? Older devices have firmware that only
> supports WBE mode.
>
> Thanks,
> Lior
I'm using Dell Wireless DW1601 7Gbps WiGig 802.11ad 802.11n 2*2 WiFi
Half Mini Card abgn+ad 2*2:2
Regards,
Vikram
^ permalink raw reply
* Re: hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
From: SF Markus Elfring @ 2016-09-26 18:06 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, netdev, Jouni Malinen, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <874m52zgjy.fsf@kamboji.qca.qualcomm.com>
> hostap is an obsolete driver, it's waste of time doing style fixes to it
> as nobody maintains it anymore.
Thanks for another bit of your software development attention and this information.
Is it easier to understand than the previous response "Reason: The benefit is not clear."?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-26 18:16 UTC (permalink / raw)
To: IgorMitsyanko
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <7ecc6f46-a65f-2342-d495-0decdeeef8fd@quantenna.com>
IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
> On 09/26/2016 01:56 PM, Kalle Valo wrote:
>> IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
>>> On 09/17/2016 04:46 PM, Kalle Valo wrote:
>>
>> For the initial submission please freeze the driver, otherwise it's pain
>> to review as the driver changes too much in-between review rounds. So at
>> this stage only minimal changes, please.
>>
>> You can continue adding new features and making changes, but do those as
>> follow up patches and use the initial submission as the baseline for the
>> new patches. Once the driver is applied you can submit the rest of the
>> patches adding new features and they will be reviewed similarly like all
>> other wireless patches.
>
> Ok, we will keep patch modification to minimum between revisions, but
> channels-related changes are something we would like to apply: we're
> setting SELF_MANAGED bit right now and do not handle regulatory hints
> from cfg80211, having all the regulatory-related info fixed on device
> itself (region, per-channel Tx powers, DFS requirements). This info is
> what was used to pass regulatory authorities certification, and
> considering seriousness of regulatory compliance requirement it's
> probably better to use the info that is known to be accepted.
> Would it be acceptable if we keep rates/capabilities logic intact, but
> will modify channel-related logic in next patch revision?
Sure, regulatory compliance is important and it's understandable that
you want to fix that. Just give a short summary in the change log what
you changed regarding regulatory to make it easier for the reviewers.
--
Kalle Valo
^ permalink raw reply
* Re: hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
From: Joe Perches @ 2016-09-26 18:18 UTC (permalink / raw)
To: Kalle Valo, SF Markus Elfring
Cc: linux-wireless, netdev, Jouni Malinen, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <874m52zgjy.fsf@kamboji.qca.qualcomm.com>
On Mon, 2016-09-26 at 21:01 +0300, Kalle Valo wrote:
> hostap is an obsolete driver, it's waste of time doing style fixes to it
> as nobody maintains it anymore.
Dunno know if Jouni is still maintaining this at all
but maybe a MAINTAINERS update to mark it obsolete so
checkpatch warns on unnecessary changes.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e0a912c3b13..ff293e70fae6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5722,7 +5722,7 @@ M: Jouni Malinen
L: hostap@shmoo.com (subscribers-only)
L: linux-wireless@vger.kernel.org
W: http://hostap.epitest.fi/
-S: Maintained
+S: Maintained / Obsolete
F: drivers/net/wireless/intersil/hostap/
HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
^ permalink raw reply related
* Re: hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
From: Kalle Valo @ 2016-09-26 18:37 UTC (permalink / raw)
To: Joe Perches
Cc: SF Markus Elfring, linux-wireless, netdev, Jouni Malinen, LKML,
kernel-janitors, Julia Lawall
In-Reply-To: <1474913885.2238.19.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Mon, 2016-09-26 at 21:01 +0300, Kalle Valo wrote:
>> hostap is an obsolete driver, it's waste of time doing style fixes to it
>> as nobody maintains it anymore.
>
> Dunno know if Jouni is still maintaining this at all
> but maybe a MAINTAINERS update to mark it obsolete so
> checkpatch warns on unnecessary changes.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6e0a912c3b13..ff293e70fae6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5722,7 +5722,7 @@ M: Jouni Malinen
> L: hostap@shmoo.com (subscribers-only)
> L: linux-wireless@vger.kernel.org
> W: http://hostap.epitest.fi/
> -S: Maintained
> +S: Maintained / Obsolete
> F: drivers/net/wireless/intersil/hostap/
I talked with Jouni and we concluded marking this fully obsolete is the
best (so removing the "Maintained" part completely). Also the shmoo list
is not used anymore, that can be removed.
--
Kalle Valo
^ permalink raw reply
* Re: hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()
From: Joe Perches @ 2016-09-26 18:43 UTC (permalink / raw)
To: Kalle Valo
Cc: SF Markus Elfring, linux-wireless, netdev, Jouni Malinen, LKML,
kernel-janitors, Julia Lawall
In-Reply-To: <87mviuy0b7.fsf@kamboji.qca.qualcomm.com>
On Mon, 2016-09-26 at 21:37 +0300, Kalle Valo wrote:
> I talked with Jouni and we concluded marking this fully obsolete is the
> best (so removing the "Maintained" part completelo the shmoo list
> is not used anymore, that can be removed.
Well, it would be best if Jouni submitted something.
^ permalink raw reply
* Re: [PATCH 07/10] iwlwifi: remove support for fw older than -17 and -22
From: Coelho, Luciano @ 2016-09-26 20:13 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: kvalo@codeaurora.org
In-Reply-To: <20160922205210.1778-8-luca@coelho.fi>
T24gVGh1LCAyMDE2LTA5LTIyIGF0IDIzOjUyICswMzAwLCBMdWNhIENvZWxobyB3cm90ZToNCj4g
RnJvbTogTHVjYSBDb2VsaG8gPGx1Y2lhbm8uY29lbGhvQGludGVsLmNvbT4NCj4gDQo+IEZXIHZl
cnNpb25zIG9sZGVyIHRoYW4gLTE3IGZvciAzMTYwIGFuZCA3MjYwIGFuZCBvbGRlciB0aGFuIC0y
MiBmb3INCj4gbmV3ZXIgTklDcyBhcmUgbm90IHN1cHBvcnRlZCBhbnltb3JlLsKgwqBEb24ndCBs
b2FkIHRoZXNlIHZlcnNpb25zDQo+IGFuZCByZW1vdmUgY29kZSB0aGF0IGhhbmRsZXMgdGhlbS4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IEx1Y2EgQ29lbGhvIDxsdWNpYW5vLmNvZWxob0BpbnRlbC5j
b20+DQo+IFNpZ25lZC1vZmYtYnk6IEx1Y2EgQ29lbGhvIDxsdWNpYW5vLmNvZWxob0BpbnRlbC5j
b20+DQo+IC0tLQ0KDQpIZWgsIGRvdWJsZSBTLU8tQi4gwqBJJ2xsIGZpeCB0aGlzIGJlZm9yZSBz
ZW5kaW5nIHRoZSBwdWxsIHJlcXVlc3QuDQoNCi0tDQpMdWNhLg==
^ permalink raw reply
* pull-request: iwlwifi-next 2016-09-26
From: Luca Coelho @ 2016-09-26 20:24 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]
Hi Kalle,
One more small pull-request intended for 4.9. It seems that I'm
actually catching up with our internal tree! :) Nothing major here,
mostly clean-ups and small bug fixes and improvements.
Let me know if everything's fine (or not). :)
Luca.
The following changes since commit 0979a913f879ea39504200d83fb9f275a555a58d:
iwlwifi: pcie: use LIST_HEAD() macro (2016-09-19 11:29:35 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2016-09-26
for you to fetch changes up to 9cd70e80f7f0df1d6d13d8aeb50a16bf40e2962c:
iwlwifi: mvm: initialise ADD_STA before sending it to the firmware (2016-09-26 23:15:26 +0300)
----------------------------------------------------------------
* Some new HW IDs;
* Small fix in CTDP error handling;
* Remove support for older firmwares;
* Clean-ups and a few simple fixes here and there.
----------------------------------------------------------------
Emmanuel Grumbach (2):
iwlwifi: mvm: fix typo in TC_CMD_SEC_KEY_FROM_TABLE
iwlwifi: mvm: initialise ADD_STA before sending it to the firmware
Johannes Berg (2):
iwlwifi: pcie: avoid variable shadowing in TFD helpers
iwlwifi: mvm: correct rate_idx bounds-check
Luca Coelho (2):
iwlwifi: mvm: bail out if CTDP start operation fails
iwlwifi: remove support for fw older than -17 and -22
Oren Givon (1):
iwlwifi: add two new 9560 series PCI IDs
Sara Sharon (3):
iwlwifi: mvm: cleanup redundant no_power_up_nic_in_init config
iwlwifi: mvm: cleanup usage of init_dbg parameter
iwlwifi: allow error table address new range
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 6 +++---
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 1 -
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 24 +-----------------------
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 3 +--
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-power.h | 21 ++++++---------------
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 6 ++----
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 43 +++++++++++++++++++------------------------
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 24 +++++++++---------------
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 --
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 52 +++++++++++++++++-----------------------------------
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 15 +++++----------
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 27 ++++-----------------------
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 10 ++--------
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 4 ++--
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 2 ++
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 19 ++++++++-----------
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 47 +++++++++++++++++++++++++----------------------
21 files changed, 110 insertions(+), 204 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] brcmfmac: proto: add callback for queuing TX data
From: Rafał Miłecki @ 2016-09-26 21:51 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
So far our core code was calling brcmf_fws_process_skb which wasn't
a proper thing to do. If case of devices using msgbuf protocol fwsignal
shouldn't be used. It was an unnecessary extra layer simply calling
a protocol specifix txdata function.
Please note we already have txdata callback, but it's used for calls
between bcdc and fwsignal so it couldn't be simply used there.
This makes core code more generic (instead of bcdc/fwsignal specific).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
There is one 1 CHECK report from checkpatch.pl in this patch:
CHECK: Comparison to NULL could be written "!proto->hdrpull"
#157: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c:54:
+ if (!proto->tx_queue_data || (proto->hdrpull == NULL) ||
It's caused by a code that was already there and that should be fixed
in a separated patch. This shouldn't stop this patch from being applied.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 12 ++++++++++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 8 +++++++-
.../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 15 +++++----------
.../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 6 +++---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h | 9 +++++++++
7 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 038a960..384b187 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -326,6 +326,17 @@ brcmf_proto_bcdc_hdrpull(struct brcmf_pub *drvr, bool do_fws,
return 0;
}
+static int brcmf_proto_bcdc_tx_queue_data(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb)
+{
+ struct brcmf_if *ifp = brcmf_get_ifp(drvr, ifidx);
+
+ if (!brcmf_fws_queue_skbs(drvr->fws))
+ return brcmf_proto_txdata(drvr, ifidx, 0, skb);
+
+ return brcmf_fws_process_skb(ifp, skb);
+}
+
static int
brcmf_proto_bcdc_txdata(struct brcmf_pub *drvr, int ifidx, u8 offset,
struct sk_buff *pktbuf)
@@ -375,6 +386,7 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
drvr->proto->hdrpull = brcmf_proto_bcdc_hdrpull;
drvr->proto->query_dcmd = brcmf_proto_bcdc_query_dcmd;
drvr->proto->set_dcmd = brcmf_proto_bcdc_set_dcmd;
+ drvr->proto->tx_queue_data = brcmf_proto_bcdc_tx_queue_data;
drvr->proto->txdata = brcmf_proto_bcdc_txdata;
drvr->proto->configure_addr_mode = brcmf_proto_bcdc_configure_addr_mode;
drvr->proto->delete_peer = brcmf_proto_bcdc_delete_peer;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 1715280..6d046ba 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -239,7 +239,13 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
if (eh->h_proto == htons(ETH_P_PAE))
atomic_inc(&ifp->pend_8021x_cnt);
- ret = brcmf_fws_process_skb(ifp, skb);
+ /* determine the priority */
+ if ((skb->priority == 0) || (skb->priority > 7))
+ skb->priority = cfg80211_classify8021d(skb, NULL);
+
+ ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);
+ if (ret < 0)
+ brcmf_txfinalize(ifp, skb, false);
done:
if (ret) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index a190f53..5f1a592 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2100,16 +2100,6 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
int rc = 0;
brcmf_dbg(DATA, "tx proto=0x%X\n", ntohs(eh->h_proto));
- /* determine the priority */
- if ((skb->priority == 0) || (skb->priority > 7))
- skb->priority = cfg80211_classify8021d(skb, NULL);
-
- if (fws->avoid_queueing) {
- rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
- if (rc < 0)
- brcmf_txfinalize(ifp, skb, false);
- return rc;
- }
/* set control buffer information */
skcb->if_flags = 0;
@@ -2442,6 +2432,11 @@ void brcmf_fws_deinit(struct brcmf_pub *drvr)
kfree(fws);
}
+bool brcmf_fws_queue_skbs(struct brcmf_fws_info *fws)
+{
+ return !fws->avoid_queueing;
+}
+
bool brcmf_fws_fc_active(struct brcmf_fws_info *fws)
{
if (!fws->creditmap_received)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
index ef0ad85..96df660 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
@@ -20,6 +20,7 @@
int brcmf_fws_init(struct brcmf_pub *drvr);
void brcmf_fws_deinit(struct brcmf_pub *drvr);
+bool brcmf_fws_queue_skbs(struct brcmf_fws_info *fws);
bool brcmf_fws_fc_active(struct brcmf_fws_info *fws);
void brcmf_fws_hdrpull(struct brcmf_if *ifp, s16 siglen, struct sk_buff *skb);
int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index 2b9a2bc..7cc8851 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -782,8 +782,8 @@ static int brcmf_msgbuf_schedule_txdata(struct brcmf_msgbuf *msgbuf, u32 flowid,
}
-static int brcmf_msgbuf_txdata(struct brcmf_pub *drvr, int ifidx,
- u8 offset, struct sk_buff *skb)
+static int brcmf_msgbuf_tx_queue_data(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb)
{
struct brcmf_msgbuf *msgbuf = (struct brcmf_msgbuf *)drvr->proto->pd;
struct brcmf_flowring *flow = msgbuf->flow;
@@ -1467,7 +1467,7 @@ int brcmf_proto_msgbuf_attach(struct brcmf_pub *drvr)
drvr->proto->hdrpull = brcmf_msgbuf_hdrpull;
drvr->proto->query_dcmd = brcmf_msgbuf_query_dcmd;
drvr->proto->set_dcmd = brcmf_msgbuf_set_dcmd;
- drvr->proto->txdata = brcmf_msgbuf_txdata;
+ drvr->proto->tx_queue_data = brcmf_msgbuf_tx_queue_data;
drvr->proto->configure_addr_mode = brcmf_msgbuf_configure_addr_mode;
drvr->proto->delete_peer = brcmf_msgbuf_delete_peer;
drvr->proto->add_tdls_peer = brcmf_msgbuf_add_tdls_peer;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c
index 26b68c3..d26ff21 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c
@@ -51,7 +51,7 @@ int brcmf_proto_attach(struct brcmf_pub *drvr)
drvr->bus_if->proto_type);
goto fail;
}
- if ((proto->txdata == NULL) || (proto->hdrpull == NULL) ||
+ if (!proto->tx_queue_data || (proto->hdrpull == NULL) ||
(proto->query_dcmd == NULL) || (proto->set_dcmd == NULL) ||
(proto->configure_addr_mode == NULL) ||
(proto->delete_peer == NULL) || (proto->add_tdls_peer == NULL)) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
index 57531f4..34b59fe 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
@@ -33,6 +33,8 @@ struct brcmf_proto {
void *buf, uint len);
int (*set_dcmd)(struct brcmf_pub *drvr, int ifidx, uint cmd, void *buf,
uint len);
+ int (*tx_queue_data)(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb);
int (*txdata)(struct brcmf_pub *drvr, int ifidx, u8 offset,
struct sk_buff *skb);
void (*configure_addr_mode)(struct brcmf_pub *drvr, int ifidx,
@@ -74,6 +76,13 @@ static inline int brcmf_proto_set_dcmd(struct brcmf_pub *drvr, int ifidx,
{
return drvr->proto->set_dcmd(drvr, ifidx, cmd, buf, len);
}
+
+static inline int brcmf_proto_tx_queue_data(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb)
+{
+ return drvr->proto->tx_queue_data(drvr, ifidx, skb);
+}
+
static inline int brcmf_proto_txdata(struct brcmf_pub *drvr, int ifidx,
u8 offset, struct sk_buff *skb)
{
--
2.9.3
^ permalink raw reply related
* Re: [PATCHv2] mac80211: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-27 8:01 UTC (permalink / raw)
To: Michael Braun
Cc: linux-wireless, projekt-wlan, Amitkumar Karwar, Avinash Patil
In-Reply-To: <1474802886-27220-1-git-send-email-michael-dev@fami-braun.de>
Huh. I know this bug, I thought we fixed it a long time ago. Oops.
> - struct ethhdr eth;
> + struct ethhdr eth, eth_80211;
> bool reuse_frag = skb->head_frag && !skb_has_frag_list(skb);
> bool reuse_skb = false;
> bool last = false;
>
> if (has_80211_header) {
> - err = __ieee80211_data_to_8023(skb, ð, addr,
> iftype);
> + err = __ieee80211_data_to_8023(skb, ð_80211,
> addr, iftype);
> if (err)
> goto out;
> }
This leaves "eth_80211" uninitialized if has_80211_header is false.
> @@ -768,6 +768,13 @@ void ieee80211_amsdu_to_8023s(struct sk_buff
> *skb, struct sk_buff_head *list,
> subframe_len = sizeof(struct ethhdr) + len;
> padding = (4 - subframe_len) & 0x3;
>
> + if (unlikely(has_80211_header &&
> + (iftype == NL80211_IFTYPE_AP ||
> + iftype == NL80211_IFTYPE_AP_VLAN) &&
> + !ether_addr_equal(eth_80211.h_source,
> eth.h_source)
> + ))
> + goto purge;
And this then compares against uninitialized data, so this won't work.
I'd suggest removing the "has_80211_header" argument entirely, and
replacing it with a "const u8 *sa" argument, but that complicates
mac80211 significantly since all the checks
in __ieee80211_data_to_8023() would have to be replicated.
Maybe we can still do this, and say that it must be NULL when an 802.11
header is present, and be the SA when not. However, mwifiex doesn't
seem to be able to easily provide the SA (at least I don't see it,
perhaps it can), so that we'd have to allow some kind of ERR_PTR() or
something for that special case ... Actually it'd be better to just fix
mwifiex though :)
The staging driver using this (rtl8712) can easily provide the SA,
afaict.
johannes
^ permalink raw reply
* Re: [PATCHv2] mac80211: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-27 8:55 UTC (permalink / raw)
To: michael-dev; +Cc: linux-wireless, projekt-wlan, Amitkumar Karwar, Avinash Patil
In-Reply-To: <dbc9f09e4d932d808fed99ebd02301c0@fami-braun.de>
On Tue, 2016-09-27 at 10:53 +0200, michael-dev wrote:
> Am 27.09.2016 10:01, schrieb Johannes Berg:
> >
> > ...
> >
> > This leaves "eth_80211" uninitialized if has_80211_header is false.
> >
> > >
> > > @@ -768,6 +768,13 @@ void ieee80211_amsdu_to_8023s(struct sk_buff
> > > *skb, struct sk_buff_head *list,
> > > subframe_len = sizeof(struct ethhdr) + len;
> > > padding = (4 - subframe_len) & 0x3;
> > >
> > > + if (unlikely(has_80211_header &&
> > > + (iftype == NL80211_IFTYPE_AP ||
> > > + iftype == NL80211_IFTYPE_AP_VLAN)
> > > &&
> > > > > > + !ether_addr_equal(eth_80211.h_source,
> > > eth.h_source)
> > > + ))
> > > + goto purge;
> >
> > And this then compares against uninitialized data, so this won't
> > work.
>
> but it only compares against eth_80211 if has_80211_header is true
> due to order of evaluation, which in turn implies eth_80211 is
> initialized, right?
>
Oh, right, I missed that, sorry.
Nevertheless, it seems it would be better to allow the other users (not
mac80211) that have has_80211_header=false to still have the check?
johannes
^ permalink raw reply
* Re: [PATCHv2] mac80211: check A-MSDU inner frame source address on AP interfaces
From: michael-dev @ 2016-09-27 8:53 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, projekt-wlan, Amitkumar Karwar, Avinash Patil
In-Reply-To: <1474963267.5141.11.camel@sipsolutions.net>
Am 27.09.2016 10:01, schrieb Johannes Berg:
> ...
>=20
> This leaves "eth_80211" uninitialized if has_80211_header is false.
>=20
>> @@ -768,6 +768,13 @@ void ieee80211_amsdu_to_8023s(struct sk_buff
>> *skb, struct sk_buff_head *list,
>> =C2=A0 subframe_len =3D sizeof(struct ethhdr) + len;
>> =C2=A0 padding =3D (4 - subframe_len) & 0x3;
>> =C2=A0
>> + if (unlikely(has_80211_header &&
>> + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(iftype =3D=3D NL80211_IFTYPE_AP ||
>> + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0iftype =3D=3D NL80211_IFTYPE_AP_=
VLAN) &&
>> + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0!ether_addr_equal(eth_80211.h_source,
>> eth.h_source)
>> + =C2=A0=C2=A0=C2=A0))
>> + goto purge;
>=20
> And this then compares against uninitialized data, so this won't work.
but it only compares against eth_80211 if has_80211_header is true due=20
to order of evaluation, which in turn implies eth_80211 is initialized,=20
right?
michael
^ permalink raw reply
* bcmdhd: Strange Power Save messages
From: Gucea Doru @ 2016-09-27 9:03 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless
Hello,
I am analyzing the Power Save algorithm used on a pair of Nexus 5
devices. The devices use the bcmdhd Broadcom driver and are Wi-Fi
Direct connected.
My test is very simple: I send ping packets from the P2P client
towards the P2P GO. Before sending a ping packet the P2P client enters
PS mode (it sends a Null frame with the PWR MGT bit set). A few
miliseconds later, the P2P client sends the ping request message. Once
the ping request is ACKed the P2P client exits the PS mode (it sends a
Null frame with the PWR MGT bit unset) and the P2P GO decides to send
him the ping reply.
What is the decision triggering the exit from the PS mode immediately
after the ping request? I am asking this because 802.11 PS legacy
specifies that the client should wait for a beacon with TIM set in
order to wake up: in my case, there is no beacon between the ping
request message and the Null frame that announces the exit from the PS
mode.
For reference, the Wireshark trace can be found at [1].
SSID: DIRECT-35-Android_Intel
WPA pass: JYdrhZp3
[1] https://drive.google.com/file/d/0B5SBH08PU_ChQk95LWpzekh3VU0/view?usp=sharing
Thank you,
Doru
^ permalink raw reply
* Re: [PATCH] brcmfmac: implement more accurate skb tracking
From: Arend Van Spriel @ 2016-09-27 9:06 UTC (permalink / raw)
To: Dan Williams, Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List,
Rafał Miłecki
In-Reply-To: <1474901966.4519.8.camel@redhat.com>
On 26-9-2016 16:59, Dan Williams wrote:
> On Mon, 2016-09-26 at 14:13 +0200, Rafał Miłecki wrote:
>> On 26 September 2016 at 13:46, Arend Van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>>
>>> On 26-9-2016 12:23, Rafał Miłecki wrote:
>>>>
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> We need to track 802.1x packets to know if there are any pending
>>>> ones
>>>> for transmission. This is required for performing key update in
>>>> the
>>>> firmware.
>>>
>>> The problem we are trying to solve is a pretty old one. The problem
>>> is
>>> that wpa_supplicant uses two separate code paths: EAPOL messaging
>>> through data path and key configuration though nl80211.
>>
>> Can I find it described/reported somewhere?
>
> If I understand the issue correctly, you can find all this in the
> supplicant code. Once the supplicant has done whatever it wants to do
> with the data frames that just happen to be EAPOL it then sends the
> keys down to the driver with nl80211.
Indeed. EAPOL packets are simply data packets as far as the 802.11 stack
is concerned. The arrival of those in the driver is not predictable
hence we hold off the key configuration until those have been passed
over to firmware.
> But it sounds like, instead of sniffing EAPOL frames in the driver skb
> tracking and sniffing ETH_P_PAE, you should probably implement support
> for NL80211_CMD_CRIT_PROTOCOL_START/NL80211_CMD_CRIT_PROTOCOL_STOP and
> key off the passed-in NL80211_CRIT_PROTO_EAPOL. At least at the
> beginning of connection setup only EAPOL packets will be allowed
> anyway.
>
> It doesn't seem like the supplicant uses NL80211_CRIT_PROTO_EAPOL yet,
> but that should also be fixed in the supplicant itself. You should
> probably get some comments from Jouni on how he'd like to see all this
> work. But generally the less specific sniffing of frames in drivers,
> likely the better.
Indeed. That was the main motivation to introduce the CRIT_PROTO api. If
I recall correctly it was considered the task of the network manager to
issue the START/STOP. Recently noticed the use of CRIT_PROTO_DHCP on
some target system, which we already support in brcmfmac. From your
response I guess you consider CRIT_PROTO_EAPOL to be issued by the
supplicant.
Regards,
Arend
> Dan
>
>>
>>>
>>>>
>>>> Unfortunately our old tracking code wasn't very accurate. It was
>>>> treating skb as pending as soon as it was passed by the netif.
>>>> Actual
>>>> handling packet to the firmware was happening later as brcmfmac
>>>> internally queues them and uses its own worker(s).
>>>
>>> That does not seem right. As soon as we get a 1x packet we need to
>>> wait
>>> with key configuration regardless whether it is still in the driver
>>> or
>>> handed over to firmware already.
>>
>> OK, thanks.
^ permalink raw reply
* [PATCH 4.9] brcmfmac: use correct skb freeing helper when deleting flowring
From: Rafał Miłecki @ 2016-09-27 9:14 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
Flowrings contain skbs waiting for transmission that were passed to us
by netif. It means we checked every one of them looking for 802.1x
Ethernet type. When deleting flowring we have to use freeing function
that will check for 802.1x type as well.
Freeing skbs without a proper check was leading to counter not being
properly decreased. This was triggering a WARNING every time
brcmf_netdev_wait_pend8021x was called.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
Kalle: this isn't important enough for 4.8 as it's too late for that.
I'd like to get it for 4.9 however, as this fixes bug that could lead
to WARNING on every add_key/del_key call. We was struggling with these
WARNINGs for some time and this fixes one of two problems causing them.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
index b16b367..d0b738d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
@@ -234,13 +234,20 @@ static void brcmf_flowring_block(struct brcmf_flowring *flow, u16 flowid,
void brcmf_flowring_delete(struct brcmf_flowring *flow, u16 flowid)
{
+ struct brcmf_bus *bus_if = dev_get_drvdata(flow->dev);
struct brcmf_flowring_ring *ring;
+ struct brcmf_if *ifp;
u16 hash_idx;
+ u8 ifidx;
struct sk_buff *skb;
ring = flow->rings[flowid];
if (!ring)
return;
+
+ ifidx = brcmf_flowring_ifidx_get(flow, flowid);
+ ifp = brcmf_get_ifp(bus_if->drvr, ifidx);
+
brcmf_flowring_block(flow, flowid, false);
hash_idx = ring->hash_id;
flow->hash[hash_idx].ifidx = BRCMF_FLOWRING_INVALID_IFIDX;
@@ -249,7 +256,7 @@ void brcmf_flowring_delete(struct brcmf_flowring *flow, u16 flowid)
skb = skb_dequeue(&ring->skblist);
while (skb) {
- brcmu_pkt_buf_free_skb(skb);
+ brcmf_txfinalize(ifp, skb, false);
skb = skb_dequeue(&ring->skblist);
}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] brcmfmac: implement more accurate skb tracking
From: Arend Van Spriel @ 2016-09-27 9:24 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List,
Rafał Miłecki
In-Reply-To: <CACna6ryNLOqrwsa9KFueUdqStxjP7KoRyvsn6eynLc6Y7Ug_sw@mail.gmail.com>
On 26-9-2016 14:38, Rafał Miłecki wrote:
> On 26 September 2016 at 14:13, Rafał Miłecki <zajec5@gmail.com> wrote:
>> On 26 September 2016 at 13:46, Arend Van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 26-9-2016 12:23, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> We need to track 802.1x packets to know if there are any pending ones
>>>> for transmission. This is required for performing key update in the
>>>> firmware.
>>>
>>> The problem we are trying to solve is a pretty old one. The problem is
>>> that wpa_supplicant uses two separate code paths: EAPOL messaging
>>> through data path and key configuration though nl80211.
>>
>> Can I find it described/reported somewhere?
>>
>>
>>>> Unfortunately our old tracking code wasn't very accurate. It was
>>>> treating skb as pending as soon as it was passed by the netif. Actual
>>>> handling packet to the firmware was happening later as brcmfmac
>>>> internally queues them and uses its own worker(s).
>>>
>>> That does not seem right. As soon as we get a 1x packet we need to wait
>>> with key configuration regardless whether it is still in the driver or
>>> handed over to firmware already.
>>
>> OK, thanks.
>
> Actually, it's not OK. I was trying to report/describe/discuss this
> problem for over a week. I couldn't get much of answer from you.
>
> I had to come with a patch I worked on for quite some time. Only then
> you decided to react and reply with a reason for a nack. I see this
> patch may be wrong (but it's still hard to know what's going wrong
> without a proper hostapd bug report). I'd expect you to somehow work &
> communicate with open source community.
We do or at least make an honest attempt, but there is more on our plate
so responses may be delayed. It also does not help when you get anal and
preachy when we do respond. Also not OK. In this case the delay is
caused because I had to pick up the thread(s) as Hante is on vacation
(he needed a break :-p ). However, you started sending patches so I
decided to look at and respond to those. Sorry if you felt like we left
you hanging to dry.
Regards,
Arend
^ 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