Re: [PATCH v2] ath: Add support for tracing
Kalle Valo wrote: > The current debug printing code in ath10k is something like 100 lines, I > don't see the point of trying to make that common with all ath* drivers. > > In my opinion ath.ko should only have code which used at least two > different drivers (and I consider ath9k.ko and ath9k_htc.ko as one > driver). So the right thing here would be to actually move all debugging > code from ath.ko to ath9k, as it's the only user anyway. I don't think anyone is interested in moving debug code from ath.ko to ath9k.ko at this point. There is no benefit and it is just code churn. Sujith -- 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] mwifiex: add client mac address while configuring keys on GO.
From: Maithili Hinge
When mwifiex device becomes GO, unicast traffic between client1 and GO stops
when client2 connects to GO. Reason behind this was PTK getting
overwritten by key_material command for client2 as it did not have client
mac address. So, client1 can no more decode GO's ping packets though it
responds to its broadcast packets.
This patch adds case to check for BSS_ROLE instead of bss_type to set
client mac address while configuring keys when device becomes GO.
Signed-off-by: Maithili Hinge
Signed-off-by: Avinash Patil
Signed-off-by: Cathy Luo
---
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mwifiex/sta_cmd.c
b/drivers/net/wireless/mwifiex/sta_cmd.c
index 225f749..1c2ca29 100644
--- a/drivers/net/wireless/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/mwifiex/sta_cmd.c
@@ -938,7 +938,7 @@ mwifiex_cmd_802_11_key_material_v1(struct mwifiex_private
*priv,
cmd->size = cpu_to_le16(sizeof(key_material->action) + S_DS_GEN
+ key_param_len);
- if (priv->bss_type == MWIFIEX_BSS_TYPE_UAP) {
+ if (GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_UAP) {
tlv_mac = (void *)((u8 *)&key_material->key_param_set +
key_param_len);
tlv_mac->header.type =
--
1.8.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: [PATCH v2] ath: Add support for tracing
Sujith Manoharan writes: > Kalle Valo wrote: >> You mean ath_printk() & friends? But that doesn't require tracing code >> to be in ath.ko as well, right? If I understood correctly, trace.c could >> be under ath9k directory and the kconfig option could be >> ATH9K_TRACEPOINTS. >> >> I think it's just misleading and confusing for the user to call it >> "Atheros wireless tracing" when it only affects ath9k. It's easier to >> understand if each driver has it's own "tracing" kconfig option. > > We have CONFIG_ATH_DEBUG, which is used by ath9k and ath9k_htc. > I think it is okay to have CONFIG_ATH_TRACEPOINTS, which can be > used by ath9k/ath9k_htc too. In my opinion that just creates even a bigger mess. > The original motive of ath.ko was to have a common module with > debugging facilities that can be shared by Atheros drivers. But, > each driver has ended up reinventing things. The current debug printing code in ath10k is something like 100 lines, I don't see the point of trying to make that common with all ath* drivers. In my opinion ath.ko should only have code which used at least two different drivers (and I consider ath9k.ko and ath9k_htc.ko as one driver). So the right thing here would be to actually move all debugging code from ath.ko to ath9k, as it's the only user anyway. > Since it is mentioned in the help text that ath9k is the only driver > making use of ATH_DEBUG/ATH_TRACEPOINTS, I don't think it is > confusing. To me it is. But it's a mess already so I guess I'm worrying nothing. -- 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
[PATCH] mac80211: return the vif's chandef in ieee80211_cfg_get_channel()
From: Luciano Coelho
The chandef of the channel context a vif is using may be different
than the chandef of the vif itself. For instance, the bandwidth used
by the vif may be narrower than the one configured in the channel
context. To avoid confusion, return the vif's chandef in
ieee80211_cfg_get_channel() instead of the chandef of the channel
context.
Signed-off-by: Luciano Coelho
Signed-off-by: Emmanuel Grumbach
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 9b03d08..6a7339e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3476,7 +3476,7 @@ static int ieee80211_cfg_get_channel(struct wiphy *wiphy,
rcu_read_lock();
chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
if (chanctx_conf) {
- *chandef = chanctx_conf->def;
+ *chandef = sdata->vif.bss_conf.chandef;
ret = 0;
} else if (local->open_count > 0 &&
local->open_count == local->monitors &&
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Revert "ath9k_hw: reduce ANI firstep range for older chips"
Felix Fietkau wrote: > This reverts commit 09efc56345be4146ab9fc87a55c837ed5d6ea1ab > > I've received reports that this change is decreasing throughput in some > rare conditions on an AR9280 based device Wasn't the original patch for improving stability ? Won't reverting it reintroduce the earlier situation ? If ANI issues/regressions for pre-AR9003 chips are still arising, I wonder what we have gained by the switch and if the new algorithm is a good fit for the older chips. At least for SoC chips, people will report it to OpenWrt. For PC-OEM cards, users will just say that the card sucks and move on... Sujith -- 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
Proper way to use mac80211_hwsim.h in user-space tool?
As far as I can tell, the .h file is not installed anywhere in a normal OS. What is the proper method to get this file sanitized and put into a more common location? 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: BCM4313 & brcmsmac & 3.12: only semi-working?
On Monday 29 September 2014 15:44:03 Arend van Spriel wrote: > On 09/26/14 17:20, Michael Tokarev wrote: > > I can send it your way, -- guess it will be quite a bit costly, > > but I don't have any use for it anyway (short of throwing it > > away), and since I already spent significantly more money due > > to all this (whole thinkpad plus ssds and several wifi adaptors), > > this additional cost is just a small noize. But since that's > > 2nd card in a row, maybe there's something else in there, the > > prob is not in the card? > > Could be. Maybe some BIOS issue. Can you make some hi-res pictures of > the card and email them to me? If it is identical to what I already have > over here there is not much sense in sending it. > > Regards, > Arend Hi Arend, I just saw this thread on linux-wireless and wanted to answer as it might be of interest to you. I also own a BCM4313 wireless network card. About a year ago I reported some problems with reception strength which were then fixed after some time, debugging and testing passed. At that time I also did some throughput testing, but only had a 802.11g access-point to test. The results were not ideal, but also not too bad. So at that time I thought the issues were all more or less fixed and mostly fine. I also don't use wireless very much, so as long as things do work somehow acceptable I probably don't notice any problems immediately. So it comes that only about some month ago I noticed that the throughput I measured with my 11g access-point (about half the rate than with an atheros card on the same ap) is about the same on a 11n access-point where it should be much faster. I didn't experience any stalls, but that may also be that I didn't use the card enough to really notice them. I always wanted to report a bug because of the low throughout, but never got to it because of lack of time. I didn't want to provide a report saying just it doesn't work or it's slow without any data about it and a description how to reproduce it, as I think without this information a bug report is mostly useless. I also had a look at the kernel changelog of the brcmsm driver and notices there was little to no activity lately. Because of this I also wasn't sure if there is still someone interesting in fixing bugs for this device. As I was annoyed by the bad support for this card I decided it would be more easy and much less time consuming to simply buy another card than trying to get this fixed. So I bought a BCM43228 card, because it also supports 5 GHz. Only after it arrived I noticed that it was only supported by the 3.17+ kernel (not so much of a problem) and that it only seems to work in 802.11g mode (only slow speeds and no 5 GHz). At least I could use it in full 11g speeds, so it was a improvement. So I still don't have a card that does simply work. As I hope the missing support for my BCM43228 will hopefully be added some time in the future it probably would still be worth fixing the BCM4313 card as other users will also benefit from it. A friend of mine also has the same laptop than me and the same (or at least very similar) wireless card. He has told me he has also problem with stalls like Michael reported (if I remember the history of the thread correctly). So I'm not really sure where I should go from here. I can try to provide some debugging information as time permits, but I don't know how much time I will have for this in the future. Of course ideally I want to use the BCM43228 card with full support, as it can work on 5 GHz. Currently the BCM43228 card is plugged into my laptop, but I want to avoid swapping the cards more that very few times because the antenna connectors are only designed for very few (un)plug cycles. If it's of any information, my card is labeled BCM-BCM94313HMGB on the sticker, the laptop where it was originally is a ThinkPad Edge E135. Greetings, Maxi signature.asc Description: This is a digitally signed message part.
Re: RTL8188SU(rtl8192su) - unavailable
On Mon, 2014-09-29 at 11:29 +0200, poma wrote: > [platform/nm-platform.c:806] nm_platform_link_set_up(): link: setting up > 'wlp0s4f1u1' (4) > [platform/nm-linux-platform.c:2356] link_change_flags(): link: change 4: > flags set 'up' (1) > [platform/nm-linux-platform.c:2250] link_change(): Netlink error changing > link 4: mtu 0 (1) driver 'rtl8192su' udi > '/sys/devices/pci:00/:00:04.1/usb2/2-1/2-1:1.0/net/wlp0s4f1u1': No > such device > (wlp0s4f1u1): preparing device This is likely the core problem, and it's also probably the cause of the wpa_supplicant failures too. You can test this out without NM running by simply doing: ifconfig wlp0s4f1u1 up and see if it returns an error or not. Does it? Does anything show up in 'dmesg'? If we can't get 'ifconfig up' working for the device, clearly NM won't work either... Dan > [devices/nm-device.c:6396] nm_device_remove_pending_action(): (wlp0s4f1u1): > remove_pending_action (0): 'autoconf6' not pending (expected) > [platform/nm-linux-platform.c:1965] _log_dbg_sysctl_set_impl(): sysctl: > setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/disable_ipv6' to '1' (current > value is identical) > [platform/nm-linux-platform.c:1967] _log_dbg_sysctl_set_impl(): sysctl: > setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra' to '0' (current value > is '1') > [platform/nm-linux-platform.c:1965] _log_dbg_sysctl_set_impl(): sysctl: > setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/use_tempaddr' to '0' (current > value is identical) > [devices/nm-device.c:7024] nm_device_set_hw_addr(): (wlp0s4f1u1): no MAC > address change needed > [devices/nm-device.c:5095] nm_device_set_ip4_config(): (wlp0s4f1u1): clear > IP4Config instance (/org/freedesktop/NetworkManager/IP4Config/0) > [devices/nm-device.c:5203] nm_device_set_ip6_config(): (wlp0s4f1u1): clear > IP6Config instance (/org/freedesktop/NetworkManager/IP6Config/0) > [supplicant-manager/nm-supplicant-manager.c:90] > nm_supplicant_manager_iface_get(): (wlp0s4f1u1): creating new supplicant > interface > [supplicant-manager/nm-supplicant-interface.c:881] interface_add(): > (wlp0s4f1u1): adding interface to supplicant > [devices/nm-device.c:6342] nm_device_add_pending_action(): (wlp0s4f1u1): > add_pending_action (1): 'waiting for supplicant' > [nm-manager.c:718] check_if_startup_complete(): check_if_startup_complete > returns FALSE because of wlp0s4f1u1 > [nm-device-wifi.c:1192] is_available(): (wlp0s4f1u1): not available because > supplicant interface not ready > [devices/nm-device.c:6705] _set_state_full(): (wlp0s4f1u1): device not yet > available for transition to DISCONNECTED > [nm-manager.c:718] check_if_startup_complete(): check_if_startup_complete > returns FALSE because of wlp0s4f1u1 > [devices/nm-device.c:6342] nm_device_add_pending_action(): (wlp0s4f1u1): > add_pending_action (2): 'autoactivate' > [devices/nm-device.c:6376] nm_device_remove_pending_action(): (wlp0s4f1u1): > remove_pending_action (1): 'autoactivate' > [nm-manager.c:718] check_if_startup_complete(): check_if_startup_complete > returns FALSE because of wlp0s4f1u1 > [supplicant-manager/nm-supplicant-interface.c:856] interface_add_cb(): > (wlp0s4f1u1): error adding interface: wpa_supplicant couldn't grab this > interface. > (wlp0s4f1u1): supplicant interface state: starting -> down > [devices/nm-device.c:6376] nm_device_remove_pending_action(): (wlp0s4f1u1): > remove_pending_action (0): 'waiting for supplicant' > [supplicant-manager/nm-supplicant-manager.c:90] > nm_supplicant_manager_iface_get(): (wlp0s4f1u1): creating new supplicant > interface > [supplicant-manager/nm-supplicant-interface.c:881] interface_add(): > (wlp0s4f1u1): adding interface to supplicant > [devices/nm-device.c:6342] nm_device_add_pending_action(): (wlp0s4f1u1): > add_pending_action (1): 'waiting for supplicant' > [supplicant-manager/nm-supplicant-manager.c:182] get_capabilities_cb(): AP > mode is supported > [supplicant-manager/nm-supplicant-manager.c:194] get_capabilities_cb(): > EAP-FAST is supported > [supplicant-manager/nm-supplicant-interface.c:856] interface_add_cb(): > (wlp0s4f1u1): error adding interface: wpa_supplicant couldn't grab this > interface. > etc. etc.. etc... > > > - nmcli device > DEVICE TYPE STATECONNECTION > wlp0s4f1u1 wifi unavailable -- > > > poma > > -- > 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 -- 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: how can we fast roaming between multi-aps
On Sat, 2014-09-27 at 16:18 +0800, jammy wrote: > Hi DAN， > 1，Are all the SSIDs the same? > A：yes，SSIDs are same. > 2，What kind of authentication? WPA Enterprise/802.1x? What EAP methods? > A：there are no authentication，and no EAP methods > 3，Is pre-authentication enabled on the network and in the client? > A：how to enable pre-authentication？My linux kernel is build by OpenWRT. > 4，Is background scanning enabled in wpa_supplicant, and if so what is the > interval? > A：How to enable the background scanning in wpa_supplicant？ Given your answers, I think the problem is that background scanning is not enabled in the supplicant. The reason it's necessary for better roaming is that when the signal from your current AP becomes weak, the supplicant needs to know what AP to roam *to*. It cannot do that unless it has an up-to-date picture of the network, and what other APs it can see. Background scanning will initiate a scan when the current signal drops below a certain threshold, so that when the current AP becomes unusable, the supplicant can immediately switch to a better AP without delay. If background scanning is not enabled, when the current AP goes out of range the supplicant has to run a scan *after* it has disconnected, which can take a few seconds. That is likely the source of your issue. In the supplicant configuration file, in the network block for your SSID, put something like: bgscan="simple:30:-45:300" Dan -- 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] mac80211: minstrel_ht: add basic support for VHT rates <= 80MHz@NSS2
On 2014-09-29 15:58, Karl Beldan wrote:
> You mean having a common hardcoded value for both ?
Yes. And at the same time also getting rid of #if tests for it.
> After 4441e8e9 the minstrel rate indexes have to be u8-s and having this
> common param > 2 would require something like:
>
> {{{
> diff --git a/net/mac80211/rc80211_minstrel_ht.c
> b/net/mac80211/rc80211_minstrel_ht.c
> index 41522c7..c3d9136 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -346,8 +364,8 @@ minstrel_ht_calc_tp(struct minstrel_ht_sta *mi, int
> group, int rate)
> * MCS groups, CCK rates do not provide aggregation and are therefore at
> last.
> */
> static void
> -minstrel_ht_sort_best_tp_rates(struct minstrel_ht_sta *mi, u8 index,
> - u8 *tp_list)
> +minstrel_ht_sort_best_tp_rates(struct minstrel_ht_sta *mi, u16 index,
> + u16 *tp_list)
> {
> int cur_group, cur_idx, cur_thr, cur_prob;
> int tmp_group, tmp_idx, tmp_thr, tmp_prob;
> @@ -384,7 +402,7 @@ minstrel_ht_sort_best_tp_rates(struct minstrel_ht_sta
> *mi, u8 index,
> * Find and set the topmost probability rate per sta and per group
> */
> static void
> -minstrel_ht_set_best_prob_rate(struct minstrel_ht_sta *mi, u8 index)
> +minstrel_ht_set_best_prob_rate(struct minstrel_ht_sta *mi, u16 index)
> {
> struct minstrel_mcs_group_data *mg;
> struct minstrel_rate_stats *mr;
> @@ -427,8 +445,8 @@ minstrel_ht_set_best_prob_rate(struct minstrel_ht_sta
> *mi, u8 index)
> */
> static void
> minstrel_ht_assign_best_tp_rates(struct minstrel_ht_sta *mi,
> -u8 tmp_mcs_tp_rate[MAX_THR_RATES],
> -u8 tmp_cck_tp_rate[MAX_THR_RATES])
> +u16 tmp_mcs_tp_rate[MAX_THR_RATES],
> +u16 tmp_cck_tp_rate[MAX_THR_RATES])
> {
> unsigned int tmp_group, tmp_idx, tmp_cck_tp, tmp_mcs_tp;
> int i;
> @@ -492,8 +510,8 @@ minstrel_ht_update_stats(struct minstrel_priv *mp, struct
> minstrel_ht_sta *mi)
> struct minstrel_mcs_group_data *mg;
> struct minstrel_rate_stats *mr;
> int group, i, j;
> - u8 tmp_mcs_tp_rate[MAX_THR_RATES], tmp_group_tp_rate[MAX_THR_RATES];
> - u8 tmp_cck_tp_rate[MAX_THR_RATES], index;
> + u16 tmp_mcs_tp_rate[MAX_THR_RATES], tmp_group_tp_rate[MAX_THR_RATES];
> + u16 tmp_cck_tp_rate[MAX_THR_RATES], index;
>
> if (mi->ampdu_packets > 0) {
> mi->avg_ampdu_len = minstrel_ewma(mi->avg_ampdu_len,
> diff --git a/net/mac80211/rc80211_minstrel_ht.h
> b/net/mac80211/rc80211_minstrel_ht.h
> index 7856062..354e076 100644
> --- a/net/mac80211/rc80211_minstrel_ht.h
> +++ b/net/mac80211/rc80211_minstrel_ht.h
> @@ -57,8 +57,8 @@ struct minstrel_mcs_group_data {
> u16 supported;
>
> /* sorted rate set within a MCS group*/
> - u8 max_group_tp_rate[MAX_THR_RATES];
> - u8 max_group_prob_rate;
> + u16 max_group_tp_rate[MAX_THR_RATES];
> + u16 max_group_prob_rate;
>
> /* MCS rate statistics */
> struct minstrel_rate_stats rates[MCS_GROUP_RATES];
> @@ -75,8 +75,8 @@ struct minstrel_ht_sta {
> unsigned int avg_ampdu_len;
>
> /* overall sorted rate set */
> - u8 max_tp_rate[MAX_THR_RATES];
> - u8 max_prob_rate;
> + u16 max_tp_rate[MAX_THR_RATES];
> + u16 max_prob_rate;
>
> /* time of last status update */
> unsigned long stats_update;
> }}}
>
> With this I could not advertise the patch overhead-less when not setting
> MAC80211_RC_MINSTREL_VHT, too invasive for a simple step to feel the
> limits of the present implementation and a way to test vht tx path.
>
> But maybe that's not what you had in mind for MINSTREL_*_MAX_STREAMS ?
I think the overhead of this is insignificant enough to justify getting
rid of some #if spaghetti. It should probably be posted as a separate
patch though, to simplify review.
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ath9k_hw: fix PLL clock initialization for newer SoC
On AR934x and newer SoC devices, the layout of the AR_RTC_PLL_CONTROL
register changed. This currently breaks at least 5/10 MHz operation.
AR933x uses the old layout.
It might also have been causing other stability issues because of the
different location of the PLL_BYPASS bit which needs to be set during
PLL clock initialization.
This patch also removes more instances of hardcoded register values in
favor of properly computed ones with the PLL_BYPASS bit added.
Reported-by: Lorenzo Bianconi
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 24 +++-
drivers/net/wireless/ath/ath9k/hw.c | 9 ++---
drivers/net/wireless/ath/ath9k/reg.h| 11 +++
3 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 542a8d5..697c4ae 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -517,6 +517,23 @@ static void ar9003_hw_spur_mitigate(struct ath_hw *ah,
ar9003_hw_spur_mitigate_ofdm(ah, chan);
}
+static u32 ar9003_hw_compute_pll_control_soc(struct ath_hw *ah,
+struct ath9k_channel *chan)
+{
+ u32 pll;
+
+ pll = SM(0x5, AR_RTC_9300_SOC_PLL_REFDIV);
+
+ if (chan && IS_CHAN_HALF_RATE(chan))
+ pll |= SM(0x1, AR_RTC_9300_SOC_PLL_CLKSEL);
+ else if (chan && IS_CHAN_QUARTER_RATE(chan))
+ pll |= SM(0x2, AR_RTC_9300_SOC_PLL_CLKSEL);
+
+ pll |= SM(0x2c, AR_RTC_9300_SOC_PLL_DIV_INT);
+
+ return pll;
+}
+
static u32 ar9003_hw_compute_pll_control(struct ath_hw *ah,
struct ath9k_channel *chan)
{
@@ -1781,7 +1798,12 @@ void ar9003_hw_attach_phy_ops(struct ath_hw *ah)
priv_ops->rf_set_freq = ar9003_hw_set_channel;
priv_ops->spur_mitigate_freq = ar9003_hw_spur_mitigate;
- priv_ops->compute_pll_control = ar9003_hw_compute_pll_control;
+
+ if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah))
+ priv_ops->compute_pll_control =
ar9003_hw_compute_pll_control_soc;
+ else
+ priv_ops->compute_pll_control = ar9003_hw_compute_pll_control;
+
priv_ops->set_channel_regs = ar9003_hw_set_channel_regs;
priv_ops->init_bb = ar9003_hw_init_bb;
priv_ops->process_ini = ar9003_hw_process_ini;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 3aed729..f03e283 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -704,6 +704,8 @@ static void ath9k_hw_init_pll(struct ath_hw *ah,
{
u32 pll;
+ pll = ath9k_hw_compute_pll_control(ah, chan);
+
if (AR_SREV_9485(ah) || AR_SREV_9565(ah)) {
/* program BB PLL ki and kd value, ki=0x4, kd=0x40 */
REG_RMW_FIELD(ah, AR_CH0_BB_DPLL2,
@@ -754,7 +756,8 @@ static void ath9k_hw_init_pll(struct ath_hw *ah,
REG_RMW_FIELD(ah, AR_CH0_DDR_DPLL3,
AR_CH0_DPLL3_PHASE_SHIFT, 0x1);
- REG_WRITE(ah, AR_RTC_PLL_CONTROL, 0x1142c);
+ REG_WRITE(ah, AR_RTC_PLL_CONTROL,
+ pll | AR_RTC_9300_PLL_BYPASS);
udelay(1000);
/* program refdiv, nint, frac to RTC register */
@@ -770,7 +773,8 @@ static void ath9k_hw_init_pll(struct ath_hw *ah,
} else if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah)) {
u32 regval, pll2_divint, pll2_divfrac, refdiv;
- REG_WRITE(ah, AR_RTC_PLL_CONTROL, 0x1142c);
+ REG_WRITE(ah, AR_RTC_PLL_CONTROL,
+ pll | AR_RTC_9300_SOC_PLL_BYPASS);
udelay(1000);
REG_SET_BIT(ah, AR_PHY_PLL_MODE, 0x1 << 16);
@@ -843,7 +847,6 @@ static void ath9k_hw_init_pll(struct ath_hw *ah,
udelay(1000);
}
- pll = ath9k_hw_compute_pll_control(ah, chan);
if (AR_SREV_9565(ah))
pll |= 0x4;
REG_WRITE(ah, AR_RTC_PLL_CONTROL, pll);
diff --git a/drivers/net/wireless/ath/ath9k/reg.h
b/drivers/net/wireless/ath/ath9k/reg.h
index a149970..3747a8a 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1240,12 +1240,23 @@ enum {
#define AR_CH0_DPLL3_PHASE_SHIFT_S 23
#define AR_PHY_CCA_NOM_VAL_2GHZ -118
+#define AR_RTC_9300_SOC_PLL_DIV_INT 0x003f
+#define AR_RTC_9300_SOC_PLL_DIV_INT_S0
+#define AR_RTC_9300_SOC_PLL_DIV_FRAC 0x000fffc0
+#define AR_RTC_9300_SOC_PLL_DIV_FRAC_S 6
+#define AR_RTC_9300_SOC_PLL_REFDIV 0x01f0
+#define AR_RTC_9300_SOC_PLL_REFDIV_S 20
+#define AR_RTC_9300_SOC_PLL_CLKSEL 0x0600
+#define AR_RTC_9300_SOC_PLL_CLKSEL_S 25
+#define AR_RTC_9300_SOC_PLL_BYPASS 0x0800
[PATCH 2/3] ath9k_hw: reduce ANI spur immunity setting on HT40 extension channel
The cycpwr_thr1 value needs to be lower on the extension channel than on
the control channel, similar to how the register settings are programmed
in the initvals.
Also drop the unnecessary check for HT40 - this register can always be
written. This patch has been reported to improve HT40 stability and
throughput in some environments.
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 3b3e910..b72d0be 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -1042,9 +1042,8 @@ static bool ar5008_hw_ani_control_new(struct ath_hw *ah,
REG_RMW_FIELD(ah, AR_PHY_TIMING5,
AR_PHY_TIMING5_CYCPWR_THR1, value);
- if (IS_CHAN_HT40(ah->curchan))
- REG_RMW_FIELD(ah, AR_PHY_EXT_CCA,
- AR_PHY_EXT_TIMING5_CYCPWR_THR1, value);
+ REG_RMW_FIELD(ah, AR_PHY_EXT_CCA,
+ AR_PHY_EXT_TIMING5_CYCPWR_THR1, value - 1);
if (level != aniState->spurImmunityLevel) {
ath_dbg(common, ANI,
--
2.0.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 1/3] Revert "ath9k_hw: reduce ANI firstep range for older chips"
This reverts commit 09efc56345be4146ab9fc87a55c837ed5d6ea1ab
I've received reports that this change is decreasing throughput in some
rare conditions on an AR9280 based device
Cc: sta...@vger.kernel.org
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 00fb8ba..3b3e910 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -1004,9 +1004,11 @@ static bool ar5008_hw_ani_control_new(struct ath_hw *ah,
case ATH9K_ANI_FIRSTEP_LEVEL:{
u32 level = param;
- value = level;
+ value = level * 2;
REG_RMW_FIELD(ah, AR_PHY_FIND_SIG,
AR_PHY_FIND_SIG_FIRSTEP, value);
+ REG_RMW_FIELD(ah, AR_PHY_FIND_SIG_LOW,
+ AR_PHY_FIND_SIG_FIRSTEP_LOW, value);
if (level != aniState->firstepLevel) {
ath_dbg(common, ANI,
--
2.0.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: [PATCH v2 03/10] ath10k: support ethtool stats.
On 09/29/2014 01:21 AM, Kalle Valo wrote:
> Ben Greear writes:
>
>> On 09/24/2014 12:44 AM, Michal Kazior wrote:
>>> On 23 September 2014 23:17, wrote:
>>> [...]
+void ath10k_get_et_stats(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif,
+struct ethtool_stats *stats, u64 *data)
+{
+ struct ath10k *ar = hw->priv;
+ int i = 0;
+ struct ath10k_target_stats *fw_stats;
+
+ fw_stats = &ar->debug.target_stats;
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state == ATH10K_STATE_ON)
+ ath10k_refresh_peer_stats(ar);
+
+ mutex_unlock(&ar->conf_mutex);
>>>
>>> Just for correctness sake - it's probably a good idea to
>>> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
>>> the stats are for this particular request. With your patch there's a
>>> very slight chance that, e.g. fw_stats debug file is being read at the
>>> same time and it updates fw stats between the above mutex_unlock() and
>>> following spin_lock_bh().
>>
>> That makes no difference at all to the user though, and it is one less
>> set of nested locks to worry about.
>
> I still do not want to have known races, especially when it's so easy to
> fix. The ethtool patches patches conflict with Michal's fw_stats fixes.
> Let me take the ethtool patches so that I can rebase them, fix this race
> and do some other small changes as well. I'll send v2 soon.
Your v2 patches are fine with me.
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 v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
On 09/29/2014 01:24 AM, Kalle Valo wrote:
> gree...@candelatech.com writes:
>
>> 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
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> ret);
>>
>> if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
>> -return ret;
>> +goto out;
>>
>> ath10k_warn(ar, "trying cold reset\n");
>>
>> @@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> if (ret) {
>> ath10k_err(ar, "failed to power up target using cold
>> reset too (%d)\n",
>> ret);
>> -return ret;
>> +goto out;
>> }
>> }
>>
>> -return 0;
>> +out:
>> +/* If we have failed to power-up, it may take a reboot to
>> + * get the NIC back online.
>> + * Set flag accordinly so that user-space can know.
>> + */
>> +ar->fw_powerup_failed = !!ret;
>> +return ret;
>> }
>
> Would it be better to use ATH10K_STATE_WEDGED for this and then just
> export the state value to user space? Or should we have two different
> states, like FW_WEDGED and HW_WEDGED?
I didn't want to mess with the state machine. This counter
is just a clue to users that things might be badly wrong. Some systems
might recover with another hard reset, some will hang the entire
system hard, and some will just stick in this state unable to
recover. Some of my systems exhibit this last behaviour, so at
least with this patch I can warn the user that they need to
reboot to regain wifi functionality.
If you want to tie it to a state machine, that is OK with me, but
I don't want to mess with it because that code is already tricky
enough.
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] ath10k: request firmware flush in ath10k_flush.
On 09/29/2014 03:53 AM, Kalle Valo wrote: >> Thanks. I think ath10k should do this instead of having CT-specific >> flush eventually. > > I agree. We should not be forking functionality unless absolutely > necessary. Ok, this patch is easy to carry in my own tree. But, for things upstream firmware just cannot support, like tx-rate-status and rx-software-crypt, how do you want it flagged in the driver? Can I get the CT firmware flag in for that, or does it have to be some other way? If you just will not accept any such patch, let me know so I can quite bothering you about 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] mac80211: minstrel_ht: add basic support for VHT rates <= 80MHz@NSS2
Unless I can spare some space in rc_stats, v2 will need an increase in minstrel_debugfs_info buffer (ATM 1 line is > 100 chars). Karl -- 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: [rt2x00-users] [PATCH] MAINTAINERS: change rt2x00 maintainer
On Sun, Sep 28, 2014 at 02:30:13PM +0200, Peter Stuge wrote: > Stanislaw Gruszka wrote: > > After short chat with Ivo, we decided that I'll take maintenance > > of rt2x00 driver. > > > > Thanks for Ivo's great work in the past! > > > > Signed-off-by: Stanislaw Gruszka > > I would have been a whole lot happier to see this patch from Ivo. Ivo acked this change, but his email somehow did not get on linux-wireless mailing list: http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2014-September/006657.html Stanislaw -- 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] mac80211: minstrel_ht: add basic support for VHT rates <= 80MHz@NSS2
On Mon, Sep 29, 2014 at 01:46:15PM +0200, Felix Fietkau wrote:
> On 2014-09-29 02:38, Karl Beldan wrote:
> > diff --git a/net/mac80211/rc80211_minstrel_ht.h
> > b/net/mac80211/rc80211_minstrel_ht.h
> > index 01570e0..7856062 100644
> > --- a/net/mac80211/rc80211_minstrel_ht.h
> > +++ b/net/mac80211/rc80211_minstrel_ht.h
> > @@ -13,10 +13,33 @@
> > * The number of streams can be changed to 2 to reduce code
> > * size and memory footprint.
> > */
> > -#define MINSTREL_MAX_STREAMS 3
> > -#define MINSTREL_STREAM_GROUPS 4
> > +#ifdef CONFIG_MAC80211_RC_MINSTREL_VHT
> > +#define MINSTREL_VHT_MAX_STREAMS 2
> > +#else
> > +#define MINSTREL_VHT_MAX_STREAMS 0
> > +#endif
> > +#define MINSTREL_VHT_STREAM_GROUPS 6 /* BW(=3) * SGI(=2) */
> > +
> > +#define MINSTREL_HT_MAX_STREAMS3
> > +#define MINSTREL_HT_STREAM_GROUPS 4 /* BW(=2) * SGI(=2) */
> I think we should get rid of MINSTREL_*_MAX_STREAMS instead of expanding
> its use to VHT.
>
You mean having a common hardcoded value for both ?
After 4441e8e9 the minstrel rate indexes have to be u8-s and having this
common param > 2 would require something like:
{{{
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 41522c7..c3d9136 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -346,8 +364,8 @@ minstrel_ht_calc_tp(struct minstrel_ht_sta *mi, int group,
int rate)
* MCS groups, CCK rates do not provide aggregation and are therefore at last.
*/
static void
-minstrel_ht_sort_best_tp_rates(struct minstrel_ht_sta *mi, u8 index,
- u8 *tp_list)
+minstrel_ht_sort_best_tp_rates(struct minstrel_ht_sta *mi, u16 index,
+ u16 *tp_list)
{
int cur_group, cur_idx, cur_thr, cur_prob;
int tmp_group, tmp_idx, tmp_thr, tmp_prob;
@@ -384,7 +402,7 @@ minstrel_ht_sort_best_tp_rates(struct minstrel_ht_sta *mi,
u8 index,
* Find and set the topmost probability rate per sta and per group
*/
static void
-minstrel_ht_set_best_prob_rate(struct minstrel_ht_sta *mi, u8 index)
+minstrel_ht_set_best_prob_rate(struct minstrel_ht_sta *mi, u16 index)
{
struct minstrel_mcs_group_data *mg;
struct minstrel_rate_stats *mr;
@@ -427,8 +445,8 @@ minstrel_ht_set_best_prob_rate(struct minstrel_ht_sta *mi,
u8 index)
*/
static void
minstrel_ht_assign_best_tp_rates(struct minstrel_ht_sta *mi,
-u8 tmp_mcs_tp_rate[MAX_THR_RATES],
-u8 tmp_cck_tp_rate[MAX_THR_RATES])
+u16 tmp_mcs_tp_rate[MAX_THR_RATES],
+u16 tmp_cck_tp_rate[MAX_THR_RATES])
{
unsigned int tmp_group, tmp_idx, tmp_cck_tp, tmp_mcs_tp;
int i;
@@ -492,8 +510,8 @@ minstrel_ht_update_stats(struct minstrel_priv *mp, struct
minstrel_ht_sta *mi)
struct minstrel_mcs_group_data *mg;
struct minstrel_rate_stats *mr;
int group, i, j;
- u8 tmp_mcs_tp_rate[MAX_THR_RATES], tmp_group_tp_rate[MAX_THR_RATES];
- u8 tmp_cck_tp_rate[MAX_THR_RATES], index;
+ u16 tmp_mcs_tp_rate[MAX_THR_RATES], tmp_group_tp_rate[MAX_THR_RATES];
+ u16 tmp_cck_tp_rate[MAX_THR_RATES], index;
if (mi->ampdu_packets > 0) {
mi->avg_ampdu_len = minstrel_ewma(mi->avg_ampdu_len,
diff --git a/net/mac80211/rc80211_minstrel_ht.h
b/net/mac80211/rc80211_minstrel_ht.h
index 7856062..354e076 100644
--- a/net/mac80211/rc80211_minstrel_ht.h
+++ b/net/mac80211/rc80211_minstrel_ht.h
@@ -57,8 +57,8 @@ struct minstrel_mcs_group_data {
u16 supported;
/* sorted rate set within a MCS group*/
- u8 max_group_tp_rate[MAX_THR_RATES];
- u8 max_group_prob_rate;
+ u16 max_group_tp_rate[MAX_THR_RATES];
+ u16 max_group_prob_rate;
/* MCS rate statistics */
struct minstrel_rate_stats rates[MCS_GROUP_RATES];
@@ -75,8 +75,8 @@ struct minstrel_ht_sta {
unsigned int avg_ampdu_len;
/* overall sorted rate set */
- u8 max_tp_rate[MAX_THR_RATES];
- u8 max_prob_rate;
+ u16 max_tp_rate[MAX_THR_RATES];
+ u16 max_prob_rate;
/* time of last status update */
unsigned long stats_update;
}}}
With this I could not advertise the patch overhead-less when not setting
MAC80211_RC_MINSTREL_VHT, too invasive for a simple step to feel the
limits of the present implementation and a way to test vht tx path.
But maybe that's not what you had in mind for MINSTREL_*_MAX_STREAMS ?
Karl
--
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: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/26/14 17:20, Michael Tokarev wrote: I can send it your way, -- guess it will be quite a bit costly, but I don't have any use for it anyway (short of throwing it away), and since I already spent significantly more money due to all this (whole thinkpad plus ssds and several wifi adaptors), this additional cost is just a small noize. But since that's 2nd card in a row, maybe there's something else in there, the prob is not in the card? Could be. Maybe some BIOS issue. Can you make some hi-res pictures of the card and email them to me? If it is identical to what I already have over here there is not much sense in sending it. 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
iwlwifi: ibss on 6205 always stuck at 1 Mbps
Hi,
I get bad performance with IBSS on my 6205 devices running iwlwifi.
They seem to be stuck on 1 Mbps and through bisecting, it comes down to
this bad commit:
3ac40edadcb7799391452ffaa1745084c3e4c747
('iwlwifi: calculate active legacy rates per station')
https://github.com/torvalds/linux/commit/3ac40edadcb7799391452ffaa1745084c3e4c747
I have tested the issue on a few different settings:
iwlwifi (6205) => iwlwifi (6205): BAD
iwlwifi (6205) => ath9k_htc: BAD
iwlwifi (6205) => iwlwifi (6300): BAD
iwlwifi (6300) => iwlwifi (6205): GOOD
ath9k_htc => iwlwifi (6205): GOOD
So, as the first bad commit and the simple tests indicate, the issue is
related to the rate selection for 6205 devices.
dmesg and phy-info from an affected device is attached. Let me know if
more information is needed.
Thanks,
Martin
core@core01:~$ sudo iw wlan0 info
Interface wlan0
ifindex 3
wdev 0x1
addr a0:88:b4:bf:f4:cc
ssid core-test
type IBSS
wiphy 0
channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
core@core01:~$ sudo iw wlan0 station dump
Station 24:77:03:d7:6a:7c (on wlan0)
inactive time: 32 ms
rx bytes: 11009701
rx packets: 24719
tx bytes: 1264256
tx packets: 4032
tx retries: 501
tx failed: 0
signal: -44 dBm
signal avg: -43 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 54.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME:yes
MFP:no
TDLS peer: no
Station f8:d1:11:0c:3f:2b (on wlan0)
inactive time: 4 ms
rx bytes: 13269604
rx packets: 33953
tx bytes: 1332906
tx packets: 4831
tx retries: 765
tx failed: 0
signal: -46 dBm
signal avg: -47 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME:yes
MFP:no
TDLS peer: no
Station a0:88:b4:d8:b0:d8 (on wlan0)
inactive time: 20 ms
rx bytes: 7199547
rx packets: 86184
tx bytes: 135242
tx packets: 1573
tx retries: 323
tx failed: 0
signal: -41 dBm
signal avg: -40 dBm
tx bitrate: 54.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME:yes
MFP:no
TDLS peer: no
Station 08:11:96:06:22:48 (on wlan0)
inactive time: 76 ms
rx bytes: 3290846
rx packets: 83190
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
signal: -12 dBm
signal avg: -11 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME:yes
MFP:no
TDLS peer: no
Station a0:88:b4:dc:f1:e0 (on wlan0)
inactive time: 104 ms
rx bytes: 3092949
rx packets: 78249
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
signal: -24 dBm
signal avg: -23 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME:yes
MFP:no
TDLS peer: no
Wiphy phy0
max # scan SSIDs: 20
max scan IEs length: 195 bytes
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
Band 1:
Capabilities: 0x1072
HT20/HT40
Static SM Power Save
RX Greenfield
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT TX/RX MCS rate indexes supported: 0-15, 32
Bitrates (non-HT):
* 1.0 Mbps
Re: [PATCH] mac80211: minstrel_ht: add basic support for VHT rates <= 80MHz@NSS2
On 2014-09-29 02:38, Karl Beldan wrote: > From: Karl Beldan > > When the new CONFIG_MAC80211_RC_MINSTREL_VHT is not set, there is no > behavioral change including in sampling and MCS_GROUP_RATES remains 8. > When it is, MCS_GROUP_RATES is 10 and we restrict to VHT rates for stats > readability (though it is possible to use both HT and VHT (unset > vht_only)). > --- > net/mac80211/Kconfig | 7 + > net/mac80211/rc80211_minstrel_ht.c | 263 > +++-- > net/mac80211/rc80211_minstrel_ht.h | 33 +++- > net/mac80211/rc80211_minstrel_ht_debugfs.c | 30 ++-- > 4 files changed, 261 insertions(+), 72 deletions(-) > > diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig > index aeb6a48..39095a9 100644 > --- a/net/mac80211/Kconfig > +++ b/net/mac80211/Kconfig > @@ -33,6 +33,13 @@ config MAC80211_RC_MINSTREL_HT > ---help--- > This option enables the 'minstrel_ht' TX rate control algorithm > > +config MAC80211_RC_MINSTREL_VHT > + bool "Minstrel 802.11vht support" if EXPERT This should be VHT or 802.11ac instead of 802.11vht > + depends on MAC80211_RC_MINSTREL_HT > + default n > + ---help--- > + This option enables vht in the 'minstrel_ht' TX rate control algorithm > + > choice > prompt "Default rate control algorithm" > depends on MAC80211_HAS_RC > diff --git a/net/mac80211/rc80211_minstrel_ht.h > b/net/mac80211/rc80211_minstrel_ht.h > index 01570e0..7856062 100644 > --- a/net/mac80211/rc80211_minstrel_ht.h > +++ b/net/mac80211/rc80211_minstrel_ht.h > @@ -13,10 +13,33 @@ > * The number of streams can be changed to 2 to reduce code > * size and memory footprint. > */ > -#define MINSTREL_MAX_STREAMS 3 > -#define MINSTREL_STREAM_GROUPS 4 > +#ifdef CONFIG_MAC80211_RC_MINSTREL_VHT > +#define MINSTREL_VHT_MAX_STREAMS 2 > +#else > +#define MINSTREL_VHT_MAX_STREAMS 0 > +#endif > +#define MINSTREL_VHT_STREAM_GROUPS 6 /* BW(=3) * SGI(=2) */ > + > +#define MINSTREL_HT_MAX_STREAMS 3 > +#define MINSTREL_HT_STREAM_GROUPS4 /* BW(=2) * SGI(=2) */ I think we should get rid of MINSTREL_*_MAX_STREAMS instead of expanding its use to VHT. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ath10k: fix/cleanup fw stats
Michal Kazior writes: > This cleans up and fixes fw stats aggregation. > > > Michal Kazior (4): > ath10k: split wmi stats parsing > ath10k: rename fw_stats related stuff > ath10k: request fw_stats once on open > ath10k: fix fw stats processing Thanks, applied. And thank you for fixing this for good, it has been buggy for way too long. -- 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] ath: change logging functions to return void
Joe Perches writes: > The return values are not used by callers of these functions > so change the functions to return void. > > Other miscellanea: > > o add __printf verification to wil6210 logging functions > No format/argument mismatches found > > Signed-off-by: Joe Perches Thanks, applied. -- 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] ath10k: request firmware flush in ath10k_flush.
Michal Kazior writes: > On 23 September 2014 16:19, Ben Greear wrote: >> On 09/23/2014 02:16 AM, Michal Kazior wrote: >>> On 19 September 2014 20:28, wrote: >>> [...] + /* If we are CT firmware, ask it to flush all tids on all peers on +* all vdevs. Normal firmware will just crash if you do this. +*/ + if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT, ar->fw_features)) + ath10k_wmi_peer_flush(ar, 0x, peer_addr, 0x); >>> >>> I recall you've explained this some time ago, but can you refresh my >>> memory, please? Is this any different from iterating over all peers >>> and flushing each? Or does your firmware do so extra magic that is >>> impossible to do with normal firmware commands? >> >> My firmware does that iteration internally. >> >> You could probably do that in the driver, but it would be a lot >> of messages (for all vdevs, all peers, all tids)... >> I was not sure if there were limits to the number >> of commands you should attempt during the flush... > > Thanks. I think ath10k should do this instead of having CT-specific > flush eventually. I agree. We should not be forking functionality unless absolutely necessary. -- 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
[PATCHv1 RESEND 1/3] mwifiex: fix soft lockup during iperf UDP RX
A soft lockup was observed on ARM multicore platform while UDP
RX iperf was running on station.
Reason for this is delay_main_task was not taken into consideration while
jumping to process_start. Now if delay_main_task is true, we would exit
mwifiex_main_process instead of going to process_start again.
This ensure other process is scheduled on this CPU and soft lockup is avoided.
Signed-off-by: Amitkumar Karwar
Signed-off-by: Kevin Gan
Signed-off-by: Marc Yang
Signed-off-by: Avinash Patil
Signed-off-by: Cathy Luo
---
drivers/net/wireless/mwifiex/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mwifiex/main.c
b/drivers/net/wireless/mwifiex/main.c
index b522f7c..be52189 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -330,7 +330,8 @@ process_start:
} while (true);
spin_lock_irqsave(&adapter->main_proc_lock, flags);
- if ((adapter->int_status) || IS_CARD_RX_RCVD(adapter)) {
+ if (!adapter->delay_main_work &&
+ (adapter->int_status || IS_CARD_RX_RCVD(adapter))) {
spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
goto process_start;
}
--
1.8.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
[PATCHv1 RESEND 3/3] mwifiex: remove unnecessary rx_q lock
SKB lists have their own lock. So this lock is not needed.
Signed-off-by: Avinash Patil
---
drivers/net/wireless/mwifiex/init.c | 1 -
drivers/net/wireless/mwifiex/main.h | 2 --
drivers/net/wireless/mwifiex/pcie.c | 4
drivers/net/wireless/mwifiex/sdio.c | 3 ---
4 files changed, 10 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/init.c
b/drivers/net/wireless/mwifiex/init.c
index f7c97cf..580aa45 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -447,7 +447,6 @@ int mwifiex_init_lock_list(struct mwifiex_adapter *adapter)
spin_lock_init(&adapter->cmd_free_q_lock);
spin_lock_init(&adapter->cmd_pending_q_lock);
spin_lock_init(&adapter->scan_pending_q_lock);
- spin_lock_init(&adapter->rx_q_lock);
spin_lock_init(&adapter->rx_proc_lock);
skb_queue_head_init(&adapter->usb_rx_data_q);
diff --git a/drivers/net/wireless/mwifiex/main.h
b/drivers/net/wireless/mwifiex/main.h
index 022486e..e263574 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -764,8 +764,6 @@ struct mwifiex_adapter {
struct list_head scan_pending_q;
/* spin lock for scan_pending_q */
spinlock_t scan_pending_q_lock;
- /* spin lock for RX queue */
- spinlock_t rx_q_lock;
/* spin lock for RX processing routine */
spinlock_t rx_proc_lock;
struct sk_buff_head usb_rx_data_q;
diff --git a/drivers/net/wireless/mwifiex/pcie.c
b/drivers/net/wireless/mwifiex/pcie.c
index 74c0db9..c3a20f9 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -1237,7 +1237,6 @@ static int mwifiex_pcie_process_recv_data(struct
mwifiex_adapter *adapter)
struct sk_buff *skb_tmp = NULL;
struct mwifiex_pcie_buf_desc *desc;
struct mwifiex_pfu_buf_desc *desc2;
- unsigned long flags;
if (!mwifiex_pcie_ok_to_access_hw(adapter))
mwifiex_pm_wakeup_card(adapter);
@@ -1289,10 +1288,7 @@ static int mwifiex_pcie_process_recv_data(struct
mwifiex_adapter *adapter)
card->rxbd_rdptr, wrptr, rx_len);
skb_pull(skb_data, INTF_HEADER_LEN);
if (adapter->rx_work_enabled) {
- spin_lock_irqsave(&adapter->rx_q_lock, flags);
skb_queue_tail(&adapter->rx_data_q, skb_data);
- spin_unlock_irqrestore(&adapter->rx_q_lock,
- flags);
adapter->data_received = true;
atomic_inc(&adapter->rx_pending);
} else {
diff --git a/drivers/net/wireless/mwifiex/sdio.c
b/drivers/net/wireless/mwifiex/sdio.c
index ea8fc58..db9e4e3 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1039,7 +1039,6 @@ static int mwifiex_decode_rx_packet(struct
mwifiex_adapter *adapter,
struct sk_buff *skb, u32 upld_typ)
{
u8 *cmd_buf;
- unsigned long flags;
__le16 *curr_ptr = (__le16 *)skb->data;
u16 pkt_len = le16_to_cpu(*curr_ptr);
@@ -1050,9 +1049,7 @@ static int mwifiex_decode_rx_packet(struct
mwifiex_adapter *adapter,
case MWIFIEX_TYPE_DATA:
dev_dbg(adapter->dev, "info: --- Rx: Data packet ---\n");
if (adapter->rx_work_enabled) {
- spin_lock_irqsave(&adapter->rx_q_lock, flags);
skb_queue_tail(&adapter->rx_data_q, skb);
- spin_unlock_irqrestore(&adapter->rx_q_lock, flags);
adapter->data_received = true;
atomic_inc(&adapter->rx_pending);
} else {
--
1.8.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
[PATCHv1 RESEND 2/3] mwifiex: do not decrement rx_pending count twice
This patch fixes an issue with rx processing function where we were
decrementing rx_pending count twice.
Patch also queues correct main_work item when rx_pending count reaches
low watermark.
Signed-off-by: Avinash Patil
Signed-off-by: Cathy Luo
---
drivers/net/wireless/mwifiex/main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/main.c
b/drivers/net/wireless/mwifiex/main.c
index be52189..d5070c4 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -130,7 +130,6 @@ static int mwifiex_process_rx(struct mwifiex_adapter
*adapter)
{
unsigned long flags;
struct sk_buff *skb;
- bool delay_main_work = adapter->delay_main_work;
spin_lock_irqsave(&adapter->rx_proc_lock, flags);
if (adapter->rx_processing || adapter->rx_locked) {
@@ -145,10 +144,9 @@ static int mwifiex_process_rx(struct mwifiex_adapter
*adapter)
while ((skb = skb_dequeue(&adapter->rx_data_q))) {
atomic_dec(&adapter->rx_pending);
if (adapter->delay_main_work &&
- (atomic_dec_return(&adapter->rx_pending) <
-LOW_RX_PENDING)) {
+ (atomic_read(&adapter->rx_pending) < LOW_RX_PENDING)) {
adapter->delay_main_work = false;
- queue_work(adapter->rx_workqueue, &adapter->rx_work);
+ queue_work(adapter->workqueue, &adapter->main_work);
}
mwifiex_handle_rx_packet(adapter, skb);
}
@@ -156,8 +154,6 @@ static int mwifiex_process_rx(struct mwifiex_adapter
*adapter)
adapter->rx_processing = false;
spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
- if (delay_main_work)
- queue_work(adapter->workqueue, &adapter->main_work);
exit_rx_proc:
return 0;
}
--
1.8.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: [PATCH 3/3] mwifiex: remove unnecessary rx_q lock
Hi John,
Yes; I have sent 2/3 as well; maybe there was some issue. I will resend V1.
Thanks,
Avinash.
From: John W. Linville [linvi...@tuxdriver.com]
Sent: Friday, September 26, 2014 11:02 PM
To: Avinash Patil
Cc: linux-wireless@vger.kernel.org; Amitkumar Karwar; Xinming Hu; Marc Yang;
Cathy Luo; Maithili Hinge
Subject: Re: [PATCH 3/3] mwifiex: remove unnecessary rx_q lock
I only got 1/3 and 3/3 -- was there a 2/3 posted?
On Thu, Sep 25, 2014 at 05:16:42PM +0530, Avinash Patil wrote:
> SKB lists have their own lock. So this lock is not needed.
>
> Signed-off-by: Avinash Patil
> ---
> drivers/net/wireless/mwifiex/init.c | 1 -
> drivers/net/wireless/mwifiex/main.h | 2 --
> drivers/net/wireless/mwifiex/pcie.c | 4
> drivers/net/wireless/mwifiex/sdio.c | 3 ---
> 4 files changed, 10 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/init.c
> b/drivers/net/wireless/mwifiex/init.c
> index f7c97cf..580aa45 100644
> --- a/drivers/net/wireless/mwifiex/init.c
> +++ b/drivers/net/wireless/mwifiex/init.c
> @@ -447,7 +447,6 @@ int mwifiex_init_lock_list(struct mwifiex_adapter
> *adapter)
> spin_lock_init(&adapter->cmd_free_q_lock);
> spin_lock_init(&adapter->cmd_pending_q_lock);
> spin_lock_init(&adapter->scan_pending_q_lock);
> - spin_lock_init(&adapter->rx_q_lock);
> spin_lock_init(&adapter->rx_proc_lock);
>
> skb_queue_head_init(&adapter->usb_rx_data_q);
> diff --git a/drivers/net/wireless/mwifiex/main.h
> b/drivers/net/wireless/mwifiex/main.h
> index 1a9..b5dc78b 100644
> --- a/drivers/net/wireless/mwifiex/main.h
> +++ b/drivers/net/wireless/mwifiex/main.h
> @@ -763,8 +763,6 @@ struct mwifiex_adapter {
> struct list_head scan_pending_q;
> /* spin lock for scan_pending_q */
> spinlock_t scan_pending_q_lock;
> - /* spin lock for RX queue */
> - spinlock_t rx_q_lock;
> /* spin lock for RX processing routine */
> spinlock_t rx_proc_lock;
> struct sk_buff_head usb_rx_data_q;
> diff --git a/drivers/net/wireless/mwifiex/pcie.c
> b/drivers/net/wireless/mwifiex/pcie.c
> index 1504b16..7e8d9b0 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -1233,7 +1233,6 @@ static int mwifiex_pcie_process_recv_data(struct
> mwifiex_adapter *adapter)
> struct sk_buff *skb_tmp = NULL;
> struct mwifiex_pcie_buf_desc *desc;
> struct mwifiex_pfu_buf_desc *desc2;
> - unsigned long flags;
>
> if (!mwifiex_pcie_ok_to_access_hw(adapter))
> mwifiex_pm_wakeup_card(adapter);
> @@ -1285,10 +1284,7 @@ static int mwifiex_pcie_process_recv_data(struct
> mwifiex_adapter *adapter)
> card->rxbd_rdptr, wrptr, rx_len);
> skb_pull(skb_data, INTF_HEADER_LEN);
> if (adapter->rx_work_enabled) {
> - spin_lock_irqsave(&adapter->rx_q_lock, flags);
> skb_queue_tail(&adapter->rx_data_q, skb_data);
> - spin_unlock_irqrestore(&adapter->rx_q_lock,
> -flags);
> adapter->data_received = true;
> atomic_inc(&adapter->rx_pending);
> } else {
> diff --git a/drivers/net/wireless/mwifiex/sdio.c
> b/drivers/net/wireless/mwifiex/sdio.c
> index ea8fc58..db9e4e3 100644
> --- a/drivers/net/wireless/mwifiex/sdio.c
> +++ b/drivers/net/wireless/mwifiex/sdio.c
> @@ -1039,7 +1039,6 @@ static int mwifiex_decode_rx_packet(struct
> mwifiex_adapter *adapter,
> struct sk_buff *skb, u32 upld_typ)
> {
> u8 *cmd_buf;
> - unsigned long flags;
> __le16 *curr_ptr = (__le16 *)skb->data;
> u16 pkt_len = le16_to_cpu(*curr_ptr);
>
> @@ -1050,9 +1049,7 @@ static int mwifiex_decode_rx_packet(struct
> mwifiex_adapter *adapter,
> case MWIFIEX_TYPE_DATA:
> dev_dbg(adapter->dev, "info: --- Rx: Data packet ---\n");
> if (adapter->rx_work_enabled) {
> - spin_lock_irqsave(&adapter->rx_q_lock, flags);
> skb_queue_tail(&adapter->rx_data_q, skb);
> - spin_unlock_irqrestore(&adapter->rx_q_lock, flags);
> adapter->data_received = true;
> atomic_inc(&adapter->rx_pending);
> } else {
> --
> 1.8.1.4
>
>
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
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/2] ath10k: add firmware crash counters
Kalle Valo writes: > From: Ben Greear > > kvalo: split into it's own patch, add debugfs file and add locking > > Signed-off-by: Ben Greear > Signed-off-by: Kalle Valo Oh, I forgot to add a commit log. I'm planning to add something like this: -- Add three counters related to firmware crashes or resets. Usage: # cat /sys/kernel/debug/ieee80211/phy0/ath10k/fw_reset_stats fw_crash_counter2 fw_warm_reset_counter 43 fw_cold_reset_counter 0 # -- Also I forgot to add the cover letter, here's the changelog for both patches: v2: * remove unneeded ifdef from debug.c * rebase on top of Michal's "ath10k: fix fw stats processing", dropping patch "ath10k: add helper method to grab debug stats" because it was not needed anymore * remove ifdef from ath10k_ops with "#define foo NULL" hack * hold mutex when reading pdev_stats in ath10k_debug_get_et_stats() * move fw reset stats to struct ath10k::stats and add locking * add fw_reset_stats debugfs file -- 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
[PATCH v2 1/2] ath10k: add firmware crash counters
From: Ben Greear
kvalo: split into it's own patch, add debugfs file and add locking
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.h |7 +
drivers/net/wireless/ath/ath10k/debug.c | 44 +++
drivers/net/wireless/ath/ath10k/pci.c | 14 ++
3 files changed, 65 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 674e38c219e6..5a1dc98375e1 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -563,6 +563,13 @@ struct ath10k {
bool utf_monitor;
} testmode;
+ struct {
+ /* protected by data_lock */
+ u32 fw_crash_counter;
+ u32 fw_warm_reset_counter;
+ u32 fw_cold_reset_counter;
+ } stats;
+
/* must be last */
u8 drv_priv[0] __aligned(sizeof(void *));
};
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 680d5088b6f3..8d3db1c3f4a8 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -625,6 +625,47 @@ static const struct file_operations fops_fw_stats = {
.llseek = default_llseek,
};
+static ssize_t ath10k_debug_fw_reset_stats_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ int ret, len, buf_len;
+ char *buf;
+
+ buf_len = 500;
+ buf = kmalloc(buf_len, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ spin_lock_bh(&ar->data_lock);
+
+ len = 0;
+ len += scnprintf(buf + len, buf_len - len,
+"fw_crash_counter\t\t%d\n",
ar->stats.fw_crash_counter);
+ len += scnprintf(buf + len, buf_len - len,
+"fw_warm_reset_counter\t\t%d\n",
+ar->stats.fw_warm_reset_counter);
+ len += scnprintf(buf + len, buf_len - len,
+"fw_cold_reset_counter\t\t%d\n",
+ar->stats.fw_cold_reset_counter);
+
+ spin_unlock_bh(&ar->data_lock);
+
+ ret = simple_read_from_buffer(user_buf, count, ppos, buf, len);
+
+ kfree(buf);
+
+ return ret;
+}
+
+static const struct file_operations fops_fw_reset_stats = {
+ .open = simple_open,
+ .read = ath10k_debug_fw_reset_stats_read,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
/* This is a clean assert crash in firmware. */
static int ath10k_debug_fw_assert(struct ath10k *ar)
{
@@ -1331,6 +1372,9 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("fw_stats", S_IRUSR, ar->debug.debugfs_phy, ar,
&fops_fw_stats);
+ debugfs_create_file("fw_reset_stats", S_IRUSR, ar->debug.debugfs_phy,
+ ar, &fops_fw_reset_stats);
+
debugfs_create_file("wmi_services", S_IRUSR, ar->debug.debugfs_phy, ar,
&fops_wmi_services);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index ae961c6ff74e..8a04904cccee 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1006,6 +1006,8 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
spin_lock_bh(&ar->data_lock);
+ ar->stats.fw_crash_counter++;
+
crash_data = ath10k_debug_get_new_fw_crash_data(ar);
if (crash_data)
@@ -1692,6 +1694,12 @@ static int ath10k_pci_warm_reset(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot warm reset\n");
+ spin_lock_bh(&ar->data_lock);
+
+ ar->stats.fw_warm_reset_counter++;
+
+ spin_unlock_bh(&ar->data_lock);
+
/* debug */
val = ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS +
PCIE_INTR_CAUSE_ADDRESS);
@@ -2308,6 +2316,12 @@ static int ath10k_pci_cold_reset(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot cold reset\n");
+ spin_lock_bh(&ar->data_lock);
+
+ ar->stats.fw_cold_reset_counter++;
+
+ spin_unlock_bh(&ar->data_lock);
+
/* Put Target, including PCIe, into RESET. */
val = ath10k_pci_reg_read32(ar, SOC_GLOBAL_RESET_ADDRESS);
val |= 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ath10k: support ethtool stats
From: Ben Greear
Add support for reading firmware stats through the ethtool
API. This may be easier for applications to manipulate
compared to parsing a text based debugfs file.
kvalo: remove unneeded ifdefs, call ath10k_debug_fw_stats_request() and added
simple error handling
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/debug.c | 160 +++
drivers/net/wireless/ath/ath10k/debug.h | 13 +++
drivers/net/wireless/ath/ath10k/mac.c |3 +
3 files changed, 176 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 8d3db1c3f4a8..2bb894f31337 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1130,6 +1130,166 @@ exit:
return ret;
}
+/* TODO: Would be nice to always support ethtool stats, would need to
+ * move the stats storage out of ath10k_debug, or always have ath10k_debug
+ * struct available..
+ */
+
+/* This generally cooresponds to the debugfs fw_stats file */
+static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "tx_pkts_nic",
+ "tx_bytes_nic",
+ "rx_pkts_nic",
+ "rx_bytes_nic",
+ "d_noise_floor",
+ "d_cycle_count",
+ "d_phy_error",
+ "d_rts_bad",
+ "d_rts_good",
+ "d_tx_power", /* in .5 dbM I think */
+ "d_rx_crc_err", /* fcs_bad */
+ "d_no_beacon",
+ "d_tx_mpdus_queued",
+ "d_tx_msdu_queued",
+ "d_tx_msdu_dropped",
+ "d_local_enqued",
+ "d_local_freed",
+ "d_tx_ppdu_hw_queued",
+ "d_tx_ppdu_reaped",
+ "d_tx_fifo_underrun",
+ "d_tx_ppdu_abort",
+ "d_tx_mpdu_requed",
+ "d_tx_excessive_retries",
+ "d_tx_hw_rate",
+ "d_tx_dropped_sw_retries",
+ "d_tx_illegal_rate",
+ "d_tx_continuous_xretries",
+ "d_tx_timeout",
+ "d_tx_mpdu_txop_limit",
+ "d_pdev_resets",
+ "d_rx_mid_ppdu_route_change",
+ "d_rx_status",
+ "d_rx_extra_frags_ring0",
+ "d_rx_extra_frags_ring1",
+ "d_rx_extra_frags_ring2",
+ "d_rx_extra_frags_ring3",
+ "d_rx_msdu_htt",
+ "d_rx_mpdu_htt",
+ "d_rx_msdu_stack",
+ "d_rx_mpdu_stack",
+ "d_rx_phy_err",
+ "d_rx_phy_err_drops",
+ "d_rx_mpdu_errors", /* FCS, MIC, ENC */
+ "d_fw_crash_count",
+ "d_fw_warm_reset_count",
+ "d_fw_cold_reset_count",
+};
+
+#define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
+
+void ath10k_debug_get_et_strings(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif,
+u32 sset, u8 *data)
+{
+ if (sset == ETH_SS_STATS)
+ memcpy(data, *ath10k_gstrings_stats,
+ sizeof(ath10k_gstrings_stats));
+}
+
+int ath10k_debug_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset)
+{
+ if (sset == ETH_SS_STATS)
+ return ATH10K_SSTATS_LEN;
+
+ return 0;
+}
+
+void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct ath10k *ar = hw->priv;
+ static const struct ath10k_fw_stats_pdev zero_stats = {};
+ const struct ath10k_fw_stats_pdev *pdev_stats;
+ int i = 0, ret;
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state == ATH10K_STATE_ON) {
+ ret = ath10k_debug_fw_stats_request(ar);
+ if (ret) {
+ /* just print a warning and try to use older results */
+ ath10k_warn(ar,
+ "failed to get fw stats for ethtool: %d\n",
+ ret);
+ }
+ }
+
+ pdev_stats = list_first_entry_or_null(&ar->debug.fw_stats.pdevs,
+ struct ath10k_fw_stats_pdev,
+ list);
+ if (!pdev_stats) {
+ /* no results available so just return zeroes */
+ pdev_stats = &zero_stats;
+ }
+
+ spin_lock_bh(&ar->data_lock);
+
+ data[i++] = pdev_stats->hw_reaped; /* ppdu reaped */
+ data[i++] = 0; /* tx bytes */
+ data[i++] = pdev_stats->htt_mpdus;
+ data[i++] = 0; /* rx bytes */
+ data[i++] = pdev_stats->ch_noise_floor;
+ data[i++] = pdev_stats->cycle_count;
+ data[i++] = pdev_stats->phy_err_count;
+ data[i++] = pdev_stats->rts_bad;
+ data[i++] = pdev_stats->rts_good;
+ data[i++] = pdev_stats->chan_tx_power;
+ data[i++] = pdev_stats->fcs_bad;
+ data[i++] = pdev_stats->no_beacons;
+ data[i++] = pdev_stats->mpdu_enqued;
+ data[i++] = pdev_stats->msdu_enqued;
+ data[i++] = pdev_stats->wmm_drop;
+ data[i++] = pd
RTL8188SU(rtl8192su) - unavailable
- lsusb 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter - http://wireless.kernel.org/en/users/Drivers/rtl819x#staging_drivers ... r8712u is a USB driver for RTL8712U/RTL8192SU devices, it's going to be replaced by rtl8192su. - /etc/modprobe.d/blacklist-r8712u.conf blacklist r8712u - http://wireless.kernel.org/en/users/Drivers/rtl819x#rtlwifi ... rtl8192su is a USB driver for RTL8712U/RTL8192SU devices. (WIP : http://github.com/chunkeey/rtl8192su ) - modulecomb mac80211 - - rtl_usb - \ / \ - rtlwifi - - rtl8192su / \ / cfg80211 - - rtl8192s-common - ls /usr/lib/modules/3.17.0-0.rc6.git2.1.fc22.x86_64/updates rtl8192s-common.ko rtl8192su.ko rtl_usb.ko rtlwifi.ko - file /usr/lib/firmware/rtlwifi/rtl8192sufw.bin /usr/lib/firmware/rtlwifi/rtl8192sufw.bin: symbolic link to `rtl8712u.bin' - dmesg rtlwifi: module verification failed: signature and/or required key missing - tainting kernel rtl8192s_common: Chip version 0x3 rtl_usb: rx_max_size 9100, rx_urb_num 8, in_ep 3 rtl8192su: Power Save off (module option) rtl8192su: FW Power Save off (module option) rtl8192su: Driver for Realtek RTL8192SU/RTL8191SU Loading firmware rtlwifi/rtl8192sufw.bin usbcore: registered new interface driver rtl8192su ieee80211 phy0: Selected rate control algorithm 'rtl_rc' rtl8192su 2-1:1.0 wlp0s4f1u1: renamed from wlan0 systemd-udevd[391]: renamed network interface wlan0 to wlp0s4f1u1 - nmcli radio WIFI-HW WIFI WWAN-HW WWAN enabled enabled enabled enabled - journalctl NetworkManager(debug) [platform/nm-platform.c:2565] log_link(): signal: link added: 4: wlp0s4f1u1 mtu 1500 wifi driver 'rtl8192su' udi '/sys/devices/pci:00/:00:04.1/usb2/2-1/2-1:1.0/net/wlp0s4f1u1' [nm-device-wifi.c:228] constructor(): (wlp0s4f1u1): kernel ifindex 4 (wlp0s4f1u1): using nl80211 for WiFi device control (wlp0s4f1u1): driver supports Access Point (AP) mode [devices/nm-device.c:6983] nm_device_update_hw_address(): (wlp0s4f1u1): hardware address is 00:E0:4C:81:92:E4 [nm-device-wifi.c:2623] update_initial_hw_address(): (wlp0s4f1u1): read initial MAC address 00:E0:4C:81:92:E4 [platform/nm-linux-platform.c:2099] sysctl_get(): error reading /sys/class/net/wlp0s4f1u1/phys_port_id: Failed to read from file '/sys/class/net/wlp0s4f1u1/phys_port_id': Operation not supported [nm-manager.c:1372] manager_rfkill_update_one_type(): WiFi hw-enabled 1 sw-enabled 1 [nm-device-wifi.c:3230] set_enabled(): (wlp0s4f1u1): device now enabled [nm-device-wifi.c:3236] set_enabled(): (enable): wlp0s4f1u1 blocked by UNMANAGED state (wlp0s4f1u1): new 802.11 WiFi device (driver: 'rtl8192su' ifindex: 4) (wlp0s4f1u1): exported as /org/freedesktop/NetworkManager/Devices/1 [devices/nm-device.c:5089] nm_device_set_ip4_config(): (wlp0s4f1u1): set IP4Config instance (/org/freedesktop/NetworkManager/IP4Config/0) [devices/nm-device.c:5197] nm_device_set_ip6_config(): (wlp0s4f1u1): set IP6Config instance (/org/freedesktop/NetworkManager/IP6Config/0) (wlp0s4f1u1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] [platform/nm-linux-platform.c:2067] _log_dbg_sysctl_get_impl(): sysctl: reading '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra': '1' [platform/nm-linux-platform.c:2067] _log_dbg_sysctl_get_impl(): sysctl: reading '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra_defrtr': '1' [platform/nm-linux-platform.c:2067] _log_dbg_sysctl_get_impl(): sysctl: reading '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra_pinfo': '1' [platform/nm-linux-platform.c:2067] _log_dbg_sysctl_get_impl(): sysctl: reading '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra_rtr_pref': '1' [platform/nm-linux-platform.c:2067] _log_dbg_sysctl_get_impl(): sysctl: reading '/proc/sys/net/ipv6/conf/wlp0s4f1u1/disable_ipv6': '0' [platform/nm-linux-platform.c:2067] _log_dbg_sysctl_get_impl(): sysctl: reading '/proc/sys/net/ipv6/conf/wlp0s4f1u1/hop_limit': '64' [platform/nm-linux-platform.c:2067] _log_dbg_sysctl_get_impl(): sysctl: reading '/proc/sys/net/ipv6/conf/wlp0s4f1u1/use_tempaddr': '0' [platform/nm-linux-platform.c:1967] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/disable_ipv6' to '1' (current value is '0') [platform/nm-linux-platform.c:1967] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra_defrtr' to '0' (current value is '1') [platform/nm-linux-platform.c:1967] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra_pinfo' to '0' (current value is '1') [platform/nm-linux-platform.c:1967] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra_rtr_pref' to '0' (current value is '1') [platform/nm-linux-platform.c:1965] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/use_tempaddr' to '0' (current value is identical) [devices/nm-device.c:55
Re: [PATCH 6/7] mac80211: wait for the first beacon on the new channel after CSA
On 26 September 2014 21:35, Luca Coelho wrote:
> From: Luciano Coelho
>
> Instead of immediately reopening the queues (in case of block_tx),
> calling the post_channel_switch operation and sending the
> notification, wait for the first beacon on the new channel. This
> makes sure that we don't lose packets if the AP/GO is not on the new
> channel yet.
>
> Signed-off-by: Luciano Coelho
[...]
Just a few nitpicks from me:
> +static void ieee80211_chswitch_post_beacon(struct ieee80211_sub_if_data
> *sdata)
> +{
> + struct ieee80211_local *local = sdata->local;
> + struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> + int ret;
> +
> + sdata_assert_lock(sdata);
>
I was thinking about WARN_ON(!sdata->vif.csa_active) here. csa_active
should be set in all cases if csa_waiting_bcn is set, no?
> - /* XXX: wait for a beacon first? */
> if (sdata->csa_block_tx) {
> ieee80211_wake_vif_queues(local, sdata,
> IEEE80211_QUEUE_STOP_REASON_CSA);
> sdata->csa_block_tx = false;
> }
>
> + sdata->vif.csa_active = false;
> + ifmgd->csa_waiting_bcn = false;
> +
> ret = drv_post_channel_switch(sdata);
> if (ret) {
> sdata_info(sdata,
>"driver post channel switch failed,
> disconnecting\n");
> ieee80211_queue_work(&local->hw,
> &ifmgd->csa_connection_drop_work);
> - goto out;
> + return;
> }
> < here
> - ieee80211_sta_reset_beacon_monitor(sdata);
> - ieee80211_sta_reset_conn_monitor(sdata);
> -
> -out:
> - mutex_unlock(&local->chanctx_mtx);
> - mutex_unlock(&local->mtx);
> - sdata_unlock(sdata);
> }
Is that an empty line I before final `}`?
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
Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
gree...@candelatech.com writes:
> 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
[...]
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> ret);
>
> if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
> - return ret;
> + goto out;
>
> ath10k_warn(ar, "trying cold reset\n");
>
> @@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> if (ret) {
> ath10k_err(ar, "failed to power up target using cold
> reset too (%d)\n",
> ret);
> - return ret;
> + goto out;
> }
> }
>
> - return 0;
> +out:
> + /* If we have failed to power-up, it may take a reboot to
> + * get the NIC back online.
> + * Set flag accordinly so that user-space can know.
> + */
> + ar->fw_powerup_failed = !!ret;
> + return ret;
> }
Would it be better to use ATH10K_STATE_WEDGED for this and then just
export the state value to user space? Or should we have two different
states, like FW_WEDGED and HW_WEDGED?
--
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 03/10] ath10k: support ethtool stats.
Ben Greear writes:
> On 09/24/2014 12:44 AM, Michal Kazior wrote:
>> On 23 September 2014 23:17, wrote:
>> [...]
>>> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
>>> +struct ieee80211_vif *vif,
>>> +struct ethtool_stats *stats, u64 *data)
>>> +{
>>> + struct ath10k *ar = hw->priv;
>>> + int i = 0;
>>> + struct ath10k_target_stats *fw_stats;
>>> +
>>> + fw_stats = &ar->debug.target_stats;
>>> +
>>> + mutex_lock(&ar->conf_mutex);
>>> +
>>> + if (ar->state == ATH10K_STATE_ON)
>>> + ath10k_refresh_peer_stats(ar);
>>> +
>>> + mutex_unlock(&ar->conf_mutex);
>>
>> Just for correctness sake - it's probably a good idea to
>> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
>> the stats are for this particular request. With your patch there's a
>> very slight chance that, e.g. fw_stats debug file is being read at the
>> same time and it updates fw stats between the above mutex_unlock() and
>> following spin_lock_bh().
>
> That makes no difference at all to the user though, and it is one less
> set of nested locks to worry about.
I still do not want to have known races, especially when it's so easy to
fix. The ethtool patches patches conflict with Michal's fw_stats fixes.
Let me take the ethtool patches so that I can rebase them, fix this race
and do some other small changes as well. I'll send v2 soon.
--
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] ath: Add support for tracing
Kalle Valo wrote: > You mean ath_printk() & friends? But that doesn't require tracing code > to be in ath.ko as well, right? If I understood correctly, trace.c could > be under ath9k directory and the kconfig option could be > ATH9K_TRACEPOINTS. > > I think it's just misleading and confusing for the user to call it > "Atheros wireless tracing" when it only affects ath9k. It's easier to > understand if each driver has it's own "tracing" kconfig option. We have CONFIG_ATH_DEBUG, which is used by ath9k and ath9k_htc. I think it is okay to have CONFIG_ATH_TRACEPOINTS, which can be used by ath9k/ath9k_htc too. The original motive of ath.ko was to have a common module with debugging facilities that can be shared by Atheros drivers. But, each driver has ended up reinventing things. Since it is mentioned in the help text that ath9k is the only driver making use of ATH_DEBUG/ATH_TRACEPOINTS, I don't think it is confusing. Sujith -- 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: fix fw stats processing
Michal Kazior writes: > On 27 September 2014 10:01, Kalle Valo wrote: >> Michal Kazior writes: >> >>> If stat data exceeds wmi-htc buffer limits >>> firmware splits it into many wmi stats update >>> events which are delivered in a ping-pong fashion >>> triggered by wmi stats request command. >>> >>> Since there's only an implicit start-of-data and >>> no end-of-data indications the driver has to >>> perform some trickery to get complete stat data. >>> >>> Signed-off-by: Michal Kazior >> >> I folded the patch below in ath-next-next. Please check: >> >> https://github.com/kvalo/ath/commit/7071112c5ddaff761cd7d9bb3110c3f3d2f83bb8 > [...] > > I think you meant: > > https://github.com/kvalo/ath/commit/5122a60f4fbf5a38e70a14578858b39058ee367a Indeed. Sorry for the mixup. > It looks good. Thanks! Thanks for checking. -- 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 4/4] ath10k: fix fw stats processing
On 27 September 2014 10:01, Kalle Valo wrote: > Michal Kazior writes: > >> If stat data exceeds wmi-htc buffer limits >> firmware splits it into many wmi stats update >> events which are delivered in a ping-pong fashion >> triggered by wmi stats request command. >> >> Since there's only an implicit start-of-data and >> no end-of-data indications the driver has to >> perform some trickery to get complete stat data. >> >> Signed-off-by: Michal Kazior > > I folded the patch below in ath-next-next. Please check: > > https://github.com/kvalo/ath/commit/7071112c5ddaff761cd7d9bb3110c3f3d2f83bb8 [...] I think you meant: https://github.com/kvalo/ath/commit/5122a60f4fbf5a38e70a14578858b39058ee367a It looks good. Thanks! 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
