Commits · b037b107565f329e737ec9ffdb121477a07245b6 · Kirill Smelkov / linux

29 Apr, 2019 13 commits

ath9k: Differentiate between max combined and per chain power · b037b107

Sven Eckelmann authored Mar 20, 2019

The ath9k driver uses as maximum allowed txpower the constant
MAX_RATE_POWER. It is used to set a maximum txpower limit for the PHY
(which is combined txpower) and also the maximum txpower for per chain
rates. Its value 63 is derived from the maximum number the registers can
store for the per chain txpower.

The max txpower a user can set because of this is 31 dBm (floor(63 / 2)).
This also means that a device with multiple tx chains is even limited
further:

* 1 chain:  31 dBm per chain
* 2 chains: 28 dBm per chain
* 3 chains: 26 dBm per chain

This combined txpower limit of 31 dBm becomes even more problematic when
some extra antenna gain is set in the EEPROM. A high power device is then
no longer able to reach its potential limits.

Instead the code dealing with the combined txpower must use a higher limit
than 63 and only the code dealing with the per chain txpower have to use
the limit of 63. Since the antenna gain can be quite large and 8 bit
variables are often used in ath9k for txpower, a large, divisible by two
number like 254 is a good choice for this new limit.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

b037b107

ath9k: Check for errors when reading SREV register · 2f90c7e5

Tim Schumacher authored Mar 18, 2019

Right now, if an error is encountered during the SREV register
read (i.e. an EIO in ath9k_regread()), that error code gets
passed all the way to __ath9k_hw_init(), where it is visible
during the "Chip rev not supported" message.

    ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
    ath: phy2: Mac Chip Rev 0x0f.3 is not supported by this driver
    ath: phy2: Unable to initialize hardware; initialization status: -95
    ath: phy2: Unable to initialize hardware; initialization status: -95
    ath9k_htc: Failed to initialize the device

Check for -EIO explicitly in ath9k_hw_read_revisions() and return
a boolean based on the success of the operation. Check for that in
__ath9k_hw_init() and abort with a more debugging-friendly message
if reading the revisions wasn't successful.

    ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
    ath: phy2: Failed to read SREV register
    ath: phy2: Could not read hardware revision
    ath: phy2: Unable to initialize hardware; initialization status: -95
    ath: phy2: Unable to initialize hardware; initialization status: -95
    ath9k_htc: Failed to initialize the device

This helps when debugging by directly showing the first point of
failure and it could prevent possible errors if a 0x0f.3 revision
is ever supported.
Signed-off-by: Tim Schumacher <timschumi@gmx.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

2f90c7e5

ath9k: Don't trust TX status TID number when reporting airtime · 389b72e5

Toke Høiland-Jørgensen authored Mar 07, 2019

As already noted a comment in ath_tx_complete_aggr(), the hardware will
occasionally send a TX status with the wrong tid number. If we trust the
value, airtime usage will be reported to the wrong AC, which can cause the
deficit on that AC to become very low, blocking subsequent attempts to
transmit.

To fix this, account airtime usage to the TID number from the original skb,
instead of the one in the hardware TX status report.
Reported-by: Miguel Catalan Cid <miguel.catalan@i2cat.net>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

389b72e5

ath6kl: remove redundant check of status != 0 · e643da21

Colin Ian King authored Apr 04, 2019

The check on status not being zero is redundant as previous code
paths that set status to an error value break out of the while
loop and hence status is never non-zero at the check. Remove
this redundant code.

Addresses-Coverity: ("Logically dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

e643da21

ath6kl: add some bounds checking · 5d6751ea

Dan Carpenter authored Apr 04, 2019

The "ev->traffic_class" and "reply->ac" variables come from the network
and they're used as an offset into the wmi->stream_exist_for_ac[] array.
Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[]
array only has WMM_NUM_AC (4) elements. We need to add a couple bounds
checks to prevent array overflows.

I also modified one existing check from "if (traffic_class > 3) {" to
"if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent.

Fixes: bdcd8170 (" Add ath6kl cleaned up driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

5d6751ea

ath6kl: wmi: use struct_size() helper · 83d9562b

Gustavo A. R. Silva authored Apr 03, 2019

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.

So, replace code of the following form:

sizeof(*ev) + ev->num_neighbors * sizeof(struct wmi_neighbor_info)

with:

struct_size(ev, neighbor, ev->num_neighbors)

This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

83d9562b

ath6kl: debug: Use struct_size() helper · df75786b

Gustavo A. R. Silva authored Apr 03, 2019

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.

So, change the following form:

sizeof(*tbl) + num_entries * sizeof(struct wmi_bss_roam_info)

 to :

struct_size(tbl, info, num_entries)

This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

df75786b

ath10k: fix incorrect multicast/broadcast rate setting · 93ee3d10

Pradeep kumar Chitrapu authored Apr 23, 2019

Invalid rate code is sent to firmware when multicast rate value of 0 is
sent to driver indicating disabled case, causing broken mesh path.
so fix that.

Tested on QCA9984 with firmware 10.4-3.6.1-00827

Sven tested on IPQ4019 with 10.4-3.5.3-00057 and QCA9888 with 10.4-3.5.3-00053
(ath10k-firmware) and 10.4-3.6-00140 (linux-firmware 2018-12-16-211de167).

Fixes: cd93b83a ("ath10k: support for multicast rate control")
Co-developed-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Tested-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>