Hi,
The support for this device was added a while ago to OpenWrt. This AP requires
two special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s
would clash with one of the IPQ401X AP-DK boards because QCA doesn't provide
special IDs for customers and seems to use the AP-DK
On Wed, Sep 18, 2019 at 04:41:54PM +0300, Kalle Valo wrote:
> Bob Copeland writes:
> > - on A, changed the global tx power limit to 1 dBm
> > -> result: signal level dropped to ~ -95 dBm
> >
> > Reading the description above, now I'm wondering if the txpower is
> > max(sta-power,global-power)?
On 17/09/2019, Kalle Valo wrote:
> Christian Lamparter wrote:
>
>> This patch restores the old behavior that read
>> the chip_id on the QCA988x before resetting the
>> chip. This needs to be done in this order since
>> the unsupported QCA988x AR1A chips fall off the
>> bus when resetted.
Brian Norris writes:
> Since Wen has once again suggested I use this patch in other forums,
> I'll ping here to note:
>
> On Wed, Nov 14, 2018 at 2:59 PM Brian Norris wrote:
>> You've introduced a regression in 4.20-rc1:
>
> This regression still survives in the latest tree. Is it fair to just
Abhishek Ambure wrote:
> PKT log enable command expects pdev id in enable params which is missing
> in current configuration. Fill pdev id in pkt log enable wmi command for
> correct configuration.
>
> Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
> Tested HW: WCN3990
> Tested FW:
Abhishek Ambure wrote:
> PKT log enable command expects pdev id in enable params which is missing
> in current configuration. Fill pdev id in pkt log enable wmi command for
> correct configuration.
>
> Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
> Tested HW: WCN3990
> Tested FW:
Bob Copeland writes:
> On Fri, Mar 29, 2019 at 04:19:47PM +0530, Balaji Pothunoori wrote:
>> From: Ashok Raj Nagarajan
>>
>> This patch will add the support to control the transmit power for traffic
>> to a station associated with the AP.
>>
>> Underlying firmware will enforce that the
On Wednesday, 18 September 2019 15:07:11 CEST Sven Eckelmann wrote:
[...]
> I have now prepared a test patch [1] to get the data every 10 seconds. This
> was a compromise between having useful information over time and the
> overflowing problem.
...over time without too many "bss channel
On Wednesday, 18 September 2019 14:58:46 CEST Ben Greear wrote:
[...]
> > So as Ben Greear said, the 10.4 firmware version is fixed and 10.2.* (for
> > the wave-1 cards) is still broken and we need a QCA firmware engineer to
> > fix it. Or to work around it by polling every couple of seconds and
>
On 09/18/2019 01:46 AM, Sven Eckelmann wrote:
On Tuesday, 17 September 2019 19:27:50 CEST Sven Eckelmann wrote:
[...]
So whatever the firmware does when it gets a
WMI_BSS_SURVEY_REQ_TYPE_READ_CLEAR - it is not a CLEAR after read. And they
also don't simply wrap around but there all values
From: Sven Eckelmann
The survey counters from firmwares like 10.2.4 are not actually using the
full 64 bit. Instead, they only use the lower 31 bit and overflow ever
14-30s. The driver must frequently fetch the survey data and add it to the
survey data storage to avoid this problem and to
From: Sven Eckelmann
Hi,
it was observed that ath9k provides accumulated survey counters but ath10k
neither provides deltas nor accumulated counters. Instead it returns
some value which was returned at some point from the firmware.
But as it turns out, this data is not reliable. To make it
From: Sven Eckelmann
The survey report is expected to contain a counter which is increasing all
the time. But ath10k reports some kind of delta. This can either be the
difference to the last get_survey or the difference to some even older
get_survey because the values are sometimes cached and
Yibo Zhao writes:
> On 2019-09-18 05:10, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> In a loop txqs dequeue scenario, if the first txq in the rbtree gets
>>> removed from rbtree immediately in the ieee80211_return_txq(), the
>>> loop will break soon in the ieee80211_next_txq()
On 2019-09-18 17:59, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
Not long after the start of multi-clients test, not a single station
is
an eligible candidate for transmission since global virtual time(g_vt)
is
smaller than the virtual airtime(s_vt) of all the stations. As a
result,
On 2019-09-18 05:10, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
In a loop txqs dequeue scenario, if the first txq in the rbtree gets
removed from rbtree immediately in the ieee80211_return_txq(), the
loop will break soon in the ieee80211_next_txq() due to schedule_pos
not leading to the
On 2019-09-18 18:16, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
On 2019-09-18 05:12, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
On 2019-09-16 23:27, Johannes Berg wrote:
Without really looking at the code -
If station is ineligible for transmission in
On 2019-09-18 05:24, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
Global airtime weight sum is updated only when txq is added/removed
from rbtree. If upper layer configures sta weight during high load,
airtime weight sum will not be updated since txq is most likely on the
tree. It could a
Yibo Zhao writes:
> On 2019-09-18 05:12, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-09-16 23:27, Johannes Berg wrote:
Without really looking at the code -
> If station is ineligible for transmission in
> ieee80211_txq_may_transmit(),
> no packet
From: Toke Høiland-Jørgensen
This switches the airtime scheduler in mac80211 to use a virtual time-based
scheduler instead of the round-robin scheduler used before. This has a
couple of advantages:
- No need to sync up the round-robin scheduler in firmware/hardware with
the round-robin
Not long after the start of multi-clients test, not a single station is
an eligible candidate for transmission since global virtual time(g_vt) is
smaller than the virtual airtime(s_vt) of all the stations. As a result,
the Tx has been blocked and throughput is quite low.
This may mainly due to
In a loop txqs dequeue scenario, if the first txq in the rbtree gets
removed from rbtree immediately in the ieee80211_return_txq(), the
loop will break soon in the ieee80211_next_txq() due to schedule_pos
not leading to the second txq in the rbtree. Thus, defering the
removal right before the end
On Tuesday, 17 September 2019 19:27:50 CEST Sven Eckelmann wrote:
[...]
> So whatever the firmware does when it gets a
> WMI_BSS_SURVEY_REQ_TYPE_READ_CLEAR - it is not a CLEAR after read. And they
> also don't simply wrap around but there all values have to get some kind of
> "fix" like the
23 matches
Mail list logo
