* Re: [PATCH v2 3/9] cfg80211: add add_nan_func / rm_nan_func
From: kbuild test robot @ 2016-09-16 10:46 UTC (permalink / raw)
To: Luca Coelho
Cc: kbuild-all, johannes, linux-wireless, Ayala Beker,
Andrei Otcheretianski, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-4-luca@coelho.fi>
[-- Attachment #1: Type: text/plain, Size: 7963 bytes --]
Hi Ayala,
[auto build test ERROR on mac80211-next/master]
[also build test ERROR on next-20160916]
[cannot apply to v4.8-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Luca-Coelho/Add-support-for-Neighbor-Awareness-Networking/20160916-164553
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: x86_64-lkp (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
net/wireless/nl80211.c: In function 'nl80211_nan_add_func':
>> net/wireless/nl80211.c:10588:30: error: implicit declaration of function 'genl_info_snd_portid' [-Werror=implicit-function-declaration]
wdev->owner_nlportid != genl_info_snd_portid(info))
^~~~~~~~~~~~~~~~~~~~
>> net/wireless/nl80211.c:10785:6: error: implicit declaration of function 'nla_put_u64' [-Werror=implicit-function-declaration]
if (nla_put_u64(msg, NL80211_ATTR_COOKIE, func->cookie))
^~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/genl_info_snd_portid +10588 net/wireless/nl80211.c
10582 return -ENOTCONN;
10583
10584 if (!info->attrs[NL80211_ATTR_NAN_FUNC])
10585 return -EINVAL;
10586
10587 if (wdev->owner_nlportid &&
10588 wdev->owner_nlportid != genl_info_snd_portid(info))
10589 return -ENOTCONN;
10590
10591 err = nla_parse(tb, NL80211_NAN_FUNC_ATTR_MAX,
10592 nla_data(info->attrs[NL80211_ATTR_NAN_FUNC]),
10593 nla_len(info->attrs[NL80211_ATTR_NAN_FUNC]),
10594 nl80211_nan_func_policy);
10595 if (err)
10596 return err;
10597
10598 func = kzalloc(sizeof(*func), GFP_KERNEL);
10599 if (!func)
10600 return -ENOMEM;
10601
10602 func->cookie = wdev->wiphy->cookie_counter++;
10603
10604 if (!tb[NL80211_NAN_FUNC_TYPE] ||
10605 nla_get_u8(tb[NL80211_NAN_FUNC_TYPE]) > NL80211_NAN_FUNC_MAX_TYPE) {
10606 err = -EINVAL;
10607 goto out;
10608 }
10609
10610
10611 func->type = nla_get_u8(tb[NL80211_NAN_FUNC_TYPE]);
10612
10613 if (!tb[NL80211_NAN_FUNC_SERVICE_ID]) {
10614 err = -EINVAL;
10615 goto out;
10616 }
10617
10618 memcpy(func->service_id, nla_data(tb[NL80211_NAN_FUNC_SERVICE_ID]),
10619 sizeof(func->service_id));
10620
10621 func->close_range =
10622 nla_get_flag(tb[NL80211_NAN_FUNC_CLOSE_RANGE]);
10623
10624 if (tb[NL80211_NAN_FUNC_SERVICE_INFO]) {
10625 func->serv_spec_info_len =
10626 nla_len(tb[NL80211_NAN_FUNC_SERVICE_INFO]);
10627 func->serv_spec_info =
10628 kmemdup(nla_data(tb[NL80211_NAN_FUNC_SERVICE_INFO]),
10629 func->serv_spec_info_len,
10630 GFP_KERNEL);
10631 if (!func->serv_spec_info) {
10632 err = -ENOMEM;
10633 goto out;
10634 }
10635 }
10636
10637 if (tb[NL80211_NAN_FUNC_TTL])
10638 func->ttl = nla_get_u32(tb[NL80211_NAN_FUNC_TTL]);
10639
10640 switch (func->type) {
10641 case NL80211_NAN_FUNC_PUBLISH:
10642 if (!tb[NL80211_NAN_FUNC_PUBLISH_TYPE]) {
10643 err = -EINVAL;
10644 goto out;
10645 }
10646
10647 func->publish_type =
10648 nla_get_u8(tb[NL80211_NAN_FUNC_PUBLISH_TYPE]);
10649 func->publish_bcast =
10650 nla_get_flag(tb[NL80211_NAN_FUNC_PUBLISH_BCAST]);
10651
10652 if ((!(func->publish_type & NL80211_NAN_SOLICITED_PUBLISH)) &&
10653 func->publish_bcast) {
10654 err = -EINVAL;
10655 goto out;
10656 }
10657 break;
10658 case NL80211_NAN_FUNC_SUBSCRIBE:
10659 func->subscribe_active =
10660 nla_get_flag(tb[NL80211_NAN_FUNC_SUBSCRIBE_ACTIVE]);
10661 break;
10662 case NL80211_NAN_FUNC_FOLLOW_UP:
10663 if (!tb[NL80211_NAN_FUNC_FOLLOW_UP_ID] ||
10664 !tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID]) {
10665 err = -EINVAL;
10666 goto out;
10667 }
10668
10669 func->followup_id =
10670 nla_get_u8(tb[NL80211_NAN_FUNC_FOLLOW_UP_ID]);
10671 func->followup_reqid =
10672 nla_get_u8(tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID]);
10673 memcpy(func->followup_dest.addr,
10674 nla_data(tb[NL80211_NAN_FUNC_FOLLOW_UP_DEST]),
10675 sizeof(func->followup_dest.addr));
10676 if (func->ttl) {
10677 err = -EINVAL;
10678 goto out;
10679 }
10680 break;
10681 default:
10682 err = -EINVAL;
10683 goto out;
10684 }
10685
10686 if (tb[NL80211_NAN_FUNC_SRF]) {
10687 struct nlattr *srf_tb[NUM_NL80211_NAN_SRF_ATTR];
10688
10689 err = nla_parse(srf_tb, NL80211_NAN_SRF_ATTR_MAX,
10690 nla_data(tb[NL80211_NAN_FUNC_SRF]),
10691 nla_len(tb[NL80211_NAN_FUNC_SRF]), NULL);
10692 if (err)
10693 goto out;
10694
10695 func->srf_include =
10696 nla_get_flag(srf_tb[NL80211_NAN_SRF_INCLUDE]);
10697
10698 if (srf_tb[NL80211_NAN_SRF_BF]) {
10699 if (srf_tb[NL80211_NAN_SRF_MAC_ADDRS] ||
10700 !srf_tb[NL80211_NAN_SRF_BF_IDX]) {
10701 err = -EINVAL;
10702 goto out;
10703 }
10704
10705 func->srf_bf_len =
10706 nla_len(srf_tb[NL80211_NAN_SRF_BF]);
10707 func->srf_bf =
10708 kmemdup(nla_data(srf_tb[NL80211_NAN_SRF_BF]),
10709 func->srf_bf_len, GFP_KERNEL);
10710 if (!func->srf_bf) {
10711 err = -ENOMEM;
10712 goto out;
10713 }
10714
10715 func->srf_bf_idx =
10716 nla_get_u8(srf_tb[NL80211_NAN_SRF_BF_IDX]);
10717 } else {
10718 struct nlattr *attr, *mac_attr =
10719 srf_tb[NL80211_NAN_SRF_MAC_ADDRS];
10720 int n_entries, rem, i = 0;
10721
10722 if (!mac_attr) {
10723 err = -EINVAL;
10724 goto out;
10725 }
10726
10727 n_entries = validate_acl_mac_addrs(mac_attr);
10728 if (n_entries <= 0) {
10729 err = -EINVAL;
10730 goto out;
10731 }
10732
10733 func->srf_num_macs = n_entries;
10734 func->srf_macs =
10735 kzalloc(sizeof(*func->srf_macs) * n_entries,
10736 GFP_KERNEL);
10737 if (!func->srf_macs) {
10738 err = -ENOMEM;
10739 goto out;
10740 }
10741
10742 nla_for_each_nested(attr, mac_attr, rem)
10743 memcpy(func->srf_macs[i++].addr, nla_data(attr),
10744 sizeof(*func->srf_macs));
10745 }
10746 }
10747
10748 if (tb[NL80211_NAN_FUNC_TX_MATCH_FILTER]) {
10749 err = handle_nan_filter(tb[NL80211_NAN_FUNC_TX_MATCH_FILTER],
10750 func, true);
10751 if (err)
10752 goto out;
10753 }
10754
10755 if (tb[NL80211_NAN_FUNC_RX_MATCH_FILTER]) {
10756 err = handle_nan_filter(tb[NL80211_NAN_FUNC_RX_MATCH_FILTER],
10757 func, false);
10758 if (err)
10759 goto out;
10760 }
10761
10762 msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
10763 if (!msg) {
10764 err = -ENOMEM;
10765 goto out;
10766 }
10767
10768 hdr = nl80211hdr_put(msg, genl_info_snd_portid(info), info->snd_seq, 0,
10769 NL80211_CMD_ADD_NAN_FUNCTION);
10770 /* This can't really happen - we just allocated 4KB */
10771 if (WARN_ON(!hdr)) {
10772 err = -ENOMEM;
10773 goto out;
10774 }
10775
10776 err = rdev_add_nan_func(rdev, wdev, func);
10777 out:
10778 if (err < 0) {
10779 cfg80211_free_nan_func(func);
10780 nlmsg_free(msg);
10781 return err;
10782 }
10783
10784 /* propagate the instance id and cookie to userspace */
10785 if (nla_put_u64(msg, NL80211_ATTR_COOKIE, func->cookie))
10786 goto nla_put_failure;
10787
10788 func_attr = nla_nest_start(msg, NL80211_ATTR_NAN_FUNC);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 23730 bytes --]
^ permalink raw reply
* ath10k mesh mode issue
From: Matteo Grandi @ 2016-09-16 10:52 UTC (permalink / raw)
To: LinuxWireless Mailing List
Hello all,
I'm using Gateworks Ventana 5410 boards
(http://www.gateworks.com/product/item/ventana-gw5410-network-processor)
running Ubuntu Trusty-Ventana kernel v3.14 with a Compex WLE600V5-27
miniPCIe Qualcomm Atheros QCA9882 wifi dongle installed
https://www.landashop.com/compex-wle-600v5.html?___store=english&___from_store=default
The aim is to use some of these boards to build a mesh network and
perform some HT test (it's a part of my MSc thesis).
I'm trying to configure the devices in mesh mode, but I've encountered
some problems, this is the dmesg output:
root@Yazi:~# iw dev wlan1 interface add mp1 type mp
root@Yazi:~# iw dev mp1 set freq 5240
root@Yazi:~# dmesg | grep ath
[ 7.134520] ath10k_pci 0000:07:00.0: pci irq legacy interrupts 0
irq_mode 0 reset_mode 0
[ 7.349228] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.349245] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 7.417170] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.417189] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 8.589474] ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c,
0x043222ff sub 0000:0000) fw 10.2.4.70.54 fwapi 5 bdapi 1 htt-ver 2.1
wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features
no-p2p,raw-mode
[ 8.589491] ath10k_pci 0000:07:00.0: debug 1 debugfs 1 tracing 0
dfs 0 testmode 1
[ 8.691670] ath: EEPROM regdomain: 0x0
[ 8.691680] ath: EEPROM indicates default country code should be used
[ 8.691686] ath: doing EEPROM country->regdmn map search
[ 8.691695] ath: country maps to regdmn code: 0x3a
[ 8.691702] ath: Country alpha2 being used: US
[ 8.691706] ath: Regpair used: 0x3a
root@Yazi:~# ifconfig mp1 up
SIOCSIFFLAGS: Invalid argument
root@Yazi:~# dmesg | grep ath
[ 7.134520] ath10k_pci 0000:07:00.0: pci irq legacy interrupts 0
irq_mode 0 reset_mode 0
[ 7.349228] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.349245] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 7.417170] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.417189] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 8.589474] ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c,
0x043222ff sub 0000:0000) fw 10.2.4.70.54 fwapi 5 bdapi 1 htt-ver 2.1
wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features
no-p2p,raw-mode
[ 8.589491] ath10k_pci 0000:07:00.0: debug 1 debugfs 1 tracing 0
dfs 0 testmode 1
[ 8.691670] ath: EEPROM regdomain: 0x0
[ 8.691680] ath: EEPROM indicates default country code should be used
[ 8.691686] ath: doing EEPROM country->regdmn map search
[ 8.691695] ath: country maps to regdmn code: 0x3a
[ 8.691702] ath: Country alpha2 being used: US
[ 8.691706] ath: Regpair used: 0x3a
[ 176.983250] ath10k_pci 0000:07:00.0: must load driver with
rawmode=1 to add mesh interfaces
It seems that the rowmode is NOT enable, but 8 lines above it's seems
to be ok...
Let me give you some useful details:
- the lspci output:
root@Yazi:~# lspci
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
01:00.1 System peripheral: PLX Technology, Inc. PEX 8609 8-lane,
8-Port PCI Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:04.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:05.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:06.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:07.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:08.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:09.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
07:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
Wireless Network Adapter
08:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8057
PCI-E Gigabit Ethernet Controller
-the lsmod output:
root@Yazi:~# lsmod
Module Size Used by
arc4 1687 2
ath10k_pci 34340 0
ath10k_core 289147 1 ath10k_pci
sky2 53987 0
mac80211 458056 1 ath10k_core
ath 21573 1 ath10k_core
cfg80211 218260 3 ath,mac80211,ath10k_core
compat 24039 4 cfg80211,mac80211,ath10k_pci,ath10k_core
- the firmware currently in use is the firmware-5.bin_10.2.4.70.54
(renamed firmware-5.bin and with executable permission) located in
/lib/firmware/ath10k/QCA988X/hw2.0. I retrived it on
https://github.com/kvalo/ath10k-firmware
- The backports-4.2.6-1 was crosscompiled with the kernel following
the official wiki guide provided by Gateworks
- I've also tried to load the ath10k modules adding the parameter
rowmode=1 but I had an error "rawmode unknown parameter"
- in another try I used the firmware "firmware-5.bin_10.2.4.70.6-2"
after retriving this
https://github.com/o11s/open80211s/wiki/ath10k-(802.11ac)-for-Mesh-Support
but nothing is changed...
I'm not an expert so I'm sorry if I miss some basics...
Hope in your help!
All the best
^ permalink raw reply
* ath10k mesh mode issue
From: Matteo Grandi @ 2016-09-16 10:56 UTC (permalink / raw)
To: LinuxWireless Mailing List
Hello all,
I'm using Gateworks Ventana 5410 boards
(http://www.gateworks.com/product/item/ventana-gw5410-network-processor)
running Ubuntu Trusty-Ventana kernel v3.14 with a Compex WLE600V5-27
miniPCIe Qualcomm Atheros QCA9882 wifi dongle installed
https://www.landashop.com/compex-wle-600v5.html?___store=english&___from_store=default
The aim is to use some of these boards to build a mesh network and
perform some HT test (it's a part of my MSc thesis).
I'm trying to configure the devices in mesh mode, but I've encountered
some problems, this is the dmesg output:
root@Yazi:~# iw dev wlan1 interface add mp1 type mp
root@Yazi:~# iw dev mp1 set freq 5240
root@Yazi:~# dmesg | grep ath
[ 7.134520] ath10k_pci 0000:07:00.0: pci irq legacy interrupts 0
irq_mode 0 reset_mode 0
[ 7.349228] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.349245] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 7.417170] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.417189] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 8.589474] ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c,
0x043222ff sub 0000:0000) fw 10.2.4.70.54 fwapi 5 bdapi 1 htt-ver 2.1
wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features
no-p2p,raw-mode
[ 8.589491] ath10k_pci 0000:07:00.0: debug 1 debugfs 1 tracing 0
dfs 0 testmode 1
[ 8.691670] ath: EEPROM regdomain: 0x0
[ 8.691680] ath: EEPROM indicates default country code should be used
[ 8.691686] ath: doing EEPROM country->regdmn map search
[ 8.691695] ath: country maps to regdmn code: 0x3a
[ 8.691702] ath: Country alpha2 being used: US
[ 8.691706] ath: Regpair used: 0x3a
root@Yazi:~# ifconfig mp1 up
SIOCSIFFLAGS: Invalid argument
root@Yazi:~# dmesg | grep ath
[ 7.134520] ath10k_pci 0000:07:00.0: pci irq legacy interrupts 0
irq_mode 0 reset_mode 0
[ 7.349228] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.349245] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 7.417170] ath10k_pci 0000:07:00.0: Direct firmware load failed
with error -2
[ 7.417189] ath10k_pci 0000:07:00.0: Falling back to user helper
[ 8.589474] ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c,
0x043222ff sub 0000:0000) fw 10.2.4.70.54 fwapi 5 bdapi 1 htt-ver 2.1
wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features
no-p2p,raw-mode
[ 8.589491] ath10k_pci 0000:07:00.0: debug 1 debugfs 1 tracing 0
dfs 0 testmode 1
[ 8.691670] ath: EEPROM regdomain: 0x0
[ 8.691680] ath: EEPROM indicates default country code should be used
[ 8.691686] ath: doing EEPROM country->regdmn map search
[ 8.691695] ath: country maps to regdmn code: 0x3a
[ 8.691702] ath: Country alpha2 being used: US
[ 8.691706] ath: Regpair used: 0x3a
[ 176.983250] ath10k_pci 0000:07:00.0: must load driver with
rawmode=1 to add mesh interfaces
It seems that the rowmode is NOT enable, but 8 lines above it's seems
to be ok...
Let me give you some useful details:
- the lspci output:
root@Yazi:~# lspci
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
01:00.1 System peripheral: PLX Technology, Inc. PEX 8609 8-lane,
8-Port PCI Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:04.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:05.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:06.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:07.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:08.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
02:09.0 PCI bridge: PLX Technology, Inc. PEX 8609 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch with DMA (rev ba)
07:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
Wireless Network Adapter
08:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8057
PCI-E Gigabit Ethernet Controller
-the lsmod output:
root@Yazi:~# lsmod
Module Size Used by
arc4 1687 2
ath10k_pci 34340 0
ath10k_core 289147 1 ath10k_pci
sky2 53987 0
mac80211 458056 1 ath10k_core
ath 21573 1 ath10k_core
cfg80211 218260 3 ath,mac80211,ath10k_core
compat 24039 4 cfg80211,mac80211,ath10k_pci,ath10k_core
- the firmware currently in use is the firmware-5.bin_10.2.4.70.54
(renamed firmware-5.bin and with executable permission) located in
/lib/firmware/ath10k/QCA988X/hw2.0. I retrived it on
https://github.com/kvalo/ath10k-firmware
- The backports-4.2.6-1 was crosscompiled with the kernel following
the official wiki guide provided by Gateworks
- I've also tried to load the ath10k modules adding the parameter
rowmode=1 but I had an error "rawmode unknown parameter"
- in another try I used the firmware "firmware-5.bin_10.2.4.70.6-2"
after retriving this
https://github.com/o11s/open80211s/wiki/ath10k-(802.11ac)-for-Mesh-Support
but nothing is changed...
I'm not an expert so I'm sorry if I miss some basics...
Hope in your help!
All the bes
^ permalink raw reply
* Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
From: Arend Van Spriel @ 2016-09-16 10:58 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-2-luca@coelho.fi>
On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker <ayala.beker@intel.com>
>
> This allows user space to start/stop NAN interface.
> A NAN interface is like P2P device in a few aspects: it
> doesn't have a netdev associated to it.
> Add the new interface type and prevent operations that
> can't be executed on NAN interface like scan.
>
> Define several attributes that may be configured by user space
> when starting NAN functionality (master preference and dual
> band operation)
>
> Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
> include/net/cfg80211.h | 21 +++++++++-
> include/uapi/linux/nl80211.h | 52 +++++++++++++++++++++++++
> net/mac80211/cfg.c | 2 +
> net/mac80211/chan.c | 3 ++
> net/mac80211/iface.c | 4 ++
> net/mac80211/offchannel.c | 1 +
> net/mac80211/rx.c | 3 ++
> net/mac80211/util.c | 1 +
> net/wireless/chan.c | 2 +
> net/wireless/core.c | 34 ++++++++++++++++
> net/wireless/core.h | 3 ++
> net/wireless/mlme.c | 1 +
> net/wireless/nl80211.c | 93 ++++++++++++++++++++++++++++++++++++++++++--
> net/wireless/rdev-ops.h | 20 ++++++++++
> net/wireless/trace.h | 27 +++++++++++++
> net/wireless/util.c | 6 ++-
> 16 files changed, 267 insertions(+), 6 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index d5e7f69..ca64d69 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2293,6 +2293,19 @@ struct cfg80211_qos_map {
> };
[...]
> +/**
> + * enum nl80211_nan_dual_band_conf - NAN dual band configuration
> + *
> + * Defines the NAN dual band mode of operation
Does it make sense to have such a notion of bands in use. And what does
5.2GHz mean. Is this a subband within 5G channels? Probably I should
read the NAN spec to understand what is meant here. I would consider
5.2G as lower 5G, ie. discovery on channel 44 but not sure if that is
meant here.
> + * @NL80211_NAN_BAND_DEFAULT: device default mode
> + * @NL80211_NAN_BAND_SINGLE: 2.4GHz only mode
> + * @NL80211_NAN_BAND_DUAL: 2.4GHz and 5.2GHz mode
> + */
> +enum nl80211_nan_dual_band_conf {
> + NL80211_NAN_BAND_DEFAULT,
> + NL80211_NAN_BAND_SINGLE,
> + NL80211_NAN_BAND_DUAL,
> +
> + /* keep last */
> + __NL80211_NAN_BAND_AFTER_LAST,
> + NL80211_NAN_BAND_MAX =
> + __NL80211_NAN_BAND_AFTER_LAST - 1,
> +};
> +
> #endif /* __LINUX_NL80211_H */
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index e29ff57..a74027f 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -257,6 +257,7 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
> case NL80211_IFTYPE_WDS:
> case NL80211_IFTYPE_MONITOR:
> case NL80211_IFTYPE_P2P_DEVICE:
> + case NL80211_IFTYPE_NAN:
> case NL80211_IFTYPE_UNSPECIFIED:
> case NUM_NL80211_IFTYPES:
Huh? What is this doing here? Not yours but weird still.
> case NL80211_IFTYPE_P2P_CLIENT:
> @@ -2036,6 +2037,7 @@ static int ieee80211_scan(struct wiphy *wiphy,
> !(req->flags & NL80211_SCAN_FLAG_AP)))
> return -EOPNOTSUPP;
> break;
> + case NL80211_IFTYPE_NAN:
> default:
> return -EOPNOTSUPP;
> }
> diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
> index 74142d0..acb50f8 100644
> --- a/net/mac80211/chan.c
> +++ b/net/mac80211/chan.c
> @@ -274,6 +274,7 @@ ieee80211_get_chanctx_max_required_bw(struct ieee80211_local *local,
> ieee80211_get_max_required_bw(sdata));
> break;
> case NL80211_IFTYPE_P2P_DEVICE:
> + case NL80211_IFTYPE_NAN:
> continue;
> case NL80211_IFTYPE_ADHOC:
> case NL80211_IFTYPE_WDS:
> @@ -718,6 +719,7 @@ void ieee80211_recalc_smps_chanctx(struct ieee80211_local *local,
>
> switch (sdata->vif.type) {
> case NL80211_IFTYPE_P2P_DEVICE:
> + case NL80211_IFTYPE_NAN:
> continue;
> case NL80211_IFTYPE_STATION:
> if (!sdata->u.mgd.associated)
> @@ -981,6 +983,7 @@ ieee80211_vif_chanctx_reservation_complete(struct ieee80211_sub_if_data *sdata)
> case NL80211_IFTYPE_P2P_GO:
> case NL80211_IFTYPE_P2P_DEVICE:
> case NUM_NL80211_IFTYPES:
I think NUM_NL80211_IFTYPES should not be in the switch. If it must I
would leave it as last one here.
> + case NL80211_IFTYPE_NAN:
> WARN_ON(1);
> break;
> }
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
From: Johannes Berg @ 2016-09-16 11:00 UTC (permalink / raw)
To: Arend Van Spriel, Luca Coelho
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <6bfd6007-8650-3c75-2e90-c2c94202e2b9@broadcom.com>
> I think NUM_NL80211_IFTYPES should not be in the switch. If it must I
> would leave it as last one here.
>
It just suppresses compiler warnings :)
johannes
^ permalink raw reply
* Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
From: Arend Van Spriel @ 2016-09-16 11:08 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-3-luca@coelho.fi>
On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker <ayala.beker@intel.com>
>
> This code doesn't do much besides allowing to start and
> stop the vif.
>
> Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Ayala Beker <ayala.beker@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
> include/net/mac80211.h | 9 +++++++++
> net/mac80211/cfg.c | 36 ++++++++++++++++++++++++++++++++++
> net/mac80211/chan.c | 3 +++
> net/mac80211/driver-ops.h | 29 ++++++++++++++++++++++++++-
> net/mac80211/iface.c | 8 ++++++--
> net/mac80211/main.c | 5 +++++
> net/mac80211/offchannel.c | 3 ++-
> net/mac80211/trace.h | 50 +++++++++++++++++++++++++++++++++++++++++++++++
> net/mac80211/util.c | 3 ++-
> 9 files changed, 141 insertions(+), 5 deletions(-)
[...]
> diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
> index fe35a1c..67b42c8 100644
> --- a/net/mac80211/driver-ops.h
> +++ b/net/mac80211/driver-ops.h
> @@ -163,7 +163,8 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
>
> if (WARN_ON_ONCE(sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE ||
> (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
> - !sdata->vif.mu_mimo_owner)))
> + !sdata->vif.mu_mimo_owner) ||
> + sdata->vif.type == NL80211_IFTYPE_NAN))
Might be more clear to move this up right after P2P_DEVICE check.
> return;
>
> if (!check_sdata_in_driver(sdata))
> @@ -1165,4 +1166,30 @@ static inline void drv_wake_tx_queue(struct ieee80211_local *local,
> local->ops->wake_tx_queue(&local->hw, &txq->txq);
> }
>
> +static inline int drv_start_nan(struct ieee80211_local *local,
> + struct ieee80211_sub_if_data *sdata,
> + struct cfg80211_nan_conf *conf)
> +{
> + int ret;
> +
> + might_sleep();
> + check_sdata_in_driver(sdata);
> +
> + trace_drv_start_nan(local, sdata, conf);
> + ret = local->ops->start_nan(&local->hw, &sdata->vif, conf);
> + trace_drv_return_int(local, ret);
> + return ret;
> +}
> +
> +static inline void drv_stop_nan(struct ieee80211_local *local,
> + struct ieee80211_sub_if_data *sdata)
> +{
> + might_sleep();
> + check_sdata_in_driver(sdata);
> +
> + trace_drv_stop_nan(local, sdata);
> + local->ops->stop_nan(&local->hw, &sdata->vif);
> + trace_drv_return_void(local);
> +}
> +
> #endif /* __MAC80211_DRIVER_OPS */
> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
> index e694ca2..507f46a 100644
> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -327,6 +327,9 @@ static int ieee80211_check_queues(struct ieee80211_sub_if_data *sdata,
> int n_queues = sdata->local->hw.queues;
> int i;
>
> + if (iftype == NL80211_IFTYPE_NAN)
> + return 0;
> +
> if (iftype != NL80211_IFTYPE_P2P_DEVICE) {
> for (i = 0; i < IEEE80211_NUM_ACS; i++) {
> if (WARN_ON_ONCE(sdata->vif.hw_queue[i] ==
> @@ -647,7 +650,8 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
> local->fif_probe_req++;
> }
>
> - if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE)
> + if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE &&
> + sdata->vif.type != NL80211_IFTYPE_NAN)
similar check keeps reoccuring in various places so maybe we can create
a helper function for it.
> changed |= ieee80211_reset_erp_info(sdata);
> ieee80211_bss_info_change_notify(sdata, changed);
>
Regards,
Arend
^ permalink raw reply
* [PATCH] ath10k: add cc_wraparound type for QCA9888 and QCA9884
From: akolli @ 2016-09-16 11:45 UTC (permalink / raw)
To: ath10k; +Cc: akolli, linux-wireless, Anilkumar Kolli
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
During offchannel scan, iw survey dump shows wrong values.
Fix this by assigning cycle counter wranarround type for
QCA9888 and QCA9884, they share same config with QCA4019.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 3a8984ba9f74..93168d9f8902 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -191,6 +191,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.name = "qca9984/qca9994 hw1.0",
.patch_load_addr = QCA9984_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
+ .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
.otp_exe_param = 0x00000700,
.continuous_frag_desc = true,
.cck_rate_map_rev2 = true,
@@ -215,6 +216,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.name = "qca9888 hw2.0",
.patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
+ .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
.otp_exe_param = 0x00000700,
.continuous_frag_desc = true,
.channel_counters_freq_hz = 150000,
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 3/9] cfg80211: add add_nan_func / rm_nan_func
From: kbuild test robot @ 2016-09-16 12:20 UTC (permalink / raw)
To: Luca Coelho
Cc: kbuild-all, johannes, linux-wireless, Ayala Beker,
Andrei Otcheretianski, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-4-luca@coelho.fi>
[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]
Hi Ayala,
[auto build test WARNING on mac80211-next/master]
[also build test WARNING on next-20160916]
[cannot apply to v4.8-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Luca-Coelho/Add-support-for-Neighbor-Awareness-Networking/20160916-164553
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: x86_64-randconfig-v0-09161926 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/if.h:23,
from net/wireless/nl80211.c:9:
net/wireless/nl80211.c: In function 'nl80211_nan_add_func':
net/wireless/nl80211.c:10588:30: error: implicit declaration of function 'genl_info_snd_portid' [-Werror=implicit-function-declaration]
wdev->owner_nlportid != genl_info_snd_portid(info))
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> net/wireless/nl80211.c:10587:2: note: in expansion of macro 'if'
if (wdev->owner_nlportid &&
^~
net/wireless/nl80211.c:10785:6: error: implicit declaration of function 'nla_put_u64' [-Werror=implicit-function-declaration]
if (nla_put_u64(msg, NL80211_ATTR_COOKIE, func->cookie))
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
net/wireless/nl80211.c:10785:2: note: in expansion of macro 'if'
if (nla_put_u64(msg, NL80211_ATTR_COOKIE, func->cookie))
^~
cc1: some warnings being treated as errors
vim +/if +10587 net/wireless/nl80211.c
10571 struct wireless_dev *wdev = info->user_ptr[1];
10572 struct nlattr *tb[NUM_NL80211_NAN_FUNC_ATTR], *func_attr;
10573 struct cfg80211_nan_func *func;
10574 struct sk_buff *msg = NULL;
10575 void *hdr = NULL;
10576 int err = 0;
10577
10578 if (wdev->iftype != NL80211_IFTYPE_NAN)
10579 return -EOPNOTSUPP;
10580
10581 if (!wdev->nan_started)
10582 return -ENOTCONN;
10583
10584 if (!info->attrs[NL80211_ATTR_NAN_FUNC])
10585 return -EINVAL;
10586
10587 if (wdev->owner_nlportid &&
10588 wdev->owner_nlportid != genl_info_snd_portid(info))
10589 return -ENOTCONN;
10590
10591 err = nla_parse(tb, NL80211_NAN_FUNC_ATTR_MAX,
10592 nla_data(info->attrs[NL80211_ATTR_NAN_FUNC]),
10593 nla_len(info->attrs[NL80211_ATTR_NAN_FUNC]),
10594 nl80211_nan_func_policy);
10595 if (err)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 22768 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Rob Herring @ 2016-09-16 12:37 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, mcgrof,
mark.rutland, kvalo, chunkeey, arend.vanspriel, julian.calaby,
bjorn, linux, nbd
In-Reply-To: <20160906214623.20424-2-martin.blumenstingl@googlemail.com>
On Tue, Sep 06, 2016 at 11:46:21PM +0200, Martin Blumenstingl wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 0000000..77b9202
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,39 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: For PCI and PCIe devices this should be an identifier following
> + the format as defined in "PCI Bus Binding to Open Firmware"
> + Revision 2.1. One of the possible formats is "pciVVVV,DDDD"
> + where VVVV is the PCI vendor ID and DDDD is PCI device ID.
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
reg is not optional.
> +- qca,clk-25mhz: Defines that a 25MHz clock is used
> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
> + ath9k wireless chip (in this case the calibration /
> + EEPROM data will be loaded from userspace using the
> + kernel firmware loader).
> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
> + 2.4GHz band. Setting this property is only needed
> + when the RF circuit does not support the 2.4GHz band
> + while it is enabled nevertheless in the EEPROM.
> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
> + 5GHz band. Setting this property is only needed when
> + the RF circuit does not support the 5GHz band while
> + it is enabled nevertheless in the EEPROM.
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +
> +
> +In this example, the node is defined as child node of the PCI controller:
> +&pci0 {
> + ath9k@168c,002d {
unit address is not the vendor/device ID, but the reg value. So
'@7000,0,0' I think in this case. Double check the OF PCI bus binding.
> + compatible = "pci168c,002d";
> + reg = <0x7000 0 0 0 0x1000>;
> + qca,disable-5ghz;
> + };
> +};
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Rob Herring @ 2016-09-16 12:45 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Oleksij Rempel, ath9k-devel, devicetree, linux-wireless,
ath9k-devel, mcgrof, mark.rutland, kvalo, chunkeey,
arend.vanspriel, julian.calaby, bjorn, nbd, arnd
In-Reply-To: <CAFBinCAOQmk3KY1b+D1iKAOEBfasYyei681cae4PbD+201mzbQ@mail.gmail.com>
On Fri, Sep 09, 2016 at 10:57:06PM +0200, Martin Blumenstingl wrote:
> On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> >> +Optional properties:
> >> +- reg: Address and length of the register set for the device.
> >> +- qca,clk-25mhz: Defines that a 25MHz clock is used
> >
> > Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
> > case we need to use clock framework any way, so why not in this case too?
> > Provide dummy static clock in DT and connect it with this node?
> >
> > osc25m: oscillator {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <25000000>;
> > clock-accuracy = <30000>;
> > };
> >
> > acc: clock-controller@80040000 {
> > compatible = "some-clock-controller";
> > #clock-cells = <1>;
> > clocks = <&osc25m>;
> > reg = <0x80040000 0x204>;
> > };
> >
> >
> > &pci0 {
> > ath9k@168c,002d {
> > compatible = "pci168c,002d";
> > reg = <0x7000 0 0 0 0x1000>;
> > clocks = <&osc25m>;
> > qca,disable-5ghz;
> > };
> > };
> >
> >
> > driver will need to use clk_get and compare frequency instead of
> > of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
> > to define source clock only one time and reuse it by all affected DT
> > nodes. If we have 40MHz clock you will only need to change it in
> > fixed-clock.
> that does sound like a good idea, thanks for that input!
> However, I will remove the property for the first version because I am
> trying to get PCI(e) devices supported. OF support for AHB (WiSoC)
> needs more work (in other places, like ahb.c) anyways.
> But this suggestion should be remembered!
>
> >> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
> >> + ath9k wireless chip (in this case the calibration /
> >> + EEPROM data will be loaded from userspace using the
> >> + kernel firmware loader).
> >> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
> >> + 2.4GHz band. Setting this property is only needed
> >> + when the RF circuit does not support the 2.4GHz band
> >> + while it is enabled nevertheless in the EEPROM.
> >> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
> >> + 5GHz band. Setting this property is only needed when
> >> + the RF circuit does not support the 5GHz band while
> >> + it is enabled nevertheless in the EEPROM.
> >
> > This option can be reused for every WiFi controller. Not only for qca.
> > So may be instead of adding vendor specific name, make it reusable for
> > all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
> > disable-5ghz and disable-2ghz?
Fine, but if you do this then document in a common location.
> I am personally fine with anything that fits best into the grand
> scheme of things.
> There are three scenarios I can think of which may be influenced by
> devicetree configuration:
> a) let the driver decide automatically whether the 2.4GHz and/or 5GHz
> band is/are enabled
> b) explicitly disable either bands (because the driver thinks due to
> whatever reason that a band is supported while in reality it isn't)
> c) explicitly enable a band (for example because the driver cannot
> automagically detect which band should be enabled)
>
> for ath9k we default to a) but also allow b): the EEPROM (device
> specific calibration data) contains information about which bands are
> enabled (or not). But some manufacturers are shipping devices for
> example with the 5G band enabled, while the actual hardware doesn't
> support it.
And you can't determine that based on different device IDs? If you can
use vendor/device ID, then you should. If not, then this is fine.
Is it possible to have no EEPROM at all? If so, you might want to just
put the raw EEPROM data into DT rather than a property for every field
(I'm assuming there's more than just what you have properties for now).
Rob
^ permalink raw reply
* pull-request: mac80211 2016-09-16
From: Johannes Berg @ 2016-09-16 12:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Sorry - I know you only just pulled my tree for the previous fixes,
but we found two more problems in the last few days; it'd be great
to get those fixes in as well.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit ad5987b47e96a0fb6d13fea250e936aed000093c:
nl80211: validate number of probe response CSA counters (2016-09-13 20:19:27 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-09-16
for you to fetch changes up to 85d5313ed717ad60769491c7c072d23bc0a68e7a:
mac80211: reject TSPEC TIDs (TSIDs) for aggregation (2016-09-15 10:08:52 +0200)
----------------------------------------------------------------
Two more fixes:
* reject aggregation sessions for TSID/TID 8-16 that we
can never use anyway and which could confuse drivers
* check return value of skb_linearize()
----------------------------------------------------------------
Johannes Berg (2):
mac80211: check skb_linearize() return value
mac80211: reject TSPEC TIDs (TSIDs) for aggregation
net/mac80211/agg-rx.c | 8 +++++++-
net/mac80211/agg-tx.c | 3 +++
net/mac80211/tx.c | 8 ++++++--
3 files changed, 16 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: allow to support AP_LINK_PS when the set_tim is still needed
From: Johannes Berg @ 2016-09-16 12:50 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160915133003.24214-1-luca@coelho.fi>
Both applied.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: add helper to find an IE that matches a byte-array
From: Johannes Berg @ 2016-09-16 12:50 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <20160915151509.30840-1-luca@coelho.fi>
On Thu, 2016-09-15 at 18:15 +0300, Luca Coelho wrote:
> From: Luca Coelho <luciano.coelho@intel.com>
>
> There are a few places where an IE that matches not only the EID, but
> also other bytes inside the element, needs to be found. To simplify
> that and reduce the amount of similar code, implement a new helper
> function to match the EID and an extra array of bytes.
>
Applied.
johannes
^ permalink raw reply
* pull-request: mac80211-next 2016-09-16
From: Johannes Berg @ 2016-09-16 12:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
And here's another set for net-next, it's been a month or so and we have a
reasonably large number of patches (for a change, mostly because I cleaned
up some WEP crypto thing and a few static checkers.)
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit 02154927c115c7599677df57203988e05b576346:
net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device (2016-09-11 19:37:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-09-16
for you to fetch changes up to fbd05e4a6e82fd573d3aa79e284e424b8d78c149:
cfg80211: add helper to find an IE that matches a byte-array (2016-09-16 14:49:52 +0200)
----------------------------------------------------------------
This time we have various things - all across the board:
* MU-MIMO sniffer support in mac80211
* a create_singlethread_workqueue() cleanup
* interface dump filtering that was documented but not implemented
* support for the new radiotap timestamp field
* send delBA in two unexpected conditions (as required by the spec)
* connect keys cleanups - allow only WEP with index 0-3
* per-station aggregation limit to work around broken APs
* debugfs improvement for the integrated codel algorithm
and various other small improvements and cleanups.
----------------------------------------------------------------
Aviya Erenfeld (2):
mac80211: refactor monitor representation in sdata
mac80211: add support for MU-MIMO air sniffer
Bhaktipriya Shridhar (1):
cfg80211: Remove deprecated create_singlethread_workqueue
Denis Kenzior (1):
nl80211: Allow GET_INTERFACE dumps to be filtered
Emmanuel Grumbach (2):
cfg80211: clarify the requirements of .disconnect()
mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE
Johannes Berg (21):
mac80211: add support for radiotap timestamp field
mac80211: send delBA on unexpected BlockAck data frames
mac80211: send delBA on unexpected BlockAck Request
mac80211: simplify TDLS RA lookup
mac80211: remove useless open_count check
cfg80211: disallow shared key authentication with key index 4
nl80211: fix connect keys range check
nl80211: only allow WEP keys during connect command
cfg80211: wext: only allow WEP keys to be configured before connected
cfg80211: validate key index better
cfg80211: reduce connect key caching struct size
cfg80211: allow connect keys only with default (TX) key
mac80211: fix possible out-of-bounds access
mac80211: fix scan completed tracing
nl80211: always check nla_nest_start() return value
nl80211: always check nla_put* return values
mac80211: remove unused assignment
mac80211: remove pointless chanctx NULL check
mac80211: remove sta_remove_debugfs driver callback
cfg80211: remove unnecessary pointer-of
mac80211_hwsim: statically initialize hwsim_radios list
Luca Coelho (1):
cfg80211: add helper to find an IE that matches a byte-array
Maxim Altshul (1):
mac80211: RX BA support for sta max_rx_aggregation_subframes
Rajkumar Manoharan (1):
mac80211: allow driver to handle packet-loss mechanism
Toke Høiland-Jørgensen (1):
mac80211: Re-structure aqm debugfs output and keep CoDel stats per txq
drivers/net/wireless/mac80211_hwsim.c | 3 +-
include/net/cfg80211.h | 36 +++++++-
include/net/ieee80211_radiotap.h | 21 +++++
include/net/mac80211.h | 33 ++++++--
net/mac80211/agg-rx.c | 11 ++-
net/mac80211/cfg.c | 35 ++++++--
net/mac80211/debugfs.c | 152 ++++++----------------------------
net/mac80211/debugfs_netdev.c | 37 ++++++++-
net/mac80211/debugfs_sta.c | 56 ++++++++++++-
net/mac80211/driver-ops.c | 2 +-
net/mac80211/driver-ops.h | 18 +---
net/mac80211/ieee80211_i.h | 11 ++-
net/mac80211/iface.c | 21 +++--
net/mac80211/main.c | 3 +
net/mac80211/mlme.c | 12 ++-
net/mac80211/pm.c | 3 +-
net/mac80211/rx.c | 69 ++++++++++++++-
net/mac80211/scan.c | 2 +-
net/mac80211/sta_info.c | 5 +-
net/mac80211/sta_info.h | 3 +
net/mac80211/status.c | 8 +-
net/mac80211/tx.c | 21 ++---
net/mac80211/util.c | 3 +-
net/wireless/core.c | 2 +-
net/wireless/core.h | 6 +-
net/wireless/ibss.c | 11 +--
net/wireless/mlme.c | 2 +-
net/wireless/nl80211.c | 85 ++++++++++++++++---
net/wireless/scan.c | 58 ++++++-------
net/wireless/sme.c | 3 +
net/wireless/sysfs.c | 2 +-
net/wireless/util.c | 13 +--
net/wireless/wext-compat.c | 9 +-
net/wireless/wext-sme.c | 5 +-
34 files changed, 484 insertions(+), 277 deletions(-)
^ permalink raw reply
* [PATCH -next] ath10k: fix error return code in ahb
From: Wei Yongjun @ 2016-09-16 13:05 UTC (permalink / raw)
To: Kalle Valo, Raja Mani; +Cc: Wei Yongjun, ath10k, linux-wireless
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return a negative error code from the error handling case
instead of 0, as done elsewhere in function ath10k_ahb_probe() or
ath10k_ahb_resource_init().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/wireless/ath/ath10k/ahb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/ahb.c b/drivers/net/wireless/ath/ath10k/ahb.c
index b99ad5d..6dc1c60 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -572,6 +572,7 @@ static int ath10k_ahb_resource_init(struct ath10k *ar)
ar_ahb->irq = platform_get_irq_byname(pdev, "legacy");
if (ar_ahb->irq < 0) {
ath10k_err(ar, "failed to get irq number: %d\n", ar_ahb->irq);
+ ret = ar_ahb->irq;
goto err_clock_deinit;
}
@@ -850,6 +851,7 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
chip_id = ath10k_ahb_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
if (chip_id == 0xffffffff) {
ath10k_err(ar, "failed to get chip id\n");
+ ret = -ENODEV;
goto err_halt_device;
}
^ permalink raw reply related
* Re: wireless.wiki.kernel.org: lingering status of http://linuxwireless.org/en/users/Drivers/wl12xx/calibrator/
From: Andreas Mohr @ 2016-09-16 16:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andreas Mohr, linux-wireless
In-Reply-To: <1474018288.5481.4.camel@sipsolutions.net>
Hi,
On Fri, Sep 16, 2016 at 11:31:28AM +0200, Johannes Berg wrote:
> > The apparent underlying reason for this surfaces when going through
> > the en ... users ... Drivers hierarchy to
> > https://wireless.wiki.kernel.org/en/users/drivers/wl12xx
> > where it says
> > "
> > For relicensing, the content of this page was removed.
> >
> > The old website for now has a copy of the old content:
> >
> > http://linuxwireless.sipsolutions.net/en/users/Drivers/wl12xx/·
> > "
>
> Right, so there were some people who couldn't be reached for
> relicensing of their submissions under the license the new wiki
> requires. The wl1251 and wl12xx pages were removed since I couldn't
> reach Gery Kahn and Oz Krakowski, or they couldn't agree to
> relicensing, I don't remember. I still have the Google spreadsheet that
> tells me who it was though :-)
Hmm, would be nice if that situation were sufficiently easily improvable still...
(however sometimes RL ain't that easy after all).
> I have no intention of removing it, since it's a static HTML site and
> has no maintenance overhead.
Sufficiently solid intentions, given status quo.
(so that content likely won't be available in one hundred years,
but now there's hope that it will remain available
over a "sane" remaining lifetime span of these devices... ;)
> > So, are there some ways to improve the content situation,
> > or will this job then eventually need to be done by last-ditch
> > efforts (web.archive.org etc.)?
>
> I can't side-step the licensing issue, so no. You can download and
> store locally everything you need, I guess.
Dito.
(I already had the same thought and had acted accordingly)
Thank you for your service!
Andreas Mohr
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Pedersen, Thomas @ 2016-09-16 18:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ben Greear, linux-wireless
In-Reply-To: <1473789740.5622.3.camel@sipsolutions.net>
T24gVHVlLCAyMDE2LTA5LTEzIGF0IDIwOjAyICswMjAwLCBKb2hhbm5lcyBCZXJnIHdyb3RlOg0K
PiA+IFllYWggc28gYXBwYXJlbnRseSB0aGUgb3ZlcmhlYWQgaW52b2x2ZWQgaW4gMjU2LVFBTSA1
LzYgKE1DUyA5KQ0KPiA+IHJlc3VsdHMgaW4gbG93ZXIgZWZmZWN0aXZlIGJpdHJhdGUgdGhhbiBq
dXN0IHVzaW5nIE1DUyA4ICh1bmxlc3MNCj4gPiB5b3UncmUgdXNpbmcgMyBzcGF0aWFsIHN0cmVh
bXMpLg0KPiANCj4gQWguIEkgdG9vayBhIC0gdmVyeSBicmllZiAtIGxvb2sgYXQgd2h5IHRoaXMg
b25lIGlzIGludmFsaWQgYW5kDQo+IGNvdWxkbid0IGZpZ3VyZSBpdCBvdXQuDQoNCkkgZG9uJ3Qg
a25vdyB3aGF0IEknbSB0YWxraW5nIGFib3V0LiBUaGlzIHdhcyBhIG1pc2NvbW11bmljYXRpb24g
ZnJvbQ0KdGhlIHN5c3RlbXMgdGVhbS4gSSB0aGluayBpdCB3YXMgYmVjYXVzZSBFVk0gdGFyZ2V0
cyB3ZXJlIHRvbyBoaWdoLCBidXQNCkxEUEMgZml4ZXMgdGhhdCwgc2VlIGJlbG93Lg0KDQo+ID4g
IFNvdW5kcyBsaWtlIGEgcmF0ZSBjb250cm9sIG9yIHJlcG9ydGluZyBidWcgdGhlbi4NCj4gPiBQ
bGVhc2UgZHJvcCB0aGlzLg0KPiA+IA0KPiBPaywgdGhhbmtzLg0KDQpBY3R1YWxseSwgY2FuIHlv
dSBhcHBseSB0aGUgdjIgKGNmZzgwMjExOiBhZGQgYml0cmF0ZSBmb3IgMjBNSHogTUNTIDkpDQpv
ZiB0aGlzPyBTeXN0ZW1zIGd1eXMgY29uZmlybWVkIHRoZXkgdXNlIE1DUyA5IEAgMjBNSHogd2hl
biBMRFBDIGlzDQplbmFibGVkLiBBbHNvIGNvbmZpcm1lZCBiaXRyYXRlIHNob3VsZCBiZSBvay4N
Cg0KVGhhbmtzLA0KDQp0aG9tYXMNCg==
^ permalink raw reply
* Re: [PATCH 4/4] ath10k: fix spurious tx/rx during boot
From: Hsu, Ryan @ 2016-09-16 22:37 UTC (permalink / raw)
To: michal.kazior@tieto.com, Valo, Kalle
Cc: marek.puzyniak@tieto.com, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <1468924452-23877-5-git-send-email-michal.kazior@tieto.com>
On 07/19/2016 03:34 AM, Michal Kazior wrote:
> =20
> +static int ath10k_core_reset_rx_filter(struct ath10k *ar)
> +{
> + int ret;
> + int vdev_id;
> + int vdev_type;
> + int vdev_subtype;
> + const u8 *vdev_addr;
> +
> + vdev_id =3D 0;
> + vdev_type =3D WMI_VDEV_TYPE_STA;
> + vdev_subtype =3D ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE)=
;
> + vdev_addr =3D ar->mac_addr;
> +
> + ret =3D ath10k_wmi_vdev_create(ar, vdev_id, vdev_type, vdev_subtype,
> + vdev_addr);
> + if (ret) {
> + ath10k_err(ar, "failed to create dummy vdev: %d\n", ret);
> + return ret;
> + }
> +
> + ret =3D ath10k_wmi_vdev_delete(ar, vdev_id);
> + if (ret) {
> + ath10k_err(ar, "failed to delete dummy vdev: %d\n", ret);
> + return ret;
> + }
> +
> + /* WMI and HTT may use separate HIF pipes and are not guaranteed to be
> + * serialized properly implicitly.
> + *
> + * Moreover (most) WMI commands have no explicit acknowledges. It is
> + * possible to infer it implicitly by poking firmware with echo
> + * command - getting a reply means all preceding comments have been
> + * (mostly) processed.
> + *
> + * In case of vdev create/delete this is sufficient.
> + *
> + * Without this it's possible to end up with a race when HTT Rx ring is
> + * started before vdev create/delete hack is complete allowing a short
> + * window of opportunity to receive (and Tx ACK) a bunch of frames.
> + */
> + ret =3D ath10k_wmi_barrier(ar);
QCA6174 UTF firmware seems doesn't support the WMI_ECHO command.
[16460.274822] ath10k_pci 0000:04:00.0: wmi tlv echo value 0x0ba991e9
...
[16463.461970] ath10k_pci 0000:04:00.0: failed to ping firmware: -110
[16463.461975] ath10k_pci 0000:04:00.0: failed to reset rx filter: -110
Has anyone verified any AP solution to see if UTF mode is still working=20
with after this patch?
Anyway, I would like to exclude the workaround from all solution's UTF mode=
.
Michal any concerns? (or maybe just for QCA61x4 if any...)
> + if (ret) {
> + ath10k_err(ar, "failed to ping firmware: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
>
^ permalink raw reply
* [athk9] beacon.c:642 ath9k_calculate_summary_state dump
From: Vidar Haarr @ 2016-09-17 9:49 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm seeing the message below spammed continously in journald, even
with 4.8-rc6. It's so bad that it throttles the CPU performance every
few seconds.
I found https://patchwork.kernel.org/patch/9247699/ which seems related.
I am not subscribed to linux-wireless.
First, here's some system info, then the stack trace at the bottom.
$ lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM
Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 2 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC
Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family
SMBus Controller (rev 04)
02:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network
Adapter (rev 01)
$ sudo lshw -class network
[sudo] passord for folk:
*-network
description: Wireless interface
product: AR9462 Wireless Network Adapter
vendor: Qualcomm Atheros
physical id: 0
bus info: pci@0000:02:00.0
logical name: wlan0
version: 01
serial: 24:ec:99:7f:0e:30
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list rom
ethernet physical wireless
configuration: broadcast=yes driver=ath9k
driverversion=4.8.0-040800rc6-generic firmware=N/A ip=192.168.1.176
latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:17 memory:f0400000-f047ffff memory:f0480000-f048ffff
$ uname -a
Linux edbpc 4.8.0-040800rc6-generic #201609121119 SMP Mon Sep 12
15:21:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
rfkill list all
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
sep. 17 11:38:36 edbpc kernel: WARNING: CPU: 0 PID: 1684 at
/home/kernel/COD/linux/drivers/net/wireless/ath/ath9k/beacon.c:642
ath9k_calculate_summary_state+0x135/0x390 [ath9k]
sep. 17 11:38:36 edbpc kernel: Modules linked in: fuse ctr ccm
binfmt_misc nls_utf8 nls_cp437 vfat fat intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic arc4 snd_hda_intel
snd_hda_codec snd_hda_core ath9k snd_hwdep ath9k_common ath9k_hw
snd_pcm ath kvm_intel snd_seq_midi uvcvideo snd_seq_midi_event
mac80211 kvm videobuf2_vmalloc snd_rawmidi irqbypass videobuf2_memops
snd_seq crct10dif_pclmul videobuf2_v4l2 crc32_pclmul videobuf2_core
snd_seq_device videodev ghash_clmulni_intel cryptd intel_cstate
cfg80211 media intel_rapl_perf snd_timer ath3k btusb btrtl btbcm
btintel efi_pstore bluetooth snd joydev rfkill efivars lpc_ich
serio_raw sg shpchp mei_me soundcore mfd_core mei evdev fujitsu_laptop
battery ac tpm_tis tpm_tis_core tpm lp parport loop efivarfs
sep. 17 11:38:36 edbpc kernel: ip_tables x_tables autofs4 ext4 crc16
jbd2 fscrypto mbcache hid_generic usbhid hid uas usb_storage sd_mod
i915 ahci crc32c_intel libahci libata psmouse i2c_algo_bit scsi_mod
drm_kms_helper xhci_pci syscopyarea ehci_pci xhci_hcd sysfillrect
ehci_hcd sysimgblt fb_sys_fops usbcore drm usb_common fan thermal
video fjes button
sep. 17 11:38:36 edbpc kernel: CPU: 0 PID: 1684 Comm: kworker/u16:0
Tainted: G W 4.8.0-040800rc6-generic #201609121119
sep. 17 11:38:36 edbpc kernel: Hardware name: FUJITSU LIFEBOOK
UH572/FJNBB31 , BIOS 2.15 07/29/2013
sep. 17 11:38:36 edbpc kernel: Workqueue: phy0 ieee80211_scan_work [mac80211]
sep. 17 11:38:36 edbpc kernel: 0000000000000286 00000000189cb902
ffffffffab33fb84 0000000000000000
sep. 17 11:38:36 edbpc kernel: 0000000000000000 ffffffffab07f69e
ffff96690ec45580 ffff96690ec46e10
sep. 17 11:38:36 edbpc kernel: ffff96690ec74018 ffff96690ec74018
ffff966912773360 ffff966912773360
sep. 17 11:38:36 edbpc kernel: Call Trace:
sep. 17 11:38:36 edbpc kernel: [<ffffffffab33fb84>] ? dump_stack+0x5c/0x78
sep. 17 11:38:36 edbpc kernel: [<ffffffffab07f69e>] ? __warn+0xbe/0xe0
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a0b5>] ?
ath9k_calculate_summary_state+0x135/0x390 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a332>] ?
ath_complete_reset+0x22/0x130 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a55e>] ?
ath_reset_internal+0x11e/0x1e0 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a656>] ?
ath_reset+0x36/0x50 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b82e5a>] ?
ath_chanctx_set_channel+0x13a/0x250 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b796c9>] ?
ath9k_config+0xb9/0x1e0 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc09a9d05>] ?
ieee80211_hw_config+0x85/0x3e0 [mac80211]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc09b52ed>] ?
__ieee80211_scan_completed+0xfd/0x470 [mac80211]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc09b5eeb>] ?
ieee80211_scan_work+0x7b/0x490 [mac80211]
sep. 17 11:38:36 edbpc kernel: [<ffffffffab098ae4>] ?
process_one_work+0x184/0x4b0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab098e5d>] ? worker_thread+0x4d/0x480
sep. 17 11:38:36 edbpc kernel: [<ffffffffab6188b1>] ? __schedule+0x261/0x720
sep. 17 11:38:36 edbpc kernel: [<ffffffffab098e10>] ?
process_one_work+0x4b0/0x4b0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab09efbd>] ? kthread+0xcd/0xf0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab02c751>] ? __switch_to+0x2c1/0x7a0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab61d41f>] ? ret_from_fork+0x1f/0x40
sep. 17 11:38:36 edbpc kernel: [<ffffffffab09eef0>] ?
kthread_create_on_node+0x1a0/0x1a0
sep. 17 11:38:36 edbpc kernel: ---[ end trace 4e47cb6784f0f49d ]---
--
Vidar
^ permalink raw reply
* Re: [athk9] beacon.c:642 ath9k_calculate_summary_state dump
From: Kalle Valo @ 2016-09-17 13:29 UTC (permalink / raw)
To: Vidar Haarr; +Cc: linux-wireless
In-Reply-To: <CAJiC63F-O5KeCP+JZjW38uNDc=umXcOZVGma_SyiaTm70fGQ3A@mail.gmail.com>
Vidar Haarr <vidar@heidrunbryggeri.no> writes:
> I'm seeing the message below spammed continously in journald, even
> with 4.8-rc6. It's so bad that it throttles the CPU performance every
> few seconds.
>
> I found https://patchwork.kernel.org/patch/9247699/ which seems related.
[...]
> sep. 17 11:38:36 edbpc kernel: WARNING: CPU: 0 PID: 1684 at
> /home/kernel/COD/linux/drivers/net/wireless/ath/ath9k/beacon.c:642
> ath9k_calculate_summary_state+0x135/0x390 [ath9k]
Looks like exactly the same problem, but the fix (below) is not in
v4.8-rc6. Should be in -rc7 which Linus hopefully releases on Sunday.
Please test that and report if the problem continues.
05860bed491b ath9k: fix client mode beacon configuration
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 13:46 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <1466460688-28160-1-git-send-email-igor.mitsyanko.os@quantenna.com>
<igor.mitsyanko.os@quantenna.com> writes:
> From: Avinash Patil <avinashp@quantenna.com>
>
> This patch adds support for new FullMAC WiFi driver for Quantenna
> QSR10G chipsets.
>
> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
> supports 160M, 8x8 configuration.
> FW supports 8 concurrent virtual interfaces on each WMAC.
>
> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>
> Signed-off-by: Dmitrii Lebed <dlebed@quantenna.com>
> Signed-off-by: Sergei Maksimenko <smaksimenko@quantenna.com>
> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
> Signed-off-by: Bindu Therthala <btherthala@quantenna.com>
> Signed-off-by: Huizhao Wang <hwang@quantenna.com>
> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
I read this through and looking good. Below are some comments.
I also saw few warnings but I suspect they are because of cfg80211 API
changes (didn't bother to check that now):
drivers/net/wireless/quantenna/qtnfmac/event.c: In function `qtnf_event_handle_scan_complete':
drivers/net/wireless/quantenna/qtnfmac/event.c:342:2: warning: passing argument 2 of `cfg80211_scan_done' makes pointer from integer without a cast [enabled by default]
./include/net/cfg80211.h:4104:6: note: expected `struct cfg80211_scan_info *' but argument is of type `u32'
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c: In function `qtnf_virtual_intf_cleanup':
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c:1093:4: warning: passing argument 2 of `cfg80211_scan_done' makes pointer from integer without a cast [enabled by default]
./include/net/cfg80211.h:4104:6: note: expected `struct cfg80211_scan_info *' but argument is of type `int'
> Resend to correct email kvalo@codeaurora.org.
BTW, no need to send me directly. I take patches directly from patchwork
so sending them to linux-wireless is enough. Doesn't do any harm to send
them to, I just immediately delete them from my INBOX :)
> Changelist V1->V2:
> 1. Get rid of confidentiality footer.
> 2. Rewrite qlink.h header to make it easier to use, add
> documentation to most of qlink.h definitions.
>
> MAINTAINERS | 8 +
> drivers/net/wireless/Kconfig | 1 +
> drivers/net/wireless/Makefile | 1 +
> drivers/net/wireless/quantenna/Kconfig | 16 +
> drivers/net/wireless/quantenna/Makefile | 6 +
> drivers/net/wireless/quantenna/include/bus.h | 195 ++
> .../wireless/quantenna/include/pcie_regs_pearl.h | 353 ++++
> drivers/net/wireless/quantenna/include/qlink.h | 939 ++++++++++
> .../net/wireless/quantenna/include/qtn_hw_ids.h | 34 +
> .../net/wireless/quantenna/include/shm_ipc_defs.h | 46 +
Is there a particular reason why you have a separate include directory?
There's just one quantenna driver for now so the extra include directory
feels unnecessary. I would prefer to have that only once there are two
quantenna drivers and we know exactly what is shared between the two.
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9151,6 +9151,14 @@ L: qemu-devel@nongnu.org
> S: Maintained
> F: drivers/firmware/qemu_fw_cfg.c
>
> +QUANTENNA QTNFMAC WIRELESS DRIVER
> +M: Igor Mitsyanko <imitsyanko@quantenna.com>
> +M: Avinash Patil <avinashp@quantenna.com>
> +M: Sergey Matyukevich <smatyukevich@quantenna.com>
> +L: linux-wireless@vger.kernel.org
> +S: Maintained
> +F: drivers/net/wireless/quantenna/qtnfmac
The include directory is not listed.
> +ccflags-y += -D__CHECK_ENDIAN
Very good.
> +/* Supported rates to be advertised to the cfg80211 */
> +static struct ieee80211_rate qtnf_rates[] = {
> + {.bitrate = 10, .hw_value = 2, },
> + {.bitrate = 20, .hw_value = 4, },
> + {.bitrate = 55, .hw_value = 11, },
> + {.bitrate = 110, .hw_value = 22, },
> + {.bitrate = 60, .hw_value = 12, },
> + {.bitrate = 90, .hw_value = 18, },
> + {.bitrate = 120, .hw_value = 24, },
> + {.bitrate = 180, .hw_value = 36, },
> + {.bitrate = 240, .hw_value = 48, },
> + {.bitrate = 360, .hw_value = 72, },
> + {.bitrate = 480, .hw_value = 96, },
> + {.bitrate = 540, .hw_value = 108, },
> +};
> +
> +/* Channel definitions to be advertised to cfg80211 */
> +static struct ieee80211_channel qtnf_channels_2ghz[] = {
> + {.center_freq = 2412, .hw_value = 1, },
> + {.center_freq = 2417, .hw_value = 2, },
> + {.center_freq = 2422, .hw_value = 3, },
> + {.center_freq = 2427, .hw_value = 4, },
> + {.center_freq = 2432, .hw_value = 5, },
> + {.center_freq = 2437, .hw_value = 6, },
> + {.center_freq = 2442, .hw_value = 7, },
> + {.center_freq = 2447, .hw_value = 8, },
> + {.center_freq = 2452, .hw_value = 9, },
> + {.center_freq = 2457, .hw_value = 10, },
> + {.center_freq = 2462, .hw_value = 11, },
> + {.center_freq = 2467, .hw_value = 12, },
> + {.center_freq = 2472, .hw_value = 13, },
> + {.center_freq = 2484, .hw_value = 14, },
> +};
I guess some of these static variables could be also const, but didn't
check.
> +MODULE_AUTHOR("Quantenna Communications");
> +MODULE_DESCRIPTION("Quantenna 802.11 wireless LAN FullMAC driver.");
> +MODULE_LICENSE("Dual BSD/GPL");
[...]
> +++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
> @@ -0,0 +1,170 @@
> +/**
> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + **/
MODULE_LICENSE() doesn't match license in headers, is that correct?
> +static int
> +qtnf_event_handle_sta_assoc(struct qtnf_wmac *mac, struct qtnf_vif *vif,
> + const struct qlink_event_sta_assoc *sta_assoc,
> + u16 len)
> +{
> + const u8 *sta_addr;
> + u16 frame_control;
> + struct station_info sinfo = { 0 };
> + size_t payload_len;
> + u16 tlv_type;
> + u16 tlv_value_len;
> + size_t tlv_full_len;
> + const struct qlink_tlv_hdr *tlv;
> +
> + if (unlikely(len < sizeof(*sta_assoc))) {
> + pr_err("%s: payload is too short (%u < %zu)\n", __func__,
> + len, sizeof(*sta_assoc));
> + return -EINVAL;
> + }
I see unlikely() used a lot, I counted 145 times. Not a big issue but I
don't see the point. In hot path I understand using it, but not
everywhere.
> +/* sysfs knobs: stats and other diagnistics */
Johannes also commented about this. Please use debugfs or some generic
interface.
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-09-15
From: David Miller @ 2016-09-17 13:54 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87zin99p3y.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 15 Sep 2016 18:09:21 +0300
> here's the first pull request for 4.9. The ones I want to point out are
> the FIELD_PREP() and FIELD_GET() macros added to bitfield.h, which are
> reviewed by Linus, and make it possible to remove util.h from mt7601u.
>
> Also we have new HW support to various drivers and other smaller
> features, the signed tag below contains more information. And I pulled
> my ath-current (uses older net tree as the baseline) branch to fix a
> conflict in ath10k.
>
> Once again the diffstat from git request-pull was wrong. I fixed it by
> manually copying the diffstat from a test pull against net-next, so
> everything should be ok. But please let me know if there are any
> problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 13:56 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <1466460688-28160-1-git-send-email-igor.mitsyanko.os@quantenna.com>
<igor.mitsyanko.os@quantenna.com> writes:
> From: Avinash Patil <avinashp@quantenna.com>
>
> This patch adds support for new FullMAC WiFi driver for Quantenna
> QSR10G chipsets.
>
> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
> supports 160M, 8x8 configuration.
> FW supports 8 concurrent virtual interfaces on each WMAC.
>
> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>
> Signed-off-by: Dmitrii Lebed <dlebed@quantenna.com>
> Signed-off-by: Sergei Maksimenko <smaksimenko@quantenna.com>
> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
> Signed-off-by: Bindu Therthala <btherthala@quantenna.com>
> Signed-off-by: Huizhao Wang <hwang@quantenna.com>
> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
More comments:
> +/* FW names */
> +
> +#define QTN_PCI_FW_NAME "pearl-linux.lzma.img"
The firmware name gives no indication what this file is about (remember
that linux-firmware.git has a lot of files). Please name it properly,
don't just use what is used in by firmware build scripts :) Take into
account also future hw support, all firmware files need to coexist in
the same repository without user invention. In a way the firmware
filename is part of kernel/userspace interface and needs to be stable.
For example, you could use something like "qtnfmac/qsr10g.img" (assuming
qsr10g is the name of chip).
I forgot already, is the firmware image ready for submission to
linux-firmware.git?
> + pr_info("%s: %sregistered mgmt frame type 0x%x\n", __func__,
> + reg ? "" : "un", frame_type);
The driver seems to be quite spammy with info messages:
qtnfmac/cfg80211.c: pr_info("%s: %sregistered mgmt frame type 0x%x\n", __func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s cipher=%x, idx=%u, pairwise=%u\n", __func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, pairwise=%u\n", __func__, key_index,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, unicast=%u, multicast=%u\n", __func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u\n", __func__, key_index);
qtnfmac/cfg80211.c: pr_info("%s: initiator=%d, alpha=%c%c, macid=%d\n", __func__,
qtnfmac/cfg80211.c: pr_info("%s: MAX_IF: %zu; MODES: %.4X; RADAR WIDTHS: %.2X\n", __func__,
qtnfmac/cfg80211.c: pr_info("macid=%d, phymode=%#x\n", mac->macid, mac->macinfo.phymode);
qtnfmac/commands.c: pr_info("%s: unexpected TLV type: %.4X\n",
qtnfmac/commands.c: pr_info("%s: STA %pM not found\n", __func__, sta_mac);
qtnfmac/commands.c: pr_info("country-code from EP: %c%c\n", hwinfo->country_code[0],
qtnfmac/commands.c: pr_info("fw_version = %d, num_mac=%d, mac_bitmap=%#x\n",
qtnfmac/commands.c: pr_info("iface limit record count=%zu\n", record_count);
qtnfmac/commands.c: pr_info("MAC%d reported channels %d\n",
qtnfmac/init.c: pr_info("%s: macid=%d\n", __func__, macid);
qtnfmac/pcie.c: pr_info("enabled PCIE MSI interrupt\n");
qtnfmac/pcie.c: pr_info("%s: BAR[%u] vaddr=0x%p busaddr=0x%p len=%u\n",
qtnfmac/pcie.c: pr_info("%s: set mps to %d (was %d, max %d)\n",
qtnfmac/pcie.c: pr_info("fw download started: fw start addr = 0x%p, size=%d\n",
qtnfmac/pcie.c: pr_info("fw download completed: totally sent %d blocks\n", blk);
qtnfmac/pcie.c: pr_info("RC is ready to boot EP...\n");
qtnfmac/pcie.c: pr_info("starting download firmware %s...\n", bus->fwname);
qtnfmac/pcie.c: pr_info("successful init of PCI device %x\n", pdev->device);
qtnfmac/pcie.c: pr_info("Register Quantenna FullMAC PCIE driver\n");
qtnfmac/pcie.c: pr_info("Unregister Quantenna FullMAC PCIE driver\n");
qtnfmac/trans.c: pr_info("%s: interrupted\n", __func__);
qtnfmac/trans.c: pr_info("%s: skb dropped\n", __func__);
Usualle the preference is that driver is quiet until something goes
wrong. I hope some of these could be debug messages.
> --- /dev/null
> +++ b/drivers/net/wireless/quantenna/qtnfmac/pcie.c
> @@ -0,0 +1,1374 @@
> +/**
> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + **/
> +
> +#undef DEBUG
Why?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 13:59 UTC (permalink / raw)
To: Igor Mitsyanko
Cc: Johannes Berg, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <fd6ee9cd-71fd-352a-e1cd-61d36b296057@quantenna.com>
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> writes:
> thank for review and sorry for long delays in replies. A parallel
> thread with Dave a discussion was initiated regarding HW platform
> samples availability. Current driver implementation supports a newer
> QSR10G platform, which availability is limited due to the platform
> still being in development stage. We're working on supporting
> Quantenna's current QSR1000 platform too, what would be the best
> approach to this:
> - have QSR1000 platform support ready, amend it to current patch and
> post it as a new patch revision (there should be a certain amount of
> new code);
> - have current patch accepted by community first, and then post a new
> patch (adding new platform support) one on top of it.
I prefer the latter option. Let's first try to get the driver applied
and then you can submit more features as followup patches.
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: iwlwifi 2016-09-15
From: Kalle Valo @ 2016-09-17 14:08 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1473955833.5664.38.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> Here is one more patch intended for 4.8. =C2=A0It's small and low risk, j=
ust
> moving some lines of code around, to prevent a firmware crash in
> certain situations.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit a904a08b5fee5317ff0f7b8212aa5d0776795a=
52:
>
> =C2=A0 iwlwifi: mvm: Advertise support for AP channel width change (2016-=
08-29 22:29:06 +0300)
>
> are available in the git repository at:
>
> =C2=A0 git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixe=
s.git tags/iwlwifi-for-kalle-2016-09-15
Pulled, thanks.
--=20
Kalle Valo
^ 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