Linux wireless drivers development
 help / color / mirror / Atom feed
* 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

* [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 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

* 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: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 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

* [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: 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

* 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

* [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

* 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

* 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 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 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 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 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 3/7] iwlwifi: mvm: fix d3_test with unified D0/D3 images
From: Luca Coelho @ 2016-10-26  6:47 UTC (permalink / raw)
  To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87insf7htp.fsf@kamboji.qca.qualcomm.com>

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.

--
Luca.

^ permalink raw reply

* Re: [PATCH 09/10] iwlwifi: mvm: operate in dqa mode
From: Coelho, Luciano @ 2016-10-26  6:44 UTC (permalink / raw)
  To: kvalo@codeaurora.org; +Cc: linux-wireless@vger.kernel.org, Kaufman, Liad
In-Reply-To: <87eg337h7v.fsf@kamboji.qca.qualcomm.com>

SGkgS2FsbGUsDQoNCk9uIFdlZCwgMjAxNi0xMC0yNiBhdCAwOTozMiArMDMwMCwgS2FsbGUgVmFs
byB3cm90ZToNCj4gTHVjYSBDb2VsaG8gPGx1Y2FAY29lbGhvLmZpPiB3cml0ZXM6DQo+IA0KPiA+
IEZyb206IExpYWQgS2F1Zm1hbiA8bGlhZC5rYXVmbWFuQGludGVsLmNvbT4NCj4gPiANCj4gPiBS
dW4gRFFBIGZsb3dzIGJ5IGRlZmF1bHQsIGFzIGxvbmcgYXMgdGhlIEZXIHN1cHBvcnRzIGl0Lg0K
PiA+IA0KPiA+IFNpZ25lZC1vZmYtYnk6IExpYWQgS2F1Zm1hbiA8bGlhZC5rYXVmbWFuQGludGVs
LmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBMdWNhIENvZWxobyA8bHVjaWFuby5jb2VsaG9AaW50
ZWwuY29tPg0KPiANCj4gV2hhdCdzIHRoaXMgRFFBIG1vZGU/IEEgc2hvcnQgc3VtbWFyeSB3b3Vs
ZCBoYXZlIGJlZW4gbmljZSB3aHkgaXQncw0KPiB1c2VmdWwuDQoNCkRRQSBpcyBEeW5hbWljIFF1
ZXVlIEFsbG9jYXRpb24uIMKgV2UgaGF2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyBmb3INCnF1aXRl
IGEgd2hpbGUgbm93IChzaW5jZSB2NC43KSBhbmQgaGF2ZSBtYW55IHBhdGNoZXMgbWVudGlvbmlu
ZyB0aGF0DQphcmUgYWxyZWFkeSBtZXJnZWQuICBUaGUgZmlyc3QgcGF0Y2ggaXMgdGhpczoNCg0K
Y29tbWl0IDI0YWZiYTc2OTBlNCAoIml3bHdpZmk6IG12bTogc3VwcG9ydCBic3MgZHluYW1pYyBh
bGxvYy9kZWFsbG9jDQpvZiBxdWV1ZXMiKQ0KDQpJdHMgY29tbWl0IG1lc3NhZ2UgaGFzIHNvbWUg
ZXhwbGFuYXRpb24gYW5kIHdlIGFsc28gaGF2ZSBhIERPQyBzZWN0aW9uDQppbiBvdXIgZHJpdmVy
IHRoYXQgZXhwbGFpbnMgaXQgaW4gZnVydGhlciBkZXRhaWxzOg0KDQpodHRwczovL2dpdC5rZXJu
ZWwub3JnL2NnaXQvbGludXgva2VybmVsL2dpdC9rdmFsby93aXJlbGVzcy1kcml2ZXJzLW5leHQu
Z2l0L3RyZWUvZHJpdmVycy9uZXQvd2lyZWxlc3MvaW50ZWwvaXdsd2lmaS9tdm0vc3RhLmgjbjgy
DQoNClNpbmNlIHdlJ3ZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGZvciBzbyBsb25nIGFuZCBhbHJl
YWR5IHVzZSB0aGUgdGVybQ0KRFFBIGJyb2FkbHksIHdlIHRob3VnaHQgaXQgd291bGRuJ3QgYmUg
bmVjZXNzYXJ5IHRvIGV4cGxhaW4gbW9yZSB3aGVuDQp3ZSBhcmUgZmluYWxseSBlbmFibGluZyBp
dCBieSBkZWZhdWx0LiAgQnV0IG9mIGNvdXJzZSBJIGNhbiBjaGFuZ2UgdGhhdA0KaWYgeW91IHBy
ZWZlci4NCg0KLS0NCkNoZWVycywNCkx1Y2Eu

^ permalink raw reply

* Re: [PATCH 09/10] iwlwifi: mvm: operate in dqa mode
From: Kalle Valo @ 2016-10-26  6:32 UTC (permalink / raw)
  To: Luca Coelho; +Cc: linux-wireless, Liad Kaufman, Luca Coelho
In-Reply-To: <20161019100755.23874-10-luca@coelho.fi>

Luca Coelho <luca@coelho.fi> writes:

> From: Liad Kaufman <liad.kaufman@intel.com>
>
> Run DQA flows by default, as long as the FW supports it.
>
> Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

What's this DQA mode? A short summary would have been nice why it's
useful.

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH 8/8] mac80211: Claim Fast Initial Link Setup (FILS) support
From: Johannes Berg @ 2016-10-26  5:50 UTC (permalink / raw)
  To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <1477435489-8555-4-git-send-email-jouni@qca.qualcomm.com>

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 :)

johannes

^ permalink raw reply

* Re: [PATCH 3/7] iwlwifi: mvm: fix d3_test with unified D0/D3 images
From: Kalle Valo @ 2016-10-26  6:19 UTC (permalink / raw)
  To: Luca Coelho; +Cc: linux-wireless
In-Reply-To: <20161019071122.18977-4-luca@coelho.fi>

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.

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH 2/2] mac80211: use inline kernel-doc for struct ieee80211_hw
From: Johannes Berg @ 2016-10-26  6:09 UTC (permalink / raw)
  To: Jani Nikula, linux-wireless; +Cc: linux-doc
In-Reply-To: <1477054644-5945-2-git-send-email-jani.nikula@intel.com>

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.

johannes

^ permalink raw reply

* Re: [PATCH 1/2] mac80211: fix some sphinx warnings
From: Johannes Berg @ 2016-10-26  6:02 UTC (permalink / raw)
  To: Jani Nikula, linux-wireless; +Cc: linux-doc
In-Reply-To: <1477054644-5945-1-git-send-email-jani.nikula@intel.com>

Applied.

I'll take this into the RCs so we don't have warnings there, and the
other patch into -next.

johannes

^ permalink raw reply

* [PATCH] cfg80211: process events caused by suspend before suspending
From: Johannes Berg @ 2016-10-26  5:59 UTC (permalink / raw)
  To: linux-wireless; +Cc: Amitkumar Karwar, Johannes Berg

From: Johannes Berg <johannes.berg@intel.com>

When suspending without WoWLAN, cfg80211 will ask drivers to
disconnect. Even when the driver does this synchronously, and
immediately returns with a notification, cfg80211 schedules
the handling thereof to a workqueue, and may then call back
into the driver when the driver was already suspended/ing.

Fix this by processing all events caused by cfg80211_leave_all()
directly after that function returns. The driver still needs to
do the right thing here and wait for the firmware response, but
that is - at least - true for mwifiex where this occurred.

Reported-by: Amitkumar Karwar <akarwar@marvell.com>
Tested-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/wireless/sysfs.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/wireless/sysfs.c b/net/wireless/sysfs.c
index 0082f4b01795..14b3f007826d 100644
--- a/net/wireless/sysfs.c
+++ b/net/wireless/sysfs.c
@@ -104,13 +104,16 @@ static int wiphy_suspend(struct device *dev)
 
 	rtnl_lock();
 	if (rdev->wiphy.registered) {
-		if (!rdev->wiphy.wowlan_config)
+		if (!rdev->wiphy.wowlan_config) {
 			cfg80211_leave_all(rdev);
+			cfg80211_process_rdev_events(rdev);
+		}
 		if (rdev->ops->suspend)
 			ret = rdev_suspend(rdev, rdev->wiphy.wowlan_config);
 		if (ret == 1) {
 			/* Driver refuse to configure wowlan */
 			cfg80211_leave_all(rdev);
+			cfg80211_process_rdev_events(rdev);
 			ret = rdev_suspend(rdev, NULL);
 		}
 	}
-- 
2.8.1

^ permalink raw reply related

* Re: Bayesian rate control
From: Johannes Berg @ 2016-10-26  5:56 UTC (permalink / raw)
  To: Adrian Chadd
  Cc: Björn Smedman, linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <CAJ-Vmon0RTAXJMuwANCO23cPsFyFZ17sAHoReuGBG1u1Q9kK6w@mail.gmail.com>


> The intel 7260 and later parts also allow user controllable rate
> control and provide transmit completion feedback, but I don't know
> whether it's enough for your needs.

Perhaps. However, existing rate control is *very* tightly coupled to
the driver, and it'd be fairly pointless to disentangle just for the
sake of playing with a rate control algorithm.

Also, the device doesn't support per-frame control nor any kind of
sampling-with-table-fallback, only the rate table that you give to the
device and update.

Btw, mac80211_hwsim with wmediumd doing some medium simulation might
also be something to look at for just extending to VHT.

And come to think of it, there's this new driver Felix et al have been
working on, mt7601u, which also should support proper rate control
APIs.

johannes

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox