On Wed, Nov 06, 2019 at 03:16:50PM -0800, Jeffrey Hugo wrote:
> When ath10k_qmi_init() fails, the error handling does not free the irq
> resources, which causes an issue if we EPROBE_DEFER as we'll attempt to
> (re-)register irqs which are already registered.
>
> Fixes: ba94c753ccb4 ("ath10k: add
On Wed, Nov 06, 2019 at 03:47:12PM -0800, Jeffrey Hugo wrote:
> When the BDF download QMI message has the end field set to 1, it signals
> the end of the transfer, and triggers the firmware to do a CRC check. The
> BDFs for msm8998 devices fail this check, yet the firmware is happy to
> still use
When working in station mode, after connected to a legacy
AP, 11g only, for example, the tx bitrate is incorrect in
output of command 'iw wlan0 link'.
That's because the legacy tx bitrate value reported by
firmware is not well handled:
For QCA6174, the value represents rate index, but treated
as a
When QCA6174/QCA9377 working in station mode, after connected
to AP, tx bitrate is always '1.0 MBit/s' in output of command
'iw wlan0 link'.
That's because the parameters to calculate the tx bitrate are
not well updated for QCA6174/QCA9377.
To fix this issue:
1. Add processing for HTT_T2H_MSG_TYP
Tx bitrate got by command 'iw wlan0 link' is incorrect.
These 2 patches will fix the issue.
Yu Wang (2):
ath10k: add ppdu stats support for QCA6174/QCA9377
ath10k: correct legacy rate in tx stats
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h |
On Tue, Nov 12, 2019 at 1:42 AM Simon Horman wrote:
>
> On Wed, Nov 06, 2019 at 03:16:50PM -0800, Jeffrey Hugo wrote:
> > When ath10k_qmi_init() fails, the error handling does not free the irq
> > resources, which causes an issue if we EPROBE_DEFER as we'll attempt to
> > (re-)register irqs which
On Tue, Nov 12, 2019 at 2:04 AM Simon Horman wrote:
>
> On Wed, Nov 06, 2019 at 03:47:12PM -0800, Jeffrey Hugo wrote:
> > When the BDF download QMI message has the end field set to 1, it signals
> > the end of the transfer, and triggers the firmware to do a CRC check. The
> > BDFs for msm8998 dev
On 11/12/19 3:45 AM, Yu Wang wrote:
When working in station mode, after connected to a legacy
AP, 11g only, for example, the tx bitrate is incorrect in
output of command 'iw wlan0 link'.
That's because the legacy tx bitrate value reported by
firmware is not well handled:
For QCA6174, the value
On Wed 06 Nov 15:47 PST 2019, Jeffrey Hugo wrote:
> When the BDF download QMI message has the end field set to 1, it signals
> the end of the transfer, and triggers the firmware to do a CRC check. The
> BDFs for msm8998 devices fail this check, yet the firmware is happy to
> still use the BDF. I
From: Ben Greear
[ Upstream commit 833fd34d743c728afe6d127ef7bee67e7d9199a8 ]
The vdev-start-response message should cause the
completion to fire, even in the error case. Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.
Add some warning t
From: Ben Greear
[ Upstream commit 833fd34d743c728afe6d127ef7bee67e7d9199a8 ]
The vdev-start-response message should cause the
completion to fire, even in the error case. Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.
Add some warning t
From: Ben Greear
[ Upstream commit 833fd34d743c728afe6d127ef7bee67e7d9199a8 ]
The vdev-start-response message should cause the
completion to fire, even in the error case. Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.
Add some warning t
From: Ben Greear
[ Upstream commit 833fd34d743c728afe6d127ef7bee67e7d9199a8 ]
The vdev-start-response message should cause the
completion to fire, even in the error case. Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.
Add some warning t
On 2019-11-11 20:23, Kalle Valo wrote:
Wen Gong writes:
On 2019-11-01 15:42, Wen Gong wrote:
On 2019-10-31 17:08, Kalle Valo wrote:
、> I just realised that this is RX path so we should use
ATH10K_SKB_RXCB()
instead. I made the change below to this commit in pending branch:
I will test with
Jeffrey Hugo writes:
> On Tue, Nov 12, 2019 at 1:42 AM Simon Horman
> wrote:
>>
>> On Wed, Nov 06, 2019 at 03:16:50PM -0800, Jeffrey Hugo wrote:
>> > When ath10k_qmi_init() fails, the error handling does not free the irq
>> > resources, which causes an issue if we EPROBE_DEFER as we'll attempt
Jeffrey Hugo writes:
> On Tue, Nov 12, 2019 at 2:04 AM Simon Horman
> wrote:
>>
>> On Wed, Nov 06, 2019 at 03:47:12PM -0800, Jeffrey Hugo wrote:
>> > When the BDF download QMI message has the end field set to 1, it signals
>> > the end of the transfer, and triggers the firmware to do a CRC chec
On Wed, Nov 13, 2019 at 06:58:25AM +0200, Kalle Valo wrote:
> Jeffrey Hugo writes:
>
> > On Tue, Nov 12, 2019 at 2:04 AM Simon Horman
> > wrote:
> >>
> >> On Wed, Nov 06, 2019 at 03:47:12PM -0800, Jeffrey Hugo wrote:
> >> > When the BDF download QMI message has the end field set to 1, it signal
17 matches
Mail list logo
