* Re: [PATCH] ath10k: add report MIC error for sdio chip
From: Kalle Valo @ 2019-06-25 13:16 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, linux-wireless
In-Reply-To: <1559010432-1005-1-git-send-email-wgong@codeaurora.org>
Wen Gong <wgong@codeaurora.org> wrote:
> Firmware will report flag with HTT_RX_IND_MPDU_STATUS_TKIP_MIC_ERR
> if MIC error, the flag will be used in mac80211.
>
> ieee80211_rx_h_michael_mic_verify will check the flag and start TKIP
> countermeasures.
>
> Now countermeasure tests pass both with WPA only and WPA2/WPA mixed
> mode.
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-00007-QCARMSWP-1.
>
> Signed-off-by: Wen Gong <wgong@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
47ed1b4e5d62 ath10k: add report MIC error for sdio chip
--
https://patchwork.kernel.org/patch/10963647/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v5] ath10k: add support for controlling tx power to a station
From: Kalle Valo @ 2019-06-25 13:14 UTC (permalink / raw)
To: Balaji Pothunoori
Cc: ath10k, linux-wireless, Ashok Raj Nagarajan, Balaji Pothunoori
In-Reply-To: <1559209638-23887-1-git-send-email-bpothuno@codeaurora.org>
Balaji Pothunoori <bpothuno@codeaurora.org> wrote:
> This patch will add the support to control the transmit power for traffic
> to a station associated with the AP.
>
> Underlying firmware will enforce that the maximum tx power will be based
> on the regulatory requirements. If the user given transmit power is greater
> than the allowed tx power in the given channel, then the firmware will use
> the maximum tx power in the same channel.
>
> Max and Min tx power values will depends on no of tx chain masks,
> for QCA9984 allowed tx power range values from 6 to 23.
>
> When 0 is sent to the firmware as tx power, it will revert to the default
> tx power for the station.
>
> Tested Hardware : QCA9984
> Tested Firmware : 10.4-3.9.0.2-00046
>
> Co-developed-by: Balaji Pothunoori <bpothuno@codeaurora.org>
> Signed-off-by: Ashok Raj Nagarajan <arnagara@codeaurora.org>
> Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
33410a51468f ath10k: add support for controlling tx power to a station
--
https://patchwork.kernel.org/patch/10968517/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Add peer delete response event
From: Kalle Valo @ 2019-06-25 13:13 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless, Dundi Raviteja, Rakesh Pillai
In-Reply-To: <1550673001-8779-1-git-send-email-pillair@codeaurora.org>
Rakesh Pillai <pillair@codeaurora.org> wrote:
> Peer creation in firmware fails if last peer deletion is still
> in progress.
>
> The firmware sends a peer delete response event if it advertises
> the service WMI_SERVICE_SYNC_DELETE_CMDS. This peer delete response
> event is used to synchronize the peer deletion.
>
> Add peer delete response event and wait for the event after
> deleting every peer from host driver to synchronize with firmware.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
>
> Signed-off-by: Dundi Raviteja <dundi@codeaurora.org>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
c6f537a11b81 ath10k: Add peer delete response event
--
https://patchwork.kernel.org/patch/10822207/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: wait for vdev delete response from firmware
From: Kalle Valo @ 2019-06-25 13:11 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless, Rakesh Pillai
In-Reply-To: <1550411479-32253-1-git-send-email-pillair@codeaurora.org>
Rakesh Pillai <pillair@codeaurora.org> wrote:
> When we add an interface immediately after removing
> the interface the vdev deletion in firmware might not
> have been completed. We need to synchronize the vdev creation
> with the firmware.
>
> Wait for vdev delete response from firmware when we
> remove an interface.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
fe36e70f766e ath10k: wait for vdev delete response from firmware
--
https://patchwork.kernel.org/patch/10817047/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: fix PCIE device wake up failed
From: Kalle Valo @ 2019-06-25 13:03 UTC (permalink / raw)
To: Miaoqing Pan; +Cc: ath10k, linux-wireless, Miaoqing Pan
In-Reply-To: <1559180960-13565-1-git-send-email-miaoqing@codeaurora.org>
Miaoqing Pan <miaoqing@codeaurora.org> wrote:
> Observed PCIE device wake up failed after ~120 iterations of
> soft-reboot test. The error message is
> "ath10k_pci 0000:01:00.0: failed to wake up device : -110"
>
> The call trace as below:
> ath10k_pci_probe -> ath10k_pci_force_wake -> ath10k_pci_wake_wait ->
> ath10k_pci_is_awake
>
> Once trigger the device to wake up, we will continuously check the RTC
> state until it returns RTC_STATE_V_ON or timeout.
>
> But for QCA99x0 chips, we use wrong value for RTC_STATE_V_ON.
> Occasionally, we get 0x7 on the fist read, we thought as a failure
> case, but actually is the right value, also verified with the spec.
> So fix the issue by changing RTC_STATE_V_ON from 0x5 to 0x7, passed
> ~2000 iterations.
>
> Tested HW: QCA9984
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
011d4111c8c6 ath10k: fix PCIE device wake up failed
--
https://patchwork.kernel.org/patch/10968039/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: iwl_mvm_add_new_dqa_stream_wk BUG in lib/list_debug.c:56
From: Marc Haber @ 2019-06-25 13:03 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev
In-Reply-To: <20190602134842.GC3249@torres.zugschlus.de>
On Sun, Jun 02, 2019 at 03:48:42PM +0200, Marc Haber wrote:
> On Thu, May 30, 2019 at 10:12:57AM +0200, Marc Haber wrote:
> > on my primary notebook, a Lenovo X260, with an Intel Wireless 8260
> > (8086:24f3), running Debian unstable, I have started to see network
> > hangs since upgrading to kernel 5.1. In this situation, I cannot
> > restart Network-Manager (the call just hangs), I can log out of X, but
> > the system does not cleanly shut down and I need to Magic SysRq myself
> > out of the running system. This happens about once every two days.
>
> The issue is also present in 5.1.5 and 5.1.6.
Almost a month later, 5.1.15 still crashes about twice a day on my
Notebook. The error message seems pretty clear to me, how can I go on
from there and may be identify a line number outside of a library?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [PATCH v2] ath10k: fix failure to set multiple fixed rate
From: Kalle Valo @ 2019-06-25 13:02 UTC (permalink / raw)
To: Miaoqing Pan; +Cc: ath10k, linux-wireless, Miaoqing Pan
In-Reply-To: <1559117608-11117-1-git-send-email-miaoqing@codeaurora.org>
Miaoqing Pan <miaoqing@codeaurora.org> wrote:
> Currently, below fixed rate commands are broken,
> iw wlanx set bitrates legacy-<2.4|5> ht-mcs-<2.4|5> vht-mcs-<2.4|5> \
> <NSS:MCSx>
> iw wlanx set bitrates legacy-<2.4|5> <legacy rate> ht-mcs-<2.4|5> \
> vht-mcs-<2.4|5> <NSS:MCSx>
>
> There are two methods to set fixed rate, both failed,
> - Use vdev fixed rate command
> This command only support one single rate, but it's broken due to
> mac80211 change commit e8e4f5280ddd ("mac80211: reject/clear user
> rate mask if not usable"), which requires user to specify at least
> one legacy rate. So we can't use this command to set ht/vht single
> rate any more.
> - Use peer_assoc command
> This command can update rx capability for multiple rates, it will
> work fine for ht mcs rates, as each supported mcs can be advertised
> in ht_mcs index mask. But this will not work with vht rates because,
> as per the vht mcs capability advertisement, there are only two bits
> to indicate the supported mcs. E.g. only support 0-7, 0-8, 0-9.
>
> So introduced new WMI command: WMI_PEER_PARAM_FIXED_RATE. After peer
> assoc, the peer fixed rate cmd will work for that specific peer.
> Remaining peers will use auto rate. If both vdev fixed rate and peer
> fixed rates are given, peer fixed rate will take effect to peers for
> which this cmd is given. Remaining peers in that vdev, will use vdev
> fixed rate.
>
> Tested HW: QCA9984
> Tested FW: 10.4-3.9.0.2-00035
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
8b97b055dc9d ath10k: fix failure to set multiple fixed rate
--
https://patchwork.kernel.org/patch/10966425/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Change the warning message string
From: Kalle Valo @ 2019-06-25 13:00 UTC (permalink / raw)
To: Fabio Estevam; +Cc: ath10k, andreyknvl, gregkh, linux-wireless, Fabio Estevam
In-Reply-To: <20190509121500.4730-1-festevam@gmail.com>
Fabio Estevam <festevam@gmail.com> wrote:
> The "WARNING" string confuses syzbot, which thinks it found
> a crash [1].
>
> Change the string to avoid such problem.
>
> [1] https://lkml.org/lkml/2019/5/9/243
>
> Reported-by: syzbot+c1b25598aa60dcd47e78@syzkaller.appspotmail.com
> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
265df32eae58 ath10k: Change the warning message string
--
https://patchwork.kernel.org/patch/10937077/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: fix fw crash by moving chip reset after napi disabled
From: Kalle Valo @ 2019-06-25 12:59 UTC (permalink / raw)
To: Miaoqing Pan; +Cc: ath10k, linux-wireless, Miaoqing Pan
In-Reply-To: <1558667782-10998-1-git-send-email-miaoqing@codeaurora.org>
Miaoqing Pan <miaoqing@codeaurora.org> wrote:
> On SMP platform, when continuously running wifi up/down, the napi
> poll can be scheduled during chip reset, which will call
> ath10k_pci_has_fw_crashed() to check the fw status. But in the reset
> period, the value from FW_INDICATOR_ADDRESS register will return
> 0xdeadbeef, which also be treated as fw crash. Fix the issue by
> moving chip reset after napi disabled.
>
> ath10k_pci 0000:01:00.0: firmware crashed! (guid 73b30611-5b1e-4bdd-90b4-64c81eb947b6)
> ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
> ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
> ath10k_pci 0000:01:00.0: failed to get memcpy hi address for firmware address 4: -16
> ath10k_pci 0000:01:00.0: failed to read firmware dump area: -16
> ath10k_pci 0000:01:00.0: Copy Engine register dump:
> ath10k_pci 0000:01:00.0: [00]: 0x0004a000 0 0 0 0
> ath10k_pci 0000:01:00.0: [01]: 0x0004a400 0 0 0 0
> ath10k_pci 0000:01:00.0: [02]: 0x0004a800 0 0 0 0
> ath10k_pci 0000:01:00.0: [03]: 0x0004ac00 0 0 0 0
> ath10k_pci 0000:01:00.0: [04]: 0x0004b000 0 0 0 0
> ath10k_pci 0000:01:00.0: [05]: 0x0004b400 0 0 0 0
> ath10k_pci 0000:01:00.0: [06]: 0x0004b800 0 0 0 0
> ath10k_pci 0000:01:00.0: [07]: 0x0004bc00 1 0 1 0
> ath10k_pci 0000:01:00.0: [08]: 0x0004c000 0 0 0 0
> ath10k_pci 0000:01:00.0: [09]: 0x0004c400 0 0 0 0
> ath10k_pci 0000:01:00.0: [10]: 0x0004c800 0 0 0 0
> ath10k_pci 0000:01:00.0: [11]: 0x0004cc00 0 0 0 0
>
> Tested HW: QCA9984,QCA9887,WCN3990
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
08d80e4cd27b ath10k: fix fw crash by moving chip reset after napi disabled
--
https://patchwork.kernel.org/patch/10959057/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: add missing error handling
From: Kalle Valo @ 2019-06-25 12:58 UTC (permalink / raw)
To: Claire Chang; +Cc: ath10k, linux-wireless, wgong, Claire Chang
In-Reply-To: <20190523071534.254611-1-tientzu@chromium.org>
Claire Chang <tientzu@chromium.org> wrote:
> In function ath10k_sdio_mbox_rx_alloc() [sdio.c],
> ath10k_sdio_mbox_alloc_rx_pkt() is called without handling the error cases.
> This will make the driver think the allocation for skb is successful and
> try to access the skb. If we enable failslab, system will easily crash with
> NULL pointer dereferencing.
>
> Call trace of CONFIG_FAILSLAB:
> ath10k_sdio_irq_handler+0x570/0xa88 [ath10k_sdio]
> process_sdio_pending_irqs+0x4c/0x174
> sdio_run_irqs+0x3c/0x64
> sdio_irq_work+0x1c/0x28
>
> Fixes: d96db25d2025 ("ath10k: add initial SDIO support")
> Signed-off-by: Claire Chang <tientzu@chromium.org>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
4b553f3ca4cb ath10k: add missing error handling
--
https://patchwork.kernel.org/patch/10957013/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: enabling tx stats support over pktlog
From: Kalle Valo @ 2019-06-25 12:56 UTC (permalink / raw)
To: Balaji Pothunoori; +Cc: ath10k, linux-wireless, Balaji Pothunoori
In-Reply-To: <1557759187-23910-1-git-send-email-bpothuno@codeaurora.org>
Balaji Pothunoori <bpothuno@codeaurora.org> wrote:
> For QCA988X target, pktlog gives details of the tx bitrate
> which is used in the driver for station info.
>
> Enabling pktlog by default will cause more interrupts
> in target to host CE pipe, which can impact more CPU usage
> for targets ex:WCN3990 and also not required for all other
> platforms (eg: WCN3990), for getting tx bitrate.
>
> Enable pktlog only for QCA988X based on hardware params.
>
> Tested HW : WCN3990
> Tested FW : WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Fixes: e8123bb74c4e ("ath10k: add per peer tx stats support for 10.2.4")
> Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
4fa42adebe5b ath10k: enabling tx stats support over pktlog
--
https://patchwork.kernel.org/patch/10941167/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: acquire lock to fix lockdep's warning
From: Kalle Valo @ 2019-06-25 12:55 UTC (permalink / raw)
To: Claire Chang; +Cc: linux-wireless, ath10k, wgong, drinkcat, Claire Chang
In-Reply-To: <20190506073836.184059-1-tientzu@chromium.org>
Claire Chang <tientzu@chromium.org> wrote:
> Lockdep warns at lockdep_assert_held(&ar->data_lock) in
> ath10k_htt_rx_pn_check_replay_hl(). Acquire ar->data_lock before calling
> ath10k_htt_rx_pn_check_replay_hl() to fix it.
>
> Call trace:
> ath10k_htt_rx_pn_check_replay_hl+0x118/0x134 [ath10k_core]
> ath10k_htt_rx_proc_rx_ind_hl+0xd8/0x250 [ath10k_core]
> ath10k_htt_t2h_msg_handler+0x148/0xf30 [ath10k_core]
> ath10k_htt_htc_t2h_msg_handler+0x24/0x40 [ath10k_core]
> ath10k_sdio_irq_handler+0x374/0xaa4 [ath10k_sdio]
>
> Fixes: 130c77495708 ("ath10k: add PN replay protection for high latency devices")
> Signed-off-by: Claire Chang <tientzu@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
ef9cc0c44394 ath10k: acquire lock to fix lockdep's warning
--
https://patchwork.kernel.org/patch/10930667/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: change firmware file name for UTF mode of SDIO/USB
From: Kalle Valo @ 2019-06-25 12:54 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, linux-wireless
In-Reply-To: <1557891047-16606-1-git-send-email-wgong@codeaurora.org>
Wen Gong <wgong@codeaurora.org> wrote:
> Firmware name for UTF mode of SDIO has changed from utf-2.bin to
> utf-sdio-2.bin, so it need to change in ath10k, otherwise it will
> fail for UTF mode.
>
> After change the name in ath10k, it will success for UTF mode of
> SDIO/USB.
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-00007-QCARMSWP-1.
>
> Signed-off-by: Wen Gong <wgong@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
54f6643bf19e ath10k: change firmware file name for UTF mode of SDIO/USB
--
https://patchwork.kernel.org/patch/10944213/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3] ath10k: add support for firmware crash recovery on SDIO chip
From: Kalle Valo @ 2019-06-25 12:53 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, linux-wireless
In-Reply-To: <1558506776-19702-1-git-send-email-wgong@codeaurora.org>
Wen Gong <wgong@codeaurora.org> wrote:
> The command to simulate firmware crash:
> echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash
>
> It will send WMI_FORCE_FW_HANG_ASSERT to firmware, then it will trigger
> CPU interrupt status register for SDIO chip, ath10k driver need to
> configure it while enable SDIO interrupt, otherwise ath10k driver will
> not get the assert error info.
>
> After this change, it will success for simulate firmware crash.
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-00007-QCARMSWP-1.
>
> Signed-off-by: Wen Gong <wgong@codeaurora.org>
> Tested-by: Claire Chang <tientzu@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
0f132ba7ac64 ath10k: add support for firmware crash recovery on SDIO chip
--
https://patchwork.kernel.org/patch/10955189/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCHv2] ath10k: Add wrapper function to ath10k debug
From: Kalle Valo @ 2019-06-25 12:49 UTC (permalink / raw)
To: Venkateswara Naralasetty
Cc: ath10k, linux-wireless, Venkateswara Naralasetty, Kan Yan
In-Reply-To: <1556283505-29539-1-git-send-email-vnaralas@codeaurora.org>
Venkateswara Naralasetty <vnaralas@codeaurora.org> wrote:
> ath10k_dbg() is called in ath10k_process_rx() with huge set of arguments
> which is causing CPU overhead even when debug_mask is not set.
> Good improvement was observed in the receive side performance when call
> to ath10k_dbg() is avoided in the RX path.
>
> Since currently all debug messages are sent via tracing infrastructure,
> we cannot entirely avoid calling ath10k_dbg. Therefore, call to
> ath10k_dbg() is made conditional based on tracing config in the driver.
>
> Trasmit performance remains unchanged with this patch; below are some
> experimental results with this patch and tracing disabled.
>
> mesh mode:
>
> w/o this patch with this patch
> Traffic TP CPU Usage TP CPU usage
>
> TCP 840Mbps 76.53% 960Mbps 78.14%
> UDP 1030Mbps 74.58% 1132Mbps 74.31%
>
> Infra mode:
>
> w/o this patch with this patch
> Traffic TP CPU Usage TP CPU usage
>
> TCP Rx 1241Mbps 80.89% 1270Mbps 73.50%
> UDP Rx 1433Mbps 81.77% 1472Mbps 72.80%
>
> Tested platform : IPQ8064
> hardware used : QCA9984
> firmware ver : ver 10.4-3.5.3-00057
>
> Signed-off-by: Kan Yan <kyan@chromium.org>
> Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
9d740d6380e5 ath10k: Add wrapper function to ath10k debug
--
https://patchwork.kernel.org/patch/10919117/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add inline wrapper for htt_h2t_aggr_cfg_msg
From: Kalle Valo @ 2019-06-25 12:47 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: kvalo, linux-wireless, ath10k, Erik Stromdahl
In-Reply-To: <20190326162904.6737-1-erik.stromdahl@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
> This is done in order to make the *htt_h2t_aggr_cfg_msg* op align better
> with the rest of the htt ops (whom all have inline wrappers).
>
> It also adds support for the case when the op is missing (function
> pointer is NULL).
>
> As a result of this, the name of the 32 bit implementation in htt_tx.c
> was changed and the function was made static.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2 patches applied to ath-next branch of ath.git, thanks.
74ee5715991f ath10k: add inline wrapper for htt_h2t_aggr_cfg_msg
bc31c2cfecc7 ath10k: add htt_h2t_aggr_cfg_msg op for high latency devices
--
https://patchwork.kernel.org/patch/10871563/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ssb/gpio: Remove unnecessary WARN_ON from driver_gpio
From: Kalle Valo @ 2019-06-25 12:24 UTC (permalink / raw)
To: Jonas Gorski; +Cc: Michael Büsch, H Buus, Larry Finger, linux-wireless
In-Reply-To: <CAOiHx=k_KPgXqJYjSeUFVS3pae1CGBGS9STnTuAfNyvak2k08w@mail.gmail.com>
Jonas Gorski <jonas.gorski@gmail.com> writes:
> On Tue, 25 Jun 2019 at 12:06, Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Michael Büsch <m@bues.ch> writes:
>>
>> > The WARN_ON triggers on older BCM4401-B0 100Base-TX ethernet controllers.
>> > The warning serves no purpose. So let's just remove it.
>> >
>> > Reported-by: H Buus <ubuntu@hbuus.com>
>> > Signed-off-by: Michael Büsch <m@bues.ch>
>>
>> For some reason patchwork (or pwcli script) didn't like this patch so
>> manually applied to wireless-drivers-next:
>>
>> e73e43246da6 ssb/gpio: Remove unnecessary WARN_ON from driver_gpio
>>
>> I have a faint recollection that I had a similar problem with another
>> patch from Michael, did we ever conclude what was the issue?
>
> Yes [1], a bug in kernel.org's version of patchwork.
Ah, that was it. Thanks!
> The fix was included in v2.1.1; latest is v2.1.3. kernel.org is
> (still) at v2.1.0. Maybe it's time to poke helpdesk?
Indeed, that would be a good idea. Apparently v2.1.0 was released a year
ago:
https://github.com/getpatchwork/patchwork/releases
So if your or anyone else has time, please do report to kernel.org
helpdesk and hopefully they can help.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ssb/gpio: Remove unnecessary WARN_ON from driver_gpio
From: Jonas Gorski @ 2019-06-25 12:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: Michael Büsch, H Buus, Larry Finger, linux-wireless
In-Reply-To: <87v9wus164.fsf@kamboji.qca.qualcomm.com>
On Tue, 25 Jun 2019 at 12:06, Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Michael Büsch <m@bues.ch> writes:
>
> > The WARN_ON triggers on older BCM4401-B0 100Base-TX ethernet controllers.
> > The warning serves no purpose. So let's just remove it.
> >
> > Reported-by: H Buus <ubuntu@hbuus.com>
> > Signed-off-by: Michael Büsch <m@bues.ch>
>
> For some reason patchwork (or pwcli script) didn't like this patch so
> manually applied to wireless-drivers-next:
>
> e73e43246da6 ssb/gpio: Remove unnecessary WARN_ON from driver_gpio
>
> I have a faint recollection that I had a similar problem with another
> patch from Michael, did we ever conclude what was the issue?
Yes [1], a bug in kernel.org's version of patchwork. The fix was
included in v2.1.1; latest is v2.1.3. kernel.org is (still) at v2.1.0.
Maybe it's time to poke helpdesk?
Regards
Jonas
[1] https://marc.info/?l=linux-wireless&m=153388992528252&w=2
^ permalink raw reply
* [RFC V2 2/8] cfg80211: add 6GHz UNII band definitions
From: Arend van Spriel @ 2019-06-25 11:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1561461027-10793-1-git-send-email-arend.vanspriel@broadcom.com>
For the new 6GHz there are new UNII band definitions as listed
in the FCC notice [1].
[1] https://docs.fcc.gov/public/attachments/FCC-18-147A1_Rcd.pdf
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Leon Zegers <leon.zegers@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/reg.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 4831ad74..646107a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3806,8 +3806,9 @@ void wiphy_regulatory_deregister(struct wiphy *wiphy)
}
/*
- * See http://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii, for
- * UNII band definitions
+ * See FCC notices for UNII band definitions
+ * 5GHz: https://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii
+ * 6GHz: https://www.fcc.gov/document/fcc-proposes-more-spectrum-unlicensed-use-0
*/
int cfg80211_get_unii(int freq)
{
@@ -3831,6 +3832,22 @@ int cfg80211_get_unii(int freq)
if (freq > 5725 && freq <= 5825)
return 4;
+ /* UNII-5 */
+ if (freq > 5925 && freq <= 6425)
+ return 5;
+
+ /* UNII-6 */
+ if (freq > 6425 && freq <= 6525)
+ return 6;
+
+ /* UNII-7 */
+ if (freq > 6525 && freq <= 6875)
+ return 7;
+
+ /* UNII-8 */
+ if (freq > 6875 && freq <= 7125)
+ return 8;
+
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* [RFC V2 4/8] cfg80211: extend ieee80211_operating_class_to_band() for 6GHz
From: Arend van Spriel @ 2019-06-25 11:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1561461027-10793-1-git-send-email-arend.vanspriel@broadcom.com>
Add 6GHz operating class range as defined in 802.11ax D4.1 Annex E.
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Leon Zegers <leon.zegers@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/util.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4e633d4..4462837 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1474,6 +1474,9 @@ bool ieee80211_operating_class_to_band(u8 operating_class,
case 128 ... 130:
*band = NL80211_BAND_5GHZ;
return true;
+ case 131 ... 135:
+ *band = NL80211_BAND_6GHZ;
+ return true;
case 81:
case 82:
case 83:
--
1.9.1
^ permalink raw reply related
* [RFC V2 7/8] cfg80211: ibss: use 11a mandatory rates for 6GHz band operation
From: Arend van Spriel @ 2019-06-25 11:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1561461027-10793-1-git-send-email-arend.vanspriel@broadcom.com>
The default mandatory rates, ie. when not specified by user-space, is
determined by the band. Select 11a rateset for 6GHz band.
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Leon Zegers <leon.zegers@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/ibss.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index d1743e6..ae8fe66 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -104,13 +104,19 @@ int __cfg80211_join_ibss(struct cfg80211_registered_device *rdev,
* use the mandatory rate set for 11b or
* 11a for maximum compatibility.
*/
- struct ieee80211_supported_band *sband =
- rdev->wiphy.bands[params->chandef.chan->band];
+ struct ieee80211_supported_band *sband;
+ enum nl80211_band band;
+ u32 flag;
int j;
- u32 flag = params->chandef.chan->band == NL80211_BAND_5GHZ ?
- IEEE80211_RATE_MANDATORY_A :
- IEEE80211_RATE_MANDATORY_B;
+ band = params->chandef.chan->band;
+ if (band == NL80211_BAND_5GHZ ||
+ band == NL80211_BAND_6GHZ)
+ flag = IEEE80211_RATE_MANDATORY_A;
+ else
+ flag = IEEE80211_RATE_MANDATORY_B;
+
+ sband = rdev->wiphy.bands[band];
for (j = 0; j < sband->n_bitrates; j++) {
if (sband->bitrates[j].flags & flag)
params->basic_rates |= BIT(j);
--
1.9.1
^ permalink raw reply related
* [RFC V2 1/8] nl80211: add 6GHz band definition to enum nl80211_band
From: Arend van Spriel @ 2019-06-25 11:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1561461027-10793-1-git-send-email-arend.vanspriel@broadcom.com>
In the 802.11ax specification a new band is introduced, which
is also proposed by FCC for unlicensed use. This band is referred
to as 6GHz spanning frequency range from 5925 to 7125 MHz.
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Leon Zegers <leon.zegers@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
changes:
- V2
fix ABI breakage by appending the new band definition.
---
include/uapi/linux/nl80211.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8fc3a43..45b9117 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4536,6 +4536,7 @@ enum nl80211_txrate_gi {
* @NL80211_BAND_2GHZ: 2.4 GHz ISM band
* @NL80211_BAND_5GHZ: around 5 GHz band (4.9 - 5.7 GHz)
* @NL80211_BAND_60GHZ: around 60 GHz band (58.32 - 69.12 GHz)
+ * @NL80211_BAND_6GHZ: around 6 GHz band (5.9 - 7.2 GHz)
* @NUM_NL80211_BANDS: number of bands, avoid using this in userspace
* since newer kernel versions may support more bands
*/
@@ -4543,6 +4544,7 @@ enum nl80211_band {
NL80211_BAND_2GHZ,
NL80211_BAND_5GHZ,
NL80211_BAND_60GHZ,
+ NL80211_BAND_6GHZ,
NUM_NL80211_BANDS,
};
--
1.9.1
^ permalink raw reply related
* [RFC V2 5/8] cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS entries
From: Arend van Spriel @ 2019-06-25 11:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1561461027-10793-1-git-send-email-arend.vanspriel@broadcom.com>
In nl80211.c there is a policy for all bands in NUM_NL80211_BANDS and
in trace.h there is a callback trace for multicast rates which is per
band in NUM_NL80211_BANDS. Both need to be extended for the new
NL80211_BAND_6GHZ.
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Leon Zegers <leon.zegers@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/nl80211.c | 1 +
net/wireless/trace.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fc83dd1..57bc35a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -667,6 +667,7 @@ static int validate_ie_attr(const struct nlattr *attr,
nl80211_match_band_rssi_policy[NUM_NL80211_BANDS] = {
[NL80211_BAND_2GHZ] = { .type = NLA_S32 },
[NL80211_BAND_5GHZ] = { .type = NLA_S32 },
+ [NL80211_BAND_6GHZ] = { .type = NLA_S32 },
[NL80211_BAND_60GHZ] = { .type = NLA_S32 },
};
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 4fbb91a..d98ad2b 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2446,10 +2446,11 @@
sizeof(int) * NUM_NL80211_BANDS);
),
TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", "
- "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 60GHz=0x%x]",
+ "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 6GHz=0x%x, 60GHz=0x%x]",
WIPHY_PR_ARG, NETDEV_PR_ARG,
__entry->mcast_rate[NL80211_BAND_2GHZ],
__entry->mcast_rate[NL80211_BAND_5GHZ],
+ __entry->mcast_rate[NL80211_BAND_6GHZ],
__entry->mcast_rate[NL80211_BAND_60GHZ])
);
--
1.9.1
^ permalink raw reply related
* [RFC V2 6/8] cfg80211: use same IR permissive rules for 6GHz band
From: Arend van Spriel @ 2019-06-25 11:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1561461027-10793-1-git-send-email-arend.vanspriel@broadcom.com>
The function cfg80211_ir_permissive_chan() is applicable for
6GHz band as well so make sure it is handled.
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Leon Zegers <leon.zegers@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/chan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 7dc1bbd..7c9d204 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -894,7 +894,8 @@ static bool cfg80211_ir_permissive_chan(struct wiphy *wiphy,
if (chan == other_chan)
return true;
- if (chan->band != NL80211_BAND_5GHZ)
+ if (chan->band != NL80211_BAND_5GHZ &&
+ chan->band != NL80211_BAND_6GHZ)
continue;
r1 = cfg80211_get_unii(chan->center_freq);
--
1.9.1
^ permalink raw reply related
* [RFC V2 8/8] cfg80211: apply same mandatory rate flags for 5GHz and 6GHz
From: Arend van Spriel @ 2019-06-25 11:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1561461027-10793-1-git-send-email-arend.vanspriel@broadcom.com>
For the new 6GHz band the same rules apply for mandatory rates so
add it to set_mandatory_flags_band() function.
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Leon Zegers <leon.zegers@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4462837..f0558e7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -156,6 +156,7 @@ static void set_mandatory_flags_band(struct ieee80211_supported_band *sband)
switch (sband->band) {
case NL80211_BAND_5GHZ:
+ case NL80211_BAND_6GHZ:
want = 3;
for (i = 0; i < sband->n_bitrates; i++) {
if (sband->bitrates[i].bitrate == 60 ||
--
1.9.1
^ permalink raw reply related
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