Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 6月, 2019 8 次提交
  3. 31 5月, 2019 5 次提交
  5. 30 5月, 2019 2 次提交
  7. 28 5月, 2019 5 次提交
    • Y
      rtw88: Make some symbols static · 6aca0977
      由 YueHaibing 提交于 
      Fix sparse warnings:

drivers/net/wireless/realtek/rtw88/phy.c:851:4: warning: symbol 'rtw_cck_size' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/phy.c:852:4: warning: symbol 'rtw_ofdm_size' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/phy.c:853:4: warning: symbol 'rtw_ht_1s_size' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/phy.c:854:4: warning: symbol 'rtw_ht_2s_size' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/phy.c:855:4: warning: symbol 'rtw_vht_1s_size' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/phy.c:856:4: warning: symbol 'rtw_vht_2s_size' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/fw.c:11:6: warning: symbol 'rtw_fw_c2h_cmd_handle_ext' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/fw.c:50:6: warning: symbol 'rtw_fw_send_h2c_command' was not declared. Should it be static?
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      6aca0977
    • S
      rtw88: avoid circular locking between local->iflist_mtx and rtwdev->mutex · 5b0efb4d
      由 Stanislaw Gruszka 提交于 
      Remove circular lock dependency by using atomic version of interfaces
iterate in watch_dog_work(), hence avoid taking local->iflist_mtx
(rtw_vif_watch_dog_iter() only update some data, it can be called from
atomic context). Fixes below LOCKDEP warning:

[ 1157.219415] ======================================================
[ 1157.225772] [ INFO: possible circular locking dependency detected ]
[ 1157.232150] 3.10.0-1043.el7.sgruszka1.x86_64.debug #1 Not tainted
[ 1157.238346] -------------------------------------------------------
[ 1157.244635] kworker/u4:2/14490 is trying to acquire lock:
[ 1157.250194]  (&rtwdev->mutex){+.+.+.}, at: [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88]
[ 1157.259151]
but task is already holding lock:
[ 1157.265085]  (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211]
[ 1157.276169]
which lock already depends on the new lock.

[ 1157.284488]
the existing dependency chain (in reverse order) is:
[ 1157.292101]
-> #2 (&local->iflist_mtx){+.+...}:
[ 1157.296919]        [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0
[ 1157.302955]        [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410
[ 1157.309416]        [<ffffffffc0b6038f>] ieee80211_iterate_interfaces+0x2f/0x60 [mac80211]
[ 1157.317730]        [<ffffffffc09811ab>] rtw_watch_dog_work+0xcb/0x130 [rtw88]
[ 1157.325003]        [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720
[ 1157.331481]        [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0
[ 1157.337589]        [<ffffffffbc6e107f>] kthread+0xef/0x100
[ 1157.343260]        [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39
[ 1157.350091]
-> #1 ((&(&rtwdev->watch_dog_work)->work)){+.+...}:
[ 1157.356314]        [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0
[ 1157.362427]        [<ffffffffbc6d570b>] flush_work+0x5b/0x310
[ 1157.368287]        [<ffffffffbc6d740e>] __cancel_work_timer+0xae/0x170
[ 1157.374940]        [<ffffffffbc6d7583>] cancel_delayed_work_sync+0x13/0x20
[ 1157.381930]        [<ffffffffc0982b49>] rtw_core_stop+0x29/0x50 [rtw88]
[ 1157.388679]        [<ffffffffc098bee6>] rtw_enter_ips+0x16/0x20 [rtw88]
[ 1157.395428]        [<ffffffffc0983242>] rtw_ops_config+0x42/0x90 [rtw88]
[ 1157.402173]        [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211]
[ 1157.409854]        [<ffffffffc0b3925b>] ieee80211_do_open+0x69b/0x9c0 [mac80211]
[ 1157.417418]        [<ffffffffc0b395e9>] ieee80211_open+0x69/0x70 [mac80211]
[ 1157.424496]        [<ffffffffbcd03442>] __dev_open+0xe2/0x160
[ 1157.430356]        [<ffffffffbcd03773>] __dev_change_flags+0xa3/0x180
[ 1157.436922]        [<ffffffffbcd03879>] dev_change_flags+0x29/0x60
[ 1157.443224]        [<ffffffffbcda14c4>] devinet_ioctl+0x794/0x890
[ 1157.449331]        [<ffffffffbcda27b5>] inet_ioctl+0x75/0xa0
[ 1157.455087]        [<ffffffffbccd54eb>] sock_do_ioctl+0x2b/0x60
[ 1157.461178]        [<ffffffffbccd5753>] sock_ioctl+0x233/0x310
[ 1157.467109]        [<ffffffffbc8bd820>] do_vfs_ioctl+0x410/0x6c0
[ 1157.473233]        [<ffffffffbc8bdb71>] SyS_ioctl+0xa1/0xc0
[ 1157.478914]        [<ffffffffbce84a5e>] system_call_fastpath+0x25/0x2a
[ 1157.485569]
-> #0 (&rtwdev->mutex){+.+.+.}:
[ 1157.490022]        [<ffffffffbc7409d1>] __lock_acquire+0xec1/0x1630
[ 1157.496305]        [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0
[ 1157.502413]        [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410
[ 1157.508890]        [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88]
[ 1157.515724]        [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211]
[ 1157.523370]        [<ffffffffc0b8a4ca>] ieee80211_recalc_ps.part.27+0x9a/0x180 [mac80211]
[ 1157.531685]        [<ffffffffc0b8abc5>] ieee80211_mgd_probe_ap.part.28+0x115/0x160 [mac80211]
[ 1157.540353]        [<ffffffffc0b8b40d>] ieee80211_beacon_connection_loss_work+0x4d/0x80 [mac80211]
[ 1157.549513]        [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720
[ 1157.555886]        [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0
[ 1157.562170]        [<ffffffffbc6e107f>] kthread+0xef/0x100
[ 1157.567765]        [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39
[ 1157.574579]
other info that might help us debug this:

[ 1157.582788] Chain exists of:
  &rtwdev->mutex --> (&(&rtwdev->watch_dog_work)->work) --> &local->iflist_mtx

[ 1157.593024]  Possible unsafe locking scenario:

[ 1157.599046]        CPU0                    CPU1
[ 1157.603653]        ----                    ----
[ 1157.608258]   lock(&local->iflist_mtx);
[ 1157.612180]                                lock((&(&rtwdev->watch_dog_work)->work));
[ 1157.620074]                                lock(&local->iflist_mtx);
[ 1157.626555]   lock(&rtwdev->mutex);
[ 1157.630124]
 *** DEADLOCK ***

[ 1157.636148] 4 locks held by kworker/u4:2/14490:
[ 1157.640755]  #0:  (%s#6){.+.+.+}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720
[ 1157.648965]  #1:  ((&ifmgd->beacon_connection_loss_work)){+.+.+.}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720
[ 1157.659950]  #2:  (&wdev->mtx){+.+.+.}, at: [<ffffffffc0b8aad5>] ieee80211_mgd_probe_ap.part.28+0x25/0x160 [mac80211]
[ 1157.670901]  #3:  (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211]
[ 1157.682466]

Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      5b0efb4d
    • N
      rsi: Properly initialize data in rsi_sdio_ta_reset · f57b5d85
      由 Nathan Chancellor 提交于 
      When building with -Wuninitialized, Clang warns:

drivers/net/wireless/rsi/rsi_91x_sdio.c:940:43: warning: variable 'data'
is uninitialized when used here [-Wuninitialized]
        put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
                                                 ^~~~
drivers/net/wireless/rsi/rsi_91x_sdio.c:930:10: note: initialize the
variable 'data' to silence this warning
        u8 *data;
                ^
                 = NULL
1 warning generated.

Using Clang's suggestion of initializing data to NULL wouldn't work out
because data will be dereferenced by put_unaligned_le32. Use kzalloc to
properly initialize data, which matches a couple of other places in this
driver.

Fixes: e5a1ecc9 ("rsi: add firmware loading for 9116 device")
Link: https://github.com/ClangBuiltLinux/linux/issues/464Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      f57b5d85
    • Y
      rtw88: fix unassigned rssi_level in rtw_sta_info · a24bad74
      由 Yan-Hsuan Chuang 提交于 
      The new rssi_level should be stored in si, otherwise the rssi_level will
never be updated and get a wrong RA mask, which is calculated by the
rssi level

If a wrong RA mask is chosen, the firmware will pick some *bad rates*.
The most hurtful scene will be in *noisy environment*, such as office or
public area with many APs and users.
The latency would be high and the overall throughput would be only half
or less.

Tested in 2.4G in office area, with this patch the throughput increased
from such as "1x Mbps -> 4x Mbps".
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      a24bad74
    • S
      rtw88: fix subscript above array bounds compiler warning · 8a03447d
      由 Stanislaw Gruszka 提交于 
      My compiler complains about:

drivers/net/wireless/realtek/rtw88/phy.c: In function ‘rtw_phy_rf_power_2_rssi’:
drivers/net/wireless/realtek/rtw88/phy.c:430:26: warning: array subscript is above array bounds [-Warray-bounds]
  linear = db_invert_table[i][j];

According to comment power_db should be in range 1 ~ 96 .
To fix add check for boundaries before access the array.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      8a03447d
  9. 24 5月, 2019 2 次提交
  11. 21 5月, 2019 5 次提交
  13. 11 5月, 2019 1 次提交
    • P
      net: wireless: mt76: fix similar warning reported by kbuild test robot · 1b9705d9
      由 Petr Štetiar 提交于 
      This patch fixes following (similar) warning reported by kbuild test robot:

 In function ‘memcpy’,
  inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3,
  inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
  ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull]
  return __builtin_memcpy(p, q, size);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
  ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’

I've replaced the offending memcpy with ether_addr_copy, because I'm
100% sure, that of_get_mac_address can't return NULL as it returns valid
pointer or ERR_PTR encoded value, nothing else.

I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
would make the warning disappear also, but it would be confusing to
check for impossible return value just to make a compiler happy.

I'm now changing all occurencies of memcpy to ether_addr_copy after the
of_get_mac_address call, as it's very likely, that we're going to get
similar reports from kbuild test robot in the future.

Fixes: d31a36b5 ("net: wireless: support of_get_mac_address new ERR_PTR error")
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NPetr Štetiar <ynezz@true.cz>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b9705d9
  15. 06 5月, 2019 1 次提交
  17. 03 5月, 2019 2 次提交
  19. 02 5月, 2019 2 次提交
    • G
      rtw88: phy: mark expected switch fall-throughs · aa8eaaaa
      由 Gustavo A. R. Silva 提交于 
      In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.

This patch fixes the following warnings:

drivers/net/wireless/realtek/rtw88/phy.c: In function ‘rtw_get_channel_group’:
./include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
 # define unlikely(x) __builtin_expect(!!(x), 0)
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
./include/asm-generic/bug.h:125:2: note: in expansion of macro ‘unlikely’
  unlikely(__ret_warn_on);     \
  ^~~~~~~~
drivers/net/wireless/realtek/rtw88/phy.c:907:3: note: in expansion of macro ‘WARN_ON’
   WARN_ON(1);
   ^~~~~~~
drivers/net/wireless/realtek/rtw88/phy.c:908:2: note: here
  case 1:
  ^~~~
In file included from ./include/linux/bcd.h:5,
                 from drivers/net/wireless/realtek/rtw88/phy.c:5:
drivers/net/wireless/realtek/rtw88/phy.c: In function ‘phy_get_2g_tx_power_index’:
./include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
 # define unlikely(x) __builtin_expect(!!(x), 0)
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
./include/asm-generic/bug.h:125:2: note: in expansion of macro ‘unlikely’
  unlikely(__ret_warn_on);     \
  ^~~~~~~~
drivers/net/wireless/realtek/rtw88/phy.c:1021:3: note: in expansion of macro ‘WARN_ON’
   WARN_ON(1);
   ^~~~~~~
drivers/net/wireless/realtek/rtw88/phy.c:1022:2: note: here
  case RTW_CHANNEL_WIDTH_20:
  ^~~~

Warning level 3 was used: -Wimplicit-fallthrough=3

This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      aa8eaaaa
    • C
      rtw88: fix shift of more than 32 bits of a integer · b85bd9a1
      由 Colin Ian King 提交于 
      Currently the shift of an integer value more than 32 bits can
occur when nss is more than 32.  Fix this by making the integer
constants unsigned long longs before shifting and bit-wise or'ing
with the u64 ra_mask to avoid the undefined shift behaviour.

Addresses-Coverity: ("Bad shift operation")
Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b85bd9a1
  21. 01 5月, 2019 7 次提交