[PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"
This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159.
When Ath10k is in AP mode and an unassociated STA sends a VHT action frame
(Operating Mode Notification for the NSS change) periodically to AP this causes
ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during
NSS update. Over the time (with a certain client it can happen within 15 mins
when there are over 500 of these VHT action frames) continuous calls of
WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust.
To my knowledge setting WMI_PEER_NSS peer param itself enough to handle NSS
updates and no need to call ath10k_station_assoc(). So revert the original
commit from 2014 as it's unclear why the change was really needed.
Now the firmware assert doesn't happen anymore.
Issue observed in QCA9984 platform with firmware version:10.4-3.5.3-00053.
This Change tested in QCA9984 with firmware version: 10.4-3.5.3-00053 and
QCA988x platform with firmware version: 10.2.4-1.0-00036.
Signed-off-by: Karthikeyan Periyasamy
---
drivers/net/wireless/ath/ath10k/mac.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index ebb3f1b..800a86e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6028,9 +6028,8 @@ static void ath10k_sta_rc_update_wk(struct work_struct
*wk)
sta->addr, smps, err);
}
- if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
- changed & IEEE80211_RC_NSS_CHANGED) {
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp
rates/nss\n",
+ if (changed & IEEE80211_RC_SUPP_RATES_CHANGED) {
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp
rates\n",
sta->addr);
err = ath10k_station_assoc(ar, arvif->vif, sta, true);
--
1.9.1
Re: [v8 4/8] rsi: add coex support
Hi Prameela,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.16-rc3 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Amitkumar-Karwar/rsi-add-bluetooth-and-coex-support/20180226-073244
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
config: x86_64-randconfig-ne0-02261019 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the
linux-review/Amitkumar-Karwar/rsi-add-bluetooth-and-coex-support/20180226-073244
HEAD 9c5222af2b3dbf5143bc1fa4dc0af78fcfa3559d builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/net/wireless/rsi/rsi_91x_main.c: In function 'rsi_read_pkt':
>> drivers/net/wireless/rsi/rsi_91x_main.c:165:5: error: implicit declaration
>> of function 'rsi_coex_recv_pkt' [-Werror=implicit-function-declaration]
rsi_coex_recv_pkt(common, frame_desc + offset);
^
drivers/net/wireless/rsi/rsi_91x_main.c: In function 'rsi_91x_init':
>> drivers/net/wireless/rsi/rsi_91x_main.c:287:7: error: implicit declaration
>> of function 'rsi_coex_attach' [-Werror=implicit-function-declaration]
if (rsi_coex_attach(common)) {
^~~
drivers/net/wireless/rsi/rsi_91x_main.c: In function 'rsi_91x_deinit':
>> drivers/net/wireless/rsi/rsi_91x_main.c:323:3: error: implicit declaration
>> of function 'rsi_coex_detach' [-Werror=implicit-function-declaration]
rsi_coex_detach(common);
^~~
cc1: some warnings being treated as errors
vim +/rsi_coex_recv_pkt +165 drivers/net/wireless/rsi/rsi_91x_main.c
133
134 /**
135 * rsi_read_pkt() - This function reads frames from the card.
136 * @common: Pointer to the driver private structure.
137 * @rcv_pkt_len: Received pkt length. In case of USB it is 0.
138 *
139 * Return: 0 on success, -1 on failure.
140 */
141 int rsi_read_pkt(struct rsi_common *common, u8 *rx_pkt, s32 rcv_pkt_len)
142 {
143 u8 *frame_desc = NULL, extended_desc = 0;
144 u32 index, length = 0, queueno = 0;
145 u16 actual_length = 0, offset;
146 struct sk_buff *skb = NULL;
147
148 index = 0;
149 do {
150 frame_desc = &rx_pkt[index];
151 actual_length = *(u16 *)&frame_desc[0];
152 offset = *(u16 *)&frame_desc[2];
153
154 queueno = rsi_get_queueno(frame_desc, offset);
155 length = rsi_get_length(frame_desc, offset);
156
157 /* Extended descriptor is valid for WLAN queues only */
158 if (queueno == RSI_WIFI_DATA_Q || queueno ==
RSI_WIFI_MGMT_Q)
159 extended_desc =
rsi_get_extended_desc(frame_desc,
160offset);
161
162 switch (queueno) {
163 case RSI_COEX_Q:
164 if (common->coex_mode > 1)
> 165 rsi_coex_recv_pkt(common, frame_desc +
> offset);
166 else
167 rsi_mgmt_pkt_recv(common,
168(frame_desc +
offset));
169 break;
170
171 case RSI_WIFI_DATA_Q:
172 skb = rsi_prepare_skb(common,
173(frame_desc + offset),
174length,
175extended_desc);
176 if (skb == NULL)
177 goto fail;
178
179 rsi_indicate_pkt_to_os(common, skb);
180 break;
181
182 case RSI_WIFI_MGMT_Q:
183 rsi_mgmt_pkt_recv(common, (frame_desc +
offset));
184 break;
185
186 default:
187 rsi_dbg(ERR_ZONE, "%s: pkt from invalid queue:
%d\n",
188 __func__, queueno);
189 goto fail;
190 }
191
192 index += actual_length;
193 rcv_pkt_len -= actual_length;
194 } while (rcv_pkt_len > 0);
195
196 return 0;
197 fail:
198 return -EINVAL;
199 }
200 EXPORT_SYMBOL_GPL(rsi_read_pkt);
201
202 /**
203 * rsi_tx_scheduler_t
Re: [v8 4/8] rsi: add coex support
Hi Prameela,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Amitkumar-Karwar/rsi-add-bluetooth-and-coex-support/20180226-073244
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh
Note: the
linux-review/Amitkumar-Karwar/rsi-add-bluetooth-and-coex-support/20180226-073244
HEAD 9c5222af2b3dbf5143bc1fa4dc0af78fcfa3559d builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/net//wireless/rsi/rsi_91x_main.c: In function 'rsi_read_pkt':
>> drivers/net//wireless/rsi/rsi_91x_main.c:165:5: error: implicit declaration
>> of function 'rsi_coex_recv_pkt'; did you mean 'rsi_read_pkt'?
>> [-Werror=implicit-function-declaration]
rsi_coex_recv_pkt(common, frame_desc + offset);
^
rsi_read_pkt
drivers/net//wireless/rsi/rsi_91x_main.c: In function 'rsi_91x_init':
>> drivers/net//wireless/rsi/rsi_91x_main.c:287:7: error: implicit declaration
>> of function 'rsi_coex_attach'; did you mean 'driver_attach'?
>> [-Werror=implicit-function-declaration]
if (rsi_coex_attach(common)) {
^~~
driver_attach
drivers/net//wireless/rsi/rsi_91x_main.c: In function 'rsi_91x_deinit':
>> drivers/net//wireless/rsi/rsi_91x_main.c:323:3: error: implicit declaration
>> of function 'rsi_coex_detach'; did you mean 'rsi_91x_deinit'?
>> [-Werror=implicit-function-declaration]
rsi_coex_detach(common);
^~~
rsi_91x_deinit
cc1: some warnings being treated as errors
vim +165 drivers/net//wireless/rsi/rsi_91x_main.c
133
134 /**
135 * rsi_read_pkt() - This function reads frames from the card.
136 * @common: Pointer to the driver private structure.
137 * @rcv_pkt_len: Received pkt length. In case of USB it is 0.
138 *
139 * Return: 0 on success, -1 on failure.
140 */
141 int rsi_read_pkt(struct rsi_common *common, u8 *rx_pkt, s32 rcv_pkt_len)
142 {
143 u8 *frame_desc = NULL, extended_desc = 0;
144 u32 index, length = 0, queueno = 0;
145 u16 actual_length = 0, offset;
146 struct sk_buff *skb = NULL;
147
148 index = 0;
149 do {
150 frame_desc = &rx_pkt[index];
151 actual_length = *(u16 *)&frame_desc[0];
152 offset = *(u16 *)&frame_desc[2];
153
154 queueno = rsi_get_queueno(frame_desc, offset);
155 length = rsi_get_length(frame_desc, offset);
156
157 /* Extended descriptor is valid for WLAN queues only */
158 if (queueno == RSI_WIFI_DATA_Q || queueno ==
RSI_WIFI_MGMT_Q)
159 extended_desc =
rsi_get_extended_desc(frame_desc,
160offset);
161
162 switch (queueno) {
163 case RSI_COEX_Q:
164 if (common->coex_mode > 1)
> 165 rsi_coex_recv_pkt(common, frame_desc +
> offset);
166 else
167 rsi_mgmt_pkt_recv(common,
168(frame_desc +
offset));
169 break;
170
171 case RSI_WIFI_DATA_Q:
172 skb = rsi_prepare_skb(common,
173(frame_desc + offset),
174length,
175extended_desc);
176 if (skb == NULL)
177 goto fail;
178
179 rsi_indicate_pkt_to_os(common, skb);
180 break;
181
182 case RSI_WIFI_MGMT_Q:
183 rsi_mgmt_pkt_recv(common, (frame_desc +
offset));
184 break;
185
186 default:
187 rsi_dbg(ERR_ZONE, "%s: pkt from invalid queue:
%d\n",
188 __func__, queueno);
189 goto fail;
190 }
191
192 index += act
Re: [PATCH v11] ath10k: add LED and GPIO controlling support for various chipsets
Hi Sebastian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.16-rc2 next-20180223]
[cannot apply to ath6kl/ath-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/s-gottschall-dd-wrt-com/ath10k-add-LED-and-GPIO-controlling-support-for-various-chipsets/20180226-064849
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh
All warnings (new ones prefixed by >>):
In file included from drivers/net/wireless/ath/ath10k/core.c:29:0:
>> drivers/net/wireless/ath/ath10k/core.h:815:13: warning:
>> 'ath10k_unregister_gpio_chip' used but never defined
static void ath10k_unregister_gpio_chip(struct ath10k *ar);
^~~
vim +/ath10k_unregister_gpio_chip +815 drivers/net/wireless/ath/ath10k/core.h
813
814 #if IS_ENABLED(CONFIG_ATH10K_LEDS) && IS_ENABLED(CONFIG_GPIOLIB)
> 815 static void ath10k_unregister_gpio_chip(struct ath10k *ar);
816 #else
817 static inline int ath10k_attach_gpio(struct ath10k *ar)
818 {
819 return -ENODEV;
820 }
821 #endif
822 #if IS_ENABLED(CONFIG_ATH10K_LEDS)
823 int ath10k_attach_gpio(struct ath10k *ar);
824 #else
825 static inline void ath10k_unregister_gpio_chip(struct ath10k *ar)
826 {
827
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] Revert "mac80211: use QoS NDP for AP probing"
mmh i'm not sure, but i believe i have the same issue with pci chipsets
and ath9k under high load
Sebastian
Am 25.02.2018 um 22:15 schrieb Ben Caradoc-Davies:
This reverts commit 7b6ddeaf27eca72795ceeae2f0f347db1b5f9a30.
The above commit causes an Atheros AR9271 ath9k_htc USB WiFi adapter
connected to an AP with QoS/WME enabled to lose all IP connectivity after
something like 10 to 90 minutes. The adapter remains up and associated
and "iw dev wlan0 station dump" shows byte and packet counters that keep
increasing, but all IP connectivity fails, including ping, DNS, and web.
The host cannot be pinged by other hosts on the WLAN. Network can be
restored by unloading and reloading the ath9k_htc module, or physically
unplugging and replugging the adapter, triggering NetworkManager to
reconnect.
The problematic commit is on torvalds/master and linux-stable/linux-4.15.y.
On linux-stable/linux-4.14.y: e23090a7d8f05f03cf564148472130286f5ca9bf.
Problem confirmed on Debian linux-image-4.14.0-3-amd64 4.14.17-1 and
Debian linux-image-4.15.0-1-amd64 4.15.4-1 and vanilla 4.14.16
(git e23090a7d8f0 from linux-stable/linux-4.14.y) and vanilla 4.16.0-rc2
(git 3664ce2d9309 from torvalds/master).
Fix tested by reverting the commit on vanilla 4.16.0-rc2 (git 3664ce2d9309
from torvalds/master) and applying the patch to Debian
linux-image-4.15.0-1-amd64 4.15.4-1. Both tests resulted in stable IP
connectivity.
See also Debian Bug#891060:
Atheros AR9271 ath9k_htc USB WiFi connected but IP traffic stops
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060
Signed-off-by: Ben Caradoc-Davies
---
drivers/net/wireless/ath/ath9k/channel.c | 2 +-
drivers/net/wireless/st/cw1200/sta.c | 4 ++--
drivers/net/wireless/ti/wl1251/main.c| 2 +-
drivers/net/wireless/ti/wlcore/cmd.c | 5 ++---
include/net/mac80211.h | 8 +---
net/mac80211/mlme.c | 2 +-
net/mac80211/tx.c| 29 ++---
7 files changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index 1b05b5d7a038..dfb26f03c1a2 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1113,7 +1113,7 @@ ath_chanctx_send_vif_ps_frame(struct ath_softc *sc,
struct ath_vif *avp,
if (!avp->assoc)
return false;
- skb = ieee80211_nullfunc_get(sc->hw, vif, false);
+ skb = ieee80211_nullfunc_get(sc->hw, vif);
if (!skb)
return false;
diff --git a/drivers/net/wireless/st/cw1200/sta.c b/drivers/net/wireless/st/cw1200/sta.c
index 38678e9a0562..03687a80d6e9 100644
--- a/drivers/net/wireless/st/cw1200/sta.c
+++ b/drivers/net/wireless/st/cw1200/sta.c
@@ -198,7 +198,7 @@ void __cw1200_cqm_bssloss_sm(struct cw1200_common *priv,
priv->bss_loss_state++;
- skb = ieee80211_nullfunc_get(priv->hw, priv->vif, false);
+ skb = ieee80211_nullfunc_get(priv->hw, priv->vif);
WARN_ON(!skb);
if (skb)
cw1200_tx(priv->hw, NULL, skb);
@@ -2265,7 +2265,7 @@ static int cw1200_upload_null(struct cw1200_common *priv)
.rate = 0xFF,
};
- frame.skb = ieee80211_nullfunc_get(priv->hw, priv->vif, false);
+ frame.skb = ieee80211_nullfunc_get(priv->hw, priv->vif);
if (!frame.skb)
return -ENOMEM;
diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
index 037defd10b91..99a6889a6540 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -566,7 +566,7 @@ static int wl1251_build_null_data(struct wl1251 *wl)
size = sizeof(struct wl12xx_null_data_template);
ptr = NULL;
} else {
- skb = ieee80211_nullfunc_get(wl->hw, wl->vif, false);
+ skb = ieee80211_nullfunc_get(wl->hw, wl->vif);
if (!skb)
goto out;
size = skb->len;
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c
b/drivers/net/wireless/ti/wlcore/cmd.c
index 761cf8573a80..2bfc12fdc929 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -1069,8 +1069,7 @@ int wl12xx_cmd_build_null_data(struct wl1271 *wl, struct
wl12xx_vif *wlvif)
ptr = NULL;
} else {
skb = ieee80211_nullfunc_get(wl->hw,
-wl12xx_wlvif_to_vif(wlvif),
-false);
+wl12xx_wlvif_to_vif(wlvif));
if (!skb)
goto out;
size = skb->len;
@@ -1097,7 +1096,7 @@ int wl12xx_cmd_build_klv_null_data(struct wl1271 *wl,
struct sk_buff *skb = NULL;
int ret = -ENOMEM;
[PATCH] Revert "mac80211: use QoS NDP for AP probing"
This reverts commit 7b6ddeaf27eca72795ceeae2f0f347db1b5f9a30.
The above commit causes an Atheros AR9271 ath9k_htc USB WiFi adapter
connected to an AP with QoS/WME enabled to lose all IP connectivity after
something like 10 to 90 minutes. The adapter remains up and associated
and "iw dev wlan0 station dump" shows byte and packet counters that keep
increasing, but all IP connectivity fails, including ping, DNS, and web.
The host cannot be pinged by other hosts on the WLAN. Network can be
restored by unloading and reloading the ath9k_htc module, or physically
unplugging and replugging the adapter, triggering NetworkManager to
reconnect.
The problematic commit is on torvalds/master and linux-stable/linux-4.15.y.
On linux-stable/linux-4.14.y: e23090a7d8f05f03cf564148472130286f5ca9bf.
Problem confirmed on Debian linux-image-4.14.0-3-amd64 4.14.17-1 and
Debian linux-image-4.15.0-1-amd64 4.15.4-1 and vanilla 4.14.16
(git e23090a7d8f0 from linux-stable/linux-4.14.y) and vanilla 4.16.0-rc2
(git 3664ce2d9309 from torvalds/master).
Fix tested by reverting the commit on vanilla 4.16.0-rc2 (git 3664ce2d9309
from torvalds/master) and applying the patch to Debian
linux-image-4.15.0-1-amd64 4.15.4-1. Both tests resulted in stable IP
connectivity.
See also Debian Bug#891060:
Atheros AR9271 ath9k_htc USB WiFi connected but IP traffic stops
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060
Signed-off-by: Ben Caradoc-Davies
---
drivers/net/wireless/ath/ath9k/channel.c | 2 +-
drivers/net/wireless/st/cw1200/sta.c | 4 ++--
drivers/net/wireless/ti/wl1251/main.c| 2 +-
drivers/net/wireless/ti/wlcore/cmd.c | 5 ++---
include/net/mac80211.h | 8 +---
net/mac80211/mlme.c | 2 +-
net/mac80211/tx.c| 29 ++---
7 files changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index 1b05b5d7a038..dfb26f03c1a2 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1113,7 +1113,7 @@ ath_chanctx_send_vif_ps_frame(struct ath_softc *sc,
struct ath_vif *avp,
if (!avp->assoc)
return false;
- skb = ieee80211_nullfunc_get(sc->hw, vif, false);
+ skb = ieee80211_nullfunc_get(sc->hw, vif);
if (!skb)
return false;
diff --git a/drivers/net/wireless/st/cw1200/sta.c
b/drivers/net/wireless/st/cw1200/sta.c
index 38678e9a0562..03687a80d6e9 100644
--- a/drivers/net/wireless/st/cw1200/sta.c
+++ b/drivers/net/wireless/st/cw1200/sta.c
@@ -198,7 +198,7 @@ void __cw1200_cqm_bssloss_sm(struct cw1200_common *priv,
priv->bss_loss_state++;
- skb = ieee80211_nullfunc_get(priv->hw, priv->vif, false);
+ skb = ieee80211_nullfunc_get(priv->hw, priv->vif);
WARN_ON(!skb);
if (skb)
cw1200_tx(priv->hw, NULL, skb);
@@ -2265,7 +2265,7 @@ static int cw1200_upload_null(struct cw1200_common *priv)
.rate = 0xFF,
};
- frame.skb = ieee80211_nullfunc_get(priv->hw, priv->vif, false);
+ frame.skb = ieee80211_nullfunc_get(priv->hw, priv->vif);
if (!frame.skb)
return -ENOMEM;
diff --git a/drivers/net/wireless/ti/wl1251/main.c
b/drivers/net/wireless/ti/wl1251/main.c
index 037defd10b91..99a6889a6540 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -566,7 +566,7 @@ static int wl1251_build_null_data(struct wl1251 *wl)
size = sizeof(struct wl12xx_null_data_template);
ptr = NULL;
} else {
- skb = ieee80211_nullfunc_get(wl->hw, wl->vif, false);
+ skb = ieee80211_nullfunc_get(wl->hw, wl->vif);
if (!skb)
goto out;
size = skb->len;
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c
b/drivers/net/wireless/ti/wlcore/cmd.c
index 761cf8573a80..2bfc12fdc929 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -1069,8 +1069,7 @@ int wl12xx_cmd_build_null_data(struct wl1271 *wl, struct
wl12xx_vif *wlvif)
ptr = NULL;
} else {
skb = ieee80211_nullfunc_get(wl->hw,
-wl12xx_wlvif_to_vif(wlvif),
-false);
+wl12xx_wlvif_to_vif(wlvif));
if (!skb)
goto out;
size = skb->len;
@@ -1097,7 +1096,7 @@ int wl12xx_cmd_build_klv_null_data(struct wl1271 *wl,
struct sk_buff *skb = NULL;
int ret = -ENOMEM;
- skb = ieee80211_nullfunc_get(wl->hw, vif, false);
+ skb = ieee80211_nullfunc_get(wl->hw, vif);
if (!skb)
Re: [PATCH] mt7601u: Fix system freeze after resuming from hibernation
On Mon, Feb 19, 2018 at 05:01:27PM +0200, cantabile wrote: > On 19/02/18 07:55, Jakub Kicinski wrote: > > On Sat, 17 Feb 2018 13:23:29 +0200, cantabile wrote: > > > > Thanks for the info. Would it be cleaner to EXPORT fw_add_devm_name() > > > > and just call that in case driver sees FW is already loaded? That > > > > should inform the fw subsystem that we want the image around in case of > > > > hibernation, but there is no need to load it immediately? > > > > > > No, I don't believe it's cleaner to expose a private function that you > > > don't even really need. Remember that calling request_firmware every > > > time your driver's probe and resume functions are called is normal. It's > > > the expected behaviour. > > > > I'm asking you the extend functionality of a subsystem to be able to > > cleanly communicate the intent. Not export internal functions. > > > > Requesting firmware you don't need and risking failing probe even if FW > > is already pre-loaded is not correct. Reordering you suggest is > > brittle and makes little logical sense unless someone guesses your use > > case. > > > > Please at least try to do as advised. Otherwise: > > > > Nacked-by: Jakub Kicinski > > > > You're right about the reordering not making sense to someone unfamiliar > with the problem. I can fix that with a comment. > > I can change the patch so that request_firmware will only make the probe > function fail if the firmware is not already running. Note that using request_firmware() on probe typically is also not an outstanding idea given it delays boot. Not because looking for the firmware takes time, but instead because processing firmware typically does on the device. For instance cxgb4 is an example device where processing firmware takes a long time. Delays on probe may mean the "feel good" immediate desktop coming up is delyed. Specially if its networking... I see no reason why to process firmware on probe. If one can use a workqueue to process verifying if it needs firmware and loading later, that's more advisable. Now, that's all a side topic. I will for now agree that it seems pointless to request for firmware always even if you don't need to, and all you want is to just cache the firmware on suspend. So I welcome a patch but the justification for it really needs to be documented very well, and the documentation extended as such. In fact maybe rename the function to something more sensible. Another use case for the firmware cache (which we need to add the documentation) is that for hibernation we suspend all devices first, get a snapshot, and then resume devices so we can then write the snapshot to disk. On that resume step I don't think devices have access to the hard drive for firmware, so cache is all we have. This may need some confirmation but I suspect this is the case. Drivers needing firmware on resume for hibernation may need to cache their firmware. I want to understand the case where the firmware is *not* available on resume? Why did that happen? I seem to have read that on a fresh reboot the firmware was not needed, and so on probe request_firmware() was not called? Why would firmware not be required on a reboot? Luis
Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time
Hi,
On 26-05-17 12:57, Hans de Goede wrote:
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.
Signed-off-by: Hans de Goede
I'm now seeing this on another device too, but this time the error
thrown is -EBADE, this seems to be new with recent kernels:
[root@localhost ~]# dmesg | grep brcmfmac
[ 34.265950] usbcore: registered new interface driver brcmfmac
[ 34.266059] brcmfmac :01:00.0: enabling device ( -> 0002)
[ 34.376468] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x02
[ 34.855143] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac4356-pcie.clm_blob failed with error -2
[ 34.855147] brcmfmac: brcmf_c_process_clm_blob: no clm_blob
available(err=-2), device may have limited channels available
[ 34.857029] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun 4
2017 16:50:07 version 7.35.101.6 (r702795) FWID 01-5e8eb735
[ 34.938854] brcmfmac :01:00.0 wlp1s0: renamed from wlan0
[ 37.086420] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[ 37.086431] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlp1s0
type 10 failed: err=-52
[root@localhost ~]# strings /lib/firmware/brcm/brcmfmac4356-pcie.bin | tail -n 1
4356a2-roml/pcie-ag-msgbuf-splitrx-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wl11u-mfp-tdls-amsdutx-sarctrl-proxd-hs20sta-rcc-wepso-ndoe-linkstat-gscan-hchk-logtrace-roamexp-rmon
Version: 7.35.101.6 (r702795) CRC: 4f3f65c5 Date: Sun 2017-06-04 16:51:38 PDT
Ucode Ver: 963.316 FWID: 01-5e8eb735
It would be good if we can silence these errors, or maybe at a
minimum lower their log-level from error to warning?
Regards,
Hans
---
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 5 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index cd1d6730eab7..dae88f3d041d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -684,11 +684,17 @@ static struct wireless_dev
*brcmf_cfg80211_add_iface(struct wiphy *wiphy,
return ERR_PTR(-EINVAL);
}
- if (IS_ERR(wdev))
- brcmf_err("add iface %s type %d failed: err=%d\n",
- name, type, (int)PTR_ERR(wdev));
- else
+ if (IS_ERR(wdev)) {
+ err = PTR_ERR(wdev);
+ if (err != -EBUSY)
+ brcmf_err("add iface %s type %d failed: err=%d\n",
+ name, type, err);
+ else
+ brcmf_dbg(INFO, "add iface %s type %d failed: err=%d\n",
+ name, type, err);
+ } else {
brcmf_cfg80211_update_proto_addr_mode(wdev);
+ }
return wdev;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index aa299c47bfa2..1bb296ffb46f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2090,7 +2090,10 @@ static struct wireless_dev
*brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
/* Initialize P2P Discovery in the firmware */
err = brcmf_fil_iovar_int_set(pri_ifp, "p2p_disc", 1);
if (err < 0) {
- brcmf_err("set p2p_disc error\n");
+ if (err != -EBUSY)
+ brcmf_err("set p2p_disc error\n");
+ else
+ brcmf_dbg(INFO, "set p2p_disc error\n");
brcmf_fweh_p2pdev_setup(pri_ifp, false);
brcmf_cfg80211_arm_vif_event(p2p->cfg, NULL);
goto fail;
[PATCH] cfg80211: add missing dependency to CFG80211 suboptions
New options introduced by [1] are still enabled even if CFG80211 is disabled. .config: # CONFIG_CFG80211 is not set CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS=y # CONFIG_LIB80211 is not set When CFG80211_REQUIRE_SIGNED_REGDB is enabled, it select SYSTEM_DATA_VERIFICATION which select SYSTEM_TRUSTED_KEYRING that need extract-cert tool. extract-cert needs some openssl headers to be installed on the build machine. Instead of adding missing "depends on CFG80211", it easier to use a 'if' block around all options related to CFG80211. [1] 90a53e4432b12288316efaa5f308adafb8d304b0 Signed-off-by: Romain Naour --- net/wireless/Kconfig | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index 1abcc4fc4df1..41722046b937 100644 --- a/net/wireless/Kconfig +++ b/net/wireless/Kconfig @@ -34,9 +34,10 @@ config CFG80211 When built as a module it will be called cfg80211. +if CFG80211 + config NL80211_TESTMODE bool "nl80211 testmode command" - depends on CFG80211 help The nl80211 testmode command helps implementing things like factory calibration or validation tools for wireless chips. @@ -51,7 +52,6 @@ config NL80211_TESTMODE config CFG80211_DEVELOPER_WARNINGS bool "enable developer warnings" - depends on CFG80211 default n help This option enables some additional warnings that help @@ -68,7 +68,7 @@ config CFG80211_DEVELOPER_WARNINGS config CFG80211_CERTIFICATION_ONUS bool "cfg80211 certification onus" - depends on CFG80211 && EXPERT + depends on EXPERT default n ---help--- You should disable this option unless you are both capable @@ -159,7 +159,6 @@ config CFG80211_REG_RELAX_NO_IR config CFG80211_DEFAULT_PS bool "enable powersave by default" - depends on CFG80211 default y help This option enables powersave mode by default. @@ -170,7 +169,6 @@ config CFG80211_DEFAULT_PS config CFG80211_DEBUGFS bool "cfg80211 DebugFS entries" - depends on CFG80211 depends on DEBUG_FS ---help--- You can enable this if you want debugfs entries for cfg80211. @@ -180,7 +178,6 @@ config CFG80211_DEBUGFS config CFG80211_CRDA_SUPPORT bool "support CRDA" if EXPERT default y - depends on CFG80211 help You should enable this option unless you know for sure you have no need for it, for example when using internal regdb (above) or the @@ -190,7 +187,6 @@ config CFG80211_CRDA_SUPPORT config CFG80211_WEXT bool "cfg80211 wireless extensions compatibility" if !CFG80211_WEXT_EXPORT - depends on CFG80211 select WEXT_CORE default y if CFG80211_WEXT_EXPORT help @@ -199,11 +195,12 @@ config CFG80211_WEXT config CFG80211_WEXT_EXPORT bool - depends on CFG80211 help Drivers should select this option if they require cfg80211's wext compatibility symbols to be exported. +endif # CFG80211 + config LIB80211 tristate default n -- 2.14.3
