* [PATCH] mac80211: aggregation: Convert timers to use timer_setup()
From: Kees Cook @ 2017-10-17 20:25 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, David S. Miller, netdev, linux-kernel
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
This removes the tid mapping array and expands the tid structures to
add a pointer back to the station, along with the tid index itself.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
Resend, with linux-wireless in Cc (no idea how it got missed before)
---
net/mac80211/agg-rx.c | 41 +++++++++++++++++------------------------
net/mac80211/agg-tx.c | 42 ++++++++++++++++--------------------------
net/mac80211/sta_info.c | 8 --------
net/mac80211/sta_info.h | 12 ++++++++++--
4 files changed, 43 insertions(+), 60 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 88cc1ae935ea..63aba6dbc92a 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -151,21 +151,17 @@ EXPORT_SYMBOL(ieee80211_stop_rx_ba_session);
* After accepting the AddBA Request we activated a timer,
* resetting it after each frame that arrives from the originator.
*/
-static void sta_rx_agg_session_timer_expired(unsigned long data)
+static void sta_rx_agg_session_timer_expired(struct timer_list *t)
{
- /* not an elegant detour, but there is no choice as the timer passes
- * only one argument, and various sta_info are needed here, so init
- * flow in sta_info_create gives the TID as data, while the timer_to_id
- * array gives the sta through container_of */
- u8 *ptid = (u8 *)data;
- u8 *timer_to_id = ptid - *ptid;
- struct sta_info *sta = container_of(timer_to_id, struct sta_info,
- timer_to_tid[0]);
+ struct tid_ampdu_rx *tid_rx_timer =
+ from_timer(tid_rx_timer, t, session_timer);
+ struct sta_info *sta = tid_rx_timer->sta;
+ u16 tid = tid_rx_timer->tid;
struct tid_ampdu_rx *tid_rx;
unsigned long timeout;
rcu_read_lock();
- tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[*ptid]);
+ tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
if (!tid_rx) {
rcu_read_unlock();
return;
@@ -180,21 +176,18 @@ static void sta_rx_agg_session_timer_expired(unsigned long data)
rcu_read_unlock();
ht_dbg(sta->sdata, "RX session timer expired on %pM tid %d\n",
- sta->sta.addr, (u16)*ptid);
+ sta->sta.addr, tid);
- set_bit(*ptid, sta->ampdu_mlme.tid_rx_timer_expired);
+ set_bit(tid, sta->ampdu_mlme.tid_rx_timer_expired);
ieee80211_queue_work(&sta->local->hw, &sta->ampdu_mlme.work);
}
-static void sta_rx_agg_reorder_timer_expired(unsigned long data)
+static void sta_rx_agg_reorder_timer_expired(struct timer_list *t)
{
- u8 *ptid = (u8 *)data;
- u8 *timer_to_id = ptid - *ptid;
- struct sta_info *sta = container_of(timer_to_id, struct sta_info,
- timer_to_tid[0]);
+ struct tid_ampdu_rx *tid_rx = from_timer(tid_rx, t, reorder_timer);
rcu_read_lock();
- ieee80211_release_reorder_timeout(sta, *ptid);
+ ieee80211_release_reorder_timeout(tid_rx->sta, tid_rx->tid);
rcu_read_unlock();
}
@@ -356,14 +349,12 @@ void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
spin_lock_init(&tid_agg_rx->reorder_lock);
/* rx timer */
- setup_deferrable_timer(&tid_agg_rx->session_timer,
- sta_rx_agg_session_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_agg_rx->session_timer,
+ sta_rx_agg_session_timer_expired, TIMER_DEFERRABLE);
/* rx reorder timer */
- setup_timer(&tid_agg_rx->reorder_timer,
- sta_rx_agg_reorder_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_agg_rx->reorder_timer,
+ sta_rx_agg_reorder_timer_expired, 0);
/* prepare reordering buffer */
tid_agg_rx->reorder_buf =
@@ -399,6 +390,8 @@ void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
tid_agg_rx->auto_seq = auto_seq;
tid_agg_rx->started = false;
tid_agg_rx->reorder_buf_filtered = 0;
+ tid_agg_rx->tid = tid;
+ tid_agg_rx->sta = sta;
status = WLAN_STATUS_SUCCESS;
/* activate it for RX */
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index bef516ec47f9..dedbb1fb10e7 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -422,15 +422,12 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
* add Block Ack response will arrive from the recipient.
* If this timer expires sta_addba_resp_timer_expired will be executed.
*/
-static void sta_addba_resp_timer_expired(unsigned long data)
+static void sta_addba_resp_timer_expired(struct timer_list *t)
{
- /* not an elegant detour, but there is no choice as the timer passes
- * only one argument, and both sta_info and TID are needed, so init
- * flow in sta_info_create gives the TID as data, while the timer_to_id
- * array gives the sta through container_of */
- u16 tid = *(u8 *)data;
- struct sta_info *sta = container_of((void *)data,
- struct sta_info, timer_to_tid[tid]);
+ struct tid_ampdu_tx *tid_tx_timer =
+ from_timer(tid_tx_timer, t, addba_resp_timer);
+ struct sta_info *sta = tid_tx_timer->sta;
+ u16 tid = tid_tx_timer->tid;
struct tid_ampdu_tx *tid_tx;
/* check if the TID waits for addBA response */
@@ -525,21 +522,17 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid)
* After accepting the AddBA Response we activated a timer,
* resetting it after each frame that we send.
*/
-static void sta_tx_agg_session_timer_expired(unsigned long data)
+static void sta_tx_agg_session_timer_expired(struct timer_list *t)
{
- /* not an elegant detour, but there is no choice as the timer passes
- * only one argument, and various sta_info are needed here, so init
- * flow in sta_info_create gives the TID as data, while the timer_to_id
- * array gives the sta through container_of */
- u8 *ptid = (u8 *)data;
- u8 *timer_to_id = ptid - *ptid;
- struct sta_info *sta = container_of(timer_to_id, struct sta_info,
- timer_to_tid[0]);
+ struct tid_ampdu_tx *tid_tx_timer =
+ from_timer(tid_tx_timer, t, session_timer);
+ struct sta_info *sta = tid_tx_timer->sta;
+ u16 tid = tid_tx_timer->tid;
struct tid_ampdu_tx *tid_tx;
unsigned long timeout;
rcu_read_lock();
- tid_tx = rcu_dereference(sta->ampdu_mlme.tid_tx[*ptid]);
+ tid_tx = rcu_dereference(sta->ampdu_mlme.tid_tx[tid]);
if (!tid_tx || test_bit(HT_AGG_STATE_STOPPING, &tid_tx->state)) {
rcu_read_unlock();
return;
@@ -555,9 +548,9 @@ static void sta_tx_agg_session_timer_expired(unsigned long data)
rcu_read_unlock();
ht_dbg(sta->sdata, "tx session timer expired on %pM tid %d\n",
- sta->sta.addr, (u16)*ptid);
+ sta->sta.addr, tid);
- ieee80211_stop_tx_ba_session(&sta->sta, *ptid);
+ ieee80211_stop_tx_ba_session(&sta->sta, tid);
}
int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
@@ -672,14 +665,11 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
tid_tx->timeout = timeout;
/* response timer */
- setup_timer(&tid_tx->addba_resp_timer,
- sta_addba_resp_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_tx->addba_resp_timer, sta_addba_resp_timer_expired, 0);
/* tx timer */
- setup_deferrable_timer(&tid_tx->session_timer,
- sta_tx_agg_session_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_tx->session_timer,
+ sta_tx_agg_session_timer_expired, TIMER_DEFERRABLE);
/* assign a dialog token */
sta->ampdu_mlme.dialog_token_allocator++;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 877d35796776..b5add1464aeb 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -379,14 +379,6 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
if (sta_prepare_rate_control(local, sta, gfp))
goto free_txq;
- for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
- /*
- * timer_to_tid must be initialized with identity mapping
- * to enable session_timer's data differentiation. See
- * sta_rx_agg_session_timer_expired for usage.
- */
- sta->timer_to_tid[i] = i;
- }
for (i = 0; i < IEEE80211_NUM_ACS; i++) {
skb_queue_head_init(&sta->ps_tx_buf[i]);
skb_queue_head_init(&sta->tx_filtered[i]);
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 5c54acd10562..1b9c1e81495d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -126,6 +126,8 @@ enum ieee80211_agg_stop_reason {
AGG_STOP_DESTROY_STA,
};
+struct sta_info;
+
/**
* struct tid_ampdu_tx - TID aggregation information (Tx).
*
@@ -133,8 +135,10 @@ enum ieee80211_agg_stop_reason {
* @session_timer: check if we keep Tx-ing on the TID (by timeout value)
* @addba_resp_timer: timer for peer's response to addba request
* @pending: pending frames queue -- use sta's spinlock to protect
+ * @sta: station we are attached to
* @dialog_token: dialog token for aggregation session
* @timeout: session timeout value to be filled in ADDBA requests
+ * @tid: index in station tid list
* @state: session state (see above)
* @last_tx: jiffies of last tx activity
* @stop_initiator: initiator of a session stop
@@ -158,9 +162,11 @@ struct tid_ampdu_tx {
struct timer_list session_timer;
struct timer_list addba_resp_timer;
struct sk_buff_head pending;
+ struct sta_info *sta;
unsigned long state;
unsigned long last_tx;
u16 timeout;
+ u16 tid;
u8 dialog_token;
u8 stop_initiator;
bool tx_stop;
@@ -181,12 +187,14 @@ struct tid_ampdu_tx {
* @reorder_time: jiffies when skb was added
* @session_timer: check if peer keeps Tx-ing on the TID (by timeout value)
* @reorder_timer: releases expired frames from the reorder buffer.
+ * @sta: station we are attached to
* @last_rx: jiffies of last rx activity
* @head_seq_num: head sequence number in reordering buffer.
* @stored_mpdu_num: number of MPDUs in reordering buffer
* @ssn: Starting Sequence Number expected to be aggregated.
* @buf_size: buffer size for incoming A-MPDUs
* @timeout: reset timer value (in TUs).
+ * @tid: index in station tid list
* @rcu_head: RCU head used for freeing this struct
* @reorder_lock: serializes access to reorder buffer, see below.
* @auto_seq: used for offloaded BA sessions to automatically pick head_seq_and
@@ -208,6 +216,7 @@ struct tid_ampdu_rx {
u64 reorder_buf_filtered;
struct sk_buff_head *reorder_buf;
unsigned long *reorder_time;
+ struct sta_info *sta;
struct timer_list session_timer;
struct timer_list reorder_timer;
unsigned long last_rx;
@@ -216,6 +225,7 @@ struct tid_ampdu_rx {
u16 ssn;
u16 buf_size;
u16 timeout;
+ u16 tid;
u8 auto_seq:1,
removed:1,
started:1;
@@ -447,7 +457,6 @@ struct ieee80211_sta_rx_stats {
* plus one for non-QoS frames)
* @tid_seq: per-TID sequence numbers for sending to this STA
* @ampdu_mlme: A-MPDU state machine state
- * @timer_to_tid: identity mapping to ID timers
* @mesh: mesh STA information
* @debugfs_dir: debug filesystem directory dentry
* @dead: set to true when sta is unlinked
@@ -554,7 +563,6 @@ struct sta_info {
* Aggregation information, locked with lock.
*/
struct sta_ampdu_mlme ampdu_mlme;
- u8 timer_to_tid[IEEE80211_NUM_TIDS];
#ifdef CONFIG_MAC80211_DEBUGFS
struct dentry *debugfs_dir;
--
2.7.4
--
Kees Cook
Pixel Security
^ permalink raw reply related
* Re: After upgrading to 4.11.1, wifi driver refuses to load after being unloaded once.
From: Marc MERLIN @ 2017-10-17 21:23 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1508249157.5497.103.camel@coelho.fi>
On Tue, Oct 17, 2017 at 05:05:57PM +0300, Luca Coelho wrote:
> Hi,
>
> On Tue, 2017-10-17 at 02:44 -0700, Marc MERLIN wrote:
> > Was broken in 4.11, still broken in 4.12. This is crippling, I'm not
> > running linux so that I have to reboot it to reload an intel wireless
> > driver :-/
>
> Can you report a bug in https://bugzilla.kernel.org so it's easier to
> track this?
>
> The problem seems to be that the rootport is not leaving D3 for some
> reason when the driver is loaded again. Do you have
> CONFIG_IWLWIFI_PCIE_RTPM enabled in your .config? (you shouldn't)
I don't know how or why, but I seem to:
saruman:~# grep IWLWIFI /boot/config-4.12.10-amd64-preempt-sysrq-20170406
CONFIG_IWLWIFI=m
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLWIFI_OPMODE_MODULAR=y
# CONFIG_IWLWIFI_BCAST_FILTERING is not set
CONFIG_IWLWIFI_PCIE_RTPM=y
CONFIG_IWLWIFI_DEBUG=y
CONFIG_IWLWIFI_DEVICE_TRACING=y
I'll remove that, thanks.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
^ permalink raw reply
* Re: After upgrading to 4.11.1, wifi driver refuses to load after being unloaded once.
From: Luca Coelho @ 2017-10-17 21:34 UTC (permalink / raw)
To: Marc MERLIN; +Cc: linux-wireless, linuxwifi
In-Reply-To: <20171017212319.eranorcigrmgcpyo@merlins.org>
On Tue, 2017-10-17 at 14:23 -0700, Marc MERLIN wrote:
> On Tue, Oct 17, 2017 at 05:05:57PM +0300, Luca Coelho wrote:
> > Hi,
> >
> > On Tue, 2017-10-17 at 02:44 -0700, Marc MERLIN wrote:
> > > Was broken in 4.11, still broken in 4.12. This is crippling, I'm
> > > not
> > > running linux so that I have to reboot it to reload an intel
> > > wireless
> > > driver :-/
> >
> > Can you report a bug in https://bugzilla.kernel.org so it's easier
> > to
> > track this?
> >
> > The problem seems to be that the rootport is not leaving D3 for
> > some
> > reason when the driver is loaded again. Do you have
> > CONFIG_IWLWIFI_PCIE_RTPM enabled in your .config? (you shouldn't)
>
>
> I don't know how or why, but I seem to:
> saruman:~# grep IWLWIFI /boot/config-4.12.10-amd64-preempt-sysrq-
> 20170406
> CONFIG_IWLWIFI=m
> CONFIG_IWLWIFI_LEDS=y
> CONFIG_IWLWIFI_OPMODE_MODULAR=y
> # CONFIG_IWLWIFI_BCAST_FILTERING is not set
> CONFIG_IWLWIFI_PCIE_RTPM=y
> CONFIG_IWLWIFI_DEBUG=y
> CONFIG_IWLWIFI_DEVICE_TRACING=y
>
> I'll remove that, thanks.
Cool, I think that might help. If it doesn't, please report a bug in
buzilla. ;)
--
Cheers,
Luca.
^ permalink raw reply
* Re: using verifier to ensure a BPF program uses certain metadata?
From: Alexei Starovoitov @ 2017-10-17 22:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Daniel Borkmann, linux-wireless
In-Reply-To: <1508139524.10607.25.camel@sipsolutions.net>
On Mon, Oct 16, 2017 at 09:38:44AM +0200, Johannes Berg wrote:
> Hi,
>
> As we discussed in April already (it's really been that long...), I'd
> wanted to allow using BPF to filter wireless monitor frames, to enable
> new use cases and higher performance in monitoring. I have some code,
> at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/log/?h=bpf
bpf bits looks pretty straightforward.
attach looks fine too. I'm assuming there is some rtnl or other lock,
so multiple assigns cannot race?
It's missing query interface though.
Please add support to return prog_id.
> which implements parts of this. It's still missing the TX status path
> and perhaps associated metadata, but that part is easy.
>
> The bigger "problem" is that we're going to be adding support for
> devices that have 802.11->Ethernet conversion already in hardware, and
> in that case the notion that the filter program will get an 802.11
> header to look at is no longer right.
>
> Now, most likely for the actual in-service monitoring we'll actually
> have to reconstitute the 802.11 header on the fly (in pure monitoring
> where nothing else is active, we can just disable the conversion), but
> the filtering shouldn't really be reliant on that, since that's not the
> cheapest thing to do.
>
> The obvious idea around this is to add a metadata field (just a bit
> really), something like "is_data_ethernet", saying that it was both a
> data frame and is already converted to have an Ethernet header.
> However, since these devices don't really exist yet for the vast
> majority of people, I'm a bit afraid that we'll find later a lot of
> code simply ignoring this field and looking at the "802.11" header,
> which is then broken if it encounters an Ethernet header instead.
>
> Are there lies my question: If we added a new callback to
> bpf_verifier_ops (e.g. "post_verifier_check"), to be called after the
> normal verification, and also added a context argument to
> "is_valid_access" (*), we could easily track that this new metadata
> field is accessed, and reject programs that don't access it at all.
>
> Now, I realize that people could trivially just work around this in
> their program if they wanted, but I think most will take the reminder
> and just implement
>
> if (ctx->is_data_ethernet)
> return DROP_FRAME;
>
> instead, since mostly data frames will not be very relevant to them.
>
> What do you think?
sounds fine and considering new verifier ops after Jakub refactoring
a check that is_data_ethernet was accessed would fit nicely.
Without void** hack.
^ permalink raw reply
* [PATCH] net: mac80211: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2017-10-17 23:14 UTC (permalink / raw)
To: Johannes Berg, David S. Miller
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that in some cases I replaced "fall through on else" and
"otherwise fall through" comments with just a "fall through" comment,
which is what GCC is expecting to find.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
This code was tested by compilation only (GCC 7.2.0 was used).
Please, verify that the actual intention of the code is to fall through.
net/mac80211/cfg.c | 3 +++
net/mac80211/ht.c | 1 +
net/mac80211/iface.c | 2 +-
net/mac80211/mesh.c | 2 ++
net/mac80211/mesh_hwmp.c | 1 +
net/mac80211/mesh_plink.c | 2 +-
net/mac80211/mlme.c | 1 +
net/mac80211/offchannel.c | 4 ++--
net/mac80211/tdls.c | 1 +
net/mac80211/wme.c | 1 +
10 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a354f19..9bd8bef 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -573,10 +573,12 @@ static int ieee80211_get_key(struct wiphy *wiphy, struct net_device *dev,
case WLAN_CIPHER_SUITE_BIP_CMAC_256:
BUILD_BUG_ON(offsetof(typeof(kseq), ccmp) !=
offsetof(typeof(kseq), aes_cmac));
+ /* fall through */
case WLAN_CIPHER_SUITE_BIP_GMAC_128:
case WLAN_CIPHER_SUITE_BIP_GMAC_256:
BUILD_BUG_ON(offsetof(typeof(kseq), ccmp) !=
offsetof(typeof(kseq), aes_gmac));
+ /* fall through */
case WLAN_CIPHER_SUITE_GCMP:
case WLAN_CIPHER_SUITE_GCMP_256:
BUILD_BUG_ON(offsetof(typeof(kseq), ccmp) !=
@@ -2205,6 +2207,7 @@ static int ieee80211_scan(struct wiphy *wiphy,
* for now fall through to allow scanning only when
* beaconing hasn't been configured yet
*/
+ /* fall through */
case NL80211_IFTYPE_AP:
/*
* If the scan has been forced (and the driver supports
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index 41f5e48..e55dabf 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -491,6 +491,7 @@ int ieee80211_send_smps_action(struct ieee80211_sub_if_data *sdata,
case IEEE80211_SMPS_AUTOMATIC:
case IEEE80211_SMPS_NUM_MODES:
WARN_ON(1);
+ /* fall through */
case IEEE80211_SMPS_OFF:
action_frame->u.action.u.ht_smps.smps_control =
WLAN_HT_SMPS_CONTROL_DISABLED;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 13b16f9..435e735 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1633,7 +1633,7 @@ static void ieee80211_assign_perm_addr(struct ieee80211_local *local,
goto out_unlock;
}
}
- /* otherwise fall through */
+ /* fall through */
default:
/* assign a new address if possible -- try n_addresses first */
for (i = 0; i < local->hw.wiphy->n_addresses; i++) {
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 7a76c4a..d29a545 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -988,8 +988,10 @@ ieee80211_mesh_process_chnswitch(struct ieee80211_sub_if_data *sdata,
switch (sdata->vif.bss_conf.chandef.width) {
case NL80211_CHAN_WIDTH_20_NOHT:
sta_flags |= IEEE80211_STA_DISABLE_HT;
+ /* fall through */
case NL80211_CHAN_WIDTH_20:
sta_flags |= IEEE80211_STA_DISABLE_40MHZ;
+ /* fall through */
case NL80211_CHAN_WIDTH_40:
sta_flags |= IEEE80211_STA_DISABLE_VHT;
break;
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 146ec6c..0e75abf 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1247,6 +1247,7 @@ void mesh_path_tx_root_frame(struct ieee80211_sub_if_data *sdata)
break;
case IEEE80211_PROACTIVE_PREQ_WITH_PREP:
flags |= IEEE80211_PREQ_PROACTIVE_PREP_FLAG;
+ /* fall through */
case IEEE80211_PROACTIVE_PREQ_NO_PREP:
interval = ifmsh->mshcfg.dot11MeshHWMPactivePathToRootTimeout;
target_flags |= IEEE80211_PREQ_TO_FLAG |
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index e2d00cc..0f6c9ca 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -672,7 +672,7 @@ void mesh_plink_timer(struct timer_list *t)
break;
}
reason = WLAN_REASON_MESH_MAX_RETRIES;
- /* fall through on else */
+ /* fall through */
case NL80211_PLINK_CNF_RCVD:
/* confirm timer */
if (!reason)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index e4ededa..f5f300fc4 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -473,6 +473,7 @@ static void ieee80211_add_ht_ie(struct ieee80211_sub_if_data *sdata,
case IEEE80211_SMPS_AUTOMATIC:
case IEEE80211_SMPS_NUM_MODES:
WARN_ON(1);
+ /* fall through */
case IEEE80211_SMPS_OFF:
cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
IEEE80211_HT_CAP_SM_PS_SHIFT;
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index faf4f60..f1d40b6 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -801,14 +801,14 @@ int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
case NL80211_IFTYPE_ADHOC:
if (!sdata->vif.bss_conf.ibss_joined)
need_offchan = true;
- /* fall through */
#ifdef CONFIG_MAC80211_MESH
+ /* fall through */
case NL80211_IFTYPE_MESH_POINT:
if (ieee80211_vif_is_mesh(&sdata->vif) &&
!sdata->u.mesh.mesh_id_len)
need_offchan = true;
- /* fall through */
#endif
+ /* fall through */
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_P2P_GO:
diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c
index 91093d4..96d4fb9 100644
--- a/net/mac80211/tdls.c
+++ b/net/mac80211/tdls.c
@@ -236,6 +236,7 @@ static enum ieee80211_ac_numbers ieee80211_ac_from_wmm(int ac)
switch (ac) {
default:
WARN_ON_ONCE(1);
+ /* fall through */
case 0:
return IEEE80211_AC_BE;
case 1:
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index 3e3d301..5f7c963 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -165,6 +165,7 @@ u16 ieee80211_select_queue(struct ieee80211_sub_if_data *sdata,
qos = sta->sta.wme;
break;
}
+ /* fall through */
case NL80211_IFTYPE_AP:
ra = skb->data;
break;
--
2.7.4
^ permalink raw reply related
* Re: iwlwifi crash with hostapd
From: James Cameron @ 2017-10-17 23:35 UTC (permalink / raw)
To: Mario Theodoridis; +Cc: linux-wireless
In-Reply-To: <2f83cea3-1760-1557-c0ff-0d40ab20f9e8@schmut.com>
On Tue, Oct 17, 2017 at 09:35:39PM +0200, Mario Theodoridis wrote:
> On 16.10.2017 05:37, James Cameron wrote:
> >On Sun, Oct 15, 2017 at 06:21:36PM +0200, Mario Theodoridis wrote:
> >>Thanks for the pointers, James.
> >>
> >>On 12.10.2017 23:24, James Cameron wrote:
> >>>There's a good chance this problem has been fixed already. You
> >>>are using a v4.4 kernel with many patches applied by Ubuntu. Here, we
> >>>are more concerned with the latest kernels, and v4.4 is quite old.
> >>>
> >>>Please test some of the later kernels, see
> >>>https://wiki.ubuntu.com/Kernel/MainlineBuilds
> >>>
> >>>In particular, test v4.13 or v4.14-rc4.
> >>
> >>I'm having a hard time with that, because the virtualbox-dkms build fails
> >>with the 4.13 kernel, and virtualbox unfortunately is essential.
> >
> >Is virtualbox essential for reproducing the problem, or essential for
> >your general use?
>
> It is essential for general use, like Internet connectivity.
Okay, good, that means we can ignore virtualbox, and leave that to
you.
Please test v4.13 or v4.14-rc5, ignoring virtualbox for the time being.
> >If the former, then that's interesting.
> >
> >If the latter, then you might instead test the v4.13 or v14-rc4
> >kernels for only the problem, and then revert to an older kernel after
> >testing.
> >
> >Either way, to use virtualbox-dkms with a later kernel you may be able
> >to upgrade just the virtualbox packages from a later Ubuntu release.
> >
> >See https://packages.ubuntu.com/virtualbox-dkms and
> >https://packages.ubuntu.com/virtualbox for the later versions available.
> >
> >Purpose of the test can be to help isolate the cause, not only to
> >solve your problem.
>
> Thanks for the info.
>
> >
> >[...]
> >You might also try with later firmware package.
> >See https://packages.ubuntu.com/linux-firmware
> >
> >You might also test with booting installation media in live-mode,
> >ignoring the internal disk.
>
> Ok, that was completely off the radar.
Updating linux-firmware may run different firmware on the wireless
card, and the change in behaviour may fix the problem. A gamble.
A test with later installation media is useful, because you can verify
problems with different kernels and wireless firmware without change
to configuration. You might try Ubuntu 17.10 Artful ISO.
> I ended up going the other way. I still had a 4.4.0-79-generic kernel and
> booted that. It does not have this problem.
> After checking out
> git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
> i tried to find the culprit but was not able to trace the back trace to a
> potential null pointer or some such. I got stuck at
> iwl_mvm_send_cmd_pdu_status not finding a reference to iwl_mvm_disable_txq
> from there.
>
> I did got the following diff though
>
> git diff Ubuntu-4.4.0-79.100 Ubuntu-4.4.0-93.116 --
> drivers/net/wireless/iwlwifi/ drivers/net/wireless/mac80211_hwsim.c >
> wifi.patch
>
> I don't know whether this came from upstream or was ubuntu sourced.
Upstream.
You found your problem was introduced in an Ubuntu kernel, in the
update from -79 to -93. This contained Ubuntu backports of two
stable kernel patches, which are also upstream patches;
8fbcfeb8a9cc ("mac80211_hwsim: Replace bogus hrtimer clockid")
from v4.4.69
50ea05efaf3b ("mac80211: pass block ack session timeout to to driver")
from v4.4.77
git log Ubuntu-4.4.0-79.100..Ubuntu-4.4.0-93.116 -- \
drivers/net/wireless/iwlwifi/ drivers/net/wireless/mac80211_hwsim.c
git remote add stable \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable
git log v4.4.68..v4.4.92 -- \
drivers/net/wireless/iwlwifi/ drivers/net/wireless/mac80211_hwsim.c
> This fixed the issue for now, but now i'm stuck on that kernel :(
Yes.
Here in upstream, we would run the latest kernel v4.13 and work to
fix that. Trouble you had with virtualbox packages would be
eventually solvable, but aren't really a problem with the kernel
itself.
So your next step may be to report an Ubuntu bug, and say that -79
worked fine, and -93 did not.
> While i'm perfectly comfortable with user land C, i have no kernel
> experience (clue stick links definitely welcome).
You might verify the above patches caused the problem by doing a
bisection between -79 and -93.
https://wiki.ubuntu.com/Kernel/KernelBisection
Or by reverting only those patches.
Then report to Ubuntu which patch caused the problem.
> [...]
Hope that helps.
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* [PATCH] ath10k: Fix offchannel tx failure when no ath10k_mac_tx_frm_has_freq
From: greearb @ 2017-10-18 0:03 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Ben Greear
From: Ben Greear <greearb@candelatech.com>
This bug appears to have been added between 4.0 (which works for us),
and 4.4, which does not work.
I think this is because the tx-offchannel logic gets in a loop when
ath10k_mac_tx_frm_has_freq(ar) is false, so pkt is never actually
sent to the firmware for transmit.
This patch fixes the problem on 4.9 for me, and now HS20 clients
can work again with my firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index c45ca04..f0a7864 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4101,7 +4101,7 @@ static int ath10k_mac_tx(struct ath10k *ar,
struct ieee80211_sta *sta,
enum ath10k_hw_txrx_mode txmode,
enum ath10k_mac_tx_path txpath,
- struct sk_buff *skb)
+ struct sk_buff *skb, bool noque_offchan)
{
struct ieee80211_hw *hw = ar->hw;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
@@ -4134,10 +4134,10 @@ static int ath10k_mac_tx(struct ath10k *ar,
}
}
- if (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN) {
+ if ((!noque_offchan) && info->flags & IEEE80211_TX_CTL_TX_OFFCHAN) {
if (!ath10k_mac_tx_frm_has_freq(ar)) {
- ath10k_dbg(ar, ATH10K_DBG_MAC, "queued offchannel skb %pK\n",
- skb);
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "no-tx-frm-has-freq: queued offchannel skb %pK, len: %d\n",
+ skb, skb->len);
skb_queue_tail(&ar->offchan_tx_queue, skb);
ieee80211_queue_work(hw, &ar->offchan_tx_work);
@@ -4198,8 +4198,8 @@ void ath10k_offchan_tx_work(struct work_struct *work)
mutex_lock(&ar->conf_mutex);
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac offchannel skb %pK\n",
- skb);
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "offchan-tx-work: mac offchannel skb %pK len: %d\n",
+ skb, skb->len);
hdr = (struct ieee80211_hdr *)skb->data;
peer_addr = ieee80211_get_DA(hdr);
@@ -4245,7 +4245,7 @@ void ath10k_offchan_tx_work(struct work_struct *work)
txmode = ath10k_mac_tx_h_get_txmode(ar, vif, sta, skb);
txpath = ath10k_mac_tx_h_get_txpath(ar, skb, txmode);
- ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+ ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb, true);
if (ret) {
ath10k_warn(ar, "failed to transmit offchannel frame: %d\n",
ret);
@@ -4255,8 +4255,8 @@ void ath10k_offchan_tx_work(struct work_struct *work)
time_left =
wait_for_completion_timeout(&ar->offchan_tx_completed, 3 * HZ);
if (time_left == 0)
- ath10k_warn(ar, "timed out waiting for offchannel skb %pK\n",
- skb);
+ ath10k_warn(ar, "timed out waiting for offchannel skb %pK, len: %d\n",
+ skb, skb->len);
if (!peer && tmp_peer_created) {
ret = ath10k_peer_delete(ar, vdev_id, peer_addr);
@@ -4513,7 +4513,7 @@ int ath10k_mac_tx_push_txq(struct ieee80211_hw *hw,
spin_unlock_bh(&ar->htt.tx_lock);
}
- ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+ ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb, false);
if (unlikely(ret)) {
ath10k_warn(ar, "failed to push frame: %d\n", ret);
@@ -4802,7 +4802,7 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
spin_unlock_bh(&ar->htt.tx_lock);
}
- ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+ ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb, false);
if (ret) {
ath10k_warn(ar, "failed to transmit frame: %d\n", ret);
if (is_htt) {
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v6 1/3] dt-bindings: net: add mt76 wireless device binding
From: Rob Herring @ 2017-10-18 2:02 UTC (permalink / raw)
To: Christian Lamparter
Cc: Felix Fietkau, linux-wireless, Kalle Valo,
devicetree@vger.kernel.org
In-Reply-To: <1589476.LyXlx7DqTg@debian64>
On Sat, Oct 14, 2017 at 10:43 AM, Christian Lamparter
<chunkeey@gmail.com> wrote:
> On Saturday, October 14, 2017 9:20:46 AM CEST Felix Fietkau wrote:
>> On 2017-10-13 21:07, Rob Herring wrote:
>> > On Fri, Oct 06, 2017 at 01:02:47PM +0200, Felix Fietkau wrote:
>> >> Add documentation describing how device tree can be used to configure
>> >> wireless chips supported by the mt76 driver.
>> >>
>> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> >> ---
>> >> .../bindings/net/wireless/mediatek,mt76.txt | 24 ++++++++++++++++++++++
>> >> 1 file changed, 24 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> >> new file mode 100644
>> >> index 000000000000..19522ab97d62
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> >> @@ -0,0 +1,24 @@
>> >> +* MediaTek mt76xx devices
>> >> +
>> >> +This node provides properties for configuring the MediaTek mt76xx wireless
>> >> +device. The node is expected to be specified as a child node of the PCI
>> >> +controller to which the wireless chip is connected.
>> >> +
>> >> +Optional properties:
>> >> +
>> >> +- mac-address: See ethernet.txt in the parent directory
>> >> +- local-mac-address: See ethernet.txt in the parent directory
>> >> +- ieee80211-freq-limit: See ieee80211.txt
>> >> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
>> >
>> > MTD is a Linuxism. And is an EEPROM the only supported device? I'd
>> > suggest naming if after what the data contains.
>> PCI cards with this kind of wireless chip usually come with some form of
>> EEPROM or use the on-chip OTP ROM.
>> This property is for the case where the chip is built into an embedded
>> device and the data that would otherwise be on an EEPROM is stored on a
>> MTD partition instead.
>> The EEPROM data itself contains multiple things: calibration data,
>> hardware capabilities, MAC address, etc.
>> I couldn't think of a better name for it, do you have any suggestions?
Naming is hard.
> This sort of reminds me of the failed ath9k nvmem patches:
> https://patchwork.kernel.org/patch/9622127/
>
> Which uses the nvmem system.
>
> https://github.com/torvalds/linux/blob/master/Documentation/nvmem/nvmem.txt
>
> Rob, would this be acceptable?
Yeah, alignment with other drivers is a good thing.
Rob
^ permalink raw reply
* Re: After upgrading to 4.11.1, wifi driver refuses to load after being unloaded once.
From: Kalle Valo @ 2017-10-18 4:59 UTC (permalink / raw)
To: Luca Coelho; +Cc: Marc MERLIN, linux-wireless, linuxwifi
In-Reply-To: <1508276099.5497.122.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> On Tue, 2017-10-17 at 14:23 -0700, Marc MERLIN wrote:
>> On Tue, Oct 17, 2017 at 05:05:57PM +0300, Luca Coelho wrote:
>> > Hi,
>> >
>> > On Tue, 2017-10-17 at 02:44 -0700, Marc MERLIN wrote:
>> > > Was broken in 4.11, still broken in 4.12. This is crippling, I'm
>> > > not
>> > > running linux so that I have to reboot it to reload an intel
>> > > wireless
>> > > driver :-/
>> >
>> > Can you report a bug in https://bugzilla.kernel.org so it's easier
>> > to
>> > track this?
>> >
>> > The problem seems to be that the rootport is not leaving D3 for
>> > some
>> > reason when the driver is loaded again. Do you have
>> > CONFIG_IWLWIFI_PCIE_RTPM enabled in your .config? (you shouldn't)
>>
>>
>> I don't know how or why, but I seem to:
>> saruman:~# grep IWLWIFI /boot/config-4.12.10-amd64-preempt-sysrq-
>> 20170406
>> CONFIG_IWLWIFI=m
>> CONFIG_IWLWIFI_LEDS=y
>> CONFIG_IWLWIFI_OPMODE_MODULAR=y
>> # CONFIG_IWLWIFI_BCAST_FILTERING is not set
>> CONFIG_IWLWIFI_PCIE_RTPM=y
>> CONFIG_IWLWIFI_DEBUG=y
>> CONFIG_IWLWIFI_DEVICE_TRACING=y
>>
>> I'll remove that, thanks.
>
> Cool, I think that might help. If it doesn't, please report a bug in
> buzilla. ;)
But a Kconfig option should never break functionality, so IMHO this
still sounds like a bug in iwlwifi.
--
Kalle Valo
^ permalink raw reply
* Re: Two rtlwifi drivers?
From: Kalle Valo @ 2017-10-18 5:33 UTC (permalink / raw)
To: Pkshih
Cc: Larry Finger, Greg Kroah-Hartman, Dan Carpenter,
莊彥宣, Johannes Berg, Souptick Joarder,
devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org
In-Reply-To: <5B2DA6FDDF928F4E855344EE0A5C39D105821780@RTITMBSV07.realtek.com.tw>
Pkshih <pkshih@realtek.com> writes:
>> My recommendation is to avoid accumulating patches at all cost and start
>> submitting them as soon as you can. This way you get patches committed
>> much more smoother. So do not wait until _all_ patches are ready,
>> instead start submitting patches as soon as you have _some_ patches
>> ready. In other words, keep the delta between mainline and your
>> not-yet-submitted patches as small as possible.
>>
>> And the patches don't need to be bug free as you can always fix bugs
>> later. Just mention in the commit logs that this is preparation for some
>> new feature and not fully tested yet. We do that all the time, for
>> example Intel's iwlwifi has support for hardware which have not reached
>> customers yet.
>>
>
> Thanks for your answer. I'll submit patches when the drivers are ready and
> stable. I have another question about the rules of new files. If I want to
> add some new files, could I send a big patch with all new files? Is there
> any limit?
The only limit I know is the byte size limit in the mailing list. When
submitting a new driver some people split the driver to one file per
patch for easier review but the final commit needs to be one big patch
with all files included. If you are adding big files to rtlwifi I think
you could try to follow the same model.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 00/58] networking: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-18 5:44 UTC (permalink / raw)
To: Kees Cook
Cc: David S. Miller, Network Development, Thomas Gleixner, LKML,
linux-wireless
In-Reply-To: <CAGXu5j+fcARk=yWh9Bbkn0C-4PHd+pKSPGV+5qPx88H6prvUoA@mail.gmail.com>
Kees Cook <keescook@chromium.org> writes:
> On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> + linux-wireless
>>
>> Hi Kees,
>>
>> Kees Cook <keescook@chromium.org> writes:
>>
>>> This is the current set of outstanding networking patches to perform
>>> conversions to the new timer interface (rebased to -next). This is not
>>> all expected conversions, but it contains everything needed in networking
>>> to eliminate init_timer(), and all the non-standard setup_*_timer() uses.
>>
>> So this also includes patches which I had queued for
>> wireless-drivers-next:
>>
>> https://patchwork.kernel.org/patch/9986253/
>> https://patchwork.kernel.org/patch/9986245/
>>
>> And looking at patchwork[1] I have even more timer_setup() related
>> patches from you. It would be really helpful if you could clearly
>> document to which tree you want the patches to be applied. I don't care
>
> Hi! Sorry about that. It's been a bit tricky to juggle everything.
Yeah, I understand.
>> if it's net-next or wireless-drivers-next as long as it's not the both
>> (meaning that both Dave and me apply the same patch, which would be
>> bad). The thing is that I really do not have time to figure out for
>> every patch via which tree it's supposed to go.
>
> Which split is preferred? I had been trying to separate wireless from
> the rest of net (but missed some cases).
So what we try to follow is that I apply all patches for
drivers/net/wireless to my wireless-drivers trees, with exception of
Johannes taking mac80211_hwsim.c patches to his mac80211 trees. And
Johannes of course takes all patches for net/wireless and net/mac80211.
So in general I prefer that I take all drivers/net/wireless patches and
make it obvious for Dave that he can ignore those patches (not mix
wireless-drivers and net patches into same set etc). But like I said,
it's ok to push API changes like these via Dave's net trees as well if
you want (and if Dave is ok with that). The chances of conflicts is low,
and if there are be any those would be easy to fix either by me or Dave.
>> For now I'll just drop all your timer_setup() related patches from my
>> queue and I'll assume Dave will take those. Ok?
>>
>> [1] https://patchwork.kernel.org/project/linux-wireless/list/
>
> I guess I'll wait to see what Dave says.
Ok, I don't drop the patches from my queue quite yet then.
--
Kalle Valo
^ permalink raw reply
* Re: After upgrading to 4.11.1, wifi driver refuses to load after being unloaded once.
From: Luca Coelho @ 2017-10-18 6:16 UTC (permalink / raw)
To: Kalle Valo; +Cc: Marc MERLIN, linux-wireless, linuxwifi
In-Reply-To: <87infduk4b.fsf@purkki.adurom.net>
On Wed, 2017-10-18 at 07:59 +0300, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
> > On Tue, 2017-10-17 at 14:23 -0700, Marc MERLIN wrote:
> > > On Tue, Oct 17, 2017 at 05:05:57PM +0300, Luca Coelho wrote:
> > > > Hi,
> > > >
> > > > On Tue, 2017-10-17 at 02:44 -0700, Marc MERLIN wrote:
> > > > > Was broken in 4.11, still broken in 4.12. This is crippling,
> > > > > I'm
> > > > > not
> > > > > running linux so that I have to reboot it to reload an intel
> > > > > wireless
> > > > > driver :-/
> > > >
> > > > Can you report a bug in https://bugzilla.kernel.org so it's
> > > > easier
> > > > to
> > > > track this?
> > > >
> > > > The problem seems to be that the rootport is not leaving D3 for
> > > > some
> > > > reason when the driver is loaded again. Do you have
> > > > CONFIG_IWLWIFI_PCIE_RTPM enabled in your .config? (you
> > > > shouldn't)
> > >
> > >
> > > I don't know how or why, but I seem to:
> > > saruman:~# grep IWLWIFI /boot/config-4.12.10-amd64-preempt-sysrq-
> > > 20170406
> > > CONFIG_IWLWIFI=m
> > > CONFIG_IWLWIFI_LEDS=y
> > > CONFIG_IWLWIFI_OPMODE_MODULAR=y
> > > # CONFIG_IWLWIFI_BCAST_FILTERING is not set
> > > CONFIG_IWLWIFI_PCIE_RTPM=y
> > > CONFIG_IWLWIFI_DEBUG=y
> > > CONFIG_IWLWIFI_DEVICE_TRACING=y
> > >
> > > I'll remove that, thanks.
> >
> > Cool, I think that might help. If it doesn't, please report a bug
> > in
> > buzilla. ;)
>
> But a Kconfig option should never break functionality, so IMHO this
> still sounds like a bug in iwlwifi.
The problem is that to get this to work, some changes need to be made
in the platform side. In this case, the rootport is not configured
properly so it won't work.
We discussed this before and that's why this option now depends on
EXPERT.
--
Luca.
^ permalink raw reply
* [PATCH v2 7/9] iwlwifi: mvm: add missing lq_color
From: Luca Coelho @ 2017-10-18 6:31 UTC (permalink / raw)
To: kvalo; +Cc: sara.sharon, linux-wireless, Liad Kaufman, Luca Coelho
In-Reply-To: <20171013132502.10473-8-luca@coelho.fi>
From: Liad Kaufman <liad.kaufman@intel.com>
In the compressed BA notif, the driver didn't parse out
the LQ color, so statistics for the rates tried were
always thrown out. Add it so it gets correctly used.
While at it, fix the name of the relevant field in the
struct.
Fixes: c46e7724bfe9 ("iwlwifi: mvm: support new BA notification response")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
In v2: a fix by Sari to properly initialize the tid_data lq_color
field to avoid a double usage of the rate scaling macro.
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 4 ++--
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 ++++++++++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
index 14ad9fb895f9..f5d5ba7e37ec 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
@@ -710,7 +710,7 @@ enum iwl_mvm_ba_resp_flags {
* @reduced_txp: power reduced according to TPC. This is the actual value and
* not a copy from the LQ command. Thus, if not the first rate was used
* for Tx-ing then this value will be set to 0 by FW.
- * @initial_rate: TLC rate info, initial rate index, TLC table color
+ * @tlc_rate_info: TLC rate info, initial rate index, TLC table color
* @retry_cnt: retry count
* @query_byte_cnt: SCD query byte count
* @query_frame_cnt: SCD query frame count
@@ -730,7 +730,7 @@ struct iwl_mvm_compressed_ba_notif {
__le32 flags;
u8 sta_id;
u8 reduced_txp;
- u8 initial_rate;
+ u8 tlc_rate_info;
u8 retry_cnt;
__le32 query_byte_cnt;
__le16 query_frame_cnt;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 172b5e63d3fb..35f455ede173 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -1746,6 +1746,7 @@ void iwl_mvm_rx_ba_notif(struct iwl_mvm *mvm, struct iwl_rx_cmd_buffer *rxb)
if (iwl_mvm_has_new_tx_api(mvm)) {
struct iwl_mvm_compressed_ba_notif *ba_res =
(void *)pkt->data;
+ u8 lq_color = TX_RES_RATE_TABLE_COL_GET(ba_res->tlc_rate_info);
int i;
sta_id = ba_res->sta_id;
@@ -1759,11 +1760,18 @@ void iwl_mvm_rx_ba_notif(struct iwl_mvm *mvm, struct iwl_rx_cmd_buffer *rxb)
if (!le16_to_cpu(ba_res->tfd_cnt))
goto out;
+ rcu_read_lock();
+
+ mvmsta = iwl_mvm_sta_from_staid_rcu(mvm, sta_id);
+ if (!mvmsta)
+ goto out_unlock;
+
/* Free per TID */
for (i = 0; i < le16_to_cpu(ba_res->tfd_cnt); i++) {
struct iwl_mvm_compressed_ba_tfd *ba_tfd =
&ba_res->tfd[i];
+ mvmsta->tid_data[i].lq_color = lq_color;
iwl_mvm_tx_reclaim(mvm, sta_id, ba_tfd->tid,
(int)(le16_to_cpu(ba_tfd->q_num)),
le16_to_cpu(ba_tfd->tfd_index),
@@ -1771,6 +1779,8 @@ void iwl_mvm_rx_ba_notif(struct iwl_mvm *mvm, struct iwl_rx_cmd_buffer *rxb)
le32_to_cpu(ba_res->tx_rate));
}
+out_unlock:
+ rcu_read_unlock();
out:
IWL_DEBUG_TX_REPLY(mvm,
"BA_NOTIFICATION Received from sta_id = %d, flags %x, sent:%d, acked:%d\n",
--
2.14.2
^ permalink raw reply related
* Re: [PATCH v6 1/3] dt-bindings: net: add mt76 wireless device binding
From: Felix Fietkau @ 2017-10-18 6:47 UTC (permalink / raw)
To: Rob Herring, Christian Lamparter
Cc: linux-wireless, Kalle Valo, devicetree@vger.kernel.org
In-Reply-To: <CAL_JsqLNhA2ZjMCKP1FJ1UG_VdMhJYfdyG6CX=3HYZ+k9_HROA@mail.gmail.com>
On 2017-10-18 04:02, Rob Herring wrote:
> On Sat, Oct 14, 2017 at 10:43 AM, Christian Lamparter
> <chunkeey@gmail.com> wrote:
>> On Saturday, October 14, 2017 9:20:46 AM CEST Felix Fietkau wrote:
>>> On 2017-10-13 21:07, Rob Herring wrote:
>>> > On Fri, Oct 06, 2017 at 01:02:47PM +0200, Felix Fietkau wrote:
>>> >> Add documentation describing how device tree can be used to configure
>>> >> wireless chips supported by the mt76 driver.
>>> >>
>>> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>> >> ---
>>> >> .../bindings/net/wireless/mediatek,mt76.txt | 24 ++++++++++++++++++++++
>>> >> 1 file changed, 24 insertions(+)
>>> >> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>>> >>
>>> >> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>>> >> new file mode 100644
>>> >> index 000000000000..19522ab97d62
>>> >> --- /dev/null
>>> >> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>>> >> @@ -0,0 +1,24 @@
>>> >> +* MediaTek mt76xx devices
>>> >> +
>>> >> +This node provides properties for configuring the MediaTek mt76xx wireless
>>> >> +device. The node is expected to be specified as a child node of the PCI
>>> >> +controller to which the wireless chip is connected.
>>> >> +
>>> >> +Optional properties:
>>> >> +
>>> >> +- mac-address: See ethernet.txt in the parent directory
>>> >> +- local-mac-address: See ethernet.txt in the parent directory
>>> >> +- ieee80211-freq-limit: See ieee80211.txt
>>> >> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
>>> >
>>> > MTD is a Linuxism. And is an EEPROM the only supported device? I'd
>>> > suggest naming if after what the data contains.
>>> PCI cards with this kind of wireless chip usually come with some form of
>>> EEPROM or use the on-chip OTP ROM.
>>> This property is for the case where the chip is built into an embedded
>>> device and the data that would otherwise be on an EEPROM is stored on a
>>> MTD partition instead.
>>> The EEPROM data itself contains multiple things: calibration data,
>>> hardware capabilities, MAC address, etc.
>>> I couldn't think of a better name for it, do you have any suggestions?
>
> Naming is hard.
>
>> This sort of reminds me of the failed ath9k nvmem patches:
>> https://patchwork.kernel.org/patch/9622127/
>>
>> Which uses the nvmem system.
>>
>> https://github.com/torvalds/linux/blob/master/Documentation/nvmem/nvmem.txt
>>
>> Rob, would this be acceptable?
>
> Yeah, alignment with other drivers is a good thing.
This depends on another round of patches which also never made it
upstream and from reading the thread[1], I'm not actually sure what's
missing, or what should be changed.
I'm also not convinced that this makes things better in any meaningful
way. It pulls in extra dependencies (nvmem subsystem), which means
more kernel bloat for embedded systems, which are currently the only
ones that even need this.
Would it be acceptable to you if I submit an updated version that fixes
the other things you pointed out?
- Felix
[1]: http://lists.infradead.org/pipermail/linux-mtd/2017-March/072541.html
^ permalink raw reply
* Re: using verifier to ensure a BPF program uses certain metadata?
From: Johannes Berg @ 2017-10-18 6:56 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, Daniel Borkmann, linux-wireless
In-Reply-To: <20171017225806.b5xubolkyocfgnjc@ast-mbp>
Hi Alexei,
> > https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
> > .git/log/?h=bpf
>
> bpf bits looks pretty straightforward.
Thanks for looking at this!
> attach looks fine too. I'm assuming there is some rtnl or other lock,
> so multiple assigns cannot race?
Yes.
> It's missing query interface though.
> Please add support to return prog_id.
Good point, this is about half a year old, so ... :)
[...]
> > Now, I realize that people could trivially just work around this in
> > their program if they wanted, but I think most will take the
> > reminder
> > and just implement
> >
> > if (ctx->is_data_ethernet)
> > return DROP_FRAME;
> >
> > instead, since mostly data frames will not be very relevant to
> > them.
> >
> > What do you think?
>
> sounds fine and considering new verifier ops after Jakub refactoring
> a check that is_data_ethernet was accessed would fit nicely.
> Without void** hack.
Ok, thanks! I'll have to check what Jakub is doing there, do you have a
pointer to that refactoring?
johannes
^ permalink raw reply
* Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"
From: Johannes Berg @ 2017-10-18 7:33 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org, ath10k, kirtika
In-Reply-To: <2c293255-aa79-75a0-1c28-994f864cddf4@candelatech.com>
Hi,
> The call to set the rate in the driver comes before the error
> check.
>
> if (ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL)) {
> ret = drv_set_bitrate_mask(local, sdata, mask);
> if (ret) {
> pr_err("%s: drv-set-bitrate-mask had error
> return: %d\n",
> sdata->dev->name, ret);
> return ret;
> }
> }
>
> /*
> * If active validate the setting and reject it if it doesn't
> leave
> * at least one basic rate usable, since we really have to be
> able
> * to send something, and if we're an AP we have to be able to
> do
> * so at a basic rate so that all clients can receive it.
> */
> if (rcu_access_pointer(sdata->vif.chanctx_conf) &&
> sdata->vif.bss_conf.chandef.chan) {
> u32 basic_rates = sdata->vif.bss_conf.basic_rates;
> enum nl80211_band band = sdata-
> >vif.bss_conf.chandef.chan->band;
>
> if (!(mask->control[band].legacy & basic_rates)) {
> #### I changed this code so I could set a
> single rate... --Ben
> pr_err("%s: WARNING: no legacy rates for
> band[%d] in set-bitrate-mask.\n",
> sdata->dev->name, band);
> }
> }
Heh, that's just dumb. I guess I'll fix that by putting the test first,
no idea how that happened.
> >
> > > So, I think we should relax this check, at least for ath10k.
> >
> > Well, yes and no. I don't think we should make ath10k special here,
> > and
> > this fixes a real problem - namely that you can set up the system
> > so
> > that you have no usable rates at all, and then you just get a
> > WARN_ON
> > and start using the lowest possible rate...
>
> Well, there are a million ways to set up a broken system,
True, but this one actually happened in practice, for some reason, and
stopping the user from constantly shooting themselves in the foot seems
like a good idea to me. Especially if the user (or application) can't
really even know what they're getting into.
Now, the case in question was _client_ mode, but still.
> and setting a single rate has a useful purpose, especially with
> ath10k since it has such limited rate-setting capabilities.
You're stretching the definition of "useful purpose" a bit here though,
you're about the only one who's ever going to need to set a single
rate.
> There is basically never going to be a case where setting a single
> tx-rate on an AP is a good idea in a general production environment,
> so maybe a possible WARN-ON is fine?
A WARN_ON() for a user configuration is never fine.
You're assuming that there's actually a user sitting there and doing
this, which is not necessarily the case.
Even rejecting a single rate setting wouldn't be enough because you can
get into problems even when you enable multiple rates, e.g. if you
enable all the CCK rates while connected on 5 GHz.
> If you *do* set up an AP with a limited rateset, then it should
> simply fail to allow a station to connect if it does not have any
> matching rates.
That's what requiring at least one basic rate to remain does. If you
want to have basic rates 6,9,12 and then configure only 18, how would
the client get rejected? Just configure basic rates differently
beforehand, and then you can do this easily, and the right thing with
rejecting clients will happen automatically (in fact, clients might not
even attempt to connect - even better!)
> This might go back to a previous idea I had (and patches I posted and
> carry in my tree) to allow setting a different advertise rateset vs
> usable tx-rateset.
You still have the same problem with which clients support them and
require them etc.
> For existing stations that might not match the new fixed rate, we
> could purposefully kick them off I guess, but seems like a lot of
> work for a case that seems pretty irrelevant.
For better or worse, there are people using this API programmatically
without a user baby-sitting it, so we need to make it work in all
cases. We can let the user shoot themselves in the foot and have only a
single usable rate left, but we can't let them hang themselves and have
no rate left at all.
johannes
^ permalink raw reply
* [PATCH] mac80211: validate user rate mask before configuring driver
From: Johannes Berg @ 2017-10-18 7:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Ben reported that when the user rate mask is rejected for not
matching any basic rate, the driver had already been configured.
This is clearly an oversight in my original change, fix this by
doing the validation before calling the driver.
Reported-by: Ben Greear <greearb@candelatech.com>
Fixes: e8e4f5280ddd ("mac80211: reject/clear user rate mask if not usable")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/cfg.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a354f1939e49..fb15d3b97cb2 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2727,12 +2727,6 @@ static int ieee80211_set_bitrate_mask(struct wiphy *wiphy,
if (!ieee80211_sdata_running(sdata))
return -ENETDOWN;
- if (ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL)) {
- ret = drv_set_bitrate_mask(local, sdata, mask);
- if (ret)
- return ret;
- }
-
/*
* If active validate the setting and reject it if it doesn't leave
* at least one basic rate usable, since we really have to be able
@@ -2748,6 +2742,12 @@ static int ieee80211_set_bitrate_mask(struct wiphy *wiphy,
return -EINVAL;
}
+ if (ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL)) {
+ ret = drv_set_bitrate_mask(local, sdata, mask);
+ if (ret)
+ return ret;
+ }
+
for (i = 0; i < NUM_NL80211_BANDS; i++) {
struct ieee80211_supported_band *sband = wiphy->bands[i];
int j;
--
2.14.2
^ permalink raw reply related
* Re: [PATCH] wil6210: disallow changing RSN in beacon change
From: Lior David @ 2017-10-18 9:25 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Maya Erez, Johannes Berg
In-Reply-To: <20171017194253.10212-1-johannes@sipsolutions.net>
Hi Johannes,
On 10/17/2017 10:42 PM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This is a code path that will never really get hit anyway, since
> it's nonsense to change the beacon of an existing BSS to suddenly
> include or no longer include the RSN IE. Reject this instead of
> having the dead code, and get rid of accessing wdev->ssid/_len by
> way of that.
>
This is not dead code, we reach it in several scenarios, mainly WPS tests.
hostapd uses change_beacon to change the security of the AP so this needs to
be supported. We do need to restart the AP in this case which will disconnect
existing clients, but this cannot be helped...
As a side note, hostapd can also use change_beacon to change the SSID. It
does so by updating the SSID IE in the probe response frame. We have a pending
patch that detects this and updates the FW but we also need to update wdev->ssid
otherwise the wireless_dev will be out of date (not sure if it will cause
any problems...)
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-10-18
From: Kalle Valo @ 2017-10-18 9:42 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this for 4.15 stream to net-next tree. Please let me know if there are
any problems.
Kalle
The following changes since commit 3e747fa18202896b5be66b88478352d5880fb8eb:
Merge ath-current from ath.git (2017-09-25 10:06:12 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2017-10-18
for you to fetch changes up to 66cc044249603e12e1dbba347f03bdbc9f171fdf:
bcma: use bcma_debug and pr_cont in MIPS driver (2017-10-17 17:22:07 +030=
0)
----------------------------------------------------------------
wireless-drivers-next patches for 4.15
The first pull request for 4.15, unusually late this time but still
relatively small. Also includes merge from wireless-drivers to fix
conflicts in iwlwifi.
Major changes:
rsi
* add P2P mode support
* sdio suspend and resume support
iwlwifi
* A fix and an addition for PCI devices for the A000 family
* Dump PCI registers when an error occurs, to make it easier to debug
rtlwifi
* add support for 64 bit DMA, enabled with a module parameter
* add module parameter to enable ASPM
----------------------------------------------------------------
Adam Borowski (1):
rtl8xxxu: Don't printk raw binary if serial number is not burned in.
Allen Pais (1):
brcmfmac: use setup_timer() helper
Andrey Konovalov (1):
p54: don't unregister leds when they are not initialized
Arnd Bergmann (2):
brcmsmac: make some local variables 'static const' to reduce stack si=
ze
rsi: fix integer overflow warning
Chaya Rachel Ivgi (2):
iwlwifi: nvm: set the correct offsets to 3168 series
iwlwifi: remove redundant reading from NVM file
Christoph B=C3=B6hmwalder (1):
iwlwifi: fix minor code style issues
Christos Gkekas (1):
rtlwifi: Remove unused cur_rfstate variables
Colin Ian King (8):
rsi: fix a dereference on adapter before it has been null checked
b43: fix unitialized reads of ret by initializing the array to zero
b43legacy: fix unitialized reads of ret by initializing the array to =
zero
mwifiex: make const arrays static to shink object code size
brcmsmac: make const array ucode_ofdm_rates static, reduces object co=
de size
mwifiex: make const array tos_to_ac static, reduces object code size
iwlegacy: make const array static to shink object code size
b43: make const arrays static, reduces object code size
Dan Carpenter (1):
rtlwifi: silence underflow warning
David Spinadel (1):
iwlwifi: mvm: Add new quota command API
Douglas Anderson (2):
mwifiex: kill useless list_empty checks
mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c
Emmanuel Grumbach (3):
iwlwifi: mvm: remove support for Link Quality Measurements
iwlwifi: mvm: support firmware debug trigger on frame reorder timeout
iwlwifi: mvm: don't send identical PHY_CTXT_CMD
Ganapathi Bhat (4):
mwifiex: notify cfg80211 about scan abort
mwifiex: check for mfg_mode in add_virtual_intf
mwifiex: avoid storing random_mac in private
mwifiex: use get_random_mask_addr() helper
Golan Ben Ami (1):
iwlwifi: stop dbgc recording before stopping DMA
Himanshu Jha (2):
mwifiex: remove unnecessary call to memset
mwifiex: Use put_unaligned_le32
Igor Mitsyanko (17):
qtnfmac: convert channel width from bitfiled to simple enum
qtnfmac: make "Channel change" event report full channel info
qtnfmac: retrieve current channel info from EP
qtnfmac: do not cache channel info from "connect" command
qtnfmac: let wifi card handle channel switch request to the same chan
qtnfmac: pass VIF info to SendChannel command
qtnfmac: do not cache CSA chandef info
qtnfmac: remove unused mac::status field
qtnfmac: do not report channel changes until wiphy is registered
qtnfmac: do not cache AP settings in driver structures
qtnfmac: pass all AP settings to wireless card for processing
qtnfmac: pass channel definition to WiFi card on START_AP command
qtnfmac: get rid of QTNF_STATE_AP_CONFIG
qtnfmac: get rid of QTNF_STATE_AP_START flag
qtnfmac: do not cache BSS state in per-VIF structure
qtnfmac: make encryption info a part of CONNECT command.
qtnfmac: do not cache current channel info in driver's state
Ilan Peer (1):
iwlwifi: Add few debug prints to the WRT dump flow
Johannes Berg (4):
iwlwifi: nvm-parse: unify channel flags printing
iwlwifi: fw: api: remove excess enum value documentation
iwlwifi: fix indentation in a000 family configuration
iwlwifi: mvm: warn on invalid statistics size
Kalle Valo (3):
Merge tag 'iwlwifi-for-kalle-2017-10-06' of git://git.kernel.org/.../=
iwlwifi/iwlwifi-fixes
Merge tag 'iwlwifi-next-for-kalle-2017-10-06-2' of git://git.kernel.o=
rg/.../iwlwifi/iwlwifi-next
Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
Karthik Ananthapadmanabha (1):
mwifiex: Random MAC address during scanning
Karun Eagalapati (1):
rsi: sdio suspend and resume support
Kevin Cernekee (3):
brcmfmac: Add check for short event packets
brcmfmac: Avoid possible out-of-bounds read
brcmfmac: Delete redundant length check
Larry Finger (4):
rtlwifi: btcoexist: 23b 1ant: fix duplicated code for different branc=
hes
rtlwifi: rtl8192ee: Fix memory leak when loading firmware
rtlwifi: rtl8821ae: Fix connection lost problem
rtlwifi: Fix typo in if ... else if ... else construct
Liad Kaufman (1):
iwlwifi: mvm: add dbgfs entry for fw info
Luca Coelho (12):
iwlwifi: mvm: return -ENODATA when reading the temperature with the F=
W down
iwlwifi: trans: move ref/unref code to the common part of the transpo=
rt
iwlwifi: acpi: add common code to read from ACPI
iwlwifi: acpi: move ACPI method definitions to acpi.h
iwlwifi: acpi: move ACPI-related definitions to acpi.h
iwlwifi: acpi: generalize iwl_mvm_sar_find_wifi_pkg()
iwlwifi: acpi: use iwl_acpi_get_wifi_pkg when reading reading SPLC
iwlwifi: acpi: make iwl_get_bios_mcc() use the common acpi functions
iwlwifi: acpi: remove a couple of unnecessary ifdefs
iwlwifi: acpi: move function to get mcc into acpi code
iwlwifi: acpi: move code that reads SPLC to acpi
iwlwifi: remove dflt_pwr_limit from the transport
Mordechay Goodstein (1):
iwlwifi: mvm: add marker cmd response struct.
Oren Givon (2):
iwlwifi: fix wrong struct for a000 device
iwlwifi: add a new a000 device
Pavani Muthyala (1):
rsi: add version information
Ping-Ke Shih (10):
rtlwifi: Fix MAX MPDU of VHT capability
rtlwifi: Remove redundant semicolon in wifi.h.
rtlwifi: rtl8192ee: Make driver support 64bits DMA.
rtlwifi: Implement rtl_get_tx_hw_rate to yield correct hw_rate
rtlwifi: Add rtl_get_hal_edca_param() to generate register's format o=
f EDCA.
rtlwifi: Add TX/RX throughput statistics in period
rtlwifi: Add RSSI and RF type to wifi.h for phydm
rtlwifi: Remove BAND_NUM and related fields
rtlwifi: Add bw_update parameter for RA mask update.
rtlwifi: Add module parameter ASPM
Prameela Rani Garnepudi (8):
rsi: add p2p support parameters to mac80211
rsi: add/remove interface enhancements for p2p
rsi: add support for p2p listen
rsi: handle peer connection and disconnection in p2p mode
rsi: tx and rx path enhancements for p2p mode
rsi: disallow power save config when AP vap running
rsi: aggregation changes for p2p mode
rsi: miscellaneous changes for p2p mode
Rafa=C5=82 Mi=C5=82ecki (1):
bcma: use bcma_debug and pr_cont in MIPS driver
Rajat Jain (1):
iwlwifi: pcie: dump registers when HW becomes inaccessible
Randy Dunlap (1):
bcma: keep *config menu together
Rohit Fule (1):
mwifiex: double the size of chan_stats array in adapter
Sara Sharon (1):
iwlwifi: mvm: change warning to warn_once()
Shahar S Matityahu (1):
iwlwifi: pcie: dynamic Tx command queue size
Shaul Triebitz (1):
iwlwifi: mvm: do not print security error in monitor mode
drivers/bcma/Kconfig | 18 +-
drivers/bcma/driver_mips.c | 7 +-
drivers/net/wireless/broadcom/b43/phy_g.c | 2 +-
drivers/net/wireless/broadcom/b43/phy_ht.c | 6 +-
drivers/net/wireless/broadcom/b43legacy/radio.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 8 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 197 +++++----
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
drivers/net/wireless/intel/iwlwifi/Makefile | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/7000.c | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 105 ++---
drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 210 ++++++++++
drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 138 +++++++
.../net/wireless/intel/iwlwifi/fw/api/binding.h | 41 +-
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 1 +
drivers/net/wireless/intel/iwlwifi/fw/api/debug.h | 9 +
.../net/wireless/intel/iwlwifi/fw/api/mac-cfg.h | 67 ----
.../net/wireless/intel/iwlwifi/fw/api/nvm-reg.h | 2 +
drivers/net/wireless/intel/iwlwifi/fw/api/power.h | 3 +-
drivers/net/wireless/intel/iwlwifi/fw/api/sta.h | 4 -
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 22 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 15 +
drivers/net/wireless/intel/iwlwifi/fw/file.h | 3 +
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 19 +-
drivers/net/wireless/intel/iwlwifi/iwl-debug.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 228 +++--------
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 17 -
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 16 +
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 16 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 16 +-
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 76 ----
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 32 ++
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 207 ++--------
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 59 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 67 ++--
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 22 +-
drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/quota.c | 59 +--
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 96 ++---
.../net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 100 +----
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 4 +
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 89 ++++
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 8 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 23 +-
drivers/net/wireless/intersil/p54/main.c | 7 +-
drivers/net/wireless/marvell/mwifiex/11n.c | 9 -
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 6 -
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 76 ++--
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 10 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/init.c | 4 -
drivers/net/wireless/marvell/mwifiex/main.h | 1 -
drivers/net/wireless/marvell/mwifiex/scan.c | 5 +-
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 6 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 6 +-
drivers/net/wireless/marvell/mwifiex/tdls.c | 7 -
drivers/net/wireless/marvell/mwifiex/wmm.c | 3 +-
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 173 ++------
drivers/net/wireless/quantenna/qtnfmac/commands.c | 215 ++++++----
drivers/net/wireless/quantenna/qtnfmac/commands.h | 6 +-
drivers/net/wireless/quantenna/qtnfmac/core.h | 30 +-
drivers/net/wireless/quantenna/qtnfmac/event.c | 48 +--
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 137 +++++--
.../net/wireless/quantenna/qtnfmac/qlink_util.c | 113 +++++-
.../net/wireless/quantenna/qtnfmac/qlink_util.h | 7 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 104 ++++-
drivers/net/wireless/realtek/rtlwifi/base.h | 4 +
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 13 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 8 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 49 ++-
drivers/net/wireless/realtek/rtlwifi/pci.h | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.h | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 40 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 9 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 49 ++-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 140 ++-----
.../net/wireless/realtek/rtlwifi/rtl8192se/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 13 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 3 +-
.../realtek/rtlwifi/rtl8723com/fw_common.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 3 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 60 +--
drivers/net/wireless/rsi/rsi_91x_core.c | 33 +-
drivers/net/wireless/rsi/rsi_91x_debugfs.c | 19 +-
drivers/net/wireless/rsi/rsi_91x_hal.c | 86 ++--
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 446 ++++++++++++++++-=
----
drivers/net/wireless/rsi/rsi_91x_main.c | 34 +-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 46 ++-
drivers/net/wireless/rsi/rsi_91x_ps.c | 15 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 128 +++++-
drivers/net/wireless/rsi/rsi_91x_usb.c | 4 +-
drivers/net/wireless/rsi/rsi_common.h | 4 +-
drivers/net/wireless/rsi/rsi_hal.h | 6 +-
drivers/net/wireless/rsi/rsi_main.h | 24 +-
drivers/net/wireless/rsi/rsi_mgmt.h | 21 +-
drivers/net/wireless/rsi/rsi_ps.h | 7 +-
drivers/net/wireless/rsi/rsi_sdio.h | 2 +
150 files changed, 2639 insertions(+), 1911 deletions(-)
create mode 100644 drivers/net/wireless/intel/iwlwifi/fw/acpi.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/fw/acpi.h
^ permalink raw reply
* Re: After upgrading to 4.11.1, wifi driver refuses to load after being unloaded once.
From: Kalle Valo @ 2017-10-18 9:50 UTC (permalink / raw)
To: Luca Coelho; +Cc: Marc MERLIN, linux-wireless, linuxwifi
In-Reply-To: <1508307368.5497.125.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> On Wed, 2017-10-18 at 07:59 +0300, Kalle Valo wrote:
>> Luca Coelho <luca@coelho.fi> writes:
>>
>> > On Tue, 2017-10-17 at 14:23 -0700, Marc MERLIN wrote:
>> >
>> > > I don't know how or why, but I seem to:
>> > > saruman:~# grep IWLWIFI /boot/config-4.12.10-amd64-preempt-sysrq-
>> > > 20170406
>> > > CONFIG_IWLWIFI=m
>> > > CONFIG_IWLWIFI_LEDS=y
>> > > CONFIG_IWLWIFI_OPMODE_MODULAR=y
>> > > # CONFIG_IWLWIFI_BCAST_FILTERING is not set
>> > > CONFIG_IWLWIFI_PCIE_RTPM=y
>> > > CONFIG_IWLWIFI_DEBUG=y
>> > > CONFIG_IWLWIFI_DEVICE_TRACING=y
>> > >
>> > > I'll remove that, thanks.
>> >
>> > Cool, I think that might help. If it doesn't, please report a bug
>> > in
>> > buzilla. ;)
>>
>> But a Kconfig option should never break functionality, so IMHO this
>> still sounds like a bug in iwlwifi.
>
> The problem is that to get this to work, some changes need to be made
> in the platform side. In this case, the rootport is not configured
> properly so it won't work.
Yeah, but users or distros might accidentally enable this Kconfig
option and break the driver unintentionally. And subtle bugs like this
are even worse as the user will not realise that it's because of a new
Kconfig option.
So I guess you can't automatically detect it the platform supports RTPM,
right? Maybe there should be a module parameter which has to be set to
enable this? And at least a big fat warning to the user that RTPM is
enabled, bugs are likely and the user has to know what she's doing.
> We discussed this before and that's why this option now depends on
> EXPERT.
Heh, we did? I have no recollection of whatsoever about that :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] wil6210: disallow changing RSN in beacon change
From: Johannes Berg @ 2017-10-18 10:13 UTC (permalink / raw)
To: Lior David, linux-wireless; +Cc: Maya Erez, Jouni Malinen
In-Reply-To: <18712cc3-3c69-ff9a-e64b-a988463d1965@codeaurora.org>
Hi,
> This is not dead code, we reach it in several scenarios, mainly WPS
> tests.
Interesting.
> hostapd uses change_beacon to change the security of the AP so this
> needs to be supported.
I didn't think this made sense - Jouni? Does hostapd kick off all
stations in this case?
> We do need to restart the AP in this case which will
> disconnect existing clients, but this cannot be helped...
Why not restart the AP entirely then from userspace? Hmm. I wonder what
would happen with mac80211 - I guess keys would have to removed etc?
Does this just work by accident because mac80211 removes the keys with
stations? What about GTK(s) though?
> As a side note, hostapd can also use change_beacon to change the
> SSID.
When does that happen?
> It does so by updating the SSID IE in the probe response frame. We
> have a pending patch that detects this and updates the FW but we also
> need to update wdev->ssid otherwise the wireless_dev will be out of
> date (not sure if it will cause any problems...)
Logic-wise it won't, but we do expose this to userspace and that'd be
confusing, so we have to update it I guess.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: use constant time comparison with keys
From: Johannes Berg @ 2017-10-18 10:17 UTC (permalink / raw)
To: Jason A. Donenfeld, David Miller, netdev, linux-wireless
In-Reply-To: <20171017183207.23124-1-Jason@zx2c4.com>
On Tue, 2017-10-17 at 20:32 +0200, Jason A. Donenfeld wrote:
> Otherwise we risk leaking information via timing side channel.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] fq_impl: Properly enforce memory limit
From: Johannes Berg @ 2017-10-18 10:17 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, linux-wireless
In-Reply-To: <20171016150557.19368-1-toke@toke.dk>
On Mon, 2017-10-16 at 17:05 +0200, Toke Høiland-Jørgensen wrote:
> The fq structure would fail to properly enforce the memory limit in
> the case
> where the packet being enqueued was bigger than the packet being
> removed to
> bring the memory usage down. So keep dropping packets until the
> memory usage is
> back below the limit. Also, fix the statistics for memory limit
> violations.
>
Applied.
johannes
^ permalink raw reply
* Re: After upgrading to 4.11.1, wifi driver refuses to load after being unloaded once.
From: Luca Coelho @ 2017-10-18 10:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: Marc MERLIN, linux-wireless, linuxwifi
In-Reply-To: <87bml4iy40.fsf@kamboji.qca.qualcomm.com>
On Wed, 2017-10-18 at 12:50 +0300, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
> > On Wed, 2017-10-18 at 07:59 +0300, Kalle Valo wrote:
> > > Luca Coelho <luca@coelho.fi> writes:
> > >
> > > > On Tue, 2017-10-17 at 14:23 -0700, Marc MERLIN wrote:
> > > >
> > > > > I don't know how or why, but I seem to:
> > > > > saruman:~# grep IWLWIFI /boot/config-4.12.10-amd64-preempt-
> > > > > sysrq-
> > > > > 20170406
> > > > > CONFIG_IWLWIFI=m
> > > > > CONFIG_IWLWIFI_LEDS=y
> > > > > CONFIG_IWLWIFI_OPMODE_MODULAR=y
> > > > > # CONFIG_IWLWIFI_BCAST_FILTERING is not set
> > > > > CONFIG_IWLWIFI_PCIE_RTPM=y
> > > > > CONFIG_IWLWIFI_DEBUG=y
> > > > > CONFIG_IWLWIFI_DEVICE_TRACING=y
> > > > >
> > > > > I'll remove that, thanks.
> > > >
> > > > Cool, I think that might help. If it doesn't, please report a
> > > > bug
> > > > in
> > > > buzilla. ;)
> > >
> > > But a Kconfig option should never break functionality, so IMHO
> > > this
> > > still sounds like a bug in iwlwifi.
> >
> > The problem is that to get this to work, some changes need to be
> > made
> > in the platform side. In this case, the rootport is not configured
> > properly so it won't work.
>
> Yeah, but users or distros might accidentally enable this Kconfig
> option and break the driver unintentionally. And subtle bugs like
> this
> are even worse as the user will not realise that it's because of a
> new
> Kconfig option.
>
> So I guess you can't automatically detect it the platform supports
> RTPM,
> right? Maybe there should be a module parameter which has to be set
> to
> enable this? And at least a big fat warning to the user that RTPM is
> enabled, bugs are likely and the user has to know what she's doing.
I thought this was what EXPERT was used for:
menuconfig EXPERT
bool "Configure standard kernel features (expert users)"
# Unhide debug options, to make the on-by-default options visible
select DEBUG_KERNEL
help
This option allows certain base kernel options and settings
to be disabled or tweaked. This is for specialized
environments which can tolerate a "non-standard" kernel.
Only use this if you really know what you are doing.
But it seems that it's widely used even by people/distros who don't
know what they are doing. :(
Would it be okay if we just add a printk(KERN_ERR, ...)?
> > We discussed this before and that's why this option now depends on
> > EXPERT.
>
> Heh, we did? I have no recollection of whatsoever about that :)
I'm not sure you were involved in the discussion, but that discussion
was the reason we introduced EXPERT as a dependency.
--
Luca.
^ permalink raw reply
* Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()
From: Johannes Berg @ 2017-10-18 10:29 UTC (permalink / raw)
To: Kees Cook, linux-wireless; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <20171017202545.GA115810@beast>
Hi,
[quoting your other email:]
> This has been the least trivial timer conversion yet. Given the use of
> RCU and other things I may not even know about, I'd love to get a close
> look at this. I *think* this is correct, as it will re-lookup the tid
> entries when firing the timer.
I'm not really sure why you're doing the lookup again? That seems
pointless, since you already have the right structure, and already rely
on it being valid. You can't really get a new struct assigned to the
same TID without the old one being destroyed.
> -static void sta_rx_agg_session_timer_expired(unsigned long data)
> +static void sta_rx_agg_session_timer_expired(struct timer_list *t)
> {
> - /* not an elegant detour, but there is no choice as the timer passes
> - * only one argument, and various sta_info are needed here, so init
> - * flow in sta_info_create gives the TID as data, while the timer_to_id
> - * array gives the sta through container_of */
> - u8 *ptid = (u8 *)data;
> - u8 *timer_to_id = ptid - *ptid;
> - struct sta_info *sta = container_of(timer_to_id, struct sta_info,
> - timer_to_tid[0]);
> + struct tid_ampdu_rx *tid_rx_timer =
> + from_timer(tid_rx_timer, t, session_timer);
> + struct sta_info *sta = tid_rx_timer->sta;
> + u16 tid = tid_rx_timer->tid;
> struct tid_ampdu_rx *tid_rx;
> unsigned long timeout;
>
> rcu_read_lock();
> - tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[*ptid]);
> + tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
> if (!tid_rx) {
> rcu_read_unlock();
So through all of this, I'm pretty sure we can just use tid_rx_timer
instead of tid_rx.
(Same for TX)
Anyway, the change here looks correct to me, so I'll apply it and then
perhaps clean up more. I've only changed "u16 tid" to "u8 tid" since
the valid range is 0-15 (in theory, in practice 0-7).
johannes
^ 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