* Re: [08/11] ath10k_sdio: common read write
From: Gary Bisson @ 2017-12-08 14:42 UTC (permalink / raw)
To: Alagu Sankar; +Cc: silexcommon, linux-wireless, ath10k
In-Reply-To: <e9eb78a9e0ed5e1a3acf48af88d02119@silex-india.com>
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, silexcommon@gmail.com wrote:
> > > From: Alagu Sankar <alagusankar@silex-india.com>
> > >
> > > 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 <alagusankar@silex-india.com>
> > > ---
> > > 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, &ret);
> > > + *buf = cpu_to_le32(val);
> > > +
> > > + ret = ath10k_sdio_write(ar, addr, &val, 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
^ permalink raw reply
* pull-request: wireless-drivers 2017-12-08
From: Kalle Valo @ 2017-12-08 14:32 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
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
^ permalink raw reply
* iwl3945: regression at 4.15-rc1 was Re: 4.15.0-rc1-next-20171201: WARNING: .... at net/mac80211/agg-tx.c:315
From: Pavel Machek @ 2017-12-08 14:29 UTC (permalink / raw)
To: Kalle Valo, sgruszka; +Cc: kernel list, johannes.berg, linville, linux-wireless
In-Reply-To: <874lp5jwge.fsf@purkki.adurom.net>
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
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 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
> > [ 1.026281] iwl3945 0000:03:00.0: Tunable channels: 11 802.11bg, 13 802.11a channels
> > [ 1.026287] iwl3945 0000: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: 00000000 EBX: f5c19000 ECX: f5eff670 EDX: f5eff040
[ 530.816438] ESI: 0000000f EDI: 00000003 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: 000006b0
[ 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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal
From: Sven Eckelmann @ 2017-12-08 13:40 UTC (permalink / raw)
To: akolli; +Cc: akolli, ath10k, linux-wireless
In-Reply-To: <637ab47b1794b409e595b7e219cd904f@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]
On Freitag, 8. Dezember 2017 18:05:38 CET akolli@codeaurora.org wrote:
> On 2017-12-08 17:42, Sven Eckelmann wrote:
> > On Donnerstag, 25. Mai 2017 16:21:23 CET akolli@qti.qualcomm.com wrote:
> >> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
> >>
> >> 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 0000:01:00.0: qca9984/qca9994 hw1.0
> > target 0x01000000 chip_id 0x00000000 sub 168c:cafe
> > [ 71.732926] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> > tracing 0 dfs 1 testmode 1
> > [ 71.752282] ath10k_pci 0000:01:00.0: firmware ver
> > 10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32
> > 7198d117
> > [ 73.805730] ath10k_pci 0000:01:00.0: unable to read from the
> > device
> > [ 73.805769] ath10k_pci 0000: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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 2/2] ath10k: Populate RSC counter to firmware
From: Govind Singh @ 2017-12-08 13:32 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, 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 <govinds@qti.qualcomm.com>
---
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(&arvif->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(&cmd->key_rsc_counter, &arg->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
^ permalink raw reply related
* [PATCH 1/2] mac80211: Populate RSC counter in set_key method
From: Govind Singh @ 2017-12-08 13:32 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, 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 <govinds@qti.qualcomm.com>
---
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 & 0xffff))
#define TKIP_PN_TO_IV32(pn) ((u32)((pn >> 16) & 0xffffffff))
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(&key->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(&key->conf.rx_pn, seq, seq_len);
return key;
}
--
1.9.1
^ permalink raw reply related
* Re: [v2] wireless: use ARRAY_SIZE
From: Kalle Valo @ 2017-12-08 13:20 UTC (permalink / raw)
To: Jérémy Lefaure
Cc: linux-wireless, Andy Shevchenko, Jérémy Lefaure
In-Reply-To: <20171114031941.22105-1-jeremy.lefaure@lse.epita.fr>
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 <jeremy.lefaure@lse.epita.fr>
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
^ permalink raw reply
* Re: iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports
From: Kalle Valo @ 2017-12-08 13:04 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <20171208125259.21401-1-luca@coelho.fi>
Luciano Coelho <luca@coelho.fi> wrote:
> From: Luca Coelho <luciano.coelho@intel.com>
>
> 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 <luciano.coelho@intel.com>
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
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2017-12-05
From: Kalle Valo @ 2017-12-08 13:01 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, linuxwifi, david.e.box, janet.morgan, joe.konno
In-Reply-To: <1512501020.4827.197.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> 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
^ permalink raw reply
* Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped
From: Kalle Valo @ 2017-12-08 12:56 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Sara Sharon
In-Reply-To: <1512736519.4827.287.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> On Fri, 2017-12-08 at 14:26 +0200, Kalle Valo wrote:
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>> > Luca Coelho <luca@coelho.fi> 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
^ permalink raw reply
* [PATCH] iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports
From: Luca Coelho @ 2017-12-08 12:52 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Luca Coelho
From: Luca Coelho <luciano.coelho@intel.com>
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 <luciano.coelho@intel.com>
---
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
^ permalink raw reply related
* Re: [PATCH v2 06/15] iwlwifi: mvm: rs: add ops for the new rate scaling in the FW
From: Luciano Coelho @ 2017-12-08 12:40 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Gregory Greenman
In-Reply-To: <87374ls8bt.fsf@kamboji.qca.qualcomm.com>
On Fri, 2017-12-08 at 14:38 +0200, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
> > From: Gregory Greenman <gregory.greenman@intel.com>
> >
> > 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 <gregory.greenman@intel.com>
> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>
> [...]
>
> > +void iwl_mvm_rs_add_sta(struct iwl_mvm *mvm, struct iwl_mvm_sta
> > *mvmsta)
> > +{
> > + struct iwl_lq_sta_rs_fw *lq_sta = &mvmsta->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.
^ permalink raw reply
* Re: [PATCH v2 06/15] iwlwifi: mvm: rs: add ops for the new rate scaling in the FW
From: Kalle Valo @ 2017-12-08 12:38 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Gregory Greenman, Luca Coelho
In-Reply-To: <20171202213603.12512-1-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> From: Gregory Greenman <gregory.greenman@intel.com>
>
> 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 <gregory.greenman@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
[...]
> +void iwl_mvm_rs_add_sta(struct iwl_mvm *mvm, struct iwl_mvm_sta *mvmsta)
> +{
> + struct iwl_lq_sta_rs_fw *lq_sta = &mvmsta->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
^ permalink raw reply
* Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal
From: akolli @ 2017-12-08 12:35 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: akolli, ath10k, linux-wireless, linux-wireless-owner
In-Reply-To: <6476910.M9FJQ0px1r@bentobox>
On 2017-12-08 17:42, Sven Eckelmann wrote:
> On Donnerstag, 25. Mai 2017 16:21:23 CET akolli@qti.qualcomm.com wrote:
>> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>>
>> 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 0000:01:00.0: failed to fetch board file: -2
>> [ 15.741474] ath10k_pci 0000: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 0x10000
>> Board id 0x10 0x8000
>>
>> Tested on QCA9888 with pre-cal file.
>>
>> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
>> ---
>> 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 0000:01:00.0: qca9984/qca9994 hw1.0
> target 0x01000000 chip_id 0x00000000 sub 168c:cafe
> [ 71.732926] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 71.752282] ath10k_pci 0000:01:00.0: firmware ver
> 10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32
> 7198d117
> [ 73.805730] ath10k_pci 0000:01:00.0: unable to read from the
> device
> [ 73.805769] ath10k_pci 0000: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.
^ permalink raw reply
* Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped
From: Luca Coelho @ 2017-12-08 12:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Sara Sharon
In-Reply-To: <87vahhflsf.fsf@purkki.adurom.net>
On Fri, 2017-12-08 at 14:26 +0200, Kalle Valo wrote:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
> > Luca Coelho <luca@coelho.fi> 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.
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
From: Kalle Valo @ 2017-12-08 12:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Wireless, Linux-Next Mailing List, Linux Kernel Mailing List,
Ihab Zhaika, Luca Coelho
In-Reply-To: <20171208120034.499e1a65@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> 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
^ permalink raw reply
* Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped
From: Luca Coelho @ 2017-12-08 12:28 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Sara Sharon
In-Reply-To: <87efo5s93p.fsf@kamboji.qca.qualcomm.com>
On Fri, 2017-12-08 at 14:22 +0200, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> 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.
^ permalink raw reply
* Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped
From: Kalle Valo @ 2017-12-08 12:26 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Sara Sharon
In-Reply-To: <87efo5s93p.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Luca Coelho <luca@coelho.fi> 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
^ permalink raw reply
* Re: [PATCH 6/6] iwlwifi: fix access to prph when transport is stopped
From: Kalle Valo @ 2017-12-08 12:22 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Sara Sharon
In-Reply-To: <1511951353.4827.27.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> 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
^ permalink raw reply
* Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal
From: Sven Eckelmann @ 2017-12-08 12:12 UTC (permalink / raw)
To: akolli; +Cc: ath10k, linux-wireless, akolli
In-Reply-To: <1495709483-29793-1-git-send-email-akolli@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
On Donnerstag, 25. Mai 2017 16:21:23 CET akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> 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 0000:01:00.0: failed to fetch board file: -2
> [ 15.741474] ath10k_pci 0000: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 0x10000
> Board id 0x10 0x8000
>
> Tested on QCA9888 with pre-cal file.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
> ---
> 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 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 71.732926] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
[ 71.752282] ath10k_pci 0000:01:00.0: firmware ver 10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32 7198d117
[ 73.805730] ath10k_pci 0000:01:00.0: unable to read from the device
[ 73.805769] ath10k_pci 0000: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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 07/10] brcmfmac: remove unnecessary call to brcmf_sdiod_set_backplane_window()
From: Arend van Spriel @ 2017-12-08 12:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1512735035-342-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
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 <ian@mnementh.co.uk>
[arend: corrected the driver prefix in the subject]
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
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
^ permalink raw reply related
* [PATCH 06/10] brcmfmac: Remove brcmf_sdiod_addrprep()
From: Arend van Spriel @ 2017-12-08 12:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1512735035-342-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
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 <ian@mnementh.co.uk>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../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, &err);
-
- 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, &err);
+ 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, &addr);
+ 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, &retval);
+ data = sdio_readl(sdiodev->func[1], addr, &retval);
+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, &addr);
+ 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, &retval);
+ sdio_writel(sdiodev->func[1], data, addr, &retval);
+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, &addr);
+ 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, &addr);
+ 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, &addr);
+ err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
+ if (err)
+ return err;
+
+ addr &= SBSDIO_SB_OFT_ADDR_MASK;
+ addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
if (!err)
err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2, addr, mypkt);
@@ -625,10 +630,13 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
brcmf_dbg(SDIO, "addr = 0x%x, size = %d\n", addr, pktq->qlen);
- err = brcmf_sdiod_addrprep(sdiodev, &addr);
+ err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
if (err)
return err;
+ addr &= SBSDIO_SB_OFT_ADDR_MASK;
+ addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
+
if (pktq->qlen == 1 || !sdiodev->sg_support) {
skb_queue_walk(pktq, skb) {
err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2,
@@ -673,7 +681,7 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
/* Do the transfer(s) */
while (size) {
/* Set the backplane window to include the start address */
- err = brcmf_sdiod_set_sbaddr_window(sdiodev, address);
+ err = brcmf_sdiod_set_backplane_window(sdiodev, address);
if (err)
break;
@@ -716,7 +724,7 @@ 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_sbaddr_window(sdiodev, sdiodev->sbwad))
+ if (brcmf_sdiod_set_backplane_window(sdiodev, sdiodev->sbwad))
brcmf_err("FAILED to set window back to 0x%x\n",
sdiodev->sbwad);
--
1.9.1
^ permalink raw reply related
* [PATCH 09/10] brcmfmac: Remove unused macro.
From: Arend van Spriel @ 2017-12-08 12:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1512735035-342-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
This macro is used exactly nowhere in the code. Delete it.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
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_LEN 6
-#define CORE_BUS_REG(base, field) \
- (base + offsetof(struct sdpcmd_regs, field))
#define SD_REG(field) \
(offsetof(struct sdpcmd_regs, field))
--
1.9.1
^ permalink raw reply related
* [PATCH 02/10] brcmfmac: whitespace fixes in brcmf_sdiod_send_buf()
From: Arend van Spriel @ 2017-12-08 12:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1512735035-342-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
[arend: mention function in patch subject]
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
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
^ permalink raw reply related
* [PATCH 10/10] brcmfmac: Remove repeated calls to brcmf_chip_get_core()
From: Arend van Spriel @ 2017-12-08 12:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1512735035-342-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
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 <ian@mnementh.co.uk>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../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, &ret);
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, &ret);
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, &ret);
@@ -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, &err);
@@ -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", &value,
@@ -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, 0xFFFFFFFF, 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,
BRCMF_BUSTYPE_SDIO,
bus->ci->chip,
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox