Re: [RFC 0/7] netlink: Add allocation flag to netlink_unicast()

[Masashi Honma]

On 2016年07月06日 09:28, Masashi Honma wrote:
> Though netlink_broadcast() ...

Thanks for reply of David Miller, Eric Dumazet, David Teigrand.

On the basis of their comment, only rtnl_unicast() looks need to add gfp
flag
argument. So I will drop almost of patches except 0005.

I will send patch v2 to more limited destination.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull-request: mac80211 2016-07-06

[David Miller]

From: Johannes Berg 
Date: Wed,  6 Jul 2016 14:27:43 +0200

> People found two more bugs, so I have two more fixes. Both are related to
> memory - one's a leak, the other is a missing allocation failure check.
> 
> These are both tagged for stable already, and shouldn't conflict with any
> other patches, so if they won't go in any more it won't be a big deal.
> 
> Let me know if there's any problem.

Pulled, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/7] netlink: Add allocation flag to netlink_unicast()

[Masashi Honma]

On 2016年07月09日 01:08, David Teigland wrote:

On Thu, Jul 07, 2016 at 09:35:45AM +0900, Masashi Honma wrote:

At the fs/dlm/netlink.c#dlm_timeout_warn(),
prepare_data allocates buffer with GFP_NOFS
and send_data() sends the buffer.

But send_data() uses GFP_KERNEL or GFP_ATOMIC inside it.
Should it be replaced by GFP_NOFS ?

That's old code that's never been used so it doesn't really matter.


I see. Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath6kl: sme_state shortcut to SME_DISCONNECTED removed

[engineering]

From: Dan Kephart 

When an NL80211_DISCONNECT is sent to cfg80211, the driver's cfg80211
disconnect function sets the sme_state to SME_DISCONNECTED before receiving
a WMI_DISCONNECT_EVENT from the firmware.  This caused cfg80211 to not know
that the connection is disconnected because the driver fails to notify
cfg80211 upon receiving WMI_DISCONNECT_EVENT from the firmware believing
it is already disconnected.

Signed-off-by: Dan Kephart 
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index ef5b40e..86a860f 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -847,8 +847,6 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
 
up(>sem);
 
-   vif->sme_state = SME_DISCONNECTED;
-
return 0;
 }
 
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 2/3] core: Always notify of new wireless netdevs

[Denis Kenzior]

This change alters the semantics of NL80211_CMD_NEW_INTERFACE events
by always sending this event whenever a new net_device object
associated with a wdev is registered.  Prior to this change, this event
was only sent as a result of NL80211_CMD_NEW_INTERFACE command sent
from userspace.  This allows userspace to reliably detect new wireless
interfaces (e.g. due to hardware hot-plug events, etc).

For wdevs created without an associated net_device object (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_NEW_INTERFACE event is
still generated inside the relevant nl80211 command handler.

Signed-off-by: Denis Kenzior 
---
 net/wireless/core.c|  2 ++
 net/wireless/nl80211.c | 23 +--
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..7758c0f 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1079,6 +1079,8 @@ static int cfg80211_netdev_notifier_call(struct 
notifier_block *nb,
 wdev->iftype == NL80211_IFTYPE_P2P_CLIENT ||
 wdev->iftype == NL80211_IFTYPE_ADHOC) && !wdev->use_4addr)
dev->priv_flags |= IFF_DONT_BRIDGE;
+
+   nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
break;
case NETDEV_GOING_DOWN:
cfg80211_leave(rdev, wdev);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index da03e17..ec8eb88 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2787,7 +2787,7 @@ static int nl80211_new_interface(struct sk_buff *skb, 
struct genl_info *info)
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct vif_params params;
struct wireless_dev *wdev;
-   struct sk_buff *msg, *event;
+   struct sk_buff *msg;
int err;
enum nl80211_iftype type = NL80211_IFTYPE_UNSPECIFIED;
u32 flags;
@@ -2891,20 +2891,15 @@ static int nl80211_new_interface(struct sk_buff *skb, 
struct genl_info *info)
return -ENOBUFS;
}
 
-   event = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
-   if (event) {
-   if (nl80211_send_iface(event, 0, 0, 0,
-  rdev, wdev, false) < 0) {
-   nlmsg_free(event);
-   goto out;
-   }
-
-   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy),
-   event, 0, NL80211_MCGRP_CONFIG,
-   GFP_KERNEL);
-   }
+   /*
+* For wdevs which have no associated netdev object (e.g. of type
+* NL80211_IFTYPE_P2P_DEVICE), emit the NEW_INTERFACE event here.
+* For all other types, the event will be generated from the
+* netdev notifier
+*/
+   if (!wdev->netdev)
+   nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
 
-out:
return genlmsg_reply(msg, info);
 }
 
-- 
2.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 3/3] core: Always notify when wireless netdev is removed

[Denis Kenzior]

This change alters the semantics of NL80211_CMD_DEL_INTERFACE events
by always sending this event whenever a net_device object associated
with a wdev is destroyed.  Prior to this change, this event was only
emitted as a result of NL80211_CMD_DEL_INTERFACE command sent from
userspace.  This allows userspace to reliably detect when wireless
interfaces have been removed, e.g. due to USB removal events, etc.

For wireless device objects without an associated net_device (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_DEL_INTERFACE event is
now generated inside cfg80211_unregister_wdev.

Signed-off-by: Denis Kenzior 
---
 net/wireless/core.c|  4 
 net/wireless/nl80211.c | 18 +-
 2 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7758c0f..fccead7 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -906,6 +906,8 @@ void cfg80211_unregister_wdev(struct wireless_dev *wdev)
if (WARN_ON(wdev->netdev))
return;
 
+   nl80211_notify_iface(rdev, wdev, NL80211_CMD_DEL_INTERFACE);
+
list_del_rcu(>list);
rdev->devlist_generation++;
 
@@ -1159,6 +1161,8 @@ static int cfg80211_netdev_notifier_call(struct 
notifier_block *nb,
 * remove and clean it up.
 */
if (!list_empty(>list)) {
+   nl80211_notify_iface(rdev, wdev,
+   NL80211_CMD_DEL_INTERFACE);
sysfs_remove_link(>dev.kobj, "phy80211");
list_del_rcu(>list);
rdev->devlist_generation++;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ec8eb88..bc45d8a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2907,18 +2907,10 @@ static int nl80211_del_interface(struct sk_buff *skb, 
struct genl_info *info)
 {
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct wireless_dev *wdev = info->user_ptr[1];
-   struct sk_buff *msg;
-   int status;
 
if (!rdev->ops->del_virtual_intf)
return -EOPNOTSUPP;
 
-   msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
-   if (msg && nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, true) < 0) {
-   nlmsg_free(msg);
-   msg = NULL;
-   }
-
/*
 * If we remove a wireless device without a netdev then clear
 * user_ptr[1] so that nl80211_post_doit won't dereference it
@@ -2929,15 +2921,7 @@ static int nl80211_del_interface(struct sk_buff *skb, 
struct genl_info *info)
if (!wdev->netdev)
info->user_ptr[1] = NULL;
 
-   status = rdev_del_virtual_intf(rdev, wdev);
-   if (status >= 0 && msg)
-   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy),
-   msg, 0, NL80211_MCGRP_CONFIG,
-   GFP_KERNEL);
-   else
-   nlmsg_free(msg);
-
-   return status;
+   return rdev_del_virtual_intf(rdev, wdev);
 }
 
 static int nl80211_set_noack_map(struct sk_buff *skb, struct genl_info *info)
-- 
2.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 1/3] nl80211: Add nl80211_notify_iface

[Denis Kenzior]

This function emits NL80211_CMD_NEW_INTERFACE or
NL80211_CMD_DEL_INTERFACE events.  This is meant to be used by the core
to notify userspace applications such as wpa_supplicant when a netdev
related to a wireless device has been added or removed.

Signed-off-by: Denis Kenzior 
---
 net/wireless/nl80211.c | 28 
 net/wireless/nl80211.h |  3 +++
 2 files changed, 31 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f39fd4d..da03e17 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11855,6 +11855,34 @@ void nl80211_notify_wiphy(struct 
cfg80211_registered_device *rdev,
NL80211_MCGRP_CONFIG, GFP_KERNEL);
 }
 
+void nl80211_notify_iface(struct cfg80211_registered_device *rdev,
+   struct wireless_dev *wdev,
+   enum nl80211_commands cmd)
+{
+   struct sk_buff *msg;
+   bool removal;
+
+   WARN_ON(cmd != NL80211_CMD_NEW_INTERFACE &&
+   cmd != NL80211_CMD_DEL_INTERFACE);
+
+   if (cmd == NL80211_CMD_DEL_INTERFACE)
+   removal = true;
+   else
+   removal = false;
+
+   msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+   if (!msg)
+   return;
+
+   if (nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, removal) < 0) {
+   nlmsg_free(msg);
+   return;
+   }
+
+   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy), msg, 0,
+   NL80211_MCGRP_CONFIG, GFP_KERNEL);
+}
+
 static int nl80211_add_scan_req(struct sk_buff *msg,
struct cfg80211_registered_device *rdev)
 {
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index a63f402..6f6b73c 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -7,6 +7,9 @@ int nl80211_init(void);
 void nl80211_exit(void);
 void nl80211_notify_wiphy(struct cfg80211_registered_device *rdev,
  enum nl80211_commands cmd);
+void nl80211_notify_iface(struct cfg80211_registered_device *rdev,
+   struct wireless_dev *wdev,
+   enum nl80211_commands cmd);
 void nl80211_send_scan_start(struct cfg80211_registered_device *rdev,
 struct wireless_dev *wdev);
 struct sk_buff *nl80211_build_scan_msg(struct cfg80211_registered_device *rdev,
-- 
2.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 0/3] Improve wireless netdev detection

[Denis Kenzior]

The current mechanism to detect hot-plug / unplug of wireless devices is
somewhat arcane.  One has to listen to NEW_WIPHY/DEL_WIPHY events over
nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
somehow find a correlation between these events.  This involves userspace
sending GET_INTERFACE or GET_WIPHY commands to the kernel, which incurs
additional roundtrips.

This patch series proposes that NEW_INTERFACE and DEL_INTERFACE events are
always emitted, regardless of whether a netdev was added/removed by the
driver or explicitly via NEW_INTERFACE/DEL_INTERFACE commands.

v2: Squished patches 2+3, 4+5.  DEL_INTERFACE event notification is now
sent inside cfg80211_unregister_wdev instead of nl80211_del_interface.

Denis Kenzior (3):
  nl80211: Add nl80211_notify_iface
  core: Always notify of new wireless netdevs
  core: Always notify when wireless netdev is removed

 net/wireless/core.c|  6 +
 net/wireless/nl80211.c | 69 +++---
 net/wireless/nl80211.h |  3 +++
 3 files changed, 47 insertions(+), 31 deletions(-)

-- 
2.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Sebastian Gottschall]

for me it crashes on wds sta on 3.18 kernels. need to solder a serial to 
get more logs


Am 08.07.2016 um 18:31 schrieb Felix Fietkau:

On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote:

Felix Fietkau  writes:


On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:

Kalle Valo  writes:


Toke Høiland-Jørgensen wrote:

This switches ath9k over to using the mac80211 intermediate software
queueing mechanism for data packets. It removes the queueing inside the
driver, except for the retry queue, and instead pulls from mac80211 when
a packet is needed. The retry queue is used to store a packet that was
pulled but can't be sent immediately.

The old code path in ath_tx_start that would queue packets has been
removed completely, as has the qlen limit tunables (since there's no
longer a queue in the driver to limit).

Based on Tim's original patch set, but reworked quite thoroughly.

Cc: Tim Shepard 
Cc: Felix Fietkau 
Signed-off-by: Toke Høiland-Jørgensen 

Nice work.

Thanks :)


Because this is such a significant change, and to maximise testing
time, I'm planning to queue this for 4.9 (so I would apply this to
ath-next in 3-4 weeks after the merge window closes). But anyone who
wants to test this can use master-pending branch from my ath.git tree
(uses wireless-testing as the baseline). Sounds good?

Sounds good to me. I'm planning on backporting this and Michael's
mac80211 FQ-CoDel patches to 4.4 and post them for inclusion in LEDE.
Hopefully that will get it some more testing as well.

I've pushed a backport of this into my LEDE staging tree:
https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary

Awesome! What about the FQ-CoDel mac80211 patches themselves? I have a
tree where I've separated out the needed patches and rebased them on
mainline 4.4.9. Can I post that somewhere (or just email you the series)
and get you to include those as well? Or do I just dump the patch files
into the LEDE patches dir and send that as a patch to LEDE? (I see your
patch also refreshed subsequent patches; is there a script to do that
automatically?)

You don't need to do anything here. LEDE does not use mac80211 and
drivers from the kernel tree, it's built using backports.
It's currently using a backports snapshot that I built myself from
wireless-testing 2016-06-20, which already includes FQ-Codel.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Toke Høiland-Jørgensen]

Felix Fietkau  writes:

> On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau  writes:
>> 
>>> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
 Kalle Valo  writes:
 
> Toke Høiland-Jørgensen wrote:
>> This switches ath9k over to using the mac80211 intermediate software
>> queueing mechanism for data packets. It removes the queueing inside the
>> driver, except for the retry queue, and instead pulls from mac80211 when
>> a packet is needed. The retry queue is used to store a packet that was
>> pulled but can't be sent immediately.
>> 
>> The old code path in ath_tx_start that would queue packets has been
>> removed completely, as has the qlen limit tunables (since there's no
>> longer a queue in the driver to limit).
>> 
>> Based on Tim's original patch set, but reworked quite thoroughly.
>> 
>> Cc: Tim Shepard 
>> Cc: Felix Fietkau 
>> Signed-off-by: Toke Høiland-Jørgensen 
>
> Nice work.
 
 Thanks :)
 
> Because this is such a significant change, and to maximise testing
> time, I'm planning to queue this for 4.9 (so I would apply this to
> ath-next in 3-4 weeks after the merge window closes). But anyone who
> wants to test this can use master-pending branch from my ath.git tree
> (uses wireless-testing as the baseline). Sounds good?
 
 Sounds good to me. I'm planning on backporting this and Michael's
 mac80211 FQ-CoDel patches to 4.4 and post them for inclusion in LEDE.
 Hopefully that will get it some more testing as well.
>>> I've pushed a backport of this into my LEDE staging tree:
>>> https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary
>> 
>> Awesome! What about the FQ-CoDel mac80211 patches themselves? I have a
>> tree where I've separated out the needed patches and rebased them on
>> mainline 4.4.9. Can I post that somewhere (or just email you the series)
>> and get you to include those as well? Or do I just dump the patch files
>> into the LEDE patches dir and send that as a patch to LEDE? (I see your
>> patch also refreshed subsequent patches; is there a script to do that
>> automatically?)
> You don't need to do anything here. LEDE does not use mac80211 and
> drivers from the kernel tree, it's built using backports.
> It's currently using a backports snapshot that I built myself from
> wireless-testing 2016-06-20, which already includes FQ-Codel.

Ah, didn't know that. Cool; and thanks for taking care of the
backporting :)

-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Felix Fietkau]

On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote:
> Felix Fietkau  writes:
> 
>> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
>>> Kalle Valo  writes:
>>> 
 Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
> 
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
> 
> Based on Tim's original patch set, but reworked quite thoroughly.
> 
> Cc: Tim Shepard 
> Cc: Felix Fietkau 
> Signed-off-by: Toke Høiland-Jørgensen 

 Nice work.
>>> 
>>> Thanks :)
>>> 
 Because this is such a significant change, and to maximise testing
 time, I'm planning to queue this for 4.9 (so I would apply this to
 ath-next in 3-4 weeks after the merge window closes). But anyone who
 wants to test this can use master-pending branch from my ath.git tree
 (uses wireless-testing as the baseline). Sounds good?
>>> 
>>> Sounds good to me. I'm planning on backporting this and Michael's
>>> mac80211 FQ-CoDel patches to 4.4 and post them for inclusion in LEDE.
>>> Hopefully that will get it some more testing as well.
>> I've pushed a backport of this into my LEDE staging tree:
>> https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary
> 
> Awesome! What about the FQ-CoDel mac80211 patches themselves? I have a
> tree where I've separated out the needed patches and rebased them on
> mainline 4.4.9. Can I post that somewhere (or just email you the series)
> and get you to include those as well? Or do I just dump the patch files
> into the LEDE patches dir and send that as a patch to LEDE? (I see your
> patch also refreshed subsequent patches; is there a script to do that
> automatically?)
You don't need to do anything here. LEDE does not use mac80211 and
drivers from the kernel tree, it's built using backports.
It's currently using a backports snapshot that I built myself from
wireless-testing 2016-06-20, which already includes FQ-Codel.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Toke Høiland-Jørgensen]

Felix Fietkau  writes:

> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
>> Kalle Valo  writes:
>> 
>>> Toke Høiland-Jørgensen wrote:
 This switches ath9k over to using the mac80211 intermediate software
 queueing mechanism for data packets. It removes the queueing inside the
 driver, except for the retry queue, and instead pulls from mac80211 when
 a packet is needed. The retry queue is used to store a packet that was
 pulled but can't be sent immediately.
 
 The old code path in ath_tx_start that would queue packets has been
 removed completely, as has the qlen limit tunables (since there's no
 longer a queue in the driver to limit).
 
 Based on Tim's original patch set, but reworked quite thoroughly.
 
 Cc: Tim Shepard 
 Cc: Felix Fietkau 
 Signed-off-by: Toke Høiland-Jørgensen 
>>>
>>> Nice work.
>> 
>> Thanks :)
>> 
>>> Because this is such a significant change, and to maximise testing
>>> time, I'm planning to queue this for 4.9 (so I would apply this to
>>> ath-next in 3-4 weeks after the merge window closes). But anyone who
>>> wants to test this can use master-pending branch from my ath.git tree
>>> (uses wireless-testing as the baseline). Sounds good?
>> 
>> Sounds good to me. I'm planning on backporting this and Michael's
>> mac80211 FQ-CoDel patches to 4.4 and post them for inclusion in LEDE.
>> Hopefully that will get it some more testing as well.
> I've pushed a backport of this into my LEDE staging tree:
> https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary

Awesome! What about the FQ-CoDel mac80211 patches themselves? I have a
tree where I've separated out the needed patches and rebased them on
mainline 4.4.9. Can I post that somewhere (or just email you the series)
and get you to include those as well? Or do I just dump the patch files
into the LEDE patches dir and send that as a patch to LEDE? (I see your
patch also refreshed subsequent patches; is there a script to do that
automatically?)

> I don't have time for testing it myself at the moment, but I'll try to
> get some people to do so.

Awesome :)

-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Felix Fietkau]

On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
> Kalle Valo  writes:
> 
>> Toke Høiland-Jørgensen wrote:
>>> This switches ath9k over to using the mac80211 intermediate software
>>> queueing mechanism for data packets. It removes the queueing inside the
>>> driver, except for the retry queue, and instead pulls from mac80211 when
>>> a packet is needed. The retry queue is used to store a packet that was
>>> pulled but can't be sent immediately.
>>> 
>>> The old code path in ath_tx_start that would queue packets has been
>>> removed completely, as has the qlen limit tunables (since there's no
>>> longer a queue in the driver to limit).
>>> 
>>> Based on Tim's original patch set, but reworked quite thoroughly.
>>> 
>>> Cc: Tim Shepard 
>>> Cc: Felix Fietkau 
>>> Signed-off-by: Toke Høiland-Jørgensen 
>>
>> Nice work.
> 
> Thanks :)
> 
>> Because this is such a significant change, and to maximise testing
>> time, I'm planning to queue this for 4.9 (so I would apply this to
>> ath-next in 3-4 weeks after the merge window closes). But anyone who
>> wants to test this can use master-pending branch from my ath.git tree
>> (uses wireless-testing as the baseline). Sounds good?
> 
> Sounds good to me. I'm planning on backporting this and Michael's
> mac80211 FQ-CoDel patches to 4.4 and post them for inclusion in LEDE.
> Hopefully that will get it some more testing as well.
I've pushed a backport of this into my LEDE staging tree:
https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary

I don't have time for testing it myself at the moment, but I'll try to
get some people to do so.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
 wrote:
> I think security failures are due to peer unmap & map upon reassoc. Can you 
> please try below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..f7f04bb46fc8 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct 
> *wk)
> sta->addr, smps, err);
> }
>
> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> -   changed & IEEE80211_RC_NSS_CHANGED) {
> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> +   changed & IEEE80211_RC_NSS_CHANGED) &&
> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
> rates/nss\n",
>sta->addr);

Bottom posting please. I have tried your change i still see the same issue.
Right after connecting i see that packets are encrypted but once it
unset/set "bitrates" plain packets are seen in sniffer.

BTW, i am not rebooting for each driver update, just re-inserting the module,
do i need to do a reboot for each driver change?
 
> From: Krishna Chaitanya 
> Sent: Friday, July 8, 2016 5:26 PM
> To: Manoharan, Rajkumar
> Cc: linux-wireless; ath10k
> Subject: Re: ath10k + iw set bitrates is causing FW crash
>
> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>  wrote:
 I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
 VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).

 But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
 no crash is observed but it still uses MCS9.

 tree: wireless-drivers-next: 
 commit#535633a5ba4ea2504fa6c33176633becf0e59339

 1) If i disable HW_RATE_CONTROL, will ath10k honor
 the mac80211 rates?

>>>
>> Thanks for reporting the issue. Could you please try with below change?
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>> return ret;
>> }
>>
>> +   if (vif->type != NL80211_IFTYPE_ADHOC)
>> +   peer_arg.peer_reassoc = reassoc;
>> +
>> ret = ath10k_wmi_peer_assoc(ar, _arg);
>> if (ret) {
>> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
>> %i: %d\n",
>
> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> seeing 0-9, so its
> working.
>
> But i am seeing a weird issues, the moment i give bitrates command,
> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> interface up/down
> it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:17 PM, Ben Greear  wrote:
> On 07/08/2016 08:44 AM, Krishna Chaitanya wrote:
>>
>> On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear 
>> wrote:
>>>
>>> On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:
>>>
 Also can you please tell me how to make ath10k use minstrel rc, its
 needed
 for comparative purposes? Is disable HW_RATE_CONTROL enough or does
 it need more changes?
>>>
>>>
>>>
>>> It cannot be done.  You have to use whatever rate-ctrl is baked into the
>>> firmware.
>>
>> Ok, its a good feature to have.
>>
>
> It is unlikely to happen anytime soon.  It requires significant firmware
> modification (and driver too),
Ok, I understand.
>and probably you would have to add MU-MIMO
> support to minstrel if you wanted to support latest ath10k NICs.
It need not be a full pledged one, but 11ac MIMO works should be
good enough (for now).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Toke Høiland-Jørgensen]

Kalle Valo  writes:

> Toke Høiland-Jørgensen wrote:
>> This switches ath9k over to using the mac80211 intermediate software
>> queueing mechanism for data packets. It removes the queueing inside the
>> driver, except for the retry queue, and instead pulls from mac80211 when
>> a packet is needed. The retry queue is used to store a packet that was
>> pulled but can't be sent immediately.
>> 
>> The old code path in ath_tx_start that would queue packets has been
>> removed completely, as has the qlen limit tunables (since there's no
>> longer a queue in the driver to limit).
>> 
>> Based on Tim's original patch set, but reworked quite thoroughly.
>> 
>> Cc: Tim Shepard 
>> Cc: Felix Fietkau 
>> Signed-off-by: Toke Høiland-Jørgensen 
>
> Nice work.

Thanks :)

> Because this is such a significant change, and to maximise testing
> time, I'm planning to queue this for 4.9 (so I would apply this to
> ath-next in 3-4 weeks after the merge window closes). But anyone who
> wants to test this can use master-pending branch from my ath.git tree
> (uses wireless-testing as the baseline). Sounds good?

Sounds good to me. I'm planning on backporting this and Michael's
mac80211 FQ-CoDel patches to 4.4 and post them for inclusion in LEDE.
Hopefully that will get it some more testing as well.

> Testing and review feedback very welcome!

My own evaluation results are here:
https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html
-- I see aggregate throughput to multiple stations improve by a factor
of ~3 and latency under load decrease by a factor of ~10 now that we can
take advantage of the mac80211 FQ-CoDel patches.

-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Ben Greear]

On 07/08/2016 08:44 AM, Krishna Chaitanya wrote:

On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear  wrote:

On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:


Also can you please tell me how to make ath10k use minstrel rc, its needed
for comparative purposes? Is disable HW_RATE_CONTROL enough or does
it need more changes?



It cannot be done.  You have to use whatever rate-ctrl is baked into the
firmware.

Ok, its a good feature to have.



It is unlikely to happen anytime soon.  It requires significant firmware
modification (and driver too), and probably you would have to add MU-MIMO
support to minstrel if you wanted to support latest ath10k NICs.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear  wrote:
> On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:
>
>> Also can you please tell me how to make ath10k use minstrel rc, its needed
>> for comparative purposes? Is disable HW_RATE_CONTROL enough or does
>> it need more changes?
>
>
> It cannot be done.  You have to use whatever rate-ctrl is baked into the
> firmware.
Ok, its a good feature to have.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Ben Greear]

On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:


Also can you please tell me how to make ath10k use minstrel rc, its needed
for comparative purposes? Is disable HW_RATE_CONTROL enough or does
it need more changes?


It cannot be done.  You have to use whatever rate-ctrl is baked into the
firmware.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya
 wrote:
> On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
>  wrote:
>> On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
>>  wrote:
>>> I think security failures are due to peer unmap & map upon reassoc. Can you 
>>> please try below change?
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 5e1cc8f4c43c..f7f04bb46fc8 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct 
>>> work_struct *wk)
>>> sta->addr, smps, err);
>>> }
>>>
>>> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>>> -   changed & IEEE80211_RC_NSS_CHANGED) {
>>> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>>> +   changed & IEEE80211_RC_NSS_CHANGED) &&
>>> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
>>> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
>>> rates/nss\n",
>>>sta->addr);
>>
>> Bottom posting please. I have tried your change i still see the same issue.
>> Right after connecting i see that packets are encrypted but once it
>> unset/set "bitrates" plain packets are seen in sniffer.
>>
>> BTW, i am not rebooting for each driver update, just re-inserting the module,
>> do i need to do a reboot for each driver change?
>
> After reboot i dont see the "unencrypted" packet issue, i will do
> some more testing on limiting the rates, currently in my setup its
> not reaching MCS9 so cannot verify now.
>
> Thanks for the fixes and prompt reply.
>   
>>> From: Krishna Chaitanya 
>>> Sent: Friday, July 8, 2016 5:26 PM
>>> To: Manoharan, Rajkumar
>>> Cc: linux-wireless; ath10k
>>> Subject: Re: ath10k + iw set bitrates is causing FW crash
>>>
>>> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>>>  wrote:
>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>
>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>> no crash is observed but it still uses MCS9.
>>
>> tree: wireless-drivers-next: 
>> commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>
>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>> the mac80211 rates?
>>
>
 Thanks for reporting the issue. Could you please try with below change?

 diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
 b/drivers/net/wireless/ath/ath10k/mac.c
 index 5e1cc8f4c43c..cfa7e01a6103 100644
 --- a/drivers/net/wireless/ath/ath10k/mac.c
 +++ b/drivers/net/wireless/ath/ath10k/mac.c
 @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
 return ret;
 }

 +   if (vif->type != NL80211_IFTYPE_ADHOC)
 +   peer_arg.peer_reassoc = reassoc;
 +
 ret = ath10k_wmi_peer_assoc(ar, _arg);
 if (ret) {
 ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
 %i: %d\n",
>>>
>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>> seeing 0-9, so its
>>> working.
>>>
>>> But i am seeing a weird issues, the moment i give bitrates command,
>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>> interface up/down
>>> it doesn't work.

Also can you please tell me how to make ath10k use minstrel rc, its needed
for comparative purposes? Is disable HW_RATE_CONTROL enough or does
it need more changes?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
 wrote:
> On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
>  wrote:
>> I think security failures are due to peer unmap & map upon reassoc. Can you 
>> please try below change?
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 5e1cc8f4c43c..f7f04bb46fc8 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct 
>> *wk)
>> sta->addr, smps, err);
>> }
>>
>> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>> -   changed & IEEE80211_RC_NSS_CHANGED) {
>> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>> +   changed & IEEE80211_RC_NSS_CHANGED) &&
>> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
>> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
>> rates/nss\n",
>>sta->addr);
>
> Bottom posting please. I have tried your change i still see the same issue.
> Right after connecting i see that packets are encrypted but once it
> unset/set "bitrates" plain packets are seen in sniffer.
>
> BTW, i am not rebooting for each driver update, just re-inserting the module,
> do i need to do a reboot for each driver change?

After reboot i dont see the "unencrypted" packet issue, i will do
some more testing on limiting the rates, currently in my setup its
not reaching MCS9 so cannot verify now.

Thanks for the fixes and prompt reply.
  
>> From: Krishna Chaitanya 
>> Sent: Friday, July 8, 2016 5:26 PM
>> To: Manoharan, Rajkumar
>> Cc: linux-wireless; ath10k
>> Subject: Re: ath10k + iw set bitrates is causing FW crash
>>
>> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>>  wrote:
> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>
> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
> no crash is observed but it still uses MCS9.
>
> tree: wireless-drivers-next: 
> commit#535633a5ba4ea2504fa6c33176633becf0e59339
>
> 1) If i disable HW_RATE_CONTROL, will ath10k honor
> the mac80211 rates?
>

>>> Thanks for reporting the issue. Could you please try with below change?
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>>> return ret;
>>> }
>>>
>>> +   if (vif->type != NL80211_IFTYPE_ADHOC)
>>> +   peer_arg.peer_reassoc = reassoc;
>>> +
>>> ret = ath10k_wmi_peer_assoc(ar, _arg);
>>> if (ret) {
>>> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
>>> %i: %d\n",
>>
>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>> seeing 0-9, so its
>> working.
>>
>> But i am seeing a weird issues, the moment i give bitrates command,
>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>> interface up/down
>> it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Improve wireless netdev detection

[Denis Kenzior]

Hi Johannes,

>> Are you okay with the general approach?


I see no issues with sending these events out. I'd like them to
actually be reliable (if present) though, not double as you'd implied -
but I didn't really understand in which cases you were expecting
issues, was it only P2P-Device?



That seems to be the only special case.  At least I didn't find any 
other situations where a NEW_INTERFACE command can be called without a 
corresponding net_device being created.



  Are there any locking issues I
might be overlooking?


Not that I'm aware of. All of the netdev/wdev handling should be
protected by RTNL.



That was my understanding as well.  Thanks.

Okay, let me spin up a v2 with patches 2+3 and 4+5 squished together. 
Or do you want one big patch?


Regards,
-Denis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Improve wireless netdev detection

[Johannes Berg]

On Fri, 2016-07-08 at 10:22 -0500, Denis Kenzior wrote:
> 
> Apologies, I've only been looking at the kernel side for several
> days, so my understanding is still incomplete.
> 
> I was looking at mac80211/iface.c: ieee80211_if_add() which seems to 
> handle NL80211_IFTYPE_P2P_DEVICE specially by not
> creating/registering a 
> net_device object.  For some reason I thought that this object was 
> registered somewhere later, but my understanding was incorrect.  So
> the  entire 'side effect' paragraph above does not apply.

Ok, makes sense.

> Are you okay with the general approach? 

I see no issues with sending these events out. I'd like them to
actually be reliable (if present) though, not double as you'd implied -
but I didn't really understand in which cases you were expecting
issues, was it only P2P-Device?

>  Are there any locking issues I 
> might be overlooking?

Not that I'm aware of. All of the netdev/wdev handling should be
protected by RTNL.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Improve wireless netdev detection

[Denis Kenzior]

Hi Johannes,

On 07/08/2016 05:32 AM, Johannes Berg wrote:

On Thu, 2016-07-07 at 02:08 -0500, Denis Kenzior wrote:

The current mechanism to detect hot-plug / unplug of wireless devices
is
somewhat arcane.  One has to listen to NEW_WIPHY/DEL_WIPHY events
over
nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
somehow find a correlation between these events.  This involves
userspace
sending GET_INTERFACE or GET_WIPHY commands to the kernel, which
incurs
additional roundtrips.

This patch series proposes that NEW_INTERFACE and DEL_INTERFACE
events are
always emitted, regardless of whether a netdev was added/removed by
the
driver or explicitly via NEW_INTERFACE/DEL_INTERFACE commands.

One side effect of this approach is that multiple
NEW_INTERFACE/DEL_INTERFACE
events might be generated for P2P interfaces.  Once when a wdev is
created
or destroyed, and once when the associated p2p netdev is connecte or
disconnected.


I think you got some things mixed up. Are you talking of P2P GO/client
interfaces, which have netdevs, but are really the same as AP/BSS
client and thus the issue here would affect the others? Or are you
talking about the P2P-Device wdev? but that has no netdev.


Apologies, I've only been looking at the kernel side for several days, 
so my understanding is still incomplete.


I was looking at mac80211/iface.c: ieee80211_if_add() which seems to 
handle NL80211_IFTYPE_P2P_DEVICE specially by not creating/registering a 
net_device object.  For some reason I thought that this object was 
registered somewhere later, but my understanding was incorrect.  So the 
entire 'side effect' paragraph above does not apply.


Are you okay with the general approach?  Are there any locking issues I 
might be overlooking?





It is likely that only the caller of P2P oriented
NEW_INTERFACE / DEL_INTERFACE commands is interested in the status of
these
operations.  E.g. the caller is / should be using SOCKET_OWNER
attribute.
Thus one possibility is to not emit NEW_INTERFACE/DEL_INTERFACE
events in
such cases.



The breaking up of patches is also confusing. You seem to be
introducing things in the first, then breaking them again, and then
fixing them?


Sorry, this was meant to be posted as an RFC.

First patch just introduces a notification utility.  The rest of the 
patches were broken up for ease of review.




Couldn't the whole thing be done in one or maybe two (new/del)
patch(es)?


Sure, I can squash them together however you like.



(You obviously also need to sign off your patches, see the kernel
Documentation/)



Apologies, still working the kinks out of my environment setup.

Regards,
-Denis

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2] bcma: define ChipCommon B MII registers

[Rafał Miłecki]

We don't have access to datasheets to document all the bits but we can
name these registers at least.

Signed-off-by: Rafał Miłecki 
---
V2: Fix mistake in V1 that used BCMA_CCB_MII_MNG_CMD_DATA instead of
BCMA_CCB_MII_MNG_CTL in the second bcma_wait_reg call.
---
 drivers/bcma/driver_chipcommon_b.c  | 9 +
 include/linux/bcma/bcma_driver_chipcommon.h | 3 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/bcma/driver_chipcommon_b.c 
b/drivers/bcma/driver_chipcommon_b.c
index c20b5f4..57f10b5 100644
--- a/drivers/bcma/driver_chipcommon_b.c
+++ b/drivers/bcma/driver_chipcommon_b.c
@@ -33,11 +33,12 @@ static bool bcma_wait_reg(struct bcma_bus *bus, void 
__iomem *addr, u32 mask,
 void bcma_chipco_b_mii_write(struct bcma_drv_cc_b *ccb, u32 offset, u32 value)
 {
struct bcma_bus *bus = ccb->core->bus;
+   void __iomem *mii = ccb->mii;
 
-   writel(offset, ccb->mii + 0x00);
-   bcma_wait_reg(bus, ccb->mii + 0x00, 0x0100, 0x, 100);
-   writel(value, ccb->mii + 0x04);
-   bcma_wait_reg(bus, ccb->mii + 0x00, 0x0100, 0x, 100);
+   writel(offset, mii + BCMA_CCB_MII_MNG_CTL);
+   bcma_wait_reg(bus, mii + BCMA_CCB_MII_MNG_CTL, 0x0100, 0x, 100);
+   writel(value, mii + BCMA_CCB_MII_MNG_CMD_DATA);
+   bcma_wait_reg(bus, mii + BCMA_CCB_MII_MNG_CTL, 0x0100, 0x, 100);
 }
 EXPORT_SYMBOL_GPL(bcma_chipco_b_mii_write);
 
diff --git a/include/linux/bcma/bcma_driver_chipcommon.h 
b/include/linux/bcma/bcma_driver_chipcommon.h
index a5ac2ca..b20e3d5 100644
--- a/include/linux/bcma/bcma_driver_chipcommon.h
+++ b/include/linux/bcma/bcma_driver_chipcommon.h
@@ -504,6 +504,9 @@
 #define BCMA_CC_PMU1_PLL0_PC2_NDIV_INT_MASK0x1ff0
 #define BCMA_CC_PMU1_PLL0_PC2_NDIV_INT_SHIFT   20
 
+#define BCMA_CCB_MII_MNG_CTL   0x
+#define BCMA_CCB_MII_MNG_CMD_DATA  0x0004
+
 /* BCM4331 ChipControl numbers. */
 #define BCMA_CHIPCTL_4331_BT_COEXIST   BIT(0)  /* 0 disable */
 #define BCMA_CHIPCTL_4331_SECI BIT(1)  /* 0 SECI is disabled 
(JATG functional) */
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Monday, June 27, 2016 3:43 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti 
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
> Changes in v4:
>   - Fixed the sparse compilation warnings:
>   * warning: cast from restricted __le32
>   * warning: cast from restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/ioctl.h   | 10 +++---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  4 files changed, 46 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> index a5a48c1..4ce9330 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> @@ -341,16 +341,16 @@ enum {
>  };
> 
>  struct mwifiex_ds_reg_rw {
> - __le32 type;
> - __le32 offset;
> - __le32 value;
> + u32 type;
> + u32 offset;
> + u32 value;
>  };
> 
>  #define MAX_EEPROM_DATA 256
> 
>  struct mwifiex_ds_read_eeprom {
> - __le16 offset;
> - __le16 byte_count;
> + u16 offset;
> + u16 byte_count;
>   u8 value[MAX_EEPROM_DATA];
>  };
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
>   pmic_reg = >params.pmic_reg;
>   pmic_reg->action = cpu_to_le16(cmd_action);
> - pmic_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - pmic_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + pmic_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + pmic_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_CAU_REG_ACCESS:
> @@ 

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] On Behalf Of Kalle Valo
> Sent: Friday, July 08, 2016 7:10 PM
> To: Amitkumar Karwar
> Cc: Prasun Maiti; Nishant Sarmukadam; Linux Wireless; Linux Next; Linux
> Kernel
> Subject: Re: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> Amitkumar Karwar  writes:
> 
> >> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> >> Sent: Monday, June 27, 2016 3:43 PM
> >> To: Amitkumar Karwar
> >> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel;
> >> Kalle Valo
> >> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> >> Commands
> >>
> >> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> >> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are
> >> saved to driver. So, "leX_to_cpu" conversion is required too many
> >> times afterwards in driver.
> >>
> >> This patch reduces the endian: conversion without saving "cpu_to_leX"
> >> converted values in driver. This will convert endianness in prepare
> >> command and command response path.
> >>
> >> Signed-off-by: Prasun Maiti 
> 
> [deleted almost 300 lines of unnecessary quotes]
> 
> > Any specific reason for dropping this patch?
> > I can see the status as "Deferred" on patchwork.
> 
> It's not dropped, "Deferred" means that the patch was postponed for some
> reason and I need to look at the patch more carefully. In this case I
> did it because I was hoping to see an Acked-by from you.

Thanks for clarification. I will ack the patch.

Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: implement NAPI support

[Kalle Valo]

Rajkumar Manoharan  wrote:
> Add NAPI support for rx and tx completion. NAPI poll is scheduled
> from interrupt handler. The design is as below
> 
>  - on interrupt
>  - schedule napi and mask interrupts
>  - on poll
>- process all pipes (no actual Tx/Rx)
>- process Rx within budget
>- if quota exceeds budget reschedule napi poll by returning budget
>- process Tx completions and update budget if necessary
>- process Tx fetch indications (pull-push)
>- push any other pending Tx (if possible)
>- before resched or napi completion replenish htt rx ring buffer
>- if work done < budget, complete napi poll and unmask interrupts
> 
> This change also get rid of two tasklets (intr_tq and txrx_compl_task).
> 
> Measured peak throughput with NAPI on IPQ4019 platform in controlled
> environment. No noticeable reduction in throughput is seen and also
> observed improvements in CPU usage. Approx. 15% CPU usage got reduced
> in UDP uplink case.
> 
> DL: AP DUT Tx
> UL: AP DUT Rx
> 
> IPQ4019 (avg. cpu usage %)
> 
> 
> TOT  +NAPI
>   ===  =
> TCP DL   644 Mbps (42%)645 Mbps (36%)
> TCP UL   673 Mbps (30%)675 Mbps (26%)
> UDP DL   682 Mbps (49%)680 Mbps (49%)
> UDP UL   720 Mbps (28%)717 Mbps (11%)
> 
> Signed-off-by: Rajkumar Manoharan 

This is quite big change and I'm planning to queue this for 4.9. So I'm not
applying this quite yet.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9199911/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath9k: Switch to using mac80211 intermediate software queues.

[Kalle Valo]

Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
> 
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
> 
> Based on Tim's original patch set, but reworked quite thoroughly.
> 
> Cc: Tim Shepard 
> Cc: Felix Fietkau 
> Signed-off-by: Toke Høiland-Jørgensen 

Nice work. Because this is such a significant change, and to maximise testing
time, I'm planning to queue this for 4.9 (so I would apply this to ath-next in
3-4 weeks after the merge window closes). But anyone who wants to test this can
use master-pending branch from my ath.git tree (uses wireless-testing as the
baseline). Sounds good?

Testing and review feedback very welcome!

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9216993/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: Fix possible wrong rx_busy time reporting in QCA4019

[Kalle Valo]

Vasanthakumar Thiagarajan  wrote:
> As hw cycle counters in QCA4019 wraparound independantly in QCA4019
> it is possible cycle counter and rx clear counter would wraparound
> at the same time. Current logic assumes only one of the counters
> would wraparound at anytime. Fix this by moving 'else' part to
> another 'if'.
> 
> Fixes: 8e100354a98 ("ath10k: fix cycle counter wraparound handling for 
> QCA4019")
> Signed-off-by: Vasanthakumar Thiagarajan 
> Reviewed-by: Julian Calaby 

Thanks, 1 patch applied to ath-next branch of ath.git:

c11e99396d0f ath10k: fix possible wrong rx_busy time reporting in QCA4019

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9209723/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wcn36xx: Silence error about unsupported smd event 188

[Kalle Valo]

Bjorn Andersson  wrote:
> Sometimes the firmware sends a HAL_DEL_BA_IND, the prima driver silently
> ignore this message so let's do the same to silence the error message.
> 
> Cc: Nicolas Dechesne 
> Signed-off-by: Bjorn Andersson 

Thanks, 1 patch applied to ath-next branch of ath.git:

7860eb7537a0 wcn36xx: Silence error about unsupported smd event 188

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9219071/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2, 1/6] ath9k: Correct TSF adjustment to align the beacon time correctly

[Kalle Valo]

Benjamin Berg  wrote:
> From: Benjamin Berg 
> 
> Beacons were not send out at (timestamp % beacon_time == 0) for interfaces
> other than the primary one. To send out beacons with the correct timestamp
> according to 10.1.3.2 of the 802.11 standard the tsf_adjustment has to be
> set to the negative time difference instead of positive. This way the
> later beacons get corrected to have a lower (and similar) timestamp with
> regard to the beacon from slot 0.
> 
> I am not aware about any issues that have been caused by this.
> 
> Signed-off-by: Benjamin Berg 

Thanks, 6 patches applied to ath-next branch of ath.git:

fa5106e1d793 ath9k: Correct TSF adjustment to align the beacon time correctly
9580cb889f35 ath9k: Handle channel context in get_/set_/reset_tsf
bec9a94bc4e2 ath9k: Use tsf offset helper in ath9k_hw_reset
7fde51227aed ath9k: Expose tsf_adjustment in mac80211 tsf getters and setters.
11b0ac2e0c1c ath9k: Remove some #defined constants to decrease verbosity
cfda2d8e2314 ath9k: Fix beacon configuration for addition/removal of interfaces

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9212535/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/6] ath9k: Allow configuration of LED polarity in platform data.

[Kalle Valo]

Martin Blumenstingl  wrote:
> Some devices running OpenWrt need this and it makes sense to add this
> to ath9k_platform_data as the next patches will add a devicetree
> (boolean) property for it as well.
> 
> Suggested-by: Vittorio Gambaletta 
> Signed-off-by: Martin Blumenstingl 

Thanks, 5 patches applied to ath-next branch of ath.git:

3467f0d43301 ath9k: Allow configuration of LED polarity in platform data.
b27301f86cc7 ath9k: remove variable which is set but never read
0cefa9749883 ath9k: ath9k_hw_init_macaddr should not overwrite valid MAC 
addresses
d323cb71abef ath9k: remove return value from ath9k_hw_init_macaddr
28755b8f6d94 ath9k: move all ath9k_platform_data initialization into one 
function

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9195397/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/6] wcn36xx: Fold indication payload into message header

[Kalle Valo]

Bjorn Andersson  wrote:
> From: Bjorn Andersson 
> 
> Merge the two allocation instead of separately allocating room for the
> indication payload.
> 
> Signed-off-by: Bjorn Andersson 
> Signed-off-by: Bjorn Andersson 

Thanks, 5 patches applied to ath-next branch of ath.git:

909aa60c0572 wcn36xx: Fold indication payload into message header
1c41fd5fb751 wcn36xx: Change indication list lock to spinlock
05ddce497c05 wcn36xx: Split mmio space into explicit regions
6f10b4e1e6ad wcn36xx: Correct DXE chip version differentiation
86ceae90d3f9 wcn36xx: Fix up wcn36xx_smd_update_scan_params()

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9186689/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3,01/10] rtlwifi: Create common routine to get hardware info

[Kalle Valo]

Larry Finger  wrote:
> All of the rtlwifi family of drivers have a similar routine that acquires
> the hardware info from efuse and initializes a number of variables in the
> driver's private area. A common routine is created for all drivers to use.
> 
> Reported-by: Arnd Bergmann 
> Signed-off-by: Larry Finger 
> Cc: Arnd Bergmann 

Thanks, 10 patches applied to wireless-drivers-next.git:

edb45b67a09d rtlwifi: Create common routine to get hardware info
df5cbc697d9b rtlwifi: rtl8192ce: Convert driver to use common hardware info 
routine
c2d9a411456c rtlwifi: rtl8192cu: Convert driver to use common hardware info 
routine
9468792743a5 rtlwifi: rtl8188ee: Convert driver to use common hardware info 
routine
5c392654ee81 rtlwifi: rtl8192ee: Convert driver to use common hardware info 
routine
8aaf6916de68 rtlwifi: rtl8723ae: Convert driver to use common hardware info 
routine
9e9c9c247c21 rtlwifi: rtl8723be: Convert driver to use common hardware info 
routine
2f7b4b895365 rtlwifi: rtl8821ae: Convert driver to use common hardware info 
routine
a8c9fb2b82ab rtlwifi: rtl8192de: Convert driver to use common hardware info 
routine
238ad2ddf34b rtlwifi: rtl8723ae: Clean up the hardware info routine

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9214551/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex: fix interrupt processing corner case in MSI mode

[Kalle Valo]

Amitkumar Karwar  wrote:
> From: Shengzhen Li 
> 
> As interrupt is read in interrupt handler as well as interrupt processing
> thread, we observed a corner case issue for MSI in which interrupt gets
> processed twice.
> 
> This patch moves interrupt reading code for MSI mode from
> mwifiex_interrupt_status() to mwifiex_pcie_process_int() to avoid the
> issue.
> 
> Signed-off-by: Shengzhen Li 
> Signed-off-by: Amitkumar Karwar 

Thanks, 1 patch applied to wireless-drivers-next.git:

5781fc29dbbd mwifiex: fix interrupt processing corner case in MSI mode

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9209885/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex: mask PCIe interrupts before removal

[Kalle Valo]

Brian Norris  wrote:
> The PCIe driver didn't mask the host interrupts before trying to tear
> down. This causes lockups at reboot or rmmod when using MSI-X on 8997,
> since the MSI handler gets confused and locks up the system.
> 
> Also tested on 8897, which does not support MSI-X (and wasn't
> experiencing this same bug). No regressions seen there.
> 
> Signed-off-by: Brian Norris 
> Tested-by: Douglas Anderson 

Thanks, 1 patch applied to wireless-drivers-next.git:

d41376ca8ba7 mwifiex: mask PCIe interrupts before removal

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9209027/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex: Change default firmware for PCIe8997 chipset

[Kalle Valo]

Amitkumar Karwar  wrote:
> PCIe-USB8997 variant is being used in the product. Let's change default
> firmware from PCIe-UART to PCIe-USB. So by default PCIe-USB firmware would
> be downloaded if version register doesn't give any information.
> 
> Signed-off-by: Amitkumar Karwar 

Thanks, 1 patch applied to wireless-drivers-next.git:

473dfbfa0993 mwifiex: Change default firmware for PCIe8997 chipset

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9208641/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Kalle Valo]

Prasun Maiti  wrote:
> The two members min_scan_time and max_scan_time of structure
> "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> are assigned directtly from firmware without endian conversion handling.
> So, wrong datas will get saved in big-endian systems.
> 
> This patch converts the values into cpu's byte order before assigning them
> into the local members.
> 
> Signed-off-by: Prasun Maiti 
> Acked-by: Amitkumar Karwar 

Thanks, 1 patch applied to wireless-drivers-next.git:

c18b104dd249 mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9206939/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/2] brcmfmac: delete interface directly in code that sent fw request

[Kalle Valo]

Rafał Miłecki wrote:
> So far when receiving event about in-firmware-interface removal our
> event worker was notifying listener and afterwards it was removing Linux
> interface.
> 
> First of all it was resulting in slightly unexpected order. The listener
> (del_virtual_intf callback) was (usually) returning with success before
> we even called unregister_netdev(ice).
> 
> Please note this couldn't be simply fixed by changing order of calls in
> brcmf_fweh_handle_if_event as unregistering interface earlier could free
> struct brcmf_if.
> 
> Another problem of current implementation are possible lockups. Focus on
> the time slot between calling event handler and removing Linux
> interface. During that time original caller may leave (unlocking rtnl
> semaphore) *and* another call to the same code may be done (locking it
> again). If that happens our event handler will stuck at removing Linux
> interface, it won't handle another event and will block process holding
> rtnl lock.
> 
> This can be simply solved by unregistering interface in a proper
> callback, right after receiving confirmation event from firmware. This
> only required modifying worker to don't unregister on its own if there
> is someone waiting for the event.
> 
> Signed-off-by: Rafał Miłecki 

Thanks, 2 patches applied to wireless-drivers-next.git:

a63b09872c1d brcmfmac: delete interface directly in code that sent fw request
dba8fbc67ecd brcmfmac: support removing AP interfaces with "interface_remove"

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9206157/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex: fix scan_block flag handling

[Kalle Valo]

Amitkumar Karwar  wrote:
> scan_block flag is used to block scan operation when 4 way handshake
> is in progress. Sometimes it doesn't get cleared due to incomplete
> association. An example is assoc request/response is done, but add key
> operation get canceled in some corner cases. As a result, further
> association/scan operations are blocked.
> 
> This patch fixes the problem by clearing scan_block flag.
> 
> Signed-off-by: Amitkumar Karwar 
> Signed-off-by: Xinming Hu 

Thanks, 1 patch applied to wireless-drivers-next.git:

b74d6e740be3 mwifiex: fix scan_block flag handling

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9205005/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-next] rtlwifi: Fix typo in printk

[Kalle Valo]

Masanari Iida  wrote:
> This patch fix spelling typos found in drivers/net/wireless/realtek.
> 
> Signed-off-by: Masanari Iida 
> Reviewed-by: Julian Calaby 

Thanks, 1 patch applied to wireless-drivers-next.git:

8a1902374fa0 rtlwifi: Fix typo in printk

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9204261/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [01/12] rtl8xxxu: Set all ieee80211_rx_status values in parse_rx_desc()

[Kalle Valo]

Jes Sorensen  wrote:
> From: Jes Sorensen 
> 
> This needs to be handled locally in the parse_rx_desc() function in
> order to be able to handle aggregated packets in the future.
> 
> Signed-off-by: Jes Sorensen 

Thanks, 12 patches applied to wireless-drivers-next.git:

c14ee43b8ae2 rtl8xxxu: Set all ieee80211_rx_status values in parse_rx_desc()
a635df8a41ac rtl8xxxu: Move skb delivery into parse_tx_desc() handler
2db125d4af4c rtl8xxxu: Obtain ieee80211_rx_status within parse_rx_desc()
41892729cf60 rtl8xxxu: Correct rxdesc16 definition
040b97be6056 rtl8xxxu: Add support for aggregated RX packets on gen1 parts
04319ae2f609 rtl8xxxu: Allocate larger RX skbs when aggregation is enabled
1e5b3b3fe9e0 rtl8xxxu: Adjust RX skb size to include space for phystats
91dcbb717531 rtl8xxxu: Enable aggregation for rtl8723au
0a20ed8bd057 rtl8xxxu: Enable aggregation for rtl8192cu/rtl8188cu/rtl8188ru
82cce22acd8e rtl8xxxu: Make DMA aggregation optional by setting a module 
parameter
614e389f36a9 rtl8xxxu: gen1: Set aggregation timeout (REG_RXDMA_AGG_PG_TH + 1) 
as well
fd83f1227826 rtl8xxxu: gen1: Add module parameters to adjust DMA aggregation 
parameters

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9200883/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Kalle Valo]

Amitkumar Karwar  writes:

>> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
>> Sent: Monday, June 27, 2016 3:43 PM
>> To: Amitkumar Karwar
>> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
>> Valo
>> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
>> Commands
>> 
>> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
>> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
>> to driver. So, "leX_to_cpu" conversion is required too many times
>> afterwards in driver.
>> 
>> This patch reduces the endian: conversion without saving "cpu_to_leX"
>> converted values in driver. This will convert endianness in prepare
>> command and command response path.
>> 
>> Signed-off-by: Prasun Maiti 

[deleted almost 300 lines of unnecessary quotes]

> Any specific reason for dropping this patch?
> I can see the status as "Deferred" on patchwork.

It's not dropped, "Deferred" means that the patch was postponed for some
reason and I need to look at the patch more carefully. In this case I
did it because I was hoping to see an Acked-by from you.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Manoharan, Rajkumar]

I think security failures are due to peer unmap & map upon reassoc. Can you 
please try below change?

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5e1cc8f4c43c..f7f04bb46fc8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct 
*wk)
sta->addr, smps, err);
}

-   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
-   changed & IEEE80211_RC_NSS_CHANGED) {
+   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
+   changed & IEEE80211_RC_NSS_CHANGED) &&
+   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
rates/nss\n",
   sta->addr);

-Rajkumar

From: Krishna Chaitanya 
Sent: Friday, July 8, 2016 5:26 PM
To: Manoharan, Rajkumar
Cc: linux-wireless; ath10k
Subject: Re: ath10k + iw set bitrates is causing FW crash

On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
 wrote:
>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>
>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>> no crash is observed but it still uses MCS9.
>>>
>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>
>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>> the mac80211 rates?
>>>
>>
> Thanks for reporting the issue. Could you please try with below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..cfa7e01a6103 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> return ret;
> }
>
> +   if (vif->type != NL80211_IFTYPE_ADHOC)
> +   peer_arg.peer_reassoc = reassoc;
> +
> ret = ath10k_wmi_peer_assoc(ar, _arg);
> if (ret) {
> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
> %i: %d\n",

Thanks Raj, with this fix the rates are 0-7, if i disable then i am
seeing 0-9, so its
working.

But i am seeing a weird issues, the moment i give bitrates command,
ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
interface up/down
it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
 wrote:
>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>
>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>> no crash is observed but it still uses MCS9.
>>>
>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>
>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>> the mac80211 rates?
>>>
>>
> Thanks for reporting the issue. Could you please try with below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..cfa7e01a6103 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> return ret;
> }
>
> +   if (vif->type != NL80211_IFTYPE_ADHOC)
> +   peer_arg.peer_reassoc = reassoc;
> +
> ret = ath10k_wmi_peer_assoc(ar, _arg);
> if (ret) {
> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
> %i: %d\n",

Thanks Raj, with this fix the rates are 0-7, if i disable then i am
seeing 0-9, so its
working.

But i am seeing a weird issues, the moment i give bitrates command,
ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
interface up/down
it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

Hi Kalle,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Monday, June 27, 2016 3:43 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti 
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
> Changes in v4:
>   - Fixed the sparse compilation warnings:
>   * warning: cast from restricted __le32
>   * warning: cast from restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/ioctl.h   | 10 +++---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  4 files changed, 46 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> index a5a48c1..4ce9330 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> @@ -341,16 +341,16 @@ enum {
>  };
> 
>  struct mwifiex_ds_reg_rw {
> - __le32 type;
> - __le32 offset;
> - __le32 value;
> + u32 type;
> + u32 offset;
> + u32 value;
>  };
> 
>  #define MAX_EEPROM_DATA 256
> 
>  struct mwifiex_ds_read_eeprom {
> - __le16 offset;
> - __le16 byte_count;
> + u16 offset;
> + u16 byte_count;
>   u8 value[MAX_EEPROM_DATA];
>  };
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
>   pmic_reg = >params.pmic_reg;
>   pmic_reg->action = cpu_to_le16(cmd_action);
> - pmic_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - pmic_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + pmic_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + pmic_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case 

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

Hi Michal / Kalle / Ben,

is this patch is good to go (or) should i re-work  ?
I had replied to Michal's comment of introducing a new firmware
feature flag will not address the issue in older firmware / code.
Let me know if i had missed something very obvious.


On Tue, Jul 05, 2016 at 08:21:01AM -0700, Ben Greear wrote:
> On 06/30/2016 03:25 AM, Valo, Kalle wrote:
> >Ben Greear  writes:
> >
> >>Is there a better way than posting to the ath10k mailing list?  There are 
> >>quite
> >>a few more of my patches that are stuck in pending or ignored state.  If you
> >>could review some of them and add them to your testing trees then it might 
> >>help
> >>them go upstream.
> >
> >Yes, as you seem to test with your custom ath10k and custom firmware
> >review and testing feedback from others is more than welcome. That way I
> >can have more confidence that the patch really works with the mainline
> >version.
> >
> >The problem with your patches is that you dump more responsibility on
> >me. I have no idea if they work with the mainline kernel, or if they
> >break something, so I need to personally test the patch and that takes
> >time. Basically I have a rule if that I need to use more than two
> >minutes on a patch it goes to the Deferred queue and I'll go through
> >that less often than the normal patch queue.
> 
> I can do some testing with stock firmware, but stock firmware is often quite 
> limited
> so I cannot do the more interesting test cases that we use internally.
> Some of my patches are for fixing edge cases that cannot be easily reproduced,
> and that code really needs to be reviewed for correctness more by looking at
> the code than by trying to run some exhaustive test case.
> 
> I think if there were a specific maintainer for ath10k that could take a more
> active role, especially with regard to keeping a fairly wide variety of test 
> rigs
> around to run regression tests, then it would help all involved.  I think 
> this person
> needs access to firmware source so that they can more easily verify the driver
> matches the firmware:  Many of the regressions and bug fixes, for instance 
> with
> stats, would be much easier to clean up if you look at firmware while 
> developing
> the driver bits.
>

regards,
shafi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: Allow different beacon interval support on virtual interface.

[Johannes Berg]

On Fri, 2016-07-08 at 16:02 +0530, Purushottam Kushwaha wrote:
> Driver may support different beacon interval on virtual interfaces.
> Allow setting different beacon interval per interface if driver has
> such support.
> 
It seems this should be an nl80211 feature flag (ext features)

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: Add support for user configurable beacon data rate

[Johannes Berg]

On Fri, 2016-07-08 at 15:58 +0530, Purushottam Kushwaha wrote:
> 
>   *
> + * @NL80211_ATTR_BEACON_TXRATE: User configurable beacon data rate
> (u32). This is
> + *   used to set beacon tx rate.
> 
It seems this should be nested from enum nl80211_tx_rate_attributes, to
perhaps allow HT/VHT beacons in the future.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cfg80211: Allow different beacon interval support on virtual interface.

[Purushottam Kushwaha]

Driver may support different beacon interval on virtual interfaces.
Allow setting different beacon interval per interface if driver has
such support.

Signed-off-by: Purushottam Kushwaha 
---
 include/net/cfg80211.h | 5 +
 net/wireless/util.c| 3 +++
 2 files changed, 8 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9c23f4d3..2dd9152 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3292,6 +3292,9 @@ struct wiphy_iftype_ext_capab {
  * @bss_select_support: bitmask indicating the BSS selection criteria supported
  * by the driver in the .connect() callback. The bit position maps to the
  * attribute indices defined in  nl80211_bss_select_attr.
+ * @support_different_beacon_interval: support of different beacon_interval on
+ * virtual interfaces. This should be set if driver wishes to advertise
+ * support for different beacon_interval.
  */
 struct wiphy {
/* assign these fields before you register the wiphy */
@@ -3421,6 +3424,8 @@ struct wiphy {
 
u32 bss_select_support;
 
+   bool support_different_beacon_interval;
+
char priv[0] __aligned(NETDEV_ALIGN);
 };
 
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 2443ee3..253d303 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1560,6 +1560,9 @@ int cfg80211_validate_beacon_int(struct 
cfg80211_registered_device *rdev,
if (!beacon_int)
return -EINVAL;
 
+   if (rdev->wiphy.support_different_beacon_interval)
+   return 0;
+
list_for_each_entry(wdev, >wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Improve wireless netdev detection

[Johannes Berg]

On Thu, 2016-07-07 at 02:08 -0500, Denis Kenzior wrote:
> The current mechanism to detect hot-plug / unplug of wireless devices
> is
> somewhat arcane.  One has to listen to NEW_WIPHY/DEL_WIPHY events
> over
> nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
> somehow find a correlation between these events.  This involves
> userspace
> sending GET_INTERFACE or GET_WIPHY commands to the kernel, which
> incurs
> additional roundtrips.
> 
> This patch series proposes that NEW_INTERFACE and DEL_INTERFACE
> events are
> always emitted, regardless of whether a netdev was added/removed by
> the
> driver or explicitly via NEW_INTERFACE/DEL_INTERFACE commands.
> 
> One side effect of this approach is that multiple
> NEW_INTERFACE/DEL_INTERFACE
> events might be generated for P2P interfaces.  Once when a wdev is
> created
> or destroyed, and once when the associated p2p netdev is connecte or 
> disconnected.  

I think you got some things mixed up. Are you talking of P2P GO/client
interfaces, which have netdevs, but are really the same as AP/BSS
client and thus the issue here would affect the others? Or are you
talking about the P2P-Device wdev? but that has no netdev.

> It is likely that only the caller of P2P oriented
> NEW_INTERFACE / DEL_INTERFACE commands is interested in the status of
> these
> operations.  E.g. the caller is / should be using SOCKET_OWNER
> attribute.
> Thus one possibility is to not emit NEW_INTERFACE/DEL_INTERFACE
> events in
> such cases.
> 

The breaking up of patches is also confusing. You seem to be
introducing things in the first, then breaking them again, and then
fixing them?

Couldn't the whole thing be done in one or maybe two (new/del)
patch(es)?

(You obviously also need to sign off your patches, see the kernel
Documentation/)

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cfg80211: Add support for user configurable beacon data rate

[Purushottam Kushwaha]

This will allow user to configure beacon tx rate from userspace. This adds
new nl80211 attribute as NL80211_ATTR_BEACON_RATE.

Signed-off-by: Purushottam Kushwaha 
---
 include/net/cfg80211.h   | 3 ++-
 include/uapi/linux/nl80211.h | 5 +
 net/wireless/nl80211.c   | 5 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9c23f4d3..ad0200b 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -685,6 +685,7 @@ struct cfg80211_acl_data {
  * @beacon: beacon data
  * @beacon_interval: beacon interval
  * @dtim_period: DTIM period
+ * @beacon_txrate: beacon tx rate
  * @ssid: SSID to be used in the BSS (note: may be %NULL if not provided from
  * user space)
  * @ssid_len: length of @ssid
@@ -706,7 +707,7 @@ struct cfg80211_ap_settings {
 
struct cfg80211_beacon_data beacon;
 
-   int beacon_interval, dtim_period;
+   int beacon_interval, dtim_period, beacon_txrate;
const u8 *ssid;
size_t ssid_len;
enum nl80211_hidden_ssid hidden_ssid;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 2206941..f338909 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1867,6 +1867,9 @@ enum nl80211_commands {
  * @NL80211_ATTR_MESH_PEER_AID: Association ID for the mesh peer (u16). This is
  * used to pull the stored data for mesh peer in power save state.
  *
+ * @NL80211_ATTR_BEACON_TXRATE: User configurable beacon data rate (u32). This 
is
+ * used to set beacon tx rate.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2261,6 +2264,8 @@ enum nl80211_attrs {
 
NL80211_ATTR_MESH_PEER_AID,
 
+   NL80211_ATTR_BEACON_TXRATE,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 5782f71..020b753 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -409,6 +409,7 @@ static const struct nla_policy 
nl80211_policy[NUM_NL80211_ATTR] = {
.len = VHT_MUMIMO_GROUPS_DATA_LEN
},
[NL80211_ATTR_MU_MIMO_FOLLOW_MAC_ADDR] = { .len = ETH_ALEN },
+   [NL80211_ATTR_BEACON_TXRATE] = { .type = NLA_U32 },
 };
 
 /* policy for the key attributes */
@@ -3568,6 +3569,10 @@ static int nl80211_start_ap(struct sk_buff *skb, struct 
genl_info *info)
params.smps_mode = NL80211_SMPS_OFF;
}
 
+   if (info->attrs[NL80211_ATTR_BEACON_TXRATE])
+   params.beacon_txrate =
+   nla_get_u32(info->attrs[NL80211_ATTR_BEACON_TXRATE]);
+
if (info->attrs[NL80211_ATTR_ACL_POLICY]) {
params.acl = parse_acl_data(>wiphy, info);
if (IS_ERR(params.acl))
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Manoharan, Rajkumar]

>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>
>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>> no crash is observed but it still uses MCS9.
>>
>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>
>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>> the mac80211 rates?
>>
>
Thanks for reporting the issue. Could you please try with below change?

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5e1cc8f4c43c..cfa7e01a6103 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
return ret;
}

+   if (vif->type != NL80211_IFTYPE_ADHOC)
+   peer_arg.peer_reassoc = reassoc;
+
ret = ath10k_wmi_peer_assoc(ar, _arg);
if (ret) {
ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: 
%d\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] wlcore: time sync : add support for 64 bit clock

[Kalle Valo]

"Machani, Yaniv"  wrote:
> Changed the configuration to support 64bit instead of 32bit
> this in order to offload the driver from handling a wraparound.
> 
> Signed-off-by: Yaniv Machani 

Thanks, 1 patch applied to wireless-drivers-next.git:

585dfe813fa5 wlcore: time sync : add support for 64 bit clock

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9200631/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/3] mwifiex: code rearrangement in suspend handler

[Kalle Valo]

Amitkumar Karwar  wrote:
> We will derive sta_priv at the beginning of suspend handler.
> This will be useful for next patch in this series.
> 
> Signed-off-by: Amitkumar Karwar 

Thanks, 3 patches applied to wireless-drivers-next.git:

322397b268f7 mwifiex: code rearrangement in suspend handler
09e672a16b92 mwifiex: clear scan_aborting flag
16d25da94f3d mwifiex: fix NULL pointer dereference during suspend

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9200033/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] wlcore: spi: add wl18xx support

[Kalle Valo]

"Reizer, Eyal"  writes:

> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
>   extra clock cycles should be sent after the spi init command while the
>   cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
>   completes the init stage.
>
> Signed-off-by: Eyal Reizer 
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select instead
> for sending the extra init cycle which, achieves the same hardware purpose.
> update device tree bindings docucmentation accordingly
> v3->v4: Remove redundant data form binding documentation and fix chip select
> number mismatch in wl1271 example

Doesn't apply to wireless-drivers-next, please resend.

Applying: wlcore: spi: add wl18xx support
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/ti/wlcore/spi.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ti/wlcore/spi.c
Failed to merge in the changes.
Patch failed at 0001 wlcore: spi: add wl18xx support

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size

[Kalle Valo]

Joe Perches  wrote:
> This debugging macro can expand to a lot of code.
> Make it a function to reduce code size.
> 
> (x86-64 defconfig w/ all rtlwifi drivers and allyesconfig)
> $ size drivers/net/wireless/realtek/rtlwifi/built-in.o*
>text  data bss dec hex filename
>  9000832004991907 1102489  10d299 
> drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.new
> 11135972004991907 1316003  1414a3 
> drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.old
> 17468794535038512 2208894  21b47e 
> drivers/net/wireless/realtek/rtlwifi/built-in.o.new
> 20519655033118512 2563788  271ecc 
> drivers/net/wireless/realtek/rtlwifi/built-in.o.old
> 
> Signed-off-by: Joe Perches 
> Acked-by: Larry Finger 

Thanks, 1 patch applied to wireless-drivers-next.git:

9ce221915a94 rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code 
size

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9198897/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/4] rtl8xxxu: remove unneeded assignments

[Kalle Valo]

Jes Sorensen  wrote:
> From: Luis de Bethencourt 
> 
> reg_eac and reg_ecc are only used if candidate is bigger than 0, and in
> that case new values will be given to them. Removing the unused
> assignments.
> 
> Signed-off-by: Luis de Bethencourt 
> Signed-off-by: Jes Sorensen 

Thanks, 2 patches applied to wireless-drivers-next.git:

efcb32883f36 rtl8xxxu: remove unneeded assignments
78383ac95181 rtl8xxxu: Reduce console noise when removing the kernel module

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9195753/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] bcma: define ChipCommon B MII registers

[Rafał Miłecki]

We don't have access to datasheets to document all the bits but we can
name these registers at least.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/driver_chipcommon_b.c  | 10 ++
 include/linux/bcma/bcma_driver_chipcommon.h |  3 +++
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/bcma/driver_chipcommon_b.c 
b/drivers/bcma/driver_chipcommon_b.c
index c20b5f4..52c3d36 100644
--- a/drivers/bcma/driver_chipcommon_b.c
+++ b/drivers/bcma/driver_chipcommon_b.c
@@ -33,11 +33,13 @@ static bool bcma_wait_reg(struct bcma_bus *bus, void 
__iomem *addr, u32 mask,
 void bcma_chipco_b_mii_write(struct bcma_drv_cc_b *ccb, u32 offset, u32 value)
 {
struct bcma_bus *bus = ccb->core->bus;
+   void __iomem *mii = ccb->mii;
 
-   writel(offset, ccb->mii + 0x00);
-   bcma_wait_reg(bus, ccb->mii + 0x00, 0x0100, 0x, 100);
-   writel(value, ccb->mii + 0x04);
-   bcma_wait_reg(bus, ccb->mii + 0x00, 0x0100, 0x, 100);
+   writel(offset, mii + BCMA_CCB_MII_MNG_CTL);
+   bcma_wait_reg(bus, mii + BCMA_CCB_MII_MNG_CTL, 0x0100, 0x, 100);
+   writel(value, mii + BCMA_CCB_MII_MNG_CMD_DATA);
+   bcma_wait_reg(bus, mii + BCMA_CCB_MII_MNG_CMD_DATA, 0x0100, 0x,
+ 100);
 }
 EXPORT_SYMBOL_GPL(bcma_chipco_b_mii_write);
 
diff --git a/include/linux/bcma/bcma_driver_chipcommon.h 
b/include/linux/bcma/bcma_driver_chipcommon.h
index a5ac2ca..b20e3d5 100644
--- a/include/linux/bcma/bcma_driver_chipcommon.h
+++ b/include/linux/bcma/bcma_driver_chipcommon.h
@@ -504,6 +504,9 @@
 #define BCMA_CC_PMU1_PLL0_PC2_NDIV_INT_MASK0x1ff0
 #define BCMA_CC_PMU1_PLL0_PC2_NDIV_INT_SHIFT   20
 
+#define BCMA_CCB_MII_MNG_CTL   0x
+#define BCMA_CCB_MII_MNG_CMD_DATA  0x0004
+
 /* BCM4331 ChipControl numbers. */
 #define BCMA_CHIPCTL_4331_BT_COEXIST   BIT(0)  /* 0 disable */
 #define BCMA_CHIPCTL_4331_SECI BIT(1)  /* 0 SECI is disabled 
(JATG functional) */
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC

[Amitkumar Karwar]

> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] On Behalf Of Nestor Machno
> Sent: Thursday, July 07, 2016 6:07 AM
> To: linux-wireless@vger.kernel.org
> Subject: Fwd: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
> 
> Hi All,
> Amitkumar, can you confirm if this this is a bug or today is fixed?

Yes. This is a bug in our firmware. ADHOC in WPA/WPA2 security is broken. We 
have asked firmware experts to look into this. As we have a mid-year shutdown 
this week, they will be able to check the problem next week only. However ADHOC 
in open mode should work as expected

> 
> Vincent, I had also faced similar issue on Surface Pro 2 with backports
> from 4.1... So here few question:
> 
> * I saw in 1st post that you where working to make work the
> wpa_supplicant with mixed configuration for adhoc (wpa-none + wpa-ibss),
> but also in recent post that you focus mostly on debugging wpa-ibss. I
> suggest to focus your test on one wpa mode and I think wpa-none better
> because it's easier..
> * Why you are not testing the latest backport from upstream kernel? as
> you can know Marvell is focus most to fix open issue on current stable
> release, I saw from commit that recently they fix something about WPA on
> mixflex, see
> https://backports.wiki.kernel.org/index.php/Documentation/compat-
> drivers/hacking
> * Would be good information to know if you tested also on backport 3.x,
> did you?  I know mwifiex's WPA stack changed a lot from 3.x kernel.
> * To support you more, could you enable debug info and provide full log
> of your setup? .config? patch? anything else?
> * Can you share us your hacked backport?
> * Lat question Vincent, are you working for AIRBUS, ACTIA or THALES ?
> :)
> 
> Best Regards
> Nestor
> 
> On Mon, Jun 13, 2016 at 7:42 AM, Vincent CESSON
>  wrote:
> > Hi Amitkumar,
> >
> > Here are the wpa_supplicant logs (with CONFIG_IBSS_RSN=y enabled) from
> > the two devices. Beside wpa_supplicant, I manually set IPs
> > 192.168.1.xy with command "ifconfig mlan0 192.168.1.xy" and then I try
> > to ping each other, without success.
> >

Regards,
Amitkumar

Re: [PATCHv3 3/3] ath10k: add testmode support for 10.4 firmware

[Valo, Kalle]

 writes:

> From: Tamizh chelvam 
>
> This patch adds testmode support for 10.4 based chipsets
> and added code swap support for UTF binary.
>
> Signed-off-by: Tamizh chelvam 

This patch introduced new checkpatch warnings:

drivers/net/wireless/ath/ath10k/testmode.c:247: Alignment should match open 
parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:250: Alignment should match open 
parenthesis

I fixed these in the pending branch.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] ath9k: consider return code on ar9300_eeprom_restore_flash

[Kalle Valo]

Eduardo Abinader  writes:

> just to comply with current ath9k_hw_nvram_read to return value, hence
> behaving reacting accordingly.
>
> Signed-off-by: Eduardo Abinader 
> ---
>  drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Please always provide a changelog after the "---" line or in the cover
letter.

> diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c 
> b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
> index 5bd2cba..b7dc08e 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
> +++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
> @@ -3252,7 +3252,8 @@ static int ar9300_eeprom_restore_flash(struct ath_hw 
> *ah, u8 *mptr,
>   int i;
>  
>   for (i = 0; i < mdata_size / 2; i++, data++)
> - ath9k_hw_nvram_read(ah, i, data);
> + if (!ath9k_hw_nvram_read(ah, i, data))
> + return -1;

Please use proper error codes, like -EIO or some other.

>   return 0;
>  }
> @@ -3282,7 +3283,8 @@ static int ar9300_eeprom_restore_internal(struct ath_hw 
> *ah,
>   if (ath9k_hw_use_flash(ah)) {
>   u8 txrx;
>  
> - ar9300_eeprom_restore_flash(ah, mptr, mdata_size);
> + if (ar9300_eeprom_restore_flash(ah, mptr, mdata_size))
> + return -1;

And here you can just return the error code:

ret = ar9300_eeprom_restore_flash(ah, mptr, mdata_size);
if (ret)
return ret;

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/2] ath10k: Replace warning with an error message if HTT op version is unset

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Print an ath10k error message rather a call trace when HTT op version is
> not found from firmware META data (IE). This should be sufficient to figure
> out what went wrong.
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 1 patch applied to ath-next branch of ath.git:

ce30c4fe1a22 ath10k: replace warning with an error message if HTT op version is 
unset

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9195581/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/2] ath10k: remove unused member in ath10k_hw_regs

[Kalle Valo]

ako...@qti.qualcomm.com wrote:
> From: Anilkumar Kolli 
> 
> rtc_state_cold_reset_mask is unused in ath10k_hw_regs.
> instead fixed delays are used.
> 
> Signed-off-by: Anilkumar Kolli 

Thanks, 2 patches applied to ath-next branch of ath.git:

2225378d840c ath10k: remove unused member in ath10k_hw_regs
e565c3125e03 ath10k: enable support for QCA9888

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9189535/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2,3/5] ath10k: Add WARN_ON if we over-write peer-map pointer.

[Kalle Valo]

Ben Greear  wrote:
> From: Ben Greear 
> 
> Not sure this can happen, but seems like a reasonable sanity
> check.
> 
> Signed-off-by: Ben Greear 

Thanks, 2 patches applied to ath-next branch of ath.git:

c5ace87a886d ath10k: Add WARN_ON if we over-write peer-map pointer.
d0eeafad1189 ath10k: Clean up peer when sta goes away.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8727861/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: remove extra space on ath10k_update_channel_list

[Kalle Valo]

Eduardo Abinader  wrote:
> just to comply to coding style.
> 
> Signed-off-by: Eduardo Abinader 
> Reviewed-by: Julian Calaby 

Thanks, 1 patch applied to ath-next branch of ath.git:

9802977dcce5 ath10k: remove extra space on ath10k_update_channel_list

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9192945/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: simplify pktlog htt event processing

[Kalle Valo]

Ashok Raj Nagarajan  wrote:
> It is expected that all pktlog events for 10.4 firmware based solutions
> should come through CE8 where as in case of 10.2 firmware based solutions,
> it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG).
> 
> But from experiments with 10.4 based solutions, it is observed that pktlog
> event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event.
> Currently, we always parse with 10.2 pktlog header which will lead to
> pktlog decoding issues (payload length mismatch exceptions)
> 
> For trace points, it is required to provide only the payload size. So
> fixing this by simplifying the payload size calculation without the use of
> ath10k pktlog headers.
> 
> While there, remove the unused ath10k pktlog headers.
> 
> Signed-off-by: Ashok Raj Nagarajan 

Thanks, 1 patch applied to ath-next branch of ath.git:

34293f75586b ath10k: simplify pktlog htt event processing

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9192399/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/2] ath10k: remove unused

[Kalle Valo]

Chaehyun Lim  wrote:
>  is not used anymore, so just remove it.
> 
> Signed-off-by: Chaehyun Lim 

Thanks, 1 patch applied to ath-next branch of ath.git:

a3dadad73324 ath10k: remove unused 

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9190357/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2, 1/5] ath10k: Ensure txrx-compl-task is stopped when cleaning htt-tx.

[Kalle Valo]

Ben Greear  wrote:
> From: Ben Greear 
> 
> Otherwise, the txrx-compl-task may access some bad memory?
> 
> Signed-off-by: Ben Greear 

Thanks, 2 patches applied to ath-next branch of ath.git:

de0170beaa88 ath10k: ensure txrx-compl-task is stopped when cleaning htt-tx
6d68f7900d25 ath10k: ensure peer_map references are cleaned up

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8727831/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v4,1/2] ath10k: Add support for ath10k_sta_statistics support

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Enable support for 'drv_sta_statistics' callback.
> Export rx_duration support if available to cfg80211/nl80211
> 
> This can also act as a placeholder for any new per STA stats support
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 2 patches applied to ath-next branch of ath.git:

120a1f02a5c4 ath10k: add support for ath10k_sta_statistics support
2ba1f3709452 ath10k: remove debugfs support for Per STA total rx duration

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9175135/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] ath10k: Fix 10.4 extended peer stats update

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> 10.4 'extended peer stats' will be not be appended with normal peer stats
> data and they shall be coming in separate chunks. Fix this by maintaining
> a separate linked list 'extender peer stats' for 10.4 and update
> rx_duration for per station statistics. Also parse through beacon filter
> (if enabled), to make sure we parse the extended peer stats properly.
> This issue was exposed when more than one client is connected and
> extended peer stats for 10.4 is enabled
> 
> The order for the stats is as below
> S - standard peer stats, E- extended peer stats, B - beacon filter stats
> 
> {S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
> 
> Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 
> 10.4")
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 1 patch applied to ath-next branch of ath.git:

4a49ae94a448 ath10k: fix 10.4 extended peer stats update

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9149357/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html