evice) and blocks
second AP to come up.
Adding a new API cfg80211_iftype_allowed() to fix the problem, this
API works for all devices with/without SW crypto control.
Signed-off-by: Manikanta Pubbisetty
Fixes: 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto
controlled devices&quo
On 5/14/2019 2:08 PM, Johannes Berg wrote:
On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote:
+++ b/net/mac80211/util.c
@@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct
ieee80211_sub_if_data *sdata,
}
/* Always allow software iftypes */
- if
On 5/3/2019 4:58 PM, Kalle Valo wrote:
Manikanta Pubbisetty writes:
As per the current design, in the case of sw crypto controlled devices,
it is the device which advertises the support for AP/VLAN iftype based
on it's ability to tranmsit packets encrypted in software
(In VLAN function
dr operation on devices which do not support
AP/VLAN iftype but can support 4addr AP operation (decision is based on
the wiphy flag WIPHY_FLAG_4ADDR_AP).
Fixes: db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled
devices")
Signed-off-by: Manikanta Pubbisetty
---
dr operation on devices which do not support
AP/VLAN iftype but can support 4addr AP operation (decision is based on
the wiphy flag WIPHY_FLAG_4ADDR_AP).
Fixes: Commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto
controlled devices")
Signed-off-by: Manikanta Pubbisetty
--
On 11/25/2018 12:18 AM, Johannes Berg wrote:
This looks good to me, just a few nits below
On Wed, 2018-11-21 at 16:33 +0530, Manikanta Pubbisetty wrote:
As per the current design, for sw crypto controlled devices, it is
the device which has to advertise the support for AP/VLAN iftype
based on
n raw mode.
Hardwares Tested : QCA9984, QCA988X
Firmwares Tested : 10.4-3.5.3-00057, 10.2.4-1.0-00042
Signed-off-by: Manikanta Pubbisetty
---
This patch has dependency on mac80211 change
"{nl,mac}80211: allow 4addr AP operation on crypto controlled devices"
v2:
Added support for QCA988
allowing 4addr opertion on devices which do not advertise
AP/VLAN iftype but which can support 4addr operation (the desicion is
taken based on the wiphy flag WIPHY_FLAG_4ADDR_AP).
Fixes: Commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on
crypto controlled devices")
Signed-off
s which do not support this feature,
TX airtime is calculated in the driver using TX bitrate.
Hardwares tested : QCA9984
Firmwares tested : 10.4-3.6.1-00841
Signed-off-by: Manikanta Pubbisetty
---
* Changes are made on top of Rajkumar's changes for ATF
drivers/net/wireless/ath/ath10
On 8/14/2018 5:23 PM, Johannes Berg wrote:
On Tue, 2018-08-14 at 17:22 +0530, Manikanta Pubbisetty wrote:
On 8/14/2018 4:58 PM, Johannes Berg wrote:
On Mon, 2018-07-30 at 11:50 +0530, Manikanta Pubbisetty wrote:
When mac80211 receives a packet, we interate over the list of
active
On 8/14/2018 4:58 PM, Johannes Berg wrote:
On Mon, 2018-07-30 at 11:50 +0530, Manikanta Pubbisetty wrote:
When mac80211 receives a packet, we interate over the list of
active interfaces to find the station(which transmitted the packet).
Currently, station search is not allowed on AP/VLAN
.
Found this during code review; just a theoritical fix.
Signed-off-by: Manikanta Pubbisetty
---
net/mac80211/rx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a16ba56..e3fbed1 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211
On 7/2/2018 3:40 PM, Manikanta Pubbisetty wrote:
As part of hw reconfig, only stations linked to AP interfaces are added
back to the driver ignoring those which are tied to AP_VLAN interfaces.
It is true that there could be stations tied to the AP_VLAN interface while
serving 4addr clients
APIs when wake_tx_queue is implemented
but this could lead to packet drops in network layer; adding stop/start
logic for software TXQs in mac80211 instead makes more sense; the change
proposed adds the same in mac80211.
Signed-off-by: Manikanta Pubbisetty
---
V3:
* renamed _TXQ_PAUSED to
On 7/10/2018 8:52 PM, Toke Høiland-Jørgensen wrote:
Manikanta Pubbisetty writes:
On 7/10/2018 6:28 PM, Toke Høiland-Jørgensen wrote:
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 172aeae..d07f7f9 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211
include/net/mac80211.h:1537: warning: Function parameter or member
'txqs_stopped' not described in 'ieee80211_vif'
Described txq_stopped instead of txqs_stopped; will fix this in the next
version.
Thanks,
Manikanta
On 7/10/2018 6:28 PM, Toke Høiland-Jørgensen wrote:
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 172aeae..d07f7f9 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -818,6 +818,7 @@ enum txq_info_flags {
IEEE80211_TXQ_STOP,
I
On 7/10/2018 12:25 PM, Sven Eckelmann wrote:
On Donnerstag, 5. Juli 2018 10:47:11 CEST Sven Eckelmann wrote:
Hi Toke,
we are currently testing DFS with ath10k and noticed that AQM seems to ignore
cfg80211_csa_settings->block_tx. Problem is now that the channel switch is
started on a detected
APIs when wake_tx_queue is implemented
but this could lead to packet drops in network layer; adding stop/start
logic for software TXQs in mac80211 instead makes more sense; the change
proposed adds the same in mac80211.
Signed-off-by: Manikanta Pubbisetty
---
V2:
* addressed locking issues
for client devices.
Signed-off-by: Manikanta Pubbisetty
---
V2:
* Updated commit log
* Addressed V1 comments
net/mac80211/cfg.c | 2 +-
net/mac80211/key.c | 13 -
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
ind
On 7/9/2018 2:56 PM, Johannes Berg wrote:
On Mon, 2018-07-09 at 14:54 +0530, Manikanta Pubbisetty wrote:
This describes a scenario where there's *unnecessary* work done, but not
really one where we have something that's *incorrect*?
To me at least doing unnecessary things is inc
For example, let's consider the case of a 4-addr client connecting to
an AP for which AP_VLAN interface is also created, let the initial
value for tailroom_needed on the AP be 1.
* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_
VLAN iface.
Restricting delayed decrement to station interface alone fixes the problem
and it makes sense to do so because delayed decrement is done to improve
roam time which is applicable only for client devices.
Signed-off-by: Manikanta Pubbisetty
---
net/mac80211/key.c | 3 ++-
1 file changed, 2
which are
tied to AP_VLANs back to the driver.
Signed-off-by: Manikanta Pubbisetty
---
net/mac80211/util.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 3e68132..88efda7 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211
I'll also review the rest of the patch now, but I'll already note you
should fix the kernel-doc complaint from the kbuild test robot.
Sure, I will take care of this in the next revision of the patch.
Thanks,
Manikanta
+ if (txq->sta) {
+ sta = container_of(txq->sta, struct sta_info, sta);
+ atomic_set(&sta->txqs_paused, 1);
+ }
It seems to me you could remove this - possibly at the expense of doing
a little more work in ieee80211_wake_t
On 6/26/2018 4:55 PM, Toke Høiland-Jørgensen wrote:
Manikanta Pubbisetty writes:
We can still invoke netif stop/wake APIs when wake_tx_queue is
implemented but this could lead to packet drops in network layer;
adding stop/start logic for software TXQs in mac80211 instead makes
more sense
APIs when wake_tx_queue is implemented
but this could lead to packet drops in network layer; adding stop/start
logic for software TXQs in mac80211 instead makes more sense; the change
proposed adds the same in mac80211.
Signed-off-by: Manikanta Pubbisetty
---
net/mac80211/ieee80211_i.h | 6
On 5/28/2018 1:36 PM, Johannes Berg wrote:
On Mon, 2018-05-28 at 12:49 +0530, Manikanta Pubbisetty wrote:
This doesn't seem right, all the logic that clears the TXQ_STOP etc.
still needs to be invoked, otherwise your TXQ will get stuck completely
since you'll never run this code
+++ b/net/mac80211/agg-tx.c
@@ -213,11 +213,15 @@ static void
ieee80211_agg_start_txq(struct sta_info *sta, int tid, bool enable)
{
struct ieee80211_txq *txq = sta->sta.txq[tid];
+ struct ieee80211_local *local = sta->local;
struct txq_info *txqi;
if (!txq)
On 5/23/2018 4:09 PM, Johannes Berg wrote:
On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote:
+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag
+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
+ * operations in the BSS.
Based on the name and initial description, thi
Do you know why it actually broke it? I mean, we should've turned off
the strict requirement for sw crypto control only for the GTK, and that
shouldn't matter so much?
With the change db3bdcb9c3ff, AP/VLAN support is advertised by the
driver conditionally; the primary reason for doing this i
TXQs in mac80211 instead makes more sense; the change
proposed adds the same in mac80211.
Signed-off-by: Manikanta Pubbisetty
---
net/mac80211/agg-tx.c | 4
net/mac80211/ieee80211_i.h | 5 +
net/mac80211/sta_info.c| 3 +++
net/mac80211/tx.c | 3 +++
net/mac80211/util.c
w->wiphy->software_iftypes |=
BIT(NL80211_IFTYPE_AP_VLAN);
everthing else will cause a regression
Am 24.04.2018 um 10:09 schrieb Kalle Valo:
Manikanta Pubbisetty writes:
Mutlicast/broadcast traffic destined for a particular vlan group will
always be encrypted in software. To enable d
ression
Am 24.04.2018 um 10:09 schrieb Kalle Valo:
Manikanta Pubbisetty writes:
Mutlicast/broadcast traffic destined for a particular vlan group will
always be encrypted in software. To enable dynamic VLANs, it requires
driver support for sending software encrypted packets.
In ath10k, sending sw e
n raw mode.
Tested this change on QCA9984(firmware version 10.4-3.5.3-00057).
Signed-off-by: Manikanta Pubbisetty
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/mac.c | 26 --
drivers/net/wireless/ath/ath10k/wmi.h | 21 ++
tion? I may be missing something in configuration.
>
>Thanks & Regards,
>Kavita
>
>
>On Wed, 13 Dec 2017 07:54:00 +, Manikanta Pubbisetty wrote
>> Please CC linux wireless when posting queries on cfg/mac80211.
>>
>> At least, I have not had any issues in i
Please CC linux wireless when posting queries on cfg/mac80211.
At least, I have not had any issues in interface bring up after the latest
regulatory.db change, I have tested it with vanilla ath.git and it worked even
without regulatory.db file.
If you may want to refer, Johannes submitted a patc
_wmi_handle_tdls_peer_event' was not declared. Should it be static?
>
>--
>https://patchwork.kernel.org/patch/9995131/
>
>https://wireless.wiki.kernel.org/en/developers/documentation/submittingpa
>tches
My bad!!
Thanks kalle, I will fix this and send a follow up version.
Manikanta Pubbisetty
>Sorry, almost dropped this thread - my bad.
>
>> > > [Manikanta] Hmmm, I would like to have ieee80211_tx_status_8023
>> > > for now and go with a TODO for single tx reporting mechanism for
>> > > both Ethernet and 802.11 tx formats. Any thoughts?
>> >
>> > There's an additional wrinkle btw - we cu
Hi,
>[Manikanta] In that case I will keep this change, should we consider a separate
>driver hook for legacy/mgmt tx like drv_tx_8023??
>> How about having wake_tx_queue_8023 and ieee80211_tx_dequeue_8023
>so
>> that Ethernet transmit path is totally exclusive. Thoughts??
>
>I'm not sure this will
From: Manikanta Pubbisetty
Updating tx/rx antenna configuration in ath10k is done even before
it is set in target. If setting of the tx/rx antenna config fails then
we will maintain incorrect configuration in ath10k and APIs like
get_antenna will provide incorrect information.
This patch
On 10/20/2015 04:55 PM, Kalle Valo wrote:
From: Alan Liu
Add WMI-TLV and FW API support in ath10k testmode.
Ath10k can get right wmi command format from UTF image
to communicate UTF firmware.
Signed-off-by: Alan Liu
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.c
From: Manikanta Pubbisetty
This patch replaces mutliple if conditional checks with a single if condition
in WMI management rx handler. Found during code review.
Signed-off-by: Manikanta Pubbisetty
---
v2:
1) Changed commit log
2) removed compilation error
drivers/net/wireless
From: Manikanta Pubbisetty
This patch combines several if statements into a single if condition
in WMI management rx handler. Found during code review.
Signed-off-by: Manikanta Pubbisetty
---
drivers/net/wireless/ath/ath10k/wmi.c | 19 +++
1 file changed, 3 insertions(+), 16
makes debug stats prints fw specific by adding a new member
in wmi_ops.
Signed-off-by: Manikanta Pubbisetty
---
drivers/net/wireless/ath/ath10k/debug.c | 593 ++
drivers/net/wireless/ath/ath10k/debug.h | 20 +
drivers/net/wireless/ath/ath10k/wmi-ops.h | 13
47 matches
Mail list logo