Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

[Kalle Valo]

Hi Mahesh and Andy,

James Feeney reported that there's a serious regression in bonding
module since v4.12, it doesn't work with wireless drivers anymore as
wireless drivers don't report the link speed via ethtool:

https://bugzilla.kernel.org/show_bug.cgi?id=196547

In the bug report it's said that this commit is the culprit:

3f3c278c94dd bonding: fix active-backup transition

Is there a fix for this or should that commit be reverted? This seems to
be a serious regression as there are multiple reports already and we
should get it fixed for v4.13, and the fix backported to v4.12 stable
release.

-- 
Kalle Valo

Re: wireless drivers fail to report link speed?

[Kalle Valo]

(Please don't drop me from CC)

James Feeney  writes:

> @ Kalle Valo
>
>> Have you reported this on netdev (CCing linux-wireless, David Miller and
>> the patch authors)? I think the offending bonding patch should be
>> reverted but first it needs to be properly reported on the mailing list.
>> Most people don't really follow bugzilla.
>
> I have not. I first contacted David Miller and the patch authors
> personally, to see what sort of tact they might want to take. They
> have been notified. There has been no response from anyone except
> Andy. I can only make-up stories, based upon no information, about why
> they are ignoring this issue.

Contacting people privately is not a good idea as most people just
ignore them, me included. So this is not a surprise for me.

> I have been following an ever-expanding sequence of suggestions about
> where to discuss this issue - privately, Arch Linux, kernel bugzilla,
> linux-wireless - and now, netdev. 

Also bugzilla.kernel.org is not really actively followed by all
maintainers, so the best approach is to report the issue via
corresponding mailing lists and CC the developers and maintainters.

> I may do that next, but then, there
> may be so many different forums where this topic is being introduced,
> that no one anywhere will want to track it at all, or participate.

Let's not wait any longer, I'll report this forward. v4.13 release is
getting close and if we want to get this fixed for that release we have
to be quick.

> Really, who's responsibility is it, and who should have the authority, 
> deciding
> what functionality wireless drivers "must" provide for functionality like
> "wireless bonding"?

The MAINTAINERS documents the responsibility. Usually the best approach
is to connect patch authors and CC mailing lists and maintainers
involved.

For bonding it's:

BONDING DRIVER
M:  Jay Vosburgh 
M:  Veaceslav Falico 
M:  Andy Gospodarek 
L:  net...@vger.kernel.org
W:  http://sourceforge.net/projects/bonding/
S:  Supported
F:  drivers/net/bonding/
F:  include/uapi/linux/if_bonding.h

And for wireless:

CFG80211 and NL80211
M:  Johannes Berg 
L:  linux-wireless@vger.kernel.org
W:  http://wireless.kernel.org/
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S:  Maintained
F:  include/uapi/linux/nl80211.h
F:  include/net/cfg80211.h
F:  net/wireless/*
X:  net/wireless/wext*

MAC80211
M:  Johannes Berg 
L:  linux-wireless@vger.kernel.org
W:  http://wireless.kernel.org/
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S:  Maintained
F:  Documentation/networking/mac80211-injection.txt
F:  include/net/mac80211.h
F:  net/mac80211/
F:  drivers/net/wireless/mac80211_hwsim.[ch]


NETWORKING DRIVERS (WIRELESS)
M:  Kalle Valo 
L:  linux-wireless@vger.kernel.org
Q:  http://patchwork.kernel.org/project/linux-wireless/list/
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
S:  Maintained
F:  Documentation/devicetree/bindings/net/wireless/
F:  drivers/net/wireless/

-- 
Kalle Valo

Re: wireless drivers fail to report link speed?

[James Feeney]

Hey Dan

On 08/09/2017 12:25 PM, Dan Williams wrote:
> The relevant questions, in my view, are:
> 
> 1) why does the bonding driver now require this information?

Well, it *always* required the information.  Just now, Mahesh has finally
decided "up with this I will not put", not being able to get the information 
needed.

Please see Mahesh's first patch:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=c4adfc822bf5d8e97660b6114b5a8892530ce8cb



bonding: make speed, duplex setting consistent with link state

bond_update_speed_duplex() retrieves speed and duplex settings. There
is a possibility of failure in retrieving these values but caller has
to assume it's always successful. This leads to having inconsistent
slave link settings. If these (speed, duplex) values cannot be
retrieved, then keeping the link UP causes problems.

The updated bond_update_speed_duplex() returns 0 on success if it
retrieves sane values for speed and duplex. On failure it returns 1
and marks the link down.

Signed-off-by: Mahesh Bandewar 
Signed-off-by: David S. Miller 



Mahesh does not explain what these specific "problems" might be, though.

Generally, the bonding module has to be able to dynamically prioritize, enable,
and disable different network interfaces, as network circumstances change.  It
constantly monitors link speeds and connectivity, comparing links and
reconfiguring interfaces.


> 2) is this information reasonable to request from WiFi drivers?
>
> 3) how would this information affect the operation of the bonding
> driver if it doesn't mean the same thing as it means for wired devices?

I don't know that that dialog, between bonding module and wireless, have ever
happened, until now, since there just was never any link information returned
from the wireless drivers.

You might want to look through "linux/Documentation/networking/bonding.txt".

I do know that the Bonding Driver Option "primary_reselect=better" does not work
with a wireless interface - because the bonding module does not receive the
wireless link speed.  That's not the bonding module's fault, it turns out.

But then, with no information, the bonding module would be forced to "punt".
For instance, it is not correct to simply assume that a wired connection is
always faster than a wireless connection, though that assumption might be needed
as a fall-back with older non-reporting wireless drivers.

> Again, there is a problem that should be solved.  I am only advocating
> that instead of simply adding ethtool get_settings support to WiFi
> drivers and washing our hands of it, which may have unintended
> consequences, we gather all the information first, and discuss whether
> the bonding driver may need to adjust its expectations before this kind
> of change is made.

Yes, please.


James

[PATCH 1/2] cfg80211: enable setting cqm config for AP mode

[Pradeep Kumar Chitrapu]

Enable connection monitoring for AP mode which makes it possible to track
signal strength of connected stations.

Signed-off-by: Pradeep Kumar Chitrapu 
---
 net/wireless/nl80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index bafab07530d6..beda9c62f74a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -9784,7 +9784,8 @@ static int nl80211_set_cqm_rssi(struct genl_info *info,
}
 
if (wdev->iftype != NL80211_IFTYPE_STATION &&
-   wdev->iftype != NL80211_IFTYPE_P2P_CLIENT)
+   wdev->iftype != NL80211_IFTYPE_P2P_CLIENT &&
+   wdev->iftype != NL80211_IFTYPE_AP)
return -EOPNOTSUPP;
 
wdev_lock(wdev);
-- 
1.9.1

[PATCH 2/2] mac80211: enable setting cqm config for AP mode

[Pradeep Kumar Chitrapu]

Enable connection monitoring for AP mode which makes it possible to track
signal strength of connected stations.

Signed-off-by: Pradeep Kumar Chitrapu 
---
 net/mac80211/cfg.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a354f1939e49..1548fd34961c 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2682,9 +2682,11 @@ static int ieee80211_set_cqm_rssi_config(struct wiphy 
*wiphy,
bss_conf->cqm_rssi_high = 0;
sdata->u.mgd.last_cqm_event_signal = 0;
 
-   /* tell the driver upon association, unless already associated */
-   if (sdata->u.mgd.associated &&
-   sdata->vif.driver_flags & IEEE80211_VIF_SUPPORTS_CQM_RSSI)
+   /* if STA, tell the driver upon association, unless already associated.
+* if AP, always tell the driver.
+*/
+   if ((sdata->u.mgd.associated || vif->type == NL80211_IFTYPE_AP) &&
+   (sdata->vif.driver_flags & IEEE80211_VIF_SUPPORTS_CQM_RSSI))
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_CQM);
 
return 0;
@@ -2708,7 +2710,7 @@ static int ieee80211_set_cqm_rssi_range_config(struct 
wiphy *wiphy,
sdata->u.mgd.last_cqm_event_signal = 0;
 
/* tell the driver upon association, unless already associated */
-   if (sdata->u.mgd.associated &&
+   if ((sdata->u.mgd.associated  || vif->type == NL80211_IFTYPE_AP) &&
sdata->vif.driver_flags & IEEE80211_VIF_SUPPORTS_CQM_RSSI)
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_CQM);
 
-- 
1.9.1

Re: [v6] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Reizer, Eyal  [170809 10:40]:
> Hi Tony,
> 
> Sorry for top posting (mobile...)
> I have verified with system design and the data sheet that every wilink 6/7 
> chip has a mac address in fuse so probably the board you have (pretty old, 
> right?) has this mac address in fuse. Maybe it was from very early batches? 
> Anyway I see no reason to change it.
> Anyway the calibrator can be used to store a different one into the nvs file 
> that will overide it.

Well clearly at least this one does not have any valid hardware
mac address, the hardware mac address is broken with all zeroes.

It seems that you can easily add a check for empty mac address, no?
And you already showed a version that falls back to a random mac
address.

The fact that is old does not change a thing, we still need to
support it no matter what the data sheet and your system design
says. A fix that breaks other things is not really a fix :)

> I have verified using a couple of com6 modules with an am335x-evm and they 
> had mac addresses read ok.

Sounds like there are multiple variants of the wl12xx
available then.

Regards,

Tony

Re: [PATCH v2 02/20] ath6kl: constify usb_device_id

[Steve deRosier]

On Wed, Aug 9, 2017 at 9:23 AM, Arvind Yadav  wrote:
> usb_device_id are not supposed to change at runtime. All functions
> working with usb_device_id provided by  work with
> const usb_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav 
> ---
> changes in v2:
>   Re-submitting wireless separately.
>
>  drivers/net/wireless/ath/ath6kl/usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c 
> b/drivers/net/wireless/ath/ath6kl/usb.c
> index 9da3594..4defb7a 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1201,7 +1201,7 @@ static int ath6kl_usb_pm_resume(struct usb_interface 
> *interface)
>  #endif
>
>  /* table of devices that work with this driver */
> -static struct usb_device_id ath6kl_usb_ids[] = {
> +static const struct usb_device_id ath6kl_usb_ids[] = {
> {USB_DEVICE(0x0cf3, 0x9375)},
> {USB_DEVICE(0x0cf3, 0x9374)},
> { /* Terminating entry */ },
> --
> 2.7.4
>

Looks good. Also builds and works properly.

Reviewed-by: Steve deRosier 
Tested-by: Steve deRosier 

- Steve

Re: Problem with the wifi

[Arend van Spriel]

On 09-08-17 18:40, Larry Finger wrote:

On 08/08/2017 04:10 AM, Arend van Spriel wrote:

+ linux-wireless
+ Larry

please keep linux-wireless in this thread.

On 08-08-17 08:21, Paolo Bettini wrote:

Arend van Spriel ha scritto:

+ linux-wireless On 07-08-17 21:38, Paolo Bettini wrote:

Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One
problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6
linux id or Broadcom AP6212 for windowsi installed deb package
firmware-brcm80211 and nvram sdio txt in /lib/firmware/brcm, reloaded
bcrmfmac module but nothing the card seems invisible or dead i don't
know if is a problem of firmware or my system cannot detect the sdio
card ...do you know something about this problematic ?

As always a kernel log could help or output from dmesg command. Also
can you run following commands: $ ls /sys/bus/sdio/devices $ cat
/sys/bus/sdio/devices/*/modalias Regards, Arend

paolo@paolo:~$ ls /sys/bus/sdio/devices
mmc1:0001:1
paolo@paolo:~$


paolo@paolo:~$ cat /sys/bus/sdio/devices/*/modalias sdio:c07v024CdB723
paolo@paolo:~$ sorry for previous mail ls was from another pc:-[
it seems the system see only the card where the system is installed


Hi Paolo,

Interesting. Now if Google search is correct the vendor id for this
device indicates this is a Realtek (v024C) WLAN (c07) device. So what
makes you say its linux id is 02d0:a9a6?

In upstream linux I do not see any SDIO device drivers in realtek
folder. Maybe Larry can provide clue/hint if a driver for this device is
publicly available somewhere.


Paolo,

The only Realtek SDIO device in common distribution is the RTL8723BS, 
which has been packaged with some Intel processors, and may now be part 
of other SBC's. This driver has been in staging since V4.12. It handles 
SDIO Vendor code 0x024c with device codes 0x0523, 0x0623, 0x0626, and 
0xb723. If your device is one of these, then you only need to build a 
kernel with this driver enabled.


He has device id 0xb723:

paolo@paolo:~$ cat /sys/bus/sdio/devices/*/modalias sdio:c07v024CdB723

So that driver should at least try to probe his device.

Regards,
Arend

Re: pull-request: iwlwifi 2017-08-09

[Kalle Valo]

Luca Coelho  writes:

> Here is the third set of fixes for 4.13.  More details in the tag
> description.
>
> This includes both series I sent out, the first one, with v2 of the
> second patch, with an improved commit message, and the second one, which
> contains the mac80211 patch as well.
>
> I have sent this out before and kbuildbot didn't find any issues. 
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 368bd88ebb64cabe4a1ec727659214bb8d693707:
>
>   Merge tag 'iwlwifi-for-kalle-2017-08-02' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes 
> (2017-08-03 11:01:11 +0300)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
> tags/iwlwifi-for-kalle-2018-08-09
>
> for you to fetch changes up to 20fc690f38d17b8f961101a477a9aa0841fb6e20:
>
>   iwlwifi: mvm: send delba upon rx ba session timeout (2017-08-09 10:05:01 
> +0300)
>
> 
> Some more fixes for 4.13
>
> * Fix a memory leak in the SAR code;
> * Fix a stuck queue case in AP mode;
> * Convert a WARN to a simple debug in a legitimate race case (from
>   which we can recover);
> * Fix a severe throughput aggregation on 9000-family devices due to
>   aggregation issues.
>
> 

Pulled, thanks.

-- 
Kalle Valo

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Wed, 2017-08-09 at 11:01 -0600, James Feeney wrote:
> @ Dan Williams
> 
> > I'm not really arguing against updating mac80211 to report this
> > information if somebody actually wants to do the patch.  I'm only
> > saying that even with the patch, it's not going to do exactly what
> > you
> > want it to do, and even if it works for you 90% of the time, it's
> > not
> > going to work for others that much of the time, and thus it gives a
> > false sense of "correctness" which is just wrong.
> 
> Hey - don't put this on me!  This is not about "what I want it to
> do".  I'm only

I had a whole email written out, but it wasn't very constructive.

To be clear: I am not putting anything on you, or blaming you for
anything :)  Sorry if my tone implied that to you.  I feel like the
tone of this thread is becoming contentious and that's not my desire.

There is clearly a problem.  That problem was exposed by a patch to the
bonding driver that newly requires information that the WiFi drivers
don't provide.

The relevant questions, in my view, are:

1) why does the bonding driver now require this information?

2) is this information reasonable to request from WiFi drivers?

3) how would this information affect the operation of the bonding
driver if it doesn't mean the same thing as it means for wired devices?

My answers are:

1) I have no idea, though to continue being constructive to this
discussion, I should probably go find out.  We should also get the
bonding module patch authors to weigh in.  But the core point is that
it used to work, and now it doesn't work, and the WiFi drivers have not
changed in this area.

2) ethtool's API doesn't say much about semantics.  It is likely
reasonable to request this information from WiFi drivers, but
unfortunately WiFi has some different semantics for the information
than ethernet devices do.

3) The bonding module is interpreting the speed in a certain way that
can hugely affect its operation, and ethernet devices don't change
speed very frequently.  But wifi devices do.  This may well cause
unexpected operation from bonding, and we should be well aware of that
before we do anything to fix this problem.

I'd also like to point out the various virtual devices (veth, virtio,
etc) and how they report speed.  They lock the speed to a certain
value, but that doesn't actually mean anything because they are not
hardware based and their throughput is more a function of current CPU
load rather than actual wire speed.  The 'tun' driver locks the rate to
10Mb/s with no capability to change.  These are another case of
mismatch in expectations between bonding and reported speeds.

Again, there is a problem that should be solved.  I am only advocating
that instead of simply adding ethtool get_settings support to WiFi
drivers and washing our hands of it, which may have unintended
consequences, we gather all the information first, and discuss whether
the bonding driver may need to adjust its expectations before this kind
of change is made.

Dan

> trying to make my wireless bonding work again.  But I also don't want
> to simply
> "slap down" Mahesh, by only reverting his patch, which addressed
> another, real,
> problem.  This needs to be a cooperative effort.  How do *we all*
> address the
> problem that Mahesh was trying to resolve, and, at the same time,
> continue to
> support wireless bonding?  Please, don't just "kick the can down the
> road".  It
> seems to me that Mahesh must have been pretty upset about the
> wireless drivers
> not reporting speed, to have written a patch that just disables the
> wireless
> interface when the reporting fails.  Think about it.
> 
> If there is a long-standing screw-up with the wireless drivers
> failing to
> properly support 'section 11.46 ("Estimated throughput") of
> IEEE802.11-2016',
> then let's start-off by admitting that.  *Then* everyone can argue
> about what to
> do about it.  And, if that's not the underlying problem, let's make
> that
> determination.  I'm just trying to find a way forward.
> 
> > No, it's not a fault of ethtool.  Ethtool only reports something,
> > it's
> > up to the thing that interprets that data (eg, bonding) to do the
> > right
> > thing with it.
> 
> It has not yet been established that there is anything - "Estimated
> throughput"
> - being provided universally by the wireless drivers for the kernel
> ethtool to
> report.  So, you cannot blame this immediately upon "the thing that
> interprets
> the data (eg, bonding)", when there *is no data* to interpret.  That
> was the
> original question and issue.  There first *has* to be some data to
> interpret!
> 
> I will say that it is no more appropriate that the wireless drivers
> generate a
> "piss-off" error on a get_settings() request than that the bonding
> module
> respond with a "screw-you", disabling the wireless interface when it
> returns
> that error.  This has turned into some kind of nasty lovers
> quarrel.  Or like a
> couple of children having temper 

[PATCH v3 12/19] iwlwifi: mvm: support new beacon template command

[Luca Coelho]

From: Haim Dreyfuss 

Support a new version of the beacon template command. This replaces v8
of the command, which was missing the rate code.  Also, export rate
decision logic to a separate function.

Signed-off-by: Haim Dreyfuss 
Signed-off-by: Luca Coelho 
---

In v3:
   * fix a bug in the CCK flag check

drivers/net/wireless/intel/iwlwifi/fw/api/tx.h| 17 +---
 drivers/net/wireless/intel/iwlwifi/fw/file.h  |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 47 ---
 3 files changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h 
b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
index 2909d1ed89cf..4928310ddd31 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
@@ -786,13 +786,20 @@ struct iwl_mac_beacon_cmd_v7 {
struct ieee80211_hdr frame[0];
 } __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_7 */
 
+enum iwl_mac_beacon_flags {
+   IWL_MAC_BEACON_CCK  = BIT(8),
+   IWL_MAC_BEACON_ANT_A= BIT(9),
+   IWL_MAC_BEACON_ANT_B= BIT(10),
+   IWL_MAC_BEACON_ANT_C= BIT(11),
+};
+
 /**
  * struct iwl_mac_beacon_cmd - beacon template command with offloaded CSA
- * @byte_cnt: byte count of the beacon frame
- * @flags: for future use
+ * @byte_cnt: byte count of the beacon frame.
+ * @flags: least significant byte for rate code. The most significant byte
+ * is  iwl_mac_beacon_flags.
  * @reserved: reserved
- * @template_id: currently equal to the mac context id of the coresponding
- *  mac.
+ * @template_id: currently equal to the mac context id of the coresponding mac.
  * @tim_idx: the offset of the tim IE in the beacon
  * @tim_size: the length of the tim IE
  * @ecsa_offset: offset to the ECSA IE if present
@@ -809,7 +816,7 @@ struct iwl_mac_beacon_cmd {
__le32 ecsa_offset;
__le32 csa_offset;
struct ieee80211_hdr frame[0];
-} __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_8 */
+} __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_9 */
 
 struct iwl_beacon_notif {
struct iwl_mvm_tx_resp beacon_notify_hdr;
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h 
b/drivers/net/wireless/intel/iwlwifi/fw/file.h
index 0fa8c473f1e2..d933aa324ffe 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
@@ -260,6 +260,7 @@ enum iwl_ucode_tlv_api {
IWL_UCODE_TLV_API_STA_TYPE  = (__force 
iwl_ucode_tlv_api_t)30,
IWL_UCODE_TLV_API_NAN2_VER2 = (__force 
iwl_ucode_tlv_api_t)31,
/* API Set 1 */
+   IWL_UCODE_TLV_API_NEW_BEACON_TEMPLATE   = (__force 
iwl_ucode_tlv_api_t)34,
IWL_UCODE_TLV_API_NEW_RX_STATS  = (__force 
iwl_ucode_tlv_api_t)35,
 
NUM_IWL_UCODE_TLV_API
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index 8fe955d58c6e..a2bf530eeae4 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -923,6 +923,19 @@ static u32 iwl_mvm_find_ie_offset(u8 *beacon, u8 eid, u32 
frame_size)
return ie - beacon;
 }
 
+static u8 iwl_mvm_mac_ctxt_get_lowest_rate(struct ieee80211_tx_info *info,
+  struct ieee80211_vif *vif)
+{
+   u8 rate;
+
+   if (info->band == NL80211_BAND_5GHZ || vif->p2p)
+   rate = IWL_FIRST_OFDM_RATE;
+   else
+   rate = IWL_FIRST_CCK_RATE;
+
+   return rate;
+}
+
 static void iwl_mvm_mac_ctxt_set_tx(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
struct sk_buff *beacon,
@@ -930,7 +943,8 @@ static void iwl_mvm_mac_ctxt_set_tx(struct iwl_mvm *mvm,
 {
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
struct ieee80211_tx_info *info;
-   u32 rate, tx_flags;
+   u8 rate;
+   u32 tx_flags;
 
info = IEEE80211_SKB_CB(beacon);
 
@@ -955,14 +969,12 @@ static void iwl_mvm_mac_ctxt_set_tx(struct iwl_mvm *mvm,
cpu_to_le32(BIT(mvm->mgmt_last_antenna_idx) <<
RATE_MCS_ANT_POS);
 
-   if (info->band == NL80211_BAND_5GHZ || vif->p2p) {
-   rate = IWL_FIRST_OFDM_RATE;
-   } else {
-   rate = IWL_FIRST_CCK_RATE;
-   tx->rate_n_flags |= cpu_to_le32(RATE_MCS_CCK_MSK);
-   }
+   rate = iwl_mvm_mac_ctxt_get_lowest_rate(info, vif);
 
tx->rate_n_flags |= cpu_to_le32(iwl_mvm_mac80211_idx_to_hwrate(rate));
+   if (rate == IWL_FIRST_CCK_RATE)
+   tx->rate_n_flags |= cpu_to_le32(RATE_MCS_CCK_MSK);
+
 }
 
 static int iwl_mvm_mac_ctxt_send_beacon_cmd(struct iwl_mvm *mvm,
@@ -1033,19 +1045,27 @@ static int iwl_mvm_mac_ctxt_send_beacon_v7(struct 
iwl_mvm *mvm,
   

[PATCH] NFC: nfcmrvl: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/nfc/nfcmrvl/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nfc/nfcmrvl/usb.c b/drivers/nfc/nfcmrvl/usb.c
index bd35eab..46e11fc 100644
--- a/drivers/nfc/nfcmrvl/usb.c
+++ b/drivers/nfc/nfcmrvl/usb.c
@@ -23,7 +23,7 @@
 #include 
 #include "nfcmrvl.h"
 
-static struct usb_device_id nfcmrvl_table[] = {
+static const struct usb_device_id nfcmrvl_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x1286, 0x2046,
USB_CLASS_VENDOR_SPEC, 4, 1) },
{ } /* Terminating entry */
-- 
2.7.4

Re: [v6] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Tony Lindgren  [170809 10:26]:
> * Reizer, Eyal  [170809 00:55]:
> > --- a/drivers/net/wireless/ti/wlcore/main.c
> > +++ b/drivers/net/wireless/ti/wlcore/main.c
> > @@ -6040,6 +6040,21 @@ static int wl1271_register_hw(struct wl1271 *wl)
> > nic_addr = wl->fuse_nic_addr + 1;
> > }
> >  
> > +   if (oui_addr == 0xdeadbe && nic_addr == 0xef) {
> > +   wl1271_warning("Detected unconfigured mac address in nvs.\n"
> > +   "derive from fuse instead.\n"
> > +   "in case of using a wl12xx device, your "
> > +   "device performance may not be optimized.\n"
> > +   "Please use the calibrator tool to configure "
> > +   "your device.\n"
> > +   "When using a wl18xx device this default nvs "
> > +   "file can be removed from the file system\n");
> > +
> > +   oui_addr = wl->fuse_oui_addr;
> > +   /* fuse has the BD_ADDR, the WLAN addresses are the next two */
> > +   nic_addr = wl->fuse_nic_addr + 1;
> > +   }
> > +
> > wl12xx_derive_mac_addresses(wl, oui_addr, nic_addr);
> 
> I just gave this a quick try on omap3-evm with wl1271, now I get
> mac address of 00:00:00:00:00:01 :) So looks like at least wl1271 needs
> to use the random mac address here.
> 
> Note that we should now have struct wilink_family_data available
> so maybe that can be used to check if the hardware mac address
> exists?

Or actually, in the case where no hardawre mac address exists,
the mac is all zeroes at this point it seems. So maybe that
can be used to determine if a random mac address should be used
here.

Regards,

Tony

Re: [v6] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Reizer, Eyal  [170809 00:55]:
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -6040,6 +6040,21 @@ static int wl1271_register_hw(struct wl1271 *wl)
>   nic_addr = wl->fuse_nic_addr + 1;
>   }
>  
> + if (oui_addr == 0xdeadbe && nic_addr == 0xef) {
> + wl1271_warning("Detected unconfigured mac address in nvs.\n"
> + "derive from fuse instead.\n"
> + "in case of using a wl12xx device, your "
> + "device performance may not be optimized.\n"
> + "Please use the calibrator tool to configure "
> + "your device.\n"
> + "When using a wl18xx device this default nvs "
> + "file can be removed from the file system\n");
> +
> + oui_addr = wl->fuse_oui_addr;
> + /* fuse has the BD_ADDR, the WLAN addresses are the next two */
> + nic_addr = wl->fuse_nic_addr + 1;
> + }
> +
>   wl12xx_derive_mac_addresses(wl, oui_addr, nic_addr);

I just gave this a quick try on omap3-evm with wl1271, now I get
mac address of 00:00:00:00:00:01 :) So looks like at least wl1271 needs
to use the random mac address here.

Note that we should now have struct wilink_family_data available
so maybe that can be used to check if the hardware mac address
exists?

Regards,

Tony

Re: wireless drivers fail to report link speed?

[James Feeney]

On 08/09/2017 03:30 AM, Arend van Spriel wrote:
>> That seems a little over-broad, at least certainly with respect to "half
>> duplex".  If the link is known to be half duplex, then the kernel ethtool can
>> simply report that the link is "half duplex".  I am not hearing a good
>> justification, or a necessity, for the kernel ethtool to return an error,
>> instead.> > There is nothing "over-board" about it. Whhy asking a question if
you already> know the answer.
Sorry - I do not understand to what "answer" you are referring.  Are you saying
that the kernel ethtool should *not* return an error?  Or are you saying that
the kernel ethtool *should* return an error, because the "wifi duplex" is
*always* half duplex?  Or are you referring to something else?  The kernel
ethtool functions need to work with *all* network interface types, wired,
wireless, and virtual.

Or, are you saying that the bonding module should not be using the kernel
ethtool functions?

> Actually what the bonding module could rely on would be what is described in
> section 11.46 ("Estimated throughput") of IEEE802.11-2016 as it seems to 
> address
> exactly the bonding use-case. However, I am not aware of any devices in the
> field carrying that feature (but I am not all knowing ;-) ).

Ah!  That sounds like a useful focus.

I would like to discover a consensus among the wireless driver community about
what the "correct" resolution would be, with respect to the bonding module's
need to determine the link speed of an interface.

Should there be a "push" for, as you reference, proper reporting of "Estimated
throughput"?  Should there be a "wireless will never report link speed", because
- hey - it requires too much work to change all the wireless drivers?

What should the wireless group say to the bonding module group?

@ Kalle Valo

> Have you reported this on netdev (CCing linux-wireless, David Miller and
> the patch authors)? I think the offending bonding patch should be
> reverted but first it needs to be properly reported on the mailing list.
> Most people don't really follow bugzilla.

I have not.  I first contacted David Miller and the patch authors personally, to
see what sort of tact they might want to take.  They have been notified.  There
has been no response from anyone except Andy.  I can only make-up stories, based
upon no information, about why they are ignoring this issue.  I have been
following an ever-expanding sequence of suggestions about where to discuss this
issue - privately, Arch Linux, kernel bugzilla, linux-wireless - and now,
netdev.  I may do that next, but then, there may be so many different forums
where this topic is being introduced, that no one anywhere will want to track it
at all, or participate.

Really, who's responsibility is it, and who should have the authority, deciding
what functionality wireless drivers "must" provide for functionality like
"wireless bonding"?  I'd like to hear some kind of consensus on that.  So far,
no one is "owning" anything, not the wireless driver people, not the bonding
module people, not the kernel ethtool people.  So far, there are only a
developing set of "attitudes" and opinions.  I appreciate that some people are
willing to express opinions.

@ Dan Williams

> I'm not really arguing against updating mac80211 to report this
> information if somebody actually wants to do the patch.  I'm only
> saying that even with the patch, it's not going to do exactly what you
> want it to do, and even if it works for you 90% of the time, it's not
> going to work for others that much of the time, and thus it gives a
> false sense of "correctness" which is just wrong.

Hey - don't put this on me!  This is not about "what I want it to do".  I'm only
trying to make my wireless bonding work again.  But I also don't want to simply
"slap down" Mahesh, by only reverting his patch, which addressed another, real,
problem.  This needs to be a cooperative effort.  How do *we all* address the
problem that Mahesh was trying to resolve, and, at the same time, continue to
support wireless bonding?  Please, don't just "kick the can down the road".  It
seems to me that Mahesh must have been pretty upset about the wireless drivers
not reporting speed, to have written a patch that just disables the wireless
interface when the reporting fails.  Think about it.

If there is a long-standing screw-up with the wireless drivers failing to
properly support 'section 11.46 ("Estimated throughput") of IEEE802.11-2016',
then let's start-off by admitting that.  *Then* everyone can argue about what to
do about it.  And, if that's not the underlying problem, let's make that
determination.  I'm just trying to find a way forward.

> No, it's not a fault of ethtool.  Ethtool only reports something, it's
> up to the thing that interprets that data (eg, bonding) to do the right
> thing with it.

It has not yet been established that there is anything - "Estimated throughput"
- being provided universally by the wireless 

Re: [v5] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Reizer, Eyal  [170809 00:26]:
> Managed to test with a wilink6 module and in fact reading hardware mac
> Address from fuse is working ok for wilink6/7 as well.
> submitting v6 using this mac address instead of a random one when the 
> bogus (deadbeef...) mac address is read from default nvs file.

Hey great, that should help clear quite a bit of the wl12xx confusion
with distros! Thanks for doing that.

Regards,

Tony

Re: Problem with the wifi

[Larry Finger]

On 08/08/2017 04:10 AM, Arend van Spriel wrote:

+ linux-wireless
+ Larry

please keep linux-wireless in this thread.

On 08-08-17 08:21, Paolo Bettini wrote:

Arend van Spriel ha scritto:

+ linux-wireless On 07-08-17 21:38, Paolo Bettini wrote:

Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One
problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6
linux id or Broadcom AP6212 for windowsi installed deb package
firmware-brcm80211 and nvram sdio txt in /lib/firmware/brcm, reloaded
bcrmfmac module but nothing the card seems invisible or dead i don't
know if is a problem of firmware or my system cannot detect the sdio
card ...do you know something about this problematic ?

As always a kernel log could help or output from dmesg command. Also
can you run following commands: $ ls /sys/bus/sdio/devices $ cat
/sys/bus/sdio/devices/*/modalias Regards, Arend

paolo@paolo:~$ ls /sys/bus/sdio/devices
mmc1:0001:1
paolo@paolo:~$


paolo@paolo:~$ cat /sys/bus/sdio/devices/*/modalias sdio:c07v024CdB723
paolo@paolo:~$ sorry for previous mail ls was from another pc:-[
it seems the system see only the card where the system is installed


Hi Paolo,

Interesting. Now if Google search is correct the vendor id for this
device indicates this is a Realtek (v024C) WLAN (c07) device. So what
makes you say its linux id is 02d0:a9a6?

In upstream linux I do not see any SDIO device drivers in realtek
folder. Maybe Larry can provide clue/hint if a driver for this device is
publicly available somewhere.


Paolo,

The only Realtek SDIO device in common distribution is the RTL8723BS, which has 
been packaged with some Intel processors, and may now be part of other SBC's. 
This driver has been in staging since V4.12. It handles SDIO Vendor code 0x024c 
with device codes 0x0523, 0x0623, 0x0626, and 0xb723. If your device is one of 
these, then you only need to build a kernel with this driver enabled.


I have had very little to do with this driver, other than posting the original 
version on GitHub. From there, many users have modified it until it was 
submitted to staging by Hans de Goede of RedHat.


Larry

[PATCH v2 15/20] rt73usb: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/ralink/rt2x00/rt73usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt73usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt73usb.c
index fd91322..9a21282 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt73usb.c
@@ -2408,7 +2408,7 @@ static const struct rt2x00_ops rt73usb_ops = {
 /*
  * rt73usb module information.
  */
-static struct usb_device_id rt73usb_device_table[] = {
+static const struct usb_device_id rt73usb_device_table[] = {
/* AboCom */
{ USB_DEVICE(0x07b8, 0xb21b) },
{ USB_DEVICE(0x07b8, 0xb21c) },
-- 
2.7.4

[PATCH v2 13/20] rt2500usb: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 529e059..f4b48b7 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -1911,7 +1911,7 @@ static const struct rt2x00_ops rt2500usb_ops = {
 /*
  * rt2500usb module information.
  */
-static struct usb_device_id rt2500usb_device_table[] = {
+static const struct usb_device_id rt2500usb_device_table[] = {
/* ASUS */
{ USB_DEVICE(0x0b05, 0x1706) },
{ USB_DEVICE(0x0b05, 0x1707) },
-- 
2.7.4

[PATCH v2 17/20] rtl8xxxu: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 21e5ef0..7806a4d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6190,7 +6190,7 @@ static void rtl8xxxu_disconnect(struct usb_interface 
*interface)
ieee80211_free_hw(hw);
 }
 
-static struct usb_device_id dev_table[] = {
+static const struct usb_device_id dev_table[] = {
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x8724, 0xff, 0xff, 
0xff),
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x1724, 0xff, 0xff, 
0xff),
-- 
2.7.4

[PATCH v2 20/20] zd1211rw: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c 
b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
index 01ca1d5..c30bf11 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
@@ -35,7 +35,7 @@
 #include "zd_mac.h"
 #include "zd_usb.h"
 
-static struct usb_device_id usb_ids[] = {
+static const struct usb_device_id usb_ids[] = {
/* ZD1211 */
{ USB_DEVICE(0x0105, 0x145f), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x0586, 0x3401), .driver_info = DEVICE_ZD1211 },
-- 
2.7.4

[PATCH v2 19/20] zd1201: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/zydas/zd1201.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zydas/zd1201.c 
b/drivers/net/wireless/zydas/zd1201.c
index 7f586d7..581e857 100644
--- a/drivers/net/wireless/zydas/zd1201.c
+++ b/drivers/net/wireless/zydas/zd1201.c
@@ -25,7 +25,7 @@
 #include 
 #include "zd1201.h"
 
-static struct usb_device_id zd1201_table[] = {
+static const struct usb_device_id zd1201_table[] = {
{USB_DEVICE(0x0586, 0x3400)}, /* Peabird Wireless USB Adapter */
{USB_DEVICE(0x0ace, 0x1201)}, /* ZyDAS ZD1201 Wireless USB Adapter */
{USB_DEVICE(0x050d, 0x6051)}, /* Belkin F5D6051 usb  adapter */
-- 
2.7.4

[PATCH v2 18/20] rtl8192cu: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 96c923b..e673bc2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -275,7 +275,7 @@ static struct rtl_hal_cfg rtl92cu_hal_cfg = {
 #define USB_VENDER_ID_REALTEK  0x0bda
 
 /* 2010-10-19 DID_USB_V3.4 */
-static struct usb_device_id rtl8192c_usb_ids[] = {
+static const struct usb_device_id rtl8192c_usb_ids[] = {
 
/*=== Realtek demoboard ===*/
/* Default ID */
-- 
2.7.4

[PATCH v2 16/20] rtl8187: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
index 55198ac2..121b94f 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
@@ -43,7 +43,7 @@ MODULE_AUTHOR("Larry Finger ");
 MODULE_DESCRIPTION("RTL8187/RTL8187B USB wireless driver");
 MODULE_LICENSE("GPL");
 
-static struct usb_device_id rtl8187_table[] = {
+static const struct usb_device_id rtl8187_table[] = {
/* Asus */
{USB_DEVICE(0x0b05, 0x171d), .driver_info = DEVICE_RTL8187},
/* Belkin */
-- 
2.7.4

[PATCH v2 14/20] rt2800usb: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 685b8e0..cd9547e 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -915,7 +915,7 @@ static const struct rt2x00_ops rt2800usb_ops = {
 /*
  * rt2800usb module information.
  */
-static struct usb_device_id rt2800usb_device_table[] = {
+static const struct usb_device_id rt2800usb_device_table[] = {
/* Abocom */
{ USB_DEVICE(0x07b8, 0x2870) },
{ USB_DEVICE(0x07b8, 0x2770) },
-- 
2.7.4

[PATCH v2 10/20] libertas_tf: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c 
b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index e0ade40..e9104ec 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -31,7 +31,7 @@ module_param_named(fw_name, lbtf_fw_name, charp, 0644);
 
 MODULE_FIRMWARE("lbtf_usb.bin");
 
-static struct usb_device_id if_usb_table[] = {
+static const struct usb_device_id if_usb_table[] = {
/* Enter the device signature inside */
{ USB_DEVICE(0x1286, 0x2001) },
{ USB_DEVICE(0x05a3, 0x8388) },
-- 
2.7.4

[PATCH v2 12/20] mt7601u: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/mediatek/mt7601u/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/usb.c 
b/drivers/net/wireless/mediatek/mt7601u/usb.c
index 416c604..b9e4f67 100644
--- a/drivers/net/wireless/mediatek/mt7601u/usb.c
+++ b/drivers/net/wireless/mediatek/mt7601u/usb.c
@@ -19,7 +19,7 @@
 #include "usb.h"
 #include "trace.h"
 
-static struct usb_device_id mt7601u_device_table[] = {
+static const struct usb_device_id mt7601u_device_table[] = {
{ USB_DEVICE(0x0b05, 0x17d3) },
{ USB_DEVICE(0x0e8d, 0x760a) },
{ USB_DEVICE(0x0e8d, 0x760b) },
-- 
2.7.4

[PATCH v2 11/20] mwifiex: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/marvell/mwifiex/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c 
b/drivers/net/wireless/marvell/mwifiex/usb.c
index cb1753e..821a77b 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -24,7 +24,7 @@
 
 static struct mwifiex_if_ops usb_ops;
 
-static struct usb_device_id mwifiex_usb_table[] = {
+static const struct usb_device_id mwifiex_usb_table[] = {
/* 8766 */
{USB_DEVICE(USB8XXX_VID, USB8766_PID_1)},
{USB_DEVICE_AND_INTERFACE_INFO(USB8XXX_VID, USB8766_PID_2,
-- 
2.7.4

[PATCH v2 09/20] libertas: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c 
b/drivers/net/wireless/marvell/libertas/if_usb.c
index e53025e..16e54c7 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -52,7 +52,7 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8682, "libertas/usb8682.bin", NULL }
 };
 
-static struct usb_device_id if_usb_table[] = {
+static const struct usb_device_id if_usb_table[] = {
/* Enter the device signature inside */
{ USB_DEVICE(0x1286, 0x2001), .driver_info = MODEL_8388 },
{ USB_DEVICE(0x05a3, 0x8388), .driver_info = MODEL_8388 },
-- 
2.7.4

[PATCH v2 08/20] p54: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/intersil/p54/p54usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/p54/p54usb.c 
b/drivers/net/wireless/intersil/p54/p54usb.c
index 043bd1c..b0b86f7 100644
--- a/drivers/net/wireless/intersil/p54/p54usb.c
+++ b/drivers/net/wireless/intersil/p54/p54usb.c
@@ -41,7 +41,7 @@ MODULE_FIRMWARE("isl3887usb");
  * whenever you add a new device.
  */
 
-static struct usb_device_id p54u_table[] = {
+static const struct usb_device_id p54u_table[] = {
/* Version 1 devices (pci chip + net2280) */
{USB_DEVICE(0x0411, 0x0050)},   /* Buffalo WLI2-USB2-G54 */
{USB_DEVICE(0x045e, 0x00c2)},   /* Microsoft MN-710 */
-- 
2.7.4

[PATCH v2 07/20] orinoco: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/orinoco/orinoco_usb.c 
b/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
index c84fd84..56f6e3b 100644
--- a/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
@@ -210,7 +210,7 @@ struct ezusb_packet {
 } __packed;
 
 /* Table of devices that work or may work with this driver */
-static struct usb_device_id ezusb_table[] = {
+static const struct usb_device_id ezusb_table[] = {
{USB_DEVICE(USB_COMPAQ_VENDOR_ID, USB_COMPAQ_WL215_ID)},
{USB_DEVICE(USB_COMPAQ_VENDOR_ID, USB_HP_WL215_ID)},
{USB_DEVICE(USB_COMPAQ_VENDOR_ID, USB_COMPAQ_W200_ID)},
-- 
2.7.4

[PATCH v2 02/20] ath6kl: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/ath/ath6kl/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c 
b/drivers/net/wireless/ath/ath6kl/usb.c
index 9da3594..4defb7a 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1201,7 +1201,7 @@ static int ath6kl_usb_pm_resume(struct usb_interface 
*interface)
 #endif
 
 /* table of devices that work with this driver */
-static struct usb_device_id ath6kl_usb_ids[] = {
+static const struct usb_device_id ath6kl_usb_ids[] = {
{USB_DEVICE(0x0cf3, 0x9375)},
{USB_DEVICE(0x0cf3, 0x9374)},
{ /* Terminating entry */ },
-- 
2.7.4

[PATCH v2 05/20] at76c50x: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c 
b/drivers/net/wireless/atmel/at76c50x-usb.c
index 09defbc..94bf01f 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -130,7 +130,7 @@ MODULE_FIRMWARE("atmel_at76c505amx-rfmd.bin");
 
 #define USB_DEVICE_DATA(__ops) .driver_info = (kernel_ulong_t)(__ops)
 
-static struct usb_device_id dev_table[] = {
+static const struct usb_device_id dev_table[] = {
/*
 * at76c503-i3861
 */
-- 
2.7.4

[PATCH v2 04/20] carl9170: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/ath/carl9170/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/carl9170/usb.c 
b/drivers/net/wireless/ath/carl9170/usb.c
index 99ab203..e7c3f3b 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -64,7 +64,7 @@ MODULE_ALIAS("arusb_lnx");
  * http://wireless.kernel.org/en/users/Drivers/ar9170/devices ),
  * whenever you add a new device.
  */
-static struct usb_device_id carl9170_usb_ids[] = {
+static const struct usb_device_id carl9170_usb_ids[] = {
/* Atheros 9170 */
{ USB_DEVICE(0x0cf3, 0x9170) },
/* Atheros TG121N */
-- 
2.7.4

[PATCH v2 03/20] ath9k: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  Re-submitting wireless separately.

 drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 0d9687a..c5f4dd8 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -20,7 +20,7 @@
 MODULE_FIRMWARE(HTC_7010_MODULE_FW);
 MODULE_FIRMWARE(HTC_9271_MODULE_FW);
 
-static struct usb_device_id ath9k_hif_usb_ids[] = {
+static const struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
{ USB_DEVICE(0x0846, 0x9030) }, /* Netgear N150 */
-- 
2.7.4

[PATCH v2 00/20] constify wireless usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Arvind Yadav (20):
  [PATCH v2 01/20] ar5523: constify usb_device_id
  [PATCH v2 02/20] ath6kl: constify usb_device_id
  [PATCH v2 03/20] ath9k: constify usb_device_id
  [PATCH v2 04/20] carl9170: constify usb_device_id
  [PATCH v2 05/20] at76c50x: constify usb_device_id
  [PATCH v2 06/20] brcm80211: constify usb_device_id
  [PATCH v2 07/20] orinoco: constify usb_device_id
  [PATCH v2 08/20] p54: constify usb_device_id
  [PATCH v2 09/20] libertas: constify usb_device_id
  [PATCH v2 10/20] libertas_tf: constify usb_device_id
  [PATCH v2 11/20] marvell: mwifiex: constify usb_device_id
  [PATCH v2 12/20] mt7601u: constify usb_device_id
  [PATCH v2 13/20] rt2500usb: constify usb_device_id
  [PATCH v2 14/20] rt2800usb: constify usb_device_id
  [PATCH v2 15/20] rt73usb: constify usb_device_id
  [PATCH v2 16/20] rtl8187: constify usb_device_id
  [PATCH v2 17/20] realtek: rtl8xxxu: constify usb_device_id
  [PATCH v2 18/20] realtek: rtl8192cu: constify usb_device_id
  [PATCH v2 19/20] zd1201: constify usb_device_id
  [PATCH v2 20/20] zd1211rw: constify usb_device_id

 drivers/net/wireless/ath/ar5523/ar5523.c   | 2 +-
 drivers/net/wireless/ath/ath6kl/usb.c  | 2 +-
 drivers/net/wireless/ath/ath9k/hif_usb.c   | 2 +-
 drivers/net/wireless/ath/carl9170/usb.c| 2 +-
 drivers/net/wireless/atmel/at76c50x-usb.c  | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 2 +-
 drivers/net/wireless/intersil/orinoco/orinoco_usb.c| 2 +-
 drivers/net/wireless/intersil/p54/p54usb.c | 2 +-
 drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
 drivers/net/wireless/marvell/libertas_tf/if_usb.c  | 2 +-
 drivers/net/wireless/marvell/mwifiex/usb.c | 2 +-
 drivers/net/wireless/mediatek/mt7601u/usb.c| 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt73usb.c   | 2 +-
 drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c| 2 +-
 drivers/net/wireless/zydas/zd1201.c| 2 +-
 drivers/net/wireless/zydas/zd1211rw/zd_usb.c   | 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)

-- 
2.7.4

Re: brcm43430 sdio wifi regression with 4.13-rc1

[russianneuroman...@ya.ru]

Hello!

> There are three patches currently in wireless tree, maybe also in netdev 
> tree, which will probably be included in 4.13-rc4 fixing the issue below.

With Linux 4.13rc4 issue is no longer reproducible on Lenovo Miix2 8.

03.08.2017, 05:05, "Arend van Spriel" :
> On 02-08-17 22:43, russianneuroman...@ya.ru wrote:
>>  Hello!
>>
>>  Sorry for late answer.
>>
>>>  russianneuromancer has reported seeing a similar problem with 4.13.
>>
>>>  russianneuromancer, can you check if the device you are seeing this with
>>  also has a brcm43430 sdio wifi and if so if switching to:
>>
>>>  
>>> http://jwrdegoede.danny.cz/brcm-firmware/brcmfmac43430-sdio.bin.7.45.77.0.ucode1043.2054
>>
>>>  Fixes this ?
>>
>>  Judging by this error message
>>
>>>  [ 7.744262] brcmfmac mmc0:0001:1: Direct firmware load for 
>>> brcm/brcmfmac43241b4-sdio.txt failed with error -2
>>
>>  Lenovo Miix2 8 have brcm43241b4 sdio wifi.
>>
>>  With brcmfmac43241b4-sdio.txt from NVRAM, as suggested here 
>> https://wireless.wiki.kernel.org/en/users/drivers/brcm80211 WiFi connection 
>> works for me with upstream Linux 4.12.4, but doesn't work with Linux 4.13rc1 
>> and Linux 4.13rc3.
>
> Yeah. There are three patches currently in wireless tree, maybe also in
> netdev tree, which will probably be included in 4.13-rc4 fixing the
> issue below.
>
> Regards,
> Arend
>
>>  Few connection attempts with Linux 4.13rc3 looks like this:
>>
>>>  [ 7.779370] usbcore: registered new interface driver brcmfmac
>>>  [ 7.948487] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 
>>> 17 2013 07:36:07 version 6.10.197.71 (r412987) FWID 01-882d2634
>>>  [ 32.282374] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
>>>  [ 32.282393] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 
>>> type 10 failed: err=-16
>>>  [ 43.560596] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 44.494422] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 45.492956] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 46.491317] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 54.922652] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 55.849565] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 56.849437] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 57.853150] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 66.542999] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 67.483115] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>>  [ 68.483434] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet 
>>> received, flags 0x0
>>
>>  23.07.2017, 02:44, "Hans de Goede" :
>>>  Hi,
>>>
>>>  When upgrading my devel environment to 4.13-rc1+ I noticed that
>>>  the brcm43430 sdio wifi on a Chuwi Hi8 plus stopped working:
>>>
>>>  jul 22 14:13:23 localhost.localdomain kernel: brcmfmac: brcmf_sdio_probe: 
>>> Loading firmware brcm/brcmfmac43430-sdio.bin for chip a9a6 rev 0001
>>>  jul 22 14:13:23 localhost.localdomain kernel: usbcore: registered new 
>>> interface driver brcmfmac
>>>  jul 22 14:13:23 localhost.localdomain kernel: brcmfmac: 
>>> brcmf_c_preinit_dcmds: Firmware version = wl0: Aug 29 2016 20:48:16 version 
>>> 7.45.41.26 (r640327) FWID 01-4527cfab
>>>  jul 22 14:13:23 localhost.localdomain kernel: brcmfmac: 
>>> brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
>>>  jul 22 14:13:26 localhost.localdomain kernel: brcmfmac: 
>>> brcmf_sdio_bus_rxctl: resumed on timeout
>>>  jul 22 14:13:28 localhost.localdomain kernel: brcmfmac: 
>>> brcmf_sdio_bus_rxctl: resumed on timeout
>>>  jul 22 14:13:31 localhost.localdomain kernel: brcmfmac: 
>>> brcmf_sdio_bus_rxctl: resumed on timeout
>>>  
>>>
>>>  The real culprit here seems to be:
>>>
>>>  jul 22 14:13:23 localhost.localdomain kernel: brcmfmac: 
>>> brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
>>>
>>>  I've tried reverting allmost all changes under 
>>> drivers/net/wireless/broadcom/brcm80211
>>>  as well as those under drivers/mmc, but that did not help.
>>>
>>>  Googling for the "Unknown mailbox data content" error found some Raspberry 
>>> Pi 3
>>>  related comments where users report success with a different firmware 
>>> version
>>>  from: 
>>> https://android.googlesource.com/platform/hardware/broadcom/wlan/+/master/bcmdhd/firmware/bcm4343/
>>>
>>>  So I tried that as well as a version extracted from the Android install
>>>  on the tablet and both work fine, only the "version 7.45.41.26" which
>>>  happens to be the one in linux-firmware causes this problem, I've put
>>>  all (Linux build, not NDIS) versions I 

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Tue, 2017-08-08 at 18:36 -0600, James Feeney wrote:
> Hey
> 
> On 08/08/2017 04:49 PM, Ben Greear wrote:
> > 
> > Some time back, I added some support to ath10k to report some
> > ethtool info.
> > At least most of this is upstream.  I do report rx and rx link
> > rate, and yes,
> > it changes, but it does contain some useful info, at least when
> > modest amounts
> > of packets are being transmitted and received (so that rate-ctrl
> > logic
> > is working).  I think the stuff not prepended with d_ will show up
> > for any
> > mac80211 driver.  Someone could improve ethtool to report these
> > through more
> > normal API than just getting the stats if they wanted...
> 
> Hmm - would you then lean in the direction of saying that this
> failure to report
> a link speed is a fault in the kernel ethtool?

No, it's not a fault of ethtool.  Ethtool only reports something, it's
up to the thing that interprets that data (eg, bonding) to do the right
thing with it.

> And, if so, would an update be required in just the kernel ethtool,
> or in both
> the kernel ethtool and in every wireless driver?

Likely every wireless driver, except that for mac80211-based drivers it
would only take updating the mac80211 stack.

I'm not really arguing against updating mac80211 to report this
information if somebody actually wants to do the patch.  I'm only
saying that even with the patch, it's not going to do exactly what you
want it to do, and even if it works for you 90% of the time, it's not
going to work for others that much of the time, and thus it gives a
false sense of "correctness" which is just wrong.

> Should the kernel ethtool get_settings() be made to report a proper
> link speed
> and duplex when used with the wireless drivers?
> 
> On 08/08/2017 05:43 PM, Dan Williams wrote:
> > 
> > It's very relevant to the question.  Because if the speed is
> > actually
> > not useful for the requested purpose, there is no real point in
> > having
> > it reported it via ethtool.  Same for duplex.  Wifi is only "half
> > duplex", and so the property is actually meaningless for WiFi.
> 
> That seems a little over-broad, at least certainly with respect to
> "half
> duplex".  If the link is known to be half duplex, then the kernel
> ethtool can
> simply report that the link is "half duplex".  I am not hearing a
> good
> justification, or a necessity, for the kernel ethtool to return an
> error, instead.

> > At
> > worst, your bonding link will flip-flop between slaves every second
> > or
> > two.  At best, bonding won't do anything differently than if the
> > speed
> > was just faked to some fake lowest common denominator number so
> > that
> > your wired link was always faster.
> 
> Well ok, flip-flopping every second would seem a pointless and bad
> effect.  But
> then, for instance, my rtl8192ce driver shows a stable, actual link
> speed:
> 
> $ iwconfig wlp2s0
> ...
> Bit Rate=72.2 Mb/s
> ...

iwconfig cannot report high rates, so try 'iw dev  link' to make
sure.

When I did 'iw dev wlp4s0 link' with a 2.4GHz baby monitor on in the
next room, my device flipped continuously between ~70Mb/s and 130Mb/s
every couple seconds. YMMV.  It's gonna be the same anywhere near a
microwave.

> $ ethtool -S wlp2s0
> ...
>  txrate: 7220
>  rxrate: 100
> ...
> 
> Then, I don't know if this effect is as bad as you suggest.  Is there
> an actual
> "stable" link speed here?  Or is this an "illusion", of bit of
> "fluff" being
> promoted by the user-space iwconfig and ethtool?

There is no "stable" link speed.  The link selects the maximum speed
that produces as few errors as possible, and adjusts that speed
continuously due to the radio environment.  Again, many external
factors that you have no control over affect link speed.

In the span of 5 seconds, 2 feet away from my 11n AP, my link went
through 65Mb, 130Mb, 78Mb, and back to 130Mb.  That's just how this
works.

It's like if your ethernet link dynamically adjusted speed from 2Mb/s
up to 10Gb/s based on how much traffic was going through it at a given
time, or to save power, or something.

> > Sure, somebody could do a patch (like Ben has) that plumbs all this
> > stuff through.  But that's not solving the *actual* problem, which
> > is
> > that this bonding change makes assumptions of slave devices that
> > simply
> > don't match how those devices work.
> 
> I take it that your position would be that the bonding module people,
> and Mahesh
> in particular, are being unreasonable in expecting the kernel ethtool
> to provide
> anything but an error in response to get_settings()?  What do you
> think of
> Florian's suggestion, to check for dev->ieee80211_ptr being set, and
> letting
> these interfaces proceed with being enslaved in a bond master network
> device if
> that's the case?

I'm suggesting that if the bonding driver is expecting a *continuous*
stable link rate from any kind of radio device, whether that's WiFi,
WWAN, Bluetooth, or whatever, it's being 

Re: wireless drivers fail to report link speed?

[Arend van Spriel]

On 8/9/2017 2:36 AM, James Feeney wrote:

Hey



[...]


On 08/08/2017 05:43 PM, Dan Williams wrote:


It's very relevant to the question.  Because if the speed is actually
not useful for the requested purpose, there is no real point in having
it reported it via ethtool.  Same for duplex.  Wifi is only "half
duplex", and so the property is actually meaningless for WiFi.


That seems a little over-broad, at least certainly with respect to "half
duplex".  If the link is known to be half duplex, then the kernel ethtool can
simply report that the link is "half duplex".  I am not hearing a good
justification, or a necessity, for the kernel ethtool to return an error, 
instead.


There is nothing "over-board" about it. Whhy asking a question if you 
already know the answer.



At
worst, your bonding link will flip-flop between slaves every second or
two.  At best, bonding won't do anything differently than if the speed
was just faked to some fake lowest common denominator number so that
your wired link was always faster.


Well ok, flip-flopping every second would seem a pointless and bad effect.  But
then, for instance, my rtl8192ce driver shows a stable, actual link speed:

$ iwconfig wlp2s0
...
Bit Rate=72.2 Mb/s
...

$ ethtool -S wlp2s0
...
  txrate: 7220
  rxrate:  100
...

Then, I don't know if this effect is as bad as you suggest.  Is there an actual
"stable" link speed here?  Or is this an "illusion", of bit of "fluff" being
promoted by the user-space iwconfig and ethtool?


Sure, somebody could do a patch (like Ben has) that plumbs all this
stuff through.  But that's not solving the *actual* problem, which is
that this bonding change makes assumptions of slave devices that simply
don't match how those devices work.


I take it that your position would be that the bonding module people, and Mahesh
in particular, are being unreasonable in expecting the kernel ethtool to provide
anything but an error in response to get_settings()?  What do you think of
Florian's suggestion, to check for dev->ieee80211_ptr being set, and letting
these interfaces proceed with being enslaved in a bond master network device if
that's the case?

Would you go so far as to say that modifying the kernel ethtool to report
wireless link speed and duplex would be entirely pointless?


It really depends on how it is used. In case of the bonding module it 
seems it need to be pretty accurate to assure using the fastest link. 
You say your rtl8192ce driver reports stable speed, but what is your 
connection state and are you actually sending packets over it. Also the 
rxrate reported is 1MB/s, which is probably rate of the last received 
packet. Apart from your data connection to the AP the device is 
receiving beacons which are sent at a low speed thus screwing up the rx 
speed accuracy of your link.


Actually what the bonding module could rely on would be what is 
described in section 11.46 ("Estimated throughput") of IEEE802.11-2016 
as it seems to address exactly the bonding use-case. However, I am not 
aware of any devices in the field carrying that feature (but I am not 
all knowing ;-) ).


Regards,
Arend


Thanks
James

Re: [PATCH v4 01/10] wil6210: protect against invalid length of tx management frame

[Arend van Spriel]

On 8/3/2017 9:08 PM, Maya Erez wrote:

From: Hamad Kadmany 

Validate buffer length has the minimum needed size
when sending management frame to protect against
possible buffer overrun.


I noticed this is already applied, but I saw this subject text which has 
similar sound to a recent patch in our driver so I it made me curious...



Signed-off-by: Hamad Kadmany 
Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
  drivers/net/wireless/ath/wil6210/cfg80211.c | 3 +++
  drivers/net/wireless/ath/wil6210/debugfs.c  | 3 +++
  2 files changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 0b5383a..77af749 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -884,6 +884,9 @@ int wil_cfg80211_mgmt_tx(struct wiphy *wiphy, struct 
wireless_dev *wdev,
wil_hex_dump_misc("mgmt tx frame ", DUMP_PREFIX_OFFSET, 16, 1, buf,
  len, true);

+   if (len < sizeof(struct ieee80211_hdr_3addr))
+   return -EINVAL;


A similar check is already in net/wireless/cfg80211_mlme_mgmt_tx() which 
calls this function:


if (params->len < 24 + 1)
return -EINVAL;

So it only makes sense if this is called from some other call site


cmd = kmalloc(sizeof(*cmd) + len, GFP_KERNEL);
if (!cmd) {
rc = -ENOMEM;
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index f82506d..a2b5d59 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -801,6 +801,9 @@ static ssize_t wil_write_file_txmgmt(struct file *file, 
const char __user *buf,
int rc;
void *frame;

+   if (!len)
+   return -EINVAL;
+


... which is in this function. Now I wonder why you would need this 
method in the first place. Why not stick with using the nl80211 
NL80211_CMD_FRAME api?


Regards,
Arend


frame = memdup_user(buf, len);
if (IS_ERR(frame))
return PTR_ERR(frame);

[v6] wlcore: add missing nvs file name info for wilink8

[Reizer, Eyal]

The following commits:
commit c815fdebef44 ("wlcore: spi: Populate config firmware data")
commit d776fc86b82f ("wlcore: sdio: Populate config firmware data")

Populated the nvs entry for wilink6 and wilink7 only while it is
still needed for wilink8 as well for specifying an alternate mac address.
This broke user space backward compatibility when upgrading from older
kernels, as the alternate mac address would not be read from the nvs that
is present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
causing mac address change of the wlan interface.

This patch fix this and update the structure field with the same default
nvs file name that has been used before.

In addition, some distros hold a default wl1271-nvs.bin in the file
system with a bogus mac address (deadbeef...) that overrides the mac
address that is stored inside the device.
Warn users about this bogus mac address and use the internal mac address

Fixes: c815fdebef44 ("wlcore: spi: Populate config firmware data")
Fixes: d776fc86b82f ("wlcore: sdio: Populate config firmware data")
Cc:  # 4.9+
Signed-off-by: Eyal Reizer 
---
v2->v3: add a check for default deadbeef... mac address and warn about it
v3->v4: use a random TI mac address instead of the bogus one
v4->v5: add constant definition for TI oui address
v5->v6: after also verifying on wilink6/7 Use mac internal mac address
instead of a random one
---
 drivers/net/wireless/ti/wlcore/main.c | 15 +++
 drivers/net/wireless/ti/wlcore/sdio.c |  1 +
 drivers/net/wireless/ti/wlcore/spi.c  |  1 +
 3 files changed, 17 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 60aaa85..dd1ac48 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -6040,6 +6040,21 @@ static int wl1271_register_hw(struct wl1271 *wl)
nic_addr = wl->fuse_nic_addr + 1;
}
 
+   if (oui_addr == 0xdeadbe && nic_addr == 0xef) {
+   wl1271_warning("Detected unconfigured mac address in nvs.\n"
+   "derive from fuse instead.\n"
+   "in case of using a wl12xx device, your "
+   "device performance may not be optimized.\n"
+   "Please use the calibrator tool to configure "
+   "your device.\n"
+   "When using a wl18xx device this default nvs "
+   "file can be removed from the file system\n");
+
+   oui_addr = wl->fuse_oui_addr;
+   /* fuse has the BD_ADDR, the WLAN addresses are the next two */
+   nic_addr = wl->fuse_nic_addr + 1;
+   }
+
wl12xx_derive_mac_addresses(wl, oui_addr, nic_addr);
 
ret = ieee80211_register_hw(wl->hw);
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 2fb3871..f8a1fea 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -230,6 +230,7 @@ static const struct wilink_family_data wl128x_data = {
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
.cfg_name = "ti-connectivity/wl18xx-conf.bin",
+   .nvs_name = "ti-connectivity/wl1271-nvs.bin",
 };
 
 static const struct of_device_id wlcore_sdio_of_match_table[] = {
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index fdabb92..62ce54a 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -92,6 +92,7 @@ static const struct wilink_family_data wl128x_data = {
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
.cfg_name = "ti-connectivity/wl18xx-conf.bin",
+   .nvs_name = "ti-connectivity/wl1271-nvs.bin",
 };
 
 struct wl12xx_spi_glue {
-- 
2.7.4

pull-request: iwlwifi 2017-08-09

[Luca Coelho]

Hi Kalle,

Here is the third set of fixes for 4.13.  More details in the tag
description.

This includes both series I sent out, the first one, with v2 of the
second patch, with an improved commit message, and the second one, which
contains the mac80211 patch as well.

I have sent this out before and kbuildbot didn't find any issues. 
Please let me know if there are any issues.

Cheers,
Luca.


The following changes since commit 368bd88ebb64cabe4a1ec727659214bb8d693707:

  Merge tag 'iwlwifi-for-kalle-2017-08-02' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2017-08-03 
11:01:11 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2018-08-09

for you to fetch changes up to 20fc690f38d17b8f961101a477a9aa0841fb6e20:

  iwlwifi: mvm: send delba upon rx ba session timeout (2017-08-09 10:05:01 
+0300)


Some more fixes for 4.13

* Fix a memory leak in the SAR code;
* Fix a stuck queue case in AP mode;
* Convert a WARN to a simple debug in a legitimate race case (from
  which we can recover);
* Fix a severe throughput aggregation on 9000-family devices due to
  aggregation issues.


Avraham Stern (1):
  iwlwifi: mvm: start mac queues when deferred tx frames are purged

Christophe Jaillet (1):
  iwlwifi: mvm: Fix a memory leak in an error handling path in 
'iwl_mvm_sar_get_wgds_table()'

Emmanuel Grumbach (1):
  iwlwifi: mvm: don't WARN when a legit race happens in A-MPDU

Naftali Goldstein (2):
  mac80211: add api to start ba session timer expired flow
  iwlwifi: mvm: send delba upon rx ba session timeout

 drivers/net/wireless/intel/iwlwifi/mvm/fw.c   |  6 --
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 12 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 10 ++
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c  |  4 ++--
 include/net/mac80211.h| 15 +++
 net/mac80211/agg-rx.c | 22 +-
 6 files changed, 59 insertions(+), 10 deletions(-)

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 4/19] iwlwifi: mvm: add debugfs to force CT-kill

[Kalle Valo]

Luca Coelho  writes:

> From: Chaya Rachel Ivgi 
>
> CT-kill is a thermal-based "RF-kill", which disables the NIC
> completely if the temperature gets too high, in order to avoid damage.
>
> Add a debugfs entry to simulate high temperatures, in order to test
> CT-kill flows in the driver without having to physically heat the
> device up.
>
> Signed-off-by: Chaya Rachel Ivgi 
> Signed-off-by: Luca Coelho 

This is perfect, kiitti!

-- 
Kalle Valo

Re: [PATCH v2 2/3] iwlwifi: mvm: start mac queues when deferred tx frames are purged

[Kalle Valo]

Luca Coelho  writes:

> From: Avraham Stern 
>
> In AP mode, if a station is removed just as it is adding a new stream,
> the queue in question will remain stopped and no more TX will happen
> in this queue, leading to connection failures and other problems.
>
> This is because under DQA, when tx is deferred because a queue needs
> to be allocated, the mac queue for that TID is stopped until the new
> stream is added.  If at this point the station that this stream
> belongs to is removed, all the deferred tx frames are purged, but the
> mac queue is not restarted. As a result, all following tx on this
> queue will not be transmitted.
>
> Fix this by starting the relevant mac queues when the deferred tx
> frames are purged.
>
> Fixes: 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of 
> queues")
> Signed-off-by: Avraham Stern 
> Signed-off-by: Luca Coelho 

Looks good, thanks.

-- 
Kalle Valo

RE: [v5] wlcore: add missing nvs file name info for wilink8

[Reizer, Eyal]

> 
> > Subject: Re: [v5] wlcore: add missing nvs file name info for wilink8
> >
> > * Reizer, Eyal  [170807 00:47]:
> > > Hi Tony,
> > > >
> > > > * Reizer, Eyal  [170807 00:32]:
> > > > > The following commits:
> > > > > c815fde wlcore: spi: Populate config firmware data
> > > > > d776fc8 wlcore: sdio: Populate config firmware data
> > > > >
> > > > > Populated the nvs entry for wilink6 and wilink7 only while it is
> > > > > still needed for wilink8 as well.
> > > > > This broke user space backward compatibility when upgrading from
> > older
> > > > > kernels, as the alternate mac address would not be read from the nvs
> > that
> > > > is
> > > > > present in the file system (lib/firmware/ti-connectivity/wl1271-
> nvs.bin)
> > > > > causing mac address change of the wlan interface.
> > > > >
> > > > > This patch fix this and update the structure field with the same
> default
> > > > > nvs file name that has been used before.
> > > > >
> > > > > In addition, some distros hold a default wl1271-nvs.bin in the file
> > > > > system with a bogus mac address (deadbeef...) that for a wl18xx
> device
> > > > > also overrides the mac address that is stored inside the device.
> > > > > Warn users about this bogus mac address and use a random mac
> > instead
> > > >
> > > > Hmm looks pretty good to me except for one more thing I just noticed.
> > > >
> > > > Why don't you just use the hardware mac address instead of a random
> > > > mac address on wl18xx device when you see a bogus nvs file?
> > > >
> > >
> > > I agree that this would have been better but the problem is that
> hardware
> > > mac address is available for wilink8 onlyWilink6/7 don't have one stored.
> > > The wlcore code responsible for handling mac address is common code
> > > and there is method for detecting between them in this module.
> >
> > Care to clarify a bit.. Are you saying wilink8 will use the hardware
> > mac address in case of bogus nvs file?
> >
> With present implementation it will not. It will use the random one for both
> wilink6/7 as well as wilink8.
> I need to get a hold of a wilink6/7 module and see if reverting to an internal
> mac address is working. Will try to look around as it has been a while since
> I used one.
> 
Managed to test with a wilink6 module and in fact reading hardware mac
Address from fuse is working ok for wilink6/7 as well.
submitting v6 using this mac address instead of a random one when the 
bogus (deadbeef...) mac address is read from default nvs file.

Best Regards,
Eyal

[PATCH 1/2] mac80211: add api to start ba session timer expired flow

[Luca Coelho]

From: Naftali Goldstein 

Some drivers handle rx buffer reordering internally (and by extension
handle also the rx ba session timer internally), but do not ofload the
addba/delba negotiation.
Add an api for these drivers to properly tear-down the ba session,
including sending a delba.

Signed-off-by: Naftali Goldstein 
Signed-off-by: Luca Coelho 
---
 include/net/mac80211.h | 15 +++
 net/mac80211/agg-rx.c  | 22 +-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index b2b5419467cc..f8149ca192b4 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -5499,6 +5499,21 @@ static inline void 
ieee80211_stop_rx_ba_session_offl(struct ieee80211_vif *vif,
ieee80211_manage_rx_ba_offl(vif, addr, tid + IEEE80211_NUM_TIDS);
 }
 
+/**
+ * ieee80211_rx_ba_timer_expired - stop a Rx BA session due to timeout
+ *
+ * Some device drivers do not offload AddBa/DelBa negotiation, but handle rx
+ * buffer reording internally, and therefore also handle the session timer.
+ *
+ * Trigger the timeout flow, which sends a DelBa.
+ *
+ * @vif:  ieee80211_vif pointer from the add_interface callback
+ * @addr: station mac address
+ * @tid: the rx tid
+ */
+void ieee80211_rx_ba_timer_expired(struct ieee80211_vif *vif,
+  const u8 *addr, unsigned int tid);
+
 /* Rate control API */
 
 /**
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 8708cbe8af5b..2b36eff5d97e 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -7,7 +7,7 @@
  * Copyright 2006-2007 Jiri Benc 
  * Copyright 2007, Michael Wu 
  * Copyright 2007-2010, Intel Corporation
- * Copyright(c) 2015 Intel Deutschland GmbH
+ * Copyright(c) 2015-2017 Intel Deutschland GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -466,3 +466,23 @@ void ieee80211_manage_rx_ba_offl(struct ieee80211_vif *vif,
rcu_read_unlock();
 }
 EXPORT_SYMBOL(ieee80211_manage_rx_ba_offl);
+
+void ieee80211_rx_ba_timer_expired(struct ieee80211_vif *vif,
+  const u8 *addr, unsigned int tid)
+{
+   struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+   struct ieee80211_local *local = sdata->local;
+   struct sta_info *sta;
+
+   rcu_read_lock();
+   sta = sta_info_get_bss(sdata, addr);
+   if (!sta)
+   goto unlock;
+
+   set_bit(tid, sta->ampdu_mlme.tid_rx_timer_expired);
+   ieee80211_queue_work(>hw, >ampdu_mlme.work);
+
+ unlock:
+   rcu_read_unlock();
+}
+EXPORT_SYMBOL(ieee80211_rx_ba_timer_expired);
-- 
2.13.2

[PATCH 2/2] iwlwifi: mvm: send delba upon rx ba session timeout

[Luca Coelho]

From: Naftali Goldstein 

When an RX block-ack session times out, the firmware, which offloads
RX reordering but not the BA session negotiation, stops the session
but doesn't send a DELBA.  This causes the the session to remain
active in the remote device, so no more BA sessions will be
established, causing a severe throughput degradation due to the lack
of aggregation.

Use the new ieee80211_rx_ba_timer_expired API when the ba session timer
expires, since this will tear down the ba session and also send a delba.

The previous API used is intended for drivers that offload the
addba/delba negotiation, but not the rx reordering, while our driver
does the opposite.

This patch depends on "mac80211: add api to start ba session timer
expired flow".

Signed-off-by: Naftali Goldstein 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index dcaef7c043ac..027ee5e72172 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -291,8 +291,8 @@ static void iwl_mvm_rx_agg_session_expired(unsigned long 
data)
goto unlock;
 
mvm_sta = iwl_mvm_sta_from_mac80211(sta);
-   ieee80211_stop_rx_ba_session_offl(mvm_sta->vif,
- sta->addr, ba_data->tid);
+   ieee80211_rx_ba_timer_expired(mvm_sta->vif,
+ sta->addr, ba_data->tid);
 unlock:
rcu_read_unlock();
 }
-- 
2.13.2

[PATCH 0/2] iwlwifi: one more fix intended for 4.13 2017-08-09

[Luca Coelho]

From: Luca Coelho 

Hi,

This is the mac80211+iwlwifi fix we talked about earlier.  As I
mentioned, the iwlwifi patch fixes a severe degradation of throughput
in the 9000 device series, due to a BA-session getting stuck and the
lack of future aggregation.  The mac80211 patch adds a new callback
that allows us to solve this problem.

As agreed, I'm planning to apply this to my tree and send a
pull-request containing both patches.

Please review and let me know if there are any issues.

Cheers,
Luca.


Naftali Goldstein (2):
  mac80211: add api to start ba session timer expired flow
  iwlwifi: mvm: send delba upon rx ba session timeout

 drivers/net/wireless/intel/iwlwifi/mvm/sta.c |  4 ++--
 include/net/mac80211.h   | 15 +++
 net/mac80211/agg-rx.c| 22 +-
 3 files changed, 38 insertions(+), 3 deletions(-)

-- 
2.13.2

[PATCH v2 12/19] iwlwifi: mvm: support new beacon template command

[Luca Coelho]

From: Haim Dreyfuss 

Support a new version of the beacon template command. This replaces v8
of the command, which was missing the rate code.  Also, export rate
decision logic to a separate function.

Signed-off-by: Haim Dreyfuss 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/fw/api/tx.h| 17 +---
 drivers/net/wireless/intel/iwlwifi/fw/file.h  |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 47 ---
 3 files changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h 
b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
index 2909d1ed89cf..4928310ddd31 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
@@ -786,13 +786,20 @@ struct iwl_mac_beacon_cmd_v7 {
struct ieee80211_hdr frame[0];
 } __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_7 */
 
+enum iwl_mac_beacon_flags {
+   IWL_MAC_BEACON_CCK  = BIT(8),
+   IWL_MAC_BEACON_ANT_A= BIT(9),
+   IWL_MAC_BEACON_ANT_B= BIT(10),
+   IWL_MAC_BEACON_ANT_C= BIT(11),
+};
+
 /**
  * struct iwl_mac_beacon_cmd - beacon template command with offloaded CSA
- * @byte_cnt: byte count of the beacon frame
- * @flags: for future use
+ * @byte_cnt: byte count of the beacon frame.
+ * @flags: least significant byte for rate code. The most significant byte
+ * is  iwl_mac_beacon_flags.
  * @reserved: reserved
- * @template_id: currently equal to the mac context id of the coresponding
- *  mac.
+ * @template_id: currently equal to the mac context id of the coresponding mac.
  * @tim_idx: the offset of the tim IE in the beacon
  * @tim_size: the length of the tim IE
  * @ecsa_offset: offset to the ECSA IE if present
@@ -809,7 +816,7 @@ struct iwl_mac_beacon_cmd {
__le32 ecsa_offset;
__le32 csa_offset;
struct ieee80211_hdr frame[0];
-} __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_8 */
+} __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_9 */
 
 struct iwl_beacon_notif {
struct iwl_mvm_tx_resp beacon_notify_hdr;
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h 
b/drivers/net/wireless/intel/iwlwifi/fw/file.h
index 0fa8c473f1e2..d933aa324ffe 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
@@ -260,6 +260,7 @@ enum iwl_ucode_tlv_api {
IWL_UCODE_TLV_API_STA_TYPE  = (__force 
iwl_ucode_tlv_api_t)30,
IWL_UCODE_TLV_API_NAN2_VER2 = (__force 
iwl_ucode_tlv_api_t)31,
/* API Set 1 */
+   IWL_UCODE_TLV_API_NEW_BEACON_TEMPLATE   = (__force 
iwl_ucode_tlv_api_t)34,
IWL_UCODE_TLV_API_NEW_RX_STATS  = (__force 
iwl_ucode_tlv_api_t)35,
 
NUM_IWL_UCODE_TLV_API
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index 8fe955d58c6e..cb4e311b059f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -923,6 +923,19 @@ static u32 iwl_mvm_find_ie_offset(u8 *beacon, u8 eid, u32 
frame_size)
return ie - beacon;
 }
 
+static u8 iwl_mvm_mac_ctxt_get_lowest_rate(struct ieee80211_tx_info *info,
+  struct ieee80211_vif *vif)
+{
+   u8 rate;
+
+   if (info->band == NL80211_BAND_5GHZ || vif->p2p)
+   rate = IWL_FIRST_OFDM_RATE;
+   else
+   rate = IWL_FIRST_CCK_RATE;
+
+   return rate;
+}
+
 static void iwl_mvm_mac_ctxt_set_tx(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
struct sk_buff *beacon,
@@ -930,7 +943,8 @@ static void iwl_mvm_mac_ctxt_set_tx(struct iwl_mvm *mvm,
 {
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
struct ieee80211_tx_info *info;
-   u32 rate, tx_flags;
+   u8 rate;
+   u32 tx_flags;
 
info = IEEE80211_SKB_CB(beacon);
 
@@ -955,14 +969,12 @@ static void iwl_mvm_mac_ctxt_set_tx(struct iwl_mvm *mvm,
cpu_to_le32(BIT(mvm->mgmt_last_antenna_idx) <<
RATE_MCS_ANT_POS);
 
-   if (info->band == NL80211_BAND_5GHZ || vif->p2p) {
-   rate = IWL_FIRST_OFDM_RATE;
-   } else {
-   rate = IWL_FIRST_CCK_RATE;
-   tx->rate_n_flags |= cpu_to_le32(RATE_MCS_CCK_MSK);
-   }
+   rate = iwl_mvm_mac_ctxt_get_lowest_rate(info, vif);
 
tx->rate_n_flags |= cpu_to_le32(iwl_mvm_mac80211_idx_to_hwrate(rate));
+   if (rate == IWL_FIRST_CCK_RATE)
+   tx->rate_n_flags |= cpu_to_le32(RATE_MCS_CCK_MSK);
+
 }
 
 static int iwl_mvm_mac_ctxt_send_beacon_cmd(struct iwl_mvm *mvm,
@@ -1033,19 +1045,27 @@ static int iwl_mvm_mac_ctxt_send_beacon_v7(struct 
iwl_mvm *mvm,
sizeof(beacon_cmd));
 }
 

[PATCH v2 4/19] iwlwifi: mvm: add debugfs to force CT-kill

[Luca Coelho]

From: Chaya Rachel Ivgi 

CT-kill is a thermal-based "RF-kill", which disables the NIC
completely if the temperature gets too high, in order to avoid damage.

Add a debugfs entry to simulate high temperatures, in order to test
CT-kill flows in the driver without having to physically heat the
device up.

Signed-off-by: Chaya Rachel Ivgi 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 14 ++
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c  |  2 +-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
index 29f1d1807415..0b5cae54b86b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
@@ -114,6 +114,18 @@ static ssize_t iwl_dbgfs_stop_ctdp_write(struct iwl_mvm 
*mvm, char *buf,
return ret ?: count;
 }
 
+static ssize_t iwl_dbgfs_force_ctkill_write(struct iwl_mvm *mvm, char *buf,
+   size_t count, loff_t *ppos)
+{
+   if (!iwl_mvm_firmware_running(mvm) ||
+   mvm->fwrt.cur_fw_img != IWL_UCODE_REGULAR)
+   return -EIO;
+
+   iwl_mvm_enter_ctkill(mvm);
+
+   return count;
+}
+
 static ssize_t iwl_dbgfs_tx_flush_write(struct iwl_mvm *mvm, char *buf,
size_t count, loff_t *ppos)
 {
@@ -1641,6 +1653,7 @@ MVM_DEBUGFS_READ_WRITE_FILE_OPS(prph_reg, 64);
 /* Device wide debugfs entries */
 MVM_DEBUGFS_READ_FILE_OPS(ctdp_budget);
 MVM_DEBUGFS_WRITE_FILE_OPS(stop_ctdp, 8);
+MVM_DEBUGFS_WRITE_FILE_OPS(force_ctkill, 8);
 MVM_DEBUGFS_WRITE_FILE_OPS(tx_flush, 16);
 MVM_DEBUGFS_WRITE_FILE_OPS(sta_drain, 8);
 MVM_DEBUGFS_WRITE_FILE_OPS(send_echo_cmd, 8);
@@ -1828,6 +1841,7 @@ int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct 
dentry *dbgfs_dir)
MVM_DEBUGFS_ADD_FILE(nic_temp, dbgfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(ctdp_budget, dbgfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(stop_ctdp, dbgfs_dir, S_IWUSR);
+   MVM_DEBUGFS_ADD_FILE(force_ctkill, dbgfs_dir, S_IWUSR);
MVM_DEBUGFS_ADD_FILE(stations, dbgfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(bt_notif, dbgfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(bt_cmd, dbgfs_dir, S_IRUSR);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h 
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 8b6238e1c7ea..a6983042d3b8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1755,6 +1755,7 @@ void iwl_mvm_thermal_exit(struct iwl_mvm *mvm);
 void iwl_mvm_set_hw_ctkill_state(struct iwl_mvm *mvm, bool state);
 int iwl_mvm_get_temp(struct iwl_mvm *mvm, s32 *temp);
 void iwl_mvm_ct_kill_notif(struct iwl_mvm *mvm, struct iwl_rx_cmd_buffer *rxb);
+void iwl_mvm_enter_ctkill(struct iwl_mvm *mvm);
 int iwl_mvm_send_temp_report_ths_cmd(struct iwl_mvm *mvm);
 int iwl_mvm_ctdp_command(struct iwl_mvm *mvm, u32 op, u32 budget);
 
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 3f143402cf7f..8876c2abc440 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -71,7 +71,7 @@
 
 #define IWL_MVM_TEMP_NOTIF_WAIT_TIMEOUTHZ
 
-static void iwl_mvm_enter_ctkill(struct iwl_mvm *mvm)
+void iwl_mvm_enter_ctkill(struct iwl_mvm *mvm)
 {
struct iwl_mvm_tt_mgmt *tt = >thermal_throttle;
u32 duration = tt->params.ct_kill_duration;
-- 
2.13.2

[PATCH v2 2/3] iwlwifi: mvm: start mac queues when deferred tx frames are purged

[Luca Coelho]

From: Avraham Stern 

In AP mode, if a station is removed just as it is adding a new stream,
the queue in question will remain stopped and no more TX will happen
in this queue, leading to connection failures and other problems.

This is because under DQA, when tx is deferred because a queue needs
to be allocated, the mac queue for that TID is stopped until the new
stream is added.  If at this point the station that this stream
belongs to is removed, all the deferred tx frames are purged, but the
mac queue is not restarted. As a result, all following tx on this
queue will not be transmitted.

Fix this by starting the relevant mac queues when the deferred tx
frames are purged.

Fixes: 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of 
queues")
Signed-off-by: Avraham Stern 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index c7b1e58e3384..ce901be5fba8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2597,8 +2597,18 @@ static void iwl_mvm_purge_deferred_tx_frames(struct 
iwl_mvm *mvm,
spin_lock_bh(_sta->lock);
for (i = 0; i <= IWL_MAX_TID_COUNT; i++) {
tid_data = _sta->tid_data[i];
-   while ((skb = __skb_dequeue(_data->deferred_tx_frames)))
+
+   while ((skb = __skb_dequeue(_data->deferred_tx_frames))) {
+   struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+
+   /*
+* The first deferred frame should've stopped the MAC
+* queues, so we should never get a second deferred
+* frame for the RA/TID.
+*/
+   iwl_mvm_start_mac_queues(mvm, info->hw_queue);
ieee80211_free_txskb(mvm->hw, skb);
+   }
}
spin_unlock_bh(_sta->lock);
 }
-- 
2.13.2