* Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
From: Arend van Spriel @ 2016-11-25 10:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <1480062330.4317.2.camel@sipsolutions.net>
On 11/25/2016 9:25 AM, Johannes Berg wrote:
> Sorry, forgot to reply to this until Luca's email bumped it up...
>
> On Tue, 2016-11-22 at 21:06 +0100, Arend Van Spriel wrote:
>
>> Are we? Currently, the minimum is not checked in nl80211, but that
>> does not say anything about the driver which might validate the
>> interval as well and return an error.
>
> Well, since drivers currently don't return an error (even if they
> ignore the value!) that *does* change the API.
>
>> What made me start looking at this is that in brcmfmac the interval
>> in the request was ignored and a fixed interval was provisioned in
>> the device. I wanted to fix that but was not sure if I needed to
>> check it against our firmware min..max range and what the appropriate
>> error handling should be. If silently changing what user-space is
>> requesting is fine for this, I am happy to make it so. Preferably in
>> nl80211.
>
> I think (agreeing with Luca) bumping it up is fine.
Fine by me although the "drift over time" reason seems only more reason
to have minimum validation mainly because nowhere is nl80211.h it is
stated that the interval is a "soft" requirement. Now Luca proposes
bumping to minimum should be done in the driver. What is your opinion?
I will update the kernel doc to clarify what can be expected from the
interval value.
Regards,
Arend
^ permalink raw reply
* Re: [1/4] rsi: Add support to filter rx frames
From: Kalle Valo @ 2016-11-25 9:48 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi, Prameela Rani Garnepudi
In-Reply-To: <1479465429-2412-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> wrote:
> Filtering rx frames after connection in station mode avoids the
> overhead of processing un-necessary frames. Hence rx filter frame
> is added which can be configured to device at suitable times.
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
4 patches applied to wireless-drivers-next.git, thanks.
e6d6428449c5 rsi: Add support to filter rx frames
8b36de8cf5ab rsi: Add support for configuring tx power
4edbcd1aa783 rsi: Add support for antenna selection
61d108421422 rsi: Add support for 802.11d
--
https://patchwork.kernel.org/patch/9436189/
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-25 9:57 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>
Patch applied to wireless-drivers-next.git, thanks.
4c0bfeaae9f9 brcmsmac: fix array out-of-bounds access in qm_log10
--
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
* Re: mwifiex: Disable adhoc feature based on firmware capability
From: Kalle Valo @ 2016-11-25 9:55 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Karthik D A,
Amitkumar Karwar
In-Reply-To: <1479730744-8964-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Karthik D A <karthida@marvell.com>
>
> We will read fw_cap_info filled by firmware to check whether to
> skip ADHOC related commands or not. Also, IBSS_COALESCING_STATUS
> command has been moved from init path to adhoc network creation
> path.
>
> Signed-off-by: Karthik D A <karthida@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
e267e71e68ae mwifiex: Disable adhoc feature based on firmware capability
--
https://patchwork.kernel.org/patch/9439379/
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] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Kalle Valo @ 2016-11-25 9:51 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, Larry.Finger, Jes Sorensen
In-Reply-To: <1479505468-29383-2-git-send-email-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> A device running without RX package aggregation could return more data
> in the USB packet than the actual network packet. In this case the
> could would clone the skb but then determine that that there was no
> packet to handle and exit without freeing the cloned skb first.
>
> This has so far only been observed with 8188eu devices, but could
> affect others.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
7 patches applied to wireless-drivers-next.git, thanks.
a0aba89763f8 rtl8xxxu: Fix memory leak in handling rxdesc16 packets
cf7cfef06462 rtl8xxxu: Fix big-endian problem reporting mactime
b9af93551127 rtl8xxxu: Fix rtl8723bu driver reload issue
5d03f882c2fc rtl8xxxu: Fix rtl8192eu driver reload issue
a748a11038f8 rtl8xxxu: Obtain RTS rates from mac80211
b4c3d9cfb607 rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry count
13e1349aff82 rtl8xxxu: Fix non static symbol warning
--
https://patchwork.kernel.org/patch/9437419/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: cleanup wake-IRQ handling if suspend fails
From: Kalle Valo @ 2016-11-25 9:50 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, rajatja, briannorris, dmitry.torokhov,
Brian Norris, Amitkumar Karwar
In-Reply-To: <1479489205-30288-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Brian Norris <briannorris@chromium.org>
>
> We don't want to leave the wake IRQ enabled.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
2 patches applied to wireless-drivers-next.git, thanks.
d96e39270ba5 mwifiex: cleanup wake-IRQ handling if suspend fails
b9da4d223bda mwifiex: avoid double-disable_irq() race
--
https://patchwork.kernel.org/patch/9437097/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-11-25
From: Kalle Valo @ 2016-11-25 9:39 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request for 4.10. ath9k has now been converted to use
mac80211 intermediate software queues to fix bufferbloat problems. rsi
has become active again and latevy mwifiex has been getting a _lot_ of
love.
I'm not expecting to see any problems with this pull request. When you
pull git will do lots of automerging but at least I didn't see any
conflicts. Please let me know if you have any problems.
Kalle
The following changes since commit 6edf10173a1feb1078f2fc8c655baf9614e83493:
devlink: Prevent port_type_set() callback when it's not needed (2016-10-2=
6 17:30:32 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2016-11-25
for you to fetch changes up to 159a55a64d44acbbd6f0d8f3c082e628d6d75670:
rt2800: disable CCK rates on HT (2016-11-23 17:38:53 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.10
Major changes:
iwlwifi
* finalize and enable dynamic queue allocation
* use dev_coredumpmsg() to prevent locking the driver
* small fix to pass the AID to the FW
* use FW PS decisions with multi-queue
ath9k
* add device tree bindings
* switch to use mac80211 intermediate software queues to reduce
latency and fix bufferbloat
wl18xx
* allow scanning in AP mode
----------------------------------------------------------------
Amitkumar Karwar (6):
mwifiex: prevent register accesses after host is sleeping
mwifiex: report error to PCIe for suspend failure
mwifiex: Fix NULL pointer dereference in skb_dequeue()
mwifiex: add memrw command information in README
mwifiex: ignore calibration data failure
mwifiex: remove redundant pdev check in suspend/resume handlers
Anilkumar Kolli (1):
ath10k: add cc_wraparound type for QCA9888 and QCA9884
Arnd Bergmann (2):
wireless: fix bogus maybe-uninitialized warning
cw1200: fix bogus maybe-uninitialized warning
Aviya Erenfeld (1):
iwlwifi: mvm: use dev_coredumpsg()
Bartosz Markowski (1):
ath10k: add platform regulatory domain support
Benjamin Berg (1):
ath10k: allow setting coverage class
Brian Norris (8):
mwifiex: don't do unbalanced free()'ing in cleanup_if()
mwifiex: resolve races between async FW init (failure) and device rem=
oval
mwifiex: don't pretend to resume while remove()'ing
mwifiex: resolve suspend() race with async FW init failure
mwifiex: usb: handle HS failures
mwifiex: sdio: don't check for NULL sdio_func
mwifiex: stop checking for NULL drvata/intfdata
mwifiex: pcie: stop checking for NULL adapter->card
Colin Ian King (1):
ath9k_htc: fix minor mistakes in dev_err messages
Emmanuel Grumbach (1):
iwlwifi: mvm: tell the firmware about the AID of the peer
James Minor (4):
ath6kl: fix busreqs so they can be reused when sg is cleaned up
ath6kl: after cleanup properly reflect that sg is disabled
ath6kl: configure SDIO when power is reapplied
wlcore: Allow scans when in AP mode
Jiri Slaby (1):
p54: memset(0) whole array
Johannes Berg (1):
iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS
Johannes Thumshirn (1):
cw1200: Don't leak memory if krealloc failes
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2016-10-25-2' of git://git.kernel.o=
rg/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthik D A (2):
mwifiex: vendor_ie length check for parse WMM IEs
mwifiex: fix p2p device doesn't find in scan problem
Larry Finger (9):
rtlwifi: rtl8192de: Remove address of Free Software Foundation
rtlwifi: rtl8192se: Remove address of Free Software Foundation
rtlwifi: rtl8192ce: Remove address of Free Software Foundation
rtlwifi: rtl8192cu: Remove address of Free Software Foundation
rtlwifi: rtl8723ae: Remove address of Free Software Foundation
rtlwifi: rtl8188ee: Remove address of Free Software Foundation
rtlwifi: rtl8192c: Remove address of Free Software Foundation
rtlwifi: Remove address of Free Software Foundation
ssb: Fix error routine when fallback SPROM fails
Liad Kaufman (5):
iwlwifi: mvm: update txq metadata to current owner
iwlwifi: mvm: fix reserved txq freeing
iwlwifi: mvm: support MONITOR vif in DQA mode
iwlwifi: mvm: fix dqa deferred frames marking
iwlwifi: mvm: enable dynamic queue allocation mode
Maharaja Kennadyrajan (1):
ath10k: provide provision to get Transmit Power Control stats for 10.4
Martin Blumenstingl (3):
Documentation: dt: net: add ath9k wireless device binding
ath9k: add a helper to get the string representation of ath_bus_type
ath9k: parse the device configuration from an OF node
Mathias Kresin (1):
rt2x00: add support for mac addr from device tree
Maxim Altshul (2):
wlcore: Pass win_size taken from ieee80211_sta to FW
wlcore: Add RX_BA_WIN_SIZE_CHANGE_EVENT event
Miaoqing Pan (1):
ath9k: change entropy formula for easier understanding
Michal Kazior (1):
ath: export alpha2 helper
Mohammed Shafi Shajakhan (4):
ath10k: cleanup calling ath10k_htt_rx_h_unchain
ath10k: fix failure to send NULL func frame for 10.4
ath10k: clean up HTT tx buffer allocation and free
ath10k: remove extraneous error message in tx alloc
Nicolas Iooss (1):
ath10k: use the right length of "background"
Prameela Rani Garnepudi (2):
rsi: Fix memory leak in module unload
rsi: Host to device command frame vap_capabilites modified with new f=
ield vap status
Rafa=C5=82 Mi=C5=82ecki (2):
brcmfmac: proto: add callback for queuing TX data
brcmfmac: print name of connect status event
Rajat Jain (4):
mwifiex: report wakeup for wowlan
mwifiex: Allow mwifiex early access to device structure
mwifiex: Introduce mwifiex_probe_of() to parse common properties
mwifiex: Enable WoWLAN for both sdio and pcie
Ricky Liang (1):
mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
Sara Sharon (1):
iwlwifi: mvm: assign cab queue to the correct station
Sharon Dvir (1):
iwlwifi: pcie: give a meaningful name to interrupt request
Shengzhen Li (3):
mwifiex: add power save parameters in hs_cfg cmd
mwifiex: check tx_hw_pending before downloading sleep confirm
mwifiex: complete blocked power save handshake in main process
Stanislaw Gruszka (9):
rt2800: correctly report MCS TX parameters
rt2800usb: do not wipe out USB_DMA_CFG settings
rt2800: OFDM rates are mandatory
rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
rt2800: correct AUTO_RSP_CFG
rt2800: correct TX_SW_CFG1 for 5592
rt2800: use RTS/CTS protection instead of CTS-to-self
rt2800: tune *_PROT_CFG parameters
rt2800: disable CCK rates on HT
Toke H=C3=B8iland-J=C3=B8rgensen (1):
ath9k: Switch to using mac80211 intermediate software queues.
Vasanthakumar Thiagarajan (1):
ath10k: fix kernel panic due to race in accessing arvif list
Vishal Thanki (1):
rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB
Vittorio Gambaletta (VittGam) (1):
ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.
Wei Yongjun (2):
mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virt=
ual_intf()
rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb
Wright Feng (1):
brcmfmac: update beacon IE after bss up and clear when AP stopped
Xinming Hu (4):
mwifiex: update tx_pkts_queued for requeued packets
mwifiex: fix command timeout problem seen in stress tests
mwifiex: parse device tree node for PCIe
mwifiex: reset card->adapter during device unregister
.../{marvell-sd8xxx.txt =3D> marvell-8xxx.txt} | 8 +-
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 48 +++
drivers/net/wireless/ath/ath.h | 6 +
drivers/net/wireless/ath/ath10k/core.c | 13 +
drivers/net/wireless/ath/ath10k/core.h | 20 +-
drivers/net/wireless/ath/ath10k/debug.h | 22 ++
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 79 +++--
drivers/net/wireless/ath/ath10k/hw.c | 142 ++++++++
drivers/net/wireless/ath/ath10k/hw.h | 28 +-
drivers/net/wireless/ath/ath10k/mac.c | 140 +++++++-
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 54 +++-
drivers/net/wireless/ath/ath6kl/sdio.c | 15 +-
drivers/net/wireless/ath/ath6kl/wmi.c | 8 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 27 +-
drivers/net/wireless/ath/ath9k/channel.c | 2 -
drivers/net/wireless/ath/ath9k/debug.c | 14 +-
drivers/net/wireless/ath/ath9k/debug.h | 2 -
drivers/net/wireless/ath/ath9k/debug_sta.c | 4 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 6 +-
drivers/net/wireless/ath/ath9k/init.c | 44 ++-
drivers/net/wireless/ath/ath9k/main.c | 9 +-
drivers/net/wireless/ath/ath9k/pci.c | 7 +-
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 338 ++++++++--------=
----
drivers/net/wireless/ath/main.c | 7 +
drivers/net/wireless/ath/regd.c | 3 +-
drivers/net/wireless/ath/regd.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 12 +
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 8 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 8 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.h | 2 +
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 15 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 6 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.h | 9 +
drivers/net/wireless/intel/ipw2x00/libipw_rx.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 2 +
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h | 26 ++
.../net/wireless/intel/iwlwifi/mvm/fw-api-sta.h | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 100 +++---
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 86 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 +
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 37 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 29 +-
.../net/wireless/intersil/hostap/hostap_80211_rx.c | 2 +-
drivers/net/wireless/intersil/p54/fwio.c | 2 +-
drivers/net/wireless/marvell/mwifiex/README | 23 ++
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 12 +-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 10 +
drivers/net/wireless/marvell/mwifiex/init.c | 1 +
drivers/net/wireless/marvell/mwifiex/main.c | 113 +++++--
drivers/net/wireless/marvell/mwifiex/main.h | 40 ++-
drivers/net/wireless/marvell/mwifiex/pcie.c | 166 +++++-----
drivers/net/wireless/marvell/mwifiex/pcie.h | 2 +
drivers/net/wireless/marvell/mwifiex/scan.c | 4 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 153 +++------
drivers/net/wireless/marvell/mwifiex/sdio.h | 9 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 49 +--
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 60 ++--
drivers/net/wireless/marvell/mwifiex/usb.h | 2 +
drivers/net/wireless/marvell/mwifiex/wmm.c | 31 +-
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 67 ++--
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 19 +-
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 4 -
drivers/net/wireless/realtek/rtlwifi/pci.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/led.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/dm_common.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/dm_common.h | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192c/main.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8723ae/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.h | 4 -
.../realtek/rtlwifi/rtl8723ae/hal_bt_coexist.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8723ae/led.c | 4 -
drivers/net/wireless/realtek/rtlwifi/usb.c | 4 -
drivers/net/wireless/realtek/rtlwifi/usb.h | 4 -
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 19 +-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 5 +-
drivers/net/wireless/rsi/rsi_mgmt.h | 9 +-
drivers/net/wireless/st/cw1200/wsm.c | 24 +-
drivers/net/wireless/ti/wl18xx/event.c | 28 ++
drivers/net/wireless/ti/wl18xx/event.h | 1 +
drivers/net/wireless/ti/wl18xx/main.c | 3 +-
drivers/net/wireless/ti/wlcore/acx.c | 5 +-
drivers/net/wireless/ti/wlcore/acx.h | 3 +-
drivers/net/wireless/ti/wlcore/main.c | 8 +-
drivers/ssb/pci.c | 1 +
net/wireless/lib80211_crypt_tkip.c | 2 +-
189 files changed, 1607 insertions(+), 1152 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt =
=3D> marvell-8xxx.txt} (91%)
create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9=
k.txt
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Luca Coelho @ 2016-11-25 9:21 UTC (permalink / raw)
To: Jouni Malinen, Johannes Berg; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1479938857-1788-2-git-send-email-jouni@qca.qualcomm.com>
IMHO "report better BSSs" is vague in this context. It would better to
use something more concrete like "add relative RSSI attribute to sched
scan".
On Thu, 2016-11-24 at 00:07 +0200, Jouni Malinen wrote:
> 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
"Significantly" is dependent on the value you use. :)
> 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.
What happens with this attribute if we're not connected? Also, I think
you should specify the attribute type (int?) and the unit here.
> + * @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.
Could there be cases where you want the opposite? Meaning,
relative_rssi_5g_pref being negative?
> */
> 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;
I'm not sure it was your intention, but for flexibility, it's good that
both these attributes are ints so that you can find relative values on
both sides (greater than and smaller than).
It doesn't apply to the "better BSS" case, but maybe people find a
different use for it in the future?
> 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.
The userspace can always do this, but the advantage here is that it
doesn't need to be woken up and check the results itself, since it
would only receive results that matter.
> + *
> + * @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
Should be "RELATIVE_RSSI" instead of "BETTER_BSS".
[...]
> 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 },
This should probably be NLA_S32 (if we want to allow negative values as
well).
[...]
>
@@ -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]);
Good, I see you use s32 here. :)
[...]
> @@ -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;
> +
Why did you add this to nl80211_send_wowlan_nd() function?
[...]
--
Luca.
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: Use different attrs for BSSID and random MAC addr in scan req
From: Luca Coelho @ 2016-11-25 8:44 UTC (permalink / raw)
To: Jouni Malinen, Johannes Berg; +Cc: linux-wireless, Vamsi Krishna
In-Reply-To: <1479938857-1788-1-git-send-email-jouni@qca.qualcomm.com>
On Thu, 2016-11-24 at 00:07 +0200, Jouni Malinen wrote:
> 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
typo, extent
> BSSID when scanning without enabling random MAC address use.
Hopefully nobody expects the broken functionality to be the correct
behavior, so we can slightly break backwards compatibility.
> 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>
> ---
> 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
[...]
> @@ -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
The BSSID may also be used for other things, like P2P GO, right? Also
"various uses" is probably unnecessary? Every command using this
attribute should describe it's use in their description.
> + * %NL80211_ATTR_MAC has also been used in various commands/events for
> + * specifying the BSSID.
This can be a bit confusing. Maybe you can specify which commands
*used* to use NL80211_ATTR_MAC but now use NL80211_ATTR_BSSID?
[...]
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
[...]
> @@ -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).
> + */
You should probably add this information to the
NL80211_CMD_TRIGGER_SCAN description.
> + 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] &&
You should actually check that the SCAN_FLAGS attribute either doesn't
exist (as you already do) or, if it exists, that it doesn't have the
NL80211_SCAN_FLAG_RANDOM_ADDR flags.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
From: Luca Coelho @ 2016-11-25 8:04 UTC (permalink / raw)
To: Arend van Spriel, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1479821515-13261-1-git-send-email-arend.vanspriel@broadcom.com>
Hi Arend,
On Tue, 2016-11-22 at 13:31 +0000, Arend van Spriel wrote:
> The interval for scheduled scan may have a minimum value for
> the device. Allow drivers to specify a minimum value in the
> struct wiphy so user-space interval values can be validated
> against it.
>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> ---
I'm not sure this is necessary, because the interval is a "soft"
requirement, there being no guarantee on the accuracy of the intervals.
The minimum interval a firmware can support is probably variable,
depending on how long time it takes for a scan to complete. Let's say
it takes 1 second to scan a certain amount of channels. In this case,
the minimum interval is probably 1 second (i.e. you can start a new
scan immediately after the first one completed). Now, if you're
scanning more channels and it takes, say, 4 seconds to complete, the
minimum interval would be 4 seconds.
The iwlwifi firmware treats the interval as the amount of time to wait
*after* one scan cycle completes before starting the cycle. Since
sched scan is mostly used while the system is suspended, the interval
can be quite large and the accuracy really doesn't matter. The
absoulte time when the scan cycles occur will drift over time, but does
it matter?
So, for firmwares that really need to get a minimum value, I think
bumping up to the minimum allowed if the provided value is too low,
should be done in the driver.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
From: Johannes Berg @ 2016-11-25 8:25 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <5c249c34-5e8c-093a-c5df-3507cabc8872@broadcom.com>
Sorry, forgot to reply to this until Luca's email bumped it up...
On Tue, 2016-11-22 at 21:06 +0100, Arend Van Spriel wrote:
> Are we? Currently, the minimum is not checked in nl80211, but that
> does not say anything about the driver which might validate the
> interval as well and return an error.
Well, since drivers currently don't return an error (even if they
ignore the value!) that *does* change the API.
> What made me start looking at this is that in brcmfmac the interval
> in the request was ignored and a fixed interval was provisioned in
> the device. I wanted to fix that but was not sure if I needed to
> check it against our firmware min..max range and what the appropriate
> error handling should be. If silently changing what user-space is
> requesting is fine for this, I am happy to make it so. Preferably in
> nl80211.
I think (agreeing with Luca) bumping it up is fine.
johannes
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Aaro Koskinen @ 2016-11-24 18:46 UTC (permalink / raw)
To: Pali Rohár
Cc: Sebastian Reichel, Pavel Machek, Michal Kazior, Kalle Valo,
Ivaylo Dimitrov, Tony Lindgren, linux-wireless,
Network Development, linux-kernel
In-Reply-To: <20161124152045.GK13735@pali>
Hi,
On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.
>
> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But still it has problems with reading from nand, so
> cannot read NVS data nor MAC address.
You could use kexec to pass the fixed DT.
A.
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-24 18:35 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124181138.4i6ehkpohjxfgpbn@earth>
[-- Attachment #1: Type: Text/Plain, Size: 8119 bytes --]
On Thursday 24 November 2016 19:11:39 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > > > "ifconfig hw ether XX" normally sets the address. I
> > > > > > > > > guess that's ioctl?
> > > > > > > >
> > > > > > > > This sets temporary address and it is ioctl. IIRC same
> > > > > > > > as what ethtool uses. (ifconfig is already
> > > > > > > > deprecated).
> > > > > > > >
> > > > > > > > > And I guess we should use similar mechanism for
> > > > > > > > > permanent address.
> > > > > > > >
> > > > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > > > temporary mac address. But here we do not want to
> > > > > > > > change permanent mac address. We want to tell kernel
> > > > > > > > driver current permanent mac address which is stored
> > > > > > >
> > > > > > > Well... I'd still use similar mechanism :-).
> > > > > >
> > > > > > Thats problematic, because in time when wlan0 interface is
> > > > > > registered into system and visible in ifconfig output it
> > > > > > already needs to have permanent mac address assigned.
> > > > > >
> > > > > > We should assign permanent mac address before wlan0 of
> > > > > > wl1251 is registered into system.
> > > > >
> > > > > You can just add the MAC address to the NVS data, which is
> > > > > also required for the device initialization.
> > > >
> > > > NVS data file has fixed size, there is IIRC no place for it.
> > > >
> > > > But one of my suggestion was to use another request_firmware
> > > > for MAC address. So this is similar to what you are proposing,
> > > > as NVS data are loaded by request_firmware too...
> > >
> > > Just append it to NVS data and modify the size check accordingly?
> >
> > First that would mean to have request_firmware() function which
> > will not use direct VFS access, but instead use userspace helper.
>
> Permanent MAC is device specific init data, NVS is device specific
> init data => load together.
>
> The userspace helper stuff is only needed to get the data from
> the NAND calibration area on the fly.
But it is needed... and currently request_firmware() prefer direct VFS
access...
> > NVS data file with some default values (not suitable for usage) is
> > already present in linux-firmware and available in
> > /lib/firmware/...
>
> You mentioned NVS data is fixed size, so this should be enough?
>
> switch(loaded_size)
> case IMAGE_SIZE + MAC_SIZE:
> /* extract mac */
> /* fallthrough */
> case IMAGE_SIZE:
> /* load NVS */
> break;
> default:
> /* fail */
> }
>
> > Also I'm not sure if such thing is allowed by license:
> > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmwar
> > e.git/tree/LICENCE.ti-connectivity
>
> concating data is not a modification, otherwise you can't
> put the file in a filesystem.
Ok, if net maintainers agree.
> > > > > I wonder if those information could be put into DT. Iirc some
> > > > > network devices get their MAC address from DT. Maybe we can
> > > > > add all NVS info to DT? How much data is it?
> > > >
> > > > Proprietary, signed and closed bootloader NOLO does not support
> > > > DT. So for booting you need to append DTS file to kernel
> > > > image.
> > >
> > > Yeah, so NOLO without U-Boot will depend on userspace to fixup
> > > DT.
> > >
> > > > U-Boot is optional and can be used as intermediate bootloader
> > > > between NOLO and kernel. But still it has problems with reading
> > > > from nand, so cannot read NVS data nor MAC address.
> > >
> > > It may in the future?
> >
> > I already tried that, but I failed. I was not able to access N900's
> > nand from u-boot. No idea where was problem...
> >
> > And if somebody fix onenand in u-boot, then needs to reimplement
> > Nokia's proprietary parser of that partition where is stored NVS
> > and mac address && make this support in upstream u-boot.
>
> Are we talking about this?
>
> https://github.com/community-ssu/libcal/blob/master/cal.c
>
> That's ~1k loc for read-only.
Yes. There is also read-only alternative library:
https://github.com/pali/0xFFFF/blob/master/src/cal.c
But still, this is proprietary format useful only for one device (or
two) and I do not know if such thing could be accepted by u-boot
developers...
> Getting NAND working looks harder than porting this to me.
Right.
> > So... I doubt it will be in any future.
> >
> > + no men power
>
> yeah :(
>
> But with that reasoning you should just extract the NVS data
> from NAND and put it in your rootfs.
Not a clean solution. Some rootfs parts can used as readonly. And
normally rootfs is flashed into nand, so I still will say that roofs
(image) should not contain any device specific data.
> > > > > Userspace application can add all those information to the DT
> > > > > using a DT overlay. Also the u-boot could parse and add it at
> > > > > some point in the future.
> > > >
> > > > In case when wl1251 is statically linked into kernel image, it
> > > > is loaded and initialized before even userspace applications
> > > > starts.
> > > >
> > > > So no... adding NVS data or MAC address into DT or DT overlay
> > > > is not a solution.
> > >
> > > Actually with data loaded from DT you *can* load data quite early
> > > in the boot process, while your suggestions always require
> > > userspace. So you argument against yourself?
> >
> > You cannot add DTS in uboot (no support).
>
> AFAIK that's supported:
>
> http://www.denx.de/wiki/DULG/LinuxFDTBlob
>
> "Note that U-Boot makes some automatic modifications to the blob
> before passing it to the kernel - mainly adding and modifying
> information that is learnt at run-time."
I mean we do not have support for due to n900 nand.
> > And if you modify DTS on running kernel from userspace, then it is
> > too late when wl1251 is statically linked into kernel image.
> >
> > wl1251 will not wait until some userspace modify DTS and add
> > data...
>
> if (nvs info missing)
> return -EPROBE_DEFER;
Forever? Only N times? How long? Only N second?
Here we do not know if userspace is going to send data or not.
My guess is that such code will not be accepted into net/wireless
subsystem or drivers by maintainers.
> > But request_firmware() in fallback mode *can* wait for userspace so
> > wl1251 can postpone its operation until mdev/udev/whatever starts
> > listening for events and push needed firmware data to kernel.
>
> As you said one workaround is waiting. That's not a solution, that
> only works with request_firmware().
Yes, but request_firmware() uses interaction with userspace. Your
proposed solution does not do any interaction with userspace that some
process needs to fill missing data into DT.
And request_firmware() is already used for loading NVS data.
> > So no, there is no argument against... request_firmware() in
> > fallback mode with userspace helper is by design blocking and
> > waiting for userspace. But waiting for some change in DTS in
> > kernel is just nonsense.
>
> I would just mark the wlan device with status = "disabled" and
> enable it in the overlay together with adding the NVS & MAC info.
So if you think that this solution make sense, we can wait what net
wireless maintainers say about it...
For me it looks like that solution can be:
extending request_firmware() to use only userspace helper
and load mac address also via request_firmware() either by appending it
into NVS data or via separate call
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Sebastian Reichel @ 2016-11-24 18:11 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <201611241749.33681@pali>
[-- Attachment #1: Type: text/plain, Size: 6231 bytes --]
Hi,
On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > > "ifconfig hw ether XX" normally sets the address. I guess
> > > > > > > > that's ioctl?
> > > > > > >
> > > > > > > This sets temporary address and it is ioctl. IIRC same as
> > > > > > > what ethtool uses. (ifconfig is already deprecated).
> > > > > > >
> > > > > > > > And I guess we should use similar mechanism for permanent
> > > > > > > > address.
> > > > > > >
> > > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > > temporary mac address. But here we do not want to change
> > > > > > > permanent mac address. We want to tell kernel driver
> > > > > > > current permanent mac address which is stored
> > > > > >
> > > > > > Well... I'd still use similar mechanism :-).
> > > > >
> > > > > Thats problematic, because in time when wlan0 interface is
> > > > > registered into system and visible in ifconfig output it
> > > > > already needs to have permanent mac address assigned.
> > > > >
> > > > > We should assign permanent mac address before wlan0 of wl1251
> > > > > is registered into system.
> > > >
> > > > You can just add the MAC address to the NVS data, which is also
> > > > required for the device initialization.
> > >
> > > NVS data file has fixed size, there is IIRC no place for it.
> > >
> > > But one of my suggestion was to use another request_firmware for
> > > MAC address. So this is similar to what you are proposing, as NVS
> > > data are loaded by request_firmware too...
> >
> > Just append it to NVS data and modify the size check accordingly?
>
> First that would mean to have request_firmware() function which will not
> use direct VFS access, but instead use userspace helper.
Permanent MAC is device specific init data, NVS is device specific
init data => load together.
The userspace helper stuff is only needed to get the data from
the NAND calibration area on the fly.
> NVS data file with some default values (not suitable for usage) is
> already present in linux-firmware and available in /lib/firmware/...
You mentioned NVS data is fixed size, so this should be enough?
switch(loaded_size)
case IMAGE_SIZE + MAC_SIZE:
/* extract mac */
/* fallthrough */
case IMAGE_SIZE:
/* load NVS */
break;
default:
/* fail */
}
> Also I'm not sure if such thing is allowed by license:
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.ti-connectivity
concating data is not a modification, otherwise you can't
put the file in a filesystem.
> > > > I wonder if those information could be put into DT. Iirc some
> > > > network devices get their MAC address from DT. Maybe we can add
> > > > all NVS info to DT? How much data is it?
> > >
> > > Proprietary, signed and closed bootloader NOLO does not support DT.
> > > So for booting you need to append DTS file to kernel image.
> >
> > Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
> >
> > > U-Boot is optional and can be used as intermediate bootloader
> > > between NOLO and kernel. But still it has problems with reading
> > > from nand, so cannot read NVS data nor MAC address.
> >
> > It may in the future?
>
> I already tried that, but I failed. I was not able to access N900's nand
> from u-boot. No idea where was problem...
>
> And if somebody fix onenand in u-boot, then needs to reimplement Nokia's
> proprietary parser of that partition where is stored NVS and mac address
> && make this support in upstream u-boot.
Are we talking about this?
https://github.com/community-ssu/libcal/blob/master/cal.c
That's ~1k loc for read-only. Getting NAND working looks harder than
porting this to me.
> So... I doubt it will be in any future.
>
> + no men power
yeah :(
But with that reasoning you should just extract the NVS data
from NAND and put it in your rootfs.
> > > > Userspace application can add all those information to the DT
> > > > using a DT overlay. Also the u-boot could parse and add it at
> > > > some point in the future.
> > >
> > > In case when wl1251 is statically linked into kernel image, it is
> > > loaded and initialized before even userspace applications starts.
> > >
> > > So no... adding NVS data or MAC address into DT or DT overlay is
> > > not a solution.
> >
> > Actually with data loaded from DT you *can* load data quite early in
> > the boot process, while your suggestions always require userspace.
> > So you argument against yourself?
>
> You cannot add DTS in uboot (no support).
AFAIK that's supported:
http://www.denx.de/wiki/DULG/LinuxFDTBlob
"Note that U-Boot makes some automatic modifications to the blob
before passing it to the kernel - mainly adding and modifying
information that is learnt at run-time."
> And if you modify DTS on running kernel from userspace, then it is
> too late when wl1251 is statically linked into kernel image.
>
> wl1251 will not wait until some userspace modify DTS and add data...
if (nvs info missing)
return -EPROBE_DEFER;
> But request_firmware() in fallback mode *can* wait for userspace so
> wl1251 can postpone its operation until mdev/udev/whatever starts
> listening for events and push needed firmware data to kernel.
As you said one workaround is waiting. That's not a solution, that
only works with request_firmware().
> So no, there is no argument against... request_firmware() in fallback
> mode with userspace helper is by design blocking and waiting for
> userspace. But waiting for some change in DTS in kernel is just
> nonsense.
I would just mark the wlan device with status = "disabled" and
enable it in the overlay together with adding the NVS & MAC info.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-24 16:49 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124160830.kdpbonsz3l26uuo5@earth>
[-- Attachment #1: Type: Text/Plain, Size: 4604 bytes --]
On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > "ifconfig hw ether XX" normally sets the address. I guess
> > > > > > > that's ioctl?
> > > > > >
> > > > > > This sets temporary address and it is ioctl. IIRC same as
> > > > > > what ethtool uses. (ifconfig is already deprecated).
> > > > > >
> > > > > > > And I guess we should use similar mechanism for permanent
> > > > > > > address.
> > > > > >
> > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > temporary mac address. But here we do not want to change
> > > > > > permanent mac address. We want to tell kernel driver
> > > > > > current permanent mac address which is stored
> > > > >
> > > > > Well... I'd still use similar mechanism :-).
> > > >
> > > > Thats problematic, because in time when wlan0 interface is
> > > > registered into system and visible in ifconfig output it
> > > > already needs to have permanent mac address assigned.
> > > >
> > > > We should assign permanent mac address before wlan0 of wl1251
> > > > is registered into system.
> > >
> > > You can just add the MAC address to the NVS data, which is also
> > > required for the device initialization.
> >
> > NVS data file has fixed size, there is IIRC no place for it.
> >
> > But one of my suggestion was to use another request_firmware for
> > MAC address. So this is similar to what you are proposing, as NVS
> > data are loaded by request_firmware too...
>
> Just append it to NVS data and modify the size check accordingly?
First that would mean to have request_firmware() function which will not
use direct VFS access, but instead use userspace helper.
NVS data file with some default values (not suitable for usage) is
already present in linux-firmware and available in /lib/firmware/...
Also I'm not sure if such thing is allowed by license:
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.ti-connectivity
> > > I wonder if those information could be put into DT. Iirc some
> > > network devices get their MAC address from DT. Maybe we can add
> > > all NVS info to DT? How much data is it?
> >
> > Proprietary, signed and closed bootloader NOLO does not support DT.
> > So for booting you need to append DTS file to kernel image.
>
> Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
>
> > U-Boot is optional and can be used as intermediate bootloader
> > between NOLO and kernel. But still it has problems with reading
> > from nand, so cannot read NVS data nor MAC address.
>
> It may in the future?
I already tried that, but I failed. I was not able to access N900's nand
from u-boot. No idea where was problem...
And if somebody fix onenand in u-boot, then needs to reimplement Nokia's
proprietary parser of that partition where is stored NVS and mac address
&& make this support in upstream u-boot.
So... I doubt it will be in any future.
+ no men power
> > > Userspace application can add all those information to the DT
> > > using a DT overlay. Also the u-boot could parse and add it at
> > > some point in the future.
> >
> > In case when wl1251 is statically linked into kernel image, it is
> > loaded and initialized before even userspace applications starts.
> >
> > So no... adding NVS data or MAC address into DT or DT overlay is
> > not a solution.
>
> Actually with data loaded from DT you *can* load data quite early in
> the boot process, while your suggestions always require userspace.
> So you argument against yourself?
You cannot add DTS in uboot (no support). And if you modify DTS on
running kernel from userspace, then it is too late when wl1251 is
statically linked into kernel image.
wl1251 will not wait until some userspace modify DTS and add data...
But request_firmware() in fallback mode *can* wait for userspace so
wl1251 can postpone its operation until mdev/udev/whatever starts
listening for events and push needed firmware data to kernel.
So no, there is no argument against... request_firmware() in fallback
mode with userspace helper is by design blocking and waiting for
userspace. But waiting for some change in DST in kernel is just
nonsense.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Sebastian Reichel @ 2016-11-24 16:08 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124152045.GK13735@pali>
[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]
Hi,
On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > > > ioctl?
> > > > >
> > > > > This sets temporary address and it is ioctl. IIRC same as what ethtool
> > > > > uses. (ifconfig is already deprecated).
> > > > >
> > > > > > And I guess we should use similar mechanism for permanent
> > > > > > address.
> > > > >
> > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
> > > > > address. But here we do not want to change permanent mac address. We
> > > > > want to tell kernel driver current permanent mac address which is
> > > > > stored
> > > >
> > > > Well... I'd still use similar mechanism :-).
> > >
> > > Thats problematic, because in time when wlan0 interface is registered
> > > into system and visible in ifconfig output it already needs to have
> > > permanent mac address assigned.
> > >
> > > We should assign permanent mac address before wlan0 of wl1251 is
> > > registered into system.
> >
> > You can just add the MAC address to the NVS data, which is also
> > required for the device initialization.
>
> NVS data file has fixed size, there is IIRC no place for it.
>
> But one of my suggestion was to use another request_firmware for MAC
> address. So this is similar to what you are proposing, as NVS data are
> loaded by request_firmware too...
Just append it to NVS data and modify the size check accordingly?
> > I wonder if those information could be put into DT. Iirc some
> > network devices get their MAC address from DT. Maybe we can add
> > all NVS info to DT? How much data is it?
>
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.
Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But still it has problems with reading from nand, so
> cannot read NVS data nor MAC address.
It may in the future?
> > Userspace application can add all those information to the DT
> > using a DT overlay. Also the u-boot could parse and add it at
> > some point in the future.
>
> In case when wl1251 is statically linked into kernel image, it is loaded
> and initialized before even userspace applications starts.
>
> So no... adding NVS data or MAC address into DT or DT overlay is not a
> solution.
Actually with data loaded from DT you *can* load data quite early in
the boot process, while your suggestions always require userspace.
So you argument against yourself?
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Ivaylo Dimitrov @ 2016-11-24 15:31 UTC (permalink / raw)
To: Pali Rohár, Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Aaro Koskinen,
Tony Lindgren, linux-wireless, Network Development, linux-kernel
In-Reply-To: <20161124152045.GK13735@pali>
Hi,
On 24.11.2016 17:20, Pali Rohár wrote:
>
> In case when wl1251 is statically linked into kernel image, it is loaded
> and initialized before even userspace applications starts.
>
Which leaves no option, but integrating libcal into kernel :).
Ivo
^ permalink raw reply
* Re: many "changed bandwidth, new config is" messages in the log
From: Michal Hocko @ 2016-11-24 15:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: LKML, linux-wireless
In-Reply-To: <1480000334.4388.2.camel@sipsolutions.net>
On Thu 24-11-16 16:12:14, Johannes Berg wrote:
> On Thu, 2016-11-24 at 15:07 +0000, Michal Hocko wrote:
>
> > I have only now managed to move to 4.9-rc5 (from 4.8) and started
> > seeing quite a lot of following messages
> > "
> > [ 346.612211] wlan0: AP c0:4a:00:f1:48:f2 changed bandwidth, new
> > config is 2472 MHz, width 1 (2472/0 MHz)
> > [ 352.655929] wlan0: AP c0:4a:00:f1:48:f2 changed bandwidth, new
> > config is 2472 MHz, width 2 (2462/0 MHz)
> > "
>
> I don't think these messages are new in any way. checking ... nope,
> it's been around that way since 3.9 :-)
Right you are. I must have missed them before and git grep + git blame
fooled me.
> > It always seems to be changing width from 1 -> 2 and back
>
> Makes sense, that's 20 MHz <-> 40 MHz.
>
> Did you buy a new device that says it's 40 MHz incompatible or
> something?
I am using this device for years now. It is a cheap TP-Link home
wireless router. So hard to tell about above. I am far from an expert.
> Or perhaps one of your neighbors did ... Or something is
> causing interference that makes the AP switch around.
This might be possible. There are quite some devices broadcasting around
$ sudo iwlist wlan0 scan | grep "Channel:" | sort | uniq -c
6 Channel:1
6 Channel:11
1 Channel:112
2 Channel:13
2 Channel:3
7 Channel:6
1 Channel:9
my router is at channel 13 so there seems to be something else sitting
there as well.
> > $ dmesg | grep "changed bandwidth" | wc -l
> > 42
> > in 13 minutes of uptime. I have noticed this came in via 30eb1dc2c430
> > ("mac80211: properly track HT/VHT operation changes").
>
> Right, but that went into 3.9 :-)
>
> > Is this something to be worried about?
>
> Not at all. I suppose we could make this a debug message though, it's
> not super useful when it happens OK (sometimes it causes disconnections
> when we can't support the new mode, which is more relevant).
OK, I see. Then I would suggest lowering the loglevel ;)
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-24 15:20 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124151317.34yoza3dzuh46oa4@earth>
On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > Hi!
> > >
> > > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > > ioctl?
> > > >
> > > > This sets temporary address and it is ioctl. IIRC same as what ethtool
> > > > uses. (ifconfig is already deprecated).
> > > >
> > > > > And I guess we should use similar mechanism for permanent
> > > > > address.
> > > >
> > > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
> > > > address. But here we do not want to change permanent mac address. We
> > > > want to tell kernel driver current permanent mac address which is
> > > > stored
> > >
> > > Well... I'd still use similar mechanism :-).
> >
> > Thats problematic, because in time when wlan0 interface is registered
> > into system and visible in ifconfig output it already needs to have
> > permanent mac address assigned.
> >
> > We should assign permanent mac address before wlan0 of wl1251 is
> > registered into system.
>
> You can just add the MAC address to the NVS data, which is also
> required for the device initialization.
NVS data file has fixed size, there is IIRC no place for it.
But one of my suggestion was to use another request_firmware for MAC
address. So this is similar to what you are proposing, as NVS data are
loaded by request_firmware too...
> I wonder if those information could be put into DT. Iirc some
> network devices get their MAC address from DT. Maybe we can add
> all NVS info to DT? How much data is it?
Proprietary, signed and closed bootloader NOLO does not support DT. So
for booting you need to append DTS file to kernel image.
U-Boot is optional and can be used as intermediate bootloader between
NOLO and kernel. But still it has problems with reading from nand, so
cannot read NVS data nor MAC address.
> Userspace application can add all those information to the DT
> using a DT overlay. Also the u-boot could parse and add it at
> some point in the future.
In case when wl1251 is statically linked into kernel image, it is loaded
and initialized before even userspace applications starts.
So no... adding NVS data or MAC address into DT or DT overlay is not a
solution.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Sebastian Reichel @ 2016-11-24 15:13 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124083329.GB13735@pali>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
Hi,
On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > Hi!
> >
> > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > ioctl?
> > >
> > > This sets temporary address and it is ioctl. IIRC same as what ethtool
> > > uses. (ifconfig is already deprecated).
> > >
> > > > And I guess we should use similar mechanism for permanent
> > > > address.
> > >
> > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
> > > address. But here we do not want to change permanent mac address. We
> > > want to tell kernel driver current permanent mac address which is
> > > stored
> >
> > Well... I'd still use similar mechanism :-).
>
> Thats problematic, because in time when wlan0 interface is registered
> into system and visible in ifconfig output it already needs to have
> permanent mac address assigned.
>
> We should assign permanent mac address before wlan0 of wl1251 is
> registered into system.
You can just add the MAC address to the NVS data, which is also
required for the device initialization.
I wonder if those information could be put into DT. Iirc some
network devices get their MAC address from DT. Maybe we can add
all NVS info to DT? How much data is it?
Userspace application can add all those information to the DT
using a DT overlay. Also the u-boot could parse and add it at
some point in the future.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: many "changed bandwidth, new config is" messages in the log
From: Johannes Berg @ 2016-11-24 15:12 UTC (permalink / raw)
To: Michal Hocko; +Cc: LKML, linux-wireless
In-Reply-To: <20161124150723.GA4776@dhcp22.suse.cz>
On Thu, 2016-11-24 at 15:07 +0000, Michal Hocko wrote:
> I have only now managed to move to 4.9-rc5 (from 4.8) and started
> seeing quite a lot of following messages
> "
> [ 346.612211] wlan0: AP c0:4a:00:f1:48:f2 changed bandwidth, new
> config is 2472 MHz, width 1 (2472/0 MHz)
> [ 352.655929] wlan0: AP c0:4a:00:f1:48:f2 changed bandwidth, new
> config is 2472 MHz, width 2 (2462/0 MHz)
> "
I don't think these messages are new in any way. checking ... nope,
it's been around that way since 3.9 :-)
> It always seems to be changing width from 1 -> 2 and back
Makes sense, that's 20 MHz <-> 40 MHz.
Did you buy a new device that says it's 40 MHz incompatible or
something? Or perhaps one of your neighbors did ... Or something is
causing interference that makes the AP switch around.
> $ dmesg | grep "changed bandwidth" | wc -l
> 42
> in 13 minutes of uptime. I have noticed this came in via 30eb1dc2c430
> ("mac80211: properly track HT/VHT operation changes").
Right, but that went into 3.9 :-)
> Is this something to be worried about?
Not at all. I suppose we could make this a debug message though, it's
not super useful when it happens OK (sometimes it causes disconnections
when we can't support the new mode, which is more relevant).
johannes
^ permalink raw reply
* [PATCH] NFC: nfcmrvl: drop duplicate header gpio.h
From: Geliang Tang @ 2016-11-24 13:58 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz
Cc: Geliang Tang, linux-wireless, linux-kernel
In-Reply-To: <15299de49216a2360976ca37ff774cae9d27d88b.1479991297.git.geliangtang@gmail.com>
Drop duplicate header gpio.h from nfcmrvl/spi.c.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/nfc/nfcmrvl/spi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nfc/nfcmrvl/spi.c b/drivers/nfc/nfcmrvl/spi.c
index a7faa0b..e2881b15 100644
--- a/drivers/nfc/nfcmrvl/spi.c
+++ b/drivers/nfc/nfcmrvl/spi.c
@@ -26,7 +26,6 @@
#include <net/nfc/nci.h>
#include <net/nfc/nci_core.h>
#include <linux/spi/spi.h>
-#include <linux/gpio.h>
#include "nfcmrvl.h"
#define SPI_WAIT_HANDSHAKE 1
--
2.9.3
^ permalink raw reply related
* [PATCH] ath5k: drop duplicate header vmalloc.h
From: Geliang Tang @ 2016-11-24 13:58 UTC (permalink / raw)
To: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Kalle Valo
Cc: Geliang Tang, linux-wireless, netdev, linux-kernel
Drop duplicate header vmalloc.h from ath5k/debug.c.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/net/wireless/ath/ath5k/debug.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index 4f8d9ed..d068df5 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -66,7 +66,6 @@
#include <linux/seq_file.h>
#include <linux/list.h>
-#include <linux/vmalloc.h>
#include "debug.h"
#include "ath5k.h"
#include "reg.h"
--
2.9.3
^ permalink raw reply related
* [PATCH v2] ath9k: Introduce airtime fairness scheduling between stations
From: Toke Høiland-Jørgensen @ 2016-11-24 13:54 UTC (permalink / raw)
To: make-wifi-fast, linux-wireless; +Cc: Toke Høiland-Jørgensen
In-Reply-To: <20160617090929.31606-1-toke@toke.dk>
This reworks the ath9k driver to schedule transmissions to connected
stations in a way that enforces airtime fairness between them. It
accomplishes this by measuring the time spent transmitting to or
receiving from a station at TX and RX completion, and accounting this to
a per-station, per-QoS level airtime deficit. Then, an FQ-CoDel based
deficit scheduler is employed at packet dequeue time, to control which
station gets the next transmission opportunity.
Airtime fairness can significantly improve the efficiency of the network
when station rates vary. The following throughput values are from a
simple three-station test scenario, where two stations operate at the
highest HT20 rate, and one station at the lowest, and the scheduler is
employed at the access point:
Before / After
Fast station 1: 19.17 / 25.09 Mbps
Fast station 2: 19.83 / 25.21 Mbps
Slow station: 2.58 / 1.77 Mbps
Total: 41.58 / 52.07 Mbps
The benefit of airtime fairness goes up the more stations are present.
In a 30-station test with one station artificially limited to 1 Mbps,
we have seen aggregate throughput go from 2.14 to 17.76 Mbps.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 28 ++++-
drivers/net/wireless/ath/ath9k/channel.c | 26 ++++-
drivers/net/wireless/ath/ath9k/debug.c | 3 +
drivers/net/wireless/ath/ath9k/debug.h | 13 +++
drivers/net/wireless/ath/ath9k/debug_sta.c | 54 +++++++++
drivers/net/wireless/ath/ath9k/init.c | 2 +
drivers/net/wireless/ath/ath9k/main.c | 6 +-
drivers/net/wireless/ath/ath9k/recv.c | 65 +++++++++++
drivers/net/wireless/ath/ath9k/xmit.c | 177 +++++++++++++++++++++--------
9 files changed, 318 insertions(+), 56 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 378d345..d16f430 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -112,6 +112,8 @@ int ath_descdma_setup(struct ath_softc *sc, struct ath_descdma *dd,
#define ATH_TXFIFO_DEPTH 8
#define ATH_TX_ERROR 0x01
+#define ATH_AIRTIME_QUANTUM 300 /* usec */
+
/* Stop tx traffic 1ms before the GO goes away */
#define ATH_P2P_PS_STOP_TIME 1000
@@ -247,6 +249,9 @@ struct ath_atx_tid {
bool has_queued;
};
+void __ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid);
+void ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid);
+
struct ath_node {
struct ath_softc *sc;
struct ieee80211_sta *sta; /* station struct we're part of */
@@ -258,9 +263,12 @@ struct ath_node {
bool sleeping;
bool no_ps_filter;
+ s64 airtime_deficit[IEEE80211_NUM_ACS];
+ u32 airtime_rx_start;
#ifdef CONFIG_ATH9K_STATION_STATISTICS
struct ath_rx_rate_stats rx_rate_stats;
+ struct ath_airtime_stats airtime_stats;
#endif
u8 key_idx[4];
@@ -317,10 +325,16 @@ struct ath_rx {
/* Channel Context */
/*******************/
+struct ath_acq {
+ struct list_head acq_new;
+ struct list_head acq_old;
+ spinlock_t lock;
+};
+
struct ath_chanctx {
struct cfg80211_chan_def chandef;
struct list_head vifs;
- struct list_head acq[IEEE80211_NUM_ACS];
+ struct ath_acq acq[IEEE80211_NUM_ACS];
int hw_queue_base;
/* do not dereference, use for comparison only */
@@ -443,6 +457,9 @@ void ath_chanctx_init(struct ath_softc *sc);
void ath_chanctx_set_channel(struct ath_softc *sc, struct ath_chanctx *ctx,
struct cfg80211_chan_def *chandef);
+void ath_acq_lock(struct ath_softc *sc, struct ath_acq *acq);
+void ath_acq_unlock(struct ath_softc *sc, struct ath_acq *acq);
+
#ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
static inline struct ath_chanctx *
@@ -575,6 +592,8 @@ void ath_txq_schedule_all(struct ath_softc *sc);
int ath_tx_init(struct ath_softc *sc, int nbufs);
int ath_txq_update(struct ath_softc *sc, int qnum,
struct ath9k_tx_queue_info *q);
+u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
+ int width, int half_gi, bool shortPreamble);
void ath_update_max_aggr_framelen(struct ath_softc *sc, int queue, int txop);
void ath_assign_seq(struct ath_common *common, struct sk_buff *skb);
int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
@@ -963,6 +982,11 @@ void ath_ant_comb_scan(struct ath_softc *sc, struct ath_rx_status *rs);
#define ATH9K_NUM_CHANCTX 2 /* supports 2 operating channels */
+#define AIRTIME_USE_TX BIT(0)
+#define AIRTIME_USE_RX BIT(1)
+#define AIRTIME_USE_NEW_QUEUES BIT(2)
+#define AIRTIME_ACTIVE(flags) (!!(flags & (AIRTIME_USE_TX|AIRTIME_USE_RX)))
+
struct ath_softc {
struct ieee80211_hw *hw;
struct device *dev;
@@ -1005,6 +1029,8 @@ struct ath_softc {
short nbcnvifs;
unsigned long ps_usecount;
+ u16 airtime_flags; /* AIRTIME_* */
+
struct ath_rx rx;
struct ath_tx tx;
struct ath_beacon beacon;
diff --git a/drivers/net/wireless/ath/ath9k/channel.c b/drivers/net/wireless/ath/ath9k/channel.c
index 929dd70..5d4d682 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -118,8 +118,11 @@ void ath_chanctx_init(struct ath_softc *sc)
INIT_LIST_HEAD(&ctx->vifs);
ctx->txpower = ATH_TXPOWER_MAX;
ctx->flush_timeout = HZ / 5; /* 200ms */
- for (j = 0; j < ARRAY_SIZE(ctx->acq); j++)
- INIT_LIST_HEAD(&ctx->acq[j]);
+ for (j = 0; j < ARRAY_SIZE(ctx->acq); j++) {
+ INIT_LIST_HEAD(&ctx->acq[j].acq_new);
+ INIT_LIST_HEAD(&ctx->acq[j].acq_old);
+ spin_lock_init(&ctx->acq[j].lock);
+ }
}
}
@@ -144,6 +147,18 @@ void ath_chanctx_set_channel(struct ath_softc *sc, struct ath_chanctx *ctx,
ath_set_channel(sc);
}
+void ath_acq_lock(struct ath_softc *sc, struct ath_acq *acq)
+ __acquires(&acq->lock)
+{
+ spin_lock_bh(&acq->lock);
+}
+
+void ath_acq_unlock(struct ath_softc *sc, struct ath_acq *acq)
+ __releases(&acq->lock)
+{
+ spin_unlock_bh(&acq->lock);
+}
+
#ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
/*************/
@@ -1345,8 +1360,11 @@ void ath9k_offchannel_init(struct ath_softc *sc)
ctx->txpower = ATH_TXPOWER_MAX;
cfg80211_chandef_create(&ctx->chandef, chan, NL80211_CHAN_HT20);
- for (i = 0; i < ARRAY_SIZE(ctx->acq); i++)
- INIT_LIST_HEAD(&ctx->acq[i]);
+ for (i = 0; i < ARRAY_SIZE(ctx->acq); i++) {
+ INIT_LIST_HEAD(&ctx->acq[i].acq_new);
+ INIT_LIST_HEAD(&ctx->acq[i].acq_old);
+ spin_lock_init(&ctx->acq[i].lock);
+ }
sc->offchannel.chan.offchannel = true;
}
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 89a94dd..43930c3 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1399,5 +1399,8 @@ int ath9k_init_debug(struct ath_hw *ah)
debugfs_create_file("tpc", S_IRUSR | S_IWUSR,
sc->debug.debugfs_phy, sc, &fops_tpc);
+ debugfs_create_u16("airtime_flags", S_IRUSR | S_IWUSR,
+ sc->debug.debugfs_phy, &sc->airtime_flags);
+
return 0;
}
diff --git a/drivers/net/wireless/ath/ath9k/debug.h b/drivers/net/wireless/ath/ath9k/debug.h
index a078cdd..249f814 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -221,6 +221,11 @@ struct ath_rx_rate_stats {
} cck_stats[4];
};
+struct ath_airtime_stats {
+ u32 rx_airtime;
+ u32 tx_airtime;
+};
+
#define ANT_MAIN 0
#define ANT_ALT 1
@@ -314,12 +319,20 @@ ath9k_debug_sync_cause(struct ath_softc *sc, u32 sync_cause)
void ath_debug_rate_stats(struct ath_softc *sc,
struct ath_rx_status *rs,
struct sk_buff *skb);
+void ath_debug_airtime(struct ath_softc *sc,
+ struct ath_node *an,
+ u32 rx, u32 tx);
#else
static inline void ath_debug_rate_stats(struct ath_softc *sc,
struct ath_rx_status *rs,
struct sk_buff *skb)
{
}
+static inline void ath_debug_airtime(struct ath_softc *sc,
+ struct ath_node *an,
+ u32 rx, u32 tx)
+{
+}
#endif /* CONFIG_ATH9K_STATION_STATISTICS */
#endif /* DEBUG_H */
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c b/drivers/net/wireless/ath/ath9k/debug_sta.c
index 2a3a3c4..524cbf13 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -242,6 +242,59 @@ static const struct file_operations fops_node_recv = {
.llseek = default_llseek,
};
+void ath_debug_airtime(struct ath_softc *sc,
+ struct ath_node *an,
+ u32 rx,
+ u32 tx)
+{
+ struct ath_airtime_stats *astats = &an->airtime_stats;
+
+ astats->rx_airtime += rx;
+ astats->tx_airtime += tx;
+}
+
+static ssize_t read_airtime(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath_node *an = file->private_data;
+ struct ath_airtime_stats *astats;
+ static const char *qname[4] = {
+ "VO", "VI", "BE", "BK"
+ };
+ u32 len = 0, size = 256;
+ char *buf;
+ size_t retval;
+ int i;
+
+ buf = kzalloc(size, GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
+ astats = &an->airtime_stats;
+
+ len += scnprintf(buf + len, size - len, "RX: %u us\n", astats->rx_airtime);
+ len += scnprintf(buf + len, size - len, "TX: %u us\n", astats->tx_airtime);
+ len += scnprintf(buf + len, size - len, "Deficit: ");
+ for (i = 0; i < 4; i++)
+ len += scnprintf(buf+len, size - len, "%s: %lld us ", qname[i], an->airtime_deficit[i]);
+ if (len < size)
+ buf[len++] = '\n';
+
+ retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ kfree(buf);
+
+ return retval;
+}
+
+
+static const struct file_operations fops_airtime = {
+ .read = read_airtime,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
+
void ath9k_sta_add_debugfs(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
@@ -251,4 +304,5 @@ void ath9k_sta_add_debugfs(struct ieee80211_hw *hw,
debugfs_create_file("node_aggr", S_IRUGO, dir, an, &fops_node_aggr);
debugfs_create_file("node_recv", S_IRUGO, dir, an, &fops_node_recv);
+ debugfs_create_file("airtime", S_IRUGO, dir, an, &fops_airtime);
}
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index c0c8bf0..5aa665f 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -620,6 +620,8 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
/* Will be cleared in ath9k_start() */
set_bit(ATH_OP_INVALID, &common->op_flags);
+ sc->airtime_flags = (AIRTIME_USE_TX | AIRTIME_USE_RX |
+ AIRTIME_USE_NEW_QUEUES);
sc->sc_ah = ah;
sc->dfs_detector = dfs_pattern_detector_init(common, NL80211_DFS_UNSET);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 59e3bd0..58f06ce 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -70,10 +70,10 @@ static bool ath9k_has_pending_frames(struct ath_softc *sc, struct ath_txq *txq,
goto out;
if (txq->mac80211_qnum >= 0) {
- struct list_head *list;
+ struct ath_acq *acq;
- list = &sc->cur_chan->acq[txq->mac80211_qnum];
- if (!list_empty(list))
+ acq = &sc->cur_chan->acq[txq->mac80211_qnum];
+ if (!list_empty(&acq->acq_new) || !list_empty(&acq->acq_old))
pending = true;
}
out:
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6697342..9f3880d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -991,6 +991,70 @@ static void ath9k_apply_ampdu_details(struct ath_softc *sc,
}
}
+static void ath_rx_count_airtime(struct ath_softc *sc,
+ struct ath_rx_status *rs,
+ struct sk_buff *skb)
+{
+ struct ath_node *an;
+ struct ath_acq *acq;
+ struct ath_vif *avp;
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
+ struct ieee80211_sta *sta;
+ struct ieee80211_rx_status *rxs;
+ const struct ieee80211_rate *rate;
+ bool is_sgi, is_40, is_sp;
+ int phy;
+ u16 len = rs->rs_datalen;
+ u32 airtime = 0;
+ u8 tidno, acno;
+
+ if (!ieee80211_is_data(hdr->frame_control))
+ return;
+
+ rcu_read_lock();
+
+ sta = ieee80211_find_sta_by_ifaddr(sc->hw, hdr->addr2, NULL);
+ if (!sta)
+ goto exit;
+ an = (struct ath_node *) sta->drv_priv;
+ avp = (struct ath_vif *) an->vif->drv_priv;
+ tidno = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
+ acno = TID_TO_WME_AC(tidno);
+ acq = &avp->chanctx->acq[acno];
+
+ rxs = IEEE80211_SKB_RXCB(skb);
+
+ is_sgi = !!(rxs->flag & RX_FLAG_SHORT_GI);
+ is_40 = !!(rxs->flag & RX_FLAG_40MHZ);
+ is_sp = !!(rxs->flag & RX_FLAG_SHORTPRE);
+
+ if (!!(rxs->flag & RX_FLAG_HT)) {
+ /* MCS rates */
+
+ airtime += ath_pkt_duration(sc, rxs->rate_idx, len,
+ is_40, is_sgi, is_sp);
+ } else {
+
+ phy = IS_CCK_RATE(rs->rs_rate) ? WLAN_RC_PHY_CCK : WLAN_RC_PHY_OFDM;
+ rate = &common->sbands[rxs->band].bitrates[rxs->rate_idx];
+ airtime += ath9k_hw_computetxtime(ah, phy, rate->bitrate * 100,
+ len, rxs->rate_idx, is_sp);
+ }
+
+ if (!!(sc->airtime_flags & AIRTIME_USE_RX)) {
+ ath_acq_lock(sc, acq);
+ an->airtime_deficit[acno] -= airtime;
+ if (an->airtime_deficit[acno] <= 0)
+ __ath_tx_queue_tid(sc, ATH_AN_2_TID(an, tidno));
+ ath_acq_unlock(sc, acq);
+ }
+ ath_debug_airtime(sc, an, airtime, 0);
+exit:
+ rcu_read_unlock();
+}
+
int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
{
struct ath_rxbuf *bf;
@@ -1137,6 +1201,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
ath9k_antenna_check(sc, &rs);
ath9k_apply_ampdu_details(sc, &rs, rxs);
ath_debug_rate_stats(sc, &rs, skb);
+ ath_rx_count_airtime(sc, &rs, skb);
hdr = (struct ieee80211_hdr *)skb->data;
if (ieee80211_is_ack(hdr->frame_control))
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 486afa9..7386e93 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -124,21 +124,44 @@ void ath_txq_unlock_complete(struct ath_softc *sc, struct ath_txq *txq)
ath_tx_status(hw, skb);
}
-static void ath_tx_queue_tid(struct ath_softc *sc, struct ath_txq *txq,
- struct ath_atx_tid *tid)
+void __ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
{
- struct list_head *list;
struct ath_vif *avp = (struct ath_vif *) tid->an->vif->drv_priv;
struct ath_chanctx *ctx = avp->chanctx;
+ struct ath_acq *acq;
+ struct list_head *tid_list;
+ u8 acno = TID_TO_WME_AC(tid->tidno);
- if (!ctx)
+ if (!ctx || !list_empty(&tid->list))
return;
- list = &ctx->acq[TID_TO_WME_AC(tid->tidno)];
- if (list_empty(&tid->list))
- list_add_tail(&tid->list, list);
+
+ acq = &ctx->acq[acno];
+ if ((sc->airtime_flags & AIRTIME_USE_NEW_QUEUES) &&
+ tid->an->airtime_deficit[acno] > 0)
+ tid_list = &acq->acq_new;
+ else
+ tid_list = &acq->acq_old;
+
+ list_add_tail(&tid->list, tid_list);
}
+void ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
+{
+ struct ath_vif *avp = (struct ath_vif *) tid->an->vif->drv_priv;
+ struct ath_chanctx *ctx = avp->chanctx;
+ struct ath_acq *acq;
+
+ if (!ctx || !list_empty(&tid->list))
+ return;
+
+ acq = &ctx->acq[TID_TO_WME_AC(tid->tidno)];
+ ath_acq_lock(sc, acq);
+ __ath_tx_queue_tid(sc, tid);
+ ath_acq_unlock(sc, acq);
+}
+
+
void ath9k_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *queue)
{
struct ath_softc *sc = hw->priv;
@@ -153,7 +176,7 @@ void ath9k_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *queue)
ath_txq_lock(sc, txq);
tid->has_queued = true;
- ath_tx_queue_tid(sc, txq, tid);
+ ath_tx_queue_tid(sc, tid);
ath_txq_schedule(sc, txq);
ath_txq_unlock(sc, txq);
@@ -660,7 +683,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
skb_queue_splice_tail(&bf_pending, &tid->retry_q);
if (!an->sleeping) {
- ath_tx_queue_tid(sc, txq, tid);
+ ath_tx_queue_tid(sc, tid);
if (ts->ts_status & (ATH9K_TXERR_FILT | ATH9K_TXERR_XRETRY))
tid->clear_ps_filter = true;
@@ -688,6 +711,53 @@ static bool bf_is_ampdu_not_probing(struct ath_buf *bf)
return bf_isampdu(bf) && !(info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE);
}
+static void ath_tx_count_airtime(struct ath_softc *sc, struct ath_txq *txq,
+ struct ath_buf *bf, struct ath_tx_status *ts)
+{
+ struct ath_node *an;
+ struct ath_acq *acq = &sc->cur_chan->acq[txq->mac80211_qnum];
+ struct sk_buff *skb;
+ struct ieee80211_hdr *hdr;
+ struct ieee80211_hw *hw = sc->hw;
+ struct ieee80211_tx_rate rates[4];
+ struct ieee80211_sta *sta;
+ int i;
+ u32 airtime = 0;
+
+ skb = bf->bf_mpdu;
+ if(!skb)
+ return;
+
+ hdr = (struct ieee80211_hdr *)skb->data;
+ memcpy(rates, bf->rates, sizeof(rates));
+
+ rcu_read_lock();
+
+ sta = ieee80211_find_sta_by_ifaddr(hw, hdr->addr1, hdr->addr2);
+ if(!sta)
+ goto exit;
+
+
+ an = (struct ath_node *) sta->drv_priv;
+
+ airtime += ts->duration * (ts->ts_longretry + 1);
+
+ for(i=0; i < ts->ts_rateindex; i++)
+ airtime += ath9k_hw_get_duration(sc->sc_ah, bf->bf_desc, i) * rates[i].count;
+
+ if (!!(sc->airtime_flags & AIRTIME_USE_TX)) {
+ ath_acq_lock(sc, acq);
+ an->airtime_deficit[txq->mac80211_qnum] -= airtime;
+ if (an->airtime_deficit[txq->mac80211_qnum] <= 0)
+ __ath_tx_queue_tid(sc, ath_get_skb_tid(sc, an, skb));
+ ath_acq_unlock(sc, acq);
+ }
+ ath_debug_airtime(sc, an, 0, airtime);
+
+exit:
+ rcu_read_unlock();
+}
+
static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
struct ath_tx_status *ts, struct ath_buf *bf,
struct list_head *bf_head)
@@ -709,6 +779,7 @@ static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
ts->duration = ath9k_hw_get_duration(sc->sc_ah, bf->bf_desc,
ts->ts_rateindex);
+ ath_tx_count_airtime(sc, txq, bf, ts);
hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data;
sta = ieee80211_find_sta_by_ifaddr(hw, hdr->addr1, hdr->addr2);
@@ -1068,8 +1139,8 @@ ath_tx_form_aggr(struct ath_softc *sc, struct ath_txq *txq,
* width - 0 for 20 MHz, 1 for 40 MHz
* half_gi - to use 4us v/s 3.6 us for symbol time
*/
-static u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
- int width, int half_gi, bool shortPreamble)
+u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
+ int width, int half_gi, bool shortPreamble)
{
u32 nbits, nsymbits, duration, nsymbols;
int streams;
@@ -1467,7 +1538,7 @@ ath_tx_form_burst(struct ath_softc *sc, struct ath_txq *txq,
}
static bool ath_tx_sched_aggr(struct ath_softc *sc, struct ath_txq *txq,
- struct ath_atx_tid *tid, bool *stop)
+ struct ath_atx_tid *tid)
{
struct ath_buf *bf;
struct ieee80211_tx_info *tx_info;
@@ -1489,7 +1560,6 @@ static bool ath_tx_sched_aggr(struct ath_softc *sc, struct ath_txq *txq,
if ((aggr && txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH) ||
(!aggr && txq->axq_depth >= ATH_NON_AGGR_MIN_QDEPTH)) {
__skb_queue_tail(&tid->retry_q, bf->bf_mpdu);
- *stop = true;
return false;
}
@@ -1613,7 +1683,7 @@ void ath_tx_aggr_wakeup(struct ath_softc *sc, struct ath_node *an)
ath_txq_lock(sc, txq);
tid->clear_ps_filter = true;
if (ath_tid_has_buffered(tid)) {
- ath_tx_queue_tid(sc, txq, tid);
+ ath_tx_queue_tid(sc, tid);
ath_txq_schedule(sc, txq);
}
ath_txq_unlock_complete(sc, txq);
@@ -1912,9 +1982,10 @@ void ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq)
void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq)
{
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
- struct ath_atx_tid *tid, *last_tid;
+ struct ath_atx_tid *tid;
struct list_head *tid_list;
- bool sent = false;
+ struct ath_acq *acq;
+ bool active = AIRTIME_ACTIVE(sc->airtime_flags);
if (txq->mac80211_qnum < 0)
return;
@@ -1923,48 +1994,55 @@ void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq)
return;
spin_lock_bh(&sc->chan_lock);
- tid_list = &sc->cur_chan->acq[txq->mac80211_qnum];
-
- if (list_empty(tid_list)) {
- spin_unlock_bh(&sc->chan_lock);
- return;
- }
-
rcu_read_lock();
+ acq = &sc->cur_chan->acq[txq->mac80211_qnum];
- last_tid = list_entry(tid_list->prev, struct ath_atx_tid, list);
- while (!list_empty(tid_list)) {
- bool stop = false;
-
- if (sc->cur_chan->stopped)
- break;
-
- tid = list_first_entry(tid_list, struct ath_atx_tid, list);
- list_del_init(&tid->list);
+ if (sc->cur_chan->stopped)
+ goto out;
- if (ath_tx_sched_aggr(sc, txq, tid, &stop))
- sent = true;
+begin:
+ tid_list = &acq->acq_new;
+ if (list_empty(tid_list)) {
+ tid_list = &acq->acq_old;
+ if (list_empty(tid_list))
+ goto out;
+ }
+ tid = list_first_entry(tid_list, struct ath_atx_tid, list);
- /*
- * add tid to round-robin queue if more frames
- * are pending for the tid
- */
- if (ath_tid_has_buffered(tid))
- ath_tx_queue_tid(sc, txq, tid);
+ if (active && tid->an->airtime_deficit[txq->mac80211_qnum] <= 0) {
+ ath_acq_lock(sc, acq);
+ tid->an->airtime_deficit[txq->mac80211_qnum] += ATH_AIRTIME_QUANTUM;
+ list_move_tail(&tid->list, &acq->acq_old);
+ ath_acq_unlock(sc, acq);
+ goto begin;
+ }
- if (stop)
- break;
+ if (!ath_tid_has_buffered(tid)) {
+ ath_acq_lock(sc, acq);
+ if ((tid_list == &acq->acq_new) && !list_empty(&acq->acq_old))
+ list_move_tail(&tid->list, &acq->acq_old);
+ else {
+ list_del_init(&tid->list);
+ }
+ ath_acq_unlock(sc, acq);
+ goto begin;
+ }
- if (tid == last_tid) {
- if (!sent)
- break;
- sent = false;
- last_tid = list_entry(tid_list->prev,
- struct ath_atx_tid, list);
+ /*
+ * If we succeed in scheduling something, immediately restart to make
+ * sure we keep the HW busy.
+ */
+ if(ath_tx_sched_aggr(sc, txq, tid)) {
+ if (!active) {
+ ath_acq_lock(sc, acq);
+ list_move_tail(&tid->list, &acq->acq_old);
+ ath_acq_unlock(sc, acq);
}
+ goto begin;
}
+out:
rcu_read_unlock();
spin_unlock_bh(&sc->chan_lock);
}
@@ -2818,6 +2896,9 @@ void ath_tx_node_init(struct ath_softc *sc, struct ath_node *an)
struct ath_atx_tid *tid;
int tidno, acno;
+ for (acno = 0; acno < IEEE80211_NUM_ACS; acno++)
+ an->airtime_deficit[acno] = ATH_AIRTIME_QUANTUM;
+
for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
tid = ath_node_to_tid(an, tidno);
tid->an = an;
base-commit: 705d7aa062203226c8df73f18622664e30bd8a61
--
2.10.2
^ permalink raw reply related
* RE: [PATCH] mwifiex: pcie: implement timeout loop for FW programming doorbell
From: Amitkumar Karwar @ 2016-11-24 13:16 UTC (permalink / raw)
To: Brian Norris, Nishant Sarmukadam
Cc: linux-kernel@vger.kernel.org, Kalle Valo,
linux-wireless@vger.kernel.org, Cathy Luo, Dmitry Torokhov
In-Reply-To: <1479868785-16263-1-git-send-email-briannorris@chromium.org>
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Wednesday, November 23, 2016 8:10 AM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: linux-kernel@vger.kernel.org; Kalle Valo; linux-
> wireless@vger.kernel.org; Cathy Luo; Dmitry Torokhov; Brian Norris
> Subject: [PATCH] mwifiex: pcie: implement timeout loop for FW
> programming doorbell
>
> Marvell Wifi PCIe modules don't always behave nicely for PCIe power
> management when their firmware hasn't been loaded, particularly after
> suspending the PCIe link one or more times. When this happens, we might
> end up spinning forever in this status-polling tight loop. Let's make
> this less tight by adding a timeout and by sleeping a bit in between
> reads, as we do with the other similar loops.
>
> This prevents us from hogging a CPU even in such pathological cases,
> and allows the FW initialization to just fail gracefully instead.
>
> I chose the same polling parameters as the earlier loop in this
> function, and empirically, I found that this loop never makes it more
> than about 12 cycles in a sane FW init sequence. I had no official
> information on the actual intended latency for this portion of the
> download.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 4b89f557d0b6..9f9ea1350591 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -2050,7 +2050,7 @@ static int mwifiex_prog_fw_w_helper(struct
> mwifiex_adapter *adapter,
> }
>
> /* Wait for the command done interrupt */
> - do {
> + for (tries = 0; tries < MAX_POLL_TRIES; tries++) {
> if (mwifiex_read_reg(adapter, PCIE_CPU_INT_STATUS,
> &ireg_intr)) {
> mwifiex_dbg(adapter, ERROR,
> @@ -2062,8 +2062,18 @@ static int mwifiex_prog_fw_w_helper(struct
> mwifiex_adapter *adapter,
> ret = -1;
> goto done;
> }
> - } while ((ireg_intr & CPU_INTR_DOOR_BELL) ==
> - CPU_INTR_DOOR_BELL);
> + if (!(ireg_intr & CPU_INTR_DOOR_BELL))
> + break;
> + usleep_range(10, 20);
> + }
> + if (ireg_intr & CPU_INTR_DOOR_BELL) {
> + mwifiex_dbg(adapter, ERROR, "%s: Card failed to ACK
> download\n",
> + __func__);
> + mwifiex_unmap_pci_memory(adapter, skb,
> + PCI_DMA_TODEVICE);
> + ret = -1;
> + goto done;
> + }
>
> mwifiex_unmap_pci_memory(adapter, skb, PCI_DMA_TODEVICE);
>
Patch looks fine to me.
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Regards,
Amitkumar
^ 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