Re: about .dump_station() callback
On Tue, 2015-06-09 at 11:19 +0200, Arend van Spriel wrote: I am looking in get_station() and consequently dump_station() callback for our brcmfmac driver. The latter is called with index. Can I expect this to be starting at 0 and iterate through or can it be requested in any order. You can expect that, yes. If it would help, we could instead give the driver one or two pointers to unsigned long values that start out as 0 and can be controlled entirely by the driver? 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
about .dump_station() callback
Hi Johannes, I am looking in get_station() and consequently dump_station() callback for our brcmfmac driver. The latter is called with index. Can I expect this to be starting at 0 and iterate through or can it be requested in any order. 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
[PATCH] ath9k_htc: add support of channel switch
Add the support of channel switching functionality, similar
to ath9k support.
Tested with TP-Link TL-WN722N and TL-WN821N.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
drivers/net/wireless/ath/ath9k/htc.h| 2 ++
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 19 +++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 ++-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 17 +
4 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index 5dbc617..16dff4b 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -531,6 +531,7 @@ struct ath9k_htc_priv {
struct ath9k_debug debug;
#endif
struct mutex mutex;
+ struct ieee80211_vif *csa_vif;
};
static inline void ath_read_cachesize(struct ath_common *common, int *csz)
@@ -584,6 +585,7 @@ void ath9k_htc_tx_drain(struct ath9k_htc_priv *priv);
void ath9k_htc_txstatus(struct ath9k_htc_priv *priv, void *wmi_event);
void ath9k_tx_failed_tasklet(unsigned long data);
void ath9k_htc_tx_cleanup_timer(unsigned long data);
+bool ath9k_htc_csa_is_finished(struct ath9k_htc_priv *priv);
int ath9k_rx_init(struct ath9k_htc_priv *priv);
void ath9k_rx_cleanup(struct ath9k_htc_priv *priv);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
index e8b6ec3..e6bcb4c 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
@@ -257,6 +257,8 @@ static void ath9k_htc_send_beacon(struct ath9k_htc_priv
*priv,
}
spin_unlock_bh(priv-beacon_lock);
+
+ ath9k_htc_csa_is_finished(priv);
}
static int ath9k_htc_choose_bslot(struct ath9k_htc_priv *priv,
@@ -503,3 +505,20 @@ void ath9k_htc_beacon_reconfig(struct ath9k_htc_priv *priv)
return;
}
}
+
+bool ath9k_htc_csa_is_finished(struct ath9k_htc_priv *priv)
+{
+ struct ieee80211_vif *vif;
+
+ vif = priv-csa_vif;
+ if (!vif || !vif-csa_active)
+ return false;
+
+ if (!ieee80211_csa_is_complete(vif))
+ return false;
+
+ ieee80211_csa_finish(vif);
+
+ priv-csa_vif = NULL;
+ return true;
+}
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 7468562..9569010 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -744,7 +744,8 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
hw-wiphy-flags = ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
hw-wiphy-flags |= WIPHY_FLAG_IBSS_RSN |
- WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
+ WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
+ WIPHY_FLAG_HAS_CHANNEL_SWITCH;
hw-wiphy-flags |= WIPHY_FLAG_SUPPORTS_TDLS;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index b71f307..dab1323 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1134,6 +1134,9 @@ static void ath9k_htc_remove_interface(struct
ieee80211_hw *hw,
priv-nvifs--;
priv-vif_slot = ~(1 avp-index);
+ if (priv-csa_vif == vif)
+ priv-csa_vif = NULL;
+
ath9k_htc_remove_station(priv, vif, NULL);
DEC_VIF(priv, vif-type);
@@ -1841,6 +1844,19 @@ static int ath9k_htc_get_antenna(struct ieee80211_hw
*hw, u32 *tx_ant,
return 0;
}
+static void ath9k_htc_channel_switch_beacon(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct cfg80211_chan_def *chandef)
+{
+ struct ath9k_htc_priv *priv = hw-priv;
+
+ /* mac80211 does not support CSA in multi-if cases (yet) */
+ if (WARN_ON(priv-csa_vif))
+ return;
+
+ priv-csa_vif = vif;
+}
+
struct ieee80211_ops ath9k_htc_ops = {
.tx = ath9k_htc_tx,
.start = ath9k_htc_start,
@@ -1867,6 +1883,7 @@ struct ieee80211_ops ath9k_htc_ops = {
.set_bitrate_mask = ath9k_htc_set_bitrate_mask,
.get_stats = ath9k_htc_get_stats,
.get_antenna= ath9k_htc_get_antenna,
+ .channel_switch_beacon = ath9k_htc_channel_switch_beacon,
#ifdef CONFIG_ATH9K_HTC_DEBUGFS
.get_et_sset_count = ath9k_htc_get_et_sset_count,
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about .dump_station() callback
On 06/09/15 11:41, Johannes Berg wrote: On Tue, 2015-06-09 at 11:19 +0200, Arend van Spriel wrote: I am looking in get_station() and consequently dump_station() callback for our brcmfmac driver. The latter is called with index. Can I expect this to be starting at 0 and iterate through or can it be requested in any order. You can expect that, yes. Thanks. Guess it is nl80211.c assuring that. I should have checked that first. See that I have to return -ENOENT when iteration is done. If it would help, we could instead give the driver one or two pointers to unsigned long values that start out as 0 and can be controlled entirely by the driver? Not sure if I understand this. What would those pointers represent? 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: [PATCH v2] ath10k: remove unused variable 'id' in ath10k_pci_tx_pipe_cleanup()
Raja Mani rm...@qti.qualcomm.com writes: mete_data is extracted from ce descriptor and stored in variable 'id'. later, id is not used anywhere in the same function. Fixes: d84a512dca23 (ath10k: remove transfer_id from ath10k_hif_cb::tx_completion) Signed-off-by: Raja Mani rm...@qti.qualcomm.com Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about .dump_station() callback
On Tue, 2015-06-09 at 12:52 +0200, Arend van Spriel wrote: Thanks. Guess it is nl80211.c assuring that. I should have checked that first. See that I have to return -ENOENT when iteration is done. Right. If it would help, we could instead give the driver one or two pointers to unsigned long values that start out as 0 and can be controlled entirely by the driver? Not sure if I understand this. What would those pointers represent? Well, you could put in there whatever you like :) Though realistically I wouldn't expect you to put anything other than the sta_idx that you currently get. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] wil6210 patches
Vladimir Kondratiev qca_vkond...@qca.qualcomm.com writes: Small fixes here and there; save for hidden SSID Hamad Kadmany (1): wil6210: Support hidden SSID Vladimir Kondratiev (5): wil6210: modparam for bcast ring size wil6210: add NIC memory region mac_rgf_ext wil6210: add per-MCS Rx stats wil6210: platform hooks for modile init/exit wil6210: reorder init sequence Thanks, all six applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ath10k: fix ar-rx_channel updating logic
Michal Kazior michal.kaz...@tieto.com writes: Channel contexts aren't iterable until after they've been added to the driver. The code assumed otherwise. This problem could result in: * rx_channel being NULL and forcing Rx path to go the slow way to get channel on QCA988X, * report incorrect channel when running multi-channel on QCA61X4 hw2.1, * report incorrect channel after AP channel switch. Fixes: 500ff9f9389d (ath10k: implement chanctx API) Signed-off-by: Michal Kazior michal.kaz...@tieto.com Thanks, all three patches applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: prevent memory leak in wmi rx ops
Michal Kazior michal.kaz...@tieto.com writes: Found during code review. This was pretty much impossible to happen but better safe than sorry. Signed-off-by: Michal Kazior michal.kaz...@tieto.com Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: wilc1000: remove unused variables
From: Madhusudhanan Ravindran mravi...@visteon.com
removed few variables which are assigned but
never used.
Signed-off-by: Madhusudhanan Ravindran mravi...@visteon.com
---
drivers/staging/wilc1000/linux_wlan.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index 592b8ae..860f336 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -259,7 +259,6 @@ static int dev_state_ev_handler(struct notifier_block
*this, unsigned long event
tstrWILC_WFIDrv *pstrWFIDrv;
struct net_device *dev;
u8 *pIP_Add_buff;
- WILC_Sint32 s32status = WILC_FAIL;
perInterface_wlan_t *nic;
u8 null_ip[4] = {0};
char wlan_dev_name[5] = wlan0;
@@ -317,7 +316,7 @@ static int dev_state_ev_handler(struct notifier_block
*this, unsigned long event
pIP_Add_buff = (char *) ((dev_iface-ifa_address));
PRINT_D(GENERIC_DBG, IP add=%d:%d:%d:%d \n, pIP_Add_buff[0],
pIP_Add_buff[1], pIP_Add_buff[2], pIP_Add_buff[3]);
- s32status =
host_int_setup_ipaddress((WILC_WFIDrvHandle)pstrWFIDrv, pIP_Add_buff,
nic-u8IfIdx);
+ host_int_setup_ipaddress((WILC_WFIDrvHandle)pstrWFIDrv,
pIP_Add_buff, nic-u8IfIdx);
break;
@@ -341,7 +340,7 @@ static int dev_state_ev_handler(struct notifier_block
*this, unsigned long event
pIP_Add_buff = null_ip;
PRINT_D(GENERIC_DBG, IP add=%d:%d:%d:%d \n, pIP_Add_buff[0],
pIP_Add_buff[1], pIP_Add_buff[2], pIP_Add_buff[3]);
- s32status =
host_int_setup_ipaddress((WILC_WFIDrvHandle)pstrWFIDrv, pIP_Add_buff,
nic-u8IfIdx);
+ host_int_setup_ipaddress((WILC_WFIDrvHandle)pstrWFIDrv,
pIP_Add_buff, nic-u8IfIdx);
break;
@@ -1102,7 +1101,6 @@ static int linux_wlan_init_test_config(struct net_device
*dev, linux_wlan_t *p_n
#ifndef STATIC_MACADDRESS
unsigned char mac_add[] = {0x00, 0x80, 0xC2, 0x5E, 0xa2, 0xff};
#endif
- unsigned int chipid = 0;
/*BugID_5077*/
struct WILC_WFI_priv *priv;
@@ -1118,7 +1116,7 @@ static int linux_wlan_init_test_config(struct net_device
*dev, linux_wlan_t *p_n
PRINT_D(INIT_DBG, Host = %x\n, (WILC_Uint32)pstrWFIDrv);
PRINT_D(INIT_DBG, MAC address is : %02x-%02x-%02x-%02x-%02x-%02x\n,
mac_add[0], mac_add[1], mac_add[2], mac_add[3], mac_add[4], mac_add[5]);
- chipid = wilc_get_chipid(0);
+ wilc_get_chipid(0);
if (g_linux_wlan-oup.wlan_cfg_set == NULL) {
@@ -2066,7 +2064,6 @@ int mac_open(struct net_device *ndev)
/*No need for setting mac address here anymore,*/
/*Just set it in init_test_config()*/
unsigned char mac_add[ETH_ALEN] = {0};
- int status;
int ret = 0;
int i = 0;
struct WILC_WFI_priv *priv;
@@ -2095,7 +2092,7 @@ int mac_open(struct net_device *ndev)
Set_machw_change_vir_if(WILC_FALSE);
- status = host_int_get_MacAddress(priv-hWILCWFIDrv, mac_add);
+ host_int_get_MacAddress(priv-hWILCWFIDrv, mac_add);
PRINT_D(INIT_DBG, Mac address: %x:%x:%x:%x:%x:%x\n, mac_add[0],
mac_add[1], mac_add[2],
mac_add[3], mac_add[4], mac_add[5]);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: free wmi mgmt event skb when parsing fails
Raja Mani rm...@qti.qualcomm.com writes: When wmi mgmt event function fails to parse given skb, it should be freed on failure condition to avoid memory leaks. Found this during the code review. Signed-off-by: Raja Mani rm...@qti.qualcomm.com Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath6kl: Fix multiple clients associating in AP mode
Brent Taylor moto...@gmail.com writes: When one client is associated and connected to an ar6003 hw version 2.0 with firmware 3.1.1.149, and another client tries to connect, the first client's MAC address is lost in the station list because the aid is always 1. The structure wmi_connect_event has the aid as the second byte in the message, but it should be the first byte. This patch has been tested with linux-3.10.40 Signed-off-by: Brent Taylor moto...@gmail.com Thanks, applied to ath.git. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WEXT]: multiple calls for SIOCGIWSTATS return same value
On Mon, 2015-06-08 at 19:58 -0600, Gerrit Renker wrote: I am primarily referring to the signal level. The first call returns a plausible value e.g. -78dB. All subsequent calls return the same value, regardless of receiver position (moving the laptop). It almost looks like a static value that gets initialized and then does not change. There is a similar behaviour for scan results: the signal levels reported for stations remain the same for all subsequent calls. Previously these also changed with time and position of receiver. You mean BSSes, not stations, right? This is very strange - it seems those should be two entirely different code paths in the kernel. What driver are you using? But then again, you said nl80211/iw works, right? Then the driver shouldn't matter. Do you think you'd be able to use tracing? trace-cmd report -e cfg80211 -e mac80211 would report the calls to/from the driver and could perhaps shed some light. If you can record this, send me the resulting trace.dat file (compressed) off-list. 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] Add new mac80211 driver mwlwifi.
On Tue, 2015-06-09 at 07:25 +, David Lin wrote: 1. That's interesting, why does a PCI(e) driver need OF? This driver will accept parameters in DTS file for band control, antenna setting and power table, to cater for different boards combination inside a system. Ok. I saw some OF references at the very end, but then got a bit side-tracked :) 2. Can you perhaps explain how the STA/AP firmware separation works? For this driver, the AP/STA mode will use the same single firmware binary, so there is no “separation” per se. The firmware will support AP/STA mode. Hmm, interesting. It seemed that there were references in the code to loading different firmware? Might want to look through for that. 3. Does this driver has any relation to mwifiex? Mwifiex is driver for Firmware-based MLME. It interfaces with firmware with 802.3 packets. Mwlwifi is the Host Soft AP/STA driver that works with mac80211. Ok, so basically no relation - makes sense. 1. Directory name “mwlwifi”. This is to be consistent with some predecessor. For example, Intel uses iwlwifi, realtek uses rtlwifi. We do not see a need to change it. This will make sure we keep the original project mwlwifi on openwrt folder remain intact, while we continue to maintain them the same way/pace. That's fine. 2. Interface with F/W. F/W used by this driver is also used by other marvell’s drivers. Yeah, but I'm not saying you should change the interface, I'm just saying you need to properly endian-annotate it. That won't actually change the binary interface, but will make the driver more robust. 3. AMPDU related code. It has been well tested and leveraged from mwl8k. We may enhance it in future, but please accept the current code status for now. I'm not really sure it's correct, but I guess I can't really comment too much on it. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Add new mac80211 driver mwlwifi.
On Saturday, June 06, 2015 9:43 PM, Johannes Berg wrote:
Hi David, all,
I'm not really in the chain here, but I figured I'd review your driver
nonetheless. I'll want to take a closer look at some things, but for now
here's a
bit of a review just of the code.
Can you perhaps explain how the STA/AP firmware separation works? I've not
really managed to figure that out - admittedly with not all that much effort
though.
Hi Johannes,
Questions:
1. That's interesting, why does a PCI(e) driver need OF?
This driver will accept parameters in DTS file for band control, antenna
setting and power table, to cater for different boards combination inside a
system.
2. Can you perhaps explain how the STA/AP firmware separation works?
For this driver, the AP/STA mode will use the same single firmware binary, so
there is no “separation” per se. The firmware will support AP/STA mode.
3. Does this driver has any relation to mwifiex?
Mwifiex is driver for Firmware-based MLME. It interfaces with firmware with
802.3 packets. Mwlwifi is the Host Soft AP/STA driver that works with mac80211.
I will be working on the following changes as you suggested:
1. Remove mwl from filename (mwl_xxx.x - xxx.x).
2. Remove comment for the purpose of the code block and take off static
function pre-declaration.
3. Remove file debug.c and debug.h.
4. Typo error, unnecessary comment, prefer comment style and use BIT MACRO
instead of constant.
5. Move isr related functions to isr.c and isr.h.
6. Remove MACRO for SPIN LOCK and let spin lock be attached to related data
structure.
7. For firmware related structure, use __le16 for u16 and __le32 for u32. Add
compiler control “-D__CHECK_ENDIAN__” to help to check endian problem.
8. For firmware related structure, take off bit field.
We recommend that the followings should not be changed at current stage:
1. Directory name “mwlwifi”.
This is to be consistent with some predecessor. For example, Intel uses
iwlwifi, realtek uses rtlwifi. We do not see a need to change it. This will
make sure we keep the original project mwlwifi on openwrt folder remain intact,
while we continue to maintain them the same way/pace.
2. Interface with F/W.
F/W used by this driver is also used by other marvell’s drivers.
3. AMPDU related code.
It has been well tested and leveraged from mwl8k. We may enhance it in future,
but please accept the current code status for now.
After modification is done, I will come out [PATCH v2] for you to review again.
Thanks,
David
On Thu, 2015-06-04 at 04:57 +, David Lin wrote:
drivers/net/wireless/mwlwifi/Kconfig| 17 +
Does this driver has any relation to mwifiex? Perhaps the same maintainer
team, etc.? Could consider moving all the Marvell drivers into one directory,
but not really necessary I guess.
Out of curiosity - why mwlwifi and not just mwl or similar? :)
Also - consider adding a MAINTAINERS entry for this driver.
drivers/net/wireless/mwlwifi/mwl_debug.c| 207 ++
The mwl_ prefix doesn't really do much for this driver (especially since it's
used for all files) -- I'd consider removing it.
@@ -284,5 +284,6 @@ source drivers/net/wireless/zd1211rw/Kconfig
source drivers/net/wireless/mwifiex/Kconfig
source drivers/net/wireless/cw1200/Kconfig
source drivers/net/wireless/rsi/Kconfig
+source drivers/net/wireless/mwlwifi/Kconfig
Perhaps, just like with the directory structure, we should also consider
having
per-vendor Kconfig structure, like Ethernet drivers have now.
Then again, unless we decide we want to do this for all drivers and all
devices
it doesn't really do much.
+ depends on PCI MAC80211
+ select FW_LOADER
+ select OF
That's interesting, why does a PCI(e) driver need OF?
+/* CONSTANTS AND MACROS
+*/
that one-line comment style (also in other places below, and perhaps other
files) is a but strange
+#define PRT_8BYTES 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x
0x%02x 0x%02x\n
Do you really need the 0x in here? Otherwise it'd be much nicer to use %ph
instead of macros.
+void mwl_debug_prt(u32 classlevel, const char *func, const char
+*format, ...) {
+ debug_string = kmalloc(1024, GFP_ATOMIC);
+
+ if (!debug_string)
+ return;
That seems a bit questionable - when memory allocations start failing is one
of
those places where you really want debug output ...
+ switch (class) {
+ case DBG_CLASS_ENTER:
+ pr_debug(Enter %s() ...\n, func);
+ break;
+ case DBG_CLASS_EXIT:
+ pr_debug(... Exit %s()\n, func);
+ break;
I think you should not have enter/exit logging at all but use function tracing
instead in the unlikely event this becomes necessary.
+ if (strlen(debug_string) 0) {
strlen() 0 seems pretty expensive - perhaps the compiler can optimise it,
but
still.
+ if (debug_string[strlen(debug_string) - 1] == '\n')
+
Re: about .dump_station() callback
On 06/09/15 13:01, Johannes Berg wrote: On Tue, 2015-06-09 at 12:52 +0200, Arend van Spriel wrote: Thanks. Guess it is nl80211.c assuring that. I should have checked that first. See that I have to return -ENOENT when iteration is done. Right. If it would help, we could instead give the driver one or two pointers to unsigned long values that start out as 0 and can be controlled entirely by the driver? Not sure if I understand this. What would those pointers represent? Well, you could put in there whatever you like :) Though realistically I wouldn't expect you to put anything other than the sta_idx that you currently get. Well, I obtain (in ap mode) a list of associated clients and keep that list until iteration is done (or .dump_station() is called with sta_idx == 0). So I am fine with current api. 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
[PATCH] cfg80211: check correct maximum bandwidth for quarter and half rate.
When using quarter and half rates we might want to use self defined
frequencies with self defined country codes closer to the border.
To avoid these frequencies to be disabled, we need to check if
the frequency fits the band with the actual bandwidth.
Signed-off-by: Matthias May matthias@neratec.com
---
net/wireless/reg.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index fc2f135..c8fabda 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1016,6 +1016,7 @@ freq_reg_info_regd(struct wiphy *wiphy, u32 center_freq,
for (i = 0; i regd-n_reg_rules; i++) {
const struct ieee80211_reg_rule *rr;
const struct ieee80211_freq_range *fr = NULL;
+ u32 max_bw = MHZ_TO_KHZ(20);
rr = regd-reg_rules[i];
fr = rr-freq_range;
@@ -1028,8 +1028,10 @@ freq_reg_info_regd(struct wiphy *wiphy, u32 center_freq,
*/
if (!band_rule_found)
band_rule_found = freq_in_rule_band(fr, center_freq);
+ if (fr-max_bandwidth_khz max_bw)
+ max_bw = fr-max_bandwidth_khz;
- bw_fits = reg_does_bw_fit(fr, center_freq, MHZ_TO_KHZ(20));
+ bw_fits = reg_does_bw_fit(fr, center_freq, max_bw);
if (band_rule_found bw_fits)
return rr;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] staging: wilc1000: Align enum members in coreconfigurator
On Mon, Jun 08, 2015 at 11:54:29PM +0300, Stanislav Kholmanskikh wrote: Aligned enum members to follow a common style per enum. You also reformatted defines, which you didn't mention here :( -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Debugfs entry to enable/disable BTC feature
On Mon, Jun 8, 2015 at 6:44 AM, Kalle Valo kv...@qca.qualcomm.com wrote:
Li, Yanbo yan...@qca.qualcomm.com writes:
-Original Message-
From: Valo, Kalle
Sent: Wednesday, May 27, 2015 5:57 AM
To: Li, Yanbo
Cc: dreamfly...@gmail.com; linux-wireless@vger.kernel.org;
michal.kaz...@tieto.com; ath...@lists.infradead.org
Subject: Re: [PATCH] ath10k: Debugfs entry to enable/disable BTC feature
Yanbo Li yan...@qca.qualcomm.com writes:
As some radio have no connection with BT modules, enable the BTC
feature will has some side effect if the radio's GPIO connect with any
other HW modules. Add the control switcher btc_feature at debugfs
and set the feature as disable by default to avoid such case.
To enable this feature, execute:
echo 1 /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
To disable:
echo 0 /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
I suspect BTC does not really tell much for most of the people and
acronyms should be always spelled out at least once.
Signed-off-by: Yanbo Li yan...@qca.qualcomm.com
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 8444adf42195..6852e7fc5d5f 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -720,6 +720,8 @@ struct ath10k {
u32 fw_cold_reset_counter;
} stats;
+ bool btc_feature;
Could we use ar-dev_flags instead?
This dev_flags currently used to mark some status, like the cradh, CAC
running,
The BTcoex feature is more likely a HW feature, there are seems different
set.
Maybe a separately hw_feature_flag is needed as there are some other HW
feature
That we want to enable/disable from user space.
I think we don't need a separate bitmap, we can use dev_flags just fine
for this.
+static ssize_t ath10k_write_btc_feature(struct file *file,
+ const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file-private_data;
+ char buf[32];
+ size_t buf_size;
+ bool val;
+
+ buf_size = min(count, (sizeof(buf) - 1));
+ if (copy_from_user(buf, ubuf, buf_size))
+ return -EFAULT;
+
+ buf[buf_size] = '\0';
+ if (strtobool(buf, val) != 0) {
+ ath10k_warn(ar, Wrong BTC feature setting\n);
+ return -EINVAL;
+ }
+
+ mutex_lock(ar-conf_mutex);
+ ar-btc_feature = val;
+ queue_work(ar-workqueue, ar-restart_work);
+ mutex_unlock(ar-conf_mutex);
Shouldn't we test ATH10K_STATE_ON first?
The restart process will judge by itself whether the device is on or not,
and print below warning in that case:
[797424.496190] ath10k_pci :05:00.0: cannot restart a device that
hasn't been started
That's just buggy, ath10k should not print anything if a setting is
changed while interface is down. It's much better we have the check for
ATH10K_STATE_ON here.
Agree, will send v3 include these changes.
BR /Yanbo
--
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: handle aggregation session timeout on fast-xmit path
From: Johannes Berg johannes.b...@intel.com
The conversion to the fast-xmit path lost proper aggregation session
timeout handling - the last_tx wasn't set on that path and the timer
would therefore incorrectly tear down the session periodically (with
those drivers/rate control algorithms that have a timeout.)
In case of iwlwifi, this was every 5 seconds and caused significant
throughput degradation.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/tx.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 82e1e8484593..8410bb3bf5e8 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2719,9 +2719,12 @@ static bool ieee80211_xmit_fast(struct
ieee80211_sub_if_data *sdata,
if (hdr-frame_control cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
tid = skb-priority IEEE80211_QOS_CTL_TAG1D_MASK;
tid_tx = rcu_dereference(sta-ampdu_mlme.tid_tx[tid]);
- if (tid_tx
- !test_bit(HT_AGG_STATE_OPERATIONAL, tid_tx-state))
- return false;
+ if (tid_tx) {
+ if (!test_bit(HT_AGG_STATE_OPERATIONAL, tid_tx-state))
+ return false;
+ if (tid_tx-timeout)
+ tid_tx-last_tx = jiffies;
+ }
}
/* after this point (skb is modified) we cannot return false */
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] staging: wilc1000: Cleanup to coreconfigurator
On Mon, Jun 08, 2015 at 11:54:28PM +0300, Stanislav Kholmanskikh wrote: Fixed the following issues found with checkpatch.pl: * Multiple debug strings contained \n. Changed it to \n. * Changed 'return(X)' to 'return X'. * Aligned TAG_PARAM_OFFSET to fit 80 columns That is 3 different things, please make this 3 different patches. Remember, each patch can only do one thing. thanks, greg k-h -- 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] mac80211: minstrel_ht: Handle Dynamic SMPS state of the peer.
On Wed, 2015-06-03 at 23:52 +0530, Chaitanya T K wrote:
In case of Dynamic SMPS enable RTS/CTS for all rates.
+ /* Enable RTS/CTS for below cases.
+ * 1) Handle STA's SMPS State, if Nss 1.
+ *a. Use RTS_CTS, if STA is in Dynamic SMPS Mode
+ *b. Mark Nss 1 as unsupported, if STA is in static SMPS mode
+ * 2) 2nd and 3rd Rates, as 1st Rate Failed.
+ */
+ if ((mi-sta-smps_mode == IEEE80211_SMPS_DYNAMIC
+ group-streams 1) ||
+ offset 0) {
Indent still isn't right - the line starting with offset should be
indented one less. Might also be worthwhile to just reorder the
condition to first check for offset 0?
I was about to do that and apply this, but it seems the comment doesn't
make sense since you're not doing 1b. afaict?
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: Always check rates and capabilities in mesh mode
Will resend using a better mail client. Just found out that web-gmail is no-go. On Tue, Jun 9, 2015 at 12:44 PM, Johannes Berg johan...@sipsolutions.net wrote: On Fri, 2015-05-29 at 15:24 -0700, Alexis Green wrote: In mesh mode there is a race between establishing links and processing rates and capabilities in beacons. This is very noticeable with slow beacons (e.g. beacon intervals of 1s) and manifested for us as stations using minstrel when minstrel_ht should be used. Fixed by changing mesh_sta_info_init so that it always checks rates and such if it has not already done so. Signed-off-by: Alexis Green agr...@cococorp.com CC: Jesse Jones jjo...@cococorp.com This patch doesn't apply, it's line-broken and whitespace damaged. 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] mac80211: Fix double locking on CSA counter update
On Mon, 2015-06-01 at 16:51 +0200, Wojciech Dubowik wrote: We call rcu locked ieee80211_csa_update_counter from already locked section. Fix it by splitting ieee80211_csa_update_counter into locked and unlocked variants and use the latter in rcu locked section. The subject of this patch implies there's a bug (double locking, which I'd interpret as nested locking) and that there's something to fix. At best, this is an optimisation, can you please label it as such? 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: ignore invalid scan RSSI values
On Wed, 2015-06-03 at 10:44 +0300, Emmanuel Grumbach wrote: From: Sara Sharon sara.sha...@intel.com Channels in 2.4GHz band overlap, this means that if we send a probe request on channel 1 and then move to channel 2, we will hear the probe response on channel 2. In this case, the RSSI will be lower than if we had heard it on the channel on which it was sent (1 in this case). The scan result ignores those invalid values and the station last signal should not be updated as well. Applied. 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]: mac80211: Always check rates and capabilities in mesh mode
On Tue, 2015-06-09 at 13:00 -0700, Alexis Green wrote: In mesh mode there is a race between establishing links and processing rates and capabilities in beacons. This is very noticeable with slow beacons (e.g. beacon intervals of 1s) and manifested for us as stations using minstrel when minstrel_ht should be used. Fixed by changing mesh_sta_info_init so that it always checks rates and such if it has not already done so. Applied. 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] mac80211: Fix power save state stuck in ACTIVE caused by race between suspend and Tx packet.
On Wed, Jun 10, 2015 at 1:40 AM, Johannes Berg johan...@sipsolutions.net wrote: On Tue, 2015-06-02 at 03:02 +0530, Krishna Chaitanya wrote: This isn't what your patch is actually doing though. You need to mention WoWLAN at the very least in your commit log; Yes, WoWLAN is enabled in our testing. Without wowlan the connection will not be intact. So i assumed the check is_associated would imply wowlan. I meant the commit log. If I read your commit log without the patch, it doesn't make sense at all since regular suspend/resume will turn off the device anyway. You really need to mention a) the fact that wowlan is used, and b) the fact that you care about powersave state *while in wowlan* Hmm...ok, i will rephrase the commit log and re-submit V3, Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: release channel on auth failure
On Wed, 2015-06-03 at 08:36 +0200, Michal Kazior wrote: There were a few rare cases when upon authentication failure channel wasn't released. This could cause stale pointers to remain in chanctx assigned_vifs after interface removal and trigger general protection fault later. Applied. I've put this on -next, but perhaps it's needed for stable too? Maybe we can send it there next week or so ... 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: fix the beacon csa counter for mesh and ibss
On Tue, 2015-06-09 at 13:35 +0800, Chun-Yeow Yeoh wrote: The csa counter has moved from sdata to beacon/presp but it is not updated accordingly for mesh and ibss. Fix this. This regression is introduced by the following patch: mac80211: move csa counters from sdata to beacon/presp Applied. 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: Fix incorrectly named last_hop_metric variable in mesh_rx_path_sel_frame
On Fri, 2015-06-05 at 12:43 -0700, Alexis Green wrote: The last hop metric should refer to link cost (this is how hwmp_route_info_get uses it for example). But in mesh_rx_path_sel_frame we are not dealing with link cost but with the total cost to the origin of a PREQ or PREP. Signed-off-by: Alexis Green agr...@cococorp.com CC: Jesse Jones jjo...@cococorp.com Applied. This one worked, but the other ones you sent didn't. 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: Always check rates and capabilities in mesh mode
On Fri, 2015-05-29 at 15:24 -0700, Alexis Green wrote: In mesh mode there is a race between establishing links and processing rates and capabilities in beacons. This is very noticeable with slow beacons (e.g. beacon intervals of 1s) and manifested for us as stations using minstrel when minstrel_ht should be used. Fixed by changing mesh_sta_info_init so that it always checks rates and such if it has not already done so. Signed-off-by: Alexis Green agr...@cococorp.com CC: Jesse Jones jjo...@cococorp.com This patch doesn't apply, it's line-broken and whitespace damaged. 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 4.1] cfg80211: wext: clear sinfo struct before calling driver
From: Johannes Berg johan...@sipsolutions.net Date: Tue, 9 Jun 2015 21:35:44 +0200 From: Johannes Berg johannes.b...@intel.com Until recently, mac80211 overwrote all the statistics it could provide when getting called, but it now relies on the struct having been zeroed by the caller. This was always the case in nl80211, but wext used a static struct which could even cause values from one device leak to another. Using a static struct is OK (as even documented in a comment) since the whole usage of this function and its return value is always locked under RTNL. Not clearing the struct for calling the driver has always been wrong though, since drivers were free to only fill values they could report, so calling this for one device and then for another would always have leaked values from one to the other. Fix this by initializing the structure in question before the driver method call. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691 Cc: sta...@vger.kernel.org Reported-by: Gerrit Renker ger...@erg.abdn.ac.uk Reported-by: Alexander Kaltsas alexkalt...@gmail.com Signed-off-by: Johannes Berg johannes.b...@intel.com --- Dave, would you mind applying this patch directly? It seems a bit pointless to send a pull request for a single patch again. Sure, I'll do that right now. Thanks Johannes. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cfg80211: wext: clear sinfo struct before calling driver
From: Johannes Berg johannes.b...@intel.com Until recently, mac80211 overwrote all the statistics it could provide when getting called, but it now relies on the struct having been zeroed by the caller. This was always the case in nl80211, but wext used a static struct which could even cause values from one device leak to another. Using a static struct is OK (as even documented in a comment) since the whole usage of this function and its return value is always locked under RTNL. Not clearing the struct for calling the driver has always been wrong though, since drivers were free to only fill values they could report, so calling this for one device and then for another would always have leaked values from one to the other. Fix this by initializing the structure in question before the driver method call. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691 Cc: sta...@vger.kernel.org Reported-by: Gerrit Renker ger...@erg.abdn.ac.uk Reported-by: Alexander Kaltsas alexkalt...@gmail.com Signed-off-by: Johannes Berg johannes.b...@intel.com --- net/wireless/wext-compat.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c index fff1bef6ed6d..fd682832a0e3 100644 --- a/net/wireless/wext-compat.c +++ b/net/wireless/wext-compat.c @@ -1333,6 +1333,8 @@ static struct iw_statistics *cfg80211_wireless_stats(struct net_device *dev) memcpy(bssid, wdev-current_bss-pub.bssid, ETH_ALEN); wdev_unlock(wdev); + memset(sinfo, 0, sizeof(sinfo)); + if (rdev_get_station(rdev, dev, bssid, sinfo)) return NULL; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4.1] cfg80211: wext: clear sinfo struct before calling driver
From: Johannes Berg johannes.b...@intel.com Until recently, mac80211 overwrote all the statistics it could provide when getting called, but it now relies on the struct having been zeroed by the caller. This was always the case in nl80211, but wext used a static struct which could even cause values from one device leak to another. Using a static struct is OK (as even documented in a comment) since the whole usage of this function and its return value is always locked under RTNL. Not clearing the struct for calling the driver has always been wrong though, since drivers were free to only fill values they could report, so calling this for one device and then for another would always have leaked values from one to the other. Fix this by initializing the structure in question before the driver method call. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691 Cc: sta...@vger.kernel.org Reported-by: Gerrit Renker ger...@erg.abdn.ac.uk Reported-by: Alexander Kaltsas alexkalt...@gmail.com Signed-off-by: Johannes Berg johannes.b...@intel.com --- Dave, would you mind applying this patch directly? It seems a bit pointless to send a pull request for a single patch again. --- net/wireless/wext-compat.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c index fff1bef6ed6d..fd682832a0e3 100644 --- a/net/wireless/wext-compat.c +++ b/net/wireless/wext-compat.c @@ -1333,6 +1333,8 @@ static struct iw_statistics *cfg80211_wireless_stats(struct net_device *dev) memcpy(bssid, wdev-current_bss-pub.bssid, ETH_ALEN); wdev_unlock(wdev); + memset(sinfo, 0, sizeof(sinfo)); + if (rdev_get_station(rdev, dev, bssid, sinfo)) return NULL; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: remove obsolete sentence from documentation
On Tue, 2015-06-02 at 21:10 +0200, Jakub Kicinski wrote: From: Jakub Kicinski kubak...@wp.pl FIF_PROMISC_IN_BSS was removed in commit df1404650ccb (mac80211: remove support for IFF_PROMISC). Applied, thanks. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2]: mac80211: Always check rates and capabilities in mesh mode
In mesh mode there is a race between establishing links and processing
rates and capabilities in beacons. This is very noticeable with slow
beacons (e.g. beacon intervals of 1s) and manifested for us as stations
using minstrel when minstrel_ht should be used. Fixed by changing
mesh_sta_info_init so that it always checks rates and such if it has not
already done so.
Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com
---
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index ac843fc..54656af 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -394,8 +394,9 @@ static void mesh_sta_info_init(struct ieee80211_sub_if_data
*sdata,
sta-last_rx = jiffies;
/* rates and capabilities don't change during peering */
- if (sta-plink_state == NL80211_PLINK_ESTAB)
+ if (sta-plink_state == NL80211_PLINK_ESTAB sta-processed_beacon)
goto out;
+ sta-processed_beacon = true;
if (sta-sta.supp_rates[band] != rates)
changed |= IEEE80211_RC_SUPP_RATES_CHANGED;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 9bd1e97..226f8ca4 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -369,6 +369,8 @@ struct ieee80211_fast_tx {
* @rx_msdu: MSDUs received from this station, using IEEE80211_NUM_TID
* entry for non-QoS frames
* @fast_tx: TX fastpath information
+ * @processed_beacon: set to true after peer rates and capabilities are
+ * processed
*/
struct sta_info {
/* General information, mostly static */
@@ -473,6 +475,7 @@ struct sta_info {
enum nl80211_mesh_power_mode local_pm;
enum nl80211_mesh_power_mode peer_pm;
enum nl80211_mesh_power_mode nonpeer_pm;
+ bool processed_beacon;
#endif
#ifdef CONFIG_MAC80211_DEBUGFS
--
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] mac80211: Fix power save state stuck in ACTIVE caused by race between suspend and Tx packet.
On Tue, 2015-06-02 at 03:02 +0530, Krishna Chaitanya wrote: This isn't what your patch is actually doing though. You need to mention WoWLAN at the very least in your commit log; Yes, WoWLAN is enabled in our testing. Without wowlan the connection will not be intact. So i assumed the check is_associated would imply wowlan. I meant the commit log. If I read your commit log without the patch, it doesn't make sense at all since regular suspend/resume will turn off the device anyway. You really need to mention a) the fact that wowlan is used, and b) the fact that you care about powersave state *while in wowlan* johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ath10k: Debugfs entry to enable/disable WLANBlutooth Coexist feature
As some radio have no connection with BT modules, enable the WLAN/Bluetooth
coexist(BTC) feature will has some side effect if the radio's GPIO connect
with any other HW modules. Add the control switcher btc_feature at
debugfs and set the feature as disable by default to avoid such case.
The FW support this feature since 10.2.4.54 on 2G-only board, dual band
or 5G boards don't support the feature
To enable this feature, execute:
echo 1 /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
To disable:
echo 0 /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
Signed-off-by: Yanbo Li yan...@qca.qualcomm.com
---
Notes:
V3:
* using dev_flags
* check state on before restart
* Add the FW version and limitation support this feature
drivers/net/wireless/ath/ath10k/core.h | 2 +
drivers/net/wireless/ath/ath10k/debug.c | 65 +
drivers/net/wireless/ath/ath10k/wmi.c | 3 +-
3 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 87376b3283f5..7fc2034ce53d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -481,6 +481,8 @@ enum ath10k_dev_flags {
* waiters should immediately cancel instead of waiting for a time out.
*/
ATH10K_FLAG_CRASH_FLUSH,
+ /* Flag for enable the BT/WLAN coexist */
+ ATH10K_FLAG_BTCOEX_ENABLE
};
enum ath10k_cal_mode {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 8fa606a9c4dd..a5da7c96d81a 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2092,6 +2092,69 @@ static const struct file_operations fops_quiet_period = {
.open = simple_open
};
+static ssize_t ath10k_write_btc_feature(struct file *file,
+ const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file-private_data;
+ char buf[32];
+ size_t buf_size;
+ bool val;
+ int ret;
+
+ buf_size = min(count, (sizeof(buf) - 1));
+ if (copy_from_user(buf, ubuf, buf_size))
+ return -EFAULT;
+
+ buf[buf_size] = '\0';
+ if (strtobool(buf, val) != 0) {
+ ath10k_warn(ar, Wrong BTcoex feature setting\n);
+ return -EINVAL;
+ }
+
+ mutex_lock(ar-conf_mutex);
+
+ if (ar-state != ATH10K_STATE_ON) {
+ ret = -ENETDOWN;
+ goto err_unlock;
+ }
+
+ if (val != test_bit(ATH10K_FLAG_BTCOEX_ENABLE, ar-dev_flags)) {
+ if (val)
+ set_bit(ATH10K_FLAG_BTCOEX_ENABLE, ar-dev_flags);
+ else
+ clear_bit(ATH10K_FLAG_BTCOEX_ENABLE, ar-dev_flags);
+ queue_work(ar-workqueue, ar-restart_work);
+ }
+
+ ret = count;
+
+err_unlock:
+ mutex_unlock(ar-conf_mutex);
+ return ret;
+}
+
+static ssize_t ath10k_read_btc_feature(struct file *file, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ char buf[32];
+ struct ath10k *ar = file-private_data;
+ int len = 0;
+
+ mutex_lock(ar-conf_mutex);
+ len = scnprintf(buf, sizeof(buf) - len, %d\n,
+ test_bit(ATH10K_FLAG_BTCOEX_ENABLE, ar-dev_flags));
+ mutex_unlock(ar-conf_mutex);
+
+ return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_btc_feature = {
+ .read = ath10k_read_btc_feature,
+ .write = ath10k_write_btc_feature,
+ .open = simple_open
+};
+
int ath10k_debug_create(struct ath10k *ar)
{
ar-debug.fw_crash_data = vzalloc(sizeof(*ar-debug.fw_crash_data));
@@ -2195,6 +2258,8 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file(quiet_period, S_IRUGO | S_IWUSR,
ar-debug.debugfs_phy, ar, fops_quiet_period);
+ debugfs_create_file(btc_feature, S_IRUGO | S_IWUSR,
+ ar-debug.debugfs_phy, ar, fops_btc_feature);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 77220b0f0e89..98e0b087d080 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3936,7 +3936,8 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
cmd = (struct wmi_init_cmd_10_2 *)buf-data;
features = WMI_10_2_RX_BATCH_MODE;
- if (test_bit(WMI_SERVICE_COEX_GPIO, ar-wmi.svc_map))
+ if (test_bit(ATH10K_FLAG_BTCOEX_ENABLE, ar-dev_flags)
+ test_bit(WMI_SERVICE_COEX_GPIO, ar-wmi.svc_map))
features |= WMI_10_2_COEX_GPIO;
cmd-resource_config.feature_mask = __cpu_to_le32(features);
--
1.9.1
--
To unsubscribe from this list: send the
Re: [PATCH] mac80211: Fix a case of incorrect metric used when forwarding a PREQ
Resubmitting as v2 due to mangled white spaces. On Mon, Jun 8, 2015 at 10:28 AM, Jesse Jones jjo...@cococorp.com wrote: I took a look at the spec too and also didn't see mention of the MP_F_RF flag. Section 13.10.9.3 for example talks about PREQ handling and in case E2 talks about sending replies back. It says to do that if target only is not set which makes sense: MP_F_RF and MP_F_DO are exclusive options so it's silly to use two different flags for them. But for the purposes of this patch that is a moot issue: the semantics of the function don't change and the original code was both confusing and using the wrong value for metric for the not target only, intermediate station case. -- Jesse -Original Message- From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Yeoh Chun-Yeow Sent: Monday, June 08, 2015 1:55 AM To: linux-wireless@vger.kernel.org Subject: Re: [PATCH] mac80211: Fix a case of incorrect metric used when forwarding a PREQ As mentioned in Section 13.10.9.3 Case E2, the PREQ forwarding should use metric as received + own metric toward transmitter of received PREQ. So you are right. Just MP_F_RF bit is no longer use. After replying with PREP, forwarding the PREQ by setting the IEEE80211_PREQ_TO_FLAG in the per target flags. --- Chun-Yeow On Mon, Jun 8, 2015 at 4:07 PM, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote: Hi, Alexis Green I just take a look back on the code before implementing the Proactive PREQ for PREP. For the case of reply and forward (target_flags MP_F_RF), the previous metric used is the one which resolved from mpath-metric. Refer here: https://github.com/o11s/open80211s/blob/o11s-0.4.2/net/mac80211/mesh_h wmp.c But to say that, I cannpt confirm whether this is correct. The standard 802.11-2012 has no longer specified bit-1 MP_F_RF (Refer section 8.4.2.115 per target flag). So maybe it is not relevant anymore. We may need to remove as well. Chun-Yeow -- 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 -- 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] mac80211: Fix a case of incorrect metric used when forwarding a PREQ
This patch fixes a bug in hwmp_preq_frame_process where the wrong metric
can be used when forwarding a PREQ. This happens because the code uses
the same metric variable to record the value of the metric to the source
of the PREQ and the value of the metric to the target of the PREQ.
This comes into play when both reply and forward are set which happens
when IEEE80211_PREQ_PROACTIVE_PREP_FLAG is set and when MP_F_DO | MP_F_RF
is set. The original code had a special case to handle the first case
but not the second.
The patch uses distinct variables for the two metrics which makes the
code flow much clearer and removes the need to restore the original
value of metric when forwarding.
Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com
---
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 214e63b..84d1044 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -510,14 +510,14 @@ static u32 hwmp_route_info_get(struct
ieee80211_sub_if_data *sdata,
static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt,
- const u8 *preq_elem, u32 metric)
+ const u8 *preq_elem, u32 orig_metric)
{
struct ieee80211_if_mesh *ifmsh = sdata-u.mesh;
struct mesh_path *mpath = NULL;
const u8 *target_addr, *orig_addr;
const u8 *da;
u8 target_flags, ttl, flags;
- u32 orig_sn, target_sn, lifetime, orig_metric;
+ u32 orig_sn, target_sn, lifetime, target_metric;
bool reply = false;
bool forward = true;
bool root_is_gate;
@@ -528,7 +528,6 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
target_sn = PREQ_IE_TARGET_SN(preq_elem);
orig_sn = PREQ_IE_ORIG_SN(preq_elem);
target_flags = PREQ_IE_TARGET_F(preq_elem);
- orig_metric = metric;
/* Proactive PREQ gate announcements */
flags = PREQ_IE_FLAGS(preq_elem);
root_is_gate = !!(flags RANN_FLAG_IS_GATE);
@@ -539,7 +538,7 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
mhwmp_dbg(sdata, PREQ is for us\n);
forward = false;
reply = true;
- metric = 0;
+ target_metric = 0;
if (time_after(jiffies, ifmsh-last_sn_update +
net_traversal_jiffies(sdata)) ||
time_before(jiffies, ifmsh-last_sn_update)) {
@@ -556,7 +555,7 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
reply = true;
target_addr = sdata-vif.addr;
target_sn = ++ifmsh-sn;
- metric = 0;
+ target_metric = 0;
ifmsh-last_sn_update = jiffies;
}
if (root_is_gate)
@@ -574,7 +573,7 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
} else if ((!(target_flags MP_F_DO))
(mpath-flags MESH_PATH_ACTIVE)) {
reply = true;
- metric = mpath-metric;
+ target_metric = mpath-metric;
target_sn = mpath-sn;
if (target_flags MP_F_RF)
target_flags |= MP_F_DO;
@@ -593,7 +592,8 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
mesh_path_sel_frame_tx(MPATH_PREP, 0, orig_addr,
orig_sn, 0, target_addr,
target_sn, mgmt-sa, 0, ttl,
- lifetime, metric, 0, sdata);
+ lifetime, target_metric, 0,
+ sdata);
} else {
ifmsh-mshstats.dropped_frames_ttl++;
}
@@ -619,13 +619,12 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
if (flags IEEE80211_PREQ_PROACTIVE_PREP_FLAG) {
target_addr = PREQ_IE_TARGET_ADDR(preq_elem);
target_sn = PREQ_IE_TARGET_SN(preq_elem);
- metric = orig_metric;
}
mesh_path_sel_frame_tx(MPATH_PREQ, flags, orig_addr,
orig_sn, target_flags, target_addr,
target_sn, da, hopcount, ttl, lifetime,
- metric, preq_id, sdata);
+ orig_metric, preq_id,
Re: [PATCH] treewide: Fix typo compatability - compatibility
Em Wed, 27 May 2015 15:05:42 +0300
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Even though 'compatability' has a dedicated entry in the Wiktionary,
it's listed as 'Mispelling of compatibility'. Fix it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
---
arch/metag/include/asm/elf.h | 2 +-
arch/powerpc/kvm/book3s.c| 2 +-
arch/sparc/include/uapi/asm/pstate.h | 2 +-
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/media/dvb-frontends/au8522_dig.c | 2 +-
drivers/net/wireless/ipw2x00/ipw2100.h | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
I can split this into one patch per subsystem, but that seems a bit overkill.
Can someone take it ?
Who? That's the problem with treewide patches ;)
Perhaps you should re-submit it with the acks you got to akpm.
Regards,
Mauro
diff --git a/arch/metag/include/asm/elf.h b/arch/metag/include/asm/elf.h
index d2baf6961794..87b0cf1e0acb 100644
--- a/arch/metag/include/asm/elf.h
+++ b/arch/metag/include/asm/elf.h
@@ -11,7 +11,7 @@
#define R_METAG_RELBRANCH4
#define R_METAG_GETSETOFF5
-/* Backward compatability */
+/* Backward compatibility */
#define R_METAG_REG32OP1 6
#define R_METAG_REG32OP2 7
#define R_METAG_REG32OP3 8
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 453a8a47a467..cb14dd78a2e7 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -901,7 +901,7 @@ int kvmppc_core_check_processor_compat(void)
{
/*
* We always return 0 for book3s. We check
- * for compatability while loading the HV
+ * for compatibility while loading the HV
* or PR module
*/
return 0;
diff --git a/arch/sparc/include/uapi/asm/pstate.h
b/arch/sparc/include/uapi/asm/pstate.h
index 4b6b998afd99..cf832e14aa05 100644
--- a/arch/sparc/include/uapi/asm/pstate.h
+++ b/arch/sparc/include/uapi/asm/pstate.h
@@ -88,7 +88,7 @@
#define VERS_MAXTL _AC(0xff00,UL) /* Max Trap Level. */
#define VERS_MAXWIN _AC(0x001f,UL) /* Max RegWindow Idx.*/
-/* Compatability Feature Register (%asr26), SPARC-T4 and later */
+/* Compatibility Feature Register (%asr26), SPARC-T4 and later */
#define CFR_AES _AC(0x0001,UL) /* Supports AES
opcodes */
#define CFR_DES _AC(0x0002,UL) /* Supports DES
opcodes */
#define CFR_KASUMI _AC(0x0004,UL) /* Supports KASUMI opcodes
*/
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index b82ef6262469..12c5b79b0e8f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -751,7 +751,7 @@ crtc_set_mode(struct drm_device *dev, struct
drm_atomic_state *old_state)
* This function shuts down all the outputs that need to be shut down and
* prepares them (if required) with the new mode.
*
- * For compatability with legacy crtc helpers this should be called before
+ * For compatibility with legacy crtc helpers this should be called before
* drm_atomic_helper_commit_planes(), which is what the default commit
function
* does. But drivers with different needs can group the modeset commits
together
* and do the plane commits at the end. This is useful for drivers doing
runtime
@@ -776,7 +776,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_disables);
* This function enables all the outputs with the new configuration which
had to
* be turned off for the update.
*
- * For compatability with legacy crtc helpers this should be called after
+ * For compatibility with legacy crtc helpers this should be called after
* drm_atomic_helper_commit_planes(), which is what the default commit
function
* does. But drivers with different needs can group the modeset commits
together
* and do the plane commits at the end. This is useful for drivers doing
runtime
diff --git a/drivers/media/dvb-frontends/au8522_dig.c
b/drivers/media/dvb-frontends/au8522_dig.c
index 5d06c99b0e97..edadcc7eea6c 100644
--- a/drivers/media/dvb-frontends/au8522_dig.c
+++ b/drivers/media/dvb-frontends/au8522_dig.c
@@ -922,7 +922,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Enable verbose debug messages);
module_param(zv_mode, int, 0644);
-MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatability mode
(default:on).\n
+MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatibility mode
(default:on).\n
\t\ton - modified AU8522 QAM256 initialization.\n
\t\tProvides faster lock when using ZeeVee modulator based sources);
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.h
b/drivers/net/wireless/ipw2x00/ipw2100.h
index c6d78790cb0d..193947865efd
Re: [PATCH v3] ath10k: add 'cryptmode' param to support raw tx injection and software crypto
On 9 June 2015 at 03:13, Liu CF/TW cfliu...@gmail.com wrote: This change supports hardware crypto engine bypass by enabling raw Rx/Tx encap mode. This enables use cases such as software crypto and raw tx injection. This change introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. 2: Supports both hardware and software crypto with raw mode TX/RX encapsulation to the firmware. By default hardware crypto engine is used. To use software crypto in this mode, set the per ath10k_vif 'nohwcrypt' flag value to True.* *) The patch for setting vif specific 'nohwcrypt' flag when cryptmode=2 would be a separate patch to mac80211. Possible use case examples: - Use software crypto engine in mac80211. (cryptmode=1) - Support inject raw unencrypted frame on monitor interface and use hardware crypto to encrypt the injected Tx frames. (cryptmode=2) - Support receive raw hardware decrypted frame with encryption header on monitor interface. (cryptmode=2) - Support hybrid local split MAC mode to support tunneling protocols such as CAPWAP: Use hardware crypto for BSS in local mode, and bypass hardware crypto for BSS in split MAC mode. (cryptmode=2, ath10k_vif nohwcrypt=0 for local mode, =1 for split MAC mode) Testing: Used QCA988x hw 2.0 with firmware-4.bin_10.2.4.48 with backports-20150424. All test case tested** with hostapd in both WPA2-PSK-TKIP (11g) and WPA2-PSK-CCMP(11n/ac). Verified ping and http to google.com works. **) Need to skip ATH10K_FW_FEATURE_RAW_MODE_SUPPORT check in core.c to test firmware. After all, none of the existing QCA official firmware exports that firmware bit yet. Test Casecryptmode value tested --- 1. ath10k hardware crypto can encrypt/decrypt 0: PASS data frames when hostapd config the BSS in 1: Not applicable. WPA2-PSK-TKIP and WPA2-PSK-CCMP modes. 2: PASS 2. mac80211 software crypto can encrypt/decrypt 0: Not applicable data frames when hostapd config the BSS in 1: PASS WPA2-PSK-TKIP and WPA2-PSK-CCMP modes. 2: PASS, when vif nohwcrypt=1 3. Monitor interface Tx: User application can 0: Not applicable inject unencrypted raw Tx frames to monitor 1: PASS (mac80211) interface for mac80211 or hardware to encrypt2: PASS (hardware) the frames. 4. Monitor interface Rx: mac80211 software crypto 0: Not applicable engine can decrypt received TKIP/CCMP frames.1: PASS User application see decrypted frames. 2: PASS, when vif nohwcrypt=1 5. CAPWAP-like local and split MAC datapath 0: Not applicable tunneling: Setup BSS1=Local MAC mode on wlan0, 1: Not applicable BSS2=Split MAC mode on wlan0_monitor interface. 2: PASS Test BSS1 data frames can be encrypted and decrypted by ath10k hardware crypto engine while BSS2 data frames can skip both hardware kernel mac80211 crypto engines via monitor interface to the user application fot tunneling. I've finally got to run a few tests on your patch. I've tried qca988x with 10.2.4.48-2 (fw_feature hardcoded in driver). Here's a short summary of my findings: - cryptmode=1 can fix 4addr+802.1q VLAN tagging in both AP and STA modes (a problem recently reported by Cedric), - your patch as-is has AP WEP broken, see below - your patch as-is has TCP broken, see below - your patch as-is has performance really broken, see below - once patched it looks pretty solid. At the end of this email I'm attaching (most likely whitespace damaged) patch I've made on top of your patch for reviewing convenience. For testing/merging convenience here's a paste link: http://paste.ee/p/YMFrO Performance: cryptmode=1 ap=qca988x sta=killer1525 killer1525 - qca988x 194.496 mbps [tcp1 ip4] killer1525 - qca988x 238.309 mbps [tcp5 ip4] killer1525 - qca988x 266.958 mbps [udp1 ip4] killer1525 - qca988x 477.468 mbps [udp5 ip4] qca988x - killer1525 301.378 mbps [tcp1 ip4] qca988x - killer1525 297.949 mbps [tcp5 ip4] qca988x - killer1525 331.351 mbps [udp1 ip4] qca988x - killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x - killer1525 331.447 mbps [tcp1 ip4] qca988x - killer1525 328.783 mbps [tcp5 ip4] qca988x - killer1525 375.309 mbps [udp1 ip4] qca988x - killer1525 403.379 mbps [udp5 ip4] killer1525 - qca988x
Re: [WEXT]: multiple calls for SIOCGIWSTATS return same value
On Tue, 09 Jun 2015 09:33:08 +0200 Johannes Berg johan...@sipsolutions.net wrote: There is a similar behaviour for scan results: the signal levels reported for stations remain the same for all subsequent calls. Previously these also changed with time and position of receiver. You mean BSSes, not stations, right? This is very strange - it seems those should be two entirely different code paths in the kernel. What driver are you using? But then again, you said nl80211/iw works, right? Then the driver shouldn't matter. Do you think you'd be able to use tracing? Many thanks for providing the patch. I just tried it and it fixed both problems (access point signal level/quality and signal level reported for BSSes in scan result). Not sure if trace results are still needed, but I can do that if needed. Will also work on porting wavemon to nl80211 now. Thanks again, Gerrit -- 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] ath10k: enable VHT for IBSS
Enable VHT support for IBSS, while mac80211/cfg80211 and wpa_supplicant already support this. In my test env, ath10k 2x2 I get: (udp) ath10k-1 ath10k-2 (server) - speed: 419 Mbits/sec (tcp) ath10k-1 ath10k-2 (server) - speed: 404 Mbits/sec During tests I used wpa_supplicant (current version), which already support IBSS VHT, and choose highest available BW. Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com --- drivers/net/wireless/ath/ath10k/mac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index f4de717..14a8f25 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -6949,6 +6949,8 @@ int ath10k_mac_register(struct ath10k *ar) goto err_free; } + wiphy_ext_feature_set(ar-hw-wiphy, NL80211_EXT_FEATURE_VHT_IBSS); + /* * on LL hardware queues are managed entirely by the FW * so we only advertise to mac we can do the queues thing -- 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
[RFC] ath9k: allow to receive probe request when offchannel
This fix problem that p2p group negotiation didn't work
correctly when chanctx used, because we didn't receive
probe requests when offchannel and use_chanctx=1
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
@Felix, Sujith could you review? I am not sure I put this in correct place.
drivers/net/wireless/ath/ath9k/channel.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index 2066650..6301d44 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1157,6 +1157,7 @@ static bool ath_chanctx_defer_switch(struct ath_softc *sc)
static void ath_offchannel_channel_change(struct ath_softc *sc)
{
struct ath_common *common = ath9k_hw_common(sc-sc_ah);
+ u32 rfilt;
ath_dbg(common, CHAN_CTX, %s: offchannel state: %s\n,
__func__, offchannel_state_string(sc-offchannel.state));
@@ -1179,6 +1180,11 @@ static void ath_offchannel_channel_change(struct
ath_softc *sc)
ath_scan_complete(sc, false);
break;
case ATH_OFFCHANNEL_ROC_START:
+ /* Allow to receive probe requests */
+ rfilt = ath_calcrxfilter(sc);
+ rfilt |= ATH9K_RX_FILTER_PROBEREQ;
+ ath9k_hw_setrxfilter(sc-sc_ah, rfilt);
+
if (sc-cur_chan != sc-offchannel.chan)
break;
--
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] treewide: Fix typo compatability - compatibility
On Wed, Jun 10, 2015 at 7:27 AM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Em Wed, 27 May 2015 15:05:42 +0300 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Even though 'compatability' has a dedicated entry in the Wiktionary, it's listed as 'Mispelling of compatibility'. Fix it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com --- arch/metag/include/asm/elf.h | 2 +- arch/powerpc/kvm/book3s.c| 2 +- arch/sparc/include/uapi/asm/pstate.h | 2 +- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- drivers/media/dvb-frontends/au8522_dig.c | 2 +- drivers/net/wireless/ipw2x00/ipw2100.h | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) I can split this into one patch per subsystem, but that seems a bit overkill. Can someone take it ? Who? That's the problem with treewide patches ;) Perhaps you should re-submit it with the acks you got to akpm. Regards, Mauro Laurent, Please re-submit your patch to triv...@kernel.org with [trivial] in the title. Ex. [PATCH] [trivial] treewide: Fix typo compatability - compatibility Regards, Masanari -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ath9k: advertise p2p dev support when chanctx
Add p2p dev support when ath9k loaded with
use_chanctx=1. This will fix problem, when first
interface is an AP and next we would like to run
p2p_find. Before p2p scan failed.
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
@Felix, Sujith please review. I am not sure if didn't miss some
case for NL80211_IFTYPE_P2P_DEVICE (special handling required?).
drivers/net/wireless/ath/ath9k/init.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index f8d11ef..7da1a17 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -736,13 +736,14 @@ static const struct ieee80211_iface_limit
if_limits_multi[] = {
BIT(NL80211_IFTYPE_P2P_CLIENT) |
BIT(NL80211_IFTYPE_P2P_GO) },
{ .max = 1, .types = BIT(NL80211_IFTYPE_ADHOC) },
+ { .max = 1, .types = BIT(NL80211_IFTYPE_P2P_DEVICE) },
};
static const struct ieee80211_iface_combination if_comb_multi[] = {
{
.limits = if_limits_multi,
.n_limits = ARRAY_SIZE(if_limits_multi),
- .max_interfaces = 2,
+ .max_interfaces = 3,
.num_different_channels = 2,
.beacon_int_infra_match = true,
},
@@ -855,6 +856,9 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct
ieee80211_hw *hw)
BIT(NL80211_IFTYPE_MESH_POINT) |
BIT(NL80211_IFTYPE_WDS);
+ if (ath9k_is_chanctx_enabled())
+ hw-wiphy-interface_modes |=
BIT(NL80211_IFTYPE_P2P_DEVICE);
+
hw-wiphy-iface_combinations = if_comb;
hw-wiphy-n_iface_combinations = ARRAY_SIZE(if_comb);
}
--
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
