Hi Dave,
After going through my patch queue, I have another set of fixes that I
think is still appropriate for the current cycle.
Two of my own restart changes there are fairly big but for the most
part just move code around so it can be called in a slightly different
order.
Let me know if there are any issues.
Thanks,
johannes
The following changes since commit c1df932c0574c13ab3ce72e969c9647ff3aaad68:
mac80211: fix off-channel mgmt-tx uninitialized variable usage (2015-12-02 22:27:53 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2015-12-15
for you to fetch changes up to cf1e05c63642ce65821a6277adfc2157f7334c9d:
mac80211: handle width changes from opmode notification IE in beacon (2015-12-15 13:16:47 +0100)
----------------------------------------------------------------
Another set of fixes:
* memory leak fixes (from Ola)
* operating mode notification spec compliance fix (from Eyal)
* copy rfkill names in case pointer becomes invalid (myself)
* two hardware restart fixes (myself)
* get rid of "limiting TX power" log spam (myself)
----------------------------------------------------------------
Eyal Shapira (1):
mac80211: handle width changes from opmode notification IE in beacon
Johannes Berg (4):
rfkill: copy the name into the rfkill struct
mac80211: run scan completed work on reconfig failure
mac80211: reprogram in interface order
mac80211: suppress unchanged "limiting TX power" messages
Ola Olsson (3):
nl80211: fix a few memory leaks in reg.c
nl80211: Fix potential memory leak in nl80211_set_wowlan
nl80211: Fix potential memory leak in nl80211_connect
net/mac80211/cfg.c | 3 +-
net/mac80211/ieee80211_i.h | 4 +-
net/mac80211/mlme.c | 17 ++++---
net/mac80211/rx.c | 3 +-
net/mac80211/util.c | 113 +++++++++++++++++++++++++--------------------
net/mac80211/vht.c | 10 ++--
net/rfkill/core.c | 6 +--
net/wireless/nl80211.c | 5 +-
net/wireless/reg.c | 5 +-
9 files changed, 92 insertions(+), 74 deletions(-)
On Wed, 2015-12-16 at 18:34 -0500, David Miller wrote:
>
> Something about your text encoding kept this from ending up
> in patchwork for some reason.
>
Hm. I don't see anything special with this, seems to just be plain text
8bit transfer encoding.
Do you want me to watch out for things getting into patchwork in the
future?
johannes
On Thu, 17 Dec 2015 12:04:48 -0500 (EST)
David Miller <[email protected]> wrote:
> From: Johannes Berg <[email protected]>
> Date: Thu, 17 Dec 2015 13:44:32 +0100
>
> > On Wed, 2015-12-16 at 18:34 -0500, David Miller wrote:
> >>
> >> Something about your text encoding kept this from ending up
> >> in patchwork for some reason.
> >>
> >
> > Hm. I don't see anything special with this, seems to just be plain
> > text 8bit transfer encoding.
> >
> > Do you want me to watch out for things getting into patchwork in the
> > future?
>
> Look in the quoted text of mine, see that underline thing after
> the ">>"? Where are those coming from? Those were all over the
> place in your pull request and tripped up patchwork's parser I
> guess.
I was curious and took a look. I suspect what you're seeing are the UTF-8
<0xC2 0xA0> sequence, which translates to codepoint 0x00A0 "no-break space"
(same as in latin1). They seem to have been used in place of regular spaces
for the purpose of indenting. The Content-Type charset in Johannes' emails
is "UTF-8", so I think that's legal. Although I have no idea how Patchwork
reacts to it.
From: Johannes Berg <[email protected]>
Date: Tue, 15 Dec 2015 13:30:21 +0100
> After going through my patch queue, I have another set of fixes that
> I think is still appropriate for the current cycle.
>
> Two of my own restart changes there are fairly big but for the most
> part just move code around so it can be called in a slightly different
> order.
>
> Let me know if there are any issues.
Something about your text encoding kept this from ending up
in patchwork for some reason.
Anyways, pulled, thanks a lot!
From: Johannes Berg <[email protected]>
Date: Thu, 17 Dec 2015 13:44:32 +0100
> On Wed, 2015-12-16 at 18:34 -0500, David Miller wrote:
>>?
>> Something about your text encoding kept this from ending up
>> in patchwork for some reason.
>>
>
> Hm. I don't see anything special with this, seems to just be plain text
> 8bit transfer encoding.
>
> Do you want me to watch out for things getting into patchwork in the
> future?
Look in the quoted text of mine, see that underline thing after
the ">>"? Where are those coming from? Those were all over the
place in your pull request and tripped up patchwork's parser I
guess.
On Thu, 2015-12-17 at 13:44 +0100, Johannes Berg wrote:
> On Wed, 2015-12-16 at 18:34 -0500, David Miller wrote:
> > ?
> > Something about your text encoding kept this from ending up
> > in patchwork for some reason.
> >
>
> Hm. I don't see anything special with this, seems to just be plain
> text
> 8bit transfer encoding.
>
> Do you want me to watch out for things getting into patchwork in the
> future?
>
Hey Johannes.
You seem to be using:
X-Mailer: Evolution 3.18.1-1?
which, to be overly technical, _sucks_.
The new composer for Evolution has way too many defects
to list.
It adds non-breaking spaces (NBSP) characters instead of
a standard ASCII space in various places.
Every version of Evolution since 3.14 is terrible at
sending text only messages.
3.12 works