History log of /linux-master/drivers/net/wireless/realtek/rtlwifi/rc.c
Revision Date Author Comments
# 046d2e7c 04-Apr-2022 Sriram R <quic_srirrama@quicinc.com>

mac80211: prepare sta handling for MLO support

Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.

With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.

To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.

For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.

For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.

Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.

Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.

@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@

(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)

@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@

(
si->
- var
+ deflink.var
)

Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>


# 6cb5f3ea 23-Apr-2020 Johannes Berg <johannes.berg@intel.com>

mac80211: populate debugfs only after cfg80211 init

When fixing the initialization race, we neglected to account for
the fact that debugfs is initialized in wiphy_register(), and
some debugfs things went missing (or rather were rerooted to the
global debugfs root).

Fix this by adding debugfs entries only after wiphy_register().
This requires some changes in the rate control code since it
currently adds debugfs at alloc time, which can no longer be
done after the reordering.

Reported-by: Jouni Malinen <j@w1.fi>
Reported-by: kernel test robot <rong.a.chen@intel.com>
Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
Reported-by: Felix Fietkau <nbd@nbd.name>
Cc: stable@vger.kernel.org
Fixes: 52e04b4ce5d0 ("mac80211: fix race in ieee80211_register_hw()")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Link: https://lore.kernel.org/r/20200423111344.0e00d3346f12.Iadc76a03a55093d94391fc672e996a458702875d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>


# 1e87fec9 16-May-2019 Johannes Berg <johannes.berg@intel.com>

mac80211: call rate_control_send_low() internally

There's no rate control algorithm that *doesn't* want to call
it internally, and calling it internally will let us modify
its behaviour in the future.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>


# b16abaaf 21-Feb-2019 Larry Finger <Larry.Finger@lwfinger.net>

rtlwifi: Fix all blank line irregularities in main code files

The types of problems fixed are as follows:

WARNING: Missing a blank line after declarations
CHECK: Please use a blank line after function/struct/union/enum declarations
CHECK: Please don't use multiple blank lines

There are no code changes.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# d27a76fa 14-Feb-2019 Larry Finger <Larry.Finger@lwfinger.net>

rtlwifi: Replace old-style license information

The traditional license information is replaced by the SPDX form. There
are no code changes.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# 50da5da1 28-Jan-2018 Ping-Ke Shih <pkshih@realtek.com>

rtlwifi: Fix VHT NSS in RC

NSS is a argument of highest rate in RC, and it occupies bit 4-7 so use
ieee80211_rate_set_vht() to fill the values. Since it got correct rate
index, we don't need to check chips to assign NSS in set function anymore.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# d63589cb 29-Dec-2017 Frank A. Cancio Bello <frank@generalsoftwareinc.com>

rtlwifi: Remove unnecessary parentheses

This is merged by Ping-Ke Shih from commit a221cb0911b8 ("staging:
rtlwifi: Remove unnecessary parentheses"), and original commit log
is reserved below.

Remove unnecessary parentheses to comply with preferred coding style for
the linux kernel and avoid the following checkpatch's message:
'CHECK: Unnecessary parentheses around'.

Credits to checkpatch.

Signed-off-by: Frank A. Cancio Bello <frank@generalsoftwareinc.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# 2ea70bb0 29-Dec-2017 Shreeya Patel <shreeya.patel23498@gmail.com>

rtlwifi: Remove unnecessary 'out of memory' message

This is merged by Ping-Ke Shih from commit 596e0559d61a ("Staging:
rtlwifi: Remove unnecessary 'out of memory' message."), and commit log
is reserved below.

Logging messages that show some type of "out of memory" error
are generally unnecessary as there is a generic message and
a stack dump done by the memory subsystem.

These messages generally increase kernel size without much
added value.

Problem found by checkpatch.

Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# cb1b8262 06-Aug-2017 Bhumika Goyal <bhumirks@gmail.com>

rtlwifi: constify rate_control_ops structure

rate_control_ops structure is only passed as an argument to the
function ieee80211_rate_control_{register/unregister}. This argument
is of type const, so declare the structure as const.

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# b03d968b 14-Dec-2016 Larry Finger <Larry.Finger@lwfinger.net>

rtlwifi: Remove RT_TRACE messages that use DBG_EMERG

These messages are always logged and represent error conditions, thus
we can use pr_err().

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# 08aba42f 15-Jun-2016 Arnd Bergmann <arnd@arndb.de>

rtlwifi: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
incorrect code that results from 'char' being unsigned here, e.g.

realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8188ee/dm.c:1070:22: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8192ce/trx.c:54:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8192cu/mac.c:601:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8192de/trx.c:53:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8192ee/phy.c:1268:12: error: comparison is always true due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8192se/rf.c:150:20: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8723be/dm.c:877:29: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8723be/phy.c:386:16: error: comparison is always true due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8821ae/dm.c:1514:38: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8821ae/phy.c:1558:11: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8821ae/phy.c:386:24: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/rtl8821ae/trx.c:55:12: error: comparison is always false due to limited range of data type [-Werror=type-limits]
realtek/rtlwifi/stats.c:31:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]

This patch changes all uses of 'char' in this driver that refer to
8-bit integers to use 's8' instead, which is signed on all architectures.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# 73fb2705 25-Feb-2016 Larry Finger <Larry.Finger@lwfinger.net>

rtlwifi: Fix size of wireless mode variable

Smatch reports the following warning:

CHECK drivers/net/wireless/realtek/rtlwifi/rc.c
drivers/net/wireless/realtek/rtlwifi/rc.c:144 _rtl_rc_rate_set_series() warn: impossible condition '(wireless_mode == 256) => (0-255 == 256)'

This warning arises because commit acc6907b87a9 ("rtlwifi: Fix warning
from ieee80211_get_tx_rates() when using 5G") now checks the wireless
mode for WIRELESS_MODE_AC_ONLY (BIT(8)) in _rtl_rc_rate_set_series().
As a result, all quantities used to store the wireless mode must be u16.

This patch also reorders struct rtl_sta_info to save a little space.

Fixes: d76d65fd2695 ("rtlwifi: fix broken VHT support")
Reported-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# d76d65fd 31-Jan-2016 Larry Finger <Larry.Finger@lwfinger.net>

rtlwifi: fix broken VHT support

When using a 5G-capable device with VHT (802.11ac) rates enabled was not
working (packets were not delivered) and the following mac80211 warning
was printed:

WARNING: CPU: 3 PID: 2253 at net/mac80211/rate.c:625 ieee80211_get_tx_rates+0x22e/0x620 [mac80211]()
Modules linked in: rtl8821ae btcoexist rtl_pci rtlwifi fuse drbg ansi_cprng ctr ccm bnep bluetooth af_packet nfs fscache vboxpci(O) vboxnetadp(O) vboxne
tflt(O) vboxdrv(O) arc4 snd_hda_codec_generic x86_pkg_temp_thermal rtsx_pci_sdmmc mmc_core rtsx_pci_ms kvm_intel memstick iwlmvm kvm mac80211 snd_hda_intel snd_hda_cod
ec snd_hwdep snd_hda_core irqbypass snd_pcm iwlwifi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 snd_timer lrw gf128mul glue_h
elper ablk_helper cryptd snd cfg80211 pcspkr serio_raw e1000e rtsx_pci lpc_ich ptp xhci_pci mfd_core pps_core xhci_hcd soundcore toshiba_acpi thermal sparse_keymap wmi
toshiba_bluetooth rfkill acpi_cpufreq battery ac processor dm_mod i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
drm sr_mod cdrom video button sg autofs4 [last unloaded: rtlwifi]
CPU: 3 PID: 2253 Comm: Timer Tainted: G W O 4.5.0-rc1-wl+ #79
Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014
ffffffffa05c4be6 ffff8802262036d8 ffffffff813d7912 0000000000000000
ffff880226203710 ffffffff8106bcb6 ffff8800c6831300 ffff8800c6831330
0000000000000000 ffff8800c683133c ffff880065923638 ffff880226203720
Call Trace:
<IRQ> [<ffffffff813d7912>] dump_stack+0x4b/0x79
[<ffffffff8106bcb6>] warn_slowpath_common+0x86/0xc0
[<ffffffff8106bdaa>] warn_slowpath_null+0x1a/0x20
[<ffffffffa05511ee>] ieee80211_get_tx_rates+0x22e/0x620 [mac80211]
[<ffffffffa0782232>] ? rtl_is_special_data+0x32/0x240 [rtlwifi]
[<ffffffffa055209e>] ? rate_control_get_rate+0xce/0x150 [mac80211]
[<ffffffff810bfc7d>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff81071cc5>] ? __local_bh_enable_ip+0x65/0xd0

Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


# f1d2b4d3 07-Sep-2015 Larry Finger <Larry.Finger@lwfinger.net>

rtlwifi: rtl818x: Move drivers into new realtek directory

Now that a new mac80211-based driver for Realtek devices has been submitted,
it is time to reorganize the directories. Rather than having directories
rtlwifi and rtl818x be in drivers/net/wireless/, they will now be in
drivers/net/wireless/realtek/. This change simplifies the directory
structure, but does not result in any configuration changes that are
visable to the user.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>