Re: [PATCH 3/5] qtnfmac: modify qtnf_map_bar not to return NULL

[Igor Mitsyanko]

On 08/29/2017 05:16 AM, Sergey Matyukevich wrote:

NULL is not a special type of success here but a error pointer.
So it makes sense to check against NULL in qtnf_map_bar
and return error code.

Signed-off-by: Sergey Matyukevich 
---


On a first glance not immediately obvious what is logically changed 
here, is it so that pr_debug() would not print NULL pointer?

Re: [PATCH 3/5] qtnfmac: modify qtnf_map_bar not to return NULL

[Igor Mitsyanko]

On 08/29/2017 05:16 AM, Sergey Matyukevich wrote:

NULL is not a special type of success here but a error pointer.
So it makes sense to check against NULL in qtnf_map_bar
and return error code.

Signed-off-by: Sergey Matyukevich 
---


On a first glance not immediately obvious what is logically changed 
here, is it so that pr_debug() would not print NULL pointer?

Re: [PATCH 14/27] qtnfmac: do not cache CSA chandef info

[Igor Mitsyanko]

On 08/29/2017 08:44 AM, Sergey Matyukevich wrote:

I am ok with removal of CSA chandef info. It was kept mainly to warn
about channel switch to the frequency that differs from original
CSA request.


-   if (vif->vifid != 0) {
-   if (!(mac->status & QTNF_MAC_CSA_ACTIVE))
-   return -EOPNOTSUPP;
-
-   if (!cfg80211_chandef_identical(>chandef,
-   >csa_chandef))
-   return -EINVAL;
-
-   return 0;
-   }



This particular CSA_ACTIVE status check was introduced for compatibility with
hostapd behaviour. Currently hostapd goes through all the virtual interfaces
and sends CSA for each of them. So the idea was to send CSA for primary
interface and confirm success for the others. If this snipped is dropped
then we end up in multiple identical CSA requests queued in firmware.

I suggest to remove chandef_identical check, but to keep the logic for
secondary virtual interface handling.

Regards,
Sergey



The idea was that driver doesn't have to keep track of this, but instead 
it will just forward directly to card, and card will return success for 
CSA request to the same channel, because card knows that already.


As a bonus, in case it will ever support virtual concurrent (virtual 
interfaces on different physical channels), no changes to driver will be 
required.

Re: [PATCH 02/27] qtnfmac: make "Channel change" event report full channel info

[Igor Mitsyanko]

On 08/29/2017 07:31 AM, Sergey Matyukevich wrote:

  static int
  qtnf_event_handle_sta_assoc(struct qtnf_wmac *mac, struct qtnf_vif *vif,
@@ -358,41 +359,36 @@ qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
  u16 len)
  {
struct wiphy *wiphy = priv_to_wiphy(mac);
-   struct cfg80211_chan_def chandef;
-   struct ieee80211_channel *chan;
+   struct cfg80211_chan_def chdef;
struct qtnf_vif *vif;
-   int freq;
int i;


Original variable name 'chandef' was easier to spell on the phone :)


Will return)



...


+   qlink_chandef_q2cfg(wiphy, >chan, );
+
+   if (!cfg80211_chandef_valid()) {
+   pr_err("MAC%u: bad channel freq1=%u bw=%u\n", mac->macid,
+  chdef.center_freq1, chdef.width);
return -EINVAL;
}


Lets keep both freq1 and freq2 in error message.


Ok



...


+void qlink_chandef_q2cfg(struct wiphy *wiphy,
+const struct qlink_chandef *qch,
+struct cfg80211_chan_def *chdef)
+{
+   chdef->center_freq1 = le16_to_cpu(qch->center_freq1);
+   chdef->center_freq2 = le16_to_cpu(qch->center_freq2);
+   chdef->width = qlink_chanwidth_to_nl(qch->width);
+
+   switch (chdef->width) {
+   case NL80211_CHAN_WIDTH_20_NOHT:
+   case NL80211_CHAN_WIDTH_20:
+   case NL80211_CHAN_WIDTH_5:
+   case NL80211_CHAN_WIDTH_10:
+   chdef->chan = ieee80211_get_channel(wiphy, chdef->center_freq1);
+   break;
+   case NL80211_CHAN_WIDTH_40:
+   case NL80211_CHAN_WIDTH_80:
+   case NL80211_CHAN_WIDTH_80P80:
+   case NL80211_CHAN_WIDTH_160:
+   chdef->chan = ieee80211_get_channel(wiphy,
+   chdef->center_freq1 - 10);


Do we have the same formula for 40MHz and 80MHz center frequency ?
I thought we should be using the channel number for the left-most 20MHz band.


Here it should be no difference which channel number we're using as long 
as it falls within specified bandwidth. I mean, we can take (freq - 10), 
(freq + 10) for 40MHz, or (freq - 30) (freq + 30) for 80 MHz etc.


I don't see how we can identify which 20MHz channel is primary, with a 
chandef structure.





+   break;
+   default:
+   chdef->chan = NULL;
+   break;
+   }
+}


Regards,
Sergey

Re: [PATCH 03/27] qtnfmac: retreive current channel info from EP

[Igor Mitsyanko]

On 08/29/2017 07:42 AM, Sergey Matyukevich wrote:


Typo in commit title: retrieve


will fix



...


-   if (!cfg80211_chandef_valid(>chandef)) {
-   pr_err("invalid channel settings on %s\n", ndev->name);
-   return -ENODATA;
+   if (!cfg80211_chandef_valid(chandef)) {
+   pr_err("%s: bad chan freq1=%u bw=%u\n", ndev->name,
+  chandef->center_freq1, chandef->width);
+   ret = -ENODATA;
}


Lets keep both center_freq1 and center_freq2 in error message.


Ok




Regards,
Sergey

[PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac

[Antony Antony]

Add device tree binding documentation for Broadcom BCM43430
AMPAK AP6212A has this chip.

e.g
compatible = "brcm,bcm43430-fmac";

NanoPi NEO Plus2 has an AMPAK AP6212A WiFi module
with BCM43430 rev=1 inside.
brcmf_chip_recognition found AXI chip: BCM43430, rev=1
brcmf_ops_sdio_probe sdio vendor ID: 0x02d0
brcmf_ops_sdio_probe sdio device ID: 0xa9a6

Signed-off-by: Antony Antony 
---
 Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 NanoPi Neo Plus2 Kernel DT propsed patch
 https://patchwork.kernel.org/patch/9925387/

diff --git 
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
index 590f622..9107e1a 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -6,7 +6,9 @@ connects the device to the system.
 
 Required properties:
 
- - compatible : Should be "brcm,bcm4329-fmac".
+ - compatible : should be one of the following:
+   * "brcm,bcm4329-fmac"
+   * "brcm,bcm43430-fmac"
 
 Optional properties:
  - brcm,drive-strength : drive strength used for SDIO pins on device in mA
-- 
2.9.3

[PATCH] rsi: remove memset before memcpy

[Himanshu Jha]

calling memcpy immediately after memset with the same region of memory
makes memset redundant.

Signed-off-by: Himanshu Jha 
---
 drivers/net/wireless/rsi/rsi_91x_sdio.c | 1 -
 drivers/net/wireless/rsi/rsi_91x_usb.c  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c 
b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index 742f6cd..8d3a483 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -584,7 +584,6 @@ static int rsi_sdio_load_data_master_write(struct rsi_hw 
*adapter,
}
 
for (offset = 0, i = 0; i < num_blocks; i++, offset += block_size) {
-   memset(temp_buf, 0, block_size);
memcpy(temp_buf, ta_firmware + offset, block_size);
lsb_address = (u16)base_address;
status = rsi_sdio_write_register_multiple
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c 
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index 9097f7e..81df09d 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -439,7 +439,6 @@ static int rsi_usb_load_data_master_write(struct rsi_hw 
*adapter,
rsi_dbg(INFO_ZONE, "num_blocks: %d\n", num_blocks);
 
for (cur_indx = 0, i = 0; i < num_blocks; i++, cur_indx += block_size) {
-   memset(temp_buf, 0, block_size);
memcpy(temp_buf, ta_firmware + cur_indx, block_size);
status = rsi_usb_write_register_multiple(adapter, base_address,
 (u8 *)(temp_buf),
-- 
2.7.4

Re: [PATCH] rtlwifi: rtl8822be: Add firmware for new driver/device

[Kyle McMartin]

On Fri, Aug 25, 2017 at 09:23:40AM -0500, Larry Finger wrote:
> A driver for the RTL8822BE has been added to staging. This commit supplies
> the firmware for it.
> 
> Signed-off-by: Larry Finger 
> ---

applied. thanks Larry.

--kyle

Re: pull-request: wireless-drivers-next 2017-08-28

[David Miller]

From: Kalle Valo 
Date: Mon, 28 Aug 2017 12:22:34 +0300

> here's a pull request to net-next for 4.14. Because I pulled
> wireless-drivers (at least that's my suspicion) the diffstat was wrong
> again and I created it manually. I recall Linus somewhere saying that in
> certain cases this is normal and it's ok to create the diffstat
> manually, so I don't worry about this anymore.

Yeah, that's fine.

> In this pull request we also add SDIO_DEVICE_ID_CYPRESS_4373 to
> include/linux/mmc/sdio_ids.h which stands out in the diffstat.
> 
> Please let me know if there are any problems.

Pulled, thanks!

Re: rtlwifi handling of sequence numbers with aggregation

[Jes Sorensen]

On 08/29/2017 10:18 AM, Larry Finger wrote:

On 08/25/2017 09:15 PM, Larry Finger wrote:
Based on my prejudices, I would suspect the USB driver before that of 
the PCI version. I have BCc'd my contact at Realtek to see what he has 
to say on the issue.


My contact at Realtek replies that the PCI code is correct. He further 
states that "Since mac80211 uses ieee80211_tx_next_seq() to store next 
sequence number in sta->tid_seq[tid] and fill the sequence number in 
AMPDU parameters, I think driver doesn't need to maintain the seq_number 
anymore. So, let's remove 'u16 seq_number' from 'struct rtl_tid_data', 
please refer to attachment." I have not had a chance to test his patch, 
but I trust his analysis.


I don't see any attachment, but I'm happy with a correct solution if 
you'll work with them on getting that pushed in.


Cheers,
Jes

Re: [PATCH 15/27] qtnfmac: remove unused mac::status field

[Sergey Matyukevich]

On Thu, Aug 24, 2017 at 07:30:12PM -0700, igor.mitsyanko...@quantenna.com wrote:
> From: Igor Mitsyanko 
> 
> It is no longer used.

If we come to the agreement on the previous patch,
then this field should be kept.

Regards,
Sergey

Re: [PATCH 14/27] qtnfmac: do not cache CSA chandef info

[Sergey Matyukevich]

I am ok with removal of CSA chandef info. It was kept mainly to warn
about channel switch to the frequency that differs from original
CSA request.

> - if (vif->vifid != 0) {
> - if (!(mac->status & QTNF_MAC_CSA_ACTIVE))
> - return -EOPNOTSUPP;
> -
> - if (!cfg80211_chandef_identical(>chandef,
> - >csa_chandef))
> - return -EINVAL;
> -
> - return 0;
> - }


This particular CSA_ACTIVE status check was introduced for compatibility with
hostapd behaviour. Currently hostapd goes through all the virtual interfaces
and sends CSA for each of them. So the idea was to send CSA for primary
interface and confirm success for the others. If this snipped is dropped
then we end up in multiple identical CSA requests queued in firmware.

I suggest to remove chandef_identical check, but to keep the logic for
secondary virtual interface handling.

Regards,
Sergey

Re: [PATCH 03/27] qtnfmac: retreive current channel info from EP

[Sergey Matyukevich]

Typo in commit title: retrieve

...

> - if (!cfg80211_chandef_valid(>chandef)) {
> - pr_err("invalid channel settings on %s\n", ndev->name);
> - return -ENODATA;
> + if (!cfg80211_chandef_valid(chandef)) {
> + pr_err("%s: bad chan freq1=%u bw=%u\n", ndev->name,
> +chandef->center_freq1, chandef->width);
> + ret = -ENODATA;
>   }

Lets keep both center_freq1 and center_freq2 in error message.

Regards,
Sergey

Re: [PATCH 02/27] qtnfmac: make "Channel change" event report full channel info

[Sergey Matyukevich]

>  static int
>  qtnf_event_handle_sta_assoc(struct qtnf_wmac *mac, struct qtnf_vif *vif,
> @@ -358,41 +359,36 @@ qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
> u16 len)
>  {
>   struct wiphy *wiphy = priv_to_wiphy(mac);
> - struct cfg80211_chan_def chandef;
> - struct ieee80211_channel *chan;
> + struct cfg80211_chan_def chdef;
>   struct qtnf_vif *vif;
> - int freq;
>   int i;

Original variable name 'chandef' was easier to spell on the phone :)

...

> + qlink_chandef_q2cfg(wiphy, >chan, );
> +
> + if (!cfg80211_chandef_valid()) {
> + pr_err("MAC%u: bad channel freq1=%u bw=%u\n", mac->macid,
> +chdef.center_freq1, chdef.width);
>   return -EINVAL;
>   }

Lets keep both freq1 and freq2 in error message.

...

> +void qlink_chandef_q2cfg(struct wiphy *wiphy,
> +  const struct qlink_chandef *qch,
> +  struct cfg80211_chan_def *chdef)
> +{
> + chdef->center_freq1 = le16_to_cpu(qch->center_freq1);
> + chdef->center_freq2 = le16_to_cpu(qch->center_freq2);
> + chdef->width = qlink_chanwidth_to_nl(qch->width);
> +
> + switch (chdef->width) {
> + case NL80211_CHAN_WIDTH_20_NOHT:
> + case NL80211_CHAN_WIDTH_20:
> + case NL80211_CHAN_WIDTH_5:
> + case NL80211_CHAN_WIDTH_10:
> + chdef->chan = ieee80211_get_channel(wiphy, chdef->center_freq1);
> + break;
> + case NL80211_CHAN_WIDTH_40:
> + case NL80211_CHAN_WIDTH_80:
> + case NL80211_CHAN_WIDTH_80P80:
> + case NL80211_CHAN_WIDTH_160:
> + chdef->chan = ieee80211_get_channel(wiphy,
> + chdef->center_freq1 - 10);

Do we have the same formula for 40MHz and 80MHz center frequency ?
I thought we should be using the channel number for the left-most 20MHz band.

> + break;
> + default:
> + chdef->chan = NULL;
> + break;
> + }
> +}

Regards,
Sergey

Re: rtlwifi handling of sequence numbers with aggregation

[Larry Finger]

On 08/25/2017 09:15 PM, Larry Finger wrote:

On 08/25/2017 12:51 PM, Jes Sorensen wrote:

Hi,

Looking at some bits in rtlwifi I came across a discrepancy between the
PCI and USB code.

Consider the following code:

In rtl_pci_tx():
if (ieee80211_is_data_qos(fc)) {
    tid = rtl_get_tid(skb);
    if (sta) {
    sta_entry = (struct rtl_sta_info *)sta->drv_priv;
    seq_number = (le16_to_cpu(hdr->seq_ctrl) &
  IEEE80211_SCTL_SEQ) >> 4;
    seq_number += 1;

    if (!ieee80211_has_morefrags(hdr->frame_control))
    sta_entry->tids[tid].seq_number = seq_number;
    }

In _rtl_usb_tx_preprocess():
if (ieee80211_is_data_qos(fc)) {
    qc = ieee80211_get_qos_ctl(hdr);
    tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
    seq_number = (le16_to_cpu(hdr->seq_ctrl) &
 IEEE80211_SCTL_SEQ) >> 4;
    seq_number += 1;
    seq_number <<= 4;
}
[snip]
if (!ieee80211_has_morefrags(hdr->frame_control)) {
    if (qc)
    mac->tids[tid].seq_number = seq_number;
}

The seq_number is picked up from ieee80211_ops->ampdu_action()
which calls into rtl_tx_agg_start():
tid_data = _entry->tids[tid];

RT_TRACE(rtlpriv, COMP_SEND, DBG_DMESG,
 "on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
 tid_data->seq_number);

*ssn = tid_data->seq_number;

My question here is why does the USB code shift seq_number << 4 while
the PCI code doesn't? I assume one of these is wrong, but which one?


Based on my prejudices, I would suspect the USB driver before that of the PCI 
version. I have BCc'd my contact at Realtek to see what he has to say on the issue.


My contact at Realtek replies that the PCI code is correct. He further states 
that "Since mac80211 uses ieee80211_tx_next_seq() to store next sequence number 
in sta->tid_seq[tid] and fill the sequence number in AMPDU parameters, I think 
driver doesn't need to maintain the seq_number anymore. So, let's remove 'u16 
seq_number' from 'struct rtl_tid_data', please refer to attachment." I have not 
had a chance to test his patch, but I trust his analysis.


Larry

[PATCH 4/5] qtnfmac: fix free_xfer_buffer cleanup

[Sergey Matyukevich]

Check if skb tracking arrays has been already allocated. This additional
check handles the case when init partially failed.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index bfbcd0bf75bf..2921d8069bf2 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -483,7 +483,7 @@ static void free_xfer_buffers(void *data)
 
/* free rx buffers */
for (i = 0; i < priv->rx_bd_num; i++) {
-   if (priv->rx_skb[i]) {
+   if (priv->rx_skb && priv->rx_skb[i]) {
rxbd = >rx_bd_vbase[i];
paddr = QTN_HOST_ADDR(le32_to_cpu(rxbd->addr_h),
  le32_to_cpu(rxbd->addr));
@@ -496,7 +496,7 @@ static void free_xfer_buffers(void *data)
 
/* free tx buffers */
for (i = 0; i < priv->tx_bd_num; i++) {
-   if (priv->tx_skb[i]) {
+   if (priv->tx_skb && priv->tx_skb[i]) {
dev_kfree_skb_any(priv->tx_skb[i]);
priv->tx_skb[i] = NULL;
}
-- 
2.11.0

[PATCH 2/5] qtnfmac: module param sanity check

[Sergey Matyukevich]

Linux built-in circ_buf implementation assumes that that the
circular buffer length is a power of 2. Make sure that
rx and tx descriptor queue lengths are power-of-2.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index cd2f2b667643..fd552d64f943 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "qtn_hw_ids.h"
 #include "pcie_bus_priv.h"
@@ -39,11 +40,11 @@ MODULE_PARM_DESC(use_msi, "set 0 to use legacy interrupt");
 
 static unsigned int tx_bd_size_param = 32;
 module_param(tx_bd_size_param, uint, 0644);
-MODULE_PARM_DESC(tx_bd_size_param, "Tx descriptors queue size");
+MODULE_PARM_DESC(tx_bd_size_param, "Tx descriptors queue size, power of two");
 
 static unsigned int rx_bd_size_param = 256;
 module_param(rx_bd_size_param, uint, 0644);
-MODULE_PARM_DESC(rx_bd_size_param, "Rx descriptors queue size");
+MODULE_PARM_DESC(rx_bd_size_param, "Rx descriptors queue size, power of two");
 
 static u8 flashboot = 1;
 module_param(flashboot, byte, 0644);
@@ -509,6 +510,18 @@ static int qtnf_pcie_init_xfer(struct qtnf_pcie_bus_priv 
*priv)
priv->rx_bd_w_index = 0;
priv->rx_bd_r_index = 0;
 
+   if (!priv->tx_bd_num || !is_power_of_2(priv->tx_bd_num)) {
+   pr_err("tx_bd_size_param %u is not power of two\n",
+  priv->tx_bd_num);
+   return -EINVAL;
+   }
+
+   if (!priv->rx_bd_num || !is_power_of_2(priv->rx_bd_num)) {
+   pr_err("rx_bd_size_param %u is not power of two\n",
+  priv->rx_bd_num);
+   return -EINVAL;
+   }
+
ret = alloc_skb_array(priv);
if (ret) {
pr_err("failed to allocate skb array\n");
-- 
2.11.0

[PATCH 1/5] qtnfmac: drop -D__CHECK_ENDIAN from cflags

[Sergey Matyukevich]

Flag -D__CHECK_ENDIAN was wrong: it should be -D__CHECK_ENDIAN__ instead.
However now this flag is enabled by default, so it can be removed.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/Makefile | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/Makefile 
b/drivers/net/wireless/quantenna/qtnfmac/Makefile
index 0d618e5e5f5b..f236b7dc2be3 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/Makefile
+++ b/drivers/net/wireless/quantenna/qtnfmac/Makefile
@@ -25,7 +25,3 @@ qtnfmac_pearl_pcie-objs += \
pearl/pcie.o
 
 qtnfmac_pearl_pcie-$(CONFIG_DEBUG_FS) += debug.o
-
-#
-
-ccflags-y += -D__CHECK_ENDIAN
-- 
2.11.0

[PATCH 0/5] qtnfmac: pcie datapath updates and fixes

[Sergey Matyukevich]

Hello Kalle, Igor, and all

This patches introduces further updates and fixes
for pcie datapath in qtnfmac driver:

- implement 64-bit dma for hosts enabling CONFIG_ARCH_DMA_ADDR_T_64BIT
- sanity check for module params: circ_buf queues should be power-of-2
- misc cleanup according to previous reviews

Sergey Matyukevich (5):

qtnfmac: drop -D__CHECK_ENDIAN from cflags
qtnfmac: module param sanity check
qtnfmac: modify qtnf_map_bar not to return NULL
qtnfmac: fix free_xfer_buffer cleanup
qtnfmac: implement 64-bit dma support

Makefile| 4 -
pearl/pcie.c| 101 +++-
pearl/pcie_ipc.h| 10 +---
pearl/pcie_regs_pearl.h | 1
4 files changed, 88 insertions(+), 28 deletions(-)

[PATCH 5/5] qtnfmac: implement 64-bit dma support

[Sergey Matyukevich]

Use 64-bit dma for hosts with CONFIG_ARCH_DMA_ADDR_T_64BIT enabled.

Signed-off-by: Sergey Matyukevich 
---
 .../net/wireless/quantenna/qtnfmac/pearl/pcie.c| 70 ++
 .../wireless/quantenna/qtnfmac/pearl/pcie_ipc.h| 10 ++--
 .../quantenna/qtnfmac/pearl/pcie_regs_pearl.h  |  1 +
 3 files changed, 65 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 2921d8069bf2..502e72b7cdcc 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -403,10 +403,12 @@ static int alloc_bd_table(struct qtnf_pcie_bus_priv *priv)
priv->rx_bd_vbase = vaddr;
priv->rx_bd_pbase = paddr;
 
-   writel(QTN_HOST_LO32(paddr),
-  PCIE_HDP_TX_HOST_Q_BASE_L(priv->pcie_reg_base));
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
writel(QTN_HOST_HI32(paddr),
   PCIE_HDP_TX_HOST_Q_BASE_H(priv->pcie_reg_base));
+#endif
+   writel(QTN_HOST_LO32(paddr),
+  PCIE_HDP_TX_HOST_Q_BASE_L(priv->pcie_reg_base));
writel(priv->rx_bd_num | (sizeof(struct qtnf_rx_bd)) << 16,
   PCIE_HDP_TX_HOST_Q_SZ_CTRL(priv->pcie_reg_base));
 
@@ -447,8 +449,10 @@ static int skb2rbd_attach(struct qtnf_pcie_bus_priv *priv, 
u16 index)
/* sync up all descriptor updates */
wmb();
 
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
writel(QTN_HOST_HI32(paddr),
   PCIE_HDP_HHBM_BUF_PTR_H(priv->pcie_reg_base));
+#endif
writel(QTN_HOST_LO32(paddr),
   PCIE_HDP_HHBM_BUF_PTR(priv->pcie_reg_base));
 
@@ -503,9 +507,28 @@ static void free_xfer_buffers(void *data)
}
 }
 
+static int qtnf_hhbm_init(struct qtnf_pcie_bus_priv *priv)
+{
+   u32 val;
+
+   val = readl(PCIE_HHBM_CONFIG(priv->pcie_reg_base));
+   val |= HHBM_CONFIG_SOFT_RESET;
+   writel(val, PCIE_HHBM_CONFIG(priv->pcie_reg_base));
+   usleep_range(50, 100);
+   val &= ~HHBM_CONFIG_SOFT_RESET;
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+   val |= HHBM_64BIT;
+#endif
+   writel(val, PCIE_HHBM_CONFIG(priv->pcie_reg_base));
+   writel(priv->rx_bd_num, PCIE_HHBM_Q_LIMIT_REG(priv->pcie_reg_base));
+
+   return 0;
+}
+
 static int qtnf_pcie_init_xfer(struct qtnf_pcie_bus_priv *priv)
 {
int ret;
+   u32 val;
 
priv->tx_bd_num = tx_bd_size_param;
priv->rx_bd_num = rx_bd_size_param;
@@ -518,12 +541,32 @@ static int qtnf_pcie_init_xfer(struct qtnf_pcie_bus_priv 
*priv)
return -EINVAL;
}
 
+   val = priv->tx_bd_num * sizeof(struct qtnf_tx_bd);
+   if (val > PCIE_HHBM_MAX_SIZE) {
+   pr_err("tx_bd_size_param %u is too large\n",
+  priv->tx_bd_num);
+   return -EINVAL;
+   }
+
if (!priv->rx_bd_num || !is_power_of_2(priv->rx_bd_num)) {
pr_err("rx_bd_size_param %u is not power of two\n",
   priv->rx_bd_num);
return -EINVAL;
}
 
+   val = priv->rx_bd_num * sizeof(dma_addr_t);
+   if (val > PCIE_HHBM_MAX_SIZE) {
+   pr_err("rx_bd_size_param %u is too large\n",
+  priv->rx_bd_num);
+   return -EINVAL;
+   }
+
+   ret = qtnf_hhbm_init(priv);
+   if (ret) {
+   pr_err("failed to init h/w queues\n");
+   return ret;
+   }
+
ret = alloc_skb_array(priv);
if (ret) {
pr_err("failed to allocate skb array\n");
@@ -653,10 +696,13 @@ static int qtnf_pcie_data_tx(struct qtnf_bus *bus, struct 
sk_buff *skb)
 
/* write new TX descriptor to PCIE_RX_FIFO on EP */
txbd_paddr = priv->tx_bd_pbase + i * sizeof(struct qtnf_tx_bd);
-   writel(QTN_HOST_LO32(txbd_paddr),
-  PCIE_HDP_HOST_WR_DESC0(priv->pcie_reg_base));
+
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
writel(QTN_HOST_HI32(txbd_paddr),
   PCIE_HDP_HOST_WR_DESC0_H(priv->pcie_reg_base));
+#endif
+   writel(QTN_HOST_LO32(txbd_paddr),
+  PCIE_HDP_HOST_WR_DESC0(priv->pcie_reg_base));
 
if (++i >= priv->tx_bd_num)
i = 0;
@@ -1237,6 +1283,16 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
pr_debug("successful init of PCI device %x\n", pdev->device);
}
 
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
+#else
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+#endif
+   if (ret) {
+   pr_err("PCIE DMA coherent mask init failed\n");
+   goto err_base;
+   }
+
pcim_pin_device(pdev);
pci_set_master(pdev);
 
@@ -1258,12 +1314,6 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
goto err_base;
}
 
-   ret = 

[PATCH 3/5] qtnfmac: modify qtnf_map_bar not to return NULL

[Sergey Matyukevich]

NULL is not a special type of success here but a error pointer.
So it makes sense to check against NULL in qtnf_map_bar
and return error code.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index fd552d64f943..bfbcd0bf75bf 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -184,8 +184,10 @@ static void __iomem *qtnf_map_bar(struct 
qtnf_pcie_bus_priv *priv, u8 index)
return IOMEM_ERR_PTR(ret);
 
busaddr = pci_resource_start(priv->pdev, index);
-   vaddr = pcim_iomap_table(priv->pdev)[index];
len = pci_resource_len(priv->pdev, index);
+   vaddr = pcim_iomap_table(priv->pdev)[index];
+   if (!vaddr)
+   return IOMEM_ERR_PTR(-ENOMEM);
 
pr_debug("BAR%u vaddr=0x%p busaddr=%pad len=%u\n",
 index, vaddr, , (int)len);
@@ -248,19 +250,19 @@ static int qtnf_pcie_init_memory(struct 
qtnf_pcie_bus_priv *priv)
int ret = -ENOMEM;
 
priv->sysctl_bar = qtnf_map_bar(priv, QTN_SYSCTL_BAR);
-   if (IS_ERR_OR_NULL(priv->sysctl_bar)) {
+   if (IS_ERR(priv->sysctl_bar)) {
pr_err("failed to map BAR%u\n", QTN_SYSCTL_BAR);
return ret;
}
 
priv->dmareg_bar = qtnf_map_bar(priv, QTN_DMA_BAR);
-   if (IS_ERR_OR_NULL(priv->dmareg_bar)) {
+   if (IS_ERR(priv->dmareg_bar)) {
pr_err("failed to map BAR%u\n", QTN_DMA_BAR);
return ret;
}
 
priv->epmem_bar = qtnf_map_bar(priv, QTN_SHMEM_BAR);
-   if (IS_ERR_OR_NULL(priv->epmem_bar)) {
+   if (IS_ERR(priv->epmem_bar)) {
pr_err("failed to map BAR%u\n", QTN_SHMEM_BAR);
return ret;
}
-- 
2.11.0

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

[Kalle Valo]

Luca Coelho  writes:

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

"deffering"? Should it be deferring?

-- 
Kalle Valo

Re: [PATCH v2] iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc()

[Kalle Valo]

Luca Coelho  writes:

> On Thu, 2017-08-24 at 21:56 +0200, Jiri Kosina wrote:
>> On Thu, 24 Aug 2017, Luca Coelho wrote:
>> 
>> > > Work queues cannot be allocated when a mutex is held because the mutex
>> > > may be in use and that would make it sleep.  Doing so generates the
>> > > following splat with 4.13+:
>> > > 
>> > > [   19.513298] ==
>> > > [   19.513429] WARNING: possible circular locking dependency detected
>> > > [   19.513557] 4.13.0-rc5+ #6 Not tainted
>> > > [   19.513638] --
>> > > [   19.513767] cpuhp/0/12 is trying to acquire lock:
>> > > [ 19.513867] (>lock){+.+.+.}, at: []
>> > > thermal_zone_get_temp+0x5b/0xb0
>> > > [   19.514047]
>> > > [   19.514047] but task is already holding lock:
>> > > [ 19.514166] (cpuhp_state){+.+.+.}, at: []
>> > > cpuhp_thread_fun+0x3a/0x210
>> > > [   19.514338]
>> > > [   19.514338] which lock already depends on the new lock.
>> > > 
>> > > This lock dependency already existed with previous kernel versions,
>> > > but it was not detected until commit 49dfe2a67797 ("cpuhotplug: Link
>> > > lock stacks for hotplug callbacks") was introduced.
>> > > 
>> > > Reported-by: David Weinehall 
>> > > Reported-by: Jiri Kosina 
>> > > Signed-off-by: Luca Coelho 
>> > 
>> > Jiri, did you have a chance to try this out? I'm about to ask Kalle to
>> > merge this so it gets in in time for 4.13-rc7.
>> 
>> Sorry, I am almost completely offline for one more week (vacation), and 
>> will not have access to the affected system before that.
>
> Sounds good! Enjoy! ;)
>
>
>>  But this indeed 
>> looks like a correct fix to me, so feel free to add
>> 
>>  Acked-by: Jiri Kosina 
>> 
>> I'll be able to provide my Tested-by: eventually only in ~10 days.
>
>
> Kalle already picked it up in wireless-drivers and this should make it's
> way to 4.13-rc7 (we hope).

It (10a54d8196d1) didn't make it to -rc7 but it's in net tree now and
should make it to the next release on Sunday (either -rc8 or the final).

-- 
Kalle Valo

[PATCH v5] brcmfmac: add CLM download support

[Wright Feng]

From: Chung-Hsien Hsu 

The firmware for brcmfmac devices includes information regarding
regulatory constraints. For certain devices this information is kept
separately in a binary form that needs to be downloaded to the device.
This patch adds support to download this so-called CLM blob file. It
uses the same naming scheme as the other firmware files with extension
of .clm_blob.

The CLM blob file is optional. If the file does not exist, the download
process will be bypassed. It will not affect the driver loading.

Signed-off-by: Chung-Hsien Hsu 
---
v2: Revise commit message to describe in more detail
v3: Add error handling in brcmf_c_get_clm_name function
v4: Correct the length of dload_buf in brcmf_c_download function
v5: Remove unnecessary cast and alignment
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h |  10 ++
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 160 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.c|   2 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|   2 +
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  31 
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c|  19 +++
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  19 +++
 .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  18 +++
 8 files changed, 261 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index b55c329..df42e09 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -71,6 +71,7 @@ struct brcmf_bus_dcmd {
  * @wowl_config: specify if dongle is configured for wowl when going to suspend
  * @get_ramsize: obtain size of device memory.
  * @get_memdump: obtain device memory dump in provided buffer.
+ * @get_fwname: obtain firmware name.
  *
  * This structure provides an abstract interface towards the
  * bus specific driver. For control messages to common driver
@@ -87,6 +88,8 @@ struct brcmf_bus_ops {
void (*wowl_config)(struct device *dev, bool enabled);
size_t (*get_ramsize)(struct device *dev);
int (*get_memdump)(struct device *dev, void *data, size_t len);
+   int (*get_fwname)(struct device *dev, uint chip, uint chiprev,
+ unsigned char *fw_name);
 };
 
 
@@ -214,6 +217,13 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void 
*data, size_t len)
return bus->ops->get_memdump(bus->dev, data, len);
 }
 
+static inline
+int brcmf_bus_get_fwname(struct brcmf_bus *bus, uint chip, uint chiprev,
+unsigned char *fw_name)
+{
+   return bus->ops->get_fwname(bus->dev, chip, chiprev, fw_name);
+}
+
 /*
  * interface functions from common layer
  */
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 7a2b495..f6268e0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "core.h"
@@ -28,6 +29,7 @@
 #include "tracepoint.h"
 #include "common.h"
 #include "of.h"
+#include "firmware.h"
 
 MODULE_AUTHOR("Broadcom Corporation");
 MODULE_DESCRIPTION("Broadcom 802.11 wireless LAN fullmac driver.");
@@ -104,12 +106,138 @@ void brcmf_c_set_joinpref_default(struct brcmf_if *ifp)
brcmf_err("Set join_pref error (%d)\n", err);
 }
 
+static int brcmf_c_download(struct brcmf_if *ifp, u16 flag,
+   struct brcmf_dload_data_le *dload_buf,
+   u32 len)
+{
+   s32 err;
+
+   flag |= (DLOAD_HANDLER_VER << DLOAD_FLAG_VER_SHIFT);
+   dload_buf->flag = cpu_to_le16(flag);
+   dload_buf->dload_type = cpu_to_le16(DL_TYPE_CLM);
+   dload_buf->len = cpu_to_le32(len);
+   dload_buf->crc = cpu_to_le32(0);
+   len = sizeof(*dload_buf) + len - 1;
+
+   err = brcmf_fil_iovar_data_set(ifp, "clmload", dload_buf, len);
+
+   return err;
+}
+
+static int brcmf_c_get_clm_name(struct brcmf_if *ifp, u8 *clm_name)
+{
+   struct brcmf_bus *bus = ifp->drvr->bus_if;
+   struct brcmf_rev_info *ri = >drvr->revinfo;
+   u8 fw_name[BRCMF_FW_NAME_LEN];
+   u8 *ptr;
+   size_t len;
+   s32 err;
+
+   memset(fw_name, 0, BRCMF_FW_NAME_LEN);
+   err = brcmf_bus_get_fwname(bus, ri->chipnum, ri->chiprev, fw_name);
+   if (err) {
+   brcmf_err("get firmware name failed (%d)\n", err);
+   goto done;
+   }
+
+   /* generate CLM blob file name */
+   ptr = strrchr(fw_name, '.');
+   if (!ptr) {
+   err = -ENOENT;
+   goto done;
+   }
+
+   len = ptr - fw_name + 1;
+   if (len + strlen(".clm_blob") > BRCMF_FW_NAME_LEN) {
+   err = -E2BIG;
+   }