* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: miaoqing @ 2016-11-24 6:06 UTC (permalink / raw)
To: Jason Cooper, Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <aaba8b1e30dd4c22be52e50befb202b2@aptaiexm02f.ap.qualcomm.com>
>> Okay, so i was 0, so running UP probably isn't going to help. r7 is
>> also spec_priv->rfs_chan_spec_scan.
>>
>> So, I think the question is... how is this NULL - and has it always
>> been NULL...
>
> The problem appears to be that ath_cmn_process_fft() isn't called that
> often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
> spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
>
> I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
> without crashing, I'll gin up a patch.
>
A similar patch was applied to ath-next branch:
https://patchwork.kernel.org/patch/9431163/.
--
Miaoqing
^ permalink raw reply
* [PATCH 4/4] mac80211: Remove unused 'beaconint_us' variable
From: Kirtika Ruchandani @ 2016-11-24 4:46 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
In-Reply-To: <cover.1479962513.git.kirtika@chromium.org>
Commit 4a733ef1bea7 (mac80211: remove PM-QoS listener) removed all use
of 'beaconint_us' from ieee80211_recalc_ps() but left the variable
intact. Compiling with W=1 gives the following warning, fix it.
net/mac80211/mlme.c: In function ‘ieee80211_recalc_ps’:
net/mac80211/mlme.c:1481:7: warning: variable ‘beaconint_us’ set but not used [-Wunused-but-set-variable]
iee80211_tu_to_usec has no side-effects and is safe to remove.
Fixes: 4a733ef1bea7 ("mac80211: remove PM-QoS listener")
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
net/mac80211/mlme.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 7486f2d..e883345 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1478,10 +1478,6 @@ void ieee80211_recalc_ps(struct ieee80211_local *local)
if (count == 1 && ieee80211_powersave_allowed(found)) {
u8 dtimper = found->u.mgd.dtim_period;
- s32 beaconint_us;
-
- beaconint_us = ieee80211_tu_to_usec(
- found->vif.bss_conf.beacon_int);
timeout = local->dynamic_ps_forced_timeout;
if (timeout < 0)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 3/4] mac80211: Removed unused 'struct ieee80211_supported_band*' variable
From: Kirtika Ruchandani @ 2016-11-24 4:46 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
In-Reply-To: <cover.1479962513.git.kirtika@chromium.org>
Commit b1bce14a7954 (mac80211: update opmode when adding new station)
refactored ieee80211_vht_handle_opmode into __ieee80211_vht_handle_opmode
and ieee80211_vht_handle_opmode leaving a set but unused variable
(sband) in the former. Compiling with W=1 gives the following warning,
fix it.
net/mac80211/vht.c: In function ‘__ieee80211_vht_handle_opmode’:
net/mac80211/vht.c:424:35: warning: variable ‘sband’ set but not used [-Wunused-but-set-variable]
Remove 'struct ieee80211_local* local' as well, it was only used to
set sband.
This is a harmless warning, and is only being fixed to reduce the
noise with W=1 in the kernel.
Fixes: b1bce14a7954 ("mac80211: update opmode when adding new station")
Cc: Marek Kwaczynski <marek.kwaczynski@tieto.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
net/mac80211/vht.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..14920e3 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -420,14 +420,10 @@ u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta, u8 opmode,
enum nl80211_band band)
{
- struct ieee80211_local *local = sdata->local;
- struct ieee80211_supported_band *sband;
enum ieee80211_sta_rx_bandwidth new_bw;
u32 changed = 0;
u8 nss;
- sband = local->hw.wiphy->bands[band];
-
/* ignore - no support for BF yet */
if (opmode & IEEE80211_OPMODE_NOTIF_RX_NSS_TYPE_BF)
return 0;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/4] mac80211: Remove unused 'len' variable
From: Kirtika Ruchandani @ 2016-11-24 4:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
In-Reply-To: <cover.1479962513.git.kirtika@chromium.org>
Commit 633e27132625 (mac80211: split sched scan IEs) introduced the
len variable to keep track of the return value of
ieee80211_build_preq_ies() but did not use it. Compiling with W=1
gives the following warning, fix it.
net/mac80211/scan.c: In function ‘__ieee80211_request_sched_scan_start’:
net/mac80211/scan.c:1123:9: warning: variable ‘len’ set but not used [-Wunused-but-set-variable]
This is a harmless warning and is only being fixed to reduce the noise
with W=1 in the kernel.
Fixes: 633e27132625 ("mac80211: split sched scan IEs")
Cc: David Spinadel <david.spinadel@intel.com>
Cc: Alexander Bondar <alexander.bondar@intel.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
net/mac80211/scan.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 23d8ac8..faab3c4 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -1120,7 +1120,6 @@ int __ieee80211_request_sched_scan_start(struct ieee80211_sub_if_data *sdata,
u32 rate_masks[NUM_NL80211_BANDS] = {};
u8 bands_used = 0;
u8 *ie;
- size_t len;
iebufsz = local->scan_ies_len + req->ie_len;
@@ -1145,10 +1144,9 @@ int __ieee80211_request_sched_scan_start(struct ieee80211_sub_if_data *sdata,
ieee80211_prepare_scan_chandef(&chandef, req->scan_width);
- len = ieee80211_build_preq_ies(local, ie, num_bands * iebufsz,
- &sched_scan_ies, req->ie,
- req->ie_len, bands_used,
- rate_masks, &chandef);
+ ieee80211_build_preq_ies(local, ie, num_bands * iebufsz,
+ &sched_scan_ies, req->ie,
+ req->ie_len, bands_used, rate_masks, &chandef);
ret = drv_sched_scan_start(local, sdata, req, &sched_scan_ies);
if (ret == 0) {
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/4] mac80211: Removed unused 'i' variable
From: Kirtika Ruchandani @ 2016-11-24 4:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
In-Reply-To: <cover.1479962513.git.kirtika@chromium.org>
Commit 5bcae31d9 (mac80211: implement multi-vif in-place reservations)
introduced ieee80211_vif_use_reserved_switch() with a counter variable
'i' that is set but not used. Compiling with W=1 gives the following
warning, fix it.
net/mac80211/chan.c: In function ‘ieee80211_vif_use_reserved_switch’:
net/mac80211/chan.c:1273:6: warning: variable ‘i’ set but not used [-Wunused-but-set-variable]
This is a harmless warning, and is only being fixed to reduce the
noise obtained with W=1 in the kernel.
Fixes: 5bcae31d9 ("mac80211: implement multi-vif in-place reservations")
Cc: Michal Kazior <michal.kazior@tieto.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
net/mac80211/chan.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index e75cbf6..7550fd2 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -1270,7 +1270,7 @@ static int ieee80211_vif_use_reserved_switch(struct ieee80211_local *local)
struct ieee80211_sub_if_data *sdata, *sdata_tmp;
struct ieee80211_chanctx *ctx, *ctx_tmp, *old_ctx;
struct ieee80211_chanctx *new_ctx = NULL;
- int i, err, n_assigned, n_reserved, n_ready;
+ int err, n_assigned, n_reserved, n_ready;
int n_ctx = 0, n_vifs_switch = 0, n_vifs_assign = 0, n_vifs_ctxless = 0;
lockdep_assert_held(&local->mtx);
@@ -1391,8 +1391,6 @@ static int ieee80211_vif_use_reserved_switch(struct ieee80211_local *local)
* Update all structures, values and pointers to point to new channel
* context(s).
*/
-
- i = 0;
list_for_each_entry(ctx, &local->chanctx_list, list) {
if (ctx->replace_state != IEEE80211_CHANCTX_REPLACES_OTHER)
continue;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 0/4] Fix -Wunused-but-set-variable in net/mac80211/
From: Kirtika Ruchandani @ 2016-11-24 4:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
This patchset is part of the effort led by Arnd Bergmann to clean up
warnings in the kernel. This and following patchsets will focus on
"-Wunused-but-set-variable" as it among the noisier ones. These were
found compiling with W=1.
Kirtika Ruchandani (4):
mac80211: Removed unused 'i' variable
mac80211: Remove unused 'len' variable
mac80211: Removed unused 'struct ieee80211_supported_band*' variable
mac80211: Remove unused 'beaconint_us' variable
net/mac80211/chan.c | 4 +---
net/mac80211/mlme.c | 4 ----
net/mac80211/scan.c | 8 +++-----
net/mac80211/vht.c | 4 ----
4 files changed, 4 insertions(+), 16 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [PATCH v2 7/7] mwifiex: Remove unused 'bcd_usb' variable
From: Kirtika Ruchandani @ 2016-11-24 1:27 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
mwifiex_usb_probe() defines and sets bcd_usb but does not use it,
Compiling with W=1 gives the following warning, fix it.
mwifiex/usb.c: In function ‘mwifiex_usb_probe’:
mwifiex/usb.c:383:41: warning: variable ‘bcd_usb’ set but not used [-Wunused-but-set-variable]
The unused variable seems to be present since 4daffe354366 which introduced
mwifiex_usb_probe().
Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset")
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index c3f696a..c563160 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -379,7 +379,7 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
struct usb_endpoint_descriptor *epd;
int ret, i;
struct usb_card_rec *card;
- u16 id_vendor, id_product, bcd_device, bcd_usb;
+ u16 id_vendor, id_product, bcd_device;
card = devm_kzalloc(&intf->dev, sizeof(*card), GFP_KERNEL);
if (!card)
@@ -390,7 +390,6 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
id_vendor = le16_to_cpu(udev->descriptor.idVendor);
id_product = le16_to_cpu(udev->descriptor.idProduct);
bcd_device = le16_to_cpu(udev->descriptor.bcdDevice);
- bcd_usb = le16_to_cpu(udev->descriptor.bcdUSB);
pr_debug("info: VID/PID = %X/%X, Boot2 version = %X\n",
id_vendor, id_product, bcd_device);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 6/7] mwifiex: Removed unused 'pkt_type' variable
From: Kirtika Ruchandani @ 2016-11-24 1:26 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit 92263a841b15 introduced mwifiex_deaggr_sdio_pkt which initializes
variable pkt_type but does not use it. Compiling with W=1 gives the following
warning, fix it.
mwifiex/sdio.c: In function ‘mwifiex_deaggr_sdio_pkt’:
mwifiex/sdio.c:1198:6: warning: variable ‘pkt_type’ set but not used [-Wunused-but-set-variable]
Fixes: 92263a841b15 ("mwifiex: add SDIO rx single port aggregation")
Cc: Zhaoyang Liu <liuzy@marvell.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 6c9f16e..09c586f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1134,7 +1134,6 @@ static void mwifiex_deaggr_sdio_pkt(struct mwifiex_adapter *adapter,
{
u32 total_pkt_len, pkt_len;
struct sk_buff *skb_deaggr;
- u32 pkt_type;
u16 blk_size;
u8 blk_num;
u8 *data;
@@ -1155,8 +1154,6 @@ static void mwifiex_deaggr_sdio_pkt(struct mwifiex_adapter *adapter,
break;
}
pkt_len = le16_to_cpu(*(__le16 *)(data + SDIO_HEADER_OFFSET));
- pkt_type = le16_to_cpu(*(__le16 *)(data + SDIO_HEADER_OFFSET +
- 2));
if ((pkt_len + SDIO_HEADER_OFFSET) > blk_size) {
mwifiex_dbg(adapter, ERROR,
"%s: error in pkt_len,\t"
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 5/7] mwifiex: Remove unused 'pm_flag' variable
From: Kirtika Ruchandani @ 2016-11-24 1:26 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
mwifiex_sdio_resume() intializes pm_flag, just like
mwifiex_sdio_suspend(), but does not use it. Compiling with W=1 gives
the following warning, fix it.
mwifiex/sdio.c: In function ‘mwifiex_sdio_resume’:
mwifiex/sdio.c:234:16: warning: variable ‘pm_flag’ set but not used [-Wunused-but-set-variable]
sdio_get_host_pm_caps() is just an acessor, so the call to it is safe
to remove. The unused variable seems to be present since
5e6e3a92b9a4 which introduced mwifiex_sdio_resume().
Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Cc: Bing Zhao <bzhao@marvell.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 0d00db5..6c9f16e 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -186,9 +186,7 @@ static int mwifiex_sdio_resume(struct device *dev)
struct sdio_func *func = dev_to_sdio_func(dev);
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
- mmc_pm_flag_t pm_flag = 0;
- pm_flag = sdio_get_host_pm_caps(func);
card = sdio_get_drvdata(func);
if (!card || !card->adapter) {
dev_err(dev, "resume: invalid card or adapter\n");
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 4/7] mwifiex: Remove unused 'adapter'variable
From: Kirtika Ruchandani @ 2016-11-24 1:25 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit 3935ccc14d2c introduced mwifiex_tm_cmd() which initializes
struct mwifiex_adapter* adapter, but doesn't use it.
Compiling with W=1 gives the following warning, fix it.
mwifiex/cfg80211.c: In function ‘mwifiex_tm_cmd’:
mwifiex/cfg80211.c:3973:26: warning: variable ‘adapter’ set but not used [-Wunused-but-set-variable]
Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support")
Cc: Xinming Hu <huxm@marvell.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index c26469a..a231f09 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3980,13 +3980,11 @@ static int mwifiex_tm_cmd(struct wiphy *wiphy, struct wireless_dev *wdev,
struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev->netdev);
struct mwifiex_ds_misc_cmd *hostcmd;
struct nlattr *tb[MWIFIEX_TM_ATTR_MAX + 1];
- struct mwifiex_adapter *adapter;
struct sk_buff *skb;
int err;
if (!priv)
return -EINVAL;
- adapter = priv->adapter;
err = nla_parse(tb, MWIFIEX_TM_ATTR_MAX, data, len,
mwifiex_tm_policy);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 3/7] mwifiex: Remove unused 'sta_ptr' variable
From: Kirtika Ruchandani @ 2016-11-24 1:25 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit 429d90d2212b introduced mwifiex_cmd_tdls_oper() which initializes
struct mwifiex_sta_node* sta_ptr, but does not use it. Compiling with W=1 gives
the following warning, fix it.
mwifiex/sta_cmd.c: In function ‘mwifiex_cmd_tdls_oper’:
mwifiex/sta_cmd.c:1732:27: warning: variable ‘sta_ptr’ set but not used [-Wunused-but-set-variable]
Fixes: 429d90d2212b ("mwifiex: add cfg80211 tdls_oper handler support")
Cc: Avinash Patil <patila@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index bcd6408..768c519 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1746,7 +1746,6 @@ mwifiex_cmd_tdls_oper(struct mwifiex_private *priv,
{
struct host_cmd_ds_tdls_oper *tdls_oper = &cmd->params.tdls_oper;
struct mwifiex_ds_tdls_oper *oper = data_buf;
- struct mwifiex_sta_node *sta_ptr;
struct host_cmd_tlv_rates *tlv_rates;
struct mwifiex_ie_types_htcap *ht_capab;
struct mwifiex_ie_types_qos_info *wmm_qos_info;
@@ -1764,7 +1763,6 @@ mwifiex_cmd_tdls_oper(struct mwifiex_private *priv,
tdls_oper->reason = 0;
memcpy(tdls_oper->peer_mac, oper->peer_mac, ETH_ALEN);
- sta_ptr = mwifiex_get_sta_entry(priv, oper->peer_mac);
pos = (u8 *)tdls_oper + sizeof(struct host_cmd_ds_tdls_oper);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 2/7] mwifiex: Remove unused 'chan_num' variable
From: Kirtika Ruchandani @ 2016-11-24 1:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit b5413e6b2228 removed all uses of chan_num in mwifiex_config_scan().
Compiling mwifiex with W=1 gives the following warning, fix it.
mwifiex/scan.c: In function ‘mwifiex_config_scan’:
mwifiex/scan.c:830:6: warning: variable ‘chan_num’ set but not used [-Wunused-but-set-variable]
Fixes: b5413e6b2228 ("mwifiex: increase the number of nodes in command pool")
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 98ce072..1816916 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -827,7 +827,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
u32 num_probes;
u32 ssid_len;
u32 chan_idx;
- u32 chan_num;
u32 scan_type;
u16 scan_dur;
u8 channel;
@@ -1105,13 +1104,12 @@ mwifiex_config_scan(struct mwifiex_private *priv,
mwifiex_dbg(adapter, INFO,
"info: Scan: Scanning current channel only\n");
}
- chan_num = chan_idx;
} else {
mwifiex_dbg(adapter, INFO,
"info: Scan: Creating full region channel list\n");
- chan_num = mwifiex_scan_create_channel_list(priv, user_scan_in,
- scan_chan_list,
- *filtered_scan);
+ mwifiex_scan_create_channel_list(priv, user_scan_in,
+ scan_chan_list,
+ *filtered_scan);
}
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable
From: Kirtika Ruchandani @ 2016-11-24 1:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit bec568ff5107 removed the last remaining usage of struct
mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to
mwifiex_del_virtual_intf().
Compiling mwifiex/ with W=1 gives the following warning, fix it.
mwifiex/main.c: In function ‘mwifiex_fw_dpc’:
mwifiex/main.c:520:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable]
Fixes: bec568ff5107 ("mwifiex: failure path handling in mwifiex_add_virtual_intf()")
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index eac44fe..e5c3a8a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -518,7 +518,6 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
{
int ret;
char fmt[64];
- struct mwifiex_private *priv;
struct mwifiex_adapter *adapter = context;
struct mwifiex_fw_image fw;
bool init_failed = false;
@@ -576,8 +575,6 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
goto err_init_fw;
}
- priv = adapter->priv[MWIFIEX_BSS_ROLE_STA];
-
if (!adapter->wiphy) {
if (mwifiex_register_cfg80211(adapter)) {
mwifiex_dbg(adapter, ERROR,
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 0/7] Fix -Wunused-but-set-variable in mwifiex/
From: Kirtika Ruchandani @ 2016-11-24 1:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
This patchset is part of the effort led by Arnd Bergmann to clean up
warnings in the kernel. This and following patchsets will focus on
"-Wunused-but-set-variable" as it among the noisier ones. These were
found compiling with W=1.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
Changes in v2:
- Reapplied patches on top of wireless-drivers-next.
- Patch 5/7 ("mwifiex: Remove unused 'pm_flag' variable") had to be
redone slightly. The others applied cleanly with 'patch -p1'.
Kirtika Ruchandani (7):
mwifiex: Removed unused mwifiex_private* 'priv' variable
mwifiex: Remove unused 'chan_num' variable
mwifiex: Remove unused 'sta_ptr' variable
mwifiex: Remove unused 'adapter'variable
mwifiex: Remove unused 'pm_flag' variable
mwifiex: Removed unused 'pkt_type' variable
mwifiex: Remove unused 'bcd_usb' variable
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 --
drivers/net/wireless/marvell/mwifiex/main.c | 3 ---
drivers/net/wireless/marvell/mwifiex/scan.c | 8 +++-----
drivers/net/wireless/marvell/mwifiex/sdio.c | 5 -----
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 --
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +--
6 files changed, 4 insertions(+), 19 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-23 22:39 UTC (permalink / raw)
To: Pavel Machek
Cc: Michal Kazior, Kalle Valo, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161123222335.GA4788@amd>
[-- Attachment #1: Type: Text/Plain, Size: 2153 bytes --]
On Wednesday 23 November 2016 23:23:35 Pavel Machek wrote:
> Hi!
>
> > > > As wl1251.ko does not accept mac_address as module parameter,
> > > > such modprobe hook does not help -- as there is absolutely no
> > > > way from userspace to set or change (permanent) mac address.
> > >
> > > Quoting modprobe.d manual:
> > > > install modulename command...
> > > >
> > > > This command instructs modprobe to run your
> > > > command instead of inserting the module in the
> > > > kernel as normal. The command can be any shell
> > > > command: this allows you to do any kind of
> > > > complex processing you might wish. [...]
> >
> > I know. But this do not allow me to send mac address to kernel --
> > as kernel does not support such command yet (reason for my first
> > question).
>
> Plus, this does not really work for cases where wl1251 is not a
> module.
Yes, this is another problem.
> > > You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> > > macaddr) and then insmod the actual wl1251.ko module. Or you can
> > > just cook up the nvs on first device boot and store it in
> > > /lib/firmware (possibly overwriting the "generic" wl1251 from
> > > linux-firmware).
> >
> > This is what I would like to prevent -- overwriting (possible
> > readonly) system files with some device specific. It is really bad
> > idea!
>
> Agreed.
>
> "ifconfig hw ether XX" normally sets the address. I guess that's
> ioctl?
This sets temporary address and it is ioctl. IIRC same as what ethtool
uses. (ifconfig is already deprecated).
> And I guess we should use similar mechanism for permanent
> address.
I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
address. But here we do not want to change permanent mac address. We
want to tell kernel driver current permanent mac address which is stored
in permanent mac address storage (in N900 case in mtd). Just like
userspace helper as kernel driver do not have code which can read
permanent mac address.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Break-it testing for wifi
From: Jouni Malinen @ 2016-11-23 22:29 UTC (permalink / raw)
To: Ben Greear; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <5834797B.2090805@candelatech.com>
On Tue, Nov 22, 2016 at 08:59:39AM -0800, Ben Greear wrote:
> On 11/22/2016 02:56 AM, Johannes Berg wrote:
> >On Mon, 2016-11-21 at 08:10 -0800, Ben Greear wrote:
> >>1) Allow supplicant to do bad state-machine transitions (start 4-way
> >>before associating, for instance).
> >
> >Why would you do that? In order to test the AP implementation?
>
> Yes. And really, you should be able to do similar things on the AP to test stations,
> or on IBSS/Mesh devices, etc. hostapd already has some options to corrupt or
> drop a percentage of various management frames. Supplicant does not as far
> as I know.
I'm not sure adding a specific option to corrupt or drop a management
frame is the best approach here. Both hostapd and wpa_supplicant have
multiple mechanisms to enable testing in CONFIG_TESTING_OPTIONS=y builds
and the most flexible cases allow the management and EAPOL frame
processing to be handled by a test script through the control interface.
This provides much more control on how to misbehave and allows that to
be done at higher layer components without having to hardcode stuff in
hostapd/wpa_supplicant (or kernel for that matter). In case of
mac80211_hwsim tests, this is done in the python scripts (see
tests/hwsim directory in hostap.git).
> Currently, supplicant can (at least with some small patches that I carry),
> add custom information elements to probe requests and similar. But, some things
> are built by mac80211 (rate-sets advertised, for instance). So, I was thinking of slightly extending
> the API so that user-space could over-ride whatever mac80211 might normally
> build itself. That lets you more properly fuzz things from user space.
For many cases, I'd expect it to be more flexible to override full frame
payload from a test script rather than come up with more detailed (and
more complex to implement) APIs.. As far as cfg80211/mac80211 is
concerned, it might be convenient to have a command that allows user
space to force a STA entry to a specific state when working in station
mode (hostapd can already do this in AP mode). This would allow the
existing offchannel management frame TX/RX operations to be used to
perform arbitrary exchanges and with the forced state changes, this
could cover more cases related to negotiating unexpected combinations or
exchanges frames in unexpected sequence, etc.
> >>4) Maybe some specific tests like putting in over-flow sized lengths
> >>of IEs.
> >
> >Again, fuzzing would cover this?
>
> Yes, but for ease of use, and to cover frames generated by mac80211, I
> was thinking:
>
> echo 0.25 > /debug/.../wlan0/mgt_fuzzer
>
> The fuzzer would then corrupt 25% of the management frames. And instead of just randomly
> scribbling, it could also parse the frames and do some more clever (and still pseudo-random)
> modifications to the frames, like re-writing IEs with bad lengths, flipping bits in specific portions of the
> frame we feel might find problems, etc.
Why would this be in mac80211? I would much rather handle this type of
fuzzing operations in user space and just provide generic interfaces in
cfg80211 to allow the messages to be exchanged. For most parts, this
capability exists already today..
> >>Has anyone done anything similar they would like to share?
> >>
> >>Johannes: Any interest in having such a framework in upstream
> >>kernels?
hostap.git tests/hwsim has quite a few such functions in testing use. I
don't think I'd support kernel changes in the style that you are
thinking of here, but I would very much support providing more generic
interfaces, where required, to allow this type of testing to be
performed from user space scripts.
> Well, there is a decent chance you could crash some firmware if you sent
> corrupted EAPOL frames to it. And just possibly some drivers inspect packets as well,
> so I was thinking that fully transmitting the frames out of the system might
> have some use. And specifically for me, I am trying to test remote systems,
> so hwsim would not be useful for that.
>
Lots of this capability is already there in mac80211, cfg80211, hostapd,
and wpa_supplicant.. While mac80211_hwsim tests are one of the main use
cases for this, this works fine with any mac80211-based driver for
over-the-air testing as well. For AP mode, it is possible to override
most of management frame and EAPOL processing. For STA mode, EAPOL
processing can be fully overridden and quite a few management frame
exchanges can also be handled from test scripts through wpa_supplicant
control interface, but there may still exists some more constraints on
preventing some testing combinations.
> But, if local Linux (and local userspace) itself is the test target, then hwsim should give some very good
> test coverage.
Please keep in mind that almost anything that can tested with
mac80211_hwsim can also be used with real WLAN hardware when using
mac80211-based drivers..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pavel Machek @ 2016-11-23 22:23 UTC (permalink / raw)
To: Pali Rohár
Cc: Michal Kazior, Kalle Valo, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <201611221805.13606@pali>
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
Hi!
> > > As wl1251.ko does not accept mac_address as module parameter, such
> > > modprobe hook does not help -- as there is absolutely no way from
> > > userspace to set or change (permanent) mac address.
> >
> > Quoting modprobe.d manual:
> > > install modulename command...
> > >
> > > This command instructs modprobe to run your
> > > command instead of inserting the module in the
> > > kernel as normal. The command can be any shell
> > > command: this allows you to do any kind of
> > > complex processing you might wish. [...]
>
> I know. But this do not allow me to send mac address to kernel -- as
> kernel does not support such command yet (reason for my first
> question).
Plus, this does not really work for cases where wl1251 is not a
module.
> > You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> > macaddr) and then insmod the actual wl1251.ko module. Or you can just
> > cook up the nvs on first device boot and store it in /lib/firmware
> > (possibly overwriting the "generic" wl1251 from linux-firmware).
>
> This is what I would like to prevent -- overwriting (possible readonly)
> system files with some device specific. It is really bad idea!
Agreed.
"ifconfig hw ether XX" normally sets the address. I guess that's
ioctl? And I guess we should use similar mechanism for permanent
address.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Jouni Malinen @ 2016-11-23 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, vamsi krishna, Jouni Malinen
In-Reply-To: <1479938857-1788-1-git-send-email-jouni@qca.qualcomm.com>
From: vamsi krishna <vamsin@qti.qualcomm.com>
Enhance sched scan to support option of finding a better BSS while in
connected state. Firmware scans the medium and reports when it finds a
known BSS which has a significantly better RSSI than the current
connected BSS.
Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/net/cfg80211.h | 17 +++++++++++++++++
include/uapi/linux/nl80211.h | 17 +++++++++++++++++
net/wireless/nl80211.c | 32 ++++++++++++++++++++++++++++++--
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef42749..c62c42a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1626,6 +1626,20 @@ struct cfg80211_sched_scan_plan {
* cycle. The driver may ignore this parameter and start
* immediately (or at any other time), if this feature is not
* supported.
+ * @relative_rssi: Relative RSSI threshold to restrict scan result reporting in
+ * connected state to cases where a matching BSS is determined to have a
+ * significantly better RSSI than the current connected BSS.
+ * @relative_rssi_5g_pref: The amount of RSSI preference that is given to a
+ * 5 GHz BSS over 2.4 GHz BSS while looking for better BSSs in connected
+ * state.
+ * If the current connected BSS is in the 2.4 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by @relative_rssi
+ * and other BSSs in the 5 GHz band to be reported should have better RSSI
+ * by (@relative_rssi - @relative_rssi_5g_pref).
+ * If the current connected BSS is in the 5 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by
+ * (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
+ * band to be reported should have better RSSI by by @relative_rssi.
*/
struct cfg80211_sched_scan_request {
struct cfg80211_ssid *ssids;
@@ -1645,6 +1659,9 @@ struct cfg80211_sched_scan_request {
u8 mac_addr[ETH_ALEN] __aligned(2);
u8 mac_addr_mask[ETH_ALEN] __aligned(2);
+ int relative_rssi;
+ int relative_rssi_5g_pref;
+
/* internal */
struct wiphy *wiphy;
struct net_device *dev;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 984a35ac..34b16a4 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1981,6 +1981,16 @@ enum nl80211_commands {
* %NL80211_ATTR_MAC has also been used in various commands/events for
* specifying the BSSID.
*
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI: Relative RSSI threshold by which
+ * other BSSs has to be better than the current connected BSS so that they
+ * get reported to user space. This will give an opportunity to userspace
+ * to consider connecting to other matching BSSs which have better RSSI
+ * than the current connected BSS.
+ *
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF: The amount of RSSI preference
+ * to be given to 5 GHz APs over 2.4 GHz APs while searching for better
+ * BSSs than the current connected BSS.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2387,6 +2397,9 @@ enum nl80211_attrs {
NL80211_ATTR_BSSID,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -4698,6 +4711,9 @@ enum nl80211_feature_flags {
* configuration (AP/mesh) with VHT rates.
* @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
* with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
+ * @NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS: The driver supports sched_scan
+ * for reporting BSSs with better RSSI than the current connected BSS
+ * (%NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI).
*
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4713,6 +4729,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
NL80211_EXT_FEATURE_FILS_STA,
+ NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8db5cb1..af018a5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -405,6 +405,8 @@ enum nl80211_multicast_groups {
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
[NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
+ [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] = { .type = NLA_U32 },
+ [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF] = { .type = NLA_U32 },
};
/* policy for the key attributes */
@@ -6856,6 +6858,7 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
size_t ie_len;
struct nlattr *tb[NL80211_SCHED_SCAN_MATCH_ATTR_MAX + 1];
s32 default_match_rssi = NL80211_SCAN_RSSI_THOLD_OFF;
+ int bbr;
if (!is_valid_ie_attr(attrs[NL80211_ATTR_IE]))
return ERR_PTR(-EINVAL);
@@ -6950,6 +6953,13 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
if (!n_plans || n_plans > wiphy->max_sched_scan_plans)
return ERR_PTR(-EINVAL);
+ bbr = wiphy_ext_feature_isset(
+ wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS);
+ if (!bbr &&
+ (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] ||
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]))
+ return ERR_PTR(-EINVAL);
+
request = kzalloc(sizeof(*request)
+ sizeof(*request->ssids) * n_ssids
+ sizeof(*request->match_sets) * n_match_sets
@@ -7156,6 +7166,14 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
request->delay =
nla_get_u32(attrs[NL80211_ATTR_SCHED_SCAN_DELAY]);
+ if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI])
+ request->relative_rssi = nla_get_s32(
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]);
+
+ if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF])
+ request->relative_rssi_5g_pref = nla_get_s32(
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]);
+
err = nl80211_parse_sched_scan_plans(wiphy, n_plans, request, attrs);
if (err)
goto out_free;
@@ -9649,7 +9667,8 @@ static int nl80211_send_wowlan_tcp(struct sk_buff *msg,
return 0;
}
-static int nl80211_send_wowlan_nd(struct sk_buff *msg,
+static int nl80211_send_wowlan_nd(struct wiphy *wiphy,
+ struct sk_buff *msg,
struct cfg80211_sched_scan_request *req)
{
struct nlattr *nd, *freqs, *matches, *match, *scan_plans, *scan_plan;
@@ -9670,6 +9689,15 @@ static int nl80211_send_wowlan_nd(struct sk_buff *msg,
if (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_DELAY, req->delay))
return -ENOBUFS;
+ if (wiphy_ext_feature_isset(
+ wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS) &&
+ (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
+ req->relative_rssi) ||
+ nla_put_u32(msg,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
+ req->relative_rssi_5g_pref)))
+ return -ENOBUFS;
+
freqs = nla_nest_start(msg, NL80211_ATTR_SCAN_FREQUENCIES);
if (!freqs)
return -ENOBUFS;
@@ -9783,7 +9811,7 @@ static int nl80211_get_wowlan(struct sk_buff *skb, struct genl_info *info)
goto nla_put_failure;
if (nl80211_send_wowlan_nd(
- msg,
+ &rdev->wiphy, msg,
rdev->wiphy.wowlan_config->nd_config))
goto nla_put_failure;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] nl80211: Use different attrs for BSSID and random MAC addr in scan req
From: Jouni Malinen @ 2016-11-23 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Vamsi Krishna, Jouni Malinen
From: Vamsi Krishna <vamsin@qti.qualcomm.com>
NL80211_ATTR_MAC was used to set both the specific BSSID to be scanned
and the random MAC address to be used when privacy is enabled. When both
the features are enabled, both the BSSID and the local MAC address were
getting same value causing Probe Request frames to go with unintended
DA. Hence, this has been fixed by using a different NL80211_ATTR_BSSID
attribute to set the specific BSSID (which was the more recent addition
in cfg80211) for a scan.
Backwards compatibility with old userspace software is maintained to
some extend by allowing NL80211_ATTR_MAC to be used to set the specific
BSSID when scanning without enabling random MAC address use.
Scanning with random source MAC address was introduced by commit
ad2b26abc157 ("cfg80211: allow drivers to support random MAC addresses
for scan") and the issue was introduced with the addition of the second
user for the same attribute in commit 818965d39177 ("cfg80211: Allow a
scan request for a specific BSSID").
Fixes: 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID")
Signed-off-by: Vamsi Krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/uapi/linux/nl80211.h | 8 +++++++-
net/wireless/nl80211.c | 16 +++++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 259c9c7..984a35ac 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -323,7 +323,7 @@
* @NL80211_CMD_GET_SCAN: get scan results
* @NL80211_CMD_TRIGGER_SCAN: trigger a new scan with the given parameters
* %NL80211_ATTR_TX_NO_CCK_RATE is used to decide whether to send the
- * probe requests at CCK rate or not. %NL80211_ATTR_MAC can be used to
+ * probe requests at CCK rate or not. %NL80211_ATTR_BSSID can be used to
* specify a BSSID to scan for; if not included, the wildcard BSSID will
* be used.
* @NL80211_CMD_NEW_SCAN_RESULTS: scan notification (as a reply to
@@ -1977,6 +1977,10 @@ enum nl80211_commands {
* @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Indicates whether or not multicast
* packets should be send out as unicast to all stations (flag attribute).
*
+ * @NL80211_ATTR_BSSID: The BSSID of the AP (various uses). Note that
+ * %NL80211_ATTR_MAC has also been used in various commands/events for
+ * specifying the BSSID.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2381,6 +2385,8 @@ enum nl80211_attrs {
NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED,
+ NL80211_ATTR_BSSID,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e4f718e..8db5cb1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -404,6 +404,7 @@ enum nl80211_multicast_groups {
.len = FILS_MAX_KEK_LEN },
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
+ [NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
};
/* policy for the key attributes */
@@ -6703,7 +6704,20 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
request->no_cck =
nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
- if (info->attrs[NL80211_ATTR_MAC])
+ /* Initial implementation used NL80211_ATTR_MAC to set the specific
+ * BSSID to scan for. This was problematic because that same attribute
+ * was already used for another purpose (local random MAC address). The
+ * NL80211_ATTR_BSSID attribute was added to fix this. For backwards
+ * compatibility with older userspace components, also use the
+ * NL80211_ATTR_MAC value here if it can be determined to be used for
+ * the specific BSSID use case instead of the random MAC address
+ * (NL80211_ATTR_SCAN_FLAGS is used to enable random MAC address use).
+ */
+ if (info->attrs[NL80211_ATTR_BSSID])
+ memcpy(request->bssid,
+ nla_data(info->attrs[NL80211_ATTR_BSSID]), ETH_ALEN);
+ else if (!info->attrs[NL80211_ATTR_SCAN_FLAGS] &&
+ info->attrs[NL80211_ATTR_MAC])
memcpy(request->bssid, nla_data(info->attrs[NL80211_ATTR_MAC]),
ETH_ALEN);
else
--
1.9.1
^ permalink raw reply related
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 21:40 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123211745.GF14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 09:17:45PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> > As requested on irc:
>
> Thanks.
>
> > 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> > 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> > 7f8: ebfffffe bl 0 <relay_buf_full>
> > 7fc: e0844000 add r4, r4, r0
> > 800: e300a000 movw sl, #0
> > 804: e28b2001 add r2, fp, #1
> > 808: e340a000 movt sl, #0
> > 80c: e3a01004 mov r1, #4
> > 810: e1a0000a mov r0, sl
> > 814: ebfffffe bl 0 <_find_next_bit_le>
> > 818: e5953000 ldr r3, [r5]
> > 81c: e1500003 cmp r0, r3
> > 820: e1a0b000 mov fp, r0
> > 824: e2802008 add r2, r0, #8
> > 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
>
> Okay, so i was 0, so running UP probably isn't going to help. r7 is
> also spec_priv->rfs_chan_spec_scan.
>
> So, I think the question is... how is this NULL - and has it always
> been NULL...
The problem appears to be that ath_cmn_process_fft() isn't called that
often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
without crashing, I'll gin up a patch.
thx,
Jason.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 21:17 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123205917.GI2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> As requested on irc:
Thanks.
> 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> 7f8: ebfffffe bl 0 <relay_buf_full>
> 7fc: e0844000 add r4, r4, r0
> 800: e300a000 movw sl, #0
> 804: e28b2001 add r2, fp, #1
> 808: e340a000 movt sl, #0
> 80c: e3a01004 mov r1, #4
> 810: e1a0000a mov r0, sl
> 814: ebfffffe bl 0 <_find_next_bit_le>
> 818: e5953000 ldr r3, [r5]
> 81c: e1500003 cmp r0, r3
> 820: e1a0b000 mov fp, r0
> 824: e2802008 add r2, r0, #8
> 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
Okay, so i was 0, so running UP probably isn't going to help. r7 is
also spec_priv->rfs_chan_spec_scan.
So, I think the question is... how is this NULL - and has it always
been NULL...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
>
> where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
> there's precious little to go on with the Code: line - modern GCCs
> don't give us much with the Code: line anymore to figure out what's
> going on without the exact object files.
>
> e5933000 ldr r3, [r3]
> e1d330b4 ldrh r3, [r3, #4]
> e58d3030 str r3, [sp, #48] ; 0x30
> ea000002 b 1c <foo+0x1c>
> e7970102 ldr r0, [r7, r2, lsl #2]
>
As requested on irc:
-------------->8--------------------------------------------------------
drivers/net/wireless/ath/ath9k/common-spectral.o: file format elf32-littlearm
Disassembly of section .text:
...
00000754 <ath_cmn_process_fft>:
754: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
758: e24dd0d4 sub sp, sp, #212 ; 0xd4
75c: e1a04002 mov r4, r2
760: e1a06001 mov r6, r1
764: e58d0024 str r0, [sp, #36] ; 0x24
768: e3a01000 mov r1, #0
76c: e58d2018 str r2, [sp, #24]
770: e28d0049 add r0, sp, #73 ; 0x49
774: e3a02087 mov r2, #135 ; 0x87
778: ebfffffe bl 0 <memset>
77c: e5d44007 ldrb r4, [r4, #7]
780: e20430fd and r3, r4, #253 ; 0xfd
784: e3530024 cmp r3, #36 ; 0x24
788: 13540005 cmpne r4, #5
78c: 13a04001 movne r4, #1
790: 03a04000 moveq r4, #0
794: 13a00000 movne r0, #0
798: 0a000001 beq 7a4 <ath_cmn_process_fft+0x50>
79c: e28dd0d4 add sp, sp, #212 ; 0xd4
7a0: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
7a4: e59d3018 ldr r3, [sp, #24]
7a8: e1d380b4 ldrh r8, [r3, #4]
7ac: e2489003 sub r9, r8, #3
7b0: e0863009 add r3, r6, r9
7b4: e5d30002 ldrb r0, [r3, #2]
7b8: e2000010 and r0, r0, #16
7bc: e21000ff ands r0, r0, #255 ; 0xff
7c0: 0afffff5 beq 79c <ath_cmn_process_fft+0x48>
7c4: e59d3024 ldr r3, [sp, #36] ; 0x24
7c8: e3005000 movw r5, #0
7cc: e3405000 movt r5, #0
7d0: e3e0b000 mvn fp, #0
7d4: e5932000 ldr r2, [r3]
7d8: e5937004 ldr r7, [r3, #4]
7dc: e5923438 ldr r3, [r2, #1080] ; 0x438
7e0: e58d2010 str r2, [sp, #16]
7e4: e5933000 ldr r3, [r3]
7e8: e1d330b4 ldrh r3, [r3, #4]
7ec: e58d3030 str r3, [sp, #48] ; 0x30
7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
7f4: e7970102 ldr r0, [r7, r2, lsl #2]
7f8: ebfffffe bl 0 <relay_buf_full>
7fc: e0844000 add r4, r4, r0
800: e300a000 movw sl, #0
804: e28b2001 add r2, fp, #1
808: e340a000 movt sl, #0
80c: e3a01004 mov r1, #4
810: e1a0000a mov r0, sl
814: ebfffffe bl 0 <_find_next_bit_le>
818: e5953000 ldr r3, [r5]
81c: e1500003 cmp r0, r3
820: e1a0b000 mov fp, r0
824: e2802008 add r2, r0, #8
828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
82c: e59a0000 ldr r0, [sl]
830: e200000f and r0, r0, #15
834: ebfffffe bl 0 <__sw_hweight32>
838: e1540000 cmp r4, r0
83c: 0a000092 beq a8c <ath_cmn_process_fft+0x338>
840: e59d3010 ldr r3, [sp, #16]
844: e5932030 ldr r2, [r3, #48] ; 0x30
848: e5923018 ldr r3, [r2, #24]
84c: e3530001 cmp r3, #1
850: 0a000090 beq a98 <ath_cmn_process_fft+0x344>
854: 3a000119 bcc cc0 <ath_cmn_process_fft+0x56c>
858: e3530002 cmp r3, #2
85c: 1a000110 bne ca4 <ath_cmn_process_fft+0x550>
860: e3003000 movw r3, #0
864: e5921014 ldr r1, [r2, #20]
868: e1a00003 mov r0, r3
86c: e592301c ldr r3, [r2, #28]
870: e3002000 movw r2, #0
874: e3a0b087 mov fp, #135 ; 0x87
878: e1a0c002 mov ip, r2
87c: e1a02000 mov r2, r0
880: e3402000 movt r2, #0
884: e58d2034 str r2, [sp, #52] ; 0x34
888: e1a0200c mov r2, ip
88c: e3a0a08a mov sl, #138 ; 0x8a
890: e3402000 movt r2, #0
894: e58d2044 str r2, [sp, #68] ; 0x44
898: e1d120b4 ldrh r2, [r1, #4]
89c: e3a01080 mov r1, #128 ; 0x80
8a0: e58d1020 str r1, [sp, #32]
8a4: e1520003 cmp r2, r3
8a8: 33a03003 movcc r3, #3
8ac: 23a03002 movcs r3, #2
8b0: e58d3038 str r3, [sp, #56] ; 0x38
8b4: e2483002 sub r3, r8, #2
8b8: e58d3014 str r3, [sp, #20]
8bc: e3530000 cmp r3, #0
8c0: da000071 ble a8c <ath_cmn_process_fft+0x338>
8c4: e3a03000 mov r3, #0
8c8: e28aa002 add sl, sl, #2
8cc: e1a04003 mov r4, r3
8d0: e58d3028 str r3, [sp, #40] ; 0x28
8d4: e1a05004 mov r5, r4
8d8: e24b3001 sub r3, fp, #1
8dc: e1a07006 mov r7, r6
8e0: e58d302c str r3, [sp, #44] ; 0x2c
8e4: e58db01c str fp, [sp, #28]
8e8: e1a03009 mov r3, r9
8ec: e58d8010 str r8, [sp, #16]
8f0: e1a09004 mov r9, r4
8f4: ea00002c b 9ac <ath_cmn_process_fft+0x258>
8f8: e3520007 cmp r2, #7
8fc: e1a05003 mov r5, r3
900: e086b004 add fp, r6, r4
904: 8a00006f bhi ac8 <ath_cmn_process_fft+0x374>
908: e59d202c ldr r2, [sp, #44] ; 0x2c
90c: e1530002 cmp r3, r2
910: a3a09001 movge r9, #1
914: ba0000dd blt c90 <ath_cmn_process_fft+0x53c>
918: e59d101c ldr r1, [sp, #28]
91c: e2812002 add r2, r1, #2
920: e1520005 cmp r2, r5
924: ba000058 blt a8c <ath_cmn_process_fft+0x338>
928: e1510005 cmp r1, r5
92c: aa000092 bge b7c <ath_cmn_process_fft+0x428>
930: e5d7001f ldrb r0, [r7, #31]
934: e5d71020 ldrb r1, [r7, #32]
938: e1500001 cmp r0, r1
93c: 1a000052 bne a8c <ath_cmn_process_fft+0x338>
940: e58d3040 str r3, [sp, #64] ; 0x40
944: e1a01004 mov r1, r4
948: e59d3044 ldr r3, [sp, #68] ; 0x44
94c: e1a0000b mov r0, fp
950: e58d203c str r2, [sp, #60] ; 0x3c
954: e12fff33 blx r3
958: e3500000 cmp r0, #0
95c: e59d203c ldr r2, [sp, #60] ; 0x3c
960: e59d3040 ldr r3, [sp, #64] ; 0x40
964: 1a00008e bne ba4 <ath_cmn_process_fft+0x450>
968: e59d2010 ldr r2, [sp, #16]
96c: e152000a cmp r2, sl
970: da0000c9 ble c9c <ath_cmn_process_fft+0x548>
974: e59d9028 ldr r9, [sp, #40] ; 0x28
978: e2842001 add r2, r4, #1
97c: e0867002 add r7, r6, r2
980: e3590000 cmp r9, #0
984: 13a09000 movne r9, #0
988: 1a000003 bne 99c <ath_cmn_process_fft+0x248>
98c: e59d2020 ldr r2, [sp, #32]
990: e2425002 sub r5, r2, #2
994: e0844005 add r4, r4, r5
998: e2842001 add r2, r4, #1
99c: e1a04002 mov r4, r2
9a0: e59d2014 ldr r2, [sp, #20]
9a4: e1540002 cmp r4, r2
9a8: aa000037 bge a8c <ath_cmn_process_fft+0x338>
9ac: e59d2010 ldr r2, [sp, #16]
9b0: e152000a cmp r2, sl
9b4: e7d62004 ldrb r2, [r6, r4]
9b8: daffffce ble 8f8 <ath_cmn_process_fft+0x1a4>
9bc: e3520007 cmp r2, #7
9c0: e2855001 add r5, r5, #1
9c4: e086b004 add fp, r6, r4
9c8: 8a000002 bhi 9d8 <ath_cmn_process_fft+0x284>
9cc: e59d202c ldr r2, [sp, #44] ; 0x2c
9d0: e1550002 cmp r5, r2
9d4: aaffffcf bge 918 <ath_cmn_process_fft+0x1c4>
9d8: e3590000 cmp r9, #0
9dc: 0affffed beq 998 <ath_cmn_process_fft+0x244>
9e0: e59d201c ldr r2, [sp, #28]
9e4: e1520005 cmp r2, r5
9e8: 1affffe1 bne 974 <ath_cmn_process_fft+0x220>
9ec: ea00007e b bec <ath_cmn_process_fft+0x498>
9f0: e597e000 ldr lr, [r7]
9f4: e24b201f sub r2, fp, #31
9f8: e597c004 ldr ip, [r7, #4]
9fc: e2871021 add r1, r7, #33 ; 0x21
a00: e5973008 ldr r3, [r7, #8]
a04: e28d0068 add r0, sp, #104 ; 0x68
a08: e58de049 str lr, [sp, #73] ; 0x49
a0c: e58dc04d str ip, [sp, #77] ; 0x4d
a10: e597e010 ldr lr, [r7, #16]
a14: e597c014 ldr ip, [r7, #20]
a18: e58d3051 str r3, [sp, #81] ; 0x51
a1c: e597300c ldr r3, [r7, #12]
a20: e58de059 str lr, [sp, #89] ; 0x59
a24: e58dc05d str ip, [sp, #93] ; 0x5d
a28: e58d3055 str r3, [sp, #85] ; 0x55
a2c: e1d7c1bc ldrh ip, [r7, #28]
a30: e5973018 ldr r3, [r7, #24]
a34: e5d7e01f ldrb lr, [r7, #31]
a38: e1cdc6b5 strh ip, [sp, #101] ; 0x65
a3c: e58d3061 str r3, [sp, #97] ; 0x61
a40: e5cde067 strb lr, [sp, #103] ; 0x67
a44: ebfffffe bl 0 <memcpy>
a48: e59d3038 ldr r3, [sp, #56] ; 0x38
a4c: e59d1024 ldr r1, [sp, #36] ; 0x24
a50: e59d0018 ldr r0, [sp, #24]
a54: e58d300c str r3, [sp, #12]
a58: e59d3030 ldr r3, [sp, #48] ; 0x30
a5c: e58d3008 str r3, [sp, #8]
a60: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
a64: e1cd20f0 strd r2, [sp]
a68: e28d2049 add r2, sp, #73 ; 0x49
a6c: e59d3034 ldr r3, [sp, #52] ; 0x34
a70: e12fff33 blx r3
a74: e3a01087 mov r1, #135 ; 0x87
a78: e28d0049 add r0, sp, #73 ; 0x49
a7c: ebfffffe bl 0 <__memzero>
a80: e59d1020 ldr r1, [sp, #32]
a84: e28d0049 add r0, sp, #73 ; 0x49
a88: ebfffffe bl 0 <add_device_randomness>
a8c: e3a00001 mov r0, #1
a90: e28dd0d4 add sp, sp, #212 ; 0xd4
a94: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
a98: e58d3038 str r3, [sp, #56] ; 0x38
a9c: e3003000 movw r3, #0
aa0: e3002000 movw r2, #0
aa4: e3403000 movt r3, #0
aa8: e3402000 movt r2, #0
aac: e58d3034 str r3, [sp, #52] ; 0x34
ab0: e3a0b03c mov fp, #60 ; 0x3c
ab4: e3a03038 mov r3, #56 ; 0x38
ab8: e58d2044 str r2, [sp, #68] ; 0x44
abc: e3a0a03f mov sl, #63 ; 0x3f
ac0: e58d3020 str r3, [sp, #32]
ac4: eaffff7a b 8b4 <ath_cmn_process_fft+0x160>
ac8: e59db01c ldr fp, [sp, #28]
acc: e153000b cmp r3, fp
ad0: 0a00005e beq c50 <ath_cmn_process_fft+0x4fc>
ad4: e06b5005 rsb r5, fp, r5
ad8: e2855001 add r5, r5, #1
adc: e3550003 cmp r5, #3
ae0: 979ff105 ldrls pc, [pc, r5, lsl #2]
ae4: eaffffd7 b a48 <ath_cmn_process_fft+0x2f4>
ae8: 00000b0c andeq r0, r0, ip, lsl #22
aec: 00000af8 strdeq r0, [r0], -r8
af0: 00000b20 andeq r0, r0, r0, lsr #22
af4: 000009f0 strdeq r0, [r0], -r0 ; <UNPREDICTABLE>
af8: e1a0200b mov r2, fp
afc: e1a01007 mov r1, r7
b00: e28d0049 add r0, sp, #73 ; 0x49
b04: ebfffffe bl 0 <memcpy>
b08: eaffffce b a48 <ath_cmn_process_fft+0x2f4>
b0c: e24b2001 sub r2, fp, #1
b10: e1a01007 mov r1, r7
b14: e28d004a add r0, sp, #74 ; 0x4a
b18: ebfffffe bl 0 <memcpy>
b1c: eaffffc9 b a48 <ath_cmn_process_fft+0x2f4>
b20: e597e000 ldr lr, [r7]
b24: e24b2020 sub r2, fp, #32
b28: e597c004 ldr ip, [r7, #4]
b2c: e2871021 add r1, r7, #33 ; 0x21
b30: e5973008 ldr r3, [r7, #8]
b34: e28d0069 add r0, sp, #105 ; 0x69
b38: e58de04a str lr, [sp, #74] ; 0x4a
b3c: e58dc04e str ip, [sp, #78] ; 0x4e
b40: e597e010 ldr lr, [r7, #16]
b44: e597c014 ldr ip, [r7, #20]
b48: e58d3052 str r3, [sp, #82] ; 0x52
b4c: e597300c ldr r3, [r7, #12]
b50: e58de05a str lr, [sp, #90] ; 0x5a
b54: e58dc05e str ip, [sp, #94] ; 0x5e
b58: e5d7e01f ldrb lr, [r7, #31]
b5c: e1d7c1bc ldrh ip, [r7, #28]
b60: e58d3056 str r3, [sp, #86] ; 0x56
b64: e5973018 ldr r3, [r7, #24]
b68: e1cdc6b6 strh ip, [sp, #102] ; 0x66
b6c: e5cde068 strb lr, [sp, #104] ; 0x68
b70: e58d3062 str r3, [sp, #98] ; 0x62
b74: ebfffffe bl 0 <memcpy>
b78: eaffffb2 b a48 <ath_cmn_process_fft+0x2f4>
b7c: e58d3040 str r3, [sp, #64] ; 0x40
b80: e1a01004 mov r1, r4
b84: e59d3044 ldr r3, [sp, #68] ; 0x44
b88: e1a0000b mov r0, fp
b8c: e58d203c str r2, [sp, #60] ; 0x3c
b90: e12fff33 blx r3
b94: e3500000 cmp r0, #0
b98: e59d203c ldr r2, [sp, #60] ; 0x3c
b9c: e59d3040 ldr r3, [sp, #64] ; 0x40
ba0: 0a00000e beq be0 <ath_cmn_process_fft+0x48c>
ba4: e5d7101f ldrb r1, [r7, #31]
ba8: e5d70020 ldrb r0, [r7, #32]
bac: e59dc01c ldr ip, [sp, #28]
bb0: e15c0005 cmp ip, r5
bb4: d1510000 cmple r1, r0
bb8: 03a01001 moveq r1, #1
bbc: 13a01000 movne r1, #0
bc0: e1520005 cmp r2, r5
bc4: d3a02000 movle r2, #0
bc8: c2012001 andgt r2, r1, #1
bcc: e3520000 cmp r2, #0
bd0: 0a00001a beq c40 <ath_cmn_process_fft+0x4ec>
bd4: e5db2001 ldrb r2, [fp, #1]
bd8: e3520007 cmp r2, #7
bdc: 9affff6d bls 998 <ath_cmn_process_fft+0x244>
be0: e59d201c ldr r2, [sp, #28]
be4: e1520005 cmp r2, r5
be8: 1affff5e bne 968 <ath_cmn_process_fft+0x214>
bec: e58d303c str r3, [sp, #60] ; 0x3c
bf0: e1a02007 mov r2, r7
bf4: e59d3038 ldr r3, [sp, #56] ; 0x38
bf8: e1cd8fd8 ldrd r8, [sp, #248] ; 0xf8
bfc: e59d1024 ldr r1, [sp, #36] ; 0x24
c00: e58d300c str r3, [sp, #12]
c04: e59d3030 ldr r3, [sp, #48] ; 0x30
c08: e1cd80f0 strd r8, [sp]
c0c: e59d0018 ldr r0, [sp, #24]
c10: e58d3008 str r3, [sp, #8]
c14: e59d3034 ldr r3, [sp, #52] ; 0x34
c18: e12fff33 blx r3
c1c: e58d0028 str r0, [sp, #40] ; 0x28
c20: e1a00007 mov r0, r7
c24: e59d1020 ldr r1, [sp, #32]
c28: ebfffffe bl 0 <add_device_randomness>
c2c: e59d3010 ldr r3, [sp, #16]
c30: e153000a cmp r3, sl
c34: e59d303c ldr r3, [sp, #60] ; 0x3c
c38: caffff4d bgt 974 <ath_cmn_process_fft+0x220>
c3c: eaffff92 b a8c <ath_cmn_process_fft+0x338>
c40: e59d202c ldr r2, [sp, #44] ; 0x2c
c44: e1520005 cmp r2, r5
c48: 1affffe4 bne be0 <ath_cmn_process_fft+0x48c>
c4c: eaffffe0 b bd4 <ath_cmn_process_fft+0x480>
c50: e59d3038 ldr r3, [sp, #56] ; 0x38
c54: e59d1024 ldr r1, [sp, #36] ; 0x24
c58: e59d0018 ldr r0, [sp, #24]
c5c: e58d300c str r3, [sp, #12]
c60: e59d3030 ldr r3, [sp, #48] ; 0x30
c64: e58d3008 str r3, [sp, #8]
c68: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
c6c: e1cd20f0 strd r2, [sp]
c70: e1a02007 mov r2, r7
c74: e59d3034 ldr r3, [sp, #52] ; 0x34
c78: e12fff33 blx r3
c7c: e1a00007 mov r0, r7
c80: e59d1020 ldr r1, [sp, #32]
c84: ebfffffe bl 0 <add_device_randomness>
c88: e3a00001 mov r0, #1
c8c: eaffff7f b a90 <ath_cmn_process_fft+0x33c>
c90: e59d201c ldr r2, [sp, #28]
c94: e1530002 cmp r3, r2
c98: 0affffd3 beq bec <ath_cmn_process_fft+0x498>
c9c: e59db01c ldr fp, [sp, #28]
ca0: eaffff8b b ad4 <ath_cmn_process_fft+0x380>
ca4: e3000000 movw r0, #0
ca8: e300119a movw r1, #410 ; 0x19a
cac: e3400000 movt r0, #0
cb0: e3a03000 mov r3, #0
cb4: e58d3038 str r3, [sp, #56] ; 0x38
cb8: ebfffffe bl 0 <warn_slowpath_null>
cbc: eaffff76 b a9c <ath_cmn_process_fft+0x348>
cc0: e3a03000 mov r3, #0
cc4: e58d3038 str r3, [sp, #56] ; 0x38
cc8: eaffff73 b a9c <ath_cmn_process_fft+0x348>
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
Hi Russell,
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
ahhh, my config has NR_CPUS=4, this SoC is uniprocessor. I'm going to
give it a go with SMP=no. This config is a lightly modified
mvebu_v7_defconfig. However, NR_CPUS isn't set in mvebu_v7_defconfig.
Only in multi_v7_defconfig.
I suspect ath9k uses different logic for setting up the relay buffer(s)
than for the code you referenced.
If SMP=no fails to fail ( :-P ) then we'll know where to start digging.
thx,
Jason.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 19:51 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> ------- oops from v4.8.6 #2 ------------------------------------------
> [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> [42059.311799] pgd = c0004000
> [42059.314522] [00000020] *pgd=00000000
> [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> [42059.340613] task: c0b091c0 task.stack: c0b00000
> [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
Well, the good news is that it's reproducable.
It looks like it could be this:
static int
ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
{
for_each_online_cpu(i)
ret += relay_buf_full(rc->buf[i]);
where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
there's precious little to go on with the Code: line - modern GCCs
don't give us much with the Code: line anymore to figure out what's
going on without the exact object files.
e5933000 ldr r3, [r3]
e1d330b4 ldrh r3, [r3, #4]
e58d3030 str r3, [sp, #48] ; 0x30
ea000002 b 1c <foo+0x1c>
e7970102 ldr r0, [r7, r2, lsl #2]
What makes me wonder though is that if i=8, that means you must have a
system with 9 online CPUs, which is probably unlikely - or maybe that's
the problem, for_each_online_cpu() is going wrong...
If it's not that line of code, I don't see what else it would be based
on the output of my compiler - there's only one case in my disassembly
that corresponds with the single code line that we have to go on, and
it's this:
a44: e5983020 ldr r3, [r8, #32]
a48: e793010a ldr r0, [r3, sl, lsl #2] <===
a4c: ebfffffe bl 0 <relay_buf_full>
a50: e0844000 add r4, r4, r0
a54: e59f9434 ldr r9, [pc, #1076]
a58: e28a2001 add r2, sl, #1
a5c: e3a01004 mov r1, #4
a60: e1a00009 mov r0, r9
a64: ebfffffe bl 0 <_find_next_bit_le>
a68: e5953000 ldr r3, [r5]
a6c: e1500003 cmp r0, r3
a70: e1a0a000 mov sl, r0
a74: bafffff2 blt a44 <ath_cmn_process_fft+0xa8>
I'm debating now about whether we need to dump more of the code in the
oops - both before and after the faulting instruction...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:34 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Andrew Lunn
In-Reply-To: <87a8cqgfpp.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
On Wed, Nov 23, 2016 at 09:26:42PM +0200, Kalle Valo wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> > I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> > board (Marvell Armada 370 SoC). Every day or so I get a consistent
> > crash that brings down the whole board. I've attached three oops I
> > captured on the serial port.
> >
> > I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> > at me as "this would fix it". And since it takes a day or so to trigger
> > the oops, bisecting would be a bit brutal. Does anyone have any insight
> > into this?
>
> Is this a regression, meaning that it didn't crash on older kernels but
> crashes on newer ones? Or has it always crashed?
iirc, it's always done this. It's one of my spare wifi backhauls that
spends most of it's time in a cardboard box waiting for a task,
collecting dust. Kinda like the toys in Toy Story.
I pulled it out a month or so ago and the behavior started. It had
4.2.8 on it at the time. I upgraded to latest stable a few weeks ago
(v4.8.6) and I'm getting the same issue.
When I originally set it up, it didn't run long enough for me to recall
if the issue occurred. Best I recall, that was with v4.2.8.
thx,
Jason.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox