* [RFC 2/5] ath6kl: Updated TARG_VTOP macro with default value
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
A minor modification of the TARG_VTOP macro.
The AR6004 VTOP macro is used as default (for all
chip's except AR6003)
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/target.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/target.h b/drivers/net/wireless/ath/ath6kl/target.h
index d5eeeae..c6c49b0 100644
--- a/drivers/net/wireless/ath/ath6kl/target.h
+++ b/drivers/net/wireless/ath/ath6kl/target.h
@@ -331,11 +331,11 @@ struct host_interest {
/* Convert a Target virtual address into a Target physical address */
#define AR6003_VTOP(vaddr) ((vaddr) & 0x001fffff)
-#define AR6004_VTOP(vaddr) (vaddr)
+#define DEFAULT_VTOP(vaddr) (vaddr)
#define TARG_VTOP(target_type, vaddr) \
(((target_type) == TARGET_TYPE_AR6003) ? AR6003_VTOP(vaddr) : \
- (((target_type) == TARGET_TYPE_AR6004) ? AR6004_VTOP(vaddr) : 0))
+ DEFAULT_VTOP(vaddr))
#define ATH6KL_FWLOG_PAYLOAD_SIZE 1500
--
2.1.4
^ permalink raw reply related
* [RFC 1/5] ath6kl: HTC mbox tx complete cb support
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
The current implementation always call ath6kl_tx_complete
regardless if a tx_complete callback has been associated with the
endpoint or not.
This patch fixes this by calling the associated callback in case
it is present.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 65c31da..6e8c493 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -445,7 +445,10 @@ static void htc_tx_complete(struct htc_endpoint *endpoint,
"htc tx complete ep %d pkts %d\n",
endpoint->eid, get_queue_depth(txq));
- ath6kl_tx_complete(endpoint->target, txq);
+ if (endpoint->ep_cb.tx_comp_multi)
+ endpoint->ep_cb.tx_comp_multi(endpoint->target, txq);
+ else
+ ath6kl_tx_complete(endpoint->target, txq);
}
static void htc_tx_comp_handler(struct htc_target *target,
--
2.1.4
^ permalink raw reply related
* [RFC 0/5] ath6kl: non WMI data service support
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
This patch series is intended to prepare the ath6kl driver
for newer chipsets that doesn't use the current WMI data
endpoints for data traffic.
The chipset I have been working with (and used for testing)
is QCA6584. It is SDIO based (at least the variant I have
been using) with 802.11p WAVE DSRC capabilities.
This chipset is different from the AR600X family in that
it does not use the WMI data services (service id's 0x101
to 0x104 ) for data traffic.
Instead it uses the HTT data service for data and wmi unified
for control messages.
It is also different when it comes to mailbox addresses
and HTC header format as well, but these differences are not
part of this patch series.
Erik Stromdahl (5):
ath6kl: HTC mbox tx complete cb support
ath6kl: Updated TARG_VTOP macro with default value
ath6kl: Added disable credit flow ctrl for mbox
ath6kl: Updated credit setup
ath6kl: service connect rewrite
drivers/net/wireless/ath/ath6kl/core.h | 3 +
drivers/net/wireless/ath/ath6kl/htc-ops.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc.h | 4 +-
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 75 +++++-------
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 16 +--
drivers/net/wireless/ath/ath6kl/init.c | 187 +++++++++++++++++------------
drivers/net/wireless/ath/ath6kl/target.h | 4 +-
7 files changed, 156 insertions(+), 135 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH] cfg80211: Add support to update connection parameters
From: Jouni Malinen @ 2016-10-13 15:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, vamsi krishna, Jouni Malinen
From: vamsi krishna <vamsin@qti.qualcomm.com>
Add functionality to update the connection parameters when in connected
state, so that driver/firmware uses the updated parameters for
subsequent roaming. This is for drivers that support internal BSS
selection and roaming. The new command does not change the current
association state, i.e., it can be used to update IE contents for future
(re)associations without causing an immediate disassociation or
reassociation with the current BSS.
This commit implements the required functionality for updating IEs for
(Re)Association Request frame only. Other parameters can be added in
future when required.
Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/net/cfg80211.h | 22 ++++++++++++++++++++++
include/uapi/linux/nl80211.h | 7 +++++++
net/wireless/core.h | 4 ++++
net/wireless/nl80211.c | 33 +++++++++++++++++++++++++++++++++
net/wireless/rdev-ops.h | 13 +++++++++++++
net/wireless/sme.c | 10 ++++++++++
net/wireless/trace.h | 19 +++++++++++++++++++
7 files changed, 108 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5000ec7..a4fc28a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2044,6 +2044,18 @@ struct cfg80211_connect_params {
};
/**
+ * struct cfg80211_connect_params_valid - Connection parameters to be updated
+ *
+ * This structure provides information of all connect parameters that
+ * have to be updated as part of update_connect_params() call.
+ *
+ * @assoc_ies_valid: Indicates whether association request IEs are updated
+ */
+struct cfg80211_connect_params_valid {
+ bool assoc_ies_valid;
+};
+
+/**
* enum wiphy_params_flags - set_wiphy_params bitfield values
* @WIPHY_PARAM_RETRY_SHORT: wiphy->retry_short has changed
* @WIPHY_PARAM_RETRY_LONG: wiphy->retry_long has changed
@@ -2564,6 +2576,12 @@ struct cfg80211_nan_func {
* cases, the result of roaming is indicated with a call to
* cfg80211_roamed() or cfg80211_roamed_bss().
* (invoked with the wireless_dev mutex held)
+ * @update_connect_params: Update the connect parameters while connected to a
+ * BSS. The updated parameters can be used by driver/firmware for
+ * subsequent BSS selection (roaming) decisions and to form the
+ * Authentication/(Re)Association Request frames. This call does not
+ * request an immediate disassociation or reassociation with the current
+ * BSS, i.e., this impacts only subsequence (re)associations.
* @disconnect: Disconnect from the BSS/ESS. Once done, call
* cfg80211_disconnected().
* (invoked with the wireless_dev mutex held)
@@ -2848,6 +2866,10 @@ struct cfg80211_ops {
int (*connect)(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_connect_params *sme);
+ int (*update_connect_params)(struct wiphy *wiphy,
+ struct net_device *dev,
+ struct cfg80211_connect_params *sme,
+ struct cfg80211_connect_params_valid *cpv);
int (*disconnect)(struct wiphy *wiphy, struct net_device *dev,
u16 reason_code);
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1362d24..ee85ce1 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -874,6 +874,11 @@
* This will contain a %NL80211_ATTR_NAN_MATCH nested attribute and
* %NL80211_ATTR_COOKIE.
*
+ * @NL80211_CMD_UPDATE_CONNECT_PARAMS: Update one or more connect parameters
+ * for subsequent roaming cases if the driver or firmware uses internal
+ * BSS selection. This command can be issued only while connected and it
+ * does not result in a change for the current association.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -1069,6 +1074,8 @@ enum nl80211_commands {
NL80211_CMD_CHANGE_NAN_CONFIG,
NL80211_CMD_NAN_MATCH,
+ NL80211_CMD_UPDATE_CONNECT_PARAMS,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 21e3188..7b8c8d1 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -383,6 +383,10 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
struct cfg80211_connect_params *connect,
struct cfg80211_cached_keys *connkeys,
const u8 *prev_bssid);
+int cfg80211_update_connect_params(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ struct cfg80211_connect_params *connect,
+ struct cfg80211_connect_params_valid *cpv);
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 903cd5a..a3c5f5a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8732,6 +8732,31 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
return err;
}
+static int nl80211_update_connect_params(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ struct cfg80211_connect_params connect;
+ struct cfg80211_connect_params_valid cpv;
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct net_device *dev = info->user_ptr[1];
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+
+ memset(&connect, 0, sizeof(connect));
+ memset(&cpv, 0, sizeof(cpv));
+
+ if (!wdev->current_bss)
+ return -ENOLINK;
+
+ if (info->attrs[NL80211_ATTR_IE]) {
+ if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
+ return -EINVAL;
+ connect.ie = nla_data(info->attrs[NL80211_ATTR_IE]);
+ connect.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
+ cpv.assoc_ies_valid = true;
+ }
+ return cfg80211_update_connect_params(rdev, dev, &connect, &cpv);
+}
+
static int nl80211_disconnect(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev = info->user_ptr[0];
@@ -12187,6 +12212,14 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
NL80211_FLAG_NEED_RTNL,
},
{
+ .cmd = NL80211_CMD_UPDATE_CONNECT_PARAMS,
+ .doit = nl80211_update_connect_params,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
.cmd = NL80211_CMD_DISCONNECT,
.doit = nl80211_disconnect,
.policy = nl80211_policy,
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 11cf83c..9ad3b2c 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -490,6 +490,19 @@ static inline int rdev_connect(struct cfg80211_registered_device *rdev,
return ret;
}
+static inline int
+rdev_update_connect_params(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ struct cfg80211_connect_params *sme,
+ struct cfg80211_connect_params_valid *cpv)
+{
+ int ret;
+ trace_rdev_update_connect_params(&rdev->wiphy, dev, sme, cpv);
+ ret = rdev->ops->update_connect_params(&rdev->wiphy, dev, sme, cpv);
+ trace_rdev_return_int(&rdev->wiphy, ret);
+ return ret;
+}
+
static inline int rdev_disconnect(struct cfg80211_registered_device *rdev,
struct net_device *dev, u16 reason_code)
{
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index a77db33..93106da 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1073,6 +1073,16 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
return 0;
}
+int cfg80211_update_connect_params(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ struct cfg80211_connect_params *connect,
+ struct cfg80211_connect_params_valid *cpv)
+{
+ if (rdev->ops->update_connect_params)
+ return rdev_update_connect_params(rdev, dev, connect, cpv);
+ return 0;
+}
+
int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
struct net_device *dev, u16 reason, bool wextev)
{
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index a3d0a91b..b53d72b 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -1281,6 +1281,25 @@
__entry->wpa_versions, __entry->flags, MAC_PR_ARG(prev_bssid))
);
+TRACE_EVENT(rdev_update_connect_params,
+ TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
+ struct cfg80211_connect_params *sme,
+ struct cfg80211_connect_params_valid *cpv),
+ TP_ARGS(wiphy, netdev, sme, cpv),
+ TP_STRUCT__entry(
+ WIPHY_ENTRY
+ NETDEV_ENTRY
+ __field(bool, assoc_ies_valid)
+ ),
+ TP_fast_assign(
+ WIPHY_ASSIGN;
+ NETDEV_ASSIGN;
+ __entry->assoc_ies_valid = cpv->assoc_ies_valid;
+ ),
+ TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", assoc_ies_valid: %d",
+ WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->assoc_ies_valid)
+);
+
TRACE_EVENT(rdev_set_cqm_rssi_config,
TP_PROTO(struct wiphy *wiphy,
struct net_device *netdev, s32 rssi_thold,
--
1.9.1
^ permalink raw reply related
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 15:04 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Johannes Berg, Andy Lutomirski, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <20161013150011.GA437@swordfish>
On (10/14/16 00:00), Sergey Senozhatsky wrote:
> kernel: [<ffffffff8145c405>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
> kernel: [<ffffffff81476cd8>] ieee80211_rx_handlers+0x7df/0x1c1d
> kernel: [<ffffffff814790c8>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
> kernel: [<ffffffff814792e7>] ? ieee80211_rx_napi+0x168/0x7b6
> kernel: [<ffffffff8147960a>] ieee80211_rx_napi+0x48b/0x7b6
> kernel: [<ffffffff8123729e>] ? debug_smp_processor_id+0x17/0x19
> kernel: [<ffffffffa01cfe3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
> kernel: [<ffffffffa01c9c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
> kernel: [<ffffffffa0131bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
> kernel: [<ffffffffa0133027>] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi]
> kernel: [<ffffffff810893d0>] ? irq_finalize_oneshot+0xd4/0xd4
> kernel: [<ffffffff810893ed>] irq_thread_fn+0x1d/0x34
> kernel: [<ffffffff81089661>] irq_thread+0xe6/0x1bb
> kernel: [<ffffffff810894e6>] ? wake_threads_waitq+0x2c/0x2c
> kernel: [<ffffffff8108957b>] ? irq_thread_dtor+0x95/0x95
> kernel: [<ffffffff8105d762>] kthread+0xfc/0x104
> kernel: [<ffffffff8107d36c>] ? put_lock_stats.isra.9+0xe/0x20
> kernel: [<ffffffff8105d666>] ? kthread_create_on_node+0x3f/0x3f
> kernel: [<ffffffff814b2852>] ret_from_fork+0x22/0x30
> kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d
> kernel: RIP [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
ffffffff8146d1ed <ieee80211_aes_ccm_decrypt>:
ffffffff8146d1ed: e8 9e 67 04 00 callq ffffffff814b3990 <__fentry__>
ffffffff8146d1f2: 55 push %rbp
ffffffff8146d1f3: 48 89 e5 mov %rsp,%rbp
ffffffff8146d1f6: 41 57 push %r15
ffffffff8146d1f8: 41 56 push %r14
ffffffff8146d1fa: 49 89 ce mov %rcx,%r14
ffffffff8146d1fd: 41 55 push %r13
ffffffff8146d1ff: 41 54 push %r12
ffffffff8146d201: 53 push %rbx
ffffffff8146d202: 48 83 c4 80 add $0xffffffffffffff80,%rsp
ffffffff8146d206: 8b 47 04 mov 0x4(%rdi),%eax
ffffffff8146d209: 48 8d 48 50 lea 0x50(%rax),%rcx
ffffffff8146d20d: 48 83 c0 5e add $0x5e,%rax
ffffffff8146d211: 48 c1 e8 03 shr $0x3,%rax
ffffffff8146d215: 48 c1 e0 03 shl $0x3,%rax
ffffffff8146d219: 48 29 c4 sub %rax,%rsp
ffffffff8146d21c: 4c 8d 7c 24 07 lea 0x7(%rsp),%r15
ffffffff8146d221: 49 c1 ef 03 shr $0x3,%r15
ffffffff8146d225: 4d 85 c0 test %r8,%r8
ffffffff8146d228: 4a 8d 04 fd 00 00 00 lea 0x0(,%r15,8),%rax
ffffffff8146d22f: 00
ffffffff8146d230: 48 89 85 70 ff ff ff mov %rax,-0x90(%rbp)
ffffffff8146d237: 75 0a jne ffffffff8146d243 <ieee80211_aes_ccm_decrypt+0x56>
ffffffff8146d239: b8 ea ff ff ff mov $0xffffffea,%eax
ffffffff8146d23e: e9 1a 02 00 00 jmpq ffffffff8146d45d <ieee80211_aes_ccm_decrypt+0x270>
ffffffff8146d243: 31 c0 xor %eax,%eax
ffffffff8146d245: 49 89 fc mov %rdi,%r12
ffffffff8146d248: 49 89 f5 mov %rsi,%r13
ffffffff8146d24b: 4c 89 85 58 ff ff ff mov %r8,-0xa8(%rbp)
ffffffff8146d252: 4a 8d 3c fd 00 00 00 lea 0x0(,%r15,8),%rdi
ffffffff8146d259: 00
ffffffff8146d25a: be 03 00 00 00 mov $0x3,%esi
ffffffff8146d25f: 4c 89 cb mov %r9,%rbx
ffffffff8146d262: 48 89 95 60 ff ff ff mov %rdx,-0xa0(%rbp)
ffffffff8146d269: f3 aa rep stos %al,%es:(%rdi)
ffffffff8146d26b: 48 8d 85 78 ff ff ff lea -0x88(%rbp),%rax
ffffffff8146d272: 48 89 c7 mov %rax,%rdi
ffffffff8146d275: 48 89 85 68 ff ff ff mov %rax,-0x98(%rbp)
ffffffff8146d27c: e8 46 06 dc ff callq ffffffff8122d8c7 <sg_init_table>
ffffffff8146d281: 48 8b 95 60 ff ff ff mov -0xa0(%rbp),%rdx
ffffffff8146d288: 41 b9 00 00 00 80 mov $0x80000000,%r9d
ffffffff8146d28e: 48 8b 0d 7b cd 39 00 mov 0x39cd7b(%rip),%rcx # ffffffff8180a010 <phys_base>
ffffffff8146d295: 48 8b 85 68 ff ff ff mov -0x98(%rbp),%rax
ffffffff8146d29c: 4c 8b 85 58 ff ff ff mov -0xa8(%rbp),%r8
ffffffff8146d2a3: 0f b7 32 movzwl (%rdx),%esi
ffffffff8146d2a6: 48 83 c2 02 add $0x2,%rdx
ffffffff8146d2aa: 89 d7 mov %edx,%edi
ffffffff8146d2ac: 81 e7 ff 0f 00 00 and $0xfff,%edi
ffffffff8146d2b2: 66 c1 c6 08 rol $0x8,%si
ffffffff8146d2b6: 4c 01 ca add %r9,%rdx
ffffffff8146d2b9: 0f b7 f6 movzwl %si,%esi
ffffffff8146d2bc: 72 0a jb ffffffff8146d2c8 <ieee80211_aes_ccm_decrypt+0xdb>
ffffffff8146d2be: 48 b9 00 00 00 80 ff movabs $0x77ff80000000,%rcx
ffffffff8146d2c5: 77 00 00
ffffffff8146d2c8: 48 01 ca add %rcx,%rdx
ffffffff8146d2cb: 49 89 d1 mov %rdx,%r9
ffffffff8146d2ce: 48 89 d1 mov %rdx,%rcx
ffffffff8146d2d1: 48 c1 ea 23 shr $0x23,%rdx
ffffffff8146d2d5: 48 8b 14 d5 80 23 63 mov -0x7d9cdc80(,%rdx,8),%rdx
ffffffff8146d2dc: 82
ffffffff8146d2dd: 49 c1 e9 0c shr $0xc,%r9
ffffffff8146d2e1: 48 c1 e9 1b shr $0x1b,%rcx
ffffffff8146d2e5: 48 85 d2 test %rdx,%rdx
ffffffff8146d2e8: 74 0a je ffffffff8146d2f4 <ieee80211_aes_ccm_decrypt+0x107>
ffffffff8146d2ea: 0f b6 c9 movzbl %cl,%ecx
ffffffff8146d2ed: 48 c1 e1 04 shl $0x4,%rcx
ffffffff8146d2f1: 48 01 ca add %rcx,%rdx
ffffffff8146d2f4: 48 8b 12 mov (%rdx),%rdx
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ffffffff8146d2f7: 49 c1 e1 06 shl $0x6,%r9
ffffffff8146d2fb: b9 00 00 00 80 mov $0x80000000,%ecx
ffffffff8146d300: 89 7d 80 mov %edi,-0x80(%rbp)
ffffffff8146d303: 89 75 84 mov %esi,-0x7c(%rbp)
ffffffff8146d306: 48 8b 3d 03 cd 39 00 mov 0x39cd03(%rip),%rdi # ffffffff8180a010 <phys_base>
ffffffff8146d30d: 48 83 e2 fc and $0xfffffffffffffffc,%rdx
ffffffff8146d311: 49 01 d1 add %rdx,%r9
ffffffff8146d314: 48 8b 95 78 ff ff ff mov -0x88(%rbp),%rdx
-ss
^ permalink raw reply
* [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Purushottam Kushwaha @ 2016-10-13 15:15 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This commit enhances the current beacon interval validation to also consider
the "radar_detect" and "num_different_channels".
Move calculation of GCD for all beaconing interfaces to "cfg80211_iter_combinations".
Rename "cfg80211_validate_beacon_int" to "cfg80211_validate_beacon_combination"
as the validation considers other parameters.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
include/net/cfg80211.h | 3 --
net/wireless/core.h | 7 ++--
net/wireless/mesh.c | 7 ++++
net/wireless/nl80211.c | 32 ++++++++----------
net/wireless/util.c | 91 +++++++++++++++++++++++++++++++++++++++-----------
5 files changed, 97 insertions(+), 43 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5000ec7..f5e076c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -788,15 +788,12 @@ struct cfg80211_csa_settings {
* the GCD of a single value is considered the value itself, so for
* a single interface this should be set to that interface's beacon
* interval
- * @beacon_int_different: a flag indicating whether or not all beacon
- * intervals (of beaconing interfaces) are different or not.
*/
struct iface_combination_params {
int num_different_channels;
u8 radar_detect;
int iftype_num[NUM_NL80211_IFTYPES];
u32 beacon_int_gcd;
- bool beacon_int_different;
};
/**
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 21e3188..e39c8a9 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -474,8 +474,11 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
const u8 *rates, unsigned int n_rates,
u32 *mask);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype, u32 beacon_int);
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index fa2066b..1d864b4 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -178,6 +178,13 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
NL80211_IFTYPE_MESH_POINT))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ NL80211_IFTYPE_MESH_POINT,
+ &setup->chandef,
+ setup->beacon_interval);
+ if (err)
+ return err;
+
err = rdev_join_mesh(rdev, dev, conf, setup);
if (!err) {
memcpy(wdev->ssid, setup->mesh_id, setup->mesh_id_len);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 903cd5a..eb2bfae 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3807,11 +3807,6 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
- params.beacon_interval);
- if (err)
- return err;
-
/*
* In theory, some of these attributes should be required here
* but since they were not used when the command was originally
@@ -3899,6 +3894,13 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
wdev->iftype))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ dev->ieee80211_ptr->iftype,
+ ¶ms.chandef,
+ params.beacon_interval);
+ if (err)
+ return err;
+
if (info->attrs[NL80211_ATTR_TX_RATES]) {
err = nl80211_parse_tx_bitrate_mask(info, ¶ms.beacon_rate);
if (err)
@@ -8157,11 +8159,6 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
- ibss.beacon_interval);
- if (err)
- return err;
-
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -8188,6 +8185,12 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
+ err = cfg80211_validate_beacon_combination(rdev, NL80211_IFTYPE_ADHOC,
+ &ibss.chandef,
+ ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef,
NL80211_IFTYPE_ADHOC))
return -EINVAL;
@@ -9419,17 +9422,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
nla_get_u32(info->attrs[NL80211_ATTR_MCAST_RATE])))
return -EINVAL;
- if (info->attrs[NL80211_ATTR_BEACON_INTERVAL]) {
+ if (info->attrs[NL80211_ATTR_BEACON_INTERVAL])
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev,
- NL80211_IFTYPE_MESH_POINT,
- setup.beacon_interval);
- if (err)
- return err;
- }
-
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
setup.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index d2ea1f1..eb89cb9 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1558,44 +1558,67 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
}
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype, u32 beacon_int)
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int)
{
+ int res, i;
struct wireless_dev *wdev;
+ struct ieee80211_channel *ch;
+ enum cfg80211_chan_mode chmode;
+ struct ieee80211_channel
+ *used_channels[CFG80211_MAX_NUM_DIFFERENT_CHANNELS];
struct iface_combination_params params = {
+ .num_different_channels = 1,
.beacon_int_gcd = beacon_int, /* GCD(n) = n */
};
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ used_channels[0] = chandef->chan;
params.iftype_num[iftype] = 1;
- list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
- if (!wdev->beacon_interval)
- continue;
- params.iftype_num[wdev->iftype]++;
- }
+ res = cfg80211_chandef_dfs_required(&rdev->wiphy, chandef, iftype);
+ if (res < 0)
+ return res;
+ if (res)
+ params.radar_detect = BIT(chandef->width);
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
- u32 bi_prev = wdev->beacon_interval;
-
if (!wdev->beacon_interval)
continue;
- /* slight optimisation - skip identical BIs */
- if (wdev->beacon_interval == beacon_int)
- continue;
+ mutex_lock_nested(&wdev->mtx, 1);
+ __acquire(wdev->mtx);
+ cfg80211_get_chan_state(wdev, &ch, &chmode,
+ ¶ms.radar_detect);
+ wdev_unlock(wdev);
- params.beacon_int_different = true;
+ switch (chmode) {
+ case CHAN_MODE_UNDEFINED:
+ break;
+ case CHAN_MODE_SHARED:
+ for (i = 0; i < CFG80211_MAX_NUM_DIFFERENT_CHANNELS; i++)
+ if (!used_channels[i] || used_channels[i] == ch)
+ break;
- /* Get the GCD */
- while (bi_prev != 0) {
- u32 tmp_bi = bi_prev;
+ if (i == CFG80211_MAX_NUM_DIFFERENT_CHANNELS)
+ return -EBUSY;
- bi_prev = params.beacon_int_gcd % bi_prev;
- params.beacon_int_gcd = tmp_bi;
+ if (!used_channels[i]) {
+ used_channels[i] = ch;
+ params.num_different_channels++;
+ }
+ break;
+ case CHAN_MODE_EXCLUSIVE:
+ params.num_different_channels++;
+ break;
}
+
+ params.iftype_num[wdev->iftype]++;
}
return cfg80211_check_combinations(&rdev->wiphy, ¶ms);
@@ -1612,6 +1635,35 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
int i, j, iftype;
int num_interfaces = 0;
u32 used_iftypes = 0;
+ struct wireless_dev *wdev;
+ bool beacon_int_different = false;
+
+ list_for_each_entry(wdev, &wiphy->wdev_list, list) {
+ u32 curr_bi = wdev->beacon_interval;
+
+ if (!curr_bi)
+ continue;
+
+ /* set first beacon_int as GCD if beacon_int_gcd = 0 */
+ if (!params->beacon_int_gcd) {
+ params->beacon_int_gcd = curr_bi;
+ continue;
+ }
+
+ /* slight optimisation - skip identical BIs */
+ if (curr_bi == params->beacon_int_gcd)
+ continue;
+
+ beacon_int_different = true;
+
+ /* Get the GCD */
+ while (curr_bi != 0) {
+ u32 tmp_bi = curr_bi;
+
+ curr_bi = params->beacon_int_gcd % curr_bi;
+ params->beacon_int_gcd = tmp_bi;
+ }
+ }
if (params->radar_detect) {
rcu_read_lock();
@@ -1678,8 +1730,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if (c->beacon_int_min_gcd &&
params->beacon_int_gcd < c->beacon_int_min_gcd)
return -EINVAL;
- if (!c->beacon_int_min_gcd &&
- params->beacon_int_different)
+ if (!c->beacon_int_min_gcd && beacon_int_different)
goto cont;
}
--
1.9.1
^ permalink raw reply related
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 15:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, Andy Lutomirski,
David S. Miller, Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476366354.4904.31.camel@sipsolutions.net>
On (10/13/16 15:45), Johannes Berg wrote:
> On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
> >
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> > >
> > > That truly sounds like something we'd rather avoid in the TX/RX
> > > paths though, which should perform well.
> >
> > didn't fix.
>
> It couldn't, since the new helpers weren't used in mac80211 in those
> patches yet.
indeed. I thought they were.
> > FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> > >> 39) == 130
>
> The question, though, is why precisely that fails in the crypto code.
> Can you send the Oops report itself?
kernel: BUG: unable to handle kernel NULL pointer dereference at (null)
kernel: IP: [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: PGD 0
kernel:
kernel: Oops: 0000 [#1] PREEMPT SMP
kernel: Modules linked in: nls_iso8859_1 nls_cp437 vfat fat mousedev psmouse serio_raw atkbd libps2 i915 coretemp i2c_algo_bit hwmon crc32c_intel mxm_wmi drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect iwlmvm sysimgblt fb_sys_fops i2c_i801 cfbcopyarea ie31200_edac drm iwlwifi i2c
kernel: CPU: 3 PID: 245 Comm: irq/28-iwlwifi Not tainted 4.8.0-next-20161013-dbg-00002-ge789862-dirty #112
kernel: task: ffff88041bf01800 task.stack: ffffc900002d0000
kernel: RIP: 0010:[<ffffffff8146d2f4>] [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: RSP: 0018:ffffc900002d3770 EFLAGS: 00010246
kernel: RAX: ffffc900002d3930 RBX: ffff8804133cf606 RCX: 0000000000082000
kernel: RDX: 0000000000000000 RSI: 0000000000000018 RDI: 0000000000000a02
kernel: RBP: ffffc900002d39b8 R08: 00000000000005e4 R09: 00000004100002d3
kernel: R10: 000000000000001c R11: ffff8803e66d2d20 R12: ffff8804191c2780
kernel: R13: ffffc900002d39f0 R14: ffff8804133cf022 R15: 1ffff9200005a6ee
kernel: FS: 0000000000000000(0000) GS:ffff88041ea00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 0000000001805000 CR4: 00000000001406e0
kernel: Stack:
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: Call Trace:
kernel: [<ffffffff8145c405>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
kernel: [<ffffffff81476cd8>] ieee80211_rx_handlers+0x7df/0x1c1d
kernel: [<ffffffff814790c8>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
kernel: [<ffffffff814792e7>] ? ieee80211_rx_napi+0x168/0x7b6
kernel: [<ffffffff8147960a>] ieee80211_rx_napi+0x48b/0x7b6
kernel: [<ffffffff8123729e>] ? debug_smp_processor_id+0x17/0x19
kernel: [<ffffffffa01cfe3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
kernel: [<ffffffffa01c9c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
kernel: [<ffffffffa0131bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
kernel: [<ffffffffa0133027>] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi]
kernel: [<ffffffff810893d0>] ? irq_finalize_oneshot+0xd4/0xd4
kernel: [<ffffffff810893ed>] irq_thread_fn+0x1d/0x34
kernel: [<ffffffff81089661>] irq_thread+0xe6/0x1bb
kernel: [<ffffffff810894e6>] ? wake_threads_waitq+0x2c/0x2c
kernel: [<ffffffff8108957b>] ? irq_thread_dtor+0x95/0x95
kernel: [<ffffffff8105d762>] kthread+0xfc/0x104
kernel: [<ffffffff8107d36c>] ? put_lock_stats.isra.9+0xe/0x20
kernel: [<ffffffff8105d666>] ? kthread_create_on_node+0x3f/0x3f
kernel: [<ffffffff814b2852>] ret_from_fork+0x22/0x30
kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d
kernel: RIP [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: RSP <ffffc900002d3770>
kernel: CR2: 0000000000000000
kernel: ---[ end trace 3cd1fcd496516f72 ]---
-ss
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 14:30 UTC (permalink / raw)
To: Chris Rorvick
Cc: linux-wireless, linuxwifi, emmanuel.grumbach, johannes, kvalo,
oren.givon, netdev, linux-kernel, Paul Bolle
In-Reply-To: <CAEUsAPaqyxA1=3ktisBO3Vrw9ygi7PSrk32Rw+iyHVe_WB1oyg@mail.gmail.com>
On Thu, 2016-10-13 at 08:56 -0500, Chris Rorvick wrote:
> Hi Luca,
>
> > On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> > Could you please give this a spin? I have tested it with some handmade
> > ACPI tables in QEMU and it seems to work fine now.
>
>
> Tested-by: Chris Rorvick <chris@rorvick.com>
>
> I think the debug output looks as expected, see below for the first 20
> lines or so. And, more importantly, everything seems to be working!
> :-)
Yes, you got exactly what was expected. Thanks for testing!
--
Luca.
^ permalink raw reply
* Re: [PATCH 1/3] rsi: Fix memory leak in module unload
From: Kalle Valo @ 2016-10-13 14:26 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi
In-Reply-To: <87inswcs1j.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
>
>> Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set.
>> Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in
>> function rsi_mac80211_detach()
>> Memory leak found and fixed for below structures in function rsi_mac80211_detach()
>> * channel list for each supported band
>> * rsi debugfs info
>>
>> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>
> BTW, I don't see patch 2 in patchwork nor in linux-wireless, but I do
> see it on my inbox. Either it's slow or there was a problem with the
> delivery.
It was just slow, I see it now:
https://patchwork.kernel.org/patch/9374987/
--
Kalle Valo
^ permalink raw reply
* Re: [1/2] ath9k: change entropy formula for easier understanding
From: Kalle Valo @ 2016-10-13 14:23 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
e463139a7262 ath9k: change entropy formula for easier understanding
--
https://patchwork.kernel.org/patch/9270463/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Fix kernel panic due to race in accessing arvif list
From: Kalle Valo @ 2016-10-13 14:21 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: ath10k, Vasanthakumar Thiagarajan, linux-wireless
In-Reply-To: <1476109278-7957-1-git-send-email-vthiagar@qti.qualcomm.com>
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> wrote:
> arvifs list is traversed within data_lock spin_lock in tasklet
> context to fill channel information from the corresponding vif.
> This means any access to arvifs list for add/del operations
> should also be protected with the same spin_lock to avoid the
> race. Fix this by performing list add/del on arvfis within the
> data_lock. This could fix kernel panic something like the below.
>
> LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core]
> PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core]
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [<bf4857f4>] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core])
> [<bf487540>] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core])
> [<c00312d4>] (tasklet_action+0x8c/0xec)
> [<c00309a8>] (__do_softirq+0xdc/0x208)
> [<c0030d6c>] (irq_exit+0x84/0xe0)
> [<c005db04>] (__handle_domain_irq+0x80/0xa0)
> [<c00085c4>] (gic_handle_irq+0x38/0x5c)
> [<c0009640>] (__irq_svc+0x40/0x74)
>
> (gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0)
> 0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769)
> 764 struct cfg80211_chan_def def;
> 765
> 766 lockdep_assert_held(&ar->data_lock);
> 767
> 768 list_for_each_entry(arvif, &ar->arvifs, list) {
> 769 if (arvif->vdev_id == vdev_id &&
> 770 ath10k_mac_vif_chan(arvif->vif, &def) == 0)
> 771 return def.chan;
> 772 }
> 773
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
ebaa4b1620bf ath10k: fix kernel panic due to race in accessing arvif list
--
https://patchwork.kernel.org/patch/9369573/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-13 13:45 UTC (permalink / raw)
To: Sergey Senozhatsky, Andy Lutomirski
Cc: Andy Lutomirski, David S. Miller, Linux Wireless List,
Network Development, linux-kernel@vger.kernel.org,
Sergey Senozhatsky, linux-next@vger.kernel.org, Stephen Rothwell,
Herbert Xu
In-Reply-To: <20161013134252.GA583@swordfish>
On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
>
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> >
> > That truly sounds like something we'd rather avoid in the TX/RX
> > paths though, which should perform well.
>
> didn't fix.
It couldn't, since the new helpers weren't used in mac80211 in those
patches yet.
> so I finally had some time to do a better bug-reporter job.
>
> I added a bunch of printk-s and several virt_addr_valid()-s
> to ieee80211_aes_ccm_encrypt().
>
> and right befoe the Oops I see the following report from
> virt_addr_valid()
>
>
> FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> >> 39) == 130
Yeah, we already know that in this function the aad variable is on the
stack, it explicitly is.
The question, though, is why precisely that fails in the crypto code.
Can you send the Oops report itself?
johannes
^ permalink raw reply
* Re: [PATCH v2] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Valo, Kalle @ 2016-10-13 14:06 UTC (permalink / raw)
To: Shajakhan, Mohammed Shafi (Mohammed Shafi)
Cc: ath10k@lists.infradead.org, mohammed@codeaurora.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1475596199-4563-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_htt_rx_h_unchain' needs to be called only if the return
> value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> change makes it more explicit and avoids doing a skb_peek, fetching
> rx descriptor pointer, checking rx msdu decap format for the case of
> ret =3D 0 (unchained msdus). Found this change during code walk through,
> not sure if this addresses any issue.
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Applied to ath-next, thanks.
(The SMTP server failed, needed to send this manually)
--=20
Kalle Valo=
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 13:45 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andy Lutomirski, Johannes Berg, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <20161013134252.GA583@swordfish>
On (10/13/16 22:42), Sergey Senozhatsky wrote:
>
> On (10/13/16 08:02), Johannes Berg wrote:
> > On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
> >
> > > In a pinch, I have these patches sitting around:
> > >
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> >
> > That truly sounds like something we'd rather avoid in the TX/RX paths
> > though, which should perform well.
>
> didn't fix.
>
> so I finally had some time to do a better bug-reporter job.
>
> I added a bunch of printk-s and several virt_addr_valid()-s
> to ieee80211_aes_ccm_encrypt().
>
> and right befoe the Oops I see the following report from
> virt_addr_valid()
>
>
> FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02 >> 39) == 130
that `(00004100002cba02 >> 39) == 130' part is
phys_addr_valid()
{
(addr >> boot_cpu_data.x86_phys_bits)
}
-ss
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Chris Rorvick @ 2016-10-13 13:56 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, linuxwifi, emmanuel.grumbach, johannes, kvalo,
oren.givon, netdev, linux-kernel, Paul Bolle
In-Reply-To: <1476358075.1999.5.camel@tiscali.nl>
Hi Luca,
> On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> Could you please give this a spin? I have tested it with some handmade
> ACPI tables in QEMU and it seems to work fine now.
Tested-by: Chris Rorvick <chris@rorvick.com>
I think the debug output looks as expected, see below for the first 20
lines or so. And, more importantly, everything seems to be working!
:-)
Thanks!
Chris
==========
iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
iwlwifi: module verification failed: signature and/or required key
missing - tainting kernel
Intel(R) Wireless WiFi driver for Linux
Copyright(c) 2003- 2015 Intel Corporation
iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-24.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-24.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-23.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-23.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-22.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-22.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-21.ucode'
iwlwifi 0000:3a:00.0: U iwl_req_fw_callback Loaded firmware file
'iwlwifi-8000C-21.ucode' (2394060 bytes).
iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware unknown TLV: 48
iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware GSCAN is supported but
capabilities TLV is unavailable
iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi
domain returned by the SPLC method.
iwlwifi 0000:3a:00.0: U set_dflt_pwr_limit Default power limit set to 0
iwlwifi 0000:3a:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
iwlwifi 0000:3a:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 13:42 UTC (permalink / raw)
To: Andy Lutomirski, Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476338524.4904.1.camel@sipsolutions.net>
On (10/13/16 08:02), Johannes Berg wrote:
> On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
>
> > In a pinch, I have these patches sitting around:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
>
> That truly sounds like something we'd rather avoid in the TX/RX paths
> though, which should perform well.
didn't fix.
so I finally had some time to do a better bug-reporter job.
I added a bunch of printk-s and several virt_addr_valid()-s
to ieee80211_aes_ccm_encrypt().
and right befoe the Oops I see the following report from
virt_addr_valid()
FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02 >> 39) == 130
which is basically failed '!phys_addr_valid(x)' in __virt_addr_valid()
/* carry flag will be set if starting x was >= PAGE_OFFSET */
if ((x > y) || !phys_addr_valid(x))
return false;
backtrace
------------[ cut here ]------------
WARNING: CPU: 7 PID: 246 at arch/x86/mm/physaddr.c:68 __virt_addr_valid+0xab/0xed
ffffc900002cb6f0 ffffffff8122168c 0000000000000000 0000000000000000
ffffc900002cb730 ffffffff810428d8 0000004400000198 ffff88041bd21022
ffffc900002cba02 1ffff920000596ed ffff88041932d1e0 ffffc900002cba00
Call Trace:
[<ffffffff8122168c>] dump_stack+0x4f/0x65
[<ffffffff810428d8>] __warn+0xc2/0xdd
[<ffffffff81042963>] warn_slowpath_null+0x1d/0x1f
[<ffffffff8103c226>] __virt_addr_valid+0xab/0xed
[<ffffffff8146d31a>] ieee80211_aes_ccm_decrypt+0x8f/0x2da
[<ffffffff812372de>] ? debug_smp_processor_id+0x17/0x19
[<ffffffff810fb7e1>] ? __put_page+0x3c/0x3f
[<ffffffff8145b879>] ? ccmp_special_blocks.isra.1+0x51/0x12d
[<ffffffff8145c445>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
[<ffffffff81476dd1>] ieee80211_rx_handlers+0x7df/0x1c1d
[<ffffffff814791c1>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
[<ffffffff814793cc>] ? ieee80211_rx_napi+0x154/0x7a5
[<ffffffff814796ec>] ieee80211_rx_napi+0x474/0x7a5
[<ffffffffa01fce3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
[<ffffffffa01f6c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
[<ffffffffa01c0bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
[<ffffffffa01c2015>] iwl_pcie_irq_handler+0x45d/0x64d [iwlwifi]
[<ffffffff81089411>] ? irq_finalize_oneshot+0xd4/0xd4
[<ffffffff8108942e>] irq_thread_fn+0x1d/0x34
[<ffffffff810896a2>] irq_thread+0xe6/0x1bb
[<ffffffff81089527>] ? wake_threads_waitq+0x2c/0x2c
[<ffffffff810895bc>] ? irq_thread_dtor+0x95/0x95
[<ffffffff8105d7a3>] kthread+0xfc/0x104
[<ffffffff8107d3ad>] ? put_lock_stats.isra.9+0xe/0x20
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff814b2952>] ret_from_fork+0x22/0x30
-ss
^ permalink raw reply
* Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
From: Johannes Berg @ 2016-10-13 13:12 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org, Xu, Peng
In-Reply-To: <20161004161518.GD5430@jouni.qca.qualcomm.com>
On Tue, 2016-10-04 at 16:15 +0000, Malinen, Jouni wrote:
>
> And even if the driver were to simply copy the IEs with the BSS
> membership selectors, this would only work with stations that
> implement this part correctly, i.e., the AP would not necessarily
> have any means for rejecting the association if a non-HT/VHT station
> were to try to associate.. With mac80211-drivers, this happens in
> hostapd.
Yes, that's a good point, so we'd still have to pass this information
down.
I think we'll look at adding the necessary parsing to cfg80211, and
then other drivers can pick it up as needed.
johannes
^ permalink raw reply
* Re: ath10k: fix debug cal data file
From: Kalle Valo @ 2016-10-13 13:42 UTC (permalink / raw)
To: Nikolay Martynov; +Cc: Nikolay Martynov, linux-wireless, ath10k
In-Reply-To: <1474341984-19220-1-git-send-email-mar.kolya@gmail.com>
Nikolay Martynov <mar.kolya@gmail.com> wrote:
> It got broken by 0b8e3c4ca29fe2c0efd3d41a76e34a657b9f17a4
>
> Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Actually Marty's patch fixed this in a better way so I actually took that
instead:
f67b107d4ced ath10k: cache calibration data when the core is stopped
--
https://patchwork.kernel.org/patch/9340953/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v10] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-10-13 12:30 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath
In-Reply-To: <1476277011-6937-1-git-send-email-pkushwah@qti.qualcomm.com>
On Wed, 2016-10-12 at 18:26 +0530, Purushottam Kushwaha wrote:
> This commit provides a mechanism for the host drivers to advertise
> the
> support for different beacon intervals among the respective interface
> combinations in a group, through beacon_int_min_gcd (u32).
> This beacon_int_min_gcd will be compared against GCD of all beaconing
> interfaces of matching combinations.
Applied. I made some more changes, in particular:
> @@ -3120,7 +3130,7 @@ struct ieee80211_iface_limit {
> * };
> *
> *
> - * 2. Allow #{AP, P2P-GO} <= 8, channels = 1, 8 total:
> + * 2. Allow #{AP, P2P-GO} <= 8, BI min gcd = 10, channels = 1, 8
> total:
> *
> * struct ieee80211_iface_limit limits2[] = {
> * { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
> @@ -3131,6 +3141,7 @@ struct ieee80211_iface_limit {
> * .n_limits = ARRAY_SIZE(limits2),
> * .max_interfaces = 8,
> * .num_different_channels = 1,
> + * .beacon_int_min_gcd = 10,
> * };
> *
I removed this, because it would conflict with the other documentation
changes in this area going through the doc tree. I didn't think this
was important enough in the example to break the merge later.
> list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
> if (!wdev->beacon_interval)
> continue;
> if (wdev->beacon_interval != beacon_int) {
> - res = -EINVAL;
> + params.diff_bi = true;
> + /* Get the GCD */
> + bi_prev = wdev->beacon_interval;
> + while (bi_prev != 0) {
> + tmp_bi = bi_prev;
> + bi_prev = params.beacon_gcd %
> bi_prev;
> + params.beacon_gcd = tmp_bi;
> + }
I changed that a bit, moving the variables in.
> break;
and, more importantly, I removed this break - we need to look at all
interfaces now, not break after the first one with different BI.
> }
> }
>
> - return res;
> + res = cfg80211_check_combinations(&rdev->wiphy, ¶ms);
> + return (res < 0) ? res : 0;
removed the res variable too
johannes
^ permalink raw reply
* [PATCH 2/3] rsi: Host to device command frame vap_capabilites modified with new field vap status
From: Prameela Rani Garnepudi @ 2016-10-13 11:26 UTC (permalink / raw)
To: linux-wireless
Cc: kvalo, johannes.berg, hofrat, xypron.glpk, prameela.garnepudi,
Prameela Rani Garnepudi
* Command frame vap_capabilites is modified to use for vap add, vap delete
and vap update in firmware, hence new filed vap status is added.
* When interface is down this frame needs to be send with vap status delete.
Otherwise it is considered as wrong frame for the same interface in firmware.
* vap_update status is reserved for future.
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 8 ++++++--
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 5 ++++-
drivers/net/wireless/rsi/rsi_mgmt.h | 9 ++++++++-
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 58779c0..aaca258 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -315,7 +315,9 @@ static int rsi_mac80211_add_interface(struct ieee80211_hw *hw,
if (!adapter->sc_nvifs) {
++adapter->sc_nvifs;
adapter->vifs[0] = vif;
- ret = rsi_set_vap_capabilities(common, STA_OPMODE);
+ ret = rsi_set_vap_capabilities(common,
+ STA_OPMODE,
+ VAP_ADD);
}
break;
default:
@@ -343,8 +345,10 @@ static void rsi_mac80211_remove_interface(struct ieee80211_hw *hw,
struct rsi_common *common = adapter->priv;
mutex_lock(&common->mutex);
- if (vif->type == NL80211_IFTYPE_STATION)
+ if (vif->type == NL80211_IFTYPE_STATION) {
adapter->sc_nvifs--;
+ rsi_set_vap_capabilities(common, STA_OPMODE, VAP_DELETE);
+ }
if (!memcmp(adapter->vifs[0], vif, sizeof(struct ieee80211_vif)))
adapter->vifs[0] = NULL;
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 35c14cc..30b9d44 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -617,7 +617,9 @@ static int rsi_program_bb_rf(struct rsi_common *common)
*
* Return: 0 on success, corresponding negative error code on failure.
*/
-int rsi_set_vap_capabilities(struct rsi_common *common, enum opmode mode)
+int rsi_set_vap_capabilities(struct rsi_common *common,
+ enum opmode mode,
+ u8 vap_status)
{
struct sk_buff *skb = NULL;
struct rsi_vap_caps *vap_caps;
@@ -642,6 +644,7 @@ int rsi_set_vap_capabilities(struct rsi_common *common, enum opmode mode)
FRAME_DESC_SZ) |
(RSI_WIFI_MGMT_Q << 12));
vap_caps->desc_word[1] = cpu_to_le16(VAP_CAPABILITIES);
+ vap_caps->desc_word[2] = cpu_to_le16(vap_status << 8);
vap_caps->desc_word[4] = cpu_to_le16(mode |
(common->channel_width << 8));
vap_caps->desc_word[7] = cpu_to_le16((vap_id << 8) |
diff --git a/drivers/net/wireless/rsi/rsi_mgmt.h b/drivers/net/wireless/rsi/rsi_mgmt.h
index 3741173..d155358 100644
--- a/drivers/net/wireless/rsi/rsi_mgmt.h
+++ b/drivers/net/wireless/rsi/rsi_mgmt.h
@@ -145,6 +145,12 @@ enum opmode {
AP_OPMODE = 2
};
+enum vap_status {
+ VAP_ADD = 1,
+ VAP_DELETE = 2,
+ VAP_UPDATE = 3
+};
+
extern struct ieee80211_rate rsi_rates[12];
extern const u16 rsi_mcsrates[8];
@@ -287,7 +293,8 @@ static inline u8 rsi_get_channel(u8 *addr)
}
int rsi_mgmt_pkt_recv(struct rsi_common *common, u8 *msg);
-int rsi_set_vap_capabilities(struct rsi_common *common, enum opmode mode);
+int rsi_set_vap_capabilities(struct rsi_common *common, enum opmode mode,
+ u8 vap_status);
int rsi_send_aggregation_params_frame(struct rsi_common *common, u16 tid,
u16 ssn, u8 buf_size, u8 event);
int rsi_hal_load_key(struct rsi_common *common, u8 *data, u16 key_len,
--
2.4.11
^ permalink raw reply related
* Re: [PATCH 1/3] rsi: Fix memory leak in module unload
From: Kalle Valo @ 2016-10-13 13:11 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi
In-Reply-To: <1476357946-15460-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set.
> Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in
> function rsi_mac80211_detach()
> Memory leak found and fixed for below structures in function rsi_mac80211_detach()
> * channel list for each supported band
> * rsi debugfs info
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
BTW, I don't see patch 2 in patchwork nor in linux-wireless, but I do
see it on my inbox. Either it's slow or there was a problem with the
delivery.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Paul Bolle @ 2016-10-13 12:55 UTC (permalink / raw)
To: Luca Coelho, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476362653.3880.25.camel@coelho.fi>
On Thu, 2016-10-13 at 15:44 +0300, Luca Coelho wrote:
> Even though there is apparently something wrong with this part of the
> ACPI table on you laptop, since it doesn't match our specifications.
> In any case, it's mostly harmless.
Would a correct implementation by Dell have any benefits for the users
of these laptops? In other words: should I bother somehow contacting
Dell and point them to this discussion in order to have them fix this?
Paul Bolle
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Johannes Berg @ 2016-10-13 12:52 UTC (permalink / raw)
To: Ben Greear, Pedersen, Thomas; +Cc: linux-wireless
In-Reply-To: <7cc8610d-453d-1611-6c60-581ca7b68346@candelatech.com>
> If the firmware/NIC is putting it on air at a particular encoding,
> then I think the stack should report it exactly as it is on air if
> possible.
It already does. We're only debating what bitrate to report :P
Anyway, I don't have the latest patch anymore - somebody please resend
it.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] rsi: Updated boot parameters
From: Kalle Valo @ 2016-10-13 12:45 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi
In-Reply-To: <1476358025-15576-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> * Switch clock info is divided in to different clock information fields for
> readability and synchronization with firmware code.
> * Other parameters are added for future use and to make the frame size in sync
> with latest firmware. Otherwise firmware will discard the frame considering
> corrupted frame.
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
Thanks, this is much easier to review now that the style changes are gone.
> /* structure to store configs related to UMAC clk programming */
> struct switch_clk {
> - __le16 switch_clk_info;
> + __le16 switch_umac_clk : 1; /* If set rest is valid */
> + __le16 switch_qspi_clk : 1; /* If set qspi clk will be changed */
> + __le16 switch_slp_clk_2_32 : 1;
> + __le16 switch_bbp_lmac_clk_reg : 1;
> + __le16 switch_mem_ctrl_cfg : 1;
> + __le16 reserved : 11;
This immediately caugh my eye. Are you sure this works on big endian
machines? I have never seen __le16 mixed with bitfields so I'm skeptical
that this will even work, but I don't have time to really check. Anyone
else know?
Anyway, the original code used the preferred format:
- .switch_clk_info = cpu_to_le16(BIT(3)),
That is use BIT() or GENMASK()/FIELD_PREP() to create the bitmask in cpu
native format and then convert it with cpu_to_le*() family of functions.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 12:44 UTC (permalink / raw)
To: Paul Bolle, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476362194.1999.11.camel@tiscali.nl>
On Thu, 2016-10-13 at 14:36 +0200, Paul Bolle wrote:
> On Thu, 2016-10-13 at 14:30 +0300, Luca Coelho wrote:
> > I forgot to say... could you load the iwlwifi module with debug=0x01
> > (module parameter), so we can see the messages the driver is printing
> > when it doesn't find a proper structure?
>
>
> That makes a lot of noise! Here's the first 100 lines or so, that
> apparently are generated directly after modprobing iwlwifi.
>
> After these 100 lines there's a ten second gap (I guess it took me ten
> seconds to actually use the wifi). I assume you don't care about that
> part of the debug messages.
>
> Have fun!
Thanks, Paul!
Yeah, this is the "INFO" debugging level and it is a sort of fallback
bucket when there is nothing more specific. Sorry for that.
> <7>[ 767.691342] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
> <7>[ 767.691362] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
> <7>[ 767.692127] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-24.ucode'
> <7>[ 767.692322] iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi domain returned by the SPLC method.
This is the line I was looking for. :) So everything looks fine now.
Even though there is apparently something wrong with this part of the
ACPI table on you laptop, since it doesn't match our specifications.
In any case, it's mostly harmless.
Thanks for the help!
--
Cheers,
Luca.
^ 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