> -Original Message-
> From: Petr Mladek
> Sent: Saturday, 13 April 2019 12:04 AM
> To: Alastair D'Silva
> Cc: alast...@d-silva.org; Jani Nikula ;
Joonas
> Lahtinen ; Rodrigo Vivi
> ; David Airlie ; Daniel Vetter
> ; Karsten Keil ; Jassi Brar
> ; Tom Lendacky ;
> David S. Miller ; Jose Ab
> -Original Message-
> From: Petr Mladek
> Sent: Friday, 12 April 2019 11:48 PM
> To: Alastair D'Silva
> Cc: alast...@d-silva.org; Jani Nikula ;
Joonas
> Lahtinen ; Rodrigo Vivi
> ; David Airlie ; Daniel Vetter
> ; Karsten Keil ; Jassi Brar
> ; Tom Lendacky ;
> David S. Miller ; Jose Abre
> -Original Message-
> From: Petr Mladek
> Sent: Saturday, 13 April 2019 12:12 AM
> To: Alastair D'Silva
> Cc: alast...@d-silva.org; Jani Nikula ;
Joonas
> Lahtinen ; Rodrigo Vivi
> ; David Airlie ; Daniel Vetter
> ; Karsten Keil ; Jassi Brar
> ; Tom Lendacky ;
> David S. Miller ; Jose Ab
On 10/04/2019 04:17, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
> d
On Wed 2019-04-10 13:17:19, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
>
On Wed 2019-04-10 13:17:18, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Some buffers may only be partially filled with useful data, while the rest
> is padded (typically with 0x00 or 0xff).
>
> This patch introduces flags which allow lines of padding bytes to be
> suppressed, making the
On Wed 2019-04-10 13:17:17, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> With modern high resolution screens, we can display more data, which makes
> life a bit easier when debugging.
I have quite some doubts about this feature.
We are talking about more than 256 characters per-line. I
With SDIO there's a use after free after a data frame is transfered, call stack
below. This happens because ath10k_htt_tx_hl() directly transmits the skb
provided by mac80211 using ath10k_htc_send(), all other HTT functions use
separate skb created with ath10k_htc_alloc_skb() to transmit the HTC pa
From: Alagu Sankar
HTT High Latency (ATH10K_DEV_TYPE_HL) does not use txdone_fifo at all, we don't
even initialise it by skipping ath10k_htt_tx_alloc_buf() in
ath10k_htt_tx_start(). Because of this using QCA6174 SDIO
ath10k_htt_rx_tx_compl_ind() will crash when it accesses unitialised
txdone_fifo
From: Alagu Sankar
Transmit completion for SDIO is similar to PCIe, modify the high
latency path to allow SDIO modules to use the msdu id.
kvalo: the original patch from Alagu enabled this only for SDIO but I'm not
sure should we also enable this with USB. I'll use bus params to enable this
for
From: Wen Gong
Disabling interrupts this early meant WMI communication was not working anymore
when the SDIO device was removed. But we call ath10k_core_unregister() that
will eventually call ath10k_sdio_hif_stop(), which disables the interrupts. So
there's actually no need to disable interrupts
This way we don't need to set every variable and give them to default, which is
zero. This is also safer in case we forgot to initalise a new field in some of
the bus modules.
Compile tested only.
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/ahb.c |2 +-
drivers/net/wirele
From: Wen Gong
On QCA6174 SDIO devices the SDIO interrupt will fail if UART is
disabled from ath10k. SDIO firmware enables UART printouts by
default. If ath10k will try to enable UART again the firmware
will configure it's GPIO line incorrectly and SDIO interrupts
won't work anymore. The workarou
Erik Stromdahl writes:
> This patch fixes a bug with padding of the skb data buffer.
> Since skb_trim can only be used to reduce the skb len, it is useless when
> we pad (increase the length of) the skb. Instead we must set skb->len
> directly.
>
> Signed-off-by: Erik Stromdahl
> ---
> drivers/
Erik Stromdahl writes:
> From: Alagu Sankar
>
> The existing implementation of initiating multiple sdio transfers for
> receive bundling is slowing down the receive speed.
>
> Instead of having one sdio transfer for each packet in the bundle, we
> read all packets in one sdio transfer.
>
> This
Erik Stromdahl writes:
> From: Alagu Sankar
>
> HTC header carries junk values that may be interpreted by the firmware
> differently. Enable credit update only if flow control is enabled for
> the corresponding endpoint.
>
> PLL clock setting sequence does not mask the PLL_CONTROL
> register val
Erik Stromdahl writes:
> This series adds a few more fixes for SDIO and high latency devices.
>
> I have had these on my private tree for quite some time now so they
> should be considered fairly well tested.
>
> 4 out of 6 patches are from Alagu Sankar at Silex.
> I have made some adjustments to
On 2019-04-09 04:01, Johannes Berg wrote:
On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
I understand your concern. Yes, I am using high end AP for throughput
test. I'd say 1.2 Gbps is not the worst case since we can achieve max
1.4Gbps according to our test. AFAIK, for most throughput cas
Am 11.04.2019 um 23:34 schrieb Carlito Nueno:
It was working before. All I did was restart the router and then crash happened.
Also who do I check if boarddata is correct or reload boarddata?
this can be just checked by analysing the content of the flash memory.
its normally located at the en
When test simulate firmware crash, it is easy to trigger error.
command:
echo soft > /sys/kernel/debug/ieee80211/phyxx/ath10k/simulate_fw_crash.
If input more than two times continuously, then it will have error.
Error message:
ath10k_pci :02:00.0: failed to set vdev 1 RX wake policy: -108
ath
20 matches
Mail list logo
