Re: [PATCH] ath10k: poll HTT send completion when CE 5 is unused
> > commit a70587b3389a ("ath10k: configure copy engine 5 for HTT messages")
> > moved send completion polling under HTT Rx (CE 5) service routine. For
> > QCA6174 based devices copy engine 1 (CE 1) is used for HTT Rx instead
> > of CE 5. So send completion never be called. This is causing "failed to
> > transmit packet, dropping: -105" errors. Fix this by processing send
> > completion from CE 1 service routine instead of CE 5.
> >
> > Tested-by: Ryan Hsu
> > Signed-off-by: Rajkumar Manoharan
>
> Applied to ath-current, thanks. I had a trivial conflict, please review
> carefully my changes:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=ath-current&id=6419fdbb6f90e147690f8833cba59d289d613da5
>
Looks good. Thanks for fixing conflicts.
-Rajkumar--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] ath10k: Fix deadlock when peer cannot be created.
> On Monday, May 9, 2016 10:49 PM, gree...@candelatech.com wrote: >> On 04/01/2016 02:12 PM, gree...@candelatech.com wrote: >> From: Ben Greear >> >> We must not attempt to send WMI packets while holding the data-lock, >> as it may deadlock: >> >> BUG: sleeping function called from invalid context at >> drivers/net/wireless/ath/ath10k/wmi.c:1824 >> in_atomic(): 1, irqs_disabled(): 0, pid: 2878, name: wpa_supplicant >> > Kalle: I notice these 5 patches are not in the latest wireless-testing. > > Are they not acceptable, or??? > Aah!.. I recently cooked up similar patch for BUG_ON issue. I think this one is stable candidate. no? -Rajkumar-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On Thursday, June 2, 2016 8:51 PM, Ben Greear wrote:
> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
>> Kalle Valo writes:
>>
>>> there's a regression in ath10k:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>>>
>>> Reporter bisected it to this:
>>>
>>> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
>>> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
>>> Author: Rajkumar Manoharan
>>> Date: Tue Mar 22 17:22:19 2016 +0530
>>>
>>> ath10k: combine txrx and replenish task
>>>
>>> Since tx completion and rx indication processing are moved out
>>> of txrx tasklet and rx ring lock contention also removed from txrx
>>> for rx_ind messages, it would be efficient to combine both replenish
>>> and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
>>> (low and high end systems). With this adjustment in AP135, TCP DL is
>>> improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
>>> to 803 Mbps. Also no watchdog are observed on UDP BiDi.
>>>
>>> Signed-off-by: Rajkumar Manoharan
>>> Signed-off-by: Kalle Valo
>>
>> Adding Mike, the bug reporter.
>
Mike,
Sorry for the regression. Since the patch combines both txrx and replenish
tasklet,
it is validated in low end embedded devices like AP135 (single core 720 MHz
MIPS processor).
It seems yours is octa core processor. So CPU is not bottleneck here. Need
your help to fix this issue asap.
Can you please try reducing rx refill threshold as below.
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 2aa407160859..d35d3d48ae6c 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1734,7 +1734,7 @@ struct htt_rx_desc {
/* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
* aggregated traffic more nicely. */
-#define ATH10K_HTT_MAX_NUM_REFILL 100
+#define ATH10K_HTT_MAX_NUM_REFILL 16
>From your log attachment from bug report, I found few timed out messages.
May 30 21:09:26 axion kernel: wlan0: deauthenticating from a0:63:91:a7:3c:9f by
local choice (Reason: 3=DEAUTH_LEAVING)
May 30 21:09:32 axion kernel: ath10k_pci :3c:00.0: failed to flush transmit
queue (skip 0 ar-state 1): 0
May 30 21:09:35 axion kernel: ath10k_pci :3c:00.0: failed to delete peer
a0:63:91:a7:3c:9f for vdev 0: -110
May 30 21:09:35 axion kernel: ath10k_pci :3c:00.0: found sta peer
a0:63:91:a7:3c:9f entry on vdev 0 after it was supposed
Try disabling pci power save for qca6174 as below.
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 852f2c18cd11..5e3ba37a8c6a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2979,7 +2979,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
case QCA6164_2_1_DEVICE_ID:
case QCA6174_2_1_DEVICE_ID:
hw_rev = ATH10K_HW_QCA6174;
- pci_ps = true;
+ pci_ps = false;
pci_soft_reset = ath10k_pci_warm_reset;
pci_hard_reset = ath10k_pci_qca6174_chip_reset;
>
> I found a lot of problems with this code as well, and the 5 patches
> starting from the URL below fixed the issues for me.
>
Ben,
Can you please explain the sort of issues you have observed with this change?
-Rajkumar--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath10k + iw set bitrates is causing FW crash
>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>
>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>> no crash is observed but it still uses MCS9.
>>
>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>
>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>> the mac80211 rates?
>>
>
Thanks for reporting the issue. Could you please try with below change?
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5e1cc8f4c43c..cfa7e01a6103 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
return ret;
}
+ if (vif->type != NL80211_IFTYPE_ADHOC)
+ peer_arg.peer_reassoc = reassoc;
+
ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
if (ret) {
ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i:
%d\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath10k + iw set bitrates is causing FW crash
I think security failures are due to peer unmap & map upon reassoc. Can you
please try below change?
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5e1cc8f4c43c..f7f04bb46fc8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct
*wk)
sta->addr, smps, err);
}
- if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
- changed & IEEE80211_RC_NSS_CHANGED) {
+ if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
+ changed & IEEE80211_RC_NSS_CHANGED) &&
+ (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp
rates/nss\n",
sta->addr);
-Rajkumar
From: Krishna Chaitanya
Sent: Friday, July 8, 2016 5:26 PM
To: Manoharan, Rajkumar
Cc: linux-wireless; ath10k
Subject: Re: ath10k + iw set bitrates is causing FW crash
On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
wrote:
>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>
>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>> no crash is observed but it still uses MCS9.
>>>
>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>
>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>> the mac80211 rates?
>>>
>>
> Thanks for reporting the issue. Could you please try with below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..cfa7e01a6103 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> return ret;
> }
>
> + if (vif->type != NL80211_IFTYPE_ADHOC)
> + peer_arg.peer_reassoc = reassoc;
> +
> ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
> if (ret) {
> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev
> %i: %d\n",
Thanks Raj, with this fix the rates are 0-7, if i disable then i am
seeing 0-9, so its
working.
But i am seeing a weird issues, the moment i give bitrates command,
ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
interface up/down
it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath10k + iw set bitrates is causing FW crash
[...] > >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am > >> seeing 0-9, so its > >> working. > >> > >> But i am seeing a weird issues, the moment i give bitrates command, > >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after > >> interface up/down > >> it doesn't work. >> After reboot i dont see the "unencrypted" packet issue, i will do >> some more testing on limiting the rates, currently in my setup its >> not reaching MCS9 so cannot verify now. > Rajkumar, > > I am still not able to make mcs9 work, so i have tried to change the Nss to 1 > using iw, but that is not taking affect. This command is not taking effect. > you mean not able to fix VHT rates alone. am i right? By auto rate mode, is firmware selecting mcs9? What is the command used for fixing vht rate? -Rajkumar-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
> from my point of view this patch is just shit. it trunkates the maximum
> allocated memory to a certain value.
> so firmware requests 800 kb memory but just gets 256kb. so out of bound
> memory access is guaranteed at all.
>
Even with current logic, If the memory chunk allocation fails for bigger size,
then it tries
to allocate smaller chunks. So anyway it is guaranteed for oob access. no?
while (!vaddr && num_units) {
pool_size = num_units * round_up(unit_len, 4);
if (!pool_size)
return -EINVAL;
vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
if (!vaddr)
num_units /= 2;
}
Actually the commit "ath10k: do not use coherent memory for allocated device
memory chunks"
is causing system hang on non VT/d x86 platform. Better to revert the commit
until it is properly
root caused
-Rajkumar
Am 23.07.2016 um 00:43 schrieb Ben Greear:
> On 06/13/2016 11:17 PM, Rajkumar Manoharan wrote:
>> commit b057886524be ("ath10k: do not use coherent memory for allocated
>> device memory chunks") replaced coherent memory allocation for memory
>> chunks to fix low memory platforms. Unfortunately this is causing system
>> freeze on x86 platform while bringing up qca99x0 device. The system
>> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
>> this by limiting maximum memory chunk size to 256 KiB per request.
>>
>> Cc: Felix Fietkau
>> Fixes: b057886524be ("ath10k: do not use coherent memory for
>> allocated device memory chunks")
>> Signed-off-by: Rajkumar Manoharan
>> ---
>> drivers/net/wireless/ath/ath10k/wmi.c | 6 ++
>> drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
>> b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 6279ab4a760e..7c15f65fe5ed 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct
>> ath10k *ar, u32 req_id,
>> if (!pool_size)
>> return -EINVAL;
>>
>> +if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
>> +num_units = WMI_MAX_MEM_CHUNK_SIZE /
>> +round_up(unit_len, 4);
>> +pool_size = num_units * round_up(unit_len, 4);
>> +}
>
> I started testing my 9980 x86-64 system with VT/d enabled today.
> With this patch in my tree, it crashes on bootup (with my firmware).
> Works fine without this patch.
>
> I don't see the exact place it is crashing in the firmware, though I
> could
> probably narrow it down with some effort. It is in the early startup
> code,
> at least, which makes debugging more difficult.
>
> This patch works fine with a slightly newer firmware compiled for
> 9984. That
> same firmware compiled for 9980 crashes, but I am not certain it is
> the same issue
> as the older 9980. It appears similar, at least.
>
> Looks to me like there are lots of variances in how firmware and chip
> revisions
> deal with this particular code, so we are going to have to test on
> lots of chips
> and platforms to know if a 'fix' is really a fix or not.
>
> Thanks,
> Ben
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c > b/drivers/net/wireless/ath/ath10k/mac.c > index 916119c..d96c06e 100644 > --- a/drivers/net/wireless/ath/ath10k/mac.c > +++ b/drivers/net/wireless/ath/ath10k/mac.c > @@ -4307,8 +4307,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar) > int max; > int loop_max = 2000; > > - spin_lock_bh(&ar->txqs_lock); > rcu_read_lock(); > + spin_lock_bh(&ar->txqs_lock); > Ben, It is quite possible that push_pending can be preempted after acquiring rcu_lock which may lead to deadlock. no? I assume to prevent that spin_lock is taken first. Could you please explain how this reordering is fixing dead lock? -Rajkumar
Re: [PATCH] ath10k: ensure pdev sta kickout threshold is set.
[...]
> +int ath10k_mac_set_pdev_kickout(struct ath10k *ar)
> +{
> + u32 param = ar->wmi.pdev_param->sta_kickout_th;
> + int rv;
> +
> + rv = ath10k_wmi_pdev_set_param(ar, param,
> + ar->sta_xretry_kickout_thresh);
> + if (rv) {
> + ath10k_warn(ar, "failed to set sta kickout threshold to %d:
> %d\n",
> + ar->sta_xretry_kickout_thresh, rv);
> + }
> + return rv;
> +}
>
Ben,
I plan to get rid of setting station kickout threshold from host. Each firmware
revision (i.e qca988x, qca99x0, ipq4019) follows different logic based on hw
capability for station kickout and follows different default paramters. So
configuring common threshold will affect firmware logic. Better to get rid of
these configuration from host driver and let firmware to work with default
parameters.
Also I could not find out sta_xretry_kickout_thresh definition in upstream
driver. Have you posted any changes for the same?
-Rajkumar
Re: [PATCH 0/7] ath10k: add copy engine fast path support
> > Below patchset adds fast path support for uplink traffic by bypassing > > HTC layer processing. This is enabled by making use of unused copy > > engine 5 to receive HTT messages directly from HIF layer. From initial > > validation in VHT80/5G mode TCP UL is improved to 900Mbps from ~840Mbps > > in conducted test. > > > > -Rajkumar > > > > Rajkumar Manoharan (7): > > ath10k: export htc tx rx handlers > > ath10k: register per copy engine send completion callbacks > > ath10k: register per copy engine receive callbacks > > ath10k: export htt tx rx handlers > > ath10k: Configure copy engine 5 for HTT messages > > ath10k: remove unused dl_is_polled > > ath10k: remove htc polling for tx completion > > With these patches I'm seeing a DMA warning every time with qca988x > during firmware boot (tested three out of three times, rebooted after > every test): > > [ 60.458260] [ cut here ] > [ 60.458374] WARNING: CPU: 1 PID: 0 at lib/dma-debug.c:1090 > check_unmap+0x815/0x940() > [ 60.458457] ath10k_pci :02:00.0: DMA-API: device driver tries to free > an invalid DMA memory address > [ 60.458557] Modules linked in: ath10k_pci ath10k_core ath mac80211 > cfg80211 [last unloaded: cfg80211] > [ 60.458941] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.3.0-rc3-wl-ath+ > #1082 > [ 60.458981] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS > 68CDD Ver. F.04 01/27/2010 Thanks for reporting this issue. Will post revised patchset asap. -Rajkumar-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ath10k firmware crashes in mesh mode on QCA9880
> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT > encryption and it still crashes. I suspect this means wpa_supplicant is > setting up > the interface incorrectly and/or transmitting a malformed packet that is > causing > the driver to crash. > Ben, IIRC mesh support was validated in qca988x in VHT mode while ago. Either it could be regression in driver/fw or lede mac80211 package. 1) Could you please try plain backports in lede w/o applying ath10k patches. I do see 160MHz support in LEDE. 2) There are some peer stats dump from your earlier log. Disable peer stats by "peer_stats" debugfs. 3) Please confirm the behavior with older firmware revisions. 4) use iw to bring up open mesh to rule out wpa_s config -Rajkumar
Re: [PATCH 1/4] ath10k: remove supported chain mask
>>> Removing supported chainmask fields as it can be always derived >>> from num_rf_chains. >>> >>> Signed-off-by: Rajkumar Manoharan >> > Hello, > > This one break monitor mode for qca988x and 10.x firmware: > After Revert "ath10k: remove supported chain mask" - works correctly. > Janusz, Thanks for reporting. Will send out patch asap. -Rajkumar-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ath10k: remove supported chain mask
Removing supported chainmask fields as it can be always derived
from num_rf_chains.
Signed-off-by: Rajkumar Manoharan
>>>
>> Hello,
>>
>> This one break monitor mode for qca988x and 10.x firmware:
>> After Revert "ath10k: remove supported chain mask" - works correctly.
>>
>Janusz,
>
> Thanks for reporting. Will send out patch asap.
>
Janusz,
It seems the change ("ath10k: remove supported chain mask") just exposed an
hidden problem. The same target assert can be reproduced by below sequence
even after reverting the commit.
ifconfig wlan0 down
iw wlan0 set type monitor
iw phy0 set antenna 7
ifconfig wlan0 up
The actual cause of target assert is below commit.
commit 5572a95b4b5768187652a346356e39e7542ca6e0
Author: Ben Greear
Date: Mon Nov 24 16:22:10 2014 +0200
ath10k: apply chainmask settings to vdev on creation
Configuring NSS vdev param on interface addition is causing the target assert
in 10.1 firmware.
Just creating monitor interface is causing assert with qca_main firmware.
-Rajkumar--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] ath10k: speedup htt rx descriptor processing for tx completion
[...]
>
>> @@ -1712,7 +1710,20 @@ static void ath10k_htt_rx_frm_tx_compl(struct ath10k
>> *ar,
>> for (i = 0; i < resp->data_tx_completion.num_msdus; i++) {
>> msdu_id = resp->data_tx_completion.msdus[i];
>> tx_done.msdu_id = __le16_to_cpu(msdu_id);
>> - ath10k_txrx_tx_unref(htt, &tx_done);
>> +
>> + /* kfifo_put: In practice firmware shouldn't fire off per-CE
>> + * interrupt and main interrupt (MSI/-X range case) for the
>> same
>> + * HTC service so it should be safe to use kfifo_put w/o lock.
>> + *
>> + * From kfifo_put() documentation:
>> + * Note that with only one concurrent reader and one
>> concurrent
>> + * writer, you don't need extra locking to use these macro.
>> + */
>> + if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
>> + ath10k_warn(ar, "txdone fifo overrun, msdu_id %d
>> status %d\n",
>> + tx_done.msdu_id, tx_done.status);
>> + ath10k_txrx_tx_unref(htt, &tx_done);
>> + }
>
> I see two new warnings on the kfifo_put() call:
>
> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast to non-scalar
> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast from
> non-scalar
>
> But I suspect they are false warnings due to my old compiler:
>
> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
>
> Opinions?
>
Hmm... I am not sure why older compiler is not complaining this. Unfortunately
both x86 and cross compiler are not throwing any warnings though :(
gcc version 5.3.0 (GCC)
Target: x86_64-unknown-linux-gnu
gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r47724)
Target: arm-openwrt-linux-uclibcgnueabi
Any suggestions welcome.
-Rajkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] ath10k: speedup htt rx descriptor processing for tx completion
[...] >> >> I see two new warnings on the kfifo_put() call: >> >> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast to non-scalar >> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast from >> non-scalar >> >> But I suspect they are false warnings due to my old compiler: >> >> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 >> >> Opinions? >> > Hmm... I am not sure why older compiler is not complaining this. Unfortunately > both x86 and cross compiler are not throwing any warnings though :( > older/latest/g-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/8] ath10k: ath10k: add support to send delba
> Subject: [PATCH 8/8] ath10k: ath10k: add support to send delba > > This per-station debugfs entry helps to send delba in manual mode > for debugging purpose. It accepts tid, initiator and reason code > as inputs. Kalle, Subject needs small correction (ath10k: ath10k:). Do you want me send v2 patch for this change? Sorry for the inconvenience. -Rajkumar-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
