* Re: Need support for Intel new wifi module 9462NGW
From: Chris Chiu @ 2017-11-07 4:26 UTC (permalink / raw)
To: Luca Coelho
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <1509952948.4492.360.camel@coelho.fi>
Hi Luca,
I just tried the firmware but seems still something wrong. dmesg
shows me the following
[ 17.786041] Intel(R) Wireless WiFi driver for Linux
[ 17.786042] Copyright(c) 2003- 2015 Intel Corporation
[ 18.120052] iwlwifi 0000:00:0c.0: loaded firmware version
33.610294.0 op_mode iwlmvm
[ 20.995731] iwlwifi 0000:00:0c.0: Detected Intel(R) Dual Band
Wireless AC 9460, REV=0x318
[ 22.012109] iwlwifi 0000:00:0c.0: SecBoot CPU1 Status: 0x3, CPU2
Status: 0x2339
[ 22.012115] iwlwifi 0000:00:0c.0: Failed to start INIT ucode: -110
[ 22.024100] iwlwifi 0000:00:0c.0: Failed to run INIT ucode: -110
Any more information you need from me?
Chris
On Mon, Nov 6, 2017 at 3:22 PM, Luca Coelho <luca@coelho.fi> wrote:
> On Mon, 2017-11-06 at 11:22 +0800, Chris Chiu wrote:
>> Hi Luca,
>
> Hi Chris,
>
>
>> Any update for the firmware approval?
>
> Yes, I published it last Thursday. Sorry, I was in such a hurry that I
> forgot to tell you about it.
>
> You can find it here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-9260-th-b0-jf-b0-33.ucode?id=f132386b542b52ade0416ecb6cb7aef426f5d175
>
> Let me know how it goes.
>
> --
> Cheers,
> Luca.
^ permalink raw reply
* Re: [PATCH 3/3] mwifiex: cleanup rx_reorder_tbl_lock usage
From: Brian Norris @ 2017-11-07 2:30 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare, Douglas Anderson, Karthik Ananthapadmanabha
In-Reply-To: <1509442967-14149-4-git-send-email-gbhat@marvell.com>
Hi,
I haven't reviewed this patch in its entirety, but I'm pretty sure
you're introducing a reliable AA deadlock. See below.
Are you sure you're actually testing these codepaths?
On Tue, Oct 31, 2017 at 03:12:47PM +0530, Ganapathi Bhat wrote:
> From: Karthik Ananthapadmanabha <karthida@marvell.com>
>
> Fix the incorrect usage of rx_reorder_tbl_lock spinlock:
>
> 1. We shouldn't access the fields of the elements returned by
> mwifiex_11n_get_rx_reorder_tbl() after we have released spin
> lock. To fix this, To fix this, aquire the spinlock before
> calling this function and release the lock only after processing
> the corresponding element is complete.
>
> 2. Realsing the spinlock during iteration of the list and holding
> it back before next iteration is unsafe. Fix it by releasing the
> lock only after iteration of the list is complete.
>
> Signed-off-by: Karthik Ananthapadmanabha <karthida@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> ---
> .../net/wireless/marvell/mwifiex/11n_rxreorder.c | 34 +++++++++++++++++-----
> drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 3 ++
> 2 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> index 4631bc2..b99ace8 100644
> --- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> +++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> @@ -234,23 +234,19 @@ static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload)
>
> /*
> * This function returns the pointer to an entry in Rx reordering
> - * table which matches the given TA/TID pair.
> + * table which matches the given TA/TID pair. The caller must
> + * hold rx_reorder_tbl_lock, before calling this function.
> */
> struct mwifiex_rx_reorder_tbl *
> mwifiex_11n_get_rx_reorder_tbl(struct mwifiex_private *priv, int tid, u8 *ta)
> {
> struct mwifiex_rx_reorder_tbl *tbl;
> - unsigned long flags;
>
> - spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> list_for_each_entry(tbl, &priv->rx_reorder_tbl_ptr, list) {
> if (!memcmp(tbl->ta, ta, ETH_ALEN) && tbl->tid == tid) {
> - spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock,
> - flags);
> return tbl;
> }
> }
> - spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
>
> return NULL;
> }
> @@ -355,11 +351,14 @@ void mwifiex_11n_del_rx_reorder_tbl_by_ta(struct mwifiex_private *priv, u8 *ta)
> * If we get a TID, ta pair which is already present dispatch all the
> * the packets and move the window size until the ssn
> */
> + spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
> if (tbl) {
> mwifiex_11n_dispatch_pkt_until_start_win(priv, tbl, seq_num);
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> return;
> }
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> /* if !tbl then create one */
> new_node = kzalloc(sizeof(struct mwifiex_rx_reorder_tbl), GFP_KERNEL);
> if (!new_node)
> @@ -571,15 +570,19 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
> u16 pkt_index;
> bool init_window_shift = false;
> int ret = 0;
> + unsigned long flags;
>
> + spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
> if (!tbl) {
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> if (pkt_type != PKT_TYPE_BAR)
> mwifiex_11n_dispatch_pkt(priv, payload);
> return ret;
> }
>
> if ((pkt_type == PKT_TYPE_AMSDU) && !tbl->amsdu) {
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> mwifiex_11n_dispatch_pkt(priv, payload);
> return ret;
> }
> @@ -666,6 +669,8 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
> if (!tbl->timer_context.timer_is_set ||
> prev_start_win != tbl->start_win)
> mwifiex_11n_rxreorder_timer_restart(tbl);
> +
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> return ret;
> }
>
> @@ -683,6 +688,7 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
> struct mwifiex_ra_list_tbl *ra_list;
> u8 cleanup_rx_reorder_tbl;
> int tid_down;
> + unsigned long flags;
>
> if (type == TYPE_DELBA_RECEIVE)
> cleanup_rx_reorder_tbl = (initiator) ? true : false;
> @@ -693,14 +699,18 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
> peer_mac, tid, initiator);
>
> if (cleanup_rx_reorder_tbl) {
> + spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid,
> peer_mac);
> if (!tbl) {
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock,
> + flags);
> mwifiex_dbg(priv->adapter, EVENT,
> "event: TID, TA not found in table\n");
> return;
> }
> mwifiex_del_rx_reorder_entry(priv, tbl);
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> } else {
> ptx_tbl = mwifiex_get_ba_tbl(priv, tid, peer_mac);
> if (!ptx_tbl) {
> @@ -732,6 +742,7 @@ int mwifiex_ret_11n_addba_resp(struct mwifiex_private *priv,
> int tid, win_size;
> struct mwifiex_rx_reorder_tbl *tbl;
> uint16_t block_ack_param_set;
> + unsigned long flags;
>
> block_ack_param_set = le16_to_cpu(add_ba_rsp->block_ack_param_set);
>
> @@ -745,17 +756,20 @@ int mwifiex_ret_11n_addba_resp(struct mwifiex_private *priv,
> mwifiex_dbg(priv->adapter, ERROR, "ADDBA RSP: failed %pM tid=%d)\n",
> add_ba_rsp->peer_mac_addr, tid);
>
> + spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid,
> add_ba_rsp->peer_mac_addr);
> if (tbl)
> mwifiex_del_rx_reorder_entry(priv, tbl);
>
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> return 0;
> }
>
> win_size = (block_ack_param_set & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK)
> >> BLOCKACKPARAM_WINSIZE_POS;
>
> + spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid,
> add_ba_rsp->peer_mac_addr);
> if (tbl) {
> @@ -766,6 +780,7 @@ int mwifiex_ret_11n_addba_resp(struct mwifiex_private *priv,
> else
> tbl->amsdu = false;
> }
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
>
> mwifiex_dbg(priv->adapter, CMD,
> "cmd: ADDBA RSP: %pM tid=%d ssn=%d win_size=%d\n",
> @@ -806,9 +821,7 @@ void mwifiex_11n_cleanup_reorder_tbl(struct mwifiex_private *priv)
> spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
^^ Acquisition
> list_for_each_entry_safe(del_tbl_ptr, tmp_node,
> &priv->rx_reorder_tbl_ptr, list) {
> - spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
^^ No longer dropping the lock
> mwifiex_del_rx_reorder_entry(priv, del_tbl_ptr);
^^ This function also acquires the lock
Deadlock!
Brian
> - spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> }
> INIT_LIST_HEAD(&priv->rx_reorder_tbl_ptr);
> spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> @@ -933,6 +946,7 @@ void mwifiex_11n_rxba_sync_event(struct mwifiex_private *priv,
> int tlv_buf_left = len;
> int ret;
> u8 *tmp;
> + unsigned long flags;
>
> mwifiex_dbg_dump(priv->adapter, EVT_D, "RXBA_SYNC event:",
> event_buf, len);
> @@ -952,14 +966,18 @@ void mwifiex_11n_rxba_sync_event(struct mwifiex_private *priv,
> tlv_rxba->mac, tlv_rxba->tid, tlv_seq_num,
> tlv_bitmap_len);
>
> + spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> rx_reor_tbl_ptr =
> mwifiex_11n_get_rx_reorder_tbl(priv, tlv_rxba->tid,
> tlv_rxba->mac);
> if (!rx_reor_tbl_ptr) {
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock,
> + flags);
> mwifiex_dbg(priv->adapter, ERROR,
> "Can not find rx_reorder_tbl!");
> return;
> }
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
>
> for (i = 0; i < tlv_bitmap_len; i++) {
> for (j = 0 ; j < 8; j++) {
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> index 1e6a62c..21dc14f 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> @@ -421,12 +421,15 @@ int mwifiex_process_uap_rx_packet(struct mwifiex_private *priv,
> spin_unlock_irqrestore(&priv->sta_list_spinlock, flags);
> }
>
> + spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> if (!priv->ap_11n_enabled ||
> (!mwifiex_11n_get_rx_reorder_tbl(priv, uap_rx_pd->priority, ta) &&
> (le16_to_cpu(uap_rx_pd->rx_pkt_type) != PKT_TYPE_AMSDU))) {
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
> ret = mwifiex_handle_uap_rx_forward(priv, skb);
> return ret;
> }
> + spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
>
> /* Reorder and send to kernel */
> pkt_type = (u8)le16_to_cpu(uap_rx_pd->rx_pkt_type);
> --
> 1.9.1
>
^ permalink raw reply
* Re: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c
From: Brian Norris @ 2017-11-07 2:25 UTC (permalink / raw)
To: Doug Anderson
Cc: Ganapathi Bhat, linux-wireless@vger.kernel.org, Cathy Luo,
Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <CAD=FV=VuxFtDdcMndLNzVYDoid8N3jP46j0sOFXG1D4CzX0=Zw@mail.gmail.com>
Hi Doug and Ganapathi,
On Mon, Nov 06, 2017 at 04:42:20PM -0800, Doug Anderson wrote:
> Hi,
>
> Please take the review below with a grain of salt since I'm not
> terribly familiar with this driver. I thought I might be able to help
> since I had previously looked at some of the spinlock stuff, but after
> digging through the below I'm not 100% convinced I understand this
> driver enough to do a quick review...
>
> On Thu, Nov 2, 2017 at 3:30 AM, Ganapathi Bhat <gbhat@marvell.com> wrote:
> > Hi Brian,
> >
> >> On Tue, Oct 31, 2017 at 03:12:45PM +0530, Ganapathi Bhat wrote:
> >> > From: Karthik Ananthapadmanabha <karthida@marvell.com>
> >> >
> >> > Fix the incorrect usage of rx_pkt_lock spinlock. Realsing the spinlock
> >> > while the element is still in process is unsafe. The lock must be
> >> > released only after the element processing is complete.
> >> >
> >> > Signed-off-by: Karthik Ananthapadmanabha <karthida@marvell.com>
> >> > Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> >> > ---
> >> > drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 5 +++--
> >> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> >> > b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> >> > index 1edcdda..0149c4a 100644
> >> > --- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> >> > +++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> >> > @@ -124,9 +124,10 @@ static int mwifiex_11n_dispatch_pkt(struct
> >> mwifiex_private *priv, void *payload)
> >> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
> >> > tbl->rx_reorder_ptr[i] = NULL;
> >> > }
> >> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> >>
> >> So, what is this lock protecting? Is it for protecting the packet itself, or for
> >> protecting the ring buffer?
> >
> > This lock is protecting the ring buffer but with the current change, we are trying also to protect the packet too.
>
> What are you trying to protect the packet from? In other words: what
> other code is trying to make changes to the same structure? I'd agree
Agreed on this question. I don't understand what, specifically, about
"the packet" you're trying to protect, nor what other code might be
accessing it.
> with Brian that on first glance nobody else can have a reference to
> this packet since we've removed it from the global list. If you're
Right, if we're safely removing it from the pseudo ring buffer, then
nobody else should have access to it now.
> trying to protect something internal to this structure or something
> global to mwifiex then it seems like you'd want a different lock...
>
>
> >> As I read it, it's just the latter, since once we've
> >> removed it from the ring buffer (and are about to dispatch it up toward the
> >> networking layer), it's handled only by a single context (or else, protected via
> >> some other common lock(s)).
> >>
> >> If I'm correct above, then I think the current code here is actually safe, since
> >> it holds the lock while removing from the ring buffer -- after it's removed
> >> from the ring, there's no way another thread can find this payload, and so we
> >> can release the lock.
> >
> > There are cases where the ring buffer is iterated by cfg80211 thread:
> > mwifiex_cfg80211_tdls_oper => mwifiex_tdls_oper => mwifiex_tdls_process_disable_link => mwifiex_11n_cleanup_reorder_tbl => mwifiex_del_rx_reorder_entry => mwifiex_11n_dispatch_pkt_until_start_win => {iterates the ring buffer}
> > So, at worst case we can have two threads (main & cfg80211) running mwifiex_11n_dispatch_pkt_until_start_win(), iterating the ring buffer.
>
> Let me see if I'm understanding properly.
>
> There's a global (one for the whole driver) list called the
Just a point of order: it's a single list for each 'mwifiex_private' --
there can actually be multiple virtual interfaces attached to each
physical wiphy interface, and each virtual interface gets a
'mwifiex_private' instance. But otherwise, your descriptions are
accurate I believe.
> "rx_reorder_tbl_ptr". Insertion, deletion, and iteration of elements
> into this list are protected by the global "rx_reorder_tbl_lock" so we
> don't corrupt the linked list structure.
>
> The actual elements in the "rx_reorder_tbl_ptr" are _not_ protected by
> the global "rx_reorder_tbl_lock". I make this statement because I see
> mwifiex_11n_get_rx_reorder_tbl() which drops the lock before returning
> an entry.
Actually, patch 3 is changing that one :)
> ...and it seems sane that there could be a separate (more
> fine grained) lock protecting these elements. It is OK to keep a
> pointer to an element in this list without holding the lock--even if
> it's removed from the list the pointer is still valid. Presumably
> full deletion of the element (and any other access of members of the
> element) is protected by some other lock.
Aiee! You have too much faith. mwifiex_11n_del_rx_reorder_tbl_by_ta() ->
mwifiex_del_rx_reorder_entry(), for instance, has *very* bad handling of
this lock. It looks like:
(a) it does a series of acquire/release pairs on this lock while still
retaining the mwifiex_rx_reorder_tbl pointer. That's bad.
(b) it doesn't have any other lock to protect deletion; it *hopes* that
it cleared out the remaining packets in its buffer
(mwifiex_11n_dispatch_pkt_until_start_win()); but it doesn't hold any
other relevant locks between that and this:
spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
list_del(&tbl->list);
spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
kfree(tbl->rx_reorder_ptr);
kfree(tbl);
That's pretty bad.
I think it's best to work toward holding that lock while anyone is accessing
the entry. So we should only drop the lock when we're done accessing the
element, or when we've removed it from the list.
> Each element in the "rx_reorder_tbl_ptr" list is a "struct
> mwifiex_rx_reorder_tbl". It contains a pseudo-circular buffer
> (win_size elements big) "tbl->rx_reorder_ptr[]". Insertions and
> deletions from the pseudo-circular buffer are supposed to be protected
> by the global "rx_pkt_lock".
Seems right to me.
> In general if you hold an "index" into
> this buffer you should be holding the "rx_pkt_lock",
Sure.
> but if you hold
> one of the elements (each element is a pointer) then you presumably
> don't need the "rx_pkt_lock" (if you do, I'd be curious as to why).
You mean, "if you hold one of these elements [and have removed it from the ring
buffer]" then you don't need the lock? If so, I agree.
> Did I get that right?
>
>
> So overall the "rx_pkt_lock" seems a bit fishy to me.
>
> My first clue that something seems wrong is that "rx_pkt_lock" is
> global (one for the whole driver) but seems to be protecting something
> that is more fine-grained. Locks really ought to be part of the
> structure whose elements they are protecting. Said another way, I'd
> expect "rx_pkt_lock" NOT to be in "priv" but for there to be a
> separate instance of "rx_pkt_lock" inside each "struct
> mwifiex_rx_reorder_tbl". That would make it much more obvious what
> was being protected and also would allow different tables to be worked
> on at the same time.
>
> NOTE: it's probably not the end of the world if there's a single
> global "rx_pkt_lock", it's just less ideal and not all that different
> than having one big lock protecting everything in the driver.
Agreed on the above 2 paragraphs. At a minimum, rx_pkt_lock should be
documented better. But part of that documentation is typically putting the lock
near what it's protecting.
But overall, I'm not sure we're getting much interesting concurrency
here at all, and so I'm not sure if all the (poort attempt at)
fine-grained locking is even helpful. Ganapathi only pointed out
cfg80211 TDLS operations as the "2nd thread of execution" besides the
mwifiex "main thread" -- this thread is only used for configuration
(e.g., setup, teardown, and configuration of TDLS links). And any time
we're holding the "fine grained" rx_pkt_lock, we already are holdling
the larger table lock.
> The other thing that is fishy is that "rx_pkt_lock" doesn't seem to be
> reliably protecting, again as Brian pointed out. Specifically:
>
> * It seems like "start_win" is supposed to be protected by
> "rx_pkt_lock" too, but it's not in
> mwifiex_11n_dispatch_pkt_until_start_win() (and many other places, I
> didn't check). In general any place where we're holding an _index_
> into the table seems like it should have the "rx_pkt_lock" and
> "start_win" is an index. Why do I say this? If you are holding an
> _index_ and something is deleted from the list (or shuffled) then the
> index just won't be valid anymore. Thus if others can be inserting /
> removing / shuffling the list then holding an index isn't safe without
> the lock.
Agreed.
> * There are several places that access "rx_reorder_ptr" without
> grabbing "rx_pkt_lock". That seems wrong. For instance,
> mwifiex_get_rx_reorder_tbl(), but probably other places too.
Ah, yes.
> * Functions like mwifiex_11n_find_last_seq_num() seem quite confused.
> They act on a table entry but for some reason grab the
> "rx_reorder_tbl_lock", which was supposed to be protecting the linked
> list (I think).
Agreed.
> Worse yet mwifiex_11n_find_last_seq_num() returns an
> _index_ into the pseudo-queue. I don't think that is a super valid
> thing to do unless you assume that the caller has the
> rx_reorder_tbl_lock, which it doesn't. Probably
> mwifiex_11n_find_last_seq_num() should require the caller hold
> "rx_pkt_lock".
I'm not sure the right solution here, but it does look wrong today. The
only saving grace here would be if we don't care about this being
slightly inaccurate. For instance, I *think* it's fine to return some of
this out of order.
On a similar note: why does mwifiex_11n_dispatch_pkt_until_start_win()
release rx_pkt_lock in between each index (i.e., the "for (i = 0; i <
pkt_to_send; ++i)" loop)? That means that the entire ring buffer
indexing could change underneath our feet. I'm not sure this is
technically unsafe (we do still grab the lock and do NULL checks), but
it might still cause undesireable results around what packets get
dispatched or now -- i.e., we might not *really* be honoring the window
arguments that were passed in.
> >> On a related note: I don't actually see the ring buffer *insertion* being
> >> protected by this rx_pkt_lock, so is it really useful? See
> >> mwifiex_11n_rx_reorder_pkt(). Perhaps the correct lock is actually
> >> rx_reorder_tbl_lock()? Except that serves multiple purposes it seems...
> >
> > Right, ring buffer insertion is not protected. I think we should be using both rx_reorder_tbl_lock(which is already present) and rx_pkt_lock(we need to add) during insertion (mwifiex_11n_rx_reorder_pkt()).
>
> As far as I see mwifiex_11n_rx_reorder_pkt() doesn't hold
> "rx_reorder_tbl_lock" for the whole function. It just grabs it to
> search the linked list and then drops it. Is that right? Seems OK
> given my current (limited) understanding but it sounded like you were
> expecting it to be held for the whole function?
I think patch 3 fixes that? It tries to grab the lock for (almost) the
entire function.
> IMHO then it needs to grab "rx_pkt_lock" before the access to
> tbl->start_win, but I haven't looked at everything fully.
>
>
> > Also, we should be using rx_pkt_lock instead of rx_reorder_tbl_lock in mwifiex_11n_find_last_seq_num().
> >>
> >> Another thought: from what I can tell, all of these operations are
> >> *only* performed on the main thread, so there's actually no concurrency
> >> involved at all. So we also could probably drop this lock entirely...
> >
> > Let us know your inputs on above observations.
>
> Not sure if my thoughts above made sense or were useful. Hopefully I
> didn't sound too stupid... ;)
Not stupid to me. Thanks for looking.
Brian
> >> I guess the real point is: can you explain better what you intend this lock to
> >> do? Then we can review whether you're accomplishing your intention, or
> >> whether we should improve the usage of this lock in some other way, or
> >> perhaps even kill it entirely.
> >>
> >> Thanks,
> >> Brian
> >>
> >> > if (rx_tmp_ptr)
> >> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
> >> > +
> >> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> >> > }
> >> >
> >> > spin_lock_irqsave(&priv->rx_pkt_lock, flags); @@ -167,8 +168,8 @@
> >> > static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void
> >> *payload)
> >> > }
> >> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
> >> > tbl->rx_reorder_ptr[i] = NULL;
> >> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> >> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
> >> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> >> > }
> >> >
> >> > spin_lock_irqsave(&priv->rx_pkt_lock, flags);
> >> > --
> >> > 1.9.1
> >> >
> >
> > Regards,
> > Ganapathi
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Kalle Valo @ 2017-11-07 2:18 UTC (permalink / raw)
To: Stefan Wahren
Cc: Simon Shields, Franky Lin, Chi-Hsien Lin, Wright Feng,
Arend van Spriel, brcm80211-dev-list.pdl, Hante Meuleman,
linux-wireless, brcm80211-dev-list
In-Reply-To: <1925563700.5172.1509993297900@email.1und1.de>
Stefan Wahren <stefan.wahren@i2se.com> writes:
>> Simon Shields <simon@lineageos.org> hat am 4. November 2017 um 14:24 geschrieben:
>>
>>
>> Some boards use an external 32khz clock for low-power
>> mode timing. Make sure the clock is powered on while the chipset
>> is active.
>>
>> Signed-off-by: Simon Shields <simon@lineageos.org>
>> ---
>> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 5 +++++
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 10 ++++++++++
>> 4 files changed, 19 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> index b2bd4704f859..37add5e29272 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> @@ -17,6 +17,8 @@ Optional properties:
>> When not specified the device will use in-band SDIO interrupts.
>> - interrupt-names : name of the out-of-band interrupt, which must be set
>> to "host-wake".
>> + - clocks : external 32khz clock
>> + - clock-names : name of the external 32khz clock, must be "32khz"
>
> sorry for the nitpicking, but according to the datasheet [1] it's
> 32768 Hz. Apart from that i suggest to use a functional name for the
> clock like "low_power" or something else, which is more flexible and
> future-proof.
>
> Btw this binding needs to be a separate patch, which should go to the
> devicetree guys.
Previously I have applied binding documentation changes which the DT
maintainers have acked, that's why I specifically asked to Cc device
tree list. Has something changed?
--
Kalle Valo
^ permalink raw reply
* Re: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c
From: Doug Anderson @ 2017-11-07 0:42 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: Brian Norris, linux-wireless@vger.kernel.org, Cathy Luo,
Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <cb98c452aa344fc0b501a776cfa8708a@SC-EXCH02.marvell.com>
Hi,
Please take the review below with a grain of salt since I'm not
terribly familiar with this driver. I thought I might be able to help
since I had previously looked at some of the spinlock stuff, but after
digging through the below I'm not 100% convinced I understand this
driver enough to do a quick review...
On Thu, Nov 2, 2017 at 3:30 AM, Ganapathi Bhat <gbhat@marvell.com> wrote:
> Hi Brian,
>
>> On Tue, Oct 31, 2017 at 03:12:45PM +0530, Ganapathi Bhat wrote:
>> > From: Karthik Ananthapadmanabha <karthida@marvell.com>
>> >
>> > Fix the incorrect usage of rx_pkt_lock spinlock. Realsing the spinlock
>> > while the element is still in process is unsafe. The lock must be
>> > released only after the element processing is complete.
>> >
>> > Signed-off-by: Karthik Ananthapadmanabha <karthida@marvell.com>
>> > Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
>> > ---
>> > drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 5 +++--
>> > 1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> > b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> > index 1edcdda..0149c4a 100644
>> > --- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> > +++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> > @@ -124,9 +124,10 @@ static int mwifiex_11n_dispatch_pkt(struct
>> mwifiex_private *priv, void *payload)
>> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
>> > tbl->rx_reorder_ptr[i] = NULL;
>> > }
>> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>>
>> So, what is this lock protecting? Is it for protecting the packet itself, or for
>> protecting the ring buffer?
>
> This lock is protecting the ring buffer but with the current change, we are trying also to protect the packet too.
What are you trying to protect the packet from? In other words: what
other code is trying to make changes to the same structure? I'd agree
with Brian that on first glance nobody else can have a reference to
this packet since we've removed it from the global list. If you're
trying to protect something internal to this structure or something
global to mwifiex then it seems like you'd want a different lock...
>> As I read it, it's just the latter, since once we've
>> removed it from the ring buffer (and are about to dispatch it up toward the
>> networking layer), it's handled only by a single context (or else, protected via
>> some other common lock(s)).
>>
>> If I'm correct above, then I think the current code here is actually safe, since
>> it holds the lock while removing from the ring buffer -- after it's removed
>> from the ring, there's no way another thread can find this payload, and so we
>> can release the lock.
>
> There are cases where the ring buffer is iterated by cfg80211 thread:
> mwifiex_cfg80211_tdls_oper => mwifiex_tdls_oper => mwifiex_tdls_process_disable_link => mwifiex_11n_cleanup_reorder_tbl => mwifiex_del_rx_reorder_entry => mwifiex_11n_dispatch_pkt_until_start_win => {iterates the ring buffer}
> So, at worst case we can have two threads (main & cfg80211) running mwifiex_11n_dispatch_pkt_until_start_win(), iterating the ring buffer.
Let me see if I'm understanding properly.
There's a global (one for the whole driver) list called the
"rx_reorder_tbl_ptr". Insertion, deletion, and iteration of elements
into this list are protected by the global "rx_reorder_tbl_lock" so we
don't corrupt the linked list structure.
The actual elements in the "rx_reorder_tbl_ptr" are _not_ protected by
the global "rx_reorder_tbl_lock". I make this statement because I see
mwifiex_11n_get_rx_reorder_tbl() which drops the lock before returning
an entry. ...and it seems sane that there could be a separate (more
fine grained) lock protecting these elements. It is OK to keep a
pointer to an element in this list without holding the lock--even if
it's removed from the list the pointer is still valid. Presumably
full deletion of the element (and any other access of members of the
element) is protected by some other lock.
Each element in the "rx_reorder_tbl_ptr" list is a "struct
mwifiex_rx_reorder_tbl". It contains a pseudo-circular buffer
(win_size elements big) "tbl->rx_reorder_ptr[]". Insertions and
deletions from the pseudo-circular buffer are supposed to be protected
by the global "rx_pkt_lock". In general if you hold an "index" into
this buffer you should be holding the "rx_pkt_lock", but if you hold
one of the elements (each element is a pointer) then you presumably
don't need the "rx_pkt_lock" (if you do, I'd be curious as to why).
Did I get that right?
So overall the "rx_pkt_lock" seems a bit fishy to me.
My first clue that something seems wrong is that "rx_pkt_lock" is
global (one for the whole driver) but seems to be protecting something
that is more fine-grained. Locks really ought to be part of the
structure whose elements they are protecting. Said another way, I'd
expect "rx_pkt_lock" NOT to be in "priv" but for there to be a
separate instance of "rx_pkt_lock" inside each "struct
mwifiex_rx_reorder_tbl". That would make it much more obvious what
was being protected and also would allow different tables to be worked
on at the same time.
NOTE: it's probably not the end of the world if there's a single
global "rx_pkt_lock", it's just less ideal and not all that different
than having one big lock protecting everything in the driver.
The other thing that is fishy is that "rx_pkt_lock" doesn't seem to be
reliably protecting, again as Brian pointed out. Specifically:
* It seems like "start_win" is supposed to be protected by
"rx_pkt_lock" too, but it's not in
mwifiex_11n_dispatch_pkt_until_start_win() (and many other places, I
didn't check). In general any place where we're holding an _index_
into the table seems like it should have the "rx_pkt_lock" and
"start_win" is an index. Why do I say this? If you are holding an
_index_ and something is deleted from the list (or shuffled) then the
index just won't be valid anymore. Thus if others can be inserting /
removing / shuffling the list then holding an index isn't safe without
the lock.
* There are several places that access "rx_reorder_ptr" without
grabbing "rx_pkt_lock". That seems wrong. For instance,
mwifiex_get_rx_reorder_tbl(), but probably other places too.
* Functions like mwifiex_11n_find_last_seq_num() seem quite confused.
They act on a table entry but for some reason grab the
"rx_reorder_tbl_lock", which was supposed to be protecting the linked
list (I think). Worse yet mwifiex_11n_find_last_seq_num() returns an
_index_ into the pseudo-queue. I don't think that is a super valid
thing to do unless you assume that the caller has the
rx_reorder_tbl_lock, which it doesn't. Probably
mwifiex_11n_find_last_seq_num() should require the caller hold
"rx_pkt_lock".
>> On a related note: I don't actually see the ring buffer *insertion* being
>> protected by this rx_pkt_lock, so is it really useful? See
>> mwifiex_11n_rx_reorder_pkt(). Perhaps the correct lock is actually
>> rx_reorder_tbl_lock()? Except that serves multiple purposes it seems...
>
> Right, ring buffer insertion is not protected. I think we should be using both rx_reorder_tbl_lock(which is already present) and rx_pkt_lock(we need to add) during insertion (mwifiex_11n_rx_reorder_pkt()).
As far as I see mwifiex_11n_rx_reorder_pkt() doesn't hold
"rx_reorder_tbl_lock" for the whole function. It just grabs it to
search the linked list and then drops it. Is that right? Seems OK
given my current (limited) understanding but it sounded like you were
expecting it to be held for the whole function?
IMHO then it needs to grab "rx_pkt_lock" before the access to
tbl->start_win, but I haven't looked at everything fully.
> Also, we should be using rx_pkt_lock instead of rx_reorder_tbl_lock in mwifiex_11n_find_last_seq_num().
>>
>> Another thought: from what I can tell, all of these operations are
>> *only* performed on the main thread, so there's actually no concurrency
>> involved at all. So we also could probably drop this lock entirely...
>
> Let us know your inputs on above observations.
Not sure if my thoughts above made sense or were useful. Hopefully I
didn't sound too stupid... ;)
>> I guess the real point is: can you explain better what you intend this lock to
>> do? Then we can review whether you're accomplishing your intention, or
>> whether we should improve the usage of this lock in some other way, or
>> perhaps even kill it entirely.
>>
>> Thanks,
>> Brian
>>
>> > if (rx_tmp_ptr)
>> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
>> > +
>> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>> > }
>> >
>> > spin_lock_irqsave(&priv->rx_pkt_lock, flags); @@ -167,8 +168,8 @@
>> > static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void
>> *payload)
>> > }
>> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
>> > tbl->rx_reorder_ptr[i] = NULL;
>> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
>> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>> > }
>> >
>> > spin_lock_irqsave(&priv->rx_pkt_lock, flags);
>> > --
>> > 1.9.1
>> >
>
> Regards,
> Ganapathi
^ permalink raw reply
* [PATCH] rsi: rsi_91x_ps: remove redundant code in str_psstate
From: Gustavo A. R. Silva @ 2017-11-06 21:53 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
"INVALID_STATE" is already being returned in the default case and this
code cannot be reached.
Addresses-Coverity-ID: 1398384
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
drivers/net/wireless/rsi/rsi_91x_ps.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_ps.c b/drivers/net/wireless/rsi/rsi_91x_ps.c
index 523f532..01472fa 100644
--- a/drivers/net/wireless/rsi/rsi_91x_ps.c
+++ b/drivers/net/wireless/rsi/rsi_91x_ps.c
@@ -36,7 +36,6 @@ char *str_psstate(enum ps_state state)
default:
return "INVALID_STATE";
}
- return "INVALID_STATE";
}
static inline void rsi_modify_ps_state(struct rsi_hw *adapter,
--
2.7.4
^ permalink raw reply related
* Re: ath10k: Fix reported HT MCS rates with NSS > 1
From: Peter Oh @ 2017-11-06 21:25 UTC (permalink / raw)
To: Sven Eckelmann, Sebastian Gottschall
Cc: Kalle Valo, ath10k, akolli, linux-wireless
In-Reply-To: <1960925.hkIbv4gX65@bentobox>
On 11/06/2017 01:02 AM, Sven Eckelmann wrote:
> On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote:
>> Am 06.11.2017 um 09:23 schrieb Sven Eckelmann:
>>> On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote:
>>>> the assumption made in this patch is obviously wrong (at least for more
>>>> recent firmwares and 9984)
>>>> my log is flooded with messages like
>>>> [208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>>>> [208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>>>> [208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>>>> [208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>>>> [208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> [...]
>>> This patch only splits WMI_RATE_PREAMBLE_HT & WMI_RATE_PREAMBLE_VHT. And for
>>> WMI_RATE_PREAMBLE_HT (*not VHT*), it uses a slightly different approach. But
>>> the WMI_RATE_PREAMBLE_VHT part (which you see in your logs) is basically
>>> untouched.
>> then a question follows up. is this check really neccessary?
> Until we find out what the heck VHT MCS 15 should mean in this context - maybe.
> But to the message - no, the message is most likely not necessary for each
> received "invalid" peer tx stat.
This validation check expects peer tx stat packets from FW contain
reasonable values and gives warning if values are different from
expectation. The problem comes from the assumption that "it always
contains reasonable stat value" which is wrong at least based on my
results. For instance, the reason MCS == 15 is because all 4 bits of mcs
potion set to 1, not because FW really sets it to 15 intentionally. when
the mcs potion bits are set to all 1s, the other bits such as nss are
also set to all 1s.
Hence it looks FW passed totally invalid stat info to me.
I don't have preference on whether it's better to split VHT and HT check
or not, but it is more appropriate to change that warning level to debug
level.
^ permalink raw reply
* Re: [PATCH 13/17] iwlwifi: mvm: Convert timers to use timer_setup()
From: Kees Cook @ 2017-11-06 20:40 UTC (permalink / raw)
To: Luca Coelho
Cc: Kalle Valo, linux-wireless, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Sara Sharon, Network Development
In-Reply-To: <1509997730.4492.422.camel@coelho.fi>
On Mon, Nov 6, 2017 at 11:48 AM, Luca Coelho <luca@coelho.fi> wrote:
> On Mon, 2017-11-06 at 11:45 -0800, Kees Cook wrote:
>> On Sun, Oct 29, 2017 at 5:28 AM, Luca Coelho <luca@coelho.fi> wrote:
>> > From: Kees Cook <keescook@chromium.org>
>> >
>> > 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.
>> >
>> > The RCU lifetime on baid_data is unclear, so this adds a direct
>> > copy of the
>> > rcu_ptr passed to the original callback. It may be possible to
>> > improve this
>> > to just use baid_data->mvm->baid_map[baid_data->baid] instead.
>> >
>> > Cc: Johannes Berg <johannes.berg@intel.com>
>> > Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>> > Cc: Luca Coelho <luciano.coelho@intel.com>
>> > Cc: Intel Linux Wireless <linuxwifi@intel.com>
>> > Cc: Kalle Valo <kvalo@codeaurora.org>
>> > Cc: Sara Sharon <sara.sharon@intel.com>
>> > Cc: linux-wireless@vger.kernel.org
>> > Cc: netdev@vger.kernel.org
>> > Signed-off-by: Kees Cook <keescook@chromium.org>
>> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>> > ---
>> > drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 ++-
>> > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 ++--
>> > drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 18 +++++++++----
>> > -----
>> > 3 files changed, 13 insertions(+), 12 deletions(-)
>>
>> Hi,
>>
>> Thanks for taking this! I had a question on timing: is this expected
>> to land for 4.15? If not, I would like to take this via the timers
>> tree, since it is one of the few remaining conversions.
>
> Hi Kees,
>
> Yes, this should land for 4.15. Kalle just pulled my pull-request
> (which includes this) to wireless-drivers-next. He told me he'll send
> a pull-request for 4.15 during this week and hopefully Dave will pull
> from him too.
>
> I'll let you know if something doesn't go as planned.
Awesome, thanks very much!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* RE: [PATCH] mac80211: Update last_ack status for all except probing frames
From: Rajkumar Manoharan @ 2017-11-06 20:20 UTC (permalink / raw)
To: Igor Mitsyanko, Johannes Berg
Cc: linux-wireless@vger.kernel.org, rmanohar@codeaurora.org
In-Reply-To: <49241af7-a50f-5758-0c7e-77f2fae5d93d@quantenna.com>
PiA+Pj4gVXBkYXRlIGxhc3RfYWNrIHN0YXR1cyBmb3IgYWxsIGV4Y2VwdCBzdGF0aW9uIHByb2Jp
bmcgZnJhbWVzIChpLmUNCj4gPj4+IG51bGwgZGF0YSkuIE90aGVyd2lzZSB0aGUgc3RhdGlvbiBp
bmFjdGl2aXR5IGR1cmF0aW9uIGlzIGNsZWFyZWQNCj4gPj4+IHdoZW5ldmVyIEFQIGlzIGNoZWNr
aW5nIHByZXNlbmNlIG9mIGlkbGUgc3RhdGlvbnMgYnkgc2VuZGluZyBudWxsDQo+ID4+PiBkYXRh
IGZyYW1lIGZvciBldmVyeSBpbmFjdGl2ZSB0aHJlc2hvbGQgKGFwX21heF9pbmFjdGl2aXR5KS4N
Cj4gPj4NCj4gPj4gWW91IG1ha2UgaXQgc291bmQgbGlrZSB0aGlzIGlzIGEgcHJvYmxlbSwgYnV0
IGRvbid0IGV4cGxhaW4gd2h5IGl0DQo+ID4+IHdvdWxkIGJlPyBJIGRvbid0IHJlYWxseSBzZWUg
aXQgYW55d2F5Lg0KPiA+Pg0KPiA+IEZvciBzdGVlcmluZyBhbiBpZGxlIHN0YXRpb24gZnJvbSBv
bmUgQlNTIHRvIGFub3RoZXIsIHRoZSBzdGVlcmluZw0KPiA+IGFwcGxpY2F0aW9uIGhhcyB0byBr
bm93IHRoZSBhY3R1YWwgc3RhdGlvbiBpZGxlIHBlcmlvZC4gQnV0IGlmIHRoZQ0KPiA+IGlkbGUg
cGVyaW9kIGlzIGNsZWFyZWQgYnkgYXBfbWF4X2luYWN0aXZpdHksIHRoZSBzdGVlcmluZyBhcHBs
aWNhdGlvbg0KPiA+IGNhbm5vdCBzdGVlciB0aGUgc3RhdGlvbiBldmVuIHRob3VnaCB0aGUgc3Rh
dGlvbiBpcyBub3Qgc2VuZGluZyBvciByZWNlaXZpbmcNCj4gYW55IGRhdGEgb3IgbWdtdC4gZnJh
bWUuDQo+ID4NCj4gPiBUaG91Z2gga2VlcGluZyBsb25nZXIgaWRsZSB0aHJlc2hvbGQgKGFwX21h
eF9pbmFjdGl2aXR5KSB0aGFuIHN0ZWVyaW5nDQo+ID4gYXBwbGljYXRpb24gbGltaXQgbWF5IGhl
bHAgdG8gaWRlbnRpZnkgaWRsZSBzdGF0aW9uLCBpdCB3aWxsIGRpZmZlciByZW1vdmluZyB0aGUN
Cj4gc3RhdGlvbnMgdGhhdCBsZWZ0IEJTUy4NCj4gPg0KPiBIaSBSYWprdW1hciwgdGhpcyB3aWxs
IG5vdCBoZWxwIGluIGFsbCB0aGUgY2FzZXMgYXMgc29tZSBkcml2ZXJzIG1heSBjaG9vc2UgdG8N
Cj4gaW1wbGVtZW50ICJpbmFjdGl2aXR5IiBsb2dpYyBpbiBmaXJtd2FyZSBhbmQgZmlybXdhcmUg
d2lsbCBzZW5kIHByb2JpbmcgZnJhbWVzDQo+IGl0c2VsZiBpZiByZXF1aXJlZCwgcmVzZXR0aW5n
IGluYWN0aXZpdHkgcGVyaW9kLg0KPg0KSW4gb2ZmbG9hZCBhcHByb2FjaCwgbm8gbmVlZCB0byBy
ZXBvcnQgdHhfYWNrIGZvciBmaXJtd2FyZSBnZW5lcmF0ZWQgZnJhbWVzLiBubz8NCg0KPiBCZXNp
ZGVzLCBhdCB0aGlzIGxldmVsIHdlIGRvIG5vdCBrbm93IHdobyBzZW50IE5VTEwgZnJhbWVzIGFu
ZCBmb3Igd2hpY2gNCj4gcHVycG9zZSwgaXQgZG9lc24ndCBsb29rIGxpa2UgYSBnb29kIGlkZWEg
dG8ganVzdCBpZ25vcmUgaXQuDQo+DQpJIGhhZCB0aGUgc2FtZSBkb3VidC4gQnV0IEFGQUlLLCBw
cm9iZV9jbGllbnQgbmV0bGluayBjb21tYW5kIGlzIHVzZWQgYnkNCkhvc3RhcGQgb25seS4gVGhh
dOKAmXMgd2h5IEkgYWRkZWQgY29tbWVudCBzZWN0aW9uIGJlZm9yZSB0aGUgY2hhbmdlLg0KIA0K
PiBJIHRoaW5rIHRoYXQgZm9yIHdoYXQgaXQgd2FzIHN1cHBvc2VkIHRvIGJlLCBpbmFjdGl2aXR5
X21zIHdvcmtzIGFzIGV4cGVjdGVkIGFuZA0KPiBpdCBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSAi
ZGVhZCIgc3RhdGlvbnMuIFdoYXQgeW91IHByb2JhYmx5IG5lZWQgaXMgc29tZXRoaW5nDQo+IGRp
ZmZlcmVudCwgY2FsbGVkIGZvciBleGFtcGxlICJyeF9pZGxlX3RpbWUiDQo+IHRoYXQgd2lsbCBr
ZWVwIHRyYWNrIG9mIGhvdyBsb25nIFNUQSBpdHNlbGYgZGlkIG5vdCBzZW5kIGFueSBmcmFtZXMg
KGlnbm9yaW5nDQo+IEFDS3MpLg0KPg0KSG1tLi4gInJ4X2lkbGVfdGltZSIgb25seSBub3QgZW5v
dWdoIHRvIGRldGVybWluZSBhY3RpdmUgc3RhdGUuIEJlY2F1c2UgYSBzdGF0aW9uDQpjYW4gcmVj
ZWl2ZSB1bmktZGlyZWN0aW9uIGRhdGEgdHJhZmZpYy4gRm9yIGV4YW1wbGUsIElmIHRoZSBzdGF0
aW9uIGlzIGNvbm5lY3RlZCBhbmQNCmlkbGUgZm9yIGhhbGYgYW4gaG91ciBidXQgd2l0aGluIEJT
UywgdGhlbiBib3RoICJpbmFjdGl2aXR5X21zIiBhbmQgImNvbm5lY3RlZF90aW1lIiANCnNob3Vs
ZCBiZSAzMCBtaW5zLiBJc24ndCBpdD8uDQoNCi1SYWprdW1hcg0K
^ permalink raw reply
* Re: [PATCH] mac80211: Update last_ack status for all except probing frames
From: Igor Mitsyanko @ 2017-11-06 19:50 UTC (permalink / raw)
To: Rajkumar Manoharan, Johannes Berg
Cc: linux-wireless@vger.kernel.org, rmanohar@codeaurora.org
In-Reply-To: <8bb232d231884f9595c81f945a5eef4f@NALASEXR01H.na.qualcomm.com>
On 11/06/2017 09:44 AM, Rajkumar Manoharan wrote:
>> On Mon, 2017-10-30 at 17:29 -0700, Rajkumar Manoharan wrote:
>>> Update last_ack status for all except station probing frames (i.e null
>>> data). Otherwise the station inactivity duration is cleared whenever
>>> AP is checking presence of idle stations by sending null data frame
>>> for every inactive threshold (ap_max_inactivity).
>>
>> You make it sound like this is a problem, but don't explain why it would be? I
>> don't really see it anyway.
>>
> For steering an idle station from one BSS to another, the steering application
> has to know the actual station idle period. But if the idle period is cleared by
> ap_max_inactivity, the steering application cannot steer the station even though
> the station is not sending or receiving any data or mgmt. frame.
>
> Though keeping longer idle threshold (ap_max_inactivity) than steering application
> limit may help to identify idle station, it will differ removing the stations that left BSS.
>
> -Rajkumar
>
Hi Rajkumar, this will not help in all the cases as some drivers may
choose to implement "inactivity" logic in firmware and firmware will
send probing frames itself if required, resetting inactivity period.
Besides, at this level we do not know who sent NULL frames and for which
purpose, it doesn't look like a good idea to just ignore it.
I think that for what it was supposed to be, inactivity_ms works as
expected and it can be used to identify "dead" stations. What you
probably need is something different, called for example "rx_idle_time"
that will keep track of how long STA itself did not send any frames
(ignoring ACKs).
^ permalink raw reply
* Re: [PATCH 13/17] iwlwifi: mvm: Convert timers to use timer_setup()
From: Luca Coelho @ 2017-11-06 19:48 UTC (permalink / raw)
To: Kees Cook
Cc: Kalle Valo, linux-wireless, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Sara Sharon, Network Development
In-Reply-To: <CAGXu5jLhCxwR1zntTYS_5X72kp-H8h++8PH-p5aKTC5oU-OaLw@mail.gmail.com>
On Mon, 2017-11-06 at 11:45 -0800, Kees Cook wrote:
> On Sun, Oct 29, 2017 at 5:28 AM, Luca Coelho <luca@coelho.fi> wrote:
> > From: Kees Cook <keescook@chromium.org>
> >
> > 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.
> >
> > The RCU lifetime on baid_data is unclear, so this adds a direct
> > copy of the
> > rcu_ptr passed to the original callback. It may be possible to
> > improve this
> > to just use baid_data->mvm->baid_map[baid_data->baid] instead.
> >
> > Cc: Johannes Berg <johannes.berg@intel.com>
> > Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > Cc: Luca Coelho <luciano.coelho@intel.com>
> > Cc: Intel Linux Wireless <linuxwifi@intel.com>
> > Cc: Kalle Valo <kvalo@codeaurora.org>
> > Cc: Sara Sharon <sara.sharon@intel.com>
> > Cc: linux-wireless@vger.kernel.org
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> > ---
> > drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 ++-
> > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 ++--
> > drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 18 +++++++++----
> > -----
> > 3 files changed, 13 insertions(+), 12 deletions(-)
>
> Hi,
>
> Thanks for taking this! I had a question on timing: is this expected
> to land for 4.15? If not, I would like to take this via the timers
> tree, since it is one of the few remaining conversions.
Hi Kees,
Yes, this should land for 4.15. Kalle just pulled my pull-request
(which includes this) to wireless-drivers-next. He told me he'll send
a pull-request for 4.15 during this week and hopefully Dave will pull
from him too.
I'll let you know if something doesn't go as planned.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 13/17] iwlwifi: mvm: Convert timers to use timer_setup()
From: Kees Cook @ 2017-11-06 19:45 UTC (permalink / raw)
To: Luca Coelho
Cc: Kalle Valo, linux-wireless, Johannes Berg, Emmanuel Grumbach,
Luca Coelho, Intel Linux Wireless, Sara Sharon,
Network Development
In-Reply-To: <20171029122816.8802-14-luca@coelho.fi>
On Sun, Oct 29, 2017 at 5:28 AM, Luca Coelho <luca@coelho.fi> wrote:
> From: Kees Cook <keescook@chromium.org>
>
> 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.
>
> The RCU lifetime on baid_data is unclear, so this adds a direct copy of the
> rcu_ptr passed to the original callback. It may be possible to improve this
> to just use baid_data->mvm->baid_map[baid_data->baid] instead.
>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Cc: Luca Coelho <luciano.coelho@intel.com>
> Cc: Intel Linux Wireless <linuxwifi@intel.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Sara Sharon <sara.sharon@intel.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 ++-
> drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 ++--
> drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 18 +++++++++---------
> 3 files changed, 13 insertions(+), 12 deletions(-)
Hi,
Thanks for taking this! I had a question on timing: is this expected
to land for 4.15? If not, I would like to take this via the timers
tree, since it is one of the few remaining conversions.
Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Stefan Wahren @ 2017-11-06 18:34 UTC (permalink / raw)
To: Simon Shields
Cc: Franky Lin, Chi-Hsien Lin, Wright Feng, Arend van Spriel,
brcm80211-dev-list.pdl, Hante Meuleman, linux-wireless,
brcm80211-dev-list
In-Reply-To: <20171104132421.GA1541@archbox.home>
Hi Simon,
> Simon Shields <simon@lineageos.org> hat am 4. November 2017 um 14:24 geschrieben:
>
>
> Some boards use an external 32khz clock for low-power
> mode timing. Make sure the clock is powered on while the chipset
> is active.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 5 +++++
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 10 ++++++++++
> 4 files changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index b2bd4704f859..37add5e29272 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -17,6 +17,8 @@ Optional properties:
> When not specified the device will use in-band SDIO interrupts.
> - interrupt-names : name of the out-of-band interrupt, which must be set
> to "host-wake".
> + - clocks : external 32khz clock
> + - clock-names : name of the external 32khz clock, must be "32khz"
sorry for the nitpicking, but according to the datasheet [1] it's 32768 Hz. Apart from that i suggest to use a functional name for the clock like "low_power" or something else, which is more flexible and future-proof.
Btw this binding needs to be a separate patch, which should go to the devicetree guys.
[1] - http://www.cypress.com/file/298706/download
>
> Example:
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> index a62f8e70b320..2e7fabae81d3 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> @@ -51,6 +51,7 @@ extern struct brcmf_mp_global_t brcmf_mp_global;
> * @roamoff: Firmware roaming off?
> * @ignore_probe_fail: Ignore probe failure.
> * @country_codes: If available, pointer to struct for translating country codes
> + * @clk: External 32khz clock, if present.
> * @bus: Bus specific platform data. Only SDIO at the mmoment.
> */
> struct brcmf_mp_device {
> @@ -60,6 +61,7 @@ struct brcmf_mp_device {
> bool roamoff;
> bool ignore_probe_fail;
> struct brcmfmac_pd_cc *country_codes;
> + struct clk *clk;
> union {
> struct brcmfmac_sdio_pd sdio;
> } bus;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> index aee6e5937c41..46f42a2c3d2b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> @@ -13,6 +13,7 @@
> * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
> * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> */
> +#include <linux/clk.h>
> #include <linux/init.h>
> #include <linux/of.h>
> #include <linux/of_irq.h>
> @@ -39,6 +40,10 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
> if (of_property_read_u32(np, "brcm,drive-strength", &val) == 0)
> sdio->drive_strength = val;
>
> + settings->clk = devm_clk_get(dev, "32khz");
> + if (IS_ERR(settings->clk))
> + settings->clk = NULL;
I cannot recommend this, please look at the thread here [2].
Thanks
[2] - https://marc.info/?l=linux-arm-kernel&m=150980353025665&w=2
> +
> /* make sure there are interrupts defined in the node */
> if (!of_find_property(np, "interrupts", NULL))
> return;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 613caca7dc02..f4ceca6dbe74 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -14,6 +14,7 @@
> * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> */
>
> +#include <linux/clk.h>
> #include <linux/types.h>
> #include <linux/atomic.h>
> #include <linux/kernel.h>
> @@ -3853,6 +3854,11 @@ brcmf_sdio_probe_attach(struct brcmf_sdio *bus)
> brcmf_err("Failed to get device parameters\n");
> goto fail;
> }
> +
> + /* enable external 32khz clock, if present */
> + if (sdiodev->settings->clk)
> + clk_prepare_enable(sdiodev->settings->clk);
> +
> /* platform specific configuration:
> * alignments must be at least 4 bytes for ADMA
> */
> @@ -4270,6 +4276,10 @@ void brcmf_sdio_remove(struct brcmf_sdio *bus)
> }
> brcmf_chip_detach(bus->ci);
> }
> +
> + if (bus->sdiodev->settings->clk)
> + clk_disable_unprepare(bus->sdiodev->settings->clk);
> +
> if (bus->sdiodev->settings)
> brcmf_release_module_param(bus->sdiodev->settings);
>
> --
> 2.15.0
>
^ permalink raw reply
* RE: [PATCH] mac80211: Update last_ack status for all except probing frames
From: Rajkumar Manoharan @ 2017-11-06 17:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, rmanohar@codeaurora.org
In-Reply-To: <1509964164.2669.0.camel@sipsolutions.net>
PiBPbiBNb24sIDIwMTctMTAtMzAgYXQgMTc6MjkgLTA3MDAsIFJhamt1bWFyIE1hbm9oYXJhbiB3
cm90ZToNCj4gPiBVcGRhdGUgbGFzdF9hY2sgc3RhdHVzIGZvciBhbGwgZXhjZXB0IHN0YXRpb24g
cHJvYmluZyBmcmFtZXMgKGkuZSBudWxsDQo+ID4gZGF0YSkuIE90aGVyd2lzZSB0aGUgc3RhdGlv
biBpbmFjdGl2aXR5IGR1cmF0aW9uIGlzIGNsZWFyZWQgd2hlbmV2ZXINCj4gPiBBUCBpcyBjaGVj
a2luZyBwcmVzZW5jZSBvZiBpZGxlIHN0YXRpb25zIGJ5IHNlbmRpbmcgbnVsbCBkYXRhIGZyYW1l
DQo+ID4gZm9yIGV2ZXJ5IGluYWN0aXZlIHRocmVzaG9sZCAoYXBfbWF4X2luYWN0aXZpdHkpLg0K
PiANCj4gWW91IG1ha2UgaXQgc291bmQgbGlrZSB0aGlzIGlzIGEgcHJvYmxlbSwgYnV0IGRvbid0
IGV4cGxhaW4gd2h5IGl0IHdvdWxkIGJlPyBJDQo+IGRvbid0IHJlYWxseSBzZWUgaXQgYW55d2F5
Lg0KPiANCkZvciBzdGVlcmluZyBhbiBpZGxlIHN0YXRpb24gZnJvbSBvbmUgQlNTIHRvIGFub3Ro
ZXIsIHRoZSBzdGVlcmluZyBhcHBsaWNhdGlvbg0KaGFzIHRvIGtub3cgdGhlIGFjdHVhbCBzdGF0
aW9uIGlkbGUgcGVyaW9kLiBCdXQgaWYgdGhlIGlkbGUgcGVyaW9kIGlzIGNsZWFyZWQgYnkNCmFw
X21heF9pbmFjdGl2aXR5LCB0aGUgc3RlZXJpbmcgYXBwbGljYXRpb24gY2Fubm90IHN0ZWVyIHRo
ZSBzdGF0aW9uIGV2ZW4gdGhvdWdoDQp0aGUgc3RhdGlvbiBpcyBub3Qgc2VuZGluZyBvciByZWNl
aXZpbmcgYW55IGRhdGEgb3IgbWdtdC4gZnJhbWUuDQoNClRob3VnaCBrZWVwaW5nIGxvbmdlciBp
ZGxlIHRocmVzaG9sZCAoYXBfbWF4X2luYWN0aXZpdHkpIHRoYW4gc3RlZXJpbmcgYXBwbGljYXRp
b24NCmxpbWl0IG1heSBoZWxwIHRvIGlkZW50aWZ5IGlkbGUgc3RhdGlvbiwgaXQgd2lsbCBkaWZm
ZXIgcmVtb3ZpbmcgdGhlIHN0YXRpb25zIHRoYXQgbGVmdCBCU1MuDQoNCi1SYWprdW1hcg0K
^ permalink raw reply
* Soft lockup in rt2x00usb_work_rxdone()
From: Richard Genoud @ 2017-11-06 15:57 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa; +Cc: linux-kernel, linux-wireless
Hi,
I get a soft lock-up while unbinding the USB driver on a TP-Link TL-WN727Nv3 (chipset 5370):
# echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308]
CPU: 0 PID: 308 Comm: kworker/u2:3 Not tainted 4.14.0-rc8 #11
Hardware name: Atmel AT91SAM9
Workqueue: phy0 rt2x00usb_work_rxdone
task: c7b91000 task.stack: c7bee000
PC is at rt2x00lib_rxdone+0x590/0x5b8
LR is at rt2x00lib_dmadone+0x54/0x58
pc : [<c0332978>] lr : [<c0331fdc>] psr: 80000013
sp : c7befebc ip : 00000052 fp : c7befee4
r10: 00000000 r9 : c79b2b58 r8 : 00000000
r7 : c7816d00 r6 : c780e200 r5 : c79c68dc r4 : c7134ce0
r3 : 00000001 r2 : c70bc200 r1 : ffffa55f r0 : 00000000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0005317f Table: 261b8000 DAC: 00000053
CPU: 0 PID: 308 Comm: kworker/u2:3 Not tainted 4.14.0-rc8 #11
Hardware name: Atmel AT91SAM9
Workqueue: phy0 rt2x00usb_work_rxdone
[<c000fe00>] (unwind_backtrace) from [<c000dd94>] (show_stack+0x20/0x24)
[<c000dd94>] (show_stack) from [<c05a5440>] (dump_stack+0x20/0x28)
[<c05a5440>] (dump_stack) from [<c000b03c>] (show_regs+0x1c/0x20)
[<c000b03c>] (show_regs) from [<c0064c6c>] (watchdog_timer_fn+0x148/0x1ac)
[<c0064c6c>] (watchdog_timer_fn) from [<c0051dec>] (hrtimer_run_queues+0x128/0x250)
[<c0051dec>] (hrtimer_run_queues) from [<c00512e8>] (run_local_timers+0x18/0x68)
[<c00512e8>] (run_local_timers) from [<c0051370>] (update_process_times+0x38/0x6c)
[<c0051370>] (update_process_times) from [<c005e1c0>] (tick_nohz_handler+0xc0/0x10c)
[<c005e1c0>] (tick_nohz_handler) from [<c03a73cc>] (ch2_irq+0x30/0x38)
[<c03a73cc>] (ch2_irq) from [<c0046b00>] (__handle_irq_event_percpu+0x74/0x1dc)
[<c0046b00>] (__handle_irq_event_percpu) from [<c0046c94>] (handle_irq_event_percpu+0x2c/0x68)
[<c0046c94>] (handle_irq_event_percpu) from [<c0046d08>] (handle_irq_event+0x38/0x4c)
[<c0046d08>] (handle_irq_event) from [<c0049f54>] (handle_fasteoi_irq+0xa0/0x114)
[<c0049f54>] (handle_fasteoi_irq) from [<c0046320>] (generic_handle_irq+0x28/0x38)
[<c0046320>] (generic_handle_irq) from [<c00463c0>] (__handle_domain_irq+0x90/0xb8)
[<c00463c0>] (__handle_domain_irq) from [<c00094a4>] (aic_handle+0xb0/0xb8)
[<c00094a4>] (aic_handle) from [<c000ea68>] (__irq_svc+0x68/0x84)
Exception stack(0xc7befe68 to 0xc7befeb0)
fe60: 00000000 ffffa55f c70bc200 00000001 c7134ce0 c79c68dc
fe80: c780e200 c7816d00 00000000 c79b2b58 00000000 c7befee4 00000052 c7befebc
fea0: c0331fdc c0332978 80000013 ffffffff
[<c000ea68>] (__irq_svc) from [<c0332978>] (rt2x00lib_rxdone+0x590/0x5b8)
[<c0332978>] (rt2x00lib_rxdone) from [<c0337550>] (rt2x00usb_work_rxdone+0x60/0x7c)
[<c0337550>] (rt2x00usb_work_rxdone) from [<c002ca64>] (process_one_work+0x1e4/0x3a0)
[<c002ca64>] (process_one_work) from [<c002cf28>] (worker_thread+0x2c8/0x45c)
[<c002cf28>] (worker_thread) from [<c0031f68>] (kthread+0x114/0x130)
[<c0031f68>] (kthread) from [<c000a4c8>] (ret_from_fork+0x14/0x2c)
I can trigger this each time.
NB: if the wifi is deactivated properly before the unbind, there's no problem :
# ifconfig wlan0 down ; echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
wlan0: deauthenticating from 06:18:d6:91:9e:29 by local choice (Reason: 3=DEAUTH_LEAVING)
Full dmesg:
## Booting kernel from Legacy Image at 20007fc0 ...
Image Name: Linux-4.14.0-rc8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4522192 Bytes = 4.3 MiB
Load Address: 20008000
Entry Point: 20008000
## Flattened Device Tree blob at 26400000
Booting using the fdt blob at 0x26400000
XIP Kernel Image ... OK
Loading Device Tree to 27df2000, end 27dfcbb3 ... OK
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 4.14.0-rc8 (rgenoud@lnx-rg) (gcc version 4.7.3 (GCC)) #11 Mon Nov 6 16:22:49 CET 2017
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: Paratronic LNS
Memory policy: Data cache writeback
On node 0 totalpages: 32768
free_area_init_node: node 0, pgdat c08a4b78, node_mem_map c7efb000
Normal zone: 256 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 32768 pages, LIFO batch:7
random: fast init done
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists, mobility grouping on. Total pages: 32512
Kernel command line: loglevel=8 ro root=ubi0:rootfs rootfstype=ubifs ubi.mtd=ubi lpj=995328 ubi.fm_autoconvert=1 panic=2 mtdparts=atmel_nand:256M(all),128k@0(dtb),10112k(kernel),251392k(ubi),512k(bbt)ro atmel-nand-controller.use_dma=0 spidev.bufsiz=53200 video=320x240-32
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 120624K/131072K available (5847K kernel code, 475K rwdata, 1504K rodata, 480K init, 245K bss, 10448K reserved, 0K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xc8800000 - 0xff800000 ( 880 MB)
lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
.text : 0xc0008000 - 0xc05be200 (5849 kB)
.init : 0xc07be000 - 0xc0836000 ( 480 kB)
.data : 0xc0836000 - 0xc08accd0 ( 476 kB)
.bss : 0xc08b20e8 - 0xc08ef77c ( 246 kB)
ftrace: allocating 23621 entries in 70 pages
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
clocksource: pit: mask: 0xfffffff max_cycles: 0xfffffff, max_idle_ns: 14334453866 ns
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns
Console: colour dummy device 80x30
console [tty0] enabled
Calibrating delay loop (skipped) preset value.. 199.06 BogoMIPS (lpj=995328)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x20008400 - 0x2000843c
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
AT91: PM: standby: standby, suspend: ulp0
gpio-at91 fffff400.gpio: at address c8861400
gpio-at91 fffff600.gpio: at address c8863600
gpio-at91 fffff800.gpio: at address c8865800
gpio-at91 fffffa00.gpio: at address c8867a00
pinctrl-at91 ahb:apb:pinctrl@fffff400: initialized AT91 pinctrl driver
tcb_clksrc: tc0 at 16.166 MHz
clocksource: tcb_clksrc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 114675631333 ns
at_hdmac ffffec00.dma-controller: Atmel AHB DMA Controller ( cpy set slave ), 8 channels
at_hdmac ffffee00.dma-controller: Atmel AHB DMA Controller ( cpy set slave ), 8 channels
AT91: Detected SoC family: at91sam9x5
AT91: Detected SoC: at91sam9g35, revision 1
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c-gpio i2c-gpio-0: using pins 30 (SDA) and 31 (SCL)
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
clocksource: Switched to clocksource tcb_clksrc
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
workingset: timestamp_bits=30 max_order=15 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
io scheduler noop registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
fffff200.serial: ttyS0 at MMIO 0xfffff200 (irq = 16, base_baud = 8333333) is a ATMEL_SERIAL
console [ttyS0] enabled
f801c000.serial: ttyS1 at MMIO 0xf801c000 (irq = 23, base_baud = 8333333) is a ATMEL_SERIAL
f8020000.serial: ttyS2 at MMIO 0xf8020000 (irq = 24, base_baud = 8333333) is a ATMEL_SERIAL
f8024000.serial: ttyS3 at MMIO 0xf8024000 (irq = 25, base_baud = 8333333) is a ATMEL_SERIAL
brd: module loaded
loop: module loaded
ssc f0010000.ssc: Atmel SSC device at 0xc88a0000 (irq 22)
at24 0-0053: 256 byte 24c02 EEPROM, writable, 16 bytes/write
at24 0-0051: 65536 byte 24c512 EEPROM, writable, 128 bytes/write
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
5 cmdlinepart partitions found on MTD device atmel_nand
Creating 5 MTD partitions on "atmel_nand":
0x000000000000-0x000010000000 : "all"
0x000000000000-0x000000020000 : "dtb"
0x000000020000-0x000000a00000 : "kernel"
0x000000a00000-0x00000ff80000 : "ubi"
0x00000ff80000-0x000010000000 : "bbt"
atmel-pmecc ffffe000.ecc-engine: can't request region for resource [mem 0xffffe000-0xffffe5ff]
atmel-pmecc: probe of ffffe000.ecc-engine failed with error -16
m25p80 spi0.0: at25df321a (4096 Kbytes)
4 ofpart partitions found on MTD device spi0.0
Creating 4 MTD partitions on "spi0.0":
0x000000000000-0x000000008000 : "bootpri"
0x000000008000-0x000000108000 : "bootsec"
0x000000108000-0x000000218000 : "bootenv"
0x000000110000-0x000000400000 : "free"
atmel_spi f0000000.spi: Atmel SPI Controller version 0x212 at 0xf0000000 (irq 27)
atmel_spi f0004000.spi: Atmel SPI Controller version 0x212 at 0xf0004000 (irq 28)
libphy: Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
libphy: MACB_mii_bus: probed
Davicom DM9161A f802c000.ethernet-ffffffff:00: attached PHY driver [Davicom DM9161A] (mii_bus:phy_addr=f802c000.ethernet-ffffffff:00, irq=POLL)
macb f802c000.ethernet eth0: Cadence MACB rev 0x0001010c at 0xf802c000 irq 31 (00:04:a3:d2:a7:ef)
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
usbcore: registered new interface driver rt2800usb
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver rndis_host
usbcore: registered new interface driver cdc_ncm
usbcore: registered new interface driver qmi_wwan
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-atmel: EHCI Atmel driver
atmel-ehci 700000.ehci: EHCI Host Controller
atmel-ehci 700000.ehci: new USB bus registered, assigned bus number 1
atmel-ehci 700000.ehci: irq 32, io mem 0x00700000
atmel-ehci 700000.ehci: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.14.0-rc8 ehci_hcd
usb usb1: SerialNumber: 700000.ehci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new interface driver cdc_acm
cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
usbcore: registered new interface driver cdc_wdm
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver option
usbserial: USB Serial support registered for GSM modem (1-port)
usbcore: registered new interface driver pl2303
usbserial: USB Serial support registered for pl2303
usbcore: registered new interface driver qcserial
usbserial: USB Serial support registered for Qualcomm USB modem
usbcore: registered new interface driver sierra
usbserial: USB Serial support registered for Sierra USB modem
atmel_usba_udc 500000.gadget: MMIO registers at 0xf803c000 mapped at c88e1000
atmel_usba_udc 500000.gadget: FIFO at 0x00500000 mapped at c8a80000
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 56:0b:bc:61:78:8c
usb0: MAC fa:b6:82:52:5d:bb
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
i2c /dev entries driver
AT91: Starting after user reset
at91_wdt fffffe40.watchdog: watchdog is disabled
at91_wdt: probe of fffffe40.watchdog failed with error -22
hidraw: raw HID events driver (C) Jiri Kosina
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (2048 buckets, 8192 max)
ctnetlink v0.93: registering with nfnetlink.
ip_tables: (C) 2000-2006 Netfilter Core Team
Initializing XFRM netlink socket
NET: Registered protocol family 10
Segment Routing with IPv6
ip6_tables: (C) 2000-2006 Netfilter Core Team
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Key type dns_resolver registered
ubi0: default fastmap pool size: 95
ubi0: default fastmap WL pool size: 47
ubi0: attaching mtd3
atmel_usba_udc 500000.gadget: ODD: EP5 configuration is invalid!
atmel_usba_udc 500000.gadget: ODD: EP6 configuration is invalid!
atmel_usba_udc 500000.gadget: ODD: EP5 configuration is invalid!
atmel_usba_udc 500000.gadget: ODD: EP6 configuration is invalid!
usb 1-2: new high-speed USB device number 2 using atmel-ehci
g_ether gadget: high-speed config #1: CDC Ethernet (ECM)
ubi0: attached by fastmap
ubi0: fastmap pool size: 95
ubi0: fastmap WL pool size: 47
usb 1-2: New USB device found, idVendor=0424, idProduct=2512
usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 2 ports detected
ubi0: attached mtd3 (name "ubi", size 245 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 1964, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 32/12, WL threshold: 4096, image sequence number: 216151522
ubi0: available PEBs: 0, total reserved PEBs: 1964, PEBs reserved for bad PEB handling: 40
backlight-power-supply: disabling
panel-power-supply: disabling
ubi0: background thread "ubi_bgt0d" started, PID 618
atmel_usart fffff200.serial: using dma1chan0 for rx DMA transfers
atmel_usart fffff200.serial: using dma1chan1 for tx DMA transfers
UBIFS (ubi0:0): recovery needed
UBIFS (ubi0:0): recovery deferred
UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs", R/O mode
UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS (ubi0:0): FS size: 66789376 bytes (63 MiB, 526 LEBs), journal size 9015296 bytes (8 MiB, 71 LEBs)
UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 764284F8-1DF2-40F9-BFB6-C0DC0D4D143F, small LPT model
VFS: Mounted root (ubifs filesystem) readonly on device 0:14.
devtmpfs: mounted
Freeing unused kernel memory: 480K
This architecture does not have kernel memory protection.
usb 1-2.2: new high-speed USB device number 3 using atmel-ehci
usb 1-2.2: New USB device found, idVendor=148f, idProduct=5370
usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2.2: Product: 802.11 n WLAN
usb 1-2.2: Manufacturer: TPlink
usb 1-2.2: SerialNumber: 1.0
UBIFS (ubi0:2): background thread "ubifs_bgt0_2" started, PID 631
usb 1-2.2: reset high-speed USB device number 3 using atmel-ehci
UBIFS (ubi0:2): recovery needed
ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 5370 detected
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
UBIFS (ubi0:2): recovery completed
UBIFS (ubi0:2): UBIFS: mounted UBI device 0, volume 2, name "data"
UBIFS (ubi0:2): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS (ubi0:2): FS size: 105771008 bytes (100 MiB, 833 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
UBIFS (ubi0:2): reserved for root: 0 bytes (0 KiB)
UBIFS (ubi0:2): media format: w4/r0 (latest is w5/r0), UUID F6094496-0276-4615-A1FF-CE370C8017B0, small LPT model
Watchdog disabled
ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: authenticate with 06:18:d6:91:9e:29
wlan0: send auth to 06:18:d6:91:9e:29 (try 1/3)
wlan0: authenticated
wlan0: associate with 06:18:d6:91:9e:29 (try 1/3)
wlan0: RX AssocResp from 06:18:d6:91:9e:29 (capab=0x431 status=0 aid=2)
wlan0: associated
IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tether Link encap:Ethernet HWaddr FA:B6:82:52:5D:BB
inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::3039:28ff:fe3d:96e8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6930 (6.7 KiB) TX bytes:2046 (1.9 KiB)
usb0 Link encap:Ethernet HWaddr FA:B6:82:52:5D:BB
inet6 addr: fe80::f8b6:82ff:fe52:5dbb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7334 (7.1 KiB) TX bytes:2432 (2.3 KiB)
wlan0 Link encap:Ethernet HWaddr 10:FE:ED:25:B1:0D
inet addr:192.168.3.134 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1440 (1.4 KiB) TX bytes:2052 (2.0 KiB)
# echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308]
CPU: 0 PID: 308 Comm: kworker/u2:3 Not tainted 4.14.0-rc8 #11
Hardware name: Atmel AT91SAM9
Workqueue: phy0 rt2x00usb_work_rxdone
task: c7b91000 task.stack: c7bee000
PC is at rt2x00lib_rxdone+0x590/0x5b8
LR is at rt2x00lib_dmadone+0x54/0x58
pc : [<c0332978>] lr : [<c0331fdc>] psr: 80000013
sp : c7befebc ip : 00000052 fp : c7befee4
r10: 00000000 r9 : c79b2b58 r8 : 00000000
r7 : c7816d00 r6 : c780e200 r5 : c79c68dc r4 : c7134ce0
r3 : 00000001 r2 : c70bc200 r1 : ffffa55f r0 : 00000000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0005317f Table: 261b8000 DAC: 00000053
CPU: 0 PID: 308 Comm: kworker/u2:3 Not tainted 4.14.0-rc8 #11
Hardware name: Atmel AT91SAM9
Workqueue: phy0 rt2x00usb_work_rxdone
[<c000fe00>] (unwind_backtrace) from [<c000dd94>] (show_stack+0x20/0x24)
[<c000dd94>] (show_stack) from [<c05a5440>] (dump_stack+0x20/0x28)
[<c05a5440>] (dump_stack) from [<c000b03c>] (show_regs+0x1c/0x20)
[<c000b03c>] (show_regs) from [<c0064c6c>] (watchdog_timer_fn+0x148/0x1ac)
[<c0064c6c>] (watchdog_timer_fn) from [<c0051dec>] (hrtimer_run_queues+0x128/0x250)
[<c0051dec>] (hrtimer_run_queues) from [<c00512e8>] (run_local_timers+0x18/0x68)
[<c00512e8>] (run_local_timers) from [<c0051370>] (update_process_times+0x38/0x6c)
[<c0051370>] (update_process_times) from [<c005e1c0>] (tick_nohz_handler+0xc0/0x10c)
[<c005e1c0>] (tick_nohz_handler) from [<c03a73cc>] (ch2_irq+0x30/0x38)
[<c03a73cc>] (ch2_irq) from [<c0046b00>] (__handle_irq_event_percpu+0x74/0x1dc)
[<c0046b00>] (__handle_irq_event_percpu) from [<c0046c94>] (handle_irq_event_percpu+0x2c/0x68)
[<c0046c94>] (handle_irq_event_percpu) from [<c0046d08>] (handle_irq_event+0x38/0x4c)
[<c0046d08>] (handle_irq_event) from [<c0049f54>] (handle_fasteoi_irq+0xa0/0x114)
[<c0049f54>] (handle_fasteoi_irq) from [<c0046320>] (generic_handle_irq+0x28/0x38)
[<c0046320>] (generic_handle_irq) from [<c00463c0>] (__handle_domain_irq+0x90/0xb8)
[<c00463c0>] (__handle_domain_irq) from [<c00094a4>] (aic_handle+0xb0/0xb8)
[<c00094a4>] (aic_handle) from [<c000ea68>] (__irq_svc+0x68/0x84)
Exception stack(0xc7befe68 to 0xc7befeb0)
fe60: 00000000 ffffa55f c70bc200 00000001 c7134ce0 c79c68dc
fe80: c780e200 c7816d00 00000000 c79b2b58 00000000 c7befee4 00000052 c7befebc
fea0: c0331fdc c0332978 80000013 ffffffff
[<c000ea68>] (__irq_svc) from [<c0332978>] (rt2x00lib_rxdone+0x590/0x5b8)
[<c0332978>] (rt2x00lib_rxdone) from [<c0337550>] (rt2x00usb_work_rxdone+0x60/0x7c)
[<c0337550>] (rt2x00usb_work_rxdone) from [<c002ca64>] (process_one_work+0x1e4/0x3a0)
[<c002ca64>] (process_one_work) from [<c002cf28>] (worker_thread+0x2c8/0x45c)
[<c002cf28>] (worker_thread) from [<c0031f68>] (kthread+0x114/0x130)
[<c0031f68>] (kthread) from [<c000a4c8>] (ret_from_fork+0x14/0x2c)
Regards,
Richard
^ permalink raw reply
* Re: [PATCH 1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time
From: Larry Finger @ 2017-11-06 14:22 UTC (permalink / raw)
To: Arnd Bergmann, Chaoming Li, Kalle Valo
Cc: stable, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171106135619.1248453-1-arnd@arndb.de>
On 11/06/2017 07:55 AM, Arnd Bergmann wrote:
> We set rtlhal->last_suspend_sec to an uninitialized stack variable,
> but unfortunately gcc never warned about this, I only found it
> while working on another patch. I opened a gcc bug for this.
>
> Presumably the value of rtlhal->last_suspend_sec is not all that
> important, but it does get used, so we probably want the
> patch backported to stable kernels.
>
> Cc: stable@vger.kernel.org
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For all three of these patches:
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks,
Larry
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
> index 60c82a5b51cd..20ffe856180e 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
> @@ -1373,6 +1373,7 @@ static void _rtl8821ae_get_wakeup_reason(struct ieee80211_hw *hw)
>
> ppsc->wakeup_reason = 0;
>
> + do_gettimeofday(&ts);
> rtlhal->last_suspend_sec = ts.tv_sec;
>
> switch (fw_reason) {
>
^ permalink raw reply
* [PATCH] rt2x00: use monotonic timestamps for frame dump
From: Arnd Bergmann @ 2017-11-06 14:03 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, Kalle Valo
Cc: Arnd Bergmann, Johannes Berg, David S. Miller, linux-wireless,
netdev, linux-kernel
rt2x00 uses the deprecated do_gettimeofday() function to get a timestamp
for its debugfs "dump" file interface.
The timestamp is using an unsigned 32-bit value, so we could make it
work until 2106 by using ktime_get_real_ts64(), but it seems better to
use monotonic times, as we normally want for timestamps.
Since this is an interface change, I'm incrementing the
DUMP_HEADER_VERSION number, so user space can figure out whether the
timestamps are monotonic or not. Most likely the tools won't care either
way.
Generally speaking, ABI version numbers and in particular changing them
is a bad idea. However since this is in debugfs, we don't put any
API stability rules on the interface according to
Documentation/filesystems/debugfs.txt, and we can take the easy way
out here; anyone using the frame dump feature can probably work out
the differences here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 7 ++++---
drivers/net/wireless/ralink/rt2x00/rt2x00dump.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index 51520a0e2138..f4fdad2ed319 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -164,13 +164,13 @@ void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
struct skb_frame_desc *skbdesc = get_skb_frame_desc(skb);
struct sk_buff *skbcopy;
struct rt2x00dump_hdr *dump_hdr;
- struct timeval timestamp;
+ struct timespec64 timestamp;
u32 data_len;
if (likely(!test_bit(FRAME_DUMP_FILE_OPEN, &intf->frame_dump_flags)))
return;
- do_gettimeofday(×tamp);
+ ktime_get_ts64(×tamp);
if (skb_queue_len(&intf->frame_dump_skbqueue) > 20) {
rt2x00_dbg(rt2x00dev, "txrx dump queue length exceeded\n");
@@ -200,7 +200,8 @@ void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
dump_hdr->queue_index = entry->queue->qid;
dump_hdr->entry_index = entry->entry_idx;
dump_hdr->timestamp_sec = cpu_to_le32(timestamp.tv_sec);
- dump_hdr->timestamp_usec = cpu_to_le32(timestamp.tv_usec);
+ dump_hdr->timestamp_usec = cpu_to_le32(timestamp.tv_nsec /
+ NSEC_PER_USEC);
if (!(skbdesc->flags & SKBDESC_DESC_IN_SKB))
skb_put_data(skbcopy, skbdesc->desc, skbdesc->desc_len);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h b/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
index 4c0e01b5d515..3b14eef0b646 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
@@ -106,7 +106,7 @@ enum rt2x00_dump_type {
*/
struct rt2x00dump_hdr {
__le32 version;
-#define DUMP_HEADER_VERSION 2
+#define DUMP_HEADER_VERSION 3
__le32 header_length;
__le32 desc_length;
--
2.9.0
^ permalink raw reply related
* [PATCH 3/3] rtlwifi: drop unused ppsc->last_wakeup_time
From: Arnd Bergmann @ 2017-11-06 13:55 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: Arnd Bergmann, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171106135619.1248453-1-arnd@arndb.de>
The calculation of ppsc->last_wakeup_time is not y2038-safe, but
the variable is not used at all, so we can simply drop it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 -----
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 --
2 files changed, 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index ad28e188bd04..36f785c4ea0f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1364,7 +1364,6 @@ static void _rtl8821ae_get_wakeup_reason(struct ieee80211_hw *hw)
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtlpriv);
u8 fw_reason = 0;
- struct timeval ts;
fw_reason = rtl_read_byte(rtlpriv, REG_MCUTST_WOWLAN);
@@ -1378,15 +1377,11 @@ static void _rtl8821ae_get_wakeup_reason(struct ieee80211_hw *hw)
switch (fw_reason) {
case FW_WOW_V2_PTK_UPDATE_EVENT:
ppsc->wakeup_reason = WOL_REASON_PTK_UPDATE;
- do_gettimeofday(&ts);
- ppsc->last_wakeup_time = ts.tv_sec*1000 + ts.tv_usec/1000;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
"It's a WOL PTK Key update event!\n");
break;
case FW_WOW_V2_GTK_UPDATE_EVENT:
ppsc->wakeup_reason = WOL_REASON_GTK_UPDATE;
- do_gettimeofday(&ts);
- ppsc->last_wakeup_time = ts.tv_sec*1000 + ts.tv_usec/1000;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
"It's a WOL GTK Key update event!\n");
break;
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 6f1b0f4667d9..d9776af41976 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1953,8 +1953,6 @@ struct rtl_ps_ctl {
u8 gtk_offload_enable;
/* Used for WOL, indicates the reason for waking event.*/
u32 wakeup_reason;
- /* Record the last waking time for comparison with setting key. */
- u64 last_wakeup_time;
};
struct rtl_stats {
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] rtlwifi: use ktime_get_real_seconds() for suspend time
From: Arnd Bergmann @ 2017-11-06 13:55 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: Arnd Bergmann, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171106135619.1248453-1-arnd@arndb.de>
do_gettimeofday() is deprecated and slower than necessary for the purpose
of reading the seconds. This changes rtl_op_suspend/resume to use
ktime_get_real_seconds() instead, which is simpler and avoids confusion
about whether it is y2038-safe or not.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/realtek/rtlwifi/core.c | 10 ++++------
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 3 +--
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 +-
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index 1147327e6f52..533e9cc4c84b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -550,15 +550,13 @@ static int rtl_op_suspend(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
- struct timeval ts;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG, "\n");
if (WARN_ON(!wow))
return -EINVAL;
/* to resolve s4 can not wake up*/
- do_gettimeofday(&ts);
- rtlhal->last_suspend_sec = ts.tv_sec;
+ rtlhal->last_suspend_sec = ktime_get_real_seconds();
if ((ppsc->wo_wlan_mode & WAKE_ON_PATTERN_MATCH) && wow->n_patterns)
_rtl_add_wowlan_patterns(hw, wow);
@@ -577,7 +575,7 @@ static int rtl_op_resume(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
- struct timeval ts;
+ time64_t now;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG, "\n");
rtlhal->driver_is_goingto_unload = false;
@@ -585,8 +583,8 @@ static int rtl_op_resume(struct ieee80211_hw *hw)
rtlhal->wake_from_pnp_sleep = true;
/* to resovle s4 can not wake up*/
- do_gettimeofday(&ts);
- if (ts.tv_sec - rtlhal->last_suspend_sec < 5)
+ now = ktime_get_real_seconds();
+ if (now - rtlhal->last_suspend_sec < 5)
return -1;
rtl_op_start(hw);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 20ffe856180e..ad28e188bd04 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1373,8 +1373,7 @@ static void _rtl8821ae_get_wakeup_reason(struct ieee80211_hw *hw)
ppsc->wakeup_reason = 0;
- do_gettimeofday(&ts);
- rtlhal->last_suspend_sec = ts.tv_sec;
+ rtlhal->last_suspend_sec = ktime_get_real_seconds();
switch (fw_reason) {
case FW_WOW_V2_PTK_UPDATE_EVENT:
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 22afc14c3da6..6f1b0f4667d9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1599,7 +1599,7 @@ struct rtl_hal {
bool enter_pnp_sleep;
bool wake_from_pnp_sleep;
bool wow_enabled;
- __kernel_time_t last_suspend_sec;
+ time64_t last_suspend_sec;
u32 wowlan_fwsize;
u8 *wowlan_firmware;
--
2.9.0
^ permalink raw reply related
* [PATCH 1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time
From: Arnd Bergmann @ 2017-11-06 13:55 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: Arnd Bergmann, stable, linux-wireless, netdev, linux-kernel
We set rtlhal->last_suspend_sec to an uninitialized stack variable,
but unfortunately gcc never warned about this, I only found it
while working on another patch. I opened a gcc bug for this.
Presumably the value of rtlhal->last_suspend_sec is not all that
important, but it does get used, so we probably want the
patch backported to stable kernels.
Cc: stable@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 60c82a5b51cd..20ffe856180e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1373,6 +1373,7 @@ static void _rtl8821ae_get_wakeup_reason(struct ieee80211_hw *hw)
ppsc->wakeup_reason = 0;
+ do_gettimeofday(&ts);
rtlhal->last_suspend_sec = ts.tv_sec;
switch (fw_reason) {
--
2.9.0
^ permalink raw reply related
* Re: rtl8821ae dbi read question
From: Larry Finger @ 2017-11-06 13:52 UTC (permalink / raw)
To: Nik Nyby, linux-wireless, pkshih
In-Reply-To: <ca520364-0d18-54c2-e6bc-b8245f8408ea@gnu.org>
On 11/05/2017 10:09 PM, Nik Nyby wrote:
> On 11/05/2017 09:09 PM, Larry Finger wrote:
>> Disabling all of _rtl8821ae_enable_aspm_back_door() may not be wise. We tried
>> that patch as part of debugging.
>>
>> That routine consists of two mdio r/w sequences, and 3 dbi r/w sequences. The
>> third one of the latter is only used for RTL8812AE, thus it can be ignored.
>>
>> What happens if you try disabling those r/w pairs one at a time? It is
>> possible that one, or more of them, should be disabled when aspm is zero.
>
> I first tried disabling only the mdio sequences, then the dbi sequences. I was
> able to reproduce my problem in both cases. But I have found that my problem is
> resolved by only removing the enable_aspm() call, and leaving the call to
> _rtl8821ae_enable_aspm_back_door() intact.
>
> If removing rtlpriv->intf_ops->enable_aspm(hw) is the same as setting aspm=0,
> then it's possible I'm not setting the option correctly. But as far as I can see
> right now, removing enable_aspm() is necessary for my stable connection.
Your results seem to indicate that aspm, which is support_aspm internally, is
not being set to zero. The first executable statement in enable_aspm is
if (!ppsc->support_aspm)
return;
That statement should disable the entire routine; however, you still need to
disable the call to this routine. It is possible that the timing is messed up
when built into the kernel. Building as a module will be instructive.
Larry
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Simon Shields @ 2017-11-06 11:27 UTC (permalink / raw)
To: Arend van Spriel
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
devicetree, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng
In-Reply-To: <5A004099.90200@broadcom.com>
On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
> On 11/4/2017 2:24 PM, Simon Shields wrote:
> > Some boards use an external 32khz clock for low-power
> > mode timing. Make sure the clock is powered on while the chipset
> > is active.
>
> Do you have such a board? With the little documentation I can get my hands
> on here I wonder whether the clock needs to be enabled before the device is
> powered. If you have the hardware I would like to check some registers in
> the device.
>
Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works fine
with this patch and one more that enables the WL_REG_EN pin when
brcmfmac is probed.
Without this patch (and only enabling WL_REG_EN), the chip is detected but
attempting to initialise it fails with a bunch of timeouts.
> Regards,
> Arend
Cheers,
Simon
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Arend van Spriel @ 2017-11-06 10:59 UTC (permalink / raw)
To: Simon Shields, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng
In-Reply-To: <20171104132421.GA1541@archbox.home>
On 11/4/2017 2:24 PM, Simon Shields wrote:
> Some boards use an external 32khz clock for low-power
> mode timing. Make sure the clock is powered on while the chipset
> is active.
Do you have such a board? With the little documentation I can get my
hands on here I wonder whether the clock needs to be enabled before the
device is powered. If you have the hardware I would like to check some
registers in the device.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Kalle Valo @ 2017-11-06 10:43 UTC (permalink / raw)
To: Simon Shields
Cc: devicetree, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng
In-Reply-To: <20171106102934.GA23805@lineageos.org>
Simon Shields <simon@lineageos.org> writes:
> Some boards use an external 32khz clock for low-power
> mode timing. Make sure the clock is powered on while the chipset
> is active.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
Then you submit a new version please always increase the version so that
I know which patch I should follow and take from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing
And yes yes, I know the patch content was identical in this case but
even a change in Cc field is important from my point of view. No need to
resend, this reply is also a reminder to me that this is the v2 :)
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2017-11-03
From: Kalle Valo @ 2017-11-06 10:38 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1509703364.4492.350.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Here's the final set of patches intended for v4.15. It's not too
> important to get them into v4.15 if there is no time anymore. There
> are a few new PCI IDs that can be added in the rc series or stable
> (they need to go to other stable releases anyway). And there's also
> one bugfix that I could also send to rc. The rest are just cleanups,
> improvements or related to the A000 series. Let me know how it goes
> and I'll adapt if needed.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
As you know we got one more week before the merge window starts, so I
should get this to v4.15.
> The following changes since commit e226fb5affccca98c405de80527180224d93d251:
>
> Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-11-02 19:48:25 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-11-03
>
> for you to fetch changes up to 57b36f7fcb39c5eae8c1f463699f747af69643ba:
>
> iwlwifi: add new cards for a000 series (2017-11-03 11:56:10 +0200)
>
> ----------------------------------------------------------------
> iwlwifi updates
>
> * Some new PCI IDs;
> * A bunch of cleanups;
> * The timers update by Kees;
> * Add more register dump call-sites;
> * A fix for a locking issue in the TX flush code;
> * Actual implementation of the TX flush code for A000;
> * An optimization to drop RX frames during restart to avoid BA issues;
>
> ----------------------------------------------------------------
> Emmanuel Grumbach (3):
> iwlwifi: mvm: rs: remove the ANT C from the toogle antenna logic
> iwlwifi: remove dead code for internal devices only
> iwlwifi: remove host assisted paging
>
> Ihab Zhaika (3):
> iwlwifi: add new cards for 8260 series
> iwlwifi: add new cards for 8265 series
> iwlwifi: add new cards for a000 series
>
> Kees Cook (1):
> iwlwifi: mvm: Convert timers to use timer_setup()
>
> Kirtika Ruchandani (1):
> iwlwifi: Add more call-sites for pcie reg dumper
>
> Liad Kaufman (1):
> iwlwifi: mvm: reset seq num after restart
>
> Luca Coelho (1):
> iwlwifi: mvm: hold mutex when flushing in iwl_mvm_flush_no_vif()
>
> Sara Sharon (6):
> iwlwifi: mvm: use RS macro instead of duplicating the code
> iwlwifi: mvm: cleanup references to aggregation count limit
> iwlwifi: mvm: improve latency when there is a reorder timeout
> iwlwifi: fix multi queue notification for a000 devices
> iwlwifi: mvm: refactor iwl_mvm_flush_no_vif
> iwlwifi: mvm: add missing implementation of flush for a000 devices
>
> Shahar S Matityahu (1):
> iwlwifi: drop RX frames during hardware restart
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox