RE: [PATCH 09/28] mac80211: pass the TWT support bits in extended caps to the driver

[Grumbach, Emmanuel]

> 
> On Mon, 2018-09-03 at 09:28 +, Grumbach, Emmanuel wrote:
> > >
> > For managed mode, the driver will need to check the HE cap along with
> > the extended capabilities to determine whether AP supports TWT or not.
> 
> Do you have any idea why it's there twice? Sounds like we should resolve
> that in mac80211, rather than requiring the driver to check two places...
>

I am now looking at table 9-135 in D3.0 and at Table-9-262z. The first describes
the extended caps IE, the second, the HE CAP IE. I can't really find any 
difference.
Since the driver already has the full HE CAP IE, I thought we'd just reflect 
what we
had in the extended caps IE so that it has the "raw" data, but I agree that 
mac80211
could / should aggregate the data.

RE: [PATCH 09/28] mac80211: pass the TWT support bits in extended caps to the driver

[Grumbach, Emmanuel]

> 
> > Since those bits are present in the HE Cap as well, we can set the
> > capability bits in the Extended Capabilities IE based on what is
> > advertised in the HE Cap IE.
> 
> It's not clear to me what this is trying to say, you don't seem to do anything
> with the HE capabilities in the patch.
>

You are right. You can drop this part of the commit log. I guess I wrote that
for the AP mode but in the AP mode this is not relevant since the beacon is
built by hostapd.
For managed mode, the driver will need to check the HE cap along with the
extended capabilities to determine whether AP supports TWT or not.

RE: [linuxwifi] Simultaneous 2.4 GHz WiFi and Bluetooth issue on Intel Dual Band Wireless-AC 8260

[Grumbach, Emmanuel]

 
> On 04/20/2018 01:03 AM, Emmanuel Grumbach wrote:
> >> Under Windows 10, the hardware appears to work without issue.
> >> Additionally, I believe I managed to warm-reboot from Windows 10 to
> >> Linux (with Bluetooth connected), and was able to continue using the
> >> same 2.4 GHz WiFi and Bluetooth audio sink without issue.
> >
> > This was reported in the past. Please make sure you have the latest BT
> > firmware files.
> 
> This seems to have resolved the issue.  Interestingly, the firmware
> (version...) shipped with Debian Sid is not in the official linux-firmware.git
> repository; its md5sum doesn't match any of prior versions of the file:

Glad to know. I guess you can open a bug on Debian to thave they fix this.
This is rather strange though.

> 
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > e.git/log/intel/ibt-11-5.sfi
> 
> Emmanuel, how can I determine the firmware version ("FW Build" and/or
> "Release Version") from a given file (e.g. ibt-11-5.sfi/.ddc)?

I have no clue :)
I am not a BT guy, sorry.

> 
> > Regardless of the BT firmware version thing which is a pure Intel
> > problem, I have heard about problems in the BT stack itself but I
> > can't help about this.
> 
> Though I've never really used the Bluetooth stack until this hardware, it
> seems the stack/blueman-* applications only behave oddly when there's
> problems with the firmware: never an issue when not using simultaneous
> 2.4 GHz WiFi + Bluetooth, or with this latest firmware, or approx. 2 years ago
> when I first started using this setup.
> 

RE: [linuxwifi] Null pointer dereference in iwlwifi when starting ad-hoc network

[Grumbach, Emmanuel]

Hi,

> I get this oops in 4.15rc9 when doing the following:
> 
> # iw dev wlp2s0 set type ibss
> # ip link set dev wlp2s0 up
> # iw dev wlp2s0 ibss join "TEST" 2412
> 
> The oops happens after some delay (approx. 5 seconds).
> 
> Hardware is:
> 
> 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78) 
> pci
> vendor code 8086:24fd
> Subsystem: 8086:0050
> 
> Oops message is:
> 
> IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Trigger new scan to find an IBSS to join
> wlp2s0: Creating new IBSS network, BSSID 3a:94:1d:dd:ab:09
> BUG: unable to handle kernel NULL pointer dereference at
> 0068

We have a fix for this which should go upstream soon:

commit 0e37a1940fcfae99ffec59ad620ed81feb2d
Author: Sara Sharon 
Date:   Thu Dec 21 15:05:28 2017 +0200

[BUGFIX] iwlwifi: mvm: fix IBSS for devices that support station type API


in our internal  tree which is mirrored here:
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/

Re: [PATCH 0/5] iwlwifi: updates intended for v4.16 2017-12-23

[Grumbach, Emmanuel]

Hi Kale,

On Fri, 2018-01-12 at 13:31 +0200, Kalle Valo wrote:
> From: Luca Coelho 
> > 
> > Hi,
> > 
> > Here's the fourth and probably last batch of patches intended for
> > 4.16.  Nothing major, just continued development, some cleanups and
> > small fixes here and there.
> > 
> > * Fix a UBSAN warning;
> > * Improvement in the net-stack/driver log syncing
> > * An RCU lock fix in the new rate-scaling code;
> > * Small cleanups;
> > 
> > As usual, I'm pushing this to a pending branch, for kbuild bot, and
> > will send a pull-request later.
> > 
> > FYI, I'll be on holidays/vacations for the next few weeks, so there
> > will probably not be much activity in the iwlwifi driver code.
> > 
> > Please review.
> > 
> > Cheers,
> > Luca.
> > 
> > 
> > Luca Coelho (1):
> >   iwlwifi: mvm: check if mac80211_queue is valid in
> > iwl_mvm_disable_txq
> > 
> > Mordechay Goodstein (1):
> >   iwlwifi: set default timstamp marker cmd
> > 
> > Sara Sharon (3):
> >   iwlwifi: mvm: flip AMSDU addresses only for 9000 family
> >   iwlwifi: mvm: take RCU lock before dereferencing
> >   iwlwifi: mvm: move TSO segment to a separate function
> 
> Most likely the merge window starts in 9 days so I need to start
> getting
> patches ready. As Luca is away should I apply these patches directly
> to
> wireless-drivers-next?
> 

First let me thank you for tracking this.
I don't see anything that we really need in 4.16 here.
Besides Luca's UBSAN warning, all the rest is for a new device
family which won't be supported in 4.16 anyway.

So I opt to wait for Luca here.

RE: [PATCH] mac80211: always update the PM state of a peer on MGMT / DATA frames

[Grumbach, Emmanuel]

> 
> The 2016 version of the spec is more generic about when the AP should
> update the power management state of the peer:
> the AP shall update the state based on any management or data frames. This
> means that even non-bufferable management frames should be looked at to
> update to maintain the power management state of the peer.
> 
> This can avoid problematic cases for example if a station disappears while
> being asleep and then re-appears. The AP would remember it as in power
> save, but the Authentication frame couldn't be used to set the peer as
> awake again.
> Note that this issues wasn't really critical since at some point (after the
> association) we would have removed the station and created another one
> with all the states cleared.
> 
> type=feature
> ticket=none
> 
> Change-Id: Iae1fbbd502d64f0c31db3e0f2d81224b29acb5af

Looks like I forgot to remove a few things here :)
And to put this as an RFC..

> Signed-off-by: Emmanuel Grumbach 
> ---
>  net/mac80211/rx.c | 17 +
>  1 file changed, 5 insertions(+), 12 deletions(-)
> 
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index
> fdf616811865..89db6b11af8a 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1749,23 +1749,16 @@ ieee80211_rx_h_sta_process(struct
> ieee80211_rx_data *rx)
> 
>   /*
>* Change STA power saving mode only at the end of a frame
> -  * exchange sequence.
> +  * exchange sequence, and only for a data or management
> +  * frame as specified in ieee80211-2016 11.2.3.2
>*/
>   if (!ieee80211_hw_check(>local->hw, AP_LINK_PS) &&
>   !ieee80211_has_morefrags(hdr->frame_control) &&
> - !ieee80211_is_back_req(hdr->frame_control) &&
> + (ieee80211_is_mgmt(hdr->frame_control) ||
> +  ieee80211_is_data(hdr->frame_control)) &&
>   !(status->rx_flags & IEEE80211_RX_DEFERRED_RELEASE) &&
>   (rx->sdata->vif.type == NL80211_IFTYPE_AP ||
> -  rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN) &&
> - /*
> -  * PM bit is only checked in frames where it isn't reserved,
> -  * in AP mode it's reserved in non-bufferable management frames
> -  * (cf. IEEE 802.11-2012 8.2.4.1.7 Power Management field)
> -  * BAR frames should be ignored as specified in
> -  * IEEE 802.11-2012 10.2.1.2.
> -  */
> - (!ieee80211_is_mgmt(hdr->frame_control) ||
> -  ieee80211_is_bufferable_mmpdu(hdr->frame_control))) {
> +  rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN)) {
>   if (test_sta_flag(sta, WLAN_STA_PS_STA)) {
>   if (!ieee80211_has_pm(hdr->frame_control))
>   sta_ps_end(sta);
> --
> 2.9.3

RE: [PATCH 06/10] cfg80211: honor NL80211_RRF_NO_HT40{MINUS,PLUS}

[Grumbach, Emmanuel]

> 
> On Tue, 2017-09-05 at 16:49 +, Grumbach, Emmanuel wrote:
> > On Tue, 2017-09-05 at 16:30 +0200, Johannes Berg wrote:
> > > On Sat, 2017-08-05 at 11:44 +0300, Luca Coelho wrote:
> > >
> > > > +   regd = get_wiphy_regdom(wiphy);
> > > > +   if (regd) {
> > > > +   const struct ieee80211_reg_rule *reg_rule =
> > > > +   freq_reg_info_regd(MHZ_TO_KHZ(channel-
> > > > > center_freq),
> > > >
> > > > +      regd,
> > > > MHZ_TO_KHZ(20));
> > > >
> > >
> > > This could return an error, how can you be sure it doesn't?
> > >
> >
> > Hm... so I guess I could check that it didn't return any error and if
> > it did, then flags = 0?
> >
> > Something like this? (on top of this patch):
> > [snip]
> 
> yeah that's obviously the easy thing to do - I just wasn't sure that you 
> didn't
> have a reason to believe it could never be an ERR_PTR :)
>
TBH, I don't really know... I don't know if *all* the channels are covered by 
rules.
For sure, if there is no rule, I can assume that the HT40{+,-} are not set... 
But I don't know if that's even possible.

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

[Grumbach, Emmanuel]

On Tue, 2017-08-15 at 10:49 +0300, Emmanuel Grumbach wrote:
> On Tue, 2017-08-15 at 10:16 +0300, Kalle Valo wrote:
> > "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes:
> > 
> > > On Mon, 2017-08-14 at 20:14 +0300, Kalle Valo wrote:
> > > > Emmanuel Grumbach <emmanuel.grumb...@intel.com> writes:
> > > > 
> > > > > User space can now allow the kernel to associate to an AP
> > > > > that requires MFP or that doesn't have MFP enabled in the
> > > > > same NL80211_CMD_CONNECT command.
> > > > > The driver / firmware will decide whether to use it or not.
> > > > > 
> > > > > Signed-off-by: Emmanuel Grumbach <emmanuel.grumb...@intel.com
> > > > > >
> > 
> > [...]
> > 
> > > > > --- a/net/wireless/nl80211.c
> > > > > +++ b/net/wireless/nl80211.c
> > > > > @@ -9115,6 +9115,7 @@ static int nl80211_connect(struct
> > > > > sk_buff
> > > > > *skb, struct genl_info *info)
> > > > >   if (info->attrs[NL80211_ATTR_USE_MFP]) {
> > > > >   connect.mfp = nla_get_u32(info-
> > > > > > attrs[NL80211_ATTR_USE_MFP]);
> > > > > 
> > > > >   if (connect.mfp != NL80211_MFP_REQUIRED &&
> > > > > + connect.mfp != NL80211_MFP_OPTIONAL &&
> > > > >   connect.mfp != NL80211_MFP_NO)
> > > > >   return -EINVAL;
> > > > >   } else {
> > > > 
> > > > I guess I'm missing something, but how is backwards
> > > > compatibility
> > > > supposed to work from user space point of view? If user space
> > > > uses
> > > > NL80211_MFP_OPTIONAL with an old kernel, the kernel will reject
> > > > the
> > > > command with -EINVAL and user space will try again without
> > > > NL80211_MFP_OPTIONAL?
> > > 
> > > No you are not. I simply forgot that point. I guess that this
> > > would
> > > be
> > > the behavior, yes...
> > 
> > I don't think that's very robust. How would user space
> > (wpasupplicant)
> > know if the the EINVAL is because NL80211_MFP_OPTIONAL is not
> > supported
> > by the kernel or because of some other error?
> 
> I hear, I hear. This is not an option, you are right.
> 
> > 
> > > This is relevant for ap_scan=2 wpa_s configuration only which
> > > makes
> > > it
> > > not really common, but still, you are right. Not sure how easy it
> > > will
> > > be to write this logic in the supplicant though... Unless we add
> > > an
> > > nl80211 feature bit but I feel it'd be a bit of a waste.
> > 
> > I don't feel that adding a feature bit is waste, I rather use a
> > feature
> > flag than making ugly hacks to user space. But of course this is up
> > to
> > Jouni and Johannes.
> 
> My latest point is that it wouldn't help since the useful usage was
> with ap_scan=2 in which wpa_supplicant can't really know what to put
> there. Or... No. It _can_ work. The user would configure pmf=optional
> in the wpa_supplicant configuration, and wpa_supplicant can check if
> that the underlying kernel supports it with the help of the feature
> flag.
> Since the pmf=optional configuration in wpa_supplicant will come from
> the user (that configures the network inside wpa_supplicant),
> wpa_supplicant can do this check.
> 
> I'll add this.
> 

And then, the cfg80211 driver can add this by itself, so that quantenna
folks don't have to fear getting the new value into their firmware,
although they already reported it'd work for them.

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

[Grumbach, Emmanuel]

On Tue, 2017-08-15 at 10:16 +0300, Kalle Valo wrote:
> "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes:
> 
> > On Mon, 2017-08-14 at 20:14 +0300, Kalle Valo wrote:
> > > Emmanuel Grumbach <emmanuel.grumb...@intel.com> writes:
> > > 
> > > > User space can now allow the kernel to associate to an AP
> > > > that requires MFP or that doesn't have MFP enabled in the
> > > > same NL80211_CMD_CONNECT command.
> > > > The driver / firmware will decide whether to use it or not.
> > > > 
> > > > Signed-off-by: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
> 
> [...]
> 
> > > > --- a/net/wireless/nl80211.c
> > > > +++ b/net/wireless/nl80211.c
> > > > @@ -9115,6 +9115,7 @@ static int nl80211_connect(struct sk_buff
> > > > *skb, struct genl_info *info)
> > > >     if (info->attrs[NL80211_ATTR_USE_MFP]) {
> > > >     connect.mfp = nla_get_u32(info-
> > > > > attrs[NL80211_ATTR_USE_MFP]);
> > > > 
> > > >     if (connect.mfp != NL80211_MFP_REQUIRED &&
> > > > +   connect.mfp != NL80211_MFP_OPTIONAL &&
> > > >     connect.mfp != NL80211_MFP_NO)
> > > >     return -EINVAL;
> > > >     } else {
> > > 
> > > I guess I'm missing something, but how is backwards compatibility
> > > supposed to work from user space point of view? If user space
> > > uses
> > > NL80211_MFP_OPTIONAL with an old kernel, the kernel will reject
> > > the
> > > command with -EINVAL and user space will try again without
> > > NL80211_MFP_OPTIONAL?
> > 
> > No you are not. I simply forgot that point. I guess that this would
> > be
> > the behavior, yes...
> 
> I don't think that's very robust. How would user space
> (wpasupplicant)
> know if the the EINVAL is because NL80211_MFP_OPTIONAL is not
> supported
> by the kernel or because of some other error?

I hear, I hear. This is not an option, you are right.

> 
> > This is relevant for ap_scan=2 wpa_s configuration only which makes
> > it
> > not really common, but still, you are right. Not sure how easy it
> > will
> > be to write this logic in the supplicant though... Unless we add an
> > nl80211 feature bit but I feel it'd be a bit of a waste.
> 
> I don't feel that adding a feature bit is waste, I rather use a
> feature
> flag than making ugly hacks to user space. But of course this is up
> to
> Jouni and Johannes.

My latest point is that it wouldn't help since the useful usage was
with ap_scan=2 in which wpa_supplicant can't really know what to put
there. Or... No. It _can_ work. The user would configure pmf=optional
in the wpa_supplicant configuration, and wpa_supplicant can check if
that the underlying kernel supports it with the help of the feature
flag.
Since the pmf=optional configuration in wpa_supplicant will come from
the user (that configures the network inside wpa_supplicant),
wpa_supplicant can do this check.

I'll add this.

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

[Grumbach, Emmanuel]

On Mon, 2017-08-14 at 13:36 -0700, Igor Mitsyanko wrote:
> On 08/14/2017 01:13 PM, Grumbach, Emmanuel wrote:
> > > It is kind of not clear right now for drivers where to get
> > > information from:
> > > - NL attributes passed from userspace and forwarded to a driver
> > 
> > Since those exist, it seems to make more sense to me to use those
> > rather than any in-driver decided policy. Usually, deciding upon
> > policies from lower levels is frowned upon I'd say.
> 
> I agree, what I mean is that drivers should know where to take this 
> information from, if there are multiple sources.
> 
> An example are HT/VHT capabilities for start_ap command: they can be 
> parsed directly by drivers by looking at beacon's IEs in 
> "cfg80211_ap_settings". At the same time those are also parsed by 
> nl80211 which fills cfg80211_ap_settings::ht_cap, 
> cfg80211_ap_settings::vht_cap.
> Why HT/VHT caps are not passed directly from usespace as one of NL 
> attributes? I guess because there is not much point in it since 
> userspace passes entire IE set anyway, which can be used by lower
> levels.

I understand your point about the information being conveyed to the
kernel through multiple pipes. But note that for HT/VHT in AP mode, the
decision maker is the user space. User space can get it from a the user
himself (hostapd.conf) or from internal knowledge (OBSS parameters in
AP mode that are handled internally in hostapd), but it essentially
doesn't matter. The kernel does nothing else but implementing the
policy decided by the user space.

When you start thinking about firmwares with more logic, the picture is
different. When Jouni added MFP support in the kernel in 2009 he wrote:

  Since we are currently using nl80211 for MFP only with drivers that
  use user space SME, only MFP disabled and required values are
  used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can
  be extended with MFP optional in the future, if that is needed with
  some drivers (e.g., if the RSN IE is generated by the driver).

(See commit dc6382ced07d6bad61d0b591fb12ab5da7ca632c).

Here is the thing: until now, MFP was supported only for drivers that
use user space SME, meaning drivers that let the user space decide
about pretty much everything: it sends the Assoc Request which means
that it knows _everything_ about the AP it connects to. When you don't
use user space SME (meaning you use NL80211_CMD_CONNECT and not
NL80211_CMD_{AUTHENTICATE,ASSOCIATE}), the user space may not know much
about the AP including not its RSN caps. Essentially, the user space is
sending a supplicant's network block to the kernel and asks the kernel
to connect to that thing. The user space may not even know that this
network is in the vicinity (which is what ap_scan=2 in the wpa_s means
IIUC).

So what I am trying to do here to shift the power of the decision from
the user space to the kernel in certain cases, or at least to allow the
user space to tell the kernel how to behave in several scenarios since
the user space doesn't have all the information in hand.

NL80211_MFP_NO is clear: you can't associate to an AP that has MFPC=1
MFPR=1
NL80211_MFP_REQUIRED is clear: you can't associate to an AP that has
MFPC=0 MFPR=0

This is possible when the user space knows how the RSN IE of the AP
looks like. If it doesn't, then it'd mean that the user space has no
way to say: I want to use MFP if required by the AP, but don't care all
that much if the AP doesn't support it, and this is exactly what the
NL80211_MFP_OPTIONAL comes to add.

I wrote this to explain that I can't use the IEs for this since I am
adding NL80211_MFP_OPTIONAL precisely because the user space doesn't
have the IEs.

Regarding the backward compatibility, this is a real problem. I am not
even sure that adding a feature flag will help since in case wpa_s
doesn't know the IEs of the AP, it can't really know what MFP
parameters to send (REQ or NO assuming wpa_s detected that the kernel
wouldn't support OPTIONAL). Note that all this is really relevant only
for ap_scan=2 configuration in wpa_s which is not really supported well
in nl80211 driver right now (at least based on the comments in the
wpa_s code). Asking why I am adding this in nl80211 kernel side if the
only user would be wpa_s with nl80211 and ap_scan=2 (which is
reportedly not really working) is a fair question :)
I am basically working in the context of a firmware that does the scan
before connect internally.

> 
> 
> > 
> > > - IEs passed from userspace, parsed by nl80211 and forwarded to a
> > > driver
> > > - IEs that are passed from userspace and parsed by drivers
> > > directly
> > > 
> > > > 
> > > > Thanks,
> > > > Arend
> > > 
> > > 
> 

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

[Grumbach, Emmanuel]

On Mon, 2017-08-14 at 13:08 -0700, Igor Mitsyanko wrote:
> On 08/14/2017 12:22 PM, Arend van Spriel wrote:
> > On 14-08-17 15:49, Emmanuel Grumbach wrote:
> > > User space can now allow the kernel to associate to an AP
> > > that requires MFP or that doesn't have MFP enabled in the
> > > same NL80211_CMD_CONNECT command.
> > > The driver / firmware will decide whether to use it or not.
> > > 
> > > Signed-off-by: Emmanuel Grumbach 
> > > ---
> > > A short tour of the drivers taught me that only Quantenna really
> > > look
> > > at cfg80211_connect_params::sme which can now be 2. This is why
> > > the maintainer of this driver is CCed.
> > 
> > Indeed in brcmfmac the IE is processed to determine whether it is
> > required or optional. Probably will change our driver to use the
> > explicit mfp values from cfg80211_connect_params::sme.
> 
> Maybe this is a right way to do that, avoiding that compatibility 
> problem (no new NL* flags)? Except for maybe nl80211 layer should
> parse 
> it instead, not driver.

Seems odd to me, since there already is an NL attribute for this and
you want the user space to decide on the policy I think.

> 
> It is kind of not clear right now for drivers where to get
> information from:
> - NL attributes passed from userspace and forwarded to a driver

Since those exist, it seems to make more sense to me to use those
rather than any in-driver decided policy. Usually, deciding upon
policies from lower levels is frowned upon I'd say.

> - IEs passed from userspace, parsed by nl80211 and forwarded to a
> driver
> - IEs that are passed from userspace and parsed by drivers directly
> 
> > 
> > Thanks,
> > Arend
> 
> 

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

[Grumbach, Emmanuel]

On Mon, 2017-08-14 at 20:14 +0300, Kalle Valo wrote:
> Emmanuel Grumbach  writes:
> 
> > User space can now allow the kernel to associate to an AP
> > that requires MFP or that doesn't have MFP enabled in the
> > same NL80211_CMD_CONNECT command.
> > The driver / firmware will decide whether to use it or not.
> > 
> > Signed-off-by: Emmanuel Grumbach 
> 
> [...]
> 
> > @@ -4086,10 +4090,12 @@ enum nl80211_key_type {
> >   * enum nl80211_mfp - Management frame protection state
> >   * @NL80211_MFP_NO: Management frame protection not used
> >   * @NL80211_MFP_REQUIRED: Management frame protection required
> > + * @NL80211_MFP_OPTIONAL: Management frame is optional
> >   */
> >  enum nl80211_mfp {
> >     NL80211_MFP_NO,
> >     NL80211_MFP_REQUIRED,
> > +   NL80211_MFP_OPTIONAL,
> >  };
> >  
> >  enum nl80211_wpa_versions {
> > diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> > index 8f035d9868d1..829867132326 100644
> > --- a/net/wireless/nl80211.c
> > +++ b/net/wireless/nl80211.c
> > @@ -9115,6 +9115,7 @@ static int nl80211_connect(struct sk_buff
> > *skb, struct genl_info *info)
> >     if (info->attrs[NL80211_ATTR_USE_MFP]) {
> >     connect.mfp = nla_get_u32(info-
> > >attrs[NL80211_ATTR_USE_MFP]);
> >     if (connect.mfp != NL80211_MFP_REQUIRED &&
> > +   connect.mfp != NL80211_MFP_OPTIONAL &&
> >     connect.mfp != NL80211_MFP_NO)
> >     return -EINVAL;
> >     } else {
> 
> I guess I'm missing something, but how is backwards compatibility
> supposed to work from user space point of view? If user space uses
> NL80211_MFP_OPTIONAL with an old kernel, the kernel will reject the
> command with -EINVAL and user space will try again without
> NL80211_MFP_OPTIONAL?
> 


No you are not. I simply forgot that point. I guess that this would be
the behavior, yes... This is relevant for ap_scan=2 wpa_s configuration
only which makes it not really common, but still, you are right.
Not sure how easy it will be to write this logic in the supplicant
though... Unless we add an nl80211 feature bit but I feel it'd be a bit
of a waste.
Jouni, what do you think?
I know you haven't seen the supplicant patch yet, but here is the gist
of it. I allow OPTIONAL in connect() only, and not in associate():

@@ -5790,6 +5786,14 @@ static int wpa_driver_nl80211_try_connect(
if (ret)
goto fail;
 
+   if (params->mgmt_frame_protection == MGMT_FRAME_PROTECTION_REQUIRED &&
+   nla_put_u32(msg, NL80211_ATTR_USE_MFP, NL80211_MFP_REQUIRED))
+   goto fail;
+
+   if (params->mgmt_frame_protection == MGMT_FRAME_PROTECTION_OPTIONAL &&
+   nla_put_u32(msg, NL80211_ATTR_USE_MFP, NL80211_MFP_OPTIONAL))
+   goto fail;
+
algs = 0;
if (params->auth_alg & WPA_AUTH_ALG_OPEN)
algs++;

 

RE: [PATCH] mac80211: don't look at the PM bit of BAR frames

[Grumbach, Emmanuel]

> 
> On 06/08/2017 04:00 AM, Emmanuel Grumbach wrote:
> > When a peer sends a BAR frame with PM bit clear, we should not modify
> > its PM state as madated by the spec in
> > 802.11-20012 10.2.1.2.
> >
> > Signed-off-by: Emmanuel Grumbach
> > 
> > ---
> >   net/mac80211/rx.c | 6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index
> > e48724a6725e..bb1e4bbf55e2 100644
> > --- a/net/mac80211/rx.c
> > +++ b/net/mac80211/rx.c
> > @@ -1558,12 +1558,16 @@ ieee80211_rx_h_sta_process(struct
> ieee80211_rx_data *rx)
> >  */
> > if (!ieee80211_hw_check(>local->hw, AP_LINK_PS) &&
> > !ieee80211_has_morefrags(hdr->frame_control) &&
> > +   !ieee80211_is_back_req(hdr->frame_control) &&
> 
> BTW latest spec also notes that PSPOLL frame has PM bit reserved too,
> because it may not result in ACK frame from AP.

PS poll are already handled before in the flow and don't reach this code.


> 
> > !(status->rx_flags & IEEE80211_RX_DEFERRED_RELEASE) &&
> > (rx->sdata->vif.type == NL80211_IFTYPE_AP ||
> >  rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN) &&
> > -   /* PM bit is only checked in frames where it isn't reserved,
> > +   /*
> > +* PM bit is only checked in frames where it isn't reserved,
> >  * in AP mode it's reserved in non-bufferable management frames
> >  * (cf. IEEE 802.11-2012 8.2.4.1.7 Power Management field)
> > +* BAR frames should be ignored as specified in
> > +* IEEE 802.11-2012 10.2.1.2.
> 
> Comment placement is a little confusing IMO. Maybe move
> ieee80211_is_back_req() check to this position?
> 

Don't know. It's been merged already. So you'd need to send a patch fixing this 
if you want :)

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

[Grumbach, Emmanuel]

> 
> On Thu, Jun 08, 2017 at 06:31:01AM +, Grumbach, Emmanuel wrote:
> > Hi,
> 
> Hi,
> 
> > True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
> > that we don't index tid_data with this. Hence I think the proper fix is:
> >
> > diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > index 06ac3f1..16a8646 100644
> > --- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > @@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv,
> struct iwl_rx_cmd_buffer *rxb)
> > next_reclaimed;
> > IWL_DEBUG_TX_REPLY(priv, "Next reclaimed 
> > packet:%d\n",
> >   next_reclaimed);
> > +   iwlagn_check_ratid_empty(priv, sta_id, tid);
> > }
> >
> > iwl_trans_reclaim(priv->trans, txq_id, ssn, );
> >
> > -   iwlagn_check_ratid_empty(priv, sta_id, tid);
> > freed = 0;
> >
> > /* process frames */
> 
> I can confirm it works. You can add my Tested-By.

Patch in review in our internal tree. It'll be upstreamed through the regular 
process.
Thanks for your report and debug work.

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

[Grumbach, Emmanuel]

Hi,

> Subject: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
> 
> Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid,
> which gives 16 possible values for tid.
> This is problematic because IWL_MAX_TID_COUNT is 8, so indexing
> iwl_priv::tid_data can go very wrong.

True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
that we don't index tid_data with this. Hence I think the proper fix is:

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
index 06ac3f1..16a8646 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
@@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, struct 
iwl_rx_cmd_buffer *rxb)
next_reclaimed;
IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
  next_reclaimed);
+   iwlagn_check_ratid_empty(priv, sta_id, tid);
}

iwl_trans_reclaim(priv->trans, txq_id, ssn, );

-   iwlagn_check_ratid_empty(priv, sta_id, tid);
freed = 0;

/* process frames */


Clearly calling iwlagn_check_ratid_empty with tid = IWL_TID_NON_QOS is a bad 
idea.

> 
> With UBSAN I can it happening while establishing the first connection
> after module load.
> 
> [  272.143440] UBSAN: Undefined behaviour in
> drivers/net/wireless/intel/iwlwifi/dvm/tx.c:777:32
> [  272.143447] index 8 is out of range for type 'iwl_tid_data [8]'
> [  272.143457] CPU: 0 PID: 4605 Comm: irq/32-iwlwifi Not tainted 4.12.0-dirty
> #2
> [  272.143460] Hardware name: Hewlett-Packard HP EliteBook 2560p/162B,
> BIOS 68SSU Ver. F.02 07/26/2011
> [  272.143462] Call Trace:
> [  272.143472]  dump_stack+0x9c/0x10b
> [  272.143477]  ? _atomic_dec_and_lock+0x285/0x285
> [  272.143486]  ubsan_epilogue+0xd/0x4e
> [  272.143493]  __ubsan_handle_out_of_bounds+0xef/0x118
> [  272.143498]  ? __ubsan_handle_shift_out_of_bounds+0x221/0x221
> [  272.143519]  ? iwl_trans_pcie_reclaim+0x153/0xc90 [iwlwifi]
> [  272.143539]  iwlagn_check_ratid_empty+0x337/0x410 [iwldvm]
> [  272.143556]  ? iwl_hcmd_names_cmp+0x2f/0x60 [iwlwifi]
> [  272.143571]  iwlagn_rx_reply_tx+0x8a4/0x1820 [iwldvm]
> 
> Signed-off-by: Seraphime Kirkovski 
> ---
>I'm currently running this patch on my machines and I have wifi.
>The patch presumes а cleanup patch, I sent yesterday:
>   https://www.spinics.net/lists/kernel/msg2526314.html
> 
>  drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> index 37d2ba5ae852..e5994df9ea4c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> @@ -1448,7 +1448,7 @@ struct agg_tx_status {
>   */
>  /* refer to ra_tid */
>  #define IWLAGN_TX_RES_TID_POS0
> -#define IWLAGN_TX_RES_TID_MSK0x0f
> +#define IWLAGN_TX_RES_TID_MSK0x07
>  #define IWLAGN_TX_RES_RA_POS 4
>  #define IWLAGN_TX_RES_RA_MSK 0xf0
> 
> --
> 2.11.0
> 
> -
> linuxw...@eclists.intel.com
> https://eclists.intel.com/sympa/info/linuxwifi
> Unsubscribe by sending email to sy...@eclists.intel.com with subject
> "Unsubscribe linuxwifi"

RE: Regression with Intel 3160 AP: client not reconnecting

[Grumbach, Emmanuel]

> 
> Hi Jarek,
> 
> [snip]
> 
> > What might be the cause? Is there anything I can do to help debug or
> > fix this?
> 
> Thanks for the detailed bug report and analysis! I can't analyse this in depth
> right now, can you please file a bug on bugzilla.kernel.org?

When you do so, please CC linuxw...@intel.com to the bug.

Thank you.

RE: [RFC 2/5] iwlwifi: fix request_module() use

[Grumbach, Emmanuel]

> 
> On Sun, Feb 19, 2017 at 09:47:59AM +, Grumbach, Emmanuel wrote:
> > >
> > > The return value of request_module() being 0 does not mean that the
> > > driver which was requested has loaded. To properly check that the
> > > driver was loaded each driver can use internal mechanisms to vet the
> > > driver is now present. The helper try_then_request_module() was
> > > added to help with this, allowing drivers to specify their own validation 
> > > as
> the first argument.
> > >
> > > On iwlwifi the use case is a bit more complicated given that the
> > > value we need to check for is protected with a mutex later used on
> > > the
> > > module_init() of the module we are asking for. If we were to lock
> > > and
> > > request_module() we'd deadlock. iwlwifi needs its own wrapper then
> > > so it can handle its special locking requirements.
> > >
> > > Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
> >
> > I don't see the problem with the current code. We don't assume that
> > everything has been loaded immediately after request_module returns.
> > We just free the intermediate firmware structures that won't be using
> > anymore. What happens here is that after request_module returns, we
> > patiently wait until it is loaded, and when that happens, iwl{d,m}vm's init
> function will be called.
> 
> Right I get that.
> 
> The code today complains if its respective opmode module was not loaded if
> request_module() did not return 0. As the commit log explains, relying on a
> return code of 0 to ensure a module loads is not sufficient. So the current
> print is almost pointless, so best we either:
> 
> a) just remove the print and use instead request_module_nowait() (this is
> more
>in alignment of what your code actually does today; or
> 
> b) fix the request_module() use so that the error print matches the
> expected
>and proper recommended use of request_module() (what this patch does)
> 
> I prefer a) actually but I had to show what b) looked like first :)
> 

Me too. Let's do the simple thing. After all, it's been working for 5 years now 
(maybe more?)
and I don't see a huge need to verify that the opmode module has been loaded.
It is very unlikely to fail anyway, and in the case it did fail, it's not that 
we can do much
from iwlwifi point of view. iwlwifi will stay loaded and sit idle since no 
opmode will
be there to start using the hardware. We will keep having the device claimed, 
and will
keep the interrupt registered and all that. No WiFi for you, but no harm caused 
either.

RE: [RFC 2/5] iwlwifi: fix request_module() use

[Grumbach, Emmanuel]

> 
> The return value of request_module() being 0 does not mean that the driver
> which was requested has loaded. To properly check that the driver was
> loaded each driver can use internal mechanisms to vet the driver is now
> present. The helper try_then_request_module() was added to help with
> this, allowing drivers to specify their own validation as the first argument.
> 
> On iwlwifi the use case is a bit more complicated given that the value we
> need to check for is protected with a mutex later used on the
> module_init() of the module we are asking for. If we were to lock and
> request_module() we'd deadlock. iwlwifi needs its own wrapper then so it
> can handle its special locking requirements.
> 
> Signed-off-by: Luis R. Rodriguez 

I don't see the problem with the current code. We don't assume that everything 
has been
loaded immediately after request_module returns. We just free the intermediate 
firmware
structures that won't be using anymore. What happens here is that after 
request_module
returns, we patiently wait until it is loaded, and when that happens, 
iwl{d,m}vm's init function
will be called. That one is the one that continues the flow by calling:

ret = iwl_opmode_register("iwlmvm", _mvm_ops);

(for the iwlmvm case).

Where am I wrong here?


> ---
>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 34 ---
> -
>  1 file changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index e198d6f5fcea..6beb92d19ea7 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1231,6 +1231,29 @@ static void _iwl_op_mode_stop(struct iwl_drv
> *drv)
>   }
>  }
> 
> +static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op,
> + struct iwl_drv *drv)
> +{
> + int ret = 0;
> +
> + ret = request_module("%s", op->name);
> + if (ret)
> + goto out;
> +
> + mutex_lock(_opmode_table_mtx);
> + if (!op->ops)
> + ret = -ENOENT;
> + mutex_unlock(_opmode_table_mtx);
> +
> +out:
> +#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> + if (ret)
> + IWL_ERR(drv,
> + "failed to load module %s (error %d), is dynamic
> loading enabled?\n",
> + op->name, ret);
> +#endif
> +}
> +
>  /**
>   * iwl_req_fw_callback - callback when firmware was loaded
>   *
> @@ -1471,15 +1494,8 @@ static void iwl_req_fw_callback(const struct
> firmware *ucode_raw, void *context)
>* else from proceeding if the module fails to load
>* or hangs loading.
>*/
> - if (load_module) {
> - err = request_module("%s", op->name);
> -#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> - if (err)
> - IWL_ERR(drv,
> - "failed to load module %s (error %d), is
> dynamic loading enabled?\n",
> - op->name, err);
> -#endif
> - }
> + if (load_module)
> + iwlwifi_try_load_op(op, drv);
>   goto free;
> 
>   try_again:
> --
> 2.11.0

RE: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure

[Grumbach, Emmanuel]

Hi Luis,

> 
> The firmware async callback handles the device's opmode start call, but
> optionally also allows opmode registration to take care of its opmode start. 
> If
> the firmware callback handles it its error path in case of opmode start 
> failure
> has a few pieces of code missing from the opmode registration. The opmode
> registration hanlder has no cleanup at all. Sync both error paths.
> 
> This should in theory fix a detangled drv from the drv list should either of 
> the
> opmode modules loaded and handled registration for the drv.
> 
> The path of having the opmode registration deal with the drv opmode start is
> actually the more common path. The other path, from the async callback is
> rathe rare (1/8 or so times for me) -- it happens when the the opmode
> driver's init routine completed prior to the driver's async callback opmode
> start call.

I'd claim it should never happen unless you have several devices on the system 
using the same
opmode, or unless you do:
modprobe iwlwifi  #which will load iwl{d,m}vm
rmmod iwl{d,m}vm #and do _not_ remove iwlwifi
modprobe iwlwifi



> 
> Signed-off-by: Luis R. Rodriguez 
> ---

Luca is OOO,  but this looks fine to me.


>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index be466a074c1d..e198d6f5fcea 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1611,8 +1611,13 @@ int iwl_opmode_register(const char *name, const
> struct iwl_op_mode_ops *ops)
>   continue;
>   op->ops = ops;
>   /* TODO: need to handle exceptional case */
> - list_for_each_entry(drv, >drv, list)
> + list_for_each_entry(drv, >drv, list) {
>   drv->op_mode = _iwl_op_mode_start(drv, op);
> + if (!drv->op_mode) {
> + complete(
> >request_firmware_complete);
> + device_release_driver(drv->trans->dev);
> + }
> + }
> 
>   mutex_unlock(_opmode_table_mtx);
>   return 0;
> --
> 2.11.0

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

[Grumbach, Emmanuel]

On Thu, 2016-09-15 at 10:59 -0700, Ben Greear wrote:
> On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> > On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote:
> > > On 09/15/2016 07:06 AM, Valo, Kalle wrote:
> > > > Ben Greear <gree...@candelatech.com> writes:
> > > > 
> > > > > On 09/14/2016 07:18 AM, Valo, Kalle wrote:
> > > > > > gree...@candelatech.com writes:
> > > > > > 
> > > > > > > From: Ben Greear <gree...@candelatech.com>
> > > > > > > 
> > > > > > > This allows user-space tools to decode debug-log
> > > > > > > messages by parsing dmesg or /var/log/messages.
> > > > > > > 
> > > > > > > Signed-off-by: Ben Greear <gree...@candelatech.com>
> > > > > > 
> > > > > > Don't tracing points already provide the same information?
> > > > > 
> > > > > Tracing tools are difficult to set up and may not be
> > > > > available on
> > > > > random embedded devices.  And if we are dealing with bug
> > > > > reports
> > > > > from
> > > > > the field, most users will not be able to set it up
> > > > > regardless.
> > > > > 
> > > > > There are similar ways to print out hex, but the logic below
> > > > > creates
> > > > > specific and parseable logs in the 'dmesg' output and
> > > > > similar.
> > > > > 
> > > > > I have written a tool that can decode these messages into
> > > > > useful
> > > > > human-readable
> > > > > text so that I can debug firmware issues both locally and
> > > > > from
> > > > > field reports.
> > > > > 
> > > > > Stock firmware generates similar logs and QCA could write
> > > > > their
> > > > > own decode logic
> > > > > for their firmware versions.
> > > > 
> > > > Reinventing the wheel by using printk as the delivery mechanism
> > > > doesn't
> > > > sound like a good idea. IIRC Emmanuel talked about some kind of
> > > > firmware
> > > > debugging framework, he might have some ideas.
> > > 
> > > Waiting for magical frameworks to fix problems is even worse.
> > > 
> > It has been years since ath10k has been in the kernel.  There is
> > > basically
> > > still no way to debug what the firmware is doing.
> > > 
> > 
> > I know the feeling :) I was in the same situation before I added
> > stuff
> > for iwlwifi.
> > 
> > > My patch gives you something that can work right now, with the
> > > standard 'dmesg'
> > > framework found in virtually all kernels new and old, and it has
> > > been
> > > proven
> > > to be useful in the field.  The messages are also nicely
> > > interleaved
> > > with the
> > > rest of the mac80211 stack messages and any other driver
> > > messages, so
> > > you have
> > > context.
> > > 
> > > If someone wants to add support for a framework later, then by
> > > all
> > > means, post
> > > the patches when it is ready.
> > 
> > From my experience, a strong and easy-to-use firmware debug
> > infrastructure is important because typically, the firmware is
> > written
> > by other people who have different priorities (and are not always
> > Linux
> > wizards) etc... Being able to give them good data is the only way
> > to
> > have them fix their bugs :) For us, it was really a game changer.
> > When
> > you work for a big corporate, having 2 groups work better together
> > always has a big impact. That's for the philosophical part :)
> > 
> > FWIW: what I did has nothing to do with FW 'live tracing', but with
> > firmware dumps. One part of our firmware dumps include tracing. We
> > also
> > have "firmware prints", but we don't print them in the kernel log
> > and
> > they are not part of the firmware dump thing. We rather record them
> > in
> > tracepoints just like really *anything* that comes from the
> > firmware.
> > Basically, we have 2 layers, the transport layer (PCIe) and the
> > operation_mode layer. The first just brings the data from the
> > firmware
> > and in that layer we *blindly* record everything in tracepoints. In
> > the
> >

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

[Grumbach, Emmanuel]

On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote:
> On 09/15/2016 07:06 AM, Valo, Kalle wrote:
> > Ben Greear  writes:
> > 
> > > On 09/14/2016 07:18 AM, Valo, Kalle wrote:
> > > > gree...@candelatech.com writes:
> > > > 
> > > > > From: Ben Greear 
> > > > > 
> > > > > This allows user-space tools to decode debug-log
> > > > > messages by parsing dmesg or /var/log/messages.
> > > > > 
> > > > > Signed-off-by: Ben Greear 
> > > > 
> > > > Don't tracing points already provide the same information?
> > > 
> > > Tracing tools are difficult to set up and may not be available on
> > > random embedded devices.  And if we are dealing with bug reports
> > > from
> > > the field, most users will not be able to set it up regardless.
> > > 
> > > There are similar ways to print out hex, but the logic below
> > > creates
> > > specific and parseable logs in the 'dmesg' output and similar.
> > > 
> > > I have written a tool that can decode these messages into useful
> > > human-readable
> > > text so that I can debug firmware issues both locally and from
> > > field reports.
> > > 
> > > Stock firmware generates similar logs and QCA could write their
> > > own decode logic
> > > for their firmware versions.
> > 
> > Reinventing the wheel by using printk as the delivery mechanism
> > doesn't
> > sound like a good idea. IIRC Emmanuel talked about some kind of
> > firmware
> > debugging framework, he might have some ideas.
> 
> Waiting for magical frameworks to fix problems is even worse.
> 
It has been years since ath10k has been in the kernel.  There is
> basically
> still no way to debug what the firmware is doing.
> 

I know the feeling :) I was in the same situation before I added stuff
for iwlwifi.

> My patch gives you something that can work right now, with the
> standard 'dmesg'
> framework found in virtually all kernels new and old, and it has been
> proven
> to be useful in the field.  The messages are also nicely interleaved
> with the
> rest of the mac80211 stack messages and any other driver messages, so
> you have
> context.
> 
> If someone wants to add support for a framework later, then by all
> means, post
> the patches when it is ready.

From my experience, a strong and easy-to-use firmware debug
infrastructure is important because typically, the firmware is written
by other people who have different priorities (and are not always Linux
wizards) etc... Being able to give them good data is the only way to
have them fix their bugs :) For us, it was really a game changer. When
you work for a big corporate, having 2 groups work better together
always has a big impact. That's for the philosophical part :)

FWIW: what I did has nothing to do with FW 'live tracing', but with
firmware dumps. One part of our firmware dumps include tracing. We also
have "firmware prints", but we don't print them in the kernel log and
they are not part of the firmware dump thing. We rather record them in
tracepoints just like really *anything* that comes from the firmware.
Basically, we have 2 layers, the transport layer (PCIe) and the
operation_mode layer. The first just brings the data from the firmware
and in that layer we *blindly* record everything in tracepoints. In the
operation_mode layer, we look at the data itself. In case of debug
prints from the firmware, we simply discard them, because we don't
really care of the meaning. All we want is to have them go through the
PCIe layer so that they are recorded in the tracepoints.
When we finish recording the sequence we wanted with tracing (trace
-cmd), we parse the output and then, we parse the firmware prints.
IMHO, this is more reliable than kernel logs and you don't lose the
alignment with the driver traces as long as you have driver data in
tracepoints as well.

> 
> Thanks,
> Ben
> 
> 

pull request: iwlwifi 2016-04-12

[Grumbach, Emmanuel]

Hi Kalle,

Here is a pull request for 4.6. I have here a patch that was merged to 
-next already, but clearly, it should have been routed through the
current cycle's trees. Sorry about that.
The patch is:

commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
Author: Ayala Beker 
Date:   Wed Feb 3 15:36:52 2016 +0200

iwlwifi: mvm: avoid to WARN about gscan capabilities

Gscan capabilities were updated with new capabilities supported
by the device. Update GSCAN capabilities TLV and avoid to WARN
if the firmware does not have the new capabilities.

It appears in -next as:

commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
Author: Ayala Beker 
Date:   Wed Feb 3 15:36:52 2016 +0200

iwlwifi: mvm: update GSCAN capabilities

Gscan capabilities were updated with new capabilities supported
by the device. Update GSCAN capabilities TLV.

The commit message wasn't good enough for the current cycle, so I
rewrote it. Besides that one, all is fairly normal.
Let me know if you have issues!

Thanks.


The following changes since commit 7fdf9663261cc77a516396fec82cee8a8ea07e76:

  iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-04-12

for you to fetch changes up to 2d25fb8b3a138706b63bd26ad72a95c58029954a:

  iwlwifi: mvm: fix accessing Null pointer during fw dump collection 
(2016-04-12 10:03:17 +0300)


* add new device IDs for 8265
* fix a NULL pointer dereference when paging firmware asserts
* remove a WARNING on gscan capabilities
* fix MODULE_FIRMWARE for 8260


Ayala Beker (1):
  iwlwifi: mvm: avoid to WARN about gscan capabilities

Matti Gottlieb (1):
  iwlwifi: mvm: fix accessing Null pointer during fw dump collection

Oren Givon (1):
  iwlwifi: add device IDs for the 8265 device

Sara Sharon (1):
  iwlwifi: 8000: fix MODULE_FIRMWARE input

 drivers/net/wireless/intel/iwlwifi/iwl-8000.c   |  2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c| 26 ++
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c |  6 --
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c |  2 ++
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c   | 10 ++
 5 files changed, 27 insertions(+), 19 deletions(-)

RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Grumbach, Emmanuel]

> On 07/15/2016 07:25 AM, Stanislaw Gruszka wrote:
> > On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote:
> >>> If I understad correctly this error happen 100% of the time, not
> >>> only during init. Hence seems there is an issue here, i.e. cur_ucode
> >>> is not marked correctly as IWL_UCODE_REGULAR or
> iwl_mvm_get_temp()
> >>> fail 100% of the time (iwl_mvm_is_tt_in_fw() incorrecly return true on
> Prarit device ? ).
> >>
> >> Cur_ucode will not be IWL_UCODE_REGULAR until you load the firmware
> >> which will happen upon ifup.
> >
> > Then creating thermal_device on ifup looks more reasonable to me.
> > Otherwise we can create device that can be non-functional virtually
> > forever, i.e. when soft RFKILL is enabled. However I admit that
> > creating thermal_device when HW is detected has some advantages too.
> 
> That's my plan right now.  Unfortunately something else in the kernel seems
> recently broken and is preventing me from testing.  I will get back to this
> early next week.
> 

But we already said that this won't work since you may have the device enabled 
upon boot and then disabled. So unless you unregister the thermal zone 
subsystem upon wifi disable, you won't solve the problem. Kalle and Luca 
already refused that solution.

I glanced (again) at the thermal zone API and since it allows to return an int, 
the subsystem itself should handle the failures and / or the userspace 
problems. The API itself is awful, it has no documentation whatsoever, even not 
variable names, but only types... You can't really blame the subsystem users to 
assume that a method that can return an int can't fail where the out values is 
passed by a pointer. Of course, you have to guess that this is the expected 
behavior, since you don't have any hint about the meaning of the parameters.
I think that the right place to "fix" this problem is to fix the subsystem. 
This way, you will fix it for iwlwifi and for any (future) other users that may 
fall into the trap opened by the API itself.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Grumbach, Emmanuel]

> 
> On Mon, Jul 11, 2016 at 06:27:30PM +, Grumbach, Emmanuel wrote:
> > I guess that works, but it seems wrong to me. Usually, registration
> > should happen only upon INIT, and yes, at that time the firmware is
> > not ready to provide the information yet.
> 
> > >
> > > As can be seen in the current code base, iwl_mvm_tzone_get_temp()
> > > will return -EIO 100% of the time when the firmware doesn't support
> > > reading the
> 
> If I understad correctly this error happen 100% of the time, not only during
> init. Hence seems there is an issue here, i.e. cur_ucode is not marked
> correctly as IWL_UCODE_REGULAR or iwl_mvm_get_temp() fail 100% of the
> time (iwl_mvm_is_tt_in_fw() incorrecly return true on Prarit device ? ).

Cur_ucode will not be IWL_UCODE_REGULAR until you load the firmware which
will happen upon ifup.

> 
> BTW, you implement thermal_zone device, but do you also need hwmon
> device? Perhaps using theramal_zone_params no_hwmon option would be
> proper here?

That's an interesting direction. I'd have to check, but TBH, I am not familiar 
with
that code. Luca was very involved during the development but he is not available
right now. I will be back more the less when the merge window will close :)

> 
> Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] iwlwifi: mvm: use setup_timer instead of init_timer and data fields

[Grumbach, Emmanuel]

On Tue, 2016-07-12 at 11:40 +, weiyj...@163.com wrote:
> From: Wei Yongjun 
> 
> Use setup_timer function instead of initializing timer with the
> function
> and data fields
> 
> Signed-off-by: Wei Yongjun 
> ---

Thanks - I picked it up and uploaded it to our internal tree.

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Grumbach, Emmanuel]

On Mon, 2016-07-11 at 14:19 -0400, Prarit Bhargava wrote:
> 
> On 07/11/2016 02:00 PM, Emmanuel Grumbach wrote:
> > On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava  > > wrote:
> > > 
> > > Didn't get any feedback or review comments on this patch. 
> > >  Resending ...
> > > 
> > > P.
> > 
> > This change is obviously completely broken. It simply disables the
> > registration to thermal zone core.
> 
> No it is not broken, and yes, that is exactly what should happen IMO.
> 
> The problem is that the iwlwifi driver implements the thermal zone
> even when the
> device doesn't support it.

We implement thermal zone because we do support it, but the problem is
that we need the firmware to be loaded for that. So you can argue that
we should register *later* when the firmware is loaded. But this is
really not helping all that much because the firmware can also be
stopped at any time. So you'd want us to register / unregister the
thermal zone anytime the firmware is loaded / unloaded?
I guess that works, but it seems wrong to me. Usually, registration
should happen only upon INIT, and yes, at that time the firmware is not
ready to provide the information yet.
Maybe returning -EBUSY would help lm-sensors not to get confused?

> 
> As can be seen in the current code base, iwl_mvm_tzone_get_temp()
> will return
> -EIO 100% of the time when the firmware doesn't support reading the
> temperature[1].  In this case a read of sysfs will result in a return
> of -EIO,
> and this breaks existing userspace programs such as lm-sensors (which
> by all
> accounts is bad to do).

Right, but I don't understand why the userspace is broken because of
that? Unless we register / unregister anytime the firmware is loaded, I
don't see any proper way to fix this. And yes, I'd expect the userspace
to handle gracefully failures in its requests.

> 
> Note that in my patch I have removed the -EIO return in favor of not
> registering
> the non-existent thermal zone.  I'm not removing any functionality by
> changing
> this, nor am I adding functionality.  In both cases the thermal zone
> is not
> functional, and with my patch userspace continues to work.

You are removing the thermal zone functionality since even when the
firmware will be loaded (which typically happens fairly quickly),
thermal zone won't work.

> 
> P.
> 
> [1] iwl_mvm_tzone_set_trip_temp() also returns -EIO, so setting and
> getting of
> the temperature is non-functional.
> 
> 
> > 
> > > 
> > > ---8<---
> > > 
> > > The iwlwifi driver implements a thermal zone and hwmon device,
> > > but
> > > returns -EIO on temperature reads if the firmware isn't loaded. 
> > >  This
> > > results in the error
> > > 
> > > iwlwifi-virtual-0
> > > Adapter: Virtual device
> > > ERROR: Can't get value of subfeature temp1_input: I/O error
> > > temp1:N/A
> > > 
> > > being output when using sensors from the lm-sensors package. 
> > >  Since
> > > the temperature cannot be read unless the ucode is loaded there
> > > is no
> > > reason to add the interface only to have it return an error 100%
> > > of
> > > the time.
> > > 
> > > This patch moves the firmware check to
> > > iwl_mvm_thermal_zone_register() and
> > > stops the thermal zone from being created if the ucode hasn't
> > > been loaded.
> > > 
> > > Signed-off-by: Prarit Bhargava 
> > > Cc: Johannes Berg 
> > > Cc: Emmanuel Grumbach 
> > > Cc: Luca Coelho 
> > > Cc: Intel Linux Wireless 
> > > Cc: Kalle Valo 
> > > Cc: Chaya Rachel Ivgi 
> > > Cc: Sara Sharon 
> > > Cc: linux-wireless@vger.kernel.org
> > > Cc: net...@vger.kernel.org
> > > ---
> > >  drivers/net/wireless/intel/iwlwifi/mvm/tt.c |   13 +++--
> > >  1 file changed, 3 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > index 58fc7b3c711c..64802659711f 100644
> > > --- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > @@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct
> > > thermal_zone_device *device,
> > > 
> > > mutex_lock(>mutex);
> > > 
> > > -   if (!mvm->ucode_loaded || !(mvm->cur_ucode ==
> > > IWL_UCODE_REGULAR)) {
> > > -   ret = -EIO;
> > > -   goto out;
> > > -   }
> > > -
> > > ret = iwl_mvm_get_temp(mvm, );
> > > if (ret)
> > > goto out;
> > > @@ -684,11 +679,6 @@ static int
> > > iwl_mvm_tzone_set_trip_temp(struct thermal_zone_device *device,
> > > 
> > > mutex_lock(>mutex);
> > > 
> > > -   if (!mvm->ucode_loaded || !(mvm->cur_ucode ==
> > > IWL_UCODE_REGULAR)) {
> > > -   ret = -EIO;
> > > -   goto out;
> > > -   }
> > > -
> > > if 

pull request: new firmware files for all mvm wireless devices

[Grumbach, Emmanuel]

Hi Kyle,

Intel is releasing new firmware versions for all its mvm wireless
devices.
For devices 7260, 7265 and 3160, this is the last firmware updates. We
may still have critical bug fixes, but those won't get any new major
releases. They will stay with -17.ucode.
For 7265D and up, we release here the -22.ucode version.

Please pull.

Thanks!

The following changes since commit a14150061388f4bcbf3c3499f1b12e3f0d5c0e7b:

  linux-firmware: Fix the filename for WsP to align with device HW_VARIANT 
(2016-07-08 18:07:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git 
tags/iwlwifi-fw-2016-07-10

for you to fetch changes up to b224bd0c77370a58b996a7be2c322b9fb4849398:

  iwlwifi: add new -22 firmware for 7265D and up (2016-07-10 09:41:14 +0300)


Release -21.ucode for 7265D and up
Release -17.ucode for 7260 / 7265 and 3160


Emmanuel Grumbach (2):
  iwlwifi: add new -17 firmware for iwlmvm devices
  iwlwifi: add new -22 firmware for 7265D and up

 WHENCE |  24 
 iwlwifi-3160-17.ucode  | Bin 0 -> 918268 bytes
 iwlwifi-3168-22.ucode  | Bin 0 -> 1028032 bytes
 iwlwifi-7260-17.ucode  | Bin 0 -> 1049340 bytes
 iwlwifi-7265-17.ucode  | Bin 0 -> 1180412 bytes
 iwlwifi-7265D-17.ucode | Bin 0 -> 1383604 bytes
 iwlwifi-7265D-22.ucode | Bin 0 -> 1028316 bytes
 iwlwifi-8000C-22.ucode | Bin 0 -> 2120860 bytes
 iwlwifi-8265-22.ucode  | Bin 0 -> 1811984 bytes
 9 files changed, 24 insertions(+)
 create mode 100644 iwlwifi-3160-17.ucode
 create mode 100644 iwlwifi-3168-22.ucode
 create mode 100644 iwlwifi-7260-17.ucode
 create mode 100644 iwlwifi-7265-17.ucode
 create mode 100644 iwlwifi-7265D-17.ucode
 create mode 100644 iwlwifi-7265D-22.ucode
 create mode 100644 iwlwifi-8000C-22.ucode
 create mode 100644 iwlwifi-8265-22.ucode

diff --git a/WHENCE b/WHENCE
index c3d98f6..4c41f21 100644
--- a/WHENCE
+++ b/WHENCE
@@ -848,6 +848,9 @@ Version: 25.30.13.0
 File: iwlwifi-7260-16.ucode
 Version 16.242414.0
 
+File: iwlwifi-7260-17.ucode
+Version 17.352738.0
+
 File: iwlwifi-3160-7.ucode
 Version: 22.1.7.0
 
@@ -869,6 +872,9 @@ Version: 25.30.13.0
 File: iwlwifi-3160-16.ucode
 Version 16.242414.0
 
+File: iwlwifi-3160-17.ucode
+Version 17.352738.0
+
 File: iwlwifi-7265-8.ucode
 Version: 22.24.8.0
 
@@ -887,6 +893,9 @@ Version: 25.30.13.0
 File: iwlwifi-7265-16.ucode
 Version 16.242414.0
 
+File: iwlwifi-7265-17.ucode
+Version 17.352738.0
+
 File: iwlwifi-7265D-10.ucode
 Version: 23.15.10.0
 
@@ -899,12 +908,21 @@ Version: 25.30.13.0
 File: iwlwifi-7265D-16.ucode
 Version 16.242414.0
 
+File: iwlwifi-7265D-17.ucode
+Version 17.352738.0
+
 File: iwlwifi-7265D-21.ucode
 Version 21.302800.0
 
+File: iwlwifi-7265D-22.ucode
+Version 22.361476.0
+
 File: iwlwifi-3168-21.ucode
 Version 21.302800.0
 
+File: iwlwifi-3168-22.ucode
+Version 22.361476.0
+
 File: iwlwifi-8000C-13.ucode
 Version: 25.30.13.0
 
@@ -914,9 +932,15 @@ Version 16.242414.0
 File: iwlwifi-8000C-21.ucode
 Version 21.302800.0
 
+File: iwlwifi-8000C-22.ucode
+Version 22.361476.0
+
 File: iwlwifi-8265-21.ucode
 Version 21.302800.0
 
+File: iwlwifi-8265-22.ucode
+Version 22.361476.0
+
 Licence: Redistributable. See LICENCE.iwlwifi_firmware for details
 
 Also available from 
http://wireless.kernel.org/en/users/Drivers/iwlwifi#Firmware
diff --git a/iwlwifi-3160-17.ucode b/iwlwifi-3160-17.ucode
new file mode 100644
index 000..e58f715
Binary files /dev/null and b/iwlwifi-3160-17.ucode differ
diff --git a/iwlwifi-3168-22.ucode b/iwlwifi-3168-22.ucode
new file mode 100644
index 000..d969aed
Binary files /dev/null and b/iwlwifi-3168-22.ucode differ
diff --git a/iwlwifi-7260-17.ucode b/iwlwifi-7260-17.ucode
new file mode 100644
index 000..6f5d713
Binary files /dev/null and b/iwlwifi-7260-17.ucode differ
diff --git a/iwlwifi-7265-17.ucode b/iwlwifi-7265-17.ucode
new file mode 100644
index 000..f2bf30e
Binary files /dev/null and b/iwlwifi-7265-17.ucode differ
diff --git a/iwlwifi-7265D-17.ucode b/iwlwifi-7265D-17.ucode
new file mode 100644
index 000..66940c4
Binary files /dev/null and b/iwlwifi-7265D-17.ucode differ
diff --git a/iwlwifi-7265D-22.ucode b/iwlwifi-7265D-22.ucode
new file mode 100644
index 000..26ca1bd
Binary files /dev/null and b/iwlwifi-7265D-22.ucode differ
diff --git a/iwlwifi-8000C-22.ucode b/iwlwifi-8000C-22.ucode
new file mode 100644
index 000..93a828b
Binary files /dev/null and b/iwlwifi-8000C-22.ucode differ
diff --git a/iwlwifi-8265-22.ucode b/iwlwifi-8265-22.ucode
new file mode 100644
index 000..3dbeb83
Binary files /dev/null and b/iwlwifi-8265-22.ucode differ

RE: Problem: iwlwifi: Microcode SW error detected. Restarting 0x2000000

[Grumbach, Emmanuel]

> 
> Emmanuel Grumbach wrote:
> > In that case, please try -21.ucode and send me again the output of the
> firmware error.
> 
> $ dmesg | grep iwlwifi
> [   14.858440] iwlwifi :04:00.0: Unsupported splx structure
> [   14.863591] iwlwifi :04:00.0: loaded firmware version 21.361477.0
> op_mode iwlmvm
> [   14.891553] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless AC 7265, REV=0x210
> [   14.893883] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [   14.894346] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [   24.346547] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [   24.347232] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [   24.413520] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [   24.414081] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [  455.386139] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [  455.386709] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
> [  455.610758] iwlwifi :04:00.0: Microcode SW error detected.
> Restarting 0x200.
> [  455.610761] iwlwifi :04:00.0: CSR values:
> [  455.610763] iwlwifi :04:00.0: (2nd byte of CSR_INT_COALESCING is
> CSR_INT_PERIODIC_REG)
> [  455.610787] iwlwifi :04:00.0:CSR_HW_IF_CONFIG_REG: 0X00c89200
> [  455.610842] iwlwifi :04:00.0:  CSR_INT_COALESCING: 0X0040
> [  455.610893] iwlwifi :04:00.0: CSR_INT: 0X
> [  455.610944] iwlwifi :04:00.0:CSR_INT_MASK: 0X
> [  455.610995] iwlwifi :04:00.0:   CSR_FH_INT_STATUS: 0X
> [  455.611046] iwlwifi :04:00.0: CSR_GPIO_IN: 0X
> [  455.611097] iwlwifi :04:00.0:   CSR_RESET: 0X
> [  455.611149] iwlwifi :04:00.0:CSR_GP_CNTRL: 0X080403c5
> [  455.611200] iwlwifi :04:00.0:  CSR_HW_REV: 0X0210
> [  455.611251] iwlwifi :04:00.0:  CSR_EEPROM_REG: 0Xd5d5
> [  455.611302] iwlwifi :04:00.0:   CSR_EEPROM_GP: 0X
> [  455.611353] iwlwifi :04:00.0:  CSR_OTP_GP_REG: 0Xd5d5
> [  455.611404] iwlwifi :04:00.0: CSR_GIO_REG: 0X00080042
> [  455.611455] iwlwifi :04:00.0:CSR_GP_UCODE_REG: 0X
> [  455.611506] iwlwifi :04:00.0:   CSR_GP_DRIVER_REG: 0X
> [  455.611557] iwlwifi :04:00.0:   CSR_UCODE_DRV_GP1: 0X
> [  455.611608] iwlwifi :04:00.0:   CSR_UCODE_DRV_GP2: 0X
> [  455.611660] iwlwifi :04:00.0: CSR_LED_REG: 0X0018
> [  455.611711] iwlwifi :04:00.0:CSR_DRAM_INT_TBL_REG:
> 0X881288b0
> [  455.611762] iwlwifi :04:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200
> [  455.611813] iwlwifi :04:00.0: CSR_ANA_PLL_CFG: 0Xd5d5
> [  455.611867] iwlwifi :04:00.0:  CSR_MONITOR_STATUS_REG:
> 0Xd3b7ff77
> [  455.611921] iwlwifi :04:00.0:   CSR_HW_REV_WA_REG: 0X0001001a
> [  455.611971] iwlwifi :04:00.0:CSR_DBG_HPET_MEM_REG:
> 0X
> [  455.611973] iwlwifi :04:00.0: FH register values:
> [  455.612035] iwlwifi :04:00.0:
> FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X0b357d00
> [  455.612047] iwlwifi :04:00.0:
> FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X00b2de60
> [  455.612058] iwlwifi :04:00.0:
> FH_RSCSR_CHNL0_WPTR: 0X
> [  455.612070] iwlwifi :04:00.0:
> FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00801114
> [  455.612082] iwlwifi :04:00.0:
> FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc
> [  455.612093] iwlwifi :04:00.0:
> FH_MEM_RSSR_RX_STATUS_REG: 0X0303
> [  455.612105] iwlwifi :04:00.0:
> FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
> [  455.612117] iwlwifi :04:00.0:
> FH_TSSR_TX_STATUS_REG: 0X07ff0001
> [  455.612128] iwlwifi :04:00.0:
> FH_TSSR_TX_ERROR_REG: 0X
> [  455.612237] iwlwifi :04:00.0: Start IWL Error Log Dump:
> [  455.612239] iwlwifi :04:00.0: Status: 0x, count: 6
> [  455.612240] iwlwifi :04:00.0: Loaded firmware version: 21.361477.0
> [  455.612242] iwlwifi :04:00.0: 0x0034 | NMI_INTERRUPT_WDG
> 
> [  455.612243] iwlwifi :04:00.0: 0x02F0 | trm_hw_status0
> [  455.612245] iwlwifi :04:00.0: 0x | trm_hw_status1
> [  455.612246] iwlwifi :04:00.0: 0x000401CE | branchlink2
> [  455.612247] iwlwifi :04:00.0: 0x0004446C | interruptlink1
> [  455.612249] iwlwifi :04:00.0: 0x5C9A | interruptlink2
> [  455.612250] iwlwifi :04:00.0: 0x | data1
> [  455.612251] iwlwifi :04:00.0: 0x0002 | data2
> [  455.612252] iwlwifi :04:00.0: 0x0703 | data3
> [  455.612254] iwlwifi :04:00.0: 0x003CB2E5 | beacon time
> [  455.612255] iwlwifi :04:00.0: 0x00034D19 | tsf low
> [  455.612256] iwlwifi :04:00.0: 0x | tsf hi
> [  455.612257] iwlwifi :04:00.0: 0x | time gp1
> [  455.612259] iwlwifi :04:00.0: 0x00034D1A | time gp2
> [  455.612260] iwlwifi :04:00.0: 0x | uCode revision 

RE: Problem: iwlwifi: Microcode SW error detected. Restarting 0x2000000

[Grumbach, Emmanuel]

> 
> Emmanuel Grumbach wrote:
> > Can you please try the newest firmware?
> > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-
> firmware.git/commit/?id=72266846faa78b939a864842a2aa6ecd8fe6989b
> 
> Yes, I've tried the newest firmware. The problem still persists.
> 
> > You should pick up the -17.ucode version.
> > Note that I can't know if your device is 7265 or 7265D. In able to 
> > determine,
> please check:
> >
> https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#and_7265_support
> 
> Yes, it's a 7265D.

In that case, please try -21.ucode and send me again the output of the firmware 
error.


> 
> > Thank you!
> 
> Thank you.

RE: Problem: iwlwifi: Microcode SW error detected. Restarting 0x2000000

[Grumbach, Emmanuel]

> 
> With a current kernel my wifi won't work after suspending and resuming
> my laptop (a ThinkPadd 11e).
> This has worked in 4.0.0 and below, so this is a regression.
> The commit that introduced this issue is
> 8d193ca26cc28019e760b77830295a0c349d90dc.
> 
> How to reproduce:
>  1. Boot.
>  2. Make sure that you are connected to wifi.
>  3. Suspend.
>  4. Wait a bit of time.
>  5. Resume.
>  6. See that the wifi is no longer functional.

This is very strange. I don't really see how the commit you mentioned can cause
this issue.

Can you please try the newest firmware?
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/commit/?id=72266846faa78b939a864842a2aa6ecd8fe6989b
You should pick up the -17.ucode version.
Note that I can't know if your device is 7265 or 7265D. In able to determine, 
please check:
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#and_7265_support


Thank you!

pull request: iwlwifi 2016-05-04

[Grumbach, Emmanuel]

Hi Kalle,

I know it is extremely late in the cycle, but this patch is intended
for 4.6... It fixes a regression I introduced: a P2P specification
violation as mentioned in the commit message.
The patch is rather big in terms of number of lines changed, but the
semantics is very simple. I have to copy the control block of the skb
to the stack whereas we accessed we used to access it directly through
a pointer.
This obviously introduces a lot of line changes, but don't really
change the behavior of the code (since most of the accesses are read
only).

Let me know how it goes.

I take this opportunity to inform you that I will be replaced by Luca
for a few months at least. I will be working full steam on a side
project that will not allow me to do the maintainer job in parallel.

Thank you!

The following changes since commit f742aaf36edf0390c54d0614bc4d20fd4cd3762a:

  iwlwifi: mvm: fix accessing Null pointer during fw dump collection 
(2016-04-12 11:52:39 +0300)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-05-04

for you to fetch changes up to 5c08b0f5026fcc13efb947c4d1f2ca3558145f68:

  iwlwifi: mvm: don't override the rate with the AMSDU len (2016-05-04 20:59:55 
+0300)


* fix P2P rates (and possibly other issues)


Emmanuel Grumbach (1):
  iwlwifi: mvm: don't override the rate with the AMSDU len

 drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 83 
---
 1 file changed, 48 insertions(+), 35 deletions(-)

Re: RSS configuration in iwlwifi

[Grumbach, Emmanuel]

On Wed, 2016-04-20 at 19:22 +0300, Emmanuel Grumbach wrote:
> On Wed, 2016-04-20 at 16:47 +0100, Ben Hutchings wrote:
> > On Wed, 2016-04-20 at 15:30 +, Grumbach, Emmanuel wrote:
> > > Hi Ben,
> > > 
> > > 
> > > Thanks for looking at our code.
> > > 
> > > 
> > > On Wed, 2016-04-20 at 16:08 +0100, Ben Hutchings wrote:
> > > > 
> > > > I'm not sure if you were aware, but there is a standard API for
> > > > configuring RSS in network drivers, part of ethtool_ops.  I
> > > > think
> > > > iwlwifi should implement that rather than a driver-specific
> > > > debugfs
> > > > interface.
> > > > 
> > > You are right, this is why Sara made this commit:
> > > 
> > > commit 854d773e4ab586924af4ca5d851730849903
> > > Author: Sara Sharon <sara.sha...@intel.com>
> > > Date:   Tue Mar 22 15:55:58 2016 +0200
> > > 
> > > iwlwifi: mvm: improve RSS configuration
> > > 
> > > Improve current RSS configuration:
> > >  * Use netdev_rss_key instead of keeping a local copy.
> > >  * Configure also UDP hashing to have UDP traffic spread
> > > across
> > > queues.
> > >  Do not direct RSS traffic to our fallback queue.
> > > 
> > > Signed-off-by: Sara Sharon <sara.sha...@intel.com>
> > > Signed-off-by: Emmanuel Grumbach <emmanuel.grumb...@intel.com
> > > >
> > 
> > That doesn't really address what I said.  Yes, it's using the
> > common
> > RSS key, but it's not implementing the ethtool operations to get
> > and
> > set the indirection table and the types of flow hashing that are
> > enabled.
> > 
> 
> Hm.. I think that setting the indirection table is a problem in our
> case because the PN check is done in the driver. The PN check is the
> way WiFi addresses the replay attack, and since the PN check relies
> on
> per-cpu variables, we cannot *safely* allow users to modify the
> indirection table while traffic is flowing.
> 

Oh - and yes, we do have a debugfs hook for that. It was meant for the
very early testing phases. I guess that we should remove it at some
point, unless we decide that whoever wants to play with the indirection
table while inbound traffic is flowing puts himself at risk.

> > Ben.
> > 

Re: RSS configuration in iwlwifi

[Grumbach, Emmanuel]

On Wed, 2016-04-20 at 16:47 +0100, Ben Hutchings wrote:
> On Wed, 2016-04-20 at 15:30 +0000, Grumbach, Emmanuel wrote:
> > Hi Ben,
> > 
> > 
> > Thanks for looking at our code.
> > 
> > 
> > On Wed, 2016-04-20 at 16:08 +0100, Ben Hutchings wrote:
> > > 
> > > I'm not sure if you were aware, but there is a standard API for
> > > configuring RSS in network drivers, part of ethtool_ops.  I think
> > > iwlwifi should implement that rather than a driver-specific
> > > debugfs
> > > interface.
> > > 
> > You are right, this is why Sara made this commit:
> > 
> > commit 854d773e4ab586924af4ca5d851730849903
> > Author: Sara Sharon <sara.sha...@intel.com>
> > Date:   Tue Mar 22 15:55:58 2016 +0200
> > 
> > iwlwifi: mvm: improve RSS configuration
> > 
> > Improve current RSS configuration:
> >  * Use netdev_rss_key instead of keeping a local copy.
> >  * Configure also UDP hashing to have UDP traffic spread across
> > queues.
> >  Do not direct RSS traffic to our fallback queue.
> >
> > Signed-off-by: Sara Sharon <sara.sha...@intel.com>
> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
> 
> That doesn't really address what I said.  Yes, it's using the common
> RSS key, but it's not implementing the ethtool operations to get and
> set the indirection table and the types of flow hashing that are
> enabled.
> 

Hm.. I think that setting the indirection table is a problem in our
case because the PN check is done in the driver. The PN check is the
way WiFi addresses the replay attack, and since the PN check relies on
per-cpu variables, we cannot *safely* allow users to modify the
indirection table while traffic is flowing.

> Ben.
> 

Re: RSS configuration in iwlwifi

[Grumbach, Emmanuel]

Hi Ben,


Thanks for looking at our code.


On Wed, 2016-04-20 at 16:08 +0100, Ben Hutchings wrote:
> I'm not sure if you were aware, but there is a standard API for
> configuring RSS in network drivers, part of ethtool_ops.  I think
> iwlwifi should implement that rather than a driver-specific debugfs
> interface.
> 

You are right, this is why Sara made this commit:

commit 854d773e4ab586924af4ca5d851730849903
Author: Sara Sharon 
Date:   Tue Mar 22 15:55:58 2016 +0200

iwlwifi: mvm: improve RSS configuration

Improve current RSS configuration:
 * Use netdev_rss_key instead of keeping a local copy.
 * Configure also UDP hashing to have UDP traffic spread across queues.
 * Do not direct RSS traffic to our fallback queue.

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 


> Ben.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
> ���j:+v���w�j�mzZ+�ݢj"��!�i

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

[Grumbach, Emmanuel]

On Sat, 2016-04-16 at 17:43 +0200, Borislav Petkov wrote:
> On Fri, Apr 15, 2016 at 04:16:02AM +0000, Grumbach, Emmanuel wrote:
> > [1] 
> > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
> > fi.git/
> 
> It is very strange to pull from this repo, git fetch is doing
> something
> for a while now without any forward progress.

This is not surprising at all. This tree is not a kernel tree, but
rather a backport tree. It doesn't contain anything besides the Wifi
stack and the backport code. It has no common commit with the Linux
kernel. I understand that you fetched this tree from a kernel tree but
that's not a good idea. Git will try to find a common ancestor but that
will fail... after a huge number of tentatives. You'd better clone it.

> In any case, 4.5 is bad too, testing 4.4 now.

Here you go.

> I 'm travelling currently
> so the whole bisection deal will take a whole but I'll get to it
> eventually.

I'll be glad to see something coming out of this, but I can't say I am
very optimistic.

> 
> Thanks for taking a look.
> 

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

[Grumbach, Emmanuel]

On Fri, 2016-04-15 at 02:07 +, Borislav Petkov wrote:
> Hi,
> 
> so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip.
> After that, wifi is dead in the water. Anyone have a clue?
> 
> And 4.5 seems fine, I'm typing from it as we speak.
> ...




> [  661.142657] [ cut here ]
> [  661.142816] WARNING: CPU: 1 PID: 2485 at
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752
> iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
> [  661.143231] Timeout waiting for hardware access (CSR_GP_CNTRL
> 0x)
> 

This means that we have an electrical issue that prevents us from
accessing the device over the PCI bus. BAR has been garbaged or alike.
Every time I tried to debug that from the driver side it has ...
failed. Because the "good" in the end did exhibit the problem. So,
unless you are ready to embark for a bisection journey (and hope that
this time when you type 'git bisect good' it is really 'good'), I can't
do much.
What I can suggest is to install our latest backport based tree on 4.5.
This will allow you to have an easily bisectable tree. But it might
very well be that 4.5 + latest driver (equivalent to 4.6 as far as
iwlwifi is concerned) will be fine.
The backport tree is here [1]. Unfortunately, that's the only thing I
can suggest for now.

[1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
fi.git/
> -- 
> Regards/Gruss,
> Boris.
> 
> ECO tip #101: Trim your mails when you reply. Srsly.

Re: pull request: iwlwifi 2016-04-12

[Grumbach, Emmanuel]

On Tue, 2016-04-12 at 11:14 +0300, Emmanuel Grumbach wrote:
> Hi Kalle,
> 
> I have here a pull request for 4.6. There is patch in this pull
> request
> that has been sent to -next already but should really have been
> included in the current cycle. Sorry for the mess.
> 
> The commit appears in -next as:
> 
> commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
> Author: Ayala Beker 
> Date:   Wed Feb 3 15:36:52 2016 +0200
> 
> iwlwifi: mvm: update GSCAN capabilities
> 
> Gscan capabilities were updated with new capabilities supported
> by the device. Update GSCAN capabilities TLV.
> 
> I modified the commit message to better emphasis the need to have it
> in
> the current release. You'll see it in this pull request as:
> 
> commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
> Author: Ayala Beker 
> Date:   Wed Feb 3 15:36:52 2016 +0200
> 
> iwlwifi: mvm: avoid to WARN about gscan capabilities
> 
> Gscan capabilities were updated with new capabilities supported
> by the device. Update GSCAN capabilities TLV and avoid to WARN
> if the firmware does not have the new capabilities.
> 
> Besides this, all is fairly normal.
> Please pull, thanks!
> 
> 
> The following changes since commit
> 7fdf9663261cc77a516396fec82cee8a8ea07e76:
> 
>   iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fix
> es.git tags/iwlwifi-for-kalle-2016-04-12
> 
> for you to fetch changes up to
> 2d25fb8b3a138706b63bd26ad72a95c58029954a:
> 
>   iwlwifi: mvm: fix accessing Null pointer during fw dump collection
> (2016-04-12 10:03:17 +0300)
> 

Sara found an embarrassing last minute issue.
New tag is iwlwifi-for-kalle-2016-04-12_2.
 
Here is the diff:
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
index cf48122..b5c57ee 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
@@ -93,7 +93,7 @@
 #define IWL8260_SMEM_OFFSET0x40
 #define IWL8260_SMEM_LEN   0x68000
 
-#define IWL8000_FW_PRE "iwlwifi-8000C"
+#define IWL8000_FW_PRE "iwlwifi-8000C-"
 #define IWL8000_MODULE_FIRMWARE(api) \
IWL8000_FW_PRE "-" __stringify(api) ".ucode"
 

> 
> * add new device IDs for 8265
> * fix a NULL pointer dereference when paging firmware asserts
> * remove a WARNING on gscan capabilities
> * fix MODULE_FIRMWARE for 8260
> 
> 
> Ayala Beker (1):
>   iwlwifi: mvm: avoid to WARN about gscan capabilities
> 
> Matti Gottlieb (1):
>   iwlwifi: mvm: fix accessing Null pointer during fw dump
> collection
> 
> Oren Givon (1):
>   iwlwifi: add device IDs for the 8265 device
> 
> Sara Sharon (1):
>   iwlwifi: 8000: fix MODULE_FIRMWARE input
> 
>  drivers/net/wireless/intel/iwlwifi/iwl-8000.c   |  2 +-
>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c| 26 ++-
> ---
>  drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c |  6 --
>  drivers/net/wireless/intel/iwlwifi/mvm/fw.c |  2 ++
>  drivers/net/wireless/intel/iwlwifi/pcie/drv.c   | 10 ++
>  5 files changed, 27 insertions(+), 19 deletions(-)

pull request: iwlwifi 2016-04-12

[Grumbach, Emmanuel]

Hi Kalle,

I have here a pull request for 4.6. There is patch in this pull request
that has been sent to -next already but should really have been
included in the current cycle. Sorry for the mess.

The commit appears in -next as:

commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
Author: Ayala Beker 
Date:   Wed Feb 3 15:36:52 2016 +0200

iwlwifi: mvm: update GSCAN capabilities

Gscan capabilities were updated with new capabilities supported
by the device. Update GSCAN capabilities TLV.

I modified the commit message to better emphasis the need to have it in
the current release. You'll see it in this pull request as:

commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
Author: Ayala Beker 
Date:   Wed Feb 3 15:36:52 2016 +0200

iwlwifi: mvm: avoid to WARN about gscan capabilities

Gscan capabilities were updated with new capabilities supported
by the device. Update GSCAN capabilities TLV and avoid to WARN
if the firmware does not have the new capabilities.

Besides this, all is fairly normal.
Please pull, thanks!


The following changes since commit 7fdf9663261cc77a516396fec82cee8a8ea07e76:

  iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-04-12

for you to fetch changes up to 2d25fb8b3a138706b63bd26ad72a95c58029954a:

  iwlwifi: mvm: fix accessing Null pointer during fw dump collection 
(2016-04-12 10:03:17 +0300)


* add new device IDs for 8265
* fix a NULL pointer dereference when paging firmware asserts
* remove a WARNING on gscan capabilities
* fix MODULE_FIRMWARE for 8260


Ayala Beker (1):
  iwlwifi: mvm: avoid to WARN about gscan capabilities

Matti Gottlieb (1):
  iwlwifi: mvm: fix accessing Null pointer during fw dump collection

Oren Givon (1):
  iwlwifi: add device IDs for the 8265 device

Sara Sharon (1):
  iwlwifi: 8000: fix MODULE_FIRMWARE input

 drivers/net/wireless/intel/iwlwifi/iwl-8000.c   |  2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c| 26 ++
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c |  6 --
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c |  2 ++
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c   | 10 ++
 5 files changed, 27 insertions(+), 19 deletions(-)

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

> On Sun, Apr 10, 2016 at 1:28 PM, Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com> wrote:
> >> > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
> >> Is the iwlwifi driver capable of capturing data frames when the
> >> channel bonding is set to 80Mhz?
> >
> > dev  set freq  [20|40|80|80+80|160] [ > freq 1>] []
> >
> > You can take center_freq1 from the output of iw dev on a device that is
> associated to the same AP.
> 
> Thanks a lot, Emmanuel. My iw binary that came default with my Ubuntu
> distribution was very old (3.4) and it didn't have support for channel bonding
> larger than 40Mhz.
> I compiled the latest iw version from sources then I took the
> center_freq1 from the beacon advertised by the AP. That's because the iw
> dev on a device associated to the same AP gave me the control frequency.
> After that, I was able to capture the data frames.
> 
> One more question that I promise to be the last one:
> - I am trying to capture the Wi-Fi Direct traffic between two
> smartphones: iw shows me that the p2p interface from one of the
> smartphones uses 2.4Ghz, channel 1 so I set the monitor interface on 2.4,
> channel 1. The problem is that, again, I can't see the data frames. Instead, I
> can see the Association/Authentication Request, RTS/CTS, Block ACK (I
> attached the Wireshark capture at [1]).
> 

   ...1 = HT LDPC coding capability: Transmitter supports receiving 
LDPC coded packets

This means that both sides use a coding algo that 7260 doesn't understand. 7260 
talks Viterbi.
The only way to go here is to get a 7265 module (or later) instead.

> Analyzing the capture, I noticed that the HT capabilities advertised in the
> beacon frames indicates 802.11n D1.10. Does this trigger any indication for
> you on how to setup the monitor interface?
> 
> [1]
> https://drive.google.com/file/d/0B5SBH08PU_ChNllaVHRienBSVlE/view?usp
> =sharing
> 
> Regards,
> Doru

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

> On Tue, Apr 5, 2016 at 4:34 PM, Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com> wrote:
> > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
> >> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
> >> <emmanuel.grumb...@intel.com> wrote:
> >> > >
> >> > > Hello,
> >> > >
> >> > > I am trying to capture packets that are exchanged between an AP
> >> > > and a smartphone on the 5Ghz frequency. For generating traffic, I
> >> > > upload UDP traffic from a laptop PC towards the smartphone using
> >> > > iperf.
> >> > >
> >> > > The problem is that I can see _only_ the control frames like
> >> > > RTS/CTS, Block ACK, while the data packets are not captured. I
> >> > > uploaded the Wireshark capture files at [1] (located inside the
> >> > > folders whose name starts with 5Ghz).
> >> >
> >> > Most likely the packets on A band have a VHT preamble and your SKU
> >> > is 11N only.
> >>
> >> My card, Intel 7260 [1]  supports 802.11 ac. So it should also
> >> support VHT, right? Is there any interface in user-space for checking
> >> after VHT?
> >
> > 7260 has several flavors. The one you have doesn't support VHT:
> >> iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 7260
> >
> > Dual Band means you have support for 5.2GHz, but Wireless N, means no
> > VHT.
> 
> One of my colleagues had an Intel 7260 AC card so I repeated the
> experiments:
> - if I set the channel width to 20Mhz from the AP and the monitor interface
> using the command iw wlan0 set freq 5240 HT20+ I can see data frames and
> the Block ACKs for these frames;
> - if I set the channel width to 40Mhz from the AP and the monitor interface
> using the command iw wlan0 set freq 5240 HT40- I can see data frames and
> the Block ACKs for these frames;
> - If I set the channel width to 80Mhz from the AP I don't how to set up the
> monitor interface. I tried with iw wlan0 set freq 5240 HT40+ but it tells me
> that the argument is invalid.
> 
> Is the iwlwifi driver capable of capturing data frames when the channel
> bonding is set to 80Mhz?

dev  set freq  [20|40|80|80+80|160] [] 
[]

You can take center_freq1 from the output of iw dev on a device that is 
associated to the same AP.

RE: [PATCHv3 RESEND 01/11] cfg80211: add start / stop NAN commands

[Grumbach, Emmanuel]

> 
> On Tue, Mar 29, 2016 at 12:34:59PM +0300, Emmanuel Grumbach wrote:
> > This allows user space to start/stop NAN interface.
> > A NAN interface is like P2P device in a few aspects: it doesn't have a
> > netdev associated to it.
> > Add the new interface type and prevent operations that can't be
> > executed on NAN interface like scan.
> 
> What is the need for this new NAN interface from the view point of
> supporting NAN discovery?

I guess you can ask the same question for P2P device. They are both
very similar. No traffic, discovery only. So all the reasons to have a P2P
device interface apply here as well.

> Are you planning to use the same iface type
> eventually for supporting data traffic over NAN interface as well?

We don't really know yet. The plan is to have another interface type.
Probably one instance per Nan Data Path or the interface type.

> 
> > + * @start_nan: Start the NAN interface.
> > + * @stop_nan: Stop the NAN interface.
> 
> >  struct cfg80211_ops {
> > +   int (*start_nan)(struct wiphy *wiphy, struct wireless_dev
> *wdev,
> > +struct cfg80211_nan_conf *conf);
> > +   void(*stop_nan)(struct wiphy *wiphy, struct wireless_dev
> *wdev);
> 
> And similarly from 4/11:
> + int (*nan_change_conf)(struct wiphy *wiphy,
> +struct wireless_dev *wdev,
> +struct cfg80211_nan_conf *conf,
> +u32 changes);
> 
> There is no matching cookie (such as transaction id) in these requests to the
> driver, are you expecting synchronous response from the driver for these
> requests? Or would some kind of event after the operation has been
> completed be possible?

Yes - these are expected to be synchronous since they don't involve network
transactions. Does your solution require this operation to be asynchronous? I
find a bit weird to make a local operation asynchronous though.

> 
> --
> Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 RESEND 01/11] cfg80211: add start / stop NAN commands

[Grumbach, Emmanuel]

 
> On Tue, Mar 29, 2016 at 12:34:59PM +0300, Emmanuel Grumbach wrote:
> > Define several attributes that may be configured by user space when
> > starting NAN functionality (master preference and dual band operation)
> 
> > diff --git a/include/uapi/linux/nl80211.h
> > b/include/uapi/linux/nl80211.h @@ -826,6 +826,16 @@
> > + * @NL80211_CMD_START_NAN: Start NAN operation, identified by its
> > + * %NL80211_ATTR_WDEV interface. This interface must have been
> previously
> > + * created with %NL80211_CMD_NEW_INTERFACE. After it has been
> started, the
> > + * NAN interface will create or join a cluster. This command must have a
> > + * valid %NL80211_ATTR_NAN_MASTER_PREF attribute and optional
> > + * %NL80211_ATTR_NAN_DUAL attributes.
> 
> 
> > diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> 
> > +static int nl80211_start_nan(struct sk_buff *skb, struct genl_info
> > +*info)
> 
> > +   if (!info->attrs[NL80211_ATTR_NAN_MASTER_PREF])
> > +   return -EINVAL;
> 
> Why NL80211_ATTR_NAN_MASTER_PREF is mandatory? The spec suggests
> to assume master preference value of 128 if not provided. Please see quoted
> text from NAN 1.0 specification:
> "A NAN Device which out-of-the-box will have a Master Preference greater
> than or equal to 128 with the intention of being a NAN Master Device"
> 

Yes, but you can still have this default being defined in user space. While I 
agree that
the kernel could accept the command even if that attribute is not present, this 
code,
by itself, doesn't mean that it does not comply with the spec. It just defines 
a different
partition of the roles.

I read the spec again, and I fail to see how you deduce from this that 128 
should be the default.
Different devices will have different master preferences. Infrastructure 
devices will have >=128
which hints that they want to be master (consume more power) most probably 
because they
are powered. Other devices that would prefer to avoid being master should set 
their out of the
box master preference to <128.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com> wrote:
> > > 
> > > Hello,
> > > 
> > > I am trying to capture packets that are exchanged between an AP
> > > and a
> > > smartphone on the 5Ghz frequency. For generating traffic, I
> > > upload UDP
> > > traffic from a laptop PC towards the smartphone using iperf.
> > > 
> > > The problem is that I can see _only_ the control frames like
> > > RTS/CTS, Block
> > > ACK, while the data packets are not captured. I uploaded the
> > > Wireshark
> > > capture files at [1] (located inside the folders whose name
> > > starts with 5Ghz).
> > 
> > Most likely the packets on A band have a VHT preamble and your SKU
> > is 11N only.
> 
> My card, Intel 7260 [1]  supports 802.11 ac. So it should also
> support
> VHT, right? Is there any interface in user-space for checking after
> VHT?

7260 has several flavors. The one you have doesn't support VHT:
> iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 7260

Dual Band means you have support for 5.2GHz, but Wireless N, means no
VHT.

> 
> However, I noticed a "failure" message in dmesg:
> [4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
> [4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
> [4.030760] iwlwifi :04:00.0: Direct firmware load for
> iwlwifi-7260-10.ucode failed with error -2
> [4.035509] iwlwifi :04:00.0: loaded firmware version
> 25.228.9.0 op_mode iwlmvm
> [4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless N 7260, REV=0x144
> [4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> 
> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
> assumption is that the card can't enter into the 802.11 ac mode, it
> just stays into 802.11n.
> 
> doru@doru-N551JK:~$ iwconfig wlan0
> wlan0 IEEE 802.11abgn  ESSID:"5_mptcp"
>   Mode:Managed  Frequency:5.24 GHz  Access Point:
> C4:6E:1F:4B:10:A2
>   Bit Rate=150 Mb/s   Tx-Power=22 dBm
>   Retry short limit:7   RTS thr:off   Fragment thr:off
>   Power Management:on
>   Link Quality=70/70  Signal level=-36 dBm
>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>   Tx excessive retries:0  Invalid misc:22   Missed beacon:0
> 
> 
> [1] http://www.intel.com/content/www/us/en/wireless-products/dual-ban
> d-wireless-ac-7260-bluetooth-brief.html
> 
> > Another option is that the traffic uses LDPC encoding and this
> > device doesn't support it.
> > 
> > 
> > > 
> > > If I use the 2.4 frequency, all the frames are captured. I also
> > > uploaded the
> > > Wireshark packet traces for 2.4Ghz at [1] (located inside the
> > > folders whose
> > > name starts with 2.4 Ghz).
> > > 
> > > Is this a known bug or am I doing something wrong?
> > > 
> > > Additional details:
> > > Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band
> > > Wireless N 7260,
> > > REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware
> > > version
> > > 25.228.9.0 op_mode iwlmvm
> > > Traffic encryption: WPA & WPA2 Personal
> > > Setting up the card in wireless mode:
> > > ip link set dev wlan0 down
> > > iw wlan0 set type monitor
> > > ip link set dev wlan0 up
> > > iw wlan0 set freq 5240
> > > 
> > > [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
> > > 
> > > Thank you, 
> > > DoruN�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
> > > ���j:+v���w�j�mzZ+�ݢj"��!�i

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

> 
> Hello,
> 
> I am trying to capture packets that are exchanged between an AP and a
> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
> traffic from a laptop PC towards the smartphone using iperf.
> 
> The problem is that I can see _only_ the control frames like RTS/CTS, Block
> ACK, while the data packets are not captured. I uploaded the Wireshark
> capture files at [1] (located inside the folders whose name starts with 5Ghz).

Most likely the packets on A band have a VHT preamble and your SKU is 11N only.
Another option is that the traffic uses LDPC encoding and this device doesn't 
support it.


> 
> If I use the 2.4 frequency, all the frames are captured. I also uploaded the
> Wireshark packet traces for 2.4Ghz at [1] (located inside the folders whose
> name starts with 2.4 Ghz).
> 
> Is this a known bug or am I doing something wrong?
> 
> Additional details:
> Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 
> 7260,
> REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware version
> 25.228.9.0 op_mode iwlmvm
> Traffic encryption: WPA & WPA2 Personal
> Setting up the card in wireless mode:
> ip link set dev wlan0 down
> iw wlan0 set type monitor
> ip link set dev wlan0 up
> iw wlan0 set freq 5240
> 
> [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
> 
> Thank you, Doru

pull request: iwlwifi-next 2016-03-30

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.7. Lots of work here and more to come when
dependencies on mac80211 will be resolved.
Let me know if you have issues!

Thanks.

The following changes since commit 1200b6809dfd9d73bc4c7db76d288c35fa4b2ebe:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next 
(2016-03-19 10:05:34 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2016-03-30

for you to fetch changes up to 46167a8fd4248533ad15867e6988ff20e76de641:

  iwlwifi: pcie: remove duplicate assignment of variable isr_stats (2016-03-30 
16:24:52 +0300)


* Support for Link Quality measurement (Aviya)
* Improvements in thermal (Chaya Rachel)
* Various cleanups (many people)
* Improvements in firmware error dump (Golan)
* More work 9000 devices and MSIx (Haim)
* Continuation of the Dynamic Queue Allocation work (Liad)
* Scan timeout to cope with buggy firmware (Luca)
* D0i3 improvements (Luca)
* Make the paging less memory hungry (Matti)
* 9000 new Rx path (Sara)


Aviya Erenfeld (2):
  iwlwifi: mvm: add LQM vendor command and notification
  iwlwifi: add a debugfs hook for LQM

Ayala Beker (1):
  iwlwifi: mvm: update GSCAN capabilities

Chaya Rachel Ivgi (2):
  iwlwifi: mvm: handle async temperature notification with unlocked mutex
  iwlwifi: mvm: remove uneeded D0I3 checking

Colin Ian King (1):
  iwlwifi: pcie: remove duplicate assignment of variable isr_stats

David Spinadel (1):
  iwlwifi: mvm: set aux STA ID in scan config

Emmanuel Grumbach (6):
  iwlwifi: pcie: print error value as signed int
  iwlwifi: mvm: modify the max SP to infinite
  iwlwifi: add missing mutex_destroy statements
  iwlwifi: make uapsd_disable module param a bitmap
  iwlwifi: remove IWLWIFI_UAPSD Kconfig
  iwlwifi: remove IWL_*_UCODE_API_OK

Eva Rachel Retuya (1):
  iwlwifi: dvm: use alloc_ordered_workqueue()

Golan Ben-Ami (2):
  iwlwifi: mvm: support dumping UMAC internal txfifos
  iwlwifi: store fw memory segments length and addresses in run-time

Haim Dreyfuss (2):
  iwlwifi: 9000: update device id and FW serial number
  iwlwifi: pcie: Fix index iteration on free_irq in MSIX mode

Johannes Berg (1):
  iwlwifi: mvm: remove is_data_qos variable in TX

Liad Kaufman (7):
  iwlwifi: mvm: support bss dynamic alloc/dealloc of queues
  iwlwifi: trans: fix iwl_trans_txq_scd_cfg.sta_id sign
  iwlwifi: mvm: use bss client queue for bss station
  iwlwifi: mvm: set sta_id in SCD_QUEUE_CONFIG cmd
  iwlwifi: mvm: allocate dedicated queue for cab in dqa mode
  iwlwifi: mvm: move cmd queue to be #0 in dqa mode
  iwlwifi: mvm: fix inconsistent lock in dqa mode

Luca Coelho (3):
  iwlwifi: pcie: refcounting is not necessary anymore
  iwlwifi: mvm: add a scan timeout for regular scans
  iwlwifi: mvm: allow setting the thermal state in D0i3

Matti Gottlieb (2):
  iwlwifi: mvm: Decrease size of the paging download buffer
  iwlwifi: mvm: make sure FW contains the right amount of paging sections

Oren Givon (1):
  iwlwifi: edit the 9000 series PCI IDs

Sara Sharon (11):
  iwlwifi: pcie: clear trans reference on queue stop
  iwlwifi: pcie: fix global table size
  iwlwifi: pcie: enable interrupts explicitly on resume
  iwlwifi: pcie: do not pad QoS AMSDU
  iwlwifi: mvm: add support for new TX CMD API
  iwlwifi: pcie: write to legacy register also in MQ
  iwlwifi: remove support for fw older than -16.ucode
  iwlwifi: mvm: report checksum is done also for IPv6 packets
  iwlwifi: pcie: request one more interrupt vector
  iwlwifi: mvm: improve RSS configuration
  iwlwifi: mvm: enable TCP/UDP checksum support for 9000 family

 drivers/net/wireless/intel/iwlwifi/Kconfig |   10 --
 drivers/net/wireless/intel/iwlwifi/dvm/main.c  |2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-1000.c  |   10 +-
 drivers/net/wireless/intel/iwlwifi/iwl-2000.c  |   18 +-
 drivers/net/wireless/intel/iwlwifi/iwl-5000.c  |   11 +-
 drivers/net/wireless/intel/iwlwifi/iwl-6000.c  |   20 +--
 drivers/net/wireless/intel/iwlwifi/iwl-7000.c  |   26 +--
 drivers/net/wireless/intel/iwlwifi/iwl-8000.c  |   13 +-
 drivers/net/wireless/intel/iwlwifi/iwl-9000.c  |   17 +-
 drivers/net/wireless/intel/iwlwifi/iwl-config.h|7 +-
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c   |  100 ++-
 drivers/net/wireless/intel/iwlwifi/iwl-fw-error-dump.h |1 +
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h   |   41 -
 drivers/net/wireless/intel/iwlwifi/iwl-fw.h|2 +
 drivers/net/wireless/intel/iwlwifi/iwl-modparams.h |   10 +-
 

pull request: iwlwifi 2016-03-30

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.6 that includes 2 trivial fixes.
Please let me know if you have issues.
Thanks!

The following changes since commit 1200b6809dfd9d73bc4c7db76d288c35fa4b2ebe:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next 
(2016-03-19 10:05:34 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-03-30

for you to fetch changes up to 7fdf9663261cc77a516396fec82cee8a8ea07e76:

  iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)


* lower the debug level of a benign print
* fix a memory leak


Emmanuel Grumbach (1):
  iwlwifi: pcie: lower the debug level for RSA semaphore access

Matti Gottlieb (1):
  iwlwifi: mvm: fix memory leak in paging

 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 ++
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c  | 2 --
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c   | 4 ++--
 3 files changed, 4 insertions(+), 4 
deletions(-)N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats

[Grumbach, Emmanuel]

On Mon, 2016-03-28 at 12:33 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> isr_stats is written twice with the same value, remove one of the
> redundant assignments to isr_stats.
> 
> Signed-off-by: Colin Ian King 
> ---


Applied - thanks.

>  drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index 4be3c35..253e4f0 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq,
> void *dev_id)
>   struct msix_entry *entry = dev_id;
>   struct iwl_trans_pcie *trans_pcie =
> iwl_pcie_get_trans_pcie(entry);
>   struct iwl_trans *trans = trans_pcie->trans;
> - struct isr_statistics *isr_stats = isr_stats = _pcie
> ->isr_stats;
> + struct isr_statistics *isr_stats = _pcie->isr_stats;
>   u32 inta_fh, inta_hw;
>  
>   lock_map_acquire(>sync_cmd_lockdep_map);

Re: [PATCH v2] cfg80211: add start / stop NAN commands

[Grumbach, Emmanuel]

On Thu, 2016-03-24 at 19:30 +0100, Arend Van Spriel wrote:
> 
> On 24-3-2016 16:12, Emmanuel Grumbach wrote:
> > This allows user space to start/stop NAN interface.
> > A NAN interface is like P2P device in a few aspects: it
> > doesn't have a netdev associated to it.
> > Add the new interface type and prevent operations that
> > can't be executed on NAN interface like scan.
> > Define several attributes that may be configured by user space
> > when starting NAN functionality (master preference and dual
> > band operation)
> > 
> > Signed-off-by: Andrei Otcheretianski <
> > andrei.otcheretian...@intel.com>
> > Signed-off-by: Emmanuel Grumbach 
> > ---
> > v2: allow master preference 1 and 255 as required by the
> > certification
> > ---
> >  include/net/cfg80211.h   | 21 +-
> >  include/uapi/linux/nl80211.h | 44 
> >  net/mac80211/cfg.c   |  2 +
> >  net/mac80211/chan.c  |  3 ++
> >  net/mac80211/iface.c |  4 ++
> >  net/mac80211/offchannel.c|  1 +
> >  net/mac80211/rx.c|  3 ++
> >  net/mac80211/util.c  |  1 +
> >  net/wireless/chan.c  |  2 +
> >  net/wireless/core.c  | 34 
> >  net/wireless/core.h  |  3 ++
> >  net/wireless/mlme.c  |  1 +
> >  net/wireless/nl80211.c   | 96
> > ++--
> >  net/wireless/rdev-ops.h  | 20 +
> >  net/wireless/trace.h | 27 +
> >  net/wireless/util.c  |  6 ++-
> >  16 files changed, 261 insertions(+), 7 deletions(-)
> > 
> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> > index 9e1b24c..cb5ab88 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -2228,6 +2228,19 @@ struct cfg80211_qos_map {
> >  };
> >  
> >  /**
> > + * struct cfg80211_nan_conf - nan configuration
> > + *
> > + * This struct defines nan configuration parameters
> > + *
> > + * @master_pref: master preference (2 -254)
> 
> This seems to contradict the change log above...

Thanks for catching this.

> 
> > + * @dual: dual band operation mode
> > + */
> > +struct cfg80211_nan_conf {
> > +   u8 master_pref;
> > +   enum nl80211_nan_dual_band_conf dual;
> > +};
> > +
> > +/**
> >   * struct cfg80211_ops - backend description for wireless
> > configuration
> >   *
> >   * This struct is registered by fullmac card drivers and/or
> > wireless stacks
> > @@ -2500,6 +2513,8 @@ struct cfg80211_qos_map {
> >   * and returning to the base channel for communication with
> > the AP.
> >   * @tdls_cancel_channel_switch: Stop channel-switching with a TDLS
> > peer. Both
> >   * peers must be on the base channel when the call
> > completes.
> > + * @start_nan: Start the NAN interface.
> > + * @stop_nan: Stop the NAN interface.
> >   */
> >  struct cfg80211_ops {
> > int (*suspend)(struct wiphy *wiphy, struct
> > cfg80211_wowlan *wow);
> > @@ -2765,6 +2780,9 @@ struct cfg80211_ops {
> > void(*tdls_cancel_channel_switch)(struct wiphy
> > *wiphy,
> >   struct net_device
> > *dev,
> >   const u8 *addr);
> > +   int (*start_nan)(struct wiphy *wiphy, struct
> > wireless_dev *wdev,
> > +struct cfg80211_nan_conf *conf);
> > +   void(*stop_nan)(struct wiphy *wiphy, struct
> > wireless_dev *wdev);
> >  };
> >  
> >  /*
> > @@ -3486,6 +3504,7 @@ struct cfg80211_cached_keys;
> >   * beacons, 0 when not valid
> >   * @address: The address for this device, valid only if @netdev is
> > %NULL
> >   * @p2p_started: true if this is a P2P Device that has been
> > started
> > + * @nan_started: true if this is a NAN interface that has been
> > started
> >   * @cac_started: true if DFS channel availability check has been
> > started
> >   * @cac_start_time: timestamp (jiffies) when the dfs state was
> > entered.
> >   * @cac_time_ms: CAC time in ms
> > @@ -3517,7 +3536,7 @@ struct wireless_dev {
> >  
> > struct mutex mtx;
> >  
> > -   bool use_4addr, p2p_started;
> > +   bool use_4addr, p2p_started, nan_started;
> >  
> > u8 address[ETH_ALEN] __aligned(sizeof(u16));
> >  
> > diff --git a/include/uapi/linux/nl80211.h
> > b/include/uapi/linux/nl80211.h
> > index 5a30a75..e5a7cfb 100644
> > --- a/include/uapi/linux/nl80211.h
> > +++ b/include/uapi/linux/nl80211.h
> > @@ -824,6 +824,16 @@
> >   * not running. The driver indicates the status of the scan
> > through
> >   * cfg80211_scan_done().
> >   *
> > + * @NL80211_CMD_START_NAN: Start NAN operation, identified by its
> > + * %NL80211_ATTR_WDEV interface. This interface must have
> > been previously
> > + * created with %NL80211_CMD_NEW_INTERFACE. After it has
> > been started, the
> > + * NAN interface will create or join a cluster. This
> > command must have a
> > + * valid %NL80211_ATTR_NAN_MASTER_PREF attribute and
> > optional
> > + * %NL80211_ATTR_NAN_DUAL attributes.
> > + * 

Re: [PATCH v3] iwlwifi: dvm: use alloc_ordered_workqueue()

[Grumbach, Emmanuel]

On 03/19/2016 07:15 AM, Eva Rachel Retuya wrote:
> Use alloc_ordered_workqueue() to allocate the workqueue instead of
> create_singlethread_workqueue() since the latter is deprecated and is 
> scheduled
> for removal.
> 
> There are work items doing related operations that shouldn't be swapped when
> queued in a certain order hence preserve the strict execution ordering of a
> single threaded (ST) workqueue by switching to alloc_ordered_workqueue().
> 
> WQ_MEM_RECLAIM flag is not needed since the worker is not depended
> during memory reclaim.
> 
> Signed-off-by: Eva Rachel Retuya 
> Acked-by: Tejun Heo 
> ---


Applied - thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi incomplete initialization in Linux 4.5?

[Grumbach, Emmanuel]

On 03/16/2016 11:44 PM, Linus Torvalds wrote:
> On Wed, Mar 16, 2016 at 2:23 PM, Linus Torvalds
>  wrote:
>>
>>> Do you use 20Mhz or 40MHz?
>>
>> HT20 on 2.4GHz, HT40 on 5GHz.
>>
>> At least that's the wireless AP setup.
>>
>>> Basically, I'd like to see the output of iw dev
>>
>> I'll have to walk over and check. I don't have my machines set up so
>> you can get into them over the network..
> 
> Hmm. "iw dev" seems to say that device is using the 2.4Ghz side, at
> least in the working configuration.
> 
>   phy#0
> Unnamed/non-netdev interface
> wdev 0x2
> addr a4:34:d9:0e:20:d7
> type P2P-device
> Interface wlp1s0
> ifindex 3
> wdev 0x1
> addr a4:34:d9:0e:20:d6
> type managed
> channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
> 
> I have no idea why it wouldn't connect to the 5GHz network, but it
> might just be far enough away (a couple of walls, not so much
> distance) that it is borderline. Both networks have the same essid and
> password, maybe I should add a separate 5GHz network to make it easier
> to say "connect to that one" for testing, in case the trouble happens
> with the 5GHz side only.
> 

You can check the RSSI of both networks:

sudo iw wlp1s0 scan

>  Linus
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()

[Grumbach, Emmanuel]

> Hello,
> 
> On Thu, Mar 17, 2016 at 01:43:22PM +0100, Johannes Berg wrote:
> > On Thu, 2016-03-17 at 20:37 +0800, Eva Rachel Retuya wrote:
> > > Use alloc_workqueue() to allocate the workqueue instead of
> > > create_singlethread_workqueue() since the latter is deprecated and
> > > is scheduled for removal.
> >
> > Scheduled where?
> 
> They've been deprecated for years now.  I should note that in the header.
> 
> > >  static void iwl_setup_deferred_work(struct iwl_priv *priv)
> > >  {
> > > - priv->workqueue = create_singlethread_workqueue(DRV_NAME);
> > > + priv->workqueue = alloc_workqueue(DRV_NAME, WQ_HIGHPRI |
> > > WQ_UNBOUND |
> > > +   WQ_MEM_RECLAIM, 1);
> >
> > Seems like you should use alloc_ordered_workqueue() though? That also
> > gets you UNBOUND immediately, and the "1".
> 
> Right, this one should have been alloc_ordered_workqueue().
> 
> > I'm not really sure HIGHPRI is needed either.
> 
> So, no WQ_MEM_RECLAIM either then, I suppose?  What are the latency
> requirements here - what happens if a thermal management work gets
> delayed?
> 

This worker is not supposed to free memory, so no WQ_MEM_RECLAIM needed. The 
latency is not critical.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi incomplete initialization in Linux 4.5?

[Grumbach, Emmanuel]

On 03/16/2016 11:23 PM, Linus Torvalds wrote:
> On Wed, Mar 16, 2016 at 2:13 PM, Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com> wrote:
>>
>> This ... typically means that the firmware got stuck while sending
>> packets. Can you tell me on what band your router operates? 2.4GHz or
>> 5.2GHz?
> 
> Both.
> 
>> Do you use 20Mhz or 40MHz?
> 
> HT20 on 2.4GHz, HT40 on 5GHz.

That's fair. Using 40MHz on 2.4GHz can be the cause of issues.

> 
> At least that's the wireless AP setup.
> 
>> Basically, I'd like to see the output of iw dev
> 
> I'll have to walk over and check. I don't have my machines set up so
> you can get into them over the network..

Not urgent. I am GMT+2, so it's kinda late here anyway :)

> 
>> Hmm, this is strange since 4.4 and 4.5 will both load -16.ucode which
>> you seemed to be running when the have the Queue hang message.
> 
> Correct. Both cases used the 16 ucode, since that's what F22 comes
> with. I upgrade the kernel, but intentionally don't touch anything
> else in the system.

Ok - we have the same device (8260), so I'll prepare a debug version of
the -16.ucode firmware and test it tomorrow morning so that *if* you
want to debug, you'll have the special firmware ready in your inbox.

> 
>Linus
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi incomplete initialization in Linux 4.5?

[Grumbach, Emmanuel]

Hi Linus,

On 03/16/2016 10:48 PM, Linus Torvalds wrote:
> So I upgraded the firmware on my Intel NUC (NUC6i3SYK), and that made
> the wireless no longer work with a 4.5 kernel. I could get the
> occasional packets through, but not many, and ti would hang for ten
> seconds at a time, and then output errors like
> 
>   iwlwifi :01:00.0: Queue 2 stuck for 1 ms.
>   iwlwifi :01:00.0: Current SW read_ptr 60 write_ptr 93
>   ..
> 

This ... typically means that the firmware got stuck while sending
packets. Can you tell me on what band your router operates? 2.4GHz or
5.2GHz?
Do you use 20Mhz or 40MHz?

Basically, I'd like to see the output of iw dev

> which was odd, because that kernel had worked fine before.

This is really firmware related.

> 
> I booted between two different kernels, going back to an older 4.5-rc3
> one that had been running a lot longer on that machine, because
> initially I thought that this was some recent kernel failure (I didn't
> initially connect it with the firmware upgrade, because this is my
> kids machine and I hadn't tested networking after the firmware
> update). But that older known-good kernel failed the same way.
> 
> Going all the way back to the 4.4 kernel that Fedora uses made
> wireless work, and then rebooting back into a 4.5 kernel also worked.
> 

Hmm, this is strange since 4.4 and 4.5 will both load -16.ucode which
you seemed to be running when the have the Queue hang message. So I'd
assume you have the same firmware running on both kernels. Sometimes, a
bug starts to appear on a new kernel, and people think the bug is in the
kernel, but in fact the newer kernel just loads a new firmware which has
a bug. In a way, it is a regression in the "system" caused by a kernel
upgrade, but the debug must be done on the firmware really.

FYI: the newest firmware a kernel supports is in:
drivers/net/wireless/intel/iwlwifi/iwl-X000.c
in your case: 8000.c:
#define IWL8000_UCODE_API_MAX   20

The newest firmware I released to distros is -16, so you load -16.
BTW - when you'll pull from davem, you be able to run -21.ucode which
has been merged into linux-firmware.git.

> Now, it's *possible* that it was just something odd and transient and
> it just happened to clear up as I rebooted into the Fedora kernel, but
> it feels more likely that there's some incomplete initialization in
> recent 4.5 kernels, which isn't normally noticeable, but the full
> system reset done as part of the firmware upgrade might have shown it.

While everything is possible especially when you have radio involved, it
would really surprise me.

> 
> I'm attaching all the iwlwifi debug output that goes along with the
> stuck queue, in the hopes that it makes sense to somebody. This is
> from the 4.5-rc3 boot into an older kernel, but final 4.5 showed the
> same behavior.

Sadly, the only sense it makes is that the firmware gets stuck.
>From that point, I can suggest you test different firmware versions
(including intermediate version that I haven't pushed to
linux-firmware.git). You can check the firmware versions from -16 to -21
in my linux-firmware.git clone:
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git
You need iwlwifi-8000C-XX.ucode

> 
> Googling iwlwifi stuck queues shows a lot of reports over the years,
> but it might be a common symptom of "something is screwed up".

Yeah... I can't claim it is the first time I see this. The good news is
that we have developed very powerful tools to debug this kind of
problems now and the firmware team can get what they need to address
those issues. The debugging and fix is outside my area of control though.

> 
> I'm not sure I can reproduce it any more now that it works again (and
> I'm not really willing to force a firmware downgrade), but if there is
> something particular to test, I can do that.

If you can reproduce, I can send you an instrumented firmware that can
record data in a cyclic buffer. When it will crash, it'll create a
devcoredump device which you can dump on the file system and send to me.
More details here:
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging

Please also look at the privacy notice.

But of course, if you can't reproduce, it won't really help. Let me know
if you want me to send you a firmware for debugging.

> 
> Ideas?
> 
> Linus
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi incomplete initialization in Linux 4.5?

[Grumbach, Emmanuel]

Replying to self to remove people who were added in CC and should really
have been BCC'ed.

On 03/16/2016 11:13 PM, Grumbach, Emmanuel wrote:
> Hi Linus,
> 
> On 03/16/2016 10:48 PM, Linus Torvalds wrote:
>> So I upgraded the firmware on my Intel NUC (NUC6i3SYK), and that made
>> the wireless no longer work with a 4.5 kernel. I could get the
>> occasional packets through, but not many, and ti would hang for ten
>> seconds at a time, and then output errors like
>>
>>   iwlwifi :01:00.0: Queue 2 stuck for 1 ms.
>>   iwlwifi :01:00.0: Current SW read_ptr 60 write_ptr 93
>>   ..
>>
> 
> This ... typically means that the firmware got stuck while sending
> packets. Can you tell me on what band your router operates? 2.4GHz or
> 5.2GHz?
> Do you use 20Mhz or 40MHz?
> 
> Basically, I'd like to see the output of iw dev
> 
>> which was odd, because that kernel had worked fine before.
> 
> This is really firmware related.
> 
>>
>> I booted between two different kernels, going back to an older 4.5-rc3
>> one that had been running a lot longer on that machine, because
>> initially I thought that this was some recent kernel failure (I didn't
>> initially connect it with the firmware upgrade, because this is my
>> kids machine and I hadn't tested networking after the firmware
>> update). But that older known-good kernel failed the same way.
>>
>> Going all the way back to the 4.4 kernel that Fedora uses made
>> wireless work, and then rebooting back into a 4.5 kernel also worked.
>>
> 
> Hmm, this is strange since 4.4 and 4.5 will both load -16.ucode which
> you seemed to be running when the have the Queue hang message. So I'd
> assume you have the same firmware running on both kernels. Sometimes, a
> bug starts to appear on a new kernel, and people think the bug is in the
> kernel, but in fact the newer kernel just loads a new firmware which has
> a bug. In a way, it is a regression in the "system" caused by a kernel
> upgrade, but the debug must be done on the firmware really.
> 
> FYI: the newest firmware a kernel supports is in:
> drivers/net/wireless/intel/iwlwifi/iwl-X000.c
> in your case: 8000.c:
> #define IWL8000_UCODE_API_MAX   20
> 
> The newest firmware I released to distros is -16, so you load -16.
> BTW - when you'll pull from davem, you be able to run -21.ucode which
> has been merged into linux-firmware.git.
> 
>> Now, it's *possible* that it was just something odd and transient and
>> it just happened to clear up as I rebooted into the Fedora kernel, but
>> it feels more likely that there's some incomplete initialization in
>> recent 4.5 kernels, which isn't normally noticeable, but the full
>> system reset done as part of the firmware upgrade might have shown it.
> 
> While everything is possible especially when you have radio involved, it
> would really surprise me.
> 
>>
>> I'm attaching all the iwlwifi debug output that goes along with the
>> stuck queue, in the hopes that it makes sense to somebody. This is
>> from the 4.5-rc3 boot into an older kernel, but final 4.5 showed the
>> same behavior.
> 
> Sadly, the only sense it makes is that the firmware gets stuck.
> From that point, I can suggest you test different firmware versions
> (including intermediate version that I haven't pushed to
> linux-firmware.git). You can check the firmware versions from -16 to -21
> in my linux-firmware.git clone:
> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git
> You need iwlwifi-8000C-XX.ucode
> 
>>
>> Googling iwlwifi stuck queues shows a lot of reports over the years,
>> but it might be a common symptom of "something is screwed up".
> 
> Yeah... I can't claim it is the first time I see this. The good news is
> that we have developed very powerful tools to debug this kind of
> problems now and the firmware team can get what they need to address
> those issues. The debugging and fix is outside my area of control though.
> 
>>
>> I'm not sure I can reproduce it any more now that it works again (and
>> I'm not really willing to force a firmware downgrade), but if there is
>> something particular to test, I can do that.
> 
> If you can reproduce, I can send you an instrumented firmware that can
> record data in a cyclic buffer. When it will crash, it'll create a
> devcoredump device which you can dump on the file system and send to me.
> More details here:
> https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging
> 
> Please also look at the privacy notice.
> 
> But of course, if you can't reproduce, it won't really help. Let me know
> if you want me to send you a firmware for debugging.
> 
>>
>> Ideas?
>>
>> Linus
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi -21.ucode firmware

[Grumbach, Emmanuel]

On 03/10/2016 08:50 PM, Kyle McMartin wrote:
> On Thu, Mar 10, 2016 at 07:29:15AM +0000, Grumbach, Emmanuel wrote:
>> Hi Kyle,
>>
>> This is a pull request to include our latest available firmware into
>> mainline linux-firmware.git.
>>
>> It includes -21.ucode for various devices including devices for which
>> this is the first supported firmware (3168 and 8265).
>> This firmware is supported starting kernel 4.6.
>>
>> Please pull!
>>
> 
> Pulled, can you follow this up and update WHENCE? I'd do it, but there's
> a lack of consistency between Version: and some of the past commit
> messages, so I'm not sure what the right value would be.
> 

Ooops - sorry:

e6dedba0a09221a755ae4573d70b86c804a14be2 in the same tree.

diff --git a/WHENCE b/WHENCE
index e249c49..a9c5e98 100644
--- a/WHENCE
+++ b/WHENCE
@@ -897,12 +897,24 @@ Version: 25.30.13.0
 File: iwlwifi-7265D-16.ucode
 Version 16.242414.0

+File: iwlwifi-7265D-21.ucode
+Version 21.302800.0
+
+File: iwlwifi-3168-21.ucode
+Version 21.302800.0
+
 File: iwlwifi-8000C-13.ucode
 Version: 25.30.13.0

 File: iwlwifi-8000C-16.ucode
 Version 16.242414.0

+File: iwlwifi-8000C-21.ucode
+Version 21.302800.0
+
+File: iwlwifi-8265-21.ucode
+Version 21.302800.0
+
 Licence: Redistributable. See LICENCE.iwlwifi_firmware for details

 Also available from
http://wireless.kernel.org/en/users/Drivers/iwlwifi#Firmware

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi -21.ucode firmware

[Grumbach, Emmanuel]

Hi Kyle,

This is a pull request to include our latest available firmware into
mainline linux-firmware.git.

It includes -21.ucode for various devices including devices for which
this is the first supported firmware (3168 and 8265).
This firmware is supported starting kernel 4.6.

Please pull!

Thank you.

The following changes since commit 8d1fd61a3723ab8cb6b7bfeb8be38e16282cc1ed:

nvidia: Add GM20B signed firmware (2016-02-23 18:48:41 +0900)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git
tags/iwlwifi-fw-2016-03-09

for you to fetch changes up to a2c354e64cec4b1146054c7e5b7df4329af752a7:

iwlwifi: add new -21.ucode for 7265D, 8260, 3168 and 8265 devices
(2016-03-09 22:41:59 +0200)


This includes -21.ucode for the following devices:
* 7265D
* 3165
* 8260
* 3168 (new device)
* 8265 (new device)


Emmanuel Grumbach (1):
iwlwifi: add new -21.ucode for 7265D, 8260, 3168 and 8265 devices

iwlwifi-3168-21.ucode | Bin 0 -> 1384856 bytes
iwlwifi-7265D-21.ucode | Bin 0 -> 1385368 bytes
iwlwifi-8000C-21.ucode | Bin 0 -> 2394060 bytes
iwlwifi-8265-21.ucode | Bin 0 -> 2389968 bytes
4 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 iwlwifi-3168-21.ucode
create mode 100644 iwlwifi-7265D-21.ucode
create mode 100644 iwlwifi-8000C-21.ucode
create mode 100644 iwlwifi-8265-21.ucode
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi-next 2016-03-09

[Grumbach, Emmanuel]

Hi Kalle,

this is the very last pull request for 4.6. I hope it is not too late.
Most of it are fixes for code that is already in
wireless-drivers.next.git. There are a few other patches as well.
Let me know if you have issues!
Thank you.

The following changes since commit 53f09e742b0fdf14a2a2bfd2062ee96c9b3eedf0:

  Merge branch 'fixes' into next (2016-03-02 09:35:38 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2016-03-09

for you to fetch changes up to 0831fcd67fc5bddd360bca51a3892bbd33048dbb:

  iwlwifi: mvm: update GSCAN capabilities (2016-03-09 16:55:39 +0200)


* update GSCAN capabilities (Ayala)
* fix AES-CMAC in AP mode (Johannes)
* adapt prints to new firmware API
* rx path improvements (Sara and Gregory)
* fixes for the thermal / cooling device code (Chaya Rachel)
* fixes for GO uAPSD handling
* more code for the 9000 device family (Sara)
* infrastructure work for firmware notification (Chaya Rachel)
* improve association reliablity (Sara)
* runtime PM fixes
* fixes for ROC (HS2.0)


Ayala Beker (1):
  iwlwifi: mvm: update GSCAN capabilities

Chaya Rachel Ivgi (4):
  iwlwifi: mvm: fix unregistration of thermal in some error flows
  iwlwifi: mvm: add ctdp operations to debugfs
  iwlwifi: mvm: add support for async rx handler without hold the mutex
  iwlwifi: mvm: return the cooling state index instead of the budget

Emmanuel Grumbach (4):
  iwlwifi: mvm: avoid panics with thermal device usage
  iwlwifi: mvm: don't let NDPs mess the packet tracking
  iwlwifi: mvm: remove RRM advertisement
  iwlwifi: mvm: adapt the firmware assert log to new firmware

Gregory Greenman (1):
  iwlwifi: pcie: avoid restocks inside rx loop if not emergency

Johannes Berg (1):
  iwlwifi: mvm: don't try to offload AES-CMAC in AP/IBSS modes

Luca Coelho (1):
  iwlwifi: pcie: forbid RTPM on device removal

Matti Gottlieb (1):
  iwlwifi: mvm: ROC: cleanup time event info on FW failure

Sara Sharon (8):
  iwlwifi: pcie: refactor RXBs reclaiming code
  iwlwifi: pcie: set RB chunk size back to 64
  iwlwifi: refactor the code that reads the MAC address from the NVM
  iwlwifi: mvm: set the correct amsdu enum values
  iwlwifi: mvm: extend time event duration
  iwlwifi: mvm: turn off AMSDU bit in QoS control for de-aggregated AMSDUs
  iwlwifi: pcie: fine tune number of rxbs
  iwlwifi: add support for getting HW address from CSR

 drivers/net/wireless/intel/iwlwifi/dvm/main.c |   8 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-9000.c |   3 +-
 drivers/net/wireless/intel/iwlwifi/iwl-config.h   |   2 +
 drivers/net/wireless/intel/iwlwifi/iwl-csr.h  |  10 +
 drivers/net/wireless/intel/iwlwifi/iwl-devtrace-iwlwifi.h |  27 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c  |  38 
++---
 drivers/net/wireless/intel/iwlwifi/iwl-fh.h   |   9 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h  |  11 +
 drivers/net/wireless/intel/iwlwifi/iwl-fw.h   |  13 ++
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c| 146 

 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h|   5 +--
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c  |  42 
+++
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h|   5 +--
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c |  14 +++
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h  |   5 +--
 drivers/net/wireless/intel/iwlwifi/mvm/nvm.c  |  11 +
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c  | 120 
+
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c |  12 ++
 drivers/net/wireless/intel/iwlwifi/mvm/time-event.c   |  15 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/time-event.h   |   2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c   | 175 
++---
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c   |  29 +++--
 drivers/net/wireless/intel/iwlwifi/mvm/utils.c|  28 ++---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c |  28 +
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h|   2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c  | 148 
-
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c   |   6 ---
 27 files changed, 563 insertions(+), 351 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe 

RE: [PATCH] mac80211: Set global RRM capability

[Grumbach, Emmanuel]

> Subject: [PATCH] mac80211: Set global RRM capability
> 
> Allow publishing RRM capabilities for features that are not HW dependent.
> 
> Signed-off-by: Emmanuel Grumbach 
> ---

Err... please ignore..

>  net/mac80211/main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c index
> 8190bf2..0c9b621 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -548,7 +548,8 @@ struct ieee80211_hw
> *ieee80211_alloc_hw_nm(size_t priv_data_len,
>  NL80211_FEATURE_VIF_TXPOWER |
>  NL80211_FEATURE_MAC_ON_CREATE |
>  NL80211_FEATURE_USERSPACE_MPM |
> -NL80211_FEATURE_FULL_AP_CLIENT_STATE;
> +NL80211_FEATURE_FULL_AP_CLIENT_STATE |
> +NL80211_EXT_FEATURE_RRM;
> 
>   if (!ops->hw_scan)
>   wiphy->features |=
> NL80211_FEATURE_LOW_PRIORITY_SCAN |
> --
> 2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

[Grumbach, Emmanuel]

On 03/07/2016 07:15 PM, Avery Pennarun wrote:
> On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht  wrote:
>> If I can just get a coherent patch set that I can build, I will gladly
>> join you on the testing ath9k in particular... can probably do ath10k,
>> too - and do a bit of code review... this week. it's very exciting
>> watching all this activity...
>>
>> but I confess that I've totally lost track of what set of trees and
>> patchwork I should try to pull from. wireless-drivers-next? ath10k?
>> wireless-next? net-next? toke and I have a ton of x86 platforms
>> available to test on
>>
>> Avery - which patches did you use??? on top of what?
>
> The patch series I'm currently using can be found here:
>
>git fetch https://gfiber.googlesource.com/vendor/opensource/backports
> ath9k_txq+fq_codel
>
> That's again backports-20160122, which comes from linux-next as of
> 20160122.  You can either build backports against whatever kernel
> you're using (probably easiest) or try to use that version of
> linux-next, or rebase the patches onto your favourite kernel.
>
>> In terms of "smoothing" codel...
>>
>> I emphatically do not think codel in it's current form is "ready" for
>> wireless, at the very least the target should not be much lower than
>> 20ms in your 2 station tests.  There is another bit in codel where the
>> algo "turns off" with only a single MTU's worth of packets
>> outstanding, which could get bumped to the ideal size of the
>> aggregate. "ideal" kind of being a variable based on a ton of other
>> factors...
>
> Yeah, I figured that sort of thing would come up.  I'm feeling forward
> progress just by finally seeing the buggy oscillations finally happen,
> though. :)
>
>> the underlying code needs to be striving successfully for per-station
>> airtime fairness for this to work at all, and the driver/card
>> interface nearly as tight as BQL is for the fq portion to behave
>> sanely. I'd configure codel at a higher target and try to observe what
>> is going on at the fq level til that got saner.
>
> That seems like two good goals.  So Emmanuel's BQL-like thing seems
> like we'll need it soon.

Well... I am going to do that for station only, and only for iwlwifi.
I haven't had a chance to work on that since then :( but I hope to get 
back to it. I also need to check what happens in multiple channels 
scenarios (in which there is inherent latency).
AP and stations have different challenges.

>
> As for per-station airtime fairness, what's a good approximation of
> that?  Perhaps round-robin between stations, one aggregate per turn,
> where each aggregate has a maximum allowed latency?  I don't know how
> the current code works, but it's probably almost like that, as long as
> we only put one aggregate's worth of stuff into each hwq, which I
> guess is what the BQL-like thing will do.
>
> So if I understand correctly, what we need is, in the following order:
> 1) Disable fq_codel for now, and get BQL-like thing working in ath9k
> (and ensure we're getting airtime fairness even without fq_codel);
> 2) Re-enable fq_codel and increase fq_codel's target up to 20ms for now;
> 3) Tweak fq_codel's "turn off" size to be larger (how important is this?)
>
> Is that right?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak

[Grumbach, Emmanuel]

On 03/06/2016 02:04 PM, Kalle Valo wrote:
> Luca Coelho  writes:
>
>> On Fri, 2016-03-04 at 18:07 +0200, Kalle Valo wrote:
>>> Emmanuel Grumbach  writes:
>>>
 From: Matti Gottlieb 

 If the opmode is stopped and started again we did not free
 the paging buffers. Fix that.
 In addition when freeing the firmware's paging download
 buffer, set the pointer to NULL.

 Signed-off-by: Matti Gottlieb 
 Signed-off-by: Emmanuel Grumbach 
>>>
>>> Nitpicking while writing the pull request for Dave:
>>>
>>> What does "opmode is stopped" mean? Important bug fixes should have a
>>> clear bug description from user's point of view. Using driver internal
>>> jargon is gibberish to most people.
>>
>> I agree that there could be a bit more high-level description here, but
>> I also think it's good to keep a bit more details about what is
>> happening internally, so that developers understand too. ;)
>
> Sure, feel free to write as much as you want and in such detail as you
> think is necessary :) Just having a clear summary without internal
> jargon helps people outside of iwlwifi.
>
> BTW, the other iwlwifi fix had a bit similar problem:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=fb896c44f88a75843a072cd6961b1615732f7811
>
> What does "non-sta" mean in this context? Is it the AP or what? Or
> something not part of the current BSS? I guess I might find a definition
> from the spec or from iwlwifi sources but I really should not be forced
> to do that.

non-sta in that context means an skb sent without a valid ieee80211_sta 
buffer. Which basically means that it is a non-data frame or a multicast 
frame.

>
>> Do you think it would be acceptable to keep the commit log most as it
>> is, but start with something like "Some paging buffers were not freed
>> when the driver is restarted."? I don't mean to change this commit
>> itself, but just so that we know how to please you (and users) while
>> still keeping the details as part of the commit logs... ;)
>
> That sounds good to me. What I'm after is that someone like Dave or
> Linus can understand from the commit log what kind of bug this patch is
> fixing, without looking into source or checking mailing lists. This is
> especially more important in the later stages of the cycle.
>
>>> I investigated this myself and apparently "opmode" is stopped when the
>>> module is unloaded or the PCI device is removed. So just say that in the
>>> commit log and everyone understand much better.
>>
>> Our driver is divided roughly into two layers: the bus layer (called
>> transport) and the protocol layer (called opmode).  The name comes from
>> the difference between the two opmodes that we currently have.  One
>> supports only a single operating channel (dvm) and the other supports
>> multiple operating channels (mvm).
>>
>> Hope this clarifies a bit. :)
>
> It did, thanks.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211_hwsim: Set global RRM capability

[Grumbach, Emmanuel]

On 03/03/2016 05:45 PM, Johannes Berg wrote:
> On Wed, 2016-03-02 at 12:36 +0000, Grumbach, Emmanuel wrote:
>>>
>> I had the same thinking, but somehow people convinced me that a
>> driver may prefer not to advertise this without its explicit
>> consent.
>
> So ... What are the arguments? :)
>

Well.. a driver may not want to advertise it... Moot...
I guess we can / should move it to mac80211.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi-next 2016-03-02

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.6. It is big because a lot of patches were
waiting for code in mac80211-next which is now in net-next.
As you figured, I need you to pull Johannes's 
mac80211-next-for-davem-2016-02-26 before you pull this from me.
Of course, you can just merge net-next. This is really up to you :)
I also merged iwlwifi-fixes.git (twice even) to prevent conflicts upstream.
In the tag, I mentioned which patches need mac80211-next since you asked for it
last time.

My prevent_stupid_mistakes.sh script seems to be working fairly well now,
in case you see an issue, let me know.

Thanks!


The following changes since commit 50ee738d7271fe825e4024cdfa5c5301a871e2c2:

  rfkill: Add documentation about LED triggers (2016-02-24 09:13:12 +0100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2016-03-02

for you to fetch changes up to 53f09e742b0fdf14a2a2bfd2062ee96c9b3eedf0:

  Merge branch 'fixes' into next (2016-03-02 09:35:38 +0200)


* add support for thermal device / cooling device (Chaya Rachel)
* fixes for 9000 devices data path (Sara Sharon)
* improvements in scheduled scan w/o profiles (Luca)
* new firmware support (-21.ucode)
* add MSIX support for 9000 devices (Haim Dreyfuss)
* cleanup in PCIe initialization
* enable MU-MIMO and take care of firmware restart(Sara Sharon)
===> This needs mac80211-next
* add support for large SKBs in mvm to reach A-MSDU
===> This needs mac80211-next
* add support for filtering frames from a BA session (Sara Sharon)
===> This needs mac80211-next
* start implementing the new Rx path for 9000 devices (Sara Sharon)
* enable the new RRM feature flag (Beni Lev)
* fix U-APSD enablement on P2P Client (Avri Altman)
* fix beacon abort enablement (Avri Altman)
* forbid beacon storing with WoWLAN (Matti Gottlieb)
* support unified uSniffer / regular firmware image (Golan Ben-Ami)
* fix a race between debugfs hooks and iface up (Chaya Rachel Ivgi)
* fixes for runtime PM (Luca)
* add a new module paramater to disable VHT (Andrei Otcheretianski)
* build infrastructure for Dynamic Queue Allocation (Liad Kaufman)


Andrei Otcheretianski (1):
  iwlwifi: add disable_11ac module param

Avri Altman (2):
  iwlwifi: mvm: forbid U-APSD for P2P Client if the firmware doesn't 
support it
  iwlwifi: mvm: Send power command on BSS_CHANGED_BEACON_INFO if needed

Beni Lev (1):
  iwlwifi: mvm: Set global RRM capability

Chaya Rachel Ivgi (4):
  iwlwifi: mvm: add CT-KILL notification
  iwlwifi: mvm: add registration to thermal zone
  iwlwifi: mvm: add registration to cooling device
  iwlwifi: mvm: update ucode status before stopping device

Emmanuel Grumbach (15):
  Merge tag 'mac80211-next-for-davem-2016-02-26' into next2
  Merge tag 'iwlwifi-for-kalle-2016-02-15' into HEAD
  iwlwifi: mvm: bump firmware API to 21
  iwlwifi: pcie: aggregate Flow Handler configuration writes
  iwlwifi: pcie: fix identation in trans.c
  iwlwifi: mvm: send large SKBs to the transport
  iwlwifi: mvm: add Tx A-MSDU inside A-MPDU
  iwlwifi: mvm: allow to limit the A-MSDU from debugfs
  iwlwifi: mvm: don't enable A-MSDU when the rates are too low
  iwlwifi: mvm: don't send an A-MSDU that is larger than the TXF
  iwlwifi: pcie: prevent skbs shadowing in iwl_trans_pcie_reclaim
  iwlwifi: mvm: remove unused field in iwl_mvm_tid_data
  iwlwifi: mvm: various trivial cleanups
  iwlwifi: mvm: kill iwl_mvm_enable_agg_txq
  Merge branch 'fixes' into next

Eyal Shapira (1):
  iwlwifi: mvm: rs: fix a theoretical access to uninitialized array elements

Golan Ben-Ami (1):
  iwlwifi: support ucode with d0 unified image - regular and usniffer

Haim Dreyfuss (1):
  iwlwifi: pcie: Add new configuration to enable MSIX

Liad Kaufman (3):
  iwlwifi: mvm: inc pending frames counter also when txing non-sta
  iwlwifi: mvm: disable DQA support
  iwlwifi: mvm: support sw queue start/stop from mvm

Luca Coelho (4):
  iwlwifi: mvm: handle pass all scan reporting
  iwlwifi: pcie: add pm_prepare and pm_complete ops
  iwlwifi: mvm: only release the trans ref if d0i3 is supported in fw
  iwlwifi: mvm: take the transport ref back when leaving

Matti Gottlieb (2):
  iwlwifi: mvm: Fix paging memory leak
  iwlwifi: mvm: Disable beacon storing in  D3 when WOWLAN configured

Sara Sharon (13):
  iwlwifi: mvm: set the correct descriptor size for tracing
  iwlwifi: mvm: fix RSS key sizing
  iwlwifi: mvm: enable VHT MU-MIMO for supported hardware
  iwlwifi: mvm: update firmware of VHT MU-MIMO groups status on restart
  iwlwifi: support tracing wide commands
  iwlwifi: mvm: update rx_status with mactime flag
  iwlwifi: mvm: support 

pull request: iwlwifi 2016-02-25

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.5 still. Two small fixes. One of them has a really 
visible impact when we remove stations.
Let me know if you have issues! Thanks.

The following changes since commit 20aa99bbddae74bded68338f9ba200ccae02858b:

  iwlwifi: pcie: fix erroneous return value (2016-02-15 13:38:31 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-02-25

for you to fetch changes up to 905e36ae172c83a30894a3adefab7d4f850fcf54:

  iwlwifi: mvm: Fix paging memory leak (2016-02-23 21:51:30 +0200)


Two fixes for 4.5:
* We forgot to free the paging memory (Matti)
* Fix the frames in flight accounting (Liad)


Liad Kaufman (1):
  iwlwifi: mvm: inc pending frames counter also when txing non-sta

Matti Gottlieb (1):
  iwlwifi: mvm: Fix paging memory leak

 drivers/net/wireless/intel/iwlwifi/mvm/fw.c  | 4 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +++
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 2 ++
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c  | 9 +
 4 files changed, 17 insertions(+), 1 deletion(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: intel7260 - iface up sometimes failed

[Grumbach, Emmanuel]

> 
> Hi Janusz,
> 
> >
> > Hello,
> >
> > I have intel7260 connected via external PCIe + DELL latitude e6430.
> >
> > [ 5199.805417] iwlwifi :04:00.0: enabling device (0100 -> 0102) [
> > 5199.809222] iwlwifi :04:00.0: loaded firmware version
> > 17.275772.0 op_mode iwlmvm
> > [ 5199.819548] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> > Wireless AC 7260, REV=0x144 [ 5199.819658] iwlwifi :04:00.0: L1
> > Enabled - LTR Disabled [ 5199.820018] iwlwifi :04:00.0: L1 Enabled
> > - LTR Disabled [ 5200.012786] ieee80211 phy0: Selected rate control
> algorithm 'iwl-mvm-rs'
> > [ 5200.020148] iwlwifi :04:00.0 wlan3: renamed from wlan0
> >
> > [ 5282.743987] iwlwifi :04:00.0: L1 Enabled - LTR Disabled [
> > 5282.781812] -- --[ cut here ] [ 5282.781823]
> > WARNING: CPU: 3 PID: 3760 at
> > drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1561
> > iwl_trans_pcie_grab_nic_access+0xe6/0xf0 [iwlwifi]() [ 5282.781824]
> > Timeout waiting for hardware access (CSR_GP_CNTRL 0x) [
> 
> Well... you are not the only one to complain about this issue and
> unfortunately, there isn't much I can do. What it means is that the device is
> removed from the bus by the PCIe controller. This happens due to an
> electrical problem which I can't really help with. This can be caused by
> different types of voodoos, like interference on the PCIe lines and other
> things that can't really be root caused without taking the system into the lab
> and adding PCIe analyzer probes.
> I am afraid I can't really help.
> As a workaround, you can unbind the device from the bus and re-
> enumerate. This will bring the device back... until the next failure.

One thing that come through my mind is that you can try to disable power save 
(power_sheme=1 as a module parameter to iwlmvm) which will prevent LX power 
state entrance and might reduce the noise on the PCIe lines. Worth trying.
N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

RE: intel7260 - iface up sometimes failed

[Grumbach, Emmanuel]

Hi Janusz,

> 
> Hello,
> 
> I have intel7260 connected via external PCIe + DELL latitude e6430.
> 
> [ 5199.805417] iwlwifi :04:00.0: enabling device (0100 -> 0102) [
> 5199.809222] iwlwifi :04:00.0: loaded firmware version
> 17.275772.0 op_mode iwlmvm
> [ 5199.819548] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC
> 7260, REV=0x144 [ 5199.819658] iwlwifi :04:00.0: L1 Enabled - LTR
> Disabled [ 5199.820018] iwlwifi :04:00.0: L1 Enabled - LTR Disabled [
> 5200.012786] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
> [ 5200.020148] iwlwifi :04:00.0 wlan3: renamed from wlan0
> 
> [ 5282.743987] iwlwifi :04:00.0: L1 Enabled - LTR Disabled [ 5282.781812] 
> --
> --[ cut here ] [ 5282.781823] WARNING: CPU: 3 PID: 3760 at
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1561
> iwl_trans_pcie_grab_nic_access+0xe6/0xf0 [iwlwifi]() [ 5282.781824]
> Timeout waiting for hardware access (CSR_GP_CNTRL 0x) [

Well... you are not the only one to complain about this issue and 
unfortunately, there isn't much I can do. What it means is that the device is 
removed from the bus by the PCIe controller. This happens due to an electrical 
problem which I can't really help with. This can be caused by different types 
of voodoos, like interference on the PCIe lines and other things that can't 
really be root caused without taking the system into the lab and adding PCIe 
analyzer probes.
I am afraid I can't really help.
As a workaround, you can unbind the device from the bus and re-enumerate. This 
will bring the device back... until the next failure.
N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

pull request: iwlwifi-2016-02-16

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.5. Apart from my RF-Kill fix, the patches are
really small. My RF-Kill patch needed to move code around to avoid adding
a forward declaration and on the way there were a few very trivial code style
fixes, that were needed to make checkpatch happy.

Let me know if you have issues, thanks!


The following changes since commit 69c7fda40921c125f6a827f6270ac6aa1baa:

  iwlwifi: mvm: rs: fix TPC statistics handling (2016-01-26 16:03:35 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-02-15

for you to fetch changes up to 20aa99bbddae74bded68338f9ba200ccae02858b:

  iwlwifi: pcie: fix erroneous return value (2016-02-15 13:38:31 +0200)


These are a few fixes for the current cycle.
3 out of the 5 patches fix a bugzilla.

* fix a race that users reported when we try to load the firmware
  and the hardware rfkill interrupt triggers at the same time.
* Luca fixes a very visible bug in scheduled scan: our firmware
  doesn't support scheduled scan with no profile configured and
  the supplicant sometimes requests such scheduled scans.
* build system fix
* firmware name update for 8265
* typo fix in return value


Anton Protopopov (1):
  iwlwifi: pcie: fix erroneous return value

Emmanuel Grumbach (2):
  iwlwifi: dvm: remove a wrong dependency on m
  iwlwifi: pcie: fix RF-Kill vs. firmware load race

Luca Coelho (1):
  iwlwifi: mvm: don't allow sched scans without matches to be started

Oren Givon (1):
  iwlwifi: fix name of ucode loaded for 8265 series

 drivers/net/wireless/intel/iwlwifi/Kconfig |   1 -
 drivers/net/wireless/intel/iwlwifi/iwl-8000.c  |  42 --
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c   |   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c  |   4 +
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h |   9 ++
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c   |   8 +-
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c| 188 
--
 7 files changed, 164 insertions(+), 94 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

[Grumbach, Emmanuel]

On 02/15/2016 11:21 AM, Eliad Peller wrote:
> On Mon, Feb 15, 2016 at 11:16 AM, Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com> wrote:
>>
>> On 02/15/2016 11:06 AM, Eliad Peller wrote:
>>> On Sun, Feb 14, 2016 at 9:37 PM, Grumbach, Emmanuel
>>> <emmanuel.grumb...@intel.com> wrote:
>>>> On 02/14/2016 09:33 PM, Johannes Berg wrote:
>>>>> On Sun, 2016-02-14 at 19:34 +0200, Emmanuel Grumbach wrote:
>>>>>> Since the 3rd patch needs to be dropped anyway, let's route this one
>>>>>> through my tree as usual.
>>>>> It doesn't really have to be dropped, why? We can just make the same
>>>>> adjustment as for dvm in the patch.
>>>>>
>>>> But I am not sure I really want to play with drivers/staging/vt6656/rxtx.c
>>> here you go:
>>>
>>> diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
>>> index b668db6..1a2dda0 100644
>>> --- a/drivers/staging/vt6655/rxtx.c
>>> +++ b/drivers/staging/vt6655/rxtx.c
>>>
>> Want to send that patch to Greg? :)
> why? can't you simply amend it to the third patch?
>
>

It doesn't feel right to remove this function in mac80211-next.git and
touch 3 drivers along the way, but I don't mind. Johannes, what do you say?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

[Grumbach, Emmanuel]

On 02/15/2016 11:06 AM, Eliad Peller wrote:
> On Sun, Feb 14, 2016 at 9:37 PM, Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com> wrote:
>>
>> On 02/14/2016 09:33 PM, Johannes Berg wrote:
>>> On Sun, 2016-02-14 at 19:34 +0200, Emmanuel Grumbach wrote:
>>>> Since the 3rd patch needs to be dropped anyway, let's route this one
>>>> through my tree as usual.
>>> It doesn't really have to be dropped, why? We can just make the same
>>> adjustment as for dvm in the patch.
>>>
>> But I am not sure I really want to play with drivers/staging/vt6656/rxtx.c
> here you go:
>
> diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
> index b668db6..1a2dda0 100644
> --- a/drivers/staging/vt6655/rxtx.c
> +++ b/drivers/staging/vt6655/rxtx.c
> @@ -1210,7 +1210,7 @@ static void vnt_fill_txkey(struct ieee80211_hdr
> *hdr, u8 *key_buffer,
> struct sk_buff *skb, u16 payload_len,
> struct vnt_mic_hdr *mic_hdr)
>  {
> - struct ieee80211_key_seq seq;
> + u64 pn64;
>   u8 *iv = ((u8 *)hdr + ieee80211_get_hdrlen_from_skb(skb));
>
>   /* strip header and icv len from payload */
> @@ -1243,9 +1243,13 @@ static void vnt_fill_txkey(struct ieee80211_hdr
> *hdr, u8 *key_buffer,
>   mic_hdr->payload_len = cpu_to_be16(payload_len);
>   ether_addr_copy(mic_hdr->mic_addr2, hdr->addr2);
>
> - ieee80211_get_key_tx_seq(tx_key, );
> -
> - memcpy(mic_hdr->ccmp_pn, seq.ccmp.pn, IEEE80211_CCMP_PN_LEN);
> + pn64 = atomic64_read(_key->tx_pn);
> + mic_hdr->ccmp_pn[5] = pn64;
> + mic_hdr->ccmp_pn[4] = pn64 >> 8;
> + mic_hdr->ccmp_pn[3] = pn64 >> 16;
> + mic_hdr->ccmp_pn[2] = pn64 >> 24;
> + mic_hdr->ccmp_pn[1] = pn64 >> 32;
> + mic_hdr->ccmp_pn[0] = pn64 >> 40;
>
>   if (ieee80211_has_a4(hdr->frame_control))
>   mic_hdr->hlen = cpu_to_be16(28);
> diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
> index efb54f5..76378d2 100644
> --- a/drivers/staging/vt6656/rxtx.c
> +++ b/drivers/staging/vt6656/rxtx.c
> @@ -719,7 +719,7 @@ static void vnt_fill_txkey(struct
> vnt_usb_send_context *tx_context,
>   u16 payload_len, struct vnt_mic_hdr *mic_hdr)
>  {
>   struct ieee80211_hdr *hdr = tx_context->hdr;
> - struct ieee80211_key_seq seq;
> + u64 pn64;
>   u8 *iv = ((u8 *)hdr + ieee80211_get_hdrlen_from_skb(skb));
>
>   /* strip header and icv len from payload */
> @@ -752,9 +752,13 @@ static void vnt_fill_txkey(struct
> vnt_usb_send_context *tx_context,
>   mic_hdr->payload_len = cpu_to_be16(payload_len);
>   ether_addr_copy(mic_hdr->mic_addr2, hdr->addr2);
>
> - ieee80211_get_key_tx_seq(tx_key, );
> -
> - memcpy(mic_hdr->ccmp_pn, seq.ccmp.pn, IEEE80211_CCMP_PN_LEN);
> + pn64 = atomic64_read(_key->tx_pn);
> + mic_hdr->ccmp_pn[5] = pn64;
> + mic_hdr->ccmp_pn[4] = pn64 >> 8;
> + mic_hdr->ccmp_pn[3] = pn64 >> 16;
> + mic_hdr->ccmp_pn[2] = pn64 >> 24;
> + mic_hdr->ccmp_pn[1] = pn64 >> 32;
> + mic_hdr->ccmp_pn[0] = pn64 >> 40;
>
>   if (ieee80211_has_a4(hdr->frame_control))
>   mic_hdr->hlen = cpu_to_be16(28);
>
>
> Eliad.
>

Want to send that patch to Greg? :)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

[Grumbach, Emmanuel]

On 02/14/2016 09:33 PM, Johannes Berg wrote:
> On Sun, 2016-02-14 at 19:34 +0200, Emmanuel Grumbach wrote:
>>  
>> Since the 3rd patch needs to be dropped anyway, let's route this one
>> through my tree as usual.
> It doesn't really have to be dropped, why? We can just make the same
> adjustment as for dvm in the patch.
>

But I am not sure I really want to play with drivers/staging/vt6656/rxtx.c
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] codel: add forgotten inline to functions in header file

[Grumbach, Emmanuel]

fixing linux-wireless address ...

On 02/11/2016 04:30 PM, Eric Dumazet wrote:
> On Thu, 2016-02-11 at 16:08 +0200, Emmanuel Grumbach wrote:
>> Signed-off-by: Emmanuel Grumbach 
>> ---
>> -static bool codel_should_drop(const struct sk_buff *skb,
>> -  struct Qdisc *sch,
>> -  struct codel_vars *vars,
>> -  struct codel_params *params,
>> -  struct codel_stats *stats,
>> -  codel_time_t now)
>> +static inline bool codel_should_drop(const struct sk_buff *skb,
>> + struct Qdisc *sch,
>> + struct codel_vars *vars,
>> + struct codel_params *params,
>> + struct codel_stats *stats,
>> + codel_time_t now)
>
> The lack of inline was done on purpose.
>
> This include file is kind of special, being included by codel and
> fq_codel.
>
> Hint : we do not want to force the compiler to inline
> codel_should_drop() (or any other function).
>
>
> See this file as if it was a .c really.
>
>

Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
codel_get_time and associated utils (_before, _after) in iwlwifi.
They're better than jiffies... So maybe I can just copy that code to
iwlwifi.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] codel: add forgotten inline to functions in header file

[Grumbach, Emmanuel]

On 02/11/2016 05:12 PM, Eric Dumazet wrote:
> On Thu, 2016-02-11 at 15:05 +0000, Grumbach, Emmanuel wrote:
>
>
>> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
>> codel_get_time and associated utils (_before, _after) in iwlwifi.
>> They're better than jiffies... So maybe I can just copy that code to
>> iwlwifi.
>
> You certainly can submit a patch adding the inline, but not on all
> functions present in this file ;)
>
> Thanks !
>

Actually... All I need *has* the inline, but if I include codel.h,
codel_dequeue is defined but not used and you definitely don't want to
inline that one. So I guess the only other option I have is to split
that header file which I don't think is really worth it. So, unless you
object it, I'll just copy the code.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iwlwifi: fix erroneous return value

[Grumbach, Emmanuel]

On 02/10/2016 07:10 PM, Anton Protopopov wrote:
> The iwl_trans_pcie_start_fw() function may return the positive value EIO
> instead of -EIO in case of error.
>
> Signed-off-by: Anton Protopopov 
> ---
>  drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
> b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index d60a467..920ea9d 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -1034,7 +1034,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans 
> *trans,
>   if (trans_pcie->is_down) {
>   IWL_WARN(trans,
>"Can't start_fw since the HW hasn't been started\n");
> - ret = EIO;
> + ret = -EIO;
>   goto out;
>   }
>  

applied - thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC RESEND] iwlwifi: pcie: transmit queue auto-sizing

[Grumbach, Emmanuel]

On 02/05/2016 12:06 AM, Dave Taht wrote:
> I am not on linux-wireless nor netdev presently, but...
>
> On Thu, Feb 4, 2016 at 12:16 PM, Emmanuel Grumbach
>  wrote:
>> As many (all?) WiFi devices, Intel WiFi devices have
>> transmit queues which have 256 transmit descriptors
>> each and each descriptor corresponds to an MPDU.
>> This means that when it is full, the queue contains
>> 256 * ~1500 bytes to be transmitted (if we don't have
>> A-MSDUs). The purpose of those queues is to have enough
>> packets to be ready for transmission so that when the device
>> gets an opportunity to transmit (TxOP), it can take as many
>> packets as the spec allows and aggregate them into one
>> A-MPDU or even several A-MPDUs if we are using bursts.
>>
>> The problem is that the packets that are in these queues are
>> already out of control of the Qdisc and can stay in those
>> queues for a fairly long time when the link condition is
>> not good. This leads to the well known bufferbloat problem.
>>
>> This patch adds a way to tune the size of the transmit queue
>> so that it won't cause excessive latency. When the link
>> condition is good, the packets will flow smoothly and the
>> transmit queue will grow quickly allowing A-MPDUs and
>> maximal throughput. When the link is not optimal, we will
>> have retransmissions, lower transmit rates or signal
>> detection (CCA) which will cause a delay in the packet
>> transmission. The driver will sense this higher latency
>> and will reduce the size of the transmit queue.
>> This means that the packets that continue to arrive
>> will pile up in the Qdisc rather than in the device
>> queues. The major advantage of this approach is that
>> codel can now do its work.
>>
>> The algorithm is really (too?) simple:
>> every 5 seconds, starts from a short queue again.
>> If a packet has been in the queue for less than 10ms,
>> allow 10 more MPDUs in.
>> If a packet has been in the queue for more than 20ms,
>> reduce by 10 the size of the transmit queue.
>>
>> The implementation is really naive and way too simple:
>>  * reading jiffies for every Tx / Tx status is not a
>>good idead.
>>  * jiffies are not fine-grained enough on all platforms
>>  * the constants chosen are really arbitrary and can't be
>>tuned.
>>  * This may be implemented in mac80211 probably and help
>>other drivers.
>>  * etc...
>>
>> But already this gives nice results. I ran a very simple
>> experiment: I put the device in a controlled environment
>> and ran traffic while running default sized ping in the
>> background. In this configuration, our device quickly
>> raises its transmission rate to the best rate.
>> Then, I force the device to use the lowest rate (6Mbps).
>> Of course, the throughput collapses, but the ping RTT
>> shoots up.
>> Using codel helps, but the latency is still high. Codel
>> with this patch gives much better results:
>>
>> pfifo_fast:
>> rtt min/avg/max/mdev = 1932.616/2393.284/2833.407/315.941 ms, pipe 3, 
>> ipg/ewma 2215.707/2446.884 ms
>>
>> fq_codel + Tx queue auto-sizing:
>> rtt min/avg/max/mdev = 13.541/32.396/54.791/9.610 ms, ipg/ewma 
>> 200.685/32.202 ms
>>
>> fq_codel without Tx queue auto-sizing:
>> rtt min/avg/max/mdev = 140.821/257.303/331.889/31.074 ms, pipe 2, ipg/ewma 
>> 258.147/252.847 ms
> This is a dramatic improvement. But I'm not sure what you are
> measuring. Is this the 6mbit test? What happens when you send traffic
> the other way (more pure acks, rather than big packets?)

Not tested. I only tested the part that I thought was most interesting:
lots of TCP traffic (charriot) with a very low rate and ping in the
background.

>
> I try to encourage folk to use flent whenever possible, for pretty
> graphs and long term measurements, so you can simultaneously measure
> both throughput and latency.
>
> flent.org's .14 release just shipped.


Ok - I hope I'll get some time to give it a try.

>> Clearly, there is more work to do to be able to merge this,
>> but it seems that the wireless problems mentioned in
>> https://lwn.net/Articles/616241/ may have a solution.
> I gave talks on the problems that wifi had with bufferbloat at the
> ieee 802.11 wg meeting a while back, and more recently it was filmed
> at battlemesh.
>
> https://www.youtube.com/watch?v=Rb-UnHDw02o
>
> I have spent my time since trying to raise sufficient resources
> (testbeds and test tools), orgs, people and money to tackle these
> problems at more depth. We made a bit of progress recently which I can
> talk about offline...
>
> In that talk I suggested that overall we move towards timestamping
> everything, that (at least in the case of the ath9k and mt72) we tie
> together aggregation with a byte based estimator similar to how BQL
> works, and I hoped that eventually - we'd be able to basically - at
> low rates, keep no more than one aggregate in the hardware, one in the
> driver queue, and one being assembled. The pending aggregate would be
> sent to the 

Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

[Grumbach, Emmanuel]

On 02/04/2016 10:46 PM, Ben Greear wrote:
> On 02/04/2016 12:16 PM, Emmanuel Grumbach wrote:
>> As many (all?) WiFi devices, Intel WiFi devices have
>> transmit queues which have 256 transmit descriptors
>> each and each descriptor corresponds to an MPDU.
>> This means that when it is full, the queue contains
>> 256 * ~1500 bytes to be transmitted (if we don't have
>> A-MSDUs). The purpose of those queues is to have enough
>> packets to be ready for transmission so that when the device
>> gets an opportunity to transmit (TxOP), it can take as many
>> packets as the spec allows and aggregate them into one
>> A-MPDU or even several A-MPDUs if we are using bursts.
> I guess this is only really usable if you have exactly one
> peer connected (ie, in station mode)?
>
> Otherwise, you could have one slow peer and one fast one,
> and then I suspect this would not work so well?

Yes. I guess this one (big) limitation. I guess that what would happen
in this case is that the the latency would constantly jitter. But I also
noticed that I could reduce the transmit queue to 130 descriptors
(instead of 256) and still reach maximal throughput because we can
refill the queues quickly enough.
In iwlwifi, we have plans to have one queue for each peer.
This is under development. Not sure when it'll be ready. It also requires
firmware change obviously.

> For reference, ath10k has around 1400 tx descriptors, though
> in practice not all are usable, and in stock firmware, I'm guessing
> the NIC will never be able to actually fill up it's tx descriptors
> and stop traffic.  Instead, it just allows the stack to try to
> TX, then drops the frame...

1400 descriptors, ok... but they are not organised in queues?
(forgive my ignorance of athX drivers)

>
> Thanks,
> Ben
>

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Grumbach, Emmanuel]

[ snip ]

> >>
> >
> > Are you sure that the antenna that reported 0 "recovers" and reports good
> values later?
> 
> In fact it does, but apparently that's not the problem (I've checked with
> monitor device and after seeing zeros during calibration I see packets and
> max rate coming in from AP).
> 
> I've done some more testing and it turns out that original problem of one
> antenna being disabled is caused by power_save parameter being set to
> true. I cannot reproduce the problem with that parameter being set to false.
> 
> I guess firmware turns off some receiving antennas to conserve power and
> reports that stat as zero.
> 
> I see there is some logic to prevent power saving from affecting this
> calibration but it looks like it doesn't work properly when power_save=true
> and unfortunately I could not immediately figure out why.
> 
> Please disregard this patch because original problem is cause by power
> saving, not by firmware issue (at least as far as I could reproduce).
> 
> Sorry for not testing it more thoroughly before sending the patch and thanks
> for kindly reviewing it and providing comments!
> 

No worries, really :)

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH 04/31] iwlwifi: pcie: add initial RTPM support for PCI

[Grumbach, Emmanuel]

On 02/01/2016 04:32 PM, Kalle Valo wrote:
> Emmanuel Grumbach  writes:
>
>> From: Luca Coelho 
>>
>> Add an initial implementation of runtime power management (RTPM) for
>> PCI devices.  With this patch, RTPM is only used when wifi is off
>> (i.e. the wifi interface is down).  This implementation is behind a
>> new Kconfig flag, IWLWIFI_PCIE_RTPM.
>>
>> Signed-off-by: Luca Coelho 
>> Signed-off-by: Emmanuel Grumbach 
> [...]
>
>> --- a/drivers/net/wireless/intel/iwlwifi/Kconfig
>> +++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
>> @@ -99,6 +99,18 @@ config IWLWIFI_UAPSD
>>  
>>If unsure, say N.
>>  
>> +config IWLWIFI_PCIE_RTPM
>> +   bool "Enable runtime power management mode for PCIe devices"
>> +   depends on IWLMVM && IWLWIFI_PCIE && PM
>> +   default false
>> +   help
>> + Say Y here to enable runtime power management for PCIe
>> + devices.  If enabled, the device will go into low power mode
>> + when idle for a short period of time, allowing for improved
>> + power saving during runtime.
>> +
>> + If unsure, say N.
> I didn't see the new option in menuconfig and then noticed that I can't
> find IWLWIFI_PCIE anywhere. Is that correct?
>

Right... This option is not upstreamed yet...
I'll respin. Sorry...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/31] iwlwifi: pcie: add initial RTPM support for PCI

[Grumbach, Emmanuel]

On 02/01/2016 04:38 PM, Grumbach, Emmanuel wrote:
>
> On 02/01/2016 04:32 PM, Kalle Valo wrote:
>> Emmanuel Grumbach <emmanuel.grumb...@intel.com> writes:
>>
>>> From: Luca Coelho <luciano.coe...@intel.com>
>>>
>>> Add an initial implementation of runtime power management (RTPM) for
>>> PCI devices.  With this patch, RTPM is only used when wifi is off
>>> (i.e. the wifi interface is down).  This implementation is behind a
>>> new Kconfig flag, IWLWIFI_PCIE_RTPM.
>>>
>>> Signed-off-by: Luca Coelho <luciano.coe...@intel.com>
>>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
>> [...]
>>
>>> --- a/drivers/net/wireless/intel/iwlwifi/Kconfig
>>> +++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
>>> @@ -99,6 +99,18 @@ config IWLWIFI_UAPSD
>>>  
>>>   If unsure, say N.
>>>  
>>> +config IWLWIFI_PCIE_RTPM
>>> +   bool "Enable runtime power management mode for PCIe devices"
>>> +   depends on IWLMVM && IWLWIFI_PCIE && PM
>>> +   default false
>>> +   help
>>> + Say Y here to enable runtime power management for PCIe
>>> + devices.  If enabled, the device will go into low power mode
>>> + when idle for a short period of time, allowing for improved
>>> + power saving during runtime.
>>> +
>>> +If unsure, say N.
>> I didn't see the new option in menuconfig and then noticed that I can't
>> find IWLWIFI_PCIE anywhere. Is that correct?
>>
> Right... This option is not upstreamed yet...
> I'll respin. Sorry...
>

Next tag: iwlwifi-next-for-kalle-2016-01-31_2

$ git diff
iwlwifi-next-for-kalle-2016-01-31..iwlwifi-next-for-kalle-2016-01-31_2
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig
b/drivers/net/wireless/intel/iwlwifi/Kconfig
index acaaf69..11932d5 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -101,7 +101,7 @@ config IWLWIFI_UAPSD
 
 config IWLWIFI_PCIE_RTPM
bool "Enable runtime power management mode for PCIe devices"
-   depends on IWLMVM && IWLWIFI_PCIE && PM
+   depends on IWLMVM && PM
default false
help
  Say Y here to enable runtime power management for PCIe

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi-next 2016-01-31

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.6. Please pull. Thanks!

The following changes since commit aee3bfa3307cd0da2126bdc0ea359dabea5ee8f7:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next 
(2016-01-12 18:57:02 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2016-01-31

for you to fetch changes up to 01789793426771a0198af6a66f48fbc2474f07ab:

  iwlwifi: mvm: allow to disable beacon filtering for AP/GO interface 
(2016-01-31 12:53:56 +0200)


Here's a first batch of patches for 4.6:
* continue the work on multiple Rx queues (Sara)
* add support for beacon storing
  used in low power states (Sara)
* cleanups (Rodrigo, Johannes)
* fix the LED behavior for iwldvm (Hubert)
* Use the regular firmware image of WoWLAN (Matti)
* fix 8000 devices for Big Endian machines (Johannes)
* more firmware debug hooks (Golan)
* add support for P2P Client snoozing (Avri)
* make the beacon filtering for AP mode configurable (Andrei)
* fix transmit queues overflow with LSO


Andrei Otcheretianski (1):
  iwlwifi: mvm: allow to disable beacon filtering for AP/GO interface

Avri Altman (3):
  iwlwifi: mvm: Add P2P client snoozing
  iwlwifi: mvm: Remove bf_vif from iwl_power_vifs
  iwlwifi: mvm: Remove iwl_mvm_update_beacon_abort

Chaya Rachel Ivgi (1):
  iwlwifi: mvm: add support for negative temperatures

Emmanuel Grumbach (2):
  iwlwifi: pcie: buffer packets to avoid overflowing Tx queues
  iwlwifi: various comments and code cleanups

Golan Ben-Ami (2):
  iwlwifi: mvm: add trigger for firmware dump upon TX response status
  iwlwifi: mvm: make collecting fw debug data optional

Gregory Greenman (1):
  iwlwifi: mvm: rs: fix TPC action decision algorithm

Hubert Tarasiuk (1):
  iwlwifi: dvm: handle zero brightness for wifi LED

Johannes Berg (5):
  iwlwifi: mvm: remove shadowing variable
  iwlwifi: mvm: fix debugfs signedness warning
  iwlwifi: mvm: track low-latency sources separately
  iwlwifi: mvm: support setting minimum quota from debugfs
  iwlwifi: treat iwl_parse_nvm_data() MAC addr as little endian

Luca Coelho (1):
  iwlwifi: pcie: add initial RTPM support for PCI

Luciano Coelho (1):
  iwlwifi: pcie: add RTPM support when wifi is enabled

Matti Gottlieb (1):
  iwlwifi: mvm: Do not switch to D3 image on suspend

Max Stepanov (1):
  iwlwifi: mvm: add debug print if scan config is ignored

Rodrigo Freire (1):
  iwlwifi: Document missing module options

Sara Sharon (10):
  iwlwifi: pcie: add infrastructure for multi-queue rx
  iwlwifi: pcie: add 9000 series multi queue rx DMA support
  iwlwifi: mvm: support beacon storing
  iwlwifi: mvm: change access to ieee80211_hdr
  iwlwifi: mvm: change the check for ADD_STA status
  iwlwifi: mvm: add tlv for multi queue rx support
  iwlwifi: mvm: add new ADD_STA command version
  iwlwifi: mvm: support rss queues configuration command
  iwlwifi: pcie: enable multi-queue rx path
  iwlwifi: pcie: update iwl_mpdu_desc fields

 drivers/net/wireless/intel/iwlwifi/Kconfig |  12 
 drivers/net/wireless/intel/iwlwifi/dvm/led.c   |   5 +-
 drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c  |   4 +-
 drivers/net/wireless/intel/iwlwifi/iwl-9000.c  |   3 +-
 drivers/net/wireless/intel/iwlwifi/iwl-config.h|   2 +
 drivers/net/wireless/intel/iwlwifi/iwl-fh.h|  77 
+
 drivers/net/wireless/intel/iwlwifi/iwl-fw-error-dump.h |   3 +
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h   |  21 ++
 drivers/net/wireless/intel/iwlwifi/iwl-modparams.h |   2 +
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c |   7 +-
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h |   2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-trans.h |  20 --
 drivers/net/wireless/intel/iwlwifi/mvm/constants.h |   8 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c|  73 
++--
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c   |  75 
++--
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c   |  58 ++--
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-d3.h |   1 +
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h |  42 ---
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-sta.h|  69 
++-
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h|  31 +
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c|   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c|  29 
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |  43 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |   4 +-
 

RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Grumbach, Emmanuel]

> 
> 2016-01-27 2:46 GMT-05:00 Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com>:
> >> Hi
> >>
> >> 2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel
> >> <emmanuel.grumb...@intel.com>:
> >> >
> >> >
> >> > On 01/26/2016 12:20 AM, Nikolay Martynov wrote:
> >> >> It looks like sometimes firmware returns zero for chain noise and
> >> >> signal during calibration period. This seems to be a known problem
> >> >> and current implementation accounts for this by ignoring invalid
> >> >> data when all chains return zero signal and noise.
> >> >>
> >> >> The problem is that sometimes firmware returns zero for only one
> >> >> chain for some (not all) beacons used for calibration. This leads
> >> >> to perfectly valid chains be disabled and may cause invalid gain
> settings.
> >> >> For example this is calibration data taken on laptop with Intel
> >> >> 6300 card with all three antennas attached:
> >> >>
> >> >> active_chains: 3
> >> >> chain_noise_a: 312
> >> >> chain_noise_b: 297
> >> >> chain_noise_c: 0
> >> >> chain_signal_a:549
> >> >> chain_signal_b:513
> >> >> chain_signal_c:0
> >> >> beacon_count:  16
> >> >> disconn_array: 0 0 1
> >> >> delta_gain_code:   4 0 0
> >> >> radio_write:   1
> >> >> state: 3
> >> >>
> >> >> This patch changes statistics gathering to make sure that zero
> >> >> noise results are ignored for valid rx chains. The rationale being
> >> >> that even if anntenna is not connected we should be able to see
> >> >> non zero noise if rx chain is present.
> >> >
> >> > But then the firmware will continue to send zero for signal and
> >> > this will impact lots of flows like roaming. If the driver allows
> >> > the firmware to use that antenna, the firmware may use this antenna
> >> > for scanning and roaming will be broken.
> >> > This seems to be a bug in the firmware, but there isn't much I can
> >> > do about it.
> >> > Sorry, I have to NACK this patch.
> >>
> >>   Could you please elaborate on how this patch would affect roaming
> >> or other things. As far as I can see this patch doesn't change much
> >> behavior apart from ignoring invalid values from firmware.
> >> Disconnected antennas still get disabled (as before) connected
> >> antennas still work (more often than before). So I'm not sure I can
> >> see how this patch would change what firmware does at all. I really
> >> hope you could find a moment and explain this.
> >>
> >
> > What you are saying here is that there is a bug in the firmware which
> > makes it report wrong values for one of the antennas. But when you
> > will have this antenna enabled (with your patch), the firmware will
> > keep sending bad signal / noise values for it. If the driver allows
> > the firmware to use this antenna (after your patch), the firmware will
> > choose this antenna to receive beacons or to scan. Then, the driver will
> look at the beacons' rssi (which will be wrong) and it will think that an AP
> which is very close is in fact far away.
> >
> No. That is not correct, I think. What I'm saying is that sometimes (not
> always) firmware is sending 0 (exactly 0) for signal and noise for some (or 
> all)
> chains.
> The case when all chains get 0 seem to be a known problem: it is worked
> around in iwl_find_disconn_antenna. The case when only one chain gets
> zero is not currently handled.
> And just to clarify - all chains are affected by this problem, it's not like 
> one
> specific chain is broken in some way and gets zero. So both of the cards I
> have may be running with 3 chains or with 2 chains depending on how lucky
> I'm during initial scan.
> 
> It's just firmware that has a bug that sometimes returns zero for chain 1,
> sometimes for chain 2, and sometimes for all of them.
> So currently driver is already enabling chains for which we may get zero later
> for rssi (presumably this is true) if it gets non zero during scan for first 
> 16
> beacons.
> Moreover, if it gets non-zero fo

pull request: iwlwifi 2016-01-26

[Grumbach, Emmanuel]

Hi Kalle,

This is the first round of fixes for 4.5.
Most of them are really trivial. The TPC stats one stands out a little bit.
It can fix traffic issues which are typically hard to debug.
Please pull and let me know if you have issues.

I also have a batch of patches for -next, but wireless-drivers-next.git doesn't
seem ready to accept new patches at this stage.

Thanks!

The following changes since commit aee3bfa3307cd0da2126bdc0ea359dabea5ee8f7:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next 
(2016-01-12 18:57:02 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-01-26

for you to fetch changes up to a0d792850af3257d9b4b1dbf4e3df57994a481e7:

  iwlwifi: mvm: rs: fix TPC statistics handling (2016-01-25 14:42:11 +0200)


* Fix support for 3168 device
+ NVM version
+ firmware file name
+ device IDs
* Fix a compilation warning in dvm calibration code
* Fix the TPC (reduced Tx Power) code. This fixes performance issues
* Device IDs for 8265


Gregory Greenman (1):
  iwlwifi: mvm: rs: fix TPC statistics handling

Johannes Berg (1):
  iwlwifi: dvm: calib.c: fix min() warning

Oren Givon (3):
  iwlwifi: add new 3168 series devices support
  iwlwifi: add device ID for 8265
  iwlwifi: update support for 3168 series firmware and NVM

 drivers/net/wireless/intel/iwlwifi/dvm/calib.c |  4 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-7000.c  | 23 +++
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h |  6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 74 
--
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c|  5 +++--
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c  |  4 
 6 files changed, 81 insertions(+), 35 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Grumbach, Emmanuel]

> Hi
> 
> 2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel
> <emmanuel.grumb...@intel.com>:
> >
> >
> > On 01/26/2016 12:20 AM, Nikolay Martynov wrote:
> >> It looks like sometimes firmware returns zero for chain noise and
> >> signal during calibration period. This seems to be a known problem
> >> and current implementation accounts for this by ignoring invalid data
> >> when all chains return zero signal and noise.
> >>
> >> The problem is that sometimes firmware returns zero for only one
> >> chain for some (not all) beacons used for calibration. This leads to
> >> perfectly valid chains be disabled and may cause invalid gain settings.
> >> For example this is calibration data taken on laptop with Intel 6300
> >> card with all three antennas attached:
> >>
> >> active_chains: 3
> >> chain_noise_a: 312
> >> chain_noise_b: 297
> >> chain_noise_c: 0
> >> chain_signal_a:549
> >> chain_signal_b:513
> >> chain_signal_c:0
> >> beacon_count:  16
> >> disconn_array: 0 0 1
> >> delta_gain_code:   4 0 0
> >> radio_write:   1
> >> state: 3
> >>
> >> This patch changes statistics gathering to make sure that zero noise
> >> results are ignored for valid rx chains. The rationale being that
> >> even if anntenna is not connected we should be able to see non zero
> >> noise if rx chain is present.
> >
> > But then the firmware will continue to send zero for signal and this
> > will impact lots of flows like roaming. If the driver allows the
> > firmware to use that antenna, the firmware may use this antenna for
> > scanning and roaming will be broken.
> > This seems to be a bug in the firmware, but there isn't much I can do
> > about it.
> > Sorry, I have to NACK this patch.
> 
>   Could you please elaborate on how this patch would affect roaming or other
> things. As far as I can see this patch doesn't change much behavior apart
> from ignoring invalid values from firmware.
> Disconnected antennas still get disabled (as before) connected antennas still
> work (more often than before). So I'm not sure I can see how this patch
> would change what firmware does at all. I really hope you could find a
> moment and explain this.
> 

What you are saying here is that there is a bug in the firmware which makes it 
report wrong
values for one of the antennas. But when you will have this antenna enabled 
(with your patch),
the firmware will keep sending bad signal / noise values for it. If the driver 
allows the firmware
to use this antenna (after your patch), the firmware will choose this antenna 
to receive beacons
or to scan. Then, the driver will look at the beacons' rssi (which will be 
wrong) and it will think that
an AP which is very close is in fact far away.

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Grumbach, Emmanuel]

On 01/26/2016 12:20 AM, Nikolay Martynov wrote:
> It looks like sometimes firmware returns zero for chain noise and signal
> during calibration period. This seems to be a known problem and current
> implementation accounts for this by ignoring invalid data when all chains
> return zero signal and noise.
>
> The problem is that sometimes firmware returns zero for only one chain for
> some (not all) beacons used for calibration. This leads to perfectly valid
> chains be disabled and may cause invalid gain settings.
> For example this is calibration data taken on laptop with Intel 6300 card
> with all three antennas attached:
>
> active_chains: 3
> chain_noise_a: 312
> chain_noise_b: 297
> chain_noise_c: 0
> chain_signal_a:549
> chain_signal_b:513
> chain_signal_c:0
> beacon_count:  16
> disconn_array: 0 0 1
> delta_gain_code:   4 0 0
> radio_write:   1
> state: 3
>
> This patch changes statistics gathering to make sure that zero noise
> results are ignored for valid rx chains. The rationale being that even if
> anntenna is not connected we should be able to see non zero noise if rx
> chain is present.

But then the firmware will continue to send zero for signal and this
will impact lots
of flows like roaming. If the driver allows the firmware to use that
antenna, the
firmware may use this antenna for scanning and roaming will be broken.
This seems to be a bug in the firmware, but there isn't much I can do
about it.
Sorry, I have to NACK this patch.

> This patch fixes the problem of disabling working chains on hardware I
> have (6300 and 5300). With three connected antennas statistics in
> chain_noise looks like this (6300):
>
> active_chains: 7
> chain_noise_a: 321
> chain_noise_b: 243
> chain_noise_c: 311
> chain_signal_a:559
> chain_signal_b:452
> chain_signal_c:512
> beacon_count:  16
> disconn_array: 0 0 0
> delta_gain_code:   4 3 0
> radio_write:   1
> state: 3
>
> It also works fine in case one 3-chain hardware has only two antennas
> attached (tested in 5300):
>
> active_chains: 3
> chain_noise_a: 238
> chain_noise_b: 234
> chain_noise_c: 219
> chain_signal_a:533
> chain_signal_b:514
> chain_signal_c:206
> beacon_count:  16
> disconn_array: 0 0 1
> delta_gain_code:   4 0 0
> radio_write:   1
> state: 3
>
> Signed-off-by: Nikolay Martynov 
> ---
>  drivers/net/wireless/iwlwifi/dvm/calib.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/wireless/iwlwifi/dvm/calib.c 
> b/drivers/net/wireless/iwlwifi/dvm/calib.c
> index 20e6aa9..cdaa88d 100644
> --- a/drivers/net/wireless/iwlwifi/dvm/calib.c
> +++ b/drivers/net/wireless/iwlwifi/dvm/calib.c
> @@ -1026,6 +1026,18 @@ void iwl_chain_noise_calibration(struct iwl_priv *priv)
>  
>   spin_unlock_bh(>statistics.lock);
>  
> + /* Sometimes firmware returns zero for chain noise and signal
> +  * even if chain is present and antenna is connected. This
> +  * often results in perfectly valid chains being disabled.
> +  * Ignore statistics if it contains zero noise for valid rx
> +  * chain: even with antenna disconnected we should hear some noise.
> +  */
> + if ((priv->nvm_data->valid_rx_ant & ANT_A && chain_noise_a == 0) ||
> + (priv->nvm_data->valid_rx_ant & ANT_B && chain_noise_b == 0) ||
> + (priv->nvm_data->valid_rx_ant & ANT_C && chain_noise_c == 0)) {
> + return;
> + }
> +
>   data->beacon_count++;
>  
>   data->chain_noise_a = (chain_noise_a + data->chain_noise_a);

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi 2016-01-26

[Grumbach, Emmanuel]

Hi Kalle,

On 01/26/2016 03:51 PM, Kalle Valo wrote:
> "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes:
>
>> This is the first round of fixes for 4.5. Most of them are really
>> trivial. The TPC stats one stands out a little bit. It can fix traffic
>> issues which are typically hard to debug. Please pull and let me know
>> if you have issues.
> There's a conflict due to 8f57e4d930d, how should I fix it?
>
> diff --cc drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> index e9cef9de9ed8,14949efc4a35..
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> @@@ -900,8 -900,8 +900,13 @@@ static void iwlagn_gain_computation(str
>   
> /* bound gain by 2 bits value max, 3rd bit is sign */
> data->delta_gain_code[i] =
> ++<<<<<<< HEAD
>  +  min(abs(delta_g),
>  +  (s32) CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
> ++===
> +   min_t(u8, abs(delta_g),
> + CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
> ++>>>>>>> c3653efc57d9b3c51ee657a471578d2493b6e3f0
>   
> if (delta_g < 0)
> /*
>
No, I'll rebase.
thanks.

>> I also have a batch of patches for -next, but
>> wireless-drivers-next.git doesn't seem ready to accept new patches at
>> this stage.
> I'll open wireless-drivers-next once net-next is open, but AFAIK Dave
> hasn't opened it yet.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi 2016-01-26

[Grumbach, Emmanuel]

On 01/26/2016 04:01 PM, Johannes Berg wrote:
>>> There's a conflict due to 8f57e4d930d, how should I fix it?
> I think we can thus drop my patch - that commit fixes the issue that
> Andrew had reported as well, and that I worked around by casting the
> result... now that abs() has a consistent result, using s32 in both
> sides of the min() is perfectly fine.
>
> johannes
>
>

I did just that in my new tag: iwlwifi-for-kalle-2016-01-26_2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iwlwifi: Document missing module options

[Grumbach, Emmanuel]

Hi,


On 01/07/2016 12:24 AM, Rodrigo Freire wrote:
> This patch documents two missing module options in the internal
> code comment block.
>
> Signed-off-by: Rodrigo Freire 
> ---
>  drivers/net/wireless/iwlwifi/iwl-modparams.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-modparams.h 
> b/drivers/net/wireless/iwlwifi/iwl-modparams.h
> index ac2b90d..1477277 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-modparams.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-modparams.h
> @@ -102,6 +102,8 @@ enum iwl_disable_11n {
>   * @power_level: power level, default = 1
>   * @debug_level: levels are IWL_DL_*
>   * @ant_coupling: antenna coupling in dB, default = 0
> + * @nvm_file: specifies a external NVM file
> + * @uapsd_disable: disable U-APSD, default = 1
>   * @d0i3_disable: disable d0i3, default = 1,
>   * @lar_disable: disable LAR (regulatory), default = 0
>   * @fw_monitor: allow to use firmware monitor
Applied in our internal tree. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi-next 2016-01-07

[Grumbach, Emmanuel]

Hi Kalle,

Here is the last round of patches for 4.5. Most of them are small and / or 
fixes.
Let me know if you have issues.
FYI - I scripted a few checks so that I hope that the internal tags that leaked
in the previous pull request won't leak any more.

The following changes since commit e5d15cb530082cc13a6c9457eddd6f75b0f4de65:

  iwlwifi: bail out in case of bad trans state (2015-12-21 19:35:41 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2016-01-07

for you to fetch changes up to ccecff64ac4ee0d2f610e6606d2dfb17a38436f6:

  iwlwifi: pcie: properly configure the debug buffer size for 8000 (2016-01-07 
14:39:58 +0200)


* bug fixes and improvements for firmware debug system (Golan and myself)
* fixes for D0i3 (Eliad)
* prevent muliple stations with the same MAC address
* advertise support for Rx A-MSDU in A-MPDU
* scan related fixes
* support -20.ucode
* fix WoWLAN for iwldvm
* preparations towards multiple Rx queues
* platform power improvements for GO mode when no clients are associated


Ayala Beker (1):
  iwlwifi: mvm: don't ask beacons when P2P GO vif and no assoc sta

David Spinadel (1):
  iwlwifi: mvm: fix extended dwell time

Eliad Peller (1):
  iwlwifi: mvm: initialize gtkdata->mvm correctly

Emmanuel Grumbach (10):
  iwlwifi: dvm: fix WoWLAN
  iwlwifi: mvm: let the firmware choose the antenna for beacons
  iwlwifi: mvm: reset mvm->scan_type when firmware is started
  iwlwifi: set max firmware version of 7265 to 17
  iwlwifi: mvm: bump max API to 20
  iwlwifi: mvm: dump the radio registers when the firmware crashes
  iwlwifi: mvm: remove useless WARN_ON and rely on cfg80211's combination
  iwlwifi: mvm: constify the parameters of a few functions in fw-dbg.c
  iwlwifi: mvm: fix memory leaks in error paths upon fw error dump
  iwlwifi: pcie: properly configure the debug buffer size for 8000

Golan Ben-Ami (1):
  iwlwifi: mvm: add a non-trigger window to fw dbg triggers

Johannes Berg (4):
  iwlwifi: mvm: support A-MSDU in A-MPDU
  iwlwifi: mvm: prevent multiple stations with the same address
  iwlwifi: mvm: check PN for CCMP/GCMP in the driver
  iwlwifi: mvm: check minimum temperature notification length

Matti Gottlieb (1):
  iwlwifi: mvm: change mcc update API

Oren Givon (2):
  iwlwifi: update and fix 7265 series PCI IDs
  iwlwifi: nvm: fix loading default NVM file

 drivers/net/wireless/intel/iwlwifi/dvm/lib.c   |   4 
 drivers/net/wireless/intel/iwlwifi/iwl-7000.c  |   4 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-8000.c  |   2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-9000.c  |   2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-fw-error-dump.h |   2 ++
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h   |  12 +++-
 drivers/net/wireless/intel/iwlwifi/iwl-prph.h  |   6 ++
 drivers/net/wireless/intel/iwlwifi/iwl-trans.h |   4 ++--
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c| 115 
+++
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h|  60 
+---
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c|  62 
--
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.h|  30 
+++---
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c|   1 +
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |  53 
+
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  49 
-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |   9 ++---
 drivers/net/wireless/intel/iwlwifi/mvm/nvm.c   |  55 
+--
 drivers/net/wireless/intel/iwlwifi/mvm/power.c |   2 --
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  | 106 
+-
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c  |  13 +++--
 drivers/net/wireless/intel/iwlwifi/mvm/sta.h   |  12 
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c|   2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c  |   5 +++--
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c|  17 +
 24 files changed, 506 insertions(+), 121 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: pull request: iwlwifi-next 2016-01-07

[Grumbach, Emmanuel]

Me again,

On 01/07/2016 02:46 PM, Grumbach, Emmanuel wrote:
> Hi Kalle,
>
> Here is the last round of patches for 4.5. Most of them are small and / or 
> fixes.
> Let me know if you have issues.
> FYI - I scripted a few checks so that I hope that the internal tags that 
> leaked
> in the previous pull request won't leak any more.
>
> The following changes since commit e5d15cb530082cc13a6c9457eddd6f75b0f4de65:

I had to edit one commit. I re-pushed to the same tag and added another
_2 tag if you prefer to be sure.

>   iwlwifi: bail out in case of bad trans state (2015-12-21 19:35:41 +0200)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2016-01-07
>
> for you to fetch changes up to ccecff64ac4ee0d2f610e6606d2dfb17a38436f6:
>
>   iwlwifi: pcie: properly configure the debug buffer size for 8000 
> (2016-01-07 14:39:58 +0200)
>
> 
> * bug fixes and improvements for firmware debug system (Golan and myself)
> * fixes for D0i3 (Eliad)
> * prevent muliple stations with the same MAC address
> * advertise support for Rx A-MSDU in A-MPDU
> * scan related fixes
> * support -20.ucode
> * fix WoWLAN for iwldvm
> * preparations towards multiple Rx queues
> * platform power improvements for GO mode when no clients are associated
>
> 
> Ayala Beker (1):
>   iwlwifi: mvm: don't ask beacons when P2P GO vif and no assoc sta
>
> David Spinadel (1):
>   iwlwifi: mvm: fix extended dwell time
>
> Eliad Peller (1):
>   iwlwifi: mvm: initialize gtkdata->mvm correctly
>
> Emmanuel Grumbach (10):
>   iwlwifi: dvm: fix WoWLAN
>   iwlwifi: mvm: let the firmware choose the antenna for beacons
>   iwlwifi: mvm: reset mvm->scan_type when firmware is started
>   iwlwifi: set max firmware version of 7265 to 17
>   iwlwifi: mvm: bump max API to 20
>   iwlwifi: mvm: dump the radio registers when the firmware crashes
>   iwlwifi: mvm: remove useless WARN_ON and rely on cfg80211's combination
>   iwlwifi: mvm: constify the parameters of a few functions in fw-dbg.c
>   iwlwifi: mvm: fix memory leaks in error paths upon fw error dump
>   iwlwifi: pcie: properly configure the debug buffer size for 8000
>
> Golan Ben-Ami (1):
>   iwlwifi: mvm: add a non-trigger window to fw dbg triggers
>
> Johannes Berg (4):
>   iwlwifi: mvm: support A-MSDU in A-MPDU
>   iwlwifi: mvm: prevent multiple stations with the same address
>   iwlwifi: mvm: check PN for CCMP/GCMP in the driver
>   iwlwifi: mvm: check minimum temperature notification length
>
> Matti Gottlieb (1):
>   iwlwifi: mvm: change mcc update API
>
> Oren Givon (2):
>   iwlwifi: update and fix 7265 series PCI IDs
>   iwlwifi: nvm: fix loading default NVM file
>
>  drivers/net/wireless/intel/iwlwifi/dvm/lib.c   |   4 
>  drivers/net/wireless/intel/iwlwifi/iwl-7000.c  |   4 ++--
>  drivers/net/wireless/intel/iwlwifi/iwl-8000.c  |   2 +-
>  drivers/net/wireless/intel/iwlwifi/iwl-9000.c  |   2 +-
>  drivers/net/wireless/intel/iwlwifi/iwl-fw-error-dump.h |   2 ++
>  drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h   |  12 +++-
>  drivers/net/wireless/intel/iwlwifi/iwl-prph.h  |   6 ++
>  drivers/net/wireless/intel/iwlwifi/iwl-trans.h |   4 ++--
>  drivers/net/wireless/intel/iwlwifi/mvm/d3.c| 115 
> +++
>  drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h|  60 
> +---
>  drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c|  62 
> --
>  drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.h|  30 
> +++---
>  drivers/net/wireless/intel/iwlwifi/mvm/fw.c|   1 +
>  drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |  53 
> +
>  drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  49 
> -
>  drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |   9 ++---
>  drivers/net/wireless/intel/iwlwifi/mvm/nvm.c   |  55 
> +--
>  drivers/net/wireless/intel/iwlwifi/mvm/power.c |   2 --
>  drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  | 106 
> +

Re: [PATCH RESEND] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd

[Grumbach, Emmanuel]

Hi,


On 12/30/2015 07:15 PM, Nicholas Krause wrote:
> This fixes error handling in the function iwl_pcie_enqueue_hcmd
> by checking if all calls to the function wl_pcie_txq_build_tfd
> have failed by returning a error code and if so jump to the goto
> label out from the cleaning up of acquired resources before


For sure you haven't ran your code otherwise you would have noticed it
break pretty much everything.
Moreover this patch is not based on my -next tree.
Simple rebasing won't fix the obvious issues in your patch though.

> Signed-off-by: Nicholas Krause 
> ---
>  drivers/net/wireless/iwlwifi/pcie/tx.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c 
> b/drivers/net/wireless/iwlwifi/pcie/tx.c
> index 2b86c21..49c8c77 100644
> --- a/drivers/net/wireless/iwlwifi/pcie/tx.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
> @@ -1472,9 +1472,11 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans 
> *trans,
>   /* start the TFD with the scratchbuf */
>   scratch_size = min_t(int, copy_size, IWL_HCMD_SCRATCHBUF_SIZE);
>   memcpy(>scratchbufs[q->write_ptr], _cmd->hdr, scratch_size);
> - iwl_pcie_txq_build_tfd(trans, txq,
> -iwl_pcie_get_scratchbuf_dma(txq, q->write_ptr),
> -scratch_size, true);
> + idx = iwl_pcie_txq_build_tfd(trans, txq,
> +  iwl_pcie_get_scratchbuf_dma(txq, 
> q->write_ptr),
> +  scratch_size, true);
> + if (idx)
> + goto out;
>  
>   /* map first command fragment, if any remains */
>   if (copy_size > scratch_size) {
> @@ -1489,8 +1491,9 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans 
> *trans,
>   goto out;
>   }
>  
> - iwl_pcie_txq_build_tfd(trans, txq, phys_addr,
> -copy_size - scratch_size, false);
> + idx = iwl_pcie_txq_build_tfd(trans, txq, phys_addr, copy_size - 
> scratch_size, false);
> + if (idx)
> + goto out;
>   }
>  
>   /* map the remaining (adjusted) nocopy/dup fragments */
> @@ -1513,7 +1516,9 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans 
> *trans,
>   goto out;
>   }
>  
> - iwl_pcie_txq_build_tfd(trans, txq, phys_addr, cmdlen[i], false);
> + idx = iwl_pcie_txq_build_tfd(trans, txq, phys_addr, cmdlen[i], 
> false);
> + if (idx)
> + goto out;
>   }
>  
>   out_meta->flags = cmd->flags;
> @@ -1830,8 +1835,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct 
> sk_buff *skb,
>   /* The first TB points to the scratchbuf data - min_copy bytes */
>   memcpy(>scratchbufs[q->write_ptr], _cmd->hdr,
>  IWL_HCMD_SCRATCHBUF_SIZE);
> - iwl_pcie_txq_build_tfd(trans, txq, tb0_phys,
> -IWL_HCMD_SCRATCHBUF_SIZE, true);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb0_phys, 
> IWL_HCMD_SCRATCHBUF_SIZE, true))
> + goto out_err;
>  
>   /* there must be data left over for TB1 or this code must be changed */
>   BUILD_BUG_ON(sizeof(struct iwl_tx_cmd) < IWL_HCMD_SCRATCHBUF_SIZE);
> @@ -1841,7 +1846,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct 
> sk_buff *skb,
>   tb1_phys = dma_map_single(trans->dev, tb1_addr, tb1_len, DMA_TO_DEVICE);
>   if (unlikely(dma_mapping_error(trans->dev, tb1_phys)))
>   goto out_err;
> - iwl_pcie_txq_build_tfd(trans, txq, tb1_phys, tb1_len, false);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb1_phys, tb1_len, false))
> + goto out_err;
>  
>   /*
>* Set up TFD's third entry to point directly to remainder
> @@ -1857,7 +1863,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct 
> sk_buff *skb,
>  >tfds[q->write_ptr]);
>   goto out_err;
>   }
> - iwl_pcie_txq_build_tfd(trans, txq, tb2_phys, tb2_len, false);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb2_phys, tb2_len, 
> false))
> + goto out_err;
>   }
>  
>   /* Set up entry for this TFD in Tx byte-count array */

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 44/45] iwlwifi: fix printf specifier

[Grumbach, Emmanuel]

On 12/23/2015 06:08 AM, Joe Perches wrote:
> On Mon, 2015-12-21 at 22:50 +0200, Emmanuel Grumbach wrote:
>> Smatch warned about a bad specifier being used. Fix that.
> I see nothing here other than a signed/unsigned
> issue that shouldn't need fixing.  The conversion
> from hex to decimal may not be useful.

Yes so maybe I could just use the 0x%x specifier since
printk-formats.txt seems to say that 0x%x is good for s32 as well. Seems
that the "02" makes it "unsigned only".
Printing those values in hexadecimal is annoying anyway since we usually
express Tx power in decimal.
Thanks for pointing that out!

>> Signed-off-by: Emmanuel Grumbach 
>> ---
>>  drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c 
>> b/drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c
>> index b395854..c15f5be 100644
>> --- a/drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c
>> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c
>> @@ -454,11 +454,11 @@ static void iwl_eeprom_enhanced_txpower(struct device 
>> *dev,
>>   TXP_CHECK_AND_PRINT(COMMON_TYPE),
>>   txp->flags);
>>  IWL_DEBUG_EEPROM(dev,
>> - "\t\t chain_A: 0x%02x chain_B: 0X%02x chain_C: 
>> 0X%02x\n",
>> + "\t\t chain_A: %d chain_B: %d chain_C: %d\n",
>>   txp->chain_a_max, txp->chain_b_max,
>>   txp->chain_c_max);
>>  IWL_DEBUG_EEPROM(dev,
>> - "\t\t MIMO2: 0x%02x MIMO3: 0x%02x High 
>> 20_on_40: 0x%02x Low 20_on_40: 0x%02x\n",
>> + "\t\t MIMO2: %d MIMO3: %d High 20_on_40: 
>> 0x%02x Low 20_on_40: 0x%02x\n",
>>   txp->mimo2_max, txp->mimo3_max,
>>   ((txp->delta_20_in_40 & 0xf0) >> 4),
>>   (txp->delta_20_in_40 & 0x0f));
>

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi-next-2015-12-21

[Grumbach, Emmanuel]

On 12/21/2015 10:49 PM, Grumbach, Emmanuel wrote:
> Hi Kalle,
>
> here is a pull request for 4.5. I guess there will be one more after that 
> depending on when Linus will open the merge window I guess.
> The diffstat look awful and I have no clue why. It looks as if I had done the 
> whole code reorganisation...
> So we have a pretty large pull request here. We are facing big new things: a 
> new device family with lots of work in the data path and such.
> Details in the tag.
> Let me know if you have issues.
> Note that as I said, I needed to merge Johannes's tree to get the new uAPSD 
> helper I added and I merge iwlwifi-fixes.git to avoid conflicts.

And I forgot: Happy New Year! :)

> The following changes since commit 1b894521e60c1b91db1e8ba1278660e5c89f1b5f:
>
>   mac80211: handle HW ROC expired properly (2015-12-07 11:06:37 +0100)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2015-12-21
>
> for you to fetch changes up to e5d15cb530082cc13a6c9457eddd6f75b0f4de65:
>
>   iwlwifi: bail out in case of bad trans state (2015-12-21 19:35:41 +0200)
>
> 
> * Make scan parameters low latency aware (Avi Stern)
> * Fix in the NL80211_FEATURE_FULL_AP_CLIENT_STATE state case (Ayala)
> * Fix enable injection mode (Chaya Rachel)
> * Various cleanups (Dan / Julia / myself)
> * Allow to stay more time on popular channels (David Spinadel)
> * Bug fixes for D0i3 (Eliad / Luca)
> * Fixes for GO uAPSD (myself)
> * Start of TSO support (myself)
> * Rate control bug fixes (Eyal / Gregory)
> * Start the work on 9000 devices (Johannes / Sara / Oren)
> * Start the work on a new Tx queue allocation model (Liad)
> * Debug infrastructure enhancements (Golan)
>
> 
> Avraham Stern (1):
>   iwlwifi: mvm: configure scheduled scan according to traffic conditions
>
> Ayala Beker (1):
>   iwlwifi: mvm: Change number of associated stations when station becomes 
> associated
>
> Chaya Rachel Ivgi (1):
>   iwlwifi: mvm: Add a station in monitor mode
>
> Dan Carpenter (1):
>   iwlwifi: mvm: remove an extra tab
>
> David Spinadel (1):
>   iwlwifi: mvm: add extended dwell time
>
> Eliad Peller (6):
>   iwlwifi: mvm: cleanup roc te on restart cleanup
>   iwlwifi: mvm: check iwl_mvm_wowlan_config_key_params() return value
>   iwlwifi: avoid d0i3 commands when no/init ucode is loaded
>   iwlwifi: mvm: remove the vif parameter of 
> iwl_mvm_configure_bcast_filter()
>   iwlwifi: update key params on d0i3 entrance/exit
>   iwlwifi: bail out in case of bad trans state
>
> Emmanuel Grumbach (18):
>   iwlwifi: pcie: allow the op_mode to block the tx queues
>   iwlwifi: trans: support a callback for ASYNC commands
>   iwlwifi: block the queues when we send ADD_STA for uAPSD
>   iwlwifi: uninline iwl_trans_send_cmd
>   Merge tag 'mac80211-next-for-davem-2015-12-07' into next
>   iwlwifi: mvm: close the SP if we send fewer frames than expected in SP
>   Merge tag 'iwlwifi-for-kalle-2015-12-16' into next
>   iwlwifi: change the Intel Wireless email address
>   iwlwifi: pcie: allow to pretend to have Tx CSUM for debug
>   iwlwifi: mvm: prepare the code towards TSO implementation
>   iwlwifi: pcie: re-organize code towards TSO
>   iwlwifi: clear ieee80211_tx_info->driver_data in the op_mode
>   iwlwifi: pcie: build an A-MSDU using TSO core
>   iwlwifi: 9000: increase the number of queues
>   iwlwifi: mvm: small update in the firmware API
>   iwlwifi: mvm: dump more registers upon error
>   iwlwifi: remove unused parameter from grab_nic_access
>   iwlwifi: fix printf specifier
>
> Eyal Shapira (1):
>   iwlwifi: mvm: rs: fix a potential out of bounds access
>
> Golan Ben-Ami (2):
>   iwlwifi: expose fw usniffer mode to more utilities
>   iwlwifi: mvm: support description for user triggered fw dbg collection
>
> Gregory Greenman (1):
>   iwlwifi: mvm: add an option to start rs from HT/VHT rates
>
> Johannes Berg (6):
>   iwlwifi: mvm: advertise NETIF_F_SG
>   iwlwifi: dvm: advertise NETIF_F_SG
>   iwlwifi: separate firmware version for 7260 devices
>   iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id
>   iwlwifi: mvm: change iwl_mvm_get_key_sta_id() to return the station
>   iwlwifi: mvm: add 9000 series RX processing
>
> Julia Lawall (1):
>   iwlwifi: dvm: fix compare_const_fl.cocci warnings
>
> Liad Kaufman (1):
>   iwlwifi: m

pull request: iwlwifi-next-2015-12-21

[Grumbach, Emmanuel]

Hi Kalle,

here is a pull request for 4.5. I guess there will be one more after that 
depending on when Linus will open the merge window I guess.
The diffstat look awful and I have no clue why. It looks as if I had done the 
whole code reorganisation...
So we have a pretty large pull request here. We are facing big new things: a 
new device family with lots of work in the data path and such.
Details in the tag.
Let me know if you have issues.
Note that as I said, I needed to merge Johannes's tree to get the new uAPSD 
helper I added and I merge iwlwifi-fixes.git to avoid conflicts.

The following changes since commit 1b894521e60c1b91db1e8ba1278660e5c89f1b5f:

  mac80211: handle HW ROC expired properly (2015-12-07 11:06:37 +0100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2015-12-21

for you to fetch changes up to e5d15cb530082cc13a6c9457eddd6f75b0f4de65:

  iwlwifi: bail out in case of bad trans state (2015-12-21 19:35:41 +0200)


* Make scan parameters low latency aware (Avi Stern)
* Fix in the NL80211_FEATURE_FULL_AP_CLIENT_STATE state case (Ayala)
* Fix enable injection mode (Chaya Rachel)
* Various cleanups (Dan / Julia / myself)
* Allow to stay more time on popular channels (David Spinadel)
* Bug fixes for D0i3 (Eliad / Luca)
* Fixes for GO uAPSD (myself)
* Start of TSO support (myself)
* Rate control bug fixes (Eyal / Gregory)
* Start the work on 9000 devices (Johannes / Sara / Oren)
* Start the work on a new Tx queue allocation model (Liad)
* Debug infrastructure enhancements (Golan)


Avraham Stern (1):
  iwlwifi: mvm: configure scheduled scan according to traffic conditions

Ayala Beker (1):
  iwlwifi: mvm: Change number of associated stations when station becomes 
associated

Chaya Rachel Ivgi (1):
  iwlwifi: mvm: Add a station in monitor mode

Dan Carpenter (1):
  iwlwifi: mvm: remove an extra tab

David Spinadel (1):
  iwlwifi: mvm: add extended dwell time

Eliad Peller (6):
  iwlwifi: mvm: cleanup roc te on restart cleanup
  iwlwifi: mvm: check iwl_mvm_wowlan_config_key_params() return value
  iwlwifi: avoid d0i3 commands when no/init ucode is loaded
  iwlwifi: mvm: remove the vif parameter of iwl_mvm_configure_bcast_filter()
  iwlwifi: update key params on d0i3 entrance/exit
  iwlwifi: bail out in case of bad trans state

Emmanuel Grumbach (18):
  iwlwifi: pcie: allow the op_mode to block the tx queues
  iwlwifi: trans: support a callback for ASYNC commands
  iwlwifi: block the queues when we send ADD_STA for uAPSD
  iwlwifi: uninline iwl_trans_send_cmd
  Merge tag 'mac80211-next-for-davem-2015-12-07' into next
  iwlwifi: mvm: close the SP if we send fewer frames than expected in SP
  Merge tag 'iwlwifi-for-kalle-2015-12-16' into next
  iwlwifi: change the Intel Wireless email address
  iwlwifi: pcie: allow to pretend to have Tx CSUM for debug
  iwlwifi: mvm: prepare the code towards TSO implementation
  iwlwifi: pcie: re-organize code towards TSO
  iwlwifi: clear ieee80211_tx_info->driver_data in the op_mode
  iwlwifi: pcie: build an A-MSDU using TSO core
  iwlwifi: 9000: increase the number of queues
  iwlwifi: mvm: small update in the firmware API
  iwlwifi: mvm: dump more registers upon error
  iwlwifi: remove unused parameter from grab_nic_access
  iwlwifi: fix printf specifier

Eyal Shapira (1):
  iwlwifi: mvm: rs: fix a potential out of bounds access

Golan Ben-Ami (2):
  iwlwifi: expose fw usniffer mode to more utilities
  iwlwifi: mvm: support description for user triggered fw dbg collection

Gregory Greenman (1):
  iwlwifi: mvm: add an option to start rs from HT/VHT rates

Johannes Berg (6):
  iwlwifi: mvm: advertise NETIF_F_SG
  iwlwifi: dvm: advertise NETIF_F_SG
  iwlwifi: separate firmware version for 7260 devices
  iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id
  iwlwifi: mvm: change iwl_mvm_get_key_sta_id() to return the station
  iwlwifi: mvm: add 9000 series RX processing

Julia Lawall (1):
  iwlwifi: dvm: fix compare_const_fl.cocci warnings

Liad Kaufman (1):
  iwlwifi: mvm: set default new STA as non-aggregated

Luca Coelho (3):
  iwlwifi: mvm: don't keep an mvm ref when the interface is down
  iwlwifi: replace d0i3_mode and wowlan_d0i3 with more generic variables
  iwlwifi: mvm: refactor the way fw_key_table is handled

Oren Givon (1):
  iwlwifi: Update PCI IDs for 8000 and 9000 series

Sara Sharon (3):
  iwlwifi: mvm: change protocol offload flows
  iwlwifi: mvm: enable L3 filtering
  iwlwifi: mvm: infrastructure for frame-release message

Sharon Dvir (1):
  iwlwifi: update host command messages to new format

 MAINTAINERS  

RE: [PATCH] mac80211: fix PS-Poll handling

[Grumbach, Emmanuel]

> 
> My commit below broken PS-Poll handling. In case the driver
> has no frames buffered, driver_release_tids will be 0, but
> calling find_highest_prio_tid() with 0 as a parameter is
> not a good idea:
> fls(0) - 1 = -1.
> This bug caused mac80211 to think that frames were buffered
> in the driver which in turn was confused because mac80211
> was asking to release frames that were not reported to
> exist.
> On iwlwifi, this led to the WARNING below:
> 
> WARNING: CPU: 0 PID: 11230 at
> drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1733
> iwl_mvm_sta_modify_sleep_tx_count+0x2af/0x320 [iwlmvm]()
> c0627c60 8800069b7648 81888913 
>  8800069b7688 81089d6a 8800069b7678
> 0001 88003b35abf0 88000698b128 8800069b76d4
> Call Trace:
> [] dump_stack+0x4c/0x65
> [] warn_slowpath_common+0x8a/0xc0
> [] warn_slowpath_null+0x1a/0x20
> [] iwl_mvm_sta_modify_sleep_tx_count+0x2af/0x320
> [iwlmvm]
> [] iwl_mvm_mac_release_buffered_frames+0x31/0x40
> [iwlmvm]
> [] ieee80211_sta_ps_deliver_response+0x6e6/0xd80
> [mac80211]
> [] ieee80211_sta_ps_deliver_poll_response+0x26/0x30
> [mac80211]
> [] ieee80211_rx_handlers+0xa83/0x2900 [mac80211]
> [] ieee80211_prepare_and_rx_handle+0x1ed/0xa70
> [mac80211]
> [] ? sta_info_get_bss+0x5/0x4a0 [mac80211]
> [] ieee80211_rx_napi+0x586/0xcd0 [mac80211]
> [] iwl_mvm_rx_rx_mpdu+0x59e/0xc60 [iwlmvm]
> 
> Fixes: 0ead2510f8ce ("mac80211: allow the driver to send EOSP when
> needed")
> Signed-off-by: Emmanuel Grumbach 
> ---
>  net/mac80211/sta_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index b346544..8ea94d3 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -1563,7 +1563,7 @@ ieee80211_sta_ps_deliver_response(struct
> sta_info *sta,
> 
>   more_data = ieee80211_sta_ps_more_data(sta, ignored_acs,
> reason, driver_release_tids);
> 
> - if (reason == IEEE80211_FRAME_RELEASE_PSPOLL)
> + if (driver_release_tids && reason ==
> IEEE80211_FRAME_RELEASE_PSPOLL)
>   driver_release_tids =
>   BIT(find_highest_prio_tid(driver_release_tids));
> 

Maybe it'd be cleaner to move all this into the else branch a bit lower in the 
code. Don't know. A matter of taste a guess.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: pull request: iwlwifi 2015-12-16

[Grumbach, Emmanuel]

> 
> "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes:
> 
> > This is a pull request with small fixes for 4.4. Note that due to the
> > large number of files being renamed, you need to set merge.renameLimit
> > to a big number to merge wl-drv into wl-drv-next but you probably
> > noticed that already :)
> 
> Actually I don't normally merge wireless-drivers to wireless-drivers-next, 
> that
> happens "automatically" the way I follow net-next. But I'll keep this in mind,
> thanks.
> 
> >   iwlwifi: separate firmware version for 7260 devices
> 
> Was this patch sent for public review? I can't seem to find it.
> 

Just did.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi 2015-12-16

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request with small fixes for 4.4.
Note that due to the large number of files being renamed, you need to
set merge.renameLimit to a big number to merge wl-drv into wl-drv-next
but you probably noticed that already :)

The following changes since commit 9513c5e18a0dc55a1fc9c890715098ba2315830b:

  iwlwifi: mvm: Avoid dereferencing sta if it was already flushed
(2015-11-15 21:18:01 +0200)

are available in the git repository at:

 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2015-12-16

for you to fetch changes up to 4585436091cd812b1165aab71bd4847ea1cb08ec:

  iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id
(2015-12-13 13:38:26 +0200)


* don't load firmware that won't exist for 7260
* fix RCU splat


Johannes Berg (2):
  iwlwifi: separate firmware version for 7260 devices
  iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

 drivers/net/wireless/iwlwifi/iwl-7000.c | 49
+++--
 drivers/net/wireless/iwlwifi/mvm/sta.c  | 15 +--
 2 files changed, 44 insertions(+), 20 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi - L1 Enabled - LTR Enabled loop

[Grumbach, Emmanuel]

On 12/14/2015 01:04 AM, Arend van Spriel wrote:
> On 12/12/2015 12:32 AM, Johannes Berg wrote:
>> On Fri, 2015-12-11 at 15:17 -0800, Luis R. Rodriguez wrote:
>>> I just tried a base config from opensuse, then localmodconfig, then
>>> 'make xenconfig' (which I need) and that worked. I can't debug
>>> further but I think this config might help debug this further:
>>>
>>> http://drvbp1.linux-foundation.org/~mcgrof/tmp/config-iwl-fail.txt
>>>
>>> So -- my new config works, but I have no idea what fixed it, a config
>>> option obviously. Not sure what though.
>>>
>> Can you post the good one too?
> I had the same issue occasionally when coming out of suspend. Running 
> 4.1 vanilla kernel with 3160 device. The issue also occurred more often 
> with particular ucode version. Running iwlwifi-3160-10.ucode now and 
> have not seen the issue pop up since.

This is really weird. I don't see how that could be firmware related.
BTW, -10.ucode is fairly old :) we have -16.ucode out there.
>
> Gr. AvS
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Grumbach, Emmanuel]

On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
> On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
>  wrote:
>> index 7a76ce6..f4a5287 100644
>> --- a/net/mac80211/ht.c
>> +++ b/net/mac80211/ht.c
>> @@ -230,6 +230,11 @@ bool ieee80211_ht_cap_ie_to_sta_ht_cap(struct 
>> ieee80211_sub_if_data *sdata,
>> /* set Rx highest rate */
>> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
>>
>> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_7935;
>> +   else
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_3839;
>> +
>>   apply:
>> changed = memcmp(>sta.ht_cap, _cap, sizeof(ht_cap));
>>
>> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
>> index 92c9843..d2f2ff6 100644
>> --- a/net/mac80211/vht.c
>> +++ b/net/mac80211/vht.c
>> @@ -281,6 +281,24 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct 
>> ieee80211_sub_if_data *sdata,
>> }
>>
>> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
>> +
>> +   /* If HT IE reported 3839 bytes only, stay with that size. */
>> +   if (sta->sta.max_amsdu_len == IEEE80211_MAX_MPDU_LEN_HT_3839)
>> +   return;
>> +
>> +   switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
>> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_11454;
>> +   break;
>> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_7991;
>> +   break;
>> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
>> +   default:
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_3895;
>> +   break;
>> +   }
> Ideally speaking shouldn't we use different variables for HT and VHT
> and depending on
> rate HT/VHT we should aggregate accordingly? of course that will be
> tricky as we dont
> have the rate control info at the time of aggregation. Standard is
> clear about usage of
> independent lengths depending on whether its an VHT/HT PPDU.

Yes - but since it is tricky, I preferred to be on the safe side and
limit VHT amsdus for the very peculiar AP that would decide to have
large A-MSDUs in VHT and small ones in HT (?!).

> If we use the same variable to arrive at max_amsdu_len for both VHT
> and HT, we might
> end up sending 11454 sized MSDU in a HT rate.
>
And since that can't be handled at the time of the A-MSDU building,
leave that to another entity :)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Grumbach, Emmanuel]

On 12/08/2015 06:35 PM, Krishna Chaitanya wrote:
>
>
> On Dec 8, 2015 10:01 PM, "Grumbach, Emmanuel"
> <emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>> wrote:
> >
> >
> >
> > On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
> > > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
> > > <emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>>
> wrote:
> > >> index 7a76ce6..f4a5287 100644
> > >> --- a/net/mac80211/ht.c
> > >> +++ b/net/mac80211/ht.c
> > >> @@ -230,6 +230,11 @@ bool
> ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data *sdata,
> > >> /* set Rx highest rate */
> > >> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
> > >>
> > >> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_HT_7935;
> > >> +   else
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_HT_3839;
> > >> +
> > >>   apply:
> > >> changed = memcmp(>sta.ht_cap, _cap, sizeof(ht_cap));
> > >>
> > >> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> > >> index 92c9843..d2f2ff6 100644
> > >> --- a/net/mac80211/vht.c
> > >> +++ b/net/mac80211/vht.c
> > >> @@ -281,6 +281,24 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct
> ieee80211_sub_if_data *sdata,
> > >> }
> > >>
> > >> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
> > >> +
> > >> +   /* If HT IE reported 3839 bytes only, stay with that size. */
> > >> +   if (sta->sta.max_amsdu_len == IEEE80211_MAX_MPDU_LEN_HT_3839)
> > >> +   return;
> > >> +
> > >> +   switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_VHT_11454;
> > >> +   break;
> > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_VHT_7991;
> > >> +   break;
> > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
> > >> +   default:
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_VHT_3895;
> > >> +   break;
> > >> +   }
> > > Ideally speaking shouldn't we use different variables for HT and VHT
> > > and depending on
> > > rate HT/VHT we should aggregate accordingly? of course that will be
> > > tricky as we dont
> > > have the rate control info at the time of aggregation. Standard is
> > > clear about usage of
> > > independent lengths depending on whether its an VHT/HT PPDU.
> >
> > Yes - but since it is tricky, I preferred to be on the safe side and
> > limit VHT amsdus for the very peculiar AP that would decide to have
> > large A-MSDUs in VHT and small ones in HT (?!).
> Yes but wouldn't it be safer to just use min(ht , vht)? For a good AP
> it shouldn't matter and bad AP it will still work.
>
This is the de-facto what this code does I think.
If the HT limit is 4K, then don't even take the VHT limit into account
and the VHT limit can't be smaller than the HT one in that case.
If the HT limit is 8K, then we can limit it further to 4K in case VHT
has a limit of 4K (which is another weird case), but we can also make it
larger for VHT frames?

So I don't really see the bug here, am I missing something?

> > > If we use the same variable to arrive at max_amsdu_len for both VHT
> > > and HT, we might
> > > end up sending 11454 sized MSDU in a HT rate.
> > >
> > And since that can't be handled at the time of the A-MSDU building,
> > leave that to another entity :)
>

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mac80211: support hw managing reorder logic

[Grumbach, Emmanuel]

On 12/08/2015 07:09 PM, Grumbach, Emmanuel wrote:
> From: Sara Sharon <sara.sha...@intel.com>
>
> Enable driver to manage the reordering logic itself.
> This is needed for example for the iwlwifi driver that
> supports hardware based reordering.
>
> type=feature

Ouch - sorry for that. I guess you'll edit? Or you want me to resend?

> Signed-off-by: Sara Sharon <sara.sha...@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
> ---
>  include/net/mac80211.h  |  6 ++
>  net/mac80211/agg-rx.c   | 24 ++--
>  net/mac80211/debugfs.c  |  1 +
>  net/mac80211/sta_info.h | 21 -
>  4 files changed, 41 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 0fad29c..916c29c 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1943,6 +1943,11 @@ struct ieee80211_txq {
>   *   by just its MAC address; this prevents, for example, the same station
>   *   from connecting to two virtual AP interfaces at the same time.
>   *
> + * @IEEE80211_HW_SUPPORTS_REORDERING_BUFFER: Hardware (or driver) manages the
> + *   reordering buffer internally, guaranteeing mac80211 receives frames in
> + *   order and does not need to manage its own reorder buffer or BA session
> + *   timeout.
> + *
>   * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
>   */
>  enum ieee80211_hw_flags {
> @@ -1979,6 +1984,7 @@ enum ieee80211_hw_flags {
>   IEEE80211_HW_SUPPORTS_AMSDU_IN_AMPDU,
>   IEEE80211_HW_BEACON_TX_STATUS,
>   IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR,
> + IEEE80211_HW_SUPPORTS_REORDERING_BUFFER,
>  
>   /* keep last, obviously */
>   NUM_IEEE80211_HW_FLAGS
> diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
> index ec80db7..2ab5479 100644
> --- a/net/mac80211/agg-rx.c
> +++ b/net/mac80211/agg-rx.c
> @@ -76,10 +76,11 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info 
> *sta, u16 tid,
>   tid_rx = rcu_dereference_protected(sta->ampdu_mlme.tid_rx[tid],
>   lockdep_is_held(>ampdu_mlme.mtx));
>  
> - if (!tid_rx)
> + if (!test_bit(tid, sta->ampdu_mlme.agg_session_valid))
>   return;
>  
>   RCU_INIT_POINTER(sta->ampdu_mlme.tid_rx[tid], NULL);
> + __clear_bit(tid, sta->ampdu_mlme.agg_session_valid);
>  
>   ht_dbg(sta->sdata,
>  "Rx BA session stop requested for %pM tid %u %s reason: %d\n",
> @@ -97,6 +98,13 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, 
> u16 tid,
>   ieee80211_send_delba(sta->sdata, sta->sta.addr,
>tid, WLAN_BACK_RECIPIENT, reason);
>  
> + /*
> +  * return here in case tid_rx is not assigned - which will happen if
> +  * IEEE80211_HW_SUPPORTS_REORDERING_BUFFER is set.
> +  */
> + if (!tid_rx)
> + return;
> +
>   del_timer_sync(_rx->session_timer);
>  
>   /* make sure ieee80211_sta_reorder_release() doesn't re-arm the timer */
> @@ -297,7 +305,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
>   /* examine state machine */
>   mutex_lock(>ampdu_mlme.mtx);
>  
> - if (sta->ampdu_mlme.tid_rx[tid]) {
> + if (test_bit(tid, sta->ampdu_mlme.agg_session_valid)) {
>   ht_dbg_ratelimited(sta->sdata,
>  "unexpected AddBA Req from %pM on tid %u\n",
>  sta->sta.addr, tid);
> @@ -308,6 +316,16 @@ void __ieee80211_start_rx_ba_session(struct sta_info 
> *sta,
>   false);
>   }
>  
> + if (ieee80211_hw_check(>hw, SUPPORTS_REORDERING_BUFFER)) {
> + ret = drv_ampdu_action(local, sta->sdata, );
> + ht_dbg(sta->sdata,
> +"Rx A-MPDU request on %pM tid %d result %d\n",
> +sta->sta.addr, tid, ret);
> + if (!ret)
> + status = WLAN_STATUS_SUCCESS;
> + goto end;
> + }
> +
>   /* prepare A-MPDU MLME for Rx aggregation */
>   tid_agg_rx = kmalloc(sizeof(struct tid_ampdu_rx), GFP_KERNEL);
>   if (!tid_agg_rx)
> @@ -369,6 +387,8 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
>   }
>  
>  end:
> + if (status == WLAN_STATUS_SUCCESS)
> + __set_bit(tid, sta->ampdu_mlme.agg_session_valid);
>   mutex_unlock(>ampdu_mlme.mtx);
>  
>  end_no_lock:
> diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
> index abbdff0..e

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Grumbach, Emmanuel]

On 12/08/2015 09:11 PM, Krishna Chaitanya wrote:
>
>
> On Dec 9, 2015 12:37 AM, "Grumbach, Emmanuel"
> <emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>> wrote:
> >
> >
> >
> > On 12/08/2015 07:49 PM, Krishna Chaitanya wrote:
> > >
> > >
> > > On Dec 8, 2015 10:13 PM, "Grumbach, Emmanuel"
> > > <emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>
> <mailto:emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>>> wrote:
> > > >
> > > >
> > > >
> > > > On 12/08/2015 06:35 PM, Krishna Chaitanya wrote:
> > > > >
> > > > >
> > > > > On Dec 8, 2015 10:01 PM, "Grumbach, Emmanuel"
> > > > > <emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>
> <mailto:emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>>
> > > <mailto:emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>
> > > <mailto:emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>>>> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
> > > > > > > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
> > > > > > > <emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>
> > > <mailto:emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>>
> > > <mailto:emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>
> <mailto:emmanuel.grumb...@intel.com
> <mailto:emmanuel.grumb...@intel.com>>>>
> > > > > wrote:
> > > > > > >> index 7a76ce6..f4a5287 100644
> > > > > > >> --- a/net/mac80211/ht.c
> > > > > > >> +++ b/net/mac80211/ht.c
> > > > > > >> @@ -230,6 +230,11 @@ bool
> > > > > ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data
> *sdata,
> > > > > > >> /* set Rx highest rate */
> > > > > > >> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
> > > > > > >>
> > > > > > >> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_HT_7935;
> > > > > > >> +   else
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_HT_3839;
> > > > > > >> +
> > > > > > >>   apply:
> > > > > > >> changed = memcmp(>sta.ht_cap, _cap,
> > > sizeof(ht_cap));
> > > > > > >>
> > > > > > >> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> > > > > > >> index 92c9843..d2f2ff6 100644
> > > > > > >> --- a/net/mac80211/vht.c
> > > > > > >> +++ b/net/mac80211/vht.c
> > > > > > >> @@ -281,6 +281,24 @@
> ieee80211_vht_cap_ie_to_sta_vht_cap(struct
> > > > > ieee80211_sub_if_data *sdata,
> > > > > > >> }
> > > > > > >>
> > > > > > >> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
> > > > > > >> +
> > > > > > >> +   /* If HT IE reported 3839 bytes only, stay with that
> > > size. */
> > > > > > >> +   if (sta->sta.max_amsdu_len ==
> > > IEEE80211_MAX_MPDU_LEN_HT_3839)
> > > > > > >> +   return;
> > > > > > >> +
> > > > > > >> +   switch (vht_cap->cap &
> IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_VHT_11454;
> > > > > > >> +   break;
> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_VHT_7991;
> > > > > > >> +   break;
> &

Re: [PATCH 24/41] iwlwifi: mvm: move fw-dbg code to separate file

[Grumbach, Emmanuel]

On 12/01/2015 08:53 PM, Kalle Valo wrote:
> Emmanuel Grumbach  writes:
>
>> From: Golan Ben-Ami 
>>
>> The fw debug functionality is big enough to warrant
>> a separate file. Move existing related functions to the new file.
>>
>> Signed-off-by: Golan Ben-Ami 
>> Signed-off-by: Emmanuel Grumbach 
> [...]
>
>>  intc-scripts/publishable-files | 203 ++
> Added by accident?
>
Indeed... Thanks for catching this...
Will re-spin...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html