Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?
On Fri, Nov 14, 2014 at 03:57:40PM +0900, Marcel Holtmann wrote: Hi Luca, I've updated wireless code on RHEL and get complain that now cfg80211 and rfkill modules are loaded on machines that do not have wireless hardware. Modules are auto-loaded because NetworkManager send nl80211 messages to check if there are wireless devices in the system. Hence my question, can we revert commit fb4e156886ce nl80211: Add generic netlink module alias for cfg80211/nl80211 ? Realistically, we can't revert it, but only remove the MODULE_ALIAS_GENL_FAMILY() line. Auto loading nl80211 does not seems to be necessary, if there are wireless devices nl80211 will be loaded anyway. Maybe other applications would like to see an empty list of devices? But OTOH, if they're robust at all, they have to cope with kernels not even compiled with nl80211, so I guess for me I don't really see a big difference in whether the module alias exists or not. auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things. Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded. NM uses nl80211 initially to determine whether *any* ethernet-type interface (a) is actually WiFi, and (b) should be driven by nl80211 or WEXT. Because of the variety of drivers (both in-kernel and out-of-kernel) and the variety of kernel versions (NM supports back to early 3.x series) we cannot rely on specific behavior. So given an ethernet-type interface, how do we determine that it is wifi? DEVTYPE=wlan - not always reliable due to driver and kernel versions phy80211 in sysfs: same reason; also doesn't capture WEXT or out-of-tree drivers nl80211 calls: this is the only 100% reliable mechanism to detect whether an ethernet-type interface is actually WiFi and nl80211-capable. And unfortunately calling nl80211 loads the module... So, basically the conclusion is: there's no way around it. If someone in userspace uses nl80211 it must be loaded, regardless of whether nl80211 is automatically loaded or if depmod bring it in. yes, that is how it should be. And actually that is how every other subsystem does. Including modules that get loaded because we have a socket() system call for an address family. On other subsystems auto loading make sense. For example on netfiler, we really want to load netfiler modules when user-space want to configure it and started talking to it by socket. But here situation is different. If there is no hardware we can not configure it. 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: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?
On Fri, Nov 14, 2014 at 04:02:33PM +0900, Marcel Holtmann wrote: Hi Dan, I've updated wireless code on RHEL and get complain that now cfg80211 and rfkill modules are loaded on machines that do not have wireless hardware. Modules are auto-loaded because NetworkManager send nl80211 messages to check if there are wireless devices in the system. Hence my question, can we revert commit fb4e156886ce nl80211: Add generic netlink module alias for cfg80211/nl80211 ? Realistically, we can't revert it, but only remove the MODULE_ALIAS_GENL_FAMILY() line. Auto loading nl80211 does not seems to be necessary, if there are wireless devices nl80211 will be loaded anyway. Maybe other applications would like to see an empty list of devices? But OTOH, if they're robust at all, they have to cope with kernels not even compiled with nl80211, so I guess for me I don't really see a big difference in whether the module alias exists or not. auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things. Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded. NM uses nl80211 initially to determine whether *any* ethernet-type interface (a) is actually WiFi, and (b) should be driven by nl80211 or WEXT. Because of the variety of drivers (both in-kernel and out-of-kernel) and the variety of kernel versions (NM supports back to early 3.x series) we cannot rely on specific behavior. So given an ethernet-type interface, how do we determine that it is wifi? DEVTYPE=wlan - not always reliable due to driver and kernel versions if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug. NM can be run with older kernel versions, which does not have DEVTYPE=wlan. I guess NM could check the kernel version and don't use nl80211 if kernel is sufficiency modern. phy80211 in sysfs: same reason; also doesn't capture WEXT or out-of-tree drivers nl80211 calls: this is the only 100% reliable mechanism to detect whether an ethernet-type interface is actually WiFi and nl80211-capable. And unfortunately calling nl80211 loads the module... So be it then, the cfg80211 modules gets loaded. People have to live with that. It's 700k of kernel memory. People running many instances of guest OS with this module loaded are quite unhappy. And just to be clear, this is not a kernel bug. Exposing the correct module alias for its netlink family is what the module should be doing. This is not a kernel bug, but not having the alias is also not a kernel bug :-) 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] ath9k_htc: turn on software mgmt crypto for secured mesh
Am 14.11.2014 um 06:07 schrieb Chun-Yeow Yeoh:
Secured mesh encrypts the unicast mgmt frame using the same
key that used for encrypting the unicast data frame. The patch
ath9k_htc_firmware: fix the offset of CCMP header for mesh
data frame applied to open-ath9k-htc-firmware allows the
ath9k_htc to be loaded without nohwcrypt=1. Unfortunately,
this is not working and we still need CCMP encryption of
management frames to be done in software. Fix this.
This patch is tested with the following hardwares:
- TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
- AR9271 802.11n
and managed to work with peer mesh STA equipped with ath9k.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 689ac99..d3f65a2 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1447,7 +1447,8 @@ static int ath9k_htc_set_key(struct ieee80211_hw *hw,
key-flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
if (key-cipher == WLAN_CIPHER_SUITE_TKIP)
key-flags |= IEEE80211_KEY_FLAG_GENERATE_MMIC;
- if (priv-ah-sw_mgmt_crypto
+ if ((vif-type == NL80211_IFTYPE_MESH_POINT ||
+ priv-ah-sw_mgmt_crypto)
key-cipher == WLAN_CIPHER_SUITE_CCMP)
key-flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
ret = 0;
Hmm.. may be we should generally do it here:
if ((vif-type == NL80211_IFTYPE_ADHOC ||
vif-type == NL80211_IFTYPE_MESH_POINT)
(key-cipher == WLAN_CIPHER_SUITE_TKIP ||
key-cipher == WLAN_CIPHER_SUITE_CCMP)
!(key-flags IEEE80211_KEY_FLAG_PAIRWISE)) {
or probably set sw_mgmt_crypto = true in ath9k_hw_init_mfp() for all
usb devices?
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] brcmfmac: kill URB when request timed out
On 13-11-14 03:33, Mathy Vanhoef wrote:
Kill the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
assures the URB is never submitted twice. It also prevents a possible
use-after-free of the URB transfer buffer if a timeout occurs.
Acked-by: Arend van Spriel ar...@broadcom.com
Signed-off-by: Mathy Vanhoef vanho...@gmail.com
---
For a discussion about this patch and the underlying problem, see the mails
with as subject [PATCH] brcmfmac: unlink URB when request timed out.
drivers/net/wireless/brcm80211/brcmfmac/usb.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index 5265aa7..4572def 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_kill_urb(devinfo-ctl_urb);
ret = -ETIMEDOUT;
- else
+ } else {
memcpy(buffer, tmpbuf, buflen);
+ }
finalize:
kfree(tmpbuf);
--
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] ath9k_htc: turn on software mgmt crypto for secured mesh
On Fri, Nov 14, 2014 at 4:54 PM, Oleksij Rempel li...@rempel-privat.de wrote:
Am 14.11.2014 um 06:07 schrieb Chun-Yeow Yeoh:
Secured mesh encrypts the unicast mgmt frame using the same
key that used for encrypting the unicast data frame. The patch
ath9k_htc_firmware: fix the offset of CCMP header for mesh
data frame applied to open-ath9k-htc-firmware allows the
ath9k_htc to be loaded without nohwcrypt=1. Unfortunately,
this is not working and we still need CCMP encryption of
management frames to be done in software. Fix this.
This patch is tested with the following hardwares:
- TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
- AR9271 802.11n
and managed to work with peer mesh STA equipped with ath9k.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 689ac99..d3f65a2 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1447,7 +1447,8 @@ static int ath9k_htc_set_key(struct ieee80211_hw *hw,
key-flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
if (key-cipher == WLAN_CIPHER_SUITE_TKIP)
key-flags |= IEEE80211_KEY_FLAG_GENERATE_MMIC;
- if (priv-ah-sw_mgmt_crypto
+ if ((vif-type == NL80211_IFTYPE_MESH_POINT ||
+ priv-ah-sw_mgmt_crypto)
key-cipher == WLAN_CIPHER_SUITE_CCMP)
key-flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
ret = 0;
Hmm.. may be we should generally do it here:
if ((vif-type == NL80211_IFTYPE_ADHOC ||
vif-type == NL80211_IFTYPE_MESH_POINT)
(key-cipher == WLAN_CIPHER_SUITE_TKIP ||
key-cipher == WLAN_CIPHER_SUITE_CCMP)
!(key-flags IEEE80211_KEY_FLAG_PAIRWISE)) {
Not so sure doing here is correctly. It is a pairwise key for unicast
management frame, right?
or probably set sw_mgmt_crypto = true in ath9k_hw_init_mfp() for all
usb devices?
All ath9k USB devices don't have MFP support?
---
ChunYeow
--
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] ath9k_htc: turn on software mgmt crypto for secured mesh
Hi, Oleksij Rpel
If we do it in ath9k_hw_init_mfp, these MAC version are related to USB devices:
AR_SREV_VERSION_9271
AR_SREV_VERSION_9280
AR_SREV_VERSION_9287
Right?
ChunYeow
On Fri, Nov 14, 2014 at 5:06 PM, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote:
On Fri, Nov 14, 2014 at 4:54 PM, Oleksij Rempel li...@rempel-privat.de
wrote:
Am 14.11.2014 um 06:07 schrieb Chun-Yeow Yeoh:
Secured mesh encrypts the unicast mgmt frame using the same
key that used for encrypting the unicast data frame. The patch
ath9k_htc_firmware: fix the offset of CCMP header for mesh
data frame applied to open-ath9k-htc-firmware allows the
ath9k_htc to be loaded without nohwcrypt=1. Unfortunately,
this is not working and we still need CCMP encryption of
management frames to be done in software. Fix this.
This patch is tested with the following hardwares:
- TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
- AR9271 802.11n
and managed to work with peer mesh STA equipped with ath9k.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 689ac99..d3f65a2 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1447,7 +1447,8 @@ static int ath9k_htc_set_key(struct ieee80211_hw *hw,
key-flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
if (key-cipher == WLAN_CIPHER_SUITE_TKIP)
key-flags |=
IEEE80211_KEY_FLAG_GENERATE_MMIC;
- if (priv-ah-sw_mgmt_crypto
+ if ((vif-type == NL80211_IFTYPE_MESH_POINT ||
+ priv-ah-sw_mgmt_crypto)
key-cipher == WLAN_CIPHER_SUITE_CCMP)
key-flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
ret = 0;
Hmm.. may be we should generally do it here:
if ((vif-type == NL80211_IFTYPE_ADHOC ||
vif-type == NL80211_IFTYPE_MESH_POINT)
(key-cipher == WLAN_CIPHER_SUITE_TKIP ||
key-cipher == WLAN_CIPHER_SUITE_CCMP)
!(key-flags IEEE80211_KEY_FLAG_PAIRWISE)) {
Not so sure doing here is correctly. It is a pairwise key for unicast
management frame, right?
or probably set sw_mgmt_crypto = true in ath9k_hw_init_mfp() for all
usb devices?
All ath9k USB devices don't have MFP support?
---
ChunYeow
--
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] ath9k_htc: turn on software mgmt crypto for secured mesh
Am 14.11.2014 um 10:06 schrieb Yeoh Chun-Yeow:
On Fri, Nov 14, 2014 at 4:54 PM, Oleksij Rempel li...@rempel-privat.de
wrote:
Am 14.11.2014 um 06:07 schrieb Chun-Yeow Yeoh:
Secured mesh encrypts the unicast mgmt frame using the same
key that used for encrypting the unicast data frame. The patch
ath9k_htc_firmware: fix the offset of CCMP header for mesh
data frame applied to open-ath9k-htc-firmware allows the
ath9k_htc to be loaded without nohwcrypt=1. Unfortunately,
this is not working and we still need CCMP encryption of
management frames to be done in software. Fix this.
This patch is tested with the following hardwares:
- TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
- AR9271 802.11n
and managed to work with peer mesh STA equipped with ath9k.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 689ac99..d3f65a2 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1447,7 +1447,8 @@ static int ath9k_htc_set_key(struct ieee80211_hw *hw,
key-flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
if (key-cipher == WLAN_CIPHER_SUITE_TKIP)
key-flags |=
IEEE80211_KEY_FLAG_GENERATE_MMIC;
- if (priv-ah-sw_mgmt_crypto
+ if ((vif-type == NL80211_IFTYPE_MESH_POINT ||
+ priv-ah-sw_mgmt_crypto)
key-cipher == WLAN_CIPHER_SUITE_CCMP)
key-flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
ret = 0;
Hmm.. may be we should generally do it here:
if ((vif-type == NL80211_IFTYPE_ADHOC ||
vif-type == NL80211_IFTYPE_MESH_POINT)
(key-cipher == WLAN_CIPHER_SUITE_TKIP ||
key-cipher == WLAN_CIPHER_SUITE_CCMP)
!(key-flags IEEE80211_KEY_FLAG_PAIRWISE)) {
Not so sure doing here is correctly. It is a pairwise key for unicast
management frame, right?
yes.
this code is identical to ath9k, so i will move it to common. This is
the reason of my doubts.
or probably set sw_mgmt_crypto = true in ath9k_hw_init_mfp() for all
usb devices?
All ath9k USB devices don't have MFP support?
Hmm... do you have docs?
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ath9k_htc: turn on software mgmt crypto for secured mesh
Unfortunately, I don't have any docs for this. Any others?
---
ChunYeow
On Fri, Nov 14, 2014 at 5:57 PM, Oleksij Rempel li...@rempel-privat.de wrote:
Am 14.11.2014 um 10:06 schrieb Yeoh Chun-Yeow:
On Fri, Nov 14, 2014 at 4:54 PM, Oleksij Rempel li...@rempel-privat.de
wrote:
Am 14.11.2014 um 06:07 schrieb Chun-Yeow Yeoh:
Secured mesh encrypts the unicast mgmt frame using the same
key that used for encrypting the unicast data frame. The patch
ath9k_htc_firmware: fix the offset of CCMP header for mesh
data frame applied to open-ath9k-htc-firmware allows the
ath9k_htc to be loaded without nohwcrypt=1. Unfortunately,
this is not working and we still need CCMP encryption of
management frames to be done in software. Fix this.
This patch is tested with the following hardwares:
- TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
- AR9271 802.11n
and managed to work with peer mesh STA equipped with ath9k.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 689ac99..d3f65a2 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1447,7 +1447,8 @@ static int ath9k_htc_set_key(struct ieee80211_hw *hw,
key-flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
if (key-cipher == WLAN_CIPHER_SUITE_TKIP)
key-flags |=
IEEE80211_KEY_FLAG_GENERATE_MMIC;
- if (priv-ah-sw_mgmt_crypto
+ if ((vif-type == NL80211_IFTYPE_MESH_POINT ||
+ priv-ah-sw_mgmt_crypto)
key-cipher == WLAN_CIPHER_SUITE_CCMP)
key-flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
ret = 0;
Hmm.. may be we should generally do it here:
if ((vif-type == NL80211_IFTYPE_ADHOC ||
vif-type == NL80211_IFTYPE_MESH_POINT)
(key-cipher == WLAN_CIPHER_SUITE_TKIP ||
key-cipher == WLAN_CIPHER_SUITE_CCMP)
!(key-flags IEEE80211_KEY_FLAG_PAIRWISE)) {
Not so sure doing here is correctly. It is a pairwise key for unicast
management frame, right?
yes.
this code is identical to ath9k, so i will move it to common. This is
the reason of my doubts.
or probably set sw_mgmt_crypto = true in ath9k_hw_init_mfp() for all
usb devices?
All ath9k USB devices don't have MFP support?
Hmm... do you have docs?
--
Regards,
Oleksij
--
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] ath9k_htc: turn on software mgmt crypto for secured mesh
On Fri, Nov 14, 2014 at 5:51 PM, Oleksij Rempel li...@rempel-privat.de wrote:
Am 14.11.2014 um 10:18 schrieb Yeoh Chun-Yeow:
Hi, Oleksij Rpel
If we do it in ath9k_hw_init_mfp, these MAC version are related to USB
devices:
AR_SREV_VERSION_9271
AR_SREV_VERSION_9280
AR_SREV_VERSION_9287
Right?
yes. ar9271 with usb interface. ar9280 and ar9287 are pcie attached to
ar7010 cpu.
Alright, I will work out the patch using ath9k_hw_init_mfp.
---
ChunYeow
ChunYeow
On Fri, Nov 14, 2014 at 5:06 PM, Yeoh Chun-Yeow yeohchuny...@gmail.com
wrote:
On Fri, Nov 14, 2014 at 4:54 PM, Oleksij Rempel li...@rempel-privat.de
wrote:
Am 14.11.2014 um 06:07 schrieb Chun-Yeow Yeoh:
Secured mesh encrypts the unicast mgmt frame using the same
key that used for encrypting the unicast data frame. The patch
ath9k_htc_firmware: fix the offset of CCMP header for mesh
data frame applied to open-ath9k-htc-firmware allows the
ath9k_htc to be loaded without nohwcrypt=1. Unfortunately,
this is not working and we still need CCMP encryption of
management frames to be done in software. Fix this.
This patch is tested with the following hardwares:
- TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
- AR9271 802.11n
and managed to work with peer mesh STA equipped with ath9k.
Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 689ac99..d3f65a2 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1447,7 +1447,8 @@ static int ath9k_htc_set_key(struct ieee80211_hw
*hw,
key-flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
if (key-cipher == WLAN_CIPHER_SUITE_TKIP)
key-flags |=
IEEE80211_KEY_FLAG_GENERATE_MMIC;
- if (priv-ah-sw_mgmt_crypto
+ if ((vif-type == NL80211_IFTYPE_MESH_POINT ||
+ priv-ah-sw_mgmt_crypto)
key-cipher == WLAN_CIPHER_SUITE_CCMP)
key-flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
ret = 0;
Hmm.. may be we should generally do it here:
if ((vif-type == NL80211_IFTYPE_ADHOC ||
vif-type == NL80211_IFTYPE_MESH_POINT)
(key-cipher == WLAN_CIPHER_SUITE_TKIP ||
key-cipher == WLAN_CIPHER_SUITE_CCMP)
!(key-flags IEEE80211_KEY_FLAG_PAIRWISE)) {
Not so sure doing here is correctly. It is a pairwise key for unicast
management frame, right?
or probably set sw_mgmt_crypto = true in ath9k_hw_init_mfp() for all
usb devices?
All ath9k USB devices don't have MFP support?
---
ChunYeow
--
Regards,
Oleksij
--
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
WSMP(Wave Short Message Protocol) Stack Implementation
Hi ,
I am planing to develop WSMP (Wave Short Message Protocol) protocol in
transport layer.Any suggestions will be appreciated,
My idea is given below
WSMP(Wave Short Message Protocol ie. 1609.3
published by the IEEE Vehicular Society) is a part of the DSRC(Dedicated
Short Range Communications) standards suite which include 802.11p,
1609.x series. Which are used for intervehicular communication and
also for vehicle to infrastructure communication.
The DSRC/WAVE stack:
Application Layer (SAE J2735 Message set dictionary)
^
|
Transport Layer -|
^ |
| |--(WSMP IEEE 1609.3) Both combined
Network Layer|
^ |
| |
LLC(existing) -|
^
|
Datalink Layer -|
^ |
| |--(1609.4 and IEEE802.11p)
Physical Layer -|
Currently as IEEE 802.11-2012 has released,it is having 802.11p also
merged in it.
We may have WSMP acting as both transport layer and network layer.We
have some proprietry
implementations of all these standards but no open source implementation
has been done.
We propose to develop this in a way so that it has a socket interface to
the user.
Please give your suggestions.
For more info regarding the stack one may refer to the Document
IEEE1609.0 or John Kenney's
paper on this subject Dedicated Short-Range
Communications (DSRC) Standards in the United States
link http://secs.oakland.edu/~gpcorser/vanet-kenny-DSRC.pdf;
* Following attachments are my source code of transport layer
please give me suggestion.
I added following attachment only transmission function but
unfortunately this packet is discarded in hardware please help me.
Thanks Regards,
Vamsi
MODULE_LICENSE(GPL);
#include net/inet_sock.h
#define WSMP_HDR_SIZE 16
#ifndef AF_WSMP
#define AF_WSMP44
#define PF_WSMPAF_WSMP
#endif
#define wsmp_sk(__sk) ((struct wsmp_sock *) __sk)
struct wsmp_sock {
struct inet_sock inet;
struct list_head accept_q;
u16 wsmp_heder_length;
__be16 num; //protocol number
};
extern struct proto_ops wsmp_sock_ops;
struct wsmphdr {
__u8 wsm_version;
__u8 security_type;
__u8 cno;
__u8 data_rate;
__u8 tx_pow_level;
__u32 psid;
__u16 wsm_length;
uint8_t *data;
};
struct sockaddr_wsmp {
__u16 sin_family;
__u8 wsm_version;
__u8 security_type;
__u8 cno;
__u8 data_rate;
__u8 tx_pow_level;
__u32 psid;
__u16 wsm_length;
};
/*
* This file implement the WSMP(Wave Short Message Protocol) priv API.
*
* Authors : Tata P Vamsi Krishna vamsi07...@gmail.com
* Copyright 2014 Tata P Vamsi Krishna vamsi07...@gmail.com
*
* (As all part of the Linux kernel, this file is GPL)
*/
#include linux/module.h
#include linux/skbuff.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
#include asm/ioctls.h
#include linux/proc_fs.h
#include linux/socket.h
#include linux/net.h
#include net/sock.h
#includewsmp.h
static void wsmp_sock_kill(struct sock *sk);
static int wsmp_sock_shutdown(struct socket *sock, int how)
{ struct sock *sk = sock-sk;
int err = 0;
if (!sk)
return 0;
if (!sk-sk_shutdown)
sk-sk_shutdown = SHUTDOWN_MASK;
// __rfcomm_sock_close(sk);
if (sock_flag(sk, SOCK_LINGER) sk-sk_lingertime)
// err = bt_sock_wait_state(sk, BT_CLOSED, sk-sk_lingertime);
release_sock(sk);
printk(This is wsmp_sock_shutdown\n);
return err;
}
static int wsmp_sock_release(struct socket *sock)
{
struct sock *sk = sock-sk;
int err = 0;
if (!sk)
return 0;
wsmp_sock_shutdown(sock,2);
sock_orphan(sk);
wsmp_sock_kill(sk);
printk(This is wsmp_sock_release..\n);
return 0;
}
static void wsmp_sock_kill(struct sock *sk){
if (!sock_flag(sk, SOCK_ZAPPED) || sk-sk_socket)
return;
sock_set_flag(sk, SOCK_DEAD);
sock_put(sk);
printk(This is wsmp_sock_kill..\n);
}
static int wsmp_sock_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
struct sockaddr_in *addr = (struct sockaddr_in *)uaddr;
struct sock *sk = sock-sk;
struct inet_sock *inet = inet_sk(sk);
struct net *net = sock_net(sk);
unsigned short snum;
int chk_addr_ret;
int err,i;
/* If the socket has its own bind function then use it. (RAW) */
if (sk-sk_prot-bind) {
err = sk-sk_prot-bind(sk, uaddr, addr_len);
printk(error message);;
}
printk(This family%d\n,uaddr-sa_family);
printk(This address: );
for(i=0;i14;i++)
printk(%d ,uaddr-sa_data[i]);
printk(\n);
printk(This is wsmp_sock_bind..\n);
return 0;
}
static int wsmp_sock_connect(struct socket *sock, struct sockaddr *addr, int alen, int flags)
{
printk(This is wsmp_sock_connect..\n);
return 0;
}
static int wsmp_sock_listen(struct socket *sock, int backlog)
{
[patch added to the 3.12 stable tree] wireless: rt2x00: rt2800usb: add new devices
From: Xose Vazquez Perez xose.vazq...@gmail.com
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit 274dede8c52036a1849ea970fab8d185fb0dce2b upstream.
0411,0241 RT5572 BUFFALO WI-U2-300D Wireless LAN Adapter
0789,0170 RT3572 Logitec LAN-W300AN/U2
0846,9013 RT3573 NETGEAR Adaptador USB Inalambrico Movistar
0df6,006e RT3573 Sitecom WiFi USB adapter N900
2001,3c1f RT3573 D-Link DWA-162 Wireless N900 Dual Band Adapter
2001,3c20 RT5372 D-Link DWA-140 Wireless N USB Adapter(rev.D)
2001,3c21 RT5572 D-Link DWA-160 Xtreme N Dual Band USB Adapter(rev.C)
2001,3c22 RT5372 D-Link DWA-132 Wireless N USB Adapter(rev.B)
2001,3c23 RT5372 D-Link GO-USB-N300 Wireless N Easy USB Adapter
2019,ab29 ? Planex GW-USMirco300
20f4,724a RT5572 TRENDnet N600 Wireless Dual Band USB Adapter
Cc: Ivo van Doorn ivdo...@gmail.com
Cc: Gertjan van Wingerde gwinge...@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: Jiri Slaby jsl...@suse.cz
---
drivers/net/wireless/rt2x00/rt2800usb.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
b/drivers/net/wireless/rt2x00/rt2800usb.c
index 4feb35aef990..997df03a0c2e 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1180,6 +1180,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Linksys */
{ USB_DEVICE(0x13b1, 0x002f) },
{ USB_DEVICE(0x1737, 0x0079) },
+ /* Logitec */
+ { USB_DEVICE(0x0789, 0x0170) },
/* Ralink */
{ USB_DEVICE(0x148f, 0x3572) },
/* Sitecom */
@@ -1203,6 +1205,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x050d, 0x1103) },
/* Cameo */
{ USB_DEVICE(0x148f, 0xf301) },
+ /* D-Link */
+ { USB_DEVICE(0x2001, 0x3c1f) },
/* Edimax */
{ USB_DEVICE(0x7392, 0x7733) },
/* Hawking */
@@ -1216,6 +1220,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x0789, 0x016b) },
/* NETGEAR */
{ USB_DEVICE(0x0846, 0x9012) },
+ { USB_DEVICE(0x0846, 0x9013) },
{ USB_DEVICE(0x0846, 0x9019) },
/* Planex */
{ USB_DEVICE(0x2019, 0xed19) },
@@ -1224,6 +1229,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Sitecom */
{ USB_DEVICE(0x0df6, 0x0067) },
{ USB_DEVICE(0x0df6, 0x006a) },
+ { USB_DEVICE(0x0df6, 0x006e) },
/* ZyXEL */
{ USB_DEVICE(0x0586, 0x3421) },
#endif
@@ -1240,6 +1246,9 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x2001, 0x3c1c) },
{ USB_DEVICE(0x2001, 0x3c1d) },
{ USB_DEVICE(0x2001, 0x3c1e) },
+ { USB_DEVICE(0x2001, 0x3c20) },
+ { USB_DEVICE(0x2001, 0x3c22) },
+ { USB_DEVICE(0x2001, 0x3c23) },
/* LG innotek */
{ USB_DEVICE(0x043e, 0x7a22) },
{ USB_DEVICE(0x043e, 0x7a42) },
@@ -1262,12 +1271,17 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x043e, 0x7a32) },
/* AVM GmbH */
{ USB_DEVICE(0x057c, 0x8501) },
- /* D-Link DWA-160-B2 */
+ /* Buffalo */
+ { USB_DEVICE(0x0411, 0x0241) },
+ /* D-Link */
{ USB_DEVICE(0x2001, 0x3c1a) },
+ { USB_DEVICE(0x2001, 0x3c21) },
/* Proware */
{ USB_DEVICE(0x043e, 0x7a13) },
/* Ralink */
{ USB_DEVICE(0x148f, 0x5572) },
+ /* TRENDnet */
+ { USB_DEVICE(0x20f4, 0x724a) },
#endif
#ifdef CONFIG_RT2800USB_UNKNOWN
/*
@@ -1337,6 +1351,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x1d4d, 0x0010) },
/* Planex */
{ USB_DEVICE(0x2019, 0xab24) },
+ { USB_DEVICE(0x2019, 0xab29) },
/* Qcom */
{ USB_DEVICE(0x18e8, 0x6259) },
/* RadioShack */
--
2.1.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: linux-next: ath9k: build failure, ath_cmn_process_fft() redefinition
Thank you, fixes are queued for review. Am 14.11.2014 um 01:07 schrieb Jeremiah Mahler: In version 20141113 of the linux-next kernel, if it is compiled with CONFIG_ATH9K_DEBUGFS unset, an error about ath_cmn_process_fft() being redefined will be produced. make ... LD [M] drivers/net/wireless/ath/ath9k/ath9k_hw.o CC [M] drivers/net/wireless/ath/ath9k/common-spectral.o CC lib/debug_locks.o CC lib/random32.o 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[5]: *** [drivers/net/wireless/ath/ath9k/common-spectral.o] Error 1 scripts/Makefile.build:402: recipe for target 'drivers/net/wireless/ath/ath9k' failed make[4]: *** [drivers/net/wireless/ath/ath9k] Error 2 scripts/Makefile.build:402: recipe for target 'drivers/net/wireless/ath' failed make[3]: *** [drivers/net/wireless/ath] Error 2 scripts/Makefile.build:402: recipe for target 'drivers/net/wireless' failed make[2]: *** [drivers/net/wireless] Error 2 scripts/Makefile.build:402: recipe for target 'drivers/net' failed make[1]: *** [drivers/net] Error 2 Makefile:953: recipe for target 'drivers' failed make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs CC lib/bust_spinlocks.o ... Bisecting the kernel found that the following patch was the cause. commit 67dc74f15f147b9f88702de2952d2951e3e000ec Author: Oleksij Rempel li...@rempel-privat.de Date: Thu Nov 6 08:53:30 2014 +0100 ath9k: move spectral.* to common-spectral.* and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_* Signed-off-by: Oleksij Rempel li...@rempel-privat.de Signed-off-by: John W. Linville linvi...@tuxdriver.com This patch mostly consists of renaming functions and moving code but there was a functional change to the Makefile. common-spectral.h uses CONFIG_ATH9K_DEBUGFS to conditionally provide a prototype of ath_cmn_process_fft() when set or to define it as a noop when it is unset. The Makefile was changed so that CONFIG_ATH9K_DEBUGFS no longer applied to common-spectral and this will result in two definitions of ath_cmn_process_fft(). --- a/drivers/net/wireless/ath/ath9k/Makefile +++ b/drivers/net/wireless/ath/ath9k/Makefile @@ -16,8 +16,7 @@ ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o ath9k-$(CONFIG_ATH9K_TX99) += tx99.o ath9k-$(CONFIG_ATH9K_WOW) += wow.o -ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o \ -spectral.o +ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o ath9k-$(CONFIG_ATH9K_STATION_STATISTICS) += debug_sta.o @@ -59,7 +58,8 @@ obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o ath9k_common-y:= common.o \ common-init.o \ common-beacon.o \ - common-debug.o + common-debug.o \ + common-spectral.o Reverting the patch solves one error, but then a new one is produced. make ... MODPOST 185 modules CC arch/x86/boot/edd.o VOFFSET arch/x86/boot/voffset.h ERROR: ath9k_cmn_spectral_scan_trigger [drivers/net/wireless/ath/ath9k/ath9k.ko] undefined! scripts/Makefile.modpost:90: recipe for target '__modpost' failed make[1]: *** [__modpost] Error 1 ... This error is caused by the patch before it. commit f00a422cc81ef665f5098c0bc43cb0c616e55a9b Author: Oleksij Rempel li...@rempel-privat.de Date: Thu Nov 6 08:53:29 2014 +0100 ath9k: move ath9k_spectral_scan_ from main.c to spectral.c Now we should be ready to make this code common. Signed-off-by: Oleksij Rempel li...@rempel-privat.de Signed-off-by: John W. Linville linvi...@tuxdriver.com Since the code was moved from main.c to spectral.c, it is now involved with CONFIG_ATH9K_DEBUGFS, which causes it to break. Reverting both the above patches resolves the build errors. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
[patch added to the 3.12 stable tree] wireless: rt2x00: add new rt2800usb devices
From: Xose Vazquez Perez xose.vazq...@gmail.com
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
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: Jiri Slaby jsl...@suse.cz
---
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 b6cb308beda1..ec816e0459cc 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1238,6 +1238,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) },
@@ -1274,6 +1276,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) },
@@ -1364,6 +1367,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.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 2/2] wil6210: atomic I/O for the card memory
Vladimir Kondratiev qca_vkond...@qca.qualcomm.com writes: Introduce netdev IOCTLs, to be used by the debug tools. Allows to read/write single dword value or memory block, aligned to dword Different address modes supported: - BAR offset - Firmware linker address - target's AHB bus Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com An ioctl interface for a wireless driver? IMHO that would have been ok in 2004, but not in 2014. Isn't there really better way to implement this? +/* Numbers SIOCDEVPRIVATE and SIOCDEVPRIVATE + 1 + * are used by Android devices to implement PNO (preferred network offload). + * Albeit it is temporary solution, use different numbers to avoid conflicts + */ Comments like this make me even more worried that that this is just yet another way to implement wext iwpriv interface. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] ath10k: testmode support
Pushpal Sidhu psi...@gateworks.com writes: On Thu, Sep 11, 2014 at 1:43 PM, Kalle Valo kv...@qca.qualcomm.com wrote: Kalle Valo kv...@qca.qualcomm.com writes: latest version of my testmode patches. Getting closer, more or less cosmetic changes this time :) While looking through this patchset (sorry it took two months), I have to wonder: what's this utf.bin blob? It seems in order to use testmode, we need this binary blob that I can't seem to find (I looked in linux-firmware and https://github.com/kvalo/ath10k-firmware). If, for whatever reason, this binary blob is not releasable, what's the point of adding in testmode to this driver? testmode is for functionality needed in the factory, it's not meant for normal users. That's why all distros should have CONFIG_NL80211_TESTMODE disabled. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: Add more checks for get_btc_status callback
On Wed, 2014-11-12 at 21:03 -0200, Murilo Opsfelder Araújo wrote: Hello, Larry. I'd like to let you know that next-20141112 brought my rtl8192se device back to life. I didn't need to build rtlwifi_new to be able to connect to my wifi network. It worked just fine. Yeah, unsurprisingly, merging those fixed up my lappy as well. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] cfg80211: add scan time to survey data
From: Johannes Berg johannes.b...@intel.com
Add the time spent scanning to the survey data so it can be
reported by drivers that collect such information.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
include/net/cfg80211.h | 3 +++
include/uapi/linux/nl80211.h | 3 +++
net/wireless/nl80211.c | 4
net/wireless/trace.h | 7 +--
4 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 07fafce7dc83..c59b93714728 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -525,6 +525,7 @@ ieee80211_chandef_max_power(struct cfg80211_chan_def
*chandef)
* @SURVEY_INFO_TIME_EXT_BUSY: extension channel busy time was filled in
* @SURVEY_INFO_TIME_RX: receive time was filled in
* @SURVEY_INFO_TIME_TX: transmit time was filled in
+ * @SURVEY_INFO_TIME_SCAN: scan time was filled in
*
* Used by the driver to indicate which info in struct survey_info
* it has filled in during the get_survey().
@@ -537,6 +538,7 @@ enum survey_info_flags {
SURVEY_INFO_TIME_EXT_BUSY = BIT(4),
SURVEY_INFO_TIME_RX = BIT(5),
SURVEY_INFO_TIME_TX = BIT(6),
+ SURVEY_INFO_TIME_SCAN = BIT(7),
};
/**
@@ -565,6 +567,7 @@ struct survey_info {
u64 time_ext_busy;
u64 time_rx;
u64 time_tx;
+ u64 time_scan;
u32 filled;
s8 noise;
};
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 92593e4e3c85..6eab1ba27f38 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2766,6 +2766,8 @@ enum nl80211_user_reg_hint_type {
* receiving data (on channel or globally)
* @NL80211_SURVEY_INFO_TIME_TX: amount of time the radio spent
* transmitting data (on channel or globally)
+ * @NL80211_SURVEY_INFO_TIME_SCAN: time the radio spent for scan
+ * (on this channel or globally)
* @NL80211_SURVEY_INFO_MAX: highest survey info attribute number
* currently defined
* @__NL80211_SURVEY_INFO_AFTER_LAST: internal use
@@ -2780,6 +2782,7 @@ enum nl80211_survey_info {
NL80211_SURVEY_INFO_TIME_EXT_BUSY,
NL80211_SURVEY_INFO_TIME_RX,
NL80211_SURVEY_INFO_TIME_TX,
+ NL80211_SURVEY_INFO_TIME_SCAN,
/* keep last */
__NL80211_SURVEY_INFO_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 6aba8de1e032..648374c4f815 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6400,6 +6400,10 @@ static int nl80211_send_survey(struct sk_buff *msg, u32
portid, u32 seq,
nla_put_u64(msg, NL80211_SURVEY_INFO_TIME_TX,
survey-time_tx))
goto nla_put_failure;
+ if ((survey-filled SURVEY_INFO_TIME_SCAN)
+ nla_put_u64(msg, NL80211_SURVEY_INFO_TIME_SCAN,
+ survey-time_scan))
+ goto nla_put_failure;
nla_nest_end(msg, infoattr);
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 2e2885ec2912..3d59b5100156 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -1609,6 +1609,7 @@ TRACE_EVENT(rdev_return_int_survey_info,
__field(u64, time_ext_busy)
__field(u64, time_rx)
__field(u64, time_tx)
+ __field(u64, time_scan)
__field(u32, filled)
__field(s8, noise)
),
@@ -1621,17 +1622,19 @@ TRACE_EVENT(rdev_return_int_survey_info,
__entry-time_ext_busy = info-time_ext_busy;
__entry-time_rx = info-time_rx;
__entry-time_tx = info-time_tx;
+ __entry-time_scan = info-time_scan;
__entry-filled = info-filled;
__entry-noise = info-noise;
),
TP_printk(WIPHY_PR_FMT , returned: %d, CHAN_PR_FMT
, channel time: %llu, channel time busy: %llu,
channel time extension busy: %llu, channel time rx: %llu,
- channel time tx: %llu, filled: %u, noise: %d,
+ channel time tx: %llu, scan time: %llu, filled: %u, noise:
%d,
WIPHY_PR_ARG, __entry-ret, CHAN_PR_ARG,
__entry-time, __entry-time_busy,
__entry-time_ext_busy, __entry-time_rx,
- __entry-time_tx, __entry-filled, __entry-noise)
+ __entry-time_tx, __entry-time_scan,
+ __entry-filled, __entry-noise)
);
TRACE_EVENT(rdev_tdls_oper,
--
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
[RFC 1/3] cfg80211: remove channel from survey names
From: Johannes Berg johannes.b...@intel.com
All of the survey data is (currently) per channel anyway,
so having the word channel in the name does nothing. In
the next patch I'll introduce global data to the survey,
where the word channel is actually confusing.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/ath/ath10k/wmi.c | 8 ++---
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 16 +-
drivers/net/wireless/ath/ath9k/link.c | 16 +-
drivers/net/wireless/ath/carl9170/cmd.c | 12
drivers/net/wireless/ath/carl9170/main.c | 6 ++--
drivers/net/wireless/mwl8k.c | 12
drivers/net/wireless/p54/eeprom.c | 6 ++--
drivers/net/wireless/p54/main.c | 8 ++---
drivers/net/wireless/p54/txrx.c | 12
drivers/net/wireless/rt2x00/rt2800lib.c | 12
include/net/cfg80211.h| 44 +--
include/uapi/linux/nl80211.h | 27 ++--
net/mac80211/ethtool.c| 20 ++--
net/wireless/nl80211.c| 30 +-
net/wireless/trace.h | 26
15 files changed, 131 insertions(+), 124 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c42bd504b79..903bea367cde 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1265,11 +1265,11 @@ static void ath10k_wmi_event_chan_info(struct ath10k
*ar, struct sk_buff *skb)
rx_clear_count -= ar-survey_last_rx_clear_count;
survey = ar-survey[idx];
- survey-channel_time = WMI_CHAN_INFO_MSEC(cycle_count);
- survey-channel_time_rx = WMI_CHAN_INFO_MSEC(rx_clear_count);
+ survey-time = WMI_CHAN_INFO_MSEC(cycle_count);
+ survey-time_rx = WMI_CHAN_INFO_MSEC(rx_clear_count);
survey-noise = noise_floor;
- survey-filled = SURVEY_INFO_CHANNEL_TIME |
-SURVEY_INFO_CHANNEL_TIME_RX |
+ survey-filled = SURVEY_INFO_TIME |
+SURVEY_INFO_TIME_RX |
SURVEY_INFO_NOISE_DBM;
}
diff --git a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
index ab2709a43768..6e69d6c40415 100644
--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+++ b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
@@ -670,10 +670,10 @@ ath5k_get_survey(struct ieee80211_hw *hw, int idx, struct
survey_info *survey)
spin_lock_bh(common-cc_lock);
ath_hw_cycle_counters_update(common);
if (cc-cycles 0) {
- ah-survey.channel_time += cc-cycles / div;
- ah-survey.channel_time_busy += cc-rx_busy / div;
- ah-survey.channel_time_rx += cc-rx_frame / div;
- ah-survey.channel_time_tx += cc-tx_frame / div;
+ ah-survey.time += cc-cycles / div;
+ ah-survey.time_busy += cc-rx_busy / div;
+ ah-survey.time_rx += cc-rx_frame / div;
+ ah-survey.time_tx += cc-tx_frame / div;
}
memset(cc, 0, sizeof(*cc));
spin_unlock_bh(common-cc_lock);
@@ -684,10 +684,10 @@ ath5k_get_survey(struct ieee80211_hw *hw, int idx, struct
survey_info *survey)
survey-noise = ah-ah_noise_floor;
survey-filled = SURVEY_INFO_NOISE_DBM |
SURVEY_INFO_IN_USE |
- SURVEY_INFO_CHANNEL_TIME |
- SURVEY_INFO_CHANNEL_TIME_BUSY |
- SURVEY_INFO_CHANNEL_TIME_RX |
- SURVEY_INFO_CHANNEL_TIME_TX;
+ SURVEY_INFO_TIME |
+ SURVEY_INFO_TIME_BUSY |
+ SURVEY_INFO_TIME_RX |
+ SURVEY_INFO_TIME_TX;
return 0;
}
diff --git a/drivers/net/wireless/ath/ath9k/link.c
b/drivers/net/wireless/ath/ath9k/link.c
index 2343f56e6498..973eed2142f2 100644
--- a/drivers/net/wireless/ath/ath9k/link.c
+++ b/drivers/net/wireless/ath/ath9k/link.c
@@ -510,14 +510,14 @@ int ath_update_survey_stats(struct ath_softc *sc)
ath_hw_cycle_counters_update(common);
if (cc-cycles 0) {
- survey-filled |= SURVEY_INFO_CHANNEL_TIME |
- SURVEY_INFO_CHANNEL_TIME_BUSY |
- SURVEY_INFO_CHANNEL_TIME_RX |
- SURVEY_INFO_CHANNEL_TIME_TX;
- survey-channel_time += cc-cycles / div;
- survey-channel_time_busy += cc-rx_busy / div;
- survey-channel_time_rx += cc-rx_frame / div;
- survey-channel_time_tx += cc-tx_frame / div;
+ survey-filled |= SURVEY_INFO_TIME |
+ SURVEY_INFO_TIME_BUSY
Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?
On Fri, 2014-11-14 at 16:02 +0900, Marcel Holtmann wrote: Hi Dan, I've updated wireless code on RHEL and get complain that now cfg80211 and rfkill modules are loaded on machines that do not have wireless hardware. Modules are auto-loaded because NetworkManager send nl80211 messages to check if there are wireless devices in the system. Hence my question, can we revert commit fb4e156886ce nl80211: Add generic netlink module alias for cfg80211/nl80211 ? Realistically, we can't revert it, but only remove the MODULE_ALIAS_GENL_FAMILY() line. Auto loading nl80211 does not seems to be necessary, if there are wireless devices nl80211 will be loaded anyway. Maybe other applications would like to see an empty list of devices? But OTOH, if they're robust at all, they have to cope with kernels not even compiled with nl80211, so I guess for me I don't really see a big difference in whether the module alias exists or not. auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things. Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded. NM uses nl80211 initially to determine whether *any* ethernet-type interface (a) is actually WiFi, and (b) should be driven by nl80211 or WEXT. Because of the variety of drivers (both in-kernel and out-of-kernel) and the variety of kernel versions (NM supports back to early 3.x series) we cannot rely on specific behavior. So given an ethernet-type interface, how do we determine that it is wifi? DEVTYPE=wlan - not always reliable due to driver and kernel versions if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug. Yeah, that's nice, and should be done. It seems a number of drivers don't have it. Obviously everything mac80211 does, and it seems we're left with: 1) legacy drivers that only support WEXT (airo, etc) 2) out-of-tree drivers (wl.o and various realtek/ralink stuff?) So it seems that new best practice is: a) if DEVTYPE=wlan, hit up nl80211 to determine whether the interface supports nl80211 or WEXT (minimal cfg80211 ports like ipw2x00 don't actually support nl80211 at all and must use WEXT) b) if DEVTYPE is missing, WEXT can be tried if it is available c) treat interface as 'ethernet'; out-of-tree WiFi drivers may end up here but that is life Does that sound valid to everyone else? Dan phy80211 in sysfs: same reason; also doesn't capture WEXT or out-of-tree drivers nl80211 calls: this is the only 100% reliable mechanism to detect whether an ethernet-type interface is actually WiFi and nl80211-capable. And unfortunately calling nl80211 loads the module... So be it then, the cfg80211 modules gets loaded. People have to live with that. And just to be clear, this is not a kernel bug. Exposing the correct module alias for its netlink family is what the module should be doing. Regards Marcel -- 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 v6] mac80211: minstrel_ht: add basic support for VHT rates = 3SS@80MHz
On Tue, Oct 21, 2014 at 10:38:38AM +0200, Karl Beldan wrote: When the new CONFIG_MAC80211_RC_MINSTREL_VHT is not set (default 'N'), there is no behavioral change including in sampling and MCS_GROUP_RATES remains 8. Otherwise MCS_GROUP_RATES is 10, and a module parameter *vht_only* (default 'true'), restricts the rates selection to VHT when vht is supported. Have you tested this with mac80211_hwsim? I'm seeing number of issues in hwsim test cases with CONFIG_MAC80211_RC_MINSTREL_VHT=y with wireless-testing.git. These disappear if I disable this build option. For example, with nfc_p2p_go_neg test case: [7.023869] wlan1: authenticate with 02:00:00:00:00:00 [7.024421] wlan1: Allocated STA 02:00:00:00:00:00 [7.024426] wlan1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded (note: this part happens also with minstrel_ht VHT supported disabled, but the issues below don't) ... [7.255983] wlan0: Allocated STA 02:00:00:00:01:00 [7.255988] wlan0: moving STA 02:00:00:00:01:00 to state 2 [7.255991] wlan0: moving STA 02:00:00:00:01:00 to state 3 [7.256232] wlan0: Inserted STA 02:00:00:00:01:00 [7.270176] wlan1: dropped frame to 02:00:00:00:00:00 (unauthorized port) [7.494771] [ cut here ] [7.495194] WARNING: CPU: 1 PID: 584 at net/mac80211/rate.c:501 ieee80211_get_tx_rates+0x2c2/0x810() [7.495972] CPU: 1 PID: 584 Comm: wpa_supplicant Not tainted 3.18.0-rc4-wl #347 [7.496607] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [7.497322] 0009 88001e327798 814d7f34 81089c41 [7.498010] 88001e3277d8 8103ab6c 0246 [7.498703] 88001dcb7600 88001dcb7630 88001dcb763c [7.499399] Call Trace: [7.499628] [814d7f34] dump_stack+0x4e/0x71 [7.500108] [81089c41] ? console_unlock+0x1f1/0x4d0 [7.500628] [8103ab6c] warn_slowpath_common+0x7c/0xa0 [7.501184] [8103ac7a] warn_slowpath_null+0x1a/0x20 [7.501702] [814598e2] ieee80211_get_tx_rates+0x2c2/0x810 [7.502256] [81459f0a] rate_control_get_rate+0xda/0xf0 [7.502790] [8146f8f2] ieee80211_tx_h_rate_ctrl+0x1a2/0x430 [7.503368] [8146fda8] invoke_tx_handlers+0x108/0x180 [7.503898] [81470d15] ieee80211_tx+0x75/0xf0 [7.504370] [81470ef1] ieee80211_xmit+0xa1/0x100 [7.504862] [8147239a] ieee80211_subif_start_xmit+0xf9a/0x1150 [7.505494] [81471442] ? ieee80211_subif_start_xmit+0x42/0x1150 [7.506039] [812e9ee1] dev_hard_start_xmit+0x271/0x830 [7.506394] [812e9cc8] ? dev_hard_start_xmit+0x58/0x830 [7.506754] [8130d822] sch_direct_xmit+0xf2/0x1f0 [7.507086] [812ea704] __dev_queue_xmit+0x264/0x8e0 [7.507426] [812ea4f0] ? __dev_queue_xmit+0x50/0x8e0 [7.507774] [812eae00] dev_queue_xmit+0x10/0x20 [7.508110] [813cdcba] packet_sendmsg+0xdfa/0x10a0 [7.508450] [812cec59] sock_sendmsg+0x69/0x90 [7.508762] [812ce8f5] ? move_addr_to_kernel+0x45/0x70 [7.509130] [812d02e2] SyS_sendto+0x112/0x150 [7.509469] [814e2995] ? sysret_check+0x22/0x5d [7.509793] [81080de5] ? trace_hardirqs_on_caller+0x105/0x1d0 [7.510208] [811e7eab] ? trace_hardirqs_on_thunk+0x3a/0x3f [7.510587] [814e2969] system_call_fastpath+0x12/0x17 [7.510941] ---[ end trace a7659d7a05f5ad35 ]--- [7.511249] [ cut here ] [7.511525] WARNING: CPU: 1 PID: 584 at net/mac80211/rx.c:3452 ieee80211_rx+0xb54/0xb60() [7.512001] Rate marked as a VHT rate but data is invalid: MCS: 11, NSS: 1 [7.512542] CPU: 1 PID: 584 Comm: wpa_supplicant Tainted: GW 3.18.0-rc4-wl #347 [7.513210] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [7.513839] 0009 88001fc83d98 814d7f34 81089c41 [7.514463] 88001fc83de8 88001fc83dd8 8103ab6c 0001 [7.514926] 88001dcb7d00 88001e1f07c0 88001e1f07c0 88001e1f0ce0 [7.515388] Call Trace: [7.515536] IRQ [814d7f34] dump_stack+0x4e/0x71 [7.515895] [81089c41] ? console_unlock+0x1f1/0x4d0 [7.516242] [8103ab6c] warn_slowpath_common+0x7c/0xa0 [7.516597] [8103ac06] warn_slowpath_fmt+0x46/0x50 [7.516949] [8146e404] ieee80211_rx+0xb54/0xb60 [7.517316] [81080d92] ? trace_hardirqs_on_caller+0xb2/0x1d0 [7.517710] [81080ebd] ? trace_hardirqs_on+0xd/0x10 [7.518056] [81430d94] ieee80211_tasklet_handler+0xd4/0xe0 [7.518435] [8103f3d7] tasklet_action+0xe7/0xf0 [7.518761] [8103e780] __do_softirq+0x150/0x610 [7.519083] [812ea74a] ?
Re: brcmfmac not working on ECS LIVA
On Thu, Nov 13, 2014 at 4:47 AM, Arend van Spriel ar...@broadcom.com wrote: On 12-11-14 16:23, Felipe Contreras wrote: On Wed, Nov 12, 2014 at 4:40 AM, Arend van Spriel ar...@broadcom.com wrote: I tried this patch, and although it seems to make a difference, it still doesn't work. http://people.freedesktop.org/~felipec/dmesg-brcm-2.txt Hi Felipe, All the messages to the firmware seem ok. If connection would succeed I normally see a LINK event followed by SET_SSID event. In your log I only see the SET_SSID event with failed status, hence the connect is unsuccessful. Do you have any control over the AP? Could you try without WPA security to quickly confirm connection works? May help in root causing the issue. I tried disabled WPA security, it's still not working. -- 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: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?
On Fri, 2014-11-14 at 10:02 -0600, Dan Williams wrote: On Fri, 2014-11-14 at 16:02 +0900, Marcel Holtmann wrote: Hi Dan, I've updated wireless code on RHEL and get complain that now cfg80211 and rfkill modules are loaded on machines that do not have wireless hardware. Modules are auto-loaded because NetworkManager send nl80211 messages to check if there are wireless devices in the system. Hence my question, can we revert commit fb4e156886ce nl80211: Add generic netlink module alias for cfg80211/nl80211 ? Realistically, we can't revert it, but only remove the MODULE_ALIAS_GENL_FAMILY() line. Auto loading nl80211 does not seems to be necessary, if there are wireless devices nl80211 will be loaded anyway. Maybe other applications would like to see an empty list of devices? But OTOH, if they're robust at all, they have to cope with kernels not even compiled with nl80211, so I guess for me I don't really see a big difference in whether the module alias exists or not. auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things. Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded. NM uses nl80211 initially to determine whether *any* ethernet-type interface (a) is actually WiFi, and (b) should be driven by nl80211 or WEXT. Because of the variety of drivers (both in-kernel and out-of-kernel) and the variety of kernel versions (NM supports back to early 3.x series) we cannot rely on specific behavior. So given an ethernet-type interface, how do we determine that it is wifi? DEVTYPE=wlan - not always reliable due to driver and kernel versions if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug. Yeah, that's nice, and should be done. It seems a number of drivers don't have it. Obviously everything mac80211 does, and it seems we're left with: 1) legacy drivers that only support WEXT (airo, etc) 2) out-of-tree drivers (wl.o and various realtek/ralink stuff?) So it seems that new best practice is: a) if DEVTYPE=wlan, hit up nl80211 to determine whether the interface supports nl80211 or WEXT (minimal cfg80211 ports like ipw2x00 don't actually support nl80211 at all and must use WEXT) b) if DEVTYPE is missing, WEXT can be tried if it is available c) treat interface as 'ethernet'; out-of-tree WiFi drivers may end up here but that is life Does that sound valid to everyone else? Potential NM fix filed at: https://bugzilla.gnome.org/show_bug.cgi?id=740131 Dan -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] mac80211: minstrel_ht: add basic support for VHT rates = 3SS@80MHz
Hi, On Fri, Nov 14, 2014 at 06:43:28PM +0200, Jouni Malinen wrote: On Tue, Oct 21, 2014 at 10:38:38AM +0200, Karl Beldan wrote: When the new CONFIG_MAC80211_RC_MINSTREL_VHT is not set (default 'N'), there is no behavioral change including in sampling and MCS_GROUP_RATES remains 8. Otherwise MCS_GROUP_RATES is 10, and a module parameter *vht_only* (default 'true'), restricts the rates selection to VHT when vht is supported. Have you tested this with mac80211_hwsim? I'm seeing number of issues in Yes, only with iw and nothing fancy, I also have had it running on some boards for some weeks as is and with rfc version for more than a year at work (minstrel not the whole tree). I guess I can take the tip of wireless-testing but can you give your HEAD though ? hwsim test cases with CONFIG_MAC80211_RC_MINSTREL_VHT=y with wireless-testing.git. These disappear if I disable this build option. For example, with nfc_p2p_go_neg test case: Have you reproduced it with other testcases (maybe more regular so that I can get my hands on it faster) ? Is it also happening when VHT support is not advertized by upper layers ? Rgds, Karl -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] mac80211: minstrel_ht: add basic support for VHT rates = 3SS@80MHz
On Fri, Nov 14, 2014 at 06:18:32PM +0100, Karl Beldan wrote: Yes, only with iw and nothing fancy, I also have had it running on some boards for some weeks as is and with rfc version for more than a year at work (minstrel not the whole tree). I guess I can take the tip of wireless-testing but can you give your HEAD though ? It looks like pretty much any snapshot between master-2014-11-04 and now is affected.. Anyway, the current master snapshot in my tests was 0e204e2422876c18034ca960c4fccf727a02a5c1. For example, with nfc_p2p_go_neg test case: Have you reproduced it with other testcases (maybe more regular so that I can get my hands on it faster) ? Is it also happening when VHT support is not advertized by upper layers ? This seems to be specific to exact timing of frames since the same issue does not show up in non-NFC P2P test cases. So no, this does not show up with anything else than the nfc_p2p_* test cases (well, at least not in my desktop+kvm setup; YMMV with other CPU speeds that could potentially affect timing): nfc_p2p_go_neg nfc_p2p_go_neg_reverse nfc_p2p_ip_addr_assignment nfc_p2p_static_handover_tagdev_client nfc_p2p_static_handover_tagdev_client_group_iface nfc_p2p_static_handover_tagdev_go I'd assume the key here is in P2P with NFC trigger having the fastest possible connection process due to all the optimizations in channel selection on WPS (which is those EAPOL Data frames that hit these rate selection issues immediately after association). That said, if you use the tests/hwsim scripts from git://w1.fi/hostap.git there should be no difference on running some of these cases vs. something more regular.. If you have not used these test scripts previously, you can find more information about the setup here: http://w1.fi/cgit/hostap/plain/tests/hwsim/README http://w1.fi/cgit/hostap/plain/tests/hwsim/vm/README -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cfg80211: protect fools returning NULL in add_virtual_intf
Callback add_virtual_intf is supposed to return ERR_PTR and trying to
return NULL results in some Unable to handle kernel paging request,
etc. As it may be complicated to debug trace, let's catch it (WARN).
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
net/wireless/nl80211.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1a31736..eeb96c1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2641,7 +2641,10 @@ static int nl80211_new_interface(struct sk_buff *skb,
struct genl_info *info)
wdev = rdev_add_virtual_intf(rdev,
nla_data(info-attrs[NL80211_ATTR_IFNAME]),
type, err ? NULL : flags, params);
- if (IS_ERR(wdev)) {
+ if (WARN_ON(!wdev)) {
+ nlmsg_free(msg);
+ return -EPROTO;
+ } else if (IS_ERR(wdev)) {
nlmsg_free(msg);
return PTR_ERR(wdev);
}
--
1.8.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] mac80211: minstrel_ht: add basic support for VHT rates = 3SS@80MHz
On Fri, Nov 14, 2014 at 07:36:48PM +0200, Jouni Malinen wrote: On Fri, Nov 14, 2014 at 06:18:32PM +0100, Karl Beldan wrote: Yes, only with iw and nothing fancy, I also have had it running on some boards for some weeks as is and with rfc version for more than a year at work (minstrel not the whole tree). I guess I can take the tip of wireless-testing but can you give your HEAD though ? It looks like pretty much any snapshot between master-2014-11-04 and now is affected.. Anyway, the current master snapshot in my tests was 0e204e2422876c18034ca960c4fccf727a02a5c1. For example, with nfc_p2p_go_neg test case: Have you reproduced it with other testcases (maybe more regular so that I can get my hands on it faster) ? Is it also happening when VHT support is not advertized by upper layers ? This seems to be specific to exact timing of frames since the same issue does not show up in non-NFC P2P test cases. So no, this does not show up with anything else than the nfc_p2p_* test cases (well, at least not in my desktop+kvm setup; YMMV with other CPU speeds that could potentially affect timing): nfc_p2p_go_neg nfc_p2p_go_neg_reverse nfc_p2p_ip_addr_assignment nfc_p2p_static_handover_tagdev_client nfc_p2p_static_handover_tagdev_client_group_iface nfc_p2p_static_handover_tagdev_go I'd assume the key here is in P2P with NFC trigger having the fastest possible connection process due to all the optimizations in channel selection on WPS (which is those EAPOL Data frames that hit these rate selection issues immediately after association). That said, if you use the tests/hwsim scripts from git://w1.fi/hostap.git there should be no difference on running some of these cases vs. something more regular.. If you have not used these test scripts previously, you can find more information about the setup here: http://w1.fi/cgit/hostap/plain/tests/hwsim/README http://w1.fi/cgit/hostap/plain/tests/hwsim/vm/README Ok, thanks for your pointers Jouni, I should get back to you soon. Karl -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcmfmac not working on ECS LIVA
On 11/14/14 18:03, Felipe Contreras wrote: On Thu, Nov 13, 2014 at 4:47 AM, Arend van Sprielar...@broadcom.com wrote: On 12-11-14 16:23, Felipe Contreras wrote: On Wed, Nov 12, 2014 at 4:40 AM, Arend van Sprielar...@broadcom.com wrote: I tried this patch, and although it seems to make a difference, it still doesn't work. http://people.freedesktop.org/~felipec/dmesg-brcm-2.txt Hi Felipe, All the messages to the firmware seem ok. If connection would succeed I normally see a LINK event followed by SET_SSID event. In your log I only see the SET_SSID event with failed status, hence the connect is unsuccessful. Do you have any control over the AP? Could you try without WPA security to quickly confirm connection works? May help in root causing the issue. I tried disabled WPA security, it's still not working. Thanks, Felipe Could you check the runtime-pm for mmc1 controller. You need to find sdhci-acpi driver in sysfs. I think it is under /sys/bus/platform/drivers. One of the bound devices is mmc1 (although probably will have different nameing there) and there is subfolder power with file named control. Can you cat that file and do 'echo on control' if it says auto. 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
[RFC] mac80211: send statistics with delete station event
From: Johannes Berg johannes.b...@intel.com
Use the new cfg80211_del_sta_sinfo() function to send the
statistics about the deleted station with the delete event.
This lets userspace see how much traffic etc. the deleted
station used.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/sta_info.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index adc25371b171..bffab579be1b 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -862,6 +862,7 @@ static void __sta_info_destroy_part2(struct sta_info *sta)
{
struct ieee80211_local *local = sta-local;
struct ieee80211_sub_if_data *sdata = sta-sdata;
+ struct station_info sinfo = {};
int ret;
/*
@@ -896,7 +897,8 @@ static void __sta_info_destroy_part2(struct sta_info *sta)
sta_dbg(sdata, Removed STA %pM\n, sta-sta.addr);
- cfg80211_del_sta(sdata-dev, sta-sta.addr, GFP_KERNEL);
+ sta_set_sinfo(sta, sinfo);
+ cfg80211_del_sta_sinfo(sdata-dev, sta-sta.addr, sinfo, GFP_KERNEL);
rate_control_remove_sta_debugfs(sta);
ieee80211_sta_debugfs_remove(sta);
--
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 1/1 net-next] wireless: remove unnecessary sizeof(u8)
sizeof(u8) is always 1.
Signed-off-by: Fabian Frederick f...@skynet.be
---
drivers/net/wireless/b43/ppr.c| 2 +-
drivers/net/wireless/iwlwifi/pcie/trans.c | 2 +-
drivers/net/wireless/rtlwifi/efuse.c | 16
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/b43/ppr.c b/drivers/net/wireless/b43/ppr.c
index 9a77027..6bc1c6f 100644
--- a/drivers/net/wireless/b43/ppr.c
+++ b/drivers/net/wireless/b43/ppr.c
@@ -28,7 +28,7 @@ void b43_ppr_clear(struct b43_wldev *dev, struct b43_ppr *ppr)
memset(ppr, 0, sizeof(*ppr));
/* Compile-time PPR check */
- BUILD_BUG_ON(sizeof(struct b43_ppr) != B43_PPR_RATES_NUM * sizeof(u8));
+ BUILD_BUG_ON(sizeof(struct b43_ppr) != B43_PPR_RATES_NUM);
}
void b43_ppr_add(struct b43_wldev *dev, struct b43_ppr *ppr, int diff)
diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c
b/drivers/net/wireless/iwlwifi/pcie/trans.c
index 836725e..f016824 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -1157,7 +1157,7 @@ static void iwl_trans_pcie_configure(struct iwl_trans
*trans,
trans_pcie-n_no_reclaim_cmds = trans_cfg-n_no_reclaim_cmds;
if (trans_pcie-n_no_reclaim_cmds)
memcpy(trans_pcie-no_reclaim_cmds, trans_cfg-no_reclaim_cmds,
- trans_pcie-n_no_reclaim_cmds * sizeof(u8));
+ trans_pcie-n_no_reclaim_cmds);
trans_pcie-rx_buf_size_8k = trans_cfg-rx_buf_size_8k;
if (trans_pcie-rx_buf_size_8k)
diff --git a/drivers/net/wireless/rtlwifi/efuse.c
b/drivers/net/wireless/rtlwifi/efuse.c
index 0b4082c..a3135c5 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -251,8 +251,8 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16
_size_byte, u8 *pbuf)
}
/* allocate memory for efuse_tbl and efuse_word */
- efuse_tbl = kzalloc(rtlpriv-cfg-maps[EFUSE_HWSET_MAX_SIZE] *
- sizeof(u8), GFP_ATOMIC);
+ efuse_tbl = kzalloc(rtlpriv-cfg-maps[EFUSE_HWSET_MAX_SIZE],
+ GFP_ATOMIC);
if (!efuse_tbl)
return;
efuse_word = kzalloc(EFUSE_MAX_WORD_UNIT * sizeof(u16 *), GFP_ATOMIC);
@@ -733,8 +733,8 @@ static int efuse_pg_packet_read(struct ieee80211_hw *hw, u8
offset, u8 *data)
if (offset 15)
return false;
- memset(data, 0xff, PGPKT_DATA_SIZE * sizeof(u8));
- memset(tmpdata, 0xff, PGPKT_DATA_SIZE * sizeof(u8));
+ memset(data, 0xff, PGPKT_DATA_SIZE);
+ memset(tmpdata, 0xff, PGPKT_DATA_SIZE);
while (continual (efuse_addr EFUSE_MAX_SIZE)) {
if (readstate PG_STATE_HEADER) {
@@ -772,7 +772,7 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw,
u16 *efuse_addr,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct pgpkt_struct tmp_pkt;
int dataempty = true;
- u8 originaldata[8 * sizeof(u8)];
+ u8 originaldata[8];
u8 badworden = 0x0F;
u8 match_word_en, tmp_word_en;
u8 tmpindex;
@@ -881,7 +881,7 @@ static void efuse_write_data_case2(struct ieee80211_hw *hw,
u16 *efuse_addr,
struct pgpkt_struct tmp_pkt;
u8 pg_header;
u8 tmp_header;
- u8 originaldata[8 * sizeof(u8)];
+ u8 originaldata[8];
u8 tmp_word_cnts;
u8 badworden = 0x0F;
@@ -904,7 +904,7 @@ static void efuse_write_data_case2(struct ieee80211_hw *hw,
u16 *efuse_addr,
tmp_word_cnts = efuse_calculate_word_cnts(tmp_pkt.word_en);
- memset(originaldata, 0xff, 8 * sizeof(u8));
+ memset(originaldata, 0xff, 8);
if (efuse_pg_packet_read(hw, tmp_pkt.offset, originaldata)) {
badworden = enable_efuse_data_write(hw,
@@ -962,7 +962,7 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
target_pkt.offset = offset;
target_pkt.word_en = word_en;
- memset(target_pkt.data, 0xFF, 8 * sizeof(u8));
+ memset(target_pkt.data, 0xFF, 8);
efuse_word_enable_data_read(word_en, data, target_pkt.data);
target_word_cnts = efuse_calculate_word_cnts(target_pkt.word_en);
--
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: pull request: wireless 2014-11-13
From: John W. Linville linvi...@tuxdriver.com Date: Thu, 13 Nov 2014 16:28:16 -0500 Please pull this set of a few more wireless fixes intended for the 3.18 stream... Pulled, thanks John. -- 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] brcmfmac: fix error handling of irq_of_parse_and_map
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Signed-off-by: Dmitry Torokhov d...@chromium.org
---
Not tested, found by casual code inspection.
drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/brcm80211/brcmfmac/of.c
index eb3fce82..c824570 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/of.c
@@ -40,8 +40,8 @@ void brcmf_of_probe(struct brcmf_sdio_dev *sdiodev)
return;
irq = irq_of_parse_and_map(np, 0);
- if (irq 0) {
- brcmf_err(interrupt could not be mapped: err=%d\n, irq);
+ if (!irq) {
+ brcmf_err(interrupt could not be mapped\n);
devm_kfree(dev, sdiodev-pdata);
return;
}
--
2.1.0.rc2.206.gedb03e5
--
Dmitry
--
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] NFC: pn544: i2c: fix error handling of irq_of_parse_and_map
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Signed-off-by: Dmitry Torokhov d...@chromium.org
---
Not tested, found by casual code inspection.
drivers/nfc/pn544/i2c.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index 440291a..cfb3f0b 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -918,13 +918,12 @@ static int pn544_hci_i2c_of_request_resources(struct
i2c_client *client)
}
/* IRQ */
- ret = irq_of_parse_and_map(pp, 0);
- if (ret 0) {
- nfc_err(client-dev,
- Unable to get irq, error: %d\n, ret);
+ client-irq = irq_of_parse_and_map(pp, 0);
+ if (!client-irq) {
+ nfc_err(client-dev, Unable to get irq\n);
+ ret = -EINVAL;
goto err_gpio_fw;
}
- client-irq = ret;
return 0;
--
2.1.0.rc2.206.gedb03e5
--
Dmitry
--
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] NFC: st21nfca: fix error handling of irq_of_parse_and_map
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Also report error returned by devm_gpio_request_one instead of
clobbering it with -ENODEV.
Signed-off-by: Dmitry Torokhov d...@chromium.org
---
drivers/nfc/st21nfca/i2c.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index 0ea756b..6d6d282 100644
--- a/drivers/nfc/st21nfca/i2c.c
+++ b/drivers/nfc/st21nfca/i2c.c
@@ -531,20 +531,19 @@ static int st21nfca_hci_i2c_of_request_resources(struct
i2c_client *client)
clf_enable);
if (r) {
nfc_err(client-dev, Failed to request enable pin\n);
- return -ENODEV;
+ return r;
}
phy-gpio_ena = gpio;
/* IRQ */
- r = irq_of_parse_and_map(pp, 0);
- if (r 0) {
- nfc_err(client-dev, Unable to get irq, error: %d\n, r);
- return r;
+ client-irq = irq_of_parse_and_map(pp, 0);
+ if (!client-irq) {
+ nfc_err(client-dev, Unable to get irq\n);
+ return -EINVAL;
}
phy-irq_polarity = irq_get_trigger_type(r);
- client-irq = r;
return 0;
}
--
2.1.0.rc2.206.gedb03e5
--
Dmitry
--
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] NFC: st21nfcb: fix error handling of irq_of_parse_and_map
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Also report error returned by devm_gpio_request_one instead of
clobbering it with -ENODEV.
Signed-off-by: Dmitry Torokhov d...@chromium.org
---
Not tested, found by casual code inspection.
drivers/nfc/st21nfcb/i2c.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/nfc/st21nfcb/i2c.c b/drivers/nfc/st21nfcb/i2c.c
index c5d2427..abe73ec 100644
--- a/drivers/nfc/st21nfcb/i2c.c
+++ b/drivers/nfc/st21nfcb/i2c.c
@@ -258,19 +258,18 @@ static int st21nfcb_nci_i2c_of_request_resources(struct
i2c_client *client)
GPIOF_OUT_INIT_HIGH, clf_reset);
if (r) {
nfc_err(client-dev, Failed to request reset pin\n);
- return -ENODEV;
+ return r;
}
phy-gpio_reset = gpio;
/* IRQ */
- r = irq_of_parse_and_map(pp, 0);
- if (r 0) {
- nfc_err(client-dev, Unable to get irq, error: %d\n, r);
- return r;
+ client-irq = irq_of_parse_and_map(pp, 0);
+ if (!client-irq) {
+ nfc_err(client-dev, Unable to get irq\n);
+ return -EINVAL;
}
phy-irq_polarity = irq_get_trigger_type(r);
- client-irq = r;
return 0;
}
--
2.1.0.rc2.206.gedb03e5
--
Dmitry
--
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
