Re: [PATCH 1/1] wireless: mac80211: Avoid using uninitialized stack data
On Wed, 2014-12-10 at 14:14 -0500, jes.soren...@redhat.com wrote: From: Jes Sorensen jes.soren...@redhat.com Avoid case where we would access uninitialized stack data if a driver advertises HT support without 40MHz channel support. I've fixed the commit message (it's actually in the check for the *AP*, not the driver!) Also, this is complicated. We originally had the DISABLE_VHT, but then found APs that were doing it wrong - see commit f3000e1b43f1 (mac80211: fix broken use of VHT/20Mhz with some APs). That fix introduced the bug here, going back now to the DISABLE_VHT as I'd suggested would break the fix again ... I'm thus taking this version to just put the right data on the stack, with the correct Fixes/Cc stable tags. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iw: Fix calculation of maximum supported 802.11n data rate
On Wed, 2014-12-10 at 10:23 +0100, Henning Rogge wrote: Fix typo in calculation, binary AND combination of low byte and high byte is always zero. Obviously - applied, thanks. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: check matches array length before acessing it
On Mon, 2014-12-01 at 11:32 +0200, Luca Coelho wrote: From: Luciano Coelho luciano.coe...@intel.com If the userspace passes a malformed sched scan request (or a net detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH attribute without any nested matchsets, a NULL pointer dereference will occur. Fix this by checking that we do have matchsets in our array before trying to access it. Applied, thanks. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On 12/12/14 00:53, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned charACI_AIFSN;
unsigned charCW;
-unsigned shortTXOP_limit;
+__le16TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned chardialog_token;
-unsigned shortBA_para_set;
+__le16BA_para_set;
unsigned shortBA_timeout_value;
-unsigned shortBA_starting_seqctrl;
+__le16BA_starting_seqctrl;
} __packed;
This fix may make the sparse warnings go away, but I think it introduces
new bugs.
Right, I see. Nice try though, isn't it? ;)
In particular, did you test on big-endian hardware after you
made this change?
Nope. I don't have any big-endian hardware. I don't even have the
wireless card TBH. But I'm happy to try to get one. Is Rtl8723AE the
right model?
I recently found that the driver for RTL8188EU needed
to have BA_para_set to unsigned short, and the endianess warnings needed
to be fixed in the code. Then it would work on my PowerBook G4 with a
PPC processor.
OK. Does it still work with little endian?
In RTL8188EU, both BA_starting_seqctrl and TXOP_limit are unsigned short.
That's not quite the case. `TXOP_limit` is __le16 in RTL8188EU [1].
It's __le16 even in your GitHub repo [2]. And that made me thinking
that there's probably some inconsistency in the header.
I'm _far_ from being a wireless expert but doesn't data coming out of
the wire/air have the endianess defined explicitly? And both `AC_param`
and `ADDBA_request` come out of air?
I was hunting particularly for inconsistencies with `sparse` and came
across this one. But I dug a bit further and I wonder why the driver is
not using standard stuff like the one in `include/linux/ieee80211.h`
where any data wider than one byte is clearly declared as __lenn?
Cheers,
Kris
--
[1] drivers/staging/rtl8188eu/include/wifi.h as of next-20141211
[2] https://github.com/lwfinger/rtl8188eu/blob/master/include/wifi.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] mac80211: update the channel context after channel switch
On Sun, 2014-11-30 at 17:17 +0200, Emmanuel Grumbach wrote: When the channel switch has been made, a vif is now using the channel context which was reserved. When that happens, we need to update the channel context since its parameters may change. I hit a case in which I switched to a 40Mhz channel but the reserved channel context was still on 20Mhz. The rate control would try to send 40Mhz packets on a 20Mhz channel context and that made iwlwifi's firmware unhappy. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ath10k: Fix no-ack frame status
On Thu, 2014-12-11 at 12:10 +0200, Kalle Valo wrote: Sujith Manoharan suj...@msujith.org writes: From: Sujith Manoharan c_man...@qca.qualcomm.com Use the new IEEE80211_TX_STAT_NOACK_TRANSMITTED flag to indicate successful transmission of no-ack frames. This fixes multicast frame accounting. Cc: ath...@lists.infradead.org Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com Johannes, are you planning to take this? Or should I take this once the corresponding mac80211 patch trickles down to my tree? I don't really want to take the driver patches, but I'll try to get to the mac80211 ones today. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] ath10k: enable per-vif sta powersave
Per-vif bss_conf.ps should be used to configure
powersave.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 2804952..19ddbc6 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1099,9 +1099,6 @@ static int ath10k_mac_vif_recalc_ps_poll_count(struct
ath10k_vif *arvif)
return 0;
}
-/*
- * Review this when mac80211 gains per-interface powersave support.
- */
static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
{
struct ath10k *ar = arvif-ar;
@@ -1117,7 +1114,7 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif
*arvif)
if (arvif-vif-type != NL80211_IFTYPE_STATION)
return 0;
- if (conf-flags IEEE80211_CONF_PS) {
+ if (vif-bss_conf.ps) {
psmode = WMI_STA_PS_MODE_ENABLED;
param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
@@ -3378,6 +3375,13 @@ static void ath10k_bss_info_changed(struct ieee80211_hw
*hw,
ath10k_warn(ar, failed to recalc tx power: %d\n, ret);
}
+ if (changed BSS_CHANGED_PS) {
+ ret = ath10k_mac_vif_setup_ps(arvif);
+ if (ret)
+ ath10k_warn(ar, failed to setup ps on vdev %i: %d\n,
+ arvif-vdev_id, ret);
+ }
+
mutex_unlock(ar-conf_mutex);
}
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] ath10k: a bunch of STA-related fixes
Michal Kazior (5): ath10k: improve 11b coex ath10k: fix STA u-APSD ath10k: prevent invalid ps timeout config ath10k: enable per-vif sta powersave ath10k: advertise p2p dev support drivers/net/wireless/ath/ath10k/core.c | 6 -- drivers/net/wireless/ath/ath10k/mac.c | 127 - drivers/net/wireless/ath/ath10k/wmi.h | 7 ++ 3 files changed, 115 insertions(+), 25 deletions(-) -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] ath10k: advertise p2p dev support
Firmware doesn't allow precise tx rate control so
P2P wasn't entirely spec compliant (it was using
CCK rates in some cases).
The only way to make sure firmware doesn't use CCK
rates is to have a vdev with P2P subtype used for
scanning and tx. This can be done via a special
dedicated P2P device interface support.
This also removes the ancient hack from ath10k in
favor of p2pdev.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/core.c | 6 --
drivers/net/wireless/ath/ath10k/mac.c | 12 +---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 577a3d7..c83f1e7 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -32,17 +32,14 @@
unsigned int ath10k_debug_mask;
static bool uart_print;
-static unsigned int ath10k_p2p;
static bool skip_otp;
module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
module_param(uart_print, bool, 0644);
-module_param_named(p2p, ath10k_p2p, uint, 0644);
module_param(skip_otp, bool, 0644);
MODULE_PARM_DESC(debug_mask, Debugging mask);
MODULE_PARM_DESC(uart_print, Uart target debugging);
-MODULE_PARM_DESC(p2p, Enable ath10k P2P support);
MODULE_PARM_DESC(skip_otp, Skip otp failure for calibration in testmode);
static const struct ath10k_hw_params ath10k_hw_params_list[] = {
@@ -1290,10 +1287,7 @@ struct ath10k *ath10k_core_create(size_t priv_size,
struct device *dev,
ar-ath_common.priv = ar;
ar-ath_common.hw = ar-hw;
-
- ar-p2p = !!ath10k_p2p;
ar-dev = dev;
-
ar-hif.ops = hif_ops;
ar-hif.bus = bus;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 19ddbc6..42f6a4d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2961,10 +2961,11 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif-vdev_id = bit;
arvif-vdev_subtype = WMI_VDEV_SUBTYPE_NONE;
- if (ar-p2p)
- arvif-vdev_subtype = WMI_VDEV_SUBTYPE_P2P_DEVICE;
-
switch (vif-type) {
+ case NL80211_IFTYPE_P2P_DEVICE:
+ arvif-vdev_type = WMI_VDEV_TYPE_STA;
+ arvif-vdev_subtype = WMI_VDEV_SUBTYPE_P2P_DEVICE;
+ break;
case NL80211_IFTYPE_UNSPECIFIED:
case NL80211_IFTYPE_STATION:
arvif-vdev_type = WMI_VDEV_TYPE_STA;
@@ -4860,6 +4861,10 @@ static const struct ieee80211_iface_limit
ath10k_if_limits[] = {
.types = BIT(NL80211_IFTYPE_P2P_GO)
},
{
+ .max= 1,
+ .types = BIT(NL80211_IFTYPE_P2P_DEVICE)
+ },
+ {
.max= 7,
.types = BIT(NL80211_IFTYPE_AP)
},
@@ -5079,6 +5084,7 @@ int ath10k_mac_register(struct ath10k *ar)
if (!test_bit(ATH10K_FW_FEATURE_NO_P2P, ar-fw_features))
ar-hw-wiphy-interface_modes |=
+ BIT(NL80211_IFTYPE_P2P_DEVICE) |
BIT(NL80211_IFTYPE_P2P_CLIENT) |
BIT(NL80211_IFTYPE_P2P_GO);
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] ath10k: improve 11b coex
Some firmware revisions need peer phymode to be
specified as MODE_11B when associating as station
to a 11b AP. Otherwise they can starve other
stations.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index fe61201..950322d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1416,6 +1416,12 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
}
+static bool ath10k_mac_sta_has_11g_rates(struct ieee80211_sta *sta)
+{
+ /* First 4 rates in ath10k_rates are CCK (11b) rates. */
+ return sta-supp_rates[IEEE80211_BAND_2GHZ] 4;
+}
+
static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
@@ -1430,8 +1436,10 @@ static void ath10k_peer_assoc_h_phymode(struct ath10k
*ar,
phymode = MODE_11NG_HT40;
else
phymode = MODE_11NG_HT20;
- } else {
+ } else if (ath10k_mac_sta_has_11g_rates(sta)) {
phymode = MODE_11G;
+ } else {
+ phymode = MODE_11B;
}
break;
@@ -4724,6 +4732,9 @@ static const struct ieee80211_channel
ath10k_5ghz_channels[] = {
CHAN5G(165, 5825, 0),
};
+/* Note: Be careful if you re-order these. There is code which depends on this
+ * ordering.
+ */
static struct ieee80211_rate ath10k_rates[] = {
/* CCK */
RATETAB_ENT(10, 0x82, 0),
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] ath10k: fix STA u-APSD
To comply with WMM-PS the device shouldn't wake up
with a NullFunc frame pair when tx-ing. Instead PM
bit on each tx frame should be used.
To make this work correctly firmware needs to be
told to use a different STA PS wake threshold when
u-APSD is enabled.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
Notes:
v2:
* fix Rx performance
* fix error handling (use goto instead of return)
drivers/net/wireless/ath/ath10k/mac.c | 79 ++-
drivers/net/wireless/ath/ath10k/wmi.h | 7
2 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 950322d..13c2bad 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1048,6 +1048,57 @@ static void ath10k_control_ibss(struct ath10k_vif *arvif,
arvif-vdev_id, ret);
}
+static int ath10k_mac_vif_recalc_ps_wake_threshold(struct ath10k_vif *arvif)
+{
+ struct ath10k *ar = arvif-ar;
+ u32 param;
+ u32 value;
+ int ret;
+
+ lockdep_assert_held(arvif-ar-conf_mutex);
+
+ if (arvif-u.sta.uapsd)
+ value = WMI_STA_PS_TX_WAKE_THRESHOLD_NEVER;
+ else
+ value = WMI_STA_PS_TX_WAKE_THRESHOLD_ALWAYS;
+
+ param = WMI_STA_PS_PARAM_TX_WAKE_THRESHOLD;
+ ret = ath10k_wmi_set_sta_ps_param(ar, arvif-vdev_id, param, value);
+ if (ret) {
+ ath10k_warn(ar, failed to submit ps wake threshold %u on vdev
%i: %d\n,
+ value, arvif-vdev_id, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ath10k_mac_vif_recalc_ps_poll_count(struct ath10k_vif *arvif)
+{
+ struct ath10k *ar = arvif-ar;
+ u32 param;
+ u32 value;
+ int ret;
+
+ lockdep_assert_held(arvif-ar-conf_mutex);
+
+ if (arvif-u.sta.uapsd)
+ value = WMI_STA_PS_PSPOLL_COUNT_UAPSD;
+ else
+ value = WMI_STA_PS_PSPOLL_COUNT_NO_MAX;
+
+ param = WMI_STA_PS_PARAM_PSPOLL_COUNT;
+ ret = ath10k_wmi_set_sta_ps_param(ar, arvif-vdev_id,
+ param, value);
+ if (ret) {
+ ath10k_warn(ar, failed to submit ps poll count %u on vdev %i:
%d\n,
+ value, arvif-vdev_id, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
/*
* Review this when mac80211 gains per-interface powersave support.
*/
@@ -3036,22 +3087,16 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
goto err_peer_delete;
}
- param = WMI_STA_PS_PARAM_TX_WAKE_THRESHOLD;
- value = WMI_STA_PS_TX_WAKE_THRESHOLD_ALWAYS;
- ret = ath10k_wmi_set_sta_ps_param(ar, arvif-vdev_id,
- param, value);
+ ret = ath10k_mac_vif_recalc_ps_wake_threshold(arvif);
if (ret) {
- ath10k_warn(ar, failed to set vdev %i TX wake thresh:
%d\n,
+ ath10k_warn(ar, failed to recalc ps wake threshold on
vdev %i: %d\n,
arvif-vdev_id, ret);
goto err_peer_delete;
}
- param = WMI_STA_PS_PARAM_PSPOLL_COUNT;
- value = WMI_STA_PS_PSPOLL_COUNT_NO_MAX;
- ret = ath10k_wmi_set_sta_ps_param(ar, arvif-vdev_id,
- param, value);
+ ret = ath10k_mac_vif_recalc_ps_poll_count(arvif);
if (ret) {
- ath10k_warn(ar, failed to set vdev %i PSPOLL count:
%d\n,
+ ath10k_warn(ar, failed to recalc ps poll count on vdev
%i: %d\n,
arvif-vdev_id, ret);
goto err_peer_delete;
}
@@ -3818,6 +3863,20 @@ static int ath10k_conf_tx_uapsd(struct ath10k *ar,
struct ieee80211_vif *vif,
if (ret)
ath10k_warn(ar, failed to set rx wake param: %d\n, ret);
+ ret = ath10k_mac_vif_recalc_ps_wake_threshold(arvif);
+ if (ret) {
+ ath10k_warn(ar, failed to recalc ps wake threshold on vdev %i:
%d\n,
+ arvif-vdev_id, ret);
+ return ret;
+ }
+
+ ret = ath10k_mac_vif_recalc_ps_poll_count(arvif);
+ if (ret) {
+ ath10k_warn(ar, failed to recalc ps poll count on vdev %i:
%d\n,
+ arvif-vdev_id, ret);
+ return ret;
+ }
+
exit:
return ret;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 97f902f..ff2d076 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4015,6 +4015,13 @@ enum wmi_sta_ps_param_pspoll_count {
* Values greater
[PATCH v2 3/5] ath10k: prevent invalid ps timeout config
Setting 0 ps timeout to firmware yields very poor
latency and traffic issues. This is the case when
multi-vif is active.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 13c2bad..2804952 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1105,10 +1105,12 @@ static int ath10k_mac_vif_recalc_ps_poll_count(struct
ath10k_vif *arvif)
static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
{
struct ath10k *ar = arvif-ar;
+ struct ieee80211_vif *vif = arvif-vif;
struct ieee80211_conf *conf = ar-hw-conf;
enum wmi_sta_powersave_param param;
enum wmi_sta_ps_mode psmode;
int ret;
+ int ps_timeout;
lockdep_assert_held(arvif-ar-conf_mutex);
@@ -1119,8 +1121,15 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif
*arvif)
psmode = WMI_STA_PS_MODE_ENABLED;
param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
+ ps_timeout = conf-dynamic_ps_timeout;
+ if (ps_timeout == 0) {
+ /* Firmware doesn't like 0 */
+ ps_timeout = ieee80211_tu_to_usec(
+ vif-bss_conf.beacon_int) / 1000;
+ }
+
ret = ath10k_wmi_set_sta_ps_param(ar, arvif-vdev_id, param,
- conf-dynamic_ps_timeout);
+ ps_timeout);
if (ret) {
ath10k_warn(ar, failed to set inactivity time for vdev
%d: %i\n,
arvif-vdev_id, ret);
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] mac80211: enable TPC through mac80211 stack
On Mon, 2014-12-01 at 11:30 +0100, Lorenzo Bianconi wrote:
Enable/disable per packet Transmit Power Control (TPC) in lower drivers
according to TX power settings configured by the user. In particular TPC is
enabled if value passed in enum nl80211_tx_power_setting is
NL80211_TX_POWER_AUTOMATIC (no limit from userspace) or
NL80211_TX_POWER_LIMITED (allow using less than specified from userspace),
whereas TPC is disabled if nl80211_tx_power_setting is set to
NL80211_TX_POWER_FIXED (use value configured from userspace)
Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com
---
include/net/mac80211.h | 10 ++
net/mac80211/cfg.c | 6 +-
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/iface.c | 8 +++-
net/mac80211/main.c| 8 +++-
5 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cff3a26..7dd2432 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -376,6 +376,8 @@ enum ieee80211_rssi_event {
* @ssid_len: Length of SSID given in @ssid.
* @hidden_ssid: The SSID of the current vif is hidden. Only valid in
AP-mode.
* @txpower: TX power in dBm
+ * @tpc_enabled: enable/disable per packet Transmit Power Control (TPC) for
the
+ * current vif
Why not put the enum nl80211_tx_power_setting value here?
struct ieee80211_conf {
u32 flags;
int power_level, dynamic_ps_timeout;
+ bool tpc_enabled;
int max_sleep_period;
Do you need it here at all?
+++ b/net/mac80211/ieee80211_i.h
@@ -869,6 +869,7 @@ struct ieee80211_sub_if_data {
int user_power_level; /* in dBm */
int ap_power_level; /* in dBm */
+ enum nl80211_tx_power_setting tx_power_type;
if you put this into bss_conf you can of course get rid of it here.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: avoid intersection when applying custom reg
On Sun, 2014-12-07 at 18:03 +0200, Arik Nemtsov wrote: The custom-reg handling function can currently only add flags to a given channel. This results in stale flags being left applied. In some cases a channel was disabled and even the orig_flags were changed to reflect this. Previously the API was designed for a single invocation before wiphy registration, so this didn't matter. The previous approach doesn't scale well to self-managed regulatory devices, particularly when a more permissive regdom is applied after a restrictive one. This description (not the patch) only makes sense after the other series with self-managed, please resend it in the self-managed patchset. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute
On Wed, 2014-12-10 at 00:21 +0200, Vadim Kochan wrote:
It allows to identify the wlan kind of device for the user application,
Applied,
+static struct rtnl_link_ops wireless_link_ops __read_mostly = {
+ .kind = wlan,
+};
but I've made this const. It only needs to be non-const (__read_mostly)
when used with rtnl_link_register() and friends.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mac80211: Move IEEE80211_TX_CTL_PS_RESPONSE
On Wed, 2014-12-10 at 21:26 +0530, Sujith Manoharan wrote: From: Sujith Manoharan c_man...@qca.qualcomm.com Move IEEE80211_TX_CTL_PS_RESPONSE to info-control.flags since this is used only in the TX path (by ath9k). This frees up a bit which can be used for other purposes. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mac80211: Fix accounting of multicast frames
On Wed, 2014-12-10 at 21:26 +0530, Sujith Manoharan wrote: From: Sujith Manoharan c_man...@qca.qualcomm.com Since multicast frames are marked as no-ack, using IEEE80211_TX_STAT_ACK to check if they have been successfully transmitted by the driver is incorrect since a driver can choose to ignore transmission status for no-ack frames. This results in incorrect accounting for such frames. To fix this issue, this patch introduces a new flag that can be used by drivers to indicate error-free transmission of no-ack frames. Seems fine, applied. I've worded the documentation a bit more strongly. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On Thu, Dec 11, 2014 at 05:53:30PM -0600, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
-unsigned short TXOP_limit;
+__le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
-unsigned short BA_para_set;
+__le16 BA_para_set;
unsigned short BA_timeout_value;
-unsigned short BA_starting_seqctrl;
+__le16 BA_starting_seqctrl;
} __packed;
This fix may make the sparse warnings go away, but I think it
introduces new bugs.
This kind of change, doesn't change the compiled code only how Sparse
sees it. It can't introduce bugs.
But it may well be that the calls to le16_to_cpu() should be removed. I
looked at it a bit but I don't know.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iw: print phy TDLS ch-switch support
Applied. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH iw v3 0/3] add WoWLAN net-detect trigger
On Fri, 2014-11-28 at 23:05 +0200, Luca Coelho wrote: From: Luciano Coelho luciano.coe...@intel.com A third spin. This one includes parsing of some configuration information related to net-detect (patch 3/3). I haven't send the nl80211 counterpart yet, but it's backwards compatible with the existing nl80211 code, so it doesn't matter if it's added in iw first. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] iw: support multiple regdom print
On Mon, 2014-12-01 at 17:53 +0200, Arik Nemtsov wrote: When a phy is given, print only its regdomain. Otherwise, use the newly implement dump functionality to print all regdomains in the system. This breaks on existing kernels. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New WARNING from mac80211
On Thu, 2014-11-06 at 21:20 +0530, Sujith Manoharan wrote: Sujith Manoharan wrote: I think this is the race described here: https://patchwork.kernel.org/patch/5095061/ I haven't tried any workaround or fix yet, but it looks like this race can be hit fairly often. https://dev.openwrt.org/ticket/9654 https://dev.openwrt.org/ticket/11862 https://dev.openwrt.org/ticket/13542 I dug out an old trace: http://pastebin.com/raw.php?i=Qj8aXJhB Would it be worthwhile to simply remove the warning and document how we can get there? johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iw: Fix calculation of maximum supported 802.11n data rate
Hi, the bug was caught by Coverity (I use parts of the iw code in a different project to talk to nl802.11). Maybe it would be interesting to register the iw project with Coverity. Henning On Fri, Dec 12, 2014 at 12:07 PM, Johannes Berg johan...@sipsolutions.net wrote: On Wed, 2014-12-10 at 10:23 +0100, Henning Rogge wrote: Fix typo in calculation, binary AND combination of low byte and high byte is always zero. Obviously - applied, thanks. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: add an intermediate software queue implementation
On Wed, 2014-11-19 at 00:14 +0100, Felix Fietkau wrote:
+ struct txq_info *txq;
+ atomic_t txq_len[IEEE80211_NUM_ACS];
I think you should consider renaming the latter to txqs_len or so - it
doesn't just cover one txq as is be implied by the name now. Otherwise
the skb_queue_head also maintains the length anyway, but I think you
need the aggregate for all stations here...
Some documentation for this and the vif.txq would be good too :)
In fact - it might be worthwhile to take parts of the commit message and
elaborate a bit on it and write a whole DOC: section?
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -371,6 +371,7 @@ struct sta_info {
struct sk_buff_head ps_tx_buf[IEEE80211_NUM_ACS];
struct sk_buff_head tx_filtered[IEEE80211_NUM_ACS];
unsigned long driver_buffered_tids;
+ void *txq;
You can still use struct txq_info * here even when it's not declared yet
(since it's in the other header file)
+static void ieee80211_drv_tx(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *pubsta,
+ struct sk_buff *skb)
+{
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb-data;
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ struct ieee80211_tx_control control = {
+ .sta = pubsta
+ };
+ struct ieee80211_txq *pubtxq = NULL;
+ struct txq_info *txq;
+ u8 ac;
+
+ if (ieee80211_is_mgmt(hdr-frame_control) ||
+ ieee80211_is_ctl(hdr-frame_control))
+ goto tx_normal;
+
+ if (pubsta) {
+ u8 tid = skb-priority IEEE80211_QOS_CTL_TID_MASK;
+ pubtxq = pubsta-txq[tid];
+ } else {
+ pubtxq = vif-txq;
+ }
This is a bit confusing - isn't this the same as sdata-txq.txq? Then
again what even sets vif-txq? Shouldn't those be per-AC? Do you really
want to mix 'normal' and txq-TX?
I think you should also use txqi as variables for txq_info - it gets
cumbersome to distinguish the two everywhere.
Also in many cases where you have txq allocation failures you just
continue as is, I'm not sure that's such a great idea. Those driver
paths will practically never get tested.
+ if (!pubtxq)
+ goto tx_normal;
+
+ ac = pubtxq-ac;
+ txq = container_of(pubtxq, struct txq_info, txq);
+ atomic_inc(sdata-txq_len[ac]);
+ if (atomic_read(sdata-txq_len[ac]) = local-hw.txq_ac_max_pending)
+ netif_stop_subqueue(sdata-dev, ac);
+
+ skb_queue_tail(txq-queue, skb);
+ drv_wake_tx_queue(local, txq);
You might consider doing locking differently here - I think you probably
don't need the txq-queue spinlock at all since you're in per-AC and
mappings are static. Not sure how that interacts with other parts of the
code though.
+int ieee80211_tx_dequeue(struct ieee80211_hw *hw, struct ieee80211_txq
*pubtxq,
+ struct sk_buff **dest)
I'd prefer you return the skb and use ERR_PTR() for errors.
+void ieee80211_init_tx_queue(struct ieee80211_sub_if_data *sdata,
+ struct sta_info *sta,
+ struct txq_info *txq, int tid)
+{
+ skb_queue_head_init(txq-queue);
+ txq-txq.vif = sdata-vif;
+
+ if (sta) {
+ txq-txq.sta = sta-sta;
+ sta-sta.txq[tid] = txq-txq;
+ txq-txq.ac = ieee802_1d_to_ac[tid 7];
+ } else {
+ sdata-vif.txq = txq-txq;
+ txq-txq.ac = IEEE80211_AC_BE;
+ }
Again, I don't quite understand the single AC queue here per vif. It
seems it should be one for each AC and possibly one for cab? Or none at
all - I don't really see what this single one would be used for, in the
TX code you seem to use it for mcast data only but then I don't really
see the point. It's also not part of the queue length accounting.
+void ieee80211_flush_tx_queue(struct ieee80211_local *local,
+ struct ieee80211_txq *pubtxq)
+{
+ struct txq_info *txq = container_of(pubtxq, struct txq_info, txq);
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(pubtxq-vif);
+ struct sk_buff *skb;
+
+ while ((skb = skb_dequeue(txq-queue)) != NULL) {
+ atomic_dec(sdata-txq_len[pubtxq-ac]);
+ ieee80211_free_txskb(local-hw, skb);
+ }
+}
You can rewrite this a bit smarter to just do one atomic op.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On Fri, 2014-12-12 at 12:35 +0100, Krzysztof Konopko wrote: I'm _far_ from being a wireless expert but doesn't data coming out of the wire/air have the endianess defined explicitly? And both `AC_param` and `ADDBA_request` come out of air? In general, data in 802.11 frames is little endian. Both of these would appear to correspond to data received/sent over the air, so __le would make sense. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: add an intermediate software queue implementation
On 2014-12-12 14:21, Johannes Berg wrote:
On Wed, 2014-11-19 at 00:14 +0100, Felix Fietkau wrote:
+struct txq_info *txq;
+atomic_t txq_len[IEEE80211_NUM_ACS];
I think you should consider renaming the latter to txqs_len or so - it
doesn't just cover one txq as is be implied by the name now. Otherwise
the skb_queue_head also maintains the length anyway, but I think you
need the aggregate for all stations here...
Some documentation for this and the vif.txq would be good too :)
In fact - it might be worthwhile to take parts of the commit message and
elaborate a bit on it and write a whole DOC: section?
Yeah, makes sense.
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -371,6 +371,7 @@ struct sta_info {
struct sk_buff_head ps_tx_buf[IEEE80211_NUM_ACS];
struct sk_buff_head tx_filtered[IEEE80211_NUM_ACS];
unsigned long driver_buffered_tids;
+void *txq;
You can still use struct txq_info * here even when it's not declared yet
(since it's in the other header file)
OK.
+static void ieee80211_drv_tx(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *pubsta,
+ struct sk_buff *skb)
+{
+struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb-data;
+struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+struct ieee80211_tx_control control = {
+.sta = pubsta
+};
+struct ieee80211_txq *pubtxq = NULL;
+struct txq_info *txq;
+u8 ac;
+
+if (ieee80211_is_mgmt(hdr-frame_control) ||
+ieee80211_is_ctl(hdr-frame_control))
+goto tx_normal;
+
+if (pubsta) {
+u8 tid = skb-priority IEEE80211_QOS_CTL_TID_MASK;
+pubtxq = pubsta-txq[tid];
+} else {
+pubtxq = vif-txq;
+}
This is a bit confusing - isn't this the same as sdata-txq.txq?
Right, I should probably use that.
Then
again what even sets vif-txq? Shouldn't those be per-AC? Do you really
want to mix 'normal' and txq-TX?
Are we even using multiple ACs for packets that don't belong to a
particular sta? I thought normal mcast data frames only use non-QoS
frames. And yes, I'm currently mixing normal and txq-TX to prioritize
ctl/mgmt frames over other less important traffic.
I think you should also use txqi as variables for txq_info - it gets
cumbersome to distinguish the two everywhere.
Will do.
Also in many cases where you have txq allocation failures you just
continue as is, I'm not sure that's such a great idea. Those driver
paths will practically never get tested.
It will just do normal tx in that case, which should work.
+if (!pubtxq)
+goto tx_normal;
+
+ac = pubtxq-ac;
+txq = container_of(pubtxq, struct txq_info, txq);
+atomic_inc(sdata-txq_len[ac]);
+if (atomic_read(sdata-txq_len[ac]) = local-hw.txq_ac_max_pending)
+netif_stop_subqueue(sdata-dev, ac);
+
+skb_queue_tail(txq-queue, skb);
+drv_wake_tx_queue(local, txq);
You might consider doing locking differently here - I think you probably
don't need the txq-queue spinlock at all since you're in per-AC and
mappings are static. Not sure how that interacts with other parts of the
code though.
I wanted to use the lock to give the driver the freedom to call
ieee80211_tx_dequeue from outside of normal per-AC tx context.
+int ieee80211_tx_dequeue(struct ieee80211_hw *hw, struct ieee80211_txq
*pubtxq,
+ struct sk_buff **dest)
I'd prefer you return the skb and use ERR_PTR() for errors.
Will do
+void ieee80211_init_tx_queue(struct ieee80211_sub_if_data *sdata,
+ struct sta_info *sta,
+ struct txq_info *txq, int tid)
+{
+skb_queue_head_init(txq-queue);
+txq-txq.vif = sdata-vif;
+
+if (sta) {
+txq-txq.sta = sta-sta;
+sta-sta.txq[tid] = txq-txq;
+txq-txq.ac = ieee802_1d_to_ac[tid 7];
+} else {
+sdata-vif.txq = txq-txq;
+txq-txq.ac = IEEE80211_AC_BE;
+}
Again, I don't quite understand the single AC queue here per vif. It
seems it should be one for each AC and possibly one for cab? Or none at
all - I don't really see what this single one would be used for, in the
TX code you seem to use it for mcast data only but then I don't really
see the point. It's also not part of the queue length accounting.
I handle CAB through normal mac80211 mcast buffering.
+void ieee80211_flush_tx_queue(struct ieee80211_local *local,
+ struct ieee80211_txq *pubtxq)
+{
+struct txq_info *txq = container_of(pubtxq, struct txq_info, txq);
+struct ieee80211_sub_if_data *sdata = vif_to_sdata(pubtxq-vif);
+struct sk_buff *skb;
+
+while ((skb = skb_dequeue(txq-queue)) != NULL) {
+atomic_dec(sdata-txq_len[pubtxq-ac]);
+
Re: [PATCH 1/1] wireless: mac80211: Avoid using uninitialized stack data
Johannes Berg johan...@sipsolutions.net writes: On Wed, 2014-12-10 at 14:14 -0500, jes.soren...@redhat.com wrote: From: Jes Sorensen jes.soren...@redhat.com Avoid case where we would access uninitialized stack data if a driver advertises HT support without 40MHz channel support. I've fixed the commit message (it's actually in the check for the *AP*, not the driver!) Also, this is complicated. We originally had the DISABLE_VHT, but then found APs that were doing it wrong - see commit f3000e1b43f1 (mac80211: fix broken use of VHT/20Mhz with some APs). That fix introduced the bug here, going back now to the DISABLE_VHT as I'd suggested would break the fix again ... I'm thus taking this version to just put the right data on the stack, with the correct Fixes/Cc stable tags. Either patch works for me, so I'm all good! Thanks for fixing this up! Cheers, 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: [PATCHv2] mac80211: enable TPC through mac80211 stack
On Mon, 2014-12-01 at 11:30 +0100, Lorenzo Bianconi wrote:
Enable/disable per packet Transmit Power Control (TPC) in lower drivers
according to TX power settings configured by the user. In particular TPC is
enabled if value passed in enum nl80211_tx_power_setting is
NL80211_TX_POWER_AUTOMATIC (no limit from userspace) or
NL80211_TX_POWER_LIMITED (allow using less than specified from userspace),
whereas TPC is disabled if nl80211_tx_power_setting is set to
NL80211_TX_POWER_FIXED (use value configured from userspace)
Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com
---
include/net/mac80211.h | 10 ++
net/mac80211/cfg.c | 6 +-
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/iface.c | 8 +++-
net/mac80211/main.c| 8 +++-
5 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cff3a26..7dd2432 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -376,6 +376,8 @@ enum ieee80211_rssi_event {
* @ssid_len: Length of SSID given in @ssid.
* @hidden_ssid: The SSID of the current vif is hidden. Only valid in
AP-mode.
* @txpower: TX power in dBm
+ * @tpc_enabled: enable/disable per packet Transmit Power Control (TPC) for
the
+ * current vif
Why not put the enum nl80211_tx_power_setting value here?
ack
struct ieee80211_conf {
u32 flags;
int power_level, dynamic_ps_timeout;
+ bool tpc_enabled;
int max_sleep_period;
Do you need it here at all?
In multi-vif scenario, TPC could be enabled just on given interfaces,
but driver TPC registers should be configured anyway (so I used a glob
flag). However I can move that logic in driver code, what do you
suggest?
+++ b/net/mac80211/ieee80211_i.h
@@ -869,6 +869,7 @@ struct ieee80211_sub_if_data {
int user_power_level; /* in dBm */
int ap_power_level; /* in dBm */
+ enum nl80211_tx_power_setting tx_power_type;
if you put this into bss_conf you can of course get rid of it here.
It sounds good to me. I can set nl80211_tx_power_setting value in
ieee80211_set_tx_power()
johannes
Best regards,
Lorenzo
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: add an intermediate software queue implementation
On 2014-12-12 15:01, Johannes Berg wrote: On Fri, 2014-12-12 at 14:40 +0100, Felix Fietkau wrote: Then again what even sets vif-txq? Shouldn't those be per-AC? Do you really want to mix 'normal' and txq-TX? Are we even using multiple ACs for packets that don't belong to a particular sta? I thought normal mcast data frames only use non-QoS frames. And yes, I'm currently mixing normal and txq-TX to prioritize ctl/mgmt frames over other less important traffic. Management (and maybe control) frames can have different priorities as well, this is only used for something with TDLS now I think though. With my implementation, those would go through the normal tx codepath, bypassing the software tx queues. Can you think of anything else that would need per-AC vif queues? - Felix -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
NetDev 0.1 Attendee clarification [was: Netdev 0.1 Call for Proposals]
On 14/12/02, Richard Guy Briggs wrote: Netdev 0.1 Call for Proposals - Netdev 0.1 (year 0, conference 1) is a community-driven conference geared towards Linux netheads. Linux kernel networking and user space utilization of the interfaces to the Linux kernel networking subsystem are the focus. Hello fellow Linux NetHeads, sorry for the noise: There seems to have been some questions about the intended audience for this conference. The 50/50 by-invitation/submission slots are for the *presenters* of the talks and not for the audience of attendees. *Anyone* with an interest in Linux networking is welcome to attend this conference. We're very sorry for the confusion and welcome you to join us. Cheers. There are 4 phases/formats to Netdev 0.1 1) Workshops (day 1) The workshop format is inspired by Netconf and the wireless mini-summits, with workshops being centered around existing networking subsystems. workshops are intended to be an extension of the mailing list in the sense that many times previous discussions from the mailing list (or that could otherwise have happened there) are taken to the round-table to simplify the decision-making process. The networking subsystem maintainer(s) should at least prepare a list of agenda items well before the workshop takes place to allow participants to come prepared; this makes the discussions most productive. Sometimes brain-storming sessions will also be appropriate where being prepared is less important, for example for discussions around new user requirements this can be very valuable. At the workshop meeting itself discussions prevail and notes are later sent back to the mailing list; presentations are typically - at the discretion of the chairs - only used where needed to clarify a problem statement for discussion. The sitting format is round-table. 2) BOFs (day 1) BOFs are sessions with a potential to become a workshop in a future Netdev conference. The lifetime of a BOF may be only one or two Netdev conference gatherings. We discourage perpetual BOFs. BoFs don't need to have an existing networking subsystem or mailing list. BOFs also don't need to strive to be upgraded to be a Workshop in the future. Their longevity could only be one conference. The sitting format could vary and be either lecture or round table format depending on the proposal. 3) Tutorials (day 2) Tutorials are generally about 2 hours long (or more at the discretion of the proposal). Tutorials are educational in nature and are presented in a classroom format with a specific educational outcome for the attendees. 4) Paper proposals (days 3 and 4) These are classical conference paper + presentations. Presentations are 30 minutes long with an additional 15 minutes for QA presented in a lecture format. We will require paper submissions for these sessions. The committee believes that a paper submission raises the quality of the presentations and makes it easier to build on presented ideas in the future. The Netdev conference this year is structured to be 50% by-invitation and 50% submission. We are making sure that we reach out to speakers who have interesting relevant topics because we recognize most of these folks would typically not be submitting papers to a conference. The invitation will be made by the technical committee to the individual speakers for workshop, paper and tutorial sessions. Clarification is that the presenters will be split 50/50 invitation/submission and that regular attendance is open to anyone and we will welcome anyone to join the conference audience. This call for papers is for the 50% submission portion of the conference for paper submissions, tutorials and workshops. We *highly discourage* submission of recycled talks. Current technical focus topics include: - wireless - performance analysis, debugging and improvement - networking hardware and offload - netfilter - traffic control - different networking layers (L2/3, etc) - Internet of things - security - additional topics can be suggested Unlike other conferences, we are going to try and accommodate as many submissions as possible - but please stay within the relevant topic focus and tie to Linux networking to make it easier for the technical committee to provide quick feedback. In order to give a talk you must be registered. If your proposal is accepted you will not be charged a conference fee or your conference fee will be refunded to you when your talk gets accepted. We expect minimum of 2 parallel tracks but likely more depending on the (quantity of submissions) in all phases i.e during tutorials, workshops and main talks. Why you should submit a proposal - If you yearn for the old community tech driven conferences where you mingle with fellow geeks (only these would be Linux networking geeks) then this would be it.
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On 12/12/2014 06:52 AM, Dan Carpenter wrote:
On Thu, Dec 11, 2014 at 05:53:30PM -0600, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
+ __le16 BA_para_set;
unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_starting_seqctrl;
} __packed;
This fix may make the sparse warnings go away, but I think it
introduces new bugs.
This kind of change, doesn't change the compiled code only how Sparse
sees it. It can't introduce bugs.
But it may well be that the calls to le16_to_cpu() should be removed. I
looked at it a bit but I don't know.
Your point regarding bugs is taken. What I should have said is that blindly
making _le changes to hide Sparse messages may hide existing bugs for BE hardware.
Larry
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state
On Fri, Dec 12, 2014 at 12:41:30PM +0100, Johannes Berg wrote: On Fri, 2014-11-21 at 11:24 +, Nishikawa, Kenzoh wrote: Instead of sending peer candidate events just once, send them as long as the peer remains in the LISTEN state in the peering state machine, when userspace is implementing the peering manager. Userspace may silence the events from a peer by progressing the state machine or by setting the link state to BLOCKED. Fixes the problem that a mesh peering process won't be fired again after the previous first peering trial fails due to like air propagation error if the peering is managed by user space such as wpa_supplicant. This patch works with another patch for wpa_supplicant described here which fires a peering process again triggered by the notice from kernel. http://lists.shmoo.com/pipermail/hostap/2014-November/031235.html Can any of the mesh folks comment on this? I think it's fine. It's not strictly necessary: userspace could run its own timers to restart peering with any unpeered candidates periodically, but doing it based on beacon arrival is a little better since it indicates the peer is still alive, and this is also exactly how the in-kernel MPM operates. -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull request: bluetooth 2014-12-12
Hi John, These fixes are intended for 3.19, note that the tree to pull from is bluetooth-next (unlike the subject implies). I'd have normally done a pull request from bluetooth.git, but since these fixes for 3.19 is all we have so far I thought it's simpler if you just pull from our -next tree. The patches consist of: - Coccinelle warning fix - hci_dev_lock/unlock fixes - Fixes for pending mgmt command handling - Fixes for properly following the force_lesc_support switch - Fix for a Microsoft branded Broadcom adapter - New device id for Atheros AR3012 - Fix for BR/EDR Secure Connections enabling Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 5a34bd5f5d8119def4feb1d2b4e3906b71059416: Bluetooth: Enable events for P-256 Public Key and DHKey commands (2014-12-05 18:17:49 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 9845904fd489288bcf693642c1b31cc463c0b660: Bluetooth: Fix mgmt response status when removing adapter (2014-12-12 13:20:12 +0100) Fengguang Wu (1): Bluetooth: fix err_cast.cocci warnings Jaganath Kanakkassery (2): Bluetooth: Fix missing hci_dev_lock/unlock in mgmt req_complete() Bluetooth: Fix missing hci_dev_lock/unlock in hci_event Janne Heikkinen (1): Bluetooth: Add USB device 04ca:3010 as Atheros AR3012 Johan Hedberg (5): Bluetooth: Fix calling hci_conn_put too early Bluetooth: Fix incorrect pending cmd removal in pairing_complete() Bluetooth: Fix notifying mgmt power off before flushing connection list Bluetooth: Fix enabling BR/EDR SC when powering on Bluetooth: Fix mgmt response status when removing adapter Marcel Holtmann (4): Bluetooth: Check for force_lesc_support when enabling SMP over BR/EDR Bluetooth: Check for force_lesc_support before rejecting SMP over BR/EDR Bluetooth: Fix generation of non-resolvable private addresses Bluetooth: Fix check for support for page scan related commands drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + net/bluetooth/hci_conn.c | 2 +- net/bluetooth/hci_core.c | 60 +++- net/bluetooth/hci_event.c | 20 +++ net/bluetooth/l2cap_core.c | 5 +-- net/bluetooth/mgmt.c | 85 - net/bluetooth/smp.c| 5 +-- 8 files changed, 126 insertions(+), 54 deletions(-) pgp9YYJ0jzbEE.pgp Description: PGP signature
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
Larry Finger larry.fin...@lwfinger.net writes: On 12/12/2014 05:35 AM, Krzysztof Konopko wrote: I was hunting particularly for inconsistencies with `sparse` and came across this one. But I dug a bit further and I wonder why the driver is not using standard stuff like the one in `include/linux/ieee80211.h` where any data wider than one byte is clearly declared as __lenn? That is a good question. One possibility is that those definitions do not exist on some of the older kernels that Realtek supports. They generally work with 2.6.18 and newer. The reason the 8723au driver doesn't use the defines from there is that in ieee80211.h they are part of struct ieee80211_mgmt, while the 8723au driver access the addba etc. elements without the full struct in place. 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
[PATCH] rsi: fix memory leak in rsi_load_ta_instructions()
Memory allocated by kmemdup() in rsi_load_ta_instructions() is leaked. But duplication of firmware data here is useless, so the patch removes kmemdup() at all. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru --- drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c index 4834a9abc171..b6cc9ff47fc2 100644 --- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c +++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c @@ -172,7 +172,6 @@ static int rsi_load_ta_instructions(struct rsi_common *common) (struct rsi_91x_sdiodev *)adapter-rsi_dev; u32 len; u32 num_blocks; - const u8 *fw; const struct firmware *fw_entry = NULL; u32 block_size = dev-tx_blk_size; int status = 0; @@ -201,7 +200,6 @@ static int rsi_load_ta_instructions(struct rsi_common *common) return status; } - fw = kmemdup(fw_entry-data, fw_entry-size, GFP_KERNEL); len = fw_entry-size; if (len % 4) @@ -212,7 +210,7 @@ static int rsi_load_ta_instructions(struct rsi_common *common) rsi_dbg(INIT_ZONE, %s: Instruction size:%d\n, __func__, len); rsi_dbg(INIT_ZONE, %s: num blocks: %d\n, __func__, num_blocks); - status = rsi_copy_to_card(common, fw, len, num_blocks); + status = rsi_copy_to_card(common, fw_entry-data, len, num_blocks); release_firmware(fw_entry); return status; } -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: avoid intersection when applying custom reg
On Sun, Dec 07, 2014 at 06:03:45PM +0200, Arik Nemtsov wrote: The custom-reg handling function can currently only add flags to a given channel. This results in stale flags being left applied. In some cases a channel was disabled and even the orig_flags were changed to reflect this. Previously the API was designed for a single invocation before wiphy registration, so this didn't matter. The previous approach doesn't scale well to self-managed regulatory devices, particularly when a more permissive regdom is applied after a restrictive one. So why not make this an excemption to only managed devices? You show the issue but am not convinced this won't introduce regressions so would prefer to make this an exception for managed devices. Luis -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On 12/12/14 17:43, Larry Finger wrote:
On 12/12/2014 06:52 AM, Dan Carpenter wrote:
On Thu, Dec 11, 2014 at 05:53:30PM -0600, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned charACI_AIFSN;
unsigned charCW;
-unsigned shortTXOP_limit;
+__le16TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned chardialog_token;
-unsigned shortBA_para_set;
+__le16BA_para_set;
unsigned shortBA_timeout_value;
-unsigned shortBA_starting_seqctrl;
+__le16BA_starting_seqctrl;
} __packed;
This fix may make the sparse warnings go away, but I think it
introduces new bugs.
This kind of change, doesn't change the compiled code only how Sparse
sees it. It can't introduce bugs.
But it may well be that the calls to le16_to_cpu() should be removed. I
looked at it a bit but I don't know.
Your point regarding bugs is taken. What I should have said is that
blindly making _le changes to hide Sparse messages may hide existing
bugs for BE hardware.
Larry
Yes, I started it off blindly but dug further and now have a better
understanding. Looking in ieee80211.h and getting your feedback helped
me to get a better understanding of the situation.
I see nothing wrong in declaring data that is supposed to be
little-endian as __le. You say that making these changes blindly may
hide existing bugs but:
* not doing anything about it is not helpful either
* this is no longer changing anything blindly
Relevant structs: `addba_req` and `ieee80211_wmm_ac_param` do declare
their fields as __le where needed.
I do take a point though about making this change inconsistently
(blindly) in my initial patch.
Kris
--
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: Fix sparse warnings
On 12/12/14 18:12, Jes Sorensen wrote:
Krzysztof Konopko k...@konagma.com writes:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
-unsigned short TXOP_limit;
+__le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
-unsigned short BA_para_set;
+__le16 BA_para_set;
unsigned short BA_timeout_value;
-unsigned short BA_starting_seqctrl;
+__le16 BA_starting_seqctrl;
} __packed;
If you are going to make the struct comply with the on-wire data format,
be consistent. Don't just change half the elements of the struct - that
will just lead to confusion.
Jes
Yes, my change was inconsistent. Looking at `addba_req` and
`ieee80211_wmm_ac_param` in include/linux/ieee80211.h, all data wider
than 1 byte should be declared as __le. I'll send through a patch that
makes this change consistently.
Thanks,
Kris
--
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: Fix sparse warnings
On 12/12/14 18:35, Larry Finger wrote: On 12/12/2014 05:35 AM, Krzysztof Konopko wrote: On 12/12/14 00:53, Larry Finger wrote: In particular, did you test on big-endian hardware after you made this change? Nope. I don't have any big-endian hardware. I don't even have the wireless card TBH. But I'm happy to try to get one. Is Rtl8723AE the right model? No. The device numbers that end in E are PCIe and use a mac80211-based driver. As none of my BE hardware has PCIe, I cannot test those drivers on other than LE hardware. I do not have the hardware either for the RTL8723AU. For that reason, I am careful when modifying the driver - I let Jes do that. Silly me. 'U' stands for USB here. But can't find this device on any auction. It's included in some ultrabooks but can't afford that for the sake of fixing some sparse warnings :) In RTL8188EU, both BA_starting_seqctrl and TXOP_limit are unsigned short. That's not quite the case. `TXOP_limit` is __le16 in RTL8188EU [1]. It's __le16 even in your GitHub repo [2]. And that made me thinking that there's probably some inconsistency in the header. All the USB drivers are a mess. The kernel version of rtl8188eu does not work on PPC; however, the git repo now does. I'm working on finding the differences and fixing the kernel version. Right. I found your introductory message: https://lkml.org/lkml/2013/4/1/280 I was hunting particularly for inconsistencies with `sparse` and came across this one. But I dug a bit further and I wonder why the driver is not using standard stuff like the one in `include/linux/ieee80211.h` where any data wider than one byte is clearly declared as __lenn? That is a good question. One possibility is that those definitions do not exist on some of the older kernels that Realtek supports. They generally work with 2.6.18 and newer. That would be important if the driver was kept out of the tree. Isn't it the point of having the driver in the mainline to keep up with the kernel and don't bother with older versions? To be able to fix the kernel driver for RTL8188EU on PPC, I need to sort out these endian problems. Once I do, I will port them to the other drivers. Isn't `sparse` useful here? :) Kris -- 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: Fix sparse warnings
On 12/12/14 19:52, Jes Sorensen wrote: Larry Finger larry.fin...@lwfinger.net writes: On 12/12/2014 05:35 AM, Krzysztof Konopko wrote: I was hunting particularly for inconsistencies with `sparse` and came across this one. But I dug a bit further and I wonder why the driver is not using standard stuff like the one in `include/linux/ieee80211.h` where any data wider than one byte is clearly declared as __lenn? That is a good question. One possibility is that those definitions do not exist on some of the older kernels that Realtek supports. They generally work with 2.6.18 and newer. The reason the 8723au driver doesn't use the defines from there is that in ieee80211.h they are part of struct ieee80211_mgmt, while the 8723au driver access the addba etc. elements without the full struct in place. And why is that the case? (I'm trying to understand, not debunk) Looks to me that this driver has been kept out of the tree for quite a while (by Realtek) and now suffers from locally invented stuff. I understand this is a lot of work to unify the codebase with ieee80211.h, but are there any technical hurdles? I'm just curious. Thanks, Kris -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: rtl8723au: Fix sparse warnings
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes the types of the struct fields involved to be
little-endian which is what is received over the air and consistent with
relevant structs in include/linux/ieee80211.h.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..266c43e 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
- unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_para_set;
+ __le16 BA_timeout_value;
+ __le16 BA_starting_seqctrl;
} __packed;
--
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] staging: rtl8723au: Fix sparse warnings
On 12/12/2014 04:50 PM, Krzysztof Konopko wrote: On 12/12/14 18:35, Larry Finger wrote: On 12/12/2014 05:35 AM, Krzysztof Konopko wrote: On 12/12/14 00:53, Larry Finger wrote: In particular, did you test on big-endian hardware after you made this change? Nope. I don't have any big-endian hardware. I don't even have the wireless card TBH. But I'm happy to try to get one. Is Rtl8723AE the right model? No. The device numbers that end in E are PCIe and use a mac80211-based driver. As none of my BE hardware has PCIe, I cannot test those drivers on other than LE hardware. I do not have the hardware either for the RTL8723AU. For that reason, I am careful when modifying the driver - I let Jes do that. Silly me. 'U' stands for USB here. But can't find this device on any auction. It's included in some ultrabooks but can't afford that for the sake of fixing some sparse warnings :) There are no stand-alone USB devices that I have found for either RTL8723AU or RTL8723BU. The closest are modules CM-8723U and CM-8723BU by CCC (http://www.ccandc.com.tw/) with RTL8723AU and RTL8723BU, respectively. The former is obsolete and no longer on the web site. These modules have D+ and D- connectors for USB, but they take 3.3 V, not 5. As a result, one would need some sort of voltage regulator circuit. That would not be complicated as it would consist of a TI LM2937-3.3 and a couple of capacitors. I wrote to them to see if I could get samples, but no response yet. To be able to fix the kernel driver for RTL8188EU on PPC, I need to sort out these endian problems. Once I do, I will port them to the other drivers. Isn't `sparse` useful here? :) Yes, but the git repo works, and the kernel version does not, even though both do not have any Sparse warhings. Larry -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On Fri, 2014-12-12 at 23:58 +0100, Krzysztof Konopko wrote:
This patch changes the types of the struct fields involved to be
little-endian which is what is received over the air and consistent with
relevant structs in include/linux/ieee80211.h.
[]
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
[]
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
- unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_para_set;
+ __le16 BA_timeout_value;
+ __le16 BA_starting_seqctrl;
} __packed;
If I did this, I would also change the
unsigned char uses to u8 at the same time.
--
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
