[PATCH] ath10k: correct target assert problem due to CE5 stuck

2018-04-12 Thread mpubbise
From: Manikanta Pubbisetty Correct a minor bug in the commit 0628467f97b5 ("ath10k: fix copy engine 5 destination ring stuck") which introduced a change to fix firmware assert that happens when ring indices of copy engine 5 are stuck for a specific duration, problem with this fix is that it did n

[PATCH] ath10k: correct target assert problem due to CE5 stuck

2018-04-12 Thread mpubbise
From: Manikanta Pubbisetty Correct a minor bug in the commit 0628467f97b5 ("ath10k: fix copy engine 5 destination ring stuck") which introduced a change to fix firmware assert that happens when ring indices of copy engine 5 are stuck for a specific duration, problem with this fix is that it did n

[PATCH] mac80211: allow AP_VLAN operation on crypto controlled devices

2018-03-28 Thread mpubbise
From: Manikanta Pubbisetty In the current implementation, mac80211 advertises the support of AP_VLANs based on the driver's support for AP mode; it also blocks encrypted AP_VLAN operation on devices advertising SW_CRYPTO_CONTROL. The implementation seems weird in it's current form and could be o

Re: [RFC] mac80211: advertise supported interface types for sw encryption

2018-03-22 Thread mpubbise
On 2018-03-22 13:36, Johannes Berg wrote: On Thu, 2018-03-22 at 11:51 +0530, mpubb...@codeaurora.org wrote: > So IMHO - just get rid of the bitmap and hard-code AP_VLAN. > I agree with you only partially. Today, I do not see any driver advertising SW_CRYPTO_CONTROL other than ath10k. There

Re: [RFC] mac80211: advertise supported interface types for sw encryption

2018-03-21 Thread mpubbise
On 2018-03-21 13:23, Johannes Berg wrote: On Fri, 2018-03-09 at 11:57 +0530, mpubb...@codeaurora.org wrote: From: Manikanta Pubbisetty Extending SW_CRYPTO_CONTROL interface so that drivers can advertise the interface types on which they can support software encryption. Driver's job is not done

[RFC] mac80211: advertise supported interface types for sw encryption

2018-03-08 Thread mpubbise
From: Manikanta Pubbisetty Extending SW_CRYPTO_CONTROL interface so that drivers can advertise the interface types on which they can support software encryption. Driver's job is not done by advertising the supported vif types alone, they should also return -EOPNOTSUPP from set_key. Mac80211 will

[PATCHv2 2/2] ath10k: handle tdls peer events

2017-11-06 Thread mpubbise
From: Manikanta Pubbisetty Handle tdls peer events from the target. TDLS events for the peer could be discover, teardown, etc. As of now, adding the logic to handle tdls teardown events alone. Teardown due to peer traffic indication(PTR) timeout is one such teardown event from the target. Teste

[PATCHv2 1/2] ath10k: update tdls teardown state to target

2017-11-06 Thread mpubbise
From: Manikanta Pubbisetty It is required to update the teardown state of the peer when a tdls link with that peer is terminated. This information is useful for the target to perform some cleanups wrt the tdls peer. Without proper cleanup, target assumes that the peer is connected and blocks fut

[PATCHv2 0/2] ath10k: more on tdls support for 10.4 firmwares

2017-11-06 Thread mpubbise
From: Manikanta Pubbisetty This patchset includes a bug fix and an enhancement of tdls functionality for 10.4 firmwares. First patch in this series is a bug fix, second one is an enhancement. Manikanta Pubbisetty (2): ath10k: update tdls teardown state to target ath10k: handle tdls peer ev

[PATCH 2/2] ath10k: handle tdls peer events

2017-10-09 Thread mpubbise
From: Manikanta Pubbisetty Handle tdls peer events from the target. TDLS events for the peer could be discover, teardown, etc. As of now, adding the logic to handle tdls teardown events alone. Teardown due to peer traffic indication(PTR) timeout is one such teardown event from the target. Teste

[PATCH 1/2] ath10k: update tdls teardown state to target

2017-10-09 Thread mpubbise
From: Manikanta Pubbisetty It is required to update the teardown state of the peer when a tdls link with that peer is terminated. This information is useful for the target to perform some cleanups wrt the tdls peer. Without proper cleanup, target assumes that the peer is connected and blocks fut

[PATCH 0/2] ath10k: more on tdls support for 10.4 firmwares

2017-10-09 Thread mpubbise
From: Manikanta Pubbisetty This patchset includes a bug fix and an enhancement of tdls functionality for 10.4 firmwares. First patch in this series is a bug fix, second one is an enhancement. Manikanta Pubbisetty (2): ath10k: update tdls teardown state to target ath10k: handle tdls peer eve

[PATCH] mac80211: fix bandwidth computation for TDLS peers

2017-09-25 Thread mpubbise
From: Manikanta Pubbisetty Section 11.23.1 of 80211-2016 specification allows TDLS peers to operate on wider bandwidths though they are connected to a BSS which do not support wider bandwidth operations, provided both the peers advertize wider banwidth capabilities. The existing logic considers

[PATCHv2 2/3] ath10k: add tdls support for 10.4 firmwares

2017-07-18 Thread mpubbise
From: Manikanta Pubbisetty This patch adds the support of TDLS feature for 10.4 firmware versions. A new WMI service is added to advertise the support of TDLS for 10.4 firmwares. Signed-off-by: Manikanta Pubbisetty --- drivers/net/wireless/ath/ath10k/core.c |9 ++ drivers/net/wireless/ath

[PATCHv2 3/3] ath10k: push peer type to target for TDLS peers

2017-07-18 Thread mpubbise
From: Manikanta Pubbisetty WMI interface for all the firmwares(except QCA6174) does not include the type of peer(default/bss/tdls) requested during peer creation, therefore target creates a default peer. TDLS implementation on 10.4 firmware requires host to configure the peer type(tdls) for TDLS

[PATCHv2 1/3] ath10k: extend wmi service map to accommodate new services

2017-07-18 Thread mpubbise
From: Manikanta Pubbisetty Though there is room to accommodate 512 services in wmi service ready event, target uses only first 4-bits of each 32-bit word for advertising wmi services thereby limiting max wmi services to 64. TDLS implementation for 10.4 firmwares introduces new wmi services by ma

[PATCHv2 0/3] TDLS support on 10.4 firmware

2017-07-18 Thread mpubbise
From: Manikanta Pubbisetty This patchset adds TDLS support on 10.4 firmwares. Manikanta Pubbisetty (3): ath10k: extend wmi service map to accommodate new services ath10k: add tdls support for 10.4 firmwares ath10k: push peer type to target for TDLS peers V2: - Commit log corrections -

[PATCH 3/3] ath10k: push peer type to target for TDLS peers

2017-07-11 Thread mpubbise
From: Manikanta Pubbisetty WMI interface for all the firmwares(except QCA6714) does not include the type of peer(default/bss/tdls) requested during peer creation, therefore target creates a default peer. TDLS implementation on 10.4 firmware requires host to configure the peer type(tdls) for TDLS

[PATCH 2/3] ath10k: add tdls support for 10.4 firmwares

2017-07-11 Thread mpubbise
From: Manikanta Pubbisetty This patch adds the support of TDLS feature for 10.4 firmware versions. A new WMI service is added to advertise the support of TDLS for 10.4 firmwares. Signed-off-by: Manikanta Pubbisetty --- drivers/net/wireless/ath/ath10k/core.c |9 ++ drivers/net/wireless/ath

[PATCH 1/3] ath10k: extend wmi service map to accommodate new services

2017-07-11 Thread mpubbise
From: Manikanta Pubbisetty Though there is room to accommodate 512 services in wmi service ready event, target uses only first 4-bits of each 32-bit word for advertising wmi services thereby limiting max wmi services to 64. TDLS implementation for 10.4 firmwares introduces new wmi services by ma

[PATCH 0/3] TDLS support on 10.4 firmware

2017-07-11 Thread mpubbise
From: Manikanta Pubbisetty This patchset adds TDLS support on 10.4 firmwares. Manikanta Pubbisetty (3): ath10k: extend wmi service map to accommodate new services ath10k: add tdls support for 10.4 firmwares ath10k: push peer type to target for TDLS peers drivers/net/wireless/ath/ath10k/c

[RFCv2 1/2] mac80211: Add provision for 802.11 encap offload

2017-03-03 Thread mpubbise
From: Vasanthakumar Thiagarajan Drivers can have the capability to offload 802.11 encap to firmware or hardware for data frames. This patch adds a new hw_flag for driver to advertise the offload support. Transmit path offloading 802.11 header (including cipher headers) encap for data frames will

[RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

2017-03-03 Thread mpubbise
From: Vasanthakumar Thiagarajan Driver (or hw) supporting 802.11 encapsulation offload for data frames can make use of this new xmit path. This patch defines new ndo_ops, all these callbacks are same as ieee80211_dataif_ops other than ndo_start_xmit() which does minimal processing leaving 802.11

[RFCv2 0/2] Add new transmit data path for ethernet frame format

2017-03-03 Thread mpubbise
From: Manikanta Pubbisetty This patch set adds a new transmit data path to offload 802.11 header encap to driver/hardware. Drivers having support for ieee80211 header encap and other offload functionalities which can't be done before encap can make use of this new data path. Currently it is imple