Re: [PATCH v1] ath10k: Fix 10.4 extended peer stats update
Hi Sven / Kalle,
seems the change got merged in pending branch
https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending&id=2a872321e07506e339fc1b3ca81aa3e88628cd6e
Request if you can send the patch to address this(incase the patch cannot be
dropped)
and the v2 version cannot be picked
regards,
shafi
From: Mohammed Shafi Shajakhan
Sent: 27 May 2016 14:36
To: Sven Eckelmann
Cc: Shajakhan, Mohammed Shafi (Mohammed Shafi); ath...@lists.infradead.org;
linux-wireless@vger.kernel.org; Valo, Kalle
Subject: Re: [PATCH v1] ath10k: Fix 10.4 extended peer stats update
On Fri, May 27, 2016 at 10:12:45AM +0200, Sven Eckelmann wrote:
> On Wednesday 11 May 2016 11:54:30 Mohammed Shafi Shajakhan wrote:
> > #else
> > -static inline void ath10k_sta_update_rx_duration(struct ath10k *ar,
> > -struct list_head *peer)
> > +static inline
> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> > + struct ath10k_fw_stats *stats);
> > {
> > }
>
> Please remove the ";" for the "static inline" version. I can also
> submit a patch in case patches in ath.git/pending cannot be dropped
> anymore.
[shafi] thanks a lot fixed it ! sorry for the typo, sent a v2 for
the same, kindly review the same.
>
> Kind regards,
> Sven
--
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] net/wireless: Fix 'multiple blank lines' check
This patch fixes the checkpatch.pl check "Please don't use multiple
blank lines" for all files in net/wireless, except nl80211.c which
is covered in a separated patch.
Signed-off-by: Kirtika Ruchandani
---
net/wireless/ap.c | 1 -
net/wireless/chan.c| 3 ---
net/wireless/core.h| 2 --
net/wireless/ibss.c| 1 -
net/wireless/mlme.c| 2 --
net/wireless/radiotap.c| 2 --
net/wireless/rdev-ops.h| 2 --
net/wireless/reg.c | 3 ---
net/wireless/scan.c| 1 -
net/wireless/sme.c | 1 -
net/wireless/util.c| 2 --
net/wireless/wext-compat.c | 3 ---
net/wireless/wext-compat.h | 2 --
net/wireless/wext-core.c | 6 --
net/wireless/wext-proc.c | 1 -
net/wireless/wext-sme.c| 1 -
16 files changed, 33 deletions(-)
diff --git a/net/wireless/ap.c b/net/wireless/ap.c
index bdad1f9..23acf58 100644
--- a/net/wireless/ap.c
+++ b/net/wireless/ap.c
@@ -5,7 +5,6 @@
#include "core.h"
#include "rdev-ops.h"
-
int __cfg80211_stop_ap(struct cfg80211_registered_device *rdev,
struct net_device *dev, bool notify)
{
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index da49c0b..34cec73d 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -325,7 +325,6 @@ static int cfg80211_get_chans_dfs_required(struct wiphy
*wiphy,
return 0;
}
-
int cfg80211_chandef_dfs_required(struct wiphy *wiphy,
const struct cfg80211_chan_def *chandef,
enum nl80211_iftype iftype)
@@ -455,7 +454,6 @@ bool cfg80211_chandef_dfs_usable(struct wiphy *wiphy,
return (r1 + r2 > 0);
}
-
static bool cfg80211_get_chans_dfs_available(struct wiphy *wiphy,
u32 center_freq,
u32 bandwidth)
@@ -685,7 +683,6 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
if (width < 20)
prohibited_flags |= IEEE80211_CHAN_NO_OFDM;
-
if (!cfg80211_secondary_chans_ok(wiphy, chandef->center_freq1,
width, prohibited_flags))
return false;
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 025b7a5..5c54a1e 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -16,7 +16,6 @@
#include
#include "reg.h"
-
#define WIPHY_IDX_INVALID -1
struct cfg80211_registered_device {
@@ -161,7 +160,6 @@ static inline void cfg80211_unhold_bss(struct
cfg80211_internal_bss *bss)
WARN_ON(r < 0);
}
-
struct cfg80211_registered_device *cfg80211_rdev_by_wiphy_idx(int wiphy_idx);
int get_wiphy_idx(struct wiphy *wiphy);
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 4a4dda5..67b4f9b 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -13,7 +13,6 @@
#include "nl80211.h"
#include "rdev-ops.h"
-
void __cfg80211_ibss_joined(struct net_device *dev, const u8 *bssid,
struct ieee80211_channel *channel)
{
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index c284d88..332a143 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -18,7 +18,6 @@
#include "nl80211.h"
#include "rdev-ops.h"
-
void cfg80211_rx_assoc_resp(struct net_device *dev, struct cfg80211_bss *bss,
const u8 *buf, size_t len, int uapsd_queues)
{
@@ -768,7 +767,6 @@ void cfg80211_dfs_channels_update_work(struct work_struct
*work)
next_time);
}
-
void cfg80211_radar_event(struct wiphy *wiphy,
struct cfg80211_chan_def *chandef,
gfp_t gfp)
diff --git a/net/wireless/radiotap.c b/net/wireless/radiotap.c
index 6582d15..f193b88 100644
--- a/net/wireless/radiotap.c
+++ b/net/wireless/radiotap.c
@@ -184,8 +184,6 @@ static void find_ns(struct ieee80211_radiotap_iterator
*iterator,
}
}
-
-
/**
* ieee80211_radiotap_iterator_next - return next radiotap parser iterator arg
* @iterator: radiotap_iterator to move to next arg (if any)
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 85ff30b..9ad56db 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -338,7 +338,6 @@ static inline int rdev_join_mesh(struct
cfg80211_registered_device *rdev,
return ret;
}
-
static inline int rdev_leave_mesh(struct cfg80211_registered_device *rdev,
struct net_device *dev)
{
@@ -569,7 +568,6 @@ static inline void rdev_rfkill_poll(struct
cfg80211_registered_device *rdev)
trace_rdev_return_void(&rdev->wiphy);
}
-
#ifdef CONFIG_NL80211_TESTMODE
static inline int rdev_testmode_cmd(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..cfd4d69 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -18,7 +18,6 @@
* OR IN CONNECTION WITH THE USE
[PATCH] cfg80211: Allow cfg80211_connect_result() errors to be distinguished
Previously, the status parameter to cfg80211_connect_result() was
documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
status code for the failure is not known. This value can be used by an
AP (and often is) and as such, user space cannot distinguish between
explicitly rejected authentication/association and not being able to
even try to associate or not receiving a response from the AP.
Add a new inline function, cfg80211_connect_timeout(), to be used when
the driver knows that the connection attempt failed due to a reason
where connection could not be attempt or no response was received from
the AP. The internal functions now allow a negative status value (-1) to
be used as an indication of this special case. This results in the
NL80211_ATTR_TIMED_OUT to be added to the NL80211_CMD_CONNECT event to
allow user space to determine this case was hit. For backwards
compatibility, NL80211_STATUS_CODE with the value
WLAN_STATUS_UNSPECIFIED_FAILURE is still indicated in the event in such
a case.
Signed-off-by: Jouni Malinen
---
include/net/cfg80211.h | 54 ++--
include/uapi/linux/nl80211.h | 7 +-
net/wireless/core.h | 4 ++--
net/wireless/nl80211.c | 7 --
net/wireless/nl80211.h | 2 +-
net/wireless/sme.c | 6 ++---
6 files changed, 58 insertions(+), 22 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 58cdd42..b60c244 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2367,19 +2367,26 @@ struct cfg80211_qos_map {
* (invoked with the wireless_dev mutex held)
*
* @connect: Connect to the ESS with the specified parameters. When connected,
- * call cfg80211_connect_result() with status code %WLAN_STATUS_SUCCESS.
- * If the connection fails for some reason, call cfg80211_connect_result()
- * with the status from the AP. The driver is allowed to roam to other
- * BSSes within the ESS when the other BSS matches the connect parameters.
- * When such roaming is initiated by the driver, the driver is expected to
- * verify that the target matches the configured security parameters and
- * to use Reassociation Request frame instead of Association Request frame.
- * The connect function can also be used to request the driver to perform
- * a specific roam when connected to an ESS. In that case, the prev_bssid
+ * call cfg80211_connect_result()/cfg80211_connect_bss() with status code
+ * %WLAN_STATUS_SUCCESS. If the connection fails for some reason, call
+ * cfg80211_connect_result()/cfg80211_connect_bss() with the status code
+ * from the AP or cfg80211_connect_timeout() if no frame with status code
+ * was received.
+ *
+ * The driver is allowed to roam to other BSSes within the ESS when the
+ * other BSS matches the connect parameters. When such roaming is initiated
+ * by the driver, the driver is expected to verify that the target matches
+ * the configured security parameters and to use Reassociation Request
+ * frame instead of Association Request frame.
+ *
+ * The connect function can also be used to request the driver to perform a
+ * specific roam when connected to an ESS. In that case, the prev_bssid
* parameter is set to the BSSID of the currently associated BSS as an
- * indication of requesting reassociation. In both the driver-initiated and
- * new connect() call initiated roaming cases, the result of roaming is
- * indicated with a call to cfg80211_roamed() or cfg80211_roamed_bss().
+ * indication of requesting reassociation.
+ *
+ * In both the driver-initiated and new connect() call initiated roaming
+ * cases, the result of roaming is indicated with a call to
+ * cfg80211_roamed() or cfg80211_roamed_bss().
* (invoked with the wireless_dev mutex held)
* @disconnect: Disconnect from the BSS/ESS.
* (invoked with the wireless_dev mutex held)
@@ -4736,6 +4743,29 @@ cfg80211_connect_result(struct net_device *dev, const u8
*bssid,
}
/**
+ * cfg80211_connect_timeout - notify cfg80211 of connection timeout
+ *
+ * @dev: network device
+ * @bssid: the BSSID of the AP
+ * @req_ie: association request IEs (maybe be %NULL)
+ * @req_ie_len: association request IEs length
+ * @gfp: allocation flags
+ *
+ * It should be called by the underlying driver whenever connect() has failed
+ * in a sequence where no explicit authentication/association rejection was
+ * received from the AP. This could happen, e.g., due to not being able to send
+ * out the Authentication or Association Request frame or timing out while
+ * waiting for the response.
+ */
+static inline void
+cfg80211_connect_timeout(struct net_device *dev, const u8 *bssid,
+const u8 *req_ie, size_t req_ie_len, gfp_t gfp)
+{
+ cfg80211_connect_bss(dev, bssid, NULL, req_ie, req_ie_len, NULL, 0, -1,
+gfp);
Re: [PATCH] iwlwifi: mvm: avoid harmless -Wmaybe-uninialized warning
On Fri, 2016-05-27 at 15:07 +0200, Arnd Bergmann wrote:
> gcc is apparently unablel to track the state of the local 'resp_v2'
> variable across the kzalloc() function, and warns about the response
> variable being used without an initialization:
>
> drivers/net/wireless/intel/iwlwifi/mvm/nvm.c: In function
> ‘iwl_mvm_update_mcc’:
> drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:727:36: warning:
> ‘mcc_resp_v1’ may be used uninitialized in this function [-Wmaybe-
> uninitialized]
> resp_cp->n_channels = mcc_resp_v1->n_channels;
> drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:721:3: warning:
> ‘mcc_resp’ may be used uninitialized in this function [-Wmaybe-
> uninitialized]
> memcpy(resp_cp, mcc_resp, resp_len);
>
> The warning showed up in x86 allmodconfig after my patch to
> unhide -Wmaybe-uninitialized warnings by default was merged,
> though it always existed in randconfig builds. I did not
> catch the warning earlier because I was testing on ARM, which
> never produced the warning.
>
> This rearranges the code in a way that improves readability for
> both humans and the compiler, and that avoids the warning.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 6fa52430f0b3 ("iwlwifi: mvm: change mcc update API")
> ---
Thanks, Arnd! I queued this via our internal tree.
--
Cheers,
Luca.
Re: linux-next: Tree for May 30
On Monday 30 May 2016 08:52 AM, Stephen Rothwell wrote: Hi all, Changes since 20160527: Hi All, I have just built and booted with next-20160530 and my dmesg is full of warnings from ath9k. Last kernel tested was v4.6 and there was no problem with that. The traces are like: Call Trace: [] dump_stack+0x63/0x87 [] __warn+0xd1/0xf0 [] warn_slowpath_null+0x1d/0x20 [] ath9k_hw_gpio_request+0x6f/0x320 [ath9k_hw] [] ath9k_hw_reset+0xfe4/0x12e0 [ath9k_hw] [] ath_reset_internal+0x104/0x1f0 [ath9k] [] ath_reset+0x3d/0x60 [ath9k] [] ath_chanctx_set_channel+0x1b6/0x300 [ath9k] [] ath9k_config+0xc6/0x1f0 [ath9k] [] ? mutex_lock+0x12/0x2f [] ieee80211_hw_config+0x63/0x350 [mac80211] [] ieee80211_scan_work+0x161/0x480 [mac80211] [] process_one_work+0x153/0x3f0 [] worker_thread+0x12b/0x4b0 [] ? rescuer_thread+0x340/0x340 [] kthread+0xc9/0xe0 [] ret_from_fork+0x1f/0x40 [] ? kthread_park+0x60/0x60 ---[ end trace 27eb5094a52869ea ]--- Call Trace: [] dump_stack+0x63/0x87 [] __warn+0xd1/0xf0 [] warn_slowpath_null+0x1d/0x20 [] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw] [] ath9k_rfkill_poll_state+0x34/0x60 [ath9k] [] ieee80211_rfkill_poll+0x33/0x40 [mac80211] [] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211] [] rfkill_poll+0x24/0x50 [] process_one_work+0x153/0x3f0 [] worker_thread+0x12b/0x4b0 [] ? rescuer_thread+0x340/0x340 [] kthread+0xc9/0xe0 [] ret_from_fork+0x1f/0x40 [] ? kthread_park+0x60/0x60 ---[ end trace 27eb5094a5286a3d ]--- If it is a known problem then great.. else i can debug and see what the problem is. There are only few patches added for GPIO, so should not be a problem to find out what is causing the error. Regards Sudip -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: fix error handling in *_read_adapter_info()
On 05/30/2016 10:26 AM, Arnd Bergmann wrote:
There are nine copies of the _rtl88ee_read_adapter_info() function,
and most but not all of them cause a build warning in some configurations:
rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
rtl8192de/hw.c:1767:12: error: 'hwinfo' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
rtl8723ae/hw.c: In function '_rtl8723e_read_adapter_info.constprop':
rtlwifi/rtl8723ae/hw.c:1654:12: error: 'hwinfo' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
The problem is that when rtlefuse->epromtype is something other than
EEPROM_BOOT_EFUSE, the rest of the function uses undefined data, resulting
in random behavior later.
Apparently, in some drivers, the problem was already found and fixed
but the fix did not make it into the others.
This picks one approach to deal with the problem and applies identical
code to all 9 files, to simplify the later consolidation of those.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 12 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 17 -
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 16 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 16 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 12 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 20 ++--
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 13 +
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 16
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 15 +++
9 files changed, 94 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index 8ee83b093c0d..e26a233684bb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
@@ -1839,20 +1839,22 @@ static void _rtl88ee_read_adapter_info(struct
ieee80211_hw *hw)
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;
- if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+ switch (rtlefuse->epromtype) {
+ case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+ break;
- memcpy(hwinfo, &rtlefuse->efuse_map[EFUSE_INIT_MAP][0],
- HWSET_MAX_SIZE);
- } else if (rtlefuse->epromtype == EEPROM_93C46) {
+ case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
"RTL819X Not boot from eeprom, check it !!");
return;
- } else {
+
+ default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
"boot from neither eeprom nor efuse, check it !!");
return;
}
+ memcpy(hwinfo, &rtlefuse->efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP\n",
hwinfo, HWSET_MAX_SIZE);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index 04eb5c3f8464..58b7ac6899ef 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -1680,21 +1680,28 @@ static void _rtl92ce_read_adapter_info(struct
ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ struct device *dev = &rtl_pcipriv(hw)->dev.pdev->dev;
u16 i, usvalue;
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;
- if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+ switch (rtlefuse->epromtype) {
+ case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+ break;
- memcpy((void *)hwinfo,
- (void *)&rtlefuse->efuse_map[EFUSE_INIT_MAP][0],
- HWSET_MAX_SIZE);
- } else if (rtlefuse->epromtype == EEPROM_93C46) {
+ case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
"RTL819X Not boot from eeprom, check it !!");
+ return;
+
+ default:
+ dev_warn(dev, "no efuse data\n");
+ return;
}
+ memcpy(hwinfo, &rtlefuse->efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);
+
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP",
hwinfo, HWSET_MAX_SIZE);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index 34ce06441d1b..ae1129f916d5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -351,15 +351,21 @@ static void _rtl92cu_read_adapter_
[PATCH] rtlwifi: fix error handling in *_read_adapter_info()
There are nine copies of the _rtl88ee_read_adapter_info() function,
and most but not all of them cause a build warning in some configurations:
rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
rtl8192de/hw.c:1767:12: error: 'hwinfo' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
rtl8723ae/hw.c: In function '_rtl8723e_read_adapter_info.constprop':
rtlwifi/rtl8723ae/hw.c:1654:12: error: 'hwinfo' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
The problem is that when rtlefuse->epromtype is something other than
EEPROM_BOOT_EFUSE, the rest of the function uses undefined data, resulting
in random behavior later.
Apparently, in some drivers, the problem was already found and fixed
but the fix did not make it into the others.
This picks one approach to deal with the problem and applies identical
code to all 9 files, to simplify the later consolidation of those.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 12 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 17 -
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 16 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 16 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 12 +++-
drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 20 ++--
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 13 +
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 16
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 15 +++
9 files changed, 94 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index 8ee83b093c0d..e26a233684bb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
@@ -1839,20 +1839,22 @@ static void _rtl88ee_read_adapter_info(struct
ieee80211_hw *hw)
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;
- if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+ switch (rtlefuse->epromtype) {
+ case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+ break;
- memcpy(hwinfo, &rtlefuse->efuse_map[EFUSE_INIT_MAP][0],
- HWSET_MAX_SIZE);
- } else if (rtlefuse->epromtype == EEPROM_93C46) {
+ case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
"RTL819X Not boot from eeprom, check it !!");
return;
- } else {
+
+ default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
"boot from neither eeprom nor efuse, check it !!");
return;
}
+ memcpy(hwinfo, &rtlefuse->efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP\n",
hwinfo, HWSET_MAX_SIZE);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index 04eb5c3f8464..58b7ac6899ef 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -1680,21 +1680,28 @@ static void _rtl92ce_read_adapter_info(struct
ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ struct device *dev = &rtl_pcipriv(hw)->dev.pdev->dev;
u16 i, usvalue;
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;
- if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+ switch (rtlefuse->epromtype) {
+ case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+ break;
- memcpy((void *)hwinfo,
- (void *)&rtlefuse->efuse_map[EFUSE_INIT_MAP][0],
- HWSET_MAX_SIZE);
- } else if (rtlefuse->epromtype == EEPROM_93C46) {
+ case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
"RTL819X Not boot from eeprom, check it !!");
+ return;
+
+ default:
+ dev_warn(dev, "no efuse data\n");
+ return;
}
+ memcpy(hwinfo, &rtlefuse->efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);
+
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP",
hwinfo, HWSET_MAX_SIZE);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index 34ce06441d1b..ae1129f916d5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -351,15 +351,21 @@ static void _rtl92cu_read_adapter_info(struct
ieee80211_hw *hw)
u8 hwinfo[H
Re: [Make-wifi-fast] [RFC] ath9k: Measure per-station airtime usage
Michal Kazior writes:
>> +void ath_debug_tx_airtime(struct ath_softc *sc,
>> + struct ath_node *an,
>> + struct ath_tx_status *ts)
>> +{
>> + struct ath_airtime_stats *astats;
>> +
>> + rcu_read_lock();
>> +
>> + astats = &an->airtime_stats;
>> + astats->tx_airtime += ts->duration;
>
> I'm not ath9k expert but this seems to be oblivious to tx retries. The
> ts->duration is acquired from the last used tx rate for given frame.
> Or am I missing something?
No, don't think you are. Wasn't sure what exactly that duration field
included, but I think you're right that it doesn't factor in retries.
> I think you should use ts->ts_rateindex and ts->ts_longretry to factor
> in retries (see ath_tx_rc_status).
I'll go digging. Thanks, this was exactly the kind of feedback I had
hoped for! :)
-Toke
--
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] ath10k: enable ipq4019 device probe in ahb module
From: Raja Mani
All the necessary patches to make wifi running (over AHB)
on ipq4019 SoC are ready now. It's good to enable
ipq4019 wifi device probing in ahb module and
remove work in progress debug print.
Device tree change is there in the public review by
below commit message
"qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree"
Signed-off-by: Tamizh chelvam
Signed-off-by: Raja Mani
---
drivers/net/wireless/ath/ath10k/ahb.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ahb.c
b/drivers/net/wireless/ath/ath10k/ahb.c
index bd62bc1..ce847bf 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -25,10 +25,9 @@
#include "ahb.h"
static const struct of_device_id ath10k_ahb_of_match[] = {
- /* TODO: enable this entry once everything in place.
-* { .compatible = "qcom,ipq4019-wifi",
-* .data = (void *)ATH10K_HW_QCA4019 },
-*/
+ { .compatible = "qcom,ipq4019-wifi",
+ .data = (void *)ATH10K_HW_QCA4019
+ },
{ }
};
@@ -918,8 +917,6 @@ int ath10k_ahb_init(void)
{
int ret;
- printk(KERN_ERR "AHB support is still work in progress\n");
-
ret = platform_driver_register(&ath10k_ahb_driver);
if (ret)
printk(KERN_ERR "failed to register ath10k ahb driver: %d\n",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Make-wifi-fast] [RFC] ath9k: Measure per-station airtime usage
On 26 May 2016 at 15:50, Toke Høiland-Jørgensen wrote:
> This is my attempt to add per-station airtime usage accounting to ath9k.
> For now I just export it to a new debugfs entry, but my plan is to use
> it to make (station) scheduling decisions. However, before attempting
> that I would like some feedback from someone more familiar with the
> ath9k than me as to whether this way of measuring airtime usage is
> likely to give reasonable results.
>
> I realise that there's probably some things I'm missing, but an initial
> test run indicates that the values are at least in the right ballpark (I
> get a total of ~170k usecs of measured airtime per 200 ms sampling
> interval when running three simultaneous TCP streams to three different
> stations).
>
> So can anyone comment on whether I'm on the right track here? And
> possibly provide some more detail as to what I'm missing and how to
> remedy that?
[...]
>
> +void ath_debug_tx_airtime(struct ath_softc *sc,
> + struct ath_node *an,
> + struct ath_tx_status *ts)
> +{
> + struct ath_airtime_stats *astats;
> +
> + rcu_read_lock();
> +
> + astats = &an->airtime_stats;
> + astats->tx_airtime += ts->duration;
I'm not ath9k expert but this seems to be oblivious to tx retries. The
ts->duration is acquired from the last used tx rate for given frame.
Or am I missing something?
I think you should use ts->ts_rateindex and ts->ts_longretry to factor
in retries (see ath_tx_rc_status).
Michał
--
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/2] ath10k: Add support for QCA9887
On Friday 27 May 2016 12:44:52 Valo, Kalle wrote: [...] > > But maybe I should add that the results with the original AP147 firmware > > also > > wasn't better. > > That doesn't sound good. Maybe a calibration issue? Maybe but I don't have a different card to compare it to. [...] > I pushed a new firmware image firmware-5.bin_10.2.3.31.7-2 with those > enabled: > > https://github.com/kvalo/ath10k-firmware/tree/master/QCA9887 Thanks for the updated firmware file. I have done some basic tests and seems to work fine. Bindiff also looks fine Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Re: [PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function
Hi Javier, 2016-05-27 16:18 GMT+02:00 Javier Martinez Canillas : > Hello, > > While booting a system with a mwifiex WiFi card, I noticed the following > missleading error message: > > [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available > > This error only applies to platforms that define a child node for the SDIO > device, but it's currently shown even in platforms that don't have a child > node defined. > > So this series fixes this issue and others I found in the .probe function > (mostly related to error handling and the error path) while looking at it. > The patches looks good to me and tested on my Veyron Chromebook, so for all this series: Tested-by: Enric Balletbo i Serra Thanks, Enric > Best regards, > Javier > > > Javier Martinez Canillas (8): > mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node > mwifiex: propagate sdio_enable_func() errno code in > mwifiex_sdio_probe() > mwifiex: propagate mwifiex_add_card() errno code in > mwifiex_sdio_probe() > mwifiex: consolidate mwifiex_sdio_probe() error paths > mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe() > mwifiex: check if mwifiex_sdio_probe_of() fails and return error > mwifiex: don't print an error if an optional DT property is missing > mwifiex: use better message and error code when OF node doesn't match > > drivers/net/wireless/marvell/mwifiex/sdio.c | 46 > ++--- > 1 file changed, 28 insertions(+), 18 deletions(-) > > -- > 2.5.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
