[PATCH] ath9k: off by one in ath9k_hw_nvram_read_array()

2017-04-05 Thread Dan Carpenter
The > should be >= or we read one space beyond the end of the array.

Fixes: ab5c4f71d8c7 ("ath9k: allow to load EEPROM content via firmware API")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c 
b/drivers/net/wireless/ath/ath9k/eeprom.c
index fb80ec86e53d..6ccf24814514 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -112,7 +112,7 @@ void ath9k_hw_usb_gen_fill_eeprom(struct ath_hw *ah, u16 
*eep_data,
 static bool ath9k_hw_nvram_read_array(u16 *blob, size_t blob_size,
  off_t offset, u16 *data)
 {
-   if (offset > blob_size)
+   if (offset >= blob_size)
return false;
 
*data =  blob[offset];


Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"

2017-04-05 Thread amit karwar
On Sat, Apr 1, 2017 at 1:51 AM, Brian Norris  wrote:
> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
>
> This above-mentioned "fix" does not actually do anything to prevent a
> race condition. It simply papers over it so that the issue doesn't
> appear.
>
> If this is a real problem, it should be explained better than the above
> commit does, and an alternative, non-racy solution should be found.
>
> For further reason to revert this: there's ot reason we can't try
> resetting the card when it's *actually* stuck in host-sleep mode. So
> instead, this is unnecessarily creating scenarios where we can't recover
> Wifi.
>
> Cc: Amitkumar Karwar 
> Signed-off-by: Brian Norris 
> ---
> Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you
> still think it's needed, can you please propose an alternative? Or at least
> explain more why this is needed? Thanks.
>

I agree. Fix just covers the issue. We need to investigate why system
hangs when card reset is attempted in host sleep activated scenario.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar Karwar


Re: [PATCH] mwifiex: MAC randomization should not be persistent

2017-04-05 Thread Kalle Valo
Brian Norris  writes:

> nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan
> request that should be randomized; the absence of such a flag means we
> should not randomize. However, mwifiex was stashing the latest
> randomization request and *always* using it for future scans, even those
> that didn't set the flag.
>
> Let's zero out the randomization info whenever we get a scan request
> without NL80211_SCAN_FLAG_RANDOM_ADDR. I'd prefer to remove
> priv->random_mac entirely (and plumb the randomization MAC properly
> through the call sequence), but the spaghetti is a little difficult to
> unravel here for me.
>
> Fixes: c2a8f0ff9c6c ("mwifiex: support random MAC address for scanning")

So the first release with this was v4.9.

> Signed-off-by: Brian Norris 
> ---
> Should this be tagged for -stable?

IMHO yes.

-- 
Kalle Valo


[PATCH v2] NFC: pn533: use constant off-stack buffer for sending acks

2017-04-05 Thread Michał Mirosław
fix for WARN:

usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
llcp: nfc_llcp_recv: err -5
llcp: nfc_llcp_symm_timer: SYMM timeout
[ cut here ]
WARNING: CPU: 1 PID: 26397 at .../drivers/usb/core/hcd.c:1584 
usb_hcd_map_urb_for_dma+0x370/0x550
transfer buffer not dma capable
[...]
Workqueue: events nfc_llcp_timeout_work [nfc]
Call Trace:
 ? dump_stack+0x46/0x5a
 ? __warn+0xb9/0xe0
 ? warn_slowpath_fmt+0x5a/0x80
 ? usb_hcd_map_urb_for_dma+0x370/0x550
 ? usb_hcd_submit_urb+0x2fb/0xa60
 ? dequeue_entity+0x3f2/0xc30
 ? pn533_usb_send_ack+0x5d/0x80 [pn533_usb]
 ? pn533_usb_abort_cmd+0x13/0x20 [pn533_usb]
 ? pn533_dep_link_down+0x32/0x70 [pn533]
 ? nfc_dep_link_down+0x87/0xd0 [nfc]
[...]
usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
llcp: nfc_llcp_recv: err -5
llcp: nfc_llcp_symm_timer: SYMM timeout

Signed-off-by: Michał Mirosław 
---
v2:
- "un-moved" other declarations
- rebased against nfc-next
---
 drivers/nfc/pn533/i2c.c | 2 +-
 drivers/nfc/pn533/usb.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 2c2fb9cfe10a..8f60ce039b0d 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -51,7 +51,7 @@ static int pn533_i2c_send_ack(struct pn533 *dev, gfp_t flags)
 {
struct pn533_i2c_phy *phy = dev->phy;
struct i2c_client *client = phy->i2c_dev;
-   u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
+   static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
/* spec 6.2.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
int rc;
 
diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
index 000159ea9c5f..8ed203ea21ea 100644
--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -148,11 +148,11 @@ static int pn533_submit_urb_for_ack(struct pn533_usb_phy 
*phy, gfp_t flags)
 static int pn533_usb_send_ack(struct pn533 *dev, gfp_t flags)
 {
struct pn533_usb_phy *phy = dev->phy;
-   u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
+   static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
/* spec 7.1.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
int rc;
 
-   phy->out_urb->transfer_buffer = ack;
+   phy->out_urb->transfer_buffer = (u8 *)ack;
phy->out_urb->transfer_buffer_length = sizeof(ack);
rc = usb_submit_urb(phy->out_urb, flags);
 
-- 
2.11.0



[PATCH] mwifiex: MAC randomization should not be persistent

2017-04-05 Thread Brian Norris
nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan
request that should be randomized; the absence of such a flag means we
should not randomize. However, mwifiex was stashing the latest
randomization request and *always* using it for future scans, even those
that didn't set the flag.

Let's zero out the randomization info whenever we get a scan request
without NL80211_SCAN_FLAG_RANDOM_ADDR. I'd prefer to remove
priv->random_mac entirely (and plumb the randomization MAC properly
through the call sequence), but the spaghetti is a little difficult to
unravel here for me.

Fixes: c2a8f0ff9c6c ("mwifiex: support random MAC address for scanning")
Signed-off-by: Brian Norris 
---
Should this be tagged for -stable?

 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 1e3bd435a694..2d7e8a372bf1 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2528,9 +2528,11 @@ mwifiex_cfg80211_scan(struct wiphy *wiphy,
priv->random_mac[i] |= get_random_int() &
   ~(request->mac_addr_mask[i]);
}
+   ether_addr_copy(user_scan_cfg->random_mac, priv->random_mac);
+   } else {
+   eth_zero_addr(priv->random_mac);
}
 
-   ether_addr_copy(user_scan_cfg->random_mac, priv->random_mac);
user_scan_cfg->num_ssids = request->n_ssids;
user_scan_cfg->ssid_list = request->ssids;
 
-- 
2.12.2.715.g7642488e1d-goog



[PATCH] brcmfmac: properly align buffers on certain platforms with 64 bit DMA

2017-04-05 Thread Heiner Kallweit
Systems with 64 bit DMA at least partially require buffers to be used
for DMA to be 8-byte-aligned. One example is Amlogic Meson GX.
Switching the MMC/SDIO driver for this platform to SG DMA mode
resulted in problems due to unaligned buffers.

Fortunately the brcmfmac driver has a global define for the alignment.
Changing it to 8 fixed the issues with Meson GX.

Suggested-by: Helmut Klein 
Tested-by: Helmut Klein 
Signed-off-by: Heiner Kallweit 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a999f950..fc64b891 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -540,7 +540,11 @@ static int qcount[NUMPRIO];
 /* Limit on rounding up frames */
 static const uint max_roundup = 512;
 
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+#define ALIGNMENT  8
+#else
 #define ALIGNMENT  4
+#endif
 
 enum brcmf_sdio_frmtype {
BRCMF_SDIO_FT_NORMAL,
-- 
2.12.1



Re: How to use netlink to determine wifi protection WEP

2017-04-05 Thread Dan Williams
On Wed, 2017-04-05 at 09:27 +0200, Thomas Thielemann wrote:
> Hello!
> 
> I need a solution to determine whether a WiFi is using WEP. I know
> there is a protection flag within MAC frame but do not know how to
> access.
> 
> To detect whether a WiFi i protected by WPA2 I found the following
> solution: 
> 
> Scan with
> 
> nl_sock* socket = nl_socket_alloc();
> genl_connect(socket);
> struct nl_msg* msg = nlmsg_alloc();
> int driverId = genl_ctrl_resolve(socket, "nl80211"); 
> genlmsg_put(msg, 0, 0, driverId, 0, 0, NL80211_CMD_TRIGGER_SCAN, 0);
> 
> and fetch with
> 
> genlmsg_put(msg, 0, 0, driverId, 0, NLM_F_DUMP, NL80211_CMD_GET_SCAN,
> 0);
> 
> Read the received structure using nl80211_bss::
> NL80211_BSS_INFORMATION_ELEMENTS from nl80211.h and
> 
> examine the field RSN(id=48) (see IEEE802.11-2012.pdf, chapter 8.4.2
> Information elements)
> 
> Which netlink command gives me the related data? Is it
> NL80211_CMD_GET_BEACON?

You want both the beacon (for the Privacy bit) and the information
elements.

If the privacy bit is set in beacon and there are no WPA/WPA2/RSN-
related information elements, then the AP is using WEP.  Unfortunately
you don't know whether it's WEP-40 or WEP-104, but that's another
topic.

If the privacy bit is set, and there are WPA/WPA2/RSN information
elements, then the AP *might* be using WEP in compatibility mode.  This
isn't very common though, so you can probably just ignore this case.

Dan


Re: [PATCH 0/7] ath10k: remove ath10k_sdio_io()

2017-04-05 Thread Erik Stromdahl

On 2017-04-05 18:53, Kalle Valo wrote:

Erik Stromdahl  writes:


I can't find patch 1/7...


Odd, apparently it didn't get delivered to ath10k list but did get to
linux-wireless. You can find the patch from linux-wireless patchwork:

https://patchwork.kernel.org/patch/9663097/

Also copying it below.

Kalle



ok, thanks.

I will add the patches to my tree and try them out.

--
Erik


[PATCH 23/38] Annotate hardware config module parameters in drivers/net/wireless/

2017-04-05 Thread David Howells
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/wireless/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
cc: Kalle Valo 
cc: linux-wireless@vger.kernel.org
cc: net...@vger.kernel.org
---

 drivers/net/wireless/cisco/airo.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/cisco/airo.c 
b/drivers/net/wireless/cisco/airo.c
index 4b040451a9b8..1b7e125a28e2 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -246,8 +246,8 @@ MODULE_DESCRIPTION("Support for Cisco/Aironet 802.11 
wireless ethernet cards.  "
   "Direct support for ISA/PCI/MPI cards and support for PCMCIA 
when used with airo_cs.");
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_SUPPORTED_DEVICE("Aironet 4500, 4800 and Cisco 340/350");
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_array(rates, int, NULL, 0);
 module_param_array(ssids, charp, NULL, 0);
 module_param(auto_wep, int, 0);



Re: [PATCH 0/7] ath10k: remove ath10k_sdio_io()

2017-04-05 Thread Kalle Valo
Erik Stromdahl  writes:

> I can't find patch 1/7...

Odd, apparently it didn't get delivered to ath10k list but did get to
linux-wireless. You can find the patch from linux-wireless patchwork:

https://patchwork.kernel.org/patch/9663097/

Also copying it below.

Kalle

Author: Kalle Valo 
Date:   Tue Mar 28 10:27:00 2017 +0300

ath10k: add ath10k_sdio_write32/read32()

Also remove ath10k_sdio_hif_set_addrwin_reg(), after the conversion it 
looked
useless.

Signed-off-by: Kalle Valo 

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index 0dced846035b..c7bc86e5063f 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -263,6 +263,53 @@ static int ath10k_sdio_read_write_sync(struct ath10k *ar, 
u32 addr, u8 *buf,
return ath10k_sdio_io(ar, request, addr, buf, len);
 }
 
+static int ath10k_sdio_write32(struct ath10k *ar, u32 addr, u32 val)
+{
+   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
+   struct sdio_func *func = ar_sdio->func;
+   int ret;
+
+   sdio_claim_host(func);
+
+   sdio_writel(func, val, addr, );
+   if (ret) {
+   ath10k_warn(ar, "failed to write 0x%x to address 0x%x: %d\n",
+   val, addr, ret);
+   goto out;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio write32 addr 0x%x val 0x%x\n",
+  addr, val);
+
+out:
+   sdio_release_host(func);
+
+   return ret;
+}
+
+static int ath10k_sdio_read32(struct ath10k *ar, u32 addr, u32 *val)
+{
+   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
+   struct sdio_func *func = ar_sdio->func;
+   int ret;
+
+   sdio_claim_host(func);
+   *val = sdio_readl(func, addr, );
+   if (ret) {
+   ath10k_warn(ar, "failed to read from address 0x%x: %d\n",
+   addr, ret);
+   goto out;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio read32 addr 0x%x val 0x%x\n",
+  addr, *val);
+
+out:
+   sdio_release_host(func);
+
+   return ret;
+}
+
 /* HIF mbox functions */
 
 static int ath10k_sdio_mbox_rx_process_packet(struct ath10k *ar,
@@ -617,27 +664,19 @@ static int ath10k_sdio_mbox_rxmsg_pending_handler(struct 
ath10k *ar,
 
 static int ath10k_sdio_mbox_proc_dbg_intr(struct ath10k *ar)
 {
-   u32 *dummy;
+   u32 val;
int ret;
 
-   dummy = kzalloc(sizeof(*dummy), GFP_KERNEL);
-   if (!dummy)
-   return -ENOMEM;
-
/* TODO: Add firmware crash handling */
ath10k_warn(ar, "firmware crashed\n");
 
/* read counter to clear the interrupt, the debug error interrupt is
 * counter 0.
 */
-   ret = ath10k_sdio_read_write_sync(ar, MBOX_COUNT_DEC_ADDRESS,
- (u8 *)dummy, sizeof(*dummy),
- HIF_RD_SYNC_BYTE_INC);
+   ret = ath10k_sdio_read32(ar, MBOX_COUNT_DEC_ADDRESS, );
if (ret)
ath10k_warn(ar, "failed to clear debug interrupt: %d\n", ret);
 
-   kfree(dummy);
-
return ret;
 }
 
@@ -972,90 +1011,70 @@ static void ath10k_sdio_set_mbox_info(struct ath10k *ar)
 
 static int ath10k_sdio_bmi_credits(struct ath10k *ar)
 {
-   int ret;
-   u32 addr, *cmd_credits;
+   u32 addr, cmd_credits;
unsigned long timeout;
-
-   cmd_credits = kzalloc(sizeof(*cmd_credits), GFP_KERNEL);
-   if (!cmd_credits)
-   return -ENOMEM;
+   int ret;
 
/* Read the counter register to get the command credits */
addr = MBOX_COUNT_DEC_ADDRESS + ATH10K_HIF_MBOX_NUM_MAX * 4;
-
timeout = jiffies + BMI_COMMUNICATION_TIMEOUT_HZ;
-   while (time_before(jiffies, timeout) && !*cmd_credits) {
+   cmd_credits = 0;
+
+   while (time_before(jiffies, timeout) && !cmd_credits) {
/* Hit the credit counter with a 4-byte access, the first byte
 * read will hit the counter and cause a decrement, while the
 * remaining 3 bytes has no effect. The rationale behind this
 * is to make all HIF accesses 4-byte aligned.
 */
-   ret = ath10k_sdio_read_write_sync(ar, addr,
- (u8 *)cmd_credits,
- sizeof(*cmd_credits),
- HIF_RD_SYNC_BYTE_INC);
+   ret = ath10k_sdio_read32(ar, addr, _credits);
if (ret) {
ath10k_warn(ar,
"unable to decrement the command credit 
count register: %d\n",
ret);
-   goto out;
+   return ret;
}
 
/* The counter is 

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-04-05 Thread Larry Finger

On 04/05/2017 04:36 AM, Hans de Goede wrote:

Hi,

On 05-04-17 01:41, Larry Finger wrote:

On 04/04/2017 04:53 PM, Hans de Goede wrote:

Hi,

On 04/04/2017 11:38 PM, Arend Van Spriel wrote:



On 4-4-2017 20:53, Hans de Goede wrote:

Hi,

On 04/04/2017 08:31 PM, Larry Finger wrote:

On 03/29/2017 12:47 PM, Hans de Goede wrote:

The rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel Computestick and various other
Atom based devices) and on many (budget) ARM boards such as
the CHIP.

The plan moving forward with this is for the new clean,
written from scratch, rtl8xxxu driver to eventually gain
support for sdio devices. But there is no clear timeline
for that, so lets add this driver included in staging for now.


Hans,

I started looking at the Smatch errors. This one may be the result of
a serious problem:

  CHECK   drivers/staging/rtl8723bs/core/rtw_debug.c
drivers/staging/rtl8723bs/core/rtw_debug.c:454 proc_get_survey_info()
error: we previously assumed 'phead' could be null (see line 453)
drivers/staging/rtl8723bs/core/rtw_debug.c:455 proc_get_survey_info()
warn: variable dereferenced before check 'phead' (see line 454)

A snippet of the code in question is as follows:

spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
phead = get_list_head(queue);
plist = phead ? get_next(phead) : NULL;
plist = get_next(phead);
if ((!phead) || (!plist)) {
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));
return 0;
}

This code comes directly from the hadess repo, but I am suspicious of
the double call to get_next(phead). I cannot imagine any valid reason
to skip every other entry on that list.


If you look closer and simplify the first getnext line what is written is:

 plist = get_next(phead);
 plist = get_next(phead);

Which indeed looks like it could use improvement, but I don't
think it is seriously broken.


So get_list_head(queue) can never return NULL?


I don't know.


Otherwise I don't know
how close I need to get for a simplified look ;-)


I simplified things so as to make clear that Larry's worry was
not really a problem, I do agree the smatch complaint is valid.


I think the following fixes the problem:

diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index d34747b29309..51cef55d3f76 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -451,7 +451,6 @@ int proc_get_survey_info(struct seq_file *m, void *v)
spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
phead = get_list_head(queue);
plist = phead ? get_next(phead) : NULL;
-   plist = get_next(phead);
if ((!phead) || (!plist)) {
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));
return 0;

Pointer plist is set in the 3rd line, thus the second set of it can be removed.


Agreed, when I've some time I plan to do a follow-up patch
to my initial submission fixing all the Smatch errors. But feel
free to beat me to it.

Greg, if I understood you correctly you plan to merge my initial
submission as is and then we can fix this (and other things) with
follow up patches, right ?


Hans,

I took GregKH out of the Cc list when I started the discussion of the Smatch 
errors/warnings, and he probably has not seen the recent E-mails in this thread. 
It it was my understanding that he planned to apply your submission in the form 
you sent.


I have several patches nearly ready to fix most of the Smatch warnings and 
errors. I will send them as soon as the original submission is applied.


Larry




[PATCH v2] mac80211: Dynamically set CoDel parameters per station

2017-04-05 Thread Toke Høiland-Jørgensen
CoDel can be too aggressive if a station sends at a very low rate,
leading to reduced throughput. This gets worse the more stations are
present, as each station gets more bursty the longer the round-robin
scheduling between stations takes.

This adds dynamic adjustment of CoDel parameters per station. It uses
the rate selection information to estimate throughput and sets more
lenient CoDel parameters if the estimated throughput is below a
threshold (modified by the number of active stations).

A new callback is added that drivers can use to notify mac80211 about
changes in expected throughput, so the same adjustment can be made for
cards that implement rate control in firmware. Drivers that don't use
this will just get the default parameters.

Signed-off-by: Toke Høiland-Jørgensen 
---
Changes since v1:
 - Get rid of the hysteresis (in practice we don't go above and below
   the threshold too often).
 - Lower threshold, but scaled with the number of active (backlogged)
   stations.
 
 include/net/mac80211.h | 17 +
 net/mac80211/debugfs_sta.c |  6 ++
 net/mac80211/rate.c|  3 ++-
 net/mac80211/sta_info.c| 31 +++
 net/mac80211/sta_info.h| 12 
 net/mac80211/tx.c  |  9 -
 6 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a3bab3c5ecfb..84ca624aa238 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4181,6 +4181,23 @@ void ieee80211_get_tx_rates(struct ieee80211_vif *vif,
int max_rates);
 
 /**
+ * ieee80211_sta_set_expected_throughput - set the expected throughput for a
+ * station
+ *
+ * Call this function to notify mac80211 about a change in expected throughput
+ * to a station. A driver for a device that does rate control in firmware can
+ * call this function when the expected throughput estimate towards a station
+ * changes. The information is used to tune the CoDel AQM applied to traffic
+ * going towards that station (which can otherwise be too aggressive and cause
+ * slow stations to starve).
+ *
+ * @sta: the station to set throughput for.
+ * @thr: the current expected throughput in kbps.
+ */
+void ieee80211_sta_set_expected_throughput(struct ieee80211_sta *pubsta,
+  u32 thr);
+
+/**
  * ieee80211_tx_status - transmit status callback
  *
  * Call this function for all transmitted frames after they have been
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 42601820db20..b15412c21ac9 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -154,6 +154,12 @@ static ssize_t sta_aqm_read(struct file *file, char __user 
*userbuf,
 
p += scnprintf(p,
   bufsz+buf-p,
+  "target %uus interval %uus ecn %s\n",
+  codel_time_to_us(sta->cparams.target),
+  codel_time_to_us(sta->cparams.interval),
+  sta->cparams.ecn ? "yes" : "no");
+   p += scnprintf(p,
+  bufsz+buf-p,
   "tid ac backlog-bytes backlog-packets new-flows drops 
marks overlimit collisions tx-bytes tx-packets\n");
 
for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 206698bc93f4..233c23ba2b98 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -890,6 +890,8 @@ int rate_control_set_rates(struct ieee80211_hw *hw,
 
drv_sta_rate_tbl_update(hw_to_local(hw), sta->sdata, pubsta);
 
+   ieee80211_sta_set_expected_throughput(pubsta, 
sta_get_expected_throughput(sta));
+
return 0;
 }
 EXPORT_SYMBOL(rate_control_set_rates);
@@ -938,4 +940,3 @@ void rate_control_deinitialize(struct ieee80211_local 
*local)
local->rate_ctrl = NULL;
rate_control_free(ref);
 }
-
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 3323a2fb289b..276ab08353b8 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include "ieee80211_i.h"
 #include "driver-ops.h"
@@ -420,6 +421,11 @@ struct sta_info *sta_info_alloc(struct 
ieee80211_sub_if_data *sdata,
 
sta->sta.max_rc_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_BA;
 
+   sta->cparams.ce_threshold = CODEL_DISABLED_THRESHOLD;
+   sta->cparams.target = MS2TIME(20);
+   sta->cparams.interval = MS2TIME(100);
+   sta->cparams.ecn = true;
+
sta_dbg(sdata, "Allocated STA %pM\n", sta->sta.addr);
 
return sta;
@@ -2298,3 +2304,28 @@ unsigned long ieee80211_sta_last_active(struct sta_info 
*sta)
return stats->last_rx;
return sta->status_stats.last_ack;
 }
+
+static inline void sta_update_codel_params(struct sta_info *sta, u32 thr)
+{
+   if (!sta->sdata->local->ops->wake_tx_queue)
+   return;
+
+   if (thr && thr 

Re: [PATCH 0/7] ath10k: remove ath10k_sdio_io()

2017-04-05 Thread Erik Stromdahl

I can't find patch 1/7...

On 2017-04-05 09:06, Kalle Valo wrote:

Using ath10k_sdio_io() and ath10k_sdio_read_write_sync() are just
confusing. Refactor the code by following the plan outlined
below.

I'm planning to fold all these seven patches into Erik's patch
adding sdio.c[1] so I didn't write any commit logs. I'm just
submitting these separately to make it easier to review the
changes.

Kalle

ath10k_sdio_read_write_sync():
X HIF_RD_SYNC_BLOCK_FIX -> ath10k_sdio_readsb()
X HIF_RD_SYNC_BYTE_INC  -> ath10k_sdio_read(), ath10k_sdio_read32()
X HIF_WR_SYNC_BYTE_FIX  -> ath10k_sdio_writesb32()
X HIF_WR_SYNC_BYTE_INC  -> ath10k_sdio_write()

ath10k_sdio_prep_async_req():
X HIF_WRITE -> HIF_WR_SYNC_BYTE_INC -> ath10k_sdio_write()

ath10k_sdio_read/write32():
sdio_readl()/sdio_writel() (those use endian macros)

ath10k_sdio_writesb32():
kmalloc()
sdio_writesb(len)
kfree()

ath10k_sdio_readsb():
len = round_down(len, ar_sdio->mbox_info.block_size);
sdio_readsb(len)

ath10k_sdio_read():
sdio_memcpy_fromio()

ath10k_sdio_write():
sdio_memcpy_toio()


[1] https://patchwork.kernel.org/patch/9626001/

---

Kalle Valo (7):
  ath10k: add ath10k_sdio_write32/read32()
  ath10k: add ath10k_sdio_writesb()
  ath10k: add ath10k_sdio_read()
  ath10k: add ath10k_sdio_write()
  ath10k: add ath10k_sdio_readsb()
  ath10k: convert __ath10k_sdio_write_async() to use ath10k_sdio_write()
  ath10k: remove unused sdio wrappers


 drivers/net/wireless/ath/ath10k/sdio.c |  419 +---
 drivers/net/wireless/ath/ath10k/sdio.h |   40 ---
 2 files changed, 219 insertions(+), 240 deletions(-)


___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k



Re: [PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock

2017-04-05 Thread Samuel Ortiz
Hi Geoff,

On Wed, Dec 21, 2016 at 11:18:32PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options to support hardware designs
> which use a 27.12MHz clock. This commit adds a device tree option
> 'clock-frequency' to support configuring the this chip for default
> 13.56MHz clock or the optional 27.12MHz clock.
> 
> Signed-off-by: Geoff Lansberry 
> ---
>  .../devicetree/bindings/net/nfc/trf7970a.txt   |  2 +
>  drivers/nfc/trf7970a.c | 50 
> +-
>  2 files changed, 41 insertions(+), 11 deletions(-)
Patches #1 and #2 applied to nfc-next. I'll wait for you to rework #3
before merging.

Cheers,
Samuel.


Re: mwifiex: add missing IEs related to TDLS operation

2017-04-05 Thread Kalle Valo
Ganapathi Bhat  wrote:
> From: Karthik Ananthapadmanabha 
> 
> In mwifiex,IEs such as supported channels, supported operating classes
> 20/40 BSS COexistence are missing and also extra QOS capabilities IE
> is added during TDLS discovery response, TDLS setup request and
> TDLS setupresponse.
> This patch adds require IEs and also removes extra IE.
> 
> Signed-off-by: Karthik Ananthapadmanabha 
> Signed-off-by: Ganapathi Bhat 

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

38c51d03cef4 mwifiex: add missing IEs related to TDLS operation

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

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



Re: [v2] mwifiex: apply radar flag

2017-04-05 Thread Kalle Valo
Ganapathi Bhat  wrote:
> From: Karthik Ananthapadmanabha 
> 
> When IEEE80211_CHAN_RADAR is set by cfg80211, passive scan must be
> performed. In mwifiex,active scan is performed even though flag is
> set from cfg80211. mwifiex_reg_apply_radar_flags() function added
> in this patch correctly uses radar flag.
> 
> Signed-off-by: Karthik Ananthapadmanabha 
> Signed-off-by: Amitkumar Karwar 
> Signed-off-by: Ganapathi Bhat 

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

1aed89640a89 mwifiex: apply radar flag

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

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



Re: [v3,01/12] rtlwifi: btcoex: remove unused functions

2017-04-05 Thread Kalle Valo
Larry Finger  wrote:
> From: Yan-Hsuan Chuang 
> 
> A number of functions in the Bluetooth Coexistence routines are not used,
> and can be removed.
> 
> Signed-off-by: Yan-Hsuan Chuang 
> Signed-off-by: Larry Finger 
> Cc: Pkshih 
> Cc: Birming Chiu 
> Cc: Shaofu 
> Cc: Steven Ting 

12 patches applied to wireless-drivers-next.git, thanks.

27a31a60a4de rtlwifi: btcoex: remove unused functions
c6821613e653 rtlwifi: btcoex: follow linux coding style
155305f5b0eb rtlwifi: btcoex: 23b 2ant: add btc8723b2ant_limited_rx to reduce 
agg size
61d802619bc6 rtlwifi: btcoex: 23b 2ant: detect if bt is slave, and modify tdma
55e9e37da2ce rtlwifi: btcoex: 23b 2ant: monitor wifi counter for allocate tdma 
time
e4782bc6ce9a rtlwifi: btcoex: 23b 2ant: less sensitive to tx rate penalty
3f957062c96c rtlwifi: btcoex: 23b 2ant: adjust wifi duration for bt a2dp
f36714fbfa6d rtlwifi: btcoex: 23b 2ant: coex table fine tune
7ff98093220b rtlwifi: btcoex: 23b 2ant: remove redundant bt stack report
44e9a5340e68 rtlwifi: btcoex: 23b 2ant: finer bt power adjustment
a66a4176b74c rtlwifi: btcoex: 23b 2ant: add comments to describe how duration 
adjusted
495d36e66814 rtlwifi: btcoex: 23b 2ant: new fw use h2c to control GNT_BT

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

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



Re: [V2] wlcore: fix spelling mistakes in wl1271_warning

2017-04-05 Thread Kalle Valo
Colin Ian King  wrote:
> From: Colin Ian King 
> 
> trivial fix to spelling mistakes in wl1271_warning error message, change
> iligal to invalid and opperation to operation.
> 
> Signed-off-by: Colin Ian King 

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

5ea807896160 wlcore: fix spelling mistakes in wl1271_warning

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

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



Re: [1/2] mwifiex: fix use-after-free for FW reinit errors

2017-04-05 Thread Kalle Valo
Brian Norris  wrote:
> If we fail to reinit the FW when resetting the device (in the
> synchronous version of mwifiex_init_hw_fw() -> mwifiex_fw_dpc()),
> mwifiex_fw_dpc() will tear down the interface and free up the adapter.
> But we don't actually check for all failure cases of mwifiex_fw_dpc(),
> so some of them fall through and dereference adapter->fw_done with a
> freed adapter, causing a use-after-free bug.
> 
> In any case, mwifiex_fw_dpc() will always signal FW completion -- in the
> error OR success case -- so at best, this was repeat work. Let's not do
> it.
> 
> Signed-off-by: Brian Norris 

2 patches applied to wireless-drivers-next.git, thanks.

ce8fad9a1f09 mwifiex: fix use-after-free for FW reinit errors
755b37c93a06 mwifiex: catch mwifiex_fw_dpc() errors properly in reset

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

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



Re: [1/5] brcmfmac: wrap brcmf_fws_init into bcdc layer

2017-04-05 Thread Kalle Valo
Arend Van Spriel  wrote:
> From: Franky Lin 
> 
> Create a new protocol layer interface brcmf_proto_init_cb for protocol
> layer to finish initialzation after core module components(fweh and
> etc.) are initialized.
> 
> Signed-off-by: Franky Lin 
> Reviewed-by: Arend Van Spriel 
> Signed-off-by: Arend van Spriel 

5 patches applied to wireless-drivers-next.git, thanks.

62c50a34883c brcmfmac: wrap brcmf_fws_init into bcdc layer
8f9dd1a97438 brcmfmac: move brcmf_fws_deinit to bcdc layer
0cc0236cf713 brcmfmac: add support to move wiphy instance into network namespace
49fe9b59f0e9 brcmfmac: restore bus state when enter_D3 fails
78b9ccb81377 brcmfmac: no need for d11inf instance in 
brcmf_pno_start_sched_scan()

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

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



Re: mwifiex: enable auto deep sleep mode for USB chipsets

2017-04-05 Thread Kalle Valo
Amitkumar Karwar  wrote:
> Chip goes into low power state when this feature is enabled.
> This was already enabled for SDIO and PCIe interface based
> chipsets.
> 
> Signed-off-by: Amitkumar Karwar 

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

36491b152c30 mwifiex: enable auto deep sleep mode for USB chipsets

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

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



Re: [v2] mwifiex: Support USB interrupt endpoint for command response/event

2017-04-05 Thread Kalle Valo
Ganapathi Bhat  wrote:
> USB firmware added support for sending command response/event through
> interrupt endpoint, to enhance RX throughput. Added corresponding changes
> required to support this feature. This change takes care of backward
> compatibility with older firmware.
> 
> Signed-off-by: Ganapathi Bhat 

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

182f56966054 mwifiex: Support USB interrupt endpoint for command response/event

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

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



Re: [V2] brcmfmac: update BRCMFMAC symbol description

2017-04-05 Thread Kalle Valo
Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> For quite some time now brcmfmac supports 802.11ac chipsets and it's
> not limited to embedded devices only. There are even standalone PCIe
> cards based on BCM43602 or BCM4366.
> 
> Signed-off-by: Rafał Miłecki 
> Reviewed-by: Arend van Spriel 

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

1c92af00a560 brcmfmac: update BRCMFMAC symbol description

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

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



[PATCH 03/11] wil6210: support 8KB RX buffers

2017-04-05 Thread Maya Erez
From: Lior David 

The 11ad spec requires 11ad devices to be able to receive 8KB
packets over the air. Currently this is only possible by
loading the driver with mtu_max=7912 but this also forces
a smaller block ACK window size which reduces performance
for stations which transmit normal sized packets (<2KB).
Fix this problem as follows:
1. Add a module parameter rx_large_buf that when set,
will allocate 8KB RX buffers regardless of mtu_max
setting.
2. When receiving block ACK request agree to any window
size not above our maximum, regardless of the mtu_max setting.
This means if the other side transmits small packets (2KB)
it can still set up block ACK with a large window size,
and get better performance.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/rx_reorder.c | 12 ++--
 drivers/net/wireless/ath/wil6210/txrx.c   | 24 ++--
 drivers/net/wireless/ath/wil6210/wil6210.h|  2 ++
 drivers/net/wireless/ath/wil6210/wmi.c|  3 ++-
 4 files changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/rx_reorder.c 
b/drivers/net/wireless/ath/wil6210/rx_reorder.c
index 7404b6f..a43cffc 100644
--- a/drivers/net/wireless/ath/wil6210/rx_reorder.c
+++ b/drivers/net/wireless/ath/wil6210/rx_reorder.c
@@ -343,8 +343,16 @@ int wil_addba_rx_request(struct wil6210_priv *wil, u8 
cidxtid,
wil_err(wil, "BACK requested unsupported ba_policy == 1\n");
status = WLAN_STATUS_INVALID_QOS_PARAM;
}
-   if (status == WLAN_STATUS_SUCCESS)
-   agg_wsize = wil_agg_size(wil, req_agg_wsize);
+   if (status == WLAN_STATUS_SUCCESS) {
+   if (req_agg_wsize == 0) {
+   wil_dbg_misc(wil, "Suggest BACK wsize %d\n",
+WIL_MAX_AGG_WSIZE);
+   agg_wsize = WIL_MAX_AGG_WSIZE;
+   } else {
+   agg_wsize = min_t(u16,
+ WIL_MAX_AGG_WSIZE, req_agg_wsize);
+   }
+   }
 
rc = wmi_addba_rx_resp(wil, cid, tid, dialog_token, status,
   agg_amsdu, agg_wsize, agg_timeout);
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c 
b/drivers/net/wireless/ath/wil6210/txrx.c
index 67f50ae..edab4c0 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -37,6 +37,10 @@
 module_param(rx_align_2, bool, 0444);
 MODULE_PARM_DESC(rx_align_2, " align Rx buffers on 4*n+2, default - no");
 
+bool rx_large_buf;
+module_param(rx_large_buf, bool, 0444);
+MODULE_PARM_DESC(rx_large_buf, " allocate 8KB RX buffers, default - no");
+
 static inline uint wil_rx_snaplen(void)
 {
return rx_align_2 ? 6 : 0;
@@ -255,7 +259,7 @@ static int wil_vring_alloc_skb(struct wil6210_priv *wil, 
struct vring *vring,
   u32 i, int headroom)
 {
struct device *dev = wil_to_dev(wil);
-   unsigned int sz = mtu_max + ETH_HLEN + wil_rx_snaplen();
+   unsigned int sz = wil->rx_buf_len + ETH_HLEN + wil_rx_snaplen();
struct vring_rx_desc dd, *d = 
volatile struct vring_rx_desc *_d = >va[i].rx;
dma_addr_t pa;
@@ -419,7 +423,7 @@ static struct sk_buff *wil_vring_reap_rx(struct 
wil6210_priv *wil,
struct sk_buff *skb;
dma_addr_t pa;
unsigned int snaplen = wil_rx_snaplen();
-   unsigned int sz = mtu_max + ETH_HLEN + snaplen;
+   unsigned int sz = wil->rx_buf_len + ETH_HLEN + snaplen;
u16 dmalen;
u8 ftype;
int cid;
@@ -780,6 +784,20 @@ void wil_rx_handle(struct wil6210_priv *wil, int *quota)
wil_rx_refill(wil, v->size);
 }
 
+static void wil_rx_buf_len_init(struct wil6210_priv *wil)
+{
+   wil->rx_buf_len = rx_large_buf ?
+   WIL_MAX_ETH_MTU : TXRX_BUF_LEN_DEFAULT - WIL_MAX_MPDU_OVERHEAD;
+   if (mtu_max > wil->rx_buf_len) {
+   /* do not allow RX buffers to be smaller than mtu_max, for
+* backward compatibility (mtu_max parameter was also used
+* to support receiving large packets)
+*/
+   wil_info(wil, "Override RX buffer to mtu_max(%d)\n", mtu_max);
+   wil->rx_buf_len = mtu_max;
+   }
+}
+
 int wil_rx_init(struct wil6210_priv *wil, u16 size)
 {
struct vring *vring = >vring_rx;
@@ -792,6 +810,8 @@ int wil_rx_init(struct wil6210_priv *wil, u16 size)
return -EINVAL;
}
 
+   wil_rx_buf_len_init(wil);
+
vring->size = size;
rc = wil_vring_alloc(wil, vring);
if (rc)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index 9cedc2d..2af4a64 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -32,6 +32,7 @@
 

[PATCH 00/11] wil6210 patches

2017-04-05 Thread Maya Erez
Various wil6210 fixes

Dedy Lansky (3):
  wil6210: align to latest auto generated wmi.h
  wil6210: fix memory access violation in wil_memcpy_from/toio_32
  wil6210: fix array out of bounds access in pmc

Hamad Kadmany (3):
  wil6210: fix sequence for scan-abort during reset
  wil6210: fix protection against connections during reset
  wil6210: fix check for sparrow D0 FW file

Lazar Alexei (1):
  wil6210: restore power save state after internal FW reset

Lior David (1):
  wil6210: support 8KB RX buffers

Maya Erez (3):
  wil6210: protect against sporadic interrupt during suspend flow
  wil6210: remove HALP voting in debugfs ioblob
  wil6210: prevent access to 11AD device if resume fails

 drivers/net/wireless/ath/wil6210/cfg80211.c   | 12 +
 drivers/net/wireless/ath/wil6210/debugfs.c|  5 +-
 drivers/net/wireless/ath/wil6210/fw_inc.c |  4 +-
 drivers/net/wireless/ath/wil6210/main.c   | 65 
 drivers/net/wireless/ath/wil6210/pm.c | 27 +-
 drivers/net/wireless/ath/wil6210/pmc.c|  4 +-
 drivers/net/wireless/ath/wil6210/rx_reorder.c | 12 -
 drivers/net/wireless/ath/wil6210/txrx.c   | 24 -
 drivers/net/wireless/ath/wil6210/wil6210.h| 13 ++---
 drivers/net/wireless/ath/wil6210/wmi.c| 14 +++--
 drivers/net/wireless/ath/wil6210/wmi.h| 73 +++
 11 files changed, 178 insertions(+), 75 deletions(-)

-- 
1.9.1



[PATCH 01/11] wil6210: fix sequence for scan-abort during reset

2017-04-05 Thread Maya Erez
From: Hamad Kadmany 

Communication with FW must be done before wil->status
is initialized in order to properly handle cases where
communication with FW halts during reset sequence.

Signed-off-by: Hamad Kadmany 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index c33cc4a..7e72096 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -948,15 +948,15 @@ int wil_reset(struct wil6210_priv *wil, bool load_fw)
/* Disable device led before reset*/
wmi_led_cfg(wil, false);
 
+   mutex_lock(>p2p_wdev_mutex);
+   wil_abort_scan(wil, false);
+   mutex_unlock(>p2p_wdev_mutex);
+
/* prevent NAPI from being scheduled and prevent wmi commands */
mutex_lock(>wmi_mutex);
bitmap_zero(wil->status, wil_status_last);
mutex_unlock(>wmi_mutex);
 
-   mutex_lock(>p2p_wdev_mutex);
-   wil_abort_scan(wil, false);
-   mutex_unlock(>p2p_wdev_mutex);
-
wil_mask_irq(wil);
 
wmi_event_flush(wil);
-- 
1.9.1



[PATCH 10/11] wil6210: fix array out of bounds access in pmc

2017-04-05 Thread Maya Erez
From: Dedy Lansky 

Array index 'i' is used before limits check.
Fix this by doing limits check first.

Signed-off-by: Dedy Lansky 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/pmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/pmc.c 
b/drivers/net/wireless/ath/wil6210/pmc.c
index b067fdf..2e301b6 100644
--- a/drivers/net/wireless/ath/wil6210/pmc.c
+++ b/drivers/net/wireless/ath/wil6210/pmc.c
@@ -200,7 +200,7 @@ void wil_pmc_alloc(struct wil6210_priv *wil,
 
 release_pmc_skbs:
wil_err(wil, "exit on error: Releasing skbs...\n");
-   for (i = 0; pmc->descriptors[i].va && i < num_descriptors; i++) {
+   for (i = 0; i < num_descriptors && pmc->descriptors[i].va; i++) {
dma_free_coherent(dev,
  descriptor_size,
  pmc->descriptors[i].va,
@@ -283,7 +283,7 @@ void wil_pmc_free(struct wil6210_priv *wil, int 
send_pmc_cmd)
int i;
 
for (i = 0;
-pmc->descriptors[i].va && i < pmc->num_descriptors; i++) {
+i < pmc->num_descriptors && pmc->descriptors[i].va; i++) {
dma_free_coherent(dev,
  pmc->descriptor_size,
  pmc->descriptors[i].va,
-- 
1.9.1



[PATCH 09/11] wil6210: remove HALP voting in debugfs ioblob

2017-04-05 Thread Maya Erez
debugfs ioblob function is called by the FW logs scripts
to copy the FW logs via PCIe.
As the FW logs collection is done in parallel to the operational
11AD actions, the HALP voting can take place during 11AD reset flow
and other sensitive scenarios.
To prevent that, remove HALP voting from the ioblob function.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/debugfs.c |  5 ++---
 drivers/net/wireless/ath/wil6210/main.c| 17 -
 drivers/net/wireless/ath/wil6210/wil6210.h |  6 --
 3 files changed, 2 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 3e8cdf1..5648ebb 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -524,9 +524,8 @@ static ssize_t wil_read_file_ioblob(struct file *file, char 
__user *user_buf,
if (!buf)
return -ENOMEM;
 
-   wil_memcpy_fromio_halp_vote(wil_blob->wil, buf,
-   (const volatile void __iomem *)
-   wil_blob->blob.data + pos, count);
+   wil_memcpy_fromio_32(buf, (const void __iomem *)
+wil_blob->blob.data + pos, count);
 
ret = copy_to_user(user_buf, buf, count);
kfree(buf);
diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index 439d27c..3208679 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -141,14 +141,6 @@ void wil_memcpy_fromio_32(void *dst, const volatile void 
__iomem *src,
}
 }
 
-void wil_memcpy_fromio_halp_vote(struct wil6210_priv *wil, void *dst,
-const volatile void __iomem *src, size_t count)
-{
-   wil_halp_vote(wil);
-   wil_memcpy_fromio_32(dst, src, count);
-   wil_halp_unvote(wil);
-}
-
 void wil_memcpy_toio_32(volatile void __iomem *dst, const void *src,
size_t count)
 {
@@ -167,15 +159,6 @@ void wil_memcpy_toio_32(volatile void __iomem *dst, const 
void *src,
}
 }
 
-void wil_memcpy_toio_halp_vote(struct wil6210_priv *wil,
-  volatile void __iomem *dst,
-  const void *src, size_t count)
-{
-   wil_halp_vote(wil);
-   wil_memcpy_toio_32(dst, src, count);
-   wil_halp_unvote(wil);
-}
-
 static void wil_disconnect_cid(struct wil6210_priv *wil, int cid,
   u16 reason_code, bool from_event)
 __acquires(>tid_rx_lock) __releases(>tid_rx_lock)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index 2af4a64..ec646d7 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -803,12 +803,6 @@ void wil_memcpy_fromio_32(void *dst, const volatile void 
__iomem *src,
  size_t count);
 void wil_memcpy_toio_32(volatile void __iomem *dst, const void *src,
size_t count);
-void wil_memcpy_fromio_halp_vote(struct wil6210_priv *wil, void *dst,
-const volatile void __iomem *src,
-size_t count);
-void wil_memcpy_toio_halp_vote(struct wil6210_priv *wil,
-  volatile void __iomem *dst,
-  const void *src, size_t count);
 
 void *wil_if_alloc(struct device *dev);
 void wil_if_free(struct wil6210_priv *wil);
-- 
1.9.1



[PATCH 07/11] wil6210: fix check for sparrow D0 FW file

2017-04-05 Thread Maya Erez
From: Hamad Kadmany 

Driver fails to load FW for sparrow D0 devices in some cases.
Fix this by returning correct value from wil_fw_verify_file_exists
when D0 FW file is not detected for any reason.

Signed-off-by: Hamad Kadmany 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/fw_inc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/fw_inc.c 
b/drivers/net/wireless/ath/wil6210/fw_inc.c
index f4901587..e01acac 100644
--- a/drivers/net/wireless/ath/wil6210/fw_inc.c
+++ b/drivers/net/wireless/ath/wil6210/fw_inc.c
@@ -554,5 +554,7 @@ bool wil_fw_verify_file_exists(struct wil6210_priv *wil, 
const char *name)
rc = request_firmware(, name, wil_to_dev(wil));
if (!rc)
release_firmware(fw);
-   return rc != -ENOENT;
+   else
+   wil_dbg_fw(wil, "<%s> not available: %d\n", name, rc);
+   return !rc;
 }
-- 
1.9.1



[PATCH 08/11] wil6210: fix memory access violation in wil_memcpy_from/toio_32

2017-04-05 Thread Maya Erez
From: Dedy Lansky 

In case count is not multiple of 4, there is a read access in
wil_memcpy_toio_32() from outside src buffer boundary.
In wil_memcpy_fromio_32(), in case count is not multiple of 4, there is
a write access to outside dst io memory boundary.

Fix these issues with proper handling of the last 1 to 4 copied bytes.

Signed-off-by: Dedy Lansky 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/main.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index 9aa81ce..439d27c 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -130,9 +130,15 @@ void wil_memcpy_fromio_32(void *dst, const volatile void 
__iomem *src,
u32 *d = dst;
const volatile u32 __iomem *s = src;
 
-   /* size_t is unsigned, if (count%4 != 0) it will wrap */
-   for (count += 4; count > 4; count -= 4)
+   for (; count >= 4; count -= 4)
*d++ = __raw_readl(s++);
+
+   if (unlikely(count)) {
+   /* count can be 1..3 */
+   u32 tmp = __raw_readl(s);
+
+   memcpy(d, , count);
+   }
 }
 
 void wil_memcpy_fromio_halp_vote(struct wil6210_priv *wil, void *dst,
@@ -149,8 +155,16 @@ void wil_memcpy_toio_32(volatile void __iomem *dst, const 
void *src,
volatile u32 __iomem *d = dst;
const u32 *s = src;
 
-   for (count += 4; count > 4; count -= 4)
+   for (; count >= 4; count -= 4)
__raw_writel(*s++, d++);
+
+   if (unlikely(count)) {
+   /* count can be 1..3 */
+   u32 tmp = 0;
+
+   memcpy(, s, count);
+   __raw_writel(tmp, d);
+   }
 }
 
 void wil_memcpy_toio_halp_vote(struct wil6210_priv *wil,
-- 
1.9.1



[PATCH 06/11] wil6210: protect against sporadic interrupt during suspend flow

2017-04-05 Thread Maya Erez
During the suspend flow, wil6210 HW can send sporadic interrupts,
while PCIe bus is not operational.
To prevent that, keep the interrupts disabled during the suspend
flow and re-enable them only after PCIe enablement in resume.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/pm.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/pm.c 
b/drivers/net/wireless/ath/wil6210/pm.c
index a0acb2d..7260bef 100644
--- a/drivers/net/wireless/ath/wil6210/pm.c
+++ b/drivers/net/wireless/ath/wil6210/pm.c
@@ -80,12 +80,20 @@ int wil_suspend(struct wil6210_priv *wil, bool is_runtime)
}
}
 
-   if (wil->platform_ops.suspend)
+   /* Disable PCIe IRQ to prevent sporadic IRQs when PCIe is suspending */
+   wil_dbg_pm(wil, "Disabling PCIe IRQ before suspending\n");
+   wil_disable_irq(wil);
+
+   if (wil->platform_ops.suspend) {
rc = wil->platform_ops.suspend(wil->platform_handle);
+   if (rc)
+   wil_enable_irq(wil);
+   }
 
 out:
wil_dbg_pm(wil, "suspend: %s => %d\n",
   is_runtime ? "runtime" : "system", rc);
+
return rc;
 }
 
@@ -104,6 +112,9 @@ int wil_resume(struct wil6210_priv *wil, bool is_runtime)
}
}
 
+   wil_dbg_pm(wil, "Enabling PCIe IRQ\n");
+   wil_enable_irq(wil);
+
/* if netif up, bring hardware up
 * During open(), IFF_UP set after actual device method
 * invocation. This prevent recursive call to wil_up()
-- 
1.9.1



[PATCH 04/11] wil6210: align to latest auto generated wmi.h

2017-04-05 Thread Maya Erez
From: Dedy Lansky 

Align to latest version of the auto generated wmi file
describing the interface with FW

Signed-off-by: Dedy Lansky 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/wmi.h | 73 --
 1 file changed, 52 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/wmi.h 
b/drivers/net/wireless/ath/wil6210/wmi.h
index 7c9fee5..f7f5f4f 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.h
+++ b/drivers/net/wireless/ath/wil6210/wmi.h
@@ -58,6 +58,7 @@ enum wmi_fw_capability {
WMI_FW_CAPABILITY_MGMT_RETRY_LIMIT  = 3,
WMI_FW_CAPABILITY_DISABLE_AP_SME= 4,
WMI_FW_CAPABILITY_WMI_ONLY  = 5,
+   WMI_FW_CAPABILITY_THERMAL_THROTTLING= 7,
WMI_FW_CAPABILITY_MAX,
 };
 
@@ -142,8 +143,6 @@ enum wmi_command_id {
WMI_MAINTAIN_RESUME_CMDID   = 0x851,
WMI_RS_MGMT_CMDID   = 0x852,
WMI_RF_MGMT_CMDID   = 0x853,
-   WMI_THERMAL_THROTTLING_CTRL_CMDID   = 0x854,
-   WMI_THERMAL_THROTTLING_GET_STATUS_CMDID = 0x855,
WMI_OTP_READ_CMDID  = 0x856,
WMI_OTP_WRITE_CMDID = 0x857,
WMI_LED_CFG_CMDID   = 0x858,
@@ -192,6 +191,8 @@ enum wmi_command_id {
WMI_GET_MGMT_RETRY_LIMIT_CMDID  = 0x931,
WMI_NEW_STA_CMDID   = 0x935,
WMI_DEL_STA_CMDID   = 0x936,
+   WMI_SET_THERMAL_THROTTLING_CFG_CMDID= 0x940,
+   WMI_GET_THERMAL_THROTTLING_CFG_CMDID= 0x941,
WMI_TOF_SESSION_START_CMDID = 0x991,
WMI_TOF_GET_CAPABILITIES_CMDID  = 0x992,
WMI_TOF_SET_LCR_CMDID   = 0x993,
@@ -438,16 +439,6 @@ struct wmi_rf_mgmt_cmd {
__le32 rf_mgmt_type;
 } __packed;
 
-/* WMI_THERMAL_THROTTLING_CTRL_CMDID */
-#define THERMAL_THROTTLING_USE_DEFAULT_MAX_TXOP_LENGTH (0x)
-
-/* WMI_THERMAL_THROTTLING_CTRL_CMDID */
-struct wmi_thermal_throttling_ctrl_cmd {
-   __le32 time_on_usec;
-   __le32 time_off_usec;
-   __le32 max_txop_length_usec;
-} __packed;
-
 /* WMI_RF_RX_TEST_CMDID */
 struct wmi_rf_rx_test_cmd {
__le32 sector;
@@ -549,7 +540,7 @@ struct wmi_pcp_start_cmd {
u8 hidden_ssid;
u8 is_go;
u8 reserved0[5];
-   /* abft_len override if non-0 */
+   /* A-BFT length override if non-0 */
u8 abft_len;
u8 disable_ap_sme;
u8 network_type;
@@ -910,6 +901,39 @@ struct wmi_set_mgmt_retry_limit_cmd {
u8 reserved[3];
 } __packed;
 
+/* Zones: HIGH, MAX, CRITICAL */
+#define WMI_NUM_OF_TT_ZONES(3)
+
+struct wmi_tt_zone_limits {
+   /* Above this temperature this zone is active */
+   u8 temperature_high;
+   /* Below this temperature the adjacent lower zone is active */
+   u8 temperature_low;
+   u8 reserved[2];
+} __packed;
+
+/* Struct used for both configuration and status commands of thermal
+ * throttling
+ */
+struct wmi_tt_data {
+   /* Enable/Disable TT algorithm for baseband */
+   u8 bb_enabled;
+   u8 reserved0[3];
+   /* Define zones for baseband */
+   struct wmi_tt_zone_limits bb_zones[WMI_NUM_OF_TT_ZONES];
+   /* Enable/Disable TT algorithm for radio */
+   u8 rf_enabled;
+   u8 reserved1[3];
+   /* Define zones for all radio chips */
+   struct wmi_tt_zone_limits rf_zones[WMI_NUM_OF_TT_ZONES];
+} __packed;
+
+/* WMI_SET_THERMAL_THROTTLING_CFG_CMDID */
+struct wmi_set_thermal_throttling_cfg_cmd {
+   /* Command data */
+   struct wmi_tt_data tt_data;
+} __packed;
+
 /* WMI_NEW_STA_CMDID */
 struct wmi_new_sta_cmd {
u8 dst_mac[WMI_MAC_LEN];
@@ -1040,7 +1064,6 @@ enum wmi_event_id {
WMI_BF_RXSS_MGMT_DONE_EVENTID   = 0x1839,
WMI_RS_MGMT_DONE_EVENTID= 0x1852,
WMI_RF_MGMT_STATUS_EVENTID  = 0x1853,
-   WMI_THERMAL_THROTTLING_STATUS_EVENTID   = 0x1855,
WMI_BF_SM_MGMT_DONE_EVENTID = 0x1838,
WMI_RX_MGMT_PACKET_EVENTID  = 0x1840,
WMI_TX_MGMT_PACKET_EVENTID  = 0x1841,
@@ -1090,6 +1113,8 @@ enum wmi_event_id {
WMI_BRP_SET_ANT_LIMIT_EVENTID   = 0x1924,
WMI_SET_MGMT_RETRY_LIMIT_EVENTID= 0x1930,
WMI_GET_MGMT_RETRY_LIMIT_EVENTID= 0x1931,
+   WMI_SET_THERMAL_THROTTLING_CFG_EVENTID  = 0x1940,
+   WMI_GET_THERMAL_THROTTLING_CFG_EVENTID  = 0x1941,
WMI_TOF_SESSION_END_EVENTID = 0x1991,
WMI_TOF_GET_CAPABILITIES_EVENTID= 0x1992,

[PATCH 05/11] wil6210: fix protection against connections during reset

2017-04-05 Thread Maya Erez
From: Hamad Kadmany 

Existing code that ignores connection events during
reset flow will never take effect since it locks the
same mutex taken by the reset flow.

In addition, in case of unsolicited disconnect events ignore
those as well since device is about to get reset.

Signed-off-by: Hamad Kadmany 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/wmi.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/wmi.c 
b/drivers/net/wireless/ath/wil6210/wmi.c
index e6c249d..814c356 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -518,16 +518,16 @@ static void wmi_evt_connect(struct wil6210_priv *wil, int 
id, void *d, int len)
assoc_resp_ielen = 0;
}
 
-   mutex_lock(>mutex);
if (test_bit(wil_status_resetting, wil->status) ||
!test_bit(wil_status_fwready, wil->status)) {
wil_err(wil, "status_resetting, cancel connect event, CID %d\n",
evt->cid);
-   mutex_unlock(>mutex);
/* no need for cleanup, wil_reset will do that */
return;
}
 
+   mutex_lock(>mutex);
+
if ((wdev->iftype == NL80211_IFTYPE_STATION) ||
(wdev->iftype == NL80211_IFTYPE_P2P_CLIENT)) {
if (!test_bit(wil_status_fwconnecting, wil->status)) {
@@ -631,6 +631,13 @@ static void wmi_evt_disconnect(struct wil6210_priv *wil, 
int id,
 
wil->sinfo_gen++;
 
+   if (test_bit(wil_status_resetting, wil->status) ||
+   !test_bit(wil_status_fwready, wil->status)) {
+   wil_err(wil, "status_resetting, cancel disconnect event\n");
+   /* no need for cleanup, wil_reset will do that */
+   return;
+   }
+
mutex_lock(>mutex);
wil6210_disconnect(wil, evt->bssid, reason_code, true);
mutex_unlock(>mutex);
-- 
1.9.1



[PATCH 11/11] wil6210: prevent access to 11AD device if resume fails

2017-04-05 Thread Maya Erez
In case wil6210 resume fails, wil6210 suspend function will try
to access the suspended device in the next kernel suspend.
To prevent that, add wil_status_suspended flag to indicate if the
device is already suspended and clear it only if the resume succeeds.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/pm.c  | 16 ++--
 drivers/net/wireless/ath/wil6210/wil6210.h |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/pm.c 
b/drivers/net/wireless/ath/wil6210/pm.c
index 7260bef..2ae4fe8 100644
--- a/drivers/net/wireless/ath/wil6210/pm.c
+++ b/drivers/net/wireless/ath/wil6210/pm.c
@@ -71,6 +71,11 @@ int wil_suspend(struct wil6210_priv *wil, bool is_runtime)
 
wil_dbg_pm(wil, "suspend: %s\n", is_runtime ? "runtime" : "system");
 
+   if (test_bit(wil_status_suspended, wil->status)) {
+   wil_dbg_pm(wil, "trying to suspend while suspended\n");
+   return 0;
+   }
+
/* if netif up, hardware is alive, shut it down */
if (ndev->flags & IFF_UP) {
rc = wil_down(wil);
@@ -86,10 +91,14 @@ int wil_suspend(struct wil6210_priv *wil, bool is_runtime)
 
if (wil->platform_ops.suspend) {
rc = wil->platform_ops.suspend(wil->platform_handle);
-   if (rc)
+   if (rc) {
wil_enable_irq(wil);
+   goto out;
+   }
}
 
+   set_bit(wil_status_suspended, wil->status);
+
 out:
wil_dbg_pm(wil, "suspend: %s => %d\n",
   is_runtime ? "runtime" : "system", rc);
@@ -117,10 +126,13 @@ int wil_resume(struct wil6210_priv *wil, bool is_runtime)
 
/* if netif up, bring hardware up
 * During open(), IFF_UP set after actual device method
-* invocation. This prevent recursive call to wil_up()
+* invocation. This prevent recursive call to wil_up().
+* wil_status_suspended will be cleared in wil_reset
 */
if (ndev->flags & IFF_UP)
rc = wil_up(wil);
+   else
+   clear_bit(wil_status_suspended, wil->status);
 
 out:
wil_dbg_pm(wil, "resume: %s => %d\n",
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index ec646d7..b00c803 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -412,6 +412,7 @@ enum { /* for wil6210_priv.status */
wil_status_irqen, /* FIXME: interrupts enabled - for debug */
wil_status_napi_en, /* NAPI enabled protected by wil->mutex */
wil_status_resetting, /* reset in progress */
+   wil_status_suspended, /* suspend completed, device is suspended */
wil_status_last /* keep last */
 };
 
-- 
1.9.1



[PATCH v2] mwifiex: apply radar flag

2017-04-05 Thread Ganapathi Bhat
From: Karthik Ananthapadmanabha 

When IEEE80211_CHAN_RADAR is set by cfg80211, passive scan must be
performed. In mwifiex,active scan is performed even though flag is
set from cfg80211. mwifiex_reg_apply_radar_flags() function added
in this patch correctly uses radar flag.

Signed-off-by: Karthik Ananthapadmanabha 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Ganapathi Bhat 
---
v3: corrected author name
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 1e3bd43..44d0617 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -594,6 +594,24 @@ int mwifiex_send_domain_info_cmd_fw(struct wiphy *wiphy)
return 0;
 }
 
+static void mwifiex_reg_apply_radar_flags(struct wiphy *wiphy)
+{
+   struct ieee80211_supported_band *sband;
+   struct ieee80211_channel *chan;
+   unsigned int i;
+
+   if (!wiphy->bands[NL80211_BAND_5GHZ])
+   return;
+   sband = wiphy->bands[NL80211_BAND_5GHZ];
+
+   for (i = 0; i < sband->n_channels; i++) {
+   chan = >channels[i];
+   if ((!(chan->flags & IEEE80211_CHAN_DISABLED)) &&
+   (chan->flags & IEEE80211_CHAN_RADAR))
+   chan->flags |= IEEE80211_CHAN_NO_IR;
+   }
+}
+
 /*
  * CFG802.11 regulatory domain callback function.
  *
@@ -613,6 +631,7 @@ static void mwifiex_reg_notifier(struct wiphy *wiphy,
mwifiex_dbg(adapter, INFO,
"info: cfg80211 regulatory domain callback for %c%c\n",
request->alpha2[0], request->alpha2[1]);
+   mwifiex_reg_apply_radar_flags(wiphy);
 
switch (request->initiator) {
case NL80211_REGDOM_SET_BY_DRIVER:
-- 
1.9.1



RE: [EXT] Re: mwifiex: apply radar flag

2017-04-05 Thread Ganapathi Bhat
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Wednesday, April 05, 2017 4:19 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Ganapathi Bhat; Karthik
> Doddayennegere Ananthapadmanabha; Amitkumar Karwar
> Subject: [EXT] Re: mwifiex: apply radar flag
> 
> Amitkumar Karwar  wrote:
> > From: Karthik D A 
> >
> > When IEEE80211_CHAN_RADAR is set by cfg80211, passive scan must be
> > performed. In mwifiex,active scan is performed even though flag is
> set
> > from cfg80211. mwifiex_reg_apply_radar_flags() function added in this
> > patch correctly uses radar flag.
> >
> > Signed-off-by: Karthik D A 
> > Signed-off-by: Amitkumar Karwar 
> 
> Please use Karthik's full name.

Ok Kalle. I will submit v2 with correction.

> 
> Patch set to Changes Requested.
> 
> --


Regards,
Ganapathi



RE: [EXT] Re: mwifiex: Fix invalid port issue

2017-04-05 Thread Ganapathi Bhat
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Wednesday, April 05, 2017 4:22 PM
> To: Ganapathi Bhat
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> Ganapathi Bhat
> Subject: [EXT] Re: mwifiex: Fix invalid port issue
> 
> Ganapathi Bhat  wrote:
> > We have to use start port, for TX/RX of single packet, instead of
> > current aggregating port. This will fix SDIO
> > CMD53(TX/RX) returning -ETIMEDOUT and halting the data path.
> >
> > fixes: 0cb52aac4 ('mwifiex: do not set multiport flag for tx/rx
> single
> > packet')
> > Signed-off-by: Ganapathi Bhat 
> 
> The correct format is:
> 
> Fixes: 0cb52aac4d19 ("mwifiex: do not set multiport flag for tx/rx
> single packet")
> 
> I can fix that. (no pun intended)

Thanks Kalle. I will follow the same in future.

> 
> --
> https://patchwork.kernel.org/patch/9660845/
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submitting
> patches


Regards,
Ganapathi


Re: mwifiex: Fix invalid port issue

2017-04-05 Thread Kalle Valo
Ganapathi Bhat  wrote:
> We have to use start port, for TX/RX of single packet,
> instead of current aggregating port. This will fix SDIO
> CMD53(TX/RX) returning -ETIMEDOUT and halting the data path.
> 
> fixes: 0cb52aac4 ('mwifiex: do not set multiport flag for tx/rx single 
> packet')
> Signed-off-by: Ganapathi Bhat 

The correct format is:

Fixes: 0cb52aac4d19 ("mwifiex: do not set multiport flag for tx/rx single 
packet")

I can fix that. (no pun intended)

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

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



Re: mwifiex: apply radar flag

2017-04-05 Thread Kalle Valo
Amitkumar Karwar  wrote:
> From: Karthik D A 
> 
> When IEEE80211_CHAN_RADAR is set by cfg80211, passive scan must be
> performed. In mwifiex,active scan is performed even though flag is
> set from cfg80211. mwifiex_reg_apply_radar_flags() function added
> in this patch correctly uses radar flag.
> 
> Signed-off-by: Karthik D A 
> Signed-off-by: Amitkumar Karwar 

Please use Karthik's full name.

Patch set to Changes Requested.

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

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



Re: [3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

2017-04-05 Thread Kalle Valo
Xinming Hu  wrote:
> From: Xinming Hu 
> 
> Wifi-only firmware name should be chipset specific.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 

The commit log is not telling anything. Why are you changing this? And how does
the functionality change from user space point of view?

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

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




Re: [PATCH 16/16] drivers, net, intersil: convert request_context.refcount from atomic_t to refcount_t

2017-04-05 Thread Kalle Valo
"Reshetova, Elena"  writes:

>> Elena Reshetova  writes:
>> 
>> > refcount_t type and corresponding API should be
>> > used instead of atomic_t when the variable is used as
>> > a reference counter. This allows to avoid accidental
>> > refcounter overflows that might lead to use-after-free
>> > situations.
>> >
>> > Signed-off-by: Elena Reshetova 
>> > Signed-off-by: Hans Liljestrand 
>> > Signed-off-by: Kees Cook 
>> > Signed-off-by: David Windsor 
>> > ---
>> >  drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 15 ---
>> >  1 file changed, 8 insertions(+), 7 deletions(-)
>> 
>> The prefix should be "orinoco_usb:", I'll fix that.
>
> Thanks for both! Will you take the patches in?

You mean patches 15 and 16? I didn't even look rest of the patches.

But not sure yet because Dave doesn't seem to like the interface and I
want to follow the discussion first.

-- 
Kalle Valo


Re: [PATCH 1/3] rsi: Rename the file rsi_91x_pkt.c to rsi_91x_hal.c

2017-04-05 Thread Kalle Valo
Prameela Rani Garnepudi  writes:

> The file rsi_91x_hal.c will contain new firmware loading method for
> RSI 9113 chipset. So this file will have device specific operations.
> As the file 'rsi_91x_pkt.c' contains code for preparing device
> (frimware understandable) specific descriptors for the transmit frames,
> it is moved to 'rsi_91x_hal.c'
>
> Signed-off-by: Prameela Rani Garnepudi 

If you send a new version of the patchset mark it as "[PATCH v2]". Also
I don't see a changelog anywhere, what has changed since the version you
posted last December?

Please read:

https://kernelnewbies.org/FirstKernelPatch#head-5c81b3c517a1d0bbc24f92594cb734e155fcbbcb

-- 
Kalle Valo


Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-04-05 Thread Kalle Valo
Alban  writes:

> The current binding only cover PCI devices so extend it for SoC devices.
>
> Most SoC platforms use an MTD partition for the calibration data
> instead of an EEPROM. The qca,no-eeprom property was added to allow
> loading the EEPROM content using firmware loading. This new binding
> replace this hack with NVMEM cells, so we also mark the qca,no-eeprom
> property as deprecated in case anyone ever used it.

A patchset like this should definitely have a cover letter and explain
the backround and reasoning for this patchset. Currently I'm just
guessing.

> Signed-off-by: Alban 

Please use your full name both in From and S-o-b lines.

-- 
Kalle Valo

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-04-05 Thread Hans de Goede

Hi,

On 05-04-17 01:41, Larry Finger wrote:

On 04/04/2017 04:53 PM, Hans de Goede wrote:

Hi,

On 04/04/2017 11:38 PM, Arend Van Spriel wrote:



On 4-4-2017 20:53, Hans de Goede wrote:

Hi,

On 04/04/2017 08:31 PM, Larry Finger wrote:

On 03/29/2017 12:47 PM, Hans de Goede wrote:

The rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel Computestick and various other
Atom based devices) and on many (budget) ARM boards such as
the CHIP.

The plan moving forward with this is for the new clean,
written from scratch, rtl8xxxu driver to eventually gain
support for sdio devices. But there is no clear timeline
for that, so lets add this driver included in staging for now.


Hans,

I started looking at the Smatch errors. This one may be the result of
a serious problem:

  CHECK   drivers/staging/rtl8723bs/core/rtw_debug.c
drivers/staging/rtl8723bs/core/rtw_debug.c:454 proc_get_survey_info()
error: we previously assumed 'phead' could be null (see line 453)
drivers/staging/rtl8723bs/core/rtw_debug.c:455 proc_get_survey_info()
warn: variable dereferenced before check 'phead' (see line 454)

A snippet of the code in question is as follows:

spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
phead = get_list_head(queue);
plist = phead ? get_next(phead) : NULL;
plist = get_next(phead);
if ((!phead) || (!plist)) {
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));
return 0;
}

This code comes directly from the hadess repo, but I am suspicious of
the double call to get_next(phead). I cannot imagine any valid reason
to skip every other entry on that list.


If you look closer and simplify the first getnext line what is written is:

 plist = get_next(phead);
 plist = get_next(phead);

Which indeed looks like it could use improvement, but I don't
think it is seriously broken.


So get_list_head(queue) can never return NULL?


I don't know.


Otherwise I don't know
how close I need to get for a simplified look ;-)


I simplified things so as to make clear that Larry's worry was
not really a problem, I do agree the smatch complaint is valid.


I think the following fixes the problem:

diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c 
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index d34747b29309..51cef55d3f76 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -451,7 +451,6 @@ int proc_get_survey_info(struct seq_file *m, void *v)
spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
phead = get_list_head(queue);
plist = phead ? get_next(phead) : NULL;
-   plist = get_next(phead);
if ((!phead) || (!plist)) {
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));
return 0;

Pointer plist is set in the 3rd line, thus the second set of it can be removed.


Agreed, when I've some time I plan to do a follow-up patch
to my initial submission fixing all the Smatch errors. But feel
free to beat me to it.

Greg, if I understood you correctly you plan to merge my initial
submission as is and then we can fix this (and other things) with
follow up patches, right ?

Regards,

Hans


Re: ath10k: Clean header files from bad block comments

2017-04-05 Thread Kalle Valo
Kalle Valo  writes:

> Marcin Rokicki  wrote:
>> Fix output from checkpatch.pl like:
>>  Block comments use a trailing */ on a separate line
>> 
>> Signed-off-by: Marcin Rokicki 
>
> Patch applied to ath-next branch of ath.git, thanks.
>
> 37ff1b0df37a ath10k: clean header files from bad block comments

I also enabled the checkpatch warning in ath10k-check so that we can
catch any new warnings:

https://github.com/qca/qca-swiss-army-knife/commit/e23fbd3c9647c20e29e819b8a6d934e1b56067b9

-- 
Kalle Valo

Re: ath9k_hw: fix channel maximum power level test

2017-04-05 Thread Kalle Valo
Felix Fietkau  wrote:
> The tx power applied by set_txpower is limited by the CTL (conformance
> test limit) entries in the EEPROM. These can change based on the user
> configured regulatory domain.
> Depending on the EEPROM data this can cause the tx power to become too
> limited, if the original regdomain CTLs impose lowr limits than the CTLs
> of the user configured regdomain.
> 
> To fix this issue, set the initial channel limits without any CTL
> restrictions and only apply the CTL at run time when setting the channel
> and the real tx power.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Felix Fietkau 

Failed to apply:

error: patch failed: drivers/net/wireless/ath/ath9k/hw.c:2937
error: drivers/net/wireless/ath/ath9k/hw.c: patch does not apply
stg import: Diff does not apply cleanly

Patch set to Changes Requested.

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

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



Re: [PATCH] NFC: pn533: use constant off-stack buffer for sending acks

2017-04-05 Thread Samuel Ortiz
Hi Michał,

On Tue, Apr 04, 2017 at 07:09:10AM +0200, Michał Mirosław wrote:
> This fixes following WARNing:
> 
> usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
> llcp: nfc_llcp_recv: err -5
> llcp: nfc_llcp_symm_timer: SYMM timeout
> [ cut here ]
> WARNING: CPU: 1 PID: 26397 at .../drivers/usb/core/hcd.c:1584 
> usb_hcd_map_urb_for_dma+0x370/0x550
> transfer buffer not dma capable
> [...]
> Workqueue: events nfc_llcp_timeout_work [nfc]
> Call Trace:
>  ? dump_stack+0x46/0x5a
>  ? __warn+0xb9/0xe0
>  ? warn_slowpath_fmt+0x5a/0x80
>  ? usb_hcd_map_urb_for_dma+0x370/0x550
>  ? usb_hcd_submit_urb+0x2fb/0xa60
>  ? dequeue_entity+0x3f2/0xc30
>  ? pn533_usb_send_ack+0x5d/0x80 [pn533_usb]
>  ? pn533_usb_abort_cmd+0x13/0x20 [pn533_usb]
>  ? pn533_dep_link_down+0x32/0x70 [pn533]
>  ? nfc_dep_link_down+0x87/0xd0 [nfc]
> [...]
> usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
> llcp: nfc_llcp_recv: err -5
> llcp: nfc_llcp_symm_timer: SYMM timeout
> 
> Signed-off-by: Michał Mirosław 
> ---
> 
> Patch against stable linux-4.10.8.
Could you please rebase against nfc-next ?


> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> index 1dc89248e58e..35f410797fe4 100644
> --- a/drivers/nfc/pn533/i2c.c
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -49,10 +49,11 @@ struct pn533_i2c_phy {
>  
>  static int pn533_i2c_send_ack(struct pn533 *dev, gfp_t flags)
>  {
> - struct pn533_i2c_phy *phy = dev->phy;
> - struct i2c_client *client = phy->i2c_dev;
> - u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> + static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
>   /* spec 6.2.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
> +
> + struct pn533_i2c_phy *phy = dev->phy;
> + struct i2c_client *client = phy->i2c_dev;
Can we please not move those 2 declarations to make the patch less
verbose ?


> diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
> index 33ed78be2750..09e1db8e8dc3 100644
> --- a/drivers/nfc/pn533/usb.c
> +++ b/drivers/nfc/pn533/usb.c
> @@ -147,12 +147,13 @@ static int pn533_submit_urb_for_ack(struct 
> pn533_usb_phy *phy, gfp_t flags)
>  
>  static int pn533_usb_send_ack(struct pn533 *dev, gfp_t flags)
>  {
> - struct pn533_usb_phy *phy = dev->phy;
> - u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> + static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
>   /* spec 7.1.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
> +
> + struct pn533_usb_phy *phy = dev->phy;
Ditto.

Cheers,
Samuel.


Re: [PATCH v1] NFC: Add nfc_dbg() macro

2017-04-05 Thread Samuel Ortiz
On Wed, Mar 22, 2017 at 09:22:51PM +0200, Andy Shevchenko wrote:
> In some cases nfc_dbg() is useful. Add such macro to a header.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  include/net/nfc/nfc.h | 1 +
>  1 file changed, 1 insertion(+)
Applied as well.

Cheers,
Samuel.


Re: [PATCH v1] NFC: netlink: Use error code from nfc_activate_target()

2017-04-05 Thread Samuel Ortiz
Hi Andy,

On Wed, Mar 22, 2017 at 09:20:58PM +0200, Andy Shevchenko wrote:
> It looks like a typo to assign a return code to a variable which is not
> used. Found due to a compiler warning:
> 
> net/nfc/netlink.c: In function ‘nfc_genl_activate_target’:
> net/nfc/netlink.c:903:6: warning: variable ‘rc’ set but not used 
> [-Wunused-but-set-variable]
>   int rc;
> ^~
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  net/nfc/netlink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.

Cheers,
Samuel.


Re: [PATCH v2 1/5] NFC: st21nfca: Fix obvious typo when check error code

2017-04-05 Thread Samuel Ortiz
Hi Andy,

On Tue, Mar 07, 2017 at 12:25:42PM +0200, Andy Shevchenko wrote:
> We return -ENODEV if ACPI provides a GPIO resource. Looks really wrong.
> If it has even been tested?
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/nfc/st21nfca/i2c.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
All 5 patches applied to nfc-next, thanks.

Cheers,
Samuel.


Re: ath10k: Clean header files from bad block comments

2017-04-05 Thread Kalle Valo
Marcin Rokicki  wrote:
> Fix output from checkpatch.pl like:
>  Block comments use a trailing */ on a separate line
> 
> Signed-off-by: Marcin Rokicki 

Patch applied to ath-next branch of ath.git, thanks.

37ff1b0df37a ath10k: clean header files from bad block comments

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



Re: ath10k: Fix the Transmit Power Control stats display format

2017-04-05 Thread Kalle Valo
c_mke...@qti.qualcomm.com wrote:
> From: Maharaja Kennadyrajan 
> 
> This patch helps to fix TPC stats to display the stats
> properly. Here cosmetic change has been done to print the
> TPC stats for all the cases 1.CDD 2.STBC 3.TXBF
> 
> Signed-off-by: Maharaja Kennadyrajan 

Patch applied to ath-next branch of ath.git, thanks.

e871fb6396f7 ath10k: fix the Transmit Power Control stats display format

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



Re: ath10k: Remove obselete Copy Engine comments

2017-04-05 Thread Kalle Valo
Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Remove obselete Copy Engine comments referring to the function
> ath10k_ce_sendlist_send as this function was removed long time back
> by the commit 2e761b5a5222 ("ath10k: remove ce_sendlist_send").
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Patch applied to ath-next branch of ath.git, thanks.

fb7fa766a8cf ath10k: remove obselete Copy Engine comments

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



Re: ath10k: cancel coverage class work during stop and restart

2017-04-05 Thread Kalle Valo
Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> It seems set_coverage_class_work is not cancelled anywhere,
> though I could not find a crash/warning  with this existing
> design, its safer to cancel it during stop() and also before
> restarting the hardware.
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Patch applied to ath-next branch of ath.git, thanks.

d94475c2f95c ath10k: cancel coverage class work during stop and restart

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



Re: ath10k: fix station nss computation

2017-04-05 Thread Kalle Valo
c_vna...@qti.qualcomm.com wrote:
> From: Venkateswara Rao Naralasetty 
> 
> If station advertises diffferent NSS capabilities in Rx_mcs set
> of HT and VHT IEs in assoc req, the current NSS computation
> logic configures the NSS support only based on Rx_mcs set of
> HT capabilities in the driver. This is configuring the station
> NSS capabilities incorreclty in the target.
> 
> For example, if station advertise Rx_mcs set as 2 spatial streams
> in HT capabilities and 1 spatial streams in VHT capabilities in
> assoc request, as per current logic we are calculating nss from
> HT capabilities and the driver sets peer_num_spatial_streams as
> 2 for the station which is configured in VHT 1*1.
> 
> This patchs fix this issue by calculating the nss from VHT cap if
> station supports vht.
> 
> Signed-off-by: Venkateswara Rao Naralasetty 

Patch applied to ath-next branch of ath.git, thanks.

fefcd11535ab ath10k: fix station nss computation

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



Re: [1/2] wireless: ath9k_htc: fix NULL-deref at probe

2017-04-05 Thread Kalle Valo
Johan Hovold  wrote:
> Make sure to check the number of endpoints to avoid dereferencing a
> NULL-pointer or accessing memory beyond the endpoint array should a
> malicious device lack the expected endpoints.
> 
> Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
> Cc: Sujith Manoharan 
> Signed-off-by: Johan Hovold 

Patch applied to ath-next branch of ath.git, thanks.

ebeb36670eca ath9k_htc: fix NULL-deref at probe

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



Re: ath10k: Fix NAPI enable/disable symmetry for AHB interface

2017-04-05 Thread Kalle Valo
Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Move NAPI enable to 'ath10k_ahb_hif_start' from
> 'ath10k_ahb_hif_power_up'. This is to maintain the symmetry
> of calling napi_enable() from ath10k_ahb_hif_start() so that it
> matches with  napi_disable() being called from ath10k_pci_hif_stop().
> 
> This change is based on the crash fix from Kalle for PCI interface in
> commit 1427228d5869 ("ath10k: fix napi crash during rmmod when probe
> firmware fails").
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Patch applied to ath-next branch of ath.git, thanks.

a7595a820b07 ath10k: fix NAPI enable/disable symmetry for AHB interface

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



Re: ath10k: use octal permission representation

2017-04-05 Thread Kalle Valo
Marcin Rokicki  wrote:
> Fix output from checkpatch.pl like:
>  Symbolic permissions 'S_IRUSR' are not preferred.
>  Consider using octal permissions '0400'.
> 
> Signed-off-by: Marcin Rokicki 

This introduced a new checkpatch warning:

drivers/net/wireless/ath/ath10k/debug.c:2494: Alignment should match open 
parenthesis

I fixed that in the pending branch.

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

Documentation about submitting wireless patches and checking status
from patchwork:

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



How to use netlink to determine wifi protection WEP

2017-04-05 Thread Thomas Thielemann
Hello!

I need a solution to determine whether a WiFi is using WEP. I know there is a 
protection flag within MAC frame but do not know how to access.

To detect whether a WiFi i protected by WPA2 I found the following solution: 

Scan with

nl_sock* socket = nl_socket_alloc();
genl_connect(socket);
struct nl_msg* msg = nlmsg_alloc();
int driverId = genl_ctrl_resolve(socket, "nl80211"); 
genlmsg_put(msg, 0, 0, driverId, 0, 0, NL80211_CMD_TRIGGER_SCAN, 0);

and fetch with

genlmsg_put(msg, 0, 0, driverId, 0, NLM_F_DUMP, NL80211_CMD_GET_SCAN, 0);

Read the received structure using nl80211_bss:: 
NL80211_BSS_INFORMATION_ELEMENTS from nl80211.h and

examine the field RSN(id=48) (see IEEE802.11-2012.pdf, chapter 8.4.2 
Information elements)

Which netlink command gives me the related data? Is it NL80211_CMD_GET_BEACON?

Regards,
Thomas

E-Mail: th-thielem...@web.de


[PATCH 6/7] ath10k: convert __ath10k_sdio_write_async() to use ath10k_sdio_write()

2017-04-05 Thread Kalle Valo
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/sdio.c |9 +
 drivers/net/wireless/ath/ath10k/sdio.h |2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index 301355228cfa..8ea1629c7bae 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -1304,9 +1304,11 @@ static void __ath10k_sdio_write_async(struct ath10k *ar,
int ret;
 
skb = req->skb;
-   ret = ath10k_sdio_read_write_sync(ar, req->address,
- skb->data, skb->len,
- req->request);
+   ret = ath10k_sdio_write(ar, req->address, skb->data, skb->len);
+   if (ret)
+   ath10k_warn(ar, "failed to write skb to 0x%x asynchronously: 
%d",
+   req->address, ret);
+
if (req->htc_msg) {
ep = >htc.endpoint[req->eid];
ath10k_htc_notify_tx_completion(ep, skb);
@@ -1355,7 +1357,6 @@ static int ath10k_sdio_prep_async_req(struct ath10k *ar, 
u32 addr,
}
 
bus_req->skb = skb;
-   bus_req->request = HIF_WRITE;
bus_req->eid = eid;
bus_req->address = addr;
bus_req->htc_msg = htc_msg;
diff --git a/drivers/net/wireless/ath/ath10k/sdio.h 
b/drivers/net/wireless/ath/ath10k/sdio.h
index d1e4f78ddaeb..1bce56447e53 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.h
+++ b/drivers/net/wireless/ath/ath10k/sdio.h
@@ -110,7 +110,7 @@ struct ath10k_sdio_bus_request {
 
/* sdio address */
u32 address;
-   u32 request;
+
struct sk_buff *skb;
enum ath10k_htc_ep_id eid;
int status;



[PATCH 4/7] ath10k: add ath10k_sdio_write()

2017-04-05 Thread Kalle Valo
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/sdio.c |   48 +++-
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index bbd8317de861..beb1749672f0 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -368,6 +368,34 @@ static int ath10k_sdio_read(struct ath10k *ar, u32 addr, 
void *buf, size_t len)
return ret;
 }
 
+static int ath10k_sdio_write(struct ath10k *ar, u32 addr, const void *buf, 
size_t len)
+{
+   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
+   struct sdio_func *func = ar_sdio->func;
+   int ret;
+
+   sdio_claim_host(func);
+
+   /* For some reason toio() doesn't have const for the buffer, need
+* an ugly hack to workaround that.
+*/
+   ret = sdio_memcpy_toio(func, addr, (void *)buf, len);
+   if (ret) {
+   ath10k_warn(ar, "failed to write to address 0x%x: %d\n",
+   addr, ret);
+   goto out;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio write addr 0x%x buf 0x%p len 
%zu\n",
+  addr, buf, len);
+   ath10k_dbg_dump(ar, ATH10K_DBG_SDIO_DUMP, NULL, "sdio write ", buf, 
len);
+
+out:
+   sdio_release_host(func);
+
+   return ret;
+}
+
 /* HIF mbox functions */
 
 static int ath10k_sdio_mbox_rx_process_packet(struct ath10k *ar,
@@ -1131,9 +1159,7 @@ static int ath10k_sdio_bmi_exchange_msg(struct ath10k *ar,
addr = ar_sdio->mbox_info.htc_addr;
 
memcpy(ar_sdio->bmi_buf, req, req_len);
-   ret = ath10k_sdio_read_write_sync(ar, addr, ar_sdio->bmi_buf,
- req_len,
- HIF_WR_SYNC_BYTE_INC);
+   ret = ath10k_sdio_write(ar, addr, ar_sdio->bmi_buf, req_len);
if (ret) {
ath10k_warn(ar,
"unable to send the bmi data to the device: 
%d\n",
@@ -1361,10 +1387,8 @@ static int ath10k_sdio_hif_disable_intrs(struct ath10k 
*ar)
mutex_lock(_data->mtx);
 
memset(regs, 0, sizeof(*regs));
-   ret = ath10k_sdio_read_write_sync(ar,
- MBOX_INT_STATUS_ENABLE_ADDRESS,
- >int_status_en, sizeof(*regs),
- HIF_WR_SYNC_BYTE_INC);
+   ret = ath10k_sdio_write(ar, MBOX_INT_STATUS_ENABLE_ADDRESS,
+   >int_status_en, sizeof(*regs));
if (ret)
ath10k_warn(ar, "unable to disable sdio interrupts: %d\n", ret);
 
@@ -1498,10 +1522,8 @@ static int ath10k_sdio_hif_enable_intrs(struct ath10k 
*ar)
FIELD_PREP(MBOX_COUNTER_INT_STATUS_ENABLE_BIT_MASK,
   ATH10K_SDIO_TARGET_DEBUG_INTR_MASK);
 
-   ret = ath10k_sdio_read_write_sync(ar,
- MBOX_INT_STATUS_ENABLE_ADDRESS,
- >int_status_en, sizeof(*regs),
- HIF_WR_SYNC_BYTE_INC);
+   ret = ath10k_sdio_write(ar, MBOX_INT_STATUS_ENABLE_ADDRESS,
+   >int_status_en, sizeof(*regs));
if (ret)
ath10k_warn(ar,
"failed to update mbox interrupt status register : 
%d\n",
@@ -1596,9 +1618,7 @@ static int ath10k_sdio_hif_diag_write_mem(struct ath10k 
*ar, u32 address,
int ret;
 
/* set write data */
-   ret = ath10k_sdio_read_write_sync(ar, MBOX_WINDOW_DATA_ADDRESS,
- (u8 *)data, nbytes,
- HIF_WR_SYNC_BYTE_INC);
+   ret = ath10k_sdio_write(ar, MBOX_WINDOW_DATA_ADDRESS, data, nbytes);
if (ret) {
ath10k_warn(ar,
"failed to write 0x%p to mbox window data addrress: 
%d\n",



[PATCH 5/7] ath10k: add ath10k_sdio_readsb()

2017-04-05 Thread Kalle Valo
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/sdio.c |   34 +++-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index beb1749672f0..301355228cfa 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -396,6 +396,33 @@ static int ath10k_sdio_write(struct ath10k *ar, u32 addr, 
const void *buf, size_
return ret;
 }
 
+static int ath10k_sdio_readsb(struct ath10k *ar, u32 addr, void *buf, size_t 
len)
+{
+   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
+   struct sdio_func *func = ar_sdio->func;
+   int ret;
+
+   sdio_claim_host(func);
+
+   len = round_down(len, ar_sdio->mbox_info.block_size);
+
+   ret = sdio_readsb(func, buf, addr, len);
+   if (ret) {
+   ath10k_warn(ar, "failed to read from fixed (sb) address 0x%x: 
%d\n",
+   addr, ret);
+   goto out;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio readsb addr 0x%x buf 0x%p len 
%zu\n",
+  addr, buf, len);
+   ath10k_dbg_dump(ar, ATH10K_DBG_SDIO_DUMP, NULL, "sdio readsb ", buf, 
len);
+
+out:
+   sdio_release_host(func);
+
+   return ret;
+}
+
 /* HIF mbox functions */
 
 static int ath10k_sdio_mbox_rx_process_packet(struct ath10k *ar,
@@ -645,11 +672,8 @@ static int ath10k_sdio_mbox_rx_packet(struct ath10k *ar,
struct sk_buff *skb = pkt->skb;
int ret;
 
-   ret = ath10k_sdio_read_write_sync(ar,
- ar_sdio->mbox_info.htc_addr,
- skb->data, pkt->alloc_len,
- HIF_RD_SYNC_BLOCK_FIX);
-
+   ret = ath10k_sdio_readsb(ar, ar_sdio->mbox_info.htc_addr,
+skb->data, pkt->alloc_len);
pkt->status = ret;
if (!ret)
skb_put(skb, pkt->act_len);



[PATCH 3/7] ath10k: add ath10k_sdio_read()

2017-04-05 Thread Kalle Valo
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/sdio.c |   40 +++-
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index 56728d44dd12..bbd8317de861 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -343,6 +343,31 @@ static int ath10k_sdio_read32(struct ath10k *ar, u32 addr, 
u32 *val)
return ret;
 }
 
+static int ath10k_sdio_read(struct ath10k *ar, u32 addr, void *buf, size_t len)
+{
+   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
+   struct sdio_func *func = ar_sdio->func;
+   int ret;
+
+   sdio_claim_host(func);
+
+   ret = sdio_memcpy_fromio(func, buf, addr, len);
+   if (ret) {
+   ath10k_warn(ar, "failed to read from address 0x%x: %d\n",
+   addr, ret);
+   goto out;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio read addr 0x%x buf 0x%p len 
%zu\n",
+  addr, buf, len);
+   ath10k_dbg_dump(ar, ATH10K_DBG_SDIO_DUMP, NULL, "sdio read ", buf, len);
+
+out:
+   sdio_release_host(func);
+
+   return ret;
+}
+
 /* HIF mbox functions */
 
 static int ath10k_sdio_mbox_rx_process_packet(struct ath10k *ar,
@@ -859,11 +884,8 @@ static int ath10k_sdio_mbox_read_int_status(struct ath10k 
*ar,
 * will yield us the value of different int status
 * registers and the lookahead registers.
 */
-   ret = ath10k_sdio_read_write_sync(ar,
- MBOX_HOST_INT_STATUS_ADDRESS,
- (u8 *)irq_proc_reg,
- sizeof(*irq_proc_reg),
- HIF_RD_SYNC_BYTE_INC);
+   ret = ath10k_sdio_read(ar, MBOX_HOST_INT_STATUS_ADDRESS,
+  irq_proc_reg, sizeof(*irq_proc_reg));
if (ret)
goto out;
 
@@ -1175,9 +1197,7 @@ static int ath10k_sdio_bmi_exchange_msg(struct ath10k *ar,
 
/* We always read from the start of the mbox address */
addr = ar_sdio->mbox_info.htc_addr;
-   ret = ath10k_sdio_read_write_sync(ar, addr, ar_sdio->bmi_buf,
- *resp_len,
- HIF_RD_SYNC_BYTE_INC);
+   ret = ath10k_sdio_read(ar, addr, ar_sdio->bmi_buf, *resp_len);
if (ret) {
ath10k_warn(ar,
"unable to read the bmi data from the device: %d\n",
@@ -1538,9 +1558,7 @@ static int ath10k_sdio_hif_diag_read(struct ath10k *ar, 
u32 address, void *buf,
}
 
/* read the data */
-   ret = ath10k_sdio_read_write_sync(ar, MBOX_WINDOW_DATA_ADDRESS,
- (u8 *)buf, buf_len,
- HIF_RD_SYNC_BYTE_INC);
+   ret = ath10k_sdio_read(ar, MBOX_WINDOW_DATA_ADDRESS, buf, buf_len);
if (ret) {
ath10k_warn(ar, "failed to read from mbox window data addrress: 
%d\n",
ret);



[PATCH 2/7] ath10k: add ath10k_sdio_writesb()

2017-04-05 Thread Kalle Valo
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/sdio.c |   85 +++-
 1 file changed, 50 insertions(+), 35 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index c7bc86e5063f..56728d44dd12 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -287,6 +287,39 @@ static int ath10k_sdio_write32(struct ath10k *ar, u32 
addr, u32 val)
return ret;
 }
 
+static int ath10k_sdio_writesb32(struct ath10k *ar, u32 addr, u32 val)
+{
+   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
+   struct sdio_func *func = ar_sdio->func;
+   __le32 *buf;
+   int ret;
+
+   buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   *buf = cpu_to_le32(val);
+
+   sdio_claim_host(func);
+
+   ret = sdio_writesb(func, addr, buf, sizeof(*buf));
+   if (ret) {
+   ath10k_warn(ar, "failed to write value 0x%x to fixed sb address 
0x%x: %d\n",
+   val, addr, ret);
+   goto out;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio writesb32 addr 0x%x val 0x%x\n",
+  addr, val);
+
+out:
+   sdio_release_host(func);
+
+   kfree(buf);
+
+   return ret;
+}
+
 static int ath10k_sdio_read32(struct ath10k *ar, u32 addr, u32 *val)
 {
struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
@@ -709,21 +742,16 @@ static int ath10k_sdio_mbox_proc_err_intr(struct ath10k 
*ar)
 {
struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
struct ath10k_sdio_irq_data *irq_data = _sdio->irq_data;
-   u8 error_int_status, *reg_buf;
+   u8 error_int_status;
int ret;
 
-   reg_buf = kzalloc(4, GFP_KERNEL);
-   if (!reg_buf)
-   return -ENOMEM;
-
ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio error interrupt\n");
 
error_int_status = irq_data->irq_proc_reg->error_int_status & 0x0F;
if (!error_int_status) {
ath10k_warn(ar, "invalid error interrupt status: 0x%x\n",
error_int_status);
-   ret = -EIO;
-   goto out;
+   return -EIO;
}
 
ath10k_dbg(ar, ATH10K_DBG_SDIO,
@@ -744,29 +772,25 @@ static int ath10k_sdio_mbox_proc_err_intr(struct ath10k 
*ar)
/* Clear the interrupt */
irq_data->irq_proc_reg->error_int_status &= ~error_int_status;
 
+   /* FIXME: is this correct? originally it was "reg_buf[0] =
+* error_int_status" and not sure if this is the same anymore */
/* set W1C value to clear the interrupt, this hits the register first */
-   reg_buf[0] = error_int_status;
-
-   ret = ath10k_sdio_read_write_sync(ar,
- MBOX_ERROR_INT_STATUS_ADDRESS,
- reg_buf, 4, HIF_WR_SYNC_BYTE_FIX);
+   ret = ath10k_sdio_writesb32(ar, MBOX_ERROR_INT_STATUS_ADDRESS,
+   error_int_status);
if (ret) {
ath10k_warn(ar, "unable to write to error int status address: 
%d\n",
ret);
-   goto out;
+   return ret;
}
 
-out:
-   kfree(reg_buf);
-
-   return ret;
+   return 0;
 }
 
 static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k *ar)
 {
struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
struct ath10k_sdio_irq_data *irq_data = _sdio->irq_data;
-   u8 cpu_int_status, *reg_buf;
+   u8 cpu_int_status;
int ret;
 
mutex_lock(_data->mtx);
@@ -781,32 +805,23 @@ static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k 
*ar)
/* Clear the interrupt */
irq_data->irq_proc_reg->cpu_int_status &= ~cpu_int_status;
 
-   /* Set up the register transfer buffer to hit the register 4 times ,
+   /* FIXME: is this correct? originally it was "reg_buf[0] =
+* cpu_int_status" and not sure if this is the same anymore */
+   /* Set up the register transfer buffer to hit the register 4 times,
 * this is done to make the access 4-byte aligned to mitigate issues
 * with host bus interconnects that restrict bus transfer lengths to
 * be a multiple of 4-bytes.
+*
+* Set W1C value to clear the interrupt, this hits the register first.
 */
-   reg_buf = kzalloc(4, GFP_KERNEL);
-   if (!reg_buf) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   /* set W1C value to clear the interrupt, this hits the register first */
-   reg_buf[0] = cpu_int_status;
-
-   ret = ath10k_sdio_read_write_sync(ar,
- MBOX_CPU_INT_STATUS_ADDRESS,
- reg_buf, 4, HIF_WR_SYNC_BYTE_FIX);
+   ret = ath10k_sdio_writesb32(ar, MBOX_CPU_INT_STATUS_ADDRESS,
+   

[PATCH 7/7] ath10k: remove unused sdio wrappers

2017-04-05 Thread Kalle Valo
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/sdio.c |   44 
 drivers/net/wireless/ath/ath10k/sdio.h |   35 -
 2 files changed, 79 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index 8ea1629c7bae..a5ed4282b3b3 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -219,50 +219,6 @@ static int ath10k_sdio_config(struct ath10k *ar)
return ret;
 }
 
-static int ath10k_sdio_io(struct ath10k *ar, u32 request, u32 addr,
- u8 *buf, u32 len)
-{
-   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
-   struct sdio_func *func = ar_sdio->func;
-   int ret;
-
-   sdio_claim_host(func);
-
-   if (request & HIF_WRITE) {
-   if (request & HIF_FIXED_ADDRESS)
-   ret = sdio_writesb(func, addr, buf, len);
-   else
-   ret = sdio_memcpy_toio(func, addr, buf, len);
-   } else {
-   if (request & HIF_FIXED_ADDRESS)
-   ret = sdio_readsb(func, buf, addr, len);
-   else
-   ret = sdio_memcpy_fromio(func, buf, addr, len);
-   }
-
-   sdio_release_host(func);
-
-   ath10k_dbg(ar, ATH10K_DBG_SDIO, "sdio %s addr 0x%x%s buf 0x%p len %d\n",
-  request & HIF_WRITE ? "wr" : "rd", addr,
-  request & HIF_FIXED_ADDRESS ? " (fixed)" : "", buf, len);
-   ath10k_dbg_dump(ar, ATH10K_DBG_SDIO_DUMP, NULL,
-   request & HIF_WRITE ? "sdio wr " : "sdio rd ",
-   buf, len);
-
-   return ret;
-}
-
-static int ath10k_sdio_read_write_sync(struct ath10k *ar, u32 addr, u8 *buf,
-  u32 len, u32 request)
-{
-   struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
-
-   if (request & HIF_BLOCK_BASIS)
-   len = round_down(len, ar_sdio->mbox_info.block_size);
-
-   return ath10k_sdio_io(ar, request, addr, buf, len);
-}
-
 static int ath10k_sdio_write32(struct ath10k *ar, u32 addr, u32 val)
 {
struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
diff --git a/drivers/net/wireless/ath/ath10k/sdio.h 
b/drivers/net/wireless/ath/ath10k/sdio.h
index 1bce56447e53..62d2699123ec 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.h
+++ b/drivers/net/wireless/ath/ath10k/sdio.h
@@ -136,41 +136,6 @@ struct ath10k_sdio_rx_data {
int status;
 };
 
-/* direction of transfer (read/write) */
-#define HIF_READ0x0001
-#define HIF_WRITE   0x0002
-
-/* dmode - An interface may support different kinds of commands based on
- * the tradeoff between the amount of data it can carry and the
- * setup time. Byte and Block modes are supported (HIF_BYTE_BASIS/
- * HIF_BLOCK_BASIS). In case of latter, the data is rounded off
- * to the nearest block size by padding. The size of the block is
- * configurable at compile time using the HIF_BLOCK_SIZE and is
- * negotiated with the target during initialization after the
- * ATH10K interrupts are enabled.
- */
-#define HIF_BYTE_BASIS  0x0040
-#define HIF_BLOCK_BASIS 0x0080
-
-/* amode - This indicates if the address has to be incremented on ATH10K
- * after every read/write operation (HIF?FIXED_ADDRESS/
- * HIF_INCREMENTAL_ADDRESS).
- */
-#define HIF_FIXED_ADDRESS   0x0100
-#define HIF_INCREMENTAL_ADDRESS 0x0200
-
-#define HIF_WR_SYNC_BYTE_FIX   \
-   (HIF_WRITE | HIF_BYTE_BASIS | HIF_FIXED_ADDRESS)
-
-#define HIF_WR_SYNC_BYTE_INC   \
-   (HIF_WRITE | HIF_BYTE_BASIS | HIF_INCREMENTAL_ADDRESS)
-
-#define HIF_RD_SYNC_BYTE_INC   \
-   (HIF_READ | HIF_BYTE_BASIS | HIF_INCREMENTAL_ADDRESS)
-
-#define HIF_RD_SYNC_BLOCK_FIX  \
-   (HIF_READ | HIF_BLOCK_BASIS | HIF_FIXED_ADDRESS)
-
 struct ath10k_sdio_irq_proc_regs {
u8 host_int_status;
u8 cpu_int_status;



[PATCH 0/7] ath10k: remove ath10k_sdio_io()

2017-04-05 Thread Kalle Valo
Using ath10k_sdio_io() and ath10k_sdio_read_write_sync() are just
confusing. Refactor the code by following the plan outlined
below.

I'm planning to fold all these seven patches into Erik's patch
adding sdio.c[1] so I didn't write any commit logs. I'm just
submitting these separately to make it easier to review the
changes.

Kalle

ath10k_sdio_read_write_sync():
X HIF_RD_SYNC_BLOCK_FIX -> ath10k_sdio_readsb()
X HIF_RD_SYNC_BYTE_INC  -> ath10k_sdio_read(), ath10k_sdio_read32()
X HIF_WR_SYNC_BYTE_FIX  -> ath10k_sdio_writesb32()
X HIF_WR_SYNC_BYTE_INC  -> ath10k_sdio_write()

ath10k_sdio_prep_async_req():
X HIF_WRITE -> HIF_WR_SYNC_BYTE_INC -> ath10k_sdio_write()

ath10k_sdio_read/write32():
sdio_readl()/sdio_writel() (those use endian macros)

ath10k_sdio_writesb32():
kmalloc()
sdio_writesb(len)
kfree()

ath10k_sdio_readsb():
len = round_down(len, ar_sdio->mbox_info.block_size);
sdio_readsb(len)

ath10k_sdio_read():
sdio_memcpy_fromio()

ath10k_sdio_write():
sdio_memcpy_toio()


[1] https://patchwork.kernel.org/patch/9626001/

---

Kalle Valo (7):
  ath10k: add ath10k_sdio_write32/read32()
  ath10k: add ath10k_sdio_writesb()
  ath10k: add ath10k_sdio_read()
  ath10k: add ath10k_sdio_write()
  ath10k: add ath10k_sdio_readsb()
  ath10k: convert __ath10k_sdio_write_async() to use ath10k_sdio_write()
  ath10k: remove unused sdio wrappers


 drivers/net/wireless/ath/ath10k/sdio.c |  419 +---
 drivers/net/wireless/ath/ath10k/sdio.h |   40 ---
 2 files changed, 219 insertions(+), 240 deletions(-)



Re: [PATCH 2/3] mwifiex: using general print function during device intialization

2017-04-05 Thread Xinming Hu

> -Original Message-
> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: 2017年4月4日 2:42
> To: Dmitry Torokhov
> Cc: Xinming Hu; Linux Wireless; Kalle Valo; Rajat Jain; Amitkumar Karwar; 
> Cathy
> Luo; Xinming Hu
> Subject: [EXT] Re: [PATCH 2/3] mwifiex: using general print function during
> device intialization
> 
> External Email
> 
> --
> On Fri, Mar 31, 2017 at 03:46:58PM -0700, Dmitry Torokhov wrote:
> > On Thu, Mar 30, 2017 at 2:19 AM, Xinming Hu 
> wrote:
> > > From: Xinming Hu 
> > >
> > > adapter->dev is initialized after mwifiex_register done, before that
> > > print message by general pr_* function
> >
> > No, we should move away from naked pr_*() as much as possible. Please
> > change  mwifiex_register() to accept "dev" parameter and assign
> > adapter->dev early enough so that the standard mwifiex_err() calls are
> > usable.
> 

Thanks for the review.

> Agreed. You mean like I did here? :)
> 
> ba1c7e45ec22 mwifiex: set adapter->dev before starting to use mwifiex_dbg()
> 
> That's in v4.11-rc4, partly as a bugfix to this:
> 
> 2e02b5814217 ("mwifiex: Allow mwifiex early access to device structure")
> 
> > Also consider changing _mwifiex_dbg() to handle cases when
> > adapter->dev is NULL and fall back to pr_.
> 
> That'd be nice. It would have mitigated the problems of commit
> 2e02b5814217 too.
> 

Yes, this commit ba1c7e4 should be better and work for most cases, will enhance 
__mwifiex_dbg for adapter->dev NULL case in V2.

Thanks,
Simon

> Brian
> 
> > > Signed-off-by: Xinming Hu 
> > > Signed-off-by: Amitkumar Karwar 
> > > ---
> > >  drivers/net/wireless/marvell/mwifiex/pcie.c | 78
> > > -
> > > drivers/net/wireless/marvell/mwifiex/sdio.c |  3 +-
> > >  2 files changed, 34 insertions(+), 47 deletions(-)
> 
> [...]