[PATCH 0/2] iwlwifi: updates intended for v4.14 2017-08-25

[PATCH 0/2] iwlwifi: updates intended for v4.14 2017-08-25

[Luca Coelho]

From: Luca Coelho <luciano.coelho@intel.com>

Hi,

A very tiny set of patches for v4.14. :) Nothing is backlogged in our
internal tree anymore and this has been a very slow week due to
vacations in our team.

These are the changes:

* Fix a queue hang problem due to 11w behavior
* Fix a warning caused by a too long debug print

As usual, I'm pushing this to a pending branch, for kbuild bot, and
will send a pull-request later.

Please review.

Cheers,
Luca.


David Spinadel (1):
  iwlwifi: mvm: Avoid deffering non bufferable frames

Liad Kaufman (1):
  iwlwifi: fix long debug print

 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 9 +++++++--
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  | 9 +++++----
 2 files changed, 12 insertions(+), 6 deletions(-)

-- 
2.14.1

[PATCH 1/2] iwlwifi: fix long debug print

[Luca Coelho]

From: Liad Kaufman <liad.kaufman@intel.com>

There is a debug print that sometimes reaches over
110 chars, thus generating a warning in those cases.
Split the print into two to prevent these cases.

Fixes: 92b0f7b26b31 ("iwlwifi: split the regulatory rules when the bandwidth flags require it")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index b46796944cf2..3014beef4873 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -915,7 +915,7 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct iwl_cfg *cfg,
 		prev_reg_rule_flags = reg_rule_flags;
 
 		IWL_DEBUG_DEV(dev, IWL_DL_LAR,
-			      "Ch. %d [%sGHz] %s%s%s%s%s%s%s%s%s%s%s%s(0x%02x) reg_flags 0x%x: %s\n",
+			      "Ch. %d [%sGHz] %s%s%s%s%s%s%s%s%s%s%s%s(0x%02x)\n",
 			      center_freq,
 			      band == NL80211_BAND_5GHZ ? "5.2" : "2.4",
 			      CHECK_AND_PRINT_I(VALID),
@@ -930,7 +930,12 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct iwl_cfg *cfg,
 			      CHECK_AND_PRINT_I(80MHZ),
 			      CHECK_AND_PRINT_I(160MHZ),
 			      CHECK_AND_PRINT_I(DC_HIGH),
-			      ch_flags, reg_rule_flags,
+			      ch_flags);
+		IWL_DEBUG_DEV(dev, IWL_DL_LAR,
+			      "Ch. %d [%sGHz] reg_flags 0x%x: %s\n",
+			      center_freq,
+			      band == NL80211_BAND_5GHZ ? "5.2" : "2.4",
+			      reg_rule_flags,
 			      ((ch_flags & NVM_CHANNEL_ACTIVE) &&
 			       !(ch_flags & NVM_CHANNEL_RADAR))
 					 ? "Ad-Hoc" : "");
-- 
2.14.1

[PATCH 2/2] iwlwifi: mvm: Avoid deffering non bufferable frames

[Luca Coelho]

From: David Spinadel <david.spinadel@intel.com>

Use bcast station for all non bufferable frames on AP and AD-HOC.

The host is no longer aware of STAs PS status because of buffer
station offload, so we can't rely on mac80211 to toggle on
IEEE80211_TX_CTL_NO_PS_BUFFER bit.

A possible issue with buffering such frames, beside the obvious spec
violation, is when a station disconnects while in PS but the AP isn't
aware of that. In such scenarios the AP won't be able to send probe
responses or auth frames so the STA won't be able to reconnect and
the AP will have a queue hang.

Fixes: 3e56eadfb6a1 ("iwlwifi: mvm: implement AP/GO uAPSD support")
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index d7feb1ab4dc9..15f2d826bb4b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -810,10 +810,11 @@ static void iwl_mvm_mac_tx(struct ieee80211_hw *hw,
 	    !test_bit(IWL_MVM_STATUS_ROC_AUX_RUNNING, &mvm->status))
 		goto drop;
 
-	/* treat non-bufferable MMPDUs as broadcast if sta is sleeping */
-	if (unlikely(info->flags & IEEE80211_TX_CTL_NO_PS_BUFFER &&
-		     ieee80211_is_mgmt(hdr->frame_control) &&
-		     !ieee80211_is_bufferable_mmpdu(hdr->frame_control)))
+	/* treat non-bufferable MMPDUs on AP interfaces as broadcast */
+	if ((info->control.vif->type == NL80211_IFTYPE_AP ||
+	     info->control.vif->type == NL80211_IFTYPE_ADHOC) &&
+	    ieee80211_is_mgmt(hdr->frame_control) &&
+	    !ieee80211_is_bufferable_mmpdu(hdr->frame_control))
 		sta = NULL;
 
 	if (sta) {
-- 
2.14.1

Re: [PATCH 2/2] iwlwifi: mvm: Avoid deffering non bufferable frames

[Kalle Valo]

Luca Coelho <luca@coelho.fi> writes:

> From: David Spinadel <david.spinadel@intel.com>
>
> Use bcast station for all non bufferable frames on AP and AD-HOC.
>
> The host is no longer aware of STAs PS status because of buffer
> station offload, so we can't rely on mac80211 to toggle on
> IEEE80211_TX_CTL_NO_PS_BUFFER bit.
>
> A possible issue with buffering such frames, beside the obvious spec
> violation, is when a station disconnects while in PS but the AP isn't
> aware of that. In such scenarios the AP won't be able to send probe
> responses or auth frames so the STA won't be able to reconnect and
> the AP will have a queue hang.
>
> Fixes: 3e56eadfb6a1 ("iwlwifi: mvm: implement AP/GO uAPSD support")
> Signed-off-by: David Spinadel <david.spinadel@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

"deffering"? Should it be deferring?

-- 
Kalle Valo

Re: [PATCH 2/2] iwlwifi: mvm: Avoid deffering non bufferable frames

[Luca Coelho]

On Tue, 2017-08-29 at 11:22 +0300, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
> 
> > From: David Spinadel <david.spinadel@intel.com>
> > 
> > Use bcast station for all non bufferable frames on AP and AD-HOC.
> > 
> > The host is no longer aware of STAs PS status because of buffer
> > station offload, so we can't rely on mac80211 to toggle on
> > IEEE80211_TX_CTL_NO_PS_BUFFER bit.
> > 
> > A possible issue with buffering such frames, beside the obvious spec
> > violation, is when a station disconnects while in PS but the AP isn't
> > aware of that. In such scenarios the AP won't be able to send probe
> > responses or auth frames so the STA won't be able to reconnect and
> > the AP will have a queue hang.
> > 
> > Fixes: 3e56eadfb6a1 ("iwlwifi: mvm: implement AP/GO uAPSD support")
> > Signed-off-by: David Spinadel <david.spinadel@intel.com>
> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> 
> "deffering"? Should it be deferring?

Yeah, sorry, I'll fix it before sending the pull-req.

--
Cheers,
Luca.

Re: [PATCH 1/2] iwlwifi: fix long debug print

[Joe Perches]

On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> From: Liad Kaufman <liad.kaufman@intel.com>
> 
> There is a debug print that sometimes reaches over
> 110 chars, thus generating a warning in those cases.

What emits a warning here?

Re: [PATCH 1/2] iwlwifi: fix long debug print

[Luca Coelho]

On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
> On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> > From: Liad Kaufman <liad.kaufman@intel.com>
> > 
> > There is a debug print that sometimes reaches over
> > 110 chars, thus generating a warning in those cases.
> 
> What emits a warning here?

We have a WARN_ON in iwl-devtrace-msg.h:

#define MAX_MSG_LEN	110

DECLARE_EVENT_CLASS(iwlwifi_msg_event,
	TP_PROTO(struct va_format *vaf),
	TP_ARGS(vaf),
	TP_STRUCT__entry(
		__dynamic_array(char, msg, MAX_MSG_LEN)
	),
	TP_fast_assign(
		WARN_ON_ONCE(vsnprintf(__get_dynamic_array(msg),
				       MAX_MSG_LEN, vaf->fmt,
				       *vaf->va) >= MAX_MSG_LEN);
	),
	TP_printk("%s", __get_str(msg))
);

We limit all our tracing messages to 110 bytes.  Anything longer than
that starts getting annoying to read.  In mac80211 we limit it even
further, to 100 bytes, so this is not unique to the iwlwifi driver.

--
Cheers,
Luca.

Re: [PATCH 1/2] iwlwifi: fix long debug print

[Joe Perches]

On Fri, 2017-09-01 at 08:37 +0300, Luca Coelho wrote:
> On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
> > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> > > From: Liad Kaufman <liad.kaufman@intel.com>
> > > 
> > > There is a debug print that sometimes reaches over
> > > 110 chars, thus generating a warning in those cases.
> > 
> > What emits a warning here?
> 
> We have a WARN_ON in iwl-devtrace-msg.h:
> 
> #define MAX_MSG_LEN	110

OK, thanks for the hint.

The commit message is a bit obscure.

It might make sense to add a comment to describe these
trace events coming from TRACE_EVENT(iwlwifi_dbg,

All the IWL_DEBUG_<foo> use this trace message maximum.

Re: [PATCH 1/2] iwlwifi: fix long debug print

[Kalle Valo]

Joe Perches <joe@perches.com> writes:

> On Fri, 2017-09-01 at 08:37 +0300, Luca Coelho wrote:
>> On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
>> > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
>> > > From: Liad Kaufman <liad.kaufman@intel.com>
>> > > 
>> > > There is a debug print that sometimes reaches over
>> > > 110 chars, thus generating a warning in those cases.
>> > 
>> > What emits a warning here?
>> 
>> We have a WARN_ON in iwl-devtrace-msg.h:
>> 
>> #define MAX_MSG_LEN	110
>
> OK, thanks for the hint.
>
> The commit message is a bit obscure.
>
> It might make sense to add a comment to describe these
> trace events coming from TRACE_EVENT(iwlwifi_dbg,
>
> All the IWL_DEBUG_<foo> use this trace message maximum.

Unfortunately the patch is already commited to wireless-drivers-next so
we can't change the commit log anymore.

-- 
Kalle Valo

Re: [PATCH 1/2] iwlwifi: fix long debug print

[Joe Perches]

On Fri, 2017-09-01 at 11:15 +0300, Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
> > On Fri, 2017-09-01 at 08:37 +0300, Luca Coelho wrote:
> > > On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
> > > > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> > > > > From: Liad Kaufman <liad.kaufman@intel.com>
> > > > > There is a debug print that sometimes reaches over
> > > > > 110 chars, thus generating a warning in those cases.
[]
> > It might make sense to add a comment to describe these
> > trace events coming from TRACE_EVENT(iwlwifi_dbg,
> > 
> > All the IWL_DEBUG_<foo> use this trace message maximum.
> 
> Unfortunately the patch is already commited to wireless-drivers-next so
> we can't change the commit log anymore.

No worries about the commit.
It'd be useful to add a comment to the code.