* Re: [PATCH 1/3] rsi: Fix memory leak in module unload
From: Kalle Valo @ 2016-10-26 6:47 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: Prameela Rani Garnepudi, linux-wireless, johannes.berg, hofrat,
xypron.glpk
In-Reply-To: <7a4d28a2-53ac-bc81-bf2c-452434d6768e@redpinesignals.com>
Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com> writes:
> On 10/13/2016 07:56 PM, Kalle Valo wrote:
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>>> Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
>>>
>>>> Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set.
>>>> Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in
>>>> function rsi_mac80211_detach()
>>>> Memory leak found and fixed for below structures in function
> rsi_mac80211_detach()
>>>> * channel list for each supported band
>>>> * rsi debugfs info
>>>>
>>>> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>>> BTW, I don't see patch 2 in patchwork nor in linux-wireless, but I do
>>> see it on my inbox. Either it's slow or there was a problem with the
>>> delivery.
>> It was just slow, I see it now:
>>
>> https://patchwork.kernel.org/patch/9374987/
>>
> Hi,
> Can you please review this patch.
wireless-drivers-next is not open yet as I was on vacation last week,
hoping to open it today.
And instead of mailing me please check the status from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
If you see lots of patches pending submitted around the same time as
yours it's a pretty good hint that I just haven't been able to go
through my queue:
https://patchwork.kernel.org/project/linux-wireless/list/?state=*&delegate=25621
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Kalle Valo @ 2016-10-26 6:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Hante Meuleman,
Franky Lin, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Rafał Miłecki, linux-wireless, brcm80211-dev-list.pdl,
netdev
In-Reply-To: <20161017221355.1861551-7-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> A bugfix added a sanity check around the assignment and use of the
> 'is_11d' variable, which looks correct to me, but as the function is
> rather complex already, this confuses the compiler to the point where
> it can no longer figure out if the variable is always initialized
> correctly:
>
> brcm80211/brcmfmac/cfg80211.c: In function =E2=80=98brcmf_cfg80211_start_=
ap=E2=80=99:
> brcm80211/brcmfmac/cfg80211.c:4586:10: error: =E2=80=98is_11d=E2=80=99 ma=
y be used uninitialized in this function [-Werror=3Dmaybe-uninitialized]
>
> This adds an initialization for the newly introduced case in which
> the variable should not really be used, in order to make the warning
> go away.
>
> Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Via which tree are you planning to submit this? Should I take it?
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 3/7] iwlwifi: mvm: fix d3_test with unified D0/D3 images
From: Kalle Valo @ 2016-10-26 6:59 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless
In-Reply-To: <1477464427.27792.5.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> On Wed, 2016-10-26 at 09:19 +0300, Kalle Valo wrote:
>> Luca Coelho <luca@coelho.fi> writes:
>>
>> > From: Luca Coelho <luciano.coelho@intel.com>
>> >
>> > When a unified D0/D3 image is used, we don't restart the FW in the
>> > D0->D3->D0 transitions. Therefore, the d3_test functionality should
>> > not call ieee8021_restart_hw() when the resuming either.
>> >
>> > Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend")
>>
>> The word "commit" is not needed in the Fixes line, but no need to change
>> that now.
>
> Oh, I didn't know that. Thanks for pointing out. I'll keep it in mind
> for future patches.
Related to this Documentation/SubmittingPatches has a handy tip:
----------------------------------------------------------------------
The following ``git config`` settings can be used to add a pretty format for
outputting the above style in the ``git log`` or ``git show`` commands::
[core]
abbrev = 12
[pretty]
fixes = Fixes: %h (\"%s\")
----------------------------------------------------------------------
And then you can do just:
$ git show --format=fixes 23ae61282b88 | head -1
Fixes: 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend")
$
Perfect for a lazy person like me :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 09/10] iwlwifi: mvm: operate in dqa mode
From: Kalle Valo @ 2016-10-26 7:14 UTC (permalink / raw)
To: Coelho, Luciano; +Cc: linux-wireless@vger.kernel.org, Kaufman, Liad
In-Reply-To: <1477464284.27792.4.camel@intel.com>
"Coelho, Luciano" <luciano.coelho@intel.com> writes:
> Hi Kalle,
>
> On Wed, 2016-10-26 at 09:32 +0300, Kalle Valo wrote:
>> Luca Coelho <luca@coelho.fi> writes:
>>=20
>> > From: Liad Kaufman <liad.kaufman@intel.com>
>> >=20
>> > Run DQA flows by default, as long as the FW supports it.
>> >=20
>> > Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
>> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>>=20
>> What's this DQA mode? A short summary would have been nice why it's
>> useful.
>
> DQA is Dynamic Queue Allocation. =C2=A0We have been working on this for
> quite a while now (since v4.7) and have many patches mentioning that
> are already merged. The first patch is this:
>
> commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc
> of queues")
Yeah, but that's commited over six month ago.
> Its commit message has some explanation and we also have a DOC section
> in our driver that explains it in further details:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.=
git/tree/drivers/net/wireless/intel/iwlwifi/mvm/sta.h#n82
And that's too detailed. I was hoping more like an executive summary in
few sentences.
> Since we've been working on this for so long and already use the term
> DQA broadly, we thought it wouldn't be necessary to explain more when
> we are finally enabling it by default. But of course I can change that
> if you prefer.
I guessed I could find more information from the history and I know this
is obvious to your team, but it's not obvious to everyone. The commit
log should always answer the questions "Why?" and this isn't answering
that. For example, I need this information when sending pull requests to
Dave and I'm sure lots of other people find it useful as well,
especially when enabling a new feature.
So I'm not asking for a long essay, something like this would be
adequate:
"Run DQA flows by default, as long as the FW supports it. It's currently
supported on 1234, 3456 and 7654, maybe more in the future. DQA improves
latency when X is used or throughput when Y is disabled. On the downside
it sometimes slows down throughput when using Z but that's still
accetable as it's so rarely used."
But no need to change anything for this commit, but just keep in mind
for the future.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 09/10] iwlwifi: mvm: operate in dqa mode
From: Valo, Kalle @ 2016-10-26 7:23 UTC (permalink / raw)
To: Coelho, Luciano; +Cc: linux-wireless@vger.kernel.org, Kaufman, Liad
In-Reply-To: <87r37360qq.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
>> Since we've been working on this for so long and already use the term
>> DQA broadly, we thought it wouldn't be necessary to explain more when
>> we are finally enabling it by default. But of course I can change that
>> if you prefer.
>
> I guessed I could find more information from the history and I know this
> is obvious to your team, but it's not obvious to everyone. The commit
> log should always answer the questions "Why?" and this isn't answering
> that. For example, I need this information when sending pull requests to
> Dave and I'm sure lots of other people find it useful as well,
> especially when enabling a new feature.
>
> So I'm not asking for a long essay, something like this would be
> adequate:
>
> "Run DQA flows by default, as long as the FW supports it. It's currently
> supported on 1234, 3456 and 7654, maybe more in the future. DQA improves
> latency when X is used or throughput when Y is disabled. On the downside
> it sometimes slows down throughput when using Z but that's still
> accetable as it's so rarely used."
Oh, I forgot that the acronym should be also spelled out in the commit
log.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH 3/7] iwlwifi: mvm: fix d3_test with unified D0/D3 images
From: Luca Coelho @ 2016-10-26 7:26 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87vawf61eo.fsf@kamboji.qca.qualcomm.com>
On Wed, 2016-10-26 at 09:59 +0300, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
> > On Wed, 2016-10-26 at 09:19 +0300, Kalle Valo wrote:
> > > Luca Coelho <luca@coelho.fi> writes:
> > >
> > > > From: Luca Coelho <luciano.coelho@intel.com>
> > > >
> > > > When a unified D0/D3 image is used, we don't restart the FW in the
> > > > D0->D3->D0 transitions. Therefore, the d3_test functionality should
> > > > not call ieee8021_restart_hw() when the resuming either.
> > > >
> > > > Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend")
> > >
> > > The word "commit" is not needed in the Fixes line, but no need to change
> > > that now.
> >
> > Oh, I didn't know that. Thanks for pointing out. I'll keep it in mind
> > for future patches.
>
> Related to this Documentation/SubmittingPatches has a handy tip:
>
> ----------------------------------------------------------------------
> The following ``git config`` settings can be used to add a pretty format for
> outputting the above style in the ``git log`` or ``git show`` commands::
>
> [core]
> abbrev = 12
> [pretty]
> fixes = Fixes: %h (\"%s\")
> ----------------------------------------------------------------------
>
> And then you can do just:
>
> $ git show --format=fixes 23ae61282b88 | head -1
> Fixes: 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend")
> $
>
> Perfect for a lazy person like me :)
Wow, really perfect for me too! Thanks! I should read SubmittingPatches
more often. :)
--
Luca.
^ permalink raw reply
* [PATCH v2] iwlwifi: mvm: enable dynamic queue allocation mode
From: Luca Coelho @ 2016-10-26 8:09 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Liad Kaufman, Luca Coelho
In-Reply-To: <20161019100755.23874-10-luca@coelho.fi>
From: Liad Kaufman <liad.kaufman@intel.com>
New firmwares support dynamic queue allocation (DQA), which enables
on-demand allocation of queues per RA/TID, instead of allocating them
statically per vif. This allows an AP to send, for instance, BE
traffic to STA2 even if it also needs to send traffic to a sleeping
STA1, without being blocked by the sleeping station.
The implementation in the driver is now ready, so we can enable this
feature by default when running firmwares that support it.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
[reworded the commit message]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 726ba48..cde8c6c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1111,9 +1111,8 @@ static inline bool iwl_mvm_is_d0i3_supported(struct iwl_mvm *mvm)
static inline bool iwl_mvm_is_dqa_supported(struct iwl_mvm *mvm)
{
- /* Make sure DQA isn't allowed in driver until feature is complete */
- return false && fw_has_capa(&mvm->fw->ucode_capa,
- IWL_UCODE_TLV_CAPA_DQA_SUPPORT);
+ return fw_has_capa(&mvm->fw->ucode_capa,
+ IWL_UCODE_TLV_CAPA_DQA_SUPPORT);
}
static inline bool iwl_mvm_enter_d0i3_on_suspend(struct iwl_mvm *mvm)
--
2.9.3
^ permalink raw reply related
* pull-request: iwlwifi-next 2016-10-25-2
From: Luca Coelho @ 2016-10-26 8:13 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]
Hi Kalle,
Here's an updated pull-request, replacing 2016-10-25, with one commit
message reworded, as you requested.
I sent v2 of that patch to the linux-wireless mailing list.
Let me know if everything's fine (or not). :)
Luca.
The following changes since commit 15b95a15950238eff4d7f24be1716086eea67835:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2016-09-28 16:37:33 +0300)
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-2016-10-25-2
for you to fetch changes up to 7e62a699aafbd97928f19a8356d719b71b0e151c:
iwlwifi: mvm: use dev_coredumpsg() (2016-10-26 11:04:15 +0300)
----------------------------------------------------------------
* Finalize and enable dynamic queue allocation;
* Use dev_coredumpmsg() to prevent locking the driver;
* Small fix to pass the AID to the FW;
* Use FW PS decisions with multi-queue;
----------------------------------------------------------------
Aviya Erenfeld (1):
iwlwifi: mvm: use dev_coredumpsg()
Emmanuel Grumbach (1):
iwlwifi: mvm: tell the firmware about the AID of the peer
Johannes Berg (1):
iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS
Liad Kaufman (5):
iwlwifi: mvm: update txq metadata to current owner
iwlwifi: mvm: fix reserved txq freeing
iwlwifi: mvm: support MONITOR vif in DQA mode
iwlwifi: mvm: fix dqa deferred frames marking
iwlwifi: mvm: enable dynamic queue allocation mode
Sara Sharon (1):
iwlwifi: mvm: assign cab queue to the correct station
Sharon Dvir (1):
iwlwifi: pcie: give a meaningful name to interrupt request
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 2 ++
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h | 26 ++++++++++++++++++++
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-sta.h | 9 ++++---
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 100 +++++++++++++++++++++++++++++++++++++++++----------------------------------
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 24 +++++++++---------
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 ++---
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 +++
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 37 ++++++++++++++++++++++------
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 29 +++++++++++++++++++++-
12 files changed, 249 insertions(+), 75 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: use inline kernel-doc for struct ieee80211_hw
From: Jani Nikula @ 2016-10-26 8:36 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: linux-doc
In-Reply-To: <1477462177.4059.19.camel@sipsolutions.net>
On Wed, 26 Oct 2016, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2016-10-21 at 15:57 +0300, Jani Nikula wrote:
>> It's easier to manage the kernel-doc for the fields when they
>> documentation is next to the field.
>
> Ok, actually, this doesn't apply. Perhaps I'll look into scripting this
> kind of conversion.
No problem; I'll leave it up to you.
BR,
Jani.
>
> johannes
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Thomas Graf @ 2016-10-26 8:53 UTC (permalink / raw)
To: davem; +Cc: johannes, daniel, netdev, linux-wireless
Wrap several common instances of:
kmemdup(nla_data(attr), nla_len(attr), GFP_KERNEL);
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
include/net/netlink.h | 10 ++++++++++
net/sched/act_bpf.c | 4 +---
net/sched/cls_bpf.c | 4 +---
net/wireless/nl80211.c | 3 +--
4 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 254a0fc..a34f53a 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -1191,6 +1191,16 @@ static inline struct in6_addr nla_get_in6_addr(const struct nlattr *nla)
}
/**
+ * nla_memdup - duplicate attribute memory (kmemdup)
+ * @src: netlink attribute to duplicate from
+ * @gfp: GFP mask
+ */
+static inline void *nla_memdup(const struct nlattr *src, gfp_t gfp)
+{
+ return kmemdup(nla_data(src), nla_len(src), gfp);
+}
+
+/**
* nla_nest_start - Start a new level of nested attributes
* @skb: socket buffer to add attributes to
* @attrtype: attribute type of container
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index 1d39600..9ff06cf 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -226,9 +226,7 @@ static int tcf_bpf_init_from_efd(struct nlattr **tb, struct tcf_bpf_cfg *cfg)
return PTR_ERR(fp);
if (tb[TCA_ACT_BPF_NAME]) {
- name = kmemdup(nla_data(tb[TCA_ACT_BPF_NAME]),
- nla_len(tb[TCA_ACT_BPF_NAME]),
- GFP_KERNEL);
+ name = nla_memdup(tb[TCA_ACT_BPF_NAME], GFP_KERNEL);
if (!name) {
bpf_prog_put(fp);
return -ENOMEM;
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index bb1d5a4..52dc85a 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -369,9 +369,7 @@ static int cls_bpf_prog_from_efd(struct nlattr **tb, struct cls_bpf_prog *prog,
return PTR_ERR(fp);
if (tb[TCA_BPF_NAME]) {
- name = kmemdup(nla_data(tb[TCA_BPF_NAME]),
- nla_len(tb[TCA_BPF_NAME]),
- GFP_KERNEL);
+ name = nla_memdup(tb[TCA_BPF_NAME], GFP_KERNEL);
if (!name) {
bpf_prog_put(fp);
return -ENOMEM;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c510810..7bfe1e0 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10638,8 +10638,7 @@ static int handle_nan_filter(struct nlattr *attr_filter,
i = 0;
nla_for_each_nested(attr, attr_filter, rem) {
- filter[i].filter = kmemdup(nla_data(attr), nla_len(attr),
- GFP_KERNEL);
+ filter[i].filter = nla_memdup(attr, GFP_KERNEL);
filter[i].len = nla_len(attr);
i++;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] mac80211: use inline kernel-doc for struct ieee80211_hw
From: Johannes Berg @ 2016-10-26 8:55 UTC (permalink / raw)
To: Jani Nikula, linux-wireless; +Cc: linux-doc
In-Reply-To: <87bmy7mrq1.fsf@intel.com>
On Wed, 2016-10-26 at 11:36 +0300, Jani Nikula wrote:
> On Wed, 26 Oct 2016, Johannes Berg <johannes@sipsolutions.net> wrote:
> >
> > On Fri, 2016-10-21 at 15:57 +0300, Jani Nikula wrote:
> > >
> > > It's easier to manage the kernel-doc for the fields when they
> > > documentation is next to the field.
> >
> > Ok, actually, this doesn't apply. Perhaps I'll look into scripting
> > this
> > kind of conversion.
>
> No problem; I'll leave it up to you.
I'll probably end up doing it manually though - no chance I can extend
the parser to output an spatch (doing the comment placement with spatch
actually works, but getting there...)
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Johannes Berg @ 2016-10-26 8:56 UTC (permalink / raw)
To: Thomas Graf, davem; +Cc: daniel, netdev, linux-wireless
In-Reply-To: <2d0864c85200f1b42b1ebceee7c2dc60fe29f26a.1477471562.git.tgraf@suug.ch>
On Wed, 2016-10-26 at 10:53 +0200, Thomas Graf wrote:
> Wrap several common instances of:
> kmemdup(nla_data(attr), nla_len(attr), GFP_KERNEL);
Makes sense
Acked-by: Johannes Berg <johannes@sipsolutions.net>
johannes
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Daniel Borkmann @ 2016-10-26 8:57 UTC (permalink / raw)
To: Thomas Graf, davem; +Cc: johannes, netdev, linux-wireless
In-Reply-To: <2d0864c85200f1b42b1ebceee7c2dc60fe29f26a.1477471562.git.tgraf@suug.ch>
On 10/26/2016 10:53 AM, Thomas Graf wrote:
> Wrap several common instances of:
> kmemdup(nla_data(attr), nla_len(attr), GFP_KERNEL);
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Thanks!
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Johannes Berg @ 2016-10-26 8:59 UTC (permalink / raw)
To: Thomas Graf, davem; +Cc: daniel, netdev, linux-wireless
In-Reply-To: <2d0864c85200f1b42b1ebceee7c2dc60fe29f26a.1477471562.git.tgraf@suug.ch>
> /**
> + * nla_memdup - duplicate attribute memory (kmemdup)
> + * @src: netlink attribute to duplicate from
> + * @gfp: GFP mask
Actually, is there any point in passing a GFP mask? None of the current
users need it, and it seems fairly unlikely to be needed since this is
typically used on the netlink input path, where you surely shouldn't
need GFP_ATOMIC or so?
johannes
^ permalink raw reply
* [PATCH] NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
From: Tobias Klauser @ 2016-10-26 9:00 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr
Cc: Samuel Ortiz, linux-wireless, linux-kernel, Vincent Cuissard
Including linux/unaligned/access_ok.h causes the allmodconfig build on
ia64 (and maybe others) to fail with the following warnings:
include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'
include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32'
include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64'
include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16'
include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32'
include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64'
include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64'
Fix these by including asm/unaligned.h instead and leave it up to the
architecture to decide how to implement unaligned accesses.
Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Link: https://lkml.org/lkml/2016/10/22/247
Cc: Vincent Cuissard <cuissard@marvell.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/nfc/nfcmrvl/fw_dnld.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/nfcmrvl/fw_dnld.c b/drivers/nfc/nfcmrvl/fw_dnld.c
index f8dcdf4b24f6..441c1b0ec7b5 100644
--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -17,7 +17,7 @@
*/
#include <linux/module.h>
-#include <linux/unaligned/access_ok.h>
+#include <asm/unaligned.h>
#include <linux/firmware.h>
#include <linux/nfc.h>
#include <net/nfc/nci.h>
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
From: Tobias Klauser @ 2016-10-26 9:03 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr
Cc: Samuel Ortiz, linux-wireless, linux-kernel, Vincent Cuissard,
Guenter Roeck
In-Reply-To: <20161026090012.29747-1-tklauser@distanz.ch>
On 2016-10-26 at 11:00:12 +0200, Tobias Klauser <tklauser@distanz.ch> wrote:
> Including linux/unaligned/access_ok.h causes the allmodconfig build on
> ia64 (and maybe others) to fail with the following warnings:
>
> include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'
> include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32'
> include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64'
> include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16'
> include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32'
> include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64'
> include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64'
>
> Fix these by including asm/unaligned.h instead and leave it up to the
> architecture to decide how to implement unaligned accesses.
>
> Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Link: https://lkml.org/lkml/2016/10/22/247
> Cc: Vincent Cuissard <cuissard@marvell.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
There are two other instances of the same issue in the NFC subsystem,
namely in drivers/nfc/nxp-nci/firmware.c and drivers/nfc/nxp-nci/i2c.c
Guenter Roeck already sent a patch for these on 2015-08-01. It would be
nice if it could be applied as well.
[1] https://patchwork.kernel.org/patch/6922341/
Thanks
^ permalink raw reply
* Re: [PATCH 5/8] cfg80211: Add KEK/nonces for FILS association frames
From: Malinen, Jouni @ 2016-10-26 9:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1477460187.4059.4.camel@sipsolutions.net>
T24gV2VkLCBPY3QgMjYsIDIwMTYgYXQgMDc6MzY6MjdBTSArMDIwMCwgSm9oYW5uZXMgQmVyZyB3
cm90ZToNCj4gPiArKysgYi9uZXQvd2lyZWxlc3Mvbmw4MDIxMS5jDQo+ID4gKwlbTkw4MDIxMV9B
VFRSX0ZJTFNfS0VLXSA9IHsgLnR5cGUgPSBOTEFfQklOQVJZLA0KPiA+ICsJCQkJwqDCoMKgwqAu
bGVuID0gRklMU19NQVhfS0VLX0xFTiB9LA0KPiA+ICsJW05MODAyMTFfQVRUUl9GSUxTX05PTkNF
U10gPSB7IC50eXBlID0gTkxBX0JJTkFSWSwNCj4gPiArCQkJCcKgwqDCoMKgwqDCoMKgLmxlbiA9
IDIgKiBGSUxTX05PTkNFX0xFTiB9LA0KDQo+IElmIHlvdSByZW1vdmUgdGhlIHR5cGUgPSBOTEFf
QklOQVJZIGFuZCBqdXN0IGxlYXZlIHRoZSB0eXBlIHplcm8sIHRoZW4NCj4geW91J2xsIGdldCAq
bWluaW11bSogbGVuZ3RoIHZhbGlkYXRpb24sIHJhdGhlciB0aGFuIGxpbWl0aW5nIHRoZQ0KPiBt
YXhpbXVtIGxlbmd0aC4gVGhhdCBzZWVtcyBtb3JlIGFwcHJvcHJpYXRlIGZvciB0aGUgbm9uY2Vz
Pw0KDQpGSUxTX0tFSyBpcyB2YXJpYWJsZSBsZW5ndGgsIGJ1dCBGSUxTX05PTkNFUyBzaG91bGQg
YmUgZXhhY3RseSAyICoNCkZJTFNfTk9OQ0VfTEVOLiBJIGRpZG4ndCByZW1lbWJlciB0aGUgbWlu
aW11bSBsZW5ndGggY2FzZSBoZXJlLCBidXQgeWVzLA0KdGhhdCBzb3VuZHMgcmVhc29uYWJsZSBm
b3IgRklMU19OT05DRVMuDQoNCj4gPiArCWlmIChpbmZvLT5hdHRyc1tOTDgwMjExX0FUVFJfRklM
U19OT05DRVNdKSB7DQo+ID4gKwkJaWYgKG5sYV9sZW4oaW5mby0+YXR0cnNbTkw4MDIxMV9BVFRS
X0ZJTFNfTk9OQ0VTXSkNCj4gPiAhPQ0KPiA+ICsJCcKgwqDCoMKgMiAqIEZJTFNfTk9OQ0VfTEVO
KQ0KPiA+ICsJCQlyZXR1cm4gLUVJTlZBTDsNCj4gDQo+IFlvdSdyZSB2YWxpZGF0aW5nIHRoZSAq
ZXhhY3QqIGxlbmd0aCBoZXJlLCB3aGljaCB1bmZvcnR1bmF0ZWx5IG5sYXR0cg0KPiBkb2Vzbid0
IHN1cHBvcnQgcmlnaHQgbm93LCBidXQgcGVyaGFwcyB3ZSBjYW4gbGl2ZSB3aXRoIGNoZWNraW5n
IHRoYXQNCj4gaXQncyBhdCBsZWFzdCB0aGF0IG1hbnkgYnl0ZXMsIGFuZCB1c2luZyBvbmx5IDIq
bm9uY2VzPyBXZSBkbyB0aGF0IGZvcg0KPiBtb3N0IG90aGVyIGF0dHJpYnV0ZXMgKGxpa2UgTUFD
IGFkZHJlc3NlcykuDQoNClRoaXMgd2FzIGJlY2F1c2Ugb2YgdGhlIC5sZW4gYWJvdmUgZW5kaW5n
IHVwIGFsbG93aW5nIHNob3J0ZXIgdmFsdWVzLi4NClNpbmNlIHdlIGRvIHRoYXQgbWluaW11bSBs
ZW5ndGggY2hlY2sgb25seSBmb3IgbnVtYmVyIG9mIG90aGVyDQphdHRyaWJ1dGVzLCBJIGd1ZXNz
IHdlIGNhbiBkbyBpdCBoZXJlIGFzIHdlbGwgYW5kIGlnbm9yZSB3aGF0ZXZlciBlbHNlDQp0aGUg
dXNlciBzcGFjZSBtaWdodCBoYXZlIGFkZGVkIGluY29ycmVjdGx5Lg0KDQo+IE9yIGRvIHdlIGV4
cGVjdCB0byBleHRlbmQgdGhpcyB0byBtb3JlIHRoYW4gMiBub25jZXMgaW4gdGhlIGZ1dHVyZSwg
YXQNCj4gd2hpY2ggcG9pbnQgd2UnbGwgbmVlZCB0aGUgbGVuZ3RoPw0KDQpObywgdGhpcyBzaG91
bGQgcmVtYWluIGV4YWN0bHkgdHdvIG5vbmNlcyBhbmQgZWFjaCBvZiB0aG9zZSBoYXZpbmcNCmV4
YWN0bHkgMTYgb2N0ZXRzLg0KDQotLSANCkpvdW5pIE1hbGluZW4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFBHUCBpZCBFRkM4OTVGQQ==
^ permalink raw reply
* Re: [PATCH 8/8] mac80211: Claim Fast Initial Link Setup (FILS) support
From: Malinen, Jouni @ 2016-10-26 9:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1477461036.4059.14.camel@sipsolutions.net>
On Wed, Oct 26, 2016 at 07:50:36AM +0200, Johannes Berg wrote:
> On Wed, 2016-10-26 at 01:44 +0300, Jouni Malinen wrote:
> > With the previous commits, initial FILS support is now functional in
> > mac80211-based drivers for both AP and stations roles.
>=20
> That's a bit misleading, I guess AP role is handled entirely in
> hostapd? You documented the extended feature bit to explicitly mean
> station role only :)
Yeah.. In case of mac80211, there was not really changes needed in the
kernel side for AP mode. That may be different with non-mac80211
drivers, though, since they might be easier to handle with the AES-SIV
operations for associations frames handled within the driver.
Would you prefer to split that NL80211_EXT_FEATURE_FILS into two
separate values (_STA and _AP) and have mac80211 advertise both? Or just
add a _STA only case for now and see what we need to do with
NL80211_ATTR_DEVICE_AP_SME cases separately once such a thing is in in
functional state?
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: [PATCH 8/8] mac80211: Claim Fast Initial Link Setup (FILS) support
From: Johannes Berg @ 2016-10-26 9:26 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20161026092315.GB3660@jouni.qca.qualcomm.com>
On Wed, 2016-10-26 at 09:23 +0000, Malinen, Jouni wrote:
> On Wed, Oct 26, 2016 at 07:50:36AM +0200, Johannes Berg wrote:
> >
> > On Wed, 2016-10-26 at 01:44 +0300, Jouni Malinen wrote:
> > >
> > > With the previous commits, initial FILS support is now functional
> > > in
> > > mac80211-based drivers for both AP and stations roles.
> >
> > That's a bit misleading, I guess AP role is handled entirely in
> > hostapd? You documented the extended feature bit to explicitly mean
> > station role only :)
>
> Yeah.. In case of mac80211, there was not really changes needed in
> the kernel side for AP mode. That may be different with non-mac80211
> drivers, though, since they might be easier to handle with the AES-
> SIV operations for associations frames handled within the driver.
Right.
> Would you prefer to split that NL80211_EXT_FEATURE_FILS into two
> separate values (_STA and _AP)
I think having it called _STA may be a little clearer, but I think I'm
OK with it the way it is (documented as station) as well.
> and have mac80211 advertise both?
I wouldn't do that, there's nothing that makes it have that capability.
> Or just add a _STA only case for now and see what we need to do with
> NL80211_ATTR_DEVICE_AP_SME cases separately once such a thing is in
> in functional state?
Yeah, we should do that.
Really all I thought you should do was reword the commit message to
make it clear that the flag only implied the station case, and that the
AP case needed no changes.
Perhaps renaming the flag to ..._STA will make that a bit clearer.
johannes
^ permalink raw reply
* [PATCH] nl80211: move unsplit command advertising to a separate function
From: Johannes Berg @ 2016-10-26 9:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When we split the wiphy dump because it got too large, I added a
comment and asked that all new command advertising be done only
for userspace clients capable of receiving split data, in order
to not break older ones (which can't use the new commands anyway)
This mostly worked, and we haven't added many new commands, but
I occasionally get patches that modify the wrong place.
Make this easier to detect and understand by splitting out the
old commands to a separate function that makes it more clear it
should never be modified again.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 142 +++++++++++++++++++++++++++----------------------
1 file changed, 79 insertions(+), 63 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46cd48993ce9..b0440de82171 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1328,6 +1328,82 @@ nl80211_send_mgmt_stypes(struct sk_buff *msg,
return 0;
}
+#define CMD(op, n) \
+ do { \
+ if (rdev->ops->op) { \
+ i++; \
+ if (nla_put_u32(msg, i, NL80211_CMD_ ## n)) \
+ goto nla_put_failure; \
+ } \
+ } while (0)
+
+static int nl80211_add_commands_unsplit(struct cfg80211_registered_device *rdev,
+ struct sk_buff *msg)
+{
+ int i = 0;
+
+ /*
+ * do *NOT* add anything into this function, new things need to be
+ * advertised only to new versions of userspace that can deal with
+ * the split (and they can't possibly care about new features...
+ */
+ CMD(add_virtual_intf, NEW_INTERFACE);
+ CMD(change_virtual_intf, SET_INTERFACE);
+ CMD(add_key, NEW_KEY);
+ CMD(start_ap, START_AP);
+ CMD(add_station, NEW_STATION);
+ CMD(add_mpath, NEW_MPATH);
+ CMD(update_mesh_config, SET_MESH_CONFIG);
+ CMD(change_bss, SET_BSS);
+ CMD(auth, AUTHENTICATE);
+ CMD(assoc, ASSOCIATE);
+ CMD(deauth, DEAUTHENTICATE);
+ CMD(disassoc, DISASSOCIATE);
+ CMD(join_ibss, JOIN_IBSS);
+ CMD(join_mesh, JOIN_MESH);
+ CMD(set_pmksa, SET_PMKSA);
+ CMD(del_pmksa, DEL_PMKSA);
+ CMD(flush_pmksa, FLUSH_PMKSA);
+ if (rdev->wiphy.flags & WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL)
+ CMD(remain_on_channel, REMAIN_ON_CHANNEL);
+ CMD(set_bitrate_mask, SET_TX_BITRATE_MASK);
+ CMD(mgmt_tx, FRAME);
+ CMD(mgmt_tx_cancel_wait, FRAME_WAIT_CANCEL);
+ if (rdev->wiphy.flags & WIPHY_FLAG_NETNS_OK) {
+ i++;
+ if (nla_put_u32(msg, i, NL80211_CMD_SET_WIPHY_NETNS))
+ goto nla_put_failure;
+ }
+ if (rdev->ops->set_monitor_channel || rdev->ops->start_ap ||
+ rdev->ops->join_mesh) {
+ i++;
+ if (nla_put_u32(msg, i, NL80211_CMD_SET_CHANNEL))
+ goto nla_put_failure;
+ }
+ CMD(set_wds_peer, SET_WDS_PEER);
+ if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) {
+ CMD(tdls_mgmt, TDLS_MGMT);
+ CMD(tdls_oper, TDLS_OPER);
+ }
+ if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN)
+ CMD(sched_scan_start, START_SCHED_SCAN);
+ CMD(probe_client, PROBE_CLIENT);
+ CMD(set_noack_map, SET_NOACK_MAP);
+ if (rdev->wiphy.flags & WIPHY_FLAG_REPORTS_OBSS) {
+ i++;
+ if (nla_put_u32(msg, i, NL80211_CMD_REGISTER_BEACONS))
+ goto nla_put_failure;
+ }
+ CMD(start_p2p_device, START_P2P_DEVICE);
+ CMD(set_mcast_rate, SET_MCAST_RATE);
+#ifdef CONFIG_NL80211_TESTMODE
+ CMD(testmode_cmd, TESTMODE);
+#endif
+ return i;
+ nla_put_failure:
+ return -ENOBUFS;
+}
+
struct nl80211_dump_wiphy_state {
s64 filter_wiphy;
long start;
@@ -1555,68 +1631,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
if (!nl_cmds)
goto nla_put_failure;
- i = 0;
-#define CMD(op, n) \
- do { \
- if (rdev->ops->op) { \
- i++; \
- if (nla_put_u32(msg, i, NL80211_CMD_ ## n)) \
- goto nla_put_failure; \
- } \
- } while (0)
-
- CMD(add_virtual_intf, NEW_INTERFACE);
- CMD(change_virtual_intf, SET_INTERFACE);
- CMD(add_key, NEW_KEY);
- CMD(start_ap, START_AP);
- CMD(add_station, NEW_STATION);
- CMD(add_mpath, NEW_MPATH);
- CMD(update_mesh_config, SET_MESH_CONFIG);
- CMD(change_bss, SET_BSS);
- CMD(auth, AUTHENTICATE);
- CMD(assoc, ASSOCIATE);
- CMD(deauth, DEAUTHENTICATE);
- CMD(disassoc, DISASSOCIATE);
- CMD(join_ibss, JOIN_IBSS);
- CMD(join_mesh, JOIN_MESH);
- CMD(set_pmksa, SET_PMKSA);
- CMD(del_pmksa, DEL_PMKSA);
- CMD(flush_pmksa, FLUSH_PMKSA);
- if (rdev->wiphy.flags & WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL)
- CMD(remain_on_channel, REMAIN_ON_CHANNEL);
- CMD(set_bitrate_mask, SET_TX_BITRATE_MASK);
- CMD(mgmt_tx, FRAME);
- CMD(mgmt_tx_cancel_wait, FRAME_WAIT_CANCEL);
- if (rdev->wiphy.flags & WIPHY_FLAG_NETNS_OK) {
- i++;
- if (nla_put_u32(msg, i, NL80211_CMD_SET_WIPHY_NETNS))
- goto nla_put_failure;
- }
- if (rdev->ops->set_monitor_channel || rdev->ops->start_ap ||
- rdev->ops->join_mesh) {
- i++;
- if (nla_put_u32(msg, i, NL80211_CMD_SET_CHANNEL))
- goto nla_put_failure;
- }
- CMD(set_wds_peer, SET_WDS_PEER);
- if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) {
- CMD(tdls_mgmt, TDLS_MGMT);
- CMD(tdls_oper, TDLS_OPER);
- }
- if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN)
- CMD(sched_scan_start, START_SCHED_SCAN);
- CMD(probe_client, PROBE_CLIENT);
- CMD(set_noack_map, SET_NOACK_MAP);
- if (rdev->wiphy.flags & WIPHY_FLAG_REPORTS_OBSS) {
- i++;
- if (nla_put_u32(msg, i, NL80211_CMD_REGISTER_BEACONS))
- goto nla_put_failure;
- }
- CMD(start_p2p_device, START_P2P_DEVICE);
- CMD(set_mcast_rate, SET_MCAST_RATE);
-#ifdef CONFIG_NL80211_TESTMODE
- CMD(testmode_cmd, TESTMODE);
-#endif
+ i = nl80211_add_commands_unsplit(rdev, msg);
+ if (i < 0)
+ goto nla_put_failure;
if (state->split) {
CMD(crit_proto_start, CRIT_PROTOCOL_START);
CMD(crit_proto_stop, CRIT_PROTOCOL_STOP);
@@ -1627,7 +1644,6 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
NL80211_FEATURE_SUPPORTS_WMM_ADMISSION)
CMD(add_tx_ts, ADD_TX_TS);
}
- /* add into the if now */
#undef CMD
if (rdev->ops->connect || rdev->ops->auth) {
--
2.8.1
^ permalink raw reply related
* [PATCH] wireless: only ask about WDS if EXPERT is selected
From: Johannes Berg @ 2016-10-26 9:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There won't be any users of this that really need it and
aren't already experts in how the kernel functions, so
require setting EXPERT to reach this setting.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index fa9c4fa9477e..8f5a3f4a43f2 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -18,7 +18,7 @@ menuconfig WLAN
if WLAN
config WIRELESS_WDS
- bool "mac80211-based legacy WDS support"
+ bool "mac80211-based legacy WDS support" if EXPERT
help
This option enables the deprecated WDS support, the newer
mac80211-based 4-addr AP/client support supersedes it with
--
2.8.1
^ permalink raw reply related
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Thomas Graf @ 2016-10-26 9:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: davem, daniel, netdev, linux-wireless
In-Reply-To: <1477472376.4059.23.camel@sipsolutions.net>
On 10/26/16 at 10:59am, Johannes Berg wrote:
>
> > /**
> > + * nla_memdup - duplicate attribute memory (kmemdup)
> > + * @src: netlink attribute to duplicate from
> > + * @gfp: GFP mask
>
> Actually, is there any point in passing a GFP mask? None of the current
> users need it, and it seems fairly unlikely to be needed since this is
> typically used on the netlink input path, where you surely shouldn't
> need GFP_ATOMIC or so?
I'm fine either way. I didn't want to make assumptions which need
later changes. It's not hurting either and the function prototype
is very small.
^ permalink raw reply
* Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Arnd Bergmann @ 2016-10-26 9:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Hante Meuleman,
Franky Lin, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Rafał Miłecki, linux-wireless, brcm80211-dev-list.pdl,
netdev
In-Reply-To: <87zilr61ux.fsf@kamboji.qca.qualcomm.com>
On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > A bugfix added a sanity check around the assignment and use of the
> > 'is_11d' variable, which looks correct to me, but as the function is
> > rather complex already, this confuses the compiler to the point where
> > it can no longer figure out if the variable is always initialized
> > correctly:
> >
> > brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > This adds an initialization for the newly introduced case in which
> > the variable should not really be used, in order to make the warning
> > go away.
> >
> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> > Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> > Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> > Cc: Kalle Valo <kvalo@codeaurora.org>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Via which tree are you planning to submit this? Should I take it?
I'd prefer if you can take it and forward it along with your other
bugfixes. I'll try to take care of the ones that nobody else
picked up.
Arnd
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Johannes Berg @ 2016-10-26 10:18 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, daniel, netdev, linux-wireless
In-Reply-To: <20161026095238.GB16590@pox.localdomain>
On Wed, 2016-10-26 at 11:52 +0200, Thomas Graf wrote:
> On 10/26/16 at 10:59am, Johannes Berg wrote:
> >
> >
> > >
> > > /**
> > > + * nla_memdup - duplicate attribute memory (kmemdup)
> > > + * @src: netlink attribute to duplicate from
> > > + * @gfp: GFP mask
> >
> > Actually, is there any point in passing a GFP mask? None of the
> > current
> > users need it, and it seems fairly unlikely to be needed since this
> > is
> > typically used on the netlink input path, where you surely
> > shouldn't
> > need GFP_ATOMIC or so?
>
> I'm fine either way. I didn't want to make assumptions which need
> later changes. It's not hurting either and the function prototype
> is very small.
Yeah, I don't really care much - just wondered.
johannes
^ permalink raw reply
* Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Kalle Valo @ 2016-10-26 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Hante Meuleman,
Franky Lin, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Rafał Miłecki, linux-wireless, brcm80211-dev-list.pdl,
netdev
In-Reply-To: <3406231.8mt2808XDi@wuerfel>
Arnd Bergmann <arnd@arndb.de> writes:
> On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>=20
>> > A bugfix added a sanity check around the assignment and use of the
>> > 'is_11d' variable, which looks correct to me, but as the function is
>> > rather complex already, this confuses the compiler to the point where
>> > it can no longer figure out if the variable is always initialized
>> > correctly:
>> >
>> > brcm80211/brcmfmac/cfg80211.c: In function =E2=80=98brcmf_cfg80211_sta=
rt_ap=E2=80=99:
>> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: =E2=80=98is_11d=E2=80=99=
may be used uninitialized in this function [-Werror=3Dmaybe-uninitialized]
>> >
>> > This adds an initialization for the newly introduced case in which
>> > the variable should not really be used, in order to make the warning
>> > go away.
>> >
>> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
>> > Cc: Hante Meuleman <hante.meuleman@broadcom.com>
>> > Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
>> > Cc: Kalle Valo <kvalo@codeaurora.org>
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>=20
>> Via which tree are you planning to submit this? Should I take it?
>
> I'd prefer if you can take it and forward it along with your other
> bugfixes. I'll try to take care of the ones that nobody else
> picked up.
Ok, I'll take it. I'm planning to push this to 4.9.
--=20
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