[PATCH 2/2] ath10k: Add copy engine register MAP for wcn3990 target

[Govind Singh]

Copy engine is a host to target communication interface
between wlan firmware and wlan wcn3990 platform driver. Add copy
engine register map for wcn3990 wlan module. This add support
for the copy engine source/destination ring configuration for
wcn3990 chipset.

Signed-off-by: Govind Singh 
---
 drivers/net/wireless/ath/ath10k/core.c |   5 ++
 drivers/net/wireless/ath/ath10k/hw.c   | 150 +
 drivers/net/wireless/ath/ath10k/hw.h   |   9 ++
 drivers/net/wireless/ath/ath10k/pci.c  |   4 +
 4 files changed, 168 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 38dbdd5..b55196c 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2474,6 +2474,11 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
struct device *dev,
ar->hw_ce_regs = _ce_regs;
ar->hw_values = _values;
break;
+   case ATH10K_HW_WCN3990:
+   ar->regs = _regs;
+   ar->hw_ce_regs = _ce_regs;
+   ar->hw_values = _values;
+   break;
default:
ath10k_err(ar, "unsupported core hardware revision %d\n",
   hw_rev);
diff --git a/drivers/net/wireless/ath/ath10k/hw.c 
b/drivers/net/wireless/ath/ath10k/hw.c
index afb0c01..a860691 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -192,6 +192,156 @@
.ce_desc_meta_data_lsb  = 4,
 };
 
+const struct ath10k_hw_regs wcn3990_regs = {
+   .rtc_soc_base_address   = 0x,
+   .rtc_wmac_base_address  = 0x,
+   .soc_core_base_address  = 0x,
+   .ce_wrapper_base_address= 0x0024C000,
+   .ce0_base_address   = 0x0024,
+   .ce1_base_address   = 0x00241000,
+   .ce2_base_address   = 0x00242000,
+   .ce3_base_address   = 0x00243000,
+   .ce4_base_address   = 0x00244000,
+   .ce5_base_address   = 0x00245000,
+   .ce6_base_address   = 0x00246000,
+   .ce7_base_address   = 0x00247000,
+   .ce8_base_address   = 0x00248000,
+   .ce9_base_address   = 0x00249000,
+   .ce10_base_address  = 0x0024A000,
+   .ce11_base_address  = 0x0024B000,
+   .soc_chip_id_address= 0x00f0,
+   .soc_reset_control_si0_rst_mask = 0x0001,
+   .soc_reset_control_ce_rst_mask  = 0x0100,
+   .ce_wrap_intr_sum_host_msi_lsb  = 0x000c,
+   .ce_wrap_intr_sum_host_msi_mask = 0x00fff000,
+   .pcie_intr_fw_mask  = 0x0010,
+};
+
+static struct ath10k_hw_ce_regs_addr_map wcn3990_src_ring = {
+   .msb= 0x0010,
+   .lsb= 0x0010,
+   .mask   = GENMASK(17, 17),
+};
+
+static struct ath10k_hw_ce_regs_addr_map wcn3990_dst_ring = {
+   .msb= 0x0012,
+   .lsb= 0x0012,
+   .mask   = GENMASK(18, 18),
+};
+
+static struct ath10k_hw_ce_regs_addr_map wcn3990_dmax = {
+   .msb= 0x,
+   .lsb= 0x,
+   .mask   = GENMASK(15, 0),
+};
+
+static struct ath10k_hw_ce_ctrl1 wcn3990_ctrl1 = {
+   .addr   = 0x0018,
+   .src_ring   = _src_ring,
+   .dst_ring   = _dst_ring,
+   .dmax   = _dmax,
+};
+
+static struct ath10k_hw_ce_regs_addr_map wcn3990_host_ie_cc = {
+   .mask   = GENMASK(0, 0),
+};
+
+static struct ath10k_hw_ce_host_ie wcn3990_host_ie = {
+   .copy_complete  = _host_ie_cc,
+};
+
+static struct ath10k_hw_ce_host_wm_regs wcn3990_wm_reg = {
+   .dstr_lmask = 0x0010,
+   .dstr_hmask = 0x0008,
+   .srcr_lmask = 0x0004,
+   .srcr_hmask = 0x0002,
+   .cc_mask= 0x0001,
+   .wm_mask= 0x001E,
+   .addr   = 0x0030,
+};
+
+static struct ath10k_hw_ce_misc_regs wcn3990_misc_reg = {
+   .axi_err= 0x0100,
+   .dstr_add_err   = 0x0200,
+   .srcr_len_err   = 0x0100,
+   .dstr_mlen_vio  = 0x0080,
+   .dstr_overflow  = 0x0040,
+   .srcr_overflow  = 0x0020,
+   .err_mask   = 0x03E0,
+   .addr   = 0x0038,
+};
+
+static struct ath10k_hw_ce_regs_addr_map wcn3990_src_wm_low = {
+   .msb= 0x,
+   .lsb= 0x0010,
+   .mask   = GENMASK(31, 16),
+};
+
+static struct ath10k_hw_ce_regs_addr_map wcn3990_src_wm_high = {
+   .msb= 0x000f,
+   .lsb= 0x,
+   .mask   = GENMASK(15, 0),
+};
+
+static struct ath10k_hw_ce_dst_src_wm_regs wcn3990_wm_src_ring = {
+ 

[PATCH 1/2] ath10k: Make CE layer bus agnostic

[Govind Singh]

Remove bus specific dependencies from CE layer
to have common CE layer across multiple targets.
This is required for adding support for WCN3990
chipset support as WCN3990 chipset uses SNOC
bus interface with Copy Engine endpoint.

Signed-off-by: Govind Singh 
---
 drivers/net/wireless/ath/ath10k/ahb.c  |   3 +-
 drivers/net/wireless/ath/ath10k/ce.c   | 299 ++---
 drivers/net/wireless/ath/ath10k/ce.h   |  30 +++-
 drivers/net/wireless/ath/ath10k/core.h |   2 +
 drivers/net/wireless/ath/ath10k/pci.c  |  51 +++---
 drivers/net/wireless/ath/ath10k/pci.h  |  14 +-
 6 files changed, 224 insertions(+), 175 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ahb.c 
b/drivers/net/wireless/ath/ath10k/ahb.c
index da770af..b36dd792 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -787,8 +787,9 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
ar_pci->mem = ar_ahb->mem;
ar_pci->mem_len = ar_ahb->mem_len;
ar_pci->ar = ar;
-   ar_pci->bus_ops = _ahb_bus_ops;
+   ar_pci->ce.bus_ops = _ahb_bus_ops;
ar_pci->targ_cpu_to_ce_addr = ath10k_ahb_qca4019_targ_cpu_to_ce_addr;
+   ar->ce_priv = _pci->ce;
 
ret = ath10k_pci_setup_resource(ar);
if (ret) {
diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index 9e620b4..3b3481c 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -16,7 +16,6 @@
  */
 
 #include "hif.h"
-#include "pci.h"
 #include "ce.h"
 #include "debug.h"
 
@@ -33,7 +32,7 @@
  * Each ring consists of a number of descriptors which specify
  * an address, length, and meta-data.
  *
- * Typically, one side of the PCIe interconnect (Host or Target)
+ * Typically, one side of the PCIe/AHB/SNOC interconnect (Host or Target)
  * controls one ring and the other side controls the other ring.
  * The source side chooses when to initiate a transfer and it
  * chooses what to send (buffer address, length). The destination
@@ -73,57 +72,71 @@
return ((offset & addr_map->mask) >> (addr_map->lsb));
 }
 
+static inline u32 ath10k_ce_read32(struct ath10k *ar, u32 offset)
+{
+   struct ath10k_ce *ce = ath10k_ce_priv(ar);
+
+   return ce->bus_ops->read32(ar, offset);
+}
+
+static inline void ath10k_ce_write32(struct ath10k *ar, u32 offset, u32 value)
+{
+   struct ath10k_ce *ce = ath10k_ce_priv(ar);
+
+   ce->bus_ops->write32(ar, offset, value);
+}
+
 static inline void ath10k_ce_dest_ring_write_index_set(struct ath10k *ar,
   u32 ce_ctrl_addr,
   unsigned int n)
 {
-   ath10k_pci_write32(ar, ce_ctrl_addr +
-   ar->hw_ce_regs->dst_wr_index_addr, n);
+   ath10k_ce_write32(ar, ce_ctrl_addr +
+ ar->hw_ce_regs->dst_wr_index_addr, n);
 }
 
 static inline u32 ath10k_ce_dest_ring_write_index_get(struct ath10k *ar,
  u32 ce_ctrl_addr)
 {
-   return ath10k_pci_read32(ar, ce_ctrl_addr +
-   ar->hw_ce_regs->dst_wr_index_addr);
+   return ath10k_ce_read32(ar, ce_ctrl_addr +
+   ar->hw_ce_regs->dst_wr_index_addr);
 }
 
 static inline void ath10k_ce_src_ring_write_index_set(struct ath10k *ar,
  u32 ce_ctrl_addr,
  unsigned int n)
 {
-   ath10k_pci_write32(ar, ce_ctrl_addr +
-   ar->hw_ce_regs->sr_wr_index_addr, n);
+   ath10k_ce_write32(ar, ce_ctrl_addr +
+ ar->hw_ce_regs->sr_wr_index_addr, n);
 }
 
 static inline u32 ath10k_ce_src_ring_write_index_get(struct ath10k *ar,
 u32 ce_ctrl_addr)
 {
-   return ath10k_pci_read32(ar, ce_ctrl_addr +
-   ar->hw_ce_regs->sr_wr_index_addr);
+   return ath10k_ce_read32(ar, ce_ctrl_addr +
+   ar->hw_ce_regs->sr_wr_index_addr);
 }
 
 static inline u32 ath10k_ce_src_ring_read_index_get(struct ath10k *ar,
u32 ce_ctrl_addr)
 {
-   return ath10k_pci_read32(ar, ce_ctrl_addr +
-   ar->hw_ce_regs->current_srri_addr);
+   return ath10k_ce_read32(ar, ce_ctrl_addr +
+   ar->hw_ce_regs->current_srri_addr);
 }
 
 static inline void ath10k_ce_src_ring_base_addr_set(struct ath10k *ar,
u32 ce_ctrl_addr,
unsigned int addr)
 {
-   ath10k_pci_write32(ar, ce_ctrl_addr +
-   ar->hw_ce_regs->sr_base_addr, addr);
+   ath10k_ce_write32(ar, ce_ctrl_addr +
+ 

Re: [PATCH v2] rtlwifi: Replace hardcode value with macro

[Souptick Joarder]

Hi Larry,

On Thu, Jun 22, 2017 at 7:05 PM, Larry Finger  wrote:
> On 06/22/2017 07:00 AM, Souptick Joarder wrote:
>>
>> In _rtl_init_mac80211(), hardcoded value for hw->max_listen_interval
>> and hw->max_rate_tries are replaced by macro.
>>
>> Signed-off-by: Souptick Joarder 
>> ---
>> Changes in v2:
>> - Signed-off was missing in previous one.
>
>
> This patch includes a comment that is not needed, but it is OK.
>
> Acked-by: Larry Finger 
>
> Larry

Any further review is required for this patch or it will be merged to
maintainer tree ?

>
>
>>
>>   drivers/net/wireless/realtek/rtlwifi/base.c | 6 +++---
>>   drivers/net/wireless/realtek/rtlwifi/base.h | 2 ++
>>   2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c
>> b/drivers/net/wireless/realtek/rtlwifi/base.c
>> index bdc3791..f45d093 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/base.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/base.c
>> @@ -422,9 +422,9 @@ static void _rtl_init_mac80211(struct ieee80211_hw
>> *hw)
>> hw->extra_tx_headroom = RTL_TX_HEADER_SIZE;
>>
>> /* TODO: Correct this value for our hw */
>> -   /* TODO: define these hard code value */
>> -   hw->max_listen_interval = 10;
>> -   hw->max_rate_tries = 4;
>> +   /* defined these hard code values */
>> +   hw->max_listen_interval = MAX_LISTEN_INTERVAL;
>> +   hw->max_rate_tries = MAX_RATE_TRIES;
>> /* hw->max_rates = 1; */
>> hw->sta_data_size = sizeof(struct rtl_sta_info);
>>
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/base.h
>> b/drivers/net/wireless/realtek/rtlwifi/base.h
>> index 02ff0c5..d03e198 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/base.h
>> +++ b/drivers/net/wireless/realtek/rtlwifi/base.h
>> @@ -65,6 +65,8 @@ enum ap_peer {
>>   #define FRAME_OFFSET_ADDRESS3 16
>>   #define FRAME_OFFSET_SEQUENCE 22
>>   #define FRAME_OFFSET_ADDRESS4 24
>> +#define MAX_LISTEN_INTERVAL 10
>> +#define MAX_RATE_TRIES  4
>>
>>   #define SET_80211_HDR_FRAME_CONTROL(_hdr, _val)   \
>> WRITEEF2BYTE(_hdr, _val)
>> --
>> 1.9.1
>>
>>
>

-Souptick

[PATCH] ieee80211: update public action codes

[peter . oh]

From: Peter Oh 

Update Public Action field values as updated in IEEE Std 802.11-2016,
so that modules/drivers can refer it.

Signed-off-by: Peter Oh 
---
 include/linux/ieee80211.h | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 6903335..91a1145 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -2113,10 +2113,43 @@ enum ieee80211_key_len {
 
 #define PMK_MAX_LEN48
 
-/* Public action codes */
+/* Public action codes (IEEE Std 802.11-2016, 9.6.8.1, Table 9-307) */
 enum ieee80211_pub_actioncode {
+   WLAN_PUB_ACTION_20_40_BSS_COEX = 0,
+   WLAN_PUB_ACTION_DSE_ENABLEMENT = 1,
+   WLAN_PUB_ACTION_DSE_DEENABLEMENT = 2,
+   WLAN_PUB_ACTION_DSE_REG_LOC_ANN = 3,
WLAN_PUB_ACTION_EXT_CHANSW_ANN = 4,
+   WLAN_PUB_ACTION_DSE_MSMT_REQ = 5,
+   WLAN_PUB_ACTION_DSE_MSMT_RESP = 6,
+   WLAN_PUB_ACTION_MSMT_PILOT = 7,
+   WLAN_PUB_ACTION_DSE_PC = 8,
+   WLAN_PUB_ACTION_VENDOR_SPECIFIC = 9,
+   WLAN_PUB_ACTION_GAS_INITIAL_REQ = 10,
+   WLAN_PUB_ACTION_GAS_INITIAL_RESP = 11,
+   WLAN_PUB_ACTION_GAS_COMEBACK_REQ = 12,
+   WLAN_PUB_ACTION_GAS_COMEBACK_RESP = 13,
WLAN_PUB_ACTION_TDLS_DISCOVER_RES = 14,
+   WLAN_PUB_ACTION_LOC_TRACK_NOTI = 15,
+   WLAN_PUB_ACTION_QAB_REQUEST_FRAME = 16,
+   WLAN_PUB_ACTION_QAB_RESPONSE_FRAME = 17,
+   WLAN_PUB_ACTION_QMF_POLICY = 18,
+   WLAN_PUB_ACTION_QMF_POLICY_CHANGE = 19,
+   WLAN_PUB_ACTION_QLOAD_REQUEST = 20,
+   WLAN_PUB_ACTION_QLOAD_REPORT = 21,
+   WLAN_PUB_ACTION_HCCA_TXOP_ADVERT = 22,
+   WLAN_PUB_ACTION_HCCA_TXOP_RESPONSE = 23,
+   WLAN_PUB_ACTION_PUBLIC_KEY = 24,
+   WLAN_PUB_ACTION_CHANNEL_AVAIL_QUERY = 25,
+   WLAN_PUB_ACTION_CHANNEL_SCHEDULE_MGMT = 26,
+   WLAN_PUB_ACTION_CONTACT_VERI_SIGNAL = 27,
+   WLAN_PUB_ACTION_GDD_ENABLEMENT_REQ = 28,
+   WLAN_PUB_ACTION_GDD_ENABLEMENT_RESP = 29,
+   WLAN_PUB_ACTION_NETWORK_CHANNEL_CONTROL = 30,
+   WLAN_PUB_ACTION_WHITE_SPACE_MAP_ANN = 31,
+   WLAN_PUB_ACTION_FTM_REQUEST = 32,
+   WLAN_PUB_ACTION_FTM = 33,
+   WLAN_PUB_ACTION_FILS_DISCOVERY = 34,
 };
 
 /* TDLS action codes */
-- 
2.7.4

Re: [PATCH 3/4] brcmfmac: rework headroom check in .start_xmit()

[Arend van Spriel]

On 27-06-17 16:09, Kalle Valo wrote:
> Arend van Spriel  writes:
> 
>> Since commit 9cc4b7cb86cb ("brcmfmac: Make skb header writable
>> before use") the headroom usage has been fixed. However, the
>> driver was keeping statistics that got lost. So reworking the
>> code so we get those driver statistics back for debugging.
>>
>> Cc: James Hughes 
>> Reviewed-by: Hante Meuleman 
>> Reviewed-by: Pieter-Paul Giesberts 
>> Reviewed-by: Franky Lin 
>> Signed-off-by: Arend van Spriel 
>> ---
>>  .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 15 --
>>  .../wireless/broadcom/brcm80211/brcmfmac/core.c| 23 
>> +++---
>>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 13 +++-
>>  3 files changed, 37 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
>> index e1a4d9e..163ddc4 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
>> @@ -113,6 +113,17 @@ struct brcmf_bus_msgbuf {
>>  
>>  
>>  /**
>> + * struct brcmf_bus_stats - bus statistic counters.
>> + *
>> + * @pktcowed: packets cowed for extra headroom/unorphan.
>> + * @pktcow_failed: packets dropped due to failed cow-ing.
>> + */
>> +struct brcmf_bus_stats {
>> +atomic_t pktcowed;
>> +atomic_t pktcow_failed;
>> +};
> 
> Same question as in the previous patch. I only see updates for these
> variables, but nobody reading them?

Hi Kalle,

You are right. My intention was to expose these to debugfs, but clearly
did not include it in this patch series. So how do you want to handle
this. Feel free to drop patch 2 and 3. I can resubmit them with
subsequent patches dealing with exposing it to debugfs if that makes
more sense.

Regards,
Arend

Re: [PATCH 05/14] mwifiex: re-register wiphy across reset

[Brian Norris]

On Thu, Jun 22, 2017 at 03:02:34PM +0200, Johannes Berg wrote:
> On Wed, 2017-06-21 at 11:27 -0700, Brian Norris wrote:

> > > Without checking the code now, it seems entirely plausible that
> > > this is
> > > holding some lock that would lock out the control path entirely,
> > > for
> > > the duration until the wiphy is actually unregistered?
> > > 
> > > Actually, you can't unregister with the relevant locks held
> > > (without
> > > causing deadlocks), so perhaps it's marking the wiphy as
> > > unavailable so
> > > that all operations fail?
> > 
> > One of the above two sounds along the right line. But it's something
> > I couldn't really figure out how to do quite right.
> > 
> > Dumb question: how would I mark the wiphy as unavailable? Is there
> > something I can do at the cfg80211 level? Or would I really have to
> > guard all the cfg80211 entry points into mwifiex with a flag or lock?
> 
> There isn't really a good way to do this. You can, of course, call
> wiphy_unregister(), but if you could do that you'd already have the
> problem solved, I think?

That's probably along the right track. There are still some things we'd
need to do properly before that though, and this is where all the
problems are so far. (Also, this is what Kalle was already objecting to;
he didn't think we should be unregistering/recreating the wiphy, but I
think he ended up softening on that a bit.)

For one, I still expect I should be removing the wireless dev's before
unregistering the wihpy, no? Otherwise, there will be existing wdevs
backed by an unregistered wiphy?

And that gets to the heart of another bug: deleting interfaces (e.g.,
"iw dev foo del") races with a lot of stuff -- like see

mwifiex_process_sta_event() ->
  EVENT_EXT_SCAN_REPORT ->
netif_running(priv->netdev)

Because mwifiex_del_virtual_intf() doesn't stop any outstanding
commands, we can be both deleting the netdev and processing scans for
it.

> I'm not really familiar enough with the context this happens in - can't
> you let all the operations that try to talk to the firmware fail
> (because the firmware is dead, or whatever) and then call
> wiphy_unregister()?

Yes, something like that, barring some of the other bugs mentioned.

> > Also, IIUC, we need to wait for all control paths to complete (or
> > cancel) before we can free up the associated resources; so just
> > marking "unavailable" isn't enough.
> 
> Yeah, I suppose so. Though if you just do all the freeing after
> wiphy_unregister() it'll do that for you?

Yes, I think so. Then part of the problem is probably that some of the
current "cancel command" logic is tied up with the "free command
structures" logic. So we're freeing some stuff too early.

Anyway, those sorts of bugs aside, IIUC the full sequence for teardown
should probably be something like:

1. Stop TX queues
2. Cancel outstanding commands (let them fail or finish, etc.) -- but
   DON'T free their backing resources yet
3. Remove wdevs
4. wiphy_unregister()
5. Free up resources

Current problems are at least:

* we don't do step 4 in the right place (if at all; see this patch)
* step 2 mixes in "free"ing resources too early

Brian

Potential byte order issue in staging/wilc1000/wilc_wfi_cfgoperations.c

[Tordek]

Hello

Line 1464 contains the following:

if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {

However Sparse complains that `ieee80211_is_action` takes a __le16
parameter. Would a cpu_to_le16 be required in this case?

If so, I'd be happy to submit a patch.

Thanks in advance

--
Guillermo O. Freschi

Re: [PATCH 05/14] mwifiex: re-register wiphy across reset

[Brian Norris]

(A little slow on follow-up here)

On Thu, Jun 22, 2017 at 02:59:49PM +0200, Johannes Berg wrote:
> On Wed, 2017-06-21 at 10:48 -0700, Brian Norris wrote:
> > 
> > Yes, that all sounds nice. But for my sake, can you describe better
> > what's actually going on there (e.g., can you point me at which code
> > does this)? 
> 
> It's much easier with mac80211, it has all the state. Basically the
> reconfig is in ieee80211_reconfig() :)

Wow, that's not exactly simple code; I expect it could be pretty
difficult to get that right today on mwifiex. The current approach
actually should be *easier* (for the kernel side) to avoid bugs, as it
should be basically the same thing as 'rmmod'. Nonetheless, there are
plenty of bugs.

Thanks for the pointer though.

> > I'm really not familiar with mac80211 (though I was aware of
> > the above general behavior). But to my knowledge, mac80211 drivers
> > keep a lot more state managed in the kernel, so it's a little easier
> > and more natural to get the driver/FW back to "the same state" than
> > it is with a full-MAC driver.
> 
> Indeed.

Brian

Re: [PATCH 21/26] iwlwifi: mvm: print base HW address during init

[Kalle Valo]

"Coelho, Luciano"  writes:

> On Tue, 2017-06-27 at 18:19 +, Coelho, Luciano wrote:
>> On Tue, 2017-06-27 at 20:36 +0300, Kalle Valo wrote:
>> > Fabio Estevam  writes:
>> > 
>> > > On Tue, Jun 27, 2017 at 2:06 PM, Kalle Valo  wrote:
>> > > 
>> > > > "crouded sniffer logs", what's that?
>> > > 
>> > > I think Luca meant 'crowded'.
>> > 
>> > Ah, makes sense. Thanks.
>> 
>> Huh, obviously a typo, sorry! Shall I fix it before my pull-req?

Up to you, I was just curious.

> And, of course, what I mean here is that sometimes you get sniffer logs
> from very crowded areas with gazillions of different MAC addresses. 
> This way we can match the logs with the sniffer a bit more easily.

Hehe, I thought you referred to "crowdsourcing" :)

-- 
Kalle Valo

Re: [PATCH 21/26] iwlwifi: mvm: print base HW address during init

[Coelho, Luciano]

On Tue, 2017-06-27 at 18:19 +, Coelho, Luciano wrote:
> On Tue, 2017-06-27 at 20:36 +0300, Kalle Valo wrote:
> > Fabio Estevam  writes:
> > 
> > > On Tue, Jun 27, 2017 at 2:06 PM, Kalle Valo  wrote:
> > > 
> > > > "crouded sniffer logs", what's that?
> > > 
> > > I think Luca meant 'crowded'.
> > 
> > Ah, makes sense. Thanks.
> 
> Huh, obviously a typo, sorry! Shall I fix it before my pull-req?

And, of course, what I mean here is that sometimes you get sniffer logs
from very crowded areas with gazillions of different MAC addresses. 
This way we can match the logs with the sniffer a bit more easily.

--
Cheers,
Luca.

Re: [PATCH 21/26] iwlwifi: mvm: print base HW address during init

[Coelho, Luciano]

On Tue, 2017-06-27 at 20:36 +0300, Kalle Valo wrote:
> Fabio Estevam  writes:
> 
> > On Tue, Jun 27, 2017 at 2:06 PM, Kalle Valo  wrote:
> > 
> > > "crouded sniffer logs", what's that?
> > 
> > I think Luca meant 'crowded'.
> 
> Ah, makes sense. Thanks.

Huh, obviously a typo, sorry! Shall I fix it before my pull-req?

--
Cheers,
Luca.

Re: [PATCH 21/26] iwlwifi: mvm: print base HW address during init

[Kalle Valo]

Fabio Estevam  writes:

> On Tue, Jun 27, 2017 at 2:06 PM, Kalle Valo  wrote:
>
>> "crouded sniffer logs", what's that?
>
> I think Luca meant 'crowded'.

Ah, makes sense. Thanks.

-- 
Kalle Valo

Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support

[Kalle Valo]

Sergey Matyukevich  writes:

> This patch implements AP_VLAN interface type support enabling
> the use of dynamic VLAN mode in hostapd.
>
> Implementation notes.
>
> 1. Passing dynamic VLAN tag to firmware
> Currently there is no established way to pass VLAN tag assigned to STA
> by Radius server to wireless driver. It is assumed that hostapd is able
> to setup all the bridging and tagging on its own. However qtnf firmware
> needs to know the assigned dynamic VLAN tags in order to perform various
> internal tasks including group key management, filtering, acceleration,
> and more.
>
> Current implementation makes use of the following workaround.
> Driver obtains dynamic VLAN tags assigned by Radius server
> from AP/VLAN interface names:
> - for primary interfaces: wlanX.Z
>   where X and Z are macid and vlan tag respectively
> - for MBSS virtual interfaces: wlanX_Y.Z
>   where X, Y, Z are macid, vifid, and vlan tag respectively
>
> Such a naming convention can be configured using
> hostapd vlan_file configuration file.
>
> 2. Packet routing to/from AP/VLAN interfaces
> Firmware operates with tagged packets after dynamic VLAN mode is
> configured. In particular, packets destined to STAs should be
> properly tagged before they can be passed to firmware. Packets
> received from STAs are properly tagged by firmware and then
> passed to wireless driver. As a result, packet routing to AP/VLAN
> interfaces is straightforward: it is enough to check VLAN tags.
>
> Normally hostapd expects untagged packets from AP/VLAN interfaces.
> Meanwhile firmware performs tagging using h/w acceleration. That
> is why it makes sense to avoid untagging packets in driver if
> they are supposed to by tagged again on host. To enable this
> behavior a new module parameter 'dyn_vlan_tagged' has been
> introduced:
>
> - dyn_vlan_tagged = 0 (default)
> In this case untagged packets are sent to and expected from AP/VLAN 
> interfaces.
> Driver tags/untags packets going to/from firmware. This behaviour is expected
> by hostapd which is able to create bridges and VLAN interfaces automatically
> when hostapd is built with CONFIG_FULL_DYNAMIC_VLAN option enabled.
>
> - dyn_vlan_tagged = 1
> In this case tagged packets are sent to and expected from AP/VLAN interfaces.
> Hostapd build option CONFIG_FULL_DYNAMIC_VLAN should be disabled. Setup of
> networking topology on host is left up to the implementers.
>
> Signed-off-by: Sergey Matyukevich 

This looks somewhat controversial to me but I'm not very familiar with
VLANs. Do other wireless drivers do something similar or how is this
usually implemented? Or not at all?

-- 
Kalle Valo

Re: [PATCH 5/8] qtnfmac: enable reporting the current operating channel

[Kalle Valo]

Sergey Matyukevich  writes:

> This patch implements all the necessary features needed to keep
> operating channel information in sync between firmware and driver:
>
> - implement cfg80211 qtnf_get_channel handler
> - implement QLINK_EVENT_FREQ_CHANGE event handling
>   using this event firmware notifies host when operating channel is changed
> - update qtnf_dump_survey
>   specify current channel in use in survey report
> - update qtnf_connect
>   pass to firmware channel number rather than frequency
>
> Signed-off-by: Sergey Matyukevich 

[...]

> +static int
> +qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
> +   const struct qlink_event_freq_change *data,
> +   u16 len)
> +{
> + struct wiphy *wiphy = priv_to_wiphy(mac);
> + struct cfg80211_chan_def chandef;
> + struct ieee80211_channel *chan;
> + struct qtnf_bss_config *bss_cfg;
> + struct qtnf_vif *vif;
> + int freq;
> + int i;
> +
> + if (len < sizeof(*data)) {
> + pr_err("payload is too short\n");
> + return -EINVAL;
> + }
> +
> + freq = le32_to_cpu(data->freq);
> + chan = ieee80211_get_channel(wiphy, freq);
> + if (!chan) {
> + pr_err("channel at %d MHz not found\n", freq);
> + return -EINVAL;
> + }
> +
> + pr_info("MAC%d switch to new channel %u MHz\n", mac->macid, freq);

Should this be a debug message? I don't see why the driver would need to
spam this every time.

-- 
Kalle Valo

Re: [PATCH 7/8] qtnfmac: implement cfg80211 channel_switch handler

[Kalle Valo]

Sergey Matyukevich  writes:

> This patch implements cfg80211 channel_switch handler enabling CSA
> channel-switch procedure.
>
> At the moment qtnfmac host driver performs only basic validation of
> the requested new channel and then sends command to firmware.
> Beacon IEs are not sent since beacon update is handled by firmware.
>
> Signed-off-by: Sergey Matyukevich 

[...]

> +static int qtnf_channel_switch(struct wiphy *wiphy, struct net_device *dev,
> +struct cfg80211_csa_settings *params)
> +{
> + struct qtnf_wmac *mac = wiphy_priv(wiphy);
> + struct qtnf_vif *vif = qtnf_netdev_get_priv(dev);
> + int ret;
> +
> + pr_info("%s: chan(%u) count(%u) radar(%u) block_tx(%u)\n", dev->name,
> + params->chandef.chan->hw_value, params->count,
> + params->radar_required, params->block_tx);

Should this be a debug message?

-- 
Kalle Valo

Re: [PATCH 8/8] qtnfmac: implement scan timeout

[Kalle Valo]

Sergey Matyukevich  writes:

> Userspace tools may hang on scan in the case when scan completion event
> is not returned by firmware. This patch implements the scan timeout
> to avoid such situation.
>
> Signed-off-by: Sergey Matyukevich 

[...]

> +static __always_inline void qtnf_wmac_lock(struct qtnf_wmac *mac)
> +{
> + mutex_lock(>mac_lock);
> +}
> +
> +static __always_inline void qtnf_wmac_unlock(struct qtnf_wmac *mac)
> +{
> + mutex_unlock(>mac_lock);
> +}

Why? These look pointless to me.

-- 
Kalle Valo

Re: [PATCH 2/8] qtnfmac: cleanup and fixes preparing AP_VLAN support

[Kalle Valo]

Sergey Matyukevich  writes:

> This patch implements various cleanups and fixes aimed to
> simplify adding AP_VLAN support to qtnfmac driver:
>
> - Remove unused flag field from qlink_intf_info
> - Add interface type to qlink_cmd_change_sta
> - Modify qtnf_cmd_send_change_sta: add interface type to command
> - Fix handling of iftype mask reported by firmware:
>   Firmware sends supported interface type rather than mask. As a result,
>   types field of ieee80211_iface_limit structure may end up having
>   multiple iftype bits set. This leads to WARN_ON from
>   wiphy_verify_combinations.
>
> Signed-off-by: Sergey Matyukevich 

Again multiple changes in one patch.

-- 
Kalle Valo

Re: [PATCH 1/8] qtnfmac: updates and fixes for regulatory support

[Kalle Valo]

Sergey Matyukevich  writes:

> This patch introduces several changes for regulatory support
> in qtnfmac driver:
>
> * Introduce support for setting regdomain from host
> New command is implemented to notify firmware about regdomain changes
> performed by host. Firmware is supposed to check requested regdomain
> changes. On success firmware enables updated hardware channel
> configuration and then host driver updates channel info for each band.
>
> * Introduce support of custom regulatory rules
> Obtain custom regulatory rules from the firmware and
> enable them during wiphy registration
>
> * Regulatory for self-managed setup
> Regdomain information needs to be registered with cfg80211
> for devices with REGULATORY_WIPHY_SELF_MANAGED flag set.
>
> * Misc fixes in regulatory code paths
>   - add missing lock in qtnf_cmd_get_mac_chan_info
>   - do not free band channel structure if channel count is the same
>   - free allocated regdomain hw_info.rd structure on detach
>
> Signed-off-by: Igor Mitsyanko 
> Signed-off-by: Sergey Matyukevich 

Each patch should contain one logical change, but here you are listing
multiple changes in the commit log which is a clear indication that's
not the case here. Is there a specific reason why you did it like this?

-- 
Kalle Valo

Re: [PATCH 21/26] iwlwifi: mvm: print base HW address during init

[Fabio Estevam]

On Tue, Jun 27, 2017 at 2:06 PM, Kalle Valo  wrote:

> "crouded sniffer logs", what's that?

I think Luca meant 'crowded'.

Re: [PATCH 21/26] iwlwifi: mvm: print base HW address during init

[Kalle Valo]

Luca Coelho  writes:

> From: Luca Coelho 
>
> It's sometimes hard to find out which HW address the iwlwifi device is
> using, for instance when reading crouded sniffer logs.  To make it
> easier, print out an info level message with the HW address as soon as
> we know it.
>
> Signed-off-by: Luca Coelho 

"crouded sniffer logs", what's that?

-- 
Kalle Valo

pull-request: iwlwifi firmwares update 2017-06-27

[Luca Coelho]

Hi Kyle,

We have some updates for our -27 firmware version (on supported devices)
and versions -29 and -31 that will be supported by the iwlwifi driver on
v4.13.

Please pull or let me know if there are any issues.

Cheers,
Luca.


The following changes since commit 7d2c913dcd1be083350d97a8cb1eba24cfacbc8a:

  ath10k: update year in license (2017-06-22 12:06:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git 
tags/iwlwifi-fw-2017-06-27

for you to fetch changes up to d392df8feda805e37022686d76be96de407a9e18:

  iwlwifi: add new firmware for 3168, 7265D, 8000C and 8265 (2017-06-27 
14:45:20 +0300)


Update and add new firmwares for 3168, 7265D, 8000C and 8265

* new -29 for 3168 and 7265D;
* new -31 for 8000C and 8265;
* updated -27 for 3168, 7265D, 8000C and 8265.


Emmanuel Grumbach (1):
  iwlwifi: update -27 firmware for 3168, 7265D, 8000C and 8265

Johannes Berg (1):
  iwlwifi: add new firmware for 3168, 7265D, 8000C and 8265

 WHENCE |  20 
 iwlwifi-3168-27.ucode  | Bin 1032168 -> 1032436 bytes
 iwlwifi-3168-29.ucode  | Bin 0 -> 1036372 bytes
 iwlwifi-7265D-27.ucode | Bin 1032452 -> 1032740 bytes
 iwlwifi-7265D-29.ucode | Bin 0 -> 1036528 bytes
 iwlwifi-8000C-27.ucode | Bin 2227284 -> 2227284 bytes
 iwlwifi-8000C-31.ucode | Bin 0 -> 2309768 bytes
 iwlwifi-8265-27.ucode  | Bin 2234528 -> 2234528 bytes
 iwlwifi-8265-31.ucode  | Bin 0 -> 2303024 bytes
 9 files changed, 16 insertions(+), 4 deletions(-)
 create mode 100644 iwlwifi-3168-29.ucode
 create mode 100644 iwlwifi-7265D-29.ucode
 create mode 100644 iwlwifi-8000C-31.ucode
 create mode 100644 iwlwifi-8265-31.ucode

[PATCH] iwlwifi: mvm: fix iwl_mvm_sar_find_wifi_pkg corner case

[Arnd Bergmann]

gcc warns about what it thinks is an uninitialized variable
access:

drivers/net/wireless/intel/iwlwifi/mvm/fw.c: In function 
'iwl_mvm_sar_find_wifi_pkg.isra.14':
drivers/net/wireless/intel/iwlwifi/mvm/fw.c:1102:5: error: 'wifi_pkg' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]

That problem cannot really happen, as we check data->package.count
to ensure that the loop is entered at least once.
However, something that can indeed happen is returning an incorrect
wifi_pkg pointer in case none of the elements are what we are looking
for.

This modifies the loop again, to only return a correct object, and
to shut up that warning.

Fixes: c386dacb4ed6 ("iwlwifi: mvm: refactor SAR init to prepare for dynamic 
SAR")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 24cc406d87ef..730c7f68c0b3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -1094,14 +1094,12 @@ static union acpi_object 
*iwl_mvm_sar_find_wifi_pkg(struct iwl_mvm *mvm,
domain = _pkg->package.elements[0];
if (domain->type == ACPI_TYPE_INTEGER &&
domain->integer.value == ACPI_WIFI_DOMAIN)
-   break;
-
-   wifi_pkg = NULL;
+   goto found;
}
 
-   if (!wifi_pkg)
-   return ERR_PTR(-ENOENT);
+   return ERR_PTR(-ENOENT);
 
+found:
return wifi_pkg;
 }
 
-- 
2.9.0

Re: brcmfmac: fix double free upon register_netdevice() failure

[Kalle Valo]

Arend Van Spriel  wrote:

> The function brcmf_net_attach() can only fail when register_netdevice()
> fails. When this happens register_netdevice() calls priv_destructor, ie.
> brcmf_cfg80211_free_netdev() freeing the vif instance. Also upon this
> failure brcmf_net_attach() calls free_netdev(). However, callers are also
> doing cleanup resulting in double free. In some places they need netdev
> private space as it holds parameters to communicate with the device. So
> we want to do the cleanup only in callers of brcmf_net_attach() by making
> the following changes:
> 
>  - set priv_destructor after register_netdevice() succeeds.
>  - remove call to free_netdev() in brcmf_net_attach().
>  - call free_netdev() in brcmf_net_detach() for unregistered netdev.
>  - add free_netdev() if brcmf_net_attach() fails for a created interface.
> 
> Fixes: cf124db566e6 ("net: Fix inconsistent teardown and release of private 
> netdev state.")
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts 
> Reviewed-by: Franky Lin 
> Signed-off-by: Arend van Spriel 

Patch applied to wireless-drivers-next.git, thanks.

dca2307ed625 brcmfmac: fix double free upon register_netdevice() failure

-- 
https://patchwork.kernel.org/patch/9807903/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 00/17] rsi: station enhancements

[Kalle Valo]

Amitkumar Karwar  writes:

> We have internal management frames(commands) sent to firmware for
> various configurations. This patch defines some common structures
> which can be shared by those frames. Key handling and regulatory
> enhancements are also includesd. With this patch series included,
> station can connect to security enabled AP and send/receive data.

Are you saying that before rsi driver was not able to connect a security
enabled AP? Just trying to understand the status.

> Prameela Rani Garnepudi (17):
>   rsi: add common structures needed for command packets
>   rsi: immediate wakeup bit and priority for TX command packets
>   rsi: Update in tx command frame radio capabilities
>   rsi: remove unnecessary check for 802.11 management packet
>   rsi: Update peer notify command frame
>   rsi: Update aggregation parameters command frame
>   rsi: Update baseband RF programming frame
>   rsi: update set_channel command frame
>   rsi: update vap capabilities command frame
>   rsi: update set_key command frame
>   rsi: set_key enhancements
>   rsi: update autorate request command frame
>   rsi: block/unblock data queues as per connection status
>   rsi: update tx command frame block/unblock data
>   rsi: Remove internal header from Tx status skb
>   rsi: Send rx filter frame to device when interface is down
>   rsi: regulatory enhancements

Also in the future please try to keep the size of patchsets in
reasonable sizes. Something like max 10-12 patches per set is usually
ok, dependinging on the size of patches of course. But anything more
than that and the review becomes too annoying.

-- 
Kalle Valo

Re: [v2] brcmfmac: Fix a memory leak in error handling path in 'brcmf_cfg80211_attach'

[Kalle Valo]

Christophe Jaillet  wrote:

> If 'wiphy_new()' fails, we leak 'ops'. Add a new label in the error
> handling path to free it in such a case.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 5c22fb85102a7 ("brcmfmac: add wowl gtk rekeying offload support")
> Signed-off-by: Christophe JAILLET 

Patch applied to wireless-drivers-next.git, thanks.

57c00f2fac51 brcmfmac: Fix a memory leak in error handling path in 
'brcmf_cfg80211_attach'

-- 
https://patchwork.kernel.org/patch/9800763/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 3/4] brcmfmac: rework headroom check in .start_xmit()

[Kalle Valo]

Arend van Spriel  writes:

> Since commit 9cc4b7cb86cb ("brcmfmac: Make skb header writable
> before use") the headroom usage has been fixed. However, the
> driver was keeping statistics that got lost. So reworking the
> code so we get those driver statistics back for debugging.
>
> Cc: James Hughes 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts 
> Reviewed-by: Franky Lin 
> Signed-off-by: Arend van Spriel 
> ---
>  .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 15 --
>  .../wireless/broadcom/brcm80211/brcmfmac/core.c| 23 
> +++---
>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 13 +++-
>  3 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index e1a4d9e..163ddc4 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -113,6 +113,17 @@ struct brcmf_bus_msgbuf {
>  
>  
>  /**
> + * struct brcmf_bus_stats - bus statistic counters.
> + *
> + * @pktcowed: packets cowed for extra headroom/unorphan.
> + * @pktcow_failed: packets dropped due to failed cow-ing.
> + */
> +struct brcmf_bus_stats {
> + atomic_t pktcowed;
> + atomic_t pktcow_failed;
> +};

Same question as in the previous patch. I only see updates for these
variables, but nobody reading them?

-- 
Kalle Valo

Re: [PATCH 2/4] brcmfmac: use atomic_t for statistic counter in struct brcmf_bus

[Kalle Valo]

Arend van Spriel  writes:

> The statistic counter is used in common layer and in the bus layer
> in different thread contexts so change to use atomic operations.
>
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts 
> Reviewed-by: Franky Lin 
> Signed-off-by: Arend van Spriel 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h  | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index e2c895b..e1a4d9e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -138,7 +138,7 @@ struct brcmf_bus {
>   struct brcmf_pub *drvr;
>   enum brcmf_bus_state state;
>   uint maxctl;
> - unsigned long tx_realloc;
> + atomic_t tx_realloc;
>   u32 chip;
>   u32 chiprev;
>   bool always_use_fws_queue;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 81f9594..a280536 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -2046,7 +2046,7 @@ static int brcmf_sdio_txpkt_hdalign(struct brcmf_sdio 
> *bus, struct sk_buff *pkt)
>   head_pad = ((unsigned long)dat_buf % bus->head_align);
>   if (head_pad) {
>   if (skb_headroom(pkt) < head_pad) {
> - bus->sdiodev->bus_if->tx_realloc++;
> + atomic_inc(>sdiodev->bus_if->tx_realloc);

What's the point of this field? AFAICS it's only incremented but never
read. What am I missing?

-- 
Kalle Valo

Re: [PATCH v2] rtlwifi: Remove unnecessary conditions

[Larry Finger]

On 06/26/2017 09:41 PM, Souptick Joarder wrote:

Any further comment on this patch ?

On 22-Jun-2017 6:53 PM, "Souptick Joarder" > wrote:

 >
 > As wmm_enable is initialized to false, hence the else condition never
 > execute and boundary is assigned with TX_PAGE_BOUNDARY. So the if-else
 > condition can be removed and boundary will be assigned with
 > TX_PAGE_BOUNDARY.
 >
 > Signed-off-by: Souptick Joarder >

 > ---
 > Changes in v2:
 >   - Correcting the indent and moving up the change where
 > boundary is defined.
 >
 >  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 9 +
 >  1 file changed, 1 insertion(+), 8 deletions(-)
 >
 > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c

 > index f95a645..107c34e 100644
 > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
 > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
 > @@ -835,7 +835,7 @@ static int _rtl92cu_init_mac(struct ieee80211_hw *hw)
 > struct rtl_usb_priv *usb_priv = rtl_usbpriv(hw);
 > struct rtl_usb *rtlusb = rtl_usbdev(usb_priv);
 > int err = 0;
 > -   u32 boundary = 0;
 > +   u32 boundary = TX_PAGE_BOUNDARY;
 > u8 wmm_enable = false; /* TODO */
 > u8 out_ep_nums = rtlusb->out_ep_nums;
 > u8 queue_sel = rtlusb->out_queue_sel;
 > @@ -845,13 +845,6 @@ static int _rtl92cu_init_mac(struct ieee80211_hw *hw)
 > pr_err("Failed to init power on!\n");
 > return err;
 > }
 > -   if (!wmm_enable) {
 > -   boundary = TX_PAGE_BOUNDARY;
 > -   } else { /* for WMM */
 > -   boundary = (IS_NORMAL_CHIP(rtlhal->version))
 > -   ? WMM_CHIP_B_TX_PAGE_BOUNDARY
 > -   : WMM_CHIP_A_TX_PAGE_BOUNDARY;
 > -   }
 > if (false == rtl92c_init_llt_table(hw, boundary)) {
 > pr_err("Failed to init LLT Table!\n");
 > return -EINVAL;


This patch troubles me. I have no idea why the original author placed a TODO on 
the assignent of wmm_enable. You, however, have left the TODO in place but 
removed the actual place where it would make a difference. As a result, it would 
become impossible to reconstruct that author's intentions. For that reason


NACK.

Note that these changes make no difference in the object code and the optimizer 
will remove that code anyway.


Larry

[PATCH 3.18 16/16] mac80211/wpa: use constant time memory comparison for MACs

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Jason A. Donenfeld 

commit 98c67d187db7808b1f3c95f2110dd4392d034182 upstream.

Otherwise, we enable all sorts of forgeries via timing attack.

Signed-off-by: Jason A. Donenfeld 
Cc: Johannes Berg 
Cc: linux-wireless@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman 


---
 net/mac80211/wpa.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ieee80211_i.h"
 #include "michael.h"
@@ -150,7 +151,7 @@ ieee80211_rx_h_michael_mic_verify(struct
data_len = skb->len - hdrlen - MICHAEL_MIC_LEN;
key = >key->conf.key[NL80211_TKIP_DATA_OFFSET_RX_MIC_KEY];
michael_mic(key, hdr, data, data_len, mic);
-   if (memcmp(mic, data + data_len, MICHAEL_MIC_LEN) != 0)
+   if (crypto_memneq(mic, data + data_len, MICHAEL_MIC_LEN))
goto mic_fail;
 
/* remove Michael MIC from payload */
@@ -771,7 +772,7 @@ ieee80211_crypto_aes_cmac_decrypt(struct
bip_aad(skb, aad);
ieee80211_aes_cmac(key->u.aes_cmac.tfm, aad,
   skb->data + 24, skb->len - 24, mic);
-   if (memcmp(mic, mmie->mic, sizeof(mmie->mic)) != 0) {
+   if (crypto_memneq(mic, mmie->mic, sizeof(mmie->mic))) {
key->u.aes_cmac.icverrors++;
return RX_DROP_UNUSABLE;
}

RE: [PATCH v2] nl80211: Don't verify owner_nlportid on NAN commands

[Otcheretianski, Andrei]

> Almost there :-p Is the reference in NL80211_CMD_ADD_NAN_FUNCTION doc to
> NL80211_ATTR_SOCKET_OWNER still warranted?

I think yes. It explains where NAN events will go, and this is relevant only 
when you add functions.

>
> Regards,
> Arend

Re: [PATCH v2] nl80211: Don't verify owner_nlportid on NAN commands

[Arend van Spriel]

On 26-06-17 18:52, Luca Coelho wrote:
> From: Andrei Otcheretianski 
> 
> If NAN interface is created with NL80211_ATTR_SOCKET_OWNER, the socket
> that is used to create the interface is used for all NAN operations and
> reporting NAN events.
> However, it turns out that sending commands and receiving events on
> the same socket is not possible in a completely race-free way:
> If the socket buffer is overflowed by the events, the command response
> will not be sent. In that case the caller will block forever on recv.
> Using non-blocking socket for commands is more complicated and still
> the command response or ack may not be received.
> So, keep unicasting NAN events to the interface creator, but allow
> using a different socket for commands.
> 
> Signed-off-by: Andrei Otcheretianski 
> Signed-off-by: Luca Coelho 
> ---
> 
> In v2:
>* Andrei fixed the documentation.

Almost there :-p Is the reference in NL80211_CMD_ADD_NAN_FUNCTION doc to
NL80211_ATTR_SOCKET_OWNER still warranted?

Regards,
Arend

Re: [PATCH v2 3.18-stable] mac80211/wpa: use constant time memory comparison for MACs

[Greg KH]

On Mon, Jun 19, 2017 at 06:44:06PM +0200, Jason A. Donenfeld wrote:
> Otherwise, we enable all sorts of forgeries via timing attack.
> 
> Signed-off-by: Jason A. Donenfeld 
> Cc: Johannes Berg 
> Cc: linux-wireless@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Signed-off-by: Johannes Berg 
> ---
> This is for 3.18. Tested this, and it works as intended.

Thanks, now applied.

greg k-h

[PATCH] staging: wilc1000: fix spelling mistake: "dissconect" -> "disconnect"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in netdev_err error message

Signed-off-by: Colin Ian King 
---
 drivers/staging/wilc1000/host_interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index f7c22d7b28d1..2568dfc15181 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1216,7 +1216,7 @@ static s32 Handle_ConnectTimeout(struct wilc_vif *vif)
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
if (result)
-   netdev_err(vif->ndev, "Failed to send dissconect\n");
+   netdev_err(vif->ndev, "Failed to send disconnect\n");
 
hif_drv->usr_conn_req.ssid_len = 0;
kfree(hif_drv->usr_conn_req.ssid);
-- 
2.11.0

Re: mac80211: out of date seq number cause network stall

[Johannes Berg]

-davem, he's really not concerned with this

Hi,

I really don't think that you're looking at the right thing - you
should look at the transmitter.

Please provide a sniffer capture showing the problem.

johannes

Re: mac80211: out of date seq number cause network stall

[孙建希]

all,

When recieve block ack request ctrl packet. I catch some error packet
with ssn bigger than last recevice packet seq number. Then

ieee80211_release_reorder_frames(rx->sdata, tid_agg_rx,
 start_seq_num, frames);

will update head_seq_num to a wrong number. Which cause packet loss.


So I think there should be a check start_seq_num should less than last
seq number.

Index: compat-wireless-2017-01-31/net/mac80211/rx.c
===
--- compat-wireless-2017-01-31.orig/net/mac80211/rx.c   2017-02-02
19:15:23.0 +0800
+++ compat-wireless-2017-01-31/net/mac80211/rx.c2017-06-27
16:06:07.688053203 +0800
@@ -1040,6 +1040,8 @@
goto out;
}

+   tid_agg_rx->last_mpdu_seq_num = mpdu_seq_num;
+
/*
 * If frame the sequence number exceeds our buffering window
 * size release some previous frames to make room for this one.
@@ -2642,6 +2644,8 @@
  TU_TO_EXP_TIME(tid_agg_rx->timeout));

spin_lock(_agg_rx->reorder_lock);
+   if(ieee80211_sn_less(tid_agg_rx->last_mpdu_seq_num,
start_seq_num))
+   start_seq_num =
ieee80211_sn_inc(tid_agg_rx->last_mpdu_seq_num);
/* release stored frames up to start of BAR */
ieee80211_release_reorder_frames(rx->sdata, tid_agg_rx,
 start_seq_num, frames);
Index: compat-wireless-2017-01-31/net/mac80211/sta_info.h
===
--- compat-wireless-2017-01-31.orig/net/mac80211/sta_info.h
2017-06-19 20:36:19.945264458 +0800
+++ compat-wireless-2017-01-31/net/mac80211/sta_info.h  2017-06-27
15:53:57.610946298 +0800
@@ -207,6 +207,7 @@
struct timer_list session_timer;
struct timer_list reorder_timer;
unsigned long last_rx;
+   u16 last_mpdu_seq_num;
u16 head_seq_num;

On Sun, Jun 25, 2017 at 6:33 PM, 孙建希  wrote:
> hi,
>
> In function `ieee80211_sta_manage_reorder_buf`:
>
> 1104 /* frame with out of date sequence number */
> 1105 if (ieee80211_sn_less(mpdu_seq_num, head_seq_num)) {
> 1106 dev_kfree_skb(skb);
> 1107 goto out;
> 1108 }
> 1109
>
> head_seq_num will out of oder, in ath9k wds mode.  But i can not find
> why will out of order.
>
> [ 1549.043719]  mac80211 mpdu_seq_num: 325  head_seq_num:326
> [ 1549.053979]  mac80211 mpdu_seq_num: 325  head_seq_num:1263
> [ 1549.072450]  mac80211 mpdu_seq_num: 326  head_seq_num:1263
>
> head_seq_num out of order. Then almost 1000 packet will drop. I have
> read function `ieee80211_sta_manage_reorder_buf` and add some debug
> info. I suppose this bug is not caused by this function.
>
> I grep all mac80211 code, and there's no code change  head_seq_num.
>
> Please help.
>
> On Sun, Jun 25, 2017 at 1:49 AM, 孙建希  wrote:
>> Hi,
>>
>> I found `head seq number` bigger than all seq num:
>>
>> [ 3887.972639] ma80211 with out of date seq number: 1296 1297 1889
>> [ 3887.977134] ma80211 with out of date seq number: 1296 1298 1889
>> [ 3887.983082] ma80211 with out of date seq number: 1296 1299 1889
>> [ 3887.988929] ma80211 with out of date seq number: 1296 1300 1889
>> [ 3887.994861] ma80211 with out of date seq number: 1296 1301 1889
>> [ 3888.000764] ma80211 with out of date seq number: 1296 1302 1889
>> [ 3888.006638] ma80211 with out of date seq number: 1296 1303 1889
>> [ 3888.012576] ma80211 with out of date seq number: 1296 1304 1889
>>
>> On Sun, Jun 25, 2017 at 1:21 AM, 孙建希  wrote:
>>> Hi,
>>>
>>> I first find this bug in wds ath9k mode.
>>>
>>> When use iperf3, so many out of date seq number, in mac80211 function
>>> ieee80211_sta_manage_reorder_buf:
>>>
>>> [ 1248.968407] mac80211 with out of date seq number: 2551 2547 2552
>>> [ 1248.972972] mac80211 with out of date seq number: 2551 2548 2552
>>> [ 1248.978800] mac80211 with out of date seq number: 2551 2549 2552
>>> [ 1248.984760] mac80211 with out of date seq number: 2551 2550 2552
>>> [ 1248.990636] mac80211 with out of date seq number: 2551 2551 2552
>>>
>>>
>>> `previous seq number` `current seq number` `head seq num`.
>>>
>>>
>>> when `head seq number` - `current seq num` > 200 . Iperf3 will block.