Re: [patch] iwlwifi: mvm: silence unintialized variable warning
On Wed, 2016-05-04 at 09:19 +0300, Dan Carpenter wrote: > "max_amsdu_len" isn't set if kstrtouint() fails. > > Signed-off-by: Dan Carpenter I'm also pushing this one via our internal tree. Thanks! -- Luca.
[PATCH] ath10k: improve tx scheduling
Recent changes revolving around implementing
wake_tx_queue support introduced a significant
performance regressions on some (slower, uni-proc)
systems.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 3 ---
drivers/net/wireless/ath/ath10k/mac.c| 7 ---
drivers/net/wireless/ath/ath10k/txrx.c | 3 +++
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index cc979a4faeb0..7411b69fde42 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2291,7 +2291,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct
sk_buff *skb)
ath10k_htt_tx_mgmt_dec_pending(htt);
spin_unlock_bh(&htt->tx_lock);
}
- ath10k_mac_tx_push_pending(ar);
break;
}
case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
@@ -2442,8 +2441,6 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
dev_kfree_skb_any(skb);
}
- ath10k_mac_tx_push_pending(ar);
-
num_mpdus = atomic_read(&htt->num_mpdus_ready);
while (num_mpdus) {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 6dd1d26b357f..1dd415d3c0ee 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3781,6 +3781,9 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
int ret;
int max;
+ if (ar->htt.num_pending_tx >= (ar->htt.max_num_pending_tx / 2))
+ return;
+
spin_lock_bh(&ar->txqs_lock);
rcu_read_lock();
@@ -4051,9 +4054,7 @@ static void ath10k_mac_op_wake_tx_queue(struct
ieee80211_hw *hw,
list_add_tail(&artxq->list, &ar->txqs);
spin_unlock_bh(&ar->txqs_lock);
- if (ath10k_mac_tx_can_push(hw, txq))
- tasklet_schedule(&ar->htt.txrx_compl_task);
-
+ ath10k_mac_tx_push_pending(ar);
ath10k_htt_tx_txq_update(hw, txq);
}
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c
b/drivers/net/wireless/ath/ath10k/txrx.c
index 576e7c42ed65..1966c787998b 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -117,6 +117,9 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
ieee80211_tx_status(htt->ar->hw, msdu);
/* we do not own the msdu anymore */
+
+ ath10k_mac_tx_push_pending(ar);
+
return 0;
}
--
2.1.4
--
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: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac
On 7-5-2016 21:24, Barry Reinhold wrote: > I have observed erratic behavior with http connectivity over the WiFi > interface of the Raspberry PI 3. This appears to be consistent with issues > that a number of other people have reported. I fear, but can not provide > definitive evidence, that these failures could be an RF design/layout issue > with the RP-3 itself. > > The purpose of this post is to see if this possible issue can be confirmed by > others, and to seek a possible work around by re configuring the BCM43438 > chip via the brcmfmac driver; or the other associated wifi modules. > > How the issue is being seen: > > Note: The testing I have done is limited and has the potential to be > misleading, so any input on improving the test process would be appreciated. > > There are two metrics we are using to define/see failure: (1) Loss/delay in > ICMP Echo requests/replys (pings), and (2) The output of messages in > journalctl from the wpa_supplicant or hostapd (sudo journalctl -u > wpa_supplicant -u hostapd -f) indicating a disconnect event with associated > reason - typically 0 - (wlan0: CTRL-EVENT-DISCONNECTED > bssid=60:02:92:cd:c9:30 reason=0). > Ping times vary from 1 to several hundred ms, to outright loss. > There are also failures to reassociate (wlan0: CTRL-EVENT-ASSOC-REJECT > status_code=16). > > The test Environment is composed of: > An official Raspberry PI-3 model B with an official Raspberry PI-3 power > supply. > Raspbian release: Jesse (March 18) > Kernel 4.4.6 > wpa_supplicant 2.3 > brcmfmac 7.45.41.23 (as reported by ethool) > BCM43438 firmware: 01-cc44eda9c > BlueZ 5.23 > > We are running both wpa_supplicant and hostapd, (disabling hostapd does not > impact the results of the tests). > We have an application that is monitoring for BTLE/Bluetooth connections so > it is scanning on a regular basis, as well as sending out Bluetooth INQUIRE > messages. > > WiFi Access Points: > 1. Cisco DPC3939B (supports n) > 2. Cisco Linksys E1200 (supports n) > 3. Netgear WNDR3400 (supports n) > 4. Linksys WAP54G v3 (does not support n) > > > > Test Process > > > While the application is running (thus generating Bluetooth activity) > 1. Connect a PC to the RPi3's software access point and ping the RPi3 > continuously. > 2. Connect the RPi3 to an AP from the set above. > 3. Let the system run for 10 minutes while counting wpa_supplicant > disconnects and lost pings. > > Observations: > In our testing we noticed that either we essentially got no errors, or we got > 12+ errors. Some error rates high enough that we couldn't count them as they > just scrolled off our screen. Hence we considered thing to work (less then 2 > errors) or failed (greater than 10 errors). > > The results table for the different APs is as follows: > DPC3939B - Failed > E1200 - Failed > WNDR3400 - Failed > WAP54G - Passed > > Since only the WAP54G passed (no n support), we modified the data rate on the > Netgear WND3400 and limited its data rate to 54 mbs, at this point the > WNDR3400 passed. > > We then tried changing channels. this did not impact the metrics we were > monitoring. > > Now being suspicious of RF issues on the board, we modified our application > which performs the Bluetooth communications so that Bluetooth was disabled. > This did not eliminate errors but dramatically reduced them. We then modified > our application to generate a lot of Bluetooth inquiry messages and > discovered that the generation and resulting response from INQUIRY messages > correlated with journalctl disconnection messages. > > We repeated this on the AP WAP54G and the rate limited WNDR3400 and did not > see problems. > > Our initial conjecture is that there is some coexistence/RF issue with the > RPI-3 board when using Bluetooth and WiFi that is impacting when operating > with a IEEE 802.11 N AP. > > Notes and steps taken: > Background reading led us to try the following fixes that have worked for > others: > 1. Disable power management > 2. Set the Country Code to US > These fixes did not help. > > I have two questions: > 1. Are there some obvious things I can do to identify/validate the initial > conjecture as to the cause of the error? > 2. Is there a way to force the RPI-3 when operating as a client of another AP > to rate limit or function as a "G" device? If the RPI-3 or the BCM43438 do > indeed have RF issues it would seem like some work around will be needed. I > could not identify a way to limit the data rate in brcmfmac. Hi Barry, What you are trying to do is simply not possible. Indeed the RF is such that Wifi and BT share the same antenna, which is the root-cause of the problems you see. When the antenna is used by BT the Wifi is unavailable. This is handled by bt-coex, but that is designed specifically for station mode. This is simply not possible when the Wifi is operating in AP mode, because of The reason why things get better/working when using g-rates i
Re: [PATCHv4 1/5] mac80211: skip netdev queue control with software queuing
On 5 May 2016 at 13:00, Michal Kazior wrote:
[...]
> -static void ieee80211_drv_tx(struct ieee80211_local *local,
> -struct ieee80211_vif *vif,
> -struct ieee80211_sta *pubsta,
> -struct sk_buff *skb)
> +static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
> + struct ieee80211_vif *vif,
> + struct ieee80211_sta *pubsta,
> + struct sk_buff *skb)
> {
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
> - struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> - struct ieee80211_tx_control control = {
> - .sta = pubsta,
> - };
> - struct ieee80211_txq *txq = NULL;
> - struct txq_info *txqi;
> - u8 ac;
>
> if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ||
> (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
> - goto tx_normal;
> + return NULL;
>
> if (!ieee80211_is_data(hdr->frame_control))
> - goto tx_normal;
> + return NULL;
>
> if (pubsta) {
> u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
>
> - txq = pubsta->txq[tid];
> + return to_txq_info(pubsta->txq[tid]);
> } else if (vif) {
> - txq = vif->txq;
> + return to_txq_info(vif->txq);
> }
I just noticed this crashes on non-wake_tx_queue drivers. I'll re-spin
a v5 with this fixed later.
Michał
--
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] ath9k: allow tx99 for ar9002 based cards
As there is current support for ar9002 tx99 mode, just allow
to init debugfs and enable tx99.
Signed-off-by: Eduardo Abinader
---
drivers/net/wireless/ath/ath9k/tx99.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/tx99.c
b/drivers/net/wireless/ath/ath9k/tx99.c
index ac4781f..6161536 100644
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -266,7 +266,7 @@ static const struct file_operations fops_tx99_power = {
void ath9k_tx99_init_debug(struct ath_softc *sc)
{
- if (!AR_SREV_9300_20_OR_LATER(sc->sc_ah))
+ if (!AR_SREV_9280_20_OR_LATER(sc->sc_ah))
return;
debugfs_create_file("tx99", S_IRUSR | S_IWUSR,
--
2.5.0
--
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] Fix regression in Android due to rework .get_station() callback
Jaap Jan Meijer writes: > 2016-05-06 17:02 GMT+01:00 Kalle Valo : >> Jaap Jan Meijer writes: >> >>> 2016-05-06 16:12 GMT+01:00 Kalle Valo : Jaap Jan Meijer writes: > I'm not sure what went wrong with the commit hash, its actually this > commit: > 1f0dc59a6de93586fcfc04696a61946408ffc56a. That commit id looks to be valid. > I see you did this commit, maybe you can check if this actually is the > root > cause? I'm sure you have a lot more insight into this issue than I do. >> >> I just commited the patch. Broadcom folks (CCed) should be able to >> answer better, most likely they missed this patch as the title didn't >> have "brcmfmac". > > Thanks, so no need to send a revised patch? Also, could you please > point me to the right repository so I can follow the progress? Sorry, I had very bad choise of words. I meant that I only commit patches (like the commit 1f0dc59a6d we are discussing here), I'm not familiar with brcmfmac internals. So I have NOT applied this patch and you need to send v2. I see that Arend also found some issues, please follow his advice. > Also, could you please point me to the right repository so I can > follow the progress? You can check that from MAINTAINERS file: NETWORKING DRIVERS (WIRELESS) M: Kalle Valo L: linux-wireless@vger.kernel.org Q: http://patchwork.kernel.org/project/linux-wireless/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git S: Maintained F: drivers/net/wireless/ But wireless-testing tree, maintained by Bob Copeland, is handy to follow the status because it contains all the wireless trees: https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git/ -- 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] Fix regression in Android due to rework .get_station() callback
Arend Van Spriel writes:
> On 6-5-2016 18:02, Kalle Valo wrote:
>> Jaap Jan Meijer writes:
>>
>>> 2016-05-06 16:12 GMT+01:00 Kalle Valo :
Jaap Jan Meijer writes:
> Hi Kalle,
>
> Op vr 6 mei 2016 12:52 schreef Kalle Valo :
>
>
> This has multiple issues:
>
> o Use your full name.
> o Use prefix "brcmfmac: " in the title.
>
> o I can't find commit f654d13, is the commit id really correct?
> o Also check from SubmittingPatches how you should reference commit
> ids.
>
>
>
> Thank you for the feedback, I will send a reworked patch as soon as I get
> home
> next week. Also I did this against v4.4.8 so I'll have to rebase it as
> well.
>
> I'm not sure what went wrong with the commit hash, its actually this
> commit:
> 1f0dc59a6de93586fcfc04696a61946408ffc56a.
That commit id looks to be valid.
> I see you did this commit, maybe you can check if this actually is the
> root
> cause? I'm sure you have a lot more insight into this issue than I do.
>>
>> I just commited the patch. Broadcom folks (CCed) should be able to
>> answer better, most likely they missed this patch as the title didn't
>> have "brcmfmac".
>
> I did see the patch and noticed the procedural issues as well. However,
> last week was a short week over here and I did not get to it to respond.
> The fix is not done properly. The function determines the RSSI from the
> per-chain values. I suspect that Jaap Jan is using a device which does
> not report per-chain values so his solution should be used as fallback.
> So can you revert the patch so Jaap Jan can rework the patch, ie.:
>
> if (count_rssi) {
> :
> } else if (test_bit(BRCMF_VIF_STATUS_CONNECTED,
> &ifp->vif->sme_state)) {
> memset(&scb_val, 0, sizeof(scb_val));
> err = brcmf_fil_cmd_data_get(ifp, BRCMF_C_GET_RSSI,
>&scb_val, sizeof(scb_val));
> if (err) {
> brcmf_err("Could not get rssi (%d)\n", err);
> goto done;
> } else {
> rssi = le32_to_cpu(scb_val.val);
> sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL);
> sinfo->signal = rssi;
> brcmf_dbg(CONN, "RSSI %d dBm\n", rssi);
> }
> }
>
> Let me know if that is ok or should I submit a fixup patch.
I haven't applied Jaap's patch yet so he can send v2. Sorry for the
confusion.
--
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 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
> > Moving the radio back to the creators namespace would be the most > > consistent behavior, so I'll check how difficult such a reverse > > lookup is. We then would delete the radio only if it is in the > > creators namespace, or if the creators namespace is gone. Does that > > make sense? > It does make sense, but it does also feel a bit complicated. Yes, and proper locking gets difficult when using cfg80211_set_netns(), which can sleep. This would probably need larger changes in the locking code, but that's IMO not worth the effort. > Perhaps just special-case the init_net case for consistency with the > existing behaviour, and reserve netgroup 0 for that so we can easily > check for it? I'll do that in a v2, following immediately. > > I suspect you should be defining a structure that currently > > contains one integer member. Something (maybe a compile time > > assert) needs to check that buffer space you are accessing (where > > ever it is) is large enough. > > It does look a bit awkward, but there's no value in having a struct - > you still have an opaque pointer here and cast it to something whose > size you assume to be present... it really makes no difference. I agree there is no added safety when using a struct; Nonetheless have I added one in v2, and is it just for any future member additions. Best regards Martin -- 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 0/2] wireless: Allow wiphy/hwsim management from user namespaces
This patch set enables user namespaces having CAP_NET_ADMIN to manage wiphy devices and create/destroy hwsim radios. The first patch allows a caller from a non-initial user namespace to run privileged nl80211 phy/dev operations. The second patch enables hwsim radio management over Netlink from such namespaces. Together, with these patches an unprivileged test environment can create user/network namespaces and set up abitrary simulated wireless networks. Changes from v1: * Use a simple counter in hwsim to assign netgroups to net namespaces. * Store hwsim net_generic() data in a struct, add accessors. * On namespace exit, do not destroy hwsim radios originally created in the initial network namespace. Martin Willi (2): nl80211: Allow privileged operations from user namespaces mac80211_hwsim: Allow managing radios from non-initial namespaces drivers/net/wireless/mac80211_hwsim.c | 97 +- net/wireless/nl80211.c| 150 +- 2 files changed, 169 insertions(+), 78 deletions(-) -- 2.7.4 -- 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 1/2] nl80211: Allow privileged operations from user namespaces
While a wiphy can be transferred to network namespaces, a process having
CAP_NET_ADMIN in a non-initial user namespace can not administrate such
devices due to the genetlink GENL_ADMIN_PERM restrictions.
For openvswitch having the same issue, a new GENL_UNS_ADMIN_PERM flag has
been introduced, commit 4a92602aa1cd ("openvswitch: allow management from
inside user namespaces"). This patch changes all privileged operations
operating on a wiphy, dev or wdev to allow their administration using the
same mechanism. All operations use either NEED_WIPHY, NEED_WDEV or
NEED_NETDEV, which implies a namespace aware lookup of the device. The only
exception is NL80211_CMD_SET_WIPHY, which explicitly uses a namespace aware
phy lookup.
Signed-off-by: Martin Willi
---
net/wireless/nl80211.c | 150 -
1 file changed, 75 insertions(+), 75 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9bc84a2..df4c897 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10945,7 +10945,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_SET_WIPHY,
.doit = nl80211_set_wiphy,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_RTNL,
},
{
@@ -10961,7 +10961,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_SET_INTERFACE,
.doit = nl80211_set_interface,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV |
NL80211_FLAG_NEED_RTNL,
},
@@ -10969,7 +10969,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_NEW_INTERFACE,
.doit = nl80211_new_interface,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WIPHY |
NL80211_FLAG_NEED_RTNL,
},
@@ -10977,7 +10977,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_DEL_INTERFACE,
.doit = nl80211_del_interface,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV |
NL80211_FLAG_NEED_RTNL,
},
@@ -10985,7 +10985,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_GET_KEY,
.doit = nl80211_get_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
},
@@ -10993,7 +10993,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_SET_KEY,
.doit = nl80211_set_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
@@ -11002,7 +11002,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_NEW_KEY,
.doit = nl80211_new_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
@@ -11011,14 +11011,14 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_DEL_KEY,
.doit = nl80211_del_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
},
{
.cmd = NL80211_CMD_SET_BEACON,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.doit = nl80211_set_beacon,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
@@ -11026,7 +11026,7 @@ static const struct genl_ops nl80211_ops[] = {
{
.cmd = NL80211_CMD_START_AP,
.policy = nl80211_policy,
-
[PATCH v2 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
While wiphys can be moved into network namespaces over nl80211, the
creation and removal of hwsim radios is currently limited to the initial
namespace. This patch allows management of namespaced radios from the
owning namespace by setting genetlink netnsok.
To prevent two arbitrary namespaces to communicate over the simulated
shared medium, radios are separated by netgroups. Each radio created in
the same namespace lives in the same netgroup and hence can communicate
with other radios in that group. When moving radios to other namespaces,
the netgroup is preserved, so two radios having the same netgroup can
communicate even if not in the same namespace; This allows a controlling
namespace to create radios and move them to other namespaces for
communication.
When a net namespace owning a radio exits, the radio is destroyed unless
it was created in the initial network namespace. This keeps the previous
behavior by returning them to the init namespace, but prevents unprivileged
users from creating radios in the initial namespace.
Signed-off-by: Martin Willi
---
drivers/net/wireless/mac80211_hwsim.c | 97 +--
1 file changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index c757f14..303d94d 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -30,6 +30,8 @@
#include
#include
#include
+#include
+#include
#include "mac80211_hwsim.h"
#define WARN_QUEUE 100
@@ -250,6 +252,28 @@ static inline void hwsim_clear_chanctx_magic(struct
ieee80211_chanctx_conf *c)
cp->magic = 0;
}
+static unsigned int hwsim_net_id;
+
+static int hwsim_netgroup;
+
+struct hwsim_net {
+ int netgroup;
+};
+
+static inline int hwsim_net_get_netgroup(struct net *net)
+{
+ struct hwsim_net *hwsim_net = net_generic(net, hwsim_net_id);
+
+ return hwsim_net->netgroup;
+}
+
+static inline void hwsim_net_set_netgroup(struct net *net)
+{
+ struct hwsim_net *hwsim_net = net_generic(net, hwsim_net_id);
+
+ hwsim_net->netgroup = hwsim_netgroup++;
+}
+
static struct class *hwsim_class;
static struct net_device *hwsim_mon; /* global monitor netdev */
@@ -526,6 +550,9 @@ struct mac80211_hwsim_data {
*/
u64 group;
+ /* group shared by radios created in the same netns */
+ int netgroup;
+
int power_level;
/* difference between this hw's clock and the real clock, in usecs */
@@ -568,6 +595,7 @@ static struct genl_family hwsim_genl_family = {
.name = "MAC80211_HWSIM",
.version = 1,
.maxattr = HWSIM_ATTR_MAX,
+ .netnsok = true,
};
enum hwsim_multicast_groups {
@@ -1202,6 +1230,9 @@ static bool mac80211_hwsim_tx_frame_no_nl(struct
ieee80211_hw *hw,
if (!(data->group & data2->group))
continue;
+ if (data->netgroup != data2->netgroup)
+ continue;
+
if (!hwsim_chans_compat(chan, data2->tmp_chan) &&
!hwsim_chans_compat(chan, data2->channel)) {
ieee80211_iterate_active_interfaces_atomic(
@@ -2349,6 +2380,7 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
struct ieee80211_hw *hw;
enum nl80211_band band;
const struct ieee80211_ops *ops = &mac80211_hwsim_ops;
+ struct net *net;
int idx;
if (WARN_ON(param->channels > 1 && !param->use_chanctx))
@@ -2366,6 +2398,13 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
err = -ENOMEM;
goto failed;
}
+
+ if (info)
+ net = genl_info_net(info);
+ else
+ net = &init_net;
+ wiphy_net_set(hw->wiphy, net);
+
data = hw->priv;
data->hw = hw;
@@ -2541,6 +2580,8 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
data->group = 1;
mutex_init(&data->mutex);
+ data->netgroup = hwsim_net_get_netgroup(net);
+
/* Enable frame retransmissions for lossy channels */
hw->max_rates = 4;
hw->max_rate_tries = 11;
@@ -3013,6 +3054,9 @@ static int hwsim_del_radio_nl(struct sk_buff *msg, struct
genl_info *info)
continue;
}
+ if (!net_eq(wiphy_net(data->hw->wiphy), genl_info_net(info)))
+ continue;
+
list_del(&data->list);
spin_unlock_bh(&hwsim_radio_lock);
mac80211_hwsim_del_radio(data, wiphy_name(data->hw->wiphy),
@@ -3039,6 +3083,9 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct
genl_info *info)
if (data->idx != idx)
continue;
+ if (!net_eq(wiphy_net(data->hw->wiphy), genl_info_net(info)))
+ continue;
+
skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_K
Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac
Arend (and Hante), I appreciate the feedback on the core problem - that brings the issue into a lot sharper focus. Based on your response I assume we should be able to see successful coexistence with Bluetooth and 802.11 STA mode, as well as STA and AP (with Bluetooth turned off). However, BT with AP mode should fail, and BT with AP and STA will fail. I will rerun some of our crude tests to see if I can corroborate your understanding by testing the different "should coexist" and "should not coexist" cases. You have a very interesting lead in statement in your response (bottom of message) but the sentence just ends with "because of...". Would you be willing to complete that thought, I would like to further understand the nature of the problem. Is there a known reason why the brcmfmac does not support the set_bitrate_mask() callback (such as the associated family of chips do not support rate limiting) or is this something that nobody has cared about to do date, ie, is it something that could be done if there was interest and resources? From: Arend Van Spriel Sent: Monday, May 9, 2016 8:23 To: Barry Reinhold; linux-wireless@vger.kernel.org Cc: Tom Harada; brcm80211-dev-list Subject: Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac On 7-5-2016 21:24, Barry Reinhold wrote: > I have observed erratic behavior with http connectivity over the WiFi > interface of the Raspberry PI 3. This appears to be consistent with issues > that a number of other people have reported. I fear, but can not provide > definitive evidence, that these failures could be an RF design/layout issue > with the RP-3 itself. > > The purpose of this post is to see if this possible issue can be confirmed by > others, and to seek a possible work around by re configuring the BCM43438 > chip via the brcmfmac driver; or the other associated wifi modules. > > How the issue is being seen: > > Note: The testing I have done is limited and has the potential to be > misleading, so any input on improving the test process would be appreciated. > > There are two metrics we are using to define/see failure: (1) Loss/delay in > ICMP Echo requests/replys (pings), and (2) The output of messages in > journalctl from the wpa_supplicant or hostapd (sudo journalctl -u > wpa_supplicant -u hostapd -f) indicating a disconnect event with associated > reason - typically 0 - (wlan0: CTRL-EVENT-DISCONNECTED > bssid=60:02:92:cd:c9:30 reason=0). > Ping times vary from 1 to several hundred ms, to outright loss. > There are also failures to reassociate (wlan0: CTRL-EVENT-ASSOC-REJECT > status_code=16). > > The test Environment is composed of: > An official Raspberry PI-3 model B with an official Raspberry PI-3 power > supply. > Raspbian release: Jesse (March 18) > Kernel 4.4.6 > wpa_supplicant 2.3 > brcmfmac 7.45.41.23 (as reported by ethool) > BCM43438 firmware: 01-cc44eda9c > BlueZ 5.23 > > We are running both wpa_supplicant and hostapd, (disabling hostapd does not > impact the results of the tests). > We have an application that is monitoring for BTLE/Bluetooth connections so > it is scanning on a regular basis, as well as sending out Bluetooth INQUIRE > messages. > > WiFi Access Points: > 1. Cisco DPC3939B (supports n) > 2. Cisco Linksys E1200 (supports n) > 3. Netgear WNDR3400 (supports n) > 4. Linksys WAP54G v3 (does not support n) > > > > Test Process > > > While the application is running (thus generating Bluetooth activity) > 1. Connect a PC to the RPi3's software access point and ping the RPi3 > continuously. > 2. Connect the RPi3 to an AP from the set above. > 3. Let the system run for 10 minutes while counting wpa_supplicant > disconnects and lost pings. > > Observations: > In our testing we noticed that either we essentially got no errors, or we got > 12+ errors. Some error rates high enough that we couldn't count them as they > just scrolled off our screen. Hence we considered thing to work (less then 2 > errors) or failed (greater than 10 errors). > > The results table for the different APs is as follows: > DPC3939B - Failed > E1200 - Failed > WNDR3400 - Failed > WAP54G - Passed > > Since only the WAP54G passed (no n support), we modified the data rate on the > Netgear WND3400 and limited its data rate to 54 mbs, at this point the > WNDR3400 passed. > > We then tried changing channels. this did not impact the metrics we were > monitoring. > > Now being suspicious of RF issues on the board, we modified our application > which performs the Bluetooth communications so that Bluetooth was disabled. > This did not eliminate errors but dramatically reduced them. We then modified > our application to generate a lot of Bluetooth inquiry messages and > discovered that the generation and resulting response from INQUIRY messages > correlated with journalctl disconnection messages. > > We repeated this on the AP WAP54G and the rate limited WNDR3400 and did not > see proble
Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac
Ugh. A somewhat dumb question is how would I disable bluetooth entirely on the rpi3? I had done some initial tests on the rpi3 for the fq_codel on wifi work and gave up due to dismal results on the flent tests. I hadn't got around to writing them up here, http://blog.cerowrt.org/tags/wifi/ but perhaps disabling bluetooth would help. On Mon, May 9, 2016 at 9:59 AM, Barry Reinhold wrote: > Arend (and Hante), > > I appreciate the feedback on the core problem - that brings the issue into a > lot sharper focus. Based on your response I assume we should be able to see > successful coexistence with Bluetooth and 802.11 STA mode, as well as STA and > AP (with Bluetooth turned off). However, BT with AP mode should fail, and BT > with AP and STA will fail. > > I will rerun some of our crude tests to see if I can corroborate your > understanding by testing the different "should coexist" and "should not > coexist" cases. > > You have a very interesting lead in statement in your response (bottom of > message) but the sentence just ends with "because of...". Would you be > willing to complete that thought, I would like to further understand the > nature of the problem. > > Is there a known reason why the brcmfmac does not support the > set_bitrate_mask() callback (such as the associated family of chips do not > support rate limiting) or is this something that nobody has cared about to do > date, ie, is it something that could be done if there was interest and > resources? > > > From: Arend Van Spriel > Sent: Monday, May 9, 2016 8:23 > To: Barry Reinhold; linux-wireless@vger.kernel.org > Cc: Tom Harada; brcm80211-dev-list > Subject: Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac > > On 7-5-2016 21:24, Barry Reinhold wrote: >> I have observed erratic behavior with http connectivity over the WiFi >> interface of the Raspberry PI 3. This appears to be consistent with issues >> that a number of other people have reported. I fear, but can not provide >> definitive evidence, that these failures could be an RF design/layout issue >> with the RP-3 itself. >> >> The purpose of this post is to see if this possible issue can be confirmed >> by others, and to seek a possible work around by re configuring the BCM43438 >> chip via the brcmfmac driver; or the other associated wifi modules. >> >> How the issue is being seen: >> >> Note: The testing I have done is limited and has the potential to be >> misleading, so any input on improving the test process would be appreciated. >> >> There are two metrics we are using to define/see failure: (1) Loss/delay in >> ICMP Echo requests/replys (pings), and (2) The output of messages in >> journalctl from the wpa_supplicant or hostapd (sudo journalctl -u >> wpa_supplicant -u hostapd -f) indicating a disconnect event with associated >> reason - typically 0 - (wlan0: CTRL-EVENT-DISCONNECTED >> bssid=60:02:92:cd:c9:30 reason=0). >> Ping times vary from 1 to several hundred ms, to outright loss. >> There are also failures to reassociate (wlan0: CTRL-EVENT-ASSOC-REJECT >> status_code=16). >> >> The test Environment is composed of: >> An official Raspberry PI-3 model B with an official Raspberry PI-3 power >> supply. >> Raspbian release: Jesse (March 18) >> Kernel 4.4.6 >> wpa_supplicant 2.3 >> brcmfmac 7.45.41.23 (as reported by ethool) >> BCM43438 firmware: 01-cc44eda9c >> BlueZ 5.23 >> >> We are running both wpa_supplicant and hostapd, (disabling hostapd does not >> impact the results of the tests). >> We have an application that is monitoring for BTLE/Bluetooth connections so >> it is scanning on a regular basis, as well as sending out Bluetooth INQUIRE >> messages. >> >> WiFi Access Points: >> 1. Cisco DPC3939B (supports n) >> 2. Cisco Linksys E1200 (supports n) >> 3. Netgear WNDR3400 (supports n) >> 4. Linksys WAP54G v3 (does not support n) >> >> >> >> Test Process >> >> >> While the application is running (thus generating Bluetooth activity) >> 1. Connect a PC to the RPi3's software access point and ping the RPi3 >> continuously. >> 2. Connect the RPi3 to an AP from the set above. >> 3. Let the system run for 10 minutes while counting wpa_supplicant >> disconnects and lost pings. >> >> Observations: >> In our testing we noticed that either we essentially got no errors, or we >> got 12+ errors. Some error rates high enough that we couldn't count them as >> they just scrolled off our screen. Hence we considered thing to work (less >> then 2 errors) or failed (greater than 10 errors). >> >> The results table for the different APs is as follows: >> DPC3939B - Failed >> E1200 - Failed >> WNDR3400 - Failed >> WAP54G - Passed >> >> Since only the WAP54G passed (no n support), we modified the data rate on >> the Netgear WND3400 and limited its data rate to 54 mbs, at this point the >> WNDR3400 passed. >> >> We then tried changing channels. this did not impact the metrics we were >> monitoring. >> >> No
Re: [PATCH v2 5/5] ath10k: Fix deadlock when peer cannot be created.
Kalle: I notice these 5 patches are not in the latest wireless-testing.
Are they not acceptable, or???
Thanks,
Ben
On 04/01/2016 02:12 PM, gree...@candelatech.com wrote:
From: Ben Greear
We must not attempt to send WMI packets while holding the data-lock,
as it may deadlock:
BUG: sleeping function called from invalid context at
drivers/net/wireless/ath/ath10k/wmi.c:1824
in_atomic(): 1, irqs_disabled(): 0, pid: 2878, name: wpa_supplicant
=
[ INFO: possible recursive locking detected ]
4.4.6+ #21 Tainted: GW O
-
wpa_supplicant/2878 is trying to acquire lock:
(&(&ar->data_lock)->rlock){+.-...}, at: []
ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
but task is already holding lock:
(&(&ar->data_lock)->rlock){+.-...}, at: []
ath10k_peer_create+0x122/0x1ae [ath10k_core]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&ar->data_lock)->rlock);
lock(&(&ar->data_lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by wpa_supplicant/2878:
#0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x14
#1: (&ar->conf_mutex){+.+.+.}, at: []
ath10k_add_interface+0x3b/0xbda [ath10k_core]
#2: (&(&ar->data_lock)->rlock){+.-...}, at: []
ath10k_peer_create+0x122/0x1ae [ath10k_core]
#3: (rcu_read_lock){..}, at: [] rcu_read_lock+0x0/0x66
[mac80211]
stack backtrace:
CPU: 3 PID: 2878 Comm: wpa_supplicant Tainted: GW O4.4.6+ #21
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS
4.6.5 06/07/2013
8801fcadf8f0 8137086d 82681720
82681720 8801fcadf9b0 8112e3be 8801fcadf920
0001 82681720 a0721500 8801fcb8d348
Call Trace:
[] dump_stack+0x81/0xb6
[] __lock_acquire+0xc5b/0xde7
[] ? ath10k_wmi_tx_beacons_iter+0x15/0x11a [ath10k_core]
[] ? mark_lock+0x24/0x201
[] lock_acquire+0x132/0x1cb
[] ? lock_acquire+0x132/0x1cb
[] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
[] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core]
[] _raw_spin_lock_bh+0x31/0x40
[] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
[] ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
[] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core]
[] __iterate_interfaces+0x9d/0x13d [mac80211]
[] ieee80211_iterate_active_interfaces_atomic+0x32/0x3e
[mac80211]
[] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core]
[] ath10k_wmi_tx_beacons_nowait.isra.13+0x14/0x16
[ath10k_core]
[] ath10k_wmi_cmd_send+0x71/0x242 [ath10k_core]
[] ath10k_wmi_peer_delete+0x3f/0x42 [ath10k_core]
[] ath10k_peer_create+0x15e/0x1ae [ath10k_core]
[] ath10k_add_interface+0x70d/0xbda [ath10k_core]
[] drv_add_interface+0x123/0x1a5 [mac80211]
[] ieee80211_do_open+0x351/0x667 [mac80211]
[] ieee80211_open+0x49/0x4c [mac80211]
[] __dev_open+0x88/0xde
[] __dev_change_flags+0xa4/0x13a
[] dev_change_flags+0x1f/0x54
[] devinet_ioctl+0x2b9/0x5c9
[] ? copy_to_user+0x32/0x38
[] inet_ioctl+0x81/0x9d
[] ? inet_ioctl+0x81/0x9d
[] sock_do_ioctl+0x20/0x3d
[] sock_ioctl+0x222/0x22e
[] do_vfs_ioctl+0x453/0x4d7
[] ? __sys_recvmsg+0x4c/0x5b
[] ? __fget_light+0x48/0x6c
[] SyS_ioctl+0x52/0x74
[] entry_SYSCALL_64_fastpath+0x16/0x7a
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 020dd25..be8345c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -700,10 +700,10 @@ static int ath10k_peer_create(struct ath10k *ar,
peer = ath10k_peer_find(ar, vdev_id, addr);
if (!peer) {
+ spin_unlock_bh(&ar->data_lock);
ath10k_warn(ar, "failed to find peer %pM on vdev %i after
creation\n",
addr, vdev_id);
ath10k_wmi_peer_delete(ar, vdev_id, addr);
- spin_unlock_bh(&ar->data_lock);
return -ENOENT;
}
--
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: [PATCH v2 5/5] ath10k: Fix deadlock when peer cannot be created.
> On Monday, May 9, 2016 10:49 PM, gree...@candelatech.com wrote: >> On 04/01/2016 02:12 PM, gree...@candelatech.com wrote: >> From: Ben Greear >> >> We must not attempt to send WMI packets while holding the data-lock, >> as it may deadlock: >> >> BUG: sleeping function called from invalid context at >> drivers/net/wireless/ath/ath10k/wmi.c:1824 >> in_atomic(): 1, irqs_disabled(): 0, pid: 2878, name: wpa_supplicant >> > Kalle: I notice these 5 patches are not in the latest wireless-testing. > > Are they not acceptable, or??? > Aah!.. I recently cooked up similar patch for BUG_ON issue. I think this one is stable candidate. no? -Rajkumar-- 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 5/5] ath10k: Fix deadlock when peer cannot be created.
On 05/09/2016 10:54 AM, Manoharan, Rajkumar wrote: On Monday, May 9, 2016 10:49 PM, gree...@candelatech.com wrote: On 04/01/2016 02:12 PM, gree...@candelatech.com wrote: From: Ben Greear We must not attempt to send WMI packets while holding the data-lock, as it may deadlock: BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath10k/wmi.c:1824 in_atomic(): 1, irqs_disabled(): 0, pid: 2878, name: wpa_supplicant Kalle: I notice these 5 patches are not in the latest wireless-testing. Are they not acceptable, or??? Aah!.. I recently cooked up similar patch for BUG_ON issue. I think this one is stable candidate. no? All 5 have a possibility of being worth stable I think, but at least they should probably go into upstream! They were not a lot of fun to find or fix, so it would be nice if no one else had to waste time on it. 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: [PATCH 1/3] ath9k: reuse ar9003_hw_tx_power_regwrite for tx99 setup
Helmut Schaa writes: > The same functionality as ar9003_hw_tx_power_regwrite is hardcoded in > ar9003_hw_tx99_set_txpower. Just reuse the existing > ar9003_hw_tx_power_regwrite > for TX99 setup too. > > Signed-off-by: Helmut Schaa Thanks, 3 patches applied to ath.git: 8569f5915456 ath9k: reuse ar9003_hw_tx_power_regwrite for tx99 setup e7ae328961ff ath9k: Move TX99 config option under ath9k debugging b0291715d31c ath9k: Simplify ar9003_hw_tx99_set_txpower -- 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] ath9k: Fix symbol overlap window for half/quarter channels
Helmut Schaa writes: > Since commit cd6cfd7311a385144a2f9c74f692ae2df3ae033f > "ath9k: do not set half/quarter channel flags in AR_PHY_MODE" the > condition "rfMode & (AR_PHY_MODE_QUARTER | AR_PHY_MODE_HALF)" would > never evaluate to true. > > Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE > marcros instead. > > Signed-off-by: Helmut Schaa > Cc: Felix Fietkau Thanks, applied to ath.git. -- 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
pull-request: wireless-drivers 2016-05-09
Hi Dave, one more iwlwifi fix we would like to get to 4.6 if possible. Please let me know if there are any problems. Kalle The following changes since commit e2841ea91611622370f66b4dfaa62599e8850d48: Merge tag 'iwlwifi-for-kalle-2016-04-12_2' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2016-04-21 15:40:13 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-05-09 for you to fetch changes up to cbbba30f1ac95a04aae9c61a55aebe5e6fdf29f0: Merge tag 'iwlwifi-for-kalle-2016-05-04' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2016-05-06 14:27:48 +0300) wireless-drivers fixes for 4.6 iwlwifi * fix P2P rates (and possibly other issues) Emmanuel Grumbach (1): iwlwifi: mvm: don't override the rate with the AMSDU len Kalle Valo (1): Merge tag 'iwlwifi-for-kalle-2016-05-04' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 83 --- 1 file changed, 48 insertions(+), 35 deletions(-) -- 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: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac
hciconfig hci0 down From: Dave Taht Sent: Monday, May 9, 2016 13:15 To: Barry Reinhold Cc: Arend Van Spriel; linux-wireless@vger.kernel.org; Tom Harada; brcm80211-dev-list Subject: Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac Ugh. A somewhat dumb question is how would I disable bluetooth entirely on the rpi3? I had done some initial tests on the rpi3 for the fq_codel on wifi work and gave up due to dismal results on the flent tests. I hadn't got around to writing them up here, http://blog.cerowrt.org/tags/wifi/ but perhaps disabling bluetooth would help. On Mon, May 9, 2016 at 9:59 AM, Barry Reinhold wrote: > Arend (and Hante), > > I appreciate the feedback on the core problem - that brings the issue into a > lot sharper focus. Based on your response I assume we should be able to see > successful coexistence with Bluetooth and 802.11 STA mode, as well as STA and > AP (with Bluetooth turned off). However, BT with AP mode should fail, and BT > with AP and STA will fail. > > I will rerun some of our crude tests to see if I can corroborate your > understanding by testing the different "should coexist" and "should not > coexist" cases. > > You have a very interesting lead in statement in your response (bottom of > message) but the sentence just ends with "because of...". Would you be > willing to complete that thought, I would like to further understand the > nature of the problem. > > Is there a known reason why the brcmfmac does not support the > set_bitrate_mask() callback (such as the associated family of chips do not > support rate limiting) or is this something that nobody has cared about to do > date, ie, is it something that could be done if there was interest and > resources? > > > From: Arend Van Spriel > Sent: Monday, May 9, 2016 8:23 > To: Barry Reinhold; linux-wireless@vger.kernel.org > Cc: Tom Harada; brcm80211-dev-list > Subject: Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac > > On 7-5-2016 21:24, Barry Reinhold wrote: >> I have observed erratic behavior with http connectivity over the WiFi >> interface of the Raspberry PI 3. This appears to be consistent with issues >> that a number of other people have reported. I fear, but can not provide >> definitive evidence, that these failures could be an RF design/layout issue >> with the RP-3 itself. >> >> The purpose of this post is to see if this possible issue can be confirmed >> by others, and to seek a possible work around by re configuring the BCM43438 >> chip via the brcmfmac driver; or the other associated wifi modules. >> >> How the issue is being seen: >> >> Note: The testing I have done is limited and has the potential to be >> misleading, so any input on improving the test process would be appreciated. >> >> There are two metrics we are using to define/see failure: (1) Loss/delay in >> ICMP Echo requests/replys (pings), and (2) The output of messages in >> journalctl from the wpa_supplicant or hostapd (sudo journalctl -u >> wpa_supplicant -u hostapd -f) indicating a disconnect event with associated >> reason - typically 0 - (wlan0: CTRL-EVENT-DISCONNECTED >> bssid=60:02:92:cd:c9:30 reason=0). >> Ping times vary from 1 to several hundred ms, to outright loss. >> There are also failures to reassociate (wlan0: CTRL-EVENT-ASSOC-REJECT >> status_code=16). >> >> The test Environment is composed of: >> An official Raspberry PI-3 model B with an official Raspberry PI-3 power >> supply. >> Raspbian release: Jesse (March 18) >> Kernel 4.4.6 >> wpa_supplicant 2.3 >> brcmfmac 7.45.41.23 (as reported by ethool) >> BCM43438 firmware: 01-cc44eda9c >> BlueZ 5.23 >> >> We are running both wpa_supplicant and hostapd, (disabling hostapd does not >> impact the results of the tests). >> We have an application that is monitoring for BTLE/Bluetooth connections so >> it is scanning on a regular basis, as well as sending out Bluetooth INQUIRE >> messages. >> >> WiFi Access Points: >> 1. Cisco DPC3939B (supports n) >> 2. Cisco Linksys E1200 (supports n) >> 3. Netgear WNDR3400 (supports n) >> 4. Linksys WAP54G v3 (does not support n) >> >> >> >> Test Process >> >> >> While the application is running (thus generating Bluetooth activity) >> 1. Connect a PC to the RPi3's software access point and ping the RPi3 >> continuously. >> 2. Connect the RPi3 to an AP from the set above. >> 3. Let the system run for 10 minutes while counting wpa_supplicant >> disconnects and lost pings. >> >> Observations: >> In our testing we noticed that either we essentially got no errors, or we >> got 12+ errors. Some error rates high enough that we couldn't count them as >> they just scrolled off our screen. Hence we considered thing to work (less >> then 2 errors) or failed (greater than 10 errors). >> >> The results table for the different APs is as follows: >> DPC3939B - Failed >> E1200 - Failed >> WNDR3400 - Failed >> WAP54G - Pass
Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac
On 9-5-2016 18:59, Barry Reinhold wrote: > Arend (and Hante), > > I appreciate the feedback on the core problem - that brings the issue into a > lot sharper focus. Based on your response I assume we should be able to see > successful coexistence with Bluetooth and 802.11 STA mode, as well as STA and > AP (with Bluetooth turned off). However, BT with AP mode should fail, and BT > with AP and STA will fail. > > I will rerun some of our crude tests to see if I can corroborate your > understanding by testing the different "should coexist" and "should not > coexist" cases. > > You have a very interesting lead in statement in your response (bottom of > message) but the sentence just ends with "because of...". Would you be > willing to complete that thought, I would like to further understand the > nature of the problem. These kind of references are why inline replies are preferrable. Anyway let me try and finish that sentence. An AP has to be able to sent a beacon on fixed times and subsequent traffic. As BT is master in most if not all bt-coex schemes that can easily screw up the beacon timing, which by the way is a reason for clients to disconnect. > Is there a known reason why the brcmfmac does not support the > set_bitrate_mask() callback (such as the associated family of chips do not > support rate limiting) or is this something that nobody has cared about to do > date, ie, is it something that could be done if there was interest and > resources? No specific reason. Regards, Arend > > From: Arend Van Spriel > Sent: Monday, May 9, 2016 8:23 > To: Barry Reinhold; linux-wireless@vger.kernel.org > Cc: Tom Harada; brcm80211-dev-list > Subject: Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac > > On 7-5-2016 21:24, Barry Reinhold wrote: >> I have observed erratic behavior with http connectivity over the WiFi >> interface of the Raspberry PI 3. This appears to be consistent with issues >> that a number of other people have reported. I fear, but can not provide >> definitive evidence, that these failures could be an RF design/layout issue >> with the RP-3 itself. >> >> The purpose of this post is to see if this possible issue can be confirmed >> by others, and to seek a possible work around by re configuring the BCM43438 >> chip via the brcmfmac driver; or the other associated wifi modules. >> >> How the issue is being seen: >> >> Note: The testing I have done is limited and has the potential to be >> misleading, so any input on improving the test process would be appreciated. >> >> There are two metrics we are using to define/see failure: (1) Loss/delay in >> ICMP Echo requests/replys (pings), and (2) The output of messages in >> journalctl from the wpa_supplicant or hostapd (sudo journalctl -u >> wpa_supplicant -u hostapd -f) indicating a disconnect event with associated >> reason - typically 0 - (wlan0: CTRL-EVENT-DISCONNECTED >> bssid=60:02:92:cd:c9:30 reason=0). >> Ping times vary from 1 to several hundred ms, to outright loss. >> There are also failures to reassociate (wlan0: CTRL-EVENT-ASSOC-REJECT >> status_code=16). >> >> The test Environment is composed of: >> An official Raspberry PI-3 model B with an official Raspberry PI-3 power >> supply. >> Raspbian release: Jesse (March 18) >> Kernel 4.4.6 >> wpa_supplicant 2.3 >> brcmfmac 7.45.41.23 (as reported by ethool) >> BCM43438 firmware: 01-cc44eda9c >> BlueZ 5.23 >> >> We are running both wpa_supplicant and hostapd, (disabling hostapd does not >> impact the results of the tests). >> We have an application that is monitoring for BTLE/Bluetooth connections so >> it is scanning on a regular basis, as well as sending out Bluetooth INQUIRE >> messages. >> >> WiFi Access Points: >> 1. Cisco DPC3939B (supports n) >> 2. Cisco Linksys E1200 (supports n) >> 3. Netgear WNDR3400 (supports n) >> 4. Linksys WAP54G v3 (does not support n) >> >> >> >> Test Process >> >> >> While the application is running (thus generating Bluetooth activity) >> 1. Connect a PC to the RPi3's software access point and ping the RPi3 >> continuously. >> 2. Connect the RPi3 to an AP from the set above. >> 3. Let the system run for 10 minutes while counting wpa_supplicant >> disconnects and lost pings. >> >> Observations: >> In our testing we noticed that either we essentially got no errors, or we >> got 12+ errors. Some error rates high enough that we couldn't count them as >> they just scrolled off our screen. Hence we considered thing to work (less >> then 2 errors) or failed (greater than 10 errors). >> >> The results table for the different APs is as follows: >> DPC3939B - Failed >> E1200 - Failed >> WNDR3400 - Failed >> WAP54G - Passed >> >> Since only the WAP54G passed (no n support), we modified the data rate on >> the Netgear WND3400 and limited its data rate to 54 mbs, at this point the >> WNDR3400 passed. >> >> We then tried changing channels. this did not impact the metrics we were >
Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac
On 9-5-2016 23:18, Arend Van Spriel wrote: > On 9-5-2016 18:59, Barry Reinhold wrote: >> Arend (and Hante), >> >> I appreciate the feedback on the core problem - that brings the issue into a >> lot sharper focus. Based on your response I assume we should be able to see >> successful coexistence with Bluetooth and 802.11 STA mode, as well as STA >> and AP (with Bluetooth turned off). However, BT with AP mode should fail, >> and BT with AP and STA will fail. >> >> I will rerun some of our crude tests to see if I can corroborate your >> understanding by testing the different "should coexist" and "should not >> coexist" cases. >> >> You have a very interesting lead in statement in your response (bottom of >> message) but the sentence just ends with "because of...". Would you be >> willing to complete that thought, I would like to further understand the >> nature of the problem. > > These kind of references are why inline replies are preferrable. Anyway > let me try and finish that sentence. An AP has to be able to sent a > beacon on fixed times and subsequent traffic. As BT is master in most if something dropped off again. It should say: ... and _handle_ subsequent traffic. > not all bt-coex schemes that can easily screw up the beacon timing, > which by the way is a reason for clients to disconnect. > >> Is there a known reason why the brcmfmac does not support the >> set_bitrate_mask() callback (such as the associated family of chips do not >> support rate limiting) or is this something that nobody has cared about to >> do date, ie, is it something that could be done if there was interest and >> resources? > > No specific reason. > > Regards, > Arend > >> >> From: Arend Van Spriel >> Sent: Monday, May 9, 2016 8:23 >> To: Barry Reinhold; linux-wireless@vger.kernel.org >> Cc: Tom Harada; brcm80211-dev-list >> Subject: Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac >> >> On 7-5-2016 21:24, Barry Reinhold wrote: >>> I have observed erratic behavior with http connectivity over the WiFi >>> interface of the Raspberry PI 3. This appears to be consistent with issues >>> that a number of other people have reported. I fear, but can not provide >>> definitive evidence, that these failures could be an RF design/layout issue >>> with the RP-3 itself. >>> >>> The purpose of this post is to see if this possible issue can be confirmed >>> by others, and to seek a possible work around by re configuring the >>> BCM43438 chip via the brcmfmac driver; or the other associated wifi modules. >>> >>> How the issue is being seen: >>> >>> Note: The testing I have done is limited and has the potential to be >>> misleading, so any input on improving the test process would be appreciated. >>> >>> There are two metrics we are using to define/see failure: (1) Loss/delay in >>> ICMP Echo requests/replys (pings), and (2) The output of messages in >>> journalctl from the wpa_supplicant or hostapd (sudo journalctl -u >>> wpa_supplicant -u hostapd -f) indicating a disconnect event with associated >>> reason - typically 0 - (wlan0: CTRL-EVENT-DISCONNECTED >>> bssid=60:02:92:cd:c9:30 reason=0). >>> Ping times vary from 1 to several hundred ms, to outright loss. >>> There are also failures to reassociate (wlan0: CTRL-EVENT-ASSOC-REJECT >>> status_code=16). >>> >>> The test Environment is composed of: >>> An official Raspberry PI-3 model B with an official Raspberry PI-3 power >>> supply. >>> Raspbian release: Jesse (March 18) >>> Kernel 4.4.6 >>> wpa_supplicant 2.3 >>> brcmfmac 7.45.41.23 (as reported by ethool) >>> BCM43438 firmware: 01-cc44eda9c >>> BlueZ 5.23 >>> >>> We are running both wpa_supplicant and hostapd, (disabling hostapd does not >>> impact the results of the tests). >>> We have an application that is monitoring for BTLE/Bluetooth connections so >>> it is scanning on a regular basis, as well as sending out Bluetooth INQUIRE >>> messages. >>> >>> WiFi Access Points: >>> 1. Cisco DPC3939B (supports n) >>> 2. Cisco Linksys E1200 (supports n) >>> 3. Netgear WNDR3400 (supports n) >>> 4. Linksys WAP54G v3 (does not support n) >>> >>> >>> >>> Test Process >>> >>> >>> While the application is running (thus generating Bluetooth activity) >>> 1. Connect a PC to the RPi3's software access point and ping the RPi3 >>> continuously. >>> 2. Connect the RPi3 to an AP from the set above. >>> 3. Let the system run for 10 minutes while counting wpa_supplicant >>> disconnects and lost pings. >>> >>> Observations: >>> In our testing we noticed that either we essentially got no errors, or we >>> got 12+ errors. Some error rates high enough that we couldn't count them as >>> they just scrolled off our screen. Hence we considered thing to work (less >>> then 2 errors) or failed (greater than 10 errors). >>> >>> The results table for the different APs is as follows: >>> DPC3939B - Failed >>> E1200 - Failed >>> WNDR3400 - Failed >>> WAP54G - Passed >>> >>> Si
[PATCH 03/21] ath10k: Support setting debug mask from driver code.
From: Ben Greear
Might want to turn off verbose debug as soon as you
see a firmware crash, for instance. Helps keep dmesg
output from over-running the stuff you care about.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/debug.c | 5 +
drivers/net/wireless/ath/ath10k/debug.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index e251155..a689bf1 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -194,6 +194,11 @@ void ath10k_print_driver_info(struct ath10k *ar)
}
EXPORT_SYMBOL(ath10k_print_driver_info);
+void ath10k_set_debug_mask(unsigned int v) {
+ ath10k_debug_mask = v;
+}
+EXPORT_SYMBOL(ath10k_set_debug_mask);
+
void ath10k_err(struct ath10k *ar, const char *fmt, ...)
{
struct va_format vaf = {
diff --git a/drivers/net/wireless/ath/ath10k/debug.h
b/drivers/net/wireless/ath/ath10k/debug.h
index 75c89e3..a5c9aae 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -69,6 +69,7 @@ void ath10k_debug_print_hwfw_info(struct ath10k *ar);
void ath10k_debug_print_board_info(struct ath10k *ar);
void ath10k_debug_print_boot_info(struct ath10k *ar);
void ath10k_print_driver_info(struct ath10k *ar);
+void ath10k_set_debug_mask(unsigned int v);
#ifdef CONFIG_ATH10K_DEBUGFS
int ath10k_debug_start(struct ath10k *ar);
--
2.4.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
[PATCH 15/21] ath10k: support CT firmware flag.
From: Ben Greear
Add placeholder so CT firmware can more easily co-exist with upstream
kernel.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
drivers/net/wireless/ath/ath10k/core.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index fa71d57..49c85c3 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
[ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
[ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
[ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
+ [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 1a75e2e..dd38f34 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -566,6 +566,9 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
+ /* Firmware from Candela Technologies, enables more VIFs, etc */
+ ATH10K_FW_FEATURE_WMI_10X_CT = 31,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
--
2.4.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
[PATCH 00/21] ath10k patches, generic and CT firmware related.
From: Ben Greear These are against wireless-testing from a few days ago. Here are a bunch of ath10k patches. First one is a crash fix. Next few are at least somewhat useful for generic firmware, and more useful for CT firmware. Much of it is related to better debugging of firmware crashes. If this can go in, then I can much better handle random bug reports from prople using stock kernels and CT firmware. With some small tweaks to how they package firmware, QCA could benefit as well. The last bit is some initial support for CT firmware. I figure it is a long-shot, but it would surely be nice to get this (and more!) upstream. If nothing else, these can be a basis for potential inclusion in openwrt or similar. These patches are not overly dependent on each other for the most part, so even if a few are not acceptable, maybe others can be applied upstream. Ben Greear (21): ath10k: Fix crash related to printing features. ath10k: fix typo in logging message ath10k: Support setting debug mask from driver code. ath10k: rate-limit packet tx errors ath10k: save firmware debug log messages. ath10k: save firmware stacks upon firmware crash ath10k: save firmware RAM and ROM BSS sections on crash ath10k: make firmware text debug messages more verbose. ath10k: print fw debug messages in hex. ath10k: support logging ath10k_info as KERN_DEBUG ath10k: add fw-powerup-fail to ethtool stats. ath10k: Support up to 64 vdevs. ath10k: Document cycle count related counters. ath10k: Add tx/rx bytes, cycle counters to ethtool stats. ath10k: support CT firmware flag. ath10k: Support 32+ stations. ath10k: Enable detecting failure to install key in firmware (CT). ath10k: Note limitation on beaconing vdevs. ath10k: Enable adhoc mode for CT firmware. ath10k: read firmware crash over ioread32 if CE fails. ath10k: Read dbglog buffers over register ping-pong. drivers/net/wireless/ath/ath10k/core.c | 70 ++- drivers/net/wireless/ath/ath10k/core.h | 52 +- drivers/net/wireless/ath/ath10k/debug.c | 268 +- drivers/net/wireless/ath/ath10k/debug.h | 18 ++ drivers/net/wireless/ath/ath10k/htt.h| 7 +- drivers/net/wireless/ath/ath10k/htt_rx.c | 23 ++- drivers/net/wireless/ath/ath10k/htt_tx.c | 22 ++- drivers/net/wireless/ath/ath10k/hw.h | 36 drivers/net/wireless/ath/ath10k/mac.c| 74 +++- drivers/net/wireless/ath/ath10k/pci.c| 311 ++- drivers/net/wireless/ath/ath10k/wmi.c| 43 - drivers/net/wireless/ath/ath10k/wmi.h| 6 + 12 files changed, 897 insertions(+), 33 deletions(-) -- 2.4.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
[PATCH 01/21] ath10k: Fix crash related to printing features.
From: Ben Greear This looks like a regression from c4cdf753 (move fw_features to struct ath10k_fw_file) Signed-off-by: Ben Greear --- drivers/net/wireless/ath/ath10k/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index e94cb87..b7318b8 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -1078,7 +1078,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name, } ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "features", "", - ar->running_fw->fw_file.fw_features, + fw_file->fw_features, sizeof(fw_file->fw_features)); break; case ATH10K_FW_IE_FW_IMAGE: -- 2.4.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
[PATCH 19/21] ath10k: Enable adhoc mode for CT firmware.
From: Ben Greear
CT firmware can support IBSS mode, so allow users to configure this.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/mac.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index f1bfb3a..3fc9006 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7482,6 +7482,10 @@ static const struct ieee80211_iface_limit
ath10k_10x_ct_if_limits[] = {
.max= 7,
.types = BIT(NL80211_IFTYPE_AP)
},
+ {
+ .max= 1,
+ .types = BIT(NL80211_IFTYPE_ADHOC)
+ },
};
static const struct ieee80211_iface_combination ath10k_if_comb[] = {
@@ -7862,6 +7866,7 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->iface_combinations =
ath10k_10x_ct_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_10x_ct_if_comb);
+ ar->hw->wiphy->interface_modes |=
BIT(NL80211_IFTYPE_ADHOC);
} else {
ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
ar->hw->wiphy->n_iface_combinations =
--
2.4.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
[PATCH 13/21] ath10k: Document cycle count related counters.
From: Ben Greear
They are not necessarily named in an intuitive manner,
so at least add some comments to help the next person.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/core.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index e7c228a..c4f649f 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -189,10 +189,10 @@ struct ath10k_fw_stats_pdev {
/* PDEV stats */
s32 ch_noise_floor;
- u32 tx_frame_count;
- u32 rx_frame_count;
- u32 rx_clear_count;
- u32 cycle_count;
+ u32 tx_frame_count; /* cycles spent transmitting frames */
+ u32 rx_frame_count; /* cycles spent receiving frames */
+ u32 rx_clear_count; /* Total channel busy time, evidently */
+ u32 cycle_count; /* Total on-channel time */
u32 phy_err_count;
u32 chan_tx_power;
u32 ack_rx_bad;
--
2.4.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
[PATCH 12/21] ath10k: Support up to 64 vdevs.
From: Ben Greear The (1 << x) - 1 trick won't work when you are trying to fill up all 64 bits, so add special case for that. And, move the limits to the per-nic structure instead of per-driver to allow better dynamic use of the limits. Signed-off-by: Ben Greear --- drivers/net/wireless/ath/ath10k/core.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 3f1786c..fa71d57 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -1819,7 +1819,10 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode, if (status) goto err_hif_stop; - ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1; + if (ar->max_num_vdevs >= 64) + ar->free_vdev_map = 0xLL; + else + ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1; INIT_LIST_HEAD(&ar->arvifs); -- 2.4.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
[PATCH 14/21] ath10k: Add tx/rx bytes, cycle counters to ethtool stats.
From: Ben Greear
The firmware does not offer tx/rx bytes counters, so just keep track of
it in the driver.
For the cycle counters:
Note these counters are since the chip reset, though the counters
wrap often. When cycle-counters counter overflows on
certain hardware, it will right shift all 4 of the
related registers to the right by one bit (basically,
divide by two). Since you have no idea what the others
were at when cycle-counter wrapped, you must simply
ignore any sample where cycle-counter wraps, and set
new baseline values to calculate diffs against next
time.
Hardware with this funny wrap logic will cause the
d_flags 'counter' to have bit 0x1 set, so that is how
user-space can know how to deal with this.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/core.h | 3 +++
drivers/net/wireless/ath/ath10k/debug.c | 22 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 3 +++
drivers/net/wireless/ath/ath10k/htt_tx.c | 22 +-
4 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index c4f649f..1a75e2e 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -466,6 +466,9 @@ struct ath10k_debug {
struct ath10k_dbglog_entry_storage dbglog_entry_data;
struct ath10k_fw_crash_data *fw_crash_data;
+
+ u64 tx_bytes; /* counter, firmware does not offer this stat */
+ u64 rx_bytes; /* counter, firmware does not offer this stat */
};
enum ath10k_state {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 54a2194..684a39d 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1442,11 +1442,15 @@ exit:
/* This generally cooresponds to the debugfs fw_stats file */
static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
"tx_pkts_nic",
- "tx_bytes_nic",
+ "tx_bytes_nic", /* from driver, firmware does not keep this stat. */
"rx_pkts_nic",
- "rx_bytes_nic",
+ "rx_bytes_nic", /* from driver, firmware does not keep this stat. */
"d_noise_floor",
- "d_cycle_count",
+ "d_cycle_count", /* this is duty cycle counter, basically channel-time.
88MHz clock */
+ "d_tx_cycle_count", /* tx cycle count */
+ "d_rx_cycle_count", /* rx cycle count */
+ "d_busy_count", /* Total channel busy time cycles (called 'clear' by
firmware) */
+ "d_flags", /* 0x1: hw has shifted cycle-count wrap, see
ath10k_hw_fill_survey_time */
"d_phy_error",
"d_rts_bad",
"d_rts_good",
@@ -1518,6 +1522,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
static const struct ath10k_fw_stats_pdev zero_stats = {};
const struct ath10k_fw_stats_pdev *pdev_stats;
int i = 0, ret;
+ u64 d_flags = 0;
mutex_lock(&ar->conf_mutex);
@@ -1541,12 +1546,19 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
spin_lock_bh(&ar->data_lock);
+ if (ar->hw_params.has_shifted_cc_wraparound)
+ d_flags |= 0x1;
+
data[i++] = pdev_stats->hw_reaped; /* ppdu reaped */
- data[i++] = 0; /* tx bytes */
+ data[i++] = ar->debug.tx_bytes;
data[i++] = pdev_stats->htt_mpdus;
- data[i++] = 0; /* rx bytes */
+ data[i++] = ar->debug.rx_bytes;
data[i++] = pdev_stats->ch_noise_floor;
data[i++] = pdev_stats->cycle_count;
+ data[i++] = pdev_stats->tx_frame_count;
+ data[i++] = pdev_stats->rx_frame_count;
+ data[i++] = pdev_stats->rx_clear_count; /* yes, this appears to
actually be 'busy' count */
+ data[i++] = d_flags; /* give user-space a chance to decode cycle
counters */
data[i++] = pdev_stats->phy_err_count;
data[i++] = pdev_stats->rts_bad;
data[i++] = pdev_stats->rts_good;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index cc979a4..47da904 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1379,6 +1379,9 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
}
skb_queue_walk(amsdu, msdu) {
+#ifdef CONFIG_ATH10K_DEBUGFS
+ ar->debug.rx_bytes += msdu->len;
+#endif
ath10k_htt_rx_h_csum_offload(msdu);
ath10k_htt_rx_h_undecap(ar, msdu, status, first_hdr, enctype,
is_decrypted);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 6269c61..06ec995 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -769,6 +769,7 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct
sk_buff *msdu)
int len = 0;
int msdu_id = -1;
int res;
+ int skb_len;
s
[PATCH 02/21] ath10k: fix typo in logging message
From: Ben Greear Signed-off-by: Ben Greear --- drivers/net/wireless/ath/ath10k/mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 0e24f9e..cd3016d 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -2747,7 +2747,7 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw, ret = ath10k_wmi_vdev_down(ar, arvif->vdev_id); if (ret) - ath10k_warn(ar, "faield to down vdev %i: %d\n", + ath10k_warn(ar, "failed to down vdev %i: %d\n", arvif->vdev_id, ret); arvif->def_wep_key_idx = -1; -- 2.4.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
[PATCH 21/21] ath10k: Read dbglog buffers over register ping-pong.
From: Ben Greear
This gives much better debugging capability when debugging
crashes in the firmware that cause CE transport loss.
(Such as AXI errors).
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/pci.c | 47 ++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 330c150..4069e72 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1532,7 +1532,7 @@ static int ath10k_ct_fw_crash_regs_harder(struct ath10k
*ar,
return -EBUSY;
pingpong:
- ath10k_warn(ar, "Trying to read crash dump over pingpong registers.\n");
+ ath10k_warn(ar, "Trying to read crash dump over pingpong registers, len
%d\n", len);
/* Firmware is trying to send us info it seems. */
for (q = 0; q 1500) {
+ ath10k_err(ar, "dbuf length is greater than 1500:
%d\n", len);
+ len = 1500;
+ }
+ if (ath10k_ct_fw_crash_regs_harder(ar, buffer, len/4))
+ goto free_and_cont;
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, buffer, len/4);
+ ath10k_dbg_print_fw_dbg_buffer(ar, buffer, len/4, KERN_ERR);
+
+ /* See if the second one is available */
+ if (ath10k_ct_fw_crash_regs_harder(ar, (__le32 *)(&dbuf),
sizeof(dbuf)/4))
+ goto free_and_cont;
+
+ len = le32_to_cpu(dbuf.length);
+ if (len > 1500) {
+ ath10k_err(ar, "dbuf[2] length is greater than 1500:
%d\n", len);
+ len = 1500;
+ }
+
+ if (ath10k_ct_fw_crash_regs_harder(ar, buffer, len/4))
+ goto free_and_cont;
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, buffer, len/4);
+ ath10k_dbg_print_fw_dbg_buffer(ar, buffer, len/4, KERN_ERR);
+
+ free_and_cont:
+ kfree(buffer);
}
BUILD_BUG_ON(REG_DUMP_COUNT_QCA988X % 4);
@@ -1723,6 +1767,7 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
spin_unlock_bh(&ar->data_lock);
+ /* ath10k_set_debug_mask(0); // stop more log spam */
queue_work(ar->workqueue, &ar->restart_work);
}
--
2.4.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
[PATCH 17/21] ath10k: Enable detecting failure to install key in firmware (CT).
From: Ben Greear
CT firmware has been modified so that it will always return
a response message when user requests to add a key, even if
the key could not actually be added. Upstream firmware may
assert or just not respond in a failure case.
This change should be compatible with non CT firmware.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/htt.h| 7 +--
drivers/net/wireless/ath/ath10k/htt_rx.c | 20 +---
drivers/net/wireless/ath/ath10k/mac.c| 3 ++-
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index dd38f34..dae453a 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -848,6 +848,7 @@ struct ath10k {
unsigned int filter_flags;
unsigned long dev_flags;
bool dfs_block_radar_events;
+ int install_key_rv; /* Store error code from key-install */
/* protected by conf_mutex */
bool radar_enabled;
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 911c535..c50b343 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -702,8 +702,9 @@ enum htt_security_types {
};
enum htt_security_flags {
-#define HTT_SECURITY_TYPE_MASK 0x7F
+#define HTT_SECURITY_TYPE_MASK 0x3F
#define HTT_SECURITY_TYPE_LSB 0
+ HTT_SECURITY_IS_FAILURE = 1 << 6, /* CT firmware only */
HTT_SECURITY_IS_UNICAST = 1 << 7
};
@@ -712,7 +713,9 @@ struct htt_security_indication {
/* dont use bitfields; undefined behaviour */
u8 flags; /* %htt_security_flags */
struct {
- u8 security_type:7, /* %htt_security_types */
+ u8 security_type:6, /* %htt_security_types */
+ is_failure:1, /* does this response indicate failure
+ (CT Firmware) */
is_unicast:1;
} __packed;
} __packed;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 47da904..02b5417 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2307,9 +2307,23 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar,
struct sk_buff *skb)
ath10k_dbg(ar, ATH10K_DBG_HTT,
"sec ind peer_id %d unicast %d type %d\n",
- __le16_to_cpu(ev->peer_id),
- !!(ev->flags & HTT_SECURITY_IS_UNICAST),
- MS(ev->flags, HTT_SECURITY_TYPE));
+ __le16_to_cpu(ev->peer_id),
+ !!(ev->flags & HTT_SECURITY_IS_UNICAST),
+ MS(ev->flags, HTT_SECURITY_TYPE));
+
+ /* CT firmware adds way to determine failure of key set, without
+* just timing things out. Indication of failure is determined
+* by the 6th bit of the security-type being set.
+*/
+ if (ev->flags & HTT_SECURITY_IS_FAILURE) {
+ ath10k_warn(ar, "Firmware failed to set security key,
peer_id: %d unicast %d type %d\n",
+ __le16_to_cpu(ev->peer_id),
+ !!(ev->flags & HTT_SECURITY_IS_UNICAST),
+ MS(ev->flags, HTT_SECURITY_TYPE));
+ ar->install_key_rv = -EINVAL;
+ } else {
+ ar->install_key_rv = 0;
+ }
complete(&ar->install_key_done);
break;
}
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 2169337..373f2ee 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -255,7 +255,8 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
if (time_left == 0)
return -ETIMEDOUT;
- return 0;
+ ret = ar->install_key_rv;
+ return ret;
}
static int ath10k_install_peer_wep_keys(struct ath10k_vif *arvif,
--
2.4.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
[PATCH 20/21] ath10k: read firmware crash over ioread32 if CE fails.
From: Ben Greear
This might work around problem where sometimes host cannot
access firmware crash over normal CE transport.
Requires CT firmware with matching logic in it's assert
handler (-13 and higher releases).
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/hw.h | 5
drivers/net/wireless/ath/ath10k/pci.c | 56 ++-
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index d3f37d5..5ff1fac 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -603,6 +603,7 @@ enum ath10k_hw_4addr_pad {
#define PCIE_INTR_ENABLE_ADDRESS 0x0008
#define PCIE_INTR_CAUSE_ADDRESS0x000c
#define PCIE_INTR_CLR_ADDRESS ar->regs->pcie_intr_clr_address
+#define SCRATCH_2_ADDRESS 0x002c
#define SCRATCH_3_ADDRESS ar->regs->scratch_3_address
#define CPU_INTR_ADDRESS 0x0010
@@ -614,6 +615,10 @@ enum ath10k_hw_4addr_pad {
#define FW_IND_INITIALIZED 2
#define FW_IND_HOST_READY 0x8000
+/* CT firmware only */
+#define FW_IND_SCRATCH2_WR (1<<14) /* scratch2 has data written to it */
+#define FW_IND_SCRATCH2_RD (1<<15) /* scratch2 has been read (by host) */
+
/* HOST_REG interrupt from firmware */
#define PCIE_INTR_FIRMWARE_MASK
ar->regs->pcie_intr_fw_mask
#define PCIE_INTR_CE_MASK_ALL ar->regs->pcie_intr_ce_mask_all
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 2adc459..330c150 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1507,6 +1507,54 @@ static void ath10k_pci_dump_exc_stack(struct ath10k *ar,
hi_err_stack);
}
+/* Only CT firmware can do this. Attempt to read crash dump over pci
+ * registers since normal CE transport is not working.
+ */
+static int ath10k_ct_fw_crash_regs_harder(struct ath10k *ar,
+ __le32 *reg_dump_values,
+ int len)
+{
+ u32 val;
+ int i;
+ int q;
+#define MAX_SPIN_TRIES 100
+
+ if (!test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ ar->running_fw->fw_file.fw_features)) {
+ return -EINVAL;
+ }
+
+ for (i = 0; ihttp://vger.kernel.org/majordomo-info.html
[PATCH 04/21] ath10k: rate-limit packet tx errors
From: Ben Greear
When firmware crashes, stack can continue to send packets
for a bit, and existing code was spamming logs.
So, rate-limit the error message for tx failures.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index cd3016d..42cac32 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
}
if (ret) {
- ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
- ret);
+ if (net_ratelimit())
+ ath10k_warn(ar, "failed to transmit packet, dropping:
%d\n",
+ ret);
ieee80211_free_txskb(ar->hw, skb);
}
--
2.4.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
[PATCH 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
From: Ben Greear
Helps keep messages off of (serial) console when
that is desired.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/debug.c | 5 -
drivers/net/wireless/ath/ath10k/debug.h | 6 ++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index c38862b..7d9ad99 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -139,7 +139,10 @@ void ath10k_info(struct ath10k *ar, const char *fmt, ...)
va_start(args, fmt);
vaf.va = &args;
- dev_info(ar->dev, "%pV", &vaf);
+ if (ath10k_debug_mask & ATH10K_DBG_INFO_AS_DBG)
+ dev_printk(KERN_DEBUG, ar->dev, "%pV", &vaf);
+ else
+ dev_info(ar->dev, "%pV", &vaf);
trace_ath10k_log_info(ar, &vaf);
va_end(args);
}
diff --git a/drivers/net/wireless/ath/ath10k/debug.h
b/drivers/net/wireless/ath/ath10k/debug.h
index 6356dce..4f10685 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -21,6 +21,10 @@
#include
#include "trace.h"
+/**
+ * ATH10K_DBG_INFO_AS_DBG: use dev_dbg instead of dev_info
+ * for ath10k_info messages
+ */
enum ath10k_debug_mask {
ATH10K_DBG_PCI = 0x0001,
ATH10K_DBG_WMI = 0x0002,
@@ -38,6 +42,8 @@ enum ath10k_debug_mask {
ATH10K_DBG_WMI_PRINT= 0x2000,
ATH10K_DBG_PCI_PS = 0x4000,
ATH10K_DBG_AHB = 0x8000,
+
+ ATH10K_DBG_INFO_AS_DBG = 0x4000,
ATH10K_DBG_FW = 0x8000,
ATH10K_DBG_ANY = 0x,
};
--
2.4.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
[PATCH 18/21] ath10k: Note limitation on beaconing vdevs.
From: Ben Greear
This only pertains to CT firmware, as standard firmware
can't do anywhere near this many vdevs anyway.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/mac.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 373f2ee..f1bfb3a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1343,6 +1343,22 @@ static int ath10k_vdev_start_restart(struct ath10k_vif
*arvif,
arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
+ /* CT Firmware can support 32+ VDEVS, but can only support
+* beacon-ing devs with dev ids 0 - 31 due to firmware limitations.
+* Create VAPs first and all should be well...likely most people
+* won't ever hit this anyway, but some day the vdev ID allocation
+* could be made smarter to make it more likely to work no matter the
+* order the vdevs are created. --Ben
+*/
+ if ((arvif->vdev_type == WMI_VDEV_TYPE_AP) ||
+ (arvif->vdev_type == WMI_VDEV_TYPE_IBSS)) {
+ if (arg.vdev_id > 31) {
+ ath10k_warn(ar, "failed to start vdev %i Beaconing
VIFS must have IDs <= 31 to work-around firmware limitations.\n",
+ arg.vdev_id);
+ return -EINVAL;
+ }
+ }
+
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
arg.ssid = arvif->u.ap.ssid;
arg.ssid_len = arvif->u.ap.ssid_len;
--
2.4.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
[PATCH 11/21] ath10k: add fw-powerup-fail to ethtool stats.
From: Ben Greear
This gives user-space a normal-ish way to detect that
firmware has failed to start and that a reboot is
probably required.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/debug.c | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 6aa7a14..e7c228a 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -698,6 +698,7 @@ struct ath10k {
enum ath10k_hw_rev hw_rev;
u16 dev_id;
+ bool fw_powerup_failed; /* If true, might take reboot to recover. */
u32 chip_id;
u32 target_version;
u8 fw_version_major;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 7d9ad99..54a2194 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1487,6 +1487,7 @@ static const char
ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
"d_fw_crash_count",
"d_fw_warm_reset_count",
"d_fw_cold_reset_count",
+ "d_fw_powerup_failed", /* boolean */
};
#define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
@@ -1586,6 +1587,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
data[i++] = ar->stats.fw_crash_counter;
data[i++] = ar->stats.fw_warm_reset_counter;
data[i++] = ar->stats.fw_cold_reset_counter;
+ data[i++] = ar->fw_powerup_failed;
spin_unlock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index dbf0db8..2adc459 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2709,10 +2709,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
goto err_ce;
}
+ ar->fw_powerup_failed = false;
return 0;
err_ce:
ath10k_pci_ce_deinit(ar);
+ ar->fw_powerup_failed = true;
err_sleep:
return ret;
--
2.4.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
[PATCH 16/21] ath10k: Support 32+ stations.
From: Ben Greear
Support up to 32 stations when using CT firmware.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/core.c | 14 +++
drivers/net/wireless/ath/ath10k/hw.h | 6 +
drivers/net/wireless/ath/ath10k/mac.c | 43 ++
drivers/net/wireless/ath/ath10k/wmi.c | 16 ++---
4 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 49c85c3..3869edd 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1567,6 +1567,20 @@ static int ath10k_core_init_firmware_features(struct
ath10k *ar)
ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+fw_file->fw_features)) {
+ ar->max_num_peers = TARGET_10X_NUM_PEERS_CT;
+ ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+ ar->max_num_vdevs = TARGET_10X_NUM_VDEVS_CT;
+ } else {
+ ar->max_num_peers = TARGET_10X_NUM_PEERS;
+ ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+ ar->max_num_vdevs = TARGET_10X_NUM_VDEVS;
+ }
+ ar->htt.max_num_pending_tx = TARGET_10X_NUM_MSDU_DESC;
+ ar->fw_stats_req_mask = WMI_STAT_PEER;
+ ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
+ break;
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
if (ath10k_peer_stats_enabled(ar)) {
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index 7b80e29..d3f37d5 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -370,6 +370,12 @@ enum ath10k_hw_4addr_pad {
(TARGET_10X_NUM_VDEVS))
#define TARGET_10X_TX_STATS_NUM_PEERS
((TARGET_10X_TX_STATS_NUM_STATIONS) + \
(TARGET_10X_NUM_VDEVS))
+
+/* Over-rides for Candela Technologies firmware */
+#define TARGET_10X_NUM_VDEVS_CT32
+#define TARGET_10X_NUM_PEERS_CT(32 +
(TARGET_10X_NUM_VDEVS_CT))
+#define TARGET_10X_AST_SKID_LIMIT_CT (TARGET_10X_NUM_PEERS_CT *
TARGET_10X_NUM_PEER_AST)
+
#define TARGET_10X_NUM_OFFLOAD_PEERS 0
#define TARGET_10X_NUM_OFFLOAD_REORDER_BUFS0
#define TARGET_10X_NUM_PEER_KEYS 2
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 42cac32..2169337 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7451,6 +7451,22 @@ static const struct ieee80211_iface_limit
ath10k_10x_if_limits[] = {
},
};
+static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
+ {
+ .max= TARGET_10X_NUM_VDEVS_CT,
+ .types = BIT(NL80211_IFTYPE_STATION)
+ | BIT(NL80211_IFTYPE_P2P_CLIENT)
+ },
+ {
+ .max= 3,
+ .types = BIT(NL80211_IFTYPE_P2P_GO)
+ },
+ {
+ .max= 7,
+ .types = BIT(NL80211_IFTYPE_AP)
+ },
+};
+
static const struct ieee80211_iface_combination ath10k_if_comb[] = {
{
.limits = ath10k_if_limits,
@@ -7531,6 +7547,22 @@ static const struct ieee80211_iface_limit
ath10k_tlv_if_limit_ibss[] = {
},
};
+static const struct ieee80211_iface_combination ath10k_10x_ct_if_comb[] = {
+ {
+ .limits = ath10k_10x_ct_if_limits,
+ .n_limits = ARRAY_SIZE(ath10k_10x_ct_if_limits),
+ .max_interfaces = TARGET_10X_NUM_VDEVS_CT,
+ .num_different_channels = 1,
+ .beacon_int_infra_match = true,
+#ifdef CONFIG_ATH10K_DFS_CERTIFIED
+ .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
+ BIT(NL80211_CHAN_WIDTH_20) |
+ BIT(NL80211_CHAN_WIDTH_40) |
+ BIT(NL80211_CHAN_WIDTH_80),
+#endif
+ },
+};
+
/* FIXME: This is not thouroughly tested. These combinations may over- or
* underestimate hw/fw capabilities.
*/
@@ -7808,6 +7840,17 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ar->normal_mode_fw.fw_file.fw_features)) {
+ ar->hw->wiphy->iface_combinations =
ath10k_10x_ct_if_comb;
+ ar->hw->wiphy->n_iface_combinations =
+
[PATCH 05/21] ath10k: save firmware debug log messages.
From: Ben Greear
They may be dumped through the firmware dump debugfs
file.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/core.h | 18 ++
drivers/net/wireless/ath/ath10k/debug.c | 97 +++-
drivers/net/wireless/ath/ath10k/debug.h | 6 ++
drivers/net/wireless/ath/ath10k/hw.h| 21 +++
drivers/net/wireless/ath/ath10k/pci.c | 99 +
drivers/net/wireless/ath/ath10k/wmi.c | 13 +
drivers/net/wireless/ath/ath10k/wmi.h | 6 ++
7 files changed, 258 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 1379054..7f9f460 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -404,6 +404,22 @@ struct ath10k_vif_iter {
struct ath10k_vif *arvif;
};
+/* This will store at least the last 128 entries. Each dbglog message
+ * is a max of 7 32-bit integers in length, but the length can be less
+ * than that as well.
+ */
+#define ATH10K_DBGLOG_DATA_LEN (128 * 7)
+struct ath10k_dbglog_entry_storage {
+ u32 head_idx; /* Where to write next chunk of data */
+ u32 tail_idx; /* Index of first msg */
+ __le32 data[ATH10K_DBGLOG_DATA_LEN];
+};
+
+/* Just enough info to decode firmware debug-log argument length */
+#define DBGLOG_NUM_ARGS_OFFSET 26
+#define DBGLOG_NUM_ARGS_MASK 0xFC00 /* Bit 26-31 */
+#define DBGLOG_NUM_ARGS_MAX 5 /* firmware tool chain limit */
+
/* used for crash-dump storage, protected by data-lock */
struct ath10k_fw_crash_data {
bool crashed_since_read;
@@ -437,6 +453,8 @@ struct ath10k_debug {
u32 reg_addr;
u32 nf_cal_period;
+ struct ath10k_dbglog_entry_storage dbglog_entry_data;
+
struct ath10k_fw_crash_data *fw_crash_data;
};
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index a689bf1..38b3541 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -35,10 +35,11 @@
/**
* enum ath10k_fw_crash_dump_type - types of data in the dump file
* @ATH10K_FW_CRASH_DUMP_REGDUMP: Register crash dump in binary format
+ * @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
-
+ ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -109,6 +110,12 @@ struct ath10k_dump_file_data {
u8 data[0];
} __packed;
+struct ath10k_dbglog_entry_storage_user {
+ __le32 head_idx; /* Where to write next chunk of data */
+ __le32 tail_idx; /* Index of first msg */
+ __le32 data[ATH10K_DBGLOG_DATA_LEN];
+} __packed;
+
void ath10k_info(struct ath10k *ar, const char *fmt, ...)
{
struct va_format vaf = {
@@ -702,7 +709,6 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
lockdep_assert_held(&ar->data_lock);
- crash_data->crashed_since_read = true;
uuid_le_gen(&crash_data->uuid);
getnstimeofday(&crash_data->timestamp);
@@ -710,17 +716,87 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
}
EXPORT_SYMBOL(ath10k_debug_get_new_fw_crash_data);
+static void ath10k_dbg_drop_dbg_buffer(struct ath10k *ar)
+{
+ /* Find next message boundary */
+ u32 lg_hdr;
+ int acnt;
+ int tail_idx = ar->debug.dbglog_entry_data.tail_idx;
+ int h_idx = (tail_idx + 1) % ATH10K_DBGLOG_DATA_LEN;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ /* Log header is second 32-bit word */
+ lg_hdr = le32_to_cpu(ar->debug.dbglog_entry_data.data[h_idx]);
+
+ acnt = (lg_hdr & DBGLOG_NUM_ARGS_MASK) >> DBGLOG_NUM_ARGS_OFFSET;
+
+ if (acnt > DBGLOG_NUM_ARGS_MAX) {
+ /* Some sort of corruption it seems, recover as best we can. */
+ ath10k_err(ar, "invalid dbglog arg-count: %i %i %i\n",
+ acnt, ar->debug.dbglog_entry_data.tail_idx,
+ ar->debug.dbglog_entry_data.head_idx);
+ ar->debug.dbglog_entry_data.tail_idx =
+ ar->debug.dbglog_entry_data.head_idx;
+ return;
+ }
+
+ /* Move forward over the args and the two header fields */
+ ar->debug.dbglog_entry_data.tail_idx =
+ (tail_idx + acnt + 2) % ATH10K_DBGLOG_DATA_LEN;
+}
+
+void ath10k_dbg_save_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer, int len)
+{
+ int i;
+ int z;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ z = ar->debug.dbglog_entry_data.head_idx;
+
+ /* Don't save any new logs until user-space reads this. */
+ if (ar->debug.fw_crash_data &&
+ ar->debug.fw_crash_data->crashed_since_read) {
+ ath10k_warn(ar, "dropping dbg buffer due to crash since
read\n");
+ return;
+ }
+
+ for (i = 0; i < le
[PATCH 06/21] ath10k: save firmware stacks upon firmware crash
From: Ben Greear
Should help debug firmware crashes, and give users a way
to provide some useful debug reports to firmware developers.
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.h | 4 +++
drivers/net/wireless/ath/ath10k/debug.c | 29 +-
drivers/net/wireless/ath/ath10k/hw.h| 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 52 +
4 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 7f9f460..644d077 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -427,6 +427,10 @@ struct ath10k_fw_crash_data {
uuid_le uuid;
struct timespec timestamp;
__le32 registers[REG_DUMP_COUNT_QCA988X];
+ __le32 stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
+ __le32 exc_stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
+ __le32 stack_addr;
+ __le32 exc_stack_addr;
};
struct ath10k_debug {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 38b3541..7bc3053 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -36,10 +36,15 @@
* enum ath10k_fw_crash_dump_type - types of data in the dump file
* @ATH10K_FW_CRASH_DUMP_REGDUMP: Register crash dump in binary format
* @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
+ * @ATH10K_FW_CRASH_DUMP_STACK: Stack memory contents.
+ * @ATH10K_FW_CRASH_DUMP_EXC_STACK: Exception stack memory contents.
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
+ ATH10K_FW_CRASH_DUMP_STACK = 2,
+ ATH10K_FW_CRASH_DUMP_EXC_STACK = 3,
+
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -103,8 +108,11 @@ struct ath10k_dump_file_data {
/* VERMAGIC_STRING */
char kernel_ver[64];
+ __le32 stack_addr;
+ __le32 exc_stack_addr;
+
/* room for growth w/out changing binary format */
- u8 unused[128];
+ u8 unused[120];
/* struct ath10k_tlv_dump_data + more */
u8 data[0];
@@ -797,6 +805,8 @@ static struct ath10k_dump_file_data
*ath10k_build_dump_file(struct ath10k *ar)
len = hdr_len;
len += sizeof(*dump_tlv) + sizeof(crash_data->registers);
len += sizeof(*dump_tlv) + sizeof(ar->debug.dbglog_entry_data);
+ len += sizeof(*dump_tlv) + sizeof(crash_data->stack_buf);
+ len += sizeof(*dump_tlv) + sizeof(crash_data->exc_stack_buf);
sofar += hdr_len;
@@ -836,6 +846,8 @@ static struct ath10k_dump_file_data
*ath10k_build_dump_file(struct ath10k *ar)
dump_data->ht_cap_info = cpu_to_le32(ar->ht_cap_info);
dump_data->vht_cap_info = cpu_to_le32(ar->vht_cap_info);
dump_data->num_rf_chains = cpu_to_le32(ar->num_rf_chains);
+ dump_data->stack_addr = cpu_to_le32(crash_data->stack_addr);
+ dump_data->exc_stack_addr = cpu_to_le32(crash_data->exc_stack_addr);
strlcpy(dump_data->fw_ver, ar->hw->wiphy->fw_version,
sizeof(dump_data->fw_ver));
@@ -868,7 +880,22 @@ static struct ath10k_dump_file_data
*ath10k_build_dump_file(struct ath10k *ar)
cpu_to_le32(ar->debug.dbglog_entry_data.head_idx);
dbglog_storage->tail_idx =
cpu_to_le32(ar->debug.dbglog_entry_data.tail_idx);
+ sofar += sizeof(*dump_tlv) + tmp;
+ /* Gather firmware stack dump */
+ tmp = sizeof(crash_data->stack_buf);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_STACK);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->stack_buf, tmp);
+ sofar += sizeof(*dump_tlv) + tmp;
+
+ /* Gather firmware exception stack dump */
+ tmp = sizeof(crash_data->exc_stack_buf);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_EXC_STACK);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->exc_stack_buf, tmp);
sofar += sizeof(*dump_tlv) + tmp;
ar->debug.fw_crash_data->crashed_since_read = false;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index 5bbef4b..e86ebf0 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -122,6 +122,8 @@ enum qca9377_chip_id_rev {
#define REG_DUMP_COUNT_QCA988X 60
+#define ATH10K_FW_STACK_SIZE 4096
+
struct ath10k_fw_ie {
__le32 id;
__le32 len;
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 16e32d0..62dd167 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -985,6 +985,22 @@
[PATCH 09/21] ath10k: print fw debug messages in hex.
From: Ben Greear
This allows user-space tools to decode debug-log
messages by parsing dmesg or /var/log/messages.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/debug.c | 72 +
drivers/net/wireless/ath/ath10k/debug.h | 5 +++
drivers/net/wireless/ath/ath10k/pci.c | 3 ++
drivers/net/wireless/ath/ath10k/wmi.c | 12 ++
4 files changed, 92 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 28e0c05..c38862b 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2660,3 +2660,75 @@ void ath10k_dbg_dump(struct ath10k *ar,
EXPORT_SYMBOL(ath10k_dbg_dump);
#endif /* CONFIG_ATH10K_DEBUG */
+
+void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *ibuf, int len,
+ const char* lvl)
+{
+ /* Print out raw hex, external tools can decode if
+* they care.
+* TODO: Add ar identifier to messages.
+*/
+ int q = 0;
+
+ dev_printk(lvl, ar->dev, "ath10k_pci ATH10K_DBG_BUFFER:\n");
+ while (q < len) {
+ if (q + 8 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X
%08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5], ibuf[q+6], ibuf[q+7]);
+ q += 8;
+ }
+ else if (q + 7 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X
%08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5], ibuf[q+6]);
+ q += 7;
+ }
+ else if (q + 6 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X
%08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5]);
+ q += 6;
+ }
+ else if (q + 5 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4]);
+ q += 5;
+ }
+ else if (q + 4 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3]);
+ q += 4;
+ }
+ else if (q + 3 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2]);
+ q += 3;
+ }
+ else if (q + 2 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1]);
+ q += 2;
+ }
+ else if (q + 1 <= len) {
+ printk("%sath10k: [%04d]: %08X\n",
+ lvl, q,
+ ibuf[q]);
+ q += 1;
+ }
+ else {
+ break;
+ }
+ }/* while */
+
+ dev_printk(lvl, ar->dev, "ATH10K_END\n");
+}
+EXPORT_SYMBOL(ath10k_dbg_print_fw_dbg_buffer);
diff --git a/drivers/net/wireless/ath/ath10k/debug.h
b/drivers/net/wireless/ath/ath10k/debug.h
index 613ad7e..6356dce 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -38,6 +38,7 @@ enum ath10k_debug_mask {
ATH10K_DBG_WMI_PRINT= 0x2000,
ATH10K_DBG_PCI_PS = 0x4000,
ATH10K_DBG_AHB = 0x8000,
+ ATH10K_DBG_FW = 0x8000,
ATH10K_DBG_ANY = 0x,
};
@@ -193,4 +194,8 @@ static inline void ath10k_dbg_dump(struct ath10k *ar,
{
}
#endif /* CONFIG_ATH10K_DEBUG */
+
+void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer,
+ int len, const char* lvl);
+
#endif /* _DEBUG_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index e6315ec..dbf0db8 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1623,6 +1623,9 @@ static void ath10k_pci_dump_dbglog(struct ath10k *ar)
WARN_ON(len & 0x3);
ath10k_dbg_save_fw_dbg_buffer(ar, (__le32 *)(buffer), len >> 2);
+ ath10k_dbg_print_fw_dbg_buffer(ar, (_
[PATCH 07/21] ath10k: save firmware RAM and ROM BSS sections on crash
From: Ben Greear
This can be used to get a useful back trace out of a firmware
crash that involves an interrupt handler. For instance, a
null-pointer-exception would be this kind of trace. A user-space
tool can read the debugfs file and decode things as wished.
This requires a packaged firmware with a new IE to describe the
BSS section starts and length.
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.c | 48 +
drivers/net/wireless/ath/ath10k/core.h | 14 +
drivers/net/wireless/ath/ath10k/debug.c | 40 +++-
drivers/net/wireless/ath/ath10k/hw.h| 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 54 +
5 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index b7318b8..3f1786c 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -922,6 +922,13 @@ err:
return ret;
}
+struct ath10k_bss_rom_ie {
+ __le32 ram_addr;
+ __le32 ram_len;
+ __le32 rom_addr;
+ __le32 rom_len;
+} __packed;
+
static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
size_t name_len)
{
@@ -983,6 +990,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar,
const char *name,
struct ath10k_fw_ie *hdr;
const u8 *data;
__le32 *timestamp, *version;
+ struct ath10k_bss_rom_ie *bss;
/* first fetch the firmware file (firmware-*.bin) */
fw_file->firmware = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir,
@@ -1100,6 +1108,12 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar,
const char *name,
break;
case ATH10K_FW_IE_WMI_OP_VERSION:
+ /* Upstream stole the ID CT firmware was using, so add
+* hack-around to deal with backwards-compat. --Ben
+*/
+ if (ie_len >= sizeof(*bss))
+ goto fw_ie_bss_info_ct;
+
if (ie_len != sizeof(u32))
break;
@@ -1128,6 +1142,40 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar,
const char *name,
fw_file->codeswap_data = data;
fw_file->codeswap_len = ie_len;
break;
+ case ATH10K_FW_IE_BSS_INFO_CT:
+fw_ie_bss_info_ct:
+ if (ie_len < sizeof(*bss)) {
+ ath10k_warn(ar, "invalid ie len for bss-info
(%zd)\n",
+ ie_len);
+ break;
+ }
+ bss = (struct ath10k_bss_rom_ie *)(data);
+
+ fw_file->ram_bss_addr = le32_to_cpu(bss->ram_addr);
+ fw_file->ram_bss_len = le32_to_cpu(bss->ram_len);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "found RAM BSS addr 0x%x length %d\n",
+ fw_file->ram_bss_addr, fw_file->ram_bss_len);
+
+ if (fw_file->ram_bss_len > ATH10K_RAM_BSS_BUF_LEN) {
+ ath10k_warn(ar, "too long firmware RAM BSS
length: %d\n",
+ fw_file->ram_bss_len);
+ fw_file->ram_bss_len = 0;
+ }
+
+ fw_file->rom_bss_addr = le32_to_cpu(bss->rom_addr);
+ fw_file->rom_bss_len = le32_to_cpu(bss->rom_len);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "found ROM BSS addr 0x%x length %d\n",
+ fw_file->rom_bss_addr, fw_file->rom_bss_len);
+
+ if (fw_file->rom_bss_len > ATH10K_ROM_BSS_BUF_LEN) {
+ ath10k_warn(ar, "too long firmware ROM BSS
length: %d\n",
+ fw_file->rom_bss_len);
+ fw_file->rom_bss_len = 0;
+ }
+
+ break;
default:
ath10k_warn(ar, "Unknown FW IE: %u\n",
le32_to_cpu(hdr->id));
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 644d077..6aa7a14 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -420,6 +420,10 @@ struct ath10k_dbglog_entry_storage {
#define DBGLOG_NUM_ARGS_MASK 0xFC00 /* Bit 26-31 */
#define DBGLOG_NUM_ARGS_MAX 5 /* firmware tool chain limit */
+/* estimated values, hopefully these are enough */
+#define ATH10K_ROM_BSS_BUF_LEN 3
+#define ATH10K_RAM_BSS_BUF_LEN
[PATCH 08/21] ath10k: make firmware text debug messages more verbose.
From: Ben Greear There are not many of these messages producted by the firmware, but they are generally fairly useful, so print them at info level. Signed-off-by: Ben Greear --- drivers/net/wireless/ath/ath10k/wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index 1758b4a..d9e4b77 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb) /* the last byte is always reserved for the null character */ buf[i] = '\0'; - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf); + ath10k_info(ar, "wmi print '%s'\n", buf); } void ath10k_wmi_event_pdev_qvit(struct ath10k *ar, struct sk_buff *skb) -- 2.4.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
[PATCH] mac80211: Get ethtool-stats frequency more often.
From: Ben Greear
Some NICs (ath9k_htc) don't use chanctx_conf, it
seems, so look at local->hw.conf.channel->center_freq
in that case.
Signed-off-by: Ben Greear
---
net/mac80211/ethtool.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ethtool.c b/net/mac80211/ethtool.c
index 9cc986d..4e937c1 100644
--- a/net/mac80211/ethtool.c
+++ b/net/mac80211/ethtool.c
@@ -165,10 +165,14 @@ do_survey:
} while (channel != survey.channel);
}
- if (survey.filled)
- data[i++] = survey.channel->center_freq;
- else
- data[i++] = 0;
+ if (channel) {
+ data[i++] = channel->center_freq;
+ } else {
+ if (local->_oper_chandef.chan)
+ data[i++] = local->_oper_chandef.chan->center_freq;
+ else
+ data[i++] = 0;
+ }
if (survey.filled & SURVEY_INFO_NOISE_DBM)
data[i++] = (u8)survey.noise;
else
--
2.4.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: pull-request: wireless-drivers 2016-05-09
From: Kalle Valo Date: Mon, 09 May 2016 22:06:42 +0300 > one more iwlwifi fix we would like to get to 4.6 if possible. Please let > me know if there are any problems. Pulled, thanks Kalle. -- 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: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub
I previously wrote: > I previously wrote: > > I previously wrote: > > > > > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 > > > chipset). I've been testing it on a BeagleBone Black running an > > > Ubuntu > > > 16.04 image (4.4.6 kernel), with a USB hub. > > > > > > When I unplug the Wi-Fi device from the USB hub, and it's connected > > > to an access point, and then I unplug it, the OS appears to lock up. > > > I get messages about a soft lockup on the serial console: > > > > > > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > > > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup - > > > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI watchdog: > > > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [ > > > 9820.136699] NMI > > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > > > [kworker/u2:0:1129] [ 9848.136696] NMI watchdog: BUG: soft lockup - > CPU#0 stuck for 22s! > > > [kworker/u2:0:1129] > > > > > > This will repeat indefinitely, until I unplug the hub, which > > > resolves the soft lockup and then the system seems to function normally. > > > > > > I've attached a dmesg log of the soft lockup stack traces. They seem > > > to indicate a lockup in workqueue rt2x00usb_work_rxdone() > > > (specifically in > > > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called > > > from rt2x00usb_clear_entry()). > > > > > > I originally found this bug on a 3.14.x kernel built with Yocto for > > > a BeagleBone Black-based product. So it seems this is a bug that has > > > been around for some time. > > > > I should also note that on the 3.14.x Yocto-built kernel on BeagleBone > > Black, this bug does not occur if the rt2800 device is unplugged > > directly from the BBB's USB port. It only occurs if unplugged from a hub. > > > > I have tested this on an i586 based eBox-3310A mini-PC running Debian > > 8.4, which has a 3.16.0 kernel, with the same hub and same rt2800 > > device. But I was not able to reproduce this issue. > > There is a patch for the AM335x musb driver that seems to fix this: > > http://marc.info/?l=linux-usb&m=146173995117456&w=2 > > So it seems that this issue's root cause is in the AM335x USB interrupt > handling, and not the Wi-Fi rt2800 driver. Having applied two AM335x USB patches in the 3.14.49 kernel, that does seem to resolve the soft lock-up on the RX side. The two patches are: http://marc.info/?l=linux-usb&m=146173995117456&w=2 http://marc.info/?l=linux-usb&m=146222355213935&w=2 But I am finding there is still a lock-up issue when unplugging from a hub, this time on the TX side. It is more likely if there is Wi-Fi traffic in progress when the unplug occurs. I'm attaching a log. Essentially there are a heap of lines (100 or so per second): [ 1866.693511] ieee80211 phy7: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 Which finally stop shortly after USB disconnect is detected: [ 1866.985854] usb 1-1.3: USB disconnect, device number 10 However that disconnect message is typically 30-90 seconds after the unplug happened. It seems that the USB disconnect detection is delayed due to the CPU load of the TX. I also sometimes see a kernel panic. That can occur whether connected to a USB hub or directly to the on-board USB port. See the attached log. I'm not so familiar with either the Wi-Fi or USB stacks in the Linux kernel, so I would appreciate any advice with debugging and fixing this. (My previous investigations indicate these issues are present in both 3.14.x kernel and 4.4.6 kernel. I'm more familiar with working with the 3.14.x kernel under Yocto, but I could try moving to 4.4.6 kernel for Ubuntu. I'm open to advice on which to investigate on.) -- Craig McQueen 2016-05-10_rt2800_lockup_hub.tar.gz Description: 2016-05-10_rt2800_lockup_hub.tar.gz
[PATCH] mwifiex: fixup error messages
Use dev_err instead of pr_err and add newline character at the end.
Signed-off-by: Wei-Ning Huang
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 099722e..bdc51ff 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -104,7 +104,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct
sdio_mmc_card *card)
if (!dev->of_node ||
!of_match_node(mwifiex_sdio_of_match_table, dev->of_node)) {
- pr_err("sdio platform data not available");
+ dev_err(dev, "sdio platform data not available\n");
return -1;
}
@@ -115,7 +115,8 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct
sdio_mmc_card *card)
if (cfg && card->plt_of_node) {
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
- dev_err(dev, "fail to parse irq_wifi from device tree");
+ dev_err(dev,
+ "fail to parse irq_wifi from device tree\n");
} else {
ret = devm_request_irq(dev, cfg->irq_wifi,
mwifiex_wake_irq_wifi,
--
2.1.2
--
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: manual merge of the net-next tree with the wireless-drivers tree
Stephen Rothwell writes:
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c
>
> between commit:
>
> 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU len")
>
> from the wireless-drivers tree and commit:
>
> d8fe484470dd ("iwlwifi: mvm: add support for new TX CMD API")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
I'm planning to fix this by merging wireless-drivers to
wireless-drivers-next later today and most likely tomorrow send a
wireless-drivers-next pull request to Dave.
--
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 1/5] ath10k: Ensure txrx-compl-task is stopped when cleaning htt-tx.
Hi Ben,
On Fri, Apr 01, 2016 at 02:12:08PM -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> Otherwise, the txrx-compl-task may access some bad memory?
good to mention when this happens, will be helpful ifsome one recreates
the issue and matches your call trace
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
> b/drivers/net/wireless/ath/ath10k/htt_tx.c
> index 07b960e..58e88d3 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_tx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
> @@ -376,6 +376,8 @@ void ath10k_htt_tx_free(struct ath10k_htt *htt)
> {
> int size;
>
> + tasklet_kill(&htt->txrx_compl_task);
> +
> idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
> idr_destroy(&htt->pending_tx);
>
> --
> 2.4.3
regards,
shafi
>
>
> ___
> ath10k mailing list
> ath...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
--
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 net-next 4/5] treewide: replace dev->trans_start update with helper
On 05/03/2016 04:33 PM, Florian Westphal wrote:
> Replace all trans_start updates with netif_trans_update helper.
> change was done via spatch:
>
> struct net_device *d;
> @@
> - d->trans_start = jiffies
> + netif_trans_update(d)
>
> Compile tested only.
>
> Cc: user-mode-linux-de...@lists.sourceforge.net
> Cc: linux-xte...@linux-xtensa.org
> Cc: linux1394-de...@lists.sourceforge.net
> Cc: linux-r...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: mpt-fusionlinux@broadcom.com
> Cc: linux-s...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-h...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-wireless@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: b.a.t.m@lists.open-mesh.org
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Florian Westphal
> ---
> Checkpatch complains about whitespace damage, but
> this extra whitespace already exists before this patch.
>
> drivers/net/can/mscan/mscan.c | 4 ++--
> drivers/net/can/usb/ems_usb.c | 4 ++--
> drivers/net/can/usb/esd_usb2.c | 4 ++--
> drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 ++--
> diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
> index e36b740..acb708f 100644
> --- a/drivers/net/can/mscan/mscan.c
> +++ b/drivers/net/can/mscan/mscan.c
> @@ -276,7 +276,7 @@ static netdev_tx_t mscan_start_xmit(struct sk_buff *skb,
> struct net_device *dev)
> out_8(®s->cantflg, 1 << buf_id);
>
> if (!test_bit(F_TX_PROGRESS, &priv->flags))
> - dev->trans_start = jiffies;
> + netif_trans_update(dev);
>
> list_add_tail(&priv->tx_queue[buf_id].list, &priv->tx_head);
>
> @@ -469,7 +469,7 @@ static irqreturn_t mscan_isr(int irq, void *dev_id)
> clear_bit(F_TX_PROGRESS, &priv->flags);
> priv->cur_pri = 0;
> } else {
> - dev->trans_start = jiffies;
> + netif_trans_update(dev);
> }
>
> if (!test_bit(F_TX_WAIT_ALL, &priv->flags))
> diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
> index 3400fd1..71f0e79 100644
> --- a/drivers/net/can/usb/ems_usb.c
> +++ b/drivers/net/can/usb/ems_usb.c
> @@ -521,7 +521,7 @@ static void ems_usb_write_bulk_callback(struct urb *urb)
> if (urb->status)
> netdev_info(netdev, "Tx URB aborted (%d)\n", urb->status);
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* transmission complete interrupt */
> netdev->stats.tx_packets++;
> @@ -835,7 +835,7 @@ static netdev_tx_t ems_usb_start_xmit(struct sk_buff
> *skb, struct net_device *ne
> stats->tx_dropped++;
> }
> } else {
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* Slow down tx path */
> if (atomic_read(&dev->active_tx_urbs) >= MAX_TX_URBS ||
> diff --git a/drivers/net/can/usb/esd_usb2.c b/drivers/net/can/usb/esd_usb2.c
> index 113e64f..784a900 100644
> --- a/drivers/net/can/usb/esd_usb2.c
> +++ b/drivers/net/can/usb/esd_usb2.c
> @@ -480,7 +480,7 @@ static void esd_usb2_write_bulk_callback(struct urb *urb)
> if (urb->status)
> netdev_info(netdev, "Tx URB aborted (%d)\n", urb->status);
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
> }
>
> static ssize_t show_firmware(struct device *d,
> @@ -820,7 +820,7 @@ static netdev_tx_t esd_usb2_start_xmit(struct sk_buff
> *skb,
> goto releasebuf;
> }
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /*
>* Release our reference to this URB, the USB core will eventually free
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index 5a2e341..bfb91d8 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -274,7 +274,7 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
> netdev->stats.tx_bytes += context->data_len;
>
> /* prevent tx timeout */
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
> break;
>
> default:
> @@ -373,7 +373,7 @@ static netdev_tx_t peak_usb_ndo_start_xmit(struct sk_buff
> *skb,
> stats->tx_dropped++;
> }
> } else {
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* slow down tx path */
> if (atomic_read(&dev->active_tx_urbs) >= PCAN_USB_MAX_TX_URBS)
For the drivers/can part:
Acked-by: Marc Kleine-Budde
regards,
Marc
--
Pengutro
Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
On Wed, 2016-05-04 at 10:33 +0200, Martin Willi wrote: > > This changes today's default behaviour of moving the wiphys to the > > default namespace. Did you intend to destroy them based on the > > netgroup, i.e. based on the namespace that created them? Actually, > > maybe they should move back to the namespace that created them, if > > the namespace they are in is destroyed? But that's difficult, I > > don't > > mind this behaviour, but I'm not sure it's what we want by default > > for radios created in the init_net. > With the proposed approach I destroy all radios if the owning > namespace gets deleted, because we probably don't want them landing > in init_net if they are created from a (unprivileged) userns process. I agree they shouldn't land in init_net. > I think this is what other "virtual" interfaces do (gre tunnels, veth > etc.). If we think of hwsim radios as such a "virtual" device, that > makes IMO sense to delete them. Ok, I have no idea what happens there. > If we want to keep the existing behavior, we could move radios > belonging to the init_net-associated netgroup back to init_net, that > shouldn't be too difficult. > > Moving the radio back to the creators namespace would be the most > consistent behavior, so I'll check how difficult such a reverse > lookup is. We then would delete the radio only if it is in the > creators namespace, or if the creators namespace is gone. Does that > make sense? It does make sense, but it does also feel a bit complicated. Perhaps just special-case the init_net case for consistency with the existing behaviour, and reserve netgroup 0 for that so we can easily check for it? 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 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
> > > > + data->netgroup = *(int *)net_generic(net, hwsim_net_id); > Anything doing *(integer_type *) rings alarm bells. > > I suspect you should be defining a structure that currently contains > one integer member. > Something (maybe a compile time assert) needs to check that buffer > space you are accessing (where ever it is) is large enough. > It does look a bit awkward, but there's no value in having a struct - you still have an opaque pointer here and cast it to something whose size you assume to be present... it really makes no difference. 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] Fix regression in Android due to rework .get_station() callback
On 6-5-2016 18:02, Kalle Valo wrote:
> Jaap Jan Meijer writes:
>
>> 2016-05-06 16:12 GMT+01:00 Kalle Valo :
>>> Jaap Jan Meijer writes:
>>>
Hi Kalle,
Op vr 6 mei 2016 12:52 schreef Kalle Valo :
This has multiple issues:
o Use your full name.
o Use prefix "brcmfmac: " in the title.
o I can't find commit f654d13, is the commit id really correct?
o Also check from SubmittingPatches how you should reference commit
ids.
Thank you for the feedback, I will send a reworked patch as soon as I get
home
next week. Also I did this against v4.4.8 so I'll have to rebase it as
well.
I'm not sure what went wrong with the commit hash, its actually this
commit:
1f0dc59a6de93586fcfc04696a61946408ffc56a.
>>>
>>> That commit id looks to be valid.
>>>
I see you did this commit, maybe you can check if this actually is the root
cause? I'm sure you have a lot more insight into this issue than I do.
>
> I just commited the patch. Broadcom folks (CCed) should be able to
> answer better, most likely they missed this patch as the title didn't
> have "brcmfmac".
Hi Kalle,
I did see the patch and noticed the procedural issues as well. However,
last week was a short week over here and I did not get to it to respond.
The fix is not done properly. The function determines the RSSI from the
per-chain values. I suspect that Jaap Jan is using a device which does
not report per-chain values so his solution should be used as fallback.
So can you revert the patch so Jaap Jan can rework the patch, ie.:
if (count_rssi) {
:
} else if (test_bit(BRCMF_VIF_STATUS_CONNECTED,
&ifp->vif->sme_state)) {
memset(&scb_val, 0, sizeof(scb_val));
err = brcmf_fil_cmd_data_get(ifp, BRCMF_C_GET_RSSI,
&scb_val, sizeof(scb_val));
if (err) {
brcmf_err("Could not get rssi (%d)\n", err);
goto done;
} else {
rssi = le32_to_cpu(scb_val.val);
sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL);
sinfo->signal = rssi;
brcmf_dbg(CONN, "RSSI %d dBm\n", rssi);
}
}
Let me know if that is ok or should I submit a fixup patch.
Regards,
Arend
--
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: Planned Support for BCM 43162 [14e4:43ae] rev 02 ?
On 6-5-2016 2:03, Rafał Miłecki wrote: > On 5 May 2016 at 18:22, Jan Sobotka wrote: >> Great, now it works. Output: >> >> root@chobot-lenovo-laptop:/home/chobot# echo "14e4 43ae" > >> /sys/bus/pci/drivers/bcma-pci-bridge/new_id >> root@chobot-lenovo-laptop:/home/chobot# dmesg | egrep "bcma|b43" >> [ 5295.114902] bcma: bus0: Found chip with id 0x4335, rev 0x02 and package >> 0x01 >> [ 5295.114950] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, >> rev 0x2E, class 0x0) >> [ 5295.114974] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, >> rev 0x2E, class 0x0) >> [ 5295.115026] bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev >> 0x04, class 0x0) >> [ 5295.115073] bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, >> rev 0x04, class 0x0) >> [ 5295.115096] bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id >> 0x81A, rev 0x14, class 0x0) >> [ 5295.115119] bcma: bus0: Core 5 found: SDIO Device (manuf 0x4BF, id 0x829, >> rev 0x15, class 0x0) >> [ 5295.115170] bcma: bus0: Bridge found >> [ 5295.115221] bcma-pci-bridge: probe of :02:00.0 failed with error -84 > > So this is device with BCM4335 chipset which is a FullMAC one AFAIK. > It may be supported by brcmfmac. There is already support for BCM4335 > in brcmfmac but it was developed for SDIO devices only. I don't think > we ever met BCM4335 on PCIe device. It does have an ARM core, but for fullmac we need RAM as well and I don't see that listed. So I guess it is a 43162 and needs softmac driver. Also could not find any fullmac firmware for it. The only thing I found was a hybrid wl driver release for it. Regards, Arend > You may try: > sudo su > rmmod bcma > echo "14e4 43ae" > /sys/bus/pci/drivers/brcmfmac/new_id > dmesg | grep brcmfmac > > However I think brcmfmac may need some extra changes to support > BCM4335 on PCIe. Lets also see if Broadcom team can help us with this. > -- 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 4/4] ath10k: Enable support for QCA9984
The firmware crashes on applying this patch.. On examining the kernel OOPs, I have found out that that ath10k_bmi_execute in drivers/net/wireless/ath/ath10k/core.c when called goes in a loop until timeout occurs after which it eventually crashes. This is called from ath10k_core_get_board_id_from_otp in drivers/net/wireless/ath/ath10k/core.c . As per my understanding, the binaries of QCA99X0 that I have used for QCA9984 is not the correct one. Could you clarify? -- 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 4/4] ath10k: Enable support for QCA9984
On Monday 09 May 2016 03:16 PM, Archisman Maitra wrote: > > > The firmware crashes on applying this patch.. On examining the kernel OOPs, > I have found out that that ath10k_bmi_execute in > drivers/net/wireless/ath/ath10k/core.c when called goes in a loop until > timeout occurs after which it eventually crashes. This is called from > ath10k_core_get_board_id_from_otp in > drivers/net/wireless/ath/ath10k/core.c . As per my understanding, the > binaries of QCA99X0 that I have used for QCA9984 is not the correct one. > Could you clarify? Yes, the firmware binaries are different for QCA99X0 and QCA9984. Vasanth-- 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 4/4] ath10k: Enable support for QCA9984
Can you provide me the binaries of QCA9984? -- 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] iwlwifi: mvm: remove an unused variable
On Wed, 2016-05-04 at 09:19 +0300, Dan Carpenter wrote: > We never initalize ampdu_status so it causes a static checker warning > when we pass it to iwl_mvm_pass_packet_to_mac80211(). Fortunately, > it's > never used so we can just remove it. > > Signed-off-by: Dan Carpenter Thanks Dan! I'll push this patch through our internal tree. -- Cheers, Luca.
