Re: [PATCH 28/28] mac80211: Don't wake up from PS for offchannel TX

On 08/31/2018 01:31 AM, Luca Coelho wrote: ) From: Andrei Otcheretianski Otherwise the offchannel frame might be queued due to IEEE80211_QUEUE_STOP_REASON_PS and later dropped (in ieee80211_tx_frags()). Anyway, it doesn't make much sense to wake up the device during ROC. Signed-off-by:

[PATCH] cfg80211: inspect off channel operation only when off channel given

From: Peter Oh NL80211_ATTR_OFFCHANNEL_TX_OK does not mean given channel is always off channel, but it means the channel given could be off channel. Hence it should not block the given channel to be used if given channel does not require off channel mgmt tx although regulatory domain is non-ETSI

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: [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] mesh: don't process mesh channel switch unless csa ie provided

On 05/07/2018 01:06 PM, Johannes Berg wrote: On Mon, 2018-05-07 at 13:04 -0700, Peter Oh wrote: On 05/07/2018 12:44 PM, Johannes Berg wrote: On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote: From: Peter Oh <peter...@bowerswilkins.com> There is no meaning t

Re: [PATCH] mesh: don't process mesh channel switch unless csa ie provided

On 05/07/2018 12:44 PM, Johannes Berg wrote: On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote: From: Peter Oh <peter...@bowerswilkins.com> There is no meaning to call ieee80211_mesh_process_chnswitch without CSA IE provided, since the function will always return

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

[PATCH] mesh: don't process mesh channel switch unless csa ie provided

From: Peter Oh <peter...@bowerswilkins.com> There is no meaning to call ieee80211_mesh_process_chnswitch without CSA IE provided, since the function will always return error. Signed-off-by: Peter Oh <peter...@bowerswilkins.com> --- net/mac80211/mesh.c | 2 +- 1 file changed, 1 ins

Re: [PATCH 8/9] mac80211: Support adding duration for prepare_tx() callback

where is the 9th patch gone? On 04/20/2018 03:49 AM, Luca Coelho wrote: From: Ilan Peer There are specific cases, such as SAE authentication exchange, that might require long duration to complete. For such cases, add support for indicating to the driver the required

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 2/3] mac80211: limit wmm params to comply with ETSI requirements

+ if (sdata->vif.type == NL80211_IFTYPE_AP) + wmm_ac = >wmm_rule->ap[ac]; + else + wmm_ac = >wmm_rule->client[ac]; + qparam->cw_min = max_t(u16, qparam->cw_min, wmm_ac->cw_min); + qparam->cw_max = max_t(u16, qparam->cw_max, wmm_ac->cw_max);

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

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 v3] mac80211: mesh: fix wrong mesh TTL offset calculation

next-20180126] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/peter-oh-bowerswilkins-com/mac80211-mesh-fix-wrong-mesh-TTL-offset-calculation/20180128-042444 base: https://git.kernel.org/pub/scm

[PATCH v4] mac80211: mesh: fix wrong mesh TTL offset calculation

From: Peter Oh <peter...@bowerswilkins.com> mesh TTL offset in Mesh Channel Switch Parameters element depends on not only Secondary Channel Offset element, but also affected by HT Control field and Wide Bandwidth Channel Switch element. So use element structure to manipulate mesh channel

Re: [PATCH v3] mac80211: mesh: fix wrong mesh TTL offset calculation

Ignore the patch below for now. Just noticed mesh_chansw_params_ie is constance. will come up with new approach. Thanks, Peter On 01/24/2018 05:16 PM, peter...@bowerswilkins.com wrote: From: Peter Oh <peter...@bowerswilkins.com> mesh TTL offset in Mesh Channel Switch Parameters e

[PATCH v3] mac80211: mesh: fix wrong mesh TTL offset calculation

From: Peter Oh <peter...@bowerswilkins.com> mesh TTL offset in Mesh Channel Switch Parameters element depends on not only Secondary Channel Offset element, but also affected by HT Control field and Wide Bandwidth Channel Switch element. Use element structure to correct the miscalculation.

[PATCH v2] mac80211: mesh: fix wrong mesh TTL offset calculation

From: Peter Oh <peter...@bowerswilkins.com> mesh TTL offset in Mesh Channel Switch Parameters element depends on not only Secondary Channel Offset element, but also affected by HT Control field and Wide Bandwidth Channel Switch element. Hence take those values place in. Signed-off-by: Pe

[PATCH] mac80211: mesh: fix wrong mesh TTL offset calculation

From: Peter Oh <peter...@bowerswilkins.com> mesh TTL offset in Mesh Channel Switch Parameters element depends on not only Secondary Channel Offset element, but also affected by HT Control field and Wide Bandwidth Channel Switch element. Hence take those values place in. Signed-off-by: Pe

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: 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: [PATCH] ieee80211: update public action codes

On 06/28/2017 01:16 PM, Arend van Spriel wrote: On 28-06-17 00:07, peter...@bowerswilkins.com wrote: From: Peter Oh <peter...@bowerswilkins.com> Update Public Action field values as updated in IEEE Std 802.11-2016, so that modules/drivers can refer it. Hi Peter, I am prett

[PATCH] ieee80211: update public action codes

From: Peter Oh <peter...@bowerswilkins.com> Update Public Action field values as updated in IEEE Std 802.11-2016, so that modules/drivers can refer it. Signed-off-by: Peter Oh <peter...@bowerswilkins.com> --- include/linux/ieee80211.h | 35 ++- 1 file

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: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

where is 2/3 ? On 06/20/2016 06:00 AM, Maxim Altshul wrote: > Hi All, > This patch series focuses on metric calculation that > occurs during the path selection phase of a mesh network. > > During the path selection phase, the mesh hwmp module > performs metric calculations, that take as parameters

[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

[PATCH v2] 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

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.

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

Thank you! On 02/25/2016 11:32 AM, Sven Eckelmann wrote: On Thursday 25 February 2016 10:53:23 Peter Oh wrote: I see new warnings: drivers/net/wireless/ath/ath10k/wmi.c:2199:16: warning: restricted __le32 degrades to integer drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: restricted

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: [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:

Re: Adjusting_tbtt in mesh capability

On 02/03/2016 12:18 PM, Neelansh Mittal wrote: Currently, for a mesh node ,the mac80211 sync implementation sets the tbtt adjustment bit , when it is adjusting it's tsf as part of Neighbour offset Synchronization(Function:mesh_sync_offset_ adjust_tbtt()) According to ieee80211s specification,

[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 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 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 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>

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

On 01/27/2016 06:04 PM, Yeoh Chun-Yeow wrote: On Thu, Jan 28, 2016 at 5:53 AM, Peter Oh <p...@codeaurora.org> wrote: 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 fi

[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 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

[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>

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

On 01/27/2016 11:11 AM, Ben Greear wrote: On 01/27/2016 10:55 AM, Peter Oh wrote: Abstraction layer for vdev subtype is added to solve subtype mismatch and to give flexible compatibility among different firmware revisions. For instance, 10.2 and 10.4 firmware has different definition

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: [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

[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 11:29 PM, Michal Kazior wrote: On 17 December 2015 at 00:50, Peter Oh <p...@codeaurora.org> wrote: On 12/16/2015 01:54 PM, Felix Fietkau wrote: On 2015-12-16 22:19, Peter Oh wrote: [...] If mentioned to use the function to mesh frame only without touching mac80211, then

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 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

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

[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)

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

I believe the robot report is false. Am I right? Thanks, Peter On 11/24/2015 01:19 PM, kbuild test robot wrote: Hi Peter, [auto build test WARNING on net-next/master] [also build test WARNING on v4.4-rc2 next-20151124] url: https://github.com/0day-ci/linux/commits/Peter-Oh/ath10k-introduce

[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 3/3] ath10k: apply Mesh subtype when Mesh interface created.

) to be received via the interface, once Mesh subtype is used. The firmware and this patch together make native Wi-Fi mode comply to IEEE802.11s Mesh frame in open mode, but the firmware doesn't yet support secured Mesh mode. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wirele

[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(+)

[PATCH 0/3] ath10k: introduce Mesh support in native WiFi mode for QCA988X

QCA988X firmware has started supporting Mesh frame in native Wi-Fi mode by adding its subtype since 10.2.4.70.12-2. Hence update its WMI service map and vdev subtypes to be used for Mesh in native Wi-Fi mode. Peter Oh (3): ath10k: update WMI 10.x service map ath10k: introduce new subtypes

[PATCH] ath10k: fix board data fetch error message

The error message order of board data fetch is board info, directory, and then file name, hence place print arguments in the order. Fixes: 0a51b343abfe ("ath10k: add board 2 API support") Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/core.

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

On 11/12/2015 11:37 PM, Johannes Berg wrote: On Thu, 2015-11-12 at 15:05 -0800, Peter Oh wrote: 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

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

On 11/12/2015 12:03 PM, Johannes Berg wrote: On Thu, 2015-11-12 at 09:59 -0800, Peter Oh wrote: Add NL80211_EXT_FEATURE_VHT_MESH flag to allow drivers to indicate support for VHT in Mesh mode. This flag will be used by wireless drivers to indicate the capability of VHT Mesh support

[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

[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 v2] cfg80211: add VHT support for Mesh

patches to ath10k driver and wpa_supplicant are also sent out. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- v2: - updated commit message for details --- include/uapi/linux/nl80211.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/nl80211.h b/include/uapi

[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

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

FYI, pre-allocated dma is coherent dma used in Tx only and only freed when ath10k driver stops. On 10/08/2015 10:17 AM, Peter Oh wrote: Does it happen after you applied copy engine patchset or even without the patchset? I saw ath10k_pci_htt_tx_cb in backtrace which is not merged to master branch

Re: [PATCH] Revert "mac80211: remove exposing 'mfp' to drivers"

On 10/06/2015 10:10 PM, c_tr...@qti.qualcomm.com wrote: From: Tamizh chelvam This reverts commit 5c48f1201744233d4f235c7dd916d5196ed20716. Some device drivers (ath10k) offload part of aggregation including AddBA/DelBA negotiations to firmware. In such scenario, the

Re: [PATCH] ath10k: only advertise mesh support in raw mode

On 09/30/2015 07:54 PM, Bob Copeland wrote: On Mon, Sep 28, 2015 at 10:27:30AM -0700, Peter Oh wrote: I prefer the current design to this new approach because drivers already know if it's mesh capable or not at build time, hence adding runtime configuration is redundant. I do think

Re: [PATCH] ath10k: only advertise mesh support in raw mode

Hi, On 09/28/2015 05:59 AM, Bob Copeland wrote: Rather than always advertising mesh support and then generating an error when the user attempts to bring up the device without rawmode, only advertise it when available: that is, if the module is loaded with rawmode=1, the firmware supports it,

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

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 trade off. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drive

[PATCH] ath10k: use Rx decap mode configured when driver registered

registration stage in case of using raw mode, so that host driver receives MAC frame header containing necessary fields such as QoS and Mesh Control and uses them in right way to make data traffic work. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi

Re: [PATCH 3/3] ath10k: implement mesh support

On 09/17/2015 10:48 AM, Yeoh Chun-Yeow wrote: Hi, Bob I have also tested with nwifi mode for non-secured mesh. It seems to be worked for me with the following two test scenarios: Node 1 [ath10k] <---> Node 2 [ath10k] <---> Node 3 [ath10k] Node 1 [ath10k] <---> Node 2 [ath9k] I am using the

Re: [PATCH 3/3] ath10k: implement mesh support

On 09/10/2015 12:22 AM, Johannes Berg wrote: On Wed, 2015-09-09 at 12:49 -0400, Bob Copeland wrote: On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: I did a quick smoke test and saw the splat below. It's this warning from cfg80211: /*

[PATCH] ath: fix incorrect PPB on JAPAN chirp radar

to avoid false detection. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c

[PATCH v2] ath: use PRI value given by spec for fixed PRI

valid. By using spec defined PRI for fixed PRI, we can correct this error. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- v2: * replaced numeral 16 with PRI_TOLERANCE macro --- drivers/net/wireless/ath/dfs_pattern_detector.c | 6 -- drivers/net/wireless/ath/dfs_pattern_detector

[PATCH v2] ath: use PRI value given by spec for fixed PRI

valid. By using spec defined PRI for fixed PRI, we can correct this error. Signed-off-by: Peter Oh <p...@qca.qualcomm.com> --- drivers/net/wireless/ath/dfs_pattern_detector.c | 6 -- drivers/net/wireless/ath/dfs_pattern_detector.h | 5 + drivers/net/wireless/ath/dfs_pri_detector.c

Re: [PATCH] ath: use PRI value given by spec for fixed PRI

Hi Zefir, I believe the patch below is good to be checked in since you've already made change in DFS. Can you confirm it? Thanks, Peter On 04/01/2015 03:04 AM, Zefir Kurtisi wrote: On 03/30/2015 07:57 PM, Peter Oh wrote: On 03/30/2015 02:55 AM, Zefir Kurtisi wrote: [...] That's why I

Re: [PATCH] ath10k: Add QCA99X0 to supported device list

On 08/06/2015 12:59 AM, Felix Fietkau wrote: On 2015-08-06 09:43, Vasanthakumar Thiagarajan wrote: On Wednesday 05 August 2015 05:51 PM, Felix Fietkau wrote: On 2015-07-21 13:36, Vasanthakumar Thiagarajan wrote: Add vendor/device id of QCA99X0 V2.0 to pci id table and

  1   2   >