* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Antonio Quartulli @ 2016-10-24 12:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <564F1790.7030309@open-mesh.com>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
On Fri, Nov 20, 2015 at 08:52:32PM +0800, Antonio Quartulli wrote:
> On 20/11/15 18:49, Johannes Berg wrote:
> >
> >> @@ -599,7 +599,9 @@ static int __ieee80211_start_scan(struct
> >> ieee80211_sub_if_data *sdata,
> >>
> >> if ((req->channels[0]->flags &
> >> IEEE80211_CHAN_NO_IR) ||
> >> - !req->n_ssids) {
> >> + !req->n_ssids ||
> >> + ((req->channels[0]->flags &
> >> IEEE80211_CHAN_RADAR) &&
> >> + (req->flags &
> >> NL80211_SCAN_FLAG_PASSIVE_RADAR))) {
> >> next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
> >>
> >
> > I don't really see any circumstances under which it's valid to actively
> > scan radar channels ... seems like we should do this unconditionally?
>
> I think it would be reasonable only if the target channel is the one we
> are using and we have done CSA. But when scanning non-operative channels
> I don't think this could work.
>
> As discussed on IRC I'd rather go for passively scanning any DFS channel.
>
> Cheers,
Hey Johannes,
this has been sleeping for a while.. :)
Would it make sense to rebase it and resubmit it for inclusion?
Given the previous discussion we could change the logic as:
* always passively scan DFS channels that are not usable
* always actively scan DFS channels that are usable (i.e. CAC was performed).
How does it sound? this would totally avoid the use of the switch in the scan
command.
Cheers,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re[2]: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Matthias Klein @ 2016-10-24 12:08 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless
In-Reply-To: <CA+BoTQkXtEcL9yk8_rYb3Z=CBkzs5R1LyMZfVCbGrsH_3Lx7eg@mail.gmail.com>
>I (naively) went through pci/pm git log and found the following was
>applied on 4.7-rc2 (i.e. prior to 4.7 release):
>
> commit 006d44e49a259b39947366728d65a873a19aadc0
> Author: Mika Westerberg <mika.westerberg@linux.intel.com>
> Date: Thu Jun 2 11:17:15 2016 +0300
>
> PCI: Add runtime PM support for PCIe ports
>
>From reading the commit log it seems to me like it could be it.
>
>ath10k tries to wake up the device during probing before it starts
>talking to it and it does so through MMIO/PCI config space. If it's
>not mapped properly then driver will not be able to wake it up and
>will timeout waiting for it.
>
>Can you try cherry-picking it into your 4.4.24 and see if it helps?
>
>
Thanks for the help!
Until now I did not compile a kernel for the board.
I will give it a try and come back with the results ...
Best regards,
Matthias
^ permalink raw reply
* RE: [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Undekari, Sunil Dutt @ 2016-10-24 11:59 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <1477052876.4068.40.camel@sipsolutions.net>
PiBJJ3ZlIGp1c3Qgc2VudCBvdXQgYSBmZXcgcGF0Y2hlcyB0aGF0LCBJIHRoaW5rLCBpbXBsZW1l
bnQgdGhlIG5lY2Vzc2FyeSB2YWxpZGF0aW9uIGZvciBqdXN0IHRoZSBiZWFjb24gaW50ZXJ2YWxz
LCB3aXRob3V0IGFsbCB0aGlzIGV4dHJhIGJhZ2dhZ2UuIFBsZWFzZSB0YWtlIGEgbG9vayBhbmQg
bGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsuDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgbmV3IHBh
dGNoZXMgZnJvbSB5b3UgYXJlIGluIGNvbnNpc3RlbnQgd2l0aCB0aGUgZXhpc3RpbmcgZGVzaWdu
IG9mIHZhbGlkYXRpbmcgdGhlIHJhZGFyIGRldGVjdGlvbiAvIGNoYW5uZWxzIGJ5IGhhdmluZyB0
aGlzIHZhbGlkYXRpb24gZG9uZSBpbiB0aGUgY2ZnODAyMTEgZHJpdmVycyB0aHJvdWdoIGNmZzgw
MjExX2NoZWNrX2NvbWJpbmF0aW9ucy4NCldpdGggdGhpcyBhcHByb2FjaCAsIHdvdWxkbid0IHRo
ZSBleGlzdGluZyBjZmc4MDIxMSBkcml2ZXJzIGJlaGF2ZSB0aGUgb3RoZXIgd2F5ID8gSSBtZWFu
ICwgd2l0aCB0aGVzZSBjb21taXRzIGFuZCB0aGUgY3VycmVudCBjZmc4MDIxMSBkcml2ZXJzICgg
ZG8gbm90IGFkdmVydGlzZSBiZWFjb25faW50X21pbl9nY2QgYW5kIGludm9rZSBjZmc4MDIxMV9j
aGVja19jb21iaW5hdGlvbnMpICwgdGhlIHZhbGlkYXRpb24gZm9yIHRoZSBkaWZmZXJlbnQgYmVh
Y29uIGludGVydmFsIHNoYWxsIHN1Y2NlZWQgLCBidXQgdGhlIGN1cnJlbnQga2VybmVsICggY2Zn
ODAyMTEgaW50ZXJmYWNlICkgd2l0aCB0aGUgc2FtZSBkcml2ZXIgZmFpbHMgdGhlIHN0YXJ0IG9m
IHRoZSBBUCAvIG1lc2guIA0KSXMgaXQgbm90IGJyZWFraW5nIHRoZSBiYWNrd2FyZCBjb21wYXRp
YmlsaXR5ID8gSXMgdGhpcyBleHBlY3RlZCA/IA0KDQpSZWdhcmRzLA0KU3VuaWwNCg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWlsdG86am9o
YW5uZXNAc2lwc29sdXRpb25zLm5ldF0gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjEsIDIwMTYg
NTo1OCBQTQ0KVG86IEt1c2h3YWhhLCBQdXJ1c2hvdHRhbSA8cGt1c2h3YWhAcXRpLnF1YWxjb21t
LmNvbT4NCkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE1hbGluZW4sIEpvdW5p
IDxqb3VuaUBxY2EucXVhbGNvbW0uY29tPjsgVW5kZWthcmksIFN1bmlsIER1dHQgPHVzZHV0dEBx
dGkucXVhbGNvbW0uY29tPjsgSHVsbHVyIFN1YnJhbWFueWFtLCBBbWFybmF0aCA8YW1hcm5hdGhA
cWNhLnF1YWxjb21tLmNvbT4NClN1YmplY3Q6IFJlOiBbUEFUQ0ggdjNdIGNmZzgwMjExOiBDaGVj
ayByYWRhcl9kZXRlY3QgYW5kIG51bV9kaWZmZXJlbnRfY2hhbm5lbHMgd2l0aCBiZWFjb24gaW50
ZXJmYWNlIGNvbWJpbmF0aW9ucy4NCg0KT24gVGh1LCAyMDE2LTEwLTEzIGF0IDIwOjQ1ICswNTMw
LCBQdXJ1c2hvdHRhbSBLdXNod2FoYSB3cm90ZToNCj4gVGhpcyBjb21taXQgZW5oYW5jZXMgdGhl
IGN1cnJlbnQgYmVhY29uIGludGVydmFsIHZhbGlkYXRpb24gdG8gYWxzbyANCj4gY29uc2lkZXIg
dGhlICJyYWRhcl9kZXRlY3QiIGFuZCAibnVtX2RpZmZlcmVudF9jaGFubmVscyIuDQo+IA0KPiBN
b3ZlIGNhbGN1bGF0aW9uIG9mIEdDRCBmb3IgYWxsIGJlYWNvbmluZyBpbnRlcmZhY2VzIHRvIA0K
PiAiY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMiLg0KPiANCj4gUmVuYW1lICJjZmc4MDIxMV92
YWxpZGF0ZV9iZWFjb25faW50IiB0byANCj4gImNmZzgwMjExX3ZhbGlkYXRlX2JlYWNvbl9jb21i
aW5hdGlvbiINCj4gYXMgdGhlIHZhbGlkYXRpb24gY29uc2lkZXJzIG90aGVyIHBhcmFtZXRlcnMu
DQoNClNvIHRoaXMgd2FzIGJldHRlciwgYnV0IEkgdGhpbmsgd2UncmUgbWl4aW5nIHRvbyBtYW55
IHRoaW5ncyBpbiBoZXJlLg0KDQpJJ20gbm90IGNvbnZpbmNlZCwgZm9yIGV4YW1wbGUsIHRoYXQg
Y2hlY2tpbmcgaWYgcmFkYXIgaXMgcmVxdWlyZWQgaXMgcmVhbGx5IHRoZSByaWdodCB0aGluZywg
aXQgbWlnaHQgc3RpbGwgYmUgZW5hYmxlZCBldmVuIGlmIGl0J3Mgbm90IHJlcXVpcmVkIChhbnkg
bW9yZSwgcmVndWxhdG9yeSBtYXkgY2hhbmdlKT8NCg0KTm90IHRoYXQgSSBkb24ndCB0aGluayB0
aGF0J3MgYSB3b3J0aHdoaWxlIGdvYWwgLSBtb3ZpbmcgbW9yZSBvZiB0aGUgZGF0YS9jYWxjdWxh
dGlvbiBiYWNrIGludG8gY2ZnODAyMTEgLSBidXQgSSBkb24ndCB0aGluayBpdCBzaG91bGQgYmUg
bWl4ZWQgaW4gaGVyZS4NCg0KSSd2ZSBqdXN0IHNlbnQgb3V0IGEgZmV3IHBhdGNoZXMgdGhhdCwg
SSB0aGluaywgaW1wbGVtZW50IHRoZSBuZWNlc3NhcnkgdmFsaWRhdGlvbiBmb3IganVzdCB0aGUg
YmVhY29uIGludGVydmFscywgd2l0aG91dCBhbGwgdGhpcyBleHRyYSBiYWdnYWdlLiBQbGVhc2Ug
dGFrZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93IHdoYXQgeW91IHRoaW5rLg0KDQpqb2hhbm5lcw0K
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Michal Kazior @ 2016-10-24 11:40 UTC (permalink / raw)
To: Matthias Klein; +Cc: linux-wireless
In-Reply-To: <emfd19c3e4-1b17-443b-b80a-e6b60a49f9dc@nb-mak>
On 24 October 2016 at 12:18, Matthias Klein <matthias.klein@optimeas.de> wr=
ote:
> I also try to get a pcie wifi card (Compex WLE600VX) running in the clear=
fog
> pro board with kernel 4.4.
>
> As I read in this thread the "irg.mode=3D1" shoud help:
> https://www.spinics.net/lists/linux-wireless/msg155685.html
>
> But it is not working for me:
>
[...]
> [ 97.899370] ath10k_pci 0000:01:00.0: Refused to change power state,
> currently in D3
> [ 97.938045] ath10k_pci 0000:01:00.0: failed to wake up device : -110
> [ 97.944973] ath10k_pci: probe of 0000:01:00.0 failed with error -110
[...]
> 01:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
> Network Adapter (rev ff) (prog-if ff)
> !!! Unknown header type 7f
The device looks completely unresponsive.
I don't think this is MSI problem. This error happens before
interrupts are even set up.
I suspect platform/PCI/PM specific problem. I would suggest bisecting
the kernel and seeing which patch is making the difference.
I (naively) went through pci/pm git log and found the following was
applied on 4.7-rc2 (i.e. prior to 4.7 release):
commit 006d44e49a259b39947366728d65a873a19aadc0
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Thu Jun 2 11:17:15 2016 +0300
PCI: Add runtime PM support for PCIe ports
>From reading the commit log it seems to me like it could be it.
ath10k tries to wake up the device during probing before it starts
talking to it and it does so through MMIO/PCI config space. If it's
not mapped properly then driver will not be able to wake it up and
will timeout waiting for it.
Can you try cherry-picking it into your 4.4.24 and see if it helps?
Micha=C5=82
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Jonas Gorski @ 2016-10-24 11:14 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <faedb36a-d99c-5891-e9c6-40ecc4d54748@gmail.com>
Hi,
(please don't toppost)
On 23 October 2016 at 21:42, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> Thanks, but its still not working. I dont get any error now when i do
> modprobe and installed is the wle900
>
> [root@alarm alarm]# rmmod ath10k_pci
> [root@alarm alarm]# modprobe ath10k_pci irq_mode=1
Strange, this was working for me with a Sparklan WPEA-352ACN.
>
> but:
>
> [root@alarm alarm]# dmesg | grep ath10k
> [ 220.356314] ath10k_pci 0000:02:00.0: Refused to change power state,
> currently in D3
Maybe there is a separate issue related to this. I don't remember
seeing this message in my kernel log. (At least to me) it would be
interesting to know if it works using a LEDE image, or if it fails
there as well. I don't have a Compex card here.
You can find an sd-card image at
https://downloads.lede-project.org/snapshots/targets/mvebu/generic/ -
it won't contain any wifi drivers though, you will need to install
them separately - easiest by providing internet access over the wan
port (the single ethernet port for the pro, it defaults to dhcp
client), then running "opkg install kmod-ath10k" on shell.
Note that this kernel has MSI disabled, so you don't need to do
anything there extra.
> [ 220.394265] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> [ 220.400770] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>
> [root@alarm alarm]# cat /proc/cmdline
> console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait ath10k_pci.irq_mode=1
>
> Thanks for your patience
Regards
Jonas
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Matthias Klein @ 2016-10-24 10:18 UTC (permalink / raw)
To: linux-wireless; +Cc: Klein, Matthias
I also try to get a pcie wifi card (Compex WLE600VX) running in the
clearfog pro board with kernel 4.4.
As I read in this thread the "irg.mode=1" shoud help:
https://www.spinics.net/lists/linux-wireless/msg155685.html
But it is not working for me:
debian@clearfog:~$ lsmod
Module Size Used by
8021q 36864 0
garp 16384 1 8021q
mrp 20480 1 8021q
stp 16384 1 garp
llc 16384 2 stp,garp
bnep 20480 2
ath10k_pci 45056 0
ath10k_core 249856 1 ath10k_pci
ath 32768 1 ath10k_core
mac80211 786432 1 ath10k_core
bluetooth 385024 7 bnep
qcserial 16384 0
cfg80211 561152 3 ath,mac80211,ath10k_core
usb_wwan 16384 1 qcserial
qmi_wwan 24576 0
cdc_wdm 20480 1 qmi_wwan
usbserial 40960 2 qcserial,usb_wwan
usbnet 36864 1 qmi_wwan
mii 16384 1 usbnet
rfkill 32768 4 cfg80211,bluetooth
firmware_class 24576 1 ath10k_core
marvell_cesa 45056 0
ehci_orion 16384 0
des_generic 28672 1 marvell_cesa
mcp3021 16384 0
hwmon 16384 1 mcp3021
evbug 16384 0
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
fuse 102400 1
ipv6 532480 0
autofs4 36864 2
debian@clearfog:~$ uname -a
Linux clearfog 4.4.15-clearfog #1 SMP Wed Oct 5 00:03:36 UTC 2016 armv7l
GNU/Linux
debian@clearfog:~$ sudo rmmod ath10k_pci ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_pci
[ 69.529351] ath10k_pci 0000:01:00.0: Refused to change power state,
currently in D3
[ 69.567989] ath10k_pci 0000:01:00.0: failed to wake up device : -110
[ 69.575267] ath10k_pci: probe of 0000:01:00.0 failed with error -110
debian@clearfog:~$ sudo rmmod ath10k_pci ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_pci irq_mode=1
[ 97.899370] ath10k_pci 0000:01:00.0: Refused to change power state,
currently in D3
[ 97.938045] ath10k_pci 0000:01:00.0: failed to wake up device : -110
[ 97.944973] ath10k_pci: probe of 0000:01:00.0 failed with error -110
debian@clearfog:~$ lspci -vvv
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
(prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f8000000-f82fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
(prog-if 00 [Normal decode])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
01:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
Network Adapter (rev ff) (prog-if ff)
!!! Unknown header type 7f
Something else what I can try?
Best regards,
Matthias
^ permalink raw reply
* [mac80211-next:genl 9/9] net/wireless/nl80211.c:8469:63: error: expected ',' or ';' before ')' token
From: kbuild test robot @ 2016-10-24 9:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: kbuild-all, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl
head: 09566d222ce4d6aab069c8b7dc625675c6cca3fc
commit: 09566d222ce4d6aab069c8b7dc625675c6cca3fc [9/9] genetlink: introduce and use genl_family_attrbuf()
config: i386-randconfig-c0-10241534 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 09566d222ce4d6aab069c8b7dc625675c6cca3fc
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/wireless/nl80211.c: In function 'nl80211_testmode_dump':
>> net/wireless/nl80211.c:8469:63: error: expected ',' or ';' before ')' token
struct nlattr ** attrbuf = genl_family_attrbuf(&nl80211_fam));
^
vim +8469 net/wireless/nl80211.c
8463 /*
8464 * 0 is a valid index, but not valid for args[0],
8465 * so we need to offset by 1.
8466 */
8467 phy_idx = cb->args[0] - 1;
8468 } else {
> 8469 struct nlattr ** attrbuf = genl_family_attrbuf(&nl80211_fam));
8470
8471 err = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
8472 attrbuf, nl80211_fam.maxattr, nl80211_policy);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29352 bytes --]
^ permalink raw reply
* [mac80211-next:genl 5/9] net/netlink/genetlink.c:430:1: warning: label 'errout' defined but not used
From: kbuild test robot @ 2016-10-24 17:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: kbuild-all, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl
head: fc4c3f9724b5c4b730490ce2637369fee6e8b87b
commit: dcc56960c6e6fa10b50d5433b10fc216a3f7c996 [5/9] genetlink: no longer support using static family IDs
config: i386-randconfig-x004-201643 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout dcc56960c6e6fa10b50d5433b10fc216a3f7c996
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
net/netlink/genetlink.c: In function '__genl_register_family':
>> net/netlink/genetlink.c:430:1: warning: label 'errout' defined but not used [-Wunused-label]
errout:
^~~~~~
vim +/errout +430 net/netlink/genetlink.c
2a94fe48 Johannes Berg 2013-11-19 414 if (err)
2a94fe48 Johannes Berg 2013-11-19 415 goto errout_locked;
2a94fe48 Johannes Berg 2013-11-19 416
482a8524 Thomas Graf 2005-11-10 417 list_add_tail(&family->family_list, genl_family_chain(family->id));
def31174 Pravin B Shelar 2013-04-23 418 genl_unlock_all();
482a8524 Thomas Graf 2005-11-10 419
2a94fe48 Johannes Berg 2013-11-19 420 /* send all events */
2a94fe48 Johannes Berg 2013-11-19 421 genl_ctrl_event(CTRL_CMD_NEWFAMILY, family, NULL, 0);
2a94fe48 Johannes Berg 2013-11-19 422 for (i = 0; i < family->n_mcgrps; i++)
2a94fe48 Johannes Berg 2013-11-19 423 genl_ctrl_event(CTRL_CMD_NEWMCAST_GRP, family,
2a94fe48 Johannes Berg 2013-11-19 424 &family->mcgrps[i], family->mcgrp_offset + i);
482a8524 Thomas Graf 2005-11-10 425
482a8524 Thomas Graf 2005-11-10 426 return 0;
482a8524 Thomas Graf 2005-11-10 427
482a8524 Thomas Graf 2005-11-10 428 errout_locked:
def31174 Pravin B Shelar 2013-04-23 429 genl_unlock_all();
482a8524 Thomas Graf 2005-11-10 @430 errout:
482a8524 Thomas Graf 2005-11-10 431 return err;
482a8524 Thomas Graf 2005-11-10 432 }
33c6b1f6 Pravin B Shelar 2013-08-23 433 EXPORT_SYMBOL(__genl_register_family);
482a8524 Thomas Graf 2005-11-10 434
482a8524 Thomas Graf 2005-11-10 435 /**
482a8524 Thomas Graf 2005-11-10 436 * genl_unregister_family - unregister generic netlink family
482a8524 Thomas Graf 2005-11-10 437 * @family: generic netlink family
482a8524 Thomas Graf 2005-11-10 438 *
:::::: The code at line 430 was first introduced by commit
:::::: 482a8524f85a7d8c40c6fb5d072e85bc2fef327f [NETLINK]: Generic netlink family
:::::: TO: Thomas Graf <tgraf@suug.ch>
:::::: CC: Thomas Graf <tgr@axs.localdomain>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35732 bytes --]
^ permalink raw reply
* [mac80211-next:genl 2/2] net/netlink/genetlink.c:693:9: error: 'genl_ctrl_ops' undeclared here (not in a function)
From: kbuild test robot @ 2016-10-24 7:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: kbuild-all, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 4121 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl
head: e406d0fb91172c4dc5364b4a2228679cb07e512c
commit: e406d0fb91172c4dc5364b4a2228679cb07e512c [2/2] genetlink: statically initialize families
config: i386-randconfig-x004-201643 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout e406d0fb91172c4dc5364b4a2228679cb07e512c
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
>> net/netlink/genetlink.c:693:9: error: 'genl_ctrl_ops' undeclared here (not in a function)
.ops = genl_ctrl_ops,
^~~~~~~~~~~~~
In file included from include/linux/thread_info.h:11:0,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from net/netlink/genetlink.c:9:
include/linux/bug.h:37:45: error: bit-field '<anonymous>' width not an integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^~~~~~~~~~~~~~~~~
include/linux/kernel.h:53:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~~~~~~~~~~~~~
>> net/netlink/genetlink.c:694:11: note: in expansion of macro 'ARRAY_SIZE'
.n_ops = ARRAY_SIZE(genl_ctrl_ops),
^~~~~~~~~~
>> net/netlink/genetlink.c:695:12: error: 'genl_ctrl_groups' undeclared here (not in a function)
.mcgrps = genl_ctrl_groups,
^~~~~~~~~~~~~~~~
In file included from include/linux/thread_info.h:11:0,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from net/netlink/genetlink.c:9:
include/linux/bug.h:37:45: error: bit-field '<anonymous>' width not an integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^~~~~~~~~~~~~~~~~
include/linux/kernel.h:53:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~~~~~~~~~~~~~
net/netlink/genetlink.c:696:14: note: in expansion of macro 'ARRAY_SIZE'
.n_mcgrps = ARRAY_SIZE(genl_ctrl_groups),
^~~~~~~~~~
vim +/genl_ctrl_ops +693 net/netlink/genetlink.c
687 /**************************************************************************
688 * Controller
689 **************************************************************************/
690
691 static struct genl_family genl_ctrl = {
692 .module = THIS_MODULE,
> 693 .ops = genl_ctrl_ops,
> 694 .n_ops = ARRAY_SIZE(genl_ctrl_ops),
> 695 .mcgrps = genl_ctrl_groups,
696 .n_mcgrps = ARRAY_SIZE(genl_ctrl_groups),
697 .id = GENL_ID_CTRL,
698 .name = "nlctrl",
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35732 bytes --]
^ permalink raw reply
* Re: Bayesian rate control
From: Johannes Berg @ 2016-10-24 5:28 UTC (permalink / raw)
To: Björn Smedman, linux-wireless, ath9k-devel
In-Reply-To: <CAGp19xcg1qCP3+JNbuiB7Hx=UjLN7KP55wVJT0sKV-iE12501A@mail.gmail.com>
> 1. Is there anybody else out there thinking along similar lines?
I'm not aware, but that may not mean much :)
> 2. What would be the best hardware/software stack to base this work
> on?
>
> I'm thinking the best driver for rate control experimentation would
> be ath9k, right? If so then a TP-Link TL-WA901ND router (apparently
> based on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800
> PCIe card (apparently based on Atheros AR9380 with PCI ID 168c:0030)
> for my desktop sounds like a good combo, no?
Seems reasonable, yes. You wouldn't have VHT, but HT has enough search
space to keep you busy ;-)
> But would I have to run a custom kernel on my desktop then (or can I
> somehow get by with an Ubuntu standard kernel)?
You could use a backported driver. https://backports.wiki.kernel.org/
johannes
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-23 19:42 UTC (permalink / raw)
To: Jonas Gorski; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAOiHx=kWh3P=Ye1Bnd35pRvwWyOdqEyYFVXvTTz60_Hj4TDFFg@mail.gmail.com>
Thanks, but its still not working. I dont get any error now when i do
modprobe and installed is the wle900
[root@alarm alarm]# rmmod ath10k_pci
[root@alarm alarm]# modprobe ath10k_pci irq_mode=1
but:
[root@alarm alarm]# dmesg | grep ath10k
[ 220.356314] ath10k_pci 0000:02:00.0: Refused to change power state,
currently in D3
[ 220.394265] ath10k_pci 0000:02:00.0: failed to wake up device : -110
[ 220.400770] ath10k_pci: probe of 0000:02:00.0 failed with error -110
[root@alarm alarm]# cat /proc/cmdline
console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait ath10k_pci.irq_mode=1
Thanks for your patience
Regards
Oli
Am 23.10.2016 um 21:33 schrieb Jonas Gorski:
> On 23 October 2016 at 17:53, Oliver Zemann <oliver.zemann@gmail.com> wrote:
>> Thanks for that info Jonas. I passed optargs=irq_mode=1 in /boot/uEnv.txt on
>> archlinux arm (kernel 4.4.23) and verified with
>>
>> [root@alarm ~]# cat /proc/cmdline
>> console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait irq_mode=1
>>
>> But it still does not work:
>>
>> [root@alarm ~]# rmmod ath10k_pci
>> [root@alarm ~]# modprobe ath10k_pci
>> [ 28.791404] ath10k_pci 0000:02:00.0: Refused to change power state,
>> currently in D3
>> [ 28.829352] ath10k_pci 0000:02:00.0: failed to wake up device : -110
>> [ 28.835861] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>>
>> Did i do something wrong? If somehow possible, i would prefer to not rebuild
>> the kernel and somehow configure the existing one without changes.
> For the kernel command line you need to prefix with the module name,
> i.e. "ath10k_pci.irq_mode=1". Alternative is while modprobing with
> "modprobe ath10_pci irq_mode=1". See
> <https://www.kernel.org/doc/Documentation/kernel-parameters.txt> for
> details.
>
> Regards
> Jonas
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Jonas Gorski @ 2016-10-23 19:33 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <43544382-075a-6437-8f72-133a907d9def@gmail.com>
On 23 October 2016 at 17:53, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> Thanks for that info Jonas. I passed optargs=irq_mode=1 in /boot/uEnv.txt on
> archlinux arm (kernel 4.4.23) and verified with
>
> [root@alarm ~]# cat /proc/cmdline
> console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait irq_mode=1
>
> But it still does not work:
>
> [root@alarm ~]# rmmod ath10k_pci
> [root@alarm ~]# modprobe ath10k_pci
> [ 28.791404] ath10k_pci 0000:02:00.0: Refused to change power state,
> currently in D3
> [ 28.829352] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> [ 28.835861] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>
> Did i do something wrong? If somehow possible, i would prefer to not rebuild
> the kernel and somehow configure the existing one without changes.
For the kernel command line you need to prefix with the module name,
i.e. "ath10k_pci.irq_mode=1". Alternative is while modprobing with
"modprobe ath10_pci irq_mode=1". See
<https://www.kernel.org/doc/Documentation/kernel-parameters.txt> for
details.
Regards
Jonas
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-23 15:53 UTC (permalink / raw)
To: Jonas Gorski; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAOiHx==nbvwiiMZaqg5okdM6ab9ZLc+JOPdHdJJMUh9uhEt3PQ@mail.gmail.com>
Thanks for that info Jonas. I passed optargs=irq_mode=1 in
/boot/uEnv.txt on archlinux arm (kernel 4.4.23) and verified with
[root@alarm ~]# cat /proc/cmdline
console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait irq_mode=1
But it still does not work:
[root@alarm ~]# rmmod ath10k_pci
[root@alarm ~]# modprobe ath10k_pci
[ 28.791404] ath10k_pci 0000:02:00.0: Refused to change power state,
currently in D3
[ 28.829352] ath10k_pci 0000:02:00.0: failed to wake up device : -110
[ 28.835861] ath10k_pci: probe of 0000:02:00.0 failed with error -110
Did i do something wrong? If somehow possible, i would prefer to not
rebuild the kernel and somehow configure the existing one without changes.
Kind regards
Oli
Am 22.10.2016 um 13:55 schrieb Jonas Gorski:
> Hi,
>
> On 21 October 2016 at 18:25, Oliver Zemann <oliver.zemann@gmail.com> wrote:
>> The problem is gone with kernel 4.7.3 on armbian - both compex cards work
>> (wle600, wle900),
> Interesting to know this issue isn't present in 4.7 - I also
> encountered it in 4.4 with LEDE.
>
>> unfortunately that kernel does not support sfp (seems like
>> its kind of proprietary drivers from clearfog).
> They aren't really proprietary, they are proper patches that were
> submitted as RFC once, so it shouldn't be much effort to port them to
> e.g. 4.7. Anyways ...
>
>> So its a driver issue but i
>> have no clue who to contact or where to file a bug report. The only
>> available kernel which supports sfp (from solidrun, vendor of the clearfog
>> board) is 4.4.23
>>
>> I am wondering if i could simply checkout the 4.4.x sources, merge the
>> atheros drivers in it and try to rebuild the kernel?
> the issue seems to be that MSI interrupts do not work on 4.4 (at least
> with ath10k, didn't have any other drivers that support it to test).
> Your options are either to disable support for them in the kernel
> config, or pass irq_mode=1 to ath10k_pci on probe to force legacy
> interrupts; it should work then properly.
>
>
> Regards
> Jonas
^ permalink raw reply
* Bayesian rate control
From: Björn Smedman @ 2016-10-23 13:57 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Hi all,
I've been thinking about rate control a bit lately. I've written up
some of my thoughts in a blog post
(http://www.openias.org/bayesian-wifi-rate-control), but very briefly
put I'd like to build a rate control algorithm based on Bayesian
statistical inference, possibly by modeling the rate control problem
as a "multi-armed bandit" problem and/or using Thompson sampling.
A couple of questions for the list:
1. Is there anybody else out there thinking along similar lines?
I'd very much like to find collaborators interested in working on
this. It could serve as a pretty nice masters thesis problem, for
example.
2. What would be the best hardware/software stack to base this work on?
I'm thinking the best driver for rate control experimentation would be
ath9k, right? If so then a TP-Link TL-WA901ND router (apparently based
on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800 PCIe
card (apparently based on Atheros AR9380 with PCI ID 168c:0030) for my
desktop sounds like a good combo, no? But would I have to run a custom
kernel on my desktop then (or can I somehow get by with an Ubuntu
standard kernel)?
Any other thoughts or pointers are also more than welcome.
Many thanks,
Bj=C3=B6rn Smedman
^ permalink raw reply
* Re: crypto: aesni - add ccm(aes) algorithm implementation
From: Ben Greear @ 2016-10-23 2:33 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Yauhen Kharuzhy
In-Reply-To: <4298972.T1UOBYP9Tx@debian64>
On 10/22/2016 12:15 PM, Christian Lamparter wrote:
> On Wednesday, October 19, 2016 9:39:49 AM CEST Ben Greear wrote:
>> On 10/19/2016 09:37 AM, greearb@candelatech.com wrote:
>>> From: Yauhen Kharuzhy <jekhor@gmail.com>
>>>
>>> Add ccm(aes) implementation from linux-wireless mailing list (see
>>> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
>>>
>>> This eliminates FPU context store/restore overhead existing in more
>>> general ccm_base(ctr(aes-aesni),aes-aesni) case in MAC calculation.
>>>
>>> Convert this patch to new AEAD API.
>>>
>>> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> I've been using this patch or something similar for a while and it
>> significantly helps me with sw-crypt performance. One version or another
>> has been around the internet for some time, and I am not the originator
>> of this code, but would still be happy to see it upstream if someone
>> can review and bless it.
>
> No. I don't think this will ever fly by the crypto folks in this
> form due to the CRYPTO_ALGO_ASYNC fallback parts which are necessary
> to get it to work with mac80211.
>
> It would be a great if mac80211 would do to the encryption and
> decryption asynchronously. As this would work for other ciphers
> and also allows crypto offload to dedicated crypto hardware.
Does it actually hurt some existing code or functionality?
It definitely helps with wifi software crypt.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Johannes Berg @ 2016-10-22 20:34 UTC (permalink / raw)
To: Antonio Quartulli, ath9k-devel; +Cc: linux-wireless, sw, Antonio Quartulli
In-Reply-To: <20161022134222.GQ12558@prodigo.lan>
> "The patch itself has (at least) one big problem. It is using some
> mac80211
> internals in ath_key_config_iter to make sure that the uploaded keys
> were
> actually programmed in the hardware. Without this check the keys
> could end up
> in the lower slots and thus break all connections."
The KEY_FLAG_UPLOADED_TO_HARDWARE use? Might not be so nice, but it's
probably not really a problem. If you wanted to avoid it, you could
just use the hw_key_idx in some way, e.g. the highest-order bit
indicates that you've set this value, or you just make sure that 0 is
an invalid value and set it to real index + 1 or something, then you
can check that?
johannes
^ permalink raw reply
* Re: crypto: aesni - add ccm(aes) algorithm implementation
From: Johannes Berg @ 2016-10-22 20:31 UTC (permalink / raw)
To: Christian Lamparter, Ben Greear; +Cc: linux-wireless, Yauhen Kharuzhy
In-Reply-To: <4298972.T1UOBYP9Tx@debian64>
On Sat, 2016-10-22 at 21:15 +0200, Christian Lamparter wrote:
>
> It would be a great if mac80211 would do to the encryption and
> decryption asynchronously. As this would work for other ciphers
> and also allows crypto offload to dedicated crypto hardware.
The only problem with that is that we'd essentially need a software
queue for *all* frames, and release them from there in RX order after
decrypt. That's surely doable, but so far nobody has thought it
important enough since mostly HW crypto is used ...
johannes
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-22 20:30 UTC (permalink / raw)
To: Markus Heiser; +Cc: Jani Nikula, Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <A533ED1D-9F0F-420D-9835-723F33D6CA83@darmarit.de>
On Sat, 2016-10-22 at 18:37 +0200, Markus Heiser wrote:
> Yeah, I thought something similar. But is the import of the extension
> a sufficient criteria?
>
> About ".. math::"; I guess we have to check if math extension AND
> pdflatex is installed.
>
> What do you suppose?
TBH, I only considered this briefly, but decided that somebody who went
to the effort of installing the sphinx extension would likely not mind
to get a subsequent error when it tries to use something that's not
installed.
I was, in fact, quite surprised that I even could install (on Debian)
the plantuml sphinx extension without plantuml, which seems odd.
In fact, I think it would be *preferable* to only check the extension ;
we should print a message from the dummy plugin to let them know what
extensions they need, and if they then go to the effort of installing
it they probably don't just not mind getting errors on dependencies,
but actually would *prefer* that, since otherwise it can be daunting to
try to figure out what *else* you actually have to install.
johannes
^ permalink raw reply
* Re: cookie_counter in wiphy object
From: Johannes Berg @ 2016-10-22 20:26 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <0e3d457d-b0d1-f2b1-b18b-3f7b3e95365c@broadcom.com>
> Since commit a442b761b24b ("cfg80211: add add_nan_func /
> del_nan_func")
> there is a cookie_counter in the wiphy object. It is only used by the
> add_nan_func now, but do we want to consolidate all cookie returning
> functions to use this cookie counter, eg. in .remain_on_channel
> callback.
We probably could now. We used to use pointers and various other kinds
of crappy things for the cookies, but the counters are much safer,
reliable, and easier to debug. Naturally, it fell out that then the
cookies would be assigned in the drivers (well, mac80211), but here I
asked that be changed - I wouldn't mind changing it for other things as
well.
johannes
^ permalink raw reply
* Re: [PATCH v3 3/9] cfg80211: add add_nan_func / del_nan_func
From: Johannes Berg @ 2016-10-22 20:24 UTC (permalink / raw)
To: Arend van Spriel
Cc: Luca Coelho, linux-wireless, ayala.beker, andrei.otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <6fb30815-b8c8-aff4-86af-d7f496da91b5@broadcom.com>
On Sat, 2016-10-22 at 21:17 +0200, Arend van Spriel wrote:
> On 20-09-16 16:31, Luca Coelho wrote:
> >
> > + .flags = GENL_ADMIN_PERM,
> Recently the nl80211_ops flags were changed to GENL_UNS_ADMIN_PERM so
> should the NAN commands use that as well?
The dangers of having such code non-upstream for too long...
It probably doesn't really matter, since most namespace uses are
probably hwsim where this isn't available, but yeah, I guess it should
be allowed to a namespace owner since he already "owns" the device if
it's in the namespace.
johannes
^ permalink raw reply
* Re: [PATCH v3 3/9] cfg80211: add add_nan_func / del_nan_func
From: Arend van Spriel @ 2016-10-22 19:17 UTC (permalink / raw)
To: johannes
Cc: Luca Coelho, linux-wireless, ayala.beker, andrei.otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160920143121.28247-4-luca@coelho.fi>
On 20-09-16 16:31, Luca Coelho wrote:
> + .flags = GENL_ADMIN_PERM,
Hi Johannes,
Recently the nl80211_ops flags were changed to GENL_UNS_ADMIN_PERM so
should the NAN commands use that as well?
Regards,
Arend
^ permalink raw reply
* Re: crypto: aesni - add ccm(aes) algorithm implementation
From: Christian Lamparter @ 2016-10-22 19:15 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, Yauhen Kharuzhy
In-Reply-To: <3e0552f3-b7f5-2ff3-1f63-9001bceb96f0@candelatech.com>
On Wednesday, October 19, 2016 9:39:49 AM CEST Ben Greear wrote:
> On 10/19/2016 09:37 AM, greearb@candelatech.com wrote:
> > From: Yauhen Kharuzhy <jekhor@gmail.com>
> >
> > Add ccm(aes) implementation from linux-wireless mailing list (see
> > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
> >
> > This eliminates FPU context store/restore overhead existing in more
> > general ccm_base(ctr(aes-aesni),aes-aesni) case in MAC calculation.
> >
> > Convert this patch to new AEAD API.
> >
> > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> > Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> I've been using this patch or something similar for a while and it
> significantly helps me with sw-crypt performance. One version or another
> has been around the internet for some time, and I am not the originator
> of this code, but would still be happy to see it upstream if someone
> can review and bless it.
No. I don't think this will ever fly by the crypto folks in this
form due to the CRYPTO_ALGO_ASYNC fallback parts which are necessary
to get it to work with mac80211.
It would be a great if mac80211 would do to the encryption and
decryption asynchronously. As this would work for other ciphers
and also allows crypto offload to dedicated crypto hardware.
Regards,
Christian
^ permalink raw reply
* cookie_counter in wiphy object
From: Arend van Spriel @ 2016-10-22 19:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Hi Johannes,
Since commit a442b761b24b ("cfg80211: add add_nan_func / del_nan_func")
there is a cookie_counter in the wiphy object. It is only used by the
add_nan_func now, but do we want to consolidate all cookie returning
functions to use this cookie counter, eg. in .remain_on_channel callback.
Regards,
Arend
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Markus Heiser @ 2016-10-22 16:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jani Nikula, Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <1477084793.4068.63.camel@sipsolutions.net>
Am 21.10.2016 um 23:19 schrieb Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2016-10-21 at 18:11 +0200, Markus Heiser wrote:
>
>> Yes and No. It depends on the tools (toolchains) we want to use.
>> As far as I can see from a abstract POV it should by simple for
>> math:: / since we already use/need LaTeX for PDF, for other tools
>> I have to look.
>
> Not sure if we were talking past each other - but the pass-through is
> actually really simple - example patch below.
Yeah, I thought something similar. But is the import of the extension
a sufficient criteria?
About ".. math::"; I guess we have to check if math extension AND
pdflatex is installed.
What do you suppose?
(ATM my comments on this are superficial, sorry that I haven't not
yet fond the time, to look closer into all these generators).
--Markus--
>
> This makes it output an SVG (with fallback to PNG even) into the HTML,
> a PDF into the PDF, and plain pre-formatted text for both when the
> plantuml sphinx plugin isn't installed.
>
> johannes
>
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index bf6f310e5170..2c00ab6f0baf 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,8 @@ from load_config import loadConfig
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain']
> +extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain',
> + 'plantuml']
>
> # The name of the math extension changed on Sphinx 1.4
> if minor > 3:
> @@ -494,6 +495,9 @@ pdf_documents = [
> kerneldoc_bin = '../scripts/kernel-doc'
> kerneldoc_srctree = '..'
>
> +plantuml_output_format = "svg"
> +plantuml_latex_output_format = "pdf"
> +
> # ------------------------------------------------------------------------------
> # Since loadConfig overwrites settings from the global namespace, it has to be
> # the last statement in the conf.py file
> diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
> index 8e259c5d0322..e0d4f24b6039 100644
> --- a/Documentation/driver-api/index.rst
> +++ b/Documentation/driver-api/index.rst
> @@ -7,6 +7,12 @@ of device drivers. This document is an only somewhat organized collection
> of some of those interfaces — it will hopefully get better over time! The
> available subsections can be seen below.
>
> +.. uml::
> +
> + Alice -> Bob: Hi!
> + Alice <- Bob: How are you?
> +
> +
> .. class:: toc-title
>
> Table of contents
> diff --git a/Documentation/sphinx/dummy.py b/Documentation/sphinx/dummy.py
> new file mode 100644
> index 000000000000..cfac42886ebd
> --- /dev/null
> +++ b/Documentation/sphinx/dummy.py
> @@ -0,0 +1,24 @@
> +from sphinx.util.compat import Directive
> +from docutils import nodes
> +from docutils.parsers.rst import directives
> +
> +class IgnoreOptions(object):
> + def __getitem__(self, key):
> + return directives.unchanged
> +
> +def create_setup(directives):
> + def setup(app):
> + for d in directives:
> + class TextDirective(Directive):
> + has_content = True
> + option_spec = IgnoreOptions()
> +
> + def run(self):
> + text = '\n'.join(self.content)
> + return [nodes.literal_block('', text,
> + classes=['code',
> + 'missing-plugin',
> + 'missing-plugin-%s' % d])]
> +
> + app.add_directive(d, TextDirective)
> + return setup
> diff --git a/Documentation/sphinx/plantuml.py b/Documentation/sphinx/plantuml.py
> new file mode 100644
> index 000000000000..0007bc7f24fd
> --- /dev/null
> +++ b/Documentation/sphinx/plantuml.py
> @@ -0,0 +1,7 @@
> +# -*- coding: utf-8 -*-
> +from dummy import create_setup
> +
> +try:
> + from sphinxcontrib.plantuml import *
> +except:
> + setup = create_setup(['uml'])
^ permalink raw reply
* Re: Using ath5k/ath9k radio for constant-tx noise source.
From: Sebastian Gottschall @ 2016-10-22 14:49 UTC (permalink / raw)
To: Zefir Kurtisi, Ben Greear, linux-wireless@vger.kernel.org
Cc: Christian Lamparter
In-Reply-To: <27058308-3d36-b415-900f-3e3b65b11dab@neratec.com>
atheros has a continues transmission mode which is used for power
calibration in factory using the ART utility. its available on ath9k
cards as well.
once enabled no wifi connection is possible on the same frequency since
it will break up all CSMA handling also with neighbor networks. its a nice
feature for disconnecting all wifi networks in your area
look for the called atheros / qca TESTMODE. its a simple register
setting (enable, disable)
Am 15.09.2016 um 17:28 schrieb Zefir Kurtisi:
> Hi Ben,
>
> On 09/15/2016 02:22 AM, Ben Greear wrote:
>> On 08/20/2015 08:11 AM, Zefir Kurtisi wrote:
>>> On 08/19/2015 09:07 PM, Ben Greear wrote:
>>>> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be
>>>> wrong)
>>>> and it has the ability to do a constant transmit of raw noise (RF probe shows
>>>> noise, but a monitor-port sniffer does not see any frames from the CM9).
>>>>
>>>> I don't know the low-level details of how it is doing this, but I suspect
>>>> it is using something like madwifi for a driver.
>>>>
>>>> Does anyone know how this can be done with modern software and
>>>> ath5k or ath9k NICs?
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>> Maybe slightly related: some years ago when DFS became a topic and it was hard to
>>> get hands on radar pattern generators, Christian Lamparter wrote a variant of the
>>> carl9170 fw [1] which can generate radar pulses to test ath9k and other DFS radar
>>> detectors. Pulses are generated by enabling txout at defined sampling intervals.
>>>
>>> It should be doable to mimic what you are looking for by generating a _very_ long
>>> pulse.
>> Sorry to revive such an old thread..but I'm back poking at this.
>>
> Whew, that year went by so incredibly fast ;)
>
>> I've used the modified carl9170 firmware to generate pulses, with
>> the control being 'pulse-width' and 'pulse-interval'.
>>
>> This sort of works, and sometimes our ath10k in an isolation chamber reports
>> a radar event.
>>
>> But, after some reading, I am thinking I need more control to better mimic
>> a radar.
>>
>> If I understand things properly, I need something like this:
>>
>> A pulse event being: pulse width, pulse period: For instance 1us, 200us
>> Then, I need to configure an amount of pulse events, maybe 10-30 consecutive pulse
>> events.
>> Then, I need a quiet period to mimic the radar sweeping full circle (15 seconds
>> perhaps)
>>
>> From what I can tell, the carl9170 modified firmware is missing the features
>> to do this, though it should not be too difficult to add.
>>
> Yes, that's essentially it - the last step is even not needed if your goal is to
> estimate DFS detection probabilities, since in the certification lab they usually
> just repeatedly fire the radar pattern and count detection events.
>
> When I played with the modified carl9170 FW, I estimated that developing an solid
> and reliable radar pattern pulse scheduler would take me 2-4 weeks, so being in a
> hurry I ended up using an SDR (Ettus USRP N200, see [1]). I developed a pulse
> scheduler to feed arbitrary patterns (covering those for DFS testing), which is
> available in [2]. It has not been maintained ever since, but might help you as
> starting point if you decide to go that route.
>
>> If someone has an idea whether the control above is appropriate, I'd
>> appreciate feedback before I start hacking...
>>
>> This document seemed useful, for instance:
>>
>> https://dl.cdn-anritsu.com/en-en/test-measurement/files/Product-Introductions/Product-Introduction/mx370073a-el1200.pdf
>>
> We use the R&S SMBV100A [3], which we know is also used in some certification
> labs. Unfortunately it is not exactly cheap - if you are not going to prepare your
> product for certification, the SDR approach is affordable and good enough.
>
>> Thanks,
>> Ben
>>
> Good luck,
> Zefir
>
> [1] https://www.ettus.com/product/details/UN200-KIT
> [2] https://github.com/zefir-kurtisi/USRP-Radar-Relay
> [3]
> https://www.rohde-schwarz.com/us/product/smbv100a-productstartpage_63493-10220.html
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ 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