* Re: ath10k: add spectral scan support to wmi-tlv
From: Kalle Valo @ 2016-11-23 13:57 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless, Michal Kazior
In-Reply-To: <1479130000-11551-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> wrote:
> Command structure and event flow doesn't seem to
> be any different compared to existing
> implementation for other firmware branches.
>
> This patch effectively adds in-driver support for
> spectral scanning on QCA61x4 and QCA9377.
>
> Tested QCA9377 w/ WLAN.TF.1.0-00267-1.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Patch applied to ath-next branch of ath.git, thanks.
5a401f36ba30 ath10k: add spectral scan support to wmi-tlv
--
https://patchwork.kernel.org/patch/9427503/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
From: Kalle Valo @ 2016-11-23 13:58 UTC (permalink / raw)
To: Matthias Schiffer
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, miaoqing
In-Reply-To: <44116a7bca8524a187083916bdea535145e7a23a.1479232041.git.mschiffer@universe-factory.net>
Matthias Schiffer <mschiffer@universe-factory.net> wrote:
> Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
> SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
> changing the return on success from 1 to BIT(gpio). This broke some callers
> like ath_is_rfkill_set().
>
> Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
> return 0 or 1.
>
> Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
> Cc: <stable@vger.kernel.org> # v4.7+
> Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Patch applied to ath-next branch of ath.git, thanks.
91851cc7a939 ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
--
https://patchwork.kernel.org/patch/9430247/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k: fix NULL pointer dereference
From: Kalle Valo @ 2016-11-23 13:59 UTC (permalink / raw)
To: miaoqing pan; +Cc: linux-wireless, ath9k-devel, devin.tuchsen, Miaoqing Pan
In-Reply-To: <1479288188-3793-1-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> relay_open() may return NULL, check the return value to avoid the crash.
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
> IP: [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
> PGD 41cf28067 PUD 41be92067 PMD 0
> Oops: 0000 [#1] SMP
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35
> Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15 07/04/2011
> task: ffffffff81e0c4c0 task.stack: ffffffff81e00000
> RIP: 0010:[<ffffffffa01a95c5>] [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
> RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293
> RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98
> RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0
> Stack:
> 0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9
> 000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0
> 0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60
>
> Call Trace:
> <IRQ>
> [<ffffffffa01b6441>] ath9k_tasklet+0x1b1/0x220 [ath9k]
> [<ffffffff8105d8dd>] tasklet_action+0x4d/0xf0
> [<ffffffff8105dde2>] __do_softirq+0x92/0x2a0
>
> Reported-by: Devin Tuchsen <devin.tuchsen@gmail.com>
> Tested-by: Devin Tuchsen <devin.tuchsen@gmail.com>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
40bea976c72b ath9k: fix NULL pointer dereference
--
https://patchwork.kernel.org/patch/9431163/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/7] wil6210: fix net queue stop/wake
From: Kalle Valo @ 2016-11-23 14:51 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Dedy Lansky, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1477720287-17606-2-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> From: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
>
> Driver calls to netif_tx_stop_all_queues/netif_tx_wake_all_queues are
> inconsistent. In several cases, driver can get to a situation where net
> queues are stopped forever and data cannot be sent.
>
> The fix is to stop net queues if there is at least one vring which is
> "full" and to wake net queues if all vrings are not "full".
>
> Signed-off-by: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
6 patches applied to ath-next branch of ath.git, thanks.
f9e3033ff7eb wil6210: fix net queue stop/wake
2c207eb8e6ab wil6210: add support for power save enable / disable
dfb5b098e0f4 wil6210: fix deadlock when using fw_no_recovery option
035859a5117b wil6210: add support for abort scan
cbf795c195fb wil6210: align to latest auto generated wmi.h
3fea18d079e2 wil6210: support NL80211_ATTR_WIPHY_RETRY_SHORT
--
https://patchwork.kernel.org/patch/9403059/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: Kalle Valo @ 2016-11-23 15:25 UTC (permalink / raw)
To: IgorMitsyanko
Cc: Johannes Berg, linux-wireless, btherthala, hwang, smaksimenko,
dlebed, Igor Mitsyanko, Kamlesh Rath, Sergey Matyukevich,
Avinash Patil, Ben Hutchings, Kyle McMartin
In-Reply-To: <a5075f50-25c6-18a1-bd5b-309927dacdab@quantenna.com>
IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
> To clarify with you and Kalle, as persons involved with
> linux-wireless: is my understanding correct that submitting firmware
> into linux-fimware repository is a prerequisite to accepting new
> driver into linux-wireless?
In my opinion the most important is that the device is usable with an
upstream driver so that anyone can start using the driver (if they have
the hardware).
> There is an option to start Quantenna device from internal flash
> memory, no external binary files involved. If we will introduce this
> functionality and remove code handling external firmware for now
> (until firmware problem resolved), would that allow driver to be
> reviewed/accepted?
Do all the publically available hardware contain the firmware in
internal flash (flashed in the factory)? Or is this something which must
be installed separately for each board's internal flash by the user?
BTW, the original mail with the firmware image didn't make it to the
list, I guess it was too big? It would be good if you could post the
license separately so that people can see it.
--
Kalle Valo
^ permalink raw reply
* Re: rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB
From: Kalle Valo @ 2016-11-23 15:34 UTC (permalink / raw)
To: Vishal Thanki; +Cc: sgruszka, helmut.schaa, linux-wireless, Vishal Thanki
In-Reply-To: <1479312114-9389-1-git-send-email-vishalthanki@gmail.com>
Vishal Thanki <vishalthanki@gmail.com> wrote:
> In device removal routine, usage of "#ifdef CONFIG_RT2X00_LIB_USB"
> will not cover the case when it is configured as module. This will
> omit the entire if-block which does cleanup of URBs and cancellation
> of pending work. Changing the #ifdef to #if IS_ENABLED() to fix it.
>
> Signed-off-by: Vishal Thanki <vishalthanki@gmail.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
a083c8fd277b rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB
--
https://patchwork.kernel.org/patch/9431983/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2] brcmfmac: update beacon IE after bss up and clear when AP stopped
From: Kalle Valo @ 2016-11-23 15:34 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel, franky.lin, hante.meuleman, pieterpg,
brcm80211-dev-list.pdl, linux-wireless, Chi-Hsien Lin,
wright.feng
In-Reply-To: <20161118015952.GA22142@cypress.com>
Wright Feng <wefe@cypress.com> wrote:
> Firmware doesn't update beacon/Probe Response vendor IEs correctly when
> bss is down, so we move brcmf_config_ap_mgmt_ie after BSS up. And host
> driver should clear IEs when AP stopped so that the IEs in host side will
> be synced with in firmware side.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
Patch applied to wireless-drivers-next.git, thanks.
f25ba69c638b brcmfmac: update beacon IE after bss up and clear when AP stopped
--
https://patchwork.kernel.org/patch/9435643/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable
From: Kalle Valo @ 2016-11-23 15:36 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Amitkumar Karwar, Arnd Bergmann, linux-wireless,
Nishant Sarmukadam, Zhaoyang Liu, Bing Zhao, Xinming Hu,
Avinash Patil
In-Reply-To: <ad72403d4d99a1b13ea7f99b0ea992b23aa2ea09.1479458373.git.kirtika@google.com>
Kirtika Ruchandani <kirtika.ruchandani@gmail.com> wrote:
> Commit bec568ff5107 removed the last remaining usage of struct
> mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to
> mwifiex_del_virtual_intf().
> Compiling mwifiex/ with W=1 gives the following warning, fix it.
> mwifiex/main.c: In function ‘mwifiex_fw_dpc’:
> mwifiex/main.c:520:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable]
>
> Fixes: bec568ff5107 ("mwifiex: failure path handling in mwifiex_add_virtual_intf()")
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
Failed to apply to wireless-drivers-next:
Applying: mwifiex: Remove unused 'pm_flag' variable
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/marvell/mwifiex/sdio.c
CONFLICT (content): Merge conflict in drivers/net/wireless/marvell/mwifiex/sdio.c
Failed to merge in the changes.
Patch failed at 0001 mwifiex: Remove unused 'pm_flag' variable
7 patches set to Changes Requested.
9435943 [1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable
9435945 [2/7] mwifiex: Remove unused 'chan_num' variable
9435947 [3/7] mwifiex: Remove unused 'sta_ptr' variable
9435949 [4/7] mwifiex: Remove unused 'adapter'variable
9435951 [5/7] mwifiex: Remove unused 'pm_flag' variable
9435953 [6/7] mwifiex: Removed unused 'pkt_type' variable
9435955 [7/7] mwifiex: Remove unused 'bcd_usb' variable
--
https://patchwork.kernel.org/patch/9435943/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2,1/9] rt2800: correctly report MCS TX parameters
From: Kalle Valo @ 2016-11-23 15:39 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin
In-Reply-To: <1479462241-9299-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> We should only set IEEE80211_HT_MCS_TX_RX_DIF when TX and RX MCS sets
> are not equal, i.e. when number of tx streams is different than
> number of RX streams.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
9 patches applied to wireless-drivers-next.git, thanks.
cea5b03d8a10 rt2800: correctly report MCS TX parameters
b29a1c1f08f3 rt2800usb: do not wipe out USB_DMA_CFG settings
770e4b730a73 rt2800: OFDM rates are mandatory
b4c449b1b803 rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
be82de9d64e2 rt2800: correct AUTO_RSP_CFG
231aeca1e19e rt2800: correct TX_SW_CFG1 for 5592
6c40063d5a61 rt2800: use RTS/CTS protection instead of CTS-to-self
8d79b0078278 rt2800: tune *_PROT_CFG parameters
159a55a64d44 rt2800: disable CCK rates on HT
--
https://patchwork.kernel.org/patch/9436109/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmsmac: fix array out-of-bounds access in qm_log10
From: Kalle Valo @ 2016-11-23 15:47 UTC (permalink / raw)
To: Tobias Regnery
Cc: linux-wireless, arend.vanspriel, franky.lin, hante.meuleman,
brcm80211-dev-list.pdl, Tobias Regnery
In-Reply-To: <1479734949-6300-1-git-send-email-tobias.regnery@gmail.com>
Tobias Regnery <tobias.regnery@gmail.com> wrote:
> I get the following UBSAN warning during boot on my laptop:
>
> ================================================================================
> UBSAN: Undefined behaviour in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:280:21
> index 32 is out of range for type 's16 [32]'
> CPU: 0 PID: 879 Comm: NetworkManager Not tainted 4.9.0-rc4 #28
> Hardware name: LENOVO Lenovo IdeaPad N581/INVALID, BIOS 5ECN96WW(V9.01) 03/14/2013
> ffff8800b74a6478 ffffffff828e59d2 0000000041b58ab3 ffffffff8398330c
> ffffffff828e5920 ffff8800b74a64a0 ffff8800b74a6450 0000000000000020
> 1ffffffff845848c ffffed0016e94bf1 ffffffffc22c2460 000000006b9c0514
> Call Trace:
> [<ffffffff828e59d2>] dump_stack+0xb2/0x110
> [<ffffffff828e5920>] ? _atomic_dec_and_lock+0x150/0x150
> [<ffffffff82968c9d>] ubsan_epilogue+0xd/0x4e
> [<ffffffff82969875>] __ubsan_handle_out_of_bounds+0xfa/0x13e
> [<ffffffff8296977b>] ? __ubsan_handle_shift_out_of_bounds+0x241/0x241
> [<ffffffffc0d48379>] ? bcma_host_pci_read16+0x59/0xa0 [bcma]
> [<ffffffffc0d48388>] ? bcma_host_pci_read16+0x68/0xa0 [bcma]
> [<ffffffffc212ad78>] ? read_phy_reg+0xe8/0x180 [brcmsmac]
> [<ffffffffc2184714>] qm_log10+0x2e4/0x350 [brcmsmac]
> [<ffffffffc2142eb8>] wlc_phy_init_lcnphy+0x538/0x1f20 [brcmsmac]
> [<ffffffffc2142980>] ? wlc_lcnphy_periodic_cal+0x5c0/0x5c0 [brcmsmac]
> [<ffffffffc1ba0c93>] ? ieee80211_open+0xb3/0x110 [mac80211]
> [<ffffffff82f73a02>] ? sk_busy_loop+0x1e2/0x840
> [<ffffffff82f7a6ce>] ? __dev_change_flags+0xae/0x220
> ...
>
> The report is valid: doing the math in this function, with an input value
> N=63 the variable s16tableIndex gets a value of 31. This value is used as
> an index in the array log_table with 32 entries. But the next line is:
>
> s16errorApproximation = (s16) qm_mulu16(u16offset,
> (u16) (log_table[s16tableIndex + 1] -
> log_table[s16tableIndex]));
>
> With s16tableIndex + 1 we are trying an out-of-bounds access to the array.
>
> The log_table array provides log2 values in q.15 format and the above
> statement tries an error approximation with the next value. To fix this
> issue add the next value to the array and update the comment accordingly.
>
> Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com>
A note to myself: this patch seems to be corrupted in patchwork web interface,
need to check that when commiting the formatting is ok.
--
https://patchwork.kernel.org/patch/9439423/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: igor.mitsyanko.os @ 2016-11-23 16:45 UTC (permalink / raw)
To: linux-wireless
Cc: johannes, btherthala, hwang, smaksimenko, dlebed, Igor Mitsyanko,
Kamlesh Rath, Sergey Matyukevich, Avinash Patil, Igor Mitsyanko
In-Reply-To: <87d1hmnrqj.fsf@purkki.adurom.net>
From: Igor Mitsyanko <imitsyanko@quantenna.com>
QSR10G is Quantenna's 8x8, 160M, 11ac WiFi card.
Signed-off-by: Kamlesh Rath <krath@quantenna.com>
Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
Signed-off-by: Avinash Patil <avinashp@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
LICENCE.Quantenna_fmac | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
WHENCE | 9 ++++++
qtn/fmac_qsr10g.img | Bin 0 -> 9559676 bytes
3 files changed, 83 insertions(+)
create mode 100644 LICENCE.Quantenna_fmac
create mode 100644 qtn/fmac_qsr10g.img
diff --git a/LICENCE.Quantenna_fmac b/LICENCE.Quantenna_fmac
new file mode 100644
index 0000000..e6f9f72
--- /dev/null
+++ b/LICENCE.Quantenna_fmac
@@ -0,0 +1,74 @@
+Copyright (c) 2016, Quantenna, Inc.
+All rights reserved.
+
+Redistribution. Reproduction and redistribution in binary form, without
+modification, for use solely in conjunction with a Quantenna, Inc. chipset, is
+permitted provided that the following conditions are met:
+
+ - Redistributions must reproduce the above copyright notice and the
+ following disclaimer in the documentation and/or other materials provided
+ with the distribution.
+
+ - Neither the name of Quantenna, Inc. nor the names of its suppliers may be
+ used to endorse or promote products derived from this Software without
+ specific prior written permission.
+
+ - No reverse engineering, decompilation, or disassembly of this Software is
+ permitted, except and solely to the extent that such a restriction is
+ impermissible pursuant to applicable law or third party license.
+
+ - Your reproduction and distribution must comply with all applicable laws,
+ including without limitation all applicable U.S., European, and other
+ export laws.
+
+Limited Patent License. Subject to your compliance with all terms of this
+license, Quantenna, Inc. (“Licensor”) grants you (“Licensee”) a limited,
+worldwide, royalty-free, non-exclusive license under the Licensed Patents to
+make, have made, use, import, offer to sell and sell the Software solely in
+conjunction with a validly purchased Quantenna, Inc. chipset. No hardware
+per se is licensed hereunder.
+
+The term “Licensed Patents” as used in this agreement means only those patents
+or patent applications owned solely and exclusively by Licensor as of the date
+of Licensor’s submission of the Software that would necessarily be infringed by
+the operation of the Software, alone, or in combination with a supported
+version of the Linux operating system. The patent license shall not apply to
+any other combinations which include the Software. The term “Licensed Patents”
+expressly excludes any patent or patent application owned by any current or
+future affiliate of Quantenna, Inc. The term “Software” as used in this
+agreement means the unmodified firmware image submitted by Licensor, under the
+terms of this license, to
+git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git.
+
+Notwithstanding anything to the contrary herein, Licensor does not grant and
+Licensee does not receive, by virtue of this agreement or the Licensor’s
+submission of any Software, any license or other rights under any patent or
+patent application owned by any current or future affiliate of Licensor or any
+other entity (other than Licensor), whether expressly, impliedly, by virtue of
+estoppel or exhaustion, or otherwise. If Licensee has a separate agreement with
+Licensor covering use of the Software, then that separate agreement shall
+control.
+
+Open Source Software. The Software may include components that are licensed
+pursuant to open source software (“Open Source Components”). Information
+regarding the Open Source Components included with the Software is available
+upon request to oslegal@quantenna.com. To the extent such Open Source
+Components are required to be licensed to you under the terms of a separate
+license (such as an open source license) then such other terms shall apply, and
+nothing herein shall be deemed or interpreted to limit any rights you may have
+under any such applicable license.
+
+DISCLAIMER. THIS SOFTWARE (INCLUDING ANY APPLICABLE OPEN SOURCE COMPONENTS) IS
+PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFREINGEMENT ARE
+EXPRESSLY DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNERS, AUTHORS, OR
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
+OF SUCH DAMAGE, AND REGARDLESS OF ANY FAILURE OF ESSENTIAL PURPOSE OF ANY
+LIMITED REMEDY PROVIDED HEREIN.
+
diff --git a/WHENCE b/WHENCE
index 534c2da..78f6b73 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3347,3 +3347,12 @@ File: rockchip/dptx.bin
Version: 2.9
Licence: Redistributable. See LICENCE.rockchip for details.
+
+--------------------------------------------------------------------------
+
+Driver: qtnfmac - FullMAC driver for Quantenna QSR10G wireless card
+
+File: qtn/fmac_qsr10g.img
+
+Licence: Redistributable. See LICENCE.Quantenna_fmac for details.
+
diff --git a/qtn/fmac_qsr10g.img b/qtn/fmac_qsr10g.img
new file mode 100644
index 0000000..a65e6ec
Binary files /dev/null and b/qtn/fmac_qsr10g.img differ
--
2.7.4
^ permalink raw reply related
* Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: IgorMitsyanko @ 2016-11-23 17:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, linux-wireless, btherthala, hwang, smaksimenko,
dlebed, Igor Mitsyanko, Kamlesh Rath, Sergey Matyukevich,
Avinash Patil, Ben Hutchings, Kyle McMartin
In-Reply-To: <87d1hmnrqj.fsf@purkki.adurom.net>
On 11/23/2016 06:25 PM, Kalle Valo wrote:
> IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
>
>> To clarify with you and Kalle, as persons involved with
>> linux-wireless: is my understanding correct that submitting firmware
>> into linux-fimware repository is a prerequisite to accepting new
>> driver into linux-wireless?
> In my opinion the most important is that the device is usable with an
> upstream driver so that anyone can start using the driver (if they have
> the hardware).
>
>> There is an option to start Quantenna device from internal flash
>> memory, no external binary files involved. If we will introduce this
>> functionality and remove code handling external firmware for now
>> (until firmware problem resolved), would that allow driver to be
>> reviewed/accepted?
> Do all the publically available hardware contain the firmware in
> internal flash (flashed in the factory)? Or is this something which must
> be installed separately for each board's internal flash by the user?
Each board must have flash installed on it, preflashed in the factory
with uboot and firmware binary, otherwise board won't boot (won't boot
without uboot, firmware itself is not mandatory).
Booting from flash is default behavior on boards that are currently on
the market, but for developemnt purpuses it's not very convenient and
harder to upgrade.
>
> BTW, the original mail with the firmware image didn't make it to the
> list, I guess it was too big? It would be good if you could post the
> license separately so that people can see it.
>
I resent the email without binary patch to linux-wireless. Yes, it was
big, I guess next time we better use pull requests on github.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Kalle Valo @ 2016-11-23 19:26 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Andrew Lunn
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
Jason Cooper <jason@lakedaemon.net> writes:
> All,
>
> I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> board (Marvell Armada 370 SoC). Every day or so I get a consistent
> crash that brings down the whole board. I've attached three oops I
> captured on the serial port.
>
> I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> at me as "this would fix it". And since it takes a day or so to trigger
> the oops, bisecting would be a bit brutal. Does anyone have any insight
> into this?
Is this a regression, meaning that it didn't crash on older kernels but
crashes on newer ones? Or has it always crashed?
--
Kalle Valo
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:15 UTC (permalink / raw)
To: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel
Cc: Kalle Valo, Thomas Petazzoni, Gregory CLEMENT, Andrew Lunn
All,
I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
board (Marvell Armada 370 SoC). Every day or so I get a consistent
crash that brings down the whole board. I've attached three oops I
captured on the serial port.
I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
at me as "this would fix it". And since it takes a day or so to trigger
the oops, bisecting would be a bit brutal. Does anyone have any insight
into this?
thx,
Jason.
------- oops from v4.2.8 ------------------------------------------
[ 3572.897994] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[ 3572.906134] pgd = c0004000
[ 3572.908891] [00000020] *pgd=00000000
[ 3572.912504] Internal error: Oops: 5 [#1] SMP ARM
[ 3572.917142] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge ipv6 ath9k ath9k_common ath9k_hw led_class ath
[ 3572.930749] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.2.8 #57
[ 3572.937915] Hardware name: Marvell Armada 370/XP (Device Tree)
[ 3572.943774] task: c06fdd30 ti: c06f8000 task.ti: c06f8000
[ 3572.949208] PC is at ath_cmn_process_fft+0xac/0x4a0 [ath9k_common]
[ 3572.955421] LR is at ath_cmn_process_fft+0xc8/0x4a0 [ath9k_common]
[ 3572.961631] pc : [<bf081f44>] lr : [<bf081f60>] psr: 80000153
[ 3572.961631] sp : c06f9ca0 ip : 00000000 fp : 00000000
[ 3572.973160] r10: dc9a8010 r9 : 00000000 r8 : c06fa4d0
[ 3572.978409] r7 : 0000006c r6 : dd3abfc0 r5 : c06fad88 r4 : 00000000
[ 3572.984965] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[ 3572.991522] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 3572.998951] Control: 10c5387d Table: 1c894019 DAC: 00000015
[ 3573.004723] Process swapper/0 (pid: 0, stack limit = 0xc06f8220)
[ 3573.010756] Stack: (0xc06f9ca0 to 0xc06fa000)
[ 3573.015137] 9ca0: c0734e31 dfbe3f40 c06f6f40 c06f6f40 c06fae34 c0734184 00989680 00000003
[ 3573.023356] 9cc0: dff6cde0 00000008 c06f9df4 00000069 dca0ab8c c0098b44 00000985 00000fc0
[ 3573.031573] 9ce0: c0733700 dffa0560 00000002 c001b6ac 000000c0 00000000 00000000 00000000
[ 3573.039790] 9d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.048006] 9d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.056222] 9d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.064438] 9d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dc9a8010
[ 3573.072654] 9d80: 00000000 dc983d18 dc983d00 dc983d00 00000002 dd045c90 dca08d40 bf090e64
[ 3573.080872] 9da0: d364463c 00000000 edf3c980 0000033f 0000033f 000001fa dc9a8010 00000000
[ 3573.089090] 9dc0: d3644890 00000000 dc9a8038 dca083e0 dd3abfc0 00000000 dd3abfc0 dca097ac
[ 3573.097306] 9de0: dc9a8038 00000002 00000001 dca083e0 00000100 d364463c 2602006c 018eff80
[ 3573.105522] 9e00: 80808000 00808080 20000001 00000000 00000000 00000000 00000000 00000000
[ 3573.113739] 9e20: 00000000 00000000 c06f9e68 dca08d40 00000001 dc9a8010 dca09708 c06f9e68
[ 3573.121955] 9e40: c06f4294 c06f8000 00000006 bf08e698 bf08e5dc dca096d0 dca096d4 00000000
[ 3573.130172] 9e60: c0735bc0 c0027e4c 00000000 c06fa098 00000100 c06f8000 c06f9e88 40000006
[ 3573.138389] 9e80: c06fa080 c0028030 ed5b3300 0000033f c06fa080 c06f4308 0000000a c0735bc0
[ 3573.146606] 9ea0: c06fa100 0004fe8e c051e380 00200000 c06f8000 c06f5444 00000000 00000000
[ 3573.154823] 9ec0: 00000001 df405000 c06fa484 c0759f80 c06f8000 c00283d8 c06f5444 c005b838
[ 3573.163041] 9ee0: c0341814 00000001 c0759f80 c06f9f20 000003ff c0009410 c034180c c0341814
[ 3573.171257] 9f00: 80000153 ffffffff c06f9f54 ed5b20c4 0000033f ed5b20c4 c06f8000 c0013340
[ 3573.179474] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.187691] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.195908] 9f60: 80000153 ffffffff 00000000 00000000 ed5b20c4 0000033f dfbe34d0 c051e374
[ 3573.204125] 9f80: dfbe34d0 c072a608 c06f64c8 c06fa51c c06f4364 c06fa524 c06f8000 c00535ec
[ 3573.212343] 9fa0: c06f9fa0 c0734dd1 dfffce00 ffffffff dfffce00 c06b5c6c ffffffff ffffffff
[ 3573.220559] 9fc0: 00000000 c06b5670 00000000 c06ea990 00000000 c0735294 c06fa4c0 c06ea98c
[ 3573.228777] 9fe0: c06fee2c 00004059 561f5811 00000000 00000000 0000807c 00000000 00000000
[ 3573.237025] [<bf081f44>] (ath_cmn_process_fft [ath9k_common]) from [<bf090e64>] (ath_rx_tasklet+0xa14/0xafc [ath9k])
[ 3573.247613] [<bf090e64>] (ath_rx_tasklet [ath9k]) from [<bf08e698>] (ath9k_tasklet+0xbc/0x20c [ath9k])
[ 3573.256981] [<bf08e698>] (ath9k_tasklet [ath9k]) from [<c0027e4c>] (tasklet_action+0x7c/0x110)
[ 3573.265641] [<c0027e4c>] (tasklet_action) from [<c0028030>] (__do_softirq+0xf8/0x23c)
[ 3573.273513] [<c0028030>] (__do_softirq) from [<c00283d8>] (irq_exit+0x78/0xb0)
[ 3573.280778] [<c00283d8>] (irq_exit) from [<c005b838>] (__handle_domain_irq+0x60/0xb0)
[ 3573.288651] [<c005b838>] (__handle_domain_irq) from [<c0009410>] (armada_370_xp_handle_irq+0x50/0xbc)
[ 3573.297917] [<c0009410>] (armada_370_xp_handle_irq) from [<c0013340>] (__irq_svc+0x40/0x54)
[ 3573.306306] Exception stack(0xc06f9f20 to 0xc06f9f68)
[ 3573.311385] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.319602] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.327816] 9f60: 80000153 ffffffff
[ 3573.331331] [<c0013340>] (__irq_svc) from [<c0341814>] (cpuidle_enter_state+0xdc/0x248)
[ 3573.339385] [<c0341814>] (cpuidle_enter_state) from [<c00535ec>] (cpu_startup_entry+0x170/0x234)
[ 3573.348218] [<c00535ec>] (cpu_startup_entry) from [<c06b5c6c>] (start_kernel+0x3b0/0x3bc)
[ 3573.356436] Code: e59c9004 e3e0b000 e5938000 ea000002 (e7990102)
[ 3573.362634] ---[ end trace 47b32564cd3160db ]---
[ 3573.367281] Kernel panic - not syncing: Fatal exception in interrupt
[ 3573.373667] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 ---------------------------------------------
[231233.388543] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[231233.396804] pgd = c0004000
[231233.399614] [00000020] *pgd=00000000
[231233.403311] Internal error: Oops: 17 [#1] SMP ARM
[231233.408124] Modules linked in: ath9k ath9k_common ath9k_hw ath
[231233.414132] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[231233.420165] Hardware name: Marvell Armada 370/XP (Device Tree)
[231233.426111] task: c0b091c0 task.stack: c0b00000
[231233.430760] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[231233.437060] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[231233.443357] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[231233.443357] sp : c0b01cd0 ip : 00000000 fp : 00000000
[231233.455059] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[231233.460394] r7 : 00000000 r6 : dbef9440 r5 : c0b03da0 r4 : 00000000
[231233.467037] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[231233.473682] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[231233.481023] Control: 10c5387d Table: 1e614019 DAC: 00000051
[231233.486882] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[231233.493001] Stack: (0xc0b01cd0 to 0xc0b02000)
[231233.497466] 1cc0: fffffffa 3b9ac9ff 003c8995 c0b44d30
[231233.505770] 1ce0: dda18010 00000000 c0b01e14 c017ad48 ffffffff dee1ac84 c0b44d30 c0b44b00
[231233.514073] 1d00: 0000099e 00000440 0001bef9 c01176f4 00000002 00000786 00000000 00000000
[231233.522377] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.530680] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.538984] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.547287] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.555591] 1da0: dda18010 dda18010 00000000 defaa3d8 defaa3c0 defaa3c0 dee18e40 de5b4a18
[231233.563895] 1dc0: dda18010 bf08a9d0 071a3710 00000056 00989680 00000000 071a393a 00000056
[231233.572199] 1de0: 000001fb dee18440 00000000 dbef9440 dee198b0 00000014 dda18038 dee1a97c
[231233.580504] 1e00: dbef9440 00000002 00000001 dee18440 0036f478 071a3710 2422006c 018fff07
[231233.588807] 1e20: 80252900 01168e85 40000000 00000000 00000000 00000000 00000000 00000000
[231233.597110] 1e40: 00000000 00000000 c0a4a2c0 dee18e40 dda18010 dee19808 00000001 c0b00000
[231233.605414] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee197d0 dee197d4 00000000 c0b01e88
[231233.613717] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[231233.622021] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 0160605b
[231233.630324] 1ec0: c0b02100 00200100 df488a20 c0a4d500 00000000 00000000 00000001 df405000
[231233.638629] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[231233.646933] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[231233.655236] 1f20: 0028571c c0b00000 00000000 c010bd8c 00000000 0000d24e 1f194000 dfbe31c0
[231233.663540] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.671843] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[231233.680148] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[231233.688452] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[231233.696756] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[231233.705059] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[231233.713401] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[231233.724079] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[231233.733623] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[231233.742367] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[231233.750324] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[231233.757678] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[231233.765637] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[231233.774989] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[231233.783463] Exception stack(0xc0b01f30 to 0xc0b01f78)
[231233.788625] 1f20: 00000000 0000d24e 1f194000 dfbe31c0
[231233.796930] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.805232] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[231233.811974] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[231233.820202] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[231233.829124] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[231233.837430] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[231233.843714] ---[ end trace 0a5139f91be0a117 ]---
[231233.848460] Kernel panic - not syncing: Fatal exception in interrupt
[231233.854937] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 #2 ------------------------------------------
[42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[42059.311799] pgd = c0004000
[42059.314522] [00000020] *pgd=00000000
[42059.318162] Internal error: Oops: 17 [#1] SMP ARM
[42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
[42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
[42059.340613] task: c0b091c0 task.stack: c0b00000
[42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
[42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
[42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[42059.387487] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[42059.394741] Control: 10c5387d Table: 1ef48019 DAC: 00000051
[42059.400513] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[42059.406545] Stack: (0xc0b01cd0 to 0xc0b02000)
[42059.410924] 1cc0: fffffffa 3b9ac9ff 0047c6ce c0b44d30
[42059.419141] 1ce0: de6a0010 00000000 c0b01e14 c017ad48 ffffffff dee0ac84 c0b44d30 c0b44b00
[42059.427357] 1d00: 0000099e 00000340 0001cfbd c01176f4 00000002 00000786 00000080 00000000
[42059.435573] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.443789] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.452005] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.460220] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.468437] 1da0: de6a0010 de6a0010 00000000 deec5b58 deec5b40 deec5b40 dee08e40 de631ff0
[42059.476653] 1dc0: de6a0010 bf08a9d0 8918a8c8 00000002 00000000 00000000 8918aaa1 00000002
[42059.484869] 1de0: 00000200 dee08440 00000000 dcfbd340 dee098b0 00000014 de6a0038 dee0a97c
[42059.493085] 1e00: dcfbd340 00000002 00000001 dee08440 00fc2540 8918a8c8 0502006c 018e026c
[42059.501301] 1e20: 80202600 016d5ab7 40000100 00000000 00000000 00000000 00000000 00000000
[42059.509518] 1e40: 00000000 00000000 c0a4a2c0 dee08e40 de6a0010 dee09808 00000001 c0b00000
[42059.517734] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee097d0 dee097d4 00000000 c0b01e88
[42059.525950] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[42059.534166] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 003fb83a
[42059.542382] 1ec0: c0b02100 00200100 df486a20 c0a4d500 00000000 00000000 00000001 df405000
[42059.550599] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[42059.558816] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[42059.567031] 1f20: 006895c7 c0b00000 00000000 c010bd8c 00000000 00002640 1f194000 dfbe31c0
[42059.575248] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.583464] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[42059.591681] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[42059.599897] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[42059.608114] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[42059.616330] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[42059.624586] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[42059.635176] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[42059.644631] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[42059.653288] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[42059.661157] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[42059.668423] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[42059.676295] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[42059.685559] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[42059.693946] Exception stack(0xc0b01f30 to 0xc0b01f78)
[42059.699021] 1f20: 00000000 00002640 1f194000 dfbe31c0
[42059.707237] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.715453] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[42059.722107] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[42059.730247] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[42059.739081] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[42059.747299] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[42059.753488] ---[ end trace d9b5665c4c165fb1 ]---
[42059.758151] Kernel panic - not syncing: Fatal exception in interrupt
[42059.764541] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCHv3,1/2] ath10k: add per peer htt tx stats support for 10.4
From: Kalle Valo @ 2016-11-23 19:40 UTC (permalink / raw)
To: akolli; +Cc: ath10k, Anilkumar Kolli, akolli, linux-wireless
In-Reply-To: <1479227849-10042-1-git-send-email-akolli@qti.qualcomm.com>
akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
>
> Parse peer stats and update the tx rate information per STA.
>
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
2 patches applied to ath-next branch of ath.git, thanks.
cec17c382140 ath10k: add per peer htt tx stats support for 10.4
5608eaf7b086 ath10k: add support for per sta tx bitrate
--
https://patchwork.kernel.org/patch/9430197/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: fix monitor vdev for receiving other bss frames
From: Kalle Valo @ 2016-11-23 19:42 UTC (permalink / raw)
To: Manoharan, Rajkumar; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <1479510658-8326-1-git-send-email-rmanohar@qca.qualcomm.com>
"Manoharan, Rajkumar" <rmanohar@qca.qualcomm.com> wrote:
> In order to receive other BSS entries in mesh mode, Monitor vdev
> is created whenever filter flag is set with OTHER_BSS. Recently
> it is root caused that setting promisc filter for Mesh interface
> is causing performance and stability issues. To fix this issue,
> firmware will configure appropriate rxfilters by default for mesh
> vdev during vdev creation. This change fixes monitor vdev creation
> based on firmware IE
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
705d7aa06220 ath10k: fix monitor vdev for receiving other bss frames
--
https://patchwork.kernel.org/patch/9437519/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:34 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Andrew Lunn
In-Reply-To: <87a8cqgfpp.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
On Wed, Nov 23, 2016 at 09:26:42PM +0200, Kalle Valo wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> > I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> > board (Marvell Armada 370 SoC). Every day or so I get a consistent
> > crash that brings down the whole board. I've attached three oops I
> > captured on the serial port.
> >
> > I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> > at me as "this would fix it". And since it takes a day or so to trigger
> > the oops, bisecting would be a bit brutal. Does anyone have any insight
> > into this?
>
> Is this a regression, meaning that it didn't crash on older kernels but
> crashes on newer ones? Or has it always crashed?
iirc, it's always done this. It's one of my spare wifi backhauls that
spends most of it's time in a cardboard box waiting for a task,
collecting dust. Kinda like the toys in Toy Story.
I pulled it out a month or so ago and the behavior started. It had
4.2.8 on it at the time. I upgraded to latest stable a few weeks ago
(v4.8.6) and I'm getting the same issue.
When I originally set it up, it didn't run long enough for me to recall
if the issue occurred. Best I recall, that was with v4.2.8.
thx,
Jason.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 19:51 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> ------- oops from v4.8.6 #2 ------------------------------------------
> [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> [42059.311799] pgd = c0004000
> [42059.314522] [00000020] *pgd=00000000
> [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> [42059.340613] task: c0b091c0 task.stack: c0b00000
> [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
Well, the good news is that it's reproducable.
It looks like it could be this:
static int
ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
{
for_each_online_cpu(i)
ret += relay_buf_full(rc->buf[i]);
where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
there's precious little to go on with the Code: line - modern GCCs
don't give us much with the Code: line anymore to figure out what's
going on without the exact object files.
e5933000 ldr r3, [r3]
e1d330b4 ldrh r3, [r3, #4]
e58d3030 str r3, [sp, #48] ; 0x30
ea000002 b 1c <foo+0x1c>
e7970102 ldr r0, [r7, r2, lsl #2]
What makes me wonder though is that if i=8, that means you must have a
system with 9 online CPUs, which is probably unlikely - or maybe that's
the problem, for_each_online_cpu() is going wrong...
If it's not that line of code, I don't see what else it would be based
on the output of my compiler - there's only one case in my disassembly
that corresponds with the single code line that we have to go on, and
it's this:
a44: e5983020 ldr r3, [r8, #32]
a48: e793010a ldr r0, [r3, sl, lsl #2] <===
a4c: ebfffffe bl 0 <relay_buf_full>
a50: e0844000 add r4, r4, r0
a54: e59f9434 ldr r9, [pc, #1076]
a58: e28a2001 add r2, sl, #1
a5c: e3a01004 mov r1, #4
a60: e1a00009 mov r0, r9
a64: ebfffffe bl 0 <_find_next_bit_le>
a68: e5953000 ldr r3, [r5]
a6c: e1500003 cmp r0, r3
a70: e1a0a000 mov sl, r0
a74: bafffff2 blt a44 <ath_cmn_process_fft+0xa8>
I'm debating now about whether we need to dump more of the code in the
oops - both before and after the faulting instruction...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
Hi Russell,
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
ahhh, my config has NR_CPUS=4, this SoC is uniprocessor. I'm going to
give it a go with SMP=no. This config is a lightly modified
mvebu_v7_defconfig. However, NR_CPUS isn't set in mvebu_v7_defconfig.
Only in multi_v7_defconfig.
I suspect ath9k uses different logic for setting up the relay buffer(s)
than for the code you referenced.
If SMP=no fails to fail ( :-P ) then we'll know where to start digging.
thx,
Jason.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
>
> where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
> there's precious little to go on with the Code: line - modern GCCs
> don't give us much with the Code: line anymore to figure out what's
> going on without the exact object files.
>
> e5933000 ldr r3, [r3]
> e1d330b4 ldrh r3, [r3, #4]
> e58d3030 str r3, [sp, #48] ; 0x30
> ea000002 b 1c <foo+0x1c>
> e7970102 ldr r0, [r7, r2, lsl #2]
>
As requested on irc:
-------------->8--------------------------------------------------------
drivers/net/wireless/ath/ath9k/common-spectral.o: file format elf32-littlearm
Disassembly of section .text:
...
00000754 <ath_cmn_process_fft>:
754: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
758: e24dd0d4 sub sp, sp, #212 ; 0xd4
75c: e1a04002 mov r4, r2
760: e1a06001 mov r6, r1
764: e58d0024 str r0, [sp, #36] ; 0x24
768: e3a01000 mov r1, #0
76c: e58d2018 str r2, [sp, #24]
770: e28d0049 add r0, sp, #73 ; 0x49
774: e3a02087 mov r2, #135 ; 0x87
778: ebfffffe bl 0 <memset>
77c: e5d44007 ldrb r4, [r4, #7]
780: e20430fd and r3, r4, #253 ; 0xfd
784: e3530024 cmp r3, #36 ; 0x24
788: 13540005 cmpne r4, #5
78c: 13a04001 movne r4, #1
790: 03a04000 moveq r4, #0
794: 13a00000 movne r0, #0
798: 0a000001 beq 7a4 <ath_cmn_process_fft+0x50>
79c: e28dd0d4 add sp, sp, #212 ; 0xd4
7a0: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
7a4: e59d3018 ldr r3, [sp, #24]
7a8: e1d380b4 ldrh r8, [r3, #4]
7ac: e2489003 sub r9, r8, #3
7b0: e0863009 add r3, r6, r9
7b4: e5d30002 ldrb r0, [r3, #2]
7b8: e2000010 and r0, r0, #16
7bc: e21000ff ands r0, r0, #255 ; 0xff
7c0: 0afffff5 beq 79c <ath_cmn_process_fft+0x48>
7c4: e59d3024 ldr r3, [sp, #36] ; 0x24
7c8: e3005000 movw r5, #0
7cc: e3405000 movt r5, #0
7d0: e3e0b000 mvn fp, #0
7d4: e5932000 ldr r2, [r3]
7d8: e5937004 ldr r7, [r3, #4]
7dc: e5923438 ldr r3, [r2, #1080] ; 0x438
7e0: e58d2010 str r2, [sp, #16]
7e4: e5933000 ldr r3, [r3]
7e8: e1d330b4 ldrh r3, [r3, #4]
7ec: e58d3030 str r3, [sp, #48] ; 0x30
7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
7f4: e7970102 ldr r0, [r7, r2, lsl #2]
7f8: ebfffffe bl 0 <relay_buf_full>
7fc: e0844000 add r4, r4, r0
800: e300a000 movw sl, #0
804: e28b2001 add r2, fp, #1
808: e340a000 movt sl, #0
80c: e3a01004 mov r1, #4
810: e1a0000a mov r0, sl
814: ebfffffe bl 0 <_find_next_bit_le>
818: e5953000 ldr r3, [r5]
81c: e1500003 cmp r0, r3
820: e1a0b000 mov fp, r0
824: e2802008 add r2, r0, #8
828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
82c: e59a0000 ldr r0, [sl]
830: e200000f and r0, r0, #15
834: ebfffffe bl 0 <__sw_hweight32>
838: e1540000 cmp r4, r0
83c: 0a000092 beq a8c <ath_cmn_process_fft+0x338>
840: e59d3010 ldr r3, [sp, #16]
844: e5932030 ldr r2, [r3, #48] ; 0x30
848: e5923018 ldr r3, [r2, #24]
84c: e3530001 cmp r3, #1
850: 0a000090 beq a98 <ath_cmn_process_fft+0x344>
854: 3a000119 bcc cc0 <ath_cmn_process_fft+0x56c>
858: e3530002 cmp r3, #2
85c: 1a000110 bne ca4 <ath_cmn_process_fft+0x550>
860: e3003000 movw r3, #0
864: e5921014 ldr r1, [r2, #20]
868: e1a00003 mov r0, r3
86c: e592301c ldr r3, [r2, #28]
870: e3002000 movw r2, #0
874: e3a0b087 mov fp, #135 ; 0x87
878: e1a0c002 mov ip, r2
87c: e1a02000 mov r2, r0
880: e3402000 movt r2, #0
884: e58d2034 str r2, [sp, #52] ; 0x34
888: e1a0200c mov r2, ip
88c: e3a0a08a mov sl, #138 ; 0x8a
890: e3402000 movt r2, #0
894: e58d2044 str r2, [sp, #68] ; 0x44
898: e1d120b4 ldrh r2, [r1, #4]
89c: e3a01080 mov r1, #128 ; 0x80
8a0: e58d1020 str r1, [sp, #32]
8a4: e1520003 cmp r2, r3
8a8: 33a03003 movcc r3, #3
8ac: 23a03002 movcs r3, #2
8b0: e58d3038 str r3, [sp, #56] ; 0x38
8b4: e2483002 sub r3, r8, #2
8b8: e58d3014 str r3, [sp, #20]
8bc: e3530000 cmp r3, #0
8c0: da000071 ble a8c <ath_cmn_process_fft+0x338>
8c4: e3a03000 mov r3, #0
8c8: e28aa002 add sl, sl, #2
8cc: e1a04003 mov r4, r3
8d0: e58d3028 str r3, [sp, #40] ; 0x28
8d4: e1a05004 mov r5, r4
8d8: e24b3001 sub r3, fp, #1
8dc: e1a07006 mov r7, r6
8e0: e58d302c str r3, [sp, #44] ; 0x2c
8e4: e58db01c str fp, [sp, #28]
8e8: e1a03009 mov r3, r9
8ec: e58d8010 str r8, [sp, #16]
8f0: e1a09004 mov r9, r4
8f4: ea00002c b 9ac <ath_cmn_process_fft+0x258>
8f8: e3520007 cmp r2, #7
8fc: e1a05003 mov r5, r3
900: e086b004 add fp, r6, r4
904: 8a00006f bhi ac8 <ath_cmn_process_fft+0x374>
908: e59d202c ldr r2, [sp, #44] ; 0x2c
90c: e1530002 cmp r3, r2
910: a3a09001 movge r9, #1
914: ba0000dd blt c90 <ath_cmn_process_fft+0x53c>
918: e59d101c ldr r1, [sp, #28]
91c: e2812002 add r2, r1, #2
920: e1520005 cmp r2, r5
924: ba000058 blt a8c <ath_cmn_process_fft+0x338>
928: e1510005 cmp r1, r5
92c: aa000092 bge b7c <ath_cmn_process_fft+0x428>
930: e5d7001f ldrb r0, [r7, #31]
934: e5d71020 ldrb r1, [r7, #32]
938: e1500001 cmp r0, r1
93c: 1a000052 bne a8c <ath_cmn_process_fft+0x338>
940: e58d3040 str r3, [sp, #64] ; 0x40
944: e1a01004 mov r1, r4
948: e59d3044 ldr r3, [sp, #68] ; 0x44
94c: e1a0000b mov r0, fp
950: e58d203c str r2, [sp, #60] ; 0x3c
954: e12fff33 blx r3
958: e3500000 cmp r0, #0
95c: e59d203c ldr r2, [sp, #60] ; 0x3c
960: e59d3040 ldr r3, [sp, #64] ; 0x40
964: 1a00008e bne ba4 <ath_cmn_process_fft+0x450>
968: e59d2010 ldr r2, [sp, #16]
96c: e152000a cmp r2, sl
970: da0000c9 ble c9c <ath_cmn_process_fft+0x548>
974: e59d9028 ldr r9, [sp, #40] ; 0x28
978: e2842001 add r2, r4, #1
97c: e0867002 add r7, r6, r2
980: e3590000 cmp r9, #0
984: 13a09000 movne r9, #0
988: 1a000003 bne 99c <ath_cmn_process_fft+0x248>
98c: e59d2020 ldr r2, [sp, #32]
990: e2425002 sub r5, r2, #2
994: e0844005 add r4, r4, r5
998: e2842001 add r2, r4, #1
99c: e1a04002 mov r4, r2
9a0: e59d2014 ldr r2, [sp, #20]
9a4: e1540002 cmp r4, r2
9a8: aa000037 bge a8c <ath_cmn_process_fft+0x338>
9ac: e59d2010 ldr r2, [sp, #16]
9b0: e152000a cmp r2, sl
9b4: e7d62004 ldrb r2, [r6, r4]
9b8: daffffce ble 8f8 <ath_cmn_process_fft+0x1a4>
9bc: e3520007 cmp r2, #7
9c0: e2855001 add r5, r5, #1
9c4: e086b004 add fp, r6, r4
9c8: 8a000002 bhi 9d8 <ath_cmn_process_fft+0x284>
9cc: e59d202c ldr r2, [sp, #44] ; 0x2c
9d0: e1550002 cmp r5, r2
9d4: aaffffcf bge 918 <ath_cmn_process_fft+0x1c4>
9d8: e3590000 cmp r9, #0
9dc: 0affffed beq 998 <ath_cmn_process_fft+0x244>
9e0: e59d201c ldr r2, [sp, #28]
9e4: e1520005 cmp r2, r5
9e8: 1affffe1 bne 974 <ath_cmn_process_fft+0x220>
9ec: ea00007e b bec <ath_cmn_process_fft+0x498>
9f0: e597e000 ldr lr, [r7]
9f4: e24b201f sub r2, fp, #31
9f8: e597c004 ldr ip, [r7, #4]
9fc: e2871021 add r1, r7, #33 ; 0x21
a00: e5973008 ldr r3, [r7, #8]
a04: e28d0068 add r0, sp, #104 ; 0x68
a08: e58de049 str lr, [sp, #73] ; 0x49
a0c: e58dc04d str ip, [sp, #77] ; 0x4d
a10: e597e010 ldr lr, [r7, #16]
a14: e597c014 ldr ip, [r7, #20]
a18: e58d3051 str r3, [sp, #81] ; 0x51
a1c: e597300c ldr r3, [r7, #12]
a20: e58de059 str lr, [sp, #89] ; 0x59
a24: e58dc05d str ip, [sp, #93] ; 0x5d
a28: e58d3055 str r3, [sp, #85] ; 0x55
a2c: e1d7c1bc ldrh ip, [r7, #28]
a30: e5973018 ldr r3, [r7, #24]
a34: e5d7e01f ldrb lr, [r7, #31]
a38: e1cdc6b5 strh ip, [sp, #101] ; 0x65
a3c: e58d3061 str r3, [sp, #97] ; 0x61
a40: e5cde067 strb lr, [sp, #103] ; 0x67
a44: ebfffffe bl 0 <memcpy>
a48: e59d3038 ldr r3, [sp, #56] ; 0x38
a4c: e59d1024 ldr r1, [sp, #36] ; 0x24
a50: e59d0018 ldr r0, [sp, #24]
a54: e58d300c str r3, [sp, #12]
a58: e59d3030 ldr r3, [sp, #48] ; 0x30
a5c: e58d3008 str r3, [sp, #8]
a60: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
a64: e1cd20f0 strd r2, [sp]
a68: e28d2049 add r2, sp, #73 ; 0x49
a6c: e59d3034 ldr r3, [sp, #52] ; 0x34
a70: e12fff33 blx r3
a74: e3a01087 mov r1, #135 ; 0x87
a78: e28d0049 add r0, sp, #73 ; 0x49
a7c: ebfffffe bl 0 <__memzero>
a80: e59d1020 ldr r1, [sp, #32]
a84: e28d0049 add r0, sp, #73 ; 0x49
a88: ebfffffe bl 0 <add_device_randomness>
a8c: e3a00001 mov r0, #1
a90: e28dd0d4 add sp, sp, #212 ; 0xd4
a94: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
a98: e58d3038 str r3, [sp, #56] ; 0x38
a9c: e3003000 movw r3, #0
aa0: e3002000 movw r2, #0
aa4: e3403000 movt r3, #0
aa8: e3402000 movt r2, #0
aac: e58d3034 str r3, [sp, #52] ; 0x34
ab0: e3a0b03c mov fp, #60 ; 0x3c
ab4: e3a03038 mov r3, #56 ; 0x38
ab8: e58d2044 str r2, [sp, #68] ; 0x44
abc: e3a0a03f mov sl, #63 ; 0x3f
ac0: e58d3020 str r3, [sp, #32]
ac4: eaffff7a b 8b4 <ath_cmn_process_fft+0x160>
ac8: e59db01c ldr fp, [sp, #28]
acc: e153000b cmp r3, fp
ad0: 0a00005e beq c50 <ath_cmn_process_fft+0x4fc>
ad4: e06b5005 rsb r5, fp, r5
ad8: e2855001 add r5, r5, #1
adc: e3550003 cmp r5, #3
ae0: 979ff105 ldrls pc, [pc, r5, lsl #2]
ae4: eaffffd7 b a48 <ath_cmn_process_fft+0x2f4>
ae8: 00000b0c andeq r0, r0, ip, lsl #22
aec: 00000af8 strdeq r0, [r0], -r8
af0: 00000b20 andeq r0, r0, r0, lsr #22
af4: 000009f0 strdeq r0, [r0], -r0 ; <UNPREDICTABLE>
af8: e1a0200b mov r2, fp
afc: e1a01007 mov r1, r7
b00: e28d0049 add r0, sp, #73 ; 0x49
b04: ebfffffe bl 0 <memcpy>
b08: eaffffce b a48 <ath_cmn_process_fft+0x2f4>
b0c: e24b2001 sub r2, fp, #1
b10: e1a01007 mov r1, r7
b14: e28d004a add r0, sp, #74 ; 0x4a
b18: ebfffffe bl 0 <memcpy>
b1c: eaffffc9 b a48 <ath_cmn_process_fft+0x2f4>
b20: e597e000 ldr lr, [r7]
b24: e24b2020 sub r2, fp, #32
b28: e597c004 ldr ip, [r7, #4]
b2c: e2871021 add r1, r7, #33 ; 0x21
b30: e5973008 ldr r3, [r7, #8]
b34: e28d0069 add r0, sp, #105 ; 0x69
b38: e58de04a str lr, [sp, #74] ; 0x4a
b3c: e58dc04e str ip, [sp, #78] ; 0x4e
b40: e597e010 ldr lr, [r7, #16]
b44: e597c014 ldr ip, [r7, #20]
b48: e58d3052 str r3, [sp, #82] ; 0x52
b4c: e597300c ldr r3, [r7, #12]
b50: e58de05a str lr, [sp, #90] ; 0x5a
b54: e58dc05e str ip, [sp, #94] ; 0x5e
b58: e5d7e01f ldrb lr, [r7, #31]
b5c: e1d7c1bc ldrh ip, [r7, #28]
b60: e58d3056 str r3, [sp, #86] ; 0x56
b64: e5973018 ldr r3, [r7, #24]
b68: e1cdc6b6 strh ip, [sp, #102] ; 0x66
b6c: e5cde068 strb lr, [sp, #104] ; 0x68
b70: e58d3062 str r3, [sp, #98] ; 0x62
b74: ebfffffe bl 0 <memcpy>
b78: eaffffb2 b a48 <ath_cmn_process_fft+0x2f4>
b7c: e58d3040 str r3, [sp, #64] ; 0x40
b80: e1a01004 mov r1, r4
b84: e59d3044 ldr r3, [sp, #68] ; 0x44
b88: e1a0000b mov r0, fp
b8c: e58d203c str r2, [sp, #60] ; 0x3c
b90: e12fff33 blx r3
b94: e3500000 cmp r0, #0
b98: e59d203c ldr r2, [sp, #60] ; 0x3c
b9c: e59d3040 ldr r3, [sp, #64] ; 0x40
ba0: 0a00000e beq be0 <ath_cmn_process_fft+0x48c>
ba4: e5d7101f ldrb r1, [r7, #31]
ba8: e5d70020 ldrb r0, [r7, #32]
bac: e59dc01c ldr ip, [sp, #28]
bb0: e15c0005 cmp ip, r5
bb4: d1510000 cmple r1, r0
bb8: 03a01001 moveq r1, #1
bbc: 13a01000 movne r1, #0
bc0: e1520005 cmp r2, r5
bc4: d3a02000 movle r2, #0
bc8: c2012001 andgt r2, r1, #1
bcc: e3520000 cmp r2, #0
bd0: 0a00001a beq c40 <ath_cmn_process_fft+0x4ec>
bd4: e5db2001 ldrb r2, [fp, #1]
bd8: e3520007 cmp r2, #7
bdc: 9affff6d bls 998 <ath_cmn_process_fft+0x244>
be0: e59d201c ldr r2, [sp, #28]
be4: e1520005 cmp r2, r5
be8: 1affff5e bne 968 <ath_cmn_process_fft+0x214>
bec: e58d303c str r3, [sp, #60] ; 0x3c
bf0: e1a02007 mov r2, r7
bf4: e59d3038 ldr r3, [sp, #56] ; 0x38
bf8: e1cd8fd8 ldrd r8, [sp, #248] ; 0xf8
bfc: e59d1024 ldr r1, [sp, #36] ; 0x24
c00: e58d300c str r3, [sp, #12]
c04: e59d3030 ldr r3, [sp, #48] ; 0x30
c08: e1cd80f0 strd r8, [sp]
c0c: e59d0018 ldr r0, [sp, #24]
c10: e58d3008 str r3, [sp, #8]
c14: e59d3034 ldr r3, [sp, #52] ; 0x34
c18: e12fff33 blx r3
c1c: e58d0028 str r0, [sp, #40] ; 0x28
c20: e1a00007 mov r0, r7
c24: e59d1020 ldr r1, [sp, #32]
c28: ebfffffe bl 0 <add_device_randomness>
c2c: e59d3010 ldr r3, [sp, #16]
c30: e153000a cmp r3, sl
c34: e59d303c ldr r3, [sp, #60] ; 0x3c
c38: caffff4d bgt 974 <ath_cmn_process_fft+0x220>
c3c: eaffff92 b a8c <ath_cmn_process_fft+0x338>
c40: e59d202c ldr r2, [sp, #44] ; 0x2c
c44: e1520005 cmp r2, r5
c48: 1affffe4 bne be0 <ath_cmn_process_fft+0x48c>
c4c: eaffffe0 b bd4 <ath_cmn_process_fft+0x480>
c50: e59d3038 ldr r3, [sp, #56] ; 0x38
c54: e59d1024 ldr r1, [sp, #36] ; 0x24
c58: e59d0018 ldr r0, [sp, #24]
c5c: e58d300c str r3, [sp, #12]
c60: e59d3030 ldr r3, [sp, #48] ; 0x30
c64: e58d3008 str r3, [sp, #8]
c68: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
c6c: e1cd20f0 strd r2, [sp]
c70: e1a02007 mov r2, r7
c74: e59d3034 ldr r3, [sp, #52] ; 0x34
c78: e12fff33 blx r3
c7c: e1a00007 mov r0, r7
c80: e59d1020 ldr r1, [sp, #32]
c84: ebfffffe bl 0 <add_device_randomness>
c88: e3a00001 mov r0, #1
c8c: eaffff7f b a90 <ath_cmn_process_fft+0x33c>
c90: e59d201c ldr r2, [sp, #28]
c94: e1530002 cmp r3, r2
c98: 0affffd3 beq bec <ath_cmn_process_fft+0x498>
c9c: e59db01c ldr fp, [sp, #28]
ca0: eaffff8b b ad4 <ath_cmn_process_fft+0x380>
ca4: e3000000 movw r0, #0
ca8: e300119a movw r1, #410 ; 0x19a
cac: e3400000 movt r0, #0
cb0: e3a03000 mov r3, #0
cb4: e58d3038 str r3, [sp, #56] ; 0x38
cb8: ebfffffe bl 0 <warn_slowpath_null>
cbc: eaffff76 b a9c <ath_cmn_process_fft+0x348>
cc0: e3a03000 mov r3, #0
cc4: e58d3038 str r3, [sp, #56] ; 0x38
cc8: eaffff73 b a9c <ath_cmn_process_fft+0x348>
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 21:17 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123205917.GI2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> As requested on irc:
Thanks.
> 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> 7f8: ebfffffe bl 0 <relay_buf_full>
> 7fc: e0844000 add r4, r4, r0
> 800: e300a000 movw sl, #0
> 804: e28b2001 add r2, fp, #1
> 808: e340a000 movt sl, #0
> 80c: e3a01004 mov r1, #4
> 810: e1a0000a mov r0, sl
> 814: ebfffffe bl 0 <_find_next_bit_le>
> 818: e5953000 ldr r3, [r5]
> 81c: e1500003 cmp r0, r3
> 820: e1a0b000 mov fp, r0
> 824: e2802008 add r2, r0, #8
> 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
Okay, so i was 0, so running UP probably isn't going to help. r7 is
also spec_priv->rfs_chan_spec_scan.
So, I think the question is... how is this NULL - and has it always
been NULL...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 21:40 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123211745.GF14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 09:17:45PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> > As requested on irc:
>
> Thanks.
>
> > 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> > 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> > 7f8: ebfffffe bl 0 <relay_buf_full>
> > 7fc: e0844000 add r4, r4, r0
> > 800: e300a000 movw sl, #0
> > 804: e28b2001 add r2, fp, #1
> > 808: e340a000 movt sl, #0
> > 80c: e3a01004 mov r1, #4
> > 810: e1a0000a mov r0, sl
> > 814: ebfffffe bl 0 <_find_next_bit_le>
> > 818: e5953000 ldr r3, [r5]
> > 81c: e1500003 cmp r0, r3
> > 820: e1a0b000 mov fp, r0
> > 824: e2802008 add r2, r0, #8
> > 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
>
> Okay, so i was 0, so running UP probably isn't going to help. r7 is
> also spec_priv->rfs_chan_spec_scan.
>
> So, I think the question is... how is this NULL - and has it always
> been NULL...
The problem appears to be that ath_cmn_process_fft() isn't called that
often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
without crashing, I'll gin up a patch.
thx,
Jason.
^ permalink raw reply
* [PATCH 1/2] nl80211: Use different attrs for BSSID and random MAC addr in scan req
From: Jouni Malinen @ 2016-11-23 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Vamsi Krishna, Jouni Malinen
From: Vamsi Krishna <vamsin@qti.qualcomm.com>
NL80211_ATTR_MAC was used to set both the specific BSSID to be scanned
and the random MAC address to be used when privacy is enabled. When both
the features are enabled, both the BSSID and the local MAC address were
getting same value causing Probe Request frames to go with unintended
DA. Hence, this has been fixed by using a different NL80211_ATTR_BSSID
attribute to set the specific BSSID (which was the more recent addition
in cfg80211) for a scan.
Backwards compatibility with old userspace software is maintained to
some extend by allowing NL80211_ATTR_MAC to be used to set the specific
BSSID when scanning without enabling random MAC address use.
Scanning with random source MAC address was introduced by commit
ad2b26abc157 ("cfg80211: allow drivers to support random MAC addresses
for scan") and the issue was introduced with the addition of the second
user for the same attribute in commit 818965d39177 ("cfg80211: Allow a
scan request for a specific BSSID").
Fixes: 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID")
Signed-off-by: Vamsi Krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/uapi/linux/nl80211.h | 8 +++++++-
net/wireless/nl80211.c | 16 +++++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 259c9c7..984a35ac 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -323,7 +323,7 @@
* @NL80211_CMD_GET_SCAN: get scan results
* @NL80211_CMD_TRIGGER_SCAN: trigger a new scan with the given parameters
* %NL80211_ATTR_TX_NO_CCK_RATE is used to decide whether to send the
- * probe requests at CCK rate or not. %NL80211_ATTR_MAC can be used to
+ * probe requests at CCK rate or not. %NL80211_ATTR_BSSID can be used to
* specify a BSSID to scan for; if not included, the wildcard BSSID will
* be used.
* @NL80211_CMD_NEW_SCAN_RESULTS: scan notification (as a reply to
@@ -1977,6 +1977,10 @@ enum nl80211_commands {
* @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Indicates whether or not multicast
* packets should be send out as unicast to all stations (flag attribute).
*
+ * @NL80211_ATTR_BSSID: The BSSID of the AP (various uses). Note that
+ * %NL80211_ATTR_MAC has also been used in various commands/events for
+ * specifying the BSSID.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2381,6 +2385,8 @@ enum nl80211_attrs {
NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED,
+ NL80211_ATTR_BSSID,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e4f718e..8db5cb1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -404,6 +404,7 @@ enum nl80211_multicast_groups {
.len = FILS_MAX_KEK_LEN },
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
+ [NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
};
/* policy for the key attributes */
@@ -6703,7 +6704,20 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
request->no_cck =
nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
- if (info->attrs[NL80211_ATTR_MAC])
+ /* Initial implementation used NL80211_ATTR_MAC to set the specific
+ * BSSID to scan for. This was problematic because that same attribute
+ * was already used for another purpose (local random MAC address). The
+ * NL80211_ATTR_BSSID attribute was added to fix this. For backwards
+ * compatibility with older userspace components, also use the
+ * NL80211_ATTR_MAC value here if it can be determined to be used for
+ * the specific BSSID use case instead of the random MAC address
+ * (NL80211_ATTR_SCAN_FLAGS is used to enable random MAC address use).
+ */
+ if (info->attrs[NL80211_ATTR_BSSID])
+ memcpy(request->bssid,
+ nla_data(info->attrs[NL80211_ATTR_BSSID]), ETH_ALEN);
+ else if (!info->attrs[NL80211_ATTR_SCAN_FLAGS] &&
+ info->attrs[NL80211_ATTR_MAC])
memcpy(request->bssid, nla_data(info->attrs[NL80211_ATTR_MAC]),
ETH_ALEN);
else
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Jouni Malinen @ 2016-11-23 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, vamsi krishna, Jouni Malinen
In-Reply-To: <1479938857-1788-1-git-send-email-jouni@qca.qualcomm.com>
From: vamsi krishna <vamsin@qti.qualcomm.com>
Enhance sched scan to support option of finding a better BSS while in
connected state. Firmware scans the medium and reports when it finds a
known BSS which has a significantly better RSSI than the current
connected BSS.
Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/net/cfg80211.h | 17 +++++++++++++++++
include/uapi/linux/nl80211.h | 17 +++++++++++++++++
net/wireless/nl80211.c | 32 ++++++++++++++++++++++++++++++--
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef42749..c62c42a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1626,6 +1626,20 @@ struct cfg80211_sched_scan_plan {
* cycle. The driver may ignore this parameter and start
* immediately (or at any other time), if this feature is not
* supported.
+ * @relative_rssi: Relative RSSI threshold to restrict scan result reporting in
+ * connected state to cases where a matching BSS is determined to have a
+ * significantly better RSSI than the current connected BSS.
+ * @relative_rssi_5g_pref: The amount of RSSI preference that is given to a
+ * 5 GHz BSS over 2.4 GHz BSS while looking for better BSSs in connected
+ * state.
+ * If the current connected BSS is in the 2.4 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by @relative_rssi
+ * and other BSSs in the 5 GHz band to be reported should have better RSSI
+ * by (@relative_rssi - @relative_rssi_5g_pref).
+ * If the current connected BSS is in the 5 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by
+ * (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
+ * band to be reported should have better RSSI by by @relative_rssi.
*/
struct cfg80211_sched_scan_request {
struct cfg80211_ssid *ssids;
@@ -1645,6 +1659,9 @@ struct cfg80211_sched_scan_request {
u8 mac_addr[ETH_ALEN] __aligned(2);
u8 mac_addr_mask[ETH_ALEN] __aligned(2);
+ int relative_rssi;
+ int relative_rssi_5g_pref;
+
/* internal */
struct wiphy *wiphy;
struct net_device *dev;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 984a35ac..34b16a4 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1981,6 +1981,16 @@ enum nl80211_commands {
* %NL80211_ATTR_MAC has also been used in various commands/events for
* specifying the BSSID.
*
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI: Relative RSSI threshold by which
+ * other BSSs has to be better than the current connected BSS so that they
+ * get reported to user space. This will give an opportunity to userspace
+ * to consider connecting to other matching BSSs which have better RSSI
+ * than the current connected BSS.
+ *
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF: The amount of RSSI preference
+ * to be given to 5 GHz APs over 2.4 GHz APs while searching for better
+ * BSSs than the current connected BSS.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2387,6 +2397,9 @@ enum nl80211_attrs {
NL80211_ATTR_BSSID,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -4698,6 +4711,9 @@ enum nl80211_feature_flags {
* configuration (AP/mesh) with VHT rates.
* @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
* with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
+ * @NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS: The driver supports sched_scan
+ * for reporting BSSs with better RSSI than the current connected BSS
+ * (%NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI).
*
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4713,6 +4729,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
NL80211_EXT_FEATURE_FILS_STA,
+ NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8db5cb1..af018a5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -405,6 +405,8 @@ enum nl80211_multicast_groups {
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
[NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
+ [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] = { .type = NLA_U32 },
+ [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF] = { .type = NLA_U32 },
};
/* policy for the key attributes */
@@ -6856,6 +6858,7 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
size_t ie_len;
struct nlattr *tb[NL80211_SCHED_SCAN_MATCH_ATTR_MAX + 1];
s32 default_match_rssi = NL80211_SCAN_RSSI_THOLD_OFF;
+ int bbr;
if (!is_valid_ie_attr(attrs[NL80211_ATTR_IE]))
return ERR_PTR(-EINVAL);
@@ -6950,6 +6953,13 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
if (!n_plans || n_plans > wiphy->max_sched_scan_plans)
return ERR_PTR(-EINVAL);
+ bbr = wiphy_ext_feature_isset(
+ wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS);
+ if (!bbr &&
+ (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] ||
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]))
+ return ERR_PTR(-EINVAL);
+
request = kzalloc(sizeof(*request)
+ sizeof(*request->ssids) * n_ssids
+ sizeof(*request->match_sets) * n_match_sets
@@ -7156,6 +7166,14 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
request->delay =
nla_get_u32(attrs[NL80211_ATTR_SCHED_SCAN_DELAY]);
+ if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI])
+ request->relative_rssi = nla_get_s32(
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]);
+
+ if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF])
+ request->relative_rssi_5g_pref = nla_get_s32(
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]);
+
err = nl80211_parse_sched_scan_plans(wiphy, n_plans, request, attrs);
if (err)
goto out_free;
@@ -9649,7 +9667,8 @@ static int nl80211_send_wowlan_tcp(struct sk_buff *msg,
return 0;
}
-static int nl80211_send_wowlan_nd(struct sk_buff *msg,
+static int nl80211_send_wowlan_nd(struct wiphy *wiphy,
+ struct sk_buff *msg,
struct cfg80211_sched_scan_request *req)
{
struct nlattr *nd, *freqs, *matches, *match, *scan_plans, *scan_plan;
@@ -9670,6 +9689,15 @@ static int nl80211_send_wowlan_nd(struct sk_buff *msg,
if (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_DELAY, req->delay))
return -ENOBUFS;
+ if (wiphy_ext_feature_isset(
+ wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS) &&
+ (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
+ req->relative_rssi) ||
+ nla_put_u32(msg,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
+ req->relative_rssi_5g_pref)))
+ return -ENOBUFS;
+
freqs = nla_nest_start(msg, NL80211_ATTR_SCAN_FREQUENCIES);
if (!freqs)
return -ENOBUFS;
@@ -9783,7 +9811,7 @@ static int nl80211_get_wowlan(struct sk_buff *skb, struct genl_info *info)
goto nla_put_failure;
if (nl80211_send_wowlan_nd(
- msg,
+ &rdev->wiphy, msg,
rdev->wiphy.wowlan_config->nd_config))
goto nla_put_failure;
--
1.9.1
^ permalink raw reply related
* Re: wl1251 & mac address & calibration data
From: Pavel Machek @ 2016-11-23 22:23 UTC (permalink / raw)
To: Pali Rohár
Cc: Michal Kazior, Kalle Valo, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <201611221805.13606@pali>
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
Hi!
> > > As wl1251.ko does not accept mac_address as module parameter, such
> > > modprobe hook does not help -- as there is absolutely no way from
> > > userspace to set or change (permanent) mac address.
> >
> > Quoting modprobe.d manual:
> > > install modulename command...
> > >
> > > This command instructs modprobe to run your
> > > command instead of inserting the module in the
> > > kernel as normal. The command can be any shell
> > > command: this allows you to do any kind of
> > > complex processing you might wish. [...]
>
> I know. But this do not allow me to send mac address to kernel -- as
> kernel does not support such command yet (reason for my first
> question).
Plus, this does not really work for cases where wl1251 is not a
module.
> > You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> > macaddr) and then insmod the actual wl1251.ko module. Or you can just
> > cook up the nvs on first device boot and store it in /lib/firmware
> > (possibly overwriting the "generic" wl1251 from linux-firmware).
>
> This is what I would like to prevent -- overwriting (possible readonly)
> system files with some device specific. It is really bad idea!
Agreed.
"ifconfig hw ether XX" normally sets the address. I guess that's
ioctl? And I guess we should use similar mechanism for permanent
address.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ 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