* [PATCH V2 0/5] nl802111/brcmfmac: wowlan netdetect fixes
From: Arend van Spriel @ 2017-01-27 12:27 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
This series has a fix for nl80211 regarding validation of wowlan
netdetect. It has been discussed with Johannes to take this through
the wireless-drivers-next repository so here it is.
* fix validation of wowlan netdetect parameters in nl80211.
* fix wowlan netdetect support.
* add new cfg80211 callback.
The series is intended for 4.11 and applies to the master branch of the
wireless-drivers-next repository.
changelog:
V2: fix checkpatch error in patch 4/5.
Arend van Spriel (5):
nl80211: fix validation of scheduled scan info for wowlan netdetect
brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
brcmfmac: fix handling firmware results for wowl netdetect
brcmfmac: allow wowlan support to be per device
brcmfmac: add .update_connect_params() callback
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 52 ++++++++++++++++++----
net/wireless/nl80211.c | 10 +++--
2 files changed, 50 insertions(+), 12 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH V2 3/5] brcmfmac: fix handling firmware results for wowl netdetect
From: Arend van Spriel @ 2017-01-27 12:27 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485520068-5807-1-git-send-email-arend.vanspriel@broadcom.com>
For wowl netdetect the event data changed for newer chips. This
was recently fixed for scheduled scan, but same change is needed
for wowl netdetect. Removing now pointles += operation from both
result handlers.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 302a78d..c81d78f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3330,7 +3330,6 @@ static int brcmf_start_internal_escan(struct brcmf_if *ifp,
goto out_err;
}
- data += sizeof(struct brcmf_pno_scanresults_le);
netinfo_start = brcmf_get_netinfo_array(pfn_result);
for (i = 0; i < result_count; i++) {
@@ -3478,8 +3477,7 @@ static s32 brcmf_config_wowl_pattern(struct brcmf_if *ifp, u8 cmd[4],
return -EINVAL;
}
- data += sizeof(struct brcmf_pno_scanresults_le);
- netinfo = (struct brcmf_pno_net_info_le *)data;
+ netinfo = brcmf_get_netinfo_array(pfn_result);
memcpy(cfg->wowl.nd->ssid.ssid, netinfo->SSID, netinfo->SSID_len);
cfg->wowl.nd->ssid.ssid_len = netinfo->SSID_len;
cfg->wowl.nd->n_channels = 1;
--
1.9.1
^ permalink raw reply related
* [PATCH V2 2/5] brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
From: Arend van Spriel @ 2017-01-27 12:27 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485520068-5807-1-git-send-email-arend.vanspriel@broadcom.com>
The driver advertises support for WOWLAN_NETDETECT but did not specify
maximum amount of netdetect match sets. This was no issue due to a bug
in nl80211. As that has been fixed, brcmfmac also needs fixing.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ec1171c..302a78d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6358,6 +6358,8 @@ static void brcmf_wiphy_wowl_params(struct wiphy *wiphy, struct brcmf_if *ifp)
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO)) {
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_WOWL_ND)) {
brcmf_wowlan_support.flags |= WIPHY_WOWLAN_NET_DETECT;
+ brcmf_wowlan_support.max_nd_match_sets =
+ BRCMF_PNO_MAX_PFN_COUNT;
init_waitqueue_head(&cfg->wowl.nd_data_wait);
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH V2 5/5] brcmfmac: add .update_connect_params() callback
From: Arend van Spriel @ 2017-01-27 12:27 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485520068-5807-1-git-send-email-arend.vanspriel@broadcom.com>
Add support for the .update_connect_params() callback for roaming
or subsequent (re)association.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ab1f9f2..0e28d07 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5067,6 +5067,29 @@ static int brcmf_cfg80211_tdls_oper(struct wiphy *wiphy,
return ret;
}
+static int
+brcmf_cfg80211_update_conn_params(struct wiphy *wiphy,
+ struct net_device *ndev,
+ struct cfg80211_connect_params *sme,
+ u32 changed)
+{
+ struct brcmf_if *ifp;
+ int err;
+
+ if (!(changed & UPDATE_ASSOC_IES))
+ return 0;
+
+ ifp = netdev_priv(ndev);
+ err = brcmf_vif_set_mgmt_ie(ifp->vif, BRCMF_VNDR_IE_ASSOCREQ_FLAG,
+ sme->ie, sme->ie_len);
+ if (err)
+ brcmf_err("Set Assoc REQ IE Failed\n");
+ else
+ brcmf_dbg(TRACE, "Applied Vndr IEs for Assoc request\n");
+
+ return err;
+}
+
#ifdef CONFIG_PM
static int
brcmf_cfg80211_set_rekey_data(struct wiphy *wiphy, struct net_device *ndev,
@@ -5134,6 +5157,7 @@ static int brcmf_cfg80211_tdls_oper(struct wiphy *wiphy,
.crit_proto_start = brcmf_cfg80211_crit_proto_start,
.crit_proto_stop = brcmf_cfg80211_crit_proto_stop,
.tdls_oper = brcmf_cfg80211_tdls_oper,
+ .update_connect_params = brcmf_cfg80211_update_conn_params,
};
struct brcmf_cfg80211_vif *brcmf_alloc_vif(struct brcmf_cfg80211_info *cfg,
--
1.9.1
^ permalink raw reply related
* [PATCH V2 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend van Spriel @ 2017-01-27 12:27 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel, Johannes Berg
In-Reply-To: <1485520068-5807-1-git-send-email-arend.vanspriel@broadcom.com>
For wowlan netdetect a separate limit is defined for the number of
matchsets. Currently, this limit is ignored and the regular limit
for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
used for the net-detect case as well.
Cc: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/nl80211.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef5eff93..90833a4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6850,7 +6850,7 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
static struct cfg80211_sched_scan_request *
nl80211_parse_sched_scan(struct wiphy *wiphy, struct wireless_dev *wdev,
- struct nlattr **attrs)
+ struct nlattr **attrs, int max_match_sets)
{
struct cfg80211_sched_scan_request *request;
struct nlattr *attr;
@@ -6915,7 +6915,7 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
if (!n_match_sets && default_match_rssi != NL80211_SCAN_RSSI_THOLD_OFF)
n_match_sets = 1;
- if (n_match_sets > wiphy->max_match_sets)
+ if (n_match_sets > max_match_sets)
return ERR_PTR(-EINVAL);
if (attrs[NL80211_ATTR_IE])
@@ -7189,7 +7189,8 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
return -EINPROGRESS;
sched_scan_req = nl80211_parse_sched_scan(&rdev->wiphy, wdev,
- info->attrs);
+ info->attrs,
+ rdev->wiphy.max_match_sets);
err = PTR_ERR_OR_ZERO(sched_scan_req);
if (err)
@@ -9966,7 +9967,8 @@ static int nl80211_parse_wowlan_nd(struct cfg80211_registered_device *rdev,
if (err)
goto out;
- trig->nd_config = nl80211_parse_sched_scan(&rdev->wiphy, NULL, tb);
+ trig->nd_config = nl80211_parse_sched_scan(&rdev->wiphy, NULL, tb,
+ wowlan->max_nd_match_sets);
err = PTR_ERR_OR_ZERO(trig->nd_config);
if (err)
trig->nd_config = NULL;
--
1.9.1
^ permalink raw reply related
* [PATCH V2 4/5] brcmfmac: allow wowlan support to be per device
From: Arend van Spriel @ 2017-01-27 12:27 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485520068-5807-1-git-send-email-arend.vanspriel@broadcom.com>
The wowlan support is (partially) determined dynamic by checking the
device/firmware capabilities. So they can differ per device. So it
is not possible to use a static global. Instead use the global as a
template and use kmemdup(). When kmemdup() fails the template is used
unmodified.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
V2: fix checkpatch error, ie. line over 80 characters.
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 26 ++++++++++++++++------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index c81d78f..ab1f9f2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6339,7 +6339,7 @@ static void brcmf_wiphy_pno_params(struct wiphy *wiphy)
}
#ifdef CONFIG_PM
-static struct wiphy_wowlan_support brcmf_wowlan_support = {
+static const struct wiphy_wowlan_support brcmf_wowlan_support = {
.flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT,
.n_patterns = BRCMF_WOWL_MAXPATTERNS,
.pattern_max_len = BRCMF_WOWL_MAXPATTERNSIZE,
@@ -6352,21 +6352,29 @@ static void brcmf_wiphy_wowl_params(struct wiphy *wiphy, struct brcmf_if *ifp)
{
#ifdef CONFIG_PM
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
+ struct wiphy_wowlan_support *wowl;
+
+ wowl = kmemdup(&brcmf_wowlan_support, sizeof(brcmf_wowlan_support),
+ GFP_KERNEL);
+ if (!wowl) {
+ brcmf_err("only support basic wowlan features\n");
+ wiphy->wowlan = &brcmf_wowlan_support;
+ return;
+ }
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO)) {
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_WOWL_ND)) {
- brcmf_wowlan_support.flags |= WIPHY_WOWLAN_NET_DETECT;
- brcmf_wowlan_support.max_nd_match_sets =
- BRCMF_PNO_MAX_PFN_COUNT;
+ wowl->flags |= WIPHY_WOWLAN_NET_DETECT;
+ wowl->max_nd_match_sets = BRCMF_PNO_MAX_PFN_COUNT;
init_waitqueue_head(&cfg->wowl.nd_data_wait);
}
}
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_WOWL_GTK)) {
- brcmf_wowlan_support.flags |= WIPHY_WOWLAN_SUPPORTS_GTK_REKEY;
- brcmf_wowlan_support.flags |= WIPHY_WOWLAN_GTK_REKEY_FAILURE;
+ wowl->flags |= WIPHY_WOWLAN_SUPPORTS_GTK_REKEY;
+ wowl->flags |= WIPHY_WOWLAN_GTK_REKEY_FAILURE;
}
- wiphy->wowlan = &brcmf_wowlan_support;
+ wiphy->wowlan = wowl;
#endif
}
@@ -6747,6 +6755,10 @@ static void brcmf_free_wiphy(struct wiphy *wiphy)
kfree(wiphy->bands[NL80211_BAND_5GHZ]->channels);
kfree(wiphy->bands[NL80211_BAND_5GHZ]);
}
+#if IS_ENABLED(CONFIG_PM)
+ if (wiphy->wowlan != &brcmf_wowlan_support)
+ kfree(wiphy->wowlan);
+#endif
wiphy_free(wiphy);
}
--
1.9.1
^ permalink raw reply related
* Re: Searching new home for ath[59]k-devel mailing lists
From: Valo, Kalle @ 2017-01-27 12:37 UTC (permalink / raw)
To: Michael Renzmann; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <877f5g7lwd.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> (dropping ath5k-devel and ath9k-devel, I assume they are closed now)
>
> "Michael Renzmann" <mrenzmann@madwifi-project.org> writes:
>
>> Kalle Valo wrote:
>>> So feel free to close both of the lists and thanks for the heads up.
>>
>> Ok. I will send a shutdown notice to both lists during the next few days=
,
>> then unsubscribe all subscribers, and close the lists for new
>> subscriptions. I intend to keep the mailing list archives online, for
>> reference purpose.
>>
>>> Are you planning to update the MAINTAINERS file or should I?
>>
>> It would be great if you could take care of that.
>
> Ok, I'll send a patch.
MAINTAINERS: ath9k-devel is closed
https://patchwork.kernel.org/patch/9541737/
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] rt2x00: avoid introducing a USB dependency in the rt2x00lib module
From: Stanislaw Gruszka @ 2017-01-27 12:10 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo, vishalthanki
In-Reply-To: <20170127083426.22655-1-nbd@nbd.name>
Hi
On Fri, Jan 27, 2017 at 09:34:26AM +0100, Felix Fietkau wrote:
> Though protected by an ifdef, introducing an usb symbol dependency in
> the rt2x00lib module is a major inconvenience for distributions that
> package kernel modules split into individual packages.
>
> Get rid of this unnecessary dependency by calling the usb related
> function from a more suitable place
<snip>
> rt2x00lib_remove_dev(rt2x00dev);
> + usb_kill_anchored_urbs(anchor);
At this point killing urb's is too late, because we already free
structures that are used by urb->callback.
Below patch should solve the problem and not break shutdown sequence:
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index eb7b714..9235e03 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -1441,21 +1441,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
cancel_work_sync(&rt2x00dev->intf_work);
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
cancel_work_sync(&rt2x00dev->sleep_work);
-#if IS_ENABLED(CONFIG_RT2X00_LIB_USB)
- if (rt2x00_is_usb(rt2x00dev)) {
- usb_kill_anchored_urbs(rt2x00dev->anchor);
- hrtimer_cancel(&rt2x00dev->txstatus_timer);
- cancel_work_sync(&rt2x00dev->rxdone_work);
- cancel_work_sync(&rt2x00dev->txdone_work);
- }
-#endif
- if (rt2x00dev->workqueue)
- destroy_workqueue(rt2x00dev->workqueue);
-
- /*
- * Free the tx status fifo.
- */
- kfifo_free(&rt2x00dev->txstatus_fifo);
/*
* Kill the tx status tasklet.
@@ -1471,6 +1456,14 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
*/
rt2x00lib_uninitialize(rt2x00dev);
+ if (rt2x00dev->workqueue)
+ destroy_workqueue(rt2x00dev->workqueue);
+
+ /*
+ * Free the tx status fifo.
+ */
+ kfifo_free(&rt2x00dev->txstatus_fifo);
+
/*
* Free extra components
*/
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 6005e14..a0a866e 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -744,6 +744,11 @@ void rt2x00usb_uninitialize(struct rt2x00_dev *rt2x00dev)
{
struct data_queue *queue;
+ usb_kill_anchored_urbs(rt2x00dev->anchor);
+ hrtimer_cancel(&rt2x00dev->txstatus_timer);
+ cancel_work_sync(&rt2x00dev->rxdone_work);
+ cancel_work_sync(&rt2x00dev->txdone_work);
+
queue_for_each(rt2x00dev, queue)
rt2x00usb_free_entries(queue);
}
^ permalink raw reply related
* Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend Van Spriel @ 2017-01-27 12:38 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1485520288.5851.8.camel@sipsolutions.net>
On 27-1-2017 13:31, Johannes Berg wrote:
> On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
>> used for the net-detect case as well.
>>
>
> But .. this patch shouldn't be first in the series, should it? That
> leaves brcmfmac broken inbetween.
>
> Also, since you fix the brcmfmac value in patch 2, and it's the same in
> both cases, I don't really see a dependency of anything *on* the
> nl80211 patch? The brcmfmac changes can go in without it entirely, and
> have no effect whatsoever, no?
Patch 4 depends on patch 2. Patch 1 and 2 were a single patch, but I
decided to separate them. So yeah, now patch 1 actually depends on patch
2 in order not to break brcmfmac.
> IOW, I think Kalle can merge 2-5, and I can then pick up this one when
> they hit net-next and I've synchronized, no?
Agree.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] rt2x00: avoid introducing a USB dependency in the rt2x00lib module
From: Felix Fietkau @ 2017-01-27 12:23 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, vishalthanki
In-Reply-To: <20170127120959.GA28776@redhat.com>
On 2017-01-27 13:10, Stanislaw Gruszka wrote:
> Hi
>
> On Fri, Jan 27, 2017 at 09:34:26AM +0100, Felix Fietkau wrote:
>> Though protected by an ifdef, introducing an usb symbol dependency in
>> the rt2x00lib module is a major inconvenience for distributions that
>> package kernel modules split into individual packages.
>>
>> Get rid of this unnecessary dependency by calling the usb related
>> function from a more suitable place
> <snip>
>> rt2x00lib_remove_dev(rt2x00dev);
>> + usb_kill_anchored_urbs(anchor);
>
> At this point killing urb's is too late, because we already free
> structures that are used by urb->callback.
>
> Below patch should solve the problem and not break shutdown sequence:
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
> index eb7b714..9235e03 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
> @@ -1441,21 +1441,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
> cancel_work_sync(&rt2x00dev->intf_work);
> cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
> cancel_work_sync(&rt2x00dev->sleep_work);
> -#if IS_ENABLED(CONFIG_RT2X00_LIB_USB)
> - if (rt2x00_is_usb(rt2x00dev)) {
> - usb_kill_anchored_urbs(rt2x00dev->anchor);
> - hrtimer_cancel(&rt2x00dev->txstatus_timer);
> - cancel_work_sync(&rt2x00dev->rxdone_work);
> - cancel_work_sync(&rt2x00dev->txdone_work);
> - }
> -#endif
> - if (rt2x00dev->workqueue)
> - destroy_workqueue(rt2x00dev->workqueue);
> -
> - /*
> - * Free the tx status fifo.
> - */
> - kfifo_free(&rt2x00dev->txstatus_fifo);
>
> /*
> * Kill the tx status tasklet.
> @@ -1471,6 +1456,14 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
> */
> rt2x00lib_uninitialize(rt2x00dev);
>
> + if (rt2x00dev->workqueue)
> + destroy_workqueue(rt2x00dev->workqueue);
> +
> + /*
> + * Free the tx status fifo.
> + */
> + kfifo_free(&rt2x00dev->txstatus_fifo);
> +
> /*
> * Free extra components
> */
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> index 6005e14..a0a866e 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> @@ -744,6 +744,11 @@ void rt2x00usb_uninitialize(struct rt2x00_dev *rt2x00dev)
> {
> struct data_queue *queue;
>
> + usb_kill_anchored_urbs(rt2x00dev->anchor);
> + hrtimer_cancel(&rt2x00dev->txstatus_timer);
> + cancel_work_sync(&rt2x00dev->rxdone_work);
> + cancel_work_sync(&rt2x00dev->txdone_work);
> +
Looks good to me, please submit that.
- Felix
^ permalink raw reply
* Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Johannes Berg @ 2017-01-27 12:42 UTC (permalink / raw)
To: Arend Van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <abafc8a5-1138-7c4f-66a3-d606700440cb@broadcom.com>
On Fri, 2017-01-27 at 13:38 +0100, Arend Van Spriel wrote:
>
> > IOW, I think Kalle can merge 2-5, and I can then pick up this one
> > when they hit net-next and I've synchronized, no?
>
> Agree.
Alright. I see you submitted another version, I'll assign 2-5 to Kalle,
and keep 1 for myself, and not worry about the ordering since I'm the
one to have to remember to actually apply it later :)
johannes
^ permalink raw reply
* Re: [PATCH V2 2/5] brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
From: Johannes Berg @ 2017-01-27 12:43 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1485520068-5807-3-git-send-email-arend.vanspriel@broadcom.com>
And to make it show up in patchwork at the right place:
Kalle, you can ignore patch 1, I'm handling it, but you need to apply
these before I can, the patch series order was wrong.
johannes
^ permalink raw reply
* Re: [PATCH 4/5] brcmfmac: allow wowlan support to be per device
From: Arend Van Spriel @ 2017-01-27 12:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1485518971-28183-5-git-send-email-arend.vanspriel@broadcom.com>
On 27-1-2017 13:09, Arend van Spriel wrote:
> The wowlan support is (partially) determined dynamic by checking the
> device/firmware capabilities. So they can differ per device. So it
> is not possible to use a static global. Instead use the global as a
> template and use kmemdup(). When kmemdup() fails the template is used
> unmodified.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> ---
> .../broadcom/brcm80211/brcmfmac/cfg80211.c | 26 ++++++++++++++++------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index c81d78f..9d5a561 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6339,7 +6339,7 @@ static void brcmf_wiphy_pno_params(struct wiphy *wiphy)
> }
>
> #ifdef CONFIG_PM
> -static struct wiphy_wowlan_support brcmf_wowlan_support = {
> +static const struct wiphy_wowlan_support brcmf_wowlan_support = {
> .flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT,
> .n_patterns = BRCMF_WOWL_MAXPATTERNS,
> .pattern_max_len = BRCMF_WOWL_MAXPATTERNSIZE,
> @@ -6352,21 +6352,29 @@ static void brcmf_wiphy_wowl_params(struct wiphy *wiphy, struct brcmf_if *ifp)
> {
> #ifdef CONFIG_PM
> struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
> + struct wiphy_wowlan_support *wowlan_support;
> +
> + wowlan_support = kmemdup(&brcmf_wowlan_support,
> + sizeof(brcmf_wowlan_support), GFP_KERNEL);
> + if (!wowlan_support) {
> + brcmf_err("only support basic wowlan features\n");
> + wiphy->wowlan = &brcmf_wowlan_support;
> + return;
> + }
>
> if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO)) {
> if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_WOWL_ND)) {
> - brcmf_wowlan_support.flags |= WIPHY_WOWLAN_NET_DETECT;
> - brcmf_wowlan_support.max_nd_match_sets =
> - BRCMF_PNO_MAX_PFN_COUNT;
> + wowlan_support->flags |= WIPHY_WOWLAN_NET_DETECT;
> + wowlan_support->max_nd_match_sets = BRCMF_PNO_MAX_PFN_COUNT;
Did not checkpatch these before sending. This is over 80 chars so please
drop this series and I will send a V2.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Johannes Berg @ 2017-01-27 12:31 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1485518971-28183-2-git-send-email-arend.vanspriel@broadcom.com>
On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as well.
>
But .. this patch shouldn't be first in the series, should it? That
leaves brcmfmac broken inbetween.
Also, since you fix the brcmfmac value in patch 2, and it's the same in
both cases, I don't really see a dependency of anything *on* the
nl80211 patch? The brcmfmac changes can go in without it entirely, and
have no effect whatsoever, no?
IOW, I think Kalle can merge 2-5, and I can then pick up this one when
they hit net-next and I've synchronized, no?
johannes
^ permalink raw reply
* Re: [PATCH V2 2/5] brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
From: Kalle Valo @ 2017-01-27 12:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: Arend van Spriel, linux-wireless
In-Reply-To: <1485521038.5851.10.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> And to make it show up in patchwork at the right place:
>
> Kalle, you can ignore patch 1, I'm handling it, but you need to apply
> these before I can, the patch series order was wrong.
Haha :) Thank you, this is the best way to remind me about something.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-01-27 12:53 UTC (permalink / raw)
To: Kalle Valo, Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <8737g47kpd.fsf@kamboji.qca.qualcomm.com>
On 27-1-2017 13:26, Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
>> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>>> Pali Rohár <pali.rohar@gmail.com> writes:
>>>
>>>>> So
>>>>> for those other platforms there will be a delay waiting for user-mode
>>>>> helper to fail, before trying to get nvs file from /lib/firmware.
>>>>
>>>> Yes, there will be. But there is no easy way to fix this problem that
>>>> kernel is trying to use default/example NVS data...
>>>
>>> Kernel is doing correctly and requesting NVS data as expected, the
>>> problem here is that linux-firmware claims that the example NVS data is
>>> real calibration data (which it is not). Distros should not use that,
>>> only developers for testing purposes. We should not courage users using
>>> example calibration data.
>>>
>>> The simple fix is to rename the NVS file in linux-firmware to something
>>> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
>>> you send a patch to linux-firmware I'm happy to ack that.
>>
>> I agree with rename and fact that default/example data should not be
>> used.
>>
>> But...
>>
>> 1) Kernel should not read device/model specific data from VFS where
>> are stored not-device-specific files preinstalled by linux
>> distributions.
>>
>> And linux distributions are already putting files into VFS and kernel
>> cannot enforce userspace to not do that (as they are already doing it).
>
> I'm having problems to understand what you are saying here.
This is a personal opinion. I read it as: /lib/firmware can only contain
files for from linux-firmware.
At least the device-specific vs. non-device-specific does not seem to
hold. The firmware files that we have in the linux-firmware repository
are very device-specific. Unless you mean the 'platform' when talking
about 'device'.
Regards,
Arend
^ permalink raw reply
* Re: iwlegacy kernel module with SLES 12 SP1
From: Stanislaw Gruszka @ 2017-01-27 12:53 UTC (permalink / raw)
To: Hassell, William; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <DF4PR84MB007667FC0FD957BA7226C7EAF1770@DF4PR84MB0076.NAMPRD84.PROD.OUTLOOK.COM>
On Thu, Jan 26, 2017 at 10:49:05PM +0000, Hassell, William wrote:
> Hoping you can help.
> I installed SUSE SLES 12 SP1 on a Sony Vaio laptop.
> To my surprise, everything is working with the exception of the wireless device.
> It is an Intel WIFI 4965 AGN device and it works fine with Windows 7 OS.
>
> I have checked that the proper firmware is in /lib/firmware and dmesg shows
> the device is discovered at boot time but no kernel module is loaded.
>
> I see that there is a module iwlwifi in this distro but no iwlegacy.
> Do I need this? If so, how do I go about getting this wireless device to work?
You need iwl4965 and iwlegacy modules. IWL 4965 is pretty old device,
hence distribution might not compile/provide those modules.
Stanislaw
^ permalink raw reply
* Re: [PATCH 4/4] ath9k: fix race condition in enabling/disabling IRQs
From: Felix Fietkau @ 2017-01-27 12:47 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20170125163654.66431-4-nbd@nbd.name>
On 2017-01-25 17:36, Felix Fietkau wrote:
> The code currently relies on refcounting to disable IRQs from within the
> IRQ handler and re-enabling them again after the tasklet has run.
>
> However, due to race conditions sometimes the IRQ handler might be
> called twice, or the tasklet may not run at all (if interrupted in the
> middle of a reset).
>
> This can cause nasty imbalances in the irq-disable refcount which will
> get the driver permanently stuck until the entire radio has been stopped
> and started again (ath_reset will not recover from this).
>
> Instead of using this fragile logic, change the code to ensure that
> running the irq handler during tasklet processing is safe, and leave the
> refcount untouched.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Please don't apply this yet, it looks like it might cause some
regressions on other devices. I will investigate.
- Felix
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 13:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <8737g47kpd.fsf@kamboji.qca.qualcomm.com>
On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >> Pali Rohár <pali.rohar@gmail.com> writes:
> >>
> >> >> So
> >> >> for those other platforms there will be a delay waiting for user-mode
> >> >> helper to fail, before trying to get nvs file from /lib/firmware.
> >> >
> >> > Yes, there will be. But there is no easy way to fix this problem that
> >> > kernel is trying to use default/example NVS data...
> >>
> >> Kernel is doing correctly and requesting NVS data as expected, the
> >> problem here is that linux-firmware claims that the example NVS data is
> >> real calibration data (which it is not). Distros should not use that,
> >> only developers for testing purposes. We should not courage users using
> >> example calibration data.
> >>
> >> The simple fix is to rename the NVS file in linux-firmware to something
> >> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
> >> you send a patch to linux-firmware I'm happy to ack that.
> >
> > I agree with rename and fact that default/example data should not be
> > used.
> >
> > But...
> >
> > 1) Kernel should not read device/model specific data from VFS where
> > are stored not-device-specific files preinstalled by linux
> > distributions.
> >
> > And linux distributions are already putting files into VFS and kernel
> > cannot enforce userspace to not do that (as they are already doing it).
>
> I'm having problems to understand what you are saying here.
I'm saying that linux distributions are putting files to /lib/firmware
which comes from some sources already released. You cannot force linux
distributions to stop putting particular file to /lib/firmware *now*
after it was already released and recommended.
> > 2) It was already tested that example NVS data can be used for N900 e.g.
> > for SSH connection. If real correct data are not available it is better
> > to use at least those example (and probably log warning message) so user
> > can connect via SSH and start investigating where is problem.
>
> I disagree. Allowing default calibration data to be used can be
> unnoticed by user and left her wondering why wifi works so badly.
So there are only two options:
1) Disallow it and so these users will have non-working wifi.
2) Allow those data to be used as fallback mechanism.
And personally I'm against 1) because it will break wifi support for
*all* Nokia N900 devices right now.
> > 3) If we do rename *now* we will totally break wifi support on Nokia
> > N900.
>
> Then the distro should fix that when updating the linux-firmware
> packages. Can you provide details about the setup, what distro etc?
Debian stable, Ubuntu LTSs 14.04, 16.04. And I think that other
LTS distributions contains that example nvs file too (I'm not going to
verify others, but list will be probably long). Upgrading linux-firmware
is against policy of those distributions. So no this is not an solution.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 13:16 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <bc26f6a5-2865-356f-7f19-f3a316257759@broadcom.com>
On Friday 27 January 2017 13:53:28 Arend Van Spriel wrote:
> On 27-1-2017 13:26, Kalle Valo wrote:
> > Pali Rohár <pali.rohar@gmail.com> writes:
> >
> >> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >>> Pali Rohár <pali.rohar@gmail.com> writes:
> >>>
> >>>>> So
> >>>>> for those other platforms there will be a delay waiting for user-mode
> >>>>> helper to fail, before trying to get nvs file from /lib/firmware.
> >>>>
> >>>> Yes, there will be. But there is no easy way to fix this problem that
> >>>> kernel is trying to use default/example NVS data...
> >>>
> >>> Kernel is doing correctly and requesting NVS data as expected, the
> >>> problem here is that linux-firmware claims that the example NVS data is
> >>> real calibration data (which it is not). Distros should not use that,
> >>> only developers for testing purposes. We should not courage users using
> >>> example calibration data.
> >>>
> >>> The simple fix is to rename the NVS file in linux-firmware to something
> >>> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
> >>> you send a patch to linux-firmware I'm happy to ack that.
> >>
> >> I agree with rename and fact that default/example data should not be
> >> used.
> >>
> >> But...
> >>
> >> 1) Kernel should not read device/model specific data from VFS where
> >> are stored not-device-specific files preinstalled by linux
> >> distributions.
> >>
> >> And linux distributions are already putting files into VFS and kernel
> >> cannot enforce userspace to not do that (as they are already doing it).
> >
> > I'm having problems to understand what you are saying here.
>
> This is a personal opinion. I read it as: /lib/firmware can only contain
> files for from linux-firmware.
>
> At least the device-specific vs. non-device-specific does not seem to
> hold. The firmware files that we have in the linux-firmware repository
> are very device-specific. Unless you mean the 'platform' when talking
> about 'device'.
Here I'm talking about files which are specific per unit. Every one N900
has different NVS file (stored in CAL) and so every one N900 device
needs its own NVS file. And we cannot store thousands of NVS files into
linux-firmware repository for each N900 which was ever produced in
factory.
Firmware files in linux-firmware repository are "device" specific, but
"filename" of that file describe exactly for which "device" it is
specific.
But there are thousands of different NVS files for one filename
"wl1251-nvs.bin" and we cannot use one particular for another device. In
linux-firmware is stored "wl1251-nvs.bin" file with example data.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH] ath10k: fix boot failure in UTF mode/testmode
From: c_traja @ 2017-01-27 13:51 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Tamizh chelvam
From: Tamizh chelvam <c_traja@qti.qualcomm.com>
Rx filter reset and the dynamic tx switch mode (EXT_RESOURCE_CFG)
configuration are causing the following errors when UTF firmware
is loaded to the target.
Error message 1:
[ 598.015629] ath10k_pci 0001:01:00.0: failed to ping firmware: -110
[ 598.020828] ath10k_pci 0001:01:00.0: failed to reset rx filter: -110
[ 598.141556] ath10k_pci 0001:01:00.0: failed to start core (testmode): -110
Error message 2:
[ 668.615839] ath10k_ahb a000000.wifi: failed to send ext resource cfg command : -95
[ 668.618902] ath10k_ahb a000000.wifi: failed to start core (testmode): -95
Avoiding these configurations while bringing the target in
testmode is solving the problem.
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 874c2a7..0d12761 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1922,7 +1922,8 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
ath10k_dbg(ar, ATH10K_DBG_BOOT, "firmware %s booted\n",
ar->hw->wiphy->fw_version);
- if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map)) {
+ if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map) &&
+ mode == ATH10K_FIRMWARE_MODE_NORMAL) {
val = 0;
if (ath10k_peer_stats_enabled(ar))
val = WMI_10_4_PEER_STATS;
@@ -1975,10 +1976,13 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
* possible to implicitly make it correct by creating a dummy vdev and
* then deleting it.
*/
- status = ath10k_core_reset_rx_filter(ar);
- if (status) {
- ath10k_err(ar, "failed to reset rx filter: %d\n", status);
- goto err_hif_stop;
+ if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
+ status = ath10k_core_reset_rx_filter(ar);
+ if (status) {
+ ath10k_err(ar,
+ "failed to reset rx filter: %d\n", status);
+ goto err_hif_stop;
+ }
}
/* If firmware indicates Full Rx Reorder support it must be used in a
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] rt2x00: avoid introducing a USB dependency in the rt2x00lib module
From: Stanislaw Gruszka @ 2017-01-27 14:14 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, vishalthanki, nbd
As reported by Felix:
Though protected by an ifdef, introducing an usb symbol dependency in
the rt2x00lib module is a major inconvenience for distributions that
package kernel modules split into individual packages.
Get rid of this unnecessary dependency by calling the usb related
function from a more suitable place.
Reported-by: Felix Fietkau <nbd@nbd.name>
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 23 ++++++++---------------
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 5 +++++
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index e464bdc..c0a66af 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -1417,21 +1417,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
cancel_work_sync(&rt2x00dev->intf_work);
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
cancel_work_sync(&rt2x00dev->sleep_work);
-#ifdef CONFIG_RT2X00_LIB_USB
- if (rt2x00_is_usb(rt2x00dev)) {
- usb_kill_anchored_urbs(rt2x00dev->anchor);
- hrtimer_cancel(&rt2x00dev->txstatus_timer);
- cancel_work_sync(&rt2x00dev->rxdone_work);
- cancel_work_sync(&rt2x00dev->txdone_work);
- }
-#endif
- if (rt2x00dev->workqueue)
- destroy_workqueue(rt2x00dev->workqueue);
-
- /*
- * Free the tx status fifo.
- */
- kfifo_free(&rt2x00dev->txstatus_fifo);
/*
* Kill the tx status tasklet.
@@ -1447,6 +1432,14 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
*/
rt2x00lib_uninitialize(rt2x00dev);
+ if (rt2x00dev->workqueue)
+ destroy_workqueue(rt2x00dev->workqueue);
+
+ /*
+ * Free the tx status fifo.
+ */
+ kfifo_free(&rt2x00dev->txstatus_fifo);
+
/*
* Free extra components
*/
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 838ca58..5a2bf9f 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -744,6 +744,11 @@ void rt2x00usb_uninitialize(struct rt2x00_dev *rt2x00dev)
{
struct data_queue *queue;
+ usb_kill_anchored_urbs(rt2x00dev->anchor);
+ hrtimer_cancel(&rt2x00dev->txstatus_timer);
+ cancel_work_sync(&rt2x00dev->rxdone_work);
+ cancel_work_sync(&rt2x00dev->txdone_work);
+
queue_for_each(rt2x00dev, queue)
rt2x00usb_free_entries(queue);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 15:23 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127131146.GI24223@pali>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
>> Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>>=20
>> > 2) It was already tested that example NVS data can be used for N900 e.=
g.
>> > for SSH connection. If real correct data are not available it is better
>> > to use at least those example (and probably log warning message) so us=
er
>> > can connect via SSH and start investigating where is problem.
>>=20
>> I disagree. Allowing default calibration data to be used can be
>> unnoticed by user and left her wondering why wifi works so badly.
>
> So there are only two options:
>
> 1) Disallow it and so these users will have non-working wifi.
>
> 2) Allow those data to be used as fallback mechanism.
>
> And personally I'm against 1) because it will break wifi support for
> *all* Nokia N900 devices right now.
All two of them? :)
But not working is exactly my point, if correct calibration data is not
available wifi should not work. And it's not only about functionality
problems, there's also the regulatory aspect.
>> > 3) If we do rename *now* we will totally break wifi support on Nokia
>> > N900.
>>=20
>> Then the distro should fix that when updating the linux-firmware
>> packages. Can you provide details about the setup, what distro etc?
>
> Debian stable, Ubuntu LTSs 14.04, 16.04.=20
You can run these out of box on N900?
> And I think that other LTS distributions contains that example nvs
> file too (I'm not going to verify others, but list will be probably
> long). Upgrading linux-firmware is against policy of those
> distributions. So no this is not an solution.
So instead we should workaround distro policies in kernel? Come on.
Seriously, just rename the file in linux-firmware and file a bug (with a
patch) to distros. If they don't fix the bug you just have to do a
custom hack for N900. But such is life.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 15:41 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <87bmus5xyc.fsf@kamboji.qca.qualcomm.com>
On Friday 27 January 2017 17:23:07 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> >> Pali Rohár <pali.rohar@gmail.com> writes:
> >>
> >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> >> > for SSH connection. If real correct data are not available it is better
> >> > to use at least those example (and probably log warning message) so user
> >> > can connect via SSH and start investigating where is problem.
> >>
> >> I disagree. Allowing default calibration data to be used can be
> >> unnoticed by user and left her wondering why wifi works so badly.
> >
> > So there are only two options:
> >
> > 1) Disallow it and so these users will have non-working wifi.
> >
> > 2) Allow those data to be used as fallback mechanism.
> >
> > And personally I'm against 1) because it will break wifi support for
> > *all* Nokia N900 devices right now.
>
> All two of them? :)
Ehm...
> But not working is exactly my point, if correct calibration data is not
> available wifi should not work. And it's not only about functionality
> problems, there's also the regulatory aspect.
About functionality, Pavel confirmed too that SSH is somehow working...
Regulatory aspect is different, but via iw can be manually configured
some settings.
> >> > 3) If we do rename *now* we will totally break wifi support on Nokia
> >> > N900.
> >>
> >> Then the distro should fix that when updating the linux-firmware
> >> packages. Can you provide details about the setup, what distro etc?
> >
> > Debian stable, Ubuntu LTSs 14.04, 16.04.
>
> You can run these out of box on N900?
Out-of-box I can run Kubuntu 12.04 (which is LTS too). They had prepared
special image for N900 and I still have it on uSD card.
I guess that new versions of Ubuntu could somehow work (maybe not
out-of-box but with some changes) and Pavel has working Debian.
Also basic support needed for wifi and SSH server is probably working
with any distribution targeting armv7-a or omap3. So yes, I can say it
is out-of-box. We will not have GSM calls or camera support, but wifi
breakage is there.
> > And I think that other LTS distributions contains that example nvs
> > file too (I'm not going to verify others, but list will be probably
> > long). Upgrading linux-firmware is against policy of those
> > distributions. So no this is not an solution.
>
> So instead we should workaround distro policies in kernel? Come on.
>
> Seriously, just rename the file in linux-firmware and file a bug (with a
> patch) to distros. If they don't fix the bug you just have to do a
> custom hack for N900. But such is life.
I do not see point what will be changed. I rename that file and after
system update (or integrity check) it will be there again.
And if I do that, what prevents kernel to stop using NVS file from
/lib/firmware/? Nothing, original problem (which is going solved by this
patch series) still remains.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [v2,02/13] wil6210: add disable_ap_sme module parameter
From: Kalle Valo @ 2017-01-27 17:50 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Dedy Lansky, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1484226365-10433-3-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> From: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
>
> By default, AP SME is handled by driver/FW.
> In case disable_ap_sme is true, driver doesn't turn-on
> WIPHY_FLAG_HAVE_AP_SME and the responsibility for
> AP SME is passed to user space.
>
> With AP SME disabled, driver reports assoc request frame
> to user space which is then responsible for sending assoc
> response frame and for sending NL80211_CMD_NEW_STATION.
> Driver also reports disassoc frame to user space
> which should then send NL80211_CMD_DEL_STATION.
>
> NL80211_CMD_SET_STATION with NL80211_STA_FLAG_AUTHORIZED
> is used by user space to allow/disallow data transmit.
>
> Signed-off-by: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
11 patches applied to ath-next branch of ath.git, thanks.
849a564b7e28 wil6210: add disable_ap_sme module parameter
a351f2f537b7 wil6210: support loading dedicated image for sparrow-plus devices
af3db60a3033 wil6210: remove __func__ from debug printouts
0d2370e939ac wil6210: support new WMI-only FW capability
4d4c4dc324b4 wil6210: missing reinit_completion in wmi_call
3ee908dc3b48 wil6210: protect against false interrupt during reset sequence
a895cb8b990c wil6210: fix for broadcast workaround in PBSS
a52fb913aee9 wil6210: align to latest auto generated wmi.h
9d865ee232ec wil6210: report association ID (AID) per station in debugfs
c3bfea05a6fd wil6210: option to override A-BFT length in start AP/PCP
78484c44e4b3 wil6210: convert symbolic permissions to octal permissions
--
https://patchwork.kernel.org/patch/9513175/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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