* [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
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 9:56 UTC (permalink / raw)
To: Stephan Mueller
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: <12791731.pG3fmEhvyp@tauon.atsec.com>
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,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 9:56 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: <20160809094656.GB6529@gondor.apana.org.au>
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.
> this is not affected by whether we whiten the result.
I understand that.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 9:46 UTC (permalink / raw)
To: Stephan Mueller
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: <1645997.7cVzaEi3NG@tauon.atsec.com>
On Tue, Aug 09, 2016 at 11:37:39AM +0200, Stephan Mueller wrote:
> 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.
You're supposed to tweak the quality of the input. In any case,
this is not affected by whether we whiten the result.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 9:37 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: <20160809091755.GA6370@gondor.apana.org.au>
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
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 9:17 UTC (permalink / raw)
To: Stephan Mueller
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: <2569442.q63FVBJjUH@tauon.atsec.com>
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.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 9:02 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: <20160809085858.GA6172@gondor.apana.org.au>
Am Dienstag, 9. August 2016, 16:58:58 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
> > Herbert, Matt, should such noise sources be added to the HW random
> > framework? The thing is that the in-kernel HW random to input_pool link
> > per default uses a more conservative entropy estimate than the user space
> > rngd. I would think that the in-kernel link would appropriate for that
> > rng. But the user space rngd tool with its default behavior is not really
> > suited here.
>
> Yes hwrng would be the best fit, with a quality of zero to be safe.
>
> Contrary to the quoted thread, there is no need to whiten the output
> /dev/hw_random. It was always meant to go through some intermediate
> processing such as rngd before it is used.
But shouldn't the default of the rngd then be adjusted a bit?
>
> Cheers,
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 8:58 UTC (permalink / raw)
To: Stephan Mueller
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: <4731753.YZZKimtrHM@tauon.atsec.com>
On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
>
> Herbert, Matt, should such noise sources be added to the HW random framework?
> The thing is that the in-kernel HW random to input_pool link per default uses
> a more conservative entropy estimate than the user space rngd. I would think
> that the in-kernel link would appropriate for that rng. But the user space
> rngd tool with its default behavior is not really suited here.
Yes hwrng would be the best fit, with a quality of zero to be safe.
Contrary to the quoted thread, there is no need to whiten the output
/dev/hw_random. It was always meant to go through some intermediate
processing such as rngd before it is used.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 8:07 UTC (permalink / raw)
To: Pan, Miaoqing, herbert, Matt Mackall
Cc: 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: <69af156ac93a4fe6ab1844dfcc35c266@aptaiexm02f.ap.qualcomm.com>
Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing:
Hi Miaoqing, Herbert, Matt,
> Hi Stephan,
>
> So your suggestion is to use HW Random framework ? Actually, which was
> done by the commit 6301566e0b2d ("ath9k: export HW random number
> generator"), but it was reverted, you can refer to
> https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html
> for more information.
I see, it is the same RNG we talked about earlier. The issue is that the
suggested rngd per default assumes one bit of entropy with every data bit.
This is not given with this noise source. This is the basis of my reply last
time.
Herbert, Matt, should such noise sources be added to the HW random framework?
The thing is that the in-kernel HW random to input_pool link per default uses
a more conservative entropy estimate than the user space rngd. I would think
that the in-kernel link would appropriate for that rng. But the user space
rngd tool with its default behavior is not really suited here.
Thanks
Stephan
^ permalink raw reply
* Re: [PATCH v4] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-08-09 7:56 UTC (permalink / raw)
To: Undekari, Sunil Dutt, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Kondabattini, Ganesh, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath, Kumar, Deepak (QCA)
In-Reply-To: <9513d3caf9354aeda408f65128b4a079@aphydexm01f.ap.qualcomm.com>
> I guess , we can extend this to mesh and IBSS as well.
I don't know what your firmware/hardware capabilities are :)
> > It seems to me that if I were to specify beacon intervals which
> > have a very small GCD, you'll run into trouble when actually
> > sending beacons.
> > Perhaps there should be a requirement on the GCD?
> Can we have this published by the host drivers through a new wiphy
> parameter , say "min_diff_beacon_interval_multiplier". This set's the
> expectation that any different beacon intervals on the wiphy shall
> be a multiple of this parameter which is advertised by the host
> driver , isn't ?
>
I'd argue that instead of having the interface combinations flag, that
nl80211 attribute could carry the GCD?
johannes
^ permalink raw reply
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-09 7:35 UTC (permalink / raw)
To: Stephan Mueller, miaoqing@codeaurora.org
Cc: Valo, Kalle, linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <4627645.oz3l49ICL3@tauon.atsec.com>
Hi Stephan,
So your suggestion is to use HW Random framework ? Actually, which was done by the commit 6301566e0b2d ("ath9k: export HW random number generator"), but it was reverted, you can refer to https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html for more information.
--
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Tuesday, August 09, 2016 3:15 PM
To: miaoqing@codeaurora.org
Cc: 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 Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoqing@codeaurora.org:
Hi Miaoqing,
> 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>
As a short term solution:
Acked-by: Stephan Mueller <smueller@chronox.de>
But as Jason outlined, there should be nothing that prevents using this code with the HW Random framework. This framework also has logic to limit the rate of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 7:14 UTC (permalink / raw)
To: miaoqing; +Cc: kvalo, linux-wireless, ath9k-devel, linux-crypto, jason, pouyans
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing@codeaurora.org>
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoqing@codeaurora.org:
Hi Miaoqing,
> 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>
As a short term solution:
Acked-by: Stephan Mueller <smueller@chronox.de>
But as Jason outlined, there should be nothing that prevents using this code
with the HW Random framework. This framework also has logic to limit the rate
of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
> config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
^ permalink raw reply
* Re: [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: H. Nikolaus Schaller @ 2016-08-09 7:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, LKML, Discussions about the Letux Kernel
In-Reply-To: <1470724641.28531.6.camel@sipsolutions.net>
> Am 09.08.2016 um 08:37 schrieb Johannes Berg <johannes@sipsolutions.net>:
>
> 2439ca0402091badb24415e1b073ba12b34ba423
Ah, nice!
Thanks,
Nikolaus
^ permalink raw reply
* [PATCH 2/2] ath9k: disable RNG by default
From: miaoqing @ 2016-08-09 7:02 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing@codeaurora.org>
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>
---
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index f68cb00..8f231c6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
- default y
+ default n
---help---
This option incorporates the ADC register output as a source of
randomness into Linux entropy pool (/dev/urandom and /dev/random)
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ath9k: change entropy formula for easier understanding
From: miaoqing @ 2016-08-09 7:02 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
From: Miaoqing Pan <miaoqing@codeaurora.org>
The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..568b1c6 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,7 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
+#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 10) >> 5) /* quality: 10/32 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{
--
1.9.1
^ permalink raw reply related
* Re: [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: Johannes Berg @ 2016-08-09 6:37 UTC (permalink / raw)
To: H. Nikolaus Schaller, linux-wireless
Cc: LKML, Discussions about the Letux Kernel
In-Reply-To: <4FEB5780-826B-49C3-81E9-D361CD12DD4A@goldelico.com>
On Mon, 2016-08-08 at 23:26 +0200, H. Nikolaus Schaller wrote:
> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
> I hope someone knows what it means.
>
> BR and thanks,
> Nikolaus
[snip]
> [ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput
> [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
> [ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from
[snip]
This is already fixed by 2439ca0402091badb24415e1b073ba12b34ba423
johannes
>
^ permalink raw reply
* Re: Wireless Workshop accepted into the 2016 Linux Kernel Summit and Linux Plumbers Conference
From: Johannes Berg @ 2016-08-09 6:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1470724262.28531.2.camel@sipsolutions.net>
On Tue, 2016-08-09 at 08:31 +0200, Johannes Berg wrote:
> Please make plans as soon as you can [...]
To clarify - I'm not asking you to book travel right now now, but be
reasonably sure that you'll be able to attend *and tell me* (or add
yourself to the wiki page), so that I can sort out the registration
situation.
johannes
^ permalink raw reply
* [PATCH v2] ath10k: fix group privacy action frame decryption for qca4019
From: Rajkumar Manoharan @ 2016-08-09 6:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
Recent commit 'mac80211: Encrypt "Group addressed privacy" action frames'
encrypts group privacy action frames. But qca99x0 family chipset delivers
broadcast/multicast management frames as encrypted and it should be
decrypted by mac80211. Setting RX_FLAG_DECRYPTED stats for those frames
is breaking mesh connection establishment.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
v2: is_broadcast_ether_addr check not needed
drivers/net/wireless/ath/ath10k/core.c | 4 ++++
drivers/net/wireless/ath/ath10k/core.h | 5 +++++
drivers/net/wireless/ath/ath10k/wmi.c | 29 ++++++++++++++++++++++++-----
3 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 0ca58cf0ffea..c4d1a5ba216e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -182,6 +182,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -205,6 +206,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -285,6 +288,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
};
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index f36c2b274ee5..7254bd3e7c82 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -765,6 +765,11 @@ struct ath10k {
size_t board_size;
size_t board_ext_size;
} fw;
+
+ /* qca99x0 family chips deliver broadcast/multicast management
+ * frames encrypted and expect software do decryption.
+ */
+ bool sw_decrypt_mcast_mgmt;
} hw_params;
/* contains the firmware images used with ATH10K_FIRMWARE_MODE_NORMAL */
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 169cd2e783eb..29b7eca071fc 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2240,6 +2240,29 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct ath10k *ar,
return 0;
}
+static bool ath10k_wmi_rx_is_decrypted(struct ath10k *ar,
+ struct ieee80211_hdr *hdr)
+{
+ if (!ieee80211_has_protected(hdr->frame_control))
+ return false;
+
+ /* FW delivers WEP Shared Auth frame with Protected Bit set and
+ * encrypted payload. However in case of PMF it delivers decrypted
+ * frames with Protected Bit set.
+ */
+ if (ieee80211_is_auth(hdr->frame_control))
+ return false;
+
+ /* qca99x0 based FW delivers broadcast or multicast management frames
+ * (ex: group privacy action frames in mesh) as encrypted payload.
+ */
+ if (is_multicast_ether_addr(ieee80211_get_DA(hdr)) &&
+ ar->hw_params.sw_decrypt_mcast_mgmt)
+ return false;
+
+ return true;
+}
+
int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_mgmt_rx_ev_arg arg = {};
@@ -2326,11 +2349,7 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
ath10k_wmi_handle_wep_reauth(ar, skb, status);
- /* FW delivers WEP Shared Auth frame with Protected Bit set and
- * encrypted payload. However in case of PMF it delivers decrypted
- * frames with Protected Bit set. */
- if (ieee80211_has_protected(hdr->frame_control) &&
- !ieee80211_is_auth(hdr->frame_control)) {
+ if (ath10k_wmi_rx_is_decrypted(ar, hdr)) {
status->flag |= RX_FLAG_DECRYPTED;
if (!ieee80211_is_action(hdr->frame_control) &&
--
2.9.2
^ permalink raw reply related
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