Re: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
On 2015/2/16 17:35, Arend van Spriel wrote: > On 02/16/15 08:34, Fu, Zhonghui wrote: >> >> On 2015/2/15 22:54, Kalle Valo wrote: >>> Arend van Spriel writes: >>> On 02/15/15 04:27, Pat Erley wrote: > On 02/14/2015 08:40 PM, Fu, Zhonghui wrote: >> Any comments to this patch? Can it be accepted? I assume that patches are queued up until after the merge window that we are currently in. >>> That's right. In the future I will most likely apply patches also during >>> the merge window, but as I'm still a greenhorn I'll be on the safe and >>> wait for the merge window to end. >> I am very glad to see this. >> Could you please tell which release candidate this patch will be likely >> merged into now? > > For which tree are you asking this? When the merge window ends and linus' > tree has moved to 3.20-rc1, the wireless-drivers-next will move to that -rc1 > as well and pending/accepted patches will be applied for the next kernel > release. If you are asking when they will be in linus' tree than the answer > is 3.21-rc1. Now if you say this patch solves a real problem for you > (providing usual proof like log with stack trace) you can request it to go on > the wireless-drivers tree to be fixed for 3.20. I was in Chinese new-year vacation these few days. So sorry for late response. Many thanks for your explanation first. Now that there is not 3.20 version. My understanding is that this patch will be in linus' tree 4.1-rc1, right? Thanks, Zhonghui > > Regards, > Arend > -- > To unsubscribe from this list: send the line "unsubscribe netdev" 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: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
On 2015/2/16 17:50, David Laight wrote:
>>> WiFi chip has 2 SDIO functions, and PM core will trigger
>>> twice suspend/resume operations for one WiFi chip to do
>>> the same things. This patch avoid this case.
> Do you want to suspend on the first or last request?
>
> In general it might be that one function is in use and
> something wants to suspend the other (as inactive).
>
> If they suspend together you might need to pretend the
> first function is suspended but only do the real power-saving
> device suspend when all the functions have been suspended.
I was in Chinese new-year vacation these few days. So sorry for late response.
Suspend/Resume entry functions of brcmfmac driver does not differentiate
between two functions, performs the same operations instead.
Thanks,
Zhonghui
>
> David
>
> N�r��y���b�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
> ���j:+v���w�j�mzZ+�ݢj"��!tml=
--
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 1/2] dt: bindings: add wl18xx wireless device
On Thu, 2015-02-19 at 18:13 +0200, Eliad Peller wrote: > Add device tree binding documentation for TI's wl18xx > wlan chip. > > Signed-off-by: Eliad Peller > --- If, as I said in the other thread, you use the work I did earlier, support for wl12xx will also be included... -- Luca. -- 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] wlcore: add basic device-tree support
Hi, On Sun, 2015-02-15 at 13:09 +0200, Eliad Peller wrote: > When running with device-tree, we no longer have a board file > that can set up the platform data for wlcore. > Allow this data to be passed from DT. > > For now, parse only the irq used. Other (optional) properties > can be added later on. > > Signed-off-by: Ido Yariv > Signed-off-by: Eliad Peller > --- I don't really care much, but why not just finalize the work I did a couple of years ago? http://mid.gmane.org/1375189476-21557-1-git-send-email-coe...@ti.com http://mid.gmane.org/1375215668-29171-1-git-send-email-coe...@ti.com IIRC there were just some minor comments there, but I never really got to it because I left TI. -- Luca. -- 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 net-next] wireless: test sscanf return values
At some point, it'd be good to make sscanf use __must_check
so make sure the net/ uses of sscanf use the return value.
Signed-off-by: Joe Perches
---
Compiled, untested.
net/mac80211/debugfs.c | 4 ++--
net/wireless/core.c| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index eeb0bbd..0e44be7 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -160,9 +160,9 @@ static ssize_t sta_tx_latency_stat_write(struct file *file,
tx_latency->n_ranges = n_ranges;
for (i = 0; i < n_ranges; i++) { /* setting bin ranges */
token = strsep(&bins, TX_LATENCY_BIN_DELIMTER_S);
- sscanf(token, "%d", &tx_latency->ranges[i]);
/* bins values should be in ascending order */
- if (prev_bin >= tx_latency->ranges[i]) {
+ if (sscanf(token, "%d", &tx_latency->ranges[i]) != 1 ||
+ prev_bin >= tx_latency->ranges[i]) {
ret = -EINVAL;
kfree(tx_latency);
goto unlock;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 3af0ecf..69a350e 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -95,8 +95,8 @@ static int cfg80211_dev_check_name(struct
cfg80211_registered_device *rdev,
ASSERT_RTNL();
/* prohibit calling the thing phy%d when %d is not its number */
- sscanf(newname, PHY_NAME "%d%n", &wiphy_idx, &taken);
- if (taken == strlen(newname) && wiphy_idx != rdev->wiphy_idx) {
+ if (sscanf(newname, PHY_NAME "%d%n", &wiphy_idx, &taken) == 1 &&
+ taken == strlen(newname) && wiphy_idx != rdev->wiphy_idx) {
/* count number of places needed to print wiphy_idx */
digits = 1;
while (wiphy_idx /= 10)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flaky AP has bad AIFSN, so no HT/VHT....
On Thu, 2015-02-26 at 10:07 -0800, Ben Greear wrote: > It looks like their beacon has bogus AIFSN info, and sniff of the beacon does > show AIFSN set to 0. Yeah this is invalid - the spec requires at least 2. > Kernel dmesg logs: > > wlan0: authenticated at: 1424969385.456415 > wlan0: AP has invalid WMM params (AIFSN=0 for ACI 0), disabling WMM and then since we disable WMM we also can't do HT or VHT since they both require WMM (technically QoS, but that's mostly just different IE signalling) > wlan0: associate with 00:18:25:06:4a:b4 (try 1/3), at: 1424969385.457148 > wlan0: RX AssocResp from 00:18:25:06:4a:b4 (capab=0x401 status=0 aid=2) at: > 1424969385.476681 > wlan0: associated at: 1424969385.477265 > > > But a commercial phone connects just fine to this AP, and reports ~780Mbps > link speed, > so it at least thinks it is doing VHT. > > My question is, should we just warn and ignore this bad AIFSN, or is this > really > a fatal issue as far as enabling WMM? It's hard to say what the AP meant when it said 0 ... did it really want the non-standard behaviour of 0, which will result in really bad medium access behaviour? Or should we override to use the minimum of 2? AFAIR at least the Intel device gets horribly confused and crashes when we actually ask it to use 0 - the backoff calculation then is rather strange anyway. Note that disabling WMM of course also makes use of *some* medium access rules, so there's perhaps the possibility of using the default value for ACs that have it as 0? OTOH, if we disable WMM, we'll use 3 for all frames, rather than 2/2/3/7 (for VO/VI/BE/BK) ... It's not really trivial though. 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] mac80211: Send EAPOL frames at lowest rate
Linus, Jouni, all, Thanks everyone. I've applied this patch to my mac80211 tree - I'll send it out to davem tomorrow I think. Jouni, given that hwsim uses minstrel as well, perhaps we could have a test case in the wpa_supplicant tests in some way that checks this? I'm thinking we could hook into the AP and remove it from the radio group right after sending 3/4, so that 4/4 would get retransmitted? I don't actually know though if hwsim really honours all the rate stuff, something to look into perhaps. > Also "Tested-by:", and I'd suggest marking it for stable too (although > I understand that David generally doesn't use stable tags, and just > sends them separately to the stable tree). Done - and yeah, he does that, but I add stable tags anyway since I don't want to track it down later. So far he hasn't complained :-) > My main laptop is iwlwifi, and the only reason that worked is > apparently that the iwlwifi driver already basically does something > similar on its own. Yes, and it also starts out at a lower rate. > All the other devices I have apparently don't use the 802.11 code even > if they are Linux-based (ie mostly android, and presumably they use > some vendor driver rather than the minstrel rate-handling code). Indeed, very few of them do. The only ones I'm aware of are (fairly old) phones using the TI wifi chip - my Motorola razr i for example actually runs mac80211. However, it also doesn't use minstrel, so I guess you won't find a phone using this :-) 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: mt7601u dies during channel switch (was: MediaTek WiFi hardware support in upstream kernel)
On Thu, 26 Feb 2015 19:50:04 +0100, Sergei Antonov wrote: > Jakub, I'll do all of it, but for now just one quick question: what > firmware binary blob should I use with your driver? Maybe I just took > a wrong firmware... You can send me yours. I have the one from vendor package. The MD5 sum is # md5sum /usr/lib/firmware/mt7601u.bin 696cedb8e76ecc0cda9f9b0d3972c64d /usr/lib/firmware/mt7601u.bin -- 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 26 February 2015 at 02:20, Jouni Malinen wrote: > On Wed, Feb 25, 2015 at 10:14:45AM -0800, 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? > >> 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.. > > Of all people, I do actually have some hatred on the one-liner to force > minimum rate for all EAPOL TX attempts. That is punishing the vast > majority of cases where the AP is perfectly fine with higher MCS rates > being used (and MCS 0 being sufficient fallback option) for EAPOL. Being > able to use higher TX rates as the initial attempt is a nice feature and > even though this may be limited to number of upstream Linux drivers > today, that part of the feature is an improvement, IMHO. This can even > be more robust in some environments especially when going through long > EAP exchange with certain types of interference. I remember running the math - well, the "airtime" math, and realised it was almost always cheaper to do the single, non-aggregated EAPOL frame exchange at the lowest rate than to try higher rates and fall back to the lowest rates. -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
Flaky AP has bad AIFSN, so no HT/VHT....
One of our customers reported that our ath10k stations were only able to connect at 54Mbps speeds. This is using somewhat hacked 3.17.8 kernel, but it looks like 3.19 has the same code checks for AIFSN. It looks like their beacon has bogus AIFSN info, and sniff of the beacon does show AIFSN set to 0. Kernel dmesg logs: wlan0: authenticated at: 1424969385.456415 wlan0: AP has invalid WMM params (AIFSN=0 for ACI 0), disabling WMM wlan0: associate with 00:18:25:06:4a:b4 (try 1/3), at: 1424969385.457148 wlan0: RX AssocResp from 00:18:25:06:4a:b4 (capab=0x401 status=0 aid=2) at: 1424969385.476681 wlan0: associated at: 1424969385.477265 But a commercial phone connects just fine to this AP, and reports ~780Mbps link speed, so it at least thinks it is doing VHT. My question is, should we just warn and ignore this bad AIFSN, or is this really a fatal issue as far as enabling WMM? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Send EAPOL frames at lowest rate
Johannes, On Thu, Feb 26, 2015 at 5:50 AM, Jouni Malinen wrote: > > Reported-by: Linus Torvalds Also "Tested-by:", and I'd suggest marking it for stable too (although I understand that David generally doesn't use stable tags, and just sends them separately to the stable tree). This fixes both Atheros and brcmsmac for me (with Ubiquiti UniFi APs). My main laptop is iwlwifi, and the only reason that worked is apparently that the iwlwifi driver already basically does something similar on its own. All the other devices I have apparently don't use the 802.11 code even if they are Linux-based (ie mostly android, and presumably they use some vendor driver rather than the minstrel rate-handling code). 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: [PATCH v8 2/3] cfg80211: Add API to change the indoor regulatory setting
On Thu, Feb 26, 2015 at 04:54:06AM -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.
> - 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.
>
> Based on the above, a user space tool that continuously monitors the
> indoor settings, i.e., tracking power setting, location etc., can
> indicate environment changes to the regulatory core.
>
> Currently, in case a received country IE includes environment
> information (indicates that the country IE applies only to
> indoor operation or only to outdoor operation) it is currently not
> used.
Since I spotted an issue and you have to remake this patch
please also change this to:
It should be noted that currently userspace is the only
provided mechanism used to hint to the regulatory core
over the indoor/outdoor environment -- while the country
IEs do have an environment setting this has been completely
ignored by the regulatory core by design for a while now
since country IEs typically can contain bogus data.
> @@ -4984,7 +4988,15 @@ 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();
> + if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) {
> + owner_nlportid = info->snd_portid;
> + is_indoor = !!info->attrs[NL80211_ATTR_REG_INDOOR];
> + } else {
> + owner_nlportid = 0;
> + is_indoor = true;
> + }
> +
> + return regulatory_hint_indoor(is_indoor, owner_nlportid);
Good, this looks better now. But you are missing the chance that a secondary
random interface can come up and override that environmental information
without checking for previous users. I'll illustrate below.
> default:
> @@ -2288,15 +2291,51 @@ int regulatory_hint_user(const char *alpha2,
> return 0;
> }
>
> -int regulatory_hint_indoor_user(void)
> +int regulatory_hint_indoor(bool is_indoor, u32 portid)
> {
> + spin_lock(®_indoor_lock);
>
> + /*
> + * Process only if there is a real change, so the original port ID is
> + * saved (to handle cases that several processes try to change the
> + * indoor setting).
> + */
> + if (reg_is_indoor == is_indoor) {
> + spin_unlock(®_indoor_lock);
> + return 0;
> + }
>
> - reg_is_indoor = true;
> + reg_is_indoor = is_indoor;
> + if (reg_is_indoor)
> + reg_is_indoor_portid = portid;
> + else
> + reg_is_indoor_portid = 0;
Why do we ignore port id if we go outdoor? Also we seem to allow
interfaces to disagree on the setting, how are you handling that here?
Don't tell me that cannot happen, I want you to think about that and
handle it.
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: RTL8192cu: not work on linux-2.6.35
On 02/26/2015 05:02 AM, Brilliantov Kirill Vladimirovich wrote: Hello! I work with board on FreeScale iMX287 CPU and use linux-2.6.35. For use WiFi USB Trendnet TEW-648UBM I download driver (rtl8188C_8192C_usb_linux_v4.0.2_9000.20130911.tar.gz) from Realtek site and build it. --snip-- Yes, this chip supported in latest linux, unfortunately now I can't run new linux on board. Can you help run rtl8192cu on linux-2.6.35? Thank you and excuse me for my bad english. Sorry, but there is no way that any of us can support a Realtek vendor driver. In addition, I have never tested any of the non-mac80211 drivers for the RTL8188CU or RTL8192CU devices. You have the latest vendor driver that I know about. 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: [ath9k-devel] AR9462 problems connecting again..
Jouni Malinen wrote: > punishing the vast majority of cases where the AP is perfectly fine > with higher MCS rates First make it work (everywhere), then make it fast (where possible). //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: [PATCH v6 1/2] cfg80211: Add API to change the indoor regulatory setting
> -Original Message- > From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] On Behalf Of Luis R. Rodriguez > Sent: Thursday, February 26, 2015 04:08 > To: Peer, Ilan > Cc: Jouni Malinen; linux-wireless@vger.kernel.org; ArikX Nemtsov > Subject: 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. > I think that RF spectrum changes are addressed in some extend in 11h, 11k and 11v etc. So maybe What you are looking for is already there. > > > 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. > I think that APs (at least what the spec allows) have mechanisms to inform the client on some change such as channel switch, operational bandwidth (11ac), tx power control etc. > > > 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 i
Re: [PATCH] rtlwifi: Improve handling of IPv6 packets
On 02/26/2015 06:56 AM, Kalle Valo wrote: Larry Finger writes: Routine rtl_is_special_data() is supposed to identify packets that need to use a low bit rate so that the probability of successful transmission is high. The current version has a bug that causes all IPv6 packets to be labelled as special, with a corresponding low rate of transmission. A complete fix will be quite intrusive, but until that is available, all IPv6 packets are identified as regular. This patch also removes a magic number. Reported-and-tested-by: Alan Fisher Signed-off-by: Larry Finger Cc: Stable [3.18+] Cc: Alan Fisher Should this go to 4.0? Yes. I should have indicated that in the subject. My expectation is that any patch that has a Cc for Stable should be applied as soon as possible. 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] ssb: Silence warning for unknown backplane revision
On 02/26/2015 06:57 AM, Kalle Valo wrote: Larry Finger writes: When using a BCM4318 in a PCMCIA format, I get a startup message that the device uses backplane revision 0xF00. Next a WARNING is logged. Despite the message, the device works fine, This patch silences the warning. Cc: Rafał Miłecki Signed-off-by: Larry Finger Should this go to 4.0? As this one merely stops log spamming, sending it through NEXT is OK. 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
[PATCH v3 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 v8 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
[PATCH v8 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.
Based on the above, a user space tool that continuously monitors the
indoor settings, i.e., tracking power setting, location etc., can
indicate environment changes to the regulatory core.
Currently, in case a received country IE includes environment
information (indicates that the country IE applies only to
indoor operation or only to outdoor operation) it is currently not
used.
Signed-off-by: Ilan Peer
Signed-off-by: ArikX Nemtsov
---
include/uapi/linux/nl80211.h | 9 +++
net/wireless/nl80211.c | 19 ++-
net/wireless/reg.c | 58 +---
net/wireless/reg.h | 15 +++-
4 files changed, 95 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..aa221a3 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;
+
/*
* You should only get this when cfg80211 hasn't yet initialized
@@ -4984,7 +4988,15 @@ 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();
+ if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) {
+ owner_nlportid = info->snd_portid;
+ is_indoor = !!info->attrs[NL80211_ATTR_REG_INDOOR];
BCM43362, sdio module sn8000
Dear all, was trying to have working a wifi module, sn8000 from muRata, with a bcm43362 from a imx6q. I have actually a 3.10 kernel, patched with same patch done on 3.14 for bcm43362, but i have no responses from the sdio module. Seems sdio probing exits for timeout (110). Module is correctly powered, and set to sdio 4 wires module. I am also using devicetree, uhsdc controller is enabled and should be set up correctly. Every suggestion is appreciated, Regards Angelo -- 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: MediaTek WiFi hardware support in upstream kernel
On Thu, 26 Feb 2015 14:56:46 +0100, poma wrote: > On 06.02.2015 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 > > > > Cheers, > > kuba > > -- > > 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 > > > > How many mt7601u module editions exists there? :) > - vendor's > - vendor's patched (how many forms of the same) > - your reinvented > - the one on which pán Gruszka allegedly works? > - any more? I assume you mean to ask how many different drivers are there. There is the vendor 3.0.0.4 STA driver which only has client functionality. Many patched versions of this driver exist on GitHub. There is also an older version of vendor driver which can work as an AP. My mac80211-based driver is the only non-vendor version I'm aware of. -- 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: MediaTek WiFi hardware support in upstream kernel
On 06.02.2015 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 > > Cheers, > kuba > -- > 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 > How many mt7601u module editions exists there? :) - vendor's - vendor's patched (how many forms of the same) - your reinvented - the one on which pán Gruszka allegedly works? - any more? -- 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: Send EAPOL frames at lowest rate
The current minstrel_ht rate control behavior is somewhat optimistic in trying to find optimum TX rate. While this is usually fine for normal Data frames, there are cases where a more conservative set of retry parameters would be beneficial to make the connection more robust. EAPOL frames are critical to the authentication and especially the EAPOL-Key message 4/4 (the last message in the 4-way handshake) is important to get through to the AP. If that message is lost, the only recovery mechanism in many cases is to reassociate with the AP and start from scratch. This can often be avoided by trying to send the frame with more conservative rate and/or with more link layer retries. In most cases, minstrel_ht is currently using the initial EAPOL-Key frames for probing higher rates and this results in only five link layer transmission attempts (one at high(ish) MCS and four at MCS0). While this works with most APs, it looks like there are some deployed APs that may have issues with the EAPOL frames using HT MCS immediately after association. Similarly, there may be issues in cases where the signal strength or radio environment is not good enough to be able to get frames through even at couple of MCS 0 tries. The best approach for this would likely to be to reduce the TX rate for the last rate (3rd rate parameter in the set) to a low basic rate (say, 6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly requires some more effort. For now, we can start with a simple one-liner that forces the minimum rate to be used for EAPOL frames similarly how the TX rate is selected for the IEEE 802.11 Management frames. This does result in a small extra latency added to the cases where the AP would be able to receive the higher rate, but taken into account how small number of EAPOL frames are used, this is likely to be insignificant. A future optimization in the minstrel_ht design can also allow this patch to be reverted to get back to the more optimized initial TX rate. It should also be noted that many drivers that do not use minstrel as the rate control algorithm are already doing similar workarounds by forcing the lowest TX rate to be used for EAPOL frames. Reported-by: Linus Torvalds Signed-off-by: Jouni Malinen --- net/mac80211/tx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index af5446c..14ff5e4 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -565,6 +565,7 @@ ieee80211_tx_h_check_control_port_protocol(struct ieee80211_tx_data *tx) if (tx->sdata->control_port_no_encrypt) info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT; info->control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO; + info->flags |= IEEE80211_TX_CTL_USE_MINRATE; } return TX_CONTINUE; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] mac80211_hwsim: Add minimal capability for vendor command/event testing
This allows wpa_supplicant/hostapd to send a vendor command and verify
response to that command and a vendor event.
Signed-off-by: Jouni Malinen
---
v2: rebased on top of updated cfg80211_vendor_event_alloc() changes
drivers/net/wireless/mac80211_hwsim.c | 83 +++
1 file changed, 83 insertions(+)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index e259ee1..32bd2f0 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -330,6 +330,83 @@ static const struct ieee80211_rate hwsim_rates[] = {
{ .bitrate = 540 }
};
+#define OUI_QCA 0x001374
+#define QCA_NL80211_SUBCMD_TEST 1
+enum qca_nl80211_vendor_subcmds {
+ QCA_WLAN_VENDOR_ATTR_TEST = 8,
+ QCA_WLAN_VENDOR_ATTR_MAX = QCA_WLAN_VENDOR_ATTR_TEST
+};
+
+static const struct nla_policy
+hwsim_vendor_test_policy[QCA_WLAN_VENDOR_ATTR_MAX + 1] = {
+ [QCA_WLAN_VENDOR_ATTR_MAX] = { .type = NLA_U32 },
+};
+
+static int mac80211_hwsim_vendor_cmd_test(struct wiphy *wiphy,
+ struct wireless_dev *wdev,
+ const void *data, int data_len)
+{
+ struct sk_buff *skb;
+ struct nlattr *tb[QCA_WLAN_VENDOR_ATTR_MAX + 1];
+ int err;
+ u32 val;
+
+ err = nla_parse(tb, QCA_WLAN_VENDOR_ATTR_MAX, data, data_len,
+ hwsim_vendor_test_policy);
+ if (err)
+ return err;
+ if (!tb[QCA_WLAN_VENDOR_ATTR_TEST])
+ return -EINVAL;
+ val = nla_get_u32(tb[QCA_WLAN_VENDOR_ATTR_TEST]);
+ wiphy_debug(wiphy, "%s: test=%u\n", __func__, val);
+
+ /* Send a vendor event as a test. Note that this would not normally be
+* done within a command handler, but rather, based on some other
+* trigger. For simplicity, this command is used to trigger the event
+* here.
+*
+* event_idx = 0 (index in mac80211_hwsim_vendor_commands)
+*/
+ skb = cfg80211_vendor_event_alloc(wiphy, wdev, 100, 0, GFP_KERNEL);
+ if (skb) {
+ /* skb_put() or nla_put() will fill up data within
+* NL80211_ATTR_VENDOR_DATA.
+*/
+
+ /* Add vendor data */
+ nla_put_u32(skb, QCA_WLAN_VENDOR_ATTR_TEST, val + 1);
+
+ /* Send the event - this will call nla_nest_end() */
+ cfg80211_vendor_event(skb, GFP_KERNEL);
+ }
+
+ /* Send a response to the command */
+ skb = cfg80211_vendor_cmd_alloc_reply_skb(wiphy, 10);
+ if (!skb)
+ return -ENOMEM;
+
+ /* skb_put() or nla_put() will fill up data within
+* NL80211_ATTR_VENDOR_DATA
+*/
+ nla_put_u32(skb, QCA_WLAN_VENDOR_ATTR_TEST, val + 2);
+
+ return cfg80211_vendor_cmd_reply(skb);
+}
+
+static struct wiphy_vendor_command mac80211_hwsim_vendor_commands[] = {
+ {
+ .info = { .vendor_id = OUI_QCA,
+ .subcmd = QCA_NL80211_SUBCMD_TEST },
+ .flags = WIPHY_VENDOR_CMD_NEED_NETDEV,
+ .doit = mac80211_hwsim_vendor_cmd_test,
+ }
+};
+
+/* Advertise support vendor specific events */
+static const struct nl80211_vendor_cmd_info mac80211_hwsim_vendor_events[] = {
+ { .vendor_id = OUI_QCA, .subcmd = 1 },
+};
+
static const struct ieee80211_iface_limit hwsim_if_limits[] = {
{ .max = 1, .types = BIT(NL80211_IFTYPE_ADHOC) },
{ .max = 2048, .types = BIT(NL80211_IFTYPE_STATION) |
@@ -2416,6 +2493,12 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
hw->max_rates = 4;
hw->max_rate_tries = 11;
+ hw->wiphy->vendor_commands = mac80211_hwsim_vendor_commands;
+ hw->wiphy->n_vendor_commands =
+ ARRAY_SIZE(mac80211_hwsim_vendor_commands);
+ hw->wiphy->vendor_events = mac80211_hwsim_vendor_events;
+ hw->wiphy->n_vendor_events = ARRAY_SIZE(mac80211_hwsim_vendor_events);
+
if (param->reg_strict)
hw->wiphy->regulatory_flags |= REGULATORY_STRICT_REG;
if (param->regd) {
--
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
[PATCH v2 1/2] cfg80211: Allow NL80211_ATTR_IFINDEX to be added to vendor events
From: Ahmad Kholaif
This modifies cfg80211_vendor_event_alloc() with an additional argument
struct wireless_dev *wdev. __cfg80211_alloc_event_skb() is modified to
take in *wdev argument, if wdev != NULL, both the NL80211_ATTR_IFINDEX
and wdev identifier are added to the vendor event.
These changes make it easier for drivers to add ifindex indication in
vendor events cleanly.
This also updates all existing users of cfg80211_vendor_event_alloc()
and __cfg80211_alloc_event_skb() in the kernel tree.
Signed-off-by: Ahmad Kholaif
Signed-off-by: Jouni Malinen
---
v2: address review comments: add NL80211_ATTR_WDEV, modify existing
cfg80211_vendor_event_alloc() instead of adding a new wrapper
function, move the wdev argument to be the second argument to the
functions instead of last
drivers/net/wireless/ti/wl18xx/event.c | 4 ++--
include/net/cfg80211.h | 14 ++
net/wireless/nl80211.c | 20
3 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/event.c
b/drivers/net/wireless/ti/wl18xx/event.c
index c28f068..548bb9e 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -77,7 +77,7 @@ static int wlcore_smart_config_sync_event(struct wl1271 *wl,
u8 sync_channel,
wl1271_debug(DEBUG_EVENT,
"SMART_CONFIG_SYNC_EVENT_ID, freq: %d (chan: %d band %d)",
freq, sync_channel, sync_band);
- skb = cfg80211_vendor_event_alloc(wl->hw->wiphy, 20,
+ skb = cfg80211_vendor_event_alloc(wl->hw->wiphy, NULL, 20,
WLCORE_VENDOR_EVENT_SC_SYNC,
GFP_KERNEL);
@@ -98,7 +98,7 @@ static int wlcore_smart_config_decode_event(struct wl1271 *wl,
wl1271_debug(DEBUG_EVENT, "SMART_CONFIG_DECODE_EVENT_ID");
wl1271_dump_ascii(DEBUG_EVENT, "SSID:", ssid, ssid_len);
- skb = cfg80211_vendor_event_alloc(wl->hw->wiphy,
+ skb = cfg80211_vendor_event_alloc(wl->hw->wiphy, NULL,
ssid_len + pwd_len + 20,
WLCORE_VENDOR_EVENT_SC_DECODE,
GFP_KERNEL);
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 64e09e1..f9a4d17 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4260,6 +4260,7 @@ struct sk_buff *__cfg80211_alloc_reply_skb(struct wiphy
*wiphy,
int approxlen);
struct sk_buff *__cfg80211_alloc_event_skb(struct wiphy *wiphy,
+ struct wireless_dev *wdev,
enum nl80211_commands cmd,
enum nl80211_attrs attr,
int vendor_event_idx,
@@ -4314,6 +4315,7 @@ int cfg80211_vendor_cmd_reply(struct sk_buff *skb);
/**
* cfg80211_vendor_event_alloc - allocate vendor-specific event skb
* @wiphy: the wiphy
+ * @wdev: the wireless device
* @event_idx: index of the vendor event in the wiphy's vendor_events
* @approxlen: an upper bound of the length of the data that will
* be put into the skb
@@ -4322,16 +4324,20 @@ int cfg80211_vendor_cmd_reply(struct sk_buff *skb);
* This function allocates and pre-fills an skb for an event on the
* vendor-specific multicast group.
*
+ * If wdev != NULL, both the ifindex and identifier of the specified
+ * wireless device are added to the event message before the vendor data
+ * attribute.
+ *
* When done filling the skb, call cfg80211_vendor_event() with the
* skb to send the event.
*
* Return: An allocated and pre-filled skb. %NULL if any errors happen.
*/
static inline struct sk_buff *
-cfg80211_vendor_event_alloc(struct wiphy *wiphy, int approxlen,
- int event_idx, gfp_t gfp)
+cfg80211_vendor_event_alloc(struct wiphy *wiphy, struct wireless_dev *wdev,
+int approxlen, int event_idx, gfp_t gfp)
{
- return __cfg80211_alloc_event_skb(wiphy, NL80211_CMD_VENDOR,
+ return __cfg80211_alloc_event_skb(wiphy, wdev, NL80211_CMD_VENDOR,
NL80211_ATTR_VENDOR_DATA,
event_idx, approxlen, gfp);
}
@@ -4432,7 +4438,7 @@ static inline int cfg80211_testmode_reply(struct sk_buff
*skb)
static inline struct sk_buff *
cfg80211_testmode_alloc_event_skb(struct wiphy *wiphy, int approxlen, gfp_t
gfp)
{
- return __cfg80211_alloc_event_skb(wiphy, NL80211_CMD_TESTMODE,
+ return __cfg80211_alloc_event_skb(wiphy, NULL, NL80211_CMD_TESTMODE,
NL80211_ATTR_TESTDATA, -1,
approxlen, gfp);
}
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9c6e23e..d3c389a 100644
--- a/net/wi
Re: ath9k_htc: Add new USB ID
> This device is a dongle made by Philips to enhance their TVs with wireless > capabilities, > but works flawlessly on any upstream kernel, provided that the ath9k_htc > module is attached to it. > It's correctly recognized by lsusb as "0471:209e Philips (or NXP) PTA01 > Wireless Adapter" and the > patch has been tested on real hardware. > > Signed-off-by: Leon Nardella Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] rtlwifi: Clear ACM_CTRL AC3_VO bit correctly
Larry Finger writes: > On 02/06/2015 04:24 PM, jes.soren...@redhat.com wrote: >> From: Jes Sorensen >> >> All hw driver components in the rtlwifi driver, except for the >> rtl8192de component has this bug. They would clear BE bit in the >> ACM_CTRL register instead of the VO bit when processing the VO queue. >> >> Signed-off-by: Jes Sorensen > > Jes, > > Good catch. Acked-by: Larry Finger BTW, if you want patchwork to use that Acked-by line add it to a line of it's own. Otherwise it will ignore it. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/1] rtlwifi: Clear ACM_CTRL AC3_VO bit correctly
> From: Jes Sorensen > > All hw driver components in the rtlwifi driver, except for the > rtl8192de component has this bug. They would clear BE bit in the > ACM_CTRL register instead of the VO bit when processing the VO queue. > > Signed-off-by: Jes Sorensen Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/6] brcmfmac: use helper function for changing SDIO state
> Changing the SDIO state of the driver involves changing the bus > interface state. Adding a helper function makes sure that knowledge > is in one place. > > Reviewed-by: Hante Meuleman > Reviewed-by: Daniel (Deognyoun) Kim > Reviewed-by: Franky (Zhenhui) Lin > Reviewed-by: Pieter-Paul Giesberts > Signed-off-by: Arend van Spriel Thanks, 6 patches applied to wireless-drivers-next.git: a1ce7a0d6a4f brcmfmac: use helper function for changing SDIO state ad5a52518aa5 brcmfmac: Remove error print for invalid key index. c7cd5d27d848 brcmfmac: add debugfs file containing revision info 9982464379e8 brcmfmac: make sdio suspend wait for threads to freeze a7b134a7676e brcmfmac: Dont sleep when ctrl frames to transmit. 661fa95ddb9e brcmfmac: Fix escan timer causing oops. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mwifiex: use alloc_workqueue's format strings capabilities for WQnames
> alloc_workqueue() has string format formation ability e.g. wqname%ifname > will be treated as wqnameifname. Use this and remove string operations > while defining strings for workqueue names. > > Reported-by: Kees Cook > Signed-off-by: Avinash Patil Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcm80211: drop unreachable else case
> the if/elseif/else is exhaustive - there is no 4th case given the > rssi_ctrl_mask = RADIO_2055_NBRSSI_SEL | RADIO_2055_WBRSSI_G1_SEL | > RADIO_2055_WBRSSI_G2_SEL; > so this unreachable else case (dead code) can be dropped. > > Signed-off-by: Nicholas Mc Guire Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcmfmac: use msecs_to_jiffies for time conversion
> This is only an API consolidation and should make things more readable > it replaces var * HZ / 1000 by msecs_to_jiffies(var). > > Signed-off-by: Nicholas Mc Guire > Acked-by: Arend van Spriel Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/7] ath9k: Fix descriptors for keep-alive frame
> From: Sujith Manoharan > > Along with AR9462, AR9565 also has an extra field > in the TX descriptor which needs to be zeroed out > for the keep alive frame. This makes the earlier > REG_WRITE redundant, so it can be removed. > > Signed-off-by: Sujith Manoharan Thanks, 7 patches applied to wireless-drivers-next.git: 2a0eef1ac629 ath9k: Fix descriptors for keep-alive frame 0d35024cad0f ath9k: Set keep awake timer ff6f0c036b32 ath9k: Add new MCI states b39adc63bf0c ath9k: Check MCI PowerSave state 6aaefab6cfe8 ath9k: Handle additional patterns on wakeup 3277b20270ee ath9k: Clear additional WoW events aa96af82b873 ath9k: Restart TSF2 timers on wakeup Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ssb: Silence warning for unknown backplane revision
Larry Finger writes: > When using a BCM4318 in a PCMCIA format, I get a startup message that the > device uses backplane revision 0xF00. Next a WARNING is logged. Despite > the message, the device works fine, This patch silences the warning. > > Cc: Rafał Miłecki > Signed-off-by: Larry Finger Should this go to 4.0? -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: Improve handling of IPv6 packets
Larry Finger writes: > Routine rtl_is_special_data() is supposed to identify packets that need to > use a low bit rate so that the probability of successful transmission is > high. The current version has a bug that causes all IPv6 packets to be > labelled as special, with a corresponding low rate of transmission. A > complete fix will be quite intrusive, but until that is available, all > IPv6 packets are identified as regular. > > This patch also removes a magic number. > > Reported-and-tested-by: Alan Fisher > Signed-off-by: Larry Finger > Cc: Stable [3.18+] > Cc: Alan Fisher Should this go to 4.0? -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ath10k: refactor p2p noa code
Some files are getting bloated and it makes sense
to split some of the code into separate files. Do
so with the P2P NoA code and prepare it for reuse.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/Makefile | 3 +-
drivers/net/wireless/ath/ath10k/p2p.c| 124 +++
drivers/net/wireless/ath/ath10k/p2p.h| 26 +++
drivers/net/wireless/ath/ath10k/wmi.c| 91 +--
4 files changed, 156 insertions(+), 88 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath10k/p2p.c
create mode 100644 drivers/net/wireless/ath/ath10k/p2p.h
diff --git a/drivers/net/wireless/ath/ath10k/Makefile
b/drivers/net/wireless/ath/ath10k/Makefile
index f4dbb3e..92a1e09 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -10,7 +10,8 @@ ath10k_core-y += mac.o \
wmi.o \
wmi-tlv.o \
bmi.o \
-hw.o
+hw.o \
+p2p.o
ath10k_core-$(CONFIG_ATH10K_DEBUGFS) += spectral.o
ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/ath10k/p2p.c
b/drivers/net/wireless/ath/ath10k/p2p.c
new file mode 100644
index 000..79d7485
--- /dev/null
+++ b/drivers/net/wireless/ath/ath10k/p2p.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright (c) 2015 Qualcomm Atheros, Inc.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "core.h"
+#include "wmi.h"
+#include "p2p.h"
+
+static void ath10k_p2p_noa_ie_fill(u8 *data, size_t len,
+ const struct wmi_p2p_noa_info *noa)
+{
+ struct ieee80211_p2p_noa_attr *noa_attr;
+ u8 ctwindow_oppps = noa->ctwindow_oppps;
+ u8 ctwindow = ctwindow_oppps >> WMI_P2P_OPPPS_CTWINDOW_OFFSET;
+ bool oppps = !!(ctwindow_oppps & WMI_P2P_OPPPS_ENABLE_BIT);
+ __le16 *noa_attr_len;
+ u16 attr_len;
+ u8 noa_descriptors = noa->num_descriptors;
+ int i;
+
+ /* P2P IE */
+ data[0] = WLAN_EID_VENDOR_SPECIFIC;
+ data[1] = len - 2;
+ data[2] = (WLAN_OUI_WFA >> 16) & 0xff;
+ data[3] = (WLAN_OUI_WFA >> 8) & 0xff;
+ data[4] = (WLAN_OUI_WFA >> 0) & 0xff;
+ data[5] = WLAN_OUI_TYPE_WFA_P2P;
+
+ /* NOA ATTR */
+ data[6] = IEEE80211_P2P_ATTR_ABSENCE_NOTICE;
+ noa_attr_len = (__le16 *)&data[7]; /* 2 bytes */
+ noa_attr = (struct ieee80211_p2p_noa_attr *)&data[9];
+
+ noa_attr->index = noa->index;
+ noa_attr->oppps_ctwindow = ctwindow;
+ if (oppps)
+ noa_attr->oppps_ctwindow |= IEEE80211_P2P_OPPPS_ENABLE_BIT;
+
+ for (i = 0; i < noa_descriptors; i++) {
+ noa_attr->desc[i].count =
+ __le32_to_cpu(noa->descriptors[i].type_count);
+ noa_attr->desc[i].duration = noa->descriptors[i].duration;
+ noa_attr->desc[i].interval = noa->descriptors[i].interval;
+ noa_attr->desc[i].start_time = noa->descriptors[i].start_time;
+ }
+
+ attr_len = 2; /* index + oppps_ctwindow */
+ attr_len += noa_descriptors * sizeof(struct ieee80211_p2p_noa_desc);
+ *noa_attr_len = __cpu_to_le16(attr_len);
+}
+
+static size_t ath10k_p2p_noa_ie_len_compute(const struct wmi_p2p_noa_info *noa)
+{
+ size_t len = 0;
+
+ if (!noa->num_descriptors &&
+ !(noa->ctwindow_oppps & WMI_P2P_OPPPS_ENABLE_BIT))
+ return 0;
+
+ len += 1 + 1 + 4; /* EID + len + OUI */
+ len += 1 + 2; /* noa attr + attr len */
+ len += 1 + 1; /* index + oppps_ctwindow */
+ len += noa->num_descriptors * sizeof(struct ieee80211_p2p_noa_desc);
+
+ return len;
+}
+
+static void ath10k_p2p_noa_ie_assign(struct ath10k_vif *arvif, void *ie,
+size_t len)
+{
+ struct ath10k *ar = arvif->ar;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ kfree(arvif->u.ap.noa_data);
+
+ arvif->u.ap.noa_data = ie;
+ arvif->u.ap.noa_len = len;
+}
+
+static void __ath10k_p2p_noa_update(struct ath10k_vif *arvif,
+ const struct wmi_p2p_noa_info *noa)
+{
+ struct ath10k *ar = arvif->ar;
+ void *ie;
+ size_t len;
+
+ lockdep_assert_held(&ar->d
[PATCH 2/2] ath10k: implement handling of p2p noa event
Since new wmi-tlv firmware doesn't have SWBA event
the only way to deliver P2P NoA information is
through a new dedicated event.
This fixes P2P GO Probe Responses to include P2P
NoA when appropriate on the new firmware.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/p2p.c | 32
drivers/net/wireless/ath/ath10k/p2p.h | 2 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 41 +++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 4 +++
4 files changed, 79 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/p2p.c
b/drivers/net/wireless/ath/ath10k/p2p.c
index 79d7485..c0b6ffa 100644
--- a/drivers/net/wireless/ath/ath10k/p2p.c
+++ b/drivers/net/wireless/ath/ath10k/p2p.c
@@ -16,6 +16,7 @@
#include "core.h"
#include "wmi.h"
+#include "mac.h"
#include "p2p.h"
static void ath10k_p2p_noa_ie_fill(u8 *data, size_t len,
@@ -122,3 +123,34 @@ void ath10k_p2p_noa_update(struct ath10k_vif *arvif,
__ath10k_p2p_noa_update(arvif, noa);
spin_unlock_bh(&ar->data_lock);
}
+
+struct ath10k_p2p_noa_arg {
+ u32 vdev_id;
+ const struct wmi_p2p_noa_info *noa;
+};
+
+static void ath10k_p2p_noa_update_vdev_iter(void *data, u8 *mac,
+ struct ieee80211_vif *vif)
+{
+ struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_p2p_noa_arg *arg = data;
+
+ if (arvif->vdev_id != arg->vdev_id)
+ return;
+
+ ath10k_p2p_noa_update(arvif, arg->noa);
+}
+
+void ath10k_p2p_noa_update_by_vdev_id(struct ath10k *ar, u32 vdev_id,
+ const struct wmi_p2p_noa_info *noa)
+{
+ struct ath10k_p2p_noa_arg arg = {
+ .vdev_id = vdev_id,
+ .noa = noa,
+ };
+
+ ieee80211_iterate_active_interfaces_atomic(ar->hw,
+ IEEE80211_IFACE_ITER_NORMAL,
+
ath10k_p2p_noa_update_vdev_iter,
+ &arg);
+}
diff --git a/drivers/net/wireless/ath/ath10k/p2p.h
b/drivers/net/wireless/ath/ath10k/p2p.h
index 171d30d6..7be616e2 100644
--- a/drivers/net/wireless/ath/ath10k/p2p.h
+++ b/drivers/net/wireless/ath/ath10k/p2p.h
@@ -22,5 +22,7 @@ struct wmi_p2p_noa_info;
void ath10k_p2p_noa_update(struct ath10k_vif *arvif,
const struct wmi_p2p_noa_info *noa);
+void ath10k_p2p_noa_update_by_vdev_id(struct ath10k *ar, u32 vdev_id,
+ const struct wmi_p2p_noa_info *noa);
#endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index f34baa0..15728e0 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -20,6 +20,7 @@
#include "wmi.h"
#include "wmi-ops.h"
#include "wmi-tlv.h"
+#include "p2p.h"
/***/
/* TLV helpers */
@@ -62,6 +63,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_STRUCT_P2P_NOA_EVENT]
+ = { .min_len = sizeof(struct wmi_tlv_p2p_noa_ev) },
};
static int
@@ -296,6 +299,41 @@ static int ath10k_wmi_tlv_event_diag(struct ath10k *ar,
return 0;
}
+static int ath10k_wmi_tlv_event_p2p_noa(struct ath10k *ar,
+ struct sk_buff *skb)
+{
+ const void **tb;
+ const struct wmi_tlv_p2p_noa_ev *ev;
+ const struct wmi_p2p_noa_info *noa;
+ int ret, vdev_id;
+
+ tb = ath10k_wmi_tlv_parse_alloc(ar, skb->data, skb->len, GFP_ATOMIC);
+ if (IS_ERR(tb)) {
+ ret = PTR_ERR(tb);
+ ath10k_warn(ar, "failed to parse tlv: %d\n", ret);
+ return ret;
+ }
+
+ ev = tb[WMI_TLV_TAG_STRUCT_P2P_NOA_EVENT];
+ noa = tb[WMI_TLV_TAG_STRUCT_P2P_NOA_INFO];
+
+ if (!ev || !noa) {
+ kfree(tb);
+ return -EPROTO;
+ }
+
+ vdev_id = __le32_to_cpu(ev->vdev_id);
+
+ ath10k_dbg(ar, ATH10K_DBG_WMI,
+ "wmi tlv p2p noa vdev_id %i descriptors %hhu\n",
+ vdev_id, noa->num_descriptors);
+
+ ath10k_p2p_noa_update_by_vdev_id(ar, vdev_id, noa);
+
+ kfree(tb);
+ return 0;
+}
+
/***/
/* TLV ops */
/***/
@@ -417,6 +455,9 @@ static void ath10k_wmi_tlv_op_rx(struct ath10k *ar, struct
sk_buff *skb)
case WMI_TLV_DIAG_EVENTID:
ath10k_wmi_tlv_event_diag(ar, skb);
break;
+ case WMI_TLV_P2P_NOA_EVENTID:
+ ath10k_wmi_tlv_event_p2p_noa(ar, skb);
+ break;
default:
ath10k_warn(ar, "Unknown eventid: %d\n", id);
break;
diff --
Re: [PATCH 9/9] wil6210: Align Rx buffers on 4*n+2
Vladimir Kondratiev writes: > On Sunday, February 15, 2015 02:02:38 PM Vladimir Kondratiev wrote: >> For the normal (non-sniffer) mode of operation, align Rx buffer >> on 4*n+2, so IP header (after 14 bytes of Ethernet header) >> will start dword aligned. This accelerated IP stack a little bit. >> >> Signed-off-by: Vladimir Kondratiev >> > Kalle, > > please do not apply this patch. I found last minute problem with it - > hardware is not always happy. > > For now, drop it please. I will do more testing and re-submit this > patch if everything wends OK. Ok, I dropped this patch. Patches 1-8 are still on my queue. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RTL8192cu: not work on linux-2.6.35
Hello! I work with board on FreeScale iMX287 CPU and use linux-2.6.35. For use WiFi USB Trendnet TEW-648UBM I download driver (rtl8188C_8192C_usb_linux_v4.0.2_9000.20130911.tar.gz) from Realtek site and build it. ~ # insmod /lib/modules/2.6.35.3\+/kernel/drivers/net/wireless/8192cu.ko rtl8192cu driver version=v4.0.2_9000.20130911 build time: Feb 22 2015 14:44:01 usbcore: registered new interface driver rtl8192cu usb 1-1: new high speed USB device using fsl-ehci and address 2 usb 1-1: device v20f4 p648b is not supported usb_endpoint_descriptor(0): bLength=7 bDescriptorType=5 bEndpointAddress=81 wMaxPacketSize=200 bInterval=0 RT_usb_endpoint_is_bulk_in = 1 usb_endpoint_descriptor(1): bLength=7 bDescriptorType=5 bEndpointAddress=2 wMaxPacketSize=200 bInterval=0 RT_usb_endpoint_is_bulk_out = 2 usb_endpoint_descriptor(2): bLength=7 bDescriptorType=5 bEndpointAddress=3 wMaxPacketSize=200 bInterval=0 RT_usb_endpoint_is_bulk_out = 3 usb_endpoint_descriptor(3): bLength=7 bDescriptorType=5 bEndpointAddress=84 wMaxPacketSize=40 bInterval=1 RT_usb_endpoint_is_int_in = 4, Interval = 1 nr_endpoint=4, in_num=2, out_num=2 USB_SPEED_HIGH CHIP TYPE: RTL8188C_8192C register rtw_netdev_ops to netdev_ops Chip Version ID: VERSION_NORMAL_TSMC_CHIP_88C. RF_Type is 3!! EEPROM type is E-FUSE > ReadAdapterInfo8192C Boot from EFUSE, Autoload OK ! EEPROMVID = 0x20f4 EEPROMPID = 0x648b EEPROMCustomerID : 0x00 EEPROMSubCustomerID: 0x00 RT_CustomerID: 0x00 _ReadMACAddress MAC Address from EFUSE = d8:eb:97:1f:07:a2 EEPROMRegulatory = 0x0 _ReadBoardType(0) BT Coexistance = disable mlmepriv.ChannelPlan = 0x02 _ReadPSSetting...bHWPwrPindetect(0)-bHWPowerdown(0) ,bSupportRemoteWakeup(0) ### PS params=> power_mgnt(1),usbss_enable(0) ### ### AntDivCfg(0) readAdapterInfo_8192CU(): REPLACEMENT = 1 < ReadAdapterInfo8192C in 340 ms rtw_macaddr_cfg MAC Address = d8:eb:97:1f:07:a2 bDriverStopped:1, bSurpriseRemoved:0, bup:0, hw_init_completed:0 _rtw_drv_register_netdev, MAC Address (if1) = d8:eb:97:1f:07:a2 ~ # ip link show wlan0 4: wlan0: mtu 1500 qdisc noop qlen 1000 link/ether d8:eb:97:1f:07:a2 brd ff:ff:ff:ff:ff:ff ~ # ifconfig wlan0 up +871x_drv - drv_open, bup=0 ===> FirmwareDownload91C() fw:Rtl819XFwImageArray_TSMC FirmwareDownload92C accquire FW from embedded image fw_ver=v88, fw_subver=2, sig=0x88c0 fw download ok! Set RF Chip ID to RF_6052 and RF type to 1T1R. IQK:Start!!! Path A IQK Success!! Path A IQK Success!! IQK: final_candidate is 0 IQK: RegE94=105 RegE9C=12 RegEA4=fd RegEAC=1 RegEB4=0 RegEBC=0 RegEC4=0 RegECC=0 Path A IQ Calibration Success ! pdmpriv->TxPowerTrackControl = 1 rtl8192cu_hal_init in 820ms MAC Address = d8:eb:97:1f:07:a2 -871x_drv - drv_open, bup=1 ~ # ###=> usb_read_port_complete => urb status(-71) ###=> usb_read_port_complete => urb status(-71) ==>rtw_ps_processor .fw_state(0) ==>ips_enter cnts:1 ===> rtw_ips_pwr_down... > rtw_ips_dev_unload... usb_read_port_cancel usb_read_port_complete()-1284: RX Warning! bDriverStopped(0) OR bSurpriseRemove) usb_read_port_complete()-1284: RX Warning! bDriverStopped(0) OR bSurpriseRemove) usb_read_port_complete()-1284: RX Warning! bDriverStopped(0) OR bSurpriseRemove) usb_read_port_complete()-1284: RX Warning! bDriverStopped(0) OR bSurpriseRemove) usb_write_port_cancel ==> rtl8192cu_hal_deinit bkeepfwalive(0) card disble without HWSM... reg 0x600, usb write 1 fail, status:-110 value=0x40, vendorreq_times:1 reg 0x600, usb write 1 fail, status:-110 value=0x40, vendorreq_times:2 reg 0x600, usb write 1 fail, status:-110 value=0x40, vendorreq_times:3 reg 0x600, usb write 1 fail, status:-110 value=0x40, vendorreq_times:4 reg 0x600, usb write 1 fail, status:-110 value=0x40, vendorreq_times:5 [dvobj:c7ca9000][ERROR] continual_urb_error:5 > 4 <=== rtw_ips_pwr_down. in 2600ms rtw_cmd_thread: DriverStopped(0) SurpriseRemoved(1) break at line 482 Unfortunately wireless-tools can't work with interface wlan0: ~ # iwconfig --version iwconfig Wireless-Tools version 29 Compatible with Wireless Extension v11 to v22. KernelCurrently compiled with Wireless Extension v22. ~ # iwconfig wlan0 wlan0 no wireless extensions. ~ # iwlist wlan0 scan wlan0 Interface doesn't support scanning. Yes, this chip supported in latest linux, unfortunately now I can't run new linux on board. Can you help run rtl8192cu on linux-2.6.35? Thank you and excuse me for my bad english. -- Best regards, Brilliantov Kirill Vladimirovich -- 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:45AM -0800, 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? > 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.. Of all people, I do actually have some hatred on the one-liner to force minimum rate for all EAPOL TX attempts. That is punishing the vast majority of cases where the AP is perfectly fine with higher MCS rates being used (and MCS 0 being sufficient fallback option) for EAPOL. Being able to use higher TX rates as the initial attempt is a nice feature and even though this may be limited to number of upstream Linux drivers today, that part of the feature is an improvement, IMHO. This can even be more robust in some environments especially when going through long EAP exchange with certain types of interference. That said, it is clear to me that we need to modify the current behavior to be more conservative with some of the EAPOL frame retries. I'm not familiar enough with the current minstrel implementation to prepare a clean patch doing the approach I think that should be used here (replace the last rate with a low basic rate and add couple of tries with it). I have reason to believe that Felix might be able to look at this in couple of weeks, though. In other words, I think I'll send out a more formal version of the patches so that they can be applied now if desired while keeping in mind that we may want to replace the minrate-for-EAPOL with something else later. As far as the EAPOL-Key msg 4/4 retries without encryption patch is concerned, I think I have enough concern on the couple of corner cases that I know it does not address (and may break), so it may take some more time before I'm ready to suggest it (or a bit modified version of it) to be applied, though. -- 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
[PATCH] ath10k: fix TxBF VHT capabilities for 2+ RF-chain devices
Firmware doesn't report a complete and
ready-to-use vht cap. Instead the driver is
supposed to fill in the missing bits related to
number of chains.
This effectively increases Compressed Steering
Number and Number of Sounding Dimensions in
AssocReq frames for devices with more than one RF
chain and should improve TxBF performance.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/mac.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 0f39af7..383250e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5263,11 +5263,30 @@ static struct ieee80211_sta_vht_cap
ath10k_create_vht_cap(struct ath10k *ar)
{
struct ieee80211_sta_vht_cap vht_cap = {0};
u16 mcs_map;
+ u32 val;
int i;
vht_cap.vht_supported = 1;
vht_cap.cap = ar->vht_cap_info;
+ if (ar->vht_cap_info & (IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |
+ IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE)) {
+ val = ar->num_rf_chains - 1;
+ val <<= IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT;
+ val &= IEEE80211_VHT_CAP_BEAMFORMEE_STS_MASK;
+
+ vht_cap.cap |= val;
+ }
+
+ if (ar->vht_cap_info & (IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE |
+ IEEE80211_VHT_CAP_MU_BEAMFORMER_CAPABLE)) {
+ val = ar->num_rf_chains - 1;
+ val <<= IEEE80211_VHT_CAP_SOUNDING_DIMENSIONS_SHIFT;
+ val &= IEEE80211_VHT_CAP_SOUNDING_DIMENSIONS_MASK;
+
+ vht_cap.cap |= val;
+ }
+
mcs_map = 0;
for (i = 0; i < 8; i++) {
if (i < ar->num_rf_chains)
--
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: [ath9k-devel] AR9462 problems connecting again..
On 02/26/15 06:55, Linus Torvalds wrote: 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. That makes sense as brcmsmac is a mac80211 driver that uses the minstrel-ht rate control algorithm. iwlwifi is also a mac80211 driver but it uses a different rate control algorithm so if you have that lying around it would be interesting to test that (if you did not already do that). Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
re: iwlwifi: split the drivers for agn and legacy devices 3945/4965
Hello Wey-Yi Guy,
The patch be663ab67077: "iwlwifi: split the drivers for agn and
legacy devices 3945/4965" from Feb 21, 2011, leads to the following
static checker warning:
drivers/net/wireless/iwlegacy/4965-mac.c:6390 il4965_init_drv()
error: potential NULL dereference 'il->ieee_rates'.
Also:
drivers/net/wireless/iwlegacy/3945-mac.c:3541 il3945_init_drv()
error: potential NULL dereference 'il->ieee_rates'.
The il_init_geos() function is the only place where we set
"->ieee_rates" to non-NULL. There are two callers and they both rely
on il_init_geos() to set it to non-NULL otherwise they crash. However,
there is a return in il_init_geos() which does not set ->ieee_rates so
if we ever hit that path then the kernel will Oops. This makes the
static checkers complain.
drivers/net/wireless/iwlegacy/common.c
3431 int
3432 il_init_geos(struct il_priv *il)
3433 {
3434 struct il_channel_info *ch;
3435 struct ieee80211_supported_band *sband;
3436 struct ieee80211_channel *channels;
3437 struct ieee80211_channel *geo_ch;
3438 struct ieee80211_rate *rates;
3439 int i = 0;
3440 s8 max_tx_power = 0;
3441
3442 if (il->bands[IEEE80211_BAND_2GHZ].n_bitrates ||
3443 il->bands[IEEE80211_BAND_5GHZ].n_bitrates) {
3444 D_INFO("Geography modes already initialized.\n");
3445 set_bit(S_GEO_CONFIGURED, &il->status);
3446 return 0;
We have not set ->ieee_rates here. If we ever hit this return then the
kernel will Oops.
3447 }
3448
Here is one caller, the other is the same.
drivers/net/wireless/iwlegacy/4965-mac.c
6362 il->ieee_channels = NULL;
6363 il->ieee_rates = NULL;
^
We set il->ieee_rates to NULL.
6364 il->band = IEEE80211_BAND_2GHZ;
6365
6366 il->iw_mode = NL80211_IFTYPE_STATION;
6367 il->current_ht_config.smps = IEEE80211_SMPS_STATIC;
6368 il->missed_beacon_threshold = IL_MISSED_BEACON_THRESHOLD_DEF;
6369
6370 /* initialize force reset */
6371 il->force_reset.reset_duration = IL_DELAY_NEXT_FORCE_FW_RELOAD;
6372
6373 /* Choose which receivers/antennas to use */
6374 if (il->ops->set_rxon_chain)
6375 il->ops->set_rxon_chain(il);
6376
6377 il_init_scan_params(il);
6378
6379 ret = il_init_channel_map(il);
6380 if (ret) {
6381 IL_ERR("initializing regulatory failed: %d\n", ret);
6382 goto err;
6383 }
6384
6385 ret = il_init_geos(il);
Assume we hit the problematic return.
6386 if (ret) {
6387 IL_ERR("initializing geos failed: %d\n", ret);
6388 goto err_free_channel_map;
6389 }
6390 il4965_init_hw_rates(il, il->ieee_rates);
^^
This will lead to a NULL dereference inside the il4965_init_hw_rates()
function.
6391
6392 return 0;
regards,
dan carpenter
--
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
