Re: [PATCH] staging:rtl8723au: core: Fix error reported by checkpatch.
Joe Perches j...@perches.com writes:
On Mon, 2014-10-27 at 09:43 +0100, Jes Sorensen wrote:
Sanjeev Sharma sanjeev_sha...@mentor.com writes:
This is a patch to the rtw_cmd.c file that fixes
Error reported by checkpatch.
[]
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
[]
@@ -957,7 +957,7 @@ static void traffic_status_watchdog(struct rtw_adapter
*padapter)
/* check traffic for powersaving. */
if (((pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod +
pmlmepriv-LinkDetectInfo.NumTxOkInPeriod) 8) ||
- pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod 2)
+ pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod
2)
bEnterPS = false;
else
bEnterPS = true;
This makes the line longer than 80 characters, that is worse than the
'problem' you are fixing.
The code already has dozens of long lines already.
This is generally a problem because the variable names
are pretty long so strict 80 column adherence generally
isn't possible.
It does, but that is not a reason to add more. I have generally tried to
trim it down when I cleaned up pieces of it.
Jes
A possible way to shorten these relatively long variable
name/line lengths is to use a temporary for
pmlmeprv-LinkDetectInfo
struct rt_link_detect *ldi = pmlmeprv-LinkDetectInfo;
so:
drivers/staging/rtl8723au/core/rtw_cmd.c | 46
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index d2d7edf..1b24945 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -922,34 +922,33 @@ 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;
@@ -958,9 +957,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,18 +970,19 @@ static void traffic_status_watchdog(struct rtw_adapter
*padapter)
else
LPS_Leave23a(padapter);
}
- }
Re: [PATCH] ath10k: handle ieee80211 header and payload tracing separately
On Wed, Oct 29, 2014 at 04:05:44PM +0100, Johannes Berg wrote: On Wed, 2014-10-29 at 19:39 +0530, Rajkumar Manoharan wrote: + u32 hdr_len = ieee80211_hdrlen(hdr-frame_control); + trace_ath10k_rx_hdr(ar, hdr, hdr_len); + trace_ath10k_rx_payload(ar, skb-data + hdr_len, skb-len - hdr_len); Another note, since you're taking my suggestion :-) It would be worth hiding that inside the tracepoint's assign function, so instead of passing data/len here you'd pass the full skb, or the full skb data/skb len, like this: ar, skb-data, skb-len to both tracers. Then inside the tracer you can do the hdrlen check, and that way move the code into the tracing so it's not hit when tracing is disabled. Nice. Let me send v2. Thanks once again. -Rajkumar -- 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: Kernel module(r8712u) reload - suspend/resume - systemd
On 30.10.2014 09:52, Lubomir Rintel wrote: On Tue, 2014-10-28 at 00:43 +0100, poma wrote: On 28.10.2014 00:15, Lennart Poettering wrote: On Mon, 27.10.14 23:43, poma (pomidorabelis...@gmail.com) wrote: but is there a better way to do it? This appears to be a kernel driver bug. Please report this issue against the kernel driver in question, systemd is not the right place to work around that. Lennart It's not a bug, it's a feature, just as true for the systemd. :) Given the condition of the entire Linux Wireless LAN stack this can go actually. Correct. Moreover the driver is actually only in the staging/ (crap) tree which means it has known serious quality issues and needs work. You may want to forward your original bug report to Larry Florian. See [1]. [1] https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8712/TODO Lastly, please do _NOT_ cross-post to multiple unrelated mailing lists. The discussion then gets disconnected. Regards, Lubo Thanks Lubo. [1] TODO: - merge Realtek's bugfixes and new features into the driver - switch to use LIB80211 - switch to use MAC80211 - checkpatch.pl fixes - only a few remain ... Guys, is it gonna happen? poma -- 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] wireless: nl80211: Broadcast CMD_NEW_INTERFACE and CMD_DEL_INTERFACE
On Thu, 2014-10-30 at 11:14 +0200, Tomasz Bursztyka wrote: Hi Johannes, It really bloats the*arguments* more than anything, no way to change that, say by sending the delete message before the wdev is destroyed? You mean building the nlmsg before? (sending it would be wrong if the deletion fails afterwards) Ah, I didn't realize that it could fail, but yeah, then it'd be something like msg = build_message(wdev) if (delete(wdev) != 0) free(msg) else send(msg) 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 1/2] cfg80211: 802.11p OCB mode handling
This patch adds new iface type (NL80211_IFTYPE_OCB) representing
the OCB (Outside the Context of a BSS) mode.
When establishing a connection to the network a cfg80211_join_ocb
function is called (particular nl80211_command is added as well).
A mandatory parameters during the ocb_join operation are 'center
frequency' and 'channel width (5/10 MHz)'.
Signed-off-by: Rostislav Lisovy rostislav.lis...@fel.cvut.cz
---
include/net/cfg80211.h | 14 +++
include/net/mac80211.h | 2 +
include/uapi/linux/nl80211.h | 10 +
net/wireless/Makefile| 2 +-
net/wireless/chan.c | 8
net/wireless/core.h | 10 +
net/wireless/nl80211.c | 41
net/wireless/ocb.c | 89
net/wireless/rdev-ops.h | 21 +++
net/wireless/trace.h | 21 +++
net/wireless/util.c | 5 ++-
11 files changed, 221 insertions(+), 2 deletions(-)
create mode 100644 net/wireless/ocb.c
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f67948e..490b3d8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1359,6 +1359,16 @@ struct mesh_setup {
};
/**
+ * struct ocb_setup - 802.11p OCB mode setup configuration
+ * @chandef: defines the channel to use
+ *
+ * These parameters are fixed when connecting to the network
+ */
+struct ocb_setup {
+ struct cfg80211_chan_def chandef;
+};
+
+/**
* struct ieee80211_txq_params - TX queue parameters
* @ac: AC identifier
* @txop: Maximum burst time in units of 32 usecs, 0 meaning disabled
@@ -2433,6 +2443,10 @@ struct cfg80211_ops {
const struct mesh_setup *setup);
int (*leave_mesh)(struct wiphy *wiphy, struct net_device *dev);
+ int (*join_ocb)(struct wiphy *wiphy, struct net_device *dev,
+ struct ocb_setup *setup);
+ int (*leave_ocb)(struct wiphy *wiphy, struct net_device *dev);
+
int (*change_bss)(struct wiphy *wiphy, struct net_device *dev,
struct bss_parameters *params);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 1614b2f..047b0d1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -263,6 +263,7 @@ struct ieee80211_vif_chanctx_switch {
* @BSS_CHANGED_BANDWIDTH: The bandwidth used by this interface changed,
* note that this is only called when it changes after the channel
* context had been assigned.
+ * @BSS_CHANGED_OCB: OCB join status changed
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 10,
@@ -287,6 +288,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_P2P_PS = 119,
BSS_CHANGED_BEACON_INFO = 120,
BSS_CHANGED_BANDWIDTH = 121,
+ BSS_CHANGED_OCB = 122,
/* when adding here, make sure to change ieee80211_reconfig */
};
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index f7daae5..b381ba7 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -746,6 +746,11 @@
* destination %NL80211_ATTR_MAC on the interface identified by
* %NL80211_ATTR_IFINDEX.
*
+ * @NL80211_CMD_JOIN_OCB: Join the OCB network. The center frequency and
+ * bandwidth of a channel must be given.
+ * @NL80211_CMD_LEAVE_OCB: Leave the OCB network -- no special arguments, the
+ * network is determined by the network interface.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -922,6 +927,8 @@ enum nl80211_commands {
NL80211_CMD_GET_MPP,
+ NL80211_CMD_JOIN_OCB,
+ NL80211_CMD_LEAVE_OCB,
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -2074,6 +2081,8 @@ enum nl80211_attrs {
* and therefore can't be created in the normal ways, use the
* %NL80211_CMD_START_P2P_DEVICE and %NL80211_CMD_STOP_P2P_DEVICE
* commands to create and destroy one
+ * @NL80211_IF_TYPE_OCB: Outside Context of a BSS
+ * This mode corresponds to the MIB variable dot11OCBActivated=true
* @NL80211_IFTYPE_MAX: highest interface type number currently defined
* @NUM_NL80211_IFTYPES: number of defined interface types
*
@@ -2093,6 +2102,7 @@ enum nl80211_iftype {
NL80211_IFTYPE_P2P_CLIENT,
NL80211_IFTYPE_P2P_GO,
NL80211_IFTYPE_P2P_DEVICE,
+ NL80211_IFTYPE_OCB,
/* keep last */
NUM_NL80211_IFTYPES,
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index a761670..4c9e39f 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_WEXT_SPY) += wext-spy.o
obj-$(CONFIG_WEXT_PRIV) += wext-priv.o
cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
-cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o
+cfg80211-y += mlme.o ibss.o sme.o chan.o
[PATCH 2/2] mac80211: 802.11p OCB mode support
This patch adds 802.11p OCB (Outside the Context of a BSS) mode
support.
When communicating in OCB mode a mandatory wildcard BSSID
(48 '1' bits) is used.
The EDCA parameters handling function was changed to support
802.11p specific values.
The insertion of a newly discovered STAs is done in the similar way
as in the IBSS mode -- through the deferred insertion.
The OCB mode uses a periodic 'housekeeping task' for expiration of
disconnected STAs (in the similar manner as in the MESH mode).
New Kconfig option for verbose OCB debugging outputs is added.
Signed-off-by: Rostislav Lisovy rostislav.lis...@fel.cvut.cz
---
net/mac80211/Kconfig | 11 ++
net/mac80211/Makefile | 3 +-
net/mac80211/cfg.c | 14 +++
net/mac80211/chan.c| 3 +
net/mac80211/debug.h | 10 ++
net/mac80211/driver-ops.h | 3 +-
net/mac80211/ieee80211_i.h | 29 ++
net/mac80211/iface.c | 23 +
net/mac80211/ocb.c | 251 +
net/mac80211/rx.c | 35 +++
net/mac80211/tx.c | 15 +++
net/mac80211/util.c| 31 +-
net/mac80211/wme.c | 4 +
13 files changed, 425 insertions(+), 7 deletions(-)
create mode 100644 net/mac80211/ocb.c
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 67cf812..75cc680 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -176,6 +176,17 @@ config MAC80211_HT_DEBUG
Do not select this option.
+config MAC80211_OCB_DEBUG
+ bool Verbose OCB debugging
+ depends on MAC80211_DEBUG_MENU
+ ---help---
+ Selecting this option causes mac80211 to print out
+ very verbose OCB debugging messages. It should not
+ be selected on production systems as those messages
+ are remotely triggerable.
+
+ Do not select this option.
+
config MAC80211_IBSS_DEBUG
bool Verbose IBSS debugging
depends on MAC80211_DEBUG_MENU
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index 7273d27..e53671b 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -27,7 +27,8 @@ mac80211-y := \
event.o \
chan.o \
trace.o mlme.o \
- tdls.o
+ tdls.o \
+ ocb.o
mac80211-$(CONFIG_MAC80211_LEDS) += led.o
mac80211-$(CONFIG_MAC80211_DEBUGFS) += \
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index d6b01ad..1530d9f 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -230,6 +230,7 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct
net_device *dev,
case NUM_NL80211_IFTYPES:
case NL80211_IFTYPE_P2P_CLIENT:
case NL80211_IFTYPE_P2P_GO:
+ case NL80211_IFTYPE_OCB:
/* shouldn't happen */
WARN_ON_ONCE(1);
break;
@@ -2018,6 +2019,17 @@ static int ieee80211_leave_ibss(struct wiphy *wiphy,
struct net_device *dev)
return ieee80211_ibss_leave(IEEE80211_DEV_TO_SUB_IF(dev));
}
+static int ieee80211_join_ocb(struct wiphy *wiphy, struct net_device *dev,
+ struct ocb_setup *setup)
+{
+ return ieee80211_ocb_join(IEEE80211_DEV_TO_SUB_IF(dev), setup);
+}
+
+static int ieee80211_leave_ocb(struct wiphy *wiphy, struct net_device *dev)
+{
+ return ieee80211_ocb_leave(IEEE80211_DEV_TO_SUB_IF(dev));
+}
+
static int ieee80211_set_mcast_rate(struct wiphy *wiphy, struct net_device
*dev,
int rate[IEEE80211_NUM_BANDS])
{
@@ -3689,6 +3701,8 @@ const struct cfg80211_ops mac80211_config_ops = {
.join_mesh = ieee80211_join_mesh,
.leave_mesh = ieee80211_leave_mesh,
#endif
+ .join_ocb = ieee80211_join_ocb,
+ .leave_ocb = ieee80211_leave_ocb,
.change_bss = ieee80211_change_bss,
.set_txq_params = ieee80211_set_txq_params,
.set_monitor_channel = ieee80211_set_monitor_channel,
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 4c74e8d..3d90c2a 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -270,6 +270,7 @@ ieee80211_get_chanctx_max_required_bw(struct
ieee80211_local *local,
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_WDS:
case NL80211_IFTYPE_MESH_POINT:
+ case NL80211_IFTYPE_OCB:
width = vif-bss_conf.chandef.width;
break;
case NL80211_IFTYPE_UNSPECIFIED:
@@ -674,6 +675,7 @@ void ieee80211_recalc_smps_chanctx(struct ieee80211_local
*local,
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_WDS:
case NL80211_IFTYPE_MESH_POINT:
+ case NL80211_IFTYPE_OCB:
break;
default:
WARN_ON_ONCE(1);
@@ -909,6 +911,7 @@ ieee80211_vif_chanctx_reservation_complete(struct
ieee80211_sub_if_data *sdata)
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_AP:
case
Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
The cover-letter subject is wrong. :) I guess you meant s/iwlwifi/rtlwifi/ ;) -- Luca. On Wed, 2014-10-29 at 23:17 -0500, Larry Finger wrote: Some late changes to rtlwifi made some of the older drivers not start correctly. These patches should be applied to 3.18. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Murilo Opsfelder Araujo mopsfel...@gmail.com Larry Finger (6): rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing get_btc_status rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw() rtlwifi: rtl8192se: Add missing section to read descriptor setting rtlwifi: rtl8192ce: Add missing section to read descriptor setting rtlwifi: rtl8821ae: Remove extra semicolons rtlwifi: rtl8192se: Fix firmware loading drivers/net/wireless/rtlwifi/core.c | 6 ++ drivers/net/wireless/rtlwifi/core.h | 1 + drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 2 ++ drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 1 + drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 3 +++ drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 1 + drivers/net/wireless/rtlwifi/rtl8192se/def.h | 2 ++ drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 22 +++--- drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 3 +++ drivers/net/wireless/rtlwifi/rtl8821ae/phy.c | 12 ++-- 10 files changed, 28 insertions(+), 25 deletions(-) -- 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 -stable] wireless: rt2x00: add new rt2800usb devices
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: sta...@vger.kernel.org
Acked-by: Stanislaw Gruszka sgrus...@redhat.com
Cc: Stanislaw Gruszka sgrus...@redhat.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
---
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 832006b..573897b 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) },
--
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
[PATCH -stable] rt2x00: support Ralink 5362.
From: Canek Peláez Valdés ca...@ciencias.unam.mx
Cc: sta...@vger.kernel.org
Acked-by: Stanislaw Gruszka sgrus...@redhat.com
Cc: Stanislaw Gruszka sgrus...@redhat.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: Canek Peláez Valdés ca...@ciencias.unam.mx
Signed-off-by: John W. Linville linvi...@tuxdriver.com
---
drivers/net/wireless/rt2x00/rt2800.h| 4 +++-
drivers/net/wireless/rt2x00/rt2800lib.c | 6 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h
b/drivers/net/wireless/rt2x00/rt2800.h
index a394a9a..b7434df 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -52,6 +52,7 @@
* RF5592 2.4G/5G 2T2R
* RF3070 2.4G 1T1R
* RF5360 2.4G 1T1R
+ * RF5362 2.4G 1T1R
* RF5370 2.4G 1T1R
* RF5390 2.4G 1T1R
*/
@@ -72,6 +73,7 @@
#define RF3070 0x3070
#define RF3290 0x3290
#define RF5360 0x5360
+#define RF5362 0x5362
#define RF5370 0x5370
#define RF5372 0x5372
#define RF5390 0x5390
@@ -2145,7 +2147,7 @@ struct mac_iveiv_entry {
/* Bits [7-4] for RF3320 (RT3370/RT3390), on other chipsets reserved */
#define RFCSR3_PA1_BIAS_CCKFIELD8(0x70)
#define RFCSR3_PA2_CASCODE_BIAS_CCKK FIELD8(0x80)
-/* Bits for RF3290/RF5360/RF5370/RF5372/RF5390/RF5392 */
+/* Bits for RF3290/RF5360/RF5362/RF5370/RF5372/RF5390/RF5392 */
#define RFCSR3_VCOCAL_EN FIELD8(0x80)
/* Bits for RF3050 */
#define RFCSR3_BIT1FIELD8(0x02)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 893c9d5..9f57a2d 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -3186,6 +3186,7 @@ static void rt2800_config_channel(struct rt2x00_dev
*rt2x00dev,
break;
case RF3070:
case RF5360:
+ case RF5362:
case RF5370:
case RF5372:
case RF5390:
@@ -3203,6 +3204,7 @@ static void rt2800_config_channel(struct rt2x00_dev
*rt2x00dev,
rt2x00_rf(rt2x00dev, RF3290) ||
rt2x00_rf(rt2x00dev, RF3322) ||
rt2x00_rf(rt2x00dev, RF5360) ||
+ rt2x00_rf(rt2x00dev, RF5362) ||
rt2x00_rf(rt2x00dev, RF5370) ||
rt2x00_rf(rt2x00dev, RF5372) ||
rt2x00_rf(rt2x00dev, RF5390) ||
@@ -4317,6 +4319,7 @@ void rt2800_vco_calibration(struct rt2x00_dev *rt2x00dev)
case RF3070:
case RF3290:
case RF5360:
+ case RF5362:
case RF5370:
case RF5372:
case RF5390:
@@ -7095,6 +7098,7 @@ static int rt2800_init_eeprom(struct rt2x00_dev
*rt2x00dev)
case RF3320:
case RF3322:
case RF5360:
+ case RF5362:
case RF5370:
case RF5372:
case RF5390:
@@ -7551,6 +7555,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
*rt2x00dev)
case RF3320:
case RF3322:
case RF5360:
+ case RF5362:
case RF5370:
case RF5372:
case RF5390:
@@ -7680,6 +7685,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
*rt2x00dev)
case RF3070:
case RF3290:
case RF5360:
+ case RF5362:
case RF5370:
case RF5372:
case RF5390:
--
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 2/3] mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO
Hi Johannes,
On ke, 2014-10-29 at 16:53 +0100, Johannes Berg wrote:
On Wed, 2014-10-29 at 16:50 +0100, Johannes Berg wrote:
On Mon, 2014-10-27 at 12:44 +0200, Jukka Rissanen wrote:
+static void mcast_msg(struct sk_buff *mcast_skb, struct genl_info *info)
+{
+ if (info)
+ genl_notify(hwsim_genl_family, mcast_skb,
+ genl_info_net(info), info-snd_portid,
+ HWSIM_MCGRP_CONFIG, info-nlhdr, GFP_KERNEL);
+ else
+ genlmsg_multicast(hwsim_genl_family, mcast_skb, 0,
+ HWSIM_MCGRP_CONFIG, GFP_KERNEL);
+}
Also - given the parameters and what this does, that's a bad name for
the function. Never mind that it doesn't have any sort of identifier
(say hwsim_ prefix), it doesn't even do what it says it does.
Or maybe it does? I'm unsure what genl_notify() does...
Yes, genl_notify() will eventually call nlmsg_notify() which will
multicast the message because we have set the group id in the call.
http://lxr.free-electrons.com/source/net/netlink/af_netlink.c#L2856
Cheers,
Jukka
--
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] staging:rtl8723au: core: Fix error reported by checkpatch.
Sharma, Sanjeev sanjeev_sha...@mentor.com writes: -Original Message- From: Jes Sorensen [mailto:jes.soren...@redhat.com] Sent: Monday, October 27, 2014 2:13 PM To: Sharma, Sanjeev Cc: larry.fin...@lwfinger.net; gre...@linuxfoundation.org; linux-wireless@vger.kernel.org; de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] staging:rtl8723au: core: Fix error reported by checkpatch. Sanjeev Sharma sanjeev_sha...@mentor.com writes: This is a patch to the rtw_cmd.c file that fixes Error reported by checkpatch. Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com --- drivers/staging/rtl8723au/core/rtw_cmd.c | 83 +++- 1 file changed, 40 insertions(+), 43 deletions(-) diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c b/drivers/staging/rtl8723au/core/rtw_cmd.c index 4eaa502..c1f6254 100644 --- a/drivers/staging/rtl8723au/core/rtw_cmd.c +++ b/drivers/staging/rtl8723au/core/rtw_cmd.c @@ -957,7 +957,7 @@ static void traffic_status_watchdog(struct rtw_adapter *padapter) /* check traffic for powersaving. */ if (((pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod + pmlmepriv-LinkDetectInfo.NumTxOkInPeriod) 8) || -pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod 2) +pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod 2) bEnterPS = false; else bEnterPS = true; This makes the line longer than 80 characters, that is worse than the 'problem' you are fixing. Jes Hello jes, How it can be worse because checkpatch treating this as an Error and line longer than 80 character is warning reported by checkpatch and I could see that in entire staging directory, every maintainer most of the time ignore the 80 column limit and give priority to Error. Please let me know your comment . Sanjeev Sharma checkpatch has it's ideas, doesn't mean it's blindly right at all times. In this particular case it keeps the code more readable to keep it below 80 characters than it does to add those two blanks and make the line longer. I agree the long variable names are nasty, and it doesn't help they were done in StUdLyCaPs. If you want to attack it from that front, please go ahead. However, on formatting, please respond with proper email using proper quoting when replying. Thanks, Jes -- 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] staging:rtl8723au: core: Fix error reported by checkpatch.
Sharma, Sanjeev sanjeev_sha...@mentor.com writes:
-Original Message-
From: Joe Perches [mailto:j...@perches.com]
Sent: Monday, October 27, 2014 8:23 PM
To: Jes Sorensen
Cc: Sharma, Sanjeev; larry.fin...@lwfinger.net;
gre...@linuxfoundation.org; linux-wireless@vger.kernel.org;
de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH] staging:rtl8723au: core: Fix error reported by
checkpatch.
On Mon, 2014-10-27 at 09:43 +0100, Jes Sorensen wrote:
Sanjeev Sharma sanjeev_sha...@mentor.com writes:
This is a patch to the rtw_cmd.c file that fixes Error reported by
checkpatch.
[]
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
[]
@@ -957,7 +957,7 @@ static void traffic_status_watchdog(struct rtw_adapter
*padapter)
/* check traffic for powersaving. */
if (((pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod +
pmlmepriv-LinkDetectInfo.NumTxOkInPeriod) 8) ||
- pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod 2)
+ pmlmepriv-LinkDetectInfo.NumRxUnicastOkInPeriod
2)
bEnterPS = false;
else
bEnterPS = true;
This makes the line longer than 80 characters, that is worse than the
'problem' you are fixing.
The code already has dozens of long lines already.
This is generally a problem because the variable names are pretty long so
strict 80 column adherence generally isn't possible.
A possible way to shorten these relatively long variable name/line lengths is
to use a temporary for
pmlmeprv-LinkDetectInfo
struct rt_link_detect *ldi = pmlmeprv-LinkDetectInfo;
so:
I am agree on this approach but Let's wait for Jes opinion on it.
Sanjeev Sharma
drivers/staging/rtl8723au/core/rtw_cmd.c | 46
1 file changed, 23 insertions(+), 23 deletions(-)
This is fine with me.
Jes
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index d2d7edf..1b24945 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -922,34 +922,33 @@ 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;
@@ -958,9 +957,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)
Re: [PATCH] net: rfkill: gpio: Add default GPIO driver mappings for ACPI
On Mon, Oct 27, 2014 at 11:15 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
The driver uses devm_gpiod_get_index(..., index) so that the index refers
directly to the GpioIo resource under the ACPI device. The problem with
this is that if the ordering changes we get wrong GPIOs.
With ACPI 5.1 _DSD we can now use names instead to reference GPIOs
analogous to Device Tree. However, we still have systems out there that do
not provide _DSD at all. These systems must be supported as well.
Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide
mappings for systems where _DSD is not provided and still take advantage of
_DSD if it exists.
This patch changes the driver to create default GPIO mappings if we are
running on ACPI system.
While there we can drop the indices completely and use devm_gpiod_get()
with name instead.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
---
Hi,
This patch is based on top of linux-pm/device-properties [1] and following
patch from Rafael [2].
Johannes, John,
If you are happy with the patch, can you ACK it so that we can merge it
with the rest of the device-properties patches. Thanks.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
[2] https://lkml.org/lkml/2014/10/24/690
(...)
+static const struct acpi_gpio_params reset_gpios = { 0, 0, false };
+static const struct acpi_gpio_params shutdown_gpios = { 1, 0, false };
+
+static const struct acpi_gpio_mapping acpi_rfkill_default_gpios[] = {
+ { reset-gpios, reset_gpios, 1 },
+ { shutdown-gpios, shutdown_gpios, 1 },
+ { },
+};
Jaysis, it could use a comment above the map telling the poor code
reader what is actually going on.
Other than that, this is what we have to live with I guess so:
Acked-by: Linus Walleij linus.wall...@linaro.org
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
On 10/30/2014 06:08 AM, Luca Coelho wrote: The cover-letter subject is wrong. :) I guess you meant s/iwlwifi/rtlwifi/ ;) Yes, the changes were for rtlwifi, not iwlwifi. Sorry. (: My laptop has an Intel 7260 card built in, and it is working correctly on both 2.4 and 5G bands under mainline 3.18-rc2. Those types of errors are what I get for trying to work while on a family vacation. Unfortunately, I needed to submit those patches quickly to prevent a set of conflicting updates from being accepted, and I made a silly mistake. Larry -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] mac80211-hwsim: Provide multicast event for HWSIM_CMD_DEL_RADIO
When deleting old radio via HWSIM_CMD_DEL_RADIO then listeners on the
multicast group config are informed.
Signed-off-by: Jukka Rissanen jukka.rissa...@linux.intel.com
---
drivers/net/wireless/mac80211_hwsim.c | 43 ++-
1 file changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index ff187fe..909777c 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2305,8 +2305,39 @@ failed:
return err;
}
-static void mac80211_hwsim_destroy_radio(struct mac80211_hwsim_data *data)
+static void hwsim_mcast_del_radio(int id, struct genl_info *info)
{
+ struct sk_buff *mcast_skb;
+ void *data;
+ int ret;
+
+ mcast_skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!mcast_skb)
+ return;
+
+ data = genlmsg_put(mcast_skb, 0, 0, hwsim_genl_family, 0,
+ HWSIM_CMD_DEL_RADIO);
+ if (!data)
+ goto error;
+
+ ret = nla_put_u32(mcast_skb, HWSIM_ATTR_RADIO_ID, id);
+ if (ret 0)
+ goto error;
+
+ genlmsg_end(mcast_skb, data);
+
+ hwsim_mcast_config_msg(mcast_skb, info);
+
+ return;
+
+error:
+ nlmsg_free(mcast_skb);
+}
+
+static void mac80211_hwsim_del_radio(struct mac80211_hwsim_data *data,
+struct genl_info *info)
+{
+ hwsim_mcast_del_radio(data-idx, info);
debugfs_remove_recursive(data-debugfs);
ieee80211_unregister_hw(data-hw);
device_release_driver(data-dev);
@@ -2324,7 +2355,7 @@ static void mac80211_hwsim_free(void)
list))) {
list_del(data-list);
spin_unlock_bh(hwsim_radio_lock);
- mac80211_hwsim_destroy_radio(data);
+ mac80211_hwsim_del_radio(data, NULL);
spin_lock_bh(hwsim_radio_lock);
}
spin_unlock_bh(hwsim_radio_lock);
@@ -2573,7 +2604,7 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct
genl_info *info)
return mac80211_hwsim_new_radio(info, param);
}
-static int hwsim_destroy_radio_nl(struct sk_buff *msg, struct genl_info *info)
+static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
{
struct mac80211_hwsim_data *data;
int idx;
@@ -2588,7 +2619,7 @@ static int hwsim_destroy_radio_nl(struct sk_buff *msg,
struct genl_info *info)
continue;
list_del(data-list);
spin_unlock_bh(hwsim_radio_lock);
- mac80211_hwsim_destroy_radio(data);
+ mac80211_hwsim_del_radio(data, info);
return 0;
}
spin_unlock_bh(hwsim_radio_lock);
@@ -2621,9 +2652,9 @@ static const struct genl_ops hwsim_ops[] = {
.flags = GENL_ADMIN_PERM,
},
{
- .cmd = HWSIM_CMD_DESTROY_RADIO,
+ .cmd = HWSIM_CMD_DEL_RADIO,
.policy = hwsim_genl_policy,
- .doit = hwsim_destroy_radio_nl,
+ .doit = hwsim_del_radio_nl,
.flags = GENL_ADMIN_PERM,
},
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO
When adding new radio via HWSIM_CMD_NEW_RADIO then listeners on the
multicast group config are informed.
Signed-off-by: Jukka Rissanen jukka.rissa...@linux.intel.com
---
drivers/net/wireless/mac80211_hwsim.c | 242 +-
1 file changed, 179 insertions(+), 63 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index babbdc1..ff187fe 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -476,6 +476,14 @@ static struct genl_family hwsim_genl_family = {
.maxattr = HWSIM_ATTR_MAX,
};
+enum hwsim_multicast_groups {
+ HWSIM_MCGRP_CONFIG,
+};
+
+static const struct genl_multicast_group hwsim_mcgrps[] = {
+ [HWSIM_MCGRP_CONFIG] = { .name = config, },
+};
+
/* MAC80211_HWSIM netlink policy */
static const struct nla_policy hwsim_genl_policy[HWSIM_ATTR_MAX + 1] = {
@@ -1943,10 +1951,114 @@ static const struct ieee80211_ops mac80211_hwsim_ops =
{
static struct ieee80211_ops mac80211_hwsim_mchan_ops;
-static int mac80211_hwsim_create_radio(int channels, const char *reg_alpha2,
- const struct ieee80211_regdomain *regd,
- bool reg_strict, bool p2p_device,
- bool use_chanctx)
+struct hwsim_new_radio_params {
+ unsigned int channels;
+ const char *reg_alpha2;
+ const struct ieee80211_regdomain *regd;
+ bool reg_strict;
+ bool p2p_device;
+ bool use_chanctx;
+};
+
+static void hwsim_mcast_config_msg(struct sk_buff *mcast_skb,
+ struct genl_info *info)
+{
+ if (info)
+ genl_notify(hwsim_genl_family, mcast_skb,
+ genl_info_net(info), info-snd_portid,
+ HWSIM_MCGRP_CONFIG, info-nlhdr, GFP_KERNEL);
+ else
+ genlmsg_multicast(hwsim_genl_family, mcast_skb, 0,
+ HWSIM_MCGRP_CONFIG, GFP_KERNEL);
+}
+
+static struct sk_buff *build_radio_msg(int cmd, int id,
+ struct hwsim_new_radio_params *param)
+{
+ struct sk_buff *skb;
+ void *data;
+ int ret;
+
+ skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!skb)
+ return NULL;
+
+ data = genlmsg_put(skb, 0, 0, hwsim_genl_family, 0, cmd);
+ if (!data)
+ goto error;
+
+ ret = nla_put_u32(skb, HWSIM_ATTR_RADIO_ID, id);
+ if (ret 0)
+ goto error;
+
+ if (param-channels) {
+ ret = nla_put_u32(skb, HWSIM_ATTR_CHANNELS, param-channels);
+ if (ret 0)
+ goto error;
+ }
+
+ if (param-reg_alpha2) {
+ ret = nla_put(skb, HWSIM_ATTR_REG_HINT_ALPHA2, 2,
+ param-reg_alpha2);
+ if (ret 0)
+ goto error;
+ }
+
+ if (param-regd) {
+ int i;
+
+ for (i = 0; hwsim_world_regdom_custom[i] != param-regd
+i ARRAY_SIZE(hwsim_world_regdom_custom); i++)
+ ;
+
+ if (i ARRAY_SIZE(hwsim_world_regdom_custom)) {
+ ret = nla_put_u32(skb, HWSIM_ATTR_REG_CUSTOM_REG, i);
+ if (ret 0)
+ goto error;
+ }
+ }
+
+ if (param-reg_strict) {
+ ret = nla_put_flag(skb, HWSIM_ATTR_REG_STRICT_REG);
+ if (ret 0)
+ goto error;
+ }
+
+ if (param-p2p_device) {
+ ret = nla_put_flag(skb, HWSIM_ATTR_SUPPORT_P2P_DEVICE);
+ if (ret 0)
+ goto error;
+ }
+
+ if (param-use_chanctx) {
+ ret = nla_put_flag(skb, HWSIM_ATTR_USE_CHANCTX);
+ if (ret 0)
+ goto error;
+ }
+
+ genlmsg_end(skb, data);
+
+ return skb;
+
+error:
+ nlmsg_free(skb);
+ return NULL;
+}
+
+static void hswim_mcast_new_radio(int id, struct genl_info *info,
+ struct hwsim_new_radio_params *param)
+{
+ struct sk_buff *mcast_skb;
+
+ mcast_skb = build_radio_msg(HWSIM_CMD_NEW_RADIO, id, param);
+ if (!mcast_skb)
+ return;
+
+ hwsim_mcast_config_msg(mcast_skb, info);
+}
+
+static int mac80211_hwsim_new_radio(struct genl_info *info,
+ struct hwsim_new_radio_params *param)
{
int err;
u8 addr[ETH_ALEN];
@@ -1956,14 +2068,14 @@ static int mac80211_hwsim_create_radio(int channels,
const char *reg_alpha2,
const struct ieee80211_ops *ops = mac80211_hwsim_ops;
int idx;
- if (WARN_ON(channels 1 !use_chanctx))
+ if (WARN_ON(param-channels 1 !param-use_chanctx))
return -EINVAL;
[PATCH v2 0/2] Add mcast event when hwsim radios are created and removed
Hi, v2: - removed old patch 1 as that is already applied - added suitable prefixes to new function names - refactored the patch 1 so that multicast message building is separated into a more generic function - instead of passing radio parameters (6 pcs) into different functions separately, a struct is used instead v1: patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more fitting on how other pieces of the wireless system work. A define to old name is provided for backward compatibility. Patches 2 and 3 use the newly named enums and provide a way to inform the listeners on the multicast group config when new radio is created and existing radio is deleted. Jukka Rissanen (2): mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO mac80211-hwsim: Provide multicast event for HWSIM_CMD_DEL_RADIO drivers/net/wireless/mac80211_hwsim.c | 285 ++ 1 file changed, 216 insertions(+), 69 deletions(-) -- 1.8.3.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: strange MPDU loss pattern
Hi Adrian, We observed that this can happen for any rate for some SNR values. If the SNR is strong enough for the given MCS this won't happen. But when the SNR approaches the transition region when error rate starts to increase, this problem will be observed. So this can happen even for MCS0-MCS4 when the client is far from the AP and specially when it's moving. Thanks, Ali On 14-10-29 04:34 PM, Adrian Chadd wrote: Just finally - MCS20 - MCS23 are very sensitive to changing channel anything. See if you can find or make some required SNR curves for each MCS rate. So although it doesn't surprise me to find this is happening, it's very cute that someone's gone and done the work of figuring out how to improve the rate control algorithm to take it into account. I'm kinda thinking about how to do that with FreeBSD right now. Do you get the same pattern on say, MCS0-MCS4 over a 4ms long aggregate frame? -adrian On 25 October 2014 13:35, Ali Abedi a2ab...@uwaterloo.ca wrote: Thank you for sharing the story. Even if I consider interference as a possibility, still I can't justify the higher chance of frame loss in the second half of the aggregate frame. We use PCI-express 3 antenna dual band cards product: AR93xx Wireless Network Adapter and/or Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop we also tried TP-LINK TL-WDN4200 N900 as the receiver. However we see the same results. we mostly use MCS 20-23, sgi = 0, 20 MHz channels. The loss pattern is something like this (each line is an imaginary aggregated frame and each bit is the fate of the MPDU) 00011 11100011010110100 1 111010100 110010101 The interesting part is that with the start of the next frame error rate goes down initially then it goes up again in the second portion of the packet. Best, Ali On 25/10/2014 2:30 PM, Adrian Chadd wrote: On 25 October 2014 08:28, Ali Abedi a2ab...@uwaterloo.ca wrote: Hi Adrian, We have a high end spectrum analyzer. So we are sure there is no background interference We run our experiments in the 5 GHZ spectrum. The channel conditions can still vary due to the movement of the people in the vicinity of the experiment setup. We select a rate that experiences at least 20% error on average. Since if the error is 100% or 0% it's not interesting for us. My point is if the channel conditions change the distribution of failed packets should be uniform. The first and second half of the packets have the same chance to be received successfully. Here's a little story. My first wifi contract had me spend months trying to figure out why an AP was losing its mind. It'd get stuck in a stuck beacon loop and only a hard powercycle of /all/ of the access points in an area would clear it. It turned out that the PCB design had some non-grounded / non-populated tracks that just happened to form a 2GHz resonator. Once we grounded those tracks, the APs started behaving themselves. The company in question spent months with high end spectrum analysis kit in the lab (where it never happened) and underground (where it did happen.) It's only after they stuck the spectrum analyser probe _inside the access point_ right up close to the NIC did they see it. Here's the spectrum analyser traces. You can see the peak. http://www.creative.net.au/ath/ So, weirder crap has happened. Which NICs and which MCS rates are you using? -adrian -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange MPDU loss pattern
On 30 October 2014 08:48, Ali Abedi a2ab...@uwaterloo.ca wrote: Hi Adrian, We observed that this can happen for any rate for some SNR values. If the SNR is strong enough for the given MCS this won't happen. But when the SNR approaches the transition region when error rate starts to increase, this problem will be observed. So this can happen even for MCS0-MCS4 when the client is far from the AP and specially when it's moving. Right. That's the missing useful information here. :) Yes, I'd expect this happens whilst the client is moving. The training stuff is all done on the beginning of the packet and channel conditions aren't adjusted during packet reception - only upon the next received packet. (FYI - I've seen a similar pattern, but when i stand between the AP / STA at MCS13 and start waving my hands around. Just that slight change in channel conditions == the above failure.) So thanks for reminding us that we should take A-MPDU length into account in our rate control code. :) -adrian -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange MPDU loss pattern
The paper mentioned that this happens when the client is mobile. But I confirm Adrian's observation . This problem happens even in stationary environments with dynamic channels (e.g., people moving in the vicinity of the AP/Client). Best, Ali On 14-10-30 12:11 PM, Adrian Chadd wrote: On 30 October 2014 08:48, Ali Abedi a2ab...@uwaterloo.ca wrote: Hi Adrian, We observed that this can happen for any rate for some SNR values. If the SNR is strong enough for the given MCS this won't happen. But when the SNR approaches the transition region when error rate starts to increase, this problem will be observed. So this can happen even for MCS0-MCS4 when the client is far from the AP and specially when it's moving. Right. That's the missing useful information here. :) Yes, I'd expect this happens whilst the client is moving. The training stuff is all done on the beginning of the packet and channel conditions aren't adjusted during packet reception - only upon the next received packet. (FYI - I've seen a similar pattern, but when i stand between the AP / STA at MCS13 and start waving my hands around. Just that slight change in channel conditions == the above failure.) So thanks for reminding us that we should take A-MPDU length into account in our rate control code. :) -adrian -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: iwlwifi-next 2014-10-29
On Wed, Oct 29, 2014 at 01:48:50PM +0200, Emmanuel Grumbach wrote: Hi John, Here is a pull request for 3.19. More details below. Thanks! The following changes since commit 35a9ad8af0bb0fa3525e6d0d20e32551d226f38e: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2014-10-08 21:40:54 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-john-2014-10-29 for you to fetch changes up to d9e4d61c5b900f6938b4aa49f25a0db37aeb23b6: iwlwifi: mvm: unref SCAN ref on scan completion (2014-10-29 13:14:41 +0200) The big new thing here is netdetect which allows the firmware to wake up the platform when a specific network is detected. Along with that I have fixes for d3 operation. The usual amount of rate scaling stuff - we now support STBC. The other commit that stands out is Johannes's work on devcoredump. He basically starts to use the standard infrastructure he built. 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 0/3] debugfs: adding helper for single seq_file
On Tue, Oct 28, 2014 at 01:19:09PM +0100, Arend van Spriel wrote: The first patch was already posted earlier: Message-ID: 1413043315-22332-1-git-send-email-ar...@broadcom.com This series include changes in driver code to investigate potential code savings. As example used the ath9k driver as it has a fair amount of debugfs files. In this series it changes 7 debugfs entries to use seq_file and the helper function. Below the output of the size utility: text data bss dec hex filename 115968 1225 28 117221 1c9e5 original/ath9k.o 113224 1225 28 114477 1bf2d seq_file/ath9k.o 111024 1225 28 112277 1b695 helper/ath9k.o This series is for 3.19 kernel and applies to the driver-core-next branch of the driver-core repository. If needed the ath9k patches may be dropped for now and I will resubmit them to wireless-next once the debugfs patch has made it into linux-next. Arend van Spriel (3): debugfs: add helper function to create device related seq_file ath: use seq_file api for ath9k debugfs files ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries Greg, If you are happy with the debugfs change then feel free to merge the wireless patches along with it. John drivers/net/wireless/ath/ath9k/ahb.c | 1 + drivers/net/wireless/ath/ath9k/debug.c | 429 +++-- drivers/net/wireless/ath/ath9k/debug.h | 3 +- drivers/net/wireless/ath/ath9k/pci.c | 1 + fs/debugfs/file.c | 54 + include/linux/debugfs.h| 16 +- 6 files changed, 207 insertions(+), 297 deletions(-) -- 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 -- 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 0/3] debugfs: adding helper for single seq_file
On Thu, Oct 30, 2014 at 03:19:22PM -0400, John W. Linville wrote: On Tue, Oct 28, 2014 at 01:19:09PM +0100, Arend van Spriel wrote: The first patch was already posted earlier: Message-ID: 1413043315-22332-1-git-send-email-ar...@broadcom.com This series include changes in driver code to investigate potential code savings. As example used the ath9k driver as it has a fair amount of debugfs files. In this series it changes 7 debugfs entries to use seq_file and the helper function. Below the output of the size utility: textdata bss dec hex filename 1159681225 28 117221 1c9e5 original/ath9k.o 1132241225 28 114477 1bf2d seq_file/ath9k.o 1110241225 28 112277 1b695 helper/ath9k.o This series is for 3.19 kernel and applies to the driver-core-next branch of the driver-core repository. If needed the ath9k patches may be dropped for now and I will resubmit them to wireless-next once the debugfs patch has made it into linux-next. Arend van Spriel (3): debugfs: add helper function to create device related seq_file ath: use seq_file api for ath9k debugfs files ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries Greg, If you are happy with the debugfs change then feel free to merge the wireless patches along with it. Ok, will do, can I get your Ack for them? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] debugfs: adding helper for single seq_file
On 10/30/14 20:39, Greg Kroah-Hartman wrote: On Thu, Oct 30, 2014 at 03:19:22PM -0400, John W. Linville wrote: On Tue, Oct 28, 2014 at 01:19:09PM +0100, Arend van Spriel wrote: The first patch was already posted earlier: Message-ID:1413043315-22332-1-git-send-email-ar...@broadcom.com This series include changes in driver code to investigate potential code savings. As example used the ath9k driver as it has a fair amount of debugfs files. In this series it changes 7 debugfs entries to use seq_file and the helper function. Below the output of the size utility: text data bss dec hex filename 115968 1225 28 117221 1c9e5 original/ath9k.o 113224 1225 28 114477 1bf2d seq_file/ath9k.o 111024 1225 28 112277 1b695 helper/ath9k.o This series is for 3.19 kernel and applies to the driver-core-next branch of the driver-core repository. If needed the ath9k patches may be dropped for now and I will resubmit them to wireless-next once the debugfs patch has made it into linux-next. Arend van Spriel (3): debugfs: add helper function to create device related seq_file ath: use seq_file api for ath9k debugfs files ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries Greg, If you are happy with the debugfs change then feel free to merge the wireless patches along with it. Ok, will do, can I get your Ack for them? I saw a patch from Dan Carpenter on one of the functions I converted so if John has taken that one [1] it may give merge conflict in linux-next. Regards, Arend [1] http://mid.gmane.org/20141029154805.GC5290@mwanda thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
On 10/30/14 16:27, Larry Finger wrote: On 10/30/2014 06:08 AM, Luca Coelho wrote: The cover-letter subject is wrong. :) I guess you meant s/iwlwifi/rtlwifi/ ;) Yes, the changes were for rtlwifi, not iwlwifi. Sorry. (: My laptop has an Intel 7260 card built in, and it is working correctly on both 2.4 and 5G bands under mainline 3.18-rc2. Those types of errors are what I get for trying to work while on a family vacation. Unfortunately, I needed to submit those patches quickly to prevent a set of conflicting updates from being accepted, and I made a silly mistake. Don't let it spoil your vacation ;-) Regards, Arend Larry -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
On 10/30/2014 02:17 AM, Larry Finger wrote: Some late changes to rtlwifi made some of the older drivers not start correctly. These patches should be applied to 3.18. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Murilo Opsfelder Araujo mopsfel...@gmail.com Larry Finger (6): rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing get_btc_status rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw() rtlwifi: rtl8192se: Add missing section to read descriptor setting rtlwifi: rtl8192ce: Add missing section to read descriptor setting rtlwifi: rtl8821ae: Remove extra semicolons rtlwifi: rtl8192se: Fix firmware loading drivers/net/wireless/rtlwifi/core.c | 6 ++ drivers/net/wireless/rtlwifi/core.h | 1 + drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 2 ++ drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 1 + drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 3 +++ drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 1 + drivers/net/wireless/rtlwifi/rtl8192se/def.h | 2 ++ drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 22 +++--- drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 3 +++ drivers/net/wireless/rtlwifi/rtl8821ae/phy.c | 12 ++-- 10 files changed, 28 insertions(+), 25 deletions(-) Hi, Larry. I've applied this patchset on top of next-20141030 and got the same result: kernel panic went away but the rtl8192se device does not associate. Thanks anyway for dedicating your family time to trying to get this fixed. We can talk about that later when you're back on regular schedule. Appreciated! -- Murilo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: avoid possible deadlock with scan timeout
Michal Kazior michal.kaz...@tieto.com writes:
This should prevent deadlock predicted by the
following splat:
==
[ INFO: possible circular locking dependency detected ]
3.17.0-wl-ath+ #67 Not tainted
---
kworker/u32:1/7230 is trying to acquire lock:
(ar-conf_mutex){+.+.+.}, at: [a040a57d]
ath10k_scan_timeout_work+0x2d/0x50 [ath10k_core]
but task is already holding lock:
(((ar-scan.timeout)-work)){+.+...}, at: [8106dae1]
process_one_work+0x151/0x470
which lock already depends on the new lock.
[...]
*** DEADLOCK ***
Reported-by: Marek Puzyniak marek.puzyn...@tieto.com
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
Thanks, applied.
--
Kalle Valo
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] ath10k: speed up recovery
Michal Kazior michal.kaz...@tieto.com writes: Patch #1 fixes a bug I've found while testing patches #2 and #3. It's safe to cherry-pick it in case patches #2 and/or #3 aren't accepted or need a re-spin. I've mainly used patch #2 to test reset and recovery. It's pretty handy for (stress-)testing. Patch #3 should improve recovery speed in some cases. Notably when there's a long chain of WMI commands involved which take a painfully long time to timeout/complete if firmware crashes mid-way. Note: Patches #2 and #3 depend on `ath10k: pci related fixes 2014-10-09`. Without the patchset patches #2 and #3 must not be applied. Patch #1 is fine though. v3: * skip shadow ring cleanup in #1 Michal Kazior (3): ath10k: fix possible bmi crash ath10k: expose hw restart via debugfs ath10k: speed up hw recovery Thanks, all three patches applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] mwifiex: ACS support for mwifiex AP
This patch series adds Automatic channel selection- ACS support for mwifiex AP. Avinash Patil (1): mwifiex: channel statistics support for mwifiex Xinming Hu (1): mwifiex: add cfg80211 dump_survey handler drivers/net/wireless/mwifiex/cfg80211.c| 66 ++ drivers/net/wireless/mwifiex/decl.h| 10 drivers/net/wireless/mwifiex/fw.h | 16 +++ drivers/net/wireless/mwifiex/main.c| 6 +++ drivers/net/wireless/mwifiex/main.h| 6 ++- drivers/net/wireless/mwifiex/scan.c| 76 +- drivers/net/wireless/mwifiex/sta_cmdresp.c | 2 +- 7 files changed, 179 insertions(+), 3 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mwifiex: channel statistics support for mwifiex
This patch adds support to record channel statistics during
scan. With extended scan, scan results are returned as events from
FW while channel statistics are part of scan command response.
We store these channel statistics in adapter.
Signed-off-by: Avinash Patil pat...@marvell.com
Signed-off-by: Xinmin Hu h...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
---
drivers/net/wireless/mwifiex/cfg80211.c| 19
drivers/net/wireless/mwifiex/decl.h| 10
drivers/net/wireless/mwifiex/fw.h | 16 +++
drivers/net/wireless/mwifiex/main.c| 6 +++
drivers/net/wireless/mwifiex/main.h| 6 ++-
drivers/net/wireless/mwifiex/scan.c| 76 +-
drivers/net/wireless/mwifiex/sta_cmdresp.c | 2 +-
7 files changed, 132 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index 0dd6729..80b1a54 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2840,6 +2840,25 @@ static const struct wiphy_coalesce_support
mwifiex_coalesce_support = {
.max_pkt_offset = MWIFIEX_MAX_OFFSET_LEN,
};
+int mwifiex_init_channel_scan_gap(struct mwifiex_adapter *adapter)
+{
+ u32 n_channels_bg, n_channels_a = 0;
+
+ n_channels_bg = mwifiex_band_2ghz.n_channels;
+
+ if (adapter-config_bands BAND_A)
+ n_channels_a = mwifiex_band_5ghz.n_channels;
+
+ adapter-num_in_chan_stats = max_t(u32, n_channels_bg, n_channels_a);
+ adapter-chan_stats = vmalloc(sizeof(*adapter-chan_stats) *
+ adapter-num_in_chan_stats);
+
+ if (!adapter-chan_stats)
+ return -ENOMEM;
+
+ return 0;
+}
+
/*
* This function registers the device with CFG802.11 subsystem.
*
diff --git a/drivers/net/wireless/mwifiex/decl.h
b/drivers/net/wireless/mwifiex/decl.h
index e0d00a7..f53e5b5 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -185,4 +185,14 @@ struct mwifiex_arp_eth_header {
u8 ar_tha[ETH_ALEN];
u8 ar_tip[4];
} __packed;
+
+struct mwifiex_chan_stats {
+ u8 chan_num;
+ u8 bandcfg;
+ u8 flags;
+ s8 noise;
+ u16 total_bss;
+ u16 cca_scan_dur;
+ u16 cca_busy_dur;
+} __packed;
#endif /* !_MWIFIEX_DECL_H_ */
diff --git a/drivers/net/wireless/mwifiex/fw.h
b/drivers/net/wireless/mwifiex/fw.h
index 1eb6173..7f922a8 100644
--- a/drivers/net/wireless/mwifiex/fw.h
+++ b/drivers/net/wireless/mwifiex/fw.h
@@ -172,6 +172,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define TLV_TYPE_TDLS_IDLE_TIMEOUT (PROPRIETARY_TLV_BASE_ID + 194)
#define TLV_TYPE_SCAN_CHANNEL_GAP (PROPRIETARY_TLV_BASE_ID + 197)
#define TLV_TYPE_API_REV(PROPRIETARY_TLV_BASE_ID + 199)
+#define TLV_TYPE_CHANNEL_STATS (PROPRIETARY_TLV_BASE_ID + 198)
#define MWIFIEX_TX_DATA_BUF_SIZE_2K2048
@@ -611,6 +612,16 @@ struct uap_rxpd {
u8 reserved1;
};
+struct mwifiex_fw_chan_stats {
+ u8 chan_num;
+ u8 bandcfg;
+ u8 flags;
+ s8 noise;
+ __le16 total_bss;
+ __le16 cca_scan_dur;
+ __le16 cca_busy_dur;
+} __packed;
+
enum mwifiex_chan_scan_mode_bitmasks {
MWIFIEX_PASSIVE_SCAN = BIT(0),
MWIFIEX_DISABLE_CHAN_FILT = BIT(1),
@@ -660,6 +671,11 @@ struct mwifiex_ie_types_scan_chan_gap {
__le16 chan_gap;
} __packed;
+struct mwifiex_ietypes_chanstats {
+ struct mwifiex_ie_types_header header;
+ struct mwifiex_fw_chan_stats chanstats[0];
+} __packed;
+
struct mwifiex_ie_types_wildcard_ssid_params {
struct mwifiex_ie_types_header header;
u8 max_ssid_length;
diff --git a/drivers/net/wireless/mwifiex/main.c
b/drivers/net/wireless/mwifiex/main.c
index d5070c4..f26420d 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -122,6 +122,7 @@ static int mwifiex_unregister(struct mwifiex_adapter
*adapter)
}
}
+ vfree(adapter-chan_stats);
kfree(adapter);
return 0;
}
@@ -447,6 +448,11 @@ static void mwifiex_fw_dpc(const struct firmware
*firmware, void *context)
goto err_init_fw;
}
+ if (mwifiex_init_channel_scan_gap(adapter)) {
+ dev_err(adapter-dev, could not init channel stats table\n);
+ goto err_init_fw;
+ }
+
rtnl_lock();
/* Create station interface by default */
wdev = mwifiex_add_virtual_intf(adapter-wiphy, mlan%d,
diff --git a/drivers/net/wireless/mwifiex/main.h
b/drivers/net/wireless/mwifiex/main.h
index f55658d..cb39319 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -845,6 +845,9 @@ struct mwifiex_adapter {
u8 curr_mem_idx;
bool scan_chan_gap_enabled;
struct sk_buff_head rx_data_q;
+ struct mwifiex_chan_stats *chan_stats;
[PATCH 2/2] mwifiex: add cfg80211 dump_survey handler
From: Xinming Hu h...@marvell.com
This patch add cfg80211 dump_survey handler for mwifiex.
This handler will be called to report channel statistics
to cfg80211.
This in turn adds ACS support for mwifiex AP.
Signed-off-by: Xinming Hu h...@marvell.com
Signed-off-by: Avinash Patil pat...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
---
drivers/net/wireless/mwifiex/cfg80211.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index 80b1a54..b3c7635 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -992,6 +992,52 @@ mwifiex_cfg80211_dump_station(struct wiphy *wiphy, struct
net_device *dev,
return mwifiex_dump_station_info(priv, sinfo);
}
+static int
+mwifiex_cfg80211_dump_survey(struct wiphy *wiphy, struct net_device *dev,
+int idx, struct survey_info *survey)
+{
+ struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+ struct mwifiex_chan_stats *pchan_stats = priv-adapter-chan_stats;
+ enum ieee80211_band band;
+
+ dev_dbg(priv-adapter-dev, dump_survey idx=%d\n, idx);
+
+ memset(survey, 0, sizeof(struct survey_info));
+
+ if ((GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_STA)
+ priv-media_connected idx == 0) {
+ u8 curr_bss_band = priv-curr_bss_params.band;
+ u32 chan = priv-curr_bss_params.bss_descriptor.channel;
+
+ band = mwifiex_band_to_radio_type(curr_bss_band);
+ survey-channel = ieee80211_get_channel(wiphy,
+ ieee80211_channel_to_frequency(chan, band));
+
+ if (priv-bcn_nf_last) {
+ survey-filled = SURVEY_INFO_NOISE_DBM;
+ survey-noise = priv-bcn_nf_last;
+ }
+ return 0;
+ }
+
+ if (idx = priv-adapter-num_in_chan_stats)
+ return -ENOENT;
+
+ if (!pchan_stats[idx].cca_scan_dur)
+ return 0;
+
+ band = pchan_stats[idx].bandcfg;
+ survey-channel = ieee80211_get_channel(wiphy,
+ ieee80211_channel_to_frequency(pchan_stats[idx].chan_num, band));
+ survey-filled = SURVEY_INFO_NOISE_DBM |
+ SURVEY_INFO_CHANNEL_TIME | SURVEY_INFO_CHANNEL_TIME_BUSY;
+ survey-noise = pchan_stats[idx].noise;
+ survey-channel_time = pchan_stats[idx].cca_scan_dur;
+ survey-channel_time_busy = pchan_stats[idx].cca_busy_dur;
+
+ return 0;
+}
+
/* Supported rates to be advertised to the cfg80211 */
static struct ieee80211_rate mwifiex_rates[] = {
{.bitrate = 10, .hw_value = 2, },
@@ -2779,6 +2825,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
.disconnect = mwifiex_cfg80211_disconnect,
.get_station = mwifiex_cfg80211_get_station,
.dump_station = mwifiex_cfg80211_dump_station,
+ .dump_survey = mwifiex_cfg80211_dump_survey,
.set_wiphy_params = mwifiex_cfg80211_set_wiphy_params,
.join_ibss = mwifiex_cfg80211_join_ibss,
.leave_ibss = mwifiex_cfg80211_leave_ibss,
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
