Re: Question on tx-power and number of chains.
On Wed, 2015-02-25 at 11:50 -0800, Ben Greear wrote: > On 02/25/2015 11:10 AM, Johannes Berg wrote: > > On Wed, 2015-02-25 at 10:51 -0800, Ben Greear wrote: > > > >> Is there a table somewhere that explains how many chains are used by each > >> rate? > > > > mcsindex.com? > > What about OFDM and CCK. Are those always 1 chain? They're 1 stream at least, so only one chain is needed. I'm not entirely sure you couldn't transmit them on multiple chains but I don't think it'd make that much sense? 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: [ath9k-devel] AR9462 problems connecting again..
On Wed, Feb 25, 2015 at 10:14 AM, Linus Torvalds wrote: > > I'm talking about the two from Jouni - the "don't encrypt EAPOL > frames" one, and the one-liner that makes all EAPOL frames go at the > lowest data rate. So I just found out and confirmed that this is not Atheros-specific in any way - it looks like it's simply the UniFi AP that does not like high-data-rate authentification frames at all. Because it looks like the brcmsmac driver has *exactly* the same behavior with this AP (in an Apple Macbook air). I assume brcmsmac uses the net/80211/tx.c logic too. And Jouni's one-liner fixes that one too, although as usual, maybe there is some testing noise, and I screwed something up. This time I only did the one-liner, so that's the critical one. It's interesting to note how nothing else has been unhappy with that network (admittedly it's been mainly android devices and a HP printer that I've tested), so it looks like everybody else does low-rate authentication packets anyway. So this actually looks like a Ubiquiti UniFi AP bug to me, but it also looks like presumably everybody else does low-rate initial packets, and our kernel 802.11 layer should just follow suit. The whole robustness principle and "be conservative in what you send, and liberal in what you accept" etc. Linus -- 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: [ath9k-devel] AR9462 problems connecting again..
On Thu, Feb 26, 2015 at 7:22 AM, Adrian Chadd wrote: > On 25 February 2015 at 10:14, Linus Torvalds > wrote: > > >> While I realize that people may disagree about the exact details of >> how to fix this in the long run, may I suggest that in the meantime we >> at least get the two workaround patches applied? >> >> I'm talking about the two from Jouni - the "don't encrypt EAPOL >> frames" one, and the one-liner that makes all EAPOL frames go at the >> lowest data rate. >> >> Even if "lowest data rate" is ridiculously low, and even if that might >> disturb other things going on on the same channel at the same time, >> those authentication packets shouldn't be so common as to be a >> problem. No? >> >> Jouni has a few packet dumps for me, and he's stumped as to what >> exactly is going on, but those two patches (well, the one-liner "low >> data rate EAPOL" in particular, it seems) do seem to make my >> connections go through reliably. >> >> And it seems that other drivers already are working around the EAPOL >> issue in similar ways, judging by the comments about iwlwifi. > > [snip] > >> So I'm sure I can improve reception of my laptop, but that's not the >> point. The point is that bad wireless networks aren't so unusual, and >> right now things clearly don't work as well as they could. >> >> Does anybody hate Jouni's two patches *so* much that they can >> articulate *why* it would be wrong to apply them as interim patches? >> And if so, do you have better patches for me to try? Because if not.. > > I agree with you. I think you should just have EAPOL frames go out at > the lowest rate for now and then worry about experimenting with more > interesting ways to make EAPOL / DHCP frames cheaper. It fixes a lot > of problems in noisy areas. That hack was hiding around in various > commercial drivers I've seen, and it's been in FreeBSD for a while. > > Same with DHCP traffic too - it's the second set of data frames that > the rate control code sees, and it's the primary reason I dropped the > initial sample rate down in FreeBSD so the DHCP exchange would have a > better chance of succeeding after association. > > > > -adrian +1 Really, who cares about efficiency here; these are rare control packets. -- 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 v7 3/3] cfg80211: Schedule timeout for all CRDA calls
On Wed, Feb 25, 2015 at 04:47:04AM -0500, Ilan Peer wrote: > Timeout was scheduled only in case CRDA was called due to user hints, > but was not scheduled for other cases. This can result in regulatory > hint processing getting stuck in case that there is no CRDA configured. > > Change this by scheduling a timeout every time CRDA is called. In > addition, in restore_regulatory_settings() all pending requests are > restored (and not only the user ones). > > Signed-off-by: Ilan Peer I think I had acked this already. If so add the tag. Luis -- 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 v7 2/3] cfg80211: Add API to change the indoor regulatory setting
On Wed, Feb 25, 2015 at 04:47:03AM -0500, Ilan Peer wrote: > case NL80211_USER_REG_HINT_INDOOR: > - return regulatory_hint_indoor_user(); > + is_indoor = !!info->attrs[NL80211_ATTR_REG_INDOOR]; > + if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) > + owner_nlportid = info->snd_portid; > + > + return regulatory_hint_indoor(is_indoor, owner_nlportid); > default: > return -EINVAL; > } You are changing this so that this can only work when NL80211_ATTR_REG_INDOOR is used however this should only be true if the info->attrs[NL80211_ATTR_SOCKET_OWNER was set as in the old days the usersapce API allowed for NL80211_ATTR_REG_INDOOR to not be set. Don't break old userspace. Fix that, and it seems fine. While at it please explain how / who send the userespace hint and that right now we don't do anything with the country IE indoor / outdoor flag. Luis -- 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 v7 1/3] cfg80211: Simplify the handling of regulatory indoor setting
On Wed, Feb 25, 2015 at 04:47:02AM -0500, Ilan Peer wrote: > Directly update the indoor setting without wrapping it as > a regulatory request, to simplify the processing. > > Signed-off-by: Ilan Peer Acked-by: Luis R. Rodriguez Luis -- 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 v6 1/2] cfg80211: Add API to change the indoor regulatory setting
On Wed, Feb 25, 2015 at 02:30:40PM +, Peer, Ilan wrote: > Hi Luis, > > > -Original Message- > > From: Luis R. Rodriguez [mailto:mcg...@suse.com] > > Sent: Tuesday, February 24, 2015 02:03 > > To: Peer, Ilan; Jouni Malinen > > Cc: linux-wireless@vger.kernel.org; ArikX Nemtsov > > Subject: Re: [PATCH v6 1/2] cfg80211: Add API to change the indoor > > regulatory setting > > > > On Sat, Feb 21, 2015 at 10:57:10PM -0500, Ilan Peer wrote: > > > Previously, the indoor setting configuration assumed that as long as a > > > station interface is connected, the indoor environment setting does > > > not change. However, this assumption is problematic > > > as: > > > > > > - It is possible that a station interface is connected to a mobile > > > AP, e.g., softAP or a P2P GO, where it is possible that both the > > > station and the mobile AP move out of the indoor environment making > > > the indoor setting invalid. In such a case, user space has no way to > > > invalidate the setting. > > > > At the protocol level should we consider the need for a dynamic environment > > change? Until then a change of environment likely should implicate an AP > > disconnect, which is what Linux does. With your changes in place we could do > > something even more graceful should the protocol allow for it. > > > > Not sure I follow ... OK right now we should disconnect if there are some regulatory params that do not agree. This event will also ony happen *rarely*. Even though this happens rarely I can find use for forcing this to happen in a not so rare case to help optimize RF spectrum use dynamically, if the protocol had a way to communicate a desired change in environment this could be reused for a dynaic RF spectrum change in environment. > > For instance if the regulatory parameters for a country are the same for > > indoor and outdoro a change in environment should not require a disconnect. > > > > So you are suggesting to extend the mechanism to also indicate if a teardown > of active interfaces is needed or not? And if so, not sure that this should > be done by > the kernel. If the AP *knew* a change in environment (now forget indoor/outdoor as that is rare today) was not disruptive this could be information that the STAs can get to use to evaluate and make a better decision as to whether or not it did need to tear down or not. > > If the change was from a more restrictive environment to a more liberal set > > of > > regulatory settings it could mean increasing TX power of the AP changing to > > a > > channel which perhaps was not allowed before. > > > > I think that such a flow needs to be handled in user-space by hostapd, which > can > leverage the proper mechanisms to do the change, e.g., eCSA. Right but that's the AP, how would the STAs get that information? This is why I mentioned the idea of a possible protocol enhancement to let the AP inform STAs of an environmental change. The AP *could* feed more than just the boring parameters we're used to. Its OK this is just an idea, ignore it. > > If the change was from a less restrictive environment to a more restrictive > > environment the AP might want to change channels for instance or reduce TX > > power. > > > > Same as above. For example, hostapd handles DFS related channel changes in > user space. We also added flows to handle channel switch etc. in > wpa_supplicant ... > and I need to resubmit them to hostap. OK.. > > While change in indoor/outdoor might be something silly to consider given > > the likelihood of it being a common thing to happen that you change an AP > > from indoor / outdoor regularly I'd consider instead the possibility to > > reuse > > such a dynamic environment change notification for purposes of dynamic > > environmental adjustments of BSSes. Typically BSSes settings are static but > > RF > > environments change regularly so its silly to expect a BSS and its initial > > Automatic Channel Selection algorithm to be corrrect during the lifetime of > > a > > BSS. > > > > > - A station interface disconnection does not necessarily imply that > > > the device is no longer operating in an indoor environment, e.g., > > > it is possible that the station interface is roaming but is still > > > stays indoor. > > > > Sure. > > > > You also fail to explain how we currently provide the indoor thing to the > > kernel, I think its worth providing that in the commit log and also > > explaining > > how we don't use the country IE environment thing at all. > > > > I explained some of the use cases in previous patches, e.g., AC power, > device type etc. I can add this, but I do not understand how country IE is > related > here. Mention it and the country IE is important given its the other place folks expect it to be deduced from -- and we don't use it at all. Without that information folks can assume we do unless they are familiar with the code. It provides useful context for your change, even for me! Luis -
[PATCH] ath: support new FCC DFS Radar Type 1
Add support for new FCC DFS rules released on August 14, 2014.
FCC has added a new radar type named Radar Type 1 and original
Radar Type 1 is renamed to Radar Type 0 in consequence.
In fact, the type ID does nothing to functionalities.
In other words, even if we re-order the IDs, DFS detection will
work as well, but we give the ID with matching to FCC doc.
By adding this support, the drivers using this DFS function are
able to support both of old and new FCC DFS rules simultaneously
without any other changes.
Signed-off-by: Peter Oh
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 23 ++--
drivers/net/wireless/ath/dfs_pattern_detector.h | 5 +
drivers/net/wireless/ath/dfs_pri_detector.c | 29 ++---
drivers/net/wireless/ath/dfs_pri_detector.h | 4 ++--
4 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c
b/drivers/net/wireless/ath/dfs_pattern_detector.c
index b1de8c6..65958ec 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -21,12 +21,6 @@
#include "dfs_pri_detector.h"
#include "ath.h"
-/*
- * tolerated deviation of radar time stamp in usecs on both sides
- * TODO: this might need to be HW-dependent
- */
-#define PRI_TOLERANCE 16
-
/**
* struct radar_types - contains array of patterns defined for one DFS domain
* @domain: DFS regulatory domain
@@ -81,13 +75,18 @@ static const struct radar_types etsi_radar_types_v15 = {
PPB_THRESH(PPB), PRI_TOLERANCE, CHIRP \
}
+/* radar types released on August 14, 2014
+ * type 1 PRI values randomly selected within the range of PMIN and PMAX,
+ * hence leave its PPB as 0 to be calculated on the fly.
+ */
static const struct radar_detector_specs fcc_radar_ref_types[] = {
FCC_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
- FCC_PATTERN(1, 0, 5, 150, 230, 1, 23, false),
- FCC_PATTERN(2, 6, 10, 200, 500, 1, 16, false),
- FCC_PATTERN(3, 11, 20, 200, 500, 1, 12, false),
- FCC_PATTERN(4, 50, 100, 1000, 2000, 1, 1, true),
- FCC_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
+ FCC_PATTERN(1, 0, 1, 518, 3066, 1, 0, false),
+ FCC_PATTERN(2, 0, 5, 150, 230, 1, 23, false),
+ FCC_PATTERN(3, 6, 10, 200, 500, 1, 16, false),
+ FCC_PATTERN(4, 11, 20, 200, 500, 1, 12, false),
+ FCC_PATTERN(5, 50, 100, 1000, 2000, 1, 1, true),
+ FCC_PATTERN(6, 0, 1, 333, 333, 1, 9, false),
};
static const struct radar_types fcc_radar_types = {
@@ -199,7 +198,7 @@ channel_detector_create(struct dfs_pattern_detector *dpd,
u16 freq)
goto fail;
for (i = 0; i < dpd->num_radar_types; i++) {
- const struct radar_detector_specs *rs = &dpd->radar_spec[i];
+ struct radar_detector_specs *rs = &dpd->radar_spec[i];
struct pri_detector *de = pri_detector_init(rs);
if (de == NULL)
goto fail;
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.h
b/drivers/net/wireless/ath/dfs_pattern_detector.h
index 25a43d6..92be353 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.h
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.h
@@ -21,6 +21,11 @@
#include
#include
+/* tolerated deviation of radar time stamp in usecs on both sides
+ * TODO: this might need to be HW-dependent
+ */
+#define PRI_TOLERANCE 16
+
/**
* struct ath_dfs_pool_stats - DFS Statistics for global pools
*/
diff --git a/drivers/net/wireless/ath/dfs_pri_detector.c
b/drivers/net/wireless/ath/dfs_pri_detector.c
index 1b5ad19..a234329 100644
--- a/drivers/net/wireless/ath/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/dfs_pri_detector.c
@@ -21,6 +21,13 @@
#include "dfs_pattern_detector.h"
#include "dfs_pri_detector.h"
+#define FCC_TYPE1_MIN_PRI (518)
+#define FCC_TYPE1_MAX_PRI (3066)
+#define FCC_TYPE1_MIN_PPB (18)
+#define FCC_TYPE1_MAX_PPB (106)
+/* round up of ((1 / 360) * (19 * 1M)) */
+#define FCC_TYPE1_PPB_CONSTANT (52778)
+
struct ath_dfs_pool_stats global_dfs_pool_stats = {};
#define DFS_POOL_STAT_INC(c) (global_dfs_pool_stats.c++)
@@ -244,6 +251,13 @@ static bool pseq_handler_create_sequences(struct
pri_detector *pde,
ps.first_ts = p->ts;
ps.last_ts = ts;
ps.pri = ts - p->ts;
+ if (pde->rs->ppb == 0) {
+ /* runtime calculation of ppb and ppb threshold for
+* pri in variable range. ppb threshold is half of ppb.
+*/
+ pde->rs->ppb = FCC_TYPE1_PPB_CONSTANT / ps.pri;
+ pde->rs->ppb_thresh = (pde->rs->ppb / 2) + 1;
+ }
ps.dur = ps.pri * (pde->rs->ppb - 1)
+ 2 * pde->rs->max_pri_tolerance;
@@ -366,6 +380,14 @@ static void pri_detector_reset(struct pri_detector *pde,
u64 ts)
}
Re: [PATCH v2 0/10] Improve Minstrels & Minstrel-HTs common code base & statistics
* Job [13.02.2015 16:32]: > This patch series adds several improvements to the readability, the > output format of rc_stats and the calculated statistics of Minstrel > and Minstrel-HT. Variable names got more consistent and functions > got unified between both rate control algorithms. i did intensive testing in our small testnet (~50 routers) with all kinds of platforms (ar71xx, x86, mpc85xx/ppc) and have no objections for this patch-series but a big "thumbs up" for very nice, readable and machine-parseable minstrel/rate-selector-output: root@KuechenJukebox:~ cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/f4:ec:38:9d:81:f0/rc_stats best rate__ ___statistics__last_____sum-of mode guard # rate [name idx airtime max_tp] [ ø(tp) ø-2σ(tp) ø(prob) σ(prob)] [prob.|retry|suc|att] [#success | #attempts] CCKLP 1 1.0M 120 10548 0.9 0.0 0.0 6.4 1.6 5.2 2 0 074 585 CCKLP 1 2.0M 1215476 1.8 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 CCKLP 1 5.5M 1222411 4.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 CCKLP 1 11.0M 1231535 6.5 1.2 1.118.7 0.7 0.0 0 0 0 1 3 HT20 LGI 1CD MCS0 01480 6.5 3.3 3.252.7 1.2 33.3 2 0 0 320 657 HT20 LGI 1 A P MCS1 1 74012.5 9.9 9.779.8 0.9 100.0 3 2 2 645 1234 HT20 LGI 1 MCS2 2 49618.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 1 MCS3 3 37223.4 1.9 1.3 8.8 1.5 0.0 5 0 069 281 HT20 LGI 1 MCS4 4 24833.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 HT20 LGI 1 MCS5 5 18841.3 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 1 MCS6 6 16845.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 1 MCS7 7 14849.5 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS810 74012.5 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 HT20 LGI 2 B MCS911 37223.4 7.4 6.832.4 1.6 0.0 4 0 810 27 HT20 LGI 2 MCS10 12 24833.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 HT20 LGI 2 MCS11 13 18841.3 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS12 14 12456.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS13 15 9666.6 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS14 16 8472.4 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS15 17 7676.9 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 Total packet count::ideal 1023 lookaround 48 Average # of aggregated frames per A-MPDU: 2.7 root@KuechenJukebox:~ cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/f4:ec:38:9d:81:f0/rc_stats_csv 1424897596.239275,CCK,LP,1,, 1.0M,120,10548,0.9,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,CCK,LP,1,, 2.0M,121,5476,1.8,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,CCK,LP,1,, 5.5M,122,2411,4.1,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,CCK,LP,1,,11.0M,123,1535,6.5,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,A,B,C,D,P,MCS0 ,0,1480,6.2,0.0,0.0,0.0,0.0,0.0,1,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS1 ,1,740,11.7,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS2 ,2,496,16.5,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS3 ,3,372,20.8,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS4 ,4,248,28.0,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS5 ,5,188,33.7,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS6 ,6,168,36.2,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS7 ,7,148,39.0,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,2,,MCS8 ,10,740,11.7,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,2,,MCS9 ,11,372,20.8,0.0,0.0,0.0
Re: [PATCH v2 0/10] Improve Minstrels & Minstrel-HTs common code base & statistics
* Job [13.02.2015 16:32]: > This patch series adds several improvements to the readability, the > output format of rc_stats and the calculated statistics of Minstrel > and Minstrel-HT. Variable names got more consistent and functions > got unified between both rate control algorithms. i did intensive testing in our small testnet (~50 routers) with all kinds of platforms (ar71xx, x86, mpc85xx/ppc) and have no objections for this patch-series but a big "thumbs up" for very nice, readable and machine-parseable minstrel/rate-selector-output: root@KuechenJukebox:~ cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/f4:ec:38:9d:81:f0/rc_stats best rate__ ___statistics__last_____sum-of mode guard # rate [name idx airtime max_tp] [ ø(tp) ø-2σ(tp) ø(prob) σ(prob)] [prob.|retry|suc|att] [#success | #attempts] CCKLP 1 1.0M 120 10548 0.9 0.0 0.0 6.4 1.6 5.2 2 0 074 585 CCKLP 1 2.0M 1215476 1.8 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 CCKLP 1 5.5M 1222411 4.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 CCKLP 1 11.0M 1231535 6.5 1.2 1.118.7 0.7 0.0 0 0 0 1 3 HT20 LGI 1CD MCS0 01480 6.5 3.3 3.252.7 1.2 33.3 2 0 0 320 657 HT20 LGI 1 A P MCS1 1 74012.5 9.9 9.779.8 0.9 100.0 3 2 2 645 1234 HT20 LGI 1 MCS2 2 49618.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 1 MCS3 3 37223.4 1.9 1.3 8.8 1.5 0.0 5 0 069 281 HT20 LGI 1 MCS4 4 24833.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 HT20 LGI 1 MCS5 5 18841.3 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 1 MCS6 6 16845.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 1 MCS7 7 14849.5 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS810 74012.5 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 HT20 LGI 2 B MCS911 37223.4 7.4 6.832.4 1.6 0.0 4 0 810 27 HT20 LGI 2 MCS10 12 24833.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 2 HT20 LGI 2 MCS11 13 18841.3 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS12 14 12456.1 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS13 15 9666.6 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS14 16 8472.4 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 HT20 LGI 2 MCS15 17 7676.9 0.0 0.0 0.0 0.0 0.0 0 0 0 0 3 Total packet count::ideal 1023 lookaround 48 Average # of aggregated frames per A-MPDU: 2.7 root@KuechenJukebox:~ cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/f4:ec:38:9d:81:f0/rc_stats_csv 1424897596.239275,CCK,LP,1,, 1.0M,120,10548,0.9,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,CCK,LP,1,, 2.0M,121,5476,1.8,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,CCK,LP,1,, 5.5M,122,2411,4.1,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,CCK,LP,1,,11.0M,123,1535,6.5,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,A,B,C,D,P,MCS0 ,0,1480,6.2,0.0,0.0,0.0,0.0,0.0,1,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS1 ,1,740,11.7,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS2 ,2,496,16.5,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS3 ,3,372,20.8,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS4 ,4,248,28.0,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS5 ,5,188,33.7,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS6 ,6,168,36.2,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,1,,MCS7 ,7,148,39.0,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,2,,MCS8 ,10,740,11.7,0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1.0 1424897596.239275,HT20,LGI,2,,MCS9 ,11,372,20.8,0.0,0.0,0.0
Re: [ath9k-devel] AR9462 problems connecting again..
Hi Jouni, >> In case of ath9k, the driver in xmit.c allocates in function >> ath_tx_fill_desc() a struct ath_tx_info info by memset(&info, 0, >> sizeof(info)) .. so all info->rates[xy].Rate == 0. >> Than function ath_buf_set_rate() sets all info->rates[xy].Rate to those >> values specified in the rate table (struct ieee8021_sta_rate) IF >> (!rates[i].count || (rates[i].idx < 0)) … >> … so info->rates[3].Rate is untouched and still „0“. > > Sure, it can be 0 and so is the number of tries at that rate.. You are absolutely right … as the tries are 0 as well, the 4th mrr[3] is not used. I missed that obvious point. >> I just added a printk() to xmit.c in function ath_tx_fill_desc() just before >> ath9k_hw_set_txdesc() is called. >> From the log I get, e.g.: >> >> [ 169.543554] mrr setup: mrr[0]:133 mrr[1]:132 mrr[2]:134 mrr[3]:0 >> >> I have not check yet if info->rates[3].Rate == 0 is the lowest possible >> rate… but I would guess so. > > It is not and even if it were, it does not matter since this 4th item is > used for _0_ tries. I've verified the exact behavior with a sniffer for > a case where the target device does not ACK frames. ath9k ends up > sending at exactly the three different rates indicated in the first > three values and nothing else. With RC probing (which happens to occur > for the initial EAPOL frames, this results in only one attempt at > MCS(>0) and two + two attempts at MCS0. No non-MCS rates are tried. As > pointed out previously, this is likely fine for normal data frames, but > not for EAPOL. I do agree in changing the way to assign a (mrr) rate set for EAPOL frames in the most robust fashion. Greetings Thomas > > -- > Jouni MalinenPGP id EFC895FA > ___ > ath9k-devel mailing list > ath9k-de...@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- 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] rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
On 02/25/2015 01:34 PM, Taehee Yoo wrote: Add HAL_DEF_WOWLAN case in rtl92cu_get_hw_reg Signed-off-by: Taehee Yoo Acked-by: Larry Finger @Kalle: This is V2. V1 is not OK. Larry --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index fe4b699..96bae39 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -1589,6 +1589,8 @@ void rtl92cu_get_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val) case HW_VAR_DATA_FILTER: *((u16 *) (val)) = rtl_read_word(rtlpriv, REG_RXFLTMAP2); break; + case HAL_DEF_WOWLAN: + break; default: RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "switch case not processed\n"); -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
On 25 February 2015 at 10:14, Linus Torvalds wrote: > While I realize that people may disagree about the exact details of > how to fix this in the long run, may I suggest that in the meantime we > at least get the two workaround patches applied? > > I'm talking about the two from Jouni - the "don't encrypt EAPOL > frames" one, and the one-liner that makes all EAPOL frames go at the > lowest data rate. > > Even if "lowest data rate" is ridiculously low, and even if that might > disturb other things going on on the same channel at the same time, > those authentication packets shouldn't be so common as to be a > problem. No? > > Jouni has a few packet dumps for me, and he's stumped as to what > exactly is going on, but those two patches (well, the one-liner "low > data rate EAPOL" in particular, it seems) do seem to make my > connections go through reliably. > > And it seems that other drivers already are working around the EAPOL > issue in similar ways, judging by the comments about iwlwifi. [snip] > So I'm sure I can improve reception of my laptop, but that's not the > point. The point is that bad wireless networks aren't so unusual, and > right now things clearly don't work as well as they could. > > Does anybody hate Jouni's two patches *so* much that they can > articulate *why* it would be wrong to apply them as interim patches? > And if so, do you have better patches for me to try? Because if not.. I agree with you. I think you should just have EAPOL frames go out at the lowest rate for now and then worry about experimenting with more interesting ways to make EAPOL / DHCP frames cheaper. It fixes a lot of problems in noisy areas. That hack was hiding around in various commercial drivers I've seen, and it's been in FreeBSD for a while. Same with DHCP traffic too - it's the second set of data frames that the rate control code sees, and it's the primary reason I dropped the initial sample rate down in FreeBSD so the DHCP exchange would have a better chance of succeeding after association. -adrian -- 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: brcmfmac43241b4-sdio / Thinkpad Tablet 10 issues
On 02/25/15 13:23, Jocky Wilson wrote: Sebastien Bourdeauducq writes: On Tuesday, February 17, 2015 03:49 AM, Arend van Spriel wrote: So it is a one-off and not showing the issue you are seeing. Your issue seems to be due to failing firmware so you may need b5 firmware. Making some progress :) ... I guess that the driver has bugs with decoding some of the data sent by the card. I can confirm this with my Thinkpad Tablet 8 which has same chip revision. Arend: do you need anything else to be tested? Nope. As it turns out this chip revision indeed needs b5 firmware. As windows and linux use different firmware we will need to release that to linux-firmware and modify brcmfmac to pick it up properly. Keep an eye out for those patches. Regards, Arend /JockyW -- 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: Question on tx-power and number of chains.
On 02/25/2015 11:10 AM, Johannes Berg wrote: > On Wed, 2015-02-25 at 10:51 -0800, Ben Greear wrote: > >> Is there a table somewhere that explains how many chains are used by each >> rate? > > mcsindex.com? What about OFDM and CCK. Are those always 1 chain? 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
[PATCH] rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
Add HAL_DEF_WOWLAN case in rtl92cu_get_hw_reg Signed-off-by: Taehee Yoo --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index fe4b699..96bae39 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -1589,6 +1589,8 @@ void rtl92cu_get_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val) case HW_VAR_DATA_FILTER: *((u16 *) (val)) = rtl_read_word(rtlpriv, REG_RXFLTMAP2); break; + case HAL_DEF_WOWLAN: + break; default: RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "switch case not processed\n"); -- 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: Question on tx-power and number of chains.
On Wed, 2015-02-25 at 20:21 +0100, Arend van Spriel wrote: > On 02/25/15 20:10, Johannes Berg wrote: > > On Wed, 2015-02-25 at 10:51 -0800, Ben Greear wrote: > > > >> Is there a table somewhere that explains how many chains are used by each > >> rate? > > > > mcsindex.com? > > Nice. Adding that to my bookmarks. What happened to that quirky MCS32. It's the unloved stepchild ;-) They also removed all the other higher HT ones (>32) when adding VHT. You can still find an old version on archive.org IIRC. 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] rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
2015-02-26 4:12 GMT+09:00 Larry Finger : > On 02/25/2015 12:59 PM, ap420073 . wrote: >> >> 2015-02-26 3:33 GMT+09:00 Larry Finger : >>> >>> On 02/25/2015 11:58 AM, Taehee Yoo wrote: rtl_op_stop get wowlan state but rtl92cu_get_hw_reg has not process. Signed-off-by: Taehee Yoo >>> >>> >>> >>> Has this been tested? I am not aware that the RTL8192CU firmware could >>> handle WOWLAN. >>> >>> Larry >>> >>> --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index fe4b699..f6ad959 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -1589,6 +1589,12 @@ void rtl92cu_get_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val) case HW_VAR_DATA_FILTER: *((u16 *) (val)) = rtl_read_word(rtlpriv, REG_RXFLTMAP2); break; + case HAL_DEF_WOWLAN: + if (ppsc->wo_wlan_mode) + *((bool *)(val)) = true; + else + *((bool *)(val)) = false; + break; default: RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "switch case not processed\n"); >>> >> >> As far as i know, rtl8192cu is not support WOWLAN. >> in rtl8192cu, this code is no effect. so, It is care of unnecessary >> debug message. > > > That is what I thought. In that case, the new code should be > > case HAL_DEF_WOWLAN: > break; > > Larry > Thanks! I would send a new code. -- 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: Question on tx-power and number of chains.
On 02/25/15 20:10, Johannes Berg wrote: On Wed, 2015-02-25 at 10:51 -0800, Ben Greear wrote: Is there a table somewhere that explains how many chains are used by each rate? mcsindex.com? Nice. Adding that to my bookmarks. What happened to that quirky MCS32. 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 -- 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: Question on tx-power and number of chains.
On Wed, 2015-02-25 at 10:51 -0800, Ben Greear wrote: > Is there a table somewhere that explains how many chains are used by each > rate? mcsindex.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] rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
On 02/25/2015 12:59 PM, ap420073 . wrote: 2015-02-26 3:33 GMT+09:00 Larry Finger : On 02/25/2015 11:58 AM, Taehee Yoo wrote: rtl_op_stop get wowlan state but rtl92cu_get_hw_reg has not process. Signed-off-by: Taehee Yoo Has this been tested? I am not aware that the RTL8192CU firmware could handle WOWLAN. Larry --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index fe4b699..f6ad959 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -1589,6 +1589,12 @@ void rtl92cu_get_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val) case HW_VAR_DATA_FILTER: *((u16 *) (val)) = rtl_read_word(rtlpriv, REG_RXFLTMAP2); break; + case HAL_DEF_WOWLAN: + if (ppsc->wo_wlan_mode) + *((bool *)(val)) = true; + else + *((bool *)(val)) = false; + break; default: RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "switch case not processed\n"); As far as i know, rtl8192cu is not support WOWLAN. in rtl8192cu, this code is no effect. so, It is care of unnecessary debug message. That is what I thought. In that case, the new code should be case HAL_DEF_WOWLAN: break; Larry -- 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] rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
2015-02-26 3:33 GMT+09:00 Larry Finger : > On 02/25/2015 11:58 AM, Taehee Yoo wrote: >> >> rtl_op_stop get wowlan state but rtl92cu_get_hw_reg has not process. >> >> Signed-off-by: Taehee Yoo > > > Has this been tested? I am not aware that the RTL8192CU firmware could > handle WOWLAN. > > Larry > > >> --- >> drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c >> b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c >> index fe4b699..f6ad959 100644 >> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c >> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c >> @@ -1589,6 +1589,12 @@ void rtl92cu_get_hw_reg(struct ieee80211_hw *hw, u8 >> variable, u8 *val) >> case HW_VAR_DATA_FILTER: >> *((u16 *) (val)) = rtl_read_word(rtlpriv, REG_RXFLTMAP2); >> break; >> + case HAL_DEF_WOWLAN: >> + if (ppsc->wo_wlan_mode) >> + *((bool *)(val)) = true; >> + else >> + *((bool *)(val)) = false; >> + break; >> default: >> RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, >> "switch case not processed\n"); >> > As far as i know, rtl8192cu is not support WOWLAN. in rtl8192cu, this code is no effect. so, It is care of unnecessary debug message. -- 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
Question on tx-power and number of chains.
Suppose a NIC wants to decrease TX power for certain rates based on the number of chains (ie, subtract amount A from requested rate for 2 chains, and B for 3 chains). I assume the NIC wants to do this is because if the pkt is transmitted out each antenna, then there is ~3x the power put onto the air. Now, the question is, should this power-decrease be per rate, and perhaps different for each rate, or can all rates use all tx-chains (and so tx-power should be decreased the same maximum amount based on the hardware's number of chains for each rate). I am thinking that CCK rates can only ever be transmitted by a single chain, so in that case those rates would not need their power decreased from the requested? And if that is so, what about the /a/g/ rates, and lower-speed HT/VHT rates as well? Is there a table somewhere that explains how many chains are used by each rate? 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] rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
On 02/25/2015 11:58 AM, Taehee Yoo wrote: rtl_op_stop get wowlan state but rtl92cu_get_hw_reg has not process. Signed-off-by: Taehee Yoo Has this been tested? I am not aware that the RTL8192CU firmware could handle WOWLAN. Larry --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index fe4b699..f6ad959 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -1589,6 +1589,12 @@ void rtl92cu_get_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val) case HW_VAR_DATA_FILTER: *((u16 *) (val)) = rtl_read_word(rtlpriv, REG_RXFLTMAP2); break; + case HAL_DEF_WOWLAN: + if (ppsc->wo_wlan_mode) + *((bool *)(val)) = true; + else + *((bool *)(val)) = false; + break; default: RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "switch case not processed\n"); -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
Linus Torvalds wrote: > Last time I had connection issues with this laptop, nothing ended up > happening in the end, and I had people pipe up saying they had had > similar problems. I'd hate for the same "nothing" to happen this time > just because people aren't 100% sure what the final right thing is to > do. So I'd really like people to apply the simple workarounds for now > because clearly something is badly wrong, and *if* there is some > better resolution later, that's fine. .. > So I'm sure I can improve reception of my laptop, but that's not the > point. The point is that bad wireless networks aren't so unusual, and > right now things clearly don't work as well as they could. Those two patches (the one-liner in particular) should have gone in already 5-10 years ago. This has been an embarrassing problem for many years. I'm glad that people jumped this time around. //Peter -- 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: [ath9k-devel] AR9462 problems connecting again..
On Wed, Feb 25, 2015 at 6:47 AM, Jouni Malinen wrote: > > There may be something else wrong (say, some kind of interference), but > there is no way we can assume normal users to be able to fix such > issues. If we make EAPOL frames go through more robustly, the connection > can be established in more cases and this can result in relatively > functional network connection and rate control can handle the less > critical data frames through whatever means to get optimal throughput > from the network. As such, I do think we do need to "paper over" this > for EAPOL frames. While I realize that people may disagree about the exact details of how to fix this in the long run, may I suggest that in the meantime we at least get the two workaround patches applied? I'm talking about the two from Jouni - the "don't encrypt EAPOL frames" one, and the one-liner that makes all EAPOL frames go at the lowest data rate. Even if "lowest data rate" is ridiculously low, and even if that might disturb other things going on on the same channel at the same time, those authentication packets shouldn't be so common as to be a problem. No? Jouni has a few packet dumps for me, and he's stumped as to what exactly is going on, but those two patches (well, the one-liner "low data rate EAPOL" in particular, it seems) do seem to make my connections go through reliably. And it seems that other drivers already are working around the EAPOL issue in similar ways, judging by the comments about iwlwifi. Last time I had connection issues with this laptop, nothing ended up happening in the end, and I had people pipe up saying they had had similar problems. I'd hate for the same "nothing" to happen this time just because people aren't 100% sure what the final right thing is to do. So I'd really like people to apply the simple workarounds for now because clearly something is badly wrong, and *if* there is some better resolution later, that's fine. I'll happily test patches. It seems to be pretty repeatable for me, even if that "pretty repeatable" seems to be very much about the laptop being in one very particular place (it's right next to another AP, there's random other electronics around, since it's on my messy desk etc). So I wouldn't be at all surprised by horribly interference. And the AP is supposed to be ceiling- or wall-mounted, but because I'm just testing things out it's just sitting on a table in the next room, so for all I know it's in the *exact* worst position for the antennas etc etc. So I'm sure I can improve reception of my laptop, but that's not the point. The point is that bad wireless networks aren't so unusual, and right now things clearly don't work as well as they could. Does anybody hate Jouni's two patches *so* much that they can articulate *why* it would be wrong to apply them as interim patches? And if so, do you have better patches for me to try? Because if not.. Linus -- 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] rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
rtl_op_stop get wowlan state but rtl92cu_get_hw_reg has not process. Signed-off-by: Taehee Yoo --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index fe4b699..f6ad959 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -1589,6 +1589,12 @@ void rtl92cu_get_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val) case HW_VAR_DATA_FILTER: *((u16 *) (val)) = rtl_read_word(rtlpriv, REG_RXFLTMAP2); break; + case HAL_DEF_WOWLAN: + if (ppsc->wo_wlan_mode) + *((bool *)(val)) = true; + else + *((bool *)(val)) = false; + break; default: RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "switch case not processed\n"); -- 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] rtlwifi: rtl8188ee: missing curly braces in handle_branch1()
On 02/25/2015 07:24 AM, Dan Carpenter wrote:
From the indenting, it seems like the READ_NEXT_PAIR() was supposed to
be inside the while loop.
Signed-off-by: Dan Carpenter
Good catch.
Acked-by: Larry Finger
Thanks,
Larry
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
index 3f6c59c..a2bb02c 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
@@ -452,9 +452,10 @@ static void handle_branch1(struct ieee80211_hw *hw, u16
arraylen,
READ_NEXT_PAIR(v1, v2, i);
while (v2 != 0xDEAD &&
v2 != 0xCDEF &&
- v2 != 0xCDCD && i < arraylen - 2)
+ v2 != 0xCDCD && i < arraylen - 2) {
_rtl8188e_config_bb_reg(hw, v1, v2);
READ_NEXT_PAIR(v1, v2, i);
+ }
while (v2 != 0xDEAD && i < arraylen - 2)
READ_NEXT_PAIR(v1, v2, i);
--
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 v7 2/3] cfg80211: Add API to change the indoor regulatory setting
Previously, the indoor setting configuration assumed that as
long as a station interface is connected, the indoor environment
setting does not change. However, this assumption is problematic
as:
- It is possible that a station interface is connected to a mobile
AP, e.g., softAP or a P2P GO, where it is possible that both the
station and the mobile AP move out of the indoor environment making
the indoor setting invalid. In such a case, user space has no way to
invalidate the setting.
- A station interface disconnection does not necessarily imply that
the device is no longer operating in an indoor environment, e.g.,
it is possible that the station interface is roaming but is still
stays indoor.
To handle the above, extend the indoor configuration API to allow
user space to indicate a change of indoor settings, and allow it to
indicate weather it controls the indoor setting, such that:
1. If the user space process explicitly indicates that it is going
to control the indoor setting, do not clear the indoor setting
internally, unless the socket is released. The user space process
should use the NL80211_ATTR_SOCKET_OWNER attribute in the command
to state that it is going to control the indoor setting.
2. Reset the indoor setting when restoring the regulatory settings in
case it is not owned by a user space process.
Signed-off-by: Ilan Peer
Signed-off-by: ArikX Nemtsov
---
include/uapi/linux/nl80211.h | 9 +++
net/wireless/nl80211.c | 15 +++-
net/wireless/reg.c | 58 +---
net/wireless/reg.h | 15 +++-
4 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 2dcf9bb..e59ea18 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1684,6 +1684,10 @@ enum nl80211_commands {
* If set during scheduled scan start then the new scan req will be
* owned by the netlink socket that created it and the scheduled scan will
* be stopped when the socket is closed.
+ * If set during configuration of regulatory indoor operation then the
+ * regulatory indoor configuration would be owned by the netlink socket
+ * that configured the indoor setting, and the indoor operation would be
+ * cleared when the socket is closed.
*
* @NL80211_ATTR_TDLS_INITIATOR: flag attribute indicating the current end is
* the TDLS link initiator.
@@ -1739,6 +1743,9 @@ enum nl80211_commands {
*
* @NL80211_ATTR_SCHED_SCAN_DELAY: delay before a scheduled scan (or a
* WoWLAN net-detect scan) is started, u32 in seconds.
+
+ * @NL80211_ATTR_REG_INDOOR: flag attribute, if set indicates that the device
+ * is operating in an indoor environment.
*
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
@@ -2107,6 +2114,8 @@ enum nl80211_attrs {
NL80211_ATTR_SCHED_SCAN_DELAY,
+ NL80211_ATTR_REG_INDOOR,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9c6e23e..16dbf38 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -399,6 +399,7 @@ static const struct nla_policy
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_WIPHY_SELF_MANAGED_REG] = { .type = NLA_FLAG },
[NL80211_ATTR_NETNS_FD] = { .type = NLA_U32 },
[NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
+ [NL80211_ATTR_REG_INDOOR] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -4958,7 +4959,10 @@ static int parse_reg_rule(struct nlattr *tb[],
static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
{
char *data = NULL;
+ bool is_indoor;
enum nl80211_user_reg_hint_type user_reg_hint_type;
+ u32 owner_nlportid = 0;
+
/*
* You should only get this when cfg80211 hasn't yet initialized
@@ -4984,7 +4988,11 @@ static int nl80211_req_set_reg(struct sk_buff *skb,
struct genl_info *info)
data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
return regulatory_hint_user(data, user_reg_hint_type);
case NL80211_USER_REG_HINT_INDOOR:
- return regulatory_hint_indoor_user();
+ is_indoor = !!info->attrs[NL80211_ATTR_REG_INDOOR];
+ if (info->attrs[NL80211_ATTR_SOCKET_OWNER])
+ owner_nlportid = info->snd_portid;
+
+ return regulatory_hint_indoor(is_indoor, owner_nlportid);
default:
return -EINVAL;
}
@@ -12767,6 +12775,11 @@ static int nl80211_netlink_notify(struct
notifier_block * nb,
rcu_read_unlock();
+ /*
+* It is possible that the user space process that is controlling the
+* indoor setting disappeared, so notify t
[PATCH v7 3/3] cfg80211: Schedule timeout for all CRDA calls
Timeout was scheduled only in case CRDA was called due to user hints,
but was not scheduled for other cases. This can result in regulatory
hint processing getting stuck in case that there is no CRDA configured.
Change this by scheduling a timeout every time CRDA is called. In
addition, in restore_regulatory_settings() all pending requests are
restored (and not only the user ones).
Signed-off-by: Ilan Peer
---
net/wireless/reg.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 4ccf563..442bb52 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -552,6 +552,9 @@ reg_call_crda(struct regulatory_request *request)
{
if (call_crda(request->alpha2))
return REG_REQ_IGNORE;
+
+ queue_delayed_work(system_power_efficient_wq,
+ ®_timeout, msecs_to_jiffies(3142));
return REG_REQ_OK;
}
@@ -1791,8 +1794,7 @@ static void reg_set_request_processed(void)
need_more_processing = true;
spin_unlock(®_requests_lock);
- if (lr->initiator == NL80211_REGDOM_SET_BY_USER)
- cancel_delayed_work(®_timeout);
+ cancel_delayed_work(®_timeout);
if (need_more_processing)
schedule_work(®_work);
@@ -2071,8 +2073,6 @@ static void reg_process_hint(struct regulatory_request
*reg_request)
if (treatment == REG_REQ_IGNORE ||
treatment == REG_REQ_ALREADY_SET)
return;
- queue_delayed_work(system_power_efficient_wq,
- ®_timeout, msecs_to_jiffies(3142));
return;
case NL80211_REGDOM_SET_BY_DRIVER:
if (!wiphy)
@@ -2497,7 +2497,6 @@ static void restore_regulatory_settings(bool reset_user)
char alpha2[2];
char world_alpha2[2];
struct reg_beacon *reg_beacon, *btmp;
- struct regulatory_request *reg_request, *tmp;
LIST_HEAD(tmp_reg_req_list);
struct cfg80211_registered_device *rdev;
@@ -2525,11 +2524,7 @@ static void restore_regulatory_settings(bool reset_user)
* settings.
*/
spin_lock(®_requests_lock);
- list_for_each_entry_safe(reg_request, tmp, ®_requests_list, list) {
- if (reg_request->initiator != NL80211_REGDOM_SET_BY_USER)
- continue;
- list_move_tail(®_request->list, &tmp_reg_req_list);
- }
+ list_splice_tail_init(®_requests_list, &tmp_reg_req_list);
spin_unlock(®_requests_lock);
/* Clear beacon hints */
--
1.8.3.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
[PATCH v7 1/3] cfg80211: Simplify the handling of regulatory indoor setting
Directly update the indoor setting without wrapping it as
a regulatory request, to simplify the processing.
Signed-off-by: Ilan Peer
---
net/wireless/reg.c | 34 +++---
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index b586d0d..c24c8bf 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -82,17 +82,12 @@
* be intersected with the current one.
* @REG_REQ_ALREADY_SET: the regulatory request will not change the current
* regulatory settings, and no further processing is required.
- * @REG_REQ_USER_HINT_HANDLED: a non alpha2 user hint was handled and no
- * further processing is required, i.e., not need to update last_request
- * etc. This should be used for user hints that do not provide an alpha2
- * but some other type of regulatory hint, i.e., indoor operation.
*/
enum reg_request_treatment {
REG_REQ_OK,
REG_REQ_IGNORE,
REG_REQ_INTERSECT,
REG_REQ_ALREADY_SET,
- REG_REQ_USER_HINT_HANDLED,
};
static struct regulatory_request core_request_world = {
@@ -1248,13 +1243,6 @@ static bool reg_request_cell_base(struct
regulatory_request *request)
return request->user_reg_hint_type == NL80211_USER_REG_HINT_CELL_BASE;
}
-static bool reg_request_indoor(struct regulatory_request *request)
-{
- if (request->initiator != NL80211_REGDOM_SET_BY_USER)
- return false;
- return request->user_reg_hint_type == NL80211_USER_REG_HINT_INDOOR;
-}
-
bool reg_last_request_cell_base(void)
{
return reg_request_cell_base(get_last_request());
@@ -1833,11 +1821,6 @@ __reg_process_hint_user(struct regulatory_request
*user_request)
{
struct regulatory_request *lr = get_last_request();
- if (reg_request_indoor(user_request)) {
- reg_is_indoor = true;
- return REG_REQ_USER_HINT_HANDLED;
- }
-
if (reg_request_cell_base(user_request))
return reg_ignore_cell_hint(user_request);
@@ -1885,8 +1868,7 @@ reg_process_hint_user(struct regulatory_request
*user_request)
treatment = __reg_process_hint_user(user_request);
if (treatment == REG_REQ_IGNORE ||
- treatment == REG_REQ_ALREADY_SET ||
- treatment == REG_REQ_USER_HINT_HANDLED) {
+ treatment == REG_REQ_ALREADY_SET) {
reg_free_request(user_request);
return treatment;
}
@@ -1947,7 +1929,6 @@ reg_process_hint_driver(struct wiphy *wiphy,
case REG_REQ_OK:
break;
case REG_REQ_IGNORE:
- case REG_REQ_USER_HINT_HANDLED:
reg_free_request(driver_request);
return treatment;
case REG_REQ_INTERSECT:
@@ -2047,7 +2028,6 @@ reg_process_hint_country_ie(struct wiphy *wiphy,
case REG_REQ_OK:
break;
case REG_REQ_IGNORE:
- case REG_REQ_USER_HINT_HANDLED:
/* fall through */
case REG_REQ_ALREADY_SET:
reg_free_request(country_ie_request);
@@ -2086,8 +2066,7 @@ static void reg_process_hint(struct regulatory_request
*reg_request)
case NL80211_REGDOM_SET_BY_USER:
treatment = reg_process_hint_user(reg_request);
if (treatment == REG_REQ_IGNORE ||
- treatment == REG_REQ_ALREADY_SET ||
- treatment == REG_REQ_USER_HINT_HANDLED)
+ treatment == REG_REQ_ALREADY_SET)
return;
queue_delayed_work(system_power_efficient_wq,
®_timeout, msecs_to_jiffies(3142));
@@ -2311,16 +2290,9 @@ int regulatory_hint_user(const char *alpha2,
int regulatory_hint_indoor_user(void)
{
- struct regulatory_request *request;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
- if (!request)
- return -ENOMEM;
- request->wiphy_idx = WIPHY_IDX_INVALID;
- request->initiator = NL80211_REGDOM_SET_BY_USER;
- request->user_reg_hint_type = NL80211_USER_REG_HINT_INDOOR;
- queue_regulatory_request(request);
+ reg_is_indoor = true;
return 0;
}
--
1.8.3.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: [ath9k-devel] AR9462 problems connecting again..
On Tue, Feb 24, 2015 at 11:38:02PM +0100, Thomas Hühn wrote: > Minstrel_HT does only set mrr[0..2] and does not touch the fourth mrr[3], > assumed chips with 4 mrr stages. > In function minstrel_ht_update_rates() the rate table struct > ieee80211_sta_rates is set for the first 3 out of 4 rates and the fouth rate > (mrr[3]) is „-1“. Agreed. > In case of ath9k, the driver in xmit.c allocates in function > ath_tx_fill_desc() a struct ath_tx_info info by memset(&info, 0, > sizeof(info)) .. so all info->rates[xy].Rate == 0. > Than function ath_buf_set_rate() sets all info->rates[xy].Rate to those > values specified in the rate table (struct ieee8021_sta_rate) IF > (!rates[i].count || (rates[i].idx < 0)) … > … so info->rates[3].Rate is untouched and still „0“. Sure, it can be 0 and so is the number of tries at that rate.. > I just added a printk() to xmit.c in function ath_tx_fill_desc() just before > ath9k_hw_set_txdesc() is called. > From the log I get, e.g.: > > [ 169.543554] mrr setup: mrr[0]:133 mrr[1]:132 mrr[2]:134 mrr[3]:0 > > I have not check yet if info->rates[3].Rate == 0 is the lowest possible rate… > but I would guess so. It is not and even if it were, it does not matter since this 4th item is used for _0_ tries. I've verified the exact behavior with a sniffer for a case where the target device does not ACK frames. ath9k ends up sending at exactly the three different rates indicated in the first three values and nothing else. With RC probing (which happens to occur for the initial EAPOL frames, this results in only one attempt at MCS(>0) and two + two attempts at MCS0. No non-MCS rates are tried. As pointed out previously, this is likely fine for normal data frames, but not for EAPOL. -- Jouni MalinenPGP id EFC895FA -- 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: [ath9k-devel] AR9462 problems connecting again..
On Wed, Feb 25, 2015 at 06:00:08PM +1300, Felix Fietkau wrote: > Minstrel_ht does *NOT* use mrr[3], nor should it. For normal data > packets, a little packet loss under tough conditions is good, otherwise > we risk lots of wasted airtime and bufferbloat. I agree for normal data packets, but EAPOL frames are not really normal data packet even though they happen to be transmitted as Data frames. EAPOL frames are rare enough to not wast much airtime (and recovery from an issue would anyway use way more airtime) and bufferbloat is irrelevant for EAPOL frames. For EAPOL frames, little packet loss is not good. Especially for EAPOL-Key msg 4/4, the only recovery option in many cases is to reassociate with the AP and start from scratch. > > That mrr[3]:= basic_rate is the part I was really asking for as far as > > EAPOL frames are concerned. > I don't think we need that. If we just exclude EAPOL from both probing > and aggregation, it should be safe. While it's connecting, that leaves > in low rates in the retry chain anyway. Not low enough IMHO. EAPOL is a special case and needs to be addressed as such. It is special for at least two reasons: being very early in the association (well, the very _first_ Data frames using rate control) and being critical for maintaining the connection (AP will disconnect if it does not reply response). What happens now is way too optimistic: - one try at MCS 2 followed by four tries at MCS 0 for EAPOL-Key msg 2/4 - one try at MCS 9 (or so) followed by four tries at MCS 0 for EAPOL-Key msg 4/4 (this being the most critical frame in the connection sequence due to not having a good recovery mechanism) Dropping probing from these would allow one more attempt at the first rate and I guess it would also drop the first rate to somewhat lower. I'm fine with using these MCS rates as the first option, but I do think that we have to add one more rate to the end (or change the 3rd rate if that is easier for implementation) to be non-MCS and I think one of the basic rates (say, 6 Mbps on 5 GHz and maybe 2 or 5.5 Mbps on 2.4 GHz) with number of tries (say, 4). There have been way too many cases reported where "strange issues" with 4-way exchange (those EAPOL-Key frames) result in connection failing. While not all of these can be explained with the TX rate, I'm pretty sure large portion of these issues are indeed caused by too optimistic TX rate selection. Such policies may be acceptable for other Data frames, but not for EAPOL. > If it still fails often enough to be noticeable under normal conditions, > there must be something seriously wrong outside of rate control, and we > should not paper over it with a crude band-aid workaround. There may be something else wrong (say, some kind of interference), but there is no way we can assume normal users to be able to fix such issues. If we make EAPOL frames go through more robustly, the connection can be established in more cases and this can result in relatively functional network connection and rate control can handle the less critical data frames through whatever means to get optimal throughput from the network. As such, I do think we do need to "paper over" this for EAPOL frames. -- Jouni MalinenPGP id EFC895FA -- 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 v6 1/2] cfg80211: Add API to change the indoor regulatory setting
Hi Luis, > -Original Message- > From: Luis R. Rodriguez [mailto:mcg...@suse.com] > Sent: Tuesday, February 24, 2015 02:03 > To: Peer, Ilan; Jouni Malinen > Cc: linux-wireless@vger.kernel.org; ArikX Nemtsov > Subject: Re: [PATCH v6 1/2] cfg80211: Add API to change the indoor > regulatory setting > > On Sat, Feb 21, 2015 at 10:57:10PM -0500, Ilan Peer wrote: > > Previously, the indoor setting configuration assumed that as long as a > > station interface is connected, the indoor environment setting does > > not change. However, this assumption is problematic > > as: > > > > - It is possible that a station interface is connected to a mobile > > AP, e.g., softAP or a P2P GO, where it is possible that both the > > station and the mobile AP move out of the indoor environment making > > the indoor setting invalid. In such a case, user space has no way to > > invalidate the setting. > > At the protocol level should we consider the need for a dynamic environment > change? Until then a change of environment likely should implicate an AP > disconnect, which is what Linux does. With your changes in place we could do > something even more graceful should the protocol allow for it. > Not sure I follow ... > For instance if the regulatory parameters for a country are the same for > indoor and outdoro a change in environment should not require a disconnect. > So you are suggesting to extend the mechanism to also indicate if a teardown of active interfaces is needed or not? And if so, not sure that this should be done by the kernel. > If the change was from a more restrictive environment to a more liberal set of > regulatory settings it could mean increasing TX power of the AP changing to a > channel which perhaps was not allowed before. > I think that such a flow needs to be handled in user-space by hostapd, which can leverage the proper mechanisms to do the change, e.g., eCSA. > If the change was from a less restrictive environment to a more restrictive > environment the AP might want to change channels for instance or reduce TX > power. > Same as above. For example, hostapd handles DFS related channel changes in user space. We also added flows to handle channel switch etc. in wpa_supplicant ... and I need to resubmit them to hostap. > While change in indoor/outdoor might be something silly to consider given > the likelihood of it being a common thing to happen that you change an AP > from indoor / outdoor regularly I'd consider instead the possibility to reuse > such a dynamic environment change notification for purposes of dynamic > environmental adjustments of BSSes. Typically BSSes settings are static but RF > environments change regularly so its silly to expect a BSS and its initial > Automatic Channel Selection algorithm to be corrrect during the lifetime of a > BSS. > > > - A station interface disconnection does not necessarily imply that > > the device is no longer operating in an indoor environment, e.g., > > it is possible that the station interface is roaming but is still > > stays indoor. > > Sure. > > You also fail to explain how we currently provide the indoor thing to the > kernel, I think its worth providing that in the commit log and also explaining > how we don't use the country IE environment thing at all. > I explained some of the use cases in previous patches, e.g., AC power, device type etc. I can add this, but I do not understand how country IE is related here. > > To handle the above, extend the indoor configuration API to allow user > > space to indicate a change of indoor settings, and allow it to > > indicate weather it controls the indoor setting, such that: > > > > 1. If the user space process explicitly indicates that it is going > >to control the indoor setting, do not clear the indoor setting > >internally, unless the socket is released. The user space process > >should use the NL80211_ATTR_SOCKET_OWNER attribute in the command > >to state that it is going to control the indoor setting. > > 2. Reset the indoor setting when restoring the regulatory settings in > >case it is not owned by a user space process. > > > > While at it directly update the indoor setting without wrapping it as > > a regulatory request, to simplify the processing. > > Please wrap that specific change into its own separate commit, it will make it > easier to review the changes and also make this change atomic. > Ok. Thanks, Ilan. -- 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] rtlwifi: rtl8188ee: missing curly braces in handle_branch1()
>From the indenting, it seems like the READ_NEXT_PAIR() was supposed to
be inside the while loop.
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
index 3f6c59c..a2bb02c 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
@@ -452,9 +452,10 @@ static void handle_branch1(struct ieee80211_hw *hw, u16
arraylen,
READ_NEXT_PAIR(v1, v2, i);
while (v2 != 0xDEAD &&
v2 != 0xCDEF &&
- v2 != 0xCDCD && i < arraylen - 2)
+ v2 != 0xCDCD && i < arraylen - 2) {
_rtl8188e_config_bb_reg(hw, v1, v2);
READ_NEXT_PAIR(v1, v2, i);
+ }
while (v2 != 0xDEAD && i < arraylen - 2)
READ_NEXT_PAIR(v1, v2, i);
--
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
[RFCv2 2/4] ath10k: add WOW disconnect/magic-packet support
Add support for WOW disconnect and magic-packet.
Signed-off-by: Janusz Dziedzic
---
drivers/net/wireless/ath/ath10k/Makefile | 1 +
drivers/net/wireless/ath/ath10k/core.c | 1 +
drivers/net/wireless/ath/ath10k/core.h | 8 +
drivers/net/wireless/ath/ath10k/mac.c| 75 +
drivers/net/wireless/ath/ath10k/wmi.c| 14 +-
drivers/net/wireless/ath/ath10k/wow.c| 280 +++
drivers/net/wireless/ath/ath10k/wow.h| 34
7 files changed, 346 insertions(+), 67 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath10k/wow.c
create mode 100644 drivers/net/wireless/ath/ath10k/wow.h
diff --git a/drivers/net/wireless/ath/ath10k/Makefile
b/drivers/net/wireless/ath/ath10k/Makefile
index f4dbb3e..8eb9424 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -17,6 +17,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
ath10k_core-$(CONFIG_THERMAL) += thermal.o
ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
+ath10k_core-$(CONFIG_PM) += wow.o
obj-$(CONFIG_ATH10K_PCI) += ath10k_pci.o
ath10k_pci-y += pci.o \
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 310e12b..39bf8fb 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1386,6 +1386,7 @@ struct ath10k *ath10k_core_create(size_t priv_size,
struct device *dev,
init_completion(&ar->scan.completed);
init_completion(&ar->scan.on_channel);
init_completion(&ar->target_suspend);
+ init_completion(&ar->wow.wakeup_completed);
init_completion(&ar->install_key_done);
init_completion(&ar->vdev_setup_done);
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 7cba781..cd56586 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -35,6 +35,7 @@
#include "../dfs_pattern_detector.h"
#include "spectral.h"
#include "thermal.h"
+#include "wow.h"
#define MS(_v, _f) (((_v) & _f##_MASK) >> _f##_LSB)
#define SM(_v, _f) (((_v) << _f##_LSB) & _f##_MASK)
@@ -433,6 +434,12 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_WMI_10_2 = 4,
+ /* Some firmware revisions have an incomplete WoWLAN implementation
+* despite WMI service bit being advertised. This feature flag is used
+* to distinguish whether WoWLAN is really supported or not.
+*/
+ ATH10K_FW_FEATURE_WOWLAN_SUPPORT = 6,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
@@ -679,6 +686,7 @@ struct ath10k {
} stats;
struct ath10k_thermal thermal;
+ struct ath10k_wow wow;
/* must be last */
u8 drv_priv[0] __aligned(sizeof(void *));
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 842b10b..04c68d4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -29,6 +29,7 @@
#include "testmode.h"
#include "wmi.h"
#include "wmi-ops.h"
+#include "wow.h"
/**/
/* Crypto */
@@ -4475,70 +4476,6 @@ static int ath10k_tx_last_beacon(struct ieee80211_hw *hw)
return 1;
}
-#ifdef CONFIG_PM
-static int ath10k_suspend(struct ieee80211_hw *hw,
- struct cfg80211_wowlan *wowlan)
-{
- struct ath10k *ar = hw->priv;
- int ret;
-
- mutex_lock(&ar->conf_mutex);
-
- ret = ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND);
- if (ret) {
- if (ret == -ETIMEDOUT)
- goto resume;
- ret = 1;
- goto exit;
- }
-
- ret = ath10k_hif_suspend(ar);
- if (ret) {
- ath10k_warn(ar, "failed to suspend hif: %d\n", ret);
- goto resume;
- }
-
- ret = 0;
- goto exit;
-resume:
- ret = ath10k_wmi_pdev_resume_target(ar);
- if (ret)
- ath10k_warn(ar, "failed to resume target: %d\n", ret);
-
- ret = 1;
-exit:
- mutex_unlock(&ar->conf_mutex);
- return ret;
-}
-
-static int ath10k_resume(struct ieee80211_hw *hw)
-{
- struct ath10k *ar = hw->priv;
- int ret;
-
- mutex_lock(&ar->conf_mutex);
-
- ret = ath10k_hif_resume(ar);
- if (ret) {
- ath10k_warn(ar, "failed to resume hif: %d\n", ret);
- ret = 1;
- goto exit;
- }
-
- ret = ath10k_wmi_pdev_resume_target(ar);
- if (ret) {
- ath10k_warn(ar, "failed to resume target: %d\n", ret);
- ret = 1;
- goto exit;
- }
-
- ret = 0;
-exit:
- mutex_unlock(&ar->conf_mutex);
- return ret;
-}
-#endif
-
static void ath10k_reconfig_complete(struct ieee80211_hw *hw,
enum ieee80211_reconfig_type reconfig_type)
{
@@
[RFCv2 1/4] ath10k: add WMI support for WOW
Add WMI support for WOW like enable,
wakeup events and host wakeup indication.
Signed-off-by: Janusz Dziedzic
---
drivers/net/wireless/ath/ath10k/wmi-ops.h | 70 +++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 116 +++-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 21 +
drivers/net/wireless/ath/ath10k/wmi.h | 144 ++
4 files changed, 349 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index c8b64e7..1dee6ed 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -45,6 +45,8 @@ struct wmi_ops {
struct wmi_rdy_ev_arg *arg);
int (*pull_fw_stats)(struct ath10k *ar, struct sk_buff *skb,
struct ath10k_fw_stats *stats);
+ int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
+ struct wmi_wow_ev_arg *arg);
struct sk_buff *(*gen_pdev_suspend)(struct ath10k *ar, u32 suspend_opt);
struct sk_buff *(*gen_pdev_resume)(struct ath10k *ar);
@@ -148,6 +150,11 @@ struct wmi_ops {
u32 num_ac);
struct sk_buff *(*gen_sta_keepalive)(struct ath10k *ar,
const struct wmi_sta_keepalive_arg
*arg);
+ struct sk_buff *(*gen_wow_enable)(struct ath10k *ar);
+ struct sk_buff *(*gen_wow_add_wakeup_event)(struct ath10k *ar, u32
vdev_id,
+ enum wmi_wow_wakeup_event
event,
+ u32 enable);
+ struct sk_buff *(*gen_wow_host_wakeup_ind)(struct ath10k *ar);
};
int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id);
@@ -274,6 +281,16 @@ ath10k_wmi_pull_fw_stats(struct ath10k *ar, struct sk_buff
*skb,
}
static inline int
+ath10k_wmi_pull_wow_event(struct ath10k *ar, struct sk_buff *skb,
+ struct wmi_wow_ev_arg *arg)
+{
+ if (!ar->wmi.ops->pull_wow_event)
+ return -EOPNOTSUPP;
+
+ return ar->wmi.ops->pull_wow_event(ar, skb, arg);
+}
+
+static inline int
ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(msdu);
@@ -1060,4 +1077,57 @@ ath10k_wmi_sta_keepalive(struct ath10k *ar,
return ath10k_wmi_cmd_send(ar, skb, cmd_id);
}
+static inline int
+ath10k_wmi_wow_enable(struct ath10k *ar)
+{
+ struct sk_buff *skb;
+ u32 cmd_id;
+
+ if (!ar->wmi.ops->gen_wow_enable)
+ return -EOPNOTSUPP;
+
+ skb = ar->wmi.ops->gen_wow_enable(ar);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ cmd_id = ar->wmi.cmd->wow_enable_cmdid;
+ return ath10k_wmi_cmd_send(ar, skb, cmd_id);
+}
+
+static inline int
+ath10k_wmi_wow_add_wakeup_event(struct ath10k *ar, u32 vdev_id,
+ enum wmi_wow_wakeup_event event,
+ u32 enable)
+{
+ struct sk_buff *skb;
+ u32 cmd_id;
+
+ if (!ar->wmi.ops->gen_wow_add_wakeup_event)
+ return -EOPNOTSUPP;
+
+ skb = ar->wmi.ops->gen_wow_add_wakeup_event(ar, vdev_id, event, enable);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ cmd_id = ar->wmi.cmd->wow_enable_disable_wake_event_cmdid;
+ return ath10k_wmi_cmd_send(ar, skb, cmd_id);
+}
+
+static inline int
+ath10k_wmi_wow_host_wakeup_ind(struct ath10k *ar)
+{
+ struct sk_buff *skb;
+ u32 cmd_id;
+
+ if (!ar->wmi.ops->gen_wow_host_wakeup_ind)
+ return -EOPNOTSUPP;
+
+ skb = ar->wmi.ops->gen_wow_host_wakeup_ind(ar);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ cmd_id = ar->wmi.cmd->wow_hostwakeup_from_sleep_cmdid;
+ return ath10k_wmi_cmd_send(ar, skb, cmd_id);
+}
+
#endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index ebd1c45..3b40a13 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -31,9 +31,9 @@ struct wmi_tlv_policy {
static const struct wmi_tlv_policy wmi_tlv_policies[] = {
[WMI_TLV_TAG_ARRAY_BYTE]
- = { .min_len = sizeof(u8) },
+ = { .min_len = 0 },
[WMI_TLV_TAG_ARRAY_UINT32]
- = { .min_len = sizeof(u32) },
+ = { .min_len = 0 },
[WMI_TLV_TAG_STRUCT_SCAN_EVENT]
= { .min_len = sizeof(struct wmi_scan_event) },
[WMI_TLV_TAG_STRUCT_MGMT_RX_HDR]
@@ -62,6 +62,8 @@ static const struct wmi_tlv_policy wmi_tlv_policies[] = {
= { .min_len = sizeof(struct wmi_tlv_bcn_tx_status_ev) },
[WMI_TLV_TAG_STRUCT_DIAG_DATA_CONTAINER_EVENT]
= { .min_len = sizeof(struct wmi_tlv_diag_data_ev) },
+ [WMI_TLV_TAG_ST
[RFCv2 4/4] ath10k: add WOW patterns support
Add patterns support for WOW.
Signed-off-by: Janusz Dziedzic
---
drivers/net/wireless/ath/ath10k/core.c| 1 +
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.h | 4 +++
drivers/net/wireless/ath/ath10k/wow.c | 49 ++-
drivers/net/wireless/ath/ath10k/wow.h | 1 +
6 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 39bf8fb..5bcf83ff 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -972,6 +972,7 @@ static int ath10k_core_init_firmware_features(struct ath10k
*ar)
ar->max_num_stations = TARGET_TLV_NUM_STATIONS;
ar->max_num_vdevs = TARGET_TLV_NUM_VDEVS;
ar->htt.max_num_pending_tx = TARGET_TLV_NUM_MSDU_DESC;
+ ar->wow.max_num_patterns = TARGET_TLV_NUM_WOW_PATTERNS;
break;
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index 460771f..a06291b 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -263,6 +263,7 @@ struct ath10k_pktlog_hdr {
2)
#define TARGET_TLV_NUM_TIDS((TARGET_TLV_NUM_PEERS) * 2)
#define TARGET_TLV_NUM_MSDU_DESC (1024 + 32)
+#define TARGET_TLV_NUM_WOW_PATTERNS22
/* Number of Copy Engines supported */
#define CE_COUNT 8
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index deed5da..d8e20c6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1229,7 +1229,7 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_init(struct
ath10k *ar)
cfg->num_tdls_conn_table_entries = __cpu_to_le32(0x20);
cfg->beacon_tx_offload_max_vdev = __cpu_to_le32(2);
cfg->num_multicast_filter_entries = __cpu_to_le32(5);
- cfg->num_wow_filters = __cpu_to_le32(0x16);
+ cfg->num_wow_filters = __cpu_to_le32(ar->wow.max_num_patterns);
cfg->num_keep_alive_pattern = __cpu_to_le32(6);
cfg->keep_alive_pattern_size = __cpu_to_le32(0);
cfg->max_tdls_concurrent_sleep_sta = __cpu_to_le32(1);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 7e0c9eb..b985dfd 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5005,6 +5005,10 @@ struct wmi_wow_ev_arg {
u32 data_len;
};
+#define WOW_MIN_PATTERN_SIZE 1
+#define WOW_MAX_PATTERN_SIZE 148
+#define WOW_MAX_PKT_OFFSET 128
+
struct ath10k;
struct ath10k_vif;
struct ath10k_fw_stats_pdev;
diff --git a/drivers/net/wireless/ath/ath10k/wow.c
b/drivers/net/wireless/ath/ath10k/wow.c
index 77c2b4d..5c95fa4 100644
--- a/drivers/net/wireless/ath/ath10k/wow.c
+++ b/drivers/net/wireless/ath/ath10k/wow.c
@@ -23,9 +23,15 @@
#include "wmi.h"
#include "wmi-ops.h"
-static const struct wiphy_wowlan_support ath10k_wowlan_support = {
+static struct wiphy_wowlan_support ath10k_wowlan_support = {
.flags = WIPHY_WOWLAN_DISCONNECT |
WIPHY_WOWLAN_MAGIC_PKT,
+ /* .n_patterns is set during driver runtime
+* per hw/fw capabilities
+*/
+ .pattern_min_len = WOW_MIN_PATTERN_SIZE,
+ .pattern_max_len = WOW_MAX_PATTERN_SIZE,
+ .max_pkt_offset = WOW_MAX_PKT_OFFSET,
};
static int ath10k_wow_vif_cleanup(struct ath10k_vif *arvif)
@@ -42,6 +48,15 @@ static int ath10k_wow_vif_cleanup(struct ath10k_vif *arvif)
}
}
+ for (i = 0; i < ar->wow.max_num_patterns; i++) {
+ ret = ath10k_wmi_wow_del_pattern(ar, arvif->vdev_id, i);
+ if (ret) {
+ ath10k_warn(ar, "failed to delete wow pattern %d for
vdev %i: %d\n",
+ i, arvif->vdev_id, ret);
+ return ret;
+ }
+ }
+
return 0;
}
@@ -70,6 +85,8 @@ static int ath10k_vif_wow_set_wakeups(struct ath10k_vif
*arvif,
int ret, i;
unsigned long wow_mask = 0;
struct ath10k *ar = arvif->ar;
+ const struct cfg80211_pkt_pattern *patterns = wowlan->patterns;
+ int pattern_id = 0;
/* Setup requested WOW features */
switch (arvif->vdev_type) {
@@ -100,6 +117,35 @@ static int ath10k_vif_wow_set_wakeups(struct ath10k_vif
*arvif,
break;
}
+ for (i = 0; i < wowlan->n_patterns; i++) {
+ u8 bitmask[WOW_MAX_PATTERN_SIZE] = {};
+ int j;
+
+ if (patterns[i].pattern_len > WOW_MAX_PATTERN_SIZE)
+ continue;
+
+ /* convert bytema
[RFCv2 3/4] ath10k: add WMI support for WOW patterns
Add WMI support for WOW patterns.
Signed-off-by: Janusz Dziedzic
---
drivers/net/wireless/ath/ath10k/wmi-ops.h | 45 +++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 130 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 38 +
3 files changed, 213 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 1dee6ed..f038551 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -155,6 +155,14 @@ struct wmi_ops {
enum wmi_wow_wakeup_event
event,
u32 enable);
struct sk_buff *(*gen_wow_host_wakeup_ind)(struct ath10k *ar);
+ struct sk_buff *(*gen_wow_add_pattern)(struct ath10k *ar, u32 vdev_id,
+ u32 pattern_id,
+ const u8 *pattern,
+ const u8 *mask,
+ int pattern_len,
+ int pattern_offset);
+ struct sk_buff *(*gen_wow_del_pattern)(struct ath10k *ar, u32 vdev_id,
+ u32 pattern_id);
};
int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id);
@@ -1130,4 +1138,41 @@ ath10k_wmi_wow_host_wakeup_ind(struct ath10k *ar)
return ath10k_wmi_cmd_send(ar, skb, cmd_id);
}
+static inline int
+ath10k_wmi_wow_add_pattern(struct ath10k *ar, u32 vdev_id, u32 pattern_id,
+ const u8 *pattern, const u8 *mask,
+ int pattern_len, int pattern_offset)
+{
+ struct sk_buff *skb;
+ u32 cmd_id;
+
+ if (!ar->wmi.ops->gen_wow_add_pattern)
+ return -EOPNOTSUPP;
+
+ skb = ar->wmi.ops->gen_wow_add_pattern(ar, vdev_id, pattern_id,
+ pattern, mask, pattern_len,
+ pattern_offset);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ cmd_id = ar->wmi.cmd->wow_add_wake_pattern_cmdid;
+ return ath10k_wmi_cmd_send(ar, skb, cmd_id);
+}
+
+static inline int
+ath10k_wmi_wow_del_pattern(struct ath10k *ar, u32 vdev_id, u32 pattern_id)
+{
+ struct sk_buff *skb;
+ u32 cmd_id;
+
+ if (!ar->wmi.ops->gen_wow_del_pattern)
+ return -EOPNOTSUPP;
+
+ skb = ar->wmi.ops->gen_wow_del_pattern(ar, vdev_id, pattern_id);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ cmd_id = ar->wmi.cmd->wow_del_wake_pattern_cmdid;
+ return ath10k_wmi_cmd_send(ar, skb, cmd_id);
+}
#endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 3b40a13..deed5da 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2601,6 +2601,134 @@ ath10k_wmi_tlv_gen_wow_host_wakeup_ind(struct ath10k
*ar)
return skb;
}
+static struct sk_buff *
+ath10k_wmi_tlv_op_gen_wow_add_pattern(struct ath10k *ar, u32 vdev_id,
+ u32 pattern_id, const u8 *pattern,
+ const u8 *bitmask, int pattern_len,
+ int pattern_offset)
+{
+ struct wmi_tlv_wow_add_pattern_cmd *cmd;
+ struct wmi_tlv_wow_bitmap_pattern *bitmap;
+ struct wmi_tlv *tlv;
+ struct sk_buff *skb;
+ void *ptr;
+ size_t len;
+
+ len = sizeof(*tlv) + sizeof(*cmd) +
+ sizeof(*tlv) +/* array struct */
+ sizeof(*tlv) + sizeof(*bitmap) + /* bitmap */
+ sizeof(*tlv) +/* empty ipv4 sync */
+ sizeof(*tlv) +/* empty ipv6 sync */
+ sizeof(*tlv) +/* empty magic */
+ sizeof(*tlv) +/* empty info timeout */
+ sizeof(*tlv) + sizeof(u32); /* ratelimit interval */
+
+ skb = ath10k_wmi_alloc_skb(ar, len);
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
+
+ /* cmd */
+ ptr = (void *)skb->data;
+ tlv = ptr;
+ tlv->tag = __cpu_to_le16(WMI_TLV_TAG_STRUCT_WOW_ADD_PATTERN_CMD);
+ tlv->len = __cpu_to_le16(sizeof(*cmd));
+ cmd = (void *)tlv->value;
+
+ cmd->vdev_id = __cpu_to_le32(vdev_id);
+ cmd->pattern_id = __cpu_to_le32(pattern_id);
+ cmd->pattern_type = __cpu_to_le32(WOW_BITMAP_PATTERN);
+
+ ptr += sizeof(*tlv);
+ ptr += sizeof(*cmd);
+
+ /* bitmap */
+ tlv = ptr;
+ tlv->tag = __cpu_to_le16(WMI_TLV_TAG_ARRAY_STRUCT);
+ tlv->len = __cpu_to_le16(sizeof(*tlv) + sizeof(*bitmap));
+
+ ptr += sizeof(*tlv);
+
+ tlv = ptr;
+ tlv->tag = __cpu_to_le16(WMI_TLV_TAG_STRUCT_WOW_BITM
Re: brcmfmac43241b4-sdio / Thinkpad Tablet 10 issues
Sebastien Bourdeauducq writes: > > On Tuesday, February 17, 2015 03:49 AM, Arend van Spriel wrote: > > So it is a one-off and not showing the issue you are seeing. Your issue > > seems to be due to failing firmware so you may need b5 firmware. > > Making some progress :) > ... > I guess that the driver has bugs with decoding some of the data sent by > the card. > I can confirm this with my Thinkpad Tablet 8 which has same chip revision. Arend: do you need anything else to be tested? /JockyW -- 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 4/4] mwifiex: preprocess packets from TX queue
From: Zhaoyang Liu
During profiling, we discovered that driver remains idle for time
when pakcet is downloaded to FW but no TX_DONE has been received
i.e. while data_sent is true.
This patch adds enhancement to TX routine where we preprocess
packets from TX queue, make them ready for TX and add them to
separate TX queue.
Signed-off-by: Zhaoyang Liu
Signed-off-by: Marc Yang
Signed-off-by: Cathy Luo
Signed-off-by: Amitkumar Karwar
Signed-off-by: Avinash Patil
---
drivers/net/wireless/mwifiex/11n_aggr.c | 14 +++-
drivers/net/wireless/mwifiex/decl.h | 2 +
drivers/net/wireless/mwifiex/init.c | 5 ++
drivers/net/wireless/mwifiex/main.c | 31 ++--
drivers/net/wireless/mwifiex/main.h | 6 ++
drivers/net/wireless/mwifiex/txrx.c | 126
drivers/net/wireless/mwifiex/wmm.c | 20 -
7 files changed, 189 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/11n_aggr.c
b/drivers/net/wireless/mwifiex/11n_aggr.c
index 9b983b5..d8558a6 100644
--- a/drivers/net/wireless/mwifiex/11n_aggr.c
+++ b/drivers/net/wireless/mwifiex/11n_aggr.c
@@ -175,6 +175,7 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
struct txpd *ptx_pd = NULL;
struct timeval tv;
int headroom = adapter->iface_type == MWIFIEX_USB ? 0 : INTF_HEADER_LEN;
+ int aggr_num = 0;
skb_src = skb_peek(&pra_list->skb_head);
if (!skb_src) {
@@ -200,7 +201,8 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
if (tx_info_src->flags & MWIFIEX_BUF_FLAG_TDLS_PKT)
tx_info_aggr->flags |= MWIFIEX_BUF_FLAG_TDLS_PKT;
- skb_aggr->priority = skb_src->priority;
+ tx_info_aggr->flags |= MWIFIEX_BUF_FLAG_AGGR_PKT;
+ skb_aggr->priority = skb_src->priority;
do_gettimeofday(&tv);
skb_aggr->tstamp = timeval_to_ktime(tv);
@@ -211,11 +213,9 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
break;
skb_src = skb_dequeue(&pra_list->skb_head);
-
pra_list->total_pkt_count--;
-
atomic_dec(&priv->wmm.tx_pkts_queued);
-
+ aggr_num++;
spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
ra_list_flags);
mwifiex_11n_form_amsdu_pkt(skb_aggr, skb_src, &pad);
@@ -251,6 +251,12 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
ptx_pd = (struct txpd *)skb_aggr->data;
skb_push(skb_aggr, headroom);
+ tx_info_aggr->aggr_num = aggr_num;
+ if (adapter->data_sent || adapter->tx_lock_flag) {
+ atomic_add(aggr_num, &adapter->tx_queued);
+ skb_queue_tail(&adapter->tx_data_q, skb_aggr);
+ return 0;
+ }
if (adapter->iface_type == MWIFIEX_USB) {
adapter->data_sent = true;
diff --git a/drivers/net/wireless/mwifiex/decl.h
b/drivers/net/wireless/mwifiex/decl.h
index cf2fa11..f530207 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -83,6 +83,7 @@
#define MWIFIEX_BUF_FLAG_TDLS_PKT BIT(2)
#define MWIFIEX_BUF_FLAG_EAPOL_TX_STATUS BIT(3)
#define MWIFIEX_BUF_FLAG_ACTION_TX_STATUS BIT(4)
+#define MWIFIEX_BUF_FLAG_AGGR_PKT BIT(5)
#define MWIFIEX_BRIDGED_PKTS_THR_HIGH 1024
#define MWIFIEX_BRIDGED_PKTS_THR_LOW128
@@ -179,6 +180,7 @@ struct mwifiex_txinfo {
u8 flags;
u8 bss_num;
u8 bss_type;
+ u8 aggr_num;
u32 pkt_len;
u8 ack_frame_id;
u64 cookie;
diff --git a/drivers/net/wireless/mwifiex/init.c
b/drivers/net/wireless/mwifiex/init.c
index 2e1df02..2f278a6 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -481,6 +481,7 @@ int mwifiex_init_lock_list(struct mwifiex_adapter *adapter)
spin_lock_init(&adapter->rx_proc_lock);
skb_queue_head_init(&adapter->rx_data_q);
+ skb_queue_head_init(&adapter->tx_data_q);
for (i = 0; i < adapter->priv_num; ++i) {
INIT_LIST_HEAD(&adapter->bss_prio_tbl[i].bss_prio_head);
@@ -688,6 +689,10 @@ mwifiex_shutdown_drv(struct mwifiex_adapter *adapter)
}
}
+ atomic_set(&adapter->tx_queued, 0);
+ while ((skb = skb_dequeue(&adapter->tx_data_q)))
+ mwifiex_write_data_complete(adapter, skb, 0, 0);
+
spin_lock_irqsave(&adapter->rx_proc_lock, flags);
while ((skb = skb_dequeue(&adapter->rx_data_q))) {
diff --git a/drivers/net/wireless/mwifiex/main.c
b/drivers/net/wireless/mwifiex/main.c
index 46e1789..dcc32c1 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -259,10 +259,11 @@ process_start:
/* Need to wake up the card ? */
if ((adapter->ps_state == PS_STATE_SLEEP) &&
- (adapter->pm_wakeup_card_req &
[PATCH 3/4] mwifiex: remove_bss_prio_lock
From: Zhaoyang Liu
This patch does away with spinlock in
mwifiex_wmm_get_highest_priolist_ptr in order to improve TP.
Signed-off-by: Zhaoyang Liu
Signed-off-by: Shengzhen Li
Signed-off-by: Cathy Luo
Signed-off-by: Amitkumar Karwar
Signed-off-by: Avinash Patil
---
drivers/net/wireless/mwifiex/cfg80211.c | 33 +
drivers/net/wireless/mwifiex/main.c | 2 +-
drivers/net/wireless/mwifiex/main.h | 1 +
drivers/net/wireless/mwifiex/wmm.c | 11 ++-
4 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index 5f3c1d3..fb55092 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -717,6 +717,9 @@ mwifiex_cfg80211_init_p2p_go(struct mwifiex_private *priv)
static int mwifiex_deinit_priv_params(struct mwifiex_private *priv)
{
+ struct mwifiex_adapter *adapter = priv->adapter;
+ unsigned long flags;
+
priv->mgmt_frame_mask = 0;
if (mwifiex_send_cmd(priv, HostCmd_CMD_MGMT_FRAME_REG,
HostCmd_ACT_GEN_SET, 0,
@@ -727,6 +730,25 @@ static int mwifiex_deinit_priv_params(struct
mwifiex_private *priv)
}
mwifiex_deauthenticate(priv, NULL);
+
+ spin_lock_irqsave(&adapter->main_proc_lock, flags);
+ adapter->main_locked = true;
+ if (adapter->mwifiex_processing) {
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
+ flush_workqueue(adapter->workqueue);
+ } else {
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
+ }
+
+ spin_lock_irqsave(&adapter->rx_proc_lock, flags);
+ adapter->rx_locked = true;
+ if (adapter->rx_processing) {
+ spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
+ flush_workqueue(adapter->rx_workqueue);
+ } else {
+ spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
+ }
+
mwifiex_free_priv(priv);
priv->wdev.iftype = NL80211_IFTYPE_UNSPECIFIED;
priv->bss_mode = NL80211_IFTYPE_UNSPECIFIED;
@@ -740,6 +762,9 @@ mwifiex_init_new_priv_params(struct mwifiex_private *priv,
struct net_device *dev,
enum nl80211_iftype type)
{
+ struct mwifiex_adapter *adapter = priv->adapter;
+ unsigned long flags;
+
mwifiex_init_priv(priv);
priv->bss_mode = type;
@@ -770,6 +795,14 @@ mwifiex_init_new_priv_params(struct mwifiex_private *priv,
return -EOPNOTSUPP;
}
+ spin_lock_irqsave(&adapter->main_proc_lock, flags);
+ adapter->main_locked = false;
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
+
+ spin_lock_irqsave(&adapter->rx_proc_lock, flags);
+ adapter->rx_locked = false;
+ spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
+
return 0;
}
diff --git a/drivers/net/wireless/mwifiex/main.c
b/drivers/net/wireless/mwifiex/main.c
index 447eb6f..46e1789 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -217,7 +217,7 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
spin_lock_irqsave(&adapter->main_proc_lock, flags);
/* Check if already processing */
- if (adapter->mwifiex_processing) {
+ if (adapter->mwifiex_processing || adapter->main_locked) {
adapter->more_task_flag = true;
spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
goto exit_main_proc;
diff --git a/drivers/net/wireless/mwifiex/main.h
b/drivers/net/wireless/mwifiex/main.h
index b47bffa..cc6a623 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -773,6 +773,7 @@ struct mwifiex_adapter {
bool rx_work_enabled;
bool rx_processing;
bool delay_main_work;
+ bool main_locked;
bool rx_locked;
struct mwifiex_bss_prio_tbl bss_prio_tbl[MWIFIEX_MAX_BSS_NUM];
/* spin lock for init/shutdown */
diff --git a/drivers/net/wireless/mwifiex/wmm.c
b/drivers/net/wireless/mwifiex/wmm.c
index ba75a45..ce747f7 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -944,14 +944,11 @@ mwifiex_wmm_get_highest_priolist_ptr(struct
mwifiex_adapter *adapter,
struct mwifiex_ra_list_tbl *ptr;
struct mwifiex_tid_tbl *tid_ptr;
atomic_t *hqp;
- unsigned long flags_bss, flags_ra;
+ unsigned long flags_ra;
int i, j;
/* check the BSS with highest priority first */
for (j = adapter->priv_num - 1; j >= 0; --j) {
- spin_lock_irqsave(&adapter->bss_prio_tbl[j].bss_prio_lock,
- flags_bss);
-
/* iterate over BSS with the equal priority */
list_for_each_entry(adapter->bss_prio_tb
[PATCH 2/4] mwifiex: get rid of BA setup helper functions
From: Zhaoyang Liu
This patch removes BA setup helper routines
mwifiex_is_bastream_setup and mwifiex_is_amsdu_in_ampdu_allowed.
Current code will use two functions to check bastream setup and
amsdu in ampdu. This patch change these functions to flags, thus
avoiding redundant spin_lock check while dequeuing TX packets.
Signed-off-by: Zhaoyang Liu
Signed-off-by: Shengzhen Li
Signed-off-by: Cathy Luo
Signed-off-by: Amitkumar Karwar
Signed-off-by: Avinash Patil
---
drivers/net/wireless/mwifiex/11n.c | 18 +++-
drivers/net/wireless/mwifiex/11n.h | 32
drivers/net/wireless/mwifiex/11n_rxreorder.c | 7 +-
drivers/net/wireless/mwifiex/main.h | 13 ++-
drivers/net/wireless/mwifiex/wmm.c | 18 +---
drivers/net/wireless/mwifiex/wmm.h | 2 ++
6 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/11n.c
b/drivers/net/wireless/mwifiex/11n.c
index 543148d..433bd68 100644
--- a/drivers/net/wireless/mwifiex/11n.c
+++ b/drivers/net/wireless/mwifiex/11n.c
@@ -159,6 +159,7 @@ int mwifiex_ret_11n_addba_req(struct mwifiex_private *priv,
int tid;
struct host_cmd_ds_11n_addba_rsp *add_ba_rsp = &resp->params.add_ba_rsp;
struct mwifiex_tx_ba_stream_tbl *tx_ba_tbl;
+ struct mwifiex_ra_list_tbl *ra_list;
u16 block_ack_param_set = le16_to_cpu(add_ba_rsp->block_ack_param_set);
add_ba_rsp->ssn = cpu_to_le16((le16_to_cpu(add_ba_rsp->ssn))
@@ -166,7 +167,13 @@ int mwifiex_ret_11n_addba_req(struct mwifiex_private *priv,
tid = (block_ack_param_set & IEEE80211_ADDBA_PARAM_TID_MASK)
>> BLOCKACKPARAM_TID_POS;
+ ra_list = mwifiex_wmm_get_ralist_node(priv, tid, add_ba_rsp->
+ peer_mac_addr);
if (le16_to_cpu(add_ba_rsp->status_code) != BA_RESULT_SUCCESS) {
+ if (ra_list) {
+ ra_list->ba_status = BA_SETUP_NONE;
+ ra_list->amsdu_in_ampdu = false;
+ }
mwifiex_del_ba_tbl(priv, tid, add_ba_rsp->peer_mac_addr,
TYPE_DELBA_SENT, true);
if (add_ba_rsp->add_rsp_result != BA_RESULT_TIMEOUT)
@@ -185,6 +192,10 @@ int mwifiex_ret_11n_addba_req(struct mwifiex_private *priv,
tx_ba_tbl->amsdu = true;
else
tx_ba_tbl->amsdu = false;
+ if (ra_list) {
+ ra_list->amsdu_in_ampdu = tx_ba_tbl->amsdu;
+ ra_list->ba_status = BA_SETUP_COMPLETE;
+ }
} else {
dev_err(priv->adapter->dev, "BA stream not created\n");
}
@@ -515,6 +526,7 @@ void mwifiex_create_ba_tbl(struct mwifiex_private *priv, u8
*ra, int tid,
enum mwifiex_ba_status ba_status)
{
struct mwifiex_tx_ba_stream_tbl *new_node;
+ struct mwifiex_ra_list_tbl *ra_list;
unsigned long flags;
if (!mwifiex_get_ba_tbl(priv, tid, ra)) {
@@ -522,7 +534,11 @@ void mwifiex_create_ba_tbl(struct mwifiex_private *priv,
u8 *ra, int tid,
GFP_ATOMIC);
if (!new_node)
return;
-
+ ra_list = mwifiex_wmm_get_ralist_node(priv, tid, ra);
+ if (ra_list) {
+ ra_list->ba_status = ba_status;
+ ra_list->amsdu_in_ampdu = false;
+ }
INIT_LIST_HEAD(&new_node->list);
new_node->tid = tid;
diff --git a/drivers/net/wireless/mwifiex/11n.h
b/drivers/net/wireless/mwifiex/11n.h
index 8e2e394..afdd58a 100644
--- a/drivers/net/wireless/mwifiex/11n.h
+++ b/drivers/net/wireless/mwifiex/11n.h
@@ -77,22 +77,6 @@ mwifiex_is_station_ampdu_allowed(struct mwifiex_private
*priv,
return (node->ampdu_sta[tid] != BA_STREAM_NOT_ALLOWED) ? true : false;
}
-/* This function checks whether AMSDU is allowed for BA stream. */
-static inline u8
-mwifiex_is_amsdu_in_ampdu_allowed(struct mwifiex_private *priv,
- struct mwifiex_ra_list_tbl *ptr, int tid)
-{
- struct mwifiex_tx_ba_stream_tbl *tx_tbl;
-
- if (is_broadcast_ether_addr(ptr->ra))
- return false;
- tx_tbl = mwifiex_get_ba_tbl(priv, tid, ptr->ra);
- if (tx_tbl)
- return tx_tbl->amsdu;
-
- return false;
-}
-
/* This function checks whether AMPDU is allowed or not for a particular TID.
*/
static inline u8
mwifiex_is_ampdu_allowed(struct mwifiex_private *priv,
@@ -182,22 +166,6 @@ mwifiex_find_stream_to_delete(struct mwifiex_private
*priv, int ptr_tid,
}
/*
- * This function checks whether BA stream is set up or not.
- */
-static inline int
-mwifiex_is_ba_stream_setup(struct mwifiex_private *priv,
- struct mwifiex_ra_list_tbl *ptr, int tid)
-{
- struct mwifiex_tx_ba_str
[PATCH 0/4] mwifiex: throughput enhancements for TX
This patch series includes patches which improve TX throughputs. Marc Yang (1): mwifiex: avoid queue_work while work is ongoing Zhaoyang Liu (3): mwifiex: get rid of BA setup helper functions mwifiex: remove_bss_prio_lock mwifiex: preprocess packets from TX queue drivers/net/wireless/mwifiex/11n.c | 18 +++- drivers/net/wireless/mwifiex/11n.h | 32 --- drivers/net/wireless/mwifiex/11n_aggr.c | 14 ++- drivers/net/wireless/mwifiex/11n_rxreorder.c | 7 +- drivers/net/wireless/mwifiex/cfg80211.c | 33 +++ drivers/net/wireless/mwifiex/decl.h | 2 + drivers/net/wireless/mwifiex/init.c | 5 ++ drivers/net/wireless/mwifiex/main.c | 71 --- drivers/net/wireless/mwifiex/main.h | 21 +++-- drivers/net/wireless/mwifiex/pcie.c | 2 +- drivers/net/wireless/mwifiex/txrx.c | 126 +++ drivers/net/wireless/mwifiex/usb.c | 4 +- drivers/net/wireless/mwifiex/wmm.c | 49 ++- drivers/net/wireless/mwifiex/wmm.h | 2 + 14 files changed, 305 insertions(+), 81 deletions(-) -- 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
[PATCH 1/4] mwifiex: avoid queue_work while work is ongoing
From: Marc Yang
Current code does not check whether main_work_queue or
rx_work_queue is running when preparing to do queue_work,
this code fix add check before calling queue_work, reducing
unnecessary queue_work switch.
This change instead sets more_task flag to ensure we run main_process
superloop once again.
Signed-off-by: Marc Yang
Signed-off-by: Zhaoyang Liu
Signed-off-by: Shengzhen Li
Signed-off-by: Cathy Luo
Signed-off-by: Amitkumar Karwar
Signed-off-by: Avinash Patil
---
drivers/net/wireless/mwifiex/main.c | 38 +++--
drivers/net/wireless/mwifiex/main.h | 1 +
drivers/net/wireless/mwifiex/pcie.c | 2 +-
drivers/net/wireless/mwifiex/usb.c | 4 ++--
4 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/main.c
b/drivers/net/wireless/mwifiex/main.c
index 74488ab..447eb6f 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -131,6 +131,34 @@ static int mwifiex_unregister(struct mwifiex_adapter
*adapter)
return 0;
}
+void mwifiex_queue_main_work(struct mwifiex_adapter *adapter)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&adapter->main_proc_lock, flags);
+ if (adapter->mwifiex_processing) {
+ adapter->more_task_flag = true;
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
+ } else {
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
+ queue_work(adapter->workqueue, &adapter->main_work);
+ }
+}
+EXPORT_SYMBOL_GPL(mwifiex_queue_main_work);
+
+static void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&adapter->rx_proc_lock, flags);
+ if (adapter->rx_processing) {
+ spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
+ } else {
+ spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
+ queue_work(adapter->rx_workqueue, &adapter->rx_work);
+ }
+}
+
static int mwifiex_process_rx(struct mwifiex_adapter *adapter)
{
unsigned long flags;
@@ -154,7 +182,7 @@ static int mwifiex_process_rx(struct mwifiex_adapter
*adapter)
if (adapter->if_ops.submit_rem_rx_urbs)
adapter->if_ops.submit_rem_rx_urbs(adapter);
adapter->delay_main_work = false;
- queue_work(adapter->workqueue, &adapter->main_work);
+ mwifiex_queue_main_work(adapter);
}
mwifiex_handle_rx_packet(adapter, skb);
}
@@ -214,9 +242,7 @@ process_start:
if (atomic_read(&adapter->rx_pending) >= HIGH_RX_PENDING &&
adapter->iface_type != MWIFIEX_USB) {
adapter->delay_main_work = true;
- if (!adapter->rx_processing)
- queue_work(adapter->rx_workqueue,
- &adapter->rx_work);
+ mwifiex_queue_rx_work(adapter);
break;
}
@@ -229,7 +255,7 @@ process_start:
}
if (adapter->rx_work_enabled && adapter->data_received)
- queue_work(adapter->rx_workqueue, &adapter->rx_work);
+ mwifiex_queue_rx_work(adapter);
/* Need to wake up the card ? */
if ((adapter->ps_state == PS_STATE_SLEEP) &&
@@ -606,7 +632,7 @@ int mwifiex_queue_tx_pkt(struct mwifiex_private *priv,
struct sk_buff *skb)
atomic_inc(&priv->adapter->tx_pending);
mwifiex_wmm_add_buf_txqueue(priv, skb);
- queue_work(priv->adapter->workqueue, &priv->adapter->main_work);
+ mwifiex_queue_main_work(priv->adapter);
return 0;
}
diff --git a/drivers/net/wireless/mwifiex/main.h
b/drivers/net/wireless/mwifiex/main.h
index 16be45e..801a23b 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -1422,6 +1422,7 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
void mwifiex_dump_drv_info(struct mwifiex_adapter *adapter);
void *mwifiex_alloc_rx_buf(int rx_len, gfp_t flags);
+void mwifiex_queue_main_work(struct mwifiex_adapter *adapter);
#ifdef CONFIG_DEBUG_FS
void mwifiex_debugfs_init(void);
diff --git a/drivers/net/wireless/mwifiex/pcie.c
b/drivers/net/wireless/mwifiex/pcie.c
index 4b463c3..c0ff33e 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -2101,7 +2101,7 @@ static irqreturn_t mwifiex_pcie_interrupt(int irq, void
*context)
goto exit;
mwifiex_interrupt_status(adapter);
- queue_work(adapter->workqueue, &adapter->main_work);
+ mwifiex_queue_main_work(adapter);
exit:
return IRQ_HANDLED;
diff --git a/drivers/net/wireless/mwifiex/usb.c
b/drivers/net/wireless/mwifiex/usb.c
index 22
[PATCH] mwifiex: do not initialize ext_scan in mwifiex_init_adapter
Features which are device specific are already updated in interface specific initialization e.g. register_dev. We should not initialize them in mwifiex_init_adapter(); else this would overwrite earlier settings. Signed-off-by: Avinash Patil Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/mwifiex/init.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c index b77ba74..2e1df02 100644 --- a/drivers/net/wireless/mwifiex/init.c +++ b/drivers/net/wireless/mwifiex/init.c @@ -296,7 +296,6 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter) memset(&adapter->arp_filter, 0, sizeof(adapter->arp_filter)); adapter->arp_filter_size = 0; adapter->max_mgmt_ie_index = MAX_MGMT_IE_INDEX; - adapter->ext_scan = false; adapter->key_api_major_ver = 0; adapter->key_api_minor_ver = 0; memset(adapter->perm_addr, 0xff, ETH_ALEN); -- 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
[PATCH] ath10k: fix ap u-apsd cmd on qca6174 w/ wmi-tlv
The command was truncated so the parameter value was seen in fw as 0. This caused U-APSD enabled stations to be misconfigured and mistreated by AP. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c index f34baa0..af5d858 100644 --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c @@ -2032,7 +2032,7 @@ ath10k_wmi_tlv_op_gen_set_ap_ps(struct ath10k *ar, u32 vdev_id, const u8 *mac, if (!mac) return ERR_PTR(-EINVAL); - skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd)); + skb = ath10k_wmi_alloc_skb(ar, sizeof(*tlv) + sizeof(*cmd)); if (!skb) return ERR_PTR(-ENOMEM); -- 1.8.5.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: [PATCH v3] wext: Return -E2BIG when the buffer is too small for the full scan results, including IEs.
On Tue, 2015-02-24 at 12:58 -0600, James Minor wrote: > When using the wext compatibility code in cfg80211, part of the IEs > can be truncated if the passed user buffer is large enough for the > BSS but not large enough for all of the IEs. This can cause an EAP > network to show up as a PSK network. > > These changes allow the scan to always return -E2BIG in that case. I've applied a patch similar to this - please check mac80211-next. I wasn't really happy with the inline either after I looked more closely, so I created new _check() wrappers in the wext header file and used those here now. I did change the control flow, which you seem to have been reluctant to do, but it ultimately seemed like the better option. 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 v2 4/4] ath10k: introduce basic tdls functionality
On 25 February 2015 at 08:55, Marek Puzyniak wrote:
[...]
> diff --git a/drivers/net/wireless/ath/ath10k/core.h
> b/drivers/net/wireless/ath/ath10k/core.h
> index 94a8788..14b99c8 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -604,6 +604,7 @@ struct ath10k {
> /* protected by conf_mutex */
> int num_peers;
> int num_stations;
> + int tdls_peers;
I don't like the idea of having another var in ath10k which isn't on
hotpath and can be derived from other structures/tools we already
have, i.e. ieee80211_iterate_stations_atomic(). You can use that to
implement ath10k_mac_tdls_num_peers(arvif).
>
> int max_num_peers;
> int max_num_stations;
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 7378656..21720b8 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -518,6 +518,73 @@ static void ath10k_peer_cleanup_all(struct ath10k *ar)
> ar->num_stations = 0;
> }
>
> +static int ath10k_mac_enable_tdls(struct ath10k *ar, u32 vdev_id, bool
> enable)
With number of tdls peers being derived you won't be able to have this
kind of "recalc" logic anymore. I guess that's a good thing. You'll
need to call ath10k_wmi_update_fw_tdls_state() explicitly in
ath10k_sta_state() depending on context and numbers of peers.
> +static int ath10k_mac_tdls_peer_update(struct ath10k *ar, u32 vdev_id,
> + struct ieee80211_sta *sta,
> + enum wmi_tdls_peer_state state)
> +{
> + int ret;
> + struct wmi_tdls_peer_update_cmd_arg arg;
I would `arg = {};` to make sure it's clean. Even if you're positive
you fill all `arg` members here it leaves it open for bugs sneaking in
when you extend the structure later on and forget to init new members
here as well.
> + struct wmi_tdls_peer_capab_arg cap = {};
> + struct wmi_channel_arg chan_arg = {};
> +
> + lockdep_assert_held(&ar->conf_mutex);
> +
> + arg.vdev_id = vdev_id;
> + arg.peer_state = state;
> + ether_addr_copy(arg.addr, sta->addr);
> +
> + cap.peer_max_sp = sta->max_sp;
> + cap.peer_uapsd_queues = sta->uapsd_queues;
> +
> + if (state == WMI_TDLS_PEER_STATE_CONNECTED) {
> + if (!sta->tdls_initiator)
> + cap.is_peer_responder = 1;
> + }
You can probably make it into a single if() ?
> @@ -4092,9 +4193,30 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
> ath10k_warn(ar, "failed to associate station %pM for
> vdev %i: %i\n",
> sta->addr, arvif->vdev_id, ret);
> } else if (old_state == IEEE80211_STA_ASSOC &&
> - new_state == IEEE80211_STA_AUTH &&
> - (vif->type == NL80211_IFTYPE_AP ||
> - vif->type == NL80211_IFTYPE_ADHOC)) {
> + new_state == IEEE80211_STA_AUTHORIZED &&
> + sta->tdls) {
> + /*
> +* Tdls station authorized.
> +*/
> + ath10k_dbg(ar, ATH10K_DBG_MAC, "mac tdls sta %pM
> authorized\n",
> + sta->addr);
> +
> + ret = ath10k_station_assoc(ar, vif, sta, false);
> + if (ret) {
> + ath10k_warn(ar, "failed to associate station %pM for
> vdev %i: %i\n",
"failed to associate tdls station" would be nicer I guess?
> +static u32 ath10k_wmi_tlv_prepare_peer_qos(u8 uapsd_queues, u8 sp)
> +{
> + u32 peer_qos = 0;
> +
> + if (uapsd_queues & IEEE80211_WMM_IE_STA_QOSINFO_AC_VO)
> + peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_VO;
> + if (uapsd_queues & IEEE80211_WMM_IE_STA_QOSINFO_AC_VI)
> + peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_VI;
> + if (uapsd_queues & IEEE80211_WMM_IE_STA_QOSINFO_AC_BK)
> + peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_BK;
> + if (uapsd_queues & IEEE80211_WMM_IE_STA_QOSINFO_AC_BE)
> + peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_BE;
> + peer_qos |= (sp << WMI_TLV_TDLS_PEER_SP_POS);
peer_qos |= (sp << WMI_TLV_TDLS_PEER_SP_SHIFT);
Or even provide _MASK + _SHIFT defines and use SM/MS macros.
> +struct wmi_tdls_peer_update_cmd_arg {
> + u32 vdev_id;
> + enum wmi_tdls_peer_state peer_state;
> + u8 addr[ETH_ALEN];
> +} __packed;
No need to pack local/driver-only structures.
> +struct wmi_tdls_peer_capab_arg {
> + u8 peer_uapsd_queues;
> + u8 peer_max_sp;
> + u32 buff_sta_support;
> + u32 off_chan_support;
> + u32 peer_curr_operclass;
> + u32 self_curr_operclass;
> + u32 peer_chan_len;
> + u32 peer_operclass_len;
> + u8 peer_operclass[WMI_TDLS_MAX_SUPP_OPER_CLASSES];
> + u32 is_peer_responder;
> + u32 pref_offchan_num;
> + u3
Re: [PATCH v6 2/3] mac80211/minstrel_ht: use the new rate control API
Hi Felix, On Friday 20 February 2015 15:12:10 Sven Eckelmann wrote: > > static void > > > > @@ -846,6 +857,8 @@ minstrel_ht_update_caps(void *priv, struct > > ieee80211_supported_band *sband, > > > > msp->is_ht = true; > > memset(mi, 0, sizeof(*mi)); > > > > + > > + mi->sta = sta; > > > > mi->stats_update = jiffies; > > minstrel_ht_update_caps can be called on init and on different other changes > (rate_control_rate_update). > > Which lock protects mi from following scenario? > > context 1: memset(mi, 0, sizeof(*mi)); // mi->sta is now NULL > context 2: minstrel_ht_update_rates -> rate_control_set_rates(mp->hw, >mi->sta, rates) > context 2: rate_control_set_rates dereferences >pubsta->rates (mi->sta + 0x48) -> Kernel Oops > context 1: mi->sta = sta > > The first context is from one of the many rate_control_rate_update in > mac80211 and the second context is from ieee80211_tx_status. > > The question came up when discovering the OpenWrt bug report > https://dev.openwrt.org/ticket/18388 (minstrel_ht_update_caps > the thing most likely behind minstrel_remove_sta_debugfs+0xe8c/0x1674 - at > least EPC is pointing inside this function for a build from this revision) I have someone here who says that he can reproduce this problem with a current mac80211 from OpenWrt in ~40 min in a mesh setup with a lot of multicast. I gave them following test patch to check if it could be related to the scenario explained earlier: --- a/net/mac80211/rc80211_minstrel_ht.c +++ b/net/mac80211/rc80211_minstrel_ht.c @@ -1126,7 +1126,8 @@ minstrel_ht_update_caps(void *priv, stru use_vht = 0; msp->is_ht = true; - memset(mi, 0, sizeof(*mi)); + /* don't reset the first entry of mi which is the sta pointer */ + memset(((u8 *)mi) + sizeof(mi->sta), 0, sizeof(*mi) - sizeof(mi->sta)); mi->sta = sta; mi->stats_update = jiffies; He reported back that the mesh nodes were now running fine since 7 hours. It is also tested in another network which now runs since 1 1/2 days and were not able to run stable for more then 20 hours at max before applying that patch. These numbers are no definitive proof but at least suggest that there could be a connection. Maybe you already had some concept how to protect from this problem and have not fully implemented it. Would be nice to hear back from you. Kind regards, Sven -- 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
mt7601u dies during channel switch (was: MediaTek WiFi hardware support in upstream kernel)
On Wed, 25 Feb 2015 01:49:02 +0100, Sergei Antonov wrote: > On 6 February 2015 at 18:29, Jakub Kiciński wrote: > > Hello everyone! > > > > I put together a mac80211 driver for Mediatek MT7601U. It's partially > > based on Felix's mt76, but I'm not sure if it will make sense to merge > > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles > > and mt76 now only supports the latest and greatest ac APs. > > > > I'm testing STA functionality right now and it seems to be working ok. > > The code is very much a work in progress but if anyone is interested you > > can get it here: > > > > https://github.com/kuba-moo/mt7601u > > Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There > were some problems, see "dmesg | grep mt7" output: OK, let me start with a set of basic questions. What device do you have (brand + model or picture on ebay please;))? What's the device ID? What platform are you working on? Is this error persistent or a one-time thing? Does the vendor driver work with your device? Can you also show content of /sys/kernel/debug/ieee80211/phy*/mt76/eeprom_param ? > [3.174960] mt7601u 3-5:1.0: ASIC revision: 76010001 MAC revision: > 76010500 > [3.181705] mt7601u 3-5:1.0: Firmware Version: 0.1.00 Build: 7640 > Build time: 201302052146 > [3.573018] mt7601u 3-5:1.0: Warning: unsupported EEPROM version 0d > [3.574853] mt7601u 3-5:1.0: EEPROM ver:0d fae:00 > [3.816647] usbcore: registered new interface driver mt7601u > [ 10.461251] mt7601u_add_interface idx:0 > [ 10.463193] mt7601u_bss_info_changed 000e > [ 10.469748] mt7601u_conf_tx 03 <- > [ 10.473738] mt7601u_conf_tx 02 <- 0001 > [ 10.477856] mt7601u_conf_tx 01 <- 0002 > [ 10.481980] mt7601u_conf_tx 00 <- 0003 > [ 10.486849] mt7601u_bss_info_changed 2000 > [ 10.488671] mt7601u_config ch:1 > [ 10.504305] mt76_configure_filter changed:0 total:8000 > [ 10.508327] mt76_configure_filter changed:0 total:8000 > [ 10.550671] mt76_configure_filter changed:0 total:8000 > [ 10.616870] mt7601u_config 0100 ch:1 > [ 10.619449] mt76_configure_filter changed:10 total:8010 > [ 10.621541] mt7601u_config 0040 ch:1 > [ 10.692407] mt7601u_config 0040 ch:2 > [ 10.992113] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying > [ 11.291819] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying > [ 11.591524] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying > [ 11.891230] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying > [ 12.190936] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying > [ 12.192790] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out Firmware clearly died somewhere between switch to channel 1 and to channel 2... I made some changes to the FW loading routine, I will try to check the traces later today to confirm that I didn't break anything. > Is it because of "unsupported EEPROM version 0d"? Don't think so. It's just for compatibility with vendor driver, they warn too. All new devices have EEPROM ver == 0x0d though. I plan to ask MediaTek about it in a week or two (Chinese New Year) and remove the warning. -- 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: remove TX latency measurement code
From: Johannes Berg
Revert commit ad38bfc916da ("mac80211: Tx frame latency statistics")
(along with some follow-up fixes).
This code turned out not to be as useful in the current form as we
thought, and we've internally hacked it up more, but that's not
very suitable for upstream (for now), and we might just do that
with tracing instead.
Therefore, for now at least, remove this code. We might also need
to use the skb->tstamp field for the TCP performance issue, which
is more important than the debugging.
Signed-off-by: Johannes Berg
---
net/mac80211/debugfs.c | 168 -
net/mac80211/debugfs_sta.c | 134
net/mac80211/ieee80211_i.h | 24 ---
net/mac80211/main.c| 2 -
net/mac80211/sta_info.c| 54 ++-
net/mac80211/sta_info.h| 22 --
net/mac80211/status.c | 74
net/mac80211/tx.c | 22 --
8 files changed, 5 insertions(+), 495 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index eeb0bbd69d98..74830ce25e74 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -18,172 +18,6 @@
#define DEBUGFS_FORMAT_BUFFER_SIZE 100
-#define TX_LATENCY_BIN_DELIMTER_C ','
-#define TX_LATENCY_BIN_DELIMTER_S ","
-#define TX_LATENCY_BINS_DISABLED "enable(bins disabled)\n"
-#define TX_LATENCY_DISABLED "disable\n"
-
-
-/*
- * Display if Tx latency statistics & bins are enabled/disabled
- */
-static ssize_t sta_tx_latency_stat_read(struct file *file,
- char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct ieee80211_local *local = file->private_data;
- struct ieee80211_tx_latency_bin_ranges *tx_latency;
- char *buf;
- int bufsz, i, ret;
- int pos = 0;
-
- rcu_read_lock();
-
- tx_latency = rcu_dereference(local->tx_latency);
-
- if (tx_latency && tx_latency->n_ranges) {
- bufsz = tx_latency->n_ranges * 15;
- buf = kzalloc(bufsz, GFP_ATOMIC);
- if (!buf)
- goto err;
-
- for (i = 0; i < tx_latency->n_ranges; i++)
- pos += scnprintf(buf + pos, bufsz - pos, "%d,",
-tx_latency->ranges[i]);
- pos += scnprintf(buf + pos, bufsz - pos, "\n");
- } else if (tx_latency) {
- bufsz = sizeof(TX_LATENCY_BINS_DISABLED) + 1;
- buf = kzalloc(bufsz, GFP_ATOMIC);
- if (!buf)
- goto err;
-
- pos += scnprintf(buf + pos, bufsz - pos, "%s\n",
-TX_LATENCY_BINS_DISABLED);
- } else {
- bufsz = sizeof(TX_LATENCY_DISABLED) + 1;
- buf = kzalloc(bufsz, GFP_ATOMIC);
- if (!buf)
- goto err;
-
- pos += scnprintf(buf + pos, bufsz - pos, "%s\n",
-TX_LATENCY_DISABLED);
- }
-
- rcu_read_unlock();
-
- ret = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- kfree(buf);
-
- return ret;
-err:
- rcu_read_unlock();
- return -ENOMEM;
-}
-
-/*
- * Receive input from user regarding Tx latency statistics
- * The input should indicate if Tx latency statistics and bins are
- * enabled/disabled.
- * If bins are enabled input should indicate the amount of different bins and
- * their ranges. Each bin will count how many Tx frames transmitted within the
- * appropriate latency.
- * Legal input is:
- * a) "enable(bins disabled)" - to enable only general statistics
- * b) "a,b,c,d,...z" - to enable general statistics and bins, where all are
- * numbers and a < b < c < d.. < z
- * c) "disable" - disable all statistics
- * NOTE: must configure Tx latency statistics bins before stations connected.
- */
-
-static ssize_t sta_tx_latency_stat_write(struct file *file,
-const char __user *userbuf,
-size_t count, loff_t *ppos)
-{
- struct ieee80211_local *local = file->private_data;
- char buf[128] = {};
- char *bins = buf;
- char *token;
- int buf_size, i, alloc_size;
- int prev_bin = 0;
- int n_ranges = 0;
- int ret = count;
- struct ieee80211_tx_latency_bin_ranges *tx_latency;
-
- if (sizeof(buf) <= count)
- return -EINVAL;
- buf_size = count;
- if (copy_from_user(buf, userbuf, buf_size))
- return -EFAULT;
-
- mutex_lock(&local->sta_mtx);
-
- /* cannot change config once we have stations */
- if (local->num_sta)
- goto unlock;
-
- tx_latency =
- rcu_dereference_protected(local->tx_latency,
- lockdep_is_held(&local->sta_mtx));
-
- /* disable Tx statisti
Re: Connection issues with BW Tracking in mac80211
On Wed, 2015-02-25 at 02:41 +0530, Krishna Chaitanya wrote: > On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg > wrote: > > On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote: > > > >> Use case2: When changing from HT40-VHT80, the connection goes through > >> but it still connected as HT40 (vht_ie from cfg80211 is returned > >> null). > >> > >> Can you think of any reason why the bss_list is not updated cfg80211? > >> Note: iwconfig and wpa_supplicant both show same behavior. > > > > Well, there's no flushing, only overwriting by new results - but if you > > previuosly got both beacons and probe responses each one will stick > > around until you get them again. > We do have the scan results expiry time of 30secs, that will flush the > results from bss_list right? Even the get_bss checks for aging? Yes but if you scan in the meantime the scan result is marked as recent again, even if some old data might be kept. Perhaps we should split that into timestamps for probe and beacons separately, but that'd certainly complicate the code significantly for little gain. 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
