From: Arend van Spriel <arend@broadcom.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "John W. Linville" <linville@tuxdriver.com>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 01/14] brcmfmac: add delay before unregistering the network device
Date: Wed, 26 Feb 2014 11:43:58 +0100 [thread overview]
Message-ID: <530DC56E.9040202@broadcom.com> (raw)
In-Reply-To: <1393407473.4133.5.camel@jlt4.sipsolutions.net>
On 02/26/2014 10:37 AM, Johannes Berg wrote:
> On Wed, 2014-02-26 at 10:28 +0100, Arend van Spriel wrote:
>
>>> Yes. Can't we just flush the work at some strategic place?
>>>
>>> Actually you're not talking about the "disconnect_work" (which is
>>> related to regulatory) but the "event_work" so I was confused here for a
>>> second.
>>>
>>> What was the warning? cfg80211 already calls
>>> cfg80211_process_wdev_events() from within the REMOVE netdev notifier,
>>> so that *shouldn't* have happened.
>>
>> I guess that means some wdev event is missing? It was the
>> WARN_ON(current->bss) that fired.
>
> Hmm, that's odd, the process_wdev_events() call is right before that, so
> I don't see how that could have happened?
Ok. The warning probably happened in earlier kernel, because our module
exit was buggy. I fixed that a while ago and I just verified I don't see
it without this patch. Sorry for bringing that diversion up.
Actually, this was not the reason for the doing the msleep(). The
problem was that wpa_supplicant received RTM_DELLINK, before getting the
NL08211_DISCONNECT. This resulted in RTM_DELLINK, immediately followed
by RTM_ADDLINK, followed by NL80211_DISCONNECT.
Gr. AvS
next prev parent reply other threads:[~2014-02-26 10:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 19:30 [PATCH 00/14] brcmfmac: driver cleanup and rework Arend van Spriel
2014-02-25 19:30 ` [PATCH 01/14] brcmfmac: add delay before unregistering the network device Arend van Spriel
2014-02-25 19:59 ` Johannes Berg
2014-02-26 9:07 ` Arend van Spriel
2014-02-26 9:17 ` Johannes Berg
2014-02-26 9:28 ` Arend van Spriel
2014-02-26 9:37 ` Johannes Berg
2014-02-26 10:43 ` Arend van Spriel [this message]
2014-02-26 11:10 ` Johannes Berg
2014-02-26 11:34 ` Arend van Spriel
2014-02-26 11:48 ` Johannes Berg
2014-02-26 12:18 ` Arend van Spriel
2014-02-26 12:22 ` Johannes Berg
2014-02-26 12:35 ` Arend van Spriel
2014-02-25 19:30 ` [PATCH 02/14] brcmfmac: Make firmeware roaming a module param Arend van Spriel
2014-02-25 19:30 ` [PATCH 03/14] brcmfmac: fix use of skb control buffer in SDIO driver part Arend van Spriel
2014-02-25 19:30 ` [PATCH 04/14] brcmfmac: remove unused variable data_len from brcmf_sdio_bus_txdata() Arend van Spriel
2014-02-25 19:30 ` [PATCH 05/14] brcmfmac: Correct header debug dump for sdio tx hdrs Arend van Spriel
2014-02-25 19:30 ` [PATCH 06/14] brcmfmac: de-init driver layers in correct order Arend van Spriel
2014-02-25 19:30 ` [PATCH 07/14] brcmfmac: Minimize SDIO dpc scheduling Arend van Spriel
2014-02-25 19:30 ` [PATCH 08/14] brcmfmac: Remove immediate sleep support from SDIO Arend van Spriel
2014-02-25 19:30 ` [PATCH 09/14] brcmfmac: Small cleanup of redundant code Arend van Spriel
2014-02-25 19:30 ` [PATCH 10/14] brcmfmac: Use atomic functions for intstatus update Arend van Spriel
2014-02-25 23:38 ` Florian Fainelli
2014-02-26 12:20 ` Arend van Spriel
2014-02-25 19:30 ` [PATCH 11/14] brcmfmac: Put frame sdio tx error handling in sub function Arend van Spriel
2014-02-25 19:30 ` [PATCH 12/14] brcmfmac: Correct mcs index report Arend van Spriel
2014-02-25 19:30 ` [PATCH 13/14] brcmfmac: use pre-allocated scatter-gather table for txglomming Arend van Spriel
2014-02-25 19:30 ` [PATCH 14/14] brcmfmac: reset suspend flag upon sdio suspend failure Arend van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530DC56E.9040202@broadcom.com \
--to=arend@broadcom.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.