Re: [PATCH] ath: regdom: extend South Korea regulatory domain support

On 9/15/21 11:56 AM, Peter Oh wrote: South Korea manufacturer, Samsung, has extended South Korea regulatory domain pair with 0x5F and has used it for their devices such as Samsung Galaxy book. Hence add support 0x5F as a regulatory domain pair along with extended country code, 413. I don't

[PATCH] ath: regdom: extend South Korea regulatory domain support

South Korea manufacturer, Samsung, has extended South Korea regulatory domain pair with 0x5F and has used it for their devices such as Samsung Galaxy book. Hence add support 0x5F as a regulatory domain pair along with extended country code, 413. Signed-off-by: Peter Oh Signed-off-by: Andreas

Re: Revert: ath: add support for special 0x0 regulatory domain

On 8/22/21 9:49 AM, Andrey Skvortsov wrote: 1) Current behaviour maps 0x0 regulatory domain to the most restrictive world domain. According to the wiki (probably based on Atheros documentation) 0x0 means US. Does wiki contain wrong information? 0x0 means country section in OTP is not

Re: [PATCH] ath10k: Do not call dma_alloc_coherent() for SDIO and USB

Fix the problem by not calling dma_alloc_coherent() when the device is not DMA capable, such as SDIO and USB. ath10k calls dma_alloc_coherent multiple places including ath10k_htt_rx_alloc. Do SDIO and USB not use such data path function at all? Thanks, Peter

Re: [PATCH] ath10k: Add interrupt summary based CE processing

11.527919] [<8023c650>] (worker_thread) from [<802408f8>] (kthread+0xd8/0xe8) [ 11.536247] [<802408f8>] (kthread) from [<80209ce8>] (ret_from_fork+0x14/0x2c) When I revert #1 eventually, my system is back to working. So I'm blaming the #1 and #2 could have potential b

Re: [PATCH] ath10k: Add interrupt summary based CE processing

of "per_ce_irq" hw param https://patchwork.kernel.org/patch/11654633/ and saw the crash happen and then reverted the top 2 and used the very first one, but it is still happening. On Mon, Jul 20, 2020 at 5:56 PM Peter Oh wrote: > > Since IPQ4019 doesn't support per CE based inte

Re: [PATCH] ath10k: Add interrupt summary based CE processing

Since IPQ4019 doesn't support per CE based interrupt summary, I doubt if this change is correct. + ath10k_ce_engine_int_status_clear(ar, ctrl_addr, + wm_regs->cc_mask | wm_regs->wm_mask); On Mon, Jul 20, 2020 at 5:53 PM Peter Oh wrote: > &

Re: [PATCH] ath10k: Add interrupt summary based CE processing

I've run 3 units and one of them happens the problem always while the other 2 are barely happening. On Mon, Jul 20, 2020 at 5:33 PM Peter Oh wrote: > > I'm getting this panic on IPQ4019 system after cherry-picked this > single patch on top of working system. > > [ 14.226184] ath

Re: [PATCH] ath10k: Add interrupt summary based CE processing

I'm getting this panic on IPQ4019 system after cherry-picked this single patch on top of working system. [ 14.226184] ath10k_ahb a00.wifi: failed to receive initialized event from target: 8000 [ 14.326406] !#% P L F<005> [0008] [ 14.326447] Unable to handle kernel NULL pointer

Re: [PATCH 2/2] ath10k: correct legacy rate in tx stats

On 11/12/19 3:45 AM, Yu Wang wrote: When working in station mode, after connected to a legacy AP, 11g only, for example, the tx bitrate is incorrect in output of command 'iw wlan0 link'. That's because the legacy tx bitrate value reported by firmware is not well handled: For QCA6174, the

Re: [PATCH RFC] Revert "ath10k: fix DMA related firmware crashes on multiple devices"

On 10/29/19 11:16 PM, zhic...@codeaurora.org wrote: On 2019-10-23 01:16, Peter Oh wrote: How can you say value 0 (I believe it's 64 bytes) DMA burst size causes the symptom and 1 fixes it? Peter Confirmed from HW team that the configuration controls AXI burst size of the RD/WR access

Re: [PATCH RFC] Revert "ath10k: fix DMA related firmware crashes on multiple devices"

On 10/22/19 11:24 AM, Adrian Chadd wrote: On Tue, 22 Oct 2019 at 10:17, Peter Oh wrote: On 10/22/19 1:57 AM, Zhi Chen wrote: This reverts commit 76d164f582150fd0259ec0fcbc485470bcd8033e. PCIe hung issue was observed on multiple platforms. The issue was reproduced when DUT was configured

Re: [PATCH RFC] Revert "ath10k: fix DMA related firmware crashes on multiple devices"

On 10/22/19 1:57 AM, Zhi Chen wrote: This reverts commit 76d164f582150fd0259ec0fcbc485470bcd8033e. PCIe hung issue was observed on multiple platforms. The issue was reproduced when DUT was configured as AP and associated with 50+ STAs. With PCIe protocol analyzer, we can see DMA Read crossing

Re: [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni

On 10/1/19 4:48 AM, Kalle Valo wrote: Erik Stromdahl writes: Since ath10k_mac_tx_push_txq() can be called from process context, we must explicitly disable softirqs before the call into mac80211. By calling ieee80211_tx_dequeue_ni() instead of ieee80211_tx_dequeue() we make sure softirqs

Re: [PATCH v2] ath10k: Report low ack rssi based on the reason code

On 04/03/2019 12:23 AM, Rakesh Pillai wrote: > Firmware sends peer sta kickout event to the driver > along with the reason code for a particular peer. > > Currently the sta kickout event is delivered to the > upper layer without checking if the reason code is > valid or not. This causes

Re: [PATCH] ath10k: remove iteration in wake_tx_queue

On 03/27/2019 09:29 AM, Erik Stromdahl wrote: > Iterating the TX queue and thereby dequeuing all available packets in the > queue could result in performance penalties on some SMP systems. > Please share the test results and numbers you've run to help others thoughts. Thanks, Peter

Re: [PATCH] ath10k: fix incorrect multicast/broadcast rate setting

On 12/10/2018 08:56 PM, Pradeep Kumar Chitrapu wrote: > From: Pradeep kumar Chitrapu > > Invalid rate code is sent to firmware when multicast rate value of 0 is > sent to driver indicating disabled case, causing broken mesh path. > so fix that. > > Tested on QCA9984 with firmware

Re: [PATCH] ath: fix frequent flase radar detection

On 10/14/2018 10:07 PM, Tamizh chelvam wrote: > Many number of false radar detection occurred in a noisy > environment in QCA4019, QCA9888 devices. By reducing > PRI_TOLERANCE to 6 and flushing out pulse queue by dpd_reset > if timestamp between current and previous pulse is lesser than > 100ms

Re: [RFC v4 2/2] ath10k: report tx rate using ieee80211_tx_rate_update()

On 09/28/2018 12:10 PM, Peter Oh wrote: > > On 09/24/2018 12:10 AM, Anilkumar Kolli wrote: >> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c >> b/drivers/net/wireless/ath/ath10k/htt_rx.c >> index f2405258a6d3..355c39a0486c 100644 >> --- a/drivers/ne

Re: [RFC v4 2/2] ath10k: report tx rate using ieee80211_tx_rate_update()

On 09/24/2018 12:10 AM, Anilkumar Kolli wrote: > diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c > b/drivers/net/wireless/ath/ath10k/htt_rx.c > index f2405258a6d3..355c39a0486c 100644 > --- a/drivers/net/wireless/ath/ath10k/htt_rx.c > +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c > @@

Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips

Hi Toke, On 08/17/2018 04:32 AM, Toke Høiland-Jørgensen wrote: Shift 6: wgong@wgong-Latitude-E5440-1:~/flent$ flent -H 192.168.1.7 -t "sk_pacing_shift6" tcp_nup --test-parameter upload_streams=1 Does flent have options to set TOS or QoS queue for TCP or UDP test? If I add "--test-paramete

Re: [PATCHv2] ath10k : Fix channel survey dump

On 08/08/2018 11:35 PM, Venkateswara Naralasetty wrote: On 2018-08-01 00:03, Jasmine Strong wrote: On Tue, Jul 31, 2018 at 10:38 AM Ben Greear wrote: On 07/31/2018 05:11 AM, Venkateswara Naralasetty wrote: Channel active/busy time are showing incorrect(less than previous or sometimes

Re: [PATCH v2 0/2] Change sk_pacing_shift in ieee80211_hw for best tx throughput

On 08/08/2018 03:40 AM, Wen Gong wrote: Add a field for ath10k to adjust the sk_pacing_shift, mac80211 set the default value to 8, and ath10k will change it to 6. Then mac80211 will use the changed value 6 as sk_pacing_shift since 6 is the best value for tx throughput by test result. I don't

Fwd: Re: [PATCHv2 2/2] ath10k: DFS Host Confirmation

+ /* Even in case of radar detection failure we follow the same +* behaviour as if radar is detected i.e to switch to a different +* channel. +*/ + if (status_arg.status == WMI_HW_RADAR_DETECTED || + status_arg.status == WMI_RADAR_DETECTION_FAIL) +

Re: [PATCHv2 2/2] ath10k: DFS Host Confirmation

+ /* Even in case of radar detection failure we follow the same +* behaviour as if radar is detected i.e to switch to a different +* channel. +*/ + if (status_arg.status == WMI_HW_RADAR_DETECTED || + status_arg.status == WMI_RADAR_DETECTION_FAIL) +

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

Sure, every software change can cause regressions. But the thing is that this isn't an optional, ath10k has to have this to be able to continue using DFS channels. Kalle, you said you don't know which exact FCC requirement this is for in another email thread. Then how come you're sure this is

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

Which regulatory enforcement are you talking to? Are you talking about such "prevent users from changing regulatory domain" or "don't provide a manner to change regulatory domain or channel list" ? If not, can you share the section of document? Sorry, I don't have any references about that.

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

On 05/02/2018 04:27 AM, Kalle Valo wrote: Peter Oh <peter...@bowerswilkins.com> writes: On 04/30/2018 10:45 AM, Sriram R wrote: In the 10.4-3.6 firmware branch there's a new DFS Host confirmation feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag. This new fe

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

On 04/30/2018 10:45 AM, Sriram R wrote: In the 10.4-3.6 firmware branch there's a new DFS Host confirmation feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag. This new features enables the ath10k host to send information to the firmware on the specifications of

Re: [PATCH 1/2] ath: Add support to get the detected radar specifications

On 04/30/2018 10:45 AM, Sriram R wrote: This enables ath10k/ath9k drivers to collect the specifications of the radar type once it is detected by the dfs pattern detector unit. Usage of the collected info is specific to driver implementation. For example, collected radar info could be used by

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

On 04/13/2018 06:48 AM, Kalle Valo wrote: Sven Eckelmann writes: But of course, I cannot say much about how the rate control from QCA works and in which form these information are already available. If you want to know the average PHY rate then wouldn't it be

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

Hi Anilkumar, On 03/27/2018 11:37 PM, Sven Eckelmann wrote: On Mittwoch, 28. März 2018 11:41:51 CEST ako...@codeaurora.org wrote: [...] The rate average and throughput are relative. no? Can you share the output number from your new function? It may help us to understand a little bit more how

Re: [PATCH v3 00/12] *** Add support for wifi QMI client driver ***

Add QMI client driver for Q6 integrated WLAN connectivity subsystem. Can you give an example which chipset series is Q6 integrated WLAN ? Thanks, Peter ___ ath10k mailing list ath10k@lists.infradead.org

Re: [PATCH 1/2] ath10k: Add WMI FWTEST command support

From: Sathishkumar Muruganandam This patch adds support for WMI_FWTEST_CMD. This command is used for setting the wifi parameters. It's too lack of information in commit message. You should add such what values are acceptable for which purpose by each param_id and

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159. When Ath10k is in AP mode and an unassociated STA sends a VHT action frame (Operating Mode Notification for the NSS change) periodically to AP this causes ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID

Re: [PATCH] ath10k: Add tx ack signal support for management frames

On 12/27/2017 02:14 AM, vnara...@qti.qualcomm.com wrote: From: Venkateswara Naralasetty This patch add support to get RSSI from acknowledgment frames for transmitted management frames. hardware_used: QCA4019, QCA9984. firmware version: 10.4-3.5.3-00052.

Re: [PATCH] ath10k: unify rx processing in napi_poll

Hi Rajkumar, I'm wondering if this patch is related to kernel crash due to ath10k napi. Do you think this patch helps the crash below? This crash happened ath10k v4.14 (10/04/2017, commit id c09dbd7) + 3.14.43 kernel backports. [ 6866.655419] [ cut here ] [

Re: mesh point and ap mode on same interface

On 11/08/2017 04:49 AM, Harms, Hannes wrote: Am 11.10.2017 um 20:10 schrieb Peter Oh: On 10/10/2017 06:04 AM, Hannes Harms wrote: On 10/09/2017 08:08 AM, Thomas Pedersen wrote: On Oct 9, 2017 1:46 AM, "Harms, Hannes" <hannes.ha...@tu-bs.de <mailto:hannes.ha...@

Re: ath10k: Fix reported HT MCS rates with NSS > 1

On 11/06/2017 01:02 AM, Sven Eckelmann wrote: On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote: Am 06.11.2017 um 09:23 schrieb Sven Eckelmann: On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote: the assumption made in this patch is obviously wrong (at

Re: [PATCH V6 0/5] Add TDLS feature for ath10k

On 10/15/2017 11:00 PM, yint...@qti.qualcomm.com wrote: From: Yingying Tang This patchset is for Rome PCIE chip, it will not affect other hardware Please add your patchset history here until V6. That's what cover letter is supposed to have. Yingying Tang (5):

Re: mesh point and ap mode on same interface

On 10/10/2017 06:04 AM, Hannes Harms wrote: On 10/09/2017 08:08 AM, Thomas Pedersen wrote: On Oct 9, 2017 1:46 AM, "Harms, Hannes" <hannes.ha...@tu-bs.de <mailto:hannes.ha...@tu-bs.de>> wrote: On 10/06/2017 20:18, Peter, Oh wrote I have tried t bri

Re: mesh point and ap mode on same interface

I have tried t bring up the ap interface with iw / hostapd, after joining the mesh. When I start the second interface, rtnetlink responds with device or resource busy. If you give more details of your steps, people may help you more. Btw, did you create a 2nd interface on the same radio and

Re: Is using 802.11s with DFS possible?

On 06/28/2017 06:54 PM, Zach Sherin wrote: Hi all, I've been running some experiments in LEDE thanks to your help many months ago, and I want to use DFS frequencies with my mesh network. Does ath10k currently support this or am I up a creek? My tests show that I can use DFS frequencies with

Re: [RFC v2 06/10] ath10k: htt: High latency RX support

On 06/12/2017 08:03 AM, Erik Stromdahl wrote: Special HTT RX handling for high latency interfaces. Since no DMA physical addresses are used in the RX ring config message (this is not supported by the high latency devices), no RX ring is allocated. All RX skb's are allocated by the driver and

Re: [RFC v2 05/10] ath10k: htt: High latency TX support

On 06/12/2017 08:03 AM, Erik Stromdahl wrote: Add HTT TX function for HL interfaces. Intended for SDIO and USB. Signed-off-by: Erik Stromdahl --- diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 48418f9..c5fd803 100644

Re: Issue with ATH10K driver while bringing up mesh interface

I was talking about QCA988X firmware and I don't think QCA99X0 has officially released firmware for mesh. Thanks, Peter From: Alexis Green <agr...@cococorp.com> Sent: Monday, August 22, 2016 10:33 AM To: Peter Oh Cc: Pedersen, Thomas; Sridhar Konabathini; michal.kaz...@tieto.com; Raj

Re: Issue with ATH10K driver while bringing up mesh interface

re-send in plain text mode. > >  > > Please try  "insmod ath10k_core.ko rawmode=1" > > I recommend you to use  FW version 10.2.4.70.12-2 or higher, so that you don't have to use raw mode. Main downside using raw mode is throughput throttled. You can get the ath10k firmware from 

Re: DFS radar pattern detection in different regions

re-send in plain text mode. > I am just confused by the output of "iw reg get", which outputs lines > from the db.txt of wireless-regdb [1]. For example, the first lines of > the output for some countries read like the following: > country AE: DFS-FCC > country AF: DFS-ETSI > country BD:

Re: Does 99x0 support mesh mode?

On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote: Make sure the firmware has the raw mode feature bit enabled to support mesh. In addition to that, you may check out wmi_services (cat /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if WMI_SERVICE_MESH_11S is set to enabled which means 11s

[PATCH 0/3] ath10k: add a support of set_tsf on vdev interface

10.2.4 and 10.4 firmware has introduced new function to set TSF via vdev parameter. set_tsf function can be used to shift TBTT that will help avoid its clockdrift which happens when beacons are collided. Peter Oh (3): ath10k: add a support of set_tsf on vdev interface ath10k: update 10.4 WMI

[PATCH 1/3] ath10k: add a support of set_tsf on vdev interface

10.2.4.70.24 firmware introduces new feature to set TSF via vdev parameter, hence implement relevant function. set_tsf function can be used to shift TBTT that will help avoid its clockdrift which happens when beacons are collided. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drive

[PATCH 2/3] ath10k: update 10.4 WMI vdev parameters

Update 10.4 WMI vdev param to sync to current 10.4 firmware as of 2/23/2016. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wirele

[PATCH 3/3] ath10k: enable set_tsf vdev command to WMI 10.4

10.4 firmware has addeded set_tsf vdev parameter, hence enable it. set_tsf function can be used to shift TBTT that will help avoid its clockdrift which happens when beacons are collided. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.c | 2 +-

Re: [PATCH v2] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

://github.com/0day-ci/linux/commits/Peter-Oh/ath10k-parse-Rx-MAC-timestamp-in-mgmt-frame-for-FW-10-4/20160323-064843 base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master config: x86_64-randconfig-x000-201612 (attached as .config) reproduce: # save

Re: [PATCH v5] ath10k: set MAC timestamp in management Rx frame

On 02/29/2016 10:33 AM, Michal Kazior wrote: On 26 February 2016 at 20:03, Peter Oh <p...@qca.qualcomm.com> wrote: Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such cloc

[PATCH v6] ath10k: set MAC timestamp in management Rx frame

Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such clockdrift or beacon collision and use the result for beacon collision avoidance. Signed-off-by: Peter Oh <p...@qca.qualcomm.

[PATCH] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

Check and parse Rx MAC timestamp when firmware sets its flag to status variable. 10.4 firmware adds it in Rx beacon frame only at this moment. Drivers and mac80211 may utilize it to detect such clockdrift or beacon collision and use the result for beacon collision avoidance. Signed-off-by: Peter

[PATCH v5] ath10k: set MAC timestamp in management Rx frame

Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such clockdrift or beacon collision and use the result for beacon collision avoidance. Signed-off-by: Peter Oh <p...@qca.qualcomm.

[PATCH v4] ath10k: set MAC timestamp in management Rx frame

Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such clockdrift or beacon collision and use the result for beacon collision avoidance. Signed-off-by: Peter Oh <p...@qca.qualcomm.

Re: [PATCH v3] ath10k: set MAC timestamp in management Rx frame

Hi, On 02/25/2016 08:34 AM, Valo, Kalle wrote: Peter Oh <p...@qca.qualcomm.com> writes: Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such clockdrift or beacon collision a

Re: Which firmware has raw mode support

On 02/25/2016 07:58 AM, Xue Liu wrote: Hello, I have a WLE900VX (QCA9880) 11ac card and would like to do some mesh test. I have try some firmware from https://github.com/kvalo/ath10k-firmware/tree/master/QCA988X/10.2.4 but no luck. Could someone tell me that which firmware has raw mode

[PATCH v3] ath10k: set MAC timestamp in management Rx frame

Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such clockdrift or beacon collision and use the result for beacon collision avoidance. Signed-off-by: Peter Oh <p...@qca.qualcomm.

Re: [PATCH v2] ath10k: set MAC timestamp in management Rx frame

On 02/24/2016 12:40 AM, Michal Kazior wrote: On 23 February 2016 at 20:44, Peter Oh <p...@qca.qualcomm.com> wrote: From: poh <p...@qca.qualcomm.com> Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and

[PATCH v2] ath10k: set MAC timestamp in management Rx frame

From: poh Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such clockdrift or beacon collision and use the result for beacon collision avoidance. Signed-off-by:

[PATCH] ath10k: set MAC timestamp in management Rx frame

From: poh Check and set Rx MAC timestamp when firmware indicates it. Firmware adds it in Rx beacon frame only at this moment. Driver and mac80211 may utilize it to detect such clockdrift or beacon collision and use the result for beacon collision avoidance. Signed-off-by:

[PATCH v2 2/4] ath10k: update 10.4 WMI service map

Update 10.4 WMI service map to sync to the latest 10.4 firmware as of 1/20/2016. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drive

[PATCH v2 4/4] ath10k: add abstraction layer for vdev subtype

. Hence use the abstraction API to get right subtype to use. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 15 --- drivers/net/wireless/ath/ath10k/wmi-ops.h | 11 + drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 + drivers/net/wirele

[PATCH v2 1/4] ath10k: rename Mesh related service names

-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 4 ++-- drivers/net/wireless/ath/ath10k/wmi.h | 16 +--- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k

[PATCH v2 3/4] ath10k: use vif->type and vif->p2p for P2P_GO check

Interface type P2P_GO can be checked by either arvif->vdev_type and arvif->vdev_subtype or vif->type and vif->p2p. Use later one to avoid more cpu consumption that could happen when subtype abstraction layer change is introduced. Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

[PATCH 1/4] ath10k: rename Mesh related service names

-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 4 ++-- drivers/net/wireless/ath/ath10k/wmi.h | 16 +--- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k

[PATCH 0/4] ath10k: rename mesh and add abstraction layer

Split Mesh service to 11s Mesh and non-11s Mesh according to firmware service bit to help users distinguish 11s Mesh from non 11s Mesh. And add abstraction layer for vdev subtype to solve subtype mismatch and to give flexible compatibility among different firmware revisions. Peter Oh (4

[PATCH 4/4] ath10k: add abstraction layer for vdev subtype

. Hence use the abstraction API to get right subtype to use. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 15 --- drivers/net/wireless/ath/ath10k/wmi-ops.h | 11 + drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 + drivers/net/wirele

[PATCH 3/4] ath10k: use vif->type and vif->p2p for P2P_GO check

Interface type P2P_GO can be checked by either arvif->vdev_type and arvif->vdev_subtype or vif->type and vif->p2p. Use later one to avoid more cpu consumption that could happen when subtype abstraction layer change is introduced. Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

[PATCH 2/4] ath10k: update 10.4 WMI service map

Update 10.4 WMI service map to sync to the latest 10.4 firmware as of 1/20/2016. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.h | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drive

Re: [PATCH 0/4] ath10k: rename mesh and add abstraction layer

On 01/27/2016 11:39 AM, Bob Copeland wrote: On Wed, Jan 27, 2016 at 10:55:53AM -0800, Peter Oh wrote: Split Mesh service to 11s Mesh and non-11s Mesh according to firmware service bit to help users distinguish 11s Mesh from non 11s Mesh. And add abstraction layer for vdev subtype to solve

Re: [PATCH 13/13] ath10k: implement push-pull tx

On 01/26/2016 02:28 AM, Michal Kazior wrote: On 22 January 2016 at 08:47, Michal Kazior <michal.kaz...@tieto.com> wrote: On 21 January 2016 at 18:40, Peter Oh <p...@codeaurora.org> wrote: On 01/21/2016 05:46 AM, Michal Kazior wrote: [...] - /* TODO: apply c

Re: Mesh on ath10k drops all packets

On 01/22/2016 03:01 AM, Jeroen Roovers wrote: Maybe related? Jan 22 11:59:33 wim kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Jan 22 11:59:33 wim kernel: wlan0: Allocated STA 40:e2:30:cb:9a:11 Jan 22 11:59:33 wim kernel: wlan0: moving STA 40:e2:30:cb:9a:11 to state 2 Jan 22

Re: Mesh on ath10k drops all packets

On 01/22/2016 04:32 PM, Yeoh Chun-Yeow wrote: On Fri, Jan 22, 2016 at 11:45 PM, Jeroen Roovers wrote: On 22 January 2016 at 13:51, Bob Copeland wrote: On Fri, Jan 22, 2016 at 12:01:36PM +0100, Jeroen Roovers wrote: Maybe related? Could be.

Re: [PATCH 13/13] ath10k: implement push-pull tx

On 01/21/2016 05:46 AM, Michal Kazior wrote: The current/old tx path design was that host, at its own leisure, pushed tx frames to the device. For HTT there was ~1000-1400 msdu queue depth. After reaching that limit the driver would request mac80211 to stop queues. There was little control

Re: Regulatory Domains and Japan Channel 14

On 01/18/2016 05:46 AM, Tomi Saarnio wrote: Dear All, We are trying to perform scanning at the 2.4GHz band with the JP (Japan) regulatory domain, but it seems that the ath10k refuses to scan the channel 14 although the channel 14 is a valid channel in Japan (with certain rate and transmit

Re:

On 01/13/2016 09:36 PM, Alexey Ivanov wrote: Yes, you're right, Michał putting cal.bin to lib/firmware/ath10k helped (before I put it to lib/firmware/ath10k/QCA988X/hw2.0/) but the mac address is still 00:03:7F:00:00:00 cal file has a mac address in it and ath10k uses it as default unless

[PATCH] ath10k: Set SM power save disabled to default value

SMPS, because they are capable to switch the mode to dynamic or static either at the end of frame sequence or by using SMPS action frame. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

On 12/16/2015 03:59 PM, Felix Fietkau wrote: On 2015-12-17 00:50, Peter Oh wrote: On 12/16/2015 01:54 PM, Felix Fietkau wrote: On 2015-12-16 22:19, Peter Oh wrote: On 12/16/2015 12:53 PM, Felix Fietkau wrote: On 2015-12-16 21:46, Peter Oh wrote: On 12/16/2015 12:35 PM, Felix Fietkau wrote

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

On 12/17/2015 02:57 PM, Felix Fietkau wrote: On 2015-12-17 23:01, Peter Oh wrote: On 12/16/2015 03:59 PM, Felix Fietkau wrote: On 2015-12-17 00:50, Peter Oh wrote: On 12/16/2015 01:54 PM, Felix Fietkau wrote: On 2015-12-16 22:19, Peter Oh wrote: On 12/16/2015 12:53 PM, Felix Fietkau wrote

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

On 12/16/2015 12:35 PM, Felix Fietkau wrote: On 2015-12-16 21:29, Peter Oh wrote: On 12/16/2015 10:27 AM, Felix Fietkau wrote: On 2015-12-16 19:20, Peter Oh wrote: Some hardwares such as QCA988X and QCA99X0 doesn't have capability of checksum offload when frame formats are not suitable

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

On 12/16/2015 10:27 AM, Felix Fietkau wrote: On 2015-12-16 19:20, Peter Oh wrote: Some hardwares such as QCA988X and QCA99X0 doesn't have capability of checksum offload when frame formats are not suitable for it such as Mesh frame. Hence add a module parameter, hw_csum, to make checksum

[PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

Some hardwares such as QCA988X and QCA99X0 doesn't have capability of checksum offload when frame formats are not suitable for it such as Mesh frame. Hence add a module parameter, hw_csum, to make checksum offload configurable during module registration time. Signed-off-by: Peter Oh &l

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

On 12/16/2015 12:53 PM, Felix Fietkau wrote: On 2015-12-16 21:46, Peter Oh wrote: On 12/16/2015 12:35 PM, Felix Fietkau wrote: On 2015-12-16 21:29, Peter Oh wrote: On 12/16/2015 10:27 AM, Felix Fietkau wrote: On 2015-12-16 19:20, Peter Oh wrote: Some hardwares such as QCA988X and QCA99X0

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

On 12/16/2015 01:54 PM, Felix Fietkau wrote: On 2015-12-16 22:19, Peter Oh wrote: On 12/16/2015 12:53 PM, Felix Fietkau wrote: On 2015-12-16 21:46, Peter Oh wrote: On 12/16/2015 12:35 PM, Felix Fietkau wrote: On 2015-12-16 21:29, Peter Oh wrote: On 12/16/2015 10:27 AM, Felix Fietkau wrote

[PATCH] ath10k: allow Mesh Point to install peer security key

supporting secured Mesh at this moment. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index bcb364d..b

Re: [PATCH] ath10k: deliver mgmt frames from htt to monitor vifs only

On 11/30/2015 04:56 AM, Grzegorz Bajorski wrote: Until now only WMI originating mgmt frames were reported to mac80211. Management frames on HTT were basically dropped (except frames which looked like management but had FCS error). To allow sniffing all frames (including offloaded frames)

[PATCH 2/3] ath10k: introduce new subtypes for proxy STA and Mesh

QCA988X firmware starting from 10.2.4.70.12-2 supports new vdev subtypes for proxy STA and Mesh, hence add them to be used as needed. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drive

[PATCH 1/3] ath10k: update WMI 10.x service map

Update WMI 10.x service map to sync with firmware 10.2.4.70.12-2 released on 11/11/2015 which is the latest QCA988X firmware as of 11/18/2015. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.h | 15 +++ 1 file changed, 15 insertions(+)

Re: [PATCH 2/2] ath10k: do not use coherent memory for tx buffers

On 11/23/2015 10:18 AM, Felix Fietkau wrote: On 2015-11-23 18:25, Peter Oh wrote: Hi, Have you measured the peak throughput? The pre-allocated coherent memory concept was introduced as once of peak throughput improvement. It's all still pre-allocated and pre-mapped. Right. I mis-guessed

[PATCH] ath10k: Enable VHT for Mesh

in this patch. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index a53e213..d38e4d8 100644 --- a/drivers/net/wireless/ath/ath10k

Re: [PATCH v2] cfg80211: add VHT support for Mesh

On 11/12/2015 01:40 PM, Johannes Berg wrote: On Thu, 2015-11-12 at 13:33 -0800, Peter Oh wrote: At this moment Mesh Point is not able to be brought up by userspace such as wap_supplicant at VHT data rates because there is no events/NL80211 defined that userspace can check out if drivers can

Re: [PATCH v2] cfg80211: add VHT support for Mesh

On 11/12/2015 02:32 PM, Johannes Berg wrote: On Thu, 2015-11-12 at 14:28 -0800, Peter Oh wrote: Exactly the same communication mechanism and purpose are used with NL80211_EXT_FEATURE_VHT_IBSS which is already a part of NL80211 feature flag. The new feature flag, NL80211_EXT_FEATURE_VHT_MESH

[PATCH] ath10k: Enable VHT for Mesh

in this patch. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index a53e213..d38e4d8 100644 --- a/drivers/net/wireless/ath/ath10k

[PATCH] cfg80211: add VHT support for Mesh

Add NL80211_EXT_FEATURE_VHT_MESH flag to allow drivers to indicate support for VHT in Mesh mode. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- include/uapi/linux/nl80211.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl8

Re: [PATCH] ath10k: use pre-allocated DMA buffer in Tx

, Kalle Valo wrote: Peter Oh <p...@qca.qualcomm.com> writes: ath10k driver is using dma_pool_alloc per packet and dma_pool_free in coresponding at Tx completion. Use of pre-allocated DMA buffer in Tx will improve saving CPU resource by 5% while it consumes about 56KB memory more as tra

  1   2   >