Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 22 Aug 2019 10:20:10 +0200
>
> The dev_kfree_skb() function performs also input parameter validation.
> Thus the test around the shown calls is not needed.
>
> This issue was detected by using the Coccinelle software.
>
>
Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 22 Aug 2019 10:20:10 +0200
>
> The dev_kfree_skb() function performs also input parameter validation.
> Thus the test around the shown calls is not needed.
>
> This issue was detected by using the Coccinelle software.
>
>
Fuqian Huang wrote:
> In commit 518a2f1925c3
> ("dma-mapping: zero memory returned from dma_alloc_*"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
>
> Signed-off-by: Fuqian Huang
Patch applied to wireless-drivers-next.git, thanks.
52d4261862ec wireless:
Fuqian Huang wrote:
> In commit 518a2f1925c3
> ("dma-mapping: zero memory returned from dma_alloc_*"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
>
> Signed-off-by: Fuqian Huang
Patch applied to wireless-drivers-next.git, thanks.
52d4261862ec wireless:
Hi Kalle,
Thanks for the help and tips. Will do that if I need to submit again.
I believe Toke will integrate this with his version and move the
estimating pending airtime part to mac80211, so maybe in the next
version, ath10k change is no longer required.
Thanks,
Kan
On Mon, Oct 14, 2019 at
> -Original Message-
> From: ath10k On Behalf Of Wen Gong
> Sent: Thursday, September 26, 2019 10:33 AM
> To: kv...@codeaurora.org
> Cc: linux-wirel...@vger.kernel.org; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH v5 0/8] ath10k: improve throughout of tcp/udp
> TX/RX of sdio
>
v6: remove module parameters disable_tx_comp and alt_data
this is 3 patches of the 7 patches from ath10k: improve throughout of tcp/udp
TX/RX of sdio
v5: change ath10k_htc_setup_tx_req to add check bundle_tx
to forbidden init 2 times
v4: add macro ATH10K_HTC_MSG_READY_EXT_ALT_DATA_MASK
v3:
The transmission utilization ratio for sdio bus for small packet is
slow, because the space and time cost for sdio bus is same for large
length packet and small length packet. So the speed of data for large
length packet is higher than small length.
Test result of different length of data:
data
For sdio chip, it is high latency bus, all the TX packet's content will
be tranferred from HOST memory to firmware memory via sdio bus, then it
need much more memory in firmware than low latency bus chip, for low
latency chip, such as PCI-E, it only need to transfer the TX descriptor
via PCI-E bus
For tcp RX, the quantity of tcp acks to remote is 1/2 of the quantity
of tcp data from remote, then it will have many small length packets
on TX path of sdio bus, then it reduce the RX packets's bandwidth of
tcp.
This patch enable napi on RX path, then the RX packet of tcp will not
feed to tcp
10.4 has additional 64 bit cycle counters. see wmi_pdev_bss_chan_info_event
the standard 32 cycle counters do individual wrap around as far as i know
Am 14.10.2019 um 09:07 schrieb Sven Eckelmann:
On Monday, 14 October 2019 00:15:20 CEST Sebastian Gottschall wrote:
i checked your patch on
Kan Yan writes:
> Calculate the estimated airtime pending in the txqs and apply AQL to
> prevent excessive amounts of packets being queued in the firmware queue.
>
> Signed-off-by: Kan Yan
Forgot to mention earlier that please add tested hardware and firmware
versions:
Kalle Valo writes:
> Kan Yan writes:
>
>> This patch series implements Airtime-based Queue Limit (AQL) in the
>> mac80211 and Ath10k driver. It is based on an earlier version from
>> the ChromiumOS tree[0].
>>
>> This version has been tested with QCA9884 platform with 4.14 kernel.
>> Tests show
Kan Yan writes:
> This patch series implements Airtime-based Queue Limit (AQL) in the mac80211
> and Ath10k driver. It is based on an earlier version from the ChromiumOS
> tree[0].
>
> This version has been tested with QCA9884 platform with 4.14 kernel. Tests
> show AQL is able to reduce
Sven Eckelmann writes:
> On Monday, 14 October 2019 00:15:20 CEST Sebastian Gottschall wrote:
>> i checked your patch on 10.4 based chipsets with 9984. the values are
>> now looking bogus and wrong at all. busy and active time time in ms does
>> increase in hours each second
>> the problem
+ linux-wireless
Patrick Steinhardt writes:
> Starting with v5.3.0, it was observed that throughput of an access point
> with QCA988x-based wireless chip is severely degraded from at least
> 10MB/s to roughly 200KB/s. A bisect of the issue points to commit
> 4504f0e5b571 (ath10k: sdio:
Bjorn Andersson wrote:
> The return value of dma_map_single() should be checked for errors using
> dma_mapping_error() and the skb has been dequeued so it needs to be
> freed.
>
> This was found when enabling CONFIG_DMA_API_DEBUG and it warned about the
> missing dma_mapping_error() call.
>
>
Bjorn Andersson wrote:
> The return value of dma_map_single() should be checked for errors using
> dma_mapping_error() and the skb has been dequeued so it needs to be
> freed.
>
> This was found when enabling CONFIG_DMA_API_DEBUG and it warned about the
> missing dma_mapping_error() call.
>
>
Tomislav Požega wrote:
> Regulatory rule defines in regd.c are used not only by ath9k but also
> ath10k driver (haven't test other drivers) and thus should be
> renamed from ATH9K* to ATH*.
>
> Signed-off-by: Tomislav Požega
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of
Tomislav Požega wrote:
> Regulatory rule defines in regd.c are used not only by ath9k but also
> ath10k driver (haven't test other drivers) and thus should be
> renamed from ATH9K* to ATH*.
>
> Signed-off-by: Tomislav Požega
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of
Miaoqing Pan wrote:
> If firmware reports rate_max > WMI_TPC_RATE_MAX(WMI_TPC_FINAL_RATE_MAX)
> or num_tx_chain > WMI_TPC_TX_N_CHAIN, it will cause array out-of-bounds
> access, so print a warning and reset to avoid memory corruption.
>
> Tested HW: QCA9984
> Tested FW: 10.4-3.9.0.2-00035
>
>
Miaoqing Pan wrote:
> If firmware reports rate_max > WMI_TPC_RATE_MAX(WMI_TPC_FINAL_RATE_MAX)
> or num_tx_chain > WMI_TPC_TX_N_CHAIN, it will cause array out-of-bounds
> access, so print a warning and reset to avoid memory corruption.
>
> Tested HW: QCA9984
> Tested FW: 10.4-3.9.0.2-00035
>
>
Bjorn Andersson writes:
> On Fri 11 Oct 04:57 PDT 2019, Kalle Valo wrote:
>
>> Bjorn Andersson wrote:
>>
>> > The return value of dma_map_single() should be checked for errors using
>> > dma_mapping_error(), rather than testing for NULL. Correct this.
>> >
>> > Fixes: 1807da49733e ("ath10k:
On Monday, 14 October 2019 00:15:20 CEST Sebastian Gottschall wrote:
> i checked your patch on 10.4 based chipsets with 9984. the values are
> now looking bogus and wrong at all. busy and active time time in ms does
> increase in hours each second
> the problem seem to be that your patch is
24 matches
Mail list logo
