* [PATCH 3/4] cfg80211: rdev-ops: remove callback check from rdev_start_radar_detection()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1470825209-10054-1-git-send-email-arend.vanspriel@broadcom.com>
The wrapper rdev_start_radar_detection() checks whether the driver provides
the start_radar_detection callback and returns -ENOTSUPP if not. However,
this check is already performed in nl80211_start_radar_detection() resulting
in -EOPNOTSUPP. This patch removes check from rdev wrapper function and move
the callback checking in nl80211_start_radar_detection() before the other
checks.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/nl80211.c | 7 ++++---
net/wireless/rdev-ops.h | 7 +++----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f02653a..8ab63b5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6826,6 +6826,9 @@ static int nl80211_start_radar_detection(struct sk_buff *skb,
unsigned int cac_time_ms;
int err;
+ if (!rdev->ops->start_radar_detection)
+ return -EOPNOTSUPP;
+
dfs_region = reg_get_dfs_region(wdev->wiphy);
if (dfs_region == NL80211_DFS_UNSET)
return -EINVAL;
@@ -6845,15 +6848,13 @@ static int nl80211_start_radar_detection(struct sk_buff *skb,
if (err < 0)
return err;
+ /* 0 value means no dfs is required so bail out */
if (err == 0)
return -EINVAL;
if (!cfg80211_chandef_dfs_usable(wdev->wiphy, &chandef))
return -EINVAL;
- if (!rdev->ops->start_radar_detection)
- return -EOPNOTSUPP;
-
cac_time_ms = cfg80211_chandef_dfs_cac_time(&rdev->wiphy, &chandef);
if (WARN_ON(!cac_time_ms))
cac_time_ms = IEEE80211_DFS_MIN_CAC_TIME_MS;
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index d002415..2020606 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1034,13 +1034,12 @@ rdev_start_radar_detection(struct cfg80211_registered_device *rdev,
struct cfg80211_chan_def *chandef,
u32 cac_time_ms)
{
- int ret = -ENOTSUPP;
+ int ret;
trace_rdev_start_radar_detection(&rdev->wiphy, dev, chandef,
cac_time_ms);
- if (rdev->ops->start_radar_detection)
- ret = rdev->ops->start_radar_detection(&rdev->wiphy, dev,
- chandef, cac_time_ms);
+ ret = rdev->ops->start_radar_detection(&rdev->wiphy, dev,
+ chandef, cac_time_ms);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] cfg80211: rdev-ops: remove callback check from rdev_set_mcast_rate()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1470825209-10054-1-git-send-email-arend.vanspriel@broadcom.com>
The wrapper rdev_set_mcast_rate() checks whether the driver provides
the set_mcast_rate callback and returns -ENOTSUPP if not. However, this
check is already performed in nl80211_set_mcast_rate() resulting in
-EOPNOTSUPP. This patch removes check from rdev wrapper function.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/rdev-ops.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 903b58a..d002415 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1050,11 +1050,10 @@ rdev_set_mcast_rate(struct cfg80211_registered_device *rdev,
struct net_device *dev,
int mcast_rate[NUM_NL80211_BANDS])
{
- int ret = -ENOTSUPP;
+ int ret;
trace_rdev_set_mcast_rate(&rdev->wiphy, dev, mcast_rate);
- if (rdev->ops->set_mcast_rate)
- ret = rdev->ops->set_mcast_rate(&rdev->wiphy, dev, mcast_rate);
+ ret = rdev->ops->set_mcast_rate(&rdev->wiphy, dev, mcast_rate);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 6:25 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <866e31b50f364a87aabe94d2af03ecb8@aptaiexm02f.ap.qualcomm.com>
Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> FIPS RNG test is supposed to be run on the output of an RNG, and not on the
> RNG entropy source. It is not surprising that the RNG input fails the
> entropy tests from NIST. Check the following example.
>
> Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each
> a_i is a byte. And imagine, this sequence passes all randomness tests.
>
> Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n,
> where each zero is a byte
>
> If you give this sequence (as an entropy source) to a randomness test, it
> will fail most of the tests, if not all. This does not mean this sequence
> is not appropriate as an entropy source, it just means we need twice more
> bytes to gain the same amount of entropy.
Agreed. But that is a very simplistic view.
>
> I can give this 2n byte sequence to an RNG as an entropy source and it
> provides the same amount of security as if I give the n byte stream.
Well, I am working with standards bodies like NIST and BSI on RNG
assessments. They all require that the noise source (pre-whitening, of
course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If
you fail, you better have a good argument.
And the only argument that is kind of allowed is that you oversample your
noise source to seed a DRNG from (i.e. have an entropy to data ratio of
significantly below 1). And the argument for the oversampling rate is always
a very interesting discussion. You apply 10/32. In private, I am wondering
about that ratio, but this should not be discussed here as I hope you have a
valid argument for that.
As we are talking about the current rngd, we have to consider that it does
*not* perform an oversampling (yet) as mentioned in the previous emails.
Do not get me wrong on my initial patch: your RNG may provide some entropy.
But there are quite some folks who want to understand and audit a noise
source before using it. Your current implementation simply does not allow
switching the noise source off to feed the input_pool with data that
increases the entropy estimator (at runtime).
Ciao
Stephan
^ permalink raw reply
* [PATCH 4/4] cfg80211: rdev-ops: remove checks from rdev_{add,del}_tx_ts()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1470825209-10054-1-git-send-email-arend.vanspriel@broadcom.com>
The wrappers check if callback is specified. Just have the checks
in nl80211.c checking the NL80211_FEATURE_SUPPORTS_WMM_ADMISSION
feature flag. If the driver sets this flag the callbacks are being
checked in wiphy_register().
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/core.c | 4 ++++
net/wireless/nl80211.c | 3 +++
net/wireless/rdev-ops.h | 12 +++++-------
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..ef83db8 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -579,6 +579,10 @@ int wiphy_register(struct wiphy *wiphy)
!rdev->ops->tdls_cancel_channel_switch)))
return -EINVAL;
+ if (WARN_ON((wiphy->features & NL80211_FEATURE_SUPPORTS_WMM_ADMISSION)
+ && (!rdev->ops->add_tx_ts || !rdev->ops->del_tx_ts)))
+ return -EINVAL;
+
/*
* if a wiphy has unsupported modes for regulatory channel enforcement,
* opt-out of enforcement checking
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8ab63b5..e818cec 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10890,6 +10890,9 @@ static int nl80211_del_tx_ts(struct sk_buff *skb, struct genl_info *info)
u8 tsid;
int err;
+ if (!(rdev->wiphy.features & NL80211_FEATURE_SUPPORTS_WMM_ADMISSION))
+ return -EOPNOTSUPP;
+
if (!info->attrs[NL80211_ATTR_TSID] || !info->attrs[NL80211_ATTR_MAC])
return -EINVAL;
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 2020606..be89461 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -978,13 +978,12 @@ rdev_add_tx_ts(struct cfg80211_registered_device *rdev,
struct net_device *dev, u8 tsid, const u8 *peer,
u8 user_prio, u16 admitted_time)
{
- int ret = -EOPNOTSUPP;
+ int ret;
trace_rdev_add_tx_ts(&rdev->wiphy, dev, tsid, peer,
user_prio, admitted_time);
- if (rdev->ops->add_tx_ts)
- ret = rdev->ops->add_tx_ts(&rdev->wiphy, dev, tsid, peer,
- user_prio, admitted_time);
+ ret = rdev->ops->add_tx_ts(&rdev->wiphy, dev, tsid, peer,
+ user_prio, admitted_time);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
@@ -994,11 +993,10 @@ static inline int
rdev_del_tx_ts(struct cfg80211_registered_device *rdev,
struct net_device *dev, u8 tsid, const u8 *peer)
{
- int ret = -EOPNOTSUPP;
+ int ret;
trace_rdev_del_tx_ts(&rdev->wiphy, dev, tsid, peer);
- if (rdev->ops->del_tx_ts)
- ret = rdev->ops->del_tx_ts(&rdev->wiphy, dev, tsid, peer);
+ ret = rdev->ops->del_tx_ts(&rdev->wiphy, dev, tsid, peer);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] cfg80211: rdev-ops: remove callback check from rdev_set_coalesce()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
The wrapper rdev_set_coalesce() checks whether the driver provides
the set_coalesce callback and returns -ENOTSUPP if not. However, this
check is already performed in nl80211_set_coalesce() resulting in
-EOPNOTSUPP. This patch removes check from rdev wrapper function.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/rdev-ops.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 85ff30b..903b58a 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1063,11 +1063,10 @@ static inline int
rdev_set_coalesce(struct cfg80211_registered_device *rdev,
struct cfg80211_coalesce *coalesce)
{
- int ret = -ENOTSUPP;
+ int ret;
trace_rdev_set_coalesce(&rdev->wiphy, coalesce);
- if (rdev->ops->set_coalesce)
- ret = rdev->ops->set_coalesce(&rdev->wiphy, coalesce);
+ ret = rdev->ops->set_coalesce(&rdev->wiphy, coalesce);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
}
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 7:15 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1526134.1iUazSISyZ@positron.chronox.de>
Hi Stephan,
NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the amount of min entropy the source provides, and not to decide if the source has passed the tests or failed. See
https://github.com/usnistgov/SP800-90B_EntropyAssessment
The goal is often to make sure the input entropy is more than the entropy we expect from the output.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 2:52 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> Would you please provide a recent NIST document which asks the entropy
> source to pass the NIST randomness tests ?
See FIPS 140-2 IG 7.15 which explicitly references SP800-22.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 7:27 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <c0951e085764481d8d85637734e2e14b@aptaiexm02f.ap.qualcomm.com>
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the
> amount of min entropy the source provides, and not to decide if the source
> has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the entropy we
> expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the
binary decision). Yet, SP800-22 with the associated tool delivers a binary
decision.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8723ae: Fix leak in _rtl8723e_read_adapter_info()
From: Larry Finger @ 2016-08-10 14:11 UTC (permalink / raw)
To: Christian Engelmayer, chaoming_li; +Cc: kvalo, arnd, joe, linux-wireless
In-Reply-To: <1470772452-24642-1-git-send-email-cengelma@gmx.at>
On 08/09/2016 02:54 PM, Christian Engelmayer wrote:
> In case of (rtlhal->oem_id != RT_CID_DEFAULT), the function directly
> returns and leaks the already allocated hwinfo memory. Go through the
> correct exit path.
>
> Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
This patch looks good. Thanks.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
> index b88c7ee72dbf..ba30efc2d195 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
> @@ -1654,7 +1654,7 @@ static void _rtl8723e_read_adapter_info(struct ieee80211_hw *hw,
> rtlefuse->autoload_failflag, hwinfo);
>
> if (rtlhal->oem_id != RT_CID_DEFAULT)
> - return;
> + goto exit;
>
> switch (rtlefuse->eeprom_oemid) {
> case EEPROM_CID_DEFAULT:
>
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 2:35 UTC (permalink / raw)
To: Stephan Mueller, Herbert Xu
Cc: Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1645997.7cVzaEi3NG@tauon.atsec.com>
Hi Stephan,
For those less perfect noise source, can't pass the FIPS test.
static int update_kernel_random(int random_step,
unsigned char *buf, fips_ctx_t *fipsctx_in)
{
unsigned char *p;
int fips;
fips = fips_run_rng_test(fipsctx_in, buf);
if (fips)
return 1;
for (p = buf; p + random_step <= &buf[FIPS_RNG_BUFFER_SIZE];
p += random_step) {
random_add_entropy(p, random_step);
random_sleep();
}
return 0;
}
--
Miaoqing
________________________________________
From: Stephan Mueller <smueller@chronox.de>
Sent: Tuesday, August 9, 2016 5:37 PM
To: Herbert Xu
Cc: Pan, Miaoqing; Matt Mackall; miaoqing@codeaurora.org; Valo, Kalle; linux-wireless@vger.kernel.org; ath9k-devel; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > But shouldn't the default of the rngd then be adjusted a bit?
>
> Please elaborate.
in rngd_linux.c:random_add_entropy(void *buf, size_t size):
entropy.ent_count = size * 8;
entropy.size = size;
memcpy(entropy.data, buf, size);
if (ioctl(random_fd, RNDADDENTROPY, &entropy) != 0) {
...
in rngd.c:do_loop():
retval = iter->xread(buf, sizeof buf, iter);
...
rc = update_kernel_random(random_step,
buf, iter->fipsctx);
where update_kernel_random simply invokes random_add_entropy in chunks.
Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
random with an entropy estimate that is equal to the read bytes.
With less than perfect noise sources, entropy.ent_count should be much
smaller.
>
> Thanks,
Ciao
Stephan
^ permalink raw reply
* Google Summer of Code 2016 - Who wants to attend the Mentor Summit
From: Till Kamppeter @ 2016-08-09 20:55 UTC (permalink / raw)
To: Alexey Khoroshilov, Luis R. Rodriguez, Greg KH,
lsb-discuss@lists.linux-foundation.org, linux-wireless,
Open Printing, chris holcombe, Chris MacNaughton,
Jan-Simon Möller
Hi,
as every year there is a Mentor Summit at Google in Mountain View,
California. Two of the mentors or org admins of each organization can
participate and Google pays the hotel plus 2200 USD (in total for the
two) to cover travel expenses.
So please tell if you want to attand. Thanks.
Till
^ permalink raw reply
* Re: Google Summer of Code 2016 - Who wants to attend the Mentor Summit
From: chris holcombe @ 2016-08-09 21:03 UTC (permalink / raw)
To: Till Kamppeter, Alexey Khoroshilov, Luis R. Rodriguez, Greg KH,
lsb-discuss@lists.linux-foundation.org, linux-wireless,
Open Printing, Chris MacNaughton, Jan-Simon Möller
In-Reply-To: <9556e237-4936-98d3-ec27-9976577ed55e@gmail.com>
Hey Till,
I'm likely available and it's a short 2hr flight for me. I'd like attend :)
-Chris
On 08/09/2016 01:55 PM, Till Kamppeter wrote:
> Hi,
>
> as every year there is a Mentor Summit at Google in Mountain View,
> California. Two of the mentors or org admins of each organization can
> participate and Google pays the hotel plus 2200 USD (in total for the
> two) to cover travel expenses.
>
> So please tell if you want to attand. Thanks.
>
> Till
>
^ permalink raw reply
* [PATCH] rtlwifi: rtl8723ae: Fix leak in _rtl8723e_read_adapter_info()
From: Christian Engelmayer @ 2016-08-09 19:54 UTC (permalink / raw)
To: Larry.Finger, chaoming_li
Cc: kvalo, arnd, joe, linux-wireless, Christian Engelmayer
In case of (rtlhal->oem_id != RT_CID_DEFAULT), the function directly
returns and leaks the already allocated hwinfo memory. Go through the
correct exit path.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
index b88c7ee72dbf..ba30efc2d195 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
@@ -1654,7 +1654,7 @@ static void _rtl8723e_read_adapter_info(struct ieee80211_hw *hw,
rtlefuse->autoload_failflag, hwinfo);
if (rtlhal->oem_id != RT_CID_DEFAULT)
- return;
+ goto exit;
switch (rtlefuse->eeprom_oemid) {
case EEPROM_CID_DEFAULT:
--
2.7.4
^ permalink raw reply related
* [PATCH] rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()
From: Christian Engelmayer @ 2016-08-09 19:19 UTC (permalink / raw)
To: Larry.Finger, chaoming_li
Cc: kvalo, arnd, linux-wireless, Christian Engelmayer
In case rtl_get_hwinfo() fails, the function directly returns and leaks the
already allocated hwinfo memory. Go through the correct exit path.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
index b0f632462335..57205514801c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
@@ -1757,7 +1757,7 @@ static void _rtl92de_read_adapter_info(struct ieee80211_hw *hw)
return;
if (rtl_get_hwinfo(hw, rtlpriv, HWSET_MAX_SIZE, hwinfo, params))
- return;
+ goto exit;
_rtl92de_efuse_update_chip_version(hw);
_rtl92de_read_macphymode_and_bandtype(hw, hwinfo);
@@ -1790,6 +1790,7 @@ static void _rtl92de_read_adapter_info(struct ieee80211_hw *hw)
break;
}
rtlefuse->txpwr_fromeprom = true;
+exit:
kfree(hwinfo);
}
--
2.7.4
^ permalink raw reply related
* Re: mwifiex: PCIe8997 chip specific handling
From: Brian Norris @ 2016-08-09 18:44 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, linux-kernel
In-Reply-To: <1469788731-5361-1-git-send-email-akarwar@marvell.com>
Hi,
On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> The patch corrects the revision id register and uses it along with
> magic value and chip version registers to download appropriate firmware
> image.
>
> PCIe8997 Z chipset variant code has been removed, as it won't be used in
> production.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 35 ++++++++++-------------------
> drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +++++-------
> 2 files changed, 18 insertions(+), 31 deletions(-)
[...]
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h b/drivers/net/wireless/marvell/mwifiex/pcie.h
> index f6992f0..46f99ca 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> @@ -32,12 +32,9 @@
> #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
Why do version bumps require firmware renames? Is this just to make sure
you don't load the new firmware on old chip revs that you don't plan to
support for production (i.e., only early revs like the _Z you're
dropping)? This doesn't seems like a good long-term solution, at least
once you start getting this silicon out in the wild. At some point, I'd
expect to see a stable file name.
Brian
>
> #define PCIE_VENDOR_ID_MARVELL (0x11ab)
> #define PCIE_VENDOR_ID_V2_MARVELL (0x1b4b)
> @@ -47,9 +44,10 @@
>
> #define PCIE8897_A0 0x1100
> #define PCIE8897_B0 0x1200
> -#define PCIE8997_Z 0x0
> -#define PCIE8997_V2 0x471
> +#define PCIE8997_A0 0x10
> +#define PCIE8997_A1 0x11
> #define CHIP_VER_PCIEUART 0x3
> +#define CHIP_MAGIC_VALUE 0x24
>
> /* Constants for Buffer Descriptor (BD) rings */
> #define MWIFIEX_MAX_TXRX_BD 0x20
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-09 17:51 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Stephan Mueller, Herbert Xu, Pan, Miaoqing, Matt Mackall,
miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, Sepehrdad, Pouyan
In-Reply-To: <20160809102458.GA20214@khazad-dum.debian.net>
Hi Henrique,
On Tue, Aug 09, 2016 at 07:24:58AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Aug 2016, Stephan Mueller wrote:
> > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools then
> > broken (at least in those large distros)?
>
> Might I humbly suggest that the kernel start providing some metatada
> about the quality of the random source that userspace can consume?
> Preferably by a new ioctl, so that it will fit naturally if we ever
> extend /dev/hwrng to support more than one source?
>
> That would allow for auto tunning to be implemented in userspace...
See my reply to Keith Packard's proposed multi-device hw_random patch:
https://lkml.kernel.org/r/20160809165710.GC2013@io.lakedaemon.net
and top of thread:
https://lkml.kernel.org/r/1469477255-26824-1-git-send-email-keithp@keithp.com
thx,
Jason.
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-09 17:48 UTC (permalink / raw)
To: miaoqing
Cc: kvalo, linux-wireless, ath9k-devel, linux-crypto, smueller,
pouyans
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing@codeaurora.org>
On Tue, Aug 09, 2016 at 03:02:27PM +0800, miaoqing@codeaurora.org wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Until we get the hw_random/get_device_randomness question sorted...
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply
* [PATCH] NFC: nfcmrvl: constify nfcmrvl_if_ops structures
From: Julia Lawall @ 2016-08-09 17:03 UTC (permalink / raw)
To: Lauro Ramos Venancio
Cc: kernel-janitors, Aloisio Almeida Jr, Samuel Ortiz, linux-wireless,
linux-kernel
The nfcmrvl_if_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/nfc/nfcmrvl/i2c.c | 2 +-
drivers/nfc/nfcmrvl/main.c | 2 +-
drivers/nfc/nfcmrvl/nfcmrvl.h | 4 ++--
drivers/nfc/nfcmrvl/spi.c | 2 +-
drivers/nfc/nfcmrvl/uart.c | 2 +-
drivers/nfc/nfcmrvl/usb.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/nfc/nfcmrvl/i2c.c b/drivers/nfc/nfcmrvl/i2c.c
index 78b7aa8..91d1e67 100644
--- a/drivers/nfc/nfcmrvl/i2c.c
+++ b/drivers/nfc/nfcmrvl/i2c.c
@@ -162,7 +162,7 @@ static void nfcmrvl_i2c_nci_update_config(struct nfcmrvl_private *priv,
{
}
-static struct nfcmrvl_if_ops i2c_ops = {
+static const struct nfcmrvl_if_ops i2c_ops = {
.nci_open = nfcmrvl_i2c_nci_open,
.nci_close = nfcmrvl_i2c_nci_close,
.nci_send = nfcmrvl_i2c_nci_send,
diff --git a/drivers/nfc/nfcmrvl/main.c b/drivers/nfc/nfcmrvl/main.c
index 51c8240..8e3f26a 100644
--- a/drivers/nfc/nfcmrvl/main.c
+++ b/drivers/nfc/nfcmrvl/main.c
@@ -102,7 +102,7 @@ static struct nci_ops nfcmrvl_nci_ops = {
struct nfcmrvl_private *nfcmrvl_nci_register_dev(enum nfcmrvl_phy phy,
void *drv_data,
- struct nfcmrvl_if_ops *ops,
+ const struct nfcmrvl_if_ops *ops,
struct device *dev,
struct nfcmrvl_platform_data *pdata)
{
diff --git a/drivers/nfc/nfcmrvl/nfcmrvl.h b/drivers/nfc/nfcmrvl/nfcmrvl.h
index de68ff4..d9c2af3 100644
--- a/drivers/nfc/nfcmrvl/nfcmrvl.h
+++ b/drivers/nfc/nfcmrvl/nfcmrvl.h
@@ -88,7 +88,7 @@ struct nfcmrvl_private {
/* PHY type */
enum nfcmrvl_phy phy;
/* Low level driver ops */
- struct nfcmrvl_if_ops *if_ops;
+ const struct nfcmrvl_if_ops *if_ops;
};
struct nfcmrvl_if_ops {
@@ -103,7 +103,7 @@ void nfcmrvl_nci_unregister_dev(struct nfcmrvl_private *priv);
int nfcmrvl_nci_recv_frame(struct nfcmrvl_private *priv, struct sk_buff *skb);
struct nfcmrvl_private *nfcmrvl_nci_register_dev(enum nfcmrvl_phy phy,
void *drv_data,
- struct nfcmrvl_if_ops *ops,
+ const struct nfcmrvl_if_ops *ops,
struct device *dev,
struct nfcmrvl_platform_data *pdata);
diff --git a/drivers/nfc/nfcmrvl/spi.c b/drivers/nfc/nfcmrvl/spi.c
index a7faa0b..f974b45 100644
--- a/drivers/nfc/nfcmrvl/spi.c
+++ b/drivers/nfc/nfcmrvl/spi.c
@@ -112,7 +112,7 @@ static void nfcmrvl_spi_nci_update_config(struct nfcmrvl_private *priv,
drv_data->nci_spi->xfer_speed_hz = config->clk;
}
-static struct nfcmrvl_if_ops spi_ops = {
+static const struct nfcmrvl_if_ops spi_ops = {
.nci_open = nfcmrvl_spi_nci_open,
.nci_close = nfcmrvl_spi_nci_close,
.nci_send = nfcmrvl_spi_nci_send,
diff --git a/drivers/nfc/nfcmrvl/uart.c b/drivers/nfc/nfcmrvl/uart.c
index 83a99e3..ad7540e 100644
--- a/drivers/nfc/nfcmrvl/uart.c
+++ b/drivers/nfc/nfcmrvl/uart.c
@@ -60,7 +60,7 @@ static void nfcmrvl_uart_nci_update_config(struct nfcmrvl_private *priv,
config->flow_control);
}
-static struct nfcmrvl_if_ops uart_ops = {
+static const struct nfcmrvl_if_ops uart_ops = {
.nci_open = nfcmrvl_uart_nci_open,
.nci_close = nfcmrvl_uart_nci_close,
.nci_send = nfcmrvl_uart_nci_send,
diff --git a/drivers/nfc/nfcmrvl/usb.c b/drivers/nfc/nfcmrvl/usb.c
index 585a0f2..ac3796d 100644
--- a/drivers/nfc/nfcmrvl/usb.c
+++ b/drivers/nfc/nfcmrvl/usb.c
@@ -273,7 +273,7 @@ done:
return err;
}
-static struct nfcmrvl_if_ops usb_ops = {
+static const struct nfcmrvl_if_ops usb_ops = {
.nci_open = nfcmrvl_usb_nci_open,
.nci_close = nfcmrvl_usb_nci_close,
.nci_send = nfcmrvl_usb_nci_send,
^ permalink raw reply related
* [PATCH] NFC: pn533: constify pn533_phy_ops structures
From: Julia Lawall @ 2016-08-09 16:11 UTC (permalink / raw)
To: Lauro Ramos Venancio
Cc: kernel-janitors, Aloisio Almeida Jr, Samuel Ortiz, linux-wireless,
linux-kernel
The pn533_phy_ops are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/nfc/pn533/i2c.c | 2 +-
drivers/nfc/pn533/pn533.c | 2 +-
drivers/nfc/pn533/pn533.h | 4 ++--
drivers/nfc/pn533/usb.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 1dc8924..8a7c17e 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -176,7 +176,7 @@ static irqreturn_t pn533_i2c_irq_thread_fn(int irq, void *data)
return IRQ_HANDLED;
}
-static struct pn533_phy_ops i2c_phy_ops = {
+static const struct pn533_phy_ops i2c_phy_ops = {
.send_frame = pn533_i2c_send_frame,
.send_ack = pn533_i2c_send_ack,
.abort_cmd = pn533_i2c_abort_cmd,
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index d9c5583..2f817b3 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -2560,7 +2560,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
- struct pn533_phy_ops *phy_ops,
+ const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent)
diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
index 553c7d1..e26d634 100644
--- a/drivers/nfc/pn533/pn533.h
+++ b/drivers/nfc/pn533/pn533.h
@@ -179,7 +179,7 @@ struct pn533 {
struct device *dev;
void *phy;
- struct pn533_phy_ops *phy_ops;
+ const struct pn533_phy_ops *phy_ops;
};
typedef int (*pn533_send_async_complete_t) (struct pn533 *dev, void *arg,
@@ -226,7 +226,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
- struct pn533_phy_ops *phy_ops,
+ const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent);
diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
index 33ed78b..bcf3f54 100644
--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -434,7 +434,7 @@ static void pn533_send_complete(struct urb *urb)
}
}
-static struct pn533_phy_ops usb_phy_ops = {
+static const struct pn533_phy_ops usb_phy_ops = {
.send_frame = pn533_usb_send_frame,
.send_ack = pn533_usb_send_ack,
.abort_cmd = pn533_usb_abort_cmd,
^ permalink raw reply related
* [PATCH 3/3] mwifiex: add custom regulatory domain support
From: Amitkumar Karwar @ 2016-08-09 14:50 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1470754246-635-1-git-send-email-akarwar@marvell.com>
This patch creates custom regulatory rules based on the information
received from firmware and enable them during wiphy registration.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 39 ++++++----
drivers/net/wireless/marvell/mwifiex/fw.h | 8 ++
drivers/net/wireless/marvell/mwifiex/main.c | 2 +
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 91 ++++++++++++++++++++++
5 files changed, 127 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 86b31b1..a91d442 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -4224,9 +4224,12 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
wiphy->cipher_suites = mwifiex_cipher_suites;
wiphy->n_cipher_suites = ARRAY_SIZE(mwifiex_cipher_suites);
- if (adapter->region_code)
- wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS |
+ if (adapter->regd) {
+ wiphy->regulatory_flags |= REGULATORY_CUSTOM_REG |
+ REGULATORY_DISABLE_BEACON_HINTS |
REGULATORY_COUNTRY_IE_IGNORE;
+ wiphy_apply_custom_regulatory(wiphy, adapter->regd);
+ }
ether_addr_copy(wiphy->perm_addr, adapter->perm_addr);
wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM;
@@ -4292,19 +4295,27 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
return ret;
}
- if (reg_alpha2 && mwifiex_is_valid_alpha2(reg_alpha2)) {
- mwifiex_dbg(adapter, INFO,
- "driver hint alpha2: %2.2s\n", reg_alpha2);
- regulatory_hint(wiphy, reg_alpha2);
- } else {
- if (adapter->region_code == 0x00) {
- mwifiex_dbg(adapter, WARN, "Ignore world regulatory domain\n");
+ if (!adapter->regd) {
+ if (reg_alpha2 && mwifiex_is_valid_alpha2(reg_alpha2)) {
+ mwifiex_dbg(adapter, INFO,
+ "driver hint alpha2: %2.2s\n", reg_alpha2);
+ regulatory_hint(wiphy, reg_alpha2);
} else {
- country_code =
- mwifiex_11d_code_2_region(adapter->region_code);
- if (country_code &&
- regulatory_hint(wiphy, country_code))
- mwifiex_dbg(priv->adapter, ERROR, "regulatory_hint() failed\n");
+ if (adapter->region_code == 0x00) {
+ mwifiex_dbg(adapter, WARN,
+ "Ignore world regulatory domain\n");
+ } else {
+ wiphy->regulatory_flags |=
+ REGULATORY_DISABLE_BEACON_HINTS |
+ REGULATORY_COUNTRY_IE_IGNORE;
+ country_code =
+ mwifiex_11d_code_2_region(
+ adapter->region_code);
+ if (country_code &&
+ regulatory_hint(wiphy, country_code))
+ mwifiex_dbg(priv->adapter, ERROR,
+ "regulatory_hint() failed\n");
+ }
}
}
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 085db99..18aa525 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -416,6 +416,14 @@ enum P2P_MODES {
P2P_MODE_CLIENT = 3,
};
+enum mwifiex_channel_flags {
+ MWIFIEX_CHANNEL_PASSIVE = BIT(0),
+ MWIFIEX_CHANNEL_DFS = BIT(1),
+ MWIFIEX_CHANNEL_NOHT40 = BIT(2),
+ MWIFIEX_CHANNEL_NOHT80 = BIT(3),
+ MWIFIEX_CHANNEL_DISABLED = BIT(7),
+};
+
#define HostCmd_RET_BIT 0x8000
#define HostCmd_ACT_GEN_GET 0x0000
#define HostCmd_ACT_GEN_SET 0x0001
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 0181247..7f2fb81 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -143,6 +143,8 @@ static int mwifiex_unregister(struct mwifiex_adapter *adapter)
adapter->nd_info = NULL;
}
+ kfree(adapter->regd);
+
vfree(adapter->chan_stats);
kfree(adapter);
return 0;
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 2d32768..26df28f 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1009,6 +1009,7 @@ struct mwifiex_adapter {
bool usb_mc_status;
bool usb_mc_setup;
struct cfg80211_wowlan_nd_info *nd_info;
+ struct ieee80211_regdomain *regd;
};
void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index db85330..3344a26 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -1022,6 +1022,93 @@ static int mwifiex_ret_robust_coex(struct mwifiex_private *priv,
return 0;
}
+static struct ieee80211_regdomain *
+mwifiex_create_custom_regdomain(struct mwifiex_private *priv,
+ u8 *buf, u16 buf_len)
+{
+ u16 num_chan = buf_len / 2;
+ struct ieee80211_regdomain *regd;
+ struct ieee80211_reg_rule *rule;
+ bool new_rule;
+ int regd_size, idx, freq, prev_freq = 0;
+ u32 bw, prev_bw = 0;
+ u8 chflags, prev_chflags = 0, valid_rules = 0;
+
+ if (WARN_ON_ONCE(num_chan > NL80211_MAX_SUPP_REG_RULES))
+ return ERR_PTR(-EINVAL);
+
+ regd_size = sizeof(struct ieee80211_regdomain) +
+ num_chan * sizeof(struct ieee80211_reg_rule);
+
+ regd = kzalloc(regd_size, GFP_KERNEL);
+ if (!regd)
+ return ERR_PTR(-ENOMEM);
+
+ for (idx = 0; idx < num_chan; idx++) {
+ u8 chan;
+ enum nl80211_band band;
+
+ chan = *buf++;
+ if (!chan)
+ return NULL;
+ chflags = *buf++;
+ band = (chan <= 14) ? NL80211_BAND_2GHZ : NL80211_BAND_5GHZ;
+ freq = ieee80211_channel_to_frequency(chan, band);
+ new_rule = false;
+
+ if (chflags & MWIFIEX_CHANNEL_DISABLED)
+ continue;
+
+ if (band == NL80211_BAND_5GHZ) {
+ if (!(chflags & MWIFIEX_CHANNEL_NOHT80))
+ bw = MHZ_TO_KHZ(80);
+ else if (!(chflags & MWIFIEX_CHANNEL_NOHT40))
+ bw = MHZ_TO_KHZ(40);
+ else
+ bw = MHZ_TO_KHZ(20);
+ } else {
+ if (!(chflags & MWIFIEX_CHANNEL_NOHT40))
+ bw = MHZ_TO_KHZ(40);
+ else
+ bw = MHZ_TO_KHZ(20);
+ }
+
+ if (idx == 0 || prev_chflags != chflags || prev_bw != bw ||
+ freq - prev_freq > 20) {
+ valid_rules++;
+ new_rule = true;
+ }
+
+ rule = ®d->reg_rules[valid_rules - 1];
+
+ rule->freq_range.end_freq_khz = MHZ_TO_KHZ(freq + 10);
+
+ prev_chflags = chflags;
+ prev_freq = freq;
+ prev_bw = bw;
+
+ if (!new_rule)
+ continue;
+
+ rule->freq_range.start_freq_khz = MHZ_TO_KHZ(freq - 10);
+ rule->power_rule.max_eirp = DBM_TO_MBM(19);
+
+ if (chflags & MWIFIEX_CHANNEL_PASSIVE)
+ rule->flags = NL80211_RRF_NO_IR;
+
+ if (chflags & MWIFIEX_CHANNEL_DFS)
+ rule->flags = NL80211_RRF_DFS;
+
+ rule->freq_range.max_bandwidth_khz = bw;
+ }
+
+ regd->n_reg_rules = valid_rules;
+ regd->alpha2[0] = '9';
+ regd->alpha2[1] = '9';
+
+ return regd;
+}
+
static int mwifiex_ret_chan_region_cfg(struct mwifiex_private *priv,
struct host_cmd_ds_command *resp)
{
@@ -1050,6 +1137,10 @@ static int mwifiex_ret_chan_region_cfg(struct mwifiex_private *priv,
mwifiex_dbg_dump(priv->adapter, CMD_D, "CHAN:",
(u8 *)head + sizeof(*head),
tlv_buf_len);
+ priv->adapter->regd =
+ mwifiex_create_custom_regdomain(priv,
+ (u8 *)head +
+ sizeof(*head), tlv_buf_len);
break;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] mwifiex: add CHAN_REGION_CFG command
From: Amitkumar Karwar @ 2016-08-09 14:50 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1470754246-635-1-git-send-email-akarwar@marvell.com>
This patch adds command preparation and response handling for
CHAN_REGION_CFG command. These changes are prerequisites for adding
custom regulatory domain support.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/fw.h | 7 ++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 21 +++++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 41 ++++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index a88030a..085db99 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -190,6 +190,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define TLV_BTCOEX_WL_SCANTIME (PROPRIETARY_TLV_BASE_ID + 203)
#define TLV_TYPE_BSS_MODE (PROPRIETARY_TLV_BASE_ID + 206)
#define TLV_TYPE_RANDOM_MAC (PROPRIETARY_TLV_BASE_ID + 236)
+#define TLV_TYPE_CHAN_ATTR_CFG (PROPRIETARY_TLV_BASE_ID + 237)
#define MWIFIEX_TX_DATA_BUF_SIZE_2K 2048
@@ -382,6 +383,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define HostCmd_CMD_MC_POLICY 0x0121
#define HostCmd_CMD_TDLS_OPER 0x0122
#define HostCmd_CMD_SDIO_SP_RX_AGGR_CFG 0x0223
+#define HostCmd_CMD_CHAN_REGION_CFG 0x0242
#define PROTOCOL_NO_SECURITY 0x01
#define PROTOCOL_STATIC_WEP 0x02
@@ -2224,6 +2226,10 @@ struct host_cmd_ds_gtk_rekey_params {
__le32 replay_ctr_high;
} __packed;
+struct host_cmd_ds_chan_region_cfg {
+ __le16 action;
+} __packed;
+
struct host_cmd_ds_command {
__le16 command;
__le16 size;
@@ -2298,6 +2304,7 @@ struct host_cmd_ds_command {
struct host_cmd_ds_robust_coex coex;
struct host_cmd_ds_wakeup_reason hs_wakeup_reason;
struct host_cmd_ds_gtk_rekey_params rekey;
+ struct host_cmd_ds_chan_region_cfg reg_cfg;
} params;
} __packed;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 1d8f284..49048b4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1594,6 +1594,21 @@ static int mwifiex_cmd_gtk_rekey_offload(struct mwifiex_private *priv,
return 0;
}
+static int mwifiex_cmd_chan_region_cfg(struct mwifiex_private *priv,
+ struct host_cmd_ds_command *cmd,
+ u16 cmd_action)
+{
+ struct host_cmd_ds_chan_region_cfg *reg = &cmd->params.reg_cfg;
+
+ cmd->command = cpu_to_le16(HostCmd_CMD_CHAN_REGION_CFG);
+ cmd->size = cpu_to_le16(sizeof(*reg) + S_DS_GEN);
+
+ if (cmd_action == HostCmd_ACT_GEN_GET)
+ reg->action = cpu_to_le16(cmd_action);
+
+ return 0;
+}
+
static int
mwifiex_cmd_coalesce_cfg(struct mwifiex_private *priv,
struct host_cmd_ds_command *cmd,
@@ -2134,6 +2149,9 @@ int mwifiex_sta_prepare_cmd(struct mwifiex_private *priv, uint16_t cmd_no,
ret = mwifiex_cmd_gtk_rekey_offload(priv, cmd_ptr, cmd_action,
data_buf);
break;
+ case HostCmd_CMD_CHAN_REGION_CFG:
+ ret = mwifiex_cmd_chan_region_cfg(priv, cmd_ptr, cmd_action);
+ break;
default:
mwifiex_dbg(priv->adapter, ERROR,
"PREP_CMD: unknown cmd- %#x\n", cmd_no);
@@ -2271,6 +2289,9 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
if (ret)
return -1;
}
+
+ mwifiex_send_cmd(priv, HostCmd_CMD_CHAN_REGION_CFG,
+ HostCmd_ACT_GEN_GET, 0, NULL, true);
}
/* get tx rate */
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index 90e191b..db85330 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -1022,6 +1022,44 @@ static int mwifiex_ret_robust_coex(struct mwifiex_private *priv,
return 0;
}
+static int mwifiex_ret_chan_region_cfg(struct mwifiex_private *priv,
+ struct host_cmd_ds_command *resp)
+{
+ struct host_cmd_ds_chan_region_cfg *reg = &resp->params.reg_cfg;
+ u16 action = le16_to_cpu(reg->action);
+ u16 tlv, tlv_buf_len, tlv_buf_left;
+ struct mwifiex_ie_types_header *head;
+ u8 *tlv_buf;
+
+ if (action != HostCmd_ACT_GEN_GET)
+ return 0;
+
+ tlv_buf = (u8 *)reg + sizeof(*reg);
+ tlv_buf_left = le16_to_cpu(resp->size) - S_DS_GEN - sizeof(*reg);
+
+ while (tlv_buf_left >= sizeof(*head)) {
+ head = (struct mwifiex_ie_types_header *)tlv_buf;
+ tlv = le16_to_cpu(head->type);
+ tlv_buf_len = le16_to_cpu(head->len);
+
+ if (tlv_buf_left < (sizeof(*head) + tlv_buf_len))
+ break;
+
+ switch (tlv) {
+ case TLV_TYPE_CHAN_ATTR_CFG:
+ mwifiex_dbg_dump(priv->adapter, CMD_D, "CHAN:",
+ (u8 *)head + sizeof(*head),
+ tlv_buf_len);
+ break;
+ }
+
+ tlv_buf += (sizeof(*head) + tlv_buf_len);
+ tlv_buf_left -= (sizeof(*head) + tlv_buf_len);
+ }
+
+ return 0;
+}
+
/*
* This function handles the command responses.
*
@@ -1239,6 +1277,9 @@ int mwifiex_process_sta_cmdresp(struct mwifiex_private *priv, u16 cmdresp_no,
break;
case HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG:
break;
+ case HostCmd_CMD_CHAN_REGION_CFG:
+ ret = mwifiex_ret_chan_region_cfg(priv, resp);
+ break;
default:
mwifiex_dbg(adapter, ERROR,
"CMD_RESP: unknown cmd response %#x\n",
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] mwifiex: correct aid value during tdls setup
From: Amitkumar Karwar @ 2016-08-09 14:50 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
AID gets updated during TDLS setup, but modified value isn't reflected
in "priv->assoc_rsp_buf". This causes TDLS setup failure. The problem is
fixed here.
Fixes: 4aff53ef18e4a4 ("mwifiex: parsing aid while receiving..")
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/join.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/join.c b/drivers/net/wireless/marvell/mwifiex/join.c
index 1c7b006..b89596c 100644
--- a/drivers/net/wireless/marvell/mwifiex/join.c
+++ b/drivers/net/wireless/marvell/mwifiex/join.c
@@ -669,9 +669,8 @@ int mwifiex_ret_802_11_associate(struct mwifiex_private *priv,
priv->assoc_rsp_size = min(le16_to_cpu(resp->size) - S_DS_GEN,
sizeof(priv->assoc_rsp_buf));
- memcpy(priv->assoc_rsp_buf, &resp->params, priv->assoc_rsp_size);
-
assoc_rsp->a_id = cpu_to_le16(aid);
+ memcpy(priv->assoc_rsp_buf, &resp->params, priv->assoc_rsp_size);
if (status_code) {
priv->adapter->dbg.num_cmd_assoc_failure++;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-09 14:04 UTC (permalink / raw)
To: Theodore Ts'o, Pan, Miaoqing, Stephan Mueller,
Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo
In-Reply-To: <20160809115622.GG9515@thunk.org>
Hi Ted,
On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 06:30:03AM +0000, Pan, Miaoqing wrote:
> > Agree with Jason's point, also understand Stephan's concern. The
> > date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> > 1000', the average speed is 1111.294Kibits/s. I will sent the patch
> > to disable ath9k RNG by default.
>
> If the ATH9K is generating some random amount of data, but you don't
> know how random, and you're gathering it opportunistically --- for
> example, suppose a wireless driver gets the radio's signal strength
> through the normal course of its operation, and while there might not
> be that much randomness for someone who can observe the exact details
> of how the phone is positioned in the room --- but for which the
> analyst sitting in Fort Meade won't know whether or not the phone is
> on the desk, or in a knapsack under the table, the right interface to
> use is:
>
> void add_device_randomness(const void *buf, unsigned int size);
>
> This won't increase the entropy count, but if you have the bit of
> potential randomness "for free", you might as well contribute it to
> the entropy pool. If it turns out that the chip was manufactured in
> China, and the MSS has backdoored it out the wazoo, it won't do any
> harm --- where as using the hwrng framework would be disastrous.
Ok, I get that. However, we have Documentation/hw_random.txt saying:
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with). Data is
only output if the hardware "has-data" flag is set, but nevertheless a
security-conscious person would run fitness tests on the data before
assuming it is truly random.
Which I would read as "Don't assume 1 bit read from /dev/hwrng equals 1
bit of entropy." Which runs counter to Stephan's reading of the rngd
code.
And then we have drivers like timeriomem-rng.c that appear to be
spitting out the raw 32bit register value of $SOC's timer.
Thankfully, most hw_random drivers don't set the quality. So unless the
user sets the default_quality param, it's zero.
iiuc, Ted, you're saying using the hw_random framework would be
disasterous because despite most drivers having a default quality of 0,
rngd assumes 1 bit of entropy for every bit read?
thx,
Jason.
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Theodore Ts'o @ 2016-08-09 11:56 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Jason Cooper, Stephan Mueller, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <99963d34acea47bbacb3ca73b18fed9f@aptaiexm02f.ap.qualcomm.com>
On Tue, Aug 09, 2016 at 06:30:03AM +0000, Pan, Miaoqing wrote:
> Agree with Jason's point, also understand Stephan's concern. The
> date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> 1000', the average speed is 1111.294Kibits/s. I will sent the patch
> to disable ath9k RNG by default.
If the ATH9K is generating some random amount of data, but you don't
know how random, and you're gathering it opportunistically --- for
example, suppose a wireless driver gets the radio's signal strength
through the normal course of its operation, and while there might not
be that much randomness for someone who can observe the exact details
of how the phone is positioned in the room --- but for which the
analyst sitting in Fort Meade won't know whether or not the phone is
on the desk, or in a knapsack under the table, the right interface to
use is:
void add_device_randomness(const void *buf, unsigned int size);
This won't increase the entropy count, but if you have the bit of
potential randomness "for free", you might as well contribute it to
the entropy pool. If it turns out that the chip was manufactured in
China, and the MSS has backdoored it out the wazoo, it won't do any
harm --- where as using the hwrng framework would be disastrous.
Cheerfs,
- Ted
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Henrique de Moraes Holschuh @ 2016-08-09 10:24 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org,
Valo, Kalle, linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <11316081.S4pPZmZMrt@tauon.atsec.com>
On Tue, 09 Aug 2016, Stephan Mueller wrote:
> RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools then
> broken (at least in those large distros)?
Might I humbly suggest that the kernel start providing some metatada
about the quality of the random source that userspace can consume?
Preferably by a new ioctl, so that it will fit naturally if we ever
extend /dev/hwrng to support more than one source?
That would allow for auto tunning to be implemented in userspace...
--
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 10:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <20160809095657.GB6618@gondor.apana.org.au>
Am Dienstag, 9. August 2016, 17:56:57 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote:
> > Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > > You're supposed to tweak the quality of the input. In any case,
> >
> > How is that tweak supposed to happen? The rngd does not allow changing the
> > amount of read data relative to the assumed entropy.
>
> Hmm, I guess it depends on your distro. Some do.
>
> Cheers,
RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools then
broken (at least in those large distros)?
Ciao
Stephan
^ 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