Re: [PATCH] wcn36xx: Fix dynamic power saving

2017-12-08 Thread Bjorn Andersson
On Fri 08 Dec 08:34 PST 2017, Loic Poulain wrote:

> Since driver does not report hardware dynamic power saving cap,
> this is up to the mac80211 to manage power saving timeout and
> state machine, using the ieee80211 config callback to report
> PS changes. This patch enables/disables PS mode according to
> the new configuration.
> 
> Remove old behaviour enabling PS mode in a static way, this make
> the device unusable when power save is enabled since device is
> forced to PS regardless RX/TX traffic.
> 
> Signed-off-by: Loic Poulain 

Acked-by: Bjorn Andersson 

With below nit.

> ---
>  drivers/net/wireless/ath/wcn36xx/main.c | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
> b/drivers/net/wireless/ath/wcn36xx/main.c
> index f0b4d43..436b8ea 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -384,6 +384,18 @@ static int wcn36xx_config(struct ieee80211_hw *hw, u32 
> changed)
>   }
>   }
>  
> + if (changed & IEEE80211_CONF_CHANGE_PS) {
> + list_for_each_entry(tmp, >vif_list, list) {
> + vif = wcn36xx_priv_to_vif(tmp);
> + if (hw->conf.flags & IEEE80211_CONF_PS) {
> + if (vif->bss_conf.ps) /* ps allowed ? */
> + wcn36xx_pmc_enter_bmps_state(wcn, vif);
> + } else {
> + wcn36xx_pmc_exit_bmps_state(wcn, vif);

During startup I get the error print from wcn36xx_pmc_exit_bmps_state()
that we're not in BMPS state. There's no harm in this, but the error
might concern people.

How about we in addition to this, change the wcn36xx_err() to a
wcn36xx_dbg(PMC...) ?

Regards,
Bjorn


[PATCH] wcn36xx: Reduce spinlock in indication handler

2017-12-08 Thread Bjorn Andersson
The purpose of pushing indication on a list and handle these in a
separate worker is to allow the handlers to sleep. It does therefor not
make much sense to hold the queue spinlock through the entire indication
worker function.

By removing items from the queue early we don't need to hold the lock
throughout the indication worker, allowing the individual handlers to
sleep.

Signed-off-by: Bjorn Andersson 
---
 drivers/net/wireless/ath/wcn36xx/smd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index fa88a2a460aa..52daae863aed 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -2414,6 +2414,8 @@ static void wcn36xx_ind_smd_work(struct work_struct *work)
hal_ind_msg = list_first_entry(>hal_ind_queue,
   struct wcn36xx_hal_ind_msg,
   list);
+   list_del(wcn->hal_ind_queue.next);
+   spin_unlock_irqrestore(>hal_ind_lock, flags);
 
msg_header = (struct wcn36xx_hal_msg_header *)hal_ind_msg->msg;
 
@@ -2450,8 +2452,6 @@ static void wcn36xx_ind_smd_work(struct work_struct *work)
wcn36xx_err("SMD_EVENT (%d) not supported\n",
  msg_header->msg_type);
}
-   list_del(wcn->hal_ind_queue.next);
-   spin_unlock_irqrestore(>hal_ind_lock, flags);
kfree(hal_ind_msg);
 }
 int wcn36xx_smd_open(struct wcn36xx *wcn)
-- 
2.15.0



Re: [PATCH] wcn36xx: Add hardware scan offload support

2017-12-08 Thread Bjorn Andersson
On Fri 08 Dec 01:35 PST 2017, Loic Poulain wrote:

> Current hw_scan implementation does not trigger offloaded
> hardware scan and seems to only put the device in a kind of
> listening mode (beacon/probe-response) for software scan.
> Since no probe request are generated by the software, current
> scanning method is similar to a passive scan.
> 
> This patch introduces support for 'true' hardware offloaded scan.
> Hardware scan is configured and started via the start-scan-offload
> firmware message. Once scan has been completed a scan indicator
> message is received from firmware.
> 
> Moreover, this patch includes support for directed probe-request,
> allowing connection with hidden APs. It also fixes scan issues with
> band-steering AP which are not 'visible' with passive scan (due to
> hidden ssid in beacons).
> 

I'm puzzled to why I didn't see this when I dumped the control channel
that lead up to the initial hw_scan patch. But this looks good and with
a related locking issue fixed this seems to work well.

Acked-by: Bjorn Andersson 

> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
> b/drivers/net/wireless/ath/wcn36xx/smd.c
[..]
> +static int wcn36xx_smd_hw_scan_ind(struct wcn36xx *wcn, void *buf, size_t 
> len)
> +{
> + struct wcn36xx_hal_scan_offload_ind *rsp = buf;
> + struct cfg80211_scan_info scan_info = {};
> +
> + if (len != sizeof(*rsp)) {
> + wcn36xx_warn("Corrupted delete scan indication\n");
> + return -EIO;
> + }
> +
> + wcn36xx_dbg(WCN36XX_DBG_HAL, "scan indication (type %x)", rsp->type);
> +
> + switch (rsp->type) {
> + case WCN36XX_HAL_SCAN_IND_FAILED:
> + scan_info.aborted = true;
> + case WCN36XX_HAL_SCAN_IND_COMPLETED:
> + mutex_lock(>scan_lock);

Grabbing this mutex with DEBUG_ATOMIC_SLEEP causes issues, but that's
because the locking in ind_smd_work() is to excessive. Will reply with a
fix for this.

> + wcn->scan_req = NULL;
> + mutex_unlock(>scan_lock);
> + ieee80211_scan_completed(wcn->hw, _info);
> + break;

Regards,
Bjorn


Re: pull-request: wireless-drivers 2017-12-08

2017-12-08 Thread David Miller
From: Kalle Valo 
Date: Fri, 08 Dec 2017 16:32:16 +0200

> this is a pull request to net tree for 4.15, more info in the signed tag
> below. All small fixes and not really expecting any problems, but please
> let me know if you have any.

Pulled, thanks Kalle.


wireless

2017-12-08 Thread Jeff Li

subscribe linux-wireless


[PATCH] wcn36xx: Fix dynamic power saving

2017-12-08 Thread Loic Poulain
Since driver does not report hardware dynamic power saving cap,
this is up to the mac80211 to manage power saving timeout and
state machine, using the ieee80211 config callback to report
PS changes. This patch enables/disables PS mode according to
the new configuration.

Remove old behaviour enabling PS mode in a static way, this make
the device unusable when power save is enabled since device is
forced to PS regardless RX/TX traffic.

Signed-off-by: Loic Poulain 
---
 drivers/net/wireless/ath/wcn36xx/main.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index f0b4d43..436b8ea 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -384,6 +384,18 @@ static int wcn36xx_config(struct ieee80211_hw *hw, u32 
changed)
}
}
 
+   if (changed & IEEE80211_CONF_CHANGE_PS) {
+   list_for_each_entry(tmp, >vif_list, list) {
+   vif = wcn36xx_priv_to_vif(tmp);
+   if (hw->conf.flags & IEEE80211_CONF_PS) {
+   if (vif->bss_conf.ps) /* ps allowed ? */
+   wcn36xx_pmc_enter_bmps_state(wcn, vif);
+   } else {
+   wcn36xx_pmc_exit_bmps_state(wcn, vif);
+   }
+   }
+   }
+
mutex_unlock(>conf_mutex);
 
return 0;
@@ -747,17 +759,6 @@ static void wcn36xx_bss_info_changed(struct ieee80211_hw 
*hw,
vif_priv->dtim_period = bss_conf->dtim_period;
}
 
-   if (changed & BSS_CHANGED_PS) {
-   wcn36xx_dbg(WCN36XX_DBG_MAC,
-   "mac bss PS set %d\n",
-   bss_conf->ps);
-   if (bss_conf->ps) {
-   wcn36xx_pmc_enter_bmps_state(wcn, vif);
-   } else {
-   wcn36xx_pmc_exit_bmps_state(wcn, vif);
-   }
-   }
-
if (changed & BSS_CHANGED_BSSID) {
wcn36xx_dbg(WCN36XX_DBG_MAC, "mac bss changed_bssid %pM\n",
bss_conf->bssid);
-- 
2.7.4



Re: [08/11] ath10k_sdio: common read write

2017-12-08 Thread Gary Bisson
Hi Alagu,

On Thu, Oct 05, 2017 at 11:03:12PM +0530, Alagu Sankar wrote:
> Hi Gary,
> 
> 
> On 2017-10-05 15:39, Gary Bisson wrote:
> > Hi Alagu,
> > 
> > On Sat, Sep 30, 2017 at 11:07:45PM +0530, silexcom...@gmail.com wrote:
> > > From: Alagu Sankar 
> > > 
> > > convert different read write functions in sdio hif to bring it under a
> > > single read-write path. This helps in having a common dma bounce
> > > buffer
> > > implementation. Also helps in address modification that is required
> > > specific to change in certain mbox addresses of sdio_write.
> > > 
> > > Signed-off-by: Alagu Sankar 
> > > ---
> > >  drivers/net/wireless/ath/ath10k/sdio.c | 131
> > > -
> > >  1 file changed, 64 insertions(+), 67 deletions(-)
> > > 
> > > diff --git a/drivers/net/wireless/ath/ath10k/sdio.c
> > > b/drivers/net/wireless/ath/ath10k/sdio.c
> > > index 77d4fa4..bb6fa67 100644
> > > --- a/drivers/net/wireless/ath/ath10k/sdio.c
> > > +++ b/drivers/net/wireless/ath/ath10k/sdio.c
> > > @@ -36,6 +36,11 @@
> > > 
> > >  #define ATH10K_SDIO_DMA_BUF_SIZE (32 * 1024)
> > > 
> > > +static int ath10k_sdio_read(struct ath10k *ar, u32 addr, void *buf,
> > > + u32 len, bool incr);
> > > +static int ath10k_sdio_write(struct ath10k *ar, u32 addr, const
> > > void *buf,
> > > +  u32 len, bool incr);
> > > +
> > 
> > As mentioned by Kalle, u32 needs to be size_t.
> Yes, the compiler I used is probably a step older and did not catch this.
> > 
> > >  /* inlined helper functions */
> > > 
> > >  /* Macro to check if DMA buffer is WORD-aligned and DMA-able.
> > > @@ -152,6 +157,7 @@ static int ath10k_sdio_config(struct ath10k *ar)
> > >   struct sdio_func *func = ar_sdio->func;
> > >   unsigned char byte, asyncintdelay = 2;
> > >   int ret;
> > > + u32 addr;
> > > 
> > >   ath10k_dbg(ar, ATH10K_DBG_BOOT, "sdio configuration\n");
> > > 
> > > @@ -180,9 +186,8 @@ static int ath10k_sdio_config(struct ath10k *ar)
> > >CCCR_SDIO_DRIVER_STRENGTH_ENABLE_C |
> > >CCCR_SDIO_DRIVER_STRENGTH_ENABLE_D);
> > > 
> > > - ret = ath10k_sdio_func0_cmd52_wr_byte(func->card,
> > > -   
> > > CCCR_SDIO_DRIVER_STRENGTH_ENABLE_ADDR,
> > > -   byte);
> > > + addr = CCCR_SDIO_DRIVER_STRENGTH_ENABLE_ADDR,
> > > + ret = ath10k_sdio_func0_cmd52_wr_byte(func->card, addr, byte);
> > 
> > Not sure this part is needed.
> This is to overcome checkpatch warning. Too big a names for the function and
> macro
> not helping in there. Will have to move it as a separate patch.
> > 
> > >   if (ret) {
> > >   ath10k_warn(ar, "failed to enable driver strength: %d\n", ret);
> > >   goto out;
> > > @@ -233,13 +238,16 @@ static int ath10k_sdio_config(struct ath10k *ar)
> > > 
> > >  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;
> > > + __le32 *buf;
> > >   int ret;
> > > 
> > > - sdio_claim_host(func);
> > > + buf = kzalloc(sizeof(*buf), GFP_KERNEL);
> > > + if (!buf)
> > > + return -ENOMEM;
> > > 
> > > - sdio_writel(func, val, addr, );
> > > + *buf = cpu_to_le32(val);
> > > +
> > > + ret = ath10k_sdio_write(ar, addr, , sizeof(val), true);
> > 
> > Shouldn't we use buf instead of val? buf seems pretty useless otherwise.
> Yes, thanks for pointing this out. will be corrected in v2.

Do you have any timeframe on the v2?

Regards,
Gary


pull-request: wireless-drivers 2017-12-08

2017-12-08 Thread Kalle Valo
Hi Dave,

this is a pull request to net tree for 4.15, more info in the signed tag
below. All small fixes and not really expecting any problems, but please
let me know if you have any.

Kalle

The following changes since commit f859b4af1c52493ec21173ccc73d0b60029b5b88:

  sit: update frag_off info (2017-11-30 10:25:41 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2017-12-08

for you to fetch changes up to a41886f56b7bbb88e6a23b5d738a94f2632142a4:

  Merge tag 'iwlwifi-for-kalle-2017-12-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2017-12-07 
15:50:34 +0200)


wireless-drivers fixes for 4.15

Second set of fixes for 4.15. This time a lot of iwlwifi patches and
two brcmfmac patches. Most important here are the MIC and IVC fixes
for iwlwifi to unbreak 9000 series.

iwlwifi

* fix rate-scaling to not start lowest possible rate

* fix the TX queue hang detection for AP/GO modes

* fix the TX queue hang timeout in monitor interfaces

* fix packet injection

* remove a wrong error message when dumping PCI registers

* fix race condition with RF-kill

* tell mac80211 when the MIC has been stripped (9000 series)

* tell mac80211 when the IVC has been stripped (9000 series)

* add 2 new PCI IDs, one for 9000 and one for 22000

* fix a queue hang due during a P2P Remain-on-Channel operation

brcmfmac

* fix a race which sometimes caused a crash during sdio unbind

* fix a kernel-doc related build error


Andy Shevchenko (1):
  brcmfmac: Avoid build error with make W=1

Arend Van Spriel (1):
  brcmfmac: change driver unbind order of the sdio function devices

David Spinadel (1):
  iwlwifi: mvm: enable RX offloading with TKIP and WEP

Emmanuel Grumbach (3):
  iwlwifi: mvm: don't use transmit queue hang detection when it is not 
possible
  iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type
  iwlwifi: mvm: fix packet injection

Ihab Zhaika (1):
  iwlwifi: add new cards for 9260 and 22000 series

Johannes Berg (1):
  iwlwifi: mvm: flush queue before deleting ROC

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2017-11-28' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge tag 'iwlwifi-for-kalle-2017-12-05' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Sara Sharon (3):
  iwlwifi: pcie: fix erroneous "Read failed message"
  iwlwifi: fix access to prph when transport is stopped
  iwlwifi: mvm: mark MIC stripped MPDUs

Shaul Triebitz (1):
  iwlwifi: mvm: set correct chains in Rx status

 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  4 +-
 drivers/net/wireless/intel/iwlwifi/fw/api/txq.h|  4 ++
 drivers/net/wireless/intel/iwlwifi/fw/dbg.h|  2 -
 drivers/net/wireless/intel/iwlwifi/iwl-trans.h |  4 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |  2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |  3 ++
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c   |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  | 18 ++--
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   | 53 --
 .../net/wireless/intel/iwlwifi/mvm/time-event.c| 24 +-
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c|  3 +-
 drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 13 +-
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c  |  2 +
 .../net/wireless/intel/iwlwifi/pcie/trans-gen2.c   |  6 +++
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c| 10 
 15 files changed, 122 insertions(+), 27 deletions(-)

-- 
Kalle Valo


iwl3945: regression at 4.15-rc1 was Re: 4.15.0-rc1-next-20171201: WARNING: .... at net/mac80211/agg-tx.c:315

2017-12-08 Thread Pavel Machek
Hi!

> > This is quite annoying: repeated
> >
> > [ 4169.591529] ---[ end trace e65d97cf1d20b84d ]---
> > [ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315
> > ___ieee80211_stop_tx_\
> > ba_session+0x158/0x1f0
> >
> > Hardware is thinkpad x60. Git blame says cfcdbde35 introduced the
> > test.
> 
> To save time for others, the driver is iwl3945:
> 
> > [0.970687] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection 
> > driver for Linux, in-tree:ds
> > [0.970690] iwl3945: Copyright(c) 2003-2011 Intel Corporation
> > [0.970692] iwl3945: hw_scan is disabled
> > [0.971082] iwl3945 :03:00.0: can't disable ASPM; OS doesn't have 
> > ASPM control
> > [1.026281] iwl3945 :03:00.0: Tunable channels: 11 802.11bg, 13 
> > 802.11a channels
> > [1.026287] iwl3945 :03:00.0: Detected Intel Wireless WiFi Link 
> > 3945ABG
> > [1.027866] ieee80211 phy0: Selected rate control algorithm 'iwl-3945-rs'

And same problem is there in 4.15-rc1. It is regression from 4.14.

[  530.816390] WARNING: CPU: 1 PID: 3193 at net/mac80211/agg-tx.c:315
___ieee802
11_stop_tx_ba_session+0x158/0x1f0
[  530.816395] Modules linked in:
[  530.816405] CPU: 1 PID: 3193 Comm: wpa_supplicant Tainted: G
W
4.15.0-rc1+ #447
[  530.816410] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW
(2.19 ) 03/3
1/2011
[  530.816416] task: 17453748 task.stack: 79a41831
[  530.816422] EIP: ___ieee80211_stop_tx_ba_session+0x158/0x1f0
[  530.816427] EFLAGS: 00010246 CPU: 1
[  530.816433] EAX:  EBX: f5c19000 ECX: f5eff670 EDX: f5eff040
[  530.816438] ESI: 000f EDI: 0003 EBP: ef32dbb4 ESP: ef32db8c
[  530.816444]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  530.816450] CR0: 80050033 CR2: 091a4008 CR3: 34d412c0 CR4: 06b0
[  530.816455] Call Trace:
[  530.816463]  ieee80211_sta_tear_down_BA_sessions+0x6e/0xd0
[  530.816470]  __sta_info_destroy_part1+0x3d/0x1f0


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

2017-12-08 Thread Sven Eckelmann
On Freitag, 8. Dezember 2017 18:05:38 CET ako...@codeaurora.org wrote:
> On 2017-12-08 17:42, Sven Eckelmann wrote:
> > On Donnerstag, 25. Mai 2017 16:21:23 CET ako...@qti.qualcomm.com wrote:
> >> From: Anilkumar Kolli 
> >> 
> >> QCA99X0, QCA9888, QCA9984 supports calibration data in
> >> either OTP or DT/pre-cal file. Current ath10k supports
> >> Calibration data from OTP only.
[...]
> > Just tried this on an QCA9984 which doesn't seem to have the
> > calibration data in the PCI EEPROM.
> > 
> > [   71.728929] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0
> > target 0x0100 chip_id 0x sub 168c:cafe
> > [   71.732926] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
> > tracing 0 dfs 1 testmode 1
> > [   71.752282] ath10k_pci :01:00.0: firmware ver
> > 10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32
> > 7198d117
> > [   73.805730] ath10k_pci :01:00.0: unable to read from the 
> > device
> > [   73.805769] ath10k_pci :01:00.0: could not execute otp for
> > board id check: -110
> > 
> 
> 'ATH10K driver <-> 10.4 firmware' expects cal data to be either in 
> EEPROM or pre-cal-file or DT.
> Hope the error is observed when there is no cal data loaded.

The problem happens when pre-cal data file is loaded using the userspace 
helper on the QCA9984. I was only able to use the device when I (for a test) 
used the pre-cal data as cal-data (file).

The EEPROM on the on the PCI device doesn't seem to be populated with a valid 
pre-cal data. I've already tested it with a QCA9984 device which had pre-cal 
data in the PCI device's EEPROM and this worked fine (without cal file and 
without pre-cal file).

> > It works when I use the pre-cal data as calibration data. The checksum 
> > in the
> > pre-cal seems to be correct. Also the pre-cal data from 0:ART for the 
> > 2.4GHz
> > and 5GHz QCA4019 seem to work perfectly fine.
> > 
> 
> Do you mean this patch works for only QCA4019 and not working for 
> QCA9984 ?

Worked fine for QCA4019 and QCA9888 - but I had no luck with QCA9984. The 
error shown above it the only thing I get.

Kind regards,
Sven

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


[PATCH 2/2] ath10k: Populate RSC counter to firmware

2017-12-08 Thread Govind Singh
Access Point (AP) re-transmits message 3 of 4 way handshake if
AP does not receive an appropriate response as acknowledgment.
As a result, the client may receive message 3 multiple times.
Each time it receives this message, it reinstalls the same
encryption key, and thereby reset the incremental transmit packet
number (nonce) and receive replay counter used by the encryption
protocol. By forcing nonce reuse in this manner, the encryption
protocol can be attacked, e.g., packets can be replayed, decrypted,
and/or forged.

Send RSC counter to FW in set key WMI command, so that FW can drop the
packet in PN check if received packet sequence no is less than current
RSC counter during group keys(GTK) exchange.

Tested on QCA6174 HW3.0 with firmware version RM.4.4.1.c1-00035-QCARMSWP-1.

Signed-off-by: Govind Singh 
---
 drivers/net/wireless/ath/ath10k/mac.c | 1 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 3 +++
 drivers/net/wireless/ath/ath10k/wmi.h | 4 +++-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 06383e7..43f78e3 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -226,6 +226,7 @@ static int ath10k_send_key(struct ath10k_vif *arvif,
.macaddr = macaddr,
};
 
+   memcpy(arg.key_rsc_counter, key->rx_pn, IEEE80211_MAX_PN_LEN);
lockdep_assert_held(>ar->conf_mutex);
 
switch (key->cipher) {
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 7616c1c..e7148f0 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1849,6 +1849,9 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_init(struct 
ath10k *ar)
if (arg->macaddr)
ether_addr_copy(cmd->peer_macaddr.addr, arg->macaddr);
 
+   memcpy(>key_rsc_counter, >key_rsc_counter,
+  WMI_MAX_RSC_LEN);
+
ptr += sizeof(*tlv);
ptr += sizeof(*cmd);
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index c02b21c..4849787 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4752,6 +4752,7 @@ struct wmi_key_seq_counter {
 #define WMI_CIPHER_CKIP 0x6
 #define WMI_CIPHER_AES_CMAC 0x7
 #define WMI_CIPHER_AES_GCM  0x8
+#define WMI_MAX_RSC_LEN 0x8
 
 struct wmi_vdev_install_key_cmd {
__le32 vdev_id;
@@ -4759,7 +4760,7 @@ struct wmi_vdev_install_key_cmd {
__le32 key_idx;
__le32 key_flags;
__le32 key_cipher; /* %WMI_CIPHER_ */
-   struct wmi_key_seq_counter key_rsc_counter;
+   u8 key_rsc_counter[WMI_MAX_RSC_LEN];
struct wmi_key_seq_counter key_global_rsc_counter;
struct wmi_key_seq_counter key_tsc_counter;
u8 wpi_key_rsc_counter[16];
@@ -4782,6 +4783,7 @@ struct wmi_vdev_install_key_arg {
u32 key_txmic_len;
u32 key_rxmic_len;
const void *key_data;
+   u8 key_rsc_counter[IEEE80211_MAX_PN_LEN];
 };
 
 /*
-- 
1.9.1



[PATCH 1/2] mac80211: Populate RSC counter in set_key method

2017-12-08 Thread Govind Singh
Send RSC counter to driver in set_key method, so that FW/driver
can drop the packet in PN check if received packet sequence
no is less than current RSC counter during group keys(GTK)
exchange.

Signed-off-by: Govind Singh 
---
 include/net/mac80211.h | 6 --
 net/mac80211/key.c | 6 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2ee4af2..2f0c91d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1564,6 +1564,8 @@ enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_RESERVE_TAILROOM = BIT(7),
 };
 
+#define IEEE80211_MAX_PN_LEN   16
+
 /**
  * struct ieee80211_key_conf - key information
  *
@@ -1586,6 +1588,7 @@ enum ieee80211_key_flags {
  * - Temporal Authenticator Rx MIC Key (64 bits)
  * @icv_len: The ICV length for this key type
  * @iv_len: The IV length for this key type
+ * @rx_pn: Last received packet number, must be in little endian.
  */
 struct ieee80211_key_conf {
atomic64_t tx_pn;
@@ -1596,11 +1599,10 @@ struct ieee80211_key_conf {
u8 flags;
s8 keyidx;
u8 keylen;
+   u8 rx_pn[IEEE80211_MAX_PN_LEN];
u8 key[0];
 };
 
-#define IEEE80211_MAX_PN_LEN   16
-
 #define TKIP_PN_TO_IV16(pn) ((u16)(pn & 0x))
 #define TKIP_PN_TO_IV32(pn) ((u32)((pn >> 16) & 0x))
 
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 9380493..15e1822 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -538,6 +538,12 @@ struct ieee80211_key *
}
memcpy(key->conf.key, key_data, key_len);
INIT_LIST_HEAD(>list);
+   /* Assign receive packet sequence no, rx_pn remains in
+* little endian format as seq is guaranteed to be in little
+* endian format.
+*/
+   if (seq)
+   memcpy(>conf.rx_pn, seq, seq_len);
 
return key;
 }
-- 
1.9.1



Re: [v2] wireless: use ARRAY_SIZE

2017-12-08 Thread Kalle Valo
Jérémy Lefaure wrote:

> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time.
> 
> Found with Coccinelle with the following semantic patch:
> @r depends on (org || report)@
> type T;
> T[] E;
> position p;
> @@
> (
>  (sizeof(E)@p /sizeof(*E))
> |
>  (sizeof(E)@p /sizeof(E[...]))
> |
>  (sizeof(E)@p /sizeof(T))
> )
> 
> Signed-off-by: Jérémy Lefaure 

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

53ac79359327 wireless: use ARRAY_SIZE

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

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



Re: iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports

2017-12-08 Thread Kalle Valo
Luciano Coelho  wrote:

> From: Luca Coelho 
> 
> I accidentally pushed a patch with CPTCFG (which is used in the
> backports project) to the rs-fw.c file.  Fix that to use CONFIG
> instead.
> 
> Fixes: 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in 
> the FW")
> Signed-off-by: Luca Coelho 

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

59365b9efd48 iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports

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

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



Re: pull-request: iwlwifi-next 2017-12-05

2017-12-08 Thread Kalle Valo
Luca Coelho  writes:

> This is my second batch of patches intended for v4.16.  As I mentioned
> in the patchset thread, I moved patches 5/15 and 6/16 to iwlwifi-fixes. 
> Otherwise nothing major here, just the usual continued development.
> More details about the contents in the tag description.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 80b0ebd488b3edaf3e5ed08c34a952c804e3a635:
>
>   Merge tag 'iwlwifi-next-for-kalle-2017-11-29' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next 
> (2017-12-02 15:22:54 +0200)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2017-12-05
>
> for you to fetch changes up to 0190ff24e55efd3e02479537c2d91835602fffa3:
>
>   iwlwifi: mvm: request statistics when reading debugfs (2017-12-05 21:01:43 
> +0200)
>
> 
> Second batch of iwlwifi updates for v4.16
>
> * Initial work for rate-scaling offload;
> * Support for new FW API version;
> * Some fixes here and there;
>
> 

Pulled, thanks.

-- 
Kalle Valo


Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped

2017-12-08 Thread Kalle Valo
Luca Coelho  writes:

> On Fri, 2017-12-08 at 14:26 +0200, Kalle Valo wrote:
>> Kalle Valo  writes:
>> 
>> > Luca Coelho  writes:
>> > 
>> > > On Wed, 2017-11-29 at 12:23 +0200, Kalle Valo wrote:
>> > > 
>> > > > But no wonder I called gnus-article-fill-cited-article, the
>> > > > commit
>> > > > log is just weirdly wrapped. Are you using outlook or how do
>> > > > you get
>> > > > it so ugly? :)
>> > > 
>> > > Heh! I don't think it's wrapped weirdly, it's just that the
>> > > paragraphs
>> > > don't have spaces between them, right? ;)
>> > 
>> > Sorry, don't get what you mean with missing spaces. To me (and
>> > patchwork[1] and git[2] seem to agree) the word wrapping is just
>> > broken
>> > for this commit log, and I have seen it also with other iwlwifi
>> > commits.
>> > For example, there are just two words in the second line "two
>> > paths."
>> > 
>> > The standard format for git commit logs is something like this:
>> > 
>> > -
>> > -
>> > When getting HW rfkill we get stop_device being called from two
>> > paths.
>> > One path is the IRQ calling stop device, and updating op mode and
>> > stack.
>> > As a result, cfg80211 is running rfkill sync work that shuts down
>> > all
>> > devices (second path). In the second path, we eventually get to
>> > iwl_mvm_stop_device which calls iwl_fw_dump_conf_clear-
>> > >iwl_fw_dbg_stop_recording,
>> > that access periphery registers.
>> > 
>> > The device may be stopped at this point from the first path,
>> > which will result with a failure to access those registers. Simply
>> > checking for the trans status is insufficient, since the race will
>> > still
>> > exist, only minimized. Instead, move the stop from
>> > iwl_fw_dump_conf_clear (which is getting called only from stop
>> > path) to
>> > the transport stop device function, where the access is always
>> > safe.
>> > This has the added value, of actually stopping dbgc before stopping
>> > device even when the stop is initiated from the transport.
>> > -
>> > -
>> > 
>> > [1] https://patchwork.kernel.org/patch/10074849/
>> 
>> Instead of trying to get what I mean, check instead the patchwork
>> page
>> and compare there the original commit log with my reformatted
>> version. I
>> think that visualises pretty well what I'm trying to say :)
>
> Okay, granted, but that's not really because of alignment or line-
> wrapping.  It's because the paragraphs are broken too often.
>
> In any case, I'll pay more attention to this.  So my questions remains,
> do you want me to remake my pull-req to fix this?

This commit is already in wireless-drivers, so no need to resend. I was
just trying to give an example of what I was trying to say.

-- 
Kalle Valo


[PATCH] iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports

2017-12-08 Thread Luca Coelho
From: Luca Coelho 

I accidentally pushed a patch with CPTCFG (which is used in the
backports project) to the rs-fw.c file.  Fix that to use CONFIG
instead.

Fixes: 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the 
FW")
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
index 4e5f09408517..55d1274c6092 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
@@ -308,7 +308,7 @@ void iwl_mvm_rs_add_sta(struct iwl_mvm *mvm, struct 
iwl_mvm_sta *mvmsta)
lq_sta->pers.last_rssi = S8_MIN;
lq_sta->last_rate_n_flags = 0;
 
-#ifdef CPTCFG_MAC80211_DEBUGFS
+#ifdef CONFIG_MAC80211_DEBUGFS
lq_sta->pers.dbg_fixed_rate = 0;
 #endif
 }
-- 
2.15.0



Re: [PATCH v2 06/15] iwlwifi: mvm: rs: add ops for the new rate scaling in the FW

2017-12-08 Thread Luciano Coelho
On Fri, 2017-12-08 at 14:38 +0200, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > From: Gregory Greenman 
> > 
> > This patch introduces a new instance of rate_control_ops for
> > the new API (adding only empty stubs here and the subsequent
> > patches in the series will fill in the implementation).
> > The decision which API to use is done during the register
> > step according to FW TLV.
> > 
> > Signed-off-by: Gregory Greenman 
> > Signed-off-by: Luca Coelho 
> 
> [...]
> 
> > +void iwl_mvm_rs_add_sta(struct iwl_mvm *mvm, struct iwl_mvm_sta
> > *mvmsta)
> > +{
> > +   struct iwl_lq_sta_rs_fw *lq_sta = >lq_sta.rs_fw;
> > +
> > +   IWL_DEBUG_RATE(mvm, "create station rate scale window\n");
> > +
> > +   lq_sta->pers.drv = mvm;
> > +   lq_sta->pers.sta_id = mvmsta->sta_id;
> > +   lq_sta->pers.chains = 0;
> > +   memset(lq_sta->pers.chain_signal, 0, sizeof(lq_sta-
> > >pers.chain_signal));
> > +   lq_sta->pers.last_rssi = S8_MIN;
> > +   lq_sta->last_rate_n_flags = 0;
> > +
> > +#ifdef CPTCFG_MAC80211_DEBUGFS
> > +   lq_sta->pers.dbg_fixed_rate = 0;
> > +#endif
> > +}
> 
> CPTCFG_ doesn't look right. But no need to resend just because of
> this,
> you can send a followup patch.

Gack, how come I let this go through? My (actually Emmanuel's ;)
checker script should catch this.  Maybe I forgot to run it on v2?
Sorry, dude!

--
Luca.


Re: [PATCH v2 06/15] iwlwifi: mvm: rs: add ops for the new rate scaling in the FW

2017-12-08 Thread Kalle Valo
Luca Coelho  writes:

> From: Gregory Greenman 
>
> This patch introduces a new instance of rate_control_ops for
> the new API (adding only empty stubs here and the subsequent
> patches in the series will fill in the implementation).
> The decision which API to use is done during the register
> step according to FW TLV.
>
> Signed-off-by: Gregory Greenman 
> Signed-off-by: Luca Coelho 

[...]

> +void iwl_mvm_rs_add_sta(struct iwl_mvm *mvm, struct iwl_mvm_sta *mvmsta)
> +{
> + struct iwl_lq_sta_rs_fw *lq_sta = >lq_sta.rs_fw;
> +
> + IWL_DEBUG_RATE(mvm, "create station rate scale window\n");
> +
> + lq_sta->pers.drv = mvm;
> + lq_sta->pers.sta_id = mvmsta->sta_id;
> + lq_sta->pers.chains = 0;
> + memset(lq_sta->pers.chain_signal, 0, sizeof(lq_sta->pers.chain_signal));
> + lq_sta->pers.last_rssi = S8_MIN;
> + lq_sta->last_rate_n_flags = 0;
> +
> +#ifdef CPTCFG_MAC80211_DEBUGFS
> + lq_sta->pers.dbg_fixed_rate = 0;
> +#endif
> +}

CPTCFG_ doesn't look right. But no need to resend just because of this,
you can send a followup patch.

-- 
Kalle Valo


Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

2017-12-08 Thread akolli

On 2017-12-08 17:42, Sven Eckelmann wrote:

On Donnerstag, 25. Mai 2017 16:21:23 CET ako...@qti.qualcomm.com wrote:

From: Anilkumar Kolli 

QCA99X0, QCA9888, QCA9984 supports calibration data in
either OTP or DT/pre-cal file. Current ath10k supports
Calibration data from OTP only.

If caldata is loaded from DT/pre-cal file, fetching board id
and applying calibration parameters like tx power gets failed.

error log:
[   15.733663] ath10k_pci :01:00.0: failed to fetch board file: -2
[   15.741474] ath10k_pci :01:00.0: could not probe fw (-2)

This patch adds calibration data support from DT/pre-cal
file.  Below parameters are used to get board id and
applying calibration parameters from cal data.

EEPROM[OTP] FLASH[DT/pre-cal file]
Cal param   0x700   0x1
Board id0x100x8000

Tested on QCA9888 with pre-cal file.

Signed-off-by: Anilkumar Kolli 
---
 drivers/net/wireless/ath/ath10k/bmi.h  |2 ++
 drivers/net/wireless/ath/ath10k/core.c |   16 +---
 2 files changed, 15 insertions(+), 3 deletions(-)


Just tried this on an QCA9984 which doesn't seem to have the
calibration data in the PCI EEPROM.

[   71.728929] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0
target 0x0100 chip_id 0x sub 168c:cafe
[   71.732926] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 1
[   71.752282] ath10k_pci :01:00.0: firmware ver
10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32
7198d117
[   73.805730] ath10k_pci :01:00.0: unable to read from the 
device

[   73.805769] ath10k_pci :01:00.0: could not execute otp for
board id check: -110



'ATH10K driver <-> 10.4 firmware' expects cal data to be either in 
EEPROM or pre-cal-file or DT.

Hope the error is observed when there is no cal data loaded.

It works when I use the pre-cal data as calibration data. The checksum 
in the
pre-cal seems to be correct. Also the pre-cal data from 0:ART for the 
2.4GHz

and 5GHz QCA4019 seem to work perfectly fine.



Do you mean this patch works for only QCA4019 and not working for 
QCA9984 ?


Anything which I could have missed or what I could test? Btw. I've also 
tested

the non-ct firmware (aka the official one from QCA).



Thanks,
Anil.



Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped

2017-12-08 Thread Luca Coelho
On Fri, 2017-12-08 at 14:26 +0200, Kalle Valo wrote:
> Kalle Valo  writes:
> 
> > Luca Coelho  writes:
> > 
> > > On Wed, 2017-11-29 at 12:23 +0200, Kalle Valo wrote:
> > > 
> > > > But no wonder I called gnus-article-fill-cited-article, the
> > > > commit
> > > > log is just weirdly wrapped. Are you using outlook or how do
> > > > you get
> > > > it so ugly? :)
> > > 
> > > Heh! I don't think it's wrapped weirdly, it's just that the
> > > paragraphs
> > > don't have spaces between them, right? ;)
> > 
> > Sorry, don't get what you mean with missing spaces. To me (and
> > patchwork[1] and git[2] seem to agree) the word wrapping is just
> > broken
> > for this commit log, and I have seen it also with other iwlwifi
> > commits.
> > For example, there are just two words in the second line "two
> > paths."
> > 
> > The standard format for git commit logs is something like this:
> > 
> > -
> > -
> > When getting HW rfkill we get stop_device being called from two
> > paths.
> > One path is the IRQ calling stop device, and updating op mode and
> > stack.
> > As a result, cfg80211 is running rfkill sync work that shuts down
> > all
> > devices (second path). In the second path, we eventually get to
> > iwl_mvm_stop_device which calls iwl_fw_dump_conf_clear-
> > >iwl_fw_dbg_stop_recording,
> > that access periphery registers.
> > 
> > The device may be stopped at this point from the first path,
> > which will result with a failure to access those registers. Simply
> > checking for the trans status is insufficient, since the race will
> > still
> > exist, only minimized. Instead, move the stop from
> > iwl_fw_dump_conf_clear (which is getting called only from stop
> > path) to
> > the transport stop device function, where the access is always
> > safe.
> > This has the added value, of actually stopping dbgc before stopping
> > device even when the stop is initiated from the transport.
> > -
> > -
> > 
> > [1] https://patchwork.kernel.org/patch/10074849/
> 
> Instead of trying to get what I mean, check instead the patchwork
> page
> and compare there the original commit log with my reformatted
> version. I
> think that visualises pretty well what I'm trying to say :)

Okay, granted, but that's not really because of alignment or line-
wrapping.  It's because the paragraphs are broken too often.

In any case, I'll pay more attention to this.  So my questions remains,
do you want me to remake my pull-req to fix this?

--
Luca.



Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

2017-12-08 Thread Kalle Valo
Stephen Rothwell  writes:

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/pcie/drv.c
>
> between commit:
>
>   567deca8e72d ("iwlwifi: add new cards for 9260 and 22000 series")
>
> from the wireless-drivers tree and commit:
>
>   2f7a3863191a ("iwlwifi: rename the temporary name of A000 to the official 
> 22000")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The fix looks good, thanks! I'll try to resolve the conflict before I
send a wireless-drivers-next pull request to Dave.

-- 
Kalle Valo


Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped

2017-12-08 Thread Luca Coelho
On Fri, 2017-12-08 at 14:22 +0200, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > On Wed, 2017-11-29 at 12:23 +0200, Kalle Valo wrote:
> > 
> > > But no wonder I called gnus-article-fill-cited-article, the
> > > commit
> > > log is just weirdly wrapped. Are you using outlook or how do you
> > > get
> > > it so ugly? :)
> > 
> > Heh! I don't think it's wrapped weirdly, it's just that the
> > paragraphs
> > don't have spaces between them, right? ;)
> 
> Sorry, don't get what you mean with missing spaces. To me (and
> patchwork[1] and git[2] seem to agree) the word wrapping is just
> broken
> for this commit log, and I have seen it also with other iwlwifi
> commits.
> For example, there are just two words in the second line "two paths."

That depends on how many characters per line you want to include.  "two
paths." is the last part of the first paragraph, I guess Sari's editor
is wrapping somewhere at <70 chars per line.

Then that is accentuated a bit by the lack of an empty line between
paragraphs.  But with those lines added, besides being a bit narrow, it
would look quite clear:

-8<-
When getting HW rfkill we get stop_device being called from
two paths.

One path is the IRQ calling stop device, and updating op
mode and stack.

As a result, cfg80211 is running rfkill sync work that shuts
down all devices (second path).

In the second path, we eventually get to iwl_mvm_stop_device
which calls iwl_fw_dump_conf_clear->iwl_fw_dbg_stop_recording,
that access periphery registers.

The device may be stopped at this point from the first path,
which will result with a failure to access those registers.

Simply checking for the trans status is insufficient, since
the race will still exist, only minimized.

Instead, move the stop from iwl_fw_dump_conf_clear (which is
getting called only from stop path) to the transport stop
device function, where the access is always safe.

This has the added value, of actually stopping dbgc before
stopping device even when the stop is initiated from the
transport.
->8-

Does it make sense?

I've already told Sari about your preference and I'll make sure the
next patches will look cleaner.  I can fix this patch if you want, but
is it worth remaking my pull-request just for this?

--
Cheers,
Luca.


Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped

2017-12-08 Thread Kalle Valo
Kalle Valo  writes:

> Luca Coelho  writes:
>
>> On Wed, 2017-11-29 at 12:23 +0200, Kalle Valo wrote:
>>
>>> But no wonder I called gnus-article-fill-cited-article, the commit
>>> log is just weirdly wrapped. Are you using outlook or how do you get
>>> it so ugly? :)
>>
>> Heh! I don't think it's wrapped weirdly, it's just that the paragraphs
>> don't have spaces between them, right? ;)
>
> Sorry, don't get what you mean with missing spaces. To me (and
> patchwork[1] and git[2] seem to agree) the word wrapping is just broken
> for this commit log, and I have seen it also with other iwlwifi commits.
> For example, there are just two words in the second line "two paths."
>
> The standard format for git commit logs is something like this:
>
> --
> When getting HW rfkill we get stop_device being called from two paths.
> One path is the IRQ calling stop device, and updating op mode and stack.
> As a result, cfg80211 is running rfkill sync work that shuts down all
> devices (second path). In the second path, we eventually get to
> iwl_mvm_stop_device which calls 
> iwl_fw_dump_conf_clear->iwl_fw_dbg_stop_recording,
> that access periphery registers.
>
> The device may be stopped at this point from the first path,
> which will result with a failure to access those registers. Simply
> checking for the trans status is insufficient, since the race will still
> exist, only minimized. Instead, move the stop from
> iwl_fw_dump_conf_clear (which is getting called only from stop path) to
> the transport stop device function, where the access is always safe.
> This has the added value, of actually stopping dbgc before stopping
> device even when the stop is initiated from the transport.
> --
>
> [1] https://patchwork.kernel.org/patch/10074849/

Instead of trying to get what I mean, check instead the patchwork page
and compare there the original commit log with my reformatted version. I
think that visualises pretty well what I'm trying to say :)

-- 
Kalle Valo


Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped

2017-12-08 Thread Kalle Valo
Luca Coelho  writes:

> On Wed, 2017-11-29 at 12:23 +0200, Kalle Valo wrote:
>
>> But no wonder I called gnus-article-fill-cited-article, the commit
>> log is just weirdly wrapped. Are you using outlook or how do you get
>> it so ugly? :)
>
> Heh! I don't think it's wrapped weirdly, it's just that the paragraphs
> don't have spaces between them, right? ;)

Sorry, don't get what you mean with missing spaces. To me (and
patchwork[1] and git[2] seem to agree) the word wrapping is just broken
for this commit log, and I have seen it also with other iwlwifi commits.
For example, there are just two words in the second line "two paths."

The standard format for git commit logs is something like this:

--
When getting HW rfkill we get stop_device being called from two paths.
One path is the IRQ calling stop device, and updating op mode and stack.
As a result, cfg80211 is running rfkill sync work that shuts down all
devices (second path). In the second path, we eventually get to
iwl_mvm_stop_device which calls 
iwl_fw_dump_conf_clear->iwl_fw_dbg_stop_recording,
that access periphery registers.

The device may be stopped at this point from the first path,
which will result with a failure to access those registers. Simply
checking for the trans status is insufficient, since the race will still
exist, only minimized. Instead, move the stop from
iwl_fw_dump_conf_clear (which is getting called only from stop path) to
the transport stop device function, where the access is always safe.
This has the added value, of actually stopping dbgc before stopping
device even when the stop is initiated from the transport.
--

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

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=0232d2cd7aa8e1b810fe84fb4059a0bd1eabe2ba

-- 
Kalle Valo


Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

2017-12-08 Thread Sven Eckelmann
On Donnerstag, 25. Mai 2017 16:21:23 CET ako...@qti.qualcomm.com wrote:
> From: Anilkumar Kolli 
> 
> QCA99X0, QCA9888, QCA9984 supports calibration data in
> either OTP or DT/pre-cal file. Current ath10k supports
> Calibration data from OTP only.
> 
> If caldata is loaded from DT/pre-cal file, fetching board id
> and applying calibration parameters like tx power gets failed.
> 
> error log:
> [   15.733663] ath10k_pci :01:00.0: failed to fetch board file: -2
> [   15.741474] ath10k_pci :01:00.0: could not probe fw (-2)
> 
> This patch adds calibration data support from DT/pre-cal
> file.  Below parameters are used to get board id and
> applying calibration parameters from cal data.
> 
>   EEPROM[OTP] FLASH[DT/pre-cal file]
> Cal param 0x700   0x1
> Board id  0x100x8000
> 
> Tested on QCA9888 with pre-cal file.
> 
> Signed-off-by: Anilkumar Kolli 
> ---
>  drivers/net/wireless/ath/ath10k/bmi.h  |2 ++
>  drivers/net/wireless/ath/ath10k/core.c |   16 +---
>  2 files changed, 15 insertions(+), 3 deletions(-)

Just tried this on an QCA9984 which doesn't seem to have the calibration data 
in the PCI EEPROM.

[   71.728929] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target 
0x0100 chip_id 0x sub 168c:cafe
[   71.732926] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 0 
dfs 1 testmode 1
[   71.752282] ath10k_pci :01:00.0: firmware ver 
10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32 7198d117
[   73.805730] ath10k_pci :01:00.0: unable to read from the device
[   73.805769] ath10k_pci :01:00.0: could not execute otp for board id 
check: -110

It works when I use the pre-cal data as calibration data. The checksum in the 
pre-cal seems to be correct. Also the pre-cal data from 0:ART for the 2.4GHz 
and 5GHz QCA4019 seem to work perfectly fine.

Anything which I could have missed or what I could test? Btw. I've also tested 
the non-ct firmware (aka the official one from QCA).

Kind

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


[PATCH 05/10] brcmfmac: Tidy register definitions a little

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

Trivial tidy of register definitions.

Signed-off-by: Ian Molton 
Acked-by: Arend van Spriel 
Signed-off-by: Arend van Spriel 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c |  4 ++--
 .../net/wireless/broadcom/brcm80211/brcmfmac/sdio.h   | 19 ++-
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 608c5f8..e0b201f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -153,9 +153,9 @@ int brcmf_sdiod_intr_register(struct brcmf_sdio_dev 
*sdiodev)
brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_IENx, data, );
 
/* redirect, configure and enable io for interrupt signal */
-   data = SDIO_SEPINT_MASK | SDIO_SEPINT_OE;
+   data = SDIO_CCCR_BRCM_SEPINT_MASK | SDIO_CCCR_BRCM_SEPINT_OE;
if (pdata->oob_irq_flags & IRQF_TRIGGER_HIGH)
-   data |= SDIO_SEPINT_ACT_HI;
+   data |= SDIO_CCCR_BRCM_SEPINT_ACT_HI;
brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_BRCM_SEPINT,
 data, );
sdio_release_host(sdiodev->func[1]);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
index 453213b..01def16 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
@@ -52,16 +52,17 @@
 /* function 0 vendor specific CCCR registers */
 
 #define SDIO_CCCR_BRCM_CARDCAP 0xf0
-#define SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT   0x02
-#define SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT   0x04
-#define SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC   0x08
-#define SDIO_CCCR_BRCM_CARDCTRL0xf1
-#define SDIO_CCCR_BRCM_CARDCTRL_WLANRESET  0x02
-#define SDIO_CCCR_BRCM_SEPINT  0xf2
+#define SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT   BIT(1)
+#define SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT   BIT(2)
+#define SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC   BIT(3)
+
+#define SDIO_CCCR_BRCM_CARDCTRL0xf1
+#define SDIO_CCCR_BRCM_CARDCTRL_WLANRESET  BIT(1)
 
-#define  SDIO_SEPINT_MASK  0x01
-#define  SDIO_SEPINT_OE0x02
-#define  SDIO_SEPINT_ACT_HI0x04
+#define SDIO_CCCR_BRCM_SEPINT  0xf2
+#define SDIO_CCCR_BRCM_SEPINT_MASK BIT(0)
+#define SDIO_CCCR_BRCM_SEPINT_OE   BIT(1)
+#define SDIO_CCCR_BRCM_SEPINT_ACT_HI   BIT(2)
 
 /* function 1 miscellaneous registers */
 
-- 
1.9.1



[PATCH 09/10] brcmfmac: Remove unused macro.

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

This macro is used exactly nowhere in the code. Delete it.

Signed-off-by: Ian Molton 
Reviewed-by: Arend van Spriel 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index b938407..1e1e198 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -159,8 +159,6 @@ struct rte_console {
 /* manfid tuple length, include tuple, link bytes */
 #define SBSDIO_CIS_MANFID_TUPLE_LEN6
 
-#define CORE_BUS_REG(base, field) \
-   (base + offsetof(struct sdpcmd_regs, field))
 #define SD_REG(field) \
(offsetof(struct sdpcmd_regs, field))
 
-- 
1.9.1



[PATCH 00/10] brcmfmac: restructuring sdio access functions - take 2

2017-12-08 Thread Arend van Spriel
Here another series of patches which were originally submitted by
Ian Molton. For some patches I reworded the commit message.

The series is intended for 4.16 and applies to the master branch of
the wireless-drivers-next repository.

Ian Molton (10):
  brcmfmac: Split brcmf_sdiod_buffrw function up.
  brcmfmac: whitespace fixes in brcmf_sdiod_send_buf()
  brcmfmac: Clarify if using braces.
  brcmfmac: Rename / replace old IO functions with simpler ones.
  brcmfmac: Tidy register definitions a little
  brcmfmac: Remove brcmf_sdiod_addrprep()
  brcmfmac: remove unnecessary call to
brcmf_sdiod_set_backplane_window()
  brcmfmac: Cleanup offsetof()
  brcmfmac: Remove unused macro.
  brcmfmac: Remove repeated calls to brcmf_chip_get_core()

 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 313 -
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 248 
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.h|  47 ++--
 3 files changed, 263 insertions(+), 345 deletions(-)

-- 
1.9.1



[PATCH 06/10] brcmfmac: Remove brcmf_sdiod_addrprep()

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

This function has become trivial enough that it may as well be pushed into
its callers, which has the side-benefit of clarifying what's going on.

Remove it, and rename brcmf_sdiod_set_sbaddr_window() to
brcmf_sdiod_set_backplane_window() as it's easier to understand.

Signed-off-by: Ian Molton 
Reviewed-by: Arend van Spriel 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 84 --
 1 file changed, 46 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index e0b201f..5fcd193 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -230,41 +230,25 @@ void brcmf_sdiod_change_state(struct brcmf_sdio_dev 
*sdiodev,
sdiodev->state = state;
 }
 
-static int brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev,
-u32 address)
+static int brcmf_sdiod_set_backplane_window(struct brcmf_sdio_dev *sdiodev,
+   u32 addr)
 {
+   u32 v, bar0 = addr & SBSDIO_SBWINDOW_MASK;
int err = 0, i;
-   u32 addr;
 
-   if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
-   return -ENOMEDIUM;
+   if (bar0 == sdiodev->sbwad)
+   return 0;
 
-   addr = (address & SBSDIO_SBWINDOW_MASK) >> 8;
+   v = bar0 >> 8;
 
-   for (i = 0 ; i < 3 && !err ; i++, addr >>= 8)
+   for (i = 0 ; i < 3 && !err ; i++, v >>= 8)
brcmf_sdiod_writeb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i,
-  addr & 0xff, );
-
-   return err;
-}
-
-static int brcmf_sdiod_addrprep(struct brcmf_sdio_dev *sdiodev, u32 *addr)
-{
-   uint bar0 = *addr & ~SBSDIO_SB_OFT_ADDR_MASK;
-   int err = 0;
-
-   if (bar0 != sdiodev->sbwad) {
-   err = brcmf_sdiod_set_sbaddr_window(sdiodev, bar0);
-   if (err)
-   return err;
+  v & 0xff, );
 
+   if (!err)
sdiodev->sbwad = bar0;
-   }
-
-   *addr &= SBSDIO_SB_OFT_ADDR_MASK;
-   *addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
 
-   return 0;
+   return err;
 }
 
 u32 brcmf_sdiod_readl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
@@ -272,11 +256,16 @@ u32 brcmf_sdiod_readl(struct brcmf_sdio_dev *sdiodev, u32 
addr, int *ret)
u32 data = 0;
int retval;
 
-   retval = brcmf_sdiod_addrprep(sdiodev, );
+   retval = brcmf_sdiod_set_backplane_window(sdiodev, addr);
+   if (retval)
+   goto out;
+
+   addr &= SBSDIO_SB_OFT_ADDR_MASK;
+   addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
 
-   if (!retval)
-   data = sdio_readl(sdiodev->func[1], addr, );
+   data = sdio_readl(sdiodev->func[1], addr, );
 
+out:
if (ret)
*ret = retval;
 
@@ -288,11 +277,16 @@ void brcmf_sdiod_writel(struct brcmf_sdio_dev *sdiodev, 
u32 addr,
 {
int retval;
 
-   retval = brcmf_sdiod_addrprep(sdiodev, );
+   retval = brcmf_sdiod_set_backplane_window(sdiodev, addr);
+   if (retval)
+   goto out;
+
+   addr &= SBSDIO_SB_OFT_ADDR_MASK;
+   addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
 
-   if (!retval)
-   sdio_writel(sdiodev->func[1], data, addr, );
+   sdio_writel(sdiodev->func[1], data, addr, );
 
+out:
if (ret)
*ret = retval;
 }
@@ -540,10 +534,13 @@ int brcmf_sdiod_recv_pkt(struct brcmf_sdio_dev *sdiodev, 
struct sk_buff *pkt)
 
brcmf_dbg(SDIO, "addr = 0x%x, size = %d\n", addr, pkt->len);
 
-   err = brcmf_sdiod_addrprep(sdiodev, );
+   err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
if (err)
goto done;
 
+   addr &= SBSDIO_SB_OFT_ADDR_MASK;
+   addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
+
err = brcmf_sdiod_buff_read(sdiodev, SDIO_FUNC_2, addr, pkt);
 
 done:
@@ -561,10 +558,13 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
brcmf_dbg(SDIO, "addr = 0x%x, size = %d\n",
  addr, pktq->qlen);
 
-   err = brcmf_sdiod_addrprep(sdiodev, );
+   err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
if (err)
goto done;
 
+   addr &= SBSDIO_SB_OFT_ADDR_MASK;
+   addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
+
if (pktq->qlen == 1)
err = brcmf_sdiod_buff_read(sdiodev, SDIO_FUNC_2, addr,
pktq->next);
@@ -606,7 +606,12 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, 
u8 *buf, uint nbytes)
 
memcpy(mypkt->data, buf, nbytes);
 
-   err = brcmf_sdiod_addrprep(sdiodev, );
+   err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
+   

[PATCH 10/10] brcmfmac: Remove repeated calls to brcmf_chip_get_core()

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

There is no need to repeatdly call brcmf_chip_get_core(), which
traverses a list of cores every time its called (including during
register access code!).

Call it once, and store a pointer to the core structure. The existing
code does nto keep track of users of the cores anyway, and even so, this
will allow for easier refcounting in future.

Signed-off-by: Ian Molton 
Reviewed-by: Arend van Spriel 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 25 +-
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 1e1e198..93a1a0c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -436,6 +436,7 @@ struct brcmf_sdio_count {
 struct brcmf_sdio {
struct brcmf_sdio_dev *sdiodev; /* sdio device handler */
struct brcmf_chip *ci;  /* Chip info struct */
+   struct brcmf_core *sdio_core; /* sdio core info struct */
 
u32 hostintmask;/* Copy of Host Interrupt Mask */
atomic_t intstatus; /* Intstatus bits (events) pending */
@@ -665,10 +666,9 @@ static bool data_ok(struct brcmf_sdio *bus)
  */
 static int r_sdreg32(struct brcmf_sdio *bus, u32 *regvar, u32 offset)
 {
-   struct brcmf_core *core;
+   struct brcmf_core *core = bus->sdio_core;
int ret;
 
-   core = brcmf_chip_get_core(bus->ci, BCMA_CORE_SDIO_DEV);
*regvar = brcmf_sdiod_readl(bus->sdiodev, core->base + offset, );
 
return ret;
@@ -676,10 +676,9 @@ static int r_sdreg32(struct brcmf_sdio *bus, u32 *regvar, 
u32 offset)
 
 static int w_sdreg32(struct brcmf_sdio *bus, u32 regval, u32 reg_offset)
 {
-   struct brcmf_core *core;
+   struct brcmf_core *core = bus->sdio_core;
int ret;
 
-   core = brcmf_chip_get_core(bus->ci, BCMA_CORE_SDIO_DEV);
brcmf_sdiod_writel(bus->sdiodev, core->base + reg_offset, regval, );
 
return ret;
@@ -2495,12 +2494,11 @@ static inline void brcmf_sdio_clrintr(struct brcmf_sdio 
*bus)
 
 static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus)
 {
-   struct brcmf_core *buscore;
+   struct brcmf_core *buscore = bus->sdio_core;
u32 addr;
unsigned long val;
int ret;
 
-   buscore = brcmf_chip_get_core(bus->ci, BCMA_CORE_SDIO_DEV);
addr = buscore->base + SD_REG(intstatus);
 
val = brcmf_sdiod_readl(bus->sdiodev, addr, );
@@ -3377,13 +3375,14 @@ static void brcmf_sdio_sr_init(struct brcmf_sdio *bus)
 /* enable KSO bit */
 static int brcmf_sdio_kso_init(struct brcmf_sdio *bus)
 {
+   struct brcmf_core *core = bus->sdio_core;
u8 val;
int err = 0;
 
brcmf_dbg(TRACE, "Enter\n");
 
/* KSO bit added in SDIO core rev 12 */
-   if (brcmf_chip_get_core(bus->ci, BCMA_CORE_SDIO_DEV)->rev < 12)
+   if (core->rev < 12)
return 0;
 
val = brcmf_sdiod_readb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, );
@@ -3412,6 +3411,7 @@ static int brcmf_sdio_bus_preinit(struct device *dev)
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
struct brcmf_sdio *bus = sdiodev->bus;
+   struct brcmf_core *core = bus->sdio_core;
uint pad_size;
u32 value;
int err;
@@ -3420,7 +3420,7 @@ static int brcmf_sdio_bus_preinit(struct device *dev)
 * a device perspective, ie. bus:txglom affects the
 * bus transfers from device to host.
 */
-   if (brcmf_chip_get_core(bus->ci, BCMA_CORE_SDIO_DEV)->rev < 12) {
+   if (core->rev < 12) {
/* for sdio core rev < 12, disable txgloming */
value = 0;
err = brcmf_iovar_data_set(dev, "bus:txglom", ,
@@ -3758,11 +3758,10 @@ static void brcmf_sdio_buscore_activate(void *ctx, 
struct brcmf_chip *chip,
u32 rstvec)
 {
struct brcmf_sdio_dev *sdiodev = ctx;
-   struct brcmf_core *core;
+   struct brcmf_core *core = sdiodev->bus->sdio_core;
u32 reg_addr;
 
/* clear all interrupts */
-   core = brcmf_chip_get_core(chip, BCMA_CORE_SDIO_DEV);
reg_addr = core->base + SD_REG(intstatus);
brcmf_sdiod_writel(sdiodev, reg_addr, 0x, NULL);
 
@@ -3843,6 +3842,12 @@ static void brcmf_sdio_buscore_write32(void *ctx, u32 
addr, u32 val)
bus->ci = NULL;
goto fail;
}
+
+   /* Pick up the SDIO core info struct from chip.c */
+   bus->sdio_core   = brcmf_chip_get_core(bus->ci, BCMA_CORE_SDIO_DEV);
+   if (!bus->sdio_core)
+   goto fail;
+
sdiodev->settings = brcmf_get_module_param(sdiodev->dev,
  

[PATCH 01/10] brcmfmac: Split brcmf_sdiod_buffrw function up.

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

This function needs to be split up into separate read / write variants
for clarity.

Signed-off-by: Ian Molton 
Reviewed-by: Arend van Spriel 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 67 +++---
 1 file changed, 45 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 30ab0aa..d9ecc69 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -414,8 +414,8 @@ void brcmf_sdiod_regwl(struct brcmf_sdio_dev *sdiodev, u32 
addr,
*ret = retval;
 }
 
-static int brcmf_sdiod_buffrw(struct brcmf_sdio_dev *sdiodev, uint fn,
-bool write, u32 addr, struct sk_buff *pkt)
+static int brcmf_sdiod_buff_read(struct brcmf_sdio_dev *sdiodev, uint fn,
+u32 addr, struct sk_buff *pkt)
 {
unsigned int req_sz;
int err;
@@ -424,18 +424,36 @@ static int brcmf_sdiod_buffrw(struct brcmf_sdio_dev 
*sdiodev, uint fn,
req_sz = pkt->len + 3;
req_sz &= (uint)~3;
 
-   if (write)
-   err = sdio_memcpy_toio(sdiodev->func[fn], addr,
-  ((u8 *)(pkt->data)), req_sz);
-   else if (fn == 1)
-   err = sdio_memcpy_fromio(sdiodev->func[fn], ((u8 *)(pkt->data)),
-addr, req_sz);
+   if (fn == 1)
+   err = sdio_memcpy_fromio(sdiodev->func[fn],
+((u8 *)(pkt->data)), addr, req_sz);
else
/* function 2 read is FIFO operation */
-   err = sdio_readsb(sdiodev->func[fn], ((u8 *)(pkt->data)), addr,
- req_sz);
+   err = sdio_readsb(sdiodev->func[fn],
+ ((u8 *)(pkt->data)), addr, req_sz);
+
+   if (err == -ENOMEDIUM)
+   brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
+
+   return err;
+}
+
+static int brcmf_sdiod_buff_write(struct brcmf_sdio_dev *sdiodev, uint fn,
+ u32 addr, struct sk_buff *pkt)
+{
+   unsigned int req_sz;
+   int err;
+
+   /* Single skb use the standard mmc interface */
+   req_sz = pkt->len + 3;
+   req_sz &= (uint)~3;
+
+   err = sdio_memcpy_toio(sdiodev->func[fn], addr,
+  ((u8 *)(pkt->data)), req_sz);
+
if (err == -ENOMEDIUM)
brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
+
return err;
 }
 
@@ -643,7 +661,7 @@ int brcmf_sdiod_recv_pkt(struct brcmf_sdio_dev *sdiodev, 
struct sk_buff *pkt)
if (err)
goto done;
 
-   err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr, pkt);
+   err = brcmf_sdiod_buff_read(sdiodev, SDIO_FUNC_2, addr, pkt);
 
 done:
return err;
@@ -665,14 +683,14 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
goto done;
 
if (pktq->qlen == 1)
-   err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
-pktq->next);
+   err = brcmf_sdiod_buff_read(sdiodev, SDIO_FUNC_2, addr,
+   pktq->next);
else if (!sdiodev->sg_support) {
glom_skb = brcmu_pkt_buf_get_skb(totlen);
if (!glom_skb)
return -ENOMEM;
-   err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
-glom_skb);
+   err = brcmf_sdiod_buff_read(sdiodev, SDIO_FUNC_2, addr,
+   glom_skb);
if (err)
goto done;
 
@@ -707,8 +725,7 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 
*buf, uint nbytes)
err = brcmf_sdiod_addrprep(sdiodev, );
 
if (!err)
-   err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, true, addr,
-mypkt);
+   err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2, addr, mypkt);
 
brcmu_pkt_buf_free_skb(mypkt);
return err;
@@ -730,8 +747,8 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
 
if (pktq->qlen == 1 || !sdiodev->sg_support)
skb_queue_walk(pktq, skb) {
-   err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, true,
-addr, skb);
+   err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2,
+addr, skb);
if (err)
break;
}
@@ 

[PATCH 07/10] brcmfmac: remove unnecessary call to brcmf_sdiod_set_backplane_window()

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

All functions that might require the window address changing call
brcmf_sdiod_set_backplane_window() prior to access. Thus resetting
the window is not required.

Signed-off-by: Ian Molton 
[arend: corrected the driver prefix in the subject]
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 5fcd193..f8b47c1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -723,11 +723,6 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
 
dev_kfree_skb(pkt);
 
-   /* Return the window to backplane enumeration space for core access */
-   if (brcmf_sdiod_set_backplane_window(sdiodev, sdiodev->sbwad))
-   brcmf_err("FAILED to set window back to 0x%x\n",
- sdiodev->sbwad);
-
sdio_release_host(sdiodev->func[1]);
 
return err;
-- 
1.9.1



[PATCH 02/10] brcmfmac: whitespace fixes in brcmf_sdiod_send_buf()

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

Signed-off-by: Ian Molton 
Reviewed-by: Arend van Spriel 
[arend: mention function in patch subject]
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index d9ecc69..bff4610 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -714,6 +714,7 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 
*buf, uint nbytes)
int err;
 
mypkt = brcmu_pkt_buf_get_skb(nbytes);
+
if (!mypkt) {
brcmf_err("brcmu_pkt_buf_get_skb failed: len %d\n",
  nbytes);
@@ -728,8 +729,8 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 
*buf, uint nbytes)
err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2, addr, mypkt);
 
brcmu_pkt_buf_free_skb(mypkt);
-   return err;
 
+   return err;
 }
 
 int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
-- 
1.9.1



[PATCH 03/10] brcmfmac: Clarify if using braces.

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

Whilst this if () statement is technically correct, it lacks clarity.

Signed-off-by: Ian Molton 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index bff4610..17cdc13 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -746,16 +746,17 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
if (err)
return err;
 
-   if (pktq->qlen == 1 || !sdiodev->sg_support)
+   if (pktq->qlen == 1 || !sdiodev->sg_support) {
skb_queue_walk(pktq, skb) {
err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2,
 addr, skb);
if (err)
break;
}
-   else
+   } else {
err = brcmf_sdiod_sglist_rw(sdiodev, SDIO_FUNC_2, true, addr,
pktq);
+   }
 
return err;
 }
-- 
1.9.1



[PATCH 08/10] brcmfmac: Cleanup offsetof()

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

Create a macro to make the code a bit more readable, whilst we're stuck
with using struct element offsets as register offsets.

Signed-off-by: Ian Molton 
Reviewed-by: Arend van Spriel 
[arend: rename macro to SD_REG]
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 35 +-
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 752e0fb..b938407 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -161,6 +161,8 @@ struct rte_console {
 
 #define CORE_BUS_REG(base, field) \
(base + offsetof(struct sdpcmd_regs, field))
+#define SD_REG(field) \
+   (offsetof(struct sdpcmd_regs, field))
 
 /* SDIO function 1 register CHIPCLKCSR */
 /* Force ALP request to backplane */
@@ -1087,12 +1089,10 @@ static u32 brcmf_sdio_hostmail(struct brcmf_sdio *bus)
brcmf_dbg(SDIO, "Enter\n");
 
/* Read mailbox data and ack that we did so */
-   ret = r_sdreg32(bus, _data,
-   offsetof(struct sdpcmd_regs, tohostmailboxdata));
+   ret = r_sdreg32(bus, _data, SD_REG(tohostmailboxdata));
 
if (ret == 0)
-   w_sdreg32(bus, SMB_INT_ACK,
- offsetof(struct sdpcmd_regs, tosbmailbox));
+   w_sdreg32(bus, SMB_INT_ACK, SD_REG(tosbmailbox));
bus->sdcnt.f1regdata += 2;
 
/* dongle indicates the firmware has halted/crashed */
@@ -1207,8 +1207,7 @@ static void brcmf_sdio_rxfail(struct brcmf_sdio *bus, 
bool abort, bool rtx)
 
if (rtx) {
bus->sdcnt.rxrtx++;
-   err = w_sdreg32(bus, SMB_NAK,
-   offsetof(struct sdpcmd_regs, tosbmailbox));
+   err = w_sdreg32(bus, SMB_NAK, SD_REG(tosbmailbox));
 
bus->sdcnt.f1regdata++;
if (err == 0)
@@ -2333,9 +2332,7 @@ static uint brcmf_sdio_sendfromq(struct brcmf_sdio *bus, 
uint maxframes)
if (!bus->intr) {
/* Check device status, signal pending interrupt */
sdio_claim_host(bus->sdiodev->func[1]);
-   ret = r_sdreg32(bus, ,
-   offsetof(struct sdpcmd_regs,
-intstatus));
+   ret = r_sdreg32(bus, , SD_REG(intstatus));
sdio_release_host(bus->sdiodev->func[1]);
bus->sdcnt.f2txdata++;
if (ret != 0)
@@ -2441,7 +2438,7 @@ static void brcmf_sdio_bus_stop(struct device *dev)
brcmf_sdio_bus_sleep(bus, false, false);
 
/* Disable and clear interrupts at the chip level also */
-   w_sdreg32(bus, 0, offsetof(struct sdpcmd_regs, hostintmask));
+   w_sdreg32(bus, 0, SD_REG(hostintmask));
local_hostintmask = bus->hostintmask;
bus->hostintmask = 0;
 
@@ -2460,8 +2457,7 @@ static void brcmf_sdio_bus_stop(struct device *dev)
sdio_disable_func(sdiodev->func[SDIO_FUNC_2]);
 
/* Clear any pending interrupts now that F2 is disabled */
-   w_sdreg32(bus, local_hostintmask,
- offsetof(struct sdpcmd_regs, intstatus));
+   w_sdreg32(bus, local_hostintmask, SD_REG(intstatus));
 
sdio_release_host(sdiodev->func[1]);
}
@@ -2507,7 +2503,7 @@ static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus)
int ret;
 
buscore = brcmf_chip_get_core(bus->ci, BCMA_CORE_SDIO_DEV);
-   addr = buscore->base + offsetof(struct sdpcmd_regs, intstatus);
+   addr = buscore->base + SD_REG(intstatus);
 
val = brcmf_sdiod_readl(bus->sdiodev, addr, );
bus->sdcnt.f1regdata++;
@@ -2584,11 +2580,9 @@ static void brcmf_sdio_dpc(struct brcmf_sdio *bus)
 */
if (intstatus & I_HMB_FC_CHANGE) {
intstatus &= ~I_HMB_FC_CHANGE;
-   err = w_sdreg32(bus, I_HMB_FC_CHANGE,
-   offsetof(struct sdpcmd_regs, intstatus));
+   err = w_sdreg32(bus, I_HMB_FC_CHANGE, SD_REG(intstatus));
 
-   err = r_sdreg32(bus, ,
-   offsetof(struct sdpcmd_regs, intstatus));
+   err = r_sdreg32(bus, , SD_REG(intstatus));
bus->sdcnt.f1regdata += 2;
atomic_set(>fcstate,
   !!(newstatus & (I_HMB_FC_STATE | I_HMB_FC_CHANGE)));
@@ -3771,7 +3765,7 @@ static void brcmf_sdio_buscore_activate(void *ctx, struct 
brcmf_chip *chip,
 
/* clear all interrupts */
core = brcmf_chip_get_core(chip, 

[PATCH 04/10] brcmfmac: Rename / replace old IO functions with simpler ones.

2017-12-08 Thread Arend van Spriel
From: Ian Molton 

Primarily this patch removes:

brcmf_sdiod_f0_writeb()
brcmf_sdiod_reg_write()
brcmf_sdiod_reg_read()

Since we no longer use the quirky method of deciding which function to
address via the address being accessed, take the opportunity to rename
some IO functions more in line with common kernel code. We also convert
those that map directly to sdio_{read,write}*() to macros.

Signed-off-by: Ian Molton 
Reviewed-by: Arend van Spriel 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 169 +++
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 186 ++---
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.h|  28 +++-
 3 files changed, 138 insertions(+), 245 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 17cdc13..608c5f8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -137,27 +137,27 @@ int brcmf_sdiod_intr_register(struct brcmf_sdio_dev 
*sdiodev)
if (sdiodev->bus_if->chip == BRCM_CC_43362_CHIP_ID) {
/* assign GPIO to SDIO core */
addr = CORE_CC_REG(SI_ENUM_BASE, gpiocontrol);
-   gpiocontrol = brcmf_sdiod_regrl(sdiodev, addr, );
+   gpiocontrol = brcmf_sdiod_readl(sdiodev, addr, );
gpiocontrol |= 0x2;
-   brcmf_sdiod_regwl(sdiodev, addr, gpiocontrol, );
+   brcmf_sdiod_writel(sdiodev, addr, gpiocontrol, );
 
-   brcmf_sdiod_regwb(sdiodev, SBSDIO_GPIO_SELECT, 0xf,
- );
-   brcmf_sdiod_regwb(sdiodev, SBSDIO_GPIO_OUT, 0, );
-   brcmf_sdiod_regwb(sdiodev, SBSDIO_GPIO_EN, 0x2, );
+   brcmf_sdiod_writeb(sdiodev, SBSDIO_GPIO_SELECT,
+  0xf, );
+   brcmf_sdiod_writeb(sdiodev, SBSDIO_GPIO_OUT, 0, );
+   brcmf_sdiod_writeb(sdiodev, SBSDIO_GPIO_EN, 0x2, );
}
 
/* must configure SDIO_CCCR_IENx to enable irq */
-   data = brcmf_sdiod_regrb(sdiodev, SDIO_CCCR_IENx, );
+   data = brcmf_sdiod_func0_rb(sdiodev, SDIO_CCCR_IENx, );
data |= 1 << SDIO_FUNC_1 | 1 << SDIO_FUNC_2 | 1;
-   brcmf_sdiod_regwb(sdiodev, SDIO_CCCR_IENx, data, );
+   brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_IENx, data, );
 
/* redirect, configure and enable io for interrupt signal */
data = SDIO_SEPINT_MASK | SDIO_SEPINT_OE;
if (pdata->oob_irq_flags & IRQF_TRIGGER_HIGH)
data |= SDIO_SEPINT_ACT_HI;
-   brcmf_sdiod_regwb(sdiodev, SDIO_CCCR_BRCM_SEPINT, data, );
-
+   brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_BRCM_SEPINT,
+data, );
sdio_release_host(sdiodev->func[1]);
} else {
brcmf_dbg(SDIO, "Entering\n");
@@ -183,8 +183,8 @@ void brcmf_sdiod_intr_unregister(struct brcmf_sdio_dev 
*sdiodev)
 
pdata = >settings->bus.sdio;
sdio_claim_host(sdiodev->func[1]);
-   brcmf_sdiod_regwb(sdiodev, SDIO_CCCR_BRCM_SEPINT, 0, NULL);
-   brcmf_sdiod_regwb(sdiodev, SDIO_CCCR_IENx, 0, NULL);
+   brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_BRCM_SEPINT, 0, NULL);
+   brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_IENx, 0, NULL);
sdio_release_host(sdiodev->func[1]);
 
sdiodev->oob_irq_requested = false;
@@ -242,8 +242,8 @@ static int brcmf_sdiod_set_sbaddr_window(struct 
brcmf_sdio_dev *sdiodev,
addr = (address & SBSDIO_SBWINDOW_MASK) >> 8;
 
for (i = 0 ; i < 3 && !err ; i++, addr >>= 8)
-   brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i,
- addr & 0xff, );
+   brcmf_sdiod_writeb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i,
+  addr & 0xff, );
 
return err;
 }
@@ -267,124 +267,15 @@ static int brcmf_sdiod_addrprep(struct brcmf_sdio_dev 
*sdiodev, u32 *addr)
return 0;
 }
 
-static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, u8 byte,
-   uint regaddr)
-{
-   int err_ret;
-
-   /*
-* Can only directly write to some F0 registers.
-* Handle CCCR_IENx and CCCR_ABORT command
-* as a special case.
-*/
-   if ((regaddr == SDIO_CCCR_ABORT) ||
-   (regaddr == SDIO_CCCR_IENx))
-   sdio_writeb(func, byte, regaddr, _ret);
-   else
-   

[PATCH v2 1/2] dt: bindings: add new dt entry for ath10k calibration variant

2017-12-08 Thread Sven Eckelmann
The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct
board data file on QCA4019 based devices. Multiple different boards share
the same values. Only the original reference designs can currently be
identified and loaded from the board-2.bin. But these will not result in
the correct calibration data when combined with the pre-calibration data
from the device.

An additional "variant" information has to be provided (via SMBIOS or DT)
to select the correct board data for a design which was modified by an ODM.

Signed-off-by: Sven Eckelmann 
---
 Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 74d7f0af209c..3d2a031217da 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -41,6 +41,9 @@ Optional properties:
 - qcom,msi_addr: MSI interrupt address.
 - qcom,msi_base: Base value to add before writing MSI data into
MSI address register.
+- qcom,ath10k-calibration-variant: string to search for in the board-2.bin
+  variant list with the same bus and device
+  specific ids
 - qcom,ath10k-calibration-data : calibration data + board specific data
 as an array, the length can vary between
 hw versions.
-- 
2.11.0



[PATCH v2 2/2] ath10k: search DT for qcom,ath10k-calibration-variant

2017-12-08 Thread Sven Eckelmann
Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified on QCA4019 using bus, bmi-chip-id and
bmi-board-id.

The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.

This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8.
Something similar has to be provided for systems without SMBIOS but with
device trees. No solution was specified by QCA and therefore a new one has
to be found for ath10k.

The device tree requires addition strings to define the variant name

wifi@a00 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};

wifi@a80 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};

This would create the boarddata identifiers for the board-2.bin search

 *  bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U
 *  bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U

Signed-off-by: Sven Eckelmann 
---
 drivers/net/wireless/ath/ath10k/core.c | 40 --
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index b29fdbd21ead..6264e2cc4c0d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -860,6 +860,28 @@ static int ath10k_core_check_smbios(struct ath10k *ar)
return 0;
 }
 
+static int ath10k_core_check_dt(struct ath10k *ar)
+{
+   struct device_node *node;
+   const char *variant = NULL;
+
+   node = ar->dev->of_node;
+   if (!node)
+   return -ENOENT;
+
+   of_property_read_string(node, "qcom,ath10k-calibration-variant",
+   );
+   if (!variant)
+   return -ENODATA;
+
+   if (strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)) < 0)
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant string is longer than the buffer can 
accommodate (variant: %s)\n",
+   variant);
+
+   return 0;
+}
+
 static int ath10k_download_and_run_otp(struct ath10k *ar)
 {
u32 result, address = ar->hw_params.patch_load_addr;
@@ -1231,19 +1253,19 @@ static int ath10k_core_create_board_name(struct ath10k 
*ar, char *name,
/* strlen(',variant=') + strlen(ar->id.bdf_ext) */
char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 };
 
+   if (ar->id.bdf_ext[0] != '\0')
+   scnprintf(variant, sizeof(variant), ",variant=%s",
+ ar->id.bdf_ext);
+
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
- "bus=%s,bmi-chip-id=%d,bmi-board-id=%d",
+ "bus=%s,bmi-chip-id=%d,bmi-board-id=%d%s",
  ath10k_bus_str(ar->hif.bus),
  ar->id.bmi_chip_id,
- ar->id.bmi_board_id);
+ ar->id.bmi_board_id, variant);
goto out;
}
 
-   if (ar->id.bdf_ext[0] != '\0')
-   scnprintf(variant, sizeof(variant), ",variant=%s",
- ar->id.bdf_ext);
-
scnprintf(name, name_len,
  
"bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s",
  ath10k_bus_str(ar->hif.bus),
@@ -2343,7 +2365,11 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 
ret = ath10k_core_check_smbios(ar);
if (ret)
-   ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not set.\n");
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "SMBIOS bdf variant name not 
set.\n");
+
+   ret = ath10k_core_check_dt(ar);
+   if (ret)
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "DT bdf variant name not 
set.\n");
 
ret = ath10k_core_fetch_board_file(ar);
if (ret) {
-- 
2.11.0



Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant

2017-12-08 Thread Kalle Valo
Christian Lamparter  writes:

> On Friday, March 10, 2017 9:06:15 AM CET Sven Eckelmann wrote:
>> Board Data File (BDF) is loaded upon driver boot-up procedure. The right
>> board data file is identified on QCA4019 using bus, bmi-chip-id and
>> bmi-board-id.
>> 
>> The problem, however, can occur when the (default) board data file cannot
>> fulfill with the vendor requirements and it is necessary to use a different
>> board data file.
>> 
>> This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8.
>> Something similar has to be provided for systems without SMBIOS but with
>> device trees. No solution was specified by QCA and therefore a new one has
>> to be found for ath10k.
>> 
>> The device tree requires addition strings to define the variant name
>> 
>> wifi@a00 {
>>  status = "okay";
>>  qcom,ath10k-calibration-variant = "RT-AC58U";
>> };
>> 
>> wifi@a80 {
>>  status = "okay";
>>  qcom,ath10k-calibration-variant = "RT-AC58U";
>> };
>> 
>> This would create the boarddata identifiers for the board-2.bin search
>> 
>>  *  bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U
>>  *  bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U
>> 
>> Signed-off-by: Sven Eckelmann 

[...]

> @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to
> the Asus RT-AC58U?

What do you mean? Add qcom,ath10k-calibration-variant to that board's
device tree or something else?

> I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board 
> files to this mail as well. So, all that needs to be done is to add
> them to the board-2.bin on your codeaurora / ath10k-firmware project.
>
> Kalle: Can you please update the board-2.bin for the IPQ40XX on your
> ath10k-firmware project on github?

Where did you get these board files from?

BTW, it seems lots of people want to add board files so I wrote
instruction how I prefer them submitted:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles

> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin
>
> It looks like this board-2.bin has support for a few more boards.

I checked and that should be in ath10k-firmware.git now:

$ ath10k-bdencoder --diff ../board-2.bin board-2.bin  | tail -1
0 board image(s) added, 0 changed, 0 deleted, 9 in total



-- 
Kalle Valo

[PATCH] wcn36xx: Add hardware scan offload support

2017-12-08 Thread Loic Poulain
Current hw_scan implementation does not trigger offloaded
hardware scan and seems to only put the device in a kind of
listening mode (beacon/probe-response) for software scan.
Since no probe request are generated by the software, current
scanning method is similar to a passive scan.

This patch introduces support for 'true' hardware offloaded scan.
Hardware scan is configured and started via the start-scan-offload
firmware message. Once scan has been completed a scan indicator
message is received from firmware.

Moreover, this patch includes support for directed probe-request,
allowing connection with hidden APs. It also fixes scan issues with
band-steering AP which are not 'visible' with passive scan (due to
hidden ssid in beacons).

Let's keep the 'legacy' scanning method in case scan-offload is not
supported.

Signed-off-by: Loic Poulain 
---
 drivers/net/wireless/ath/wcn36xx/hal.h  | 107 ++--
 drivers/net/wireless/ath/wcn36xx/main.c |  16 -
 drivers/net/wireless/ath/wcn36xx/smd.c  | 120 
 drivers/net/wireless/ath/wcn36xx/smd.h  |   3 +
 4 files changed, 238 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h 
b/drivers/net/wireless/ath/wcn36xx/hal.h
index b765c64..1829635 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -348,6 +348,13 @@ enum wcn36xx_hal_host_msg_type {
WCN36XX_HAL_DHCP_START_IND = 189,
WCN36XX_HAL_DHCP_STOP_IND = 190,
 
+   /* Scan Offload(hw) APIs */
+   WCN36XX_HAL_START_SCAN_OFFLOAD_REQ = 204,
+   WCN36XX_HAL_START_SCAN_OFFLOAD_RSP = 205,
+   WCN36XX_HAL_STOP_SCAN_OFFLOAD_REQ = 206,
+   WCN36XX_HAL_STOP_SCAN_OFFLOAD_RSP = 207,
+   WCN36XX_HAL_SCAN_OFFLOAD_IND = 210,
+
WCN36XX_HAL_AVOID_FREQ_RANGE_IND = 233,
 
WCN36XX_HAL_PRINT_REG_INFO_IND = 259,
@@ -1115,6 +1122,101 @@ struct wcn36xx_hal_finish_scan_rsp_msg {
 
 } __packed;
 
+enum wcn36xx_hal_scan_type {
+   WCN36XX_HAL_SCAN_TYPE_PASSIVE = 0x00,
+   WCN36XX_HAL_SCAN_TYPE_ACTIVE = WCN36XX_HAL_MAX_ENUM_SIZE
+};
+
+struct wcn36xx_hal_mac_ssid {
+   u8 length;
+   u8 ssid[32];
+} __packed;
+
+struct wcn36xx_hal_start_scan_offload_req_msg {
+   struct wcn36xx_hal_msg_header header;
+
+   /* BSSIDs hot list */
+   u8 num_bssid;
+   u8 bssids[4][ETH_ALEN];
+
+   /* Directed probe-requests will be sent for listed SSIDs (max 10)*/
+   u8 num_ssid;
+   struct wcn36xx_hal_mac_ssid ssids[10];
+
+   /* Report AP with hidden ssid */
+   u8 scan_hidden;
+
+   /* Self MAC address */
+   u8 mac[ETH_ALEN];
+
+   /* BSS type */
+   enum wcn36xx_hal_bss_type bss_type;
+
+   /* Scan type */
+   enum wcn36xx_hal_scan_type scan_type;
+
+   /* Minimum scanning time on each channel (ms) */
+   u32 min_ch_time;
+
+   /* Maximum scanning time on each channel */
+   u32 max_ch_time;
+
+   /* Is a p2p search */
+   u8 p2p_search;
+
+   /* Channels to scan */
+   u8 num_channel;
+   u8 channels[80];
+
+   /* IE field */
+   u16 ie_len;
+   u8 ie[0];
+} __packed;
+
+struct wcn36xx_hal_start_scan_offload_rsp_msg {
+   struct wcn36xx_hal_msg_header header;
+
+   /* success or failure */
+   u32 status;
+} __packed;
+
+enum wcn36xx_hal_scan_offload_ind_type {
+   /* Scan has been started */
+   WCN36XX_HAL_SCAN_IND_STARTED = 0x01,
+   /* Scan has been completed */
+   WCN36XX_HAL_SCAN_IND_COMPLETED = 0x02,
+   /* Moved to foreign channel */
+   WCN36XX_HAL_SCAN_IND_FOREIGN_CHANNEL = 0x08,
+   /* scan request has been dequeued */
+   WCN36XX_HAL_SCAN_IND_DEQUEUED = 0x10,
+   /* preempted by other high priority scan */
+   WCN36XX_HAL_SCAN_IND_PREEMPTED = 0x20,
+   /* scan start failed */
+   WCN36XX_HAL_SCAN_IND_FAILED = 0x40,
+/*scan restarted */
+   WCN36XX_HAL_SCAN_IND_RESTARTED = 0x80,
+   WCN36XX_HAL_SCAN_IND_MAX = WCN36XX_HAL_MAX_ENUM_SIZE
+};
+
+struct wcn36xx_hal_scan_offload_ind {
+   struct wcn36xx_hal_msg_header header;
+
+   u32 type;
+   u32 channel_mhz;
+   u32 scan_id;
+} __packed;
+
+struct wcn36xx_hal_stop_scan_offload_req_msg {
+   struct wcn36xx_hal_msg_header header;
+} __packed;
+
+struct wcn36xx_hal_stop_scan_offload_rsp_msg {
+   struct wcn36xx_hal_msg_header header;
+
+   /* success or failure */
+   u32 status;
+} __packed;
+
 enum wcn36xx_hal_rate_index {
HW_RATE_INDEX_1MBPS = 0x82,
HW_RATE_INDEX_2MBPS = 0x84,
@@ -1507,11 +1609,6 @@ struct wcn36xx_hal_edca_param_record {
u16 txop_limit;
 } __packed;
 
-struct wcn36xx_hal_mac_ssid {
-   u8 length;
-   u8 ssid[32];
-} __packed;
-
 /* Concurrency role. These are generic IDs that identify the various roles
  *  in the software system. */
 enum wcn36xx_hal_con_mode {
diff --git 

Re: [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant

2017-12-08 Thread Kalle Valo
Sven Eckelmann  writes:

> Board Data File (BDF) is loaded upon driver boot-up procedure. The right
> board data file is identified on QCA4019 using bus, bmi-chip-id and
> bmi-board-id.
>
> The problem, however, can occur when the (default) board data file cannot
> fulfill with the vendor requirements and it is necessary to use a different
> board data file.
>
> This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8.
> Something similar has to be provided for systems without SMBIOS but with
> device trees. No solution was specified by QCA and therefore a new one has
> to be found for ath10k.
>
> The device tree requires addition strings to define the variant name
>
> wifi@a00 {
>   status = "okay";
>   qcom,ath10k-calibration-variant = "RT-AC58U";
> };
>
> wifi@a80 {
>   status = "okay";
>   qcom,ath10k-calibration-variant = "RT-AC58U";
> };
>
> This would create the boarddata identifiers for the board-2.bin search
>
>  *  bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U
>  *  bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U
>
> Signed-off-by: Sven Eckelmann 
> ---
> Since RFC:
>
>  - initialize variant pointer to have it initialized to NULL when
>of_property_read_string fails (thanks Christian Lamparter)
>  - Only print warning that DT doesn't contain string ones (thanks Christian
>Lamparter)
>  - Split patch in DT doc and ath10k part (thanks Christian Lamparter)
>  - Allow to overwrite the variant string via DT and ignore that SMBIOS had
>written anything to it

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -779,6 +779,25 @@ static int ath10k_core_check_smbios(struct ath10k *ar)
>   return 0;
>  }
>  
> +static int ath10k_core_check_dt(struct ath10k *ar)
> +{
> + struct device_node *node;
> + const char *variant = NULL;
> +
> + node = ar->dev->of_node;
> + if (!node)
> + return -ENOENT;
> +
> + of_property_read_string(node, "qcom,ath10k-calibration-variant",
> + );
> + if (!variant)
> + return -ENODATA;
> +
> + strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext));

Kbuild bot found a warning here:

   drivers/net/wireless/ath/ath10k/core.c: In function 'ath10k_core_check_dt':
>> drivers/net/wireless/ath/ath10k/core.c:877:2: warning: ignoring return value 
>> of 'strscpy', declared with attribute warn_unused_result [-Wunused-result]
 strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext));
 ^~~~

I guess warn_unused_result in strscpy() is a recent addition and that's
why you didn't see it.

-- 
Kalle Valo

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

2017-12-08 Thread Kalle Valo
Hi,

getting back to this old thread, here's the discussion:

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

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

Sven Eckelmann  writes:

> On Dienstag, 21. März 2017 21:56:54 CET Rob Herring wrote:
> [...]
>> Is this always the case? There's never some variation beyond the
>> reference design that a BDF difference can't handle?
>
> I have no knowledge about anything which isn't handled directly by the BDF
> variants. But maybe Kalle can correct me here.

Currently I'm not aware of any extra properties which we would need in
ath10k, having the custom board file seems to be the only requirement I
have seen.

>> > They are basically "qcom,ipq4019-wifi" + a product specific string. The 
>> > first
>> > part is therefore the string which identifies the wifi device(s) in the
>> > QCA4018/4019 SoC. The product specific string is simply the part (or a
>> > variation of it) which would been used before in
>> > "qcom,ath10k-calibration-variant" - just to make it "use a more specific
>> > compatible string".
>> 
>> It would probably be more like: "asus,rt-ac58u-wifi", "qcom,ipq4019-wifi"
>> 
>> A more specific compatible is insurance that at some later point in
>> time you can distinguish between 2 boards due to some difference even
>> if now you believe they are "the same".
> [...]
>> I think the separate property is fine if this is the only one you
>> envision needing to add. If there's 10 more properties, then I'd feel
>> more strongly towards a board specific compatible string.
>
> Thank you. Let's wait a little bit in case someone from QCA/Codeaurora
> has some additional input.

I didn't see any comments from anyone else and I think Sven's approach
here is the best. Sven, can you submit v2 so that we get an ack from
device tree maintainers and I can apply these?

-- 
Kalle Valo