Zhou Wang [Thu, 16 Jan 2020 06:10:57 +0000 (14:10 +0800)]
dmaengine: hisilicon: Add Kunpeng DMA engine support
BugLink: https://launchpad.net/bugs/1864442
This patch adds a driver for HiSilicon Kunpeng DMA engine. This DMA engine
which is an PCIe iEP offers 30 channels, each channel has a send queue, a
complete queue and an interrupt to help to do tasks. This DMA engine can do
memory copy between memory blocks or between memory and device buffer.
UBUNTU: SAUCE: rtw88: fill zeros to words 0x06 and 0x07 of security cam entry
BugLink: https://bugs.launchpad.net/bugs/1780590
8723D adds some experimental features to word 0x06 of cam entry, so fill
zeros to initialize them to off state. For existing chips, these two words
are reserved and always zeros, so this change is harmless for them.
Ping-Ke Shih [Fri, 23 Aug 2019 08:45:30 +0000 (16:45 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add coex support
BugLink: https://bugs.launchpad.net/bugs/1780590
8723D is a Wifi+BT combo card. To make them work properly, we need coex
mechanism to avoid interference, such as TX simultaneously. Basically,
coex.c provide main algorithm to deal with many use cases, and this commit
adds some parameters and ops differ from other chips, because coex
hardware and WiFi generation are changed.
Ping-Ke Shih [Fri, 23 Aug 2019 11:39:06 +0000 (19:39 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: set ltecoex register address in chip_info
BugLink: https://bugs.launchpad.net/bugs/1780590
Since 8723D use different address of ltecoex register, this commit add a
new field in chip_info and fill proper address. Then, ltecoex_read_reg()
and ltecoex_reg_write() can use them to access ltecoex according to chip.
BugLink: https://bugs.launchpad.net/bugs/1780590
Flush queue is used to check if queue is empty, before doing something
else. Since 8723D uses different registers and page number of
availabl/reserved occupy 8 bits instead of 16 bits, so use a 'wsize' field
to discriminate which rtw_read{8,16} is adopted.
Ping-Ke Shih [Tue, 20 Aug 2019 02:55:46 +0000 (10:55 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add shutdown callback to disable BT USB suspend
BugLink: https://bugs.launchpad.net/bugs/1780590
Without this patch, wifi card can't initialize properly due to BT in USB
suspend state. So, we disable BT USB suspend (wakeup) in shutdown callback
that is the moment before rebooting. To save BT USB power, we can't do this
in 'remove' callback.
BugLink: https://bugs.launchpad.net/bugs/1780590
When chip's temperature is changed, RF characters are changed. To keep the
characters to be consistent, 8723d uses thermal meter to assist in
calibrating LCK, IQK, crystal and TX power.
A base thermal value is programmed in efuse, all calibration data in
MP process is based on this thermal value. So we calucate the delta of
thermal value between the base value, and use this delta to reference XTAL
and TX power offset tables to know how much we need to adjust.
For IQK and LCK, driver checks if delta of thermal value is over 8, then
they are triggered.
For crystal adjustment, when delta of thermal value is changed, we check
XTAL tables to get offset of XTAL value. If thermal value is larger than
base value, positive table (_p as suffix) is used. Otherwise, we use
negative table (_n as suffix). Then, we add offset to XTAL default value
programmed in efuse, and write sum value to register.
To compensate TX power, there are two hierarchical tables. First level use
delta of thermal value to access eight tables to yield delta of TX power
index. Then, plus base TX power index to get index of BB swing table
(second level tables) where register value is induced.
BB swing table can't deal with all cases, if index of BB swing table is
over the size of the table. In this case, TX AGC is used to compensate the
remnant part. Assume 'upper' is the upper bound of BB swing table, and
'target' is the desired index. Then, we can illustrate them as
BugLink: https://bugs.launchpad.net/bugs/1780590
IQ calibration is used to calibrate RF characteristic to yield expected
performance. Basically, we do calibration twice and compare the similarity
to determine calibration is good or not, if not we do the third
calibration, and then compare with the results of first and second
calibration. If it still not similar, IQK is failed.
Before doing calibration, we need to backup registers that will be
modified in calibration procedure, and restore these registers after
calibration is done.
A calibration procedure can divided into four sub-procedures that are
S1-TX, S1-RX, S0-TX and S0-RX. Where, S1 and S0 represent to path A and B
respectively. Each sub-procedure configure proper registers, and then
rigger one-shot calibration and poll until completion. For RX calibration,
it needs to do twice one-shot calibration, first one is to yield parameter
used by second one.
The result of TX part is stored for TX power tracking that adjusts TX AGC
to output expected power.
BugLink: https://bugs.launchpad.net/bugs/1780590
LC calibration is done by hardware circuit. Driver sets the LCK bit to kick
start, and then poll the bit to check if it's done.
BugLink: https://bugs.launchpad.net/bugs/1780590
Interface configuration table is used to configure PCI PHY that are
normally decided by design or bootstrap pin, and driver can do additional
settings by this table.
BugLink: https://bugs.launchpad.net/bugs/1780590
This ops is used to do statistics of false alarm periodically, and then
fine tune RX initial gain to adaptive different circumstance.
There are three steps, hold/get/reset counter, to retrieve false alarm
counters that consist of CCK and OFDM. In addition to false alarm
counters, it also collects CRC ok/error counters of CCK, OFDM and HT.
UBUNTU: SAUCE: rtw88: sar: dump sar information via debugfs
BugLink: https://bugs.launchpad.net/bugs/1780590
To know detail of SAR information, we add a debugfs entry to dump the raw
content written in ACPI, and also dump the translated data (real number in
decimal). The output looks like
Customer ID: 0x5048
WiFiEnable: 0x1
Total SAR Table Count: 3
Current SAR Table Index: (02 02 02 02)
UBUNTU: SAUCE: rtw88: sar: add sar_work to poll if dynamic SAR table is changed
BugLink: https://bugs.launchpad.net/bugs/1780590
RWSI is used to tell driver operating mode is changed. For example, a
notebook PC can also play as a tablet. Driver detects RWSI in period of
10 seconds, and reconfigure SAR power limit if RWSI values are changed.
UBUNTU: SAUCE: rtw88: sar: apply dynamic SAR table to tx power limit
BugLink: https://bugs.launchpad.net/bugs/1780590
We apply four frequency ranges to calculate TX power, though RWRD defines
five ranges. RWGS is used to adjust SAR power limit value and define the
upper bound corresponding to geography.
Some sar_read::ops are added to convert to proper unit, because the units
and fields of SAR power limit for each customer ID are different.
UBUNTU: SAUCE: rtw88: sar: Load dynamic SAR table from ACPI methods
BugLink: https://bugs.launchpad.net/bugs/1780590
Three tables RWRD, RWSI and RWGS are defined to support SAR power limit
proposed by Realtek. RWRD describes main power limit values that can support
more than one mode, tablet, lid close and etc. RWSI is used to indicate
which mode is operating, so driver must apply SAR power limit corresponding
to the mode. Since each country (geography) has some different SAR power
limit values, RWGS is introduced to adjust power limit mentioned in RWRD
if stack hints driver that regulatory domain is changed.
RWRD contains customer ID, SAR enable, table count and SAR power limit.
With different customer ID, the formats of RWRD, RWSI and RWGS are
different, such as the number of fields in table and precision of power
limit value (in Q-notation). By now, two customer IDs are supported, RT
and HP. 'table count' indicates total number of tables corresponding to
operating modes, and selected by WRSI.
To validate RWSI and RWGS tables, we check if read length and sizeof() are
equal. But these checking statements depend on RWRD's ID are little
verbose, so I use two predefined values, rwsi_sz and rwgs_sz, would be easy
to understand the code.
Ping-Ke Shih [Fri, 23 Aug 2019 05:23:58 +0000 (13:23 +0800)]
UBUNTU: SAUCE: rtw88: sar: Load static SAR table from ACPI WRDS method
BugLink: https://bugs.launchpad.net/bugs/1780590
ACPI WRDS method returns static SAR table that contains two chains (RF paths)
and five power limit data for each chain. The limit data are corresponding
to certain ranges of frequency, such as 2.4G band, 5.15~5.35G etc.
The data is in Q.3 notation that is the same with SAR entry function, so
we don't need to convert its quantity.
Ping-Ke Shih [Thu, 22 Aug 2019 14:53:03 +0000 (22:53 +0800)]
UBUNTU: SAUCE: rtw88: sar: add SAR of TX power limit
BugLink: https://bugs.launchpad.net/bugs/1780590
Originally, there are three factors of TX power:
1) TX base power, calibrated manually and programmed in efuse.
2) By-rate power, an offset to increase power depends on TX rate.
3) TX limit power, an offset to contraint the max power.
So, driver can get the TX power index by using:
TX_POWER_IDX = tx_base_power + min(by-rate, limit)
To take SAR into consideration, we can treat it as another limit of
the TX power. Then driver can get the TX power by using:
TX_POWER_IDX = tx_base_power + min(by-rate, limit, sar)
Note that the values stored in driver are not presented in dBm, so
driver needs to also convert the power limit indexes of SAR with
tx_scale_factor, then get the difference to the TX base power.
rtw_phy_set_tx_power_sar() will convert the values of SAR power in unit of
0.125d Bm (sar_q3) and store them in tx_pwr_sar_{2,5}g[regd][path][rs][ch].
Since certain SAR tables have single one table that isn't regulatory domain
specific, parser can apply to all 'regd' or only one domain RTW_REGD_WW
that SAR TX power limit can be applied no matter which regulatory domain
is selected. Because driver get 'sar' argument by
rtw_phy_get_tx_power_limit() with rule
sar = is_existing(tx_pwr_sar_{2,5}g[regd]) ? tx_pwr_sar_{2,5}g[regd] :
tx_pwr_sar_{2,5}g[RTW_REGD_WW];
There are various sources of SAR table, but it is expected to adopt only
one source. So, save current source of rtw_sar_sources to prevent more
than one source are adopted.
The sequence numbers can be filled by driver. And sometimes, for
example, for the packets downloaded to reserved page, can only be
filled by hardware. Accordingly, driver is responsible to fill some
fields of the TX descriptors to ask the hardware to fill the
sequence numbers.
Hardware fill them by setting fields such as (EN_HWSEQ, EN_HWEXSEQ,
DISQSELSEL, HW_SSN_SEL). Additionally, the rate should be adjusted
based on the current band. And for ps-poll packets, to prevent AID
being changed by hardware, NAVUSEHDR should be set.
Yan-Hsuan Chuang [Mon, 30 Dec 2019 06:40:04 +0000 (14:40 +0800)]
UBUNTU: SAUCE: rtw88: set default port to firmware
BugLink: https://bugs.launchpad.net/bugs/1780590
Most of the power save related functions (LPS/WOW) require to
monitor the interrupts of a specific port. Currently, driver
only uses port 0, so there's no need to set default port to the
firmware, as it default monitors port 0. However, if we are
going to add more limits for interface combinations, we might
add vifs not only on port 0. Set default port number to firmware
if driver is going to enter LPS or WOW, to monitor the hardware
interrupts accordingly.
UBUNTU: SAUCE: rtw88: handle C2H_CCX_TX_RPT to know if packet TX'ed successfully
BugLink: https://bugs.launchpad.net/bugs/1780590
TX status report of 8723D differs from 8822B/8822C, it uses
C2H_CCX_TX_RPT (0x03) with different format. With sequence number
and TX status, driver can know if certain packet was transmitted
successfully.
Ping-Ke Shih [Thu, 28 Nov 2019 03:26:00 +0000 (11:26 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add set_channel
BugLink: https://bugs.launchpad.net/bugs/1780590
Set MAC/BB/RF register according to specified channel. The function
rtw_set_channel_mac() is used to set MAC registers, but 8723D only need
some of them.
For channel 14, we need to set different CCK DFIR values, so restore the
values when channel 1 to 13 is selected.
Spur calibration is needed in channel 13 and 14, and we do notch if spur
is over threshold.
Ping-Ke Shih [Thu, 28 Nov 2019 03:25:45 +0000 (11:25 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add query_rx_desc
BugLink: https://bugs.launchpad.net/bugs/1780590
This ops is used to parse RX descriptor to know the length of received
packet and containing PHY status. If PHY status is existing, the order is
RX descriptor, PHY status and then packet.
There are two types of PHY status, named CCK and OFDM. Their size are the
same, but formats are different.
struct ieee80211_rx_status is also filled depends on above information.
Ping-Ke Shih [Mon, 24 Jun 2019 09:24:59 +0000 (17:24 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add DIG parameter
BugLink: https://bugs.launchpad.net/bugs/1780590
To improve user experience in field, we need DIG to adjust RX initial gain
depends on field situation. Since each chip has its own register address,
this commit defines 8723d specific address.
BugLink: https://bugs.launchpad.net/bugs/1780590
Implement rtw_chip_ops::phy_set_param and ::mac_init to initialize
mac/bb/rf, and they are used during interface up. The procedure contains
power on sequence registers, download firmware, load predefined parameters,
mac/bb/rf specific register and etc.
Ping-Ke Shih [Fri, 21 Jun 2019 01:22:17 +0000 (09:22 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Organize chip TX/RX FIFO
BugLink: https://bugs.launchpad.net/bugs/1780590
TX FIFO size is 32k and it was divided into 256 pages with 128 bytes.
A boundary is used to split pages into two parts, head part is used to
store TX packets coming from host, and tail part is reserved for special
purposes, such as beacon packet, null data packet and so on.
The TX packets coming from host have many categories, such as VO, VI, BE,
BK, MG and etc. When going into head part of TX FIFO, they are classified
to four priority queue named low, normal, high and extra priority queues.
Each priority queue occupies predefined number of page, if a certain
priority queue is full, TX packet will store into PUB priority queue.
Similarly, RX FIFO is 16k and split into two parts, head part is used to
store RX packets, and tail part is 128 bytes and used to store report.
Thus, we fill this boundary to register as well.
BugLink: https://bugs.launchpad.net/bugs/1780590
The txagc table is used to map rate_id and txagc register address and
mask, and ops set_tx_power_index uses this table to write TX power to
corresponding registers. Since 8723D is a 1x1 2.4G 11n chip, only CCK, OFDM
and HT_MCS 0-7 are listed in the table.
Ping-Ke Shih [Wed, 14 Aug 2019 12:38:32 +0000 (20:38 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: 11N chips don't support H2C queue
BugLink: https://bugs.launchpad.net/bugs/1780590
H2C queue is used to send command to firmware. Since 8723D doesn't support
this queue, this commit check wlan_cpu flag to avoid to set H2C related
registers.
Ping-Ke Shih [Mon, 17 Jun 2019 06:20:21 +0000 (14:20 +0800)]
UBUNTU: SAUCE: rtw88: decompose while(1) loop of power sequence polling command
BugLink: https://bugs.launchpad.net/bugs/1780590
The power polling command is one kind of power sequence commands. It's used
to check hardware situation, and subsequent comamnds will be executed if
hardware is ready. A special case is PCIE must toggle BIT_PFM_WOWL and try
again if first try is failed.
In order to reduce indentation to understand the code easier, move polling
part to a separate function. Then, the 'while (1)...loop' is replaced by
two statements to do first try and retry.
Ping-Ke Shih [Mon, 17 Jun 2019 05:26:36 +0000 (13:26 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add mac power-on/-off function
BugLink: https://bugs.launchpad.net/bugs/1780590
The mac power-on flow consists of three steps:
1. pre_sys_cfg (Before switching power state)
2. power_switch (Switching power state)
3. init_sys_cfg (Settings after swtiching power state)
When switching power state, driver will load and parse the power sequence
tables. For 8723D devices, the logics for parsing are most same except for
the polling function. 8723D devices need to toggle BIT_PFM_WOWL twice.
The settings after power state is switched for 8723D devices are quite
different with other devices, extract a legacy function for them.
For power-off flow, 8723D devices have the same logic with existing chips.
But warning printed if we run power-off sequence in power-off state:
rtw_pci 0000:03:00.0: failed to poll offset=0x5f8 mask=0xff value=0x0
The scenario is user do 'ifconfig up' that will run power-on sequence to
bring up and then run power-off sequence to enter idle
(IEEE80211_CONF_IDLE). Then, user do 'ifconfig down' that will run
power-off sequence again, and the warning is shown. Original code check
power-on state to avoid to run power-on sequence twice, and this commit
extends to check both power-on and power-off states.
Ping-Ke Shih [Wed, 14 Aug 2019 09:45:34 +0000 (17:45 +0800)]
UBUNTU: SAUCE: rtw88: no need to send additional information to legacy firmware
BugLink: https://bugs.launchpad.net/bugs/1780590
The firmware of 11AC devices need more information to support more offload
functions, such as IQK. And 11N devices such as 8723D does not support
offload these function in firmware, there is no need to send these additional
information to firmware when it comes to 11N devices.
Ping-Ke Shih [Wed, 19 Jun 2019 01:41:25 +0000 (09:41 +0800)]
UBUNTU: SAUCE: rtw88: add legacy firmware download for 8723D devices
BugLink: https://bugs.launchpad.net/bugs/1780590
The WLAN CPU of 8723D device is different from others, add legacy
firmware download function for it. A new variable wlan_cpu is used to
decide which firmware download function we should use.
Legacy firmware file contains 32 bytes header including version and
subversion. When downloading to wlan cpu, header is excluded.
Firmware is downloaded via beacon queue to reserved page that is a part of
TX buffer. Since 11N WLAN CPU uses different control registers, this patch
introduces related control registers.
Ping-Ke Shih [Sat, 15 Jun 2019 10:20:06 +0000 (18:20 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add read_efuse to recognize efuse info from map
BugLink: https://bugs.launchpad.net/bugs/1780590
The logical efuse map is decoded from physical map by parsing the
header format of the physical map. And each different type of chips
has different logical efuse layout. So add the logical map's layout
for parsing the efuse contents.
Ping-Ke Shih [Thu, 28 Nov 2019 03:25:06 +0000 (11:25 +0800)]
UBUNTU: SAUCE: rtw88: 8723d: Add new chip op efuse_grant() to control efuse access
BugLink: https://bugs.launchpad.net/bugs/1780590
8723D devices need to grant efuse access before dumping physical efuse
map, other chips don't need it, so keep this ops as blank.
BugLink: https://bugs.launchpad.net/bugs/1780590
Add corresponding parameter tables for 8723D devices.
Since 8723D devices currently have only one RFE type, there is
only one entry in rtw8723d_rfe_defs.
BugLink: https://bugs.launchpad.net/bugs/1780590
8723D use SIPI to indirectly read RF register instead of directly read,
so introduce a new struct rtw_rf_sipi_addr and new function
rtw_phy_read_rf_sipi(). Since other chips don't use the new function,
only 8723D needs to fill struct rtw_rf_sipi_addr in rtw_chip_info.
Because there are two kinds of functions for reading RF registers now,
change rtw_phy_read_rf() to chip->ops->read_rf() in
rtw_phy_write_rf_reg_sipi() so that we can switch tp proper RF read
functions depends on the type of the chip.
Though 8723D is an 1x1 chip, it has two RF PHY and we can switch to
one of them, and that should be configured properly. Hence, add a
fix_rf_phy_num to struct rtw_chip_info to allow driver to set one of
the PHY's registers for 8723D, even it is only 1x1. Another variable
rf_phy_num is introduced to keep the constraint number of RF path we
can access, and its value is:
rf_phy_num = (fix_rf_phy_num ? fix_rf_phy_num : rf_path_num)
BugLink: https://bugs.launchpad.net/bugs/1780590
8723D doesn't support beamform because rtw88 only supports VHT beamform
but 8723d doesn't have VHT capability. Though 8723d doesn't support
beamform, BSS_CHANGED_MU_GROUPS is still marked as changed when doing
disassociation. So, add wrapper functions for all beamform ops to make
sure they aren't NULL before calling.
Tzu-En Huang [Mon, 4 Nov 2019 05:58:57 +0000 (13:58 +0800)]
UBUNTU: SAUCE: rtw88: add adaptivity support for EU/JP regulatory
BugLink: https://bugs.launchpad.net/bugs/1780590
ETSI EN-300-328 and EN-301-893 requires "Adaptivity". Adaptivity
is an automatic channel access mechanism by which a device stops
transmission in a channel in the presence of detected signal
before any transmission on that channel.
Energy detect CCA (EDCCA) is used to detect wireless channels
signal strength, and driver will set a signal strength threshold
to decide to stop or restart the transmission.
As this may cause performance downgrade in noisy environment, a
debugfs is added to turn off this for debug or test usage.
Yan-Hsuan Chuang [Fri, 29 Nov 2019 08:57:45 +0000 (16:57 +0800)]
UBUNTU: SAUCE: rtw88: associate reserved pages with each vif
BugLink: https://bugs.launchpad.net/bugs/1780590
Each device has only one reserved page shared with all of the
vifs, so it seems not reasonable to pass vif as one of the
arguments to rtw_fw_download_rsvd_page(). If driver is going
to run more than one vif, the content of reserved page could
not be built for all of the vifs.
To fix it, let each vif maintain its own reserved page list,
and build the final reserved page to download to the firmware
from all of the vifs. Hence driver should add reserved pages
to each vif according to the vif->type when adding the vif.
For station mode, add reserved page with rtw_add_rsvd_page_sta().
If the station mode is going to suspend in PNO (net-detect)
mode, remove the reserved pages used for normal mode, and add
new one for wowlan mode with rtw_add_rsvd_page_pno().
For beacon mode, only beacon is required to be added using
rtw_add_rsvd_page_bcn().
This would make the code flow simpler as we don't need to
add reserved pages when vif is running, just add/remove them
when ieee80211_ops::[add|remove]_interface.
When driver is going to download the reserved page, it will
collect pages from all of the vifs, this list is maintained
by rtwdev, with build_list as the pages' member. That way, we
can still build a list of reserved pages to be downloaded.
Also we can get the location of the pages from the list that
is maintained by rtwdev.
The biggest problem is that the first page should always be
beacon, if other type of reserved page is put in the first
page, the tx descriptor and offset could be wrong.
But station mode vif does not add beacon into its list, so
we need to add a dummy page in front of the list, to make
sure other pages will not be put in the first page. As the
dummy page is allocated when building the list, we must free
it before building a new list of reserved pages to firmware.
This should not change the logic at all.
memset() for pkt_info is unnecessary, just declare as {0}.
Also skb_put()/memcpy() can be replaced by skb_put_data().
Brian Norris [Mon, 13 Jan 2020 19:38:15 +0000 (11:38 -0800)]
UBUNTU: SAUCE: rtw88: don't hold all IRQs disabled for PS operations
BugLink: https://bugs.launchpad.net/bugs/1780590
This driver generally only needs to ensure that
(a) it doesn't try to process TX interrupts at the same time as
power-save operations (and similar)
(b) the device interrupt gets disabled while we're still handling the
last set of interrupts
For (a), all the operations (e.g., PS transitions, packet handling)
happens in non-atomic contexts (e.g., threaded IRQ).
For (b), we only need mutual exclusion for brief sections (i.e., while
we're actually manipulating the interrupt mask/status).
So, we can introduce a separate lock for handling (b), disabling IRQs
while we do it. For (a), we can demote the locking to BH only, now that
(b) (the only steps done in atomic context) and that has its own lock.
This helps reduce the amount of time this driver spends with IRQs off.
Notably, transitioning out of power-save modes can take >3 milliseconds,
and this transition is done under the protection of 'irq_lock'.
Tzu-En Huang [Mon, 3 Feb 2020 06:27:52 +0000 (14:27 +0800)]
UBUNTU: SAUCE: rtw88: Fix incorrect beamformee role setting
BugLink: https://bugs.launchpad.net/bugs/1780590
In associating and configuring beamformee, bfee->role is not
correctly set before rtw_chip_ops::config_bfee().
Fix it by setting it correctly.
Ping-Ke Shih [Thu, 3 Oct 2019 01:37:57 +0000 (09:37 +0800)]
UBUNTU: SAUCE: rtw88: add ciphers to suppress error message
BugLink: https://bugs.launchpad.net/bugs/1780590
Though hardware isn't implement CCMP-256, GCMP and GCMP-256, it's possible
to fallback to use software de-/en-cryption implemented by mac80211.
Without adding these chipers, kernel log will show something if we connect
to a WPA3 enterprise AP, likes
wlan0: failed to set key (1, ff:ff:ff:ff:ff:ff) to hardware (-524)
Yan-Hsuan Chuang [Tue, 26 Nov 2019 09:20:49 +0000 (17:20 +0800)]
UBUNTU: SAUCE: rtw88: avoid holding mutex for cancel_delayed_work_sync()
BugLink: https://bugs.launchpad.net/bugs/1780590
Driver could possibly be dead-locked while canceling works with
*_sync() with mutex lock held. Those cancel_delayed_work_sync()
functions will wait until the work is done, but if we hold the
lock, they will never acquire the lock.
To prevent this, simply release the lock and acquire again after
the works have been canceled. And to avoid the works being queued
again, check if the device is at RTW_FLAG_RUNNING state, otherwise
just return and do nothing.
Ping-Ke Shih [Fri, 28 Jun 2019 02:06:43 +0000 (10:06 +0800)]
UBUNTU: SAUCE: rtw88: move rtw_enter_ips() to the last when config
BugLink: https://bugs.launchpad.net/bugs/1780590
When driver is coming up, mac80211 will set changed as ~0 (0xffffffff),
and driver could enter IDLE state (power off) before switching channel or
other config event. So move rtw_enter_ips() to the last, to make sure the
driver completed the config events before going to IDLE state.
So, moves leave/enter IPS config to be first/last one according to flag
IEEE80211_CONF_IDLE. If there're more configureations we want to add in
the future, they must locate between leave/enter IPS.
Yan-Hsuan Chuang [Mon, 13 Jan 2020 09:20:12 +0000 (17:20 +0800)]
UBUNTU: SAUCE: rtw88: pci: 8822c should set clock delay to zero
BugLink: https://bugs.launchpad.net/bugs/1780590
Since RTL8822CE has enabled reference clock auto calibration,
there is no need to add any clock delay for covering the timing
gap of the reference clock.
UBUNTU: SAUCE: rtw88: disable TX-AMSDU on 2.4G band
BugLink: https://bugs.launchpad.net/bugs/1780590
Some tests shows that using AMSDU to aggregate TCP ACKs to specific
APs will degrade the throughput on 2.4G band in 20MHz bandwidth
(< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's
barely no negative impact if we disable TX AMSDU on 2.4G to connect
to other APs. So it seems like we can just tell mac80211 to not to
aggregate MSDUs when transmitting on 2.4G band.
Note that we still can TX AMSDU on 5G band and benefit from it by
having 50 ~ 70 Mbps throughput improvement.
Yan-Hsuan Chuang [Tue, 10 Dec 2019 07:32:58 +0000 (15:32 +0800)]
UBUNTU: SAUCE: rtw88: disable TX-AMSDU on 2.4G band
BugLink: https://bugs.launchpad.net/bugs/1780590
Some tests shows that using AMSDU to aggregate TCP ACKs to specific
APs will degrade the throughput on 2.4G band in 20MHz bandwidth
(< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's
barely no negative impact if we disable TX AMSDU on 2.4G to connect
to other APs. So it seems like we can just tell mac80211 to not to
aggregate MSDUs by setting the max aggregation size to 1 when
transmitting on 2.4G band.
Note that we still can TX AMSDU on 5G band and benefit from it by
having 50 ~ 70 Mbps throughput improvement.
BugLink: https://bugs.launchpad.net/bugs/1780590
According to some experiments, the original RF register protection
setting of 8822c cannot perfectly make sure that there is no hardware
PI write (direct) during direct write. Modify the setting so that the
hardware block of PI would be turned off via rtw8822c_rstb_3wire()
during the direct write, to avoid RF register racing.
Note that 8822b uses SIPI write (indirect), so 8822b does not
have such problem.
Ping-Ke Shih [Fri, 28 Jun 2019 02:47:45 +0000 (10:47 +0800)]
UBUNTU: SAUCE: rtw88: Use secondary channel offset enumeration
BugLink: https://bugs.launchpad.net/bugs/1780590
The hardware value of secondary channel offset isn't very intuitive. This
commit adds enumeration, so we can easier to check the logic with the
suffix of enumeration name, likes _UPPER or _LOWER.
Tzu-En Huang [Mon, 21 Oct 2019 07:04:55 +0000 (15:04 +0800)]
UBUNTU: SAUCE: rtw88: support dynamic user regulatory setting
BugLink: https://bugs.launchpad.net/bugs/1780590
Add support for regulatory set by NL80211_REGDOM_SET_BY_USER.
This should only be enabled for distributions that need set
Realtek's card regulatory from userspace.
Tzu-En Huang [Mon, 21 Oct 2019 06:27:32 +0000 (14:27 +0800)]
UBUNTU: SAUCE: rtw88: add regulatory process strategy for different chipset
BugLink: https://bugs.launchpad.net/bugs/1780590
There are two kinds of country/regulatory efuse settings
for Realtek's chipset, one is worldwide and the other is
a specific country. For both settings, REGULATORY_STRICT_REG
will be set, telling stack that devices original regulatory is
the superset of any further settings.
For the chipset with the country setting being a specific
country, Realtek does not apply any new regulatory setting
notifiers to the card.
For the chipset with a worldwide regulatory setting,
Realtek's custom worldwide regulatory setting will be
provided via wiphy_apply_custom_regulatory().
And if a new regulatory notification is set by
NL80211_REGDOM_SET_BY_COUNTRY_IE, the new setting will be
applied to the card.
Chin-Yen Lee [Mon, 3 Feb 2020 06:01:57 +0000 (14:01 +0800)]
rtw88: Fix return value of rtw_wow_check_fw_status
BugLink: https://bugs.launchpad.net/bugs/1780590
Clang warns that ret is used uninitialzed.
And we found that actually the return type should be "int" instead
of "bool".
Fixes: 44bc17f7f5b3 ("rtw88: support wowlan feature for 8822c") Link: https://github.com/ClangBuiltLinux/linux/issues/850 Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit ebe8e6116ac49d182b060f843904caf5eacf5b87) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1780590
When TX packet arrives, driver should leave deep PS state to make
sure the DMA is working. After requested to leave deep PS state,
driver needs to poll the PS state to check if the mode has been
changed successfully. The driver used to check the state of the
hardware every 20 msecs, which means upon the first failure of
state check, the CPU is delayed 20 msecs for next check. This is
harmful for some time-sensitive applications such as media players.
So, use shorter delay time each check from 20 msecs to 100 usecs.
The state should be changed in several tries. But we still need
to reserve ~15 msecs in total in case of the state just took too
long to be changed successfully. If the states of driver and the
hardware is not synchronized, the power state could be locked
forever, which mean we could never enter/leave the PS state.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 6b6c150b8464e91af26be805f88d5e58c6d626ae) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Fri, 20 Dec 2019 09:21:52 +0000 (17:21 +0800)]
rtw88: remove unused variable 'in_lps'
BugLink: https://bugs.launchpad.net/bugs/1780590
Unused, will not be used neither, because the hardware/firmware
can only support one vif for LPS currnetly. If there's more than
one vif, than driver will never enter LPS. So remove it.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 962562cde15463f712e9cc007086f6140930199d) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Ping-Ke Shih [Fri, 20 Dec 2019 09:21:47 +0000 (17:21 +0800)]
rtw88: fix TX secondary channel offset of 40M if current bw is 20M or 40M
BugLink: https://bugs.launchpad.net/bugs/1780590
TX secondary channel offset is valid only if current bandwidth is 80M,
otherwise leave this value as zero. The wrong value of txsc40 causes
MAC unpredictable behavior.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 73a2d0b83424f7150a1f607470dac67c95b8b2d4) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Chin-Yen Lee [Thu, 19 Dec 2019 08:58:16 +0000 (16:58 +0800)]
rtw88: Add wowlan net-detect support
BugLink: https://bugs.launchpad.net/bugs/1780590
Net-detect is an option of wowlan to allow the device to
be woken up from suspend mode when configured network is detected.
When user enables net-detect and lets the device enter suspend
state, wowlan firmware will periodically scan until beacon or
probe response of configured networks are received.
Between two scans, wowlan firmware keeps wifi chip in idle mode
to reduce power consumption. If configured networks are detected,
wowlan firmware will trigger resume process.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit b6c12908a33e4e413523e73464cd5957690f1a76) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Chin-Yen Lee [Thu, 19 Dec 2019 08:58:15 +0000 (16:58 +0800)]
rtw88: Add wowlan pattern match support
BugLink: https://bugs.launchpad.net/bugs/1780590
Pattern match is an option of wowlan to allow the device
to be woken up from suspend mode when receiving packets
matched user-designed patterns.
The patterns are written into hardware cam in suspend flow
if users have set up them. If packets matched designed
pattern are received, wowlan firmware will get an interrupt
and then wake up the device.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit e3e400df30078830871b927ca24826667d97d1f6) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Chin-Yen Lee [Thu, 19 Dec 2019 08:58:14 +0000 (16:58 +0800)]
rtw88: support wowlan feature for 8822c
BugLink: https://bugs.launchpad.net/bugs/1780590
Wake on WLAN(wowlan) is a feature which allows devices
to be woken up from suspend state through wlan events.
When user enables wowlan feature and then let the device
enter suspend state, wowlan firmware will be loaded by
the driver and periodically monitors wifi packets.
Power consumption of wifi chip will be reduced in this
state.
If wowlan firmware detects that specific wlan event
happens, it will issue wakeup signal to trigger resume
process. Driver will load normal firmware and let wifi
chip return to the original state.
Currently supported wlan events include receiving magic packet,
rekey packet and deauth packet, and disconnecting from AP.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 44bc17f7f5b3b2cc4084eba6307ba750078a8a73) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Chin-Yen Lee [Thu, 19 Dec 2019 08:58:13 +0000 (16:58 +0800)]
rtw88: load wowlan firmware if wowlan is supported
BugLink: https://bugs.launchpad.net/bugs/1780590
Driver used to download normal firmware only,
but some devices support wowlan and require to
download wowlan firmware when system suspends.
So modify rtw_load_firmware() and its callback to
allow driver to download both normal and wowlan firmware.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit c8e5695eae9959fc5774c0f490f2450be8bad3de) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Thu, 19 Dec 2019 08:58:12 +0000 (16:58 +0800)]
rtw88: add interface config for 8822c
BugLink: https://bugs.launchpad.net/bugs/1780590
Some devices need to configure interface/HCI related reigsters
in power on flow. Add interface_cfg for HCI for the settings.
The driver only supports RTL8822BE/RTL8822CE now, and since
RTL8822BE does not need to configure PCIE, the configuration
is only added for RTL8822CE. Without it, some of the RTL8822CE
device can crash and disconnected to host in suspend/wowlan mode.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 786221048e8f74bafb87b4ba8b613cd5bc0ea159) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Chin-Yen Lee [Thu, 19 Dec 2019 08:58:11 +0000 (16:58 +0800)]
rtw88: pci: reset dma when reset pci trx ring
BugLink: https://bugs.launchpad.net/bugs/1780590
When PCI trx rings are reset, the DMA engine should also be reset.
Otherswise, the rx_tag of rx flow is not synchronous to hw.
Remove DMA reset when rtw_pci_start() as we added it in
rtw_pci_setup().
Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit fd30e891e0bc68735b52d480d078959e5fb30e70) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Chin-Yen Lee [Thu, 19 Dec 2019 08:58:10 +0000 (16:58 +0800)]
rtw88: pci: reset ring index when release skbs in tx ring
BugLink: https://bugs.launchpad.net/bugs/1780590
When skbs queued for each TX ring are relased in PCI stop flow,
the ring index should be reset at the same time.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 25cab7e71da32d46651f5fc9373eef9b79938629) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Mon, 18 Nov 2019 09:54:32 +0000 (17:54 +0800)]
rtw88: allows to enable/disable HCI link PS mechanism
BugLink: https://bugs.launchpad.net/bugs/1780590
Different interfaces have its own link-related power save mechanism.
Such as PCI can enter L1 state based on the traffic on the link, and
sometimes driver needs to enable/disable it to avoid some issues, like
throughput degrade when PCI trying to enter L1 state even if driver is
having heavy traffic.
For now, rtw88 only supports PCIE chips, and they just need to disable
ASPM L1 when driver is not in power save mode, such as IPS and LPS.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 3dff7c6e37499c87a7ba3f728b2ad1775cbbf725) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Mon, 18 Nov 2019 09:54:31 +0000 (17:54 +0800)]
rtw88: pci: enable CLKREQ function if host supports it
BugLink: https://bugs.launchpad.net/bugs/1780590
By Realtek's design, there are two HW modules associated for CLKREQ,
one is responsible to follow the PCIE host settings, and another
is to actually working on it. But the module that is actually working
on it is default disabled, and driver should enable that module if
host and device have successfully sync'ed with each other.
The module is default disabled because sometimes the host does not
support it, and if there is any incorrect settings (ex. CLKREQ# is
not Bi-Direction), device can be lost and disconnected to the host.
So driver should first check after host and device are sync'ed, and
the host does support the function and set it in configuration
space, then driver can turn on the HW module to working on it.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit d2e2c47e65af7310ad7d40ebf4cbb1d898719ec2) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
rtw88: raise LPS threshold to 50, for less power consumption
BugLink: https://bugs.launchpad.net/bugs/1780590
The LPS threshold was set to 2, means driver will leave LPS
mode if there is more than 2 frames TX/RX for every 2 seconds.
This makes driver enter/leave LPS frequently even if we just
"ping -i1" to the others.
Apparently we do not want to leave LPS mode if there is only
some background traffics or web surfing. By experiment, set
this to 50 is a more reasonable value to lower the over all
power consumption.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit bf9840ccf8efbdac755772501bd05f6662e1d799) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Colin Ian King [Fri, 25 Oct 2019 11:30:56 +0000 (12:30 +0100)]
rtw88: remove redundant null pointer check on arrays
BugLink: https://bugs.launchpad.net/bugs/1780590
The checks to see if swing_table->n or swing_table->p are null are
redundant since n and p are arrays and can never be null if
swing_table is non-null. I believe these are redundant checks
and can be safely removed, especially the checks implies that these
are not arrays which can lead to confusion.
Addresses-Coverity: ("Array compared against 0") Fixes: c97ee3e0bea2 ("rtw88: add power tracking support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit baff8da6e1636420ce04cadd6df56e137fa6e005) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Fri, 25 Oct 2019 09:33:45 +0000 (17:33 +0800)]
rtw88: avoid FW info flood
BugLink: https://bugs.launchpad.net/bugs/1780590
The FW info was printed everytime driver is powered on, such as
leaving IDLE state. It will flood the kernel log.
Move the FW info printing to callback when FW is loaded, so
that will only be printed once when device is probed.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 5195b904264098839144d08d23c600811de2e2da) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Fri, 25 Oct 2019 09:33:43 +0000 (17:33 +0800)]
rtw88: rearrange if..else statements for rx rate indexes
BugLink: https://bugs.launchpad.net/bugs/1780590
Driver just memset() rx_status to 0 before assigning rate indexes.
And driver could never hit the 'else' because the driver checks
if 'pkt_stat->rate >= DESC_RATEMCS0', so the 'else' statement can
be removed.
Also rearrange the if..else statements because DESC_RATEMCS0 is
actually larger than DESC_RATE1M ~ DESC_RATE54M, move the check
of 'pkt_stat->rate >= DESC_RATEMCS0' to the last to keep an
increasing order.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit ff0dfe5b0377c075986e8ac1c1516f5fbdb15b15) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Fri, 25 Oct 2019 08:32:00 +0000 (16:32 +0800)]
rtw88: fix sparse warnings for power tracking
BugLink: https://bugs.launchpad.net/bugs/1780590
sparse warnings:
drivers/net/wireless/realtek/rtw88/rtw8822b.c:1440:6: sparse: sparse:
symbol 'rtw8822b_pwr_track' was not declared. Should it be static?
drivers/net/wireless/realtek/rtw88/rtw8822c.c:1008:6: sparse: sparse:
symbol 'rtw8822c_pwrtrack_init' was not declared. Should it be static?
Fixes: c97ee3e0bea2 ("rtw88: add power tracking support") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit a969cf42e5fecbbcc04354dd22b851daa6ab5b30) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yan-Hsuan Chuang [Fri, 25 Oct 2019 08:31:59 +0000 (16:31 +0800)]
rtw88: fix sparse warnings for DPK
BugLink: https://bugs.launchpad.net/bugs/1780590
sparse warnings:
drivers/net/wireless/realtek/rtw88/rtw8822c.c:2871:6: sparse:
sparse: symbol 'rtw8822c_dpk_cal_coef1' was not declared. Should it be
static?
drivers/net/wireless/realtek/rtw88/rtw8822c.c:3112:6: sparse:
sparse: symbol 'rtw8822c_dpk_track' was not declared. Should it be
static?
Fixes: 5227c2ee453d ("rtw88: 8822c: add SW DPK support") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 1f592108bbd0c7eecfb0e60fd8f6690e134dc254) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
In file included from include/linux/bitops.h:5:0,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/mips/include/asm/bug.h:42,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/net/wireless/realtek/rtw88/main.h:8,
from drivers/net/wireless/realtek/rtw88/main.c:5:
drivers/net/wireless/realtek/rtw88/main.c: In function 'rtw_update_rate_mask':
include/linux/bits.h:23:11: warning: right shift count is negative
[-Wshift-count-negative]
(~UL(0) >> (BITS_PER_LONG - 1 - (h))))
^
drivers/net/wireless/realtek/rtw88/main.c:622:17: note: in expansion of macro 'GENMASK'
u64 cfg_mask = GENMASK(63, 0);
^~~~~~~
Reported-by: kbuild test robot <lkp@intel.com> Fixes: f39e9bd49a3d ("rtw88: add set_bitrate_mask support") Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 5c70e97142542c4d22e8892568c035bc95049258) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tsang-Shian Lin [Tue, 22 Oct 2019 10:04:20 +0000 (18:04 +0800)]
rtw88: add phy_info debugfs to show Tx/Rx physical status
BugLink: https://bugs.launchpad.net/bugs/1780590
This commit adds several Tx/Rx physical information to phy_info
debugfs for 8822B/8822C. By this debugfs, we can know physical
information, such as Tx/Rx rate, RSSI, EVM,SNR, etc. The
information is gotten from the packets of Tx/Rx path. It has
no impact for the performance of 8822B/8822C.
In the fields, we may meet different kinds of problems, but
we may have no professional instrument to check them. At
this moment, this debugfs is a good tool, and it may provide
useful information for debug.
Signed-off-by: Tsang-Shian Lin <thlin@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 082a36dc9995d581db42f47055287e4974e3825c) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tzu-En Huang [Tue, 22 Oct 2019 10:04:19 +0000 (18:04 +0800)]
rtw88: add set_bitrate_mask support
BugLink: https://bugs.launchpad.net/bugs/1780590
Support setting bit rate from upper layer.
After configuring the original rate control result in the driver, the
result is then masked by the bit rate mask received from the ops
set_bitrate_mask. Lastly, the masked result will be sent to firmware.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit f39e9bd49a3d612a2489b774265107f61ffd82fa) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
If the driver is in station mode and associated with an AP, and the
capabilities of both meet the requirement of beamforming, driver will
run as a beamformee and the corresponding chip settings will be set.
In addition, module parameter support_bf is added to enable or disable
beamforming. Sometimes driver will need to disable for inter-operate
issues, and it would be easier for driver to debug.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 0bd9557341b7fb44bf591921d7feb4dcf4f4bb52) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tzu-En Huang [Tue, 22 Oct 2019 10:04:17 +0000 (18:04 +0800)]
rtw88: add power tracking support
BugLink: https://bugs.launchpad.net/bugs/1780590
The temperature of the chip can affect the output power
of the RF components. Hence driver requires to compensate
the power by adjusting the power index recorded in the
power swing table.
And if the difference of current thermal value to the
default thermal value exceeds a threshold, the RF IQK
should be triggered to re-calibrate the characteristics
of the RF components, to keep the output IQ vectors of
the RF components orthogonal enough.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit c97ee3e0bea29827f4b44276fc792bd32977edb0) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
projects / mirror_ubuntu-focal-kernel.git / log