[PATCH v2] nl80211: Broadcast CMD_NEW_INTERFACE and CMD_DEL_INTERFACE
Let the other listeners being notified when a new or del interface
command has been issued, thus reducing later necessary request to be in
sync with current context.
Signed-off-by: Tomasz Bursztyka tomasz.burszt...@linux.intel.com
---
net/wireless/nl80211.c | 50 +-
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1a31736..032e371 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2341,12 +2341,16 @@ static int nl80211_send_chandef(struct sk_buff *msg,
static int nl80211_send_iface(struct sk_buff *msg, u32 portid, u32 seq, int
flags,
struct cfg80211_registered_device *rdev,
- struct wireless_dev *wdev)
+ struct wireless_dev *wdev, bool new)
{
struct net_device *dev = wdev-netdev;
+ u8 cmd = NL80211_CMD_NEW_INTERFACE;
void *hdr;
- hdr = nl80211hdr_put(msg, portid, seq, flags,
NL80211_CMD_NEW_INTERFACE);
+ if (!new)
+ cmd = NL80211_CMD_DEL_INTERFACE;
+
+ hdr = nl80211hdr_put(msg, portid, seq, flags, cmd);
if (!hdr)
return -1;
@@ -2364,7 +2368,7 @@ static int nl80211_send_iface(struct sk_buff *msg, u32
portid, u32 seq, int flag
(cfg80211_rdev_list_generation 2)))
goto nla_put_failure;
- if (rdev-ops-get_channel) {
+ if (new rdev-ops-get_channel) {
int ret;
struct cfg80211_chan_def chandef;
@@ -2375,7 +2379,7 @@ static int nl80211_send_iface(struct sk_buff *msg, u32
portid, u32 seq, int flag
}
}
- if (wdev-ssid_len) {
+ if (new wdev-ssid_len) {
if (nla_put(msg, NL80211_ATTR_SSID, wdev-ssid_len, wdev-ssid))
goto nla_put_failure;
}
@@ -2413,7 +2417,7 @@ static int nl80211_dump_interface(struct sk_buff *skb,
struct netlink_callback *
}
if (nl80211_send_iface(skb, NETLINK_CB(cb-skb).portid,
cb-nlh-nlmsg_seq, NLM_F_MULTI,
- rdev, wdev) 0) {
+ rdev, wdev, true) 0) {
goto out;
}
if_idx++;
@@ -2441,7 +2445,7 @@ static int nl80211_get_interface(struct sk_buff *skb,
struct genl_info *info)
return -ENOMEM;
if (nl80211_send_iface(msg, info-snd_portid, info-snd_seq, 0,
- rdev, wdev) 0) {
+ rdev, wdev, true) 0) {
nlmsg_free(msg);
return -ENOBUFS;
}
@@ -2587,7 +2591,7 @@ static int nl80211_new_interface(struct sk_buff *skb,
struct genl_info *info)
struct cfg80211_registered_device *rdev = info-user_ptr[0];
struct vif_params params;
struct wireless_dev *wdev;
- struct sk_buff *msg;
+ struct sk_buff *msg, *n_msg;
int err;
enum nl80211_iftype type = NL80211_IFTYPE_UNSPECIFIED;
u32 flags;
@@ -2682,11 +2686,24 @@ static int nl80211_new_interface(struct sk_buff *skb,
struct genl_info *info)
}
if (nl80211_send_iface(msg, info-snd_portid, info-snd_seq, 0,
- rdev, wdev) 0) {
+ rdev, wdev, true) 0) {
nlmsg_free(msg);
return -ENOBUFS;
}
+ n_msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (n_msg) {
+ if (nl80211_send_iface(n_msg, 0, 0, 0, rdev, wdev, true) 0) {
+ nlmsg_free(n_msg);
+ goto out;
+ }
+
+ genlmsg_multicast_netns(nl80211_fam, wiphy_net(rdev-wiphy),
+ n_msg, 0, NL80211_MCGRP_CONFIG,
+ GFP_KERNEL);
+ }
+
+out:
return genlmsg_reply(msg, info);
}
@@ -2694,10 +2711,18 @@ static int nl80211_del_interface(struct sk_buff *skb,
struct genl_info *info)
{
struct cfg80211_registered_device *rdev = info-user_ptr[0];
struct wireless_dev *wdev = info-user_ptr[1];
+ struct sk_buff *msg;
+ int status;
if (!rdev-ops-del_virtual_intf)
return -EOPNOTSUPP;
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (msg nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, false) 0) {
+ nlmsg_free(msg);
+ msg = NULL;
+ }
+
/*
* If we remove a wireless device without a netdev then clear
* user_ptr[1] so that nl80211_post_doit won't dereference it
@@ -2708,7 +2733,14 @@ static int nl80211_del_interface(struct sk_buff *skb,
struct genl_info *info)
if (!wdev-netdev)
Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On Tue, 2014-11-11 at 05:56 +, Gautam (Gautam Kumar) Shukla wrote: For offloading 4 way handshake to driver, currently we don't have any member of struct cfg80211_connect_params to pass PSK from supplicant to driver. I have added psk for the same and added rest of the code needed in nl80211.h and nl80211.c to parse and make it available to driver. From supplicant, we already have psk member field in assoc_params to use . Tested on x86 linux. Your commit message needs serious work. Also, there's a competing approach from QCA that's far more suited. In either case though, I'm going to ask which driver is going to use this and when it's going to land in mainline. 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 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On 11-11-14 06:56, Gautam (Gautam Kumar) Shukla wrote:
Hi Gautam,
Good to see more upstream contributions, but it might be useful to have
a driver implementation as well in this series. Maybe we can take a shot
with brcmfmac for obvious reasons. Would you happen to have
wpa_supplicant changes as well?
I added some inline comments below.
Regards,
Arend
For offloading 4 way handshake to driver, currently we don't have any member
of struct cfg80211_connect_params to pass PSK from supplicant to driver. I
have added psk for the same and added rest of the code needed in nl80211.h
and nl80211.c to parse and make it available to driver.
From supplicant, we already have psk member field in assoc_params to use .
In the commit message you should not describe what you did, but what
problem you are trying to solve and/or what functional change the patch
provides.
Tested on x86 linux.
Signed-off-by: Gautam kumar shukla gaut...@broadcom.com
---
include/net/cfg80211.h | 2 ++
include/uapi/linux/nl80211.h | 8 +++-
net/wireless/nl80211.c | 4
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index
a2ddcf2..6f744e0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1758,6 +1758,7 @@ struct cfg80211_ibss_params {
*allowed to ignore this @bssid_hint if it has knowledge of a better BSS
*to use.
* @ssid: SSID
+ * @psk:preshared key for WPA2-PSK connection or %NULL if not specified
add space after the colon sign.
* @ssid_len: Length of ssid in octets
* @auth_type: Authentication type (algorithm)
* @ie: IEs for association request
@@ -1783,6 +1784,7 @@ struct cfg80211_connect_params {
const u8 *bssid;
const u8 *bssid_hint;
const u8 *ssid;
+const u8 *psk;
size_t ssid_len;
enum nl80211_auth_type auth_type;
const u8 *ie;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 4b28dc0..b01d5dd 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -421,7 +421,7 @@
*%NL80211_ATTR_MAC, %NL80211_ATTR_WIPHY_FREQ,
%NL80211_ATTR_CONTROL_PORT,
*%NL80211_ATTR_CONTROL_PORT_ETHERTYPE,
*%NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT, %NL80211_ATTR_MAC_HINT, and
- *%NL80211_ATTR_WIPHY_FREQ_HINT.
+ *%NL80211_ATTR_WIPHY_FREQ_HINT, and %NL80211_ATTR_PSK.
*If included, %NL80211_ATTR_MAC and %NL80211_ATTR_WIPHY_FREQ are
*restrictions on BSS selection, i.e., they effectively prevent roaming
*within the ESS. %NL80211_ATTR_MAC_HINT and
%NL80211_ATTR_WIPHY_FREQ_HINT @@ -1638,6 +1638,10 @@ enum nl80211_commands {
* @NL80211_ATTR_SMPS_MODE: SMPS mode to use (ap mode). see
*enum nl80211_smps_mode.
*
+ *@NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet
+ (256-bit)
+ *PSK.
+ *
Some indentation gone haywire here. I would remove '(u8 attribute)'. The
mention of 32-octet seems sufficient to me.
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1990,6 +1994,8 @@ enum nl80211_attrs {
NL80211_ATTR_SMPS_MODE,
+NL80211_ATTR_PSK,
+
/* 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
5839c85..91c24b1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -395,6 +395,7 @@ static const struct nla_policy
nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_USER_PRIO] = { .type = NLA_U8 },
[NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
[NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
+[NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
};
/* policy for the key attributes */
@@ -7310,6 +7311,9 @@ static int nl80211_connect(struct sk_buff *skb, struct
genl_info *info)
connect.flags |= ASSOC_REQ_USE_RRM;
}
+if (info-attrs[NL80211_ATTR_PSK])
+connect.psk = nla_data(info-attrs[NL80211_ATTR_PSK]);
+
wdev_lock(dev-ieee80211_ptr);
err = cfg80211_connect(rdev, dev, connect, connkeys, NULL);
wdev_unlock(dev-ieee80211_ptr);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] linux-wireless:Added wiphy capability flag for offloading 4way handshake to driver
On 11-11-14 07:27, Gautam (Gautam Kumar) Shukla wrote:
For offloading 4 way handshake to driver , currently we don't have WIPHY
capability flag to communicate same to supplicant.
I have added the flag NL80211_ATTR_4WAY_KEY_HANDSHAKE and rest of the code
for the same.
Tested on x86 linux machine
Signed-off-by: Gautam kumar shukla gaut...@broadcom.com
---
include/net/cfg80211.h | 4
include/uapi/linux/nl80211.h | 5 -
net/wireless/nl80211.c | 4
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 6f744e0..b37de0a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2629,7 +2629,10 @@ struct cfg80211_ops {
* TSPEC sessions (TID aka TSID 0-7) with the NL80211_CMD_ADD_TX_TS
* command. Standard IEEE 802.11 TSPEC setup is not yet supported, it
* needs to be able to handle Block-Ack agreements and other things.
+ * @WIPHY_FLAG_SUPPORTS_4WAY_HANDHSHAKE:the device supports 4way handshake
Indentation seems wrong here. Also add space after the colon sign.
+ * in the driver/firmware.
*/
+
enum wiphy_flags {
WIPHY_FLAG_SUPPORTS_WMM_ADMISSION = BIT(0),
/* use hole at 1 */
@@ -2654,6 +2657,7 @@ enum wiphy_flags {
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL= BIT(21),
WIPHY_FLAG_SUPPORTS_5_10_MHZ= BIT(22),
WIPHY_FLAG_HAS_CHANNEL_SWITCH = BIT(23),
+ WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE = BIT(24),
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index b01d5dd..2c474a3 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1640,9 +1640,11 @@ enum nl80211_commands {
*
* @NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet (256-bit)
* PSK.
+ * @NL80211_ATTR_4WAY_KEY_HANDSHAKE: Indicates whether the driver is capable
+ * of 4way key handshake
convention is to have a tab in the continuing line.
*
*
- * @NL80211_ATTR_MAX: highest attribute number currently defined
+ * * @NL80211_ATTR_MAX: highest attribute number currently defined
huh?
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
enum nl80211_attrs {
@@ -1995,6 +1997,7 @@ enum nl80211_attrs {
NL80211_ATTR_SMPS_MODE,
NL80211_ATTR_PSK,
+ NL80211_ATTR_4WAY_KEY_HANDSHAKE,
/* add attributes here, update the policy in nl80211.c */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 91c24b1..5f85c41 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -396,6 +396,7 @@ static const struct nla_policy
nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
[NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
[NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
+ [NL80211_ATTR_4WAY_KEY_HANDSHAKE] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -1303,6 +1304,9 @@ static int nl80211_send_wiphy(struct
cfg80211_registered_device *rdev,
if ((rdev-wiphy.flags WIPHY_FLAG_SUPPORTS_FW_ROAM)
nla_put_flag(msg, NL80211_ATTR_ROAM_SUPPORT))
goto nla_put_failure;
+ if ((rdev-wiphy.flags WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE)
+ nla_put_flag(msg,NL80211_ATTR_4WAY_KEY_HANDSHAKE))
+ goto nla_put_failure;
if ((rdev-wiphy.flags WIPHY_FLAG_SUPPORTS_TDLS)
nla_put_flag(msg, NL80211_ATTR_TDLS_SUPPORT))
goto nla_put_failure;
--
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] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On 11-11-14 10:29, Johannes Berg wrote: On Tue, 2014-11-11 at 05:56 +, Gautam (Gautam Kumar) Shukla wrote: For offloading 4 way handshake to driver, currently we don't have any member of struct cfg80211_connect_params to pass PSK from supplicant to driver. I have added psk for the same and added rest of the code needed in nl80211.h and nl80211.c to parse and make it available to driver. From supplicant, we already have psk member field in assoc_params to use . Tested on x86 linux. Your commit message needs serious work. Also, there's a competing approach from QCA that's far more suited. I probably was not paying attention to it, but would you have a reference to this. In either case though, I'm going to ask which driver is going to use this and when it's going to land in mainline. I had the same question ;-) 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 -- 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:rtl8723au: core: Fix checkpatch warning
This is a patch to the rtw_cmd.c file that fixes following
Warning by introducing temporary structure.
WARNING: line over 80 characters
Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com
---
drivers/staging/rtl8723au/core/rtw_cmd.c | 42
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index cd2e915..6eccd86 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -919,34 +919,34 @@ static void traffic_status_watchdog(struct rtw_adapter
*padapter)
u8 bHigherBusyTxTraffic = false;
struct mlme_priv *pmlmepriv = padapter-mlmepriv;
int BusyThreshold = 100;
+ struct rt_link_detect *ldi = pmlmepriv-LinkDetectInfo;
+
/* */
/* Determine if our traffic is busy now */
/* */
if (check_fwstate(pmlmepriv, _FW_LINKED)) {
if (rtl8723a_BT_coexist(padapter))
BusyThreshold = 50;
- else if (pmlmepriv-LinkDetectInfo.bBusyTraffic)
+ else if (ldi-bBusyTraffic)
BusyThreshold = 75;
/* if we raise bBusyTraffic in last watchdog, using
lower threshold. */
- if (pmlmepriv-LinkDetectInfo.NumRxOkInPeriod BusyThreshold ||
- pmlmepriv-LinkDetectInfo.NumTxOkInPeriod BusyThreshold) {
+ if (ldi-NumRxOkInPeriod BusyThreshold ||
+ ldi-NumTxOkInPeriod BusyThreshold) {
bBusyTraffic = true;
- if (pmlmepriv-LinkDetectInfo.NumRxOkInPeriod
- pmlmepriv-LinkDetectInfo.NumTxOkInPeriod)
+ if (ldi-NumRxOkInPeriod ldi-NumTxOkInPeriod)
bRxBusyTraffic = true;
else
bTxBusyTraffic = true;
}
/* Higher Tx/Rx data. */
- if (pmlmepriv-LinkDetectInfo.NumRxOkInPeriod 4000 ||
- pmlmepriv-LinkDetectInfo.NumTxOkInPeriod 4000) {
+ if (ldi-NumRxOkInPeriod 4000 ||
+ ldi-NumTxOkInPeriod 4000) {
bHigherBusyTraffic = true;
- if (pmlmepriv-LinkDetectInfo.NumRxOkInPeriod
- pmlmepriv-LinkDetectInfo.NumTxOkInPeriod)
+ if (ldi-NumRxOkInPeriod ldi-NumTxOkInPeriod)
bHigherBusyRxTraffic = true;
else
bHigherBusyTxTraffic = true;
@@ -955,9 +955,9 @@ static void traffic_status_watchdog(struct rtw_adapter
*padapter)
if (!rtl8723a_BT_coexist(padapter) ||
!rtl8723a_BT_using_antenna_1(padapter)) {
/* check traffic for powersaving. */
- if (((pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod +
- pmlmepriv-LinkDetectInfo.NumTxOkInPeriod) 8) ||
- pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod
2)
+ if (((ldi-NumRxUnicastOkInPeriod +
+ ldi-NumTxOkInPeriod) 8) ||
+ ldi-NumRxUnicastOkInPeriod 2)
bEnterPS = false;
else
bEnterPS = true;
@@ -971,15 +971,15 @@ static void traffic_status_watchdog(struct rtw_adapter
*padapter)
} else
LPS_Leave23a(padapter);
- pmlmepriv-LinkDetectInfo.NumRxOkInPeriod = 0;
- pmlmepriv-LinkDetectInfo.NumTxOkInPeriod = 0;
- pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod = 0;
- pmlmepriv-LinkDetectInfo.bBusyTraffic = bBusyTraffic;
- pmlmepriv-LinkDetectInfo.bTxBusyTraffic = bTxBusyTraffic;
- pmlmepriv-LinkDetectInfo.bRxBusyTraffic = bRxBusyTraffic;
- pmlmepriv-LinkDetectInfo.bHigherBusyTraffic = bHigherBusyTraffic;
- pmlmepriv-LinkDetectInfo.bHigherBusyRxTraffic = bHigherBusyRxTraffic;
- pmlmepriv-LinkDetectInfo.bHigherBusyTxTraffic = bHigherBusyTxTraffic;
+ ldi-NumRxOkInPeriod = 0;
+ ldi-NumTxOkInPeriod = 0;
+ ldi-NumRxUnicastOkInPeriod = 0;
+ ldi-bBusyTraffic = bBusyTraffic;
+ ldi-bTxBusyTraffic = bTxBusyTraffic;
+ ldi-bRxBusyTraffic = bRxBusyTraffic;
+ ldi-bHigherBusyTraffic = bHigherBusyTraffic;
+ ldi-bHigherBusyRxTraffic = bHigherBusyRxTraffic;
+ ldi-bHigherBusyTxTraffic = bHigherBusyTxTraffic;
}
static void dynamic_chk_wk_hdl(struct rtw_adapter *padapter, u8 *pbuf, int sz)
--
1.7.11.7
--
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:rtl8723au: core: fix checkpatch error: that open brace { should be on the previous line
This is a patch to the rtw_cmd.c file that fixes following
Error.
ERROR: that open brace { should be on the previous line
Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com
---
drivers/staging/rtl8723au/core/rtw_cmd.c | 79 +++-
1 file changed, 38 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index cd2e915..e9d6ac2 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -1017,46 +1017,44 @@ static void lps_ctrl_wk_hdl(struct rtw_adapter
*padapter, u8 lps_ctrl_type)
check_fwstate(pmlmepriv, WIFI_ADHOC_STATE))
return;
- switch (lps_ctrl_type)
- {
- case LPS_CTRL_SCAN:
- rtl8723a_BT_wifiscan_notify(padapter, true);
- if (!rtl8723a_BT_using_antenna_1(padapter)) {
- if (check_fwstate(pmlmepriv, _FW_LINKED))
- LPS_Leave23a(padapter);
- }
- break;
- case LPS_CTRL_JOINBSS:
- LPS_Leave23a(padapter);
- break;
- case LPS_CTRL_CONNECT:
- mstatus = 1;/* connect */
- /* Reset LPS Setting */
- padapter-pwrctrlpriv.LpsIdleCount = 0;
- rtl8723a_set_FwJoinBssReport_cmd(padapter, 1);
- rtl8723a_BT_mediastatus_notify(padapter, mstatus);
- break;
- case LPS_CTRL_DISCONNECT:
- mstatus = 0;/* disconnect */
- rtl8723a_BT_mediastatus_notify(padapter, mstatus);
- if (!rtl8723a_BT_using_antenna_1(padapter))
- LPS_Leave23a(padapter);
- rtl8723a_set_FwJoinBssReport_cmd(padapter, 0);
- break;
- case LPS_CTRL_SPECIAL_PACKET:
- pwrpriv-DelayLPSLastTimeStamp = jiffies;
- rtl8723a_BT_specialpacket_notify(padapter);
- if (!rtl8723a_BT_using_antenna_1(padapter))
+ switch (lps_ctrl_type) {
+ case LPS_CTRL_SCAN:
+ rtl8723a_BT_wifiscan_notify(padapter, true);
+ if (!rtl8723a_BT_using_antenna_1(padapter)) {
+ if (check_fwstate(pmlmepriv, _FW_LINKED))
LPS_Leave23a(padapter);
- break;
- case LPS_CTRL_LEAVE:
- rtl8723a_BT_lps_leave(padapter);
- if (!rtl8723a_BT_using_antenna_1(padapter))
- LPS_Leave23a(padapter);
- break;
-
- default:
- break;
+ }
+ break;
+ case LPS_CTRL_JOINBSS:
+ LPS_Leave23a(padapter);
+ break;
+ case LPS_CTRL_CONNECT:
+ mstatus = 1;/* connect */
+ /* Reset LPS Setting */
+ padapter-pwrctrlpriv.LpsIdleCount = 0;
+ rtl8723a_set_FwJoinBssReport_cmd(padapter, 1);
+ rtl8723a_BT_mediastatus_notify(padapter, mstatus);
+ break;
+ case LPS_CTRL_DISCONNECT:
+ mstatus = 0;/* disconnect */
+ rtl8723a_BT_mediastatus_notify(padapter, mstatus);
+ if (!rtl8723a_BT_using_antenna_1(padapter))
+ LPS_Leave23a(padapter);
+ rtl8723a_set_FwJoinBssReport_cmd(padapter, 0);
+ break;
+ case LPS_CTRL_SPECIAL_PACKET:
+ pwrpriv-DelayLPSLastTimeStamp = jiffies;
+ rtl8723a_BT_specialpacket_notify(padapter);
+ if (!rtl8723a_BT_using_antenna_1(padapter))
+ LPS_Leave23a(padapter);
+ break;
+ case LPS_CTRL_LEAVE:
+ rtl8723a_BT_lps_leave(padapter);
+ if (!rtl8723a_BT_using_antenna_1(padapter))
+ LPS_Leave23a(padapter);
+ break;
+ default:
+ break;
}
}
@@ -1305,8 +1303,7 @@ int rtw_drvextra_cmd_hdl23a(struct rtw_adapter *padapter,
const u8 *pbuf)
pdrvextra_cmd = (struct drvextra_cmd_parm *)pbuf;
- switch (pdrvextra_cmd-ec_id)
- {
+ switch (pdrvextra_cmd-ec_id) {
case DYNAMIC_CHK_WK_CID:
dynamic_chk_wk_hdl(padapter, pdrvextra_cmd-pbuf,
pdrvextra_cmd-type_size);
--
1.7.11.7
--
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] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On Tue, 2014-11-11 at 10:54 +0100, Arend van Spriel wrote: Also, there's a competing approach from QCA that's far more suited. I probably was not paying attention to it, but would you have a reference to this. ... digs around in email ... http://mid.gmane.org/1343907187-6686-1-git-send-email-qca_vkond...@qca.qualcomm.com Anyway, looking back at that, it wasn't really all that different, just a bit more complete maybe. 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: (Intel Wireless 7260) + 5G + AP mode
On 10-11-14 22:31, Efill wrote: I’m trying to get the 7260 to act as an AP on the 5G band. Unfortunately it seems to be impossible due to the „no IR“ reg domain restriction done by the Intel firmware internally (this is what I’ve googled so far..). Could someone explain to me the technical background of this. As far as I understood the regulation if DFS and TPC are used, most of the 5G channels are allowed. Did I miss something? What’s the point of restricting the IR then? This is not true world wide. With the devices currently available, you can't have IR in 5GHz. Even so I don't want to teach you wrong, a quick look at wikipedia reveals a slightly different view on this: https://en.wikipedia.org/wiki/List_of_WLAN_channels#5.C2.A0GHz_.28802.11a.2Fh.2Fj.2Fn.2Fac.29.5B17.5D I mean that's exactly what's the linux kernel reg domain stuff ( http://wireless.kernel.org/en/developers/Regulatory/processing_rules ) is meant to manage, isn't it? Let me clarify, with *Intel* devices currently available, you will not be able to have IR in 5GHz. That's the reason I wrote the mail in the first place. I wasn't able to use AP mode at 5G. Wich I found out by myself and didn't read somewhere e.g. at http://wireless.kernel.org/en/users/Drivers/iwlwifi . If it's that clear and obvious, why not state it there? I would have saved me 50 Euros and some hours... Just a feeling, but I guess asking something like Why? wouldn't help me in understanding, right? This is just some marketing decision at Intel (don't support 5G AP mode in consumer WiFi cards) developers have to follow. And finally: Is there a way to get it work? Some other PCI-E chip? ath10k? Does anyone have a working setup for 5G AP mode with linux using a (m)PCI(-e) card? Or are there only SoCs available for this job? Well, I have although I would have no idea where you could buy it. As you may guess it is a Broadcom device and comes with my job. Regards, Arend Thanks, Efill-- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
Thanks a lot Johannes and Arend , for your comments and review . It will really help me in my next patch submission . Just wanted to know when QCA patch will get in main line as it was last updated on 23 aug 2012. Thanks and regards -Original Message- From: Arend van Spriel [mailto:ar...@broadcom.com] Sent: Tuesday, November 11, 2014 3:24 PM To: Johannes Berg; Gautam (Gautam Kumar) Shukla Cc: linvi...@tuxdriver.com; linux-wireless@vger.kernel.org; da...@davemloft.net; linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; net...@vger.kernel.org; Jithu Jance; Sreenath S Subject: Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver On 11-11-14 10:29, Johannes Berg wrote: On Tue, 2014-11-11 at 05:56 +, Gautam (Gautam Kumar) Shukla wrote: For offloading 4 way handshake to driver, currently we don't have any member of struct cfg80211_connect_params to pass PSK from supplicant to driver. I have added psk for the same and added rest of the code needed in nl80211.h and nl80211.c to parse and make it available to driver. From supplicant, we already have psk member field in assoc_params to use . Tested on x86 linux. Your commit message needs serious work. Also, there's a competing approach from QCA that's far more suited. I probably was not paying attention to it, but would you have a reference to this. In either case though, I'm going to ask which driver is going to use this and when it's going to land in mainline. I had the same question ;-) 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 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On 11-11-14 11:03, Johannes Berg wrote: On Tue, 2014-11-11 at 10:54 +0100, Arend van Spriel wrote: Also, there's a competing approach from QCA that's far more suited. I probably was not paying attention to it, but would you have a reference to this. ... digs around in email ... http://mid.gmane.org/1343907187-6686-1-git-send-email-qca_vkond...@qca.qualcomm.com Anyway, looking back at that, it wasn't really all that different, just a bit more complete maybe. Read through the whole thread. It seems some comments from you needed to be addressed and Vladimir wanted to evaluate it. So that was the end of the thread. What did pop up is the wiphy flags vs. nl80211 feature flags. When that comes up it looks like 'potAtoes, potaetoes' to me. So is there are clear design rule for when to use which flag. For me the wiphy object represents the device/firmware and 4-way handshake offload support is determined by what the device/firmware supports. Regards, Arend johannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On Tue, 2014-11-11 at 11:35 +0100, Arend van Spriel wrote: What did pop up is the wiphy flags vs. nl80211 feature flags. When that comes up it looks like 'potAtoes, potaetoes' to me. So is there are clear design rule for when to use which flag. For me the wiphy object represents the device/firmware and 4-way handshake offload support is determined by what the device/firmware supports. There are three types of flags: * wiphy flag attributes - deprecated as far as I'm concerned * wiphy nl80211 feature flags - much easier to use in kernel (and userspace) * nl80211 protocol flags - only one exists (NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP) 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 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On 11-11-14 11:38, Johannes Berg wrote: On Tue, 2014-11-11 at 11:35 +0100, Arend van Spriel wrote: What did pop up is the wiphy flags vs. nl80211 feature flags. When that comes up it looks like 'potAtoes, potaetoes' to me. So is there are clear design rule for when to use which flag. For me the wiphy object represents the device/firmware and 4-way handshake offload support is determined by what the device/firmware supports. There are three types of flags: * wiphy flag attributes - deprecated as far as I'm concerned Ok. deprecated is clear enough ;-) * wiphy nl80211 feature flags - much easier to use in kernel (and userspace) * nl80211 protocol flags - only one exists (NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP) Thanks, 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: linux + 5G band + AP mode
Hi On 11 November 2014 10:41, Efill ef...@me.com wrote: Dear all, Are there any working (m)PCI(e) adapters out there suitable to run an AP at 5G (using 802.11ac)? You can use atheros cards they support both AP and Sta modes on 802.11ac. Linux wireless mailing list is the place to ask not hostap. Does someone have a working dualband (using two adapters one for 11n@2G and one for 11ac@5G) setup she/he is willing to share? I appreciate any thoughts on this. Thanks, Efill ___ HostAP mailing list hos...@lists.shmoo.com http://lists.shmoo.com/mailman/listinfo/hostap -- 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] brcmfmac: unlink URB when request timed out
On 10-11-14 17:08, Mathy Vanhoef wrote: On 11/10/2014 06:18 AM, Arend van Spriel wrote: On 09-11-14 19:10, Mathy Vanhoef wrote: From: Mathy Vanhoef vanho...@gmail.com Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This assures the URB is never submitted twice, preventing a driver crash. Hi Mathy, What driver crash are you referring to? The log only shows the WARNING ending in a USB disconnect but no actual crash. Does your patch get the driver running properly or does it only avoid the warning. Hi Arend, It shows a warning, after which the device doesn't work (but the computer is still usable). But I've noticed that when *unplugging* the USB cable the OS may freeze. This doesn't always happen though, sometimes unplugging works OK. The patch both avoids the warning, and gets the device/driver running properly (unplugging also works OK). With that said, it seems there is some need for improvement, but I also notice you are running this on a virtual machine so could that affect the timeout to kick in before completion. Could you try to increase the timeout. Still when a timeout occurs this needs to be handled properly. Could you also try the following patch? I did a few additional tests: 1. When increasing IOCTL_RESP_TIMEOUT to 2 (ten times the normal value) the timeout and warning still occur. Device/driver doesn't work. 2. When increasing BRCMF_USB_RESET_GETVER_SPINWAIT to 1000 (ten timers the normal value) everything works. Device/driver works. This means the ctl_urb completes on your system within 3sec, but not within 2.1sec. After discussing this with my colleague, we think you should use usb_kill_urb() instead of usb_unlink_urb() as it assures the completion handler is called. Could you retest that and let us know. Regards, Arend 3. Quick test using backports-3.18-rc1-1 (aka unpatched driver) on a non- virtualized Linux install: In that case everything worked fine. So the bug may only be triggered in a virtualized environment / VMWare. 4. When applying your patch, the driver stops early during initialization of the device. I included a WARN_ONCE before returning EINVAL and got the output below. Kind regards, Mathy --- [ 220.955647] usb 1-1: new high-speed USB device number 3 using ehci-pci [ 221.487797] usb 1-1: New USB device found, idVendor=043e, idProduct=3004 [ 221.487802] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 221.487804] usb 1-1: Product: Remote Download Wireless Adapter [ 221.487806] usb 1-1: Manufacturer: Broadcom [ 221.487808] usb 1-1: SerialNumber: 0001 [ 221.490472] brcmfmac: brcmf_usb_probe Enter 0x043e:0x3004 [ 221.490476] brcmfmac: brcmf_usb_probe Broadcom high speed USB WLAN interface detected [ 221.490477] brcmfmac: brcmf_usb_probe_cb Enter [ 221.490480] brcmfmac: brcmf_usb_attach Enter [ 221.490494] brcmfmac: brcmf_usb_dlneeded Enter [ 221.490495] [ cut here ] [ 221.490503] WARNING: CPU: 0 PID: 100 at drivers/net/wireless/brcm80211/brcmfmac/usb.c:716 brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]() [ 221.490505] EINVAL devinfo=c0044000 ctl_rub=ef898380 completed=0 [ 221.490506] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase [ 221.490514] CPU: 0 PID: 100 Comm: kworker/0:1 Not tainted 3.18.0-rc3-wl+ #2 [ 221.490515] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 221.490528] Workqueue: usb_hub_wq hub_event [ 221.490530] eecffb58 c1711f4a eecffb98 eecffb88 c103edaf f11cbc58 [ 221.490534] eecffbb4 0064 f11cbc84 02cc f11c1595 f11c1595 c0044000 ffea [ 221.490537] ef726000 eecffba0 c103ee4e 0009 eecffb98 f11cbc58 eecffbb4 eecffbd0 [ 221.490541] Call Trace: [ 221.490550] [c1711f4a] dump_stack+0x41/0x52 [ 221.490558] [c103edaf] warn_slowpath_common+0x7f/0xa0 [ 221.490563] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490567] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490570] [c103ee4e] warn_slowpath_fmt+0x2e/0x30 [ 221.490575] [f11c1595] brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490580] [f11c2cd8] brcmf_usb_probe+0x3c8/0x640 [brcmfmac] [ 221.490583] [c1717d53] ? mutex_lock+0x13/0x32 [ 221.490586] [c1493ae3] usb_probe_interface+0xa3/0x180 [ 221.490590] [c13f5690] ? __driver_attach+0x90/0x90 [ 221.490592] [c13f546e] driver_probe_device+0x5e/0x1f0 [ 221.490595] [c13f5690] ? __driver_attach+0x90/0x90 [ 221.490597] [c13f56c9] __device_attach+0x39/0x50 [ 221.490600] [c13f3d84] bus_for_each_drv+0x34/0x70 [ 221.490602] [c13f53db] device_attach+0x7b/0x90 [ 221.490604] [c13f5690] ? __driver_attach+0x90/0x90 [ 221.490607] [c13f4b8f] bus_probe_device+0x6f/0x90 [ 221.490609] [c13f3256] device_add+0x426/0x520 [ 221.490611] [c1491503] ? usb_control_msg+0xb3/0xd0 [ 221.490614]
Re: brcmfmac not working on ECS LIVA
On 10-11-14 21:48, Felipe Contreras wrote: Hi, On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel ar...@broadcom.com wrote: The ideas may come to us with a bit more trace information. The logging above is the usual stuff so no problem indication there. I looked at the nvram file from [1]. At the end there are some entries about OOB wakeup, ie. starting with 'sd_'. You may remove those, but giving the logging it would not be the first thing to do. I removed the sd_ lines, it didn't help. Could you share the nvram obtained from EFI? Also please create a kernel log with debug=0xd416. Sure, the nvram file is here: http://pastie.org/9710358 I tried adding this file: /etc/modprobe.d/brcmfmac.conf options brcmfmac debug=0xd416 I see nothing extra in the debug log... Am I doing something wrong? Not sure. You can verify and set the log level through sysfs, ie.: $ cat /sys/module/brcmfmac/parameters/debug To set it: $ echo 0xd416 /sys/module/brcmfmac/parameters/debug 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: MediaTek WiFi hardware support in upstream kernel
Am 29.10.2014 um 11:17 schrieb Felix Fietkau: Hi Hackers, Just a quick heads up: I'm working on a new driver for MT7662E/MT7612E, written from scratch. It is already able to bring up the firmware, init the MAC and do basic TX/RX DMA communication with the firmware. I've decided to not integrate it with rt2x00, because I want to avoid dealing with the the unnecessarily convoluted abstractions and legacy code in there. I believe the result will be simpler and easier to maintain as a new driver. As soon as the basic structure is in place, I will put it on a public git tree and post a link here. - Felix Which chip would you suggest for starting? -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
[PATCH 3.16.y-ckt 008/170] wireless: rt2x00: add new rt2800usb devices
3.16.7-ckt1 -stable review patch. If anyone has any objections, please let me
know.
--
From: Xose Vazquez Perez xose.vazq...@gmail.com
commit 6a06e554daef86c4e8d290284927b081fedb249e upstream.
0x0b05 0x17e8 RT5372 USB 2.0 bgn 2x2 ASUS USB-N14
0x0411 0x0253 RT5572 USB 2.0 abgn 2x2 BUFFALO WLP-U2-300D
0x0df6 0x0078 RT Sitecom N300
Cc: Ivo van Doorn ivdo...@gmail.com
Cc: Helmut Schaa helmut.sc...@googlemail.com
Cc: John W. Linville linvi...@tuxdriver.com
Cc: us...@rt2x00.serialmonkey.com
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Xose Vazquez Perez xose.vazq...@gmail.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Cc: Stanislaw Gruszka sgrus...@redhat.com
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
drivers/net/wireless/rt2x00/rt2800usb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
b/drivers/net/wireless/rt2x00/rt2800usb.c
index 832006b5aab1..573897b8e878 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1284,6 +1284,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Arcadyan */
{ USB_DEVICE(0x043e, 0x7a12) },
{ USB_DEVICE(0x043e, 0x7a32) },
+ /* ASUS */
+ { USB_DEVICE(0x0b05, 0x17e8) },
/* Azurewave */
{ USB_DEVICE(0x13d3, 0x3329) },
{ USB_DEVICE(0x13d3, 0x3365) },
@@ -1320,6 +1322,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x057c, 0x8501) },
/* Buffalo */
{ USB_DEVICE(0x0411, 0x0241) },
+ { USB_DEVICE(0x0411, 0x0253) },
/* D-Link */
{ USB_DEVICE(0x2001, 0x3c1a) },
{ USB_DEVICE(0x2001, 0x3c21) },
@@ -1410,6 +1413,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x0df6, 0x0053) },
{ USB_DEVICE(0x0df6, 0x0069) },
{ USB_DEVICE(0x0df6, 0x006f) },
+ { USB_DEVICE(0x0df6, 0x0078) },
/* SMC */
{ USB_DEVICE(0x083a, 0xa512) },
{ USB_DEVICE(0x083a, 0xc522) },
--
2.1.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
[PATCH for-3.18] brcmfmac: fix conversion of channel width 20MHZ_NOHT
The function chandef_to_chanspec() failed when converting a
chandef with bandwidth set to NL80211_CHAN_WIDTH_20_NOHT. This
was reported by user running the device in AP mode.
[ cut here ]
WARNING: CPU: 0 PID: 304 at
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:381
chandef_to_chanspec.isra.11+0x158/0x184()
Modules linked in:
CPU: 0 PID: 304 Comm: hostapd Not tainted 3.16.0-rc7-abb+g64aa90f #8
[c0014bb4] (unwind_backtrace) from [c0012314] (show_stack+0x10/0x14)
[c0012314] (show_stack) from [c001d3f8] (warn_slowpath_common+0x6c/0x8c)
[c001d3f8] (warn_slowpath_common) from [c001d4b4]
(warn_slowpath_null+0x1c/0x24)
[c001d4b4] (warn_slowpath_null) from [c03449a4]
(chandef_to_chanspec.isra.11+0x158/0x184)
[c03449a4] (chandef_to_chanspec.isra.11) from [c0348e00]
(brcmf_cfg80211_start_ap+0x1e4/0x614)
[c0348e00] (brcmf_cfg80211_start_ap) from [c04d1468]
(nl80211_start_ap+0x288/0x414)
[c04d1468] (nl80211_start_ap) from [c043d144] (genl_rcv_msg+0x21c/0x38c)
[c043d144] (genl_rcv_msg) from [c043c740] (netlink_rcv_skb+0xac/0xc0)
[c043c740] (netlink_rcv_skb) from [c043cf14] (genl_rcv+0x20/0x34)
[c043cf14] (genl_rcv) from [c043c0a0] (netlink_unicast+0x150/0x20c)
[c043c0a0] (netlink_unicast) from [c043c4b8] (netlink_sendmsg+0x2b8/0x398)
[c043c4b8] (netlink_sendmsg) from [c04066a4] (sock_sendmsg+0x84/0xa8)
[c04066a4] (sock_sendmsg) from [c0407c5c]
(___sys_sendmsg.part.29+0x268/0x278)
[c0407c5c] (___sys_sendmsg.part.29) from [c0408bdc]
(__sys_sendmsg+0x4c/0x7c)
[c0408bdc] (__sys_sendmsg) from [c000ec60] (ret_fast_syscall+0x0/0x44)
---[ end trace 965ee2158c9905a2 ]---
Cc: sta...@vger.kernel.org # v3.17
Reported-by: Pontus Fuchs pont...@broadcom.com
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Daniel (Deognyoun) Kim de...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 28fa25b..39b45c0 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -299,6 +299,7 @@ static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
primary_offset = ch-center_freq1 - ch-chan-center_freq;
switch (ch-width) {
case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_20_NOHT:
ch_inf.bw = BRCMU_CHAN_BW_20;
WARN_ON(primary_offset != 0);
break;
@@ -323,6 +324,10 @@ static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
ch_inf.sb = BRCMU_CHAN_SB_LU;
}
break;
+ case NL80211_CHAN_WIDTH_80P80:
+ case NL80211_CHAN_WIDTH_160:
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
default:
WARN_ON_ONCE(1);
}
@@ -333,6 +338,7 @@ static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
case IEEE80211_BAND_5GHZ:
ch_inf.band = BRCMU_CHAN_BAND_5G;
break;
+ case IEEE80211_BAND_60GHZ:
default:
WARN_ON_ONCE(1);
}
--
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] rt2x00: do not align payload on modern H/W
On Sun, Nov 02, 2014 at 01:38:47PM +0100, Stanislaw Gruszka wrote: RT2800 and newer hardware require padding between header and payload if header length is not multiple of 4. For historical reasons we also align payload to to 4 bytes boundary, but such alignment is not needed on modern H/W. Patch improve performance on embedded CPUs and _possibly_ fixes skb_under_panic problems reported from time to time: https://bugzilla.kernel.org/show_bug.cgi?id=84911 https://bugzilla.kernel.org/show_bug.cgi?id=72471 http://marc.info/?l=linux-wirelessm=139108549530402w=2 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591 But we can not explain or otherwise confirm the patch fixes this panic issue for sure. Antti on https://bugzilla.kernel.org/show_bug.cgi?id=72471 tested patch and confirm it fixes the panic, he also provided traces showing that we really eat headroom on each retransmission in some special case - no payload and header length not being multiple of 4. Taking that and since this patch was not yet applied I'll repost it with updated changelog and direct to 3.18 stream and -stable. Stanislaw -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ath9k: Fix high tx power in multi-chain mode
On 2014-11-11 08:07, Sujith Manoharan wrote: From: Miaoqing Pan miaoq...@qca.qualcomm.com For multi-chain chips, if the thermometer is switched off for a chain which can be disabled by software(e.g tx_chainmask=0x1), the measured tx power is about 5dB higher than target power. Set thermometer on for all chains to fix this issue. That doesn't seem right to me. ah-caps.tx_chainmask is not altered based on software antenna configuration. - Felix -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] nl80211: Stop scheduled scan if netlink client disappears
A new attribute NL80211_ATTR_SCAN_SOCKET_OWNER can be set by the
scan initiator. If present, the attribute will cause the scan to
be stopped if the client dies.
Signed-off-by: Jukka Rissanen jukka.rissa...@linux.intel.com
---
include/net/cfg80211.h | 2 ++
include/uapi/linux/nl80211.h | 8
net/wireless/nl80211.c | 35 +++
3 files changed, 45 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 220d5f5..84378bf 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1512,6 +1512,8 @@ struct cfg80211_sched_scan_request {
struct wiphy *wiphy;
struct net_device *dev;
unsigned long scan_start;
+ u32 owner_nlportid;
+ struct work_struct sched_scan_stop_wk;
/* keep last */
struct ieee80211_channel *channels[0];
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 442369f..2731a04 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1669,6 +1669,11 @@ enum nl80211_commands {
* @NL80211_ATTR_SMPS_MODE: SMPS mode to use (ap mode). see
* enum nl80211_smps_mode.
*
+ * @NL80211_ATTR_SCAN_SOCKET_OWNER: flag attribute, if set during scheduled
+ * scan start then the new scan req will be owned by the netlink socket
+ * that created it and the pending scan will be stopped when the socket
+ * is closed.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -2021,6 +2026,8 @@ enum nl80211_attrs {
NL80211_ATTR_SMPS_MODE,
+ NL80211_ATTR_SCAN_SOCKET_OWNER,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -2056,6 +2063,7 @@ enum nl80211_attrs {
#define NL80211_ATTR_KEY NL80211_ATTR_KEY
#define NL80211_ATTR_KEYS NL80211_ATTR_KEYS
#define NL80211_ATTR_FEATURE_FLAGS NL80211_ATTR_FEATURE_FLAGS
+#define NL80211_ATTR_SCAN_SOCKET_OWNER NL80211_ATTR_SCAN_SOCKET_OWNER
#define NL80211_MAX_SUPP_RATES 32
#define NL80211_MAX_SUPP_HT_RATES 77
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d0a8361..653f649 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -395,6 +395,7 @@ static const struct nla_policy
nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_USER_PRIO] = { .type = NLA_U8 },
[NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
[NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
+ [NL80211_ATTR_SCAN_SOCKET_OWNER] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -5681,6 +5682,21 @@ static int nl80211_trigger_scan(struct sk_buff *skb,
struct genl_info *info)
return err;
}
+static void nl80211_sched_scan_stop_wk(struct work_struct *work)
+{
+ struct cfg80211_sched_scan_request *req;
+ struct cfg80211_registered_device *rdev;
+
+ req = container_of(work, struct cfg80211_sched_scan_request,
+ sched_scan_stop_wk);
+
+ rdev = wiphy_to_rdev(req-wiphy);
+
+ rtnl_lock();
+ __cfg80211_stop_sched_scan(rdev, false);
+ rtnl_unlock();
+}
+
static int nl80211_start_sched_scan(struct sk_buff *skb,
struct genl_info *info)
{
@@ -5955,6 +5971,13 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
err = rdev_sched_scan_start(rdev, dev, request);
if (!err) {
+ if (info-attrs[NL80211_ATTR_SCAN_SOCKET_OWNER]) {
+ INIT_WORK(request-sched_scan_stop_wk,
+ nl80211_sched_scan_stop_wk);
+
+ request-owner_nlportid = info-snd_portid;
+ }
+
rdev-sched_scan_req = request;
nl80211_send_sched_scan(rdev, dev,
NL80211_CMD_START_SCHED_SCAN);
@@ -12127,6 +12150,12 @@ static int nl80211_netlink_notify(struct
notifier_block * nb,
list_for_each_entry_rcu(rdev, cfg80211_rdev_list, list) {
bool schedule_destroy_work = false;
+ bool schedule_scan_stop = false;
+ struct cfg80211_sched_scan_request *req = rdev-sched_scan_req;
+
+ if (req req-owner_nlportid == notify-portid
+ notify-portid)
+ schedule_scan_stop = true;
list_for_each_entry_rcu(wdev, rdev-wdev_list, list) {
cfg80211_mlme_unregister_socket(wdev, notify-portid);
@@ -12157,6 +12186,12 @@ static int nl80211_netlink_notify(struct
notifier_block * nb,
spin_unlock(rdev-destroy_list_lock);
schedule_work(rdev-destroy_work);
}
+ } else if (schedule_scan_stop) {
+ req-owner_nlportid = 0;
+
+ if (rdev-ops-sched_scan_stop
+
Re: [PATCH] nl80211: Stop scheduled scan if netlink client disappears
On Tue, 2014-11-11 at 16:27 +0200, Jukka Rissanen wrote:
+static void nl80211_sched_scan_stop_wk(struct work_struct *work)
+{
+ struct cfg80211_sched_scan_request *req;
+ struct cfg80211_registered_device *rdev;
+
+ req = container_of(work, struct cfg80211_sched_scan_request,
+sched_scan_stop_wk);
+
+ rdev = wiphy_to_rdev(req-wiphy);
+
+ rtnl_lock();
+ __cfg80211_stop_sched_scan(rdev, false);
+ rtnl_unlock();
+}
I think you'll need to do something like flush this (which probably
isn't possible due to RTNL usage) when the interface disappears?
Otherwise interface going down and socket closure could race, ifdown
causing the request to be aborted by socket closure having scheduled the
work ... that'd be troubling.
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] mac80211: refactor duplicate detection
From: Johannes Berg johannes.b...@intel.com
Put duplicate detection into its own RX handler, and separate
out the conditions a bit to make the code more readable.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/rx.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index f57af5c7c12a..0f4297e2aae2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1047,7 +1047,7 @@ static void ieee80211_rx_reorder_ampdu(struct
ieee80211_rx_data *rx,
}
static ieee80211_rx_result debug_noinline
-ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
+ieee80211_rx_h_check_dup(struct ieee80211_rx_data *rx)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx-skb-data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx-skb);
@@ -1056,10 +1056,16 @@ ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
* Drop duplicate 802.11 retransmissions
* (IEEE 802.11-2012: 9.3.2.10 Duplicate detection and recovery)
*/
- if (rx-skb-len = 24 rx-sta
- !ieee80211_is_ctl(hdr-frame_control)
- !ieee80211_is_qos_nullfunc(hdr-frame_control)
- !is_multicast_ether_addr(hdr-addr1)) {
+
+ if (rx-skb-len 24)
+ return RX_CONTINUE;
+
+ if (ieee80211_is_ctl(hdr-frame_control) ||
+ ieee80211_is_qos_nullfunc(hdr-frame_control) ||
+ is_multicast_ether_addr(hdr-addr1))
+ return RX_CONTINUE;
+
+ if (rx-sta) {
if (unlikely(ieee80211_has_retry(hdr-frame_control)
rx-sta-last_seq_ctrl[rx-seqno_idx] ==
hdr-seq_ctrl)) {
@@ -1073,6 +1079,14 @@ ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
}
}
+ return RX_CONTINUE;
+}
+
+static ieee80211_rx_result debug_noinline
+ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
+{
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx-skb-data;
+
if (unlikely(rx-skb-len 16)) {
I802_DEBUG_INC(rx-local-rx_handlers_drop_short);
return RX_DROP_MONITOR;
@@ -3110,6 +3124,7 @@ static void ieee80211_invoke_rx_handlers(struct
ieee80211_rx_data *rx)
goto rxh_next; \
} while (0);
+ CALL_RXH(ieee80211_rx_h_check_dup)
CALL_RXH(ieee80211_rx_h_check)
ieee80211_rx_reorder_ampdu(rx, reorder_release);
--
2.1.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] mac80211: don't allow 40MHz tx rates in case of 20MHz chandef
From: Eliad Peller el...@wizery.com When 20MHz chandef is used, 40MHz rates shouldn't be used (by the rate-control algorithm), even if the sta ht capabilities indicate support for it. Signed-off-by: Eliad Peller eliadx.pel...@intel.com Singed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com --- net/mac80211/vht.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c index 671ce0d..bc9e8fc 100644 --- a/net/mac80211/vht.c +++ b/net/mac80211/vht.c @@ -287,6 +287,8 @@ enum ieee80211_sta_rx_bandwidth ieee80211_sta_cur_vht_bw(struct sta_info *sta) /* fall through */ case NL80211_CHAN_WIDTH_20_NOHT: case NL80211_CHAN_WIDTH_20: + bw = IEEE80211_STA_RX_BW_20; + break; case NL80211_CHAN_WIDTH_40: bw = sta-sta.ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40 ? IEEE80211_STA_RX_BW_40 : IEEE80211_STA_RX_BW_20; -- 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 v2] nl80211: Broadcast CMD_NEW_INTERFACE and CMD_DEL_INTERFACE
On Tue, 2014-11-11 at 10:19 +0200, Tomasz Bursztyka wrote:
static int nl80211_send_iface(struct sk_buff *msg, u32 portid, u32 seq, int
flags,
struct cfg80211_registered_device *rdev,
- struct wireless_dev *wdev)
+ struct wireless_dev *wdev, bool new)
That new parameter makes no sense, everybody is going to read that as
is it a new interface (for the mcast of NEW_INTERFACE) but that's
completely bogus. I kinda understand where you're coming from (the
command name) but it's still really confusing.
Inverting it to removal or so would be much easier to follow.
Additionally,
@@ -2364,7 +2368,7 @@ static int nl80211_send_iface(struct sk_buff *msg, u32
portid, u32 seq, int flag
(cfg80211_rdev_list_generation 2)))
goto nla_put_failure;
- if (rdev-ops-get_channel) {
+ if (new rdev-ops-get_channel) {
int ret;
struct cfg80211_chan_def chandef;
This shouldn't be needed, since when the interface is removed if there's
still a channel you can send it, but usually there won't be one.
@@ -2375,7 +2379,7 @@ static int nl80211_send_iface(struct sk_buff *msg, u32
portid, u32 seq, int flag
}
}
- if (wdev-ssid_len) {
+ if (new wdev-ssid_len) {
if (nla_put(msg, NL80211_ATTR_SSID, wdev-ssid_len, wdev-ssid))
goto nla_put_failure;
Ditto, I don't believe there can still be an SSID stored.
@@ -2587,7 +2591,7 @@ static int nl80211_new_interface(struct sk_buff *skb,
struct genl_info *info)
struct cfg80211_registered_device *rdev = info-user_ptr[0];
struct vif_params params;
struct wireless_dev *wdev;
- struct sk_buff *msg;
+ struct sk_buff *msg, *n_msg;
n_msg means nothing? maybe just call that *event?
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (msg nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, false) 0) {
+ nlmsg_free(msg);
+ msg = NULL;
+ }
broken indentation
/*
* If we remove a wireless device without a netdev then clear
* user_ptr[1] so that nl80211_post_doit won't dereference it
@@ -2708,7 +2733,14 @@ static int nl80211_del_interface(struct sk_buff *skb,
struct genl_info *info)
if (!wdev-netdev)
info-user_ptr[1] = NULL;
- return rdev_del_virtual_intf(rdev, wdev);
+ status = rdev_del_virtual_intf(rdev, wdev);
+ if (status = 0 msg) {
+ genlmsg_multicast_netns(nl80211_fam, wiphy_net(rdev-wiphy),
+ msg, 0, NL80211_MCGRP_CONFIG,
+ GFP_KERNEL);
+ }
no need for braces, missing else
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] brcmfmac: unlink URB when request timed out
Using usb_kill_urb() instead of usb_unlink_urb() seems to work without any problems. On 11/11/2014 06:05 AM, Arend van Spriel wrote: On 10-11-14 17:08, Mathy Vanhoef wrote: On 11/10/2014 06:18 AM, Arend van Spriel wrote: On 09-11-14 19:10, Mathy Vanhoef wrote: From: Mathy Vanhoef vanho...@gmail.com Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This assures the URB is never submitted twice, preventing a driver crash. Hi Mathy, What driver crash are you referring to? The log only shows the WARNING ending in a USB disconnect but no actual crash. Does your patch get the driver running properly or does it only avoid the warning. Hi Arend, It shows a warning, after which the device doesn't work (but the computer is still usable). But I've noticed that when *unplugging* the USB cable the OS may freeze. This doesn't always happen though, sometimes unplugging works OK. The patch both avoids the warning, and gets the device/driver running properly (unplugging also works OK). With that said, it seems there is some need for improvement, but I also notice you are running this on a virtual machine so could that affect the timeout to kick in before completion. Could you try to increase the timeout. Still when a timeout occurs this needs to be handled properly. Could you also try the following patch? I did a few additional tests: 1. When increasing IOCTL_RESP_TIMEOUT to 2 (ten times the normal value) the timeout and warning still occur. Device/driver doesn't work. 2. When increasing BRCMF_USB_RESET_GETVER_SPINWAIT to 1000 (ten timers the normal value) everything works. Device/driver works. This means the ctl_urb completes on your system within 3sec, but not within 2.1sec. After discussing this with my colleague, we think you should use usb_kill_urb() instead of usb_unlink_urb() as it assures the completion handler is called. Could you retest that and let us know. Regards, Arend 3. Quick test using backports-3.18-rc1-1 (aka unpatched driver) on a non- virtualized Linux install: In that case everything worked fine. So the bug may only be triggered in a virtualized environment / VMWare. 4. When applying your patch, the driver stops early during initialization of the device. I included a WARN_ONCE before returning EINVAL and got the output below. Kind regards, Mathy --- [ 220.955647] usb 1-1: new high-speed USB device number 3 using ehci-pci [ 221.487797] usb 1-1: New USB device found, idVendor=043e, idProduct=3004 [ 221.487802] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 221.487804] usb 1-1: Product: Remote Download Wireless Adapter [ 221.487806] usb 1-1: Manufacturer: Broadcom [ 221.487808] usb 1-1: SerialNumber: 0001 [ 221.490472] brcmfmac: brcmf_usb_probe Enter 0x043e:0x3004 [ 221.490476] brcmfmac: brcmf_usb_probe Broadcom high speed USB WLAN interface detected [ 221.490477] brcmfmac: brcmf_usb_probe_cb Enter [ 221.490480] brcmfmac: brcmf_usb_attach Enter [ 221.490494] brcmfmac: brcmf_usb_dlneeded Enter [ 221.490495] [ cut here ] [ 221.490503] WARNING: CPU: 0 PID: 100 at drivers/net/wireless/brcm80211/brcmfmac/usb.c:716 brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]() [ 221.490505] EINVAL devinfo=c0044000 ctl_rub=ef898380 completed=0 [ 221.490506] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase [ 221.490514] CPU: 0 PID: 100 Comm: kworker/0:1 Not tainted 3.18.0-rc3-wl+ #2 [ 221.490515] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 221.490528] Workqueue: usb_hub_wq hub_event [ 221.490530] eecffb58 c1711f4a eecffb98 eecffb88 c103edaf f11cbc58 [ 221.490534] eecffbb4 0064 f11cbc84 02cc f11c1595 f11c1595 c0044000 ffea [ 221.490537] ef726000 eecffba0 c103ee4e 0009 eecffb98 f11cbc58 eecffbb4 eecffbd0 [ 221.490541] Call Trace: [ 221.490550] [c1711f4a] dump_stack+0x41/0x52 [ 221.490558] [c103edaf] warn_slowpath_common+0x7f/0xa0 [ 221.490563] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490567] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490570] [c103ee4e] warn_slowpath_fmt+0x2e/0x30 [ 221.490575] [f11c1595] brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490580] [f11c2cd8] brcmf_usb_probe+0x3c8/0x640 [brcmfmac] [ 221.490583] [c1717d53] ? mutex_lock+0x13/0x32 [ 221.490586] [c1493ae3] usb_probe_interface+0xa3/0x180 [ 221.490590] [c13f5690] ? __driver_attach+0x90/0x90 [ 221.490592] [c13f546e] driver_probe_device+0x5e/0x1f0 [ 221.490595] [c13f5690] ? __driver_attach+0x90/0x90 [ 221.490597] [c13f56c9] __device_attach+0x39/0x50 [ 221.490600] [c13f3d84] bus_for_each_drv+0x34/0x70 [ 221.490602] [c13f53db] device_attach+0x7b/0x90 [ 221.490604] [c13f5690] ? __driver_attach+0x90/0x90 [ 221.490607] [c13f4b8f]
Re: [PATCH] brcmfmac: unlink URB when request timed out
On 11-11-14 18:35, Mathy Vanhoef wrote: Using usb_kill_urb() instead of usb_unlink_urb() seems to work without any problems. Ok, as usb_kill_urb() assures the completion handler is called there is no need to check the ctl_completed flag, ie. my patch. Go ahead and resubmit your patch replacing usb_unlink_urb() by usb_kill_urb(). Do you mean you end up with a working usb device providing a wireless interface? Or does probe still fail, but you do not get a crash. Regards, Arend On 11/11/2014 06:05 AM, Arend van Spriel wrote: On 10-11-14 17:08, Mathy Vanhoef wrote: On 11/10/2014 06:18 AM, Arend van Spriel wrote: On 09-11-14 19:10, Mathy Vanhoef wrote: From: Mathy Vanhoef vanho...@gmail.com Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This assures the URB is never submitted twice, preventing a driver crash. Hi Mathy, What driver crash are you referring to? The log only shows the WARNING ending in a USB disconnect but no actual crash. Does your patch get the driver running properly or does it only avoid the warning. Hi Arend, It shows a warning, after which the device doesn't work (but the computer is still usable). But I've noticed that when *unplugging* the USB cable the OS may freeze. This doesn't always happen though, sometimes unplugging works OK. The patch both avoids the warning, and gets the device/driver running properly (unplugging also works OK). With that said, it seems there is some need for improvement, but I also notice you are running this on a virtual machine so could that affect the timeout to kick in before completion. Could you try to increase the timeout. Still when a timeout occurs this needs to be handled properly. Could you also try the following patch? I did a few additional tests: 1. When increasing IOCTL_RESP_TIMEOUT to 2 (ten times the normal value) the timeout and warning still occur. Device/driver doesn't work. 2. When increasing BRCMF_USB_RESET_GETVER_SPINWAIT to 1000 (ten timers the normal value) everything works. Device/driver works. This means the ctl_urb completes on your system within 3sec, but not within 2.1sec. After discussing this with my colleague, we think you should use usb_kill_urb() instead of usb_unlink_urb() as it assures the completion handler is called. Could you retest that and let us know. Regards, Arend 3. Quick test using backports-3.18-rc1-1 (aka unpatched driver) on a non- virtualized Linux install: In that case everything worked fine. So the bug may only be triggered in a virtualized environment / VMWare. 4. When applying your patch, the driver stops early during initialization of the device. I included a WARN_ONCE before returning EINVAL and got the output below. Kind regards, Mathy --- [ 220.955647] usb 1-1: new high-speed USB device number 3 using ehci-pci [ 221.487797] usb 1-1: New USB device found, idVendor=043e, idProduct=3004 [ 221.487802] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 221.487804] usb 1-1: Product: Remote Download Wireless Adapter [ 221.487806] usb 1-1: Manufacturer: Broadcom [ 221.487808] usb 1-1: SerialNumber: 0001 [ 221.490472] brcmfmac: brcmf_usb_probe Enter 0x043e:0x3004 [ 221.490476] brcmfmac: brcmf_usb_probe Broadcom high speed USB WLAN interface detected [ 221.490477] brcmfmac: brcmf_usb_probe_cb Enter [ 221.490480] brcmfmac: brcmf_usb_attach Enter [ 221.490494] brcmfmac: brcmf_usb_dlneeded Enter [ 221.490495] [ cut here ] [ 221.490503] WARNING: CPU: 0 PID: 100 at drivers/net/wireless/brcm80211/brcmfmac/usb.c:716 brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]() [ 221.490505] EINVAL devinfo=c0044000 ctl_rub=ef898380 completed=0 [ 221.490506] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase [ 221.490514] CPU: 0 PID: 100 Comm: kworker/0:1 Not tainted 3.18.0-rc3-wl+ #2 [ 221.490515] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 221.490528] Workqueue: usb_hub_wq hub_event [ 221.490530] eecffb58 c1711f4a eecffb98 eecffb88 c103edaf f11cbc58 [ 221.490534] eecffbb4 0064 f11cbc84 02cc f11c1595 f11c1595 c0044000 ffea [ 221.490537] ef726000 eecffba0 c103ee4e 0009 eecffb98 f11cbc58 eecffbb4 eecffbd0 [ 221.490541] Call Trace: [ 221.490550] [c1711f4a] dump_stack+0x41/0x52 [ 221.490558] [c103edaf] warn_slowpath_common+0x7f/0xa0 [ 221.490563] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490567] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490570] [c103ee4e] warn_slowpath_fmt+0x2e/0x30 [ 221.490575] [f11c1595] brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490580] [f11c2cd8] brcmf_usb_probe+0x3c8/0x640 [brcmfmac] [ 221.490583] [c1717d53] ? mutex_lock+0x13/0x32 [ 221.490586] [c1493ae3] usb_probe_interface+0xa3/0x180 [ 221.490590]
802.11p implementation
Hello everyone, I am working to adapt the ath5k module to transmit in the 5850..5925GHz range, in order to comply with IEEE 802.11p requirements. Our plan is to liberate the code to the community as soon as we develop it. I originally posted this in ath5k-devel mailing list, but someone suggested me to post try here too. I have already compiled a new regdomains database with wireless-regdb and crda, and we are using the module in ATH5K_TEST_CHANNELS mode. The database is now defined as follows: (2402 - 2472 @ 40), (3, 27) (5170 - 5250 @ 40), (3, 17) (5250 - 5330 @ 40), (3, 20) (5490 - 5600 @ 40), (3, 20) (5650 - 5710 @ 40), (3, 20) (5735 - 5835 @ 40), (3, 30) (5835 - 5925 @ 10), (3, 30) - For 802.11P However, when I execute iw wlan1 ibss join TFG 5850 it returns the -22 error number, indicating that we are using a frequency not defined. -- 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: Thinkpad X60s/200s: Intel 3945/5100 works with kernel 2.6.32-67/3.0.0-32 but not 3.7 vanilla.
On Mon, 2014-11-10 at 11:30 +0100, Uwe Brauer wrote: You'd need CONFIG_CFG80211_WEXT (or so) as well, but realistically you Thanks indeed that solved the problem. So I can use ubuntu 10.04+jfs+trim+wireless great! should stop using wireless extensions and use nl80211 (via the iw tool) instead. Thanks but I am not sure whether it will work in Ubuntu 10.04 I am currently using. Uwe -- 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 not working on ECS LIVA
On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel ar...@broadcom.com wrote: On 10-11-14 21:48, Felipe Contreras wrote: /etc/modprobe.d/brcmfmac.conf options brcmfmac debug=0xd416 I see nothing extra in the debug log... Am I doing something wrong? Not sure. You can verify and set the log level through sysfs, ie.: $ cat /sys/module/brcmfmac/parameters/debug 54294 I guess ArchLinux's kernel is missing some configuration option needed for the debugging. -- Felipe Contreras -- 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 not working on ECS LIVA
On 11-11-14 19:32, Felipe Contreras wrote: On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel ar...@broadcom.com wrote: On 10-11-14 21:48, Felipe Contreras wrote: /etc/modprobe.d/brcmfmac.conf options brcmfmac debug=0xd416 I see nothing extra in the debug log... Am I doing something wrong? Not sure. You can verify and set the log level through sysfs, ie.: $ cat /sys/module/brcmfmac/parameters/debug 54294 I guess ArchLinux's kernel is missing some configuration option needed for the debugging. Can you boot the kernel with 'debug ignore_loglevel' on the kernel command line. 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: brcmfmac not working on ECS LIVA
On Tue, Nov 11, 2014 at 12:35 PM, Arend van Spriel ar...@broadcom.com wrote: On 11-11-14 19:32, Felipe Contreras wrote: On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel ar...@broadcom.com wrote: On 10-11-14 21:48, Felipe Contreras wrote: /etc/modprobe.d/brcmfmac.conf options brcmfmac debug=0xd416 I see nothing extra in the debug log... Am I doing something wrong? Not sure. You can verify and set the log level through sysfs, ie.: $ cat /sys/module/brcmfmac/parameters/debug 54294 I guess ArchLinux's kernel is missing some configuration option needed for the debugging. Can you boot the kernel with 'debug ignore_loglevel' on the kernel command line. Yes. I see more systemd messages, nothing extra from brcmfmac. -- Felipe Contreras -- 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 not working on ECS LIVA
On 11/11/14 19:49, Felipe Contreras wrote: On Tue, Nov 11, 2014 at 12:35 PM, Arend van Sprielar...@broadcom.com wrote: On 11-11-14 19:32, Felipe Contreras wrote: On Tue, Nov 11, 2014 at 5:08 AM, Arend van Sprielar...@broadcom.com wrote: On 10-11-14 21:48, Felipe Contreras wrote: /etc/modprobe.d/brcmfmac.conf options brcmfmac debug=0xd416 I see nothing extra in the debug log... Am I doing something wrong? Not sure. You can verify and set the log level through sysfs, ie.: $ cat /sys/module/brcmfmac/parameters/debug 54294 I guess ArchLinux's kernel is missing some configuration option needed for the debugging. Can you boot the kernel with 'debug ignore_loglevel' on the kernel command line. Yes. I see more systemd messages, nothing extra from brcmfmac. Ok. Probably brcmfmac was not built with CONFIG_BRCMDBG. Can you checkout kernel config. 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: brcmfmac not working on ECS LIVA
On Tue, Nov 11, 2014 at 1:10 PM, Arend van Spriel ar...@broadcom.com wrote: On 11/11/14 19:49, Felipe Contreras wrote: On Tue, Nov 11, 2014 at 12:35 PM, Arend van Sprielar...@broadcom.com wrote: On 11-11-14 19:32, Felipe Contreras wrote: On Tue, Nov 11, 2014 at 5:08 AM, Arend van Sprielar...@broadcom.com wrote: On 10-11-14 21:48, Felipe Contreras wrote: /etc/modprobe.d/brcmfmac.conf options brcmfmac debug=0xd416 I see nothing extra in the debug log... Am I doing something wrong? Not sure. You can verify and set the log level through sysfs, ie.: $ cat /sys/module/brcmfmac/parameters/debug 54294 I guess ArchLinux's kernel is missing some configuration option needed for the debugging. Can you boot the kernel with 'debug ignore_loglevel' on the kernel command line. Yes. I see more systemd messages, nothing extra from brcmfmac. Ok. Probably brcmfmac was not built with CONFIG_BRCMDBG. Can you checkout kernel config. That's right; it's not set. I will enable it and rebuild. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: iwlwifi 2014-11-10
On Mon, Nov 10, 2014 at 09:37:16PM -0800, Emmanuel Grumbach wrote: Hi John, This is a pull request for 3.18. More details below. Please pull - thanks! The following changes since commit 31b8b343e019e0a0c57ca9c13520a87f9cab884b: iwlwifi: fix RFkill while calibrating (2014-11-03 15:29:17 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-john-2014-11-10 for you to fetch changes up to 87dd634ae72bb8f6d0dd12f1cbbc67c7da6dba3b: iwlwifi: pcie: fix prph dump length (2014-11-11 07:24:57 +0200) Two fixes here - we weren't updating mac80211 if a scan was cut short by RFKILL which confused cfg80211. As a result, the latter wouldn't allow to run another scan. Liad fixes a small bug in the firmware dump. Emmanuel Grumbach (1): iwlwifi: mvm: abort scan upon RFKILL Liad Kaufman (1): iwlwifi: pcie: fix prph dump length Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ath9k: fix regression in bssidmask calculation
On Tue, Nov 04, 2014 at 03:22:50PM -0800, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com The commit that went into 3.17: ath9k: Summarize hw state per channel context Group and set hw state (opmode, primary_sta, beacon conf) per channel context instead of whole list of vifs. This would allow each channel context to run in different mode (STA/AP). Signed-off-by: Felix Fietkau n...@openwrt.org Signed-off-by: Rajkumar Manoharan rmano...@qti.qualcomm.com Signed-off-by: John W. Linville linvi...@tuxdriver.com broke multi-vif configuration due to not properly calculating the bssid mask. The test case that caught this was: create wlan0 and sta0-4 (6 total), not sure how much that matters. associate all 6 (works fine) disconnect 5 of them, leaving sta0 up Start trying to bring up the other 5 one at a time. It will fail, with iw events looking like this (in these logs, several sta are trying to come up, but symptom is the same with just one) The patch causing the regression made quite a few changes, but the part I think caused this particular problem was not recalculating the bssid mask when adding and removing interfaces. Re-adding those calls fixes my test case. Fix bad comment as well. Signed-off-by: Ben Greear gree...@candelatech.com --- This needs to be reviewed by ath9k driver folks that added the original patch, at least. Any word from the ath9k posse? And, should be considered for 3.17 stable if fix is accepted upstream. drivers/net/wireless/ath/ath9k/main.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index fbf23ac..d2ad9e95 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c @@ -947,9 +947,8 @@ void ath9k_calculate_iter_data(struct ath_softc *sc, struct ath_vif *avp; /* - * Pick the MAC address of the first interface as the new hardware - * MAC address. The hardware will use it together with the BSSID mask - * when matching addresses. + * The hardware will use primary station addr together with the + * BSSID mask when matching addresses. */ memset(iter_data, 0, sizeof(*iter_data)); memset(iter_data-mask, 0xff, ETH_ALEN); @@ -1169,6 +1168,8 @@ static int ath9k_add_interface(struct ieee80211_hw *hw, list_add_tail(avp-list, avp-chanctx-vifs); } + ath9k_calculate_summary_state(sc, avp-chanctx); + ath9k_assign_hw_queues(hw, vif); an-sc = sc; @@ -1238,6 +1239,8 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw, ath_tx_node_cleanup(sc, avp-mcast_node); + ath9k_calculate_summary_state(sc, avp-chanctx); + mutex_unlock(sc-mutex); } -- 1.9.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 -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: bluetooth-next 2014-11-07
On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote: Hi John Here's another set of patches for 3.19. Most of it is again fixes and cleanups to ieee802154 related code from Alexander Aring. We've also got better handling of hardware error events along with a proper API for HCI drivers to notify the HCI core of such situations. There's also a minor fix for mgmt events as well as a sparse warning fix. The code for sending HCI commands synchronously also gets a fix where we might loose the completion event in the case of very fast HW (particularly easily reproducible with an emulated HCI device). Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 6bc6c49f1e2f3ab1bec05d1c08aad219ab4eb5d0: mwifiex: add cfg80211 dump_survey handler (2014-10-31 16:07:49 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 56b2c3eea398c772dd895dc62c18cbdd1ba127b1: 6lowpan: move skb_free from error paths in decompression (2014-11-06 22:09:48 +0100) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcmfmac not working on ECS LIVA
On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel ar...@broadcom.com wrote: Could you share the nvram obtained from EFI? Also please create a kernel log with debug=0xd416. There you go: http://people.freedesktop.org/~felipec/dmesg-brcm.txt -- Felipe Contreras -- 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: remove return of value in empty definintion of ath9k_htc_deinit_debug
Cc: Oleksij Rempel li...@rempel-privat.de
Signed-off-by: John W. Linville linvi...@tuxdriver.com
---
drivers/net/wireless/ath/ath9k/htc.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index b34acdeb1f21..9dde265d3f84 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -629,7 +629,9 @@ int ath9k_htc_init_debug(struct ath_hw *ah);
void ath9k_htc_deinit_debug(struct ath9k_htc_priv *priv);
#else
static inline int ath9k_htc_init_debug(struct ath_hw *ah) { return 0; };
-static inline void ath9k_htc_deinit_debug(struct ath9k_htc_priv *priv) {
return 0; };
+static inline void ath9k_htc_deinit_debug(struct ath9k_htc_priv *priv)
+{
+}
#endif /* CONFIG_ATH9K_HTC_DEBUGFS */
#endif /* HTC_H */
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] make spectral code common for both ath9k drivers
Oleksij Rempel wrote: - makes spectral scan code common for both ath9k and ath9k_htc. - add spectral scan support to ath9k_htc. The ath9k changes look good... Sujith -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] brcmfmac: unlink URB when request timed out
On 11/11/2014 01:00 PM, Arend van Spriel wrote: On 11-11-14 18:35, Mathy Vanhoef wrote: Using usb_kill_urb() instead of usb_unlink_urb() seems to work without any problems. Ok, as usb_kill_urb() assures the completion handler is called there is no need to check the ctl_completed flag, ie. my patch. Go ahead and resubmit your patch replacing usb_unlink_urb() by usb_kill_urb(). Do you mean you end up with a working usb device providing a wireless interface? Or does probe still fail, but you do not get a crash. I end up with a working device which can connect to networks. Kind regards, Mathy Regards, Arend On 11/11/2014 06:05 AM, Arend van Spriel wrote: On 10-11-14 17:08, Mathy Vanhoef wrote: On 11/10/2014 06:18 AM, Arend van Spriel wrote: On 09-11-14 19:10, Mathy Vanhoef wrote: From: Mathy Vanhoef vanho...@gmail.com Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This assures the URB is never submitted twice, preventing a driver crash. Hi Mathy, What driver crash are you referring to? The log only shows the WARNING ending in a USB disconnect but no actual crash. Does your patch get the driver running properly or does it only avoid the warning. Hi Arend, It shows a warning, after which the device doesn't work (but the computer is still usable). But I've noticed that when *unplugging* the USB cable the OS may freeze. This doesn't always happen though, sometimes unplugging works OK. The patch both avoids the warning, and gets the device/driver running properly (unplugging also works OK). With that said, it seems there is some need for improvement, but I also notice you are running this on a virtual machine so could that affect the timeout to kick in before completion. Could you try to increase the timeout. Still when a timeout occurs this needs to be handled properly. Could you also try the following patch? I did a few additional tests: 1. When increasing IOCTL_RESP_TIMEOUT to 2 (ten times the normal value) the timeout and warning still occur. Device/driver doesn't work. 2. When increasing BRCMF_USB_RESET_GETVER_SPINWAIT to 1000 (ten timers the normal value) everything works. Device/driver works. This means the ctl_urb completes on your system within 3sec, but not within 2.1sec. After discussing this with my colleague, we think you should use usb_kill_urb() instead of usb_unlink_urb() as it assures the completion handler is called. Could you retest that and let us know. Regards, Arend 3. Quick test using backports-3.18-rc1-1 (aka unpatched driver) on a non- virtualized Linux install: In that case everything worked fine. So the bug may only be triggered in a virtualized environment / VMWare. 4. When applying your patch, the driver stops early during initialization of the device. I included a WARN_ONCE before returning EINVAL and got the output below. Kind regards, Mathy --- [ 220.955647] usb 1-1: new high-speed USB device number 3 using ehci-pci [ 221.487797] usb 1-1: New USB device found, idVendor=043e, idProduct=3004 [ 221.487802] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 221.487804] usb 1-1: Product: Remote Download Wireless Adapter [ 221.487806] usb 1-1: Manufacturer: Broadcom [ 221.487808] usb 1-1: SerialNumber: 0001 [ 221.490472] brcmfmac: brcmf_usb_probe Enter 0x043e:0x3004 [ 221.490476] brcmfmac: brcmf_usb_probe Broadcom high speed USB WLAN interface detected [ 221.490477] brcmfmac: brcmf_usb_probe_cb Enter [ 221.490480] brcmfmac: brcmf_usb_attach Enter [ 221.490494] brcmfmac: brcmf_usb_dlneeded Enter [ 221.490495] [ cut here ] [ 221.490503] WARNING: CPU: 0 PID: 100 at drivers/net/wireless/brcm80211/brcmfmac/usb.c:716 brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]() [ 221.490505] EINVAL devinfo=c0044000 ctl_rub=ef898380 completed=0 [ 221.490506] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase [ 221.490514] CPU: 0 PID: 100 Comm: kworker/0:1 Not tainted 3.18.0-rc3-wl+ #2 [ 221.490515] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 221.490528] Workqueue: usb_hub_wq hub_event [ 221.490530] eecffb58 c1711f4a eecffb98 eecffb88 c103edaf f11cbc58 [ 221.490534] eecffbb4 0064 f11cbc84 02cc f11c1595 f11c1595 c0044000 ffea [ 221.490537] ef726000 eecffba0 c103ee4e 0009 eecffb98 f11cbc58 eecffbb4 eecffbd0 [ 221.490541] Call Trace: [ 221.490550] [c1711f4a] dump_stack+0x41/0x52 [ 221.490558] [c103edaf] warn_slowpath_common+0x7f/0xa0 [ 221.490563] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490567] [f11c1595] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490570] [c103ee4e] warn_slowpath_fmt+0x2e/0x30 [ 221.490575] [f11c1595] brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac] [ 221.490580] [f11c2cd8]
Re: [PATCH] brcmfmac: unlink URB when request timed out
On 11/10/2014 04:08 AM, Oliver Neukum wrote:
On Sun, 2014-11-09 at 13:10 -0500, Mathy Vanhoef wrote:
From: Mathy Vanhoef vanho...@gmail.com
Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
assures the URB is never submitted twice, preventing a driver crash.
Hi,
I am afrad this patch is no good. The diagnosis is good,
but the fix introduces serious problems.
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index 5265aa7..1bc7858 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info
*devinfo, u8 cmd,
goto finalize;
}
- if (!brcmf_usb_ioctl_resp_wait(devinfo))
+ if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
+ usb_unlink_urb(devinfo-ctl_urb);
This is the asynchronous unlink. You have no guarantee it is finished
after this point.
ret = -ETIMEDOUT;
- else
+ } else {
memcpy(buffer, tmpbuf, buflen);
+ }
finalize:
kfree(tmpbuf);
Which means that you are freeing memory that may still be used by DMA
at this time.
In addition you have no guarantee that the unlink is indeed finished
by the time the URB is reused.
If you wish to take this approach you better forget about this URB
and allocate a new one and free the buffer from the callback.
Hi Oliver,
Good catch. I think the DMA issue is also present in the current driver: it
frees the buffer without unlinking/killing the URB at all. Can a malicious USB
device force a timeout to occur (i.e. delay the call to the completion
handler)? If so this might be a use-after-free vulnerability.
It seems using usb_kill_urb instead of usb_unlink_urb in the patch prevents any
possible use-after-free. Can someone double check?
Kind regards,
Mathy
Regards
Oliver
--
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/6] ath9k: Fix high tx power in multi-chain mode
ah-caps.tx_chainmask is read from eeprom, e.g ath9k_hw_fill_cap_info(): pCap-tx_chainmask = ah-eep_ops-get_eeprom(ah, EEP_TX_MASK); Sujith, the issue was found on ap143(QCA9531, 11n, 2x2), reported by Korea team. They want to make ap143 to work on 1x2 or 2x2 mode. You can also find the changes on 10.2(ar9300_thermometer_apply). Miaoqing -Original Message- From: Sujith Manoharan [mailto:suj...@msujith.org] Sent: Wednesday, November 12, 2014 7:38 AM To: n...@openwrt.org Cc: Pan, Miaoqing; John Linville; linux-wireless@vger.kernel.org; ath9k-devel Subject: Re: [PATCH 4/6] ath9k: Fix high tx power in multi-chain mode Felix Fietkau wrote: That doesn't seem right to me. ah-caps.tx_chainmask is not altered based on software antenna configuration. Yes, that's true. Miaoqing, can you clarify ? Should the thermometer for chain 1 be enabled even though the HW caps contain 0x1 as TX chainmask, for example ? Are there such boards ? Sujith -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.14 142/203] wireless: rt2x00: add new rt2800usb devices
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Xose Vazquez Perez xose.vazq...@gmail.com
commit 6a06e554daef86c4e8d290284927b081fedb249e upstream.
0x0b05 0x17e8 RT5372 USB 2.0 bgn 2x2 ASUS USB-N14
0x0411 0x0253 RT5572 USB 2.0 abgn 2x2 BUFFALO WLP-U2-300D
0x0df6 0x0078 RT Sitecom N300
Cc: Ivo van Doorn ivdo...@gmail.com
Cc: Helmut Schaa helmut.sc...@googlemail.com
Cc: John W. Linville linvi...@tuxdriver.com
Cc: us...@rt2x00.serialmonkey.com
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Xose Vazquez Perez xose.vazq...@gmail.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/net/wireless/rt2x00/rt2800usb.c |4
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1235,6 +1235,8 @@ static struct usb_device_id rt2800usb_de
/* Arcadyan */
{ USB_DEVICE(0x043e, 0x7a12) },
{ USB_DEVICE(0x043e, 0x7a32) },
+ /* ASUS */
+ { USB_DEVICE(0x0b05, 0x17e8) },
/* Azurewave */
{ USB_DEVICE(0x13d3, 0x3329) },
{ USB_DEVICE(0x13d3, 0x3365) },
@@ -1271,6 +1273,7 @@ static struct usb_device_id rt2800usb_de
{ USB_DEVICE(0x057c, 0x8501) },
/* Buffalo */
{ USB_DEVICE(0x0411, 0x0241) },
+ { USB_DEVICE(0x0411, 0x0253) },
/* D-Link */
{ USB_DEVICE(0x2001, 0x3c1a) },
{ USB_DEVICE(0x2001, 0x3c21) },
@@ -1361,6 +1364,7 @@ static struct usb_device_id rt2800usb_de
{ USB_DEVICE(0x0df6, 0x0053) },
{ USB_DEVICE(0x0df6, 0x0069) },
{ USB_DEVICE(0x0df6, 0x006f) },
+ { USB_DEVICE(0x0df6, 0x0078) },
/* SMC */
{ USB_DEVICE(0x083a, 0xa512) },
{ USB_DEVICE(0x083a, 0xc522) },
--
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/6] ath9k: Fix high tx power in multi-chain mode
Pan, Miaoqing wrote: the issue was found on ap143(QCA9531, 11n, 2x2), reported by Korea team. They want to make ap143 to work on 1x2 or 2x2 mode. Ok, so apparently there are boards that are 2x2 in the HW, but the tx chainmask is set as 1 in the eeprom. In such cases, the thermometer has to be enabled for both the chains. So, I think we need this fix. Sujith -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] make spectral code common for both ath9k drivers
Am 12.11.2014 um 01:10 schrieb Sujith Manoharan:
Oleksij Rempel wrote:
- makes spectral scan code common for both ath9k and ath9k_htc.
- add spectral scan support to ath9k_htc.
This has been merged, but I am getting a build error.
../drivers/net/wireless/ath/ath9k/common-spectral.c:40:5: error: redefinition
of ‘ath_cmn_process_fft’
int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, struct
ieee80211_hdr *hdr,
^
In file included from ../drivers/net/wireless/ath/ath9k/common.h:27:0,
from ../drivers/net/wireless/ath/ath9k/ath9k.h:27,
from ../drivers/net/wireless/ath/ath9k/common-spectral.c:18:
../drivers/net/wireless/ath/ath9k/common-spectral.h:146:19: note: previous
definition of ‘ath_cmn_process_fft’ was here
static inline int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv,
^
../scripts/Makefile.build:257: recipe for target
'drivers/net/wireless/ath/ath9k/common-spectral.o' failed
make[10]: *** [drivers/net/wireless/ath/ath9k/common-spectral.o] Error 1
make[10]: *** Waiting for unfinished jobs
CC [M] drivers/target/iscsi/iscsi_target_erl0.o
CC drivers/thermal/thermal_core.o
In file included from ../drivers/net/wireless/ath/ath9k/htc_hst.c:19:0:
../drivers/net/wireless/ath/ath9k/htc.h: In function ‘ath9k_htc_deinit_debug’:
../drivers/net/wireless/ath/ath9k/htc.h:632:74: warning: ‘return’ with a
value, in function returning void
static inline void ath9k_htc_deinit_debug(struct ath9k_htc_priv *priv) {
return 0; };
^
../scripts/Makefile.build:402: recipe for target
'drivers/net/wireless/ath/ath9k' failed
make[9]: *** [drivers/net/wireless/ath/ath9k] Error 2
../scripts/Makefile.build:402: recipe for target 'drivers/net/wireless/ath'
failed
make[8]: *** [drivers/net/wireless/ath] Error 2
make[8]: *** Waiting for unfinished jobs
Hi,
thank you for testing.
John already provided patch for this.
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
[PATCH] iwlwifi: dvm: Implement sta_rc_update() mac80211 callback
Perform rate scaling properly when operating in an IBSS. Prior to
this, the 5300 and 6205 devices (at least) would only transmit at
1 Mbps to other stations in an IBSS. This now allows transmission
at HT rates.
Signed-off-by: David Ward david.w...@ll.mit.edu
---
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
index 47e64e8..742218d 100644
--- a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
@@ -940,6 +940,22 @@ static int iwlagn_mac_sta_state(struct ieee80211_hw *hw,
return ret;
}
+static void iwlagn_mac_sta_rc_update(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif,
+struct ieee80211_sta *sta, u32 changed)
+{
+ struct iwl_priv *priv = IWL_MAC80211_GET_DVM(hw);
+
+ if (!(changed IEEE80211_RC_SUPP_RATES_CHANGED))
+ return;
+
+ /* Update rate scaling */
+ IWL_DEBUG_INFO(priv,
+ Updating rate scaling for station %pM\n,
+ sta-addr);
+ iwl_rs_rate_init(priv, sta, iwl_sta_id(sta));
+}
+
static void iwlagn_mac_channel_switch(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_channel_switch
*ch_switch)
@@ -1610,6 +1626,7 @@ const struct ieee80211_ops iwlagn_hw_ops = {
.hw_scan = iwlagn_mac_hw_scan,
.sta_notify = iwlagn_mac_sta_notify,
.sta_state = iwlagn_mac_sta_state,
+ .sta_rc_update = iwlagn_mac_sta_rc_update,
.channel_switch = iwlagn_mac_channel_switch,
.flush = iwlagn_mac_flush,
.tx_last_beacon = iwlagn_mac_tx_last_beacon,
--
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: Thinkpad X60s/200s: Intel 3945/5100 works with kernel 2.6.32-67/3.0.0-32 but not 3.7 vanilla.
On Wed, Nov 12, 2014 at 8:25 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Nov 11, 2014 at 7:31 PM, Uwe Brauer o...@mat.ucm.es wrote: On Mon, 2014-11-10 at 11:30 +0100, Uwe Brauer wrote: You'd need CONFIG_CFG80211_WEXT (or so) as well, but realistically you Thanks indeed that solved the problem. So I can use ubuntu 10.04+jfs+trim+wireless great! should stop using wireless extensions and use nl80211 (via the iw tool) instead. Thanks but I am not sure whether it will work in Ubuntu 10.04 I am currently using. [ To answer myself... ] Is 10.04 an LTS version (means support till 2015)? Yupp (see below). Might be there exist some 3rd party or the $-backports which will have an iw package. » Ubuntu » Packages » lucid (10.04LTS) » net » iw iw (0.9.19~ubuntu1) [universe] --- Activate universe! http://packages.ubuntu.com/lucid/iw - Sedat - -- 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: common-spectral: don't depend from ATH9K_DEBUGFS
we can have here two variants. Add
ATH9K_CMN_DEBUGFS y if ATH9K_CMN_DEBUGFS || ATH9K_HTC_DEBUGFS
wich will add more configurations and testcases. Or remove ATH9K_HTC_DEBUGFS
which need more time to be done.
So, make common-spectral ignore ATH9K_DEBUGFS option for now.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/common-spectral.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.h
b/drivers/net/wireless/ath/ath9k/common-spectral.h
index 214c3ba..82d9dd2 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.h
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.h
@@ -138,17 +138,7 @@ void ath9k_cmn_spectral_scan_trigger(struct ath_common
*common,
int ath9k_cmn_spectral_scan_config(struct ath_common *common,
struct ath_spec_scan_priv *spec_priv,
enum spectral_mode spectral_mode);
-
-#ifdef CONFIG_ATH9K_DEBUGFS
int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, struct
ieee80211_hdr *hdr,
struct ath_rx_status *rs, u64 tsf);
-#else
-static inline int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv,
- struct ieee80211_hdr *hdr,
- struct ath_rx_status *rs, u64 tsf)
-{
- return 0;
-}
-#endif /* CONFIG_ATH9K_DEBUGFS */
#endif /* SPECTRAL_H */
--
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 2/2] ath9k: fix regression in bssidmask calculation
John W. Linville wrote: Any word from the ath9k posse? Looks good to me... Sujith -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
