* [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 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
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 12:26 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: <20170127115706.GH24223@pali>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>> Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>>=20
>> >> 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...
>>=20
>> 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.
>>=20
>> 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.
> 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.
> 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?
--=20
Kalle Valo
^ permalink raw reply
* [PATCH 2/5] brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
From: Arend van Spriel @ 2017-01-27 12:09 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485518971-28183-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 0/5] nl802111/brcmfmac: wowlan netdetect fixes
From: Arend van Spriel @ 2017-01-27 12:09 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.
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 4/5] brcmfmac: allow wowlan support to be per device
From: Arend van Spriel @ 2017-01-27 12:09 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485518971-28183-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>
---
.../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;
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;
+ wowlan_support->flags |= WIPHY_WOWLAN_SUPPORTS_GTK_REKEY;
+ wowlan_support->flags |= WIPHY_WOWLAN_GTK_REKEY_FAILURE;
}
- wiphy->wowlan = &brcmf_wowlan_support;
+ wiphy->wowlan = wowlan_support;
#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
* [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend van Spriel @ 2017-01-27 12:09 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel, Johannes Berg
In-Reply-To: <1485518971-28183-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 3/5] brcmfmac: fix handling firmware results for wowl netdetect
From: Arend van Spriel @ 2017-01-27 12:09 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485518971-28183-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 5/5] brcmfmac: add .update_connect_params() callback
From: Arend van Spriel @ 2017-01-27 12:09 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485518971-28183-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 9d5a561..6741477 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] MAINTAINERS: ath9k-devel is closed
From: Kalle Valo @ 2017-01-27 12:19 UTC (permalink / raw)
To: linux-wireless
ath9k-devel list is now closed, only linux-wireless should be used.
Reported-by: Michael Renzmann <mrenzmann@madwifi-project.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9e3d94..d7699d5b5863 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10169,7 +10169,6 @@ F: drivers/media/tuners/qt1010*
QUALCOMM ATHEROS ATH9K WIRELESS DRIVER
M: QCA ath9k Development <ath9k-devel@qca.qualcomm.com>
L: linux-wireless@vger.kernel.org
-L: ath9k-devel@lists.ath9k.org
W: http://wireless.kernel.org/en/users/Drivers/ath9k
S: Supported
F: drivers/net/wireless/ath/ath9k/
--
2.7.4
^ permalink raw reply related
* Re: Searching new home for ath[59]k-devel mailing lists
From: Kalle Valo @ 2017-01-27 12:00 UTC (permalink / raw)
To: Michael Renzmann; +Cc: linux-wireless
In-Reply-To: <49460.217.24.3.26.1484376490.squirrel@webmail.madwifi-project.org>
(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.
> Someone should also update the "Mailing list" section of [1] accordingly.
> I guess one needs to have a valid user account for that to do, and I don't
> have one atm.
>
> [1] https://wireless.wiki.kernel.org/en/users/Drivers/ath9k
I updated that now.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pavel Machek @ 2017-01-27 12:03 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Kalle Valo, Ming Lei, Luis R. Rodriguez,
Greg Kroah-Hartman, David Gnedt, Michal Kazior, Daniel Wagner,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127101043.GD24223@pali>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
Hi!
> > You are probably saying that on your platform you can not remove
> > anything from /lib/firmware, right? I don't see how you come from "it is
> > part of firmware package" to "removing is not possible". Trying to
> > understand this and it makes no sense.
>
> It is already in linux distribution packages. If I remove that file from
> file system it will be placed there again by package management or it it
> will throw error message about system integrity (missing file, etc...).
>
> Also that file is already in linux-firmware git and so is propagated to
> /lib/firmware by anybody who is using linux-firmware.
>
> > >> Like we discussed earlier, the default nvs file should not be used by
> > >> normal users.
> > >
> > > But already is and we need to deal with this fact.
> >
> > Why?
>
> Because everybody has already installed it.
>
> > Are there other platforms that use the default nvs file and have a
> > working wifi.
>
> I do not know.
>
> > So your "removing is not possible" would be about
> > regression for those?
>
> Yes, that is possible.
>
> Also you can use wifi on Nokia N900 with this default file. Yes it is
> not recommended and probably has performance problems... but more people
> use it for SSH and it is working. Pavel could confirm this.
Yes, wifi somehow works on N900. .. depending on userspace and kernel
versions.
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
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 11:57 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: <87bmus7mfk.fsf@kamboji.qca.qualcomm.com>
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).
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.
3) If we do rename *now* we will totally break wifi support on Nokia
N900.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Johannes Berg @ 2017-01-27 11:27 UTC (permalink / raw)
To: Arend Van Spriel, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <a36abf1d-5d4b-4c37-e325-a69166663a04@broadcom.com>
> I actually have two dependent brcmfmac patches. Do you expect
> conflict if Kalle takes all?
Not really, if that's somehow easier we can do that.
johannes
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 11:49 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: <20170127103408.GG24223@pali>
Pali Roh=C3=A1r <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.
--=20
Kalle Valo
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2017-01-26
From: Kalle Valo @ 2017-01-27 11:24 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1485462650.26003.11.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> Here's my first pull-request intended for v4.11. It has a bunch of
> fixes, cleanups and improvements here and there, as well as a few new
> features. More details in the tag description.
>
> I have sent this out before and kbuildbot didn't find any issues.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 106e0deca1ac6ac627a10617fe77a95200cb01a7:
>
> rtlwifi: rtl8192cu: Convert driver to use common macros (2017-01-20 12:06:10 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-01-26
>
> for you to fetch changes up to 758c98e089389e90732fe45087fdee3177493a81:
>
> iwlwifi: mvm: cleanup redundant assignment (2017-01-26 09:39:02 +0200)
>
> ----------------------------------------------------------------
> Some improvements, bugfixes and new features:
> * A bunch of cleanups here and there;
> * A few simple bugfixes;
> * Some more work in preparation for A000 family support;
> * Add support for radiotap timestamps;
> * Some work on our firmware debugging capabilities;
>
> ----------------------------------------------------------------
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend Van Spriel @ 2017-01-27 11:29 UTC (permalink / raw)
To: Johannes Berg, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <1485516428.5851.6.camel@sipsolutions.net>
On 27-1-2017 12:27, Johannes Berg wrote:
>
>> I actually have two dependent brcmfmac patches. Do you expect
>> conflict if Kalle takes all?
>
> Not really, if that's somehow easier we can do that.
Will do. I checked the other drivers. All those supporting wowl
netdetect did provide max_nd_matchsets except for brcmfmac.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend Van Spriel @ 2017-01-27 11:25 UTC (permalink / raw)
To: Johannes Berg, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <13d1e654-6928-39e7-4751-fb90d3da7a54@broadcom.com>
On 24-1-2017 12:28, Arend Van Spriel wrote:
> On 24-1-2017 9:57, Johannes Berg wrote:
>> On Thu, 2017-01-19 at 14:08 +0100, Arend Van Spriel wrote:
>>>
>>> On 19-1-2017 13:00, Luca Coelho wrote:
>>>> On Thu, 2017-01-19 at 10:01 +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.
>>>>>
>>>>> Cc: Luciano Coelho <luciano.coelho@intel.com>
>>>>> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>>> ---
>>>>
>>>> What?! You don't have the same number of matchsets for both? :P
>>>
>>> Actually I have, but your comment mentioned they do not have to be
>>> the
>>> same. brcmfmac actually did not set max_nd_match_sets so I was
>>> surprised
>>> it worked. That said this patch will result in regression in brcmfmac
>>> :-p Not sure about other drivers supporting net-detect.
>>
>> So do you want to submit a patch to brcmfmac first, and then I'll apply
>> this later? I can apply it and break it, but now that we already know
>> ...?
>
> I have a brcmfmac patch in the queue. I will look at the other scheduled
> scan supporting drivers.
Hi Johannes,
I actually have two dependent brcmfmac patches. Do you expect conflict
if Kalle takes all?
Regards,
Arend
^ 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 10:34 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: <f60cf2c0-bc1e-3a5f-991c-dc6c95a656af@broadcom.com>
On Friday 27 January 2017 11:19:25 Arend Van Spriel wrote:
> On 27-1-2017 11:10, Pali Rohár wrote:
> > On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> >> On 27-1-2017 10:43, Pali Rohár wrote:
> >>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> >>>> Pali Rohár <pali.rohar@gmail.com> writes:
> >>>>
> >>>>> NVS calibration data for wl1251 are model specific. Every one device with
> >>>>> wl1251 chip has different and calibrated in factory.
> >>>>>
> >>>>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
> >>>>> in that case there is no "standard" place. Every device has stored them on
> >>>>> different place (some in rootfs file, some in dedicated nand partition,
> >>>>> some in another proprietary structure).
> >>>>>
> >>>>> Kernel wl1251 driver cannot support every one different storage decided by
> >>>>> device manufacture so it will use request_firmware_prefer_user() call for
> >>>>> loading NVS calibration data and userspace helper will be responsible to
> >>>>> prepare correct data.
> >>>>>
> >>>>> In case userspace helper fails request_firmware_prefer_user() still try to
> >>>>> load data file directly from VFS as fallback mechanism.
> >>>>>
> >>>>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> >>>>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> >>>>> devices.
> >>>>>
> >>>>> With this patch it is finally possible to load correct model specific NVS
> >>>>> calibration data for Nokia N900.
> >>>>>
> >>>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> >>>>> ---
> >>>>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> >>>>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
> >>>>> 2 files changed, 2 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
> >>>>> index 7142ccf..affe154 100644
> >>>>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> >>>>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> >>>>> @@ -2,6 +2,7 @@ config WL1251
> >>>>> tristate "TI wl1251 driver support"
> >>>>> depends on MAC80211
> >>>>> select FW_LOADER
> >>>>> + select FW_LOADER_USER_HELPER
> >>>>> select CRC7
> >>>>> ---help---
> >>>>> This will enable TI wl1251 driver support. The drivers make
> >>>>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> >>>>> index 208f062..24f8866 100644
> >>>>> --- a/drivers/net/wireless/ti/wl1251/main.c
> >>>>> +++ b/drivers/net/wireless/ti/wl1251/main.c
> >>>>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> >>>>> struct device *dev = wiphy_dev(wl->hw->wiphy);
> >>>>> int ret;
> >>>>>
> >>>>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
> >>>>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
> >>>>
> >>>> I don't see the need for this. Just remove the default nvs file from
> >>>> filesystem and the fallback user helper will be always used, right?
> >>>
> >>> It is part of linux-firmware repository. And already part of all
> >>> previous versions of linux-firmware packages in lot of linux
> >>> distributions. So removing it is not possible...
> >>
> >> You are probably saying that on your platform you can not remove
> >> anything from /lib/firmware, right? I don't see how you come from "it is
> >> part of firmware package" to "removing is not possible". Trying to
> >> understand this and it makes no sense.
> >
> > It is already in linux distribution packages. If I remove that file from
> > file system it will be placed there again by package management or it it
> > will throw error message about system integrity (missing file, etc...).
> >
> > Also that file is already in linux-firmware git and so is propagated to
> > /lib/firmware by anybody who is using linux-firmware.
> >
> >>>> Like we discussed earlier, the default nvs file should not be used by
> >>>> normal users.
> >>>
> >>> But already is and we need to deal with this fact.
> >>
> >> Why?
> >
> > Because everybody has already installed it.
> >
> >> Are there other platforms that use the default nvs file and have a
> >> working wifi.
> >
> > I do not know.
> >
> >> So your "removing is not possible" would be about
> >> regression for those?
> >
> > Yes, that is possible.
> >
> > Also you can use wifi on Nokia N900 with this default file. Yes it is
> > not recommended and probably has performance problems... but more people
> > use it for SSH and it is working. Pavel could confirm this.
> >
> > So yes, if you remove that file *now* there is regression for Nokia N900
> > when you are using SSH over wifi.
>
> So you are changing the behavior for all platforms using wl1251, but the
> user-helper preference is (probably) only applicable for N900, right?
No. Some wl1251 chips have internal EEPROM where is stored MAC address
and NVS data. And kernel driver already can read it. So this change is
only for platforms without internal EEPROM.
And all platforms without internal EEPROM should use userspace helper to
provide correct NVS data (and ideally also MAC address).
Except Nokia N900 I know just Pandora who has also wl1251 chip. But
Pandora has EEPROM.
Grepping linux source code... and I see only defines for Nokia N900 and
Pandora. There can be also another user with external DTS file, but what
is reality? Is there still really any other user of wl1251 chip with
upstream kernel? If yes, we can prepare userspace helper if he does not
have NVS stored in EEPROM...
> 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...
When helper is not available this patch just adds delay, but
functionality is still there and same. With helper support will be
finally fixed.
And I have no idea if those default NVS data are somehow usable on other
platforms...
--
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: Arend Van Spriel @ 2017-01-27 10:19 UTC (permalink / raw)
To: Pali Rohár
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: <20170127101043.GD24223@pali>
On 27-1-2017 11:10, Pali Rohár wrote:
> On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
>> On 27-1-2017 10:43, Pali Rohár wrote:
>>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
>>>> Pali Rohár <pali.rohar@gmail.com> writes:
>>>>
>>>>> NVS calibration data for wl1251 are model specific. Every one device with
>>>>> wl1251 chip has different and calibrated in factory.
>>>>>
>>>>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>>>>> in that case there is no "standard" place. Every device has stored them on
>>>>> different place (some in rootfs file, some in dedicated nand partition,
>>>>> some in another proprietary structure).
>>>>>
>>>>> Kernel wl1251 driver cannot support every one different storage decided by
>>>>> device manufacture so it will use request_firmware_prefer_user() call for
>>>>> loading NVS calibration data and userspace helper will be responsible to
>>>>> prepare correct data.
>>>>>
>>>>> In case userspace helper fails request_firmware_prefer_user() still try to
>>>>> load data file directly from VFS as fallback mechanism.
>>>>>
>>>>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
>>>>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
>>>>> devices.
>>>>>
>>>>> With this patch it is finally possible to load correct model specific NVS
>>>>> calibration data for Nokia N900.
>>>>>
>>>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>>>>> ---
>>>>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
>>>>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
>>>>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
>>>>> index 7142ccf..affe154 100644
>>>>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
>>>>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
>>>>> @@ -2,6 +2,7 @@ config WL1251
>>>>> tristate "TI wl1251 driver support"
>>>>> depends on MAC80211
>>>>> select FW_LOADER
>>>>> + select FW_LOADER_USER_HELPER
>>>>> select CRC7
>>>>> ---help---
>>>>> This will enable TI wl1251 driver support. The drivers make
>>>>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
>>>>> index 208f062..24f8866 100644
>>>>> --- a/drivers/net/wireless/ti/wl1251/main.c
>>>>> +++ b/drivers/net/wireless/ti/wl1251/main.c
>>>>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
>>>>> struct device *dev = wiphy_dev(wl->hw->wiphy);
>>>>> int ret;
>>>>>
>>>>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
>>>>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>>>>
>>>> I don't see the need for this. Just remove the default nvs file from
>>>> filesystem and the fallback user helper will be always used, right?
>>>
>>> It is part of linux-firmware repository. And already part of all
>>> previous versions of linux-firmware packages in lot of linux
>>> distributions. So removing it is not possible...
>>
>> You are probably saying that on your platform you can not remove
>> anything from /lib/firmware, right? I don't see how you come from "it is
>> part of firmware package" to "removing is not possible". Trying to
>> understand this and it makes no sense.
>
> It is already in linux distribution packages. If I remove that file from
> file system it will be placed there again by package management or it it
> will throw error message about system integrity (missing file, etc...).
>
> Also that file is already in linux-firmware git and so is propagated to
> /lib/firmware by anybody who is using linux-firmware.
>
>>>> Like we discussed earlier, the default nvs file should not be used by
>>>> normal users.
>>>
>>> But already is and we need to deal with this fact.
>>
>> Why?
>
> Because everybody has already installed it.
>
>> Are there other platforms that use the default nvs file and have a
>> working wifi.
>
> I do not know.
>
>> So your "removing is not possible" would be about
>> regression for those?
>
> Yes, that is possible.
>
> Also you can use wifi on Nokia N900 with this default file. Yes it is
> not recommended and probably has performance problems... but more people
> use it for SSH and it is working. Pavel could confirm this.
>
> So yes, if you remove that file *now* there is regression for Nokia N900
> when you are using SSH over wifi.
So you are changing the behavior for all platforms using wl1251, but the
user-helper preference is (probably) only applicable for N900, right? 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.
Regards,
Arend
^ 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 10:10 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: <def4c357-64c0-0681-a5d5-f49a6cb84a92@broadcom.com>
On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> On 27-1-2017 10:43, Pali Rohár wrote:
> > On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> >> Pali Rohár <pali.rohar@gmail.com> writes:
> >>
> >>> NVS calibration data for wl1251 are model specific. Every one device with
> >>> wl1251 chip has different and calibrated in factory.
> >>>
> >>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
> >>> in that case there is no "standard" place. Every device has stored them on
> >>> different place (some in rootfs file, some in dedicated nand partition,
> >>> some in another proprietary structure).
> >>>
> >>> Kernel wl1251 driver cannot support every one different storage decided by
> >>> device manufacture so it will use request_firmware_prefer_user() call for
> >>> loading NVS calibration data and userspace helper will be responsible to
> >>> prepare correct data.
> >>>
> >>> In case userspace helper fails request_firmware_prefer_user() still try to
> >>> load data file directly from VFS as fallback mechanism.
> >>>
> >>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> >>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> >>> devices.
> >>>
> >>> With this patch it is finally possible to load correct model specific NVS
> >>> calibration data for Nokia N900.
> >>>
> >>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> >>> ---
> >>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> >>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
> >>> 2 files changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
> >>> index 7142ccf..affe154 100644
> >>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> >>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> >>> @@ -2,6 +2,7 @@ config WL1251
> >>> tristate "TI wl1251 driver support"
> >>> depends on MAC80211
> >>> select FW_LOADER
> >>> + select FW_LOADER_USER_HELPER
> >>> select CRC7
> >>> ---help---
> >>> This will enable TI wl1251 driver support. The drivers make
> >>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> >>> index 208f062..24f8866 100644
> >>> --- a/drivers/net/wireless/ti/wl1251/main.c
> >>> +++ b/drivers/net/wireless/ti/wl1251/main.c
> >>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> >>> struct device *dev = wiphy_dev(wl->hw->wiphy);
> >>> int ret;
> >>>
> >>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
> >>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
> >>
> >> I don't see the need for this. Just remove the default nvs file from
> >> filesystem and the fallback user helper will be always used, right?
> >
> > It is part of linux-firmware repository. And already part of all
> > previous versions of linux-firmware packages in lot of linux
> > distributions. So removing it is not possible...
>
> You are probably saying that on your platform you can not remove
> anything from /lib/firmware, right? I don't see how you come from "it is
> part of firmware package" to "removing is not possible". Trying to
> understand this and it makes no sense.
It is already in linux distribution packages. If I remove that file from
file system it will be placed there again by package management or it it
will throw error message about system integrity (missing file, etc...).
Also that file is already in linux-firmware git and so is propagated to
/lib/firmware by anybody who is using linux-firmware.
> >> Like we discussed earlier, the default nvs file should not be used by
> >> normal users.
> >
> > But already is and we need to deal with this fact.
>
> Why?
Because everybody has already installed it.
> Are there other platforms that use the default nvs file and have a
> working wifi.
I do not know.
> So your "removing is not possible" would be about
> regression for those?
Yes, that is possible.
Also you can use wifi on Nokia N900 with this default file. Yes it is
not recommended and probably has performance problems... but more people
use it for SSH and it is working. Pavel could confirm this.
So yes, if you remove that file *now* there is regression for Nokia N900
when you are using SSH over wifi.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Pali Rohár @ 2017-01-27 9:05 UTC (permalink / raw)
To: Kalle Valo
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: <87inp1ndgm.fsf@codeaurora.org>
On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > In case there is no valid MAC address kernel generates random one. This
> > patch propagate this generated MAC address back to NVS data which will be
> > uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> > uses.
> >
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>
> Why? What issue does this fix?
Send permanent MAC address to wl1251 chip, same what is doing wl12xx
driver.
--
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: Arend Van Spriel @ 2017-01-27 10:05 UTC (permalink / raw)
To: Pali Rohár, Kalle Valo
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: <20170127094342.GC24223@pali>
On 27-1-2017 10:43, Pali Rohár wrote:
> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
>> Pali Rohár <pali.rohar@gmail.com> writes:
>>
>>> NVS calibration data for wl1251 are model specific. Every one device with
>>> wl1251 chip has different and calibrated in factory.
>>>
>>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>>> in that case there is no "standard" place. Every device has stored them on
>>> different place (some in rootfs file, some in dedicated nand partition,
>>> some in another proprietary structure).
>>>
>>> Kernel wl1251 driver cannot support every one different storage decided by
>>> device manufacture so it will use request_firmware_prefer_user() call for
>>> loading NVS calibration data and userspace helper will be responsible to
>>> prepare correct data.
>>>
>>> In case userspace helper fails request_firmware_prefer_user() still try to
>>> load data file directly from VFS as fallback mechanism.
>>>
>>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
>>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
>>> devices.
>>>
>>> With this patch it is finally possible to load correct model specific NVS
>>> calibration data for Nokia N900.
>>>
>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>>> ---
>>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
>>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
>>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
>>> index 7142ccf..affe154 100644
>>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
>>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
>>> @@ -2,6 +2,7 @@ config WL1251
>>> tristate "TI wl1251 driver support"
>>> depends on MAC80211
>>> select FW_LOADER
>>> + select FW_LOADER_USER_HELPER
>>> select CRC7
>>> ---help---
>>> This will enable TI wl1251 driver support. The drivers make
>>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
>>> index 208f062..24f8866 100644
>>> --- a/drivers/net/wireless/ti/wl1251/main.c
>>> +++ b/drivers/net/wireless/ti/wl1251/main.c
>>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
>>> struct device *dev = wiphy_dev(wl->hw->wiphy);
>>> int ret;
>>>
>>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
>>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>>
>> I don't see the need for this. Just remove the default nvs file from
>> filesystem and the fallback user helper will be always used, right?
>
> It is part of linux-firmware repository. And already part of all
> previous versions of linux-firmware packages in lot of linux
> distributions. So removing it is not possible...
You are probably saying that on your platform you can not remove
anything from /lib/firmware, right? I don't see how you come from "it is
part of firmware package" to "removing is not possible". Trying to
understand this and it makes no sense.
>> Like we discussed earlier, the default nvs file should not be used by
>> normal users.
>
> But already is and we need to deal with this fact.
Why? Are there other platforms that use the default nvs file and have a
working wifi. So your "removing is not possible" would be about
regression for those?
Regards,
Arend
^ 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 9:43 UTC (permalink / raw)
To: Kalle Valo
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: <87tw8lnei3.fsf@codeaurora.org>
On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > NVS calibration data for wl1251 are model specific. Every one device with
> > wl1251 chip has different and calibrated in factory.
> >
> > Not all wl1251 chips have own EEPROM where are calibration data stored. And
> > in that case there is no "standard" place. Every device has stored them on
> > different place (some in rootfs file, some in dedicated nand partition,
> > some in another proprietary structure).
> >
> > Kernel wl1251 driver cannot support every one different storage decided by
> > device manufacture so it will use request_firmware_prefer_user() call for
> > loading NVS calibration data and userspace helper will be responsible to
> > prepare correct data.
> >
> > In case userspace helper fails request_firmware_prefer_user() still try to
> > load data file directly from VFS as fallback mechanism.
> >
> > On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> > in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> > devices.
> >
> > With this patch it is finally possible to load correct model specific NVS
> > calibration data for Nokia N900.
> >
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> > drivers/net/wireless/ti/wl1251/main.c | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
> > index 7142ccf..affe154 100644
> > --- a/drivers/net/wireless/ti/wl1251/Kconfig
> > +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> > @@ -2,6 +2,7 @@ config WL1251
> > tristate "TI wl1251 driver support"
> > depends on MAC80211
> > select FW_LOADER
> > + select FW_LOADER_USER_HELPER
> > select CRC7
> > ---help---
> > This will enable TI wl1251 driver support. The drivers make
> > diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> > index 208f062..24f8866 100644
> > --- a/drivers/net/wireless/ti/wl1251/main.c
> > +++ b/drivers/net/wireless/ti/wl1251/main.c
> > @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> > struct device *dev = wiphy_dev(wl->hw->wiphy);
> > int ret;
> >
> > - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
> > + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>
> I don't see the need for this. Just remove the default nvs file from
> filesystem and the fallback user helper will be always used, right?
It is part of linux-firmware repository. And already part of all
previous versions of linux-firmware packages in lot of linux
distributions. So removing it is not possible...
> Like we discussed earlier, the default nvs file should not be used by
> normal users.
But already is and we need to deal with this fact.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Kalle Valo @ 2017-01-27 9:30 UTC (permalink / raw)
To: 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: <20170127090538.GB24223@pali>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
>> Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>>=20
>> > In case there is no valid MAC address kernel generates random one. This
>> > patch propagate this generated MAC address back to NVS data which will=
be
>> > uploaded to wl1251 chip. So HW would have same MAC address as linux ke=
rnel
>> > uses.
>> >
>> > Signed-off-by: Pali Roh=C3=A1r <pali.rohar@gmail.com>
>>=20
>> Why? What issue does this fix?
>
> Send permanent MAC address to wl1251 chip, same what is doing wl12xx
> driver.
Ok, so this doesn't change functionality in any way and you are adding
it only because wl12xx does the same? You should document that in the
the commit log.
If there's no change I don't really see the point of this. But if
there's harm, hopefully, I guess it's ok.
--=20
Kalle Valo
^ 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