RE: [PATCH v8] Add new mac80211 driver mwlwifi.

[David Lin]

> From: linux-wireless-ow...@vger.kernel.org
> [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Baumann,
> Christoph (C.)
> Sent: Wednesday, June 29, 2016 9:45 PM
> To: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH v8] Add new mac80211 driver mwlwifi.
> 
> Hello David,
> 
> I tried this new driver and it worked for me (board based on Renesas R-Car
> H3).
> But Inoticed that the data rates are asymmetrical (seen from the device):
>   * iperf -c (mainly TX): 598 Kbits/sec to 2.67 Mbits/sec
>   * iperf -s (mainly RX): 64.4 Mbits/sec to 69.2 Mbits/sec
>

Please check https://github.com/kaloz/mwlwifi to get latest firmware and 
configuration sample.

If you still get problem, please open an issue on 
https://github.com/kaloz/mwlwifi.

You can get HW, driver and firmware information via "cat 
/sys/kernel/debug/ieee80211/phy0/mwlwifi/info".

Please specify your configuration and test environment.

Thanks,
David

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

Re: [PATCH v3] mac80211: Encrypt "Group addressed privacy" action frames

[Masashi Honma]

On 2016年06月30日 01:25, Johannes Berg wrote:

[please don't quote everything to add a single line]
I applied it today, but forgot to say so. 


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

Re: [PATCH v3 2/3] ath9k: add a helper to get the string representation of ath_bus_type

[Martin Blumenstingl]

On Mon, Jun 27, 2016 at 12:26 PM, Felix Fietkau  wrote:
> On 2016-06-24 14:34, Martin Blumenstingl wrote:
>> Signed-off-by: Martin Blumenstingl 
>> ---
>> this is a new patch which didn't exist in v2 yet, it prepares the new
>> function ath_bus_type_to_string which will be used in patch #3
>>
>>  drivers/net/wireless/ath/ath.h  |  2 ++
>>  drivers/net/wireless/ath/main.c | 15 +++
>>  2 files changed, 17 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
>> index da7a7c8..be0d292 100644
>> --- a/drivers/net/wireless/ath/ath.h
>> +++ b/drivers/net/wireless/ath/ath.h
>> @@ -327,4 +327,6 @@ static inline const char *ath_opmode_to_string(enum 
>> nl80211_iftype opmode)
>>  }
>>  #endif
>>
>> +const char *ath_bus_type_to_string(enum ath_bus_type bustype);
>> +
>>  #endif /* ATH_H */
>> diff --git a/drivers/net/wireless/ath/main.c 
>> b/drivers/net/wireless/ath/main.c
>> index 338d723..90427cb 100644
>> --- a/drivers/net/wireless/ath/main.c
>> +++ b/drivers/net/wireless/ath/main.c
>> @@ -90,3 +90,18 @@ void ath_printk(const char *level, const struct 
>> ath_common* common,
>>   va_end(args);
>>  }
>>  EXPORT_SYMBOL(ath_printk);
>> +
>> +const char *ath_bus_type_to_string(enum ath_bus_type bustype)
>> +{
>> + switch (bustype) {
>> + case ATH_PCI:
>> + return "pci";
>> + case ATH_AHB:
>> + return "ahb";
>> + case ATH_USB:
>> + return "usb";
>> + default:
>> + return "unknown";
>> + }
>> +}
>> +EXPORT_SYMBOL(ath_bus_type_to_string);
> Why not simply add a const char* array with ath_bus_type as index?
Would you add this const char* array directly in ath.h or would you
define it as extern there and set it in main.c?
I would still provide the ath_bus_type_to_string function, but make it
static inline in that case.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Arnd Bergmann]

On Wednesday, June 29, 2016 10:54:38 PM CEST Priit Laes wrote:
> On Wed, 2016-06-29 at 21:33 +0200, Arnd Bergmann wrote:

> > What is the size of this nvram file? As it's board specific, I wonder
> > if we can simply include it inside of the DT verbatim. I remember
> > doing that (in the pre-dtb days, on real open firmware) for the
> > "spidernet"
> > ethernet driver.
> 
> It contains a bit too much info:
> 
> This is what CubieTruck requires:
> 
> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_a
> p6210.txt

Ah, I had not realized that this is a text based interface rather than
a small binary blob with fixed offsets.

On the other hand, each line in there could be translated easily into
a separate DT property, and some of them (manfid/prodid, macaddr, ...)
look like they directly correspond to properties we already have.

As Arend said there is also the option of having a chip specific
nvram file (brcmfmac43362-sdio.txt) as a fallback when there is no
more specific module. How many of the lines in your example would
actually differ between the two? Does this affect all of them, or
just a subset that could be turned into a smaller set of DT
properties?

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

Re: [PATCH 0/2] brcmfmac: support removing AP interfaces with new fw

[Rafał Miłecki]

On 29 June 2016 at 21:54, Rafał Miłecki  wrote:
> This is the latest patchset needed to get brcmfmac working reasonably well
> with BCM4366.
>
> Both patches were already sent as V2 RFC (10 days ago), there were no more
> comments since then and this is the same code as in V2 RFC. I was mostly 
> waiting
> for accepting
> brcmfmac: fix lockup when removing P2P interface after event timeout
> before sending these 2 (because of dependency).
>
> Rafał Miłecki (2):
>   brcmfmac: delete interface directly in code that sent fw request
>   brcmfmac: support removing AP interfaces with "interface_remove"
>
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 39 
> +-
>  .../wireless/broadcom/brcm80211/brcmfmac/fweh.c| 10 --
>  .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  3 +-
>  3 files changed, 47 insertions(+), 5 deletions(-)

Oops, I just realized get_maintainer.pl didn't pick any ppl/ML for
this cover letter. Added them now.

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

[PATCH 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

[Rafał Miłecki]

New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove"
for removing interfaces. Try to use this method on cfg80211 request. In
case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this
will just result in firmware rejecting command and this won't change any
behavior.

Signed-off-by: Rafał Miłecki 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 39 +-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index a5db953..6e6066a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -785,12 +785,48 @@ s32 brcmf_notify_escan_complete(struct 
brcmf_cfg80211_info *cfg,
return err;
 }
 
+static int brcmf_cfg80211_del_ap_iface(struct wiphy *wiphy,
+  struct wireless_dev *wdev)
+{
+   struct brcmf_cfg80211_info *cfg = wiphy_priv(wiphy);
+   struct net_device *ndev = wdev->netdev;
+   struct brcmf_if *ifp = netdev_priv(ndev);
+   int ret;
+   int err;
+
+   brcmf_cfg80211_arm_vif_event(cfg, ifp->vif);
+
+   err = brcmf_fil_bsscfg_data_set(ifp, "interface_remove", NULL, 0);
+   if (err) {
+   brcmf_err("interface_remove failed %d\n", err);
+   goto err_unarm;
+   }
+
+   /* wait for firmware event */
+   ret = brcmf_cfg80211_wait_vif_event(cfg, BRCMF_E_IF_DEL,
+   BRCMF_VIF_EVENT_TIMEOUT);
+   if (!ret) {
+   brcmf_err("timeout occurred\n");
+   err = -EIO;
+   goto err_unarm;
+   }
+
+   brcmf_remove_interface(ifp, true);
+
+err_unarm:
+   brcmf_cfg80211_arm_vif_event(cfg, NULL);
+   return err;
+}
+
 static
 int brcmf_cfg80211_del_iface(struct wiphy *wiphy, struct wireless_dev *wdev)
 {
struct brcmf_cfg80211_info *cfg = wiphy_priv(wiphy);
struct net_device *ndev = wdev->netdev;
 
+   if (ndev && ndev == cfg_to_ndev(cfg))
+   return -ENOTSUPP;
+
/* vif event pending in firmware */
if (brcmf_cfg80211_vif_event_armed(cfg))
return -EBUSY;
@@ -807,12 +843,13 @@ int brcmf_cfg80211_del_iface(struct wiphy *wiphy, struct 
wireless_dev *wdev)
switch (wdev->iftype) {
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_STATION:
-   case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_WDS:
case NL80211_IFTYPE_MONITOR:
case NL80211_IFTYPE_MESH_POINT:
return -EOPNOTSUPP;
+   case NL80211_IFTYPE_AP:
+   return brcmf_cfg80211_del_ap_iface(wiphy, wdev);
case NL80211_IFTYPE_P2P_CLIENT:
case NL80211_IFTYPE_P2P_GO:
case NL80211_IFTYPE_P2P_DEVICE:
-- 
1.8.4.5

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

[PATCH 1/2] brcmfmac: delete interface directly in code that sent fw request

[Rafał Miłecki]

So far when receiving event about in-firmware-interface removal our
event worker was notifying listener and afterwards it was removing Linux
interface.

First of all it was resulting in slightly unexpected order. The listener
(del_virtual_intf callback) was (usually) returning with success before
we even called unregister_netdev(ice).

Please note this couldn't be simply fixed by changing order of calls in
brcmf_fweh_handle_if_event as unregistering interface earlier could free
struct brcmf_if.

Another problem of current implementation are possible lockups. Focus on
the time slot between calling event handler and removing Linux
interface. During that time original caller may leave (unlocking rtnl
semaphore) *and* another call to the same code may be done (locking it
again). If that happens our event handler will stuck at removing Linux
interface, it won't handle another event and will block process holding
rtnl lock.

This can be simply solved by unregistering interface in a proper
callback, right after receiving confirmation event from firmware. This
only required modifying worker to don't unregister on its own if there
is someone waiting for the event.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 10 --
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c  |  3 +--
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
index 9da7a4c..79c081f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -18,6 +18,7 @@
 #include "brcmu_wifi.h"
 #include "brcmu_utils.h"
 
+#include "cfg80211.h"
 #include "core.h"
 #include "debug.h"
 #include "tracepoint.h"
@@ -182,8 +183,13 @@ static void brcmf_fweh_handle_if_event(struct brcmf_pub 
*drvr,
 
err = brcmf_fweh_call_event_handler(ifp, emsg->event_code, emsg, data);
 
-   if (ifp && ifevent->action == BRCMF_E_IF_DEL)
-   brcmf_remove_interface(ifp, false);
+   if (ifp && ifevent->action == BRCMF_E_IF_DEL) {
+   bool armed = brcmf_cfg80211_vif_event_armed(drvr->config);
+
+   /* Default handling in case no-one waits for this event */
+   if (!armed)
+   brcmf_remove_interface(ifp, false);
+   }
 }
 
 /**
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index f6241fd..66f942f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2288,8 +2288,7 @@ int brcmf_p2p_del_vif(struct wiphy *wiphy, struct 
wireless_dev *wdev)
else
err = 0;
}
-   if (err)
-   brcmf_remove_interface(vif->ifp, true);
+   brcmf_remove_interface(vif->ifp, true);
 
brcmf_cfg80211_arm_vif_event(cfg, NULL);
if (vif->wdev.iftype != NL80211_IFTYPE_P2P_DEVICE)
-- 
1.8.4.5

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

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Priit Laes]

On Wed, 2016-06-29 at 21:33 +0200, Arnd Bergmann wrote:
> On Wednesday, June 29, 2016 8:51:44 PM CEST Arend Van Spriel wrote:
> > > Typical wifi devices will have some sort of non volatile storage
> > > on board to not only store the ethernet(mac) address, but also
> > > to contain e.g. info about the antenna gain so that the firmware
> > > and/or the driver can take the antenna gain into account and
> > > ensure
> > > that they never exceed the maximum allowed broadcast strength.
> > > 
> > > However on some embedded devices there is no non-volatile storage
> > > for the wifi (for cost reasons) and instead this configuration
> > > info
> > > (which is board / pcb specific) is loaded in the form of a
> > > file which contains the contents which would normally be in the
> > > non-volatile storage.
> > > 
> > > Since we are dealing with a per-board config-file here, which is
> > > loaded from the os filesystem we really need to specify a
> > > basename
> > > here as the list of possible boards is endless, so we cannot
> > > have a lookup table in the driver.
> > 
> > As Jonas mentioned the general principle of device tree is to be
> > agnostic with regards to OS and/or driver as you undoubtedly know.
> > His
> > proposal seems like a usable solution for your problem while
> > complying
> > to the device tree principle. So instead of overriding the default
> > brcmfmac should modify it when dt specifies the "module" property,
> > ie:
> > 
> > no "module" in DT:  nvram filename = brcm/brcmfmac43362-
> > sdio.txt
> > "module=ap6210" in DT:  nvram filename = brcm/brcmfmac43362-
> > ap6210.txt
> > 
> > By the way, the example in the bindings file does not seem to
> > specify a
> > basename, but path+basename+fileext.
> 
> What is the size of this nvram file? As it's board specific, I wonder
> if we can simply include it inside of the DT verbatim. I remember
> doing that (in the pre-dtb days, on real open firmware) for the
> "spidernet"
> ethernet driver.

It contains a bit too much info:

This is what CubieTruck requires:

http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_a
p6210.txt

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

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Arnd Bergmann]

On Wednesday, June 29, 2016 8:51:44 PM CEST Arend Van Spriel wrote:
> > Typical wifi devices will have some sort of non volatile storage
> > on board to not only store the ethernet(mac) address, but also
> > to contain e.g. info about the antenna gain so that the firmware
> > and/or the driver can take the antenna gain into account and ensure
> > that they never exceed the maximum allowed broadcast strength.
> > 
> > However on some embedded devices there is no non-volatile storage
> > for the wifi (for cost reasons) and instead this configuration info
> > (which is board / pcb specific) is loaded in the form of a
> > file which contains the contents which would normally be in the
> > non-volatile storage.
> > 
> > Since we are dealing with a per-board config-file here, which is
> > loaded from the os filesystem we really need to specify a basename
> > here as the list of possible boards is endless, so we cannot
> > have a lookup table in the driver.
> 
> As Jonas mentioned the general principle of device tree is to be
> agnostic with regards to OS and/or driver as you undoubtedly know. His
> proposal seems like a usable solution for your problem while complying
> to the device tree principle. So instead of overriding the default
> brcmfmac should modify it when dt specifies the "module" property, ie:
> 
> no "module" in DT:  nvram filename = brcm/brcmfmac43362-sdio.txt
> "module=ap6210" in DT:  nvram filename = brcm/brcmfmac43362-ap6210.txt
> 
> By the way, the example in the bindings file does not seem to specify a
> basename, but path+basename+fileext.

What is the size of this nvram file? As it's board specific, I wonder
if we can simply include it inside of the DT verbatim. I remember
doing that (in the pre-dtb days, on real open firmware) for the "spidernet"
ethernet driver.

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

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Arend Van Spriel]

On 29-6-2016 20:51, Arend Van Spriel wrote:
> On 29-6-2016 20:01, Hans de Goede wrote:
>> Hi,
>>
>> On 29-06-16 19:00, Kalle Valo wrote:
>>> Hans de Goede  writes:
>>>
 Hi,

 On 29-06-16 16:42, Jonas Gorski wrote:
> Hi,
>
> On 29 June 2016 at 16:04, Hans de Goede  wrote:
>> Add a brcm,nvram_file_name dt property to allow overruling the default
>> nvram filename for sdio devices. The idea is that we can specify a
>> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
>> with an ap6210 wifi sdio module and ship this in linux-firmware, so
>> that wifi will work out of the box, without requiring users to find
>> and then manually install the right nvram file for their board.
>
> Directly defining a filename doesn't seem like a good OS-agnostic
> approach. Maybe an alternative would be to add a model-property to the
> nodes (this is allowed) and make brcmfmac to request
> "FWFILENAME-" as firmware if set? That would leave it to the OS
> on how the filename is set.

 It only defines the base-filename, not the entire path, how / where
 this file is searched for / loaded-from is then left up to the os
>>>
>>> It's still a bad idea. The filename, including the path, should be
>>> created in the driver. Can't you provide chipname (or similar) via
>>> device tree and then the driver can choose what image to use?
>>
>> No, the driver already does that, but this is not ...
>>
>>> Can you tell more about the naming the firmware image, how does it work
>>> exactly?
>>
>> About firmware, this is about the nvram file which is board specific,
>> rather then chip specific.
> 
> The nvram filename is determined pretty much the same as the firmware
> filename, but indeed the nvram data is board specific. This is main
> reason why we do not submit nvram files to linux-firmware, because we
> simply do not have those files.
> 
>> Typical wifi devices will have some sort of non volatile storage
>> on board to not only store the ethernet(mac) address, but also
>> to contain e.g. info about the antenna gain so that the firmware
>> and/or the driver can take the antenna gain into account and ensure
>> that they never exceed the maximum allowed broadcast strength.
>>
>> However on some embedded devices there is no non-volatile storage
>> for the wifi (for cost reasons) and instead this configuration info
>> (which is board / pcb specific) is loaded in the form of a
>> file which contains the contents which would normally be in the
>> non-volatile storage.
>>
>> Since we are dealing with a per-board config-file here, which is
>> loaded from the os filesystem we really need to specify a basename
>> here as the list of possible boards is endless, so we cannot
>> have a lookup table in the driver.

As a note: For BT Marcel was playing with the idea of having a lookup
table on the file system which would be loaded by the driver.

> As Jonas mentioned the general principle of device tree is to be
> agnostic with regards to OS and/or driver as you undoubtedly know. His
> proposal seems like a usable solution for your problem while complying
> to the device tree principle. So instead of overriding the default
> brcmfmac should modify it when dt specifies the "module" property, ie:
> 
> no "module" in DT:nvram filename = brcm/brcmfmac43362-sdio.txt
> "module=ap6210" in DT:nvram filename = brcm/brcmfmac43362-ap6210.txt
> 
> By the way, the example in the bindings file does not seem to specify a
> basename, but path+basename+fileext.

Hans,

Another btw: Kalle has taken over maintainer job from John.

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

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Arend Van Spriel]

On 29-6-2016 20:01, Hans de Goede wrote:
> Hi,
> 
> On 29-06-16 19:00, Kalle Valo wrote:
>> Hans de Goede  writes:
>>
>>> Hi,
>>>
>>> On 29-06-16 16:42, Jonas Gorski wrote:
 Hi,

 On 29 June 2016 at 16:04, Hans de Goede  wrote:
> Add a brcm,nvram_file_name dt property to allow overruling the default
> nvram filename for sdio devices. The idea is that we can specify a
> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
> with an ap6210 wifi sdio module and ship this in linux-firmware, so
> that wifi will work out of the box, without requiring users to find
> and then manually install the right nvram file for their board.

 Directly defining a filename doesn't seem like a good OS-agnostic
 approach. Maybe an alternative would be to add a model-property to the
 nodes (this is allowed) and make brcmfmac to request
 "FWFILENAME-" as firmware if set? That would leave it to the OS
 on how the filename is set.
>>>
>>> It only defines the base-filename, not the entire path, how / where
>>> this file is searched for / loaded-from is then left up to the os
>>
>> It's still a bad idea. The filename, including the path, should be
>> created in the driver. Can't you provide chipname (or similar) via
>> device tree and then the driver can choose what image to use?
> 
> No, the driver already does that, but this is not ...
> 
>> Can you tell more about the naming the firmware image, how does it work
>> exactly?
> 
> About firmware, this is about the nvram file which is board specific,
> rather then chip specific.

The nvram filename is determined pretty much the same as the firmware
filename, but indeed the nvram data is board specific. This is main
reason why we do not submit nvram files to linux-firmware, because we
simply do not have those files.

> Typical wifi devices will have some sort of non volatile storage
> on board to not only store the ethernet(mac) address, but also
> to contain e.g. info about the antenna gain so that the firmware
> and/or the driver can take the antenna gain into account and ensure
> that they never exceed the maximum allowed broadcast strength.
> 
> However on some embedded devices there is no non-volatile storage
> for the wifi (for cost reasons) and instead this configuration info
> (which is board / pcb specific) is loaded in the form of a
> file which contains the contents which would normally be in the
> non-volatile storage.
> 
> Since we are dealing with a per-board config-file here, which is
> loaded from the os filesystem we really need to specify a basename
> here as the list of possible boards is endless, so we cannot
> have a lookup table in the driver.

As Jonas mentioned the general principle of device tree is to be
agnostic with regards to OS and/or driver as you undoubtedly know. His
proposal seems like a usable solution for your problem while complying
to the device tree principle. So instead of overriding the default
brcmfmac should modify it when dt specifies the "module" property, ie:

no "module" in DT:  nvram filename = brcm/brcmfmac43362-sdio.txt
"module=ap6210" in DT:  nvram filename = brcm/brcmfmac43362-ap6210.txt

By the way, the example in the bindings file does not seem to specify a
basename, but path+basename+fileext.

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

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Hi,

On 29-06-16 19:00, Kalle Valo wrote:

Hans de Goede  writes:


Hi,

On 29-06-16 16:42, Jonas Gorski wrote:

Hi,

On 29 June 2016 at 16:04, Hans de Goede  wrote:

Add a brcm,nvram_file_name dt property to allow overruling the default
nvram filename for sdio devices. The idea is that we can specify a
board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
with an ap6210 wifi sdio module and ship this in linux-firmware, so
that wifi will work out of the box, without requiring users to find
and then manually install the right nvram file for their board.


Directly defining a filename doesn't seem like a good OS-agnostic
approach. Maybe an alternative would be to add a model-property to the
nodes (this is allowed) and make brcmfmac to request
"FWFILENAME-" as firmware if set? That would leave it to the OS
on how the filename is set.


It only defines the base-filename, not the entire path, how / where
this file is searched for / loaded-from is then left up to the os


It's still a bad idea. The filename, including the path, should be
created in the driver. Can't you provide chipname (or similar) via
device tree and then the driver can choose what image to use?


No, the driver already does that, but this is not ...


Can you tell more about the naming the firmware image, how does it work
exactly?


About firmware, this is about the nvram file which is board specific,
rather then chip specific.

Typical wifi devices will have some sort of non volatile storage
on board to not only store the ethernet(mac) address, but also
to contain e.g. info about the antenna gain so that the firmware
and/or the driver can take the antenna gain into account and ensure
that they never exceed the maximum allowed broadcast strength.

However on some embedded devices there is no non-volatile storage
for the wifi (for cost reasons) and instead this configuration info
(which is board / pcb specific) is loaded in the form of a
file which contains the contents which would normally be in the
non-volatile storage.

Since we are dealing with a per-board config-file here, which is
loaded from the os filesystem we really need to specify a basename
here as the list of possible boards is endless, so we cannot
have a lookup table in the driver.

Regards,

Hans



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

Re: [linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name

[Hans de Goede]

HI,

On 29-06-16 19:01, Kalle Valo wrote:

Hans de Goede  writes:


The cubietruck uses an ap6210 sdio wifi module, set brcm,nvram_file_name
to brcmfmac43362-ap6210.txt so that we can ship the ap6210 specific
nvram file in linunx-firmware to get the wifi to work out of the box
without users needing to download and install the nvram file themselves.

Note a downside of this patch is that users who have already manually
installed the nvram file will need to rename it.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 1 +
 1 file changed, 1 insertion(+)


I can't apply .dts changes so better to send them in a separate
patchset.


Maxime Ripard who is in the Cc maintains the dts files
in question, I've send these as one set because I find
that sending out actual dts usage examples helps.

Regards,

Hans

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

Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Kalle Valo]

Hans de Goede  writes:

> Hi,
>
> On 29-06-16 16:42, Jonas Gorski wrote:
>> Hi,
>>
>> On 29 June 2016 at 16:04, Hans de Goede  wrote:
>>> Add a brcm,nvram_file_name dt property to allow overruling the default
>>> nvram filename for sdio devices. The idea is that we can specify a
>>> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
>>> with an ap6210 wifi sdio module and ship this in linux-firmware, so
>>> that wifi will work out of the box, without requiring users to find
>>> and then manually install the right nvram file for their board.
>>
>> Directly defining a filename doesn't seem like a good OS-agnostic
>> approach. Maybe an alternative would be to add a model-property to the
>> nodes (this is allowed) and make brcmfmac to request
>> "FWFILENAME-" as firmware if set? That would leave it to the OS
>> on how the filename is set.
>
> It only defines the base-filename, not the entire path, how / where
> this file is searched for / loaded-from is then left up to the os

It's still a bad idea. The filename, including the path, should be
created in the driver. Can't you provide chipname (or similar) via
device tree and then the driver can choose what image to use?

Can you tell more about the naming the firmware image, how does it work
exactly?

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

Re: [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name

[Kalle Valo]

Hans de Goede  writes:

> The cubietruck uses an ap6210 sdio wifi module, set brcm,nvram_file_name
> to brcmfmac43362-ap6210.txt so that we can ship the ap6210 specific
> nvram file in linunx-firmware to get the wifi to work out of the box
> without users needing to download and install the nvram file themselves.
>
> Note a downside of this patch is that users who have already manually
> installed the nvram file will need to rename it.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 1 +
>  1 file changed, 1 insertion(+)

I can't apply .dts changes so better to send them in a separate
patchset.

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

Re: [PATCH v3] mac80211: Encrypt "Group addressed privacy" action frames

[Johannes Berg]

On Thu, 2016-06-30 at 00:08 +0900, Masashi Honma wrote:
[please don't quote everything to add a single line]

> Is there any comment about this ?
> 

I applied it today, but forgot to say so. Sorry about that.

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

Re: wlcore: reconfigure sta rates on authorization

[Kalle Valo]

Guy Mishol  wrote:
> Since stations can now be added before association
> (NL80211_FEATURE_FULL_AP_CLIENT_STATE support),
> no supported rates are set when the station is added
> to the fw, resulting in fw recovery.
> 
> Fix it by first configuring the AP basic rates as
> the station configured rates (when the station is
> first added to the driver), and after the station
> was authorized re-configure it, now with the actual
> supported rates.
> 
> Signed-off-by: Guy Mishol 

Thanks, 1 patch applied to wireless-drivers-next.git:

535633a5ba4e wlcore: reconfigure sta rates on authorization

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9186155/

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

Re: brcmfmac: add missing break when deleting P2P_DEVICE

[Kalle Valo]

Rafał Miłecki wrote:
> We obviously don't want to fall through in that switch. With this change
> 1) We wait for event (triggered by p2p_disc) as expected
> 2) We remove interface manually on timeout
> 3) We return 0 on success instead of -ENOTSUPP
> 
> Signed-off-by: Rafał Miłecki 

Thanks, 1 patch applied to wireless-drivers-next.git:

20856adf2280 brcmfmac: add missing break when deleting P2P_DEVICE

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9185903/

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

Re: brcmfmac: include also core.h header in cfg80211.h

[Kalle Valo]

Rafał Miłecki wrote:
> This header provides two inline functions using struct brcmf_if so we
> need core.h to avoid:
> 
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h: In function 
> ‘ndev_to_prof’:
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h:368:13: error: 
> dereferencing pointer to incomplete type
>   return >vif->profile;
>  ^
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h: In function 
> ‘ndev_to_vif’:
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h:374:12: error: 
> dereferencing pointer to incomplete type
>   return ifp->vif;
> ^
> 
> Signed-off-by: Rafał Miłecki 

Thanks, 1 patch applied to wireless-drivers-next.git:

bda9d01427f5 brcmfmac: include also core.h header in cfg80211.h

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9185755/

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

Re: brcmfmac: use const char * for interface name in brcmf_add_if

[Kalle Valo]

Rafał Miłecki wrote:
> This function can work just fine with const pointer, it only calls
> alloc_netdev which take const as well. Moreover it makes this function
> more flexible as some cfg80211 callback may provide const char * as
> well, e.g. add_virtual_intf. This will be needed for more advanced
> interface management.
> 
> Signed-off-by: Rafał Miłecki 

Thanks, 1 patch applied to wireless-drivers-next.git:

54264e7ea09a brcmfmac: use const char * for interface name in brcmf_add_if

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9183453/

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

Re: [REBASED] brcmfmac: fix lockup when removing P2P interface after event timeout

[Kalle Valo]

Rafał Miłecki wrote:
> Removing P2P interface is handled by sending a proper request to the
> firmware. On success firmware triggers an event and driver's handler
> removes a matching interface.
> 
> However on event timeout we remove interface directly from the cfg80211
> callback. Current code doesn't handle this case correctly as it always
> assumes rtnl to be unlocked.
> 
> Fix it by adding an extra rtnl_locked parameter to functions and calling
> unregister_netdevice when needed.
> 
> Signed-off-by: Rafał Miłecki 

Thanks, 1 patch applied to wireless-drivers-next.git:

b50ddfa8530e brcmfmac: fix lockup when removing P2P interface after event 
timeout

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9183337/

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

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:50 PM, Krishna Chaitanya
 wrote:
> On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
>> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
>> wrote:
>>>
>>> From: Chaitanya T K 
>>>
>>> If peer support reception of STBC and LDPC, enable them for better
>>> performance.
>>>
>>> Signed-off-by: Chaitanya TK 
>>> ---
>>>  include/linux/ieee80211.h  |1 +
>>>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>>>  2 files changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
>>> index b118744..4d01130 100644
>>> --- a/include/linux/ieee80211.h
>>> +++ b/include/linux/ieee80211.h
>>> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>>>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>>>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>>>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
>>> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
>>> 0x0800
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
>>> 0x1000
>>>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
>>> diff --git a/net/mac80211/rc80211_minstrel_ht.c
>>> b/net/mac80211/rc80211_minstrel_ht.c
>>> index 30fbabf..e2fcdea 100644
>>> --- a/net/mac80211/rc80211_minstrel_ht.c
>>> +++ b/net/mac80211/rc80211_minstrel_ht.c
>>> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> struct minstrel_ht_sta_priv *msp = priv_sta;
>>> struct minstrel_ht_sta *mi = >ht;
>>> struct ieee80211_mcs_info *mcs = >ht_cap.mcs;
>>> -   u16 sta_cap = sta->ht_cap.cap;
>>> +   u16 ht_cap = sta->ht_cap.cap;
>>> struct ieee80211_sta_vht_cap *vht_cap = >vht_cap;
>>> int use_vht;
>>> int n_supported = 0;
>>> int ack_dur;
>>> int stbc;
>>> int i;
>>> +   bool ldpc;
>>>
>>> /* fall back to the old minstrel for legacy stations */
>>> if (!sta->ht_cap.ht_supported)
>>> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> }
>>> mi->sample_tries = 4;
>>>
>>> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
>>> enough */
>>> if (!use_vht) {
>>> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> IEEE80211_HT_CAP_RX_STBC_SHIFT;
>>> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>>
>>> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> +   ldpc = true;
>>> +   } else {
>>> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
>>> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
>>> +
>>> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
>>> +   ldpc = true;
>>> }
>>>
>>> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>> +   if (ldpc)
>>> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +
>>
>>
>> Here you are using ldpc uninitialized.
>>
>>
>> As for the idea, ldpc and stbc support/enable in HT and VHT being
>> independant and tx_flags being shared by all the info.rates, you cannot use
>> it as you are trying to (e.g. you might end up asking lower layers to send
>> stbc/vht with a hw only supporting stbc/ht or/and trying to send stbc/vht
>> with inappropriate advertised vht caps).
> The design in minstrel is it checks only for peers capabilities and it doesn't
> check local hw capabilities (except for those in MCS_GROUPS), so minstrel
> just informs the we can use STBC/LDPC, its HW's decision whether to
> actually use or not.
>> This stems from the STBC/LDPC CTL flags being a mac80211_tx_info_flags, this
>> is what should be changed.
> I understand the problem here, if all rates are same then its no problem.
> But if some rates are HT and some are VHT, then we might end up in problem.
>
> To solve this, we need to move this to mac80211_rate_control_flags so that
> we can convey per rate info.
Karl/Johannes,

Any thoughts on this? This impacts all drivers, so it would be good
to finalize on design before submitting patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/8] wireless: airo: rename 'register' variable

[Kalle Valo]

Arnd Bergmann  wrote:
> 'register' is a keyword in C and cannot be used in place of a
> variable name, as shown by this -Wextra warning:
> 
> drivers/net/wireless/cisco/airo.c:1105:29: error: 'register' is not at 
> beginning of declaration [-Werror=old-style-declaration]
> 
> This replaces the 'register' keyword with a 'reg' identifier in
> the declaration, which matches the definition and has the intended
> meaning.
> 
> Signed-off-by: Arnd Bergmann 

Thanks, 3 patches applied to wireless-drivers-next.git:

88e97c32068f wireless: airo: rename 'register' variable
2a063835ce7c wireless: brcmsmac: fix old-style declaration
6f07e0f12a57 wireless: ipw2200: fix old-style declaration

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9180951/

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

Re: [1/6] mwifiex: Fix an issue spotted by KASAN

[Kalle Valo]

Amitkumar Karwar  wrote:
> From: Ganapathi Bhat 
> 
> When an association command is sent to firmware but the process is
> killed before the command response arrives, driver will try to
> access bss_desc which is already freed. This issue is fixed by
> checking return value of bss_start.
> 
> Signed-off-by: Amitkumar Karwar 

Thanks, 6 patches applied to wireless-drivers-next.git:

4699fc3f2dcb mwifiex: Fix an issue spotted by KASAN
a9c790ba23eb mwifiex: factor out mwifiex_cancel_scan
dec277f781ce mwifiex: cancel pending scan during disconnect
437322ea2a36 mwifiex: fix system hang problem after resume
568fb26ec8be mwifiex: fix AP unable to start in VHT40 problem
7311ea850079 mwifiex: fix AP start problem for newly added interface

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9180805/

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

Re: mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Kalle Valo]

Prasun Maiti  wrote:
> The two members min_scan_time and max_scan_time of structure
> "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> are assigned directtly from firmware without endian conversion handling.
> So, wrong datas will get saved in big-endian systems.
> 
> This patch converts the values into cpu's byte order before assigning them
> into the local members.
> 
> Signed-off-by: Prasun Maiti 

I would like to see Reviewed-by from someone else before I apply this.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9179811/

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

Re: [v2] rtlwifi: use s8 instead of char

[Kalle Valo]

Arnd Bergmann  wrote:
> Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
> incorrect code that results from 'char' being unsigned here, e.g.
> 
> realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited 
> range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8188ee/dm.c:1070:22: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8192ce/trx.c:54:16: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8192cu/mac.c:601:16: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8192de/trx.c:53:16: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8192ee/phy.c:1268:12: error: comparison is always true due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8192se/rf.c:150:20: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8723be/dm.c:877:29: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8723be/phy.c:386:16: error: comparison is always true due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8821ae/dm.c:1514:38: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8821ae/phy.c:1558:11: error: comparison is always false 
> due to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8821ae/phy.c:386:24: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/rtl8821ae/trx.c:55:12: error: comparison is always false due 
> to limited range of data type [-Werror=type-limits]
> realtek/rtlwifi/stats.c:31:16: error: comparison is always false due to 
> limited range of data type [-Werror=type-limits]
> 
> This patch changes all uses of 'char' in this driver that refer to
> 8-bit integers to use 's8' instead, which is signed on all architectures.
> 
> Signed-off-by: Arnd Bergmann 

Thanks, 1 patch applied to wireless-drivers-next.git:

08aba42fcc7e rtlwifi: use s8 instead of char

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9179539/

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

Re: wlcore: sdio: Fix crash on wlcore_probe_of when failing to parse/map irq

[Kalle Valo]

Bruno Herrera  wrote:
> pdev_data pointer is being freed with kfree but the pointer is not dynamic 
> allocated.
> 
> Signed-off-by: Bruno Herrera 

Thanks, 1 patch applied to wireless-drivers-next.git:

6edc119ed3b5 wlcore: sdio: Fix crash on wlcore_probe_of when failing to 
parse/map irq

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9168709/

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

Re: libertas: Add spinlock to avoid race condition

[Kalle Valo]

Pavel Andrianov  wrote:
> lbs_mac_event_disconnected may free priv->currenttxskb
> while lbs_hard_start_xmit accesses to it.
> The patch adds a spinlock for mutual exclusion.
> 
> Tested on OLPC XO-1 (usb8388) and XO-1.5 (sd8686) with v4.7-rc3.
> 
> Confirmed that lbs_mac_event_disconnected is being called on the
> station when hostapd on access point is given SIGHUP.
> 
> Signed-off-by: Pavel 
> Tested-by: James Cameron 
> Acked-by: Vaishali Thakkar 

Thanks, 1 patch applied to wireless-drivers-next.git:

f52b041aed77 libertas: Add spinlock to avoid race condition

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9178477/

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

Re: [1/4] rtl8xxxu: Add bit definitions for REG_USB_SPECIAL_OPTION

[Kalle Valo]

Jes Sorensen  wrote:
> From: Jes Sorensen 
> 
> Documentation for enabling USB aggregation and whether to select
> interrupt or bulk delivery of interrupt events.
> 
> Signed-off-by: Jes Sorensen 

Thanks, 3 patches applied to wireless-drivers-next.git:

e4ac0a8ac8ba rtl8xxxu: Add bit definitions for REG_USB_SPECIAL_OPTION
08eca32ebc89 rtl8xxxu: Add additional documentation for RX DMA registers
2b9c9f52dc03 rtl8xxxu: tuse %*ph to dump buffers

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9167727/

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

Re: libertas_tf: Remove create_workqueue

[Kalle Valo]

Bhaktipriya Shridhar  wrote:
> alloc_workqueue replaces deprecated create_workqueue().
> 
> A dedicated workqueue has been used since the workitem (viz
> >cmd_work per priv, which maps to lbtf_cmd_work) is involved in
> actual command processing and may be used on a memory reclaim path.
> The workitems require forward progress under memory pressure and hence,
> WQ_MEM_RECLAIM has been set. Since there are only a fixed number of work
> items, explicit concurrency limit is unnecessary here.
> 
> Signed-off-by: Bhaktipriya Shridhar 
> Acked-by: Tejun Heo 

Thanks, 1 patch applied to wireless-drivers-next.git:

452fa86e9806 libertas_tf: Remove create_workqueue

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9162447/

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

Re: brcmfmac: slightly simplify building interface combinations

[Kalle Valo]

Rafał Miłecki wrote:
> This change reorders some operations in brcmf_setup_ifmodes in hope to
> make it simpler:
> 1) It allocates arrays right before filling them. This way it's easier
>to follow requested array length as it's immediately followed by
>code filling it. It's easier to check e.g. why we need 4 entries for
>P2P. Other than that it deduplicates some checks (e.g. for P2P).
> 2) It reorders code to first prepare limits and then define a new combo.
>Previously this was mixed (e.g. we were setting num of channels
>before preparing limits).
> 3) It modifies mbss code to use i variable just like other combos do.
> 
> Signed-off-by: Rafał Miłecki 
> Acked-by: Arend van Spriel 

Thanks, 1 patch applied to wireless-drivers-next.git:

f568adac7d1a brcmfmac: slightly simplify building interface combinations

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9162267/

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

Issue with mwifiex

[Baumann, Christoph (C.)]

Hello,

testing mwifiex with iperf I ran into an issue with the bandwidth in RX and TX 
direction.
If I run iperf as UDP server on the target I can get a throughput of up to 90 
MBits/s.
With changed directions I have to limit the bandwidth to 10 MBits/s to keep 
things stable.
Above that limit I get this:
"
[  778.872505] NETDEV WATCHDOG: mlan0 (mwifiex_pcie): transmit queue 1 timed out
[  778.879734] [ cut here ]
[  778.884376] WARNING: CPU: 4 PID: 0 at net/sched/sch_generic.c:306 
dev_watchdog+0x2b0/0x2b8
[  778.892653] Modules linked in: mwifiex_pcie mwifiex cfg80211
[  778.898346] 
[  778.899840] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.6.0 #17
[  778.905766] Hardware name:  board based on r8a7795 (DT)
[  778.912650] task: ffc6fb0eb200 ti: ffc6fb10 task.ti: 
ffc6fb10
[  778.920143] PC is at dev_watchdog+0x2b0/0x2b8
[  778.924504] LR is at dev_watchdog+0x2b0/0x2b8
[  778.928864] pc : [] lr : [] pstate: 
2145
[  778.936268] sp : ffc6fff3fe50
[  778.939583] x29: ffc6fff3fe50 x28: 0001 
[  778.944912] x27: 0008 x26: ff800860d12c 
[  778.950241] x25:  x24: 0004 
[  778.955569] x23: ffc6fb337800 x22: ffc6fb3363a0 
[  778.960899] x21: 0004 x20: ffc6fb336000 
[  778.966228] x19: ff8008a25000 x18: 000e 
[  778.971556] x17: 0001 x16: 0007 
[  778.976885] x15: 000e x14: 756f2064656d6974 
[  778.982214] x13: 2031206575657571 x12: 2074696d736e6172 
[  778.987543] x11: 74203a2965696370 x10: 5f7865696669776d 
[  778.992872] x9 : 2820306e616c6d20 x8 : 3a474f4448435441 
[  778.998200] x7 : 572056454454454e x6 :  
[  779.003529] x5 : ffe0 x4 :  
[  779.008858] x3 : ff8008a294d0 x2 : 34c6 
[  779.014186] x1 : ffc6fb10 x0 : 0041 
[  779.019515] 
[  779.021003] ---[ end trace d756986f0e6354bf ]---
[  779.025624] Call trace:
[  779.028073] Exception stack(0xffc6fff3fc90 to 0xffc6fff3fdb0)
[  779.034523] fc80:   ff8008a25000 
ffc6fb336000
[  779.042365] fca0: ffc6fff3fe50 ff800860d3dc ff8008a26bd8 
ffc6fb10
[  779.050207] fcc0: 0001 ff8008ab4a98 ffc6fff3fd70 
ff80080e09b4
[  779.058049] fce0: ff80080e097c ffc6fb336000 0004 
ffc6fb3363a0
[  779.065891] fd00: ffc6fb337800 0004  
ff800860d12c
[  779.073732] fd20: 0008 0001 0041 
ffc6fb10
[  779.081574] fd40: 34c6 ff8008a294d0  
ffe0
[  779.089416] fd60:  572056454454454e 3a474f4448435441 
2820306e616c6d20
[  779.097257] fd80: 5f7865696669776d 74203a2965696370 2074696d736e6172 
2031206575657571
[  779.105098] fda0: 756f2064656d6974 000e
[  779.109981] [] dev_watchdog+0x2b0/0x2b8
[  779.115398] [] call_timer_fn.isra.27+0x24/0x78
[  779.121413] [] run_timer_softirq+0x18c/0x1f8
[  779.127259] [] __do_softirq+0x104/0x208
[  779.132665] [] irq_exit+0x88/0xc8
[  779.137551] [] __handle_domain_irq+0x64/0xac
[  779.143393] [] gic_handle_irq+0x50/0x9c
[  779.148797] Exception stack(0xffc6fff40050 to 0xffc6fff40170)
[  779.155246] 0040:   ffc6fb103e20 
ff8008a26bd8
[  779.163088] 0060: ffc6fb103f40 ff8008086780 6145 

[  779.170929] 0080: ffc6fb103f40 ffc6fb103e20  

[  779.178771] 00a0: ffc6fa72bb40   

[  779.186612] 00c0:    

[  779.194453] 00e0:    

[  779.202295] 0100:    

[  779.210136] 0120:    

[  779.217976] 0140:    

[  779.225816] 0160:  
[  779.230702] [] el1_irq+0xa0/0x10c
[  779.235586] [] arch_cpu_idle+0x10/0x18
[  779.240907] [] default_idle_call+0x18/0x2c
[  779.246574] [] cpu_startup_entry+0x198/0x1ec
[  779.252416] [] secondary_start_kernel+0x17c/0x1c8
[  779.258693] [<4808281c>] 0x4808281c
[  779.262898] mwifiex_pcie :01:00.0: 4295082589 : Tx timeout(#1), 
bss_type-num = 0-0
[  784.872503] mwifiex_pcie :01:00.0: 4295083992 : Tx timeout(#2), 
bss_type-num = 0-0
[  794.872499] mwifiex_pcie :01:00.0: 4295086492 : Tx timeout(#3), 
bss_type-num = 0-0
"

Any ideas what the cause might be?
I also tried the alternative driver. It had no crashes, but also showed a 
significant asymmetrical behaviour regarding RX/TX.




Regards,
Christoph
--
To unsubscribe from this list: send the line 

Re: [PATCH v8] Add new mac80211 driver mwlwifi.

[Baumann, Christoph (C.)]

Hello David,

I tried this new driver and it worked for me (board based on Renesas R-Car H3).
But Inoticed that the data rates are asymmetrical (seen from the device):
* iperf -c (mainly TX): 598 Kbits/sec to 2.67 Mbits/sec
* iperf -s (mainly RX): 64.4 Mbits/sec to 69.2 Mbits/sec



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

Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Hi,

On 29-06-16 16:42, Jonas Gorski wrote:

Hi,

On 29 June 2016 at 16:04, Hans de Goede  wrote:

Add a brcm,nvram_file_name dt property to allow overruling the default
nvram filename for sdio devices. The idea is that we can specify a
board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
with an ap6210 wifi sdio module and ship this in linux-firmware, so
that wifi will work out of the box, without requiring users to find
and then manually install the right nvram file for their board.


Directly defining a filename doesn't seem like a good OS-agnostic
approach. Maybe an alternative would be to add a model-property to the
nodes (this is allowed) and make brcmfmac to request
"FWFILENAME-" as firmware if set? That would leave it to the OS
on how the filename is set.


It only defines the base-filename, not the entire path, how / where
this file is searched for / loaded-from is then left up to the os

Regards,

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

Re: [PATCH v3] mac80211: Encrypt "Group addressed privacy" action frames

[Masashi Honma]

On 2016年06月22日 19:55, Masashi Honma wrote:
> Previously, the action frames to group address was not encrypted. But
> [1] "Table 8-38 Category values" indicates "Mesh" and "Multihop" category
> action frames should be encrypted (Group addressed privacy == yes). And the
> encyption key should be MGTK ([1] 10.13 Group addressed robust management 
> frame
> procedures). So this patch modifies the code to make it suitable for spec.
>
> [1] IEEE Std 802.11-2012
>
> Signed-off-by: Masashi Honma 
> ---
>  include/linux/ieee80211.h | 32 
>  net/mac80211/rx.c |  7 ++-
>  net/mac80211/tx.c |  6 +-
>  3 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index b118744..7c0771a 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -19,6 +19,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -2487,6 +2488,37 @@ static inline bool ieee80211_is_public_action(struct 
> ieee80211_hdr *hdr,
>  }
>  
>  /**
> + * _ieee80211_is_group_privacy_action - check if frame is a group addressed
> + * privacy action frame
> + * @hdr: the frame
> + */
> +static inline bool _ieee80211_is_group_privacy_action(struct ieee80211_hdr 
> *hdr)
> +{
> + struct ieee80211_mgmt *mgmt;
> +
> + if (!ieee80211_is_action(hdr->frame_control) ||
> + !is_multicast_ether_addr(hdr->addr1))
> + return false;
> +
> + mgmt = (struct ieee80211_mgmt *)hdr;
> +
> + return mgmt->u.action.category == WLAN_CATEGORY_MESH_ACTION ||
> + mgmt->u.action.category == WLAN_CATEGORY_MULTIHOP_ACTION;
> +}
> +
> +/**
> + * ieee80211_is_group_privacy_action - check if frame is a group addressed
> + * privacy action frame
> + * @skb: the skb containing the frame, length will be checked
> + */
> +static inline bool ieee80211_is_group_privacy_action(struct sk_buff *skb)
> +{
> + if (skb->len < IEEE80211_MIN_ACTION_SIZE)
> + return false;
> + return _ieee80211_is_group_privacy_action((void *)skb->data);
> +}
> +
> +/**
>   * ieee80211_tu_to_usec - convert time units (TU) to microseconds
>   * @tu: the TUs
>   */
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 5e65e83..2300c0f 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1624,8 +1624,13 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
>   if (mmie_keyidx < NUM_DEFAULT_KEYS ||
>   mmie_keyidx >= NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS)
>   return RX_DROP_MONITOR; /* unexpected BIP keyidx */
> - if (rx->sta)
> + if (rx->sta) {
> + if (ieee80211_is_group_privacy_action(skb) &&
> + test_sta_flag(rx->sta, WLAN_STA_MFP))
> + return RX_DROP_MONITOR;
> +
>   rx->key = rcu_dereference(rx->sta->gtk[mmie_keyidx]);
> + }
>   if (!rx->key)
>   rx->key = rcu_dereference(rx->sdata->keys[mmie_keyidx]);
>   } else if (!ieee80211_has_protected(fc)) {
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 2030443..e194df6 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -590,6 +590,9 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
>   else if (tx->sta &&
>(key = rcu_dereference(tx->sta->ptk[tx->sta->ptk_idx])))
>   tx->key = key;
> + else if (ieee80211_is_group_privacy_action(tx->skb) &&
> + (key = rcu_dereference(tx->sdata->default_multicast_key)))
> + tx->key = key;
>   else if (ieee80211_is_mgmt(hdr->frame_control) &&
>is_multicast_ether_addr(hdr->addr1) &&
>ieee80211_is_robust_mgmt_frame(tx->skb) &&
> @@ -622,7 +625,8 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
>   case WLAN_CIPHER_SUITE_GCMP_256:
>   if (!ieee80211_is_data_present(hdr->frame_control) &&
>   !ieee80211_use_mfp(hdr->frame_control, tx->sta,
> -tx->skb))
> +tx->skb) &&
> + !ieee80211_is_group_privacy_action(tx->skb))
>   tx->key = NULL;
>   else
>   skip_hw = (tx->key->conf.flags &

Is there any comment about this ?


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

Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Jonas Gorski]

Hi,

On 29 June 2016 at 16:04, Hans de Goede  wrote:
> Add a brcm,nvram_file_name dt property to allow overruling the default
> nvram filename for sdio devices. The idea is that we can specify a
> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
> with an ap6210 wifi sdio module and ship this in linux-firmware, so
> that wifi will work out of the box, without requiring users to find
> and then manually install the right nvram file for their board.

Directly defining a filename doesn't seem like a good OS-agnostic
approach. Maybe an alternative would be to add a model-property to the
nodes (this is allowed) and make brcmfmac to request
"FWFILENAME-" as firmware if set? That would leave it to the OS
on how the filename is set.


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

[PATCH 4/4] ARM: dts: sun5i-a10s-auxtek-t004: Set brcm,nvram_file_name

[Hans de Goede]

The auxtek t004 uses a toc9002 sdio wifi module, the android nvram file
for this is for an older firmware which does not work with the mainline
kernel driver.

So we set brcm,nvram_file_name to brcmfmac43362-ap6210.txt which
works fine for this wifi module.

Setting brcm,nvram_file_name allows us to ship the ap6210 specific nvram
file in linux-firmware to get the wifi to work out of the box without
users needing to download and install the nvram file themselves.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts 
b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
index a790ec8..e15d1ef 100644
--- a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
@@ -118,6 +118,12 @@
non-removable;
cap-sdio-irq;
status = "okay";
+
+   brcmf: bcrmf@1 {
+   reg = <1>;
+   compatible = "brcm,bcm4329-fmac";
+   brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
+   };
 };
 
  {
-- 
2.7.4

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

[PATCH 3/4] ARM: dts: sun7i-a20-wits-pro-a20-dkt: Set brcm,nvram_file_name

[Hans de Goede]

The wits pro uses an ap6476 sdio wifi module, we do not have a nvram file
for this, so set brcm,nvram_file_name to brcmfmac43362-ap6210.txt which
works fine for this wifi module.

Setting brcm,nvram_file_name allows us to ship the ap6210 specific nvram
file in linux-firmware to get the wifi to work out of the box without
users needing to download and install the nvram file themselves.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts 
b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
index dc31d47..3c5455a9 100644
--- a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
+++ b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
@@ -140,6 +140,7 @@
brcmf: bcrmf@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
+   brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
interrupt-parent = <>;
interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>; /* PH10 / EINT10 */
interrupt-names = "host-wake";
-- 
2.7.4

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

[PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Add a brcm,nvram_file_name dt property to allow overruling the default
nvram filename for sdio devices. The idea is that we can specify a
board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
with an ap6210 wifi sdio module and ship this in linux-firmware, so
that wifi will work out of the box, without requiring users to find
and then manually install the right nvram file for their board.

Signed-off-by: Hans de Goede 
---
 .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt  | 2 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c   | 2 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 ++
 include/linux/platform_data/brcmfmac.h  | 2 ++
 4 files changed, 12 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
index 5dbf169..2ba13a6 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -11,6 +11,7 @@ Required properties:
 Optional properties:
  - brcm,drive-strength : drive strength used for SDIO pins on device in mA
(default = 6).
+ - brcm,nvram_file_name : name of the nvram file to load
  - interrupt-parent : the phandle for the interrupt controller to which the
device interrupts are connected.
  - interrupts : specifies attributes for the out-of-band interrupt (host-wake).
@@ -34,6 +35,7 @@ mmc3: mmc@01c12000 {
brcmf: bcrmf@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
+   brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
interrupt-parent = <>;
interrupts = <10 8>; /* PH10 / EINT10 */
interrupt-names = "host-wake";
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index 425c41d..a054122 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -36,6 +36,8 @@ void brcmf_of_probe(struct device *dev, struct 
brcmfmac_sdio_pd *sdio)
if (of_property_read_u32(np, "brcm,drive-strength", ) == 0)
sdio->drive_strength = val;
 
+   of_property_read_string(np, "brcm,nvram_file_name", >nvram_name);
+
/* make sure there are interrupts defined in the node */
if (!of_find_property(np, "interrupts", NULL))
return;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 67e69bf..2655409 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4201,6 +4201,12 @@ struct brcmf_sdio *brcmf_sdio_probe(struct 
brcmf_sdio_dev *sdiodev)
if (ret)
goto fail;
 
+   if (sdiodev->settings->bus.sdio.nvram_name) {
+   strlcpy(sdiodev->nvram_name,
+   sdiodev->settings->bus.sdio.nvram_name,
+   BRCMF_FW_NAME_LEN);
+   }
+
ret = brcmf_fw_get_firmwares(sdiodev->dev, BRCMF_FW_REQUEST_NVRAM,
 sdiodev->fw_name, sdiodev->nvram_name,
 brcmf_sdio_firmware_callback);
diff --git a/include/linux/platform_data/brcmfmac.h 
b/include/linux/platform_data/brcmfmac.h
index 1d30bf2..a5515dd 100644
--- a/include/linux/platform_data/brcmfmac.h
+++ b/include/linux/platform_data/brcmfmac.h
@@ -65,6 +65,7 @@ enum brcmf_bus_type {
  * the target drive strength, the exact drive strength
  * which will be used depends on the capabilities of the
  * device.
+ * @nvram_name:name of nvram file to load.
  * @oob_irq_supported: does the board have support for OOB interrupts. SDIO
  * in-band interrupts are relatively slow and for having
  * less overhead on interrupt processing an out of band
@@ -91,6 +92,7 @@ enum brcmf_bus_type {
 struct brcmfmac_sdio_pd {
int txglomsz;
unsigned intdrive_strength;
+   const char  *nvram_name;
booloob_irq_supported;
unsigned intoob_irq_nr;
unsigned long   oob_irq_flags;
-- 
2.7.4

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

[PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name

[Hans de Goede]

The cubietruck uses an ap6210 sdio wifi module, set brcm,nvram_file_name
to brcmfmac43362-ap6210.txt so that we can ship the ap6210 specific
nvram file in linunx-firmware to get the wifi to work out of the box
without users needing to download and install the nvram file themselves.

Note a downside of this patch is that users who have already manually
installed the nvram file will need to rename it.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts 
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 83f39b0..fda1da4 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -199,6 +199,7 @@
brcmf: bcrmf@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
+   brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
interrupt-parent = <>;
interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>; /* PH10 / EINT10 */
interrupt-names = "host-wake";
-- 
2.7.4

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

Re: pull-request: mac80211 2016-06-29-v2

[David Miller]

From: Johannes Berg 
Date: Wed, 29 Jun 2016 12:02:46 +0200

> Sorry to be sending a new pull request, but Felix had just submitted a
> fairly important fix and I decided I should send it on quickly.
> 
> Now thus we have two fixes, one for the mesh refcounting issue and one
> for an issue with the ethertype/length field being too long when it's
> used as a length, during A-MSDU decapsulation.
> 
> Let me know if there's any problem.

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

[PATCH] mwifiex: fix scan_block flag handling

[Amitkumar Karwar]

scan_block flag is used to block scan operation when 4 way handshake
is in progress. Sometimes it doesn't get cleared due to incomplete
association. An example is assoc request/response is done, but add key
operation get canceled in some corner cases. As a result, further
association/scan operations are blocked.

This patch fixes the problem by clearing scan_block flag.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Xinming Hu 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index ff948a9..bbc0cfc 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2209,6 +2209,9 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy, struct 
net_device *dev,
return -EALREADY;
}
 
+   if (priv->scan_block)
+   priv->scan_block = false;
+
if (adapter->surprise_removed || adapter->is_cmd_timedout) {
mwifiex_dbg(adapter, ERROR,
"%s: Ignore connection.\t"
@@ -2427,6 +2430,9 @@ mwifiex_cfg80211_scan(struct wiphy *wiphy,
return -EBUSY;
}
 
+   if (!priv->wdev.current_bss && priv->scan_block)
+   priv->scan_block = false;
+
if (!mwifiex_stop_bg_scan(priv))
cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
 
-- 
1.9.1

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

[PATCH] mac80211: fix fq lockdep warnings

[Michal Kazior]

Some lockdep assertions were not fulfilled and
resulted in a kernel warning/call trace if driver
used intermediate software queues (e.g. ath10k).

Existing code sequences should've guranteed safety
but it's always good to be extra careful.

The call trace could look like this:

 [ 237.335805] [ cut here ]
 [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 
fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) 
mac80211(E) cfg80211(E)
 [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: GW   E   
4.7.0-rc4-wt-ath+ #1377
 [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD 
Ver. F.04 01/27/2010
 [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e  eff85de0 
c1081075
 [ 237.335928]  c1ab91f0 0003 0781 f901574e 0016 f8fbabad f8fbabad 
0016
 [ 237.335938]  eb24ff60  ef3886c0 eff85df4 c10810ba 0009  

 [ 237.335948] Call Trace:
 [ 237.335953]  [] dump_stack+0x76/0xb4
 [ 237.335957]  [] __warn+0xe5/0x100
 [ 237.336002]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336046]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336053]  [] warn_slowpath_null+0x2a/0x30
 [ 237.336095]  [] fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336137]  [] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
 [ 237.336180]  [] fq_reset.constprop.59+0x2a/0x50 [mac80211]
 [ 237.336222]  [] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
 [ 237.336258]  [] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
 [ 237.336275]  [] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
 [ 237.336292]  [] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
 [ 237.336301]  [] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
 [ 237.336307]  [] pci_device_remove+0x38/0xb0
 ...

Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows")
Fixes: fa962b92120b ("mac80211: implement fair queueing per txq")
Tested-by: Kalle Valo 
Reported-by: Kalle Valo 
Signed-off-by: Michal Kazior 
---

Notes:
v1:
 - added Tested-by [Kalle]
 - swapped first/last name in Reported-by to match Tested-by
 - improve commit log

 net/mac80211/tx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index fa8d38eb9236..91461c415525 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1449,7 +1449,9 @@ int ieee80211_txq_setup_flows(struct ieee80211_local 
*local)
local->cvars = kcalloc(fq->flows_cnt, sizeof(local->cvars[0]),
   GFP_KERNEL);
if (!local->cvars) {
+   spin_lock_bh(>lock);
fq_reset(fq, fq_skb_free_func);
+   spin_unlock_bh(>lock);
return -ENOMEM;
}
 
@@ -1469,7 +1471,9 @@ void ieee80211_txq_teardown_flows(struct ieee80211_local 
*local)
kfree(local->cvars);
local->cvars = NULL;
 
+   spin_lock_bh(>lock);
fq_reset(fq, fq_skb_free_func);
+   spin_unlock_bh(>lock);
 }
 
 struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
-- 
2.1.4

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

[PATCH] ath10k: disable wake_tx_queue for older devices

[Michal Kazior]

Ideally wake_tx_queue should be used regardless as
it is a requirement for reducing bufferbloat and
implementing airtime fairness in the future.

However some setups (typically low-end platforms
hosting QCA988X) suffer performance regressions
with the current wake_tx_queue implementation.
Therefore disable it unless it is really
beneficial with current codebase (which is when
firmware supports smart pull-push tx scheduling).

Signed-off-by: Michal Kazior 
---

Notes:
v1:
 - improve commit log

 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 24 ++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9dbd7a..de580af2e5ef 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -667,6 +667,7 @@ struct ath10k_fw_components {
 struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
+   struct ieee80211_ops *ops;
struct device *dev;
u8 mac_addr[ETH_ALEN];
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a168f7c0..958bc6c91aac 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7471,21 +7471,32 @@ static const struct ieee80211_channel 
ath10k_5ghz_channels[] = {
 struct ath10k *ath10k_mac_create(size_t priv_size)
 {
struct ieee80211_hw *hw;
+   struct ieee80211_ops *ops;
struct ath10k *ar;
 
-   hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, _ops);
-   if (!hw)
+   ops = kmemdup(_ops, sizeof(ath10k_ops), GFP_KERNEL);
+   if (!ops)
return NULL;
 
+   hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, ops);
+   if (!hw) {
+   kfree(ops);
+   return NULL;
+   }
+
ar = hw->priv;
ar->hw = hw;
+   ar->ops = ops;
 
return ar;
 }
 
 void ath10k_mac_destroy(struct ath10k *ar)
 {
+   struct ieee80211_ops *ops = ar->ops;
+
ieee80211_free_hw(ar->hw);
+   kfree(ops);
 }
 
 static const struct ieee80211_iface_limit ath10k_if_limits[] = {
@@ -7919,6 +7930,15 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_warn(ar, "failed to initialise DFS pattern 
detector\n");
}
 
+   /* Current wake_tx_queue implementation imposes a significant
+* performance penalty in some setups. The tx scheduling code needs
+* more work anyway so disable the wake_tx_queue unless firmware
+* supports the pull-push mechanism.
+*/
+   if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
+ ar->running_fw->fw_file.fw_features))
+   ar->ops->wake_tx_queue = NULL;
+
ret = ath_regd_init(>ath_common.regulatory, ar->hw->wiphy,
ath10k_reg_notifier);
if (ret) {
-- 
2.1.4

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

pull-request: mac80211 2016-06-29-v2

[Johannes Berg]

Hi Dave,

Sorry to be sending a new pull request, but Felix had just submitted a
fairly important fix and I decided I should send it on quickly.

Now thus we have two fixes, one for the mesh refcounting issue and one
for an issue with the ethertype/length field being too long when it's
used as a length, during A-MSDU decapsulation.

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724:

  wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel (2016-06-09 
09:56:11 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2016-06-29-v2

for you to fetch changes up to c041778c966c92c964033f1cdfee60a9f2b5e465:

  cfg80211: fix proto in ieee80211_data_to_8023 for frames without LLC header 
(2016-06-29 11:50:33 +0200)


Just two small fixes
 * fix mesh peer link counter, decrement wasn't always done at all
 * fix ethertype (length) for packets without RFC 1042 or bridge
   tunnel header


Felix Fietkau (1):
  cfg80211: fix proto in ieee80211_data_to_8023 for frames without LLC 
header

Jouni Malinen (1):
  mac80211: Fix mesh estab_plinks counting in STA removal case

 net/mac80211/mesh.c | 7 +--
 net/wireless/util.c | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Mohammed Shafi Shajakhan]

Hello Michal/ Kalle,

On Tue, Jun 28, 2016 at 08:48:38AM +0200, Michal Kazior wrote:
> On 27 June 2016 at 16:36, Mohammed Shafi Shajakhan
>  wrote:
> > Hi Michal,
> >
> > thanks for the review ..
> >
> > On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
> >> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
> >>  wrote:
> >> > From: Mohammed Shafi Shajakhan 
> >> >
> >> > For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
> >> > NULL func status (always acked/successs !!) when hostapd does a
> >> > PROBE_CLIENT via nullfunc frames when the station is powered off
> >> > abruptly (inactive timer probes client via null func after the inactive
> >> > time reaches beyond the threshold). Fix this by disabling the workaround
> >> > (getting the ACK status of NULL func frames by sending via HTT mgmt-tx
> >> >  path) introduced by the change ("ath10k: fix beacon loss handling ")
> >> > for QCA99X0 and later chipsets. The normal tx path provides the proper
> >> > ACK status for NULL data frames. As of now disable this workaround for
> >> > chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
> >> > completely get rid of this workaround for all the chipsets
> >> >
> >> > Signed-off-by: Tamizh chelvam 
> >> > Signed-off-by: Mohammed Shafi Shajakhan 
> >> > ---
> >> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
> >> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++
> >> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
> >> >  3 files changed, 10 insertions(+)
> >> >
> >> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> >> > b/drivers/net/wireless/ath/ath10k/core.c
> >> > index 689d6ce..9978e4a 100644
> >> > --- a/drivers/net/wireless/ath/ath10k/core.c
> >> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
> >> > ath10k_hw_params_list[] = {
> >> > .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
> >> > .board_size = QCA99X0_BOARD_DATA_SZ,
> >> > .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> >> > +   .disable_null_func_workaround = true,
> >>
> >> Tx completion (bugs) are firmware specific, not hardware. This should
> >> be expressed via features bits in ath10k FW API, no?
> >>
> >>
> > [shafi] Are you suggesting me to introduce something like
> > "ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?
> >
> > Also how about getting this workaround completely if Ben had fixed this in 
> > his tree,
> > will this affect older 10.2.4 ?
> 
> There's still 636.
> 
> We could probably get rid of this as long as:
>  - ath10k can express the need to use Probe Requests for AP probing
> (in client mode) and beacon loss handling purposes instead of NullFunc
> to mac80211
>  - everyone uses hostapd with disassoc_low_ack=1 with affected
> firmware revisions
>  - supplicant uses disassoc_low_ack=1 for p2p go
>  - I have no idea about mesh/ibss but they might require some work as well
> 
> Otherwise you'll introduce regressions.
>

[shafi] sure then we will disable this for 10.4 (QCA99X0 and later)

*firmware feature requires a new firmware updated this feature, so the bug
will be present for all the older firmware, please correct me if my
understanding is wrong

*We discussed wmi_op_version is not the way to go (in the sense just disable it
for 10.4 alone)

Let me know if there is any other suggestion (the existing change though bit
cleanly is very explicit regarding the chipsets that this workaround is not
needed), thank you !

regards,
shafi

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

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Johannes Berg]

> How do you want to proceed? Do you want to
> revert this patch and shall i send another patch?
> 

I'll rebase the patch out.

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

Re: [RFC/RFT] ath10k: disable wake_tx_queue for older devices

[Valo, Kalle]

Roman Yeryomin  writes:

> On 2 June 2016 at 16:14, Valo, Kalle  wrote:
>> Michal Kazior  writes:
>>
>>> Some setups suffer performance regressions with
>>> current wake_tx_queue implementation.
>>>
>>> Signed-off-by: Michal Kazior 
>>> ---
>>> Hi Roman,
>>>
>>> Can you give this patch a try and see if it helps
>>> with your performance problems, please?
>>
>> Did anyone seeing the performance regression manage to test this? It
>> would be good to get feedback, good or bad, before I push this to 4.7.
>>
>> Full patch here:
>>
>> https://patchwork.kernel.org/patch/9111981/
>
> Sorry, didn't try yet, bad timing for me :(
> Will try to test by the end of the week

Roman, did you have a chance to test this?

Michal, could you submit this patch as a formal patch, please? I think
we should take it even if Roman hasn't tested it.

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

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:52 PM, Krishna Chaitanya
 wrote:
> On Wed, Jun 29, 2016 at 1:50 PM, Krishna Chaitanya
>  wrote:
>> On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
>>> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
>>> wrote:

 From: Chaitanya T K 

 If peer support reception of STBC and LDPC, enable them for better
 performance.

 Signed-off-by: Chaitanya TK 
 ---
  include/linux/ieee80211.h  |1 +
  net/mac80211/rc80211_minstrel_ht.c |   25 +
  2 files changed, 18 insertions(+), 8 deletions(-)

 diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
 index b118744..4d01130 100644
 --- a/include/linux/ieee80211.h
 +++ b/include/linux/ieee80211.h
 @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
 +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
 0x0800
  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
 0x1000
  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
 diff --git a/net/mac80211/rc80211_minstrel_ht.c
 b/net/mac80211/rc80211_minstrel_ht.c
 index 30fbabf..e2fcdea 100644
 --- a/net/mac80211/rc80211_minstrel_ht.c
 +++ b/net/mac80211/rc80211_minstrel_ht.c
 @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
 ieee80211_supported_band *sband,
 struct minstrel_ht_sta_priv *msp = priv_sta;
 struct minstrel_ht_sta *mi = >ht;
 struct ieee80211_mcs_info *mcs = >ht_cap.mcs;
 -   u16 sta_cap = sta->ht_cap.cap;
 +   u16 ht_cap = sta->ht_cap.cap;
 struct ieee80211_sta_vht_cap *vht_cap = >vht_cap;
 int use_vht;
 int n_supported = 0;
 int ack_dur;
 int stbc;
 int i;
 +   bool ldpc;

 /* fall back to the old minstrel for legacy stations */
 if (!sta->ht_cap.ht_supported)
 @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
 ieee80211_supported_band *sband,
 }
 mi->sample_tries = 4;

 -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
 enough */
 if (!use_vht) {
 -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
 +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
 IEEE80211_HT_CAP_RX_STBC_SHIFT;
 -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;

 -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
 -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
 +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
 +   ldpc = true;
 +   } else {
 +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
 +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
 +
 +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
 +   ldpc = true;
 }

 +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
 +   if (ldpc)
 +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
 +
>>>
>>>
>>> Here you are using ldpc uninitialized.
> yeah, will fix it.
Johannes,

How do you want to proceed? Do you want to
revert this patch and shall i send another patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cfg80211: fix proto in ieee80211_data_to_8023 for frames without LLC header

[Felix Fietkau]

The PDU length of incoming LLC frames is set to the total skb payload size
in __ieee80211_data_to_8023() of net/wireless/util.c which incorrectly
includes the length of the IEEE 802.11 header.

The resulting LLC frame header has a too large PDU length, causing the
llc_fixup_skb() function of net/llc/llc_input.c to reject the incoming
skb, effectively breaking STP.

Solve the problem by properly substracting the IEEE 802.11 frame header size
from the PDU length, allowing the LLC processor to pick up the incoming
control messages.

Special thanks to Gerry Rozema for tracking down the regression and proposing
a suitable patch.

Fixes: 2d1c304cb2d5 ("cfg80211: add function for 802.3 conversion with separate 
output buffer")
Cc: sta...@vger.kernel.org
Reported-by: Gerry Rozema 
Signed-off-by: Felix Fietkau 
---
 net/wireless/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4e809e9..2443ee3 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -509,7 +509,7 @@ static int __ieee80211_data_to_8023(struct sk_buff *skb, 
struct ethhdr *ehdr,
 * replace EtherType */
hdrlen += ETH_ALEN + 2;
else
-   tmp.h_proto = htons(skb->len);
+   tmp.h_proto = htons(skb->len - hdrlen);
 
pskb_pull(skb, hdrlen);
 
-- 
2.8.4

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

Re: [RFT] mac80211: fix fq lockdep warnings

[Valo, Kalle]

Michal Kazior  writes:

> Some lockdep assertions were not fulfilled and
> resulted in a kernel warning/call trace.
>
> Existing code sequences should've guranteed safety
> but it's always good to be extra careful.
>
> The call trace could look like this:
>
>  [ 237.335805] [ cut here ]
>  [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 
> fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) 
> mac80211(E) cfg80211(E)
>  [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: GW   E   
> 4.7.0-rc4-wt-ath+ #1377
>  [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 
> 68CDD Ver. F.04 01/27/2010
>  [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e  
> eff85de0 c1081075
>  [ 237.335928]  c1ab91f0 0003 0781 f901574e 0016 f8fbabad 
> f8fbabad 0016
>  [ 237.335938]  eb24ff60  ef3886c0 eff85df4 c10810ba 0009 
>  
>  [ 237.335948] Call Trace:
>  [ 237.335953]  [] dump_stack+0x76/0xb4
>  [ 237.335957]  [] __warn+0xe5/0x100
>  [ 237.336002]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.336046]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.336053]  [] warn_slowpath_null+0x2a/0x30
>  [ 237.336095]  [] fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.336137]  [] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
>  [ 237.336180]  [] fq_reset.constprop.59+0x2a/0x50 [mac80211]
>  [ 237.336222]  [] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
>  [ 237.336258]  [] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
>  [ 237.336275]  [] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
>  [ 237.336292]  [] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
>  [ 237.336301]  [] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
>  [ 237.336307]  [] pci_device_remove+0x38/0xb0
>  ...
>
> Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows")
> Fixes: fa962b92120b ("mac80211: implement fair queueing per txq")
> Reported-by: Valo, Kalle 
> Signed-off-by: Michal Kazior 

Tested-by: Kalle Valo 

> Can you verify this fixes call traces you're
> seeing, please?

Yup, I don't see the warnings anymore. I tried multiple times, rebooting
etc. Thanks for fixing this.

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

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:50 PM, Krishna Chaitanya
 wrote:
> On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
>> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
>> wrote:
>>>
>>> From: Chaitanya T K 
>>>
>>> If peer support reception of STBC and LDPC, enable them for better
>>> performance.
>>>
>>> Signed-off-by: Chaitanya TK 
>>> ---
>>>  include/linux/ieee80211.h  |1 +
>>>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>>>  2 files changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
>>> index b118744..4d01130 100644
>>> --- a/include/linux/ieee80211.h
>>> +++ b/include/linux/ieee80211.h
>>> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>>>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>>>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>>>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
>>> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
>>> 0x0800
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
>>> 0x1000
>>>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
>>> diff --git a/net/mac80211/rc80211_minstrel_ht.c
>>> b/net/mac80211/rc80211_minstrel_ht.c
>>> index 30fbabf..e2fcdea 100644
>>> --- a/net/mac80211/rc80211_minstrel_ht.c
>>> +++ b/net/mac80211/rc80211_minstrel_ht.c
>>> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> struct minstrel_ht_sta_priv *msp = priv_sta;
>>> struct minstrel_ht_sta *mi = >ht;
>>> struct ieee80211_mcs_info *mcs = >ht_cap.mcs;
>>> -   u16 sta_cap = sta->ht_cap.cap;
>>> +   u16 ht_cap = sta->ht_cap.cap;
>>> struct ieee80211_sta_vht_cap *vht_cap = >vht_cap;
>>> int use_vht;
>>> int n_supported = 0;
>>> int ack_dur;
>>> int stbc;
>>> int i;
>>> +   bool ldpc;
>>>
>>> /* fall back to the old minstrel for legacy stations */
>>> if (!sta->ht_cap.ht_supported)
>>> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> }
>>> mi->sample_tries = 4;
>>>
>>> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
>>> enough */
>>> if (!use_vht) {
>>> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> IEEE80211_HT_CAP_RX_STBC_SHIFT;
>>> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>>
>>> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> +   ldpc = true;
>>> +   } else {
>>> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
>>> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
>>> +
>>> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
>>> +   ldpc = true;
>>> }
>>>
>>> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>> +   if (ldpc)
>>> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +
>>
>>
>> Here you are using ldpc uninitialized.
yeah, will fix it.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
> wrote:
>>
>> From: Chaitanya T K 
>>
>> If peer support reception of STBC and LDPC, enable them for better
>> performance.
>>
>> Signed-off-by: Chaitanya TK 
>> ---
>>  include/linux/ieee80211.h  |1 +
>>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>>  2 files changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
>> index b118744..4d01130 100644
>> --- a/include/linux/ieee80211.h
>> +++ b/include/linux/ieee80211.h
>> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
>> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
>> 0x0800
>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
>> 0x1000
>>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
>> diff --git a/net/mac80211/rc80211_minstrel_ht.c
>> b/net/mac80211/rc80211_minstrel_ht.c
>> index 30fbabf..e2fcdea 100644
>> --- a/net/mac80211/rc80211_minstrel_ht.c
>> +++ b/net/mac80211/rc80211_minstrel_ht.c
>> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
>> ieee80211_supported_band *sband,
>> struct minstrel_ht_sta_priv *msp = priv_sta;
>> struct minstrel_ht_sta *mi = >ht;
>> struct ieee80211_mcs_info *mcs = >ht_cap.mcs;
>> -   u16 sta_cap = sta->ht_cap.cap;
>> +   u16 ht_cap = sta->ht_cap.cap;
>> struct ieee80211_sta_vht_cap *vht_cap = >vht_cap;
>> int use_vht;
>> int n_supported = 0;
>> int ack_dur;
>> int stbc;
>> int i;
>> +   bool ldpc;
>>
>> /* fall back to the old minstrel for legacy stations */
>> if (!sta->ht_cap.ht_supported)
>> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
>> ieee80211_supported_band *sband,
>> }
>> mi->sample_tries = 4;
>>
>> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
>> enough */
>> if (!use_vht) {
>> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
>> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
>> IEEE80211_HT_CAP_RX_STBC_SHIFT;
>> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>
>> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
>> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
>> +   ldpc = true;
>> +   } else {
>> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
>> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
>> +
>> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
>> +   ldpc = true;
>> }
>>
>> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>> +   if (ldpc)
>> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>> +
>
>
> Here you are using ldpc uninitialized.
>
>
> As for the idea, ldpc and stbc support/enable in HT and VHT being
> independant and tx_flags being shared by all the info.rates, you cannot use
> it as you are trying to (e.g. you might end up asking lower layers to send
> stbc/vht with a hw only supporting stbc/ht or/and trying to send stbc/vht
> with inappropriate advertised vht caps).
The design in minstrel is it checks only for peers capabilities and it doesn't
check local hw capabilities (except for those in MCS_GROUPS), so minstrel
just informs the we can use STBC/LDPC, its HW's decision whether to
actually use or not.
> This stems from the STBC/LDPC CTL flags being a mac80211_tx_info_flags, this
> is what should be changed.
I understand the problem here, if all rates are same then its no problem.
But if some rates are HT and some are VHT, then we might end up in problem.

To solve this, we need to move this to mac80211_rate_control_flags so that
we can convey per rate info.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Karl Beldan]

On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK  wrote:
> From: Chaitanya T K 
>
> If peer support reception of STBC and LDPC, enable them for better
> performance.
>
> Signed-off-by: Chaitanya TK 
> ---
>  include/linux/ieee80211.h  |1 +
>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>  2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index b118744..4d01130 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
> 0x0800
>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
> 0x1000
>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
> diff --git a/net/mac80211/rc80211_minstrel_ht.c 
> b/net/mac80211/rc80211_minstrel_ht.c
> index 30fbabf..e2fcdea 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct 
> ieee80211_supported_band *sband,
> struct minstrel_ht_sta_priv *msp = priv_sta;
> struct minstrel_ht_sta *mi = >ht;
> struct ieee80211_mcs_info *mcs = >ht_cap.mcs;
> -   u16 sta_cap = sta->ht_cap.cap;
> +   u16 ht_cap = sta->ht_cap.cap;
> struct ieee80211_sta_vht_cap *vht_cap = >vht_cap;
> int use_vht;
> int n_supported = 0;
> int ack_dur;
> int stbc;
> int i;
> +   bool ldpc;
>
> /* fall back to the old minstrel for legacy stations */
> if (!sta->ht_cap.ht_supported)
> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct 
> ieee80211_supported_band *sband,
> }
> mi->sample_tries = 4;
>
> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained enough 
> */
> if (!use_vht) {
> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
> IEEE80211_HT_CAP_RX_STBC_SHIFT;
> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>
> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
> +   ldpc = true;
> +   } else {
> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
> +
> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
> +   ldpc = true;
> }
>
> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
> +   if (ldpc)
> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
> +

Here you are using ldpc uninitialized.


As for the idea, ldpc and stbc support/enable in HT and VHT being
independant and tx_flags being shared by all the info.rates, you
cannot use it as you are trying to (e.g. you might end up asking lower
layers to send stbc/vht with a hw only supporting stbc/ht or/and
trying to send stbc/vht with inappropriate advertised vht caps).
This stems from the STBC/LDPC CTL flags being a
mac80211_tx_info_flags, this is what should be changed.


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

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Johannes Berg]

On Mon, 2016-06-27 at 15:23 +0530, Chaitanya TK wrote:
> From: Chaitanya T K 
> 
> If peer support reception of STBC and LDPC, enable them for better
> performance.
> 
Applied.

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

Re: [PATCH] mac80211: util: mesh is not connected properly after recovery

[Johannes Berg]

Also - your subject lines should explain the *fix*, not the *bug*

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

Re: [PATCH] mac80211: util: mesh is not connected properly after recovery

[Johannes Berg]

On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote:
> From: Maital Hahn 
> 
> In the reconfigure process for mesh interface, moved the
> reconfiguration
> of the mesh peers to be done only after restarting the beacons,
> the same as it is done for AP.
> 
> Signed-off-by: Maital Hahn 
> Acked-by: Yaniv Machani 
> 
Same here, and this also needs a description of why this is OK with
other drivers, since presumably it already works there.

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

Re: [PATCH] mac80211: rx: frames received out of order

[Johannes Berg]

On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote:
> From: Meirav Kama 
> 
> MP received data frames from another MP. Frames are forwarded
> from Rx to Tx to be transmitted to a third MP.
> Upon cloning the skb, the tx_info was zeroed, and the
> hw_queue wasn't set correctly, causing frames to be
> inserted to queue 0 (VOICE). If re-queue occurred for some
> reason, frame will be inserted to correct queue 2 (BE).
> In this case frames are now dequeued from 2 different queues and
> sent out of order.

Please rewrite this commit log in active voice, and explain the fix
too.

> Signed-off-by: Meirav Kama 
> Acked-by: Yaniv Machani 

See Julian's comment.

johannes

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

Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template

[Johannes Berg]

On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> 
>  net/mac80211/mesh.c | 33 -
>  net/mac80211/util.c |  3 ---
>  net/wireless/mesh.c |  2 +-

That's not a good patch - one change is mac80211 and the other
cfg80211.

> - .ht_opmode = IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED,
> + .ht_opmode = IEEE80211_HT_OP_MODE_PROTECTION_NONE,
> 
How are you planning to comply with 802.11 now?


The HT Protection field in a mesh STA may be set to no protection mode
only if
— All STAs detected in the primary or the secondary channel are HT
  STAs, and
— All mesh STA members of this MBSS that are one-hop neighbors of the
  transmitting mesh STA are either:
  — 20/40 MHz HT mesh STAs in a 20/40 MHz MBSS, or
  — 20 MHz HT mesh STAs in a 20 MHz MBSS.

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

Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

[Johannes Berg]

On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> From: Maital Hahn 
> 
> Some drivers (e.g. wl18xx) expect that the last stage in the
> de-initialization process will be stopping the beacons, similar to
> ap. Update ieee80211_stop_mesh() flow accordingly.
> 
How well have you tested that with other drivers?

Changing behaviour to something a single driver desires isn't
necessarily the best thing to do, since there always are multiple
drivers.

If you're able to demonstrate that it works with the other drivers I'm
willing to take that - the change makes sense after all, and it seems
drivers must support this ordering since peers are also removed
dynamically... But still. Don't just make a change like that without
even giving any indication why you think it's fine for other drivers!

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

pull-request: mac80211 2016-06-29

[Johannes Berg]

Hi Dave,

Another (pretty old) bug showed up, and I have a single fix for it
from Jouni; would be nice to still get it in, but it's in mesh which
seems to mostly have users who integrate everything themselves.

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724:

  wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel (2016-06-09 
09:56:11 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2016-06-29

for you to fetch changes up to 126e7557328a1cd576be4fca95b133a2695283ff:

  mac80211: Fix mesh estab_plinks counting in STA removal case (2016-06-28 
12:39:50 +0200)


A single fix:
 * fix mesh peer link counter, decrement wasn't always done at all


Jouni Malinen (1):
  mac80211: Fix mesh estab_plinks counting in STA removal case

 net/mac80211/mesh.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html