| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This driver uses a set of local macros to manipulate the RX and TX
descriptors, which are all little-endian quantities. These macros
are replaced by the bitfield macros le32p_replace_bits() and
le32_get_bits(). In several places, the macros operated on an entire
32-bit word. In these cases, a direct read or replacement is used.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
As the first step in converting from macros that get/set information
in the RX and TX descriptors, unused macros are being removed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c: In function rtl92ee_download_fw:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c:111:6: warning: variable err set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c: In function rtl92ee_is_tx_desc_closed:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c:1005:18: warning: variable cur_tx_wp set but not used [-Wunused-but-set-variable]
It is not used since commit cf54622c8076 ("rtlwifi:
cleanup the code that check whether TX ring is available")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Don't populate const arrays on the stack but instead make them
static. Makes the object code smaller by 60 bytes.
Before:
text data bss dec hex filename
15133 8768 0 23901 5d5d realtek/rtl8xxxu/rtl8xxxu_8192e.o
15209 6392 0 21601 5461 realtek/rtl8xxxu/rtl8xxxu_8723b.o
103254 31202 576 135032 20f78 realtek/rtl8xxxu/rtl8xxxu_core.o
After:
text data bss dec hex filename
14861 9024 0 23885 5d4d realtek/rtl8xxxu/rtl8xxxu_8192e.o
14953 6616 0 21569 5441 realtek/rtl8xxxu/rtl8xxxu_8723b.o
102986 31458 576 135020 20f6c realtek/rtl8xxxu/rtl8xxxu_core.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The WARN_ON() macro doesn't take an error message, the argument is a
condition so this won't display the warning message.
Fixes: 27e117e4b01b ("rtw88: add deep power save support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The RTL8723BU suffers the wifi disconnection problem while bluetooth
device connected. While wifi is doing tx/rx, the bluetooth will scan
without results. This is due to the wifi and bluetooth share the same
single antenna for RF communication and they need to have a mechanism
to collaborate.
BT information is provided via the packet sent from co-processor to
host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h
dose not really handle it. And there's no bluetooth coexistence
mechanism to deal with it.
This commit adds a workqueue to set the tdma configurations and
coefficient table per the parsed bluetooth link status and given
wifi connection state. The tdma/coef table comes from the vendor
driver code of the RTL8192EU and RTL8723BU. However, this commit is
only for single antenna scenario which RTL8192EU is default dual
antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h
is only for 8723b and 8192e so the mechanism is expected to work
on both chips with single antenna. Note RTL8192EU dual antenna is
not supported.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c: In function rtl8723_cmd_send_packet:
drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c:226:5: warning: variable own set but not used [-Wunused-but-set-variable]
It is not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c: In function btc8723b1ant_tdma_dur_adj_for_acl:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:1428:7: warning: variable wifi_busy set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c: In function btc8723b1ant_tdma_dur_adj_for_acl:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:1427:22: warning: variable bt_info_ext set but not used [-Wunused-but-set-variable]
'wifi_busy' is not used since commit 158707f9584c ("rtlwifi:
btcoex: Restore 23b 1ant routine for tdma adjustment")
'bt_info_ext' is not used since commit 2622d7d86a57 ("rtlwifi:
btcoex: 23b 1ant: TDMA duration for ACL busy")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c: In function btc8192e2ant_tdma_duration_adjust:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:1584:6: warning: variable result set but not used [-Wunused-but-set-variable]
It is not used since commit 27a31a60a4de ("rtlwifi:
btcoex: remove unused functions")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c: In function rtl88e_dm_pwdb_monitor:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c:763:6: warning: variable h2c_parameter set but not used [-Wunused-but-set-variable]
It is not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
'v3','rtstatus','reg_ecc','reg_ec4','reg_eac','b_pathb_ok'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function phy_config_bb_with_pghdr:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:652:22: warning: variable v3 set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_config_rf_with_headerfile:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:772:7: warning: variable rtstatus set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1945:6: warning: variable reg_ecc set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1944:61: warning: variable reg_ec4 set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1944:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1943:19: warning: variable b_pathb_ok set but not used [-Wunused-but-set-variable]
They are not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c: In function rtl92c_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c:1373:6: warning: variable reg_ecc set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c: In function rtl92c_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c:1372:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable]
They are not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
'reg_ecc','reg_ec4','reg_eac','b_pathb_ok'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1346:6: warning: variable reg_ecc set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1345:61: warning: variable reg_ec4 set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1345:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1344:19: warning: variable b_pathb_ok set but not used [-Wunused-but-set-variable]
They are not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function rtl8812ae_phy_config_rf_with_headerfile:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:2079:7: warning: variable rtstatus set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function rtl8821ae_phy_config_rf_with_headerfile:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:2114:7: warning: variable rtstatus set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function _rtl8812ae_phy_get_txpower_limit:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:2354:6: warning: variable bd set but not used [-Wunused-but-set-variable]
They are not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.
After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.
With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps, which
indicating that rtl8xxxu could still be further improved.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Disable efuse if the efuse is enabled when we failed to setup the efuse
information, otherwise the hardware will not turn off.
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
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>
|
|
8822C is a 2x2 11ac chip, and then NSS must be less or equal to 2. However,
current nss of hw cap is 3, likes
hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=3
This commit adds constraint to make sure NSS <= rf_path_num, and result
looks like
hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=2
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
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>
|
|
This commit doesn't change logic at all, just use struct rtw_fw_hdr to
access fixed part of 64 bytes header. Since remaining part is variable
length data of actual firmware, we don't define them within the struct.
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>
|
|
It's better to print firmware version at load time.
But since we need to set debug_mask properly to default print
rtw_dbg(), raise the debug level to rtw_info() instead.
Also change the multiple line style to one line only, it will
be easier for log analyzing.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Set CWmax/CWmin, TXOP and AIFS according to ieee80211_tx_queue_params.
Do note that hardware has only one group of EDCA[ac] registers, if more
than one vif are added, the EDCA[ac] registers will contain value of
params of the most recent set by ieee80211_ops::conf_tx().
And AIFS = AIFSN[ac] * slot_time + SIFS, so if use_short_slot is changed,
need to also change AIFS.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The value of GET_RX_DESC_SWDEC() indicates that if this RX
packet requires software decryption or not. And software
decryption is required when the packet was encrypted and the
hardware failed to decrypt it.
So, GET_RX_DESC_SWDEC() is negative does not mean that this
packet is decrypted, it might just have no encryption at all.
To actually see if the packet is decrypted, driver needs to
further check if the hardware has successfully decrypted it,
with a specific type of encryption algorithm.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
When downloading the reserved page, the first page always contains
a beacon for the firmware to reference. For non-beaconing modes such
as station mode, also put a blank skb with length=1.
And for the beaconing modes, driver will get a real beacon with a
length approximate to the page size. But as the beacon is always put
at the first page, it does not need a tx_desc, because the TX path
will generate one when TXing the reserved page to the hardware. So we
could allocate a buffer with a size smaller than the reserved page,
when using memcpy() to copy the content of reserved page to the buffer,
the over-sized reserved page will violate the kernel memory.
To fix it, add the tx_desc before memcpy() the reserved packets to
the buffer, then we can get SKBs with correct length when counting
the pages in total. And for page 0, count the extra tx_desc_sz that
the TX path will generate. This way, the first beacon that allocated
without tx_desc can be counted with the extra tx_desc_sz to get
actual pages it requires.
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Sometimes mac80211 will ask us to flush the hardware queues.
To flush them, first we need to get the corresponding priority queues
from the RQPN mapping table.
Then we can check the available pages are equal to the originally
reserved pages, which means the hardware has returned all of the pages
it used to transmit.
Note that now we only check for 100 ms for the priority queue, but
sometimes if we have a lot of traffic (ex. 100Mbps up), some of the
packets could be dropped.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Based on the mac80211's TXQ implementation, TX-AMSDU can
be used to get higher MAC efficiency. To make mac80211
aggregate MSDUs, low level driver just need to leave skbs
in the TXQ, and mac80211 will try to aggregate them if
possible. As driver will schedule a tasklet when the TX
queue is woke, until the tasklet being served, there will
have some skbs in the queue if traffic is heavy.
Driver can control the max AMSDU size depending on the
current bit rate used by hardware/firmware. The higher
rates are used, the larger AMSDU size can be.
It is tested that can achieve higher T-Put at higher rates.
If the environment is relatively clean, and the bit_rate
is high enough, we can get about 80Mbps improvement.
For lower bit rates, not much gain can we get, so leave
the max_amsdu length low to prevent aggregation.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Whenever the firmware increases/decreases the bit rate used
to transmit to a peer, it sends an RA report through C2H to
driver. Driver can then record the bit rate in the peer's
struct rtw_sta_info, and report to mac80211 when it asks us
for the statistics of the sta by ieee80211_ops::sta_statistics
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>
|
|
We can indicate IEEE80211_HW_HAS_RATE_CONTROL to mac80211 because
the hardware has its own rate control algorithm. And what driver needs
to do is to choose an RA mask according the peer's capabilities.
But the hardware is not able to setup BA session by itself. So driver
requires to initiate tx BA session for hardware, and tells it if it is
possible to transmit AMPDU. The hardware can then aggregate MPDUs.
And the size of AMPDU is controlled by the TX descriptor and the
register value. Since the TX descriptor will reference the max AMPDU
size from ieee80211_sta::ht_cap::ampdu_factor, just set the register
value to 0x3f, and let it be controlled by TX descriptor.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The mac80211 provides software TX queue for driver, as long as
driver has hooked ieee80211_ops::wake_tx_queue. Each time a
packet is queued onto the TX queue, that queue will be woken
up the inform driver to serve the queue.
Now driver only supports PCI interface ICs, there's no specific
traffic control for each queue, just schedule a tasklet, and
dump all of the packets at once to the DMA ring. Instead of TX
the packets whenever TX queue is woke, tasklet handler can have
more packets dumped to the device, takes advantage of burst
write with DMA engine.
And if the driver is going to support USB/SDIO ICs, the tasklet
can be more flexible for aggregating the packets, enhance the
efficiency of bandwidth usage.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Allows driver to send RTS by filling tx descriptor.
The user may want to set the rts threshold. But since we have not
been taking over rate control from mac80211 to driver by setting flag
IEEE80211_HW_HAS_RATE_CONTROL, there is nothing we can do about it.
So here just store the value, and mac80211 will tell us to use rts
protection by ieee80211_tx_info::control::use_rts.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Driver needs to wait for firmware to restore hardware setting
to active mode after leaving lps.
After getting H2C from driver for leaving lps, firmware will
issue null packet without PS bit to inform AP driver is active,
and then restore REG_TCR Register if AP has receiced null packet.
But the transmission of null packet may cost much more time
in noisy environment. If driver does not wait for firmware,
null packet with PS bit could be sent due to incorrect REG_TCR setting.
And AP will be confused.
In our test, 100ms is enough for firmware to send null packet
to AP. If REG_TCR Register is still wrong after 100ms, we will
modify it directly, force the PS bit to be cleared
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>
|
|
There really is no need to make drivers call the
ieee80211_start_tx_ba_cb_irqsafe() function and then
schedule the worker if all we want is to set a bit.
Add a new return value (that was previously considered
invalid) to indicate that the driver is immediately
ready for the session, and make drivers use it. The
only drivers that remain different are the Intel ones
as they need to negotiate more with the firmware.
Link: https://lore.kernel.org/r/1570007543-I152912660131cbab2e5d80b4218238c20f8a06e5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The module parameter rtw_fw_support_lps is misleading. It
is not used to represent the firmware's property, but to
determine if driver wants to ask firmware to enter LPS.
However, driver should better enable/disable PS through
cfg80211_ops::set_power_mgmt instead.
For example, one could use iw command to set PS state.
$ sudo iw wlanX set power_save [on/off]
So rtw_fw_support_lps should be removed because it is
misleading and useless. Instead of checking the parameter,
set PS mode according to IEEE80211_CONF_PS.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Compare with LCLK mode, PG mode saves more power, by turning
off more circuits. Therefore, to recover from PG mode, driver
needs to backup some information into rsvd page. Such as CAM
entries, DPK results.
As CAM entries can change, it is required to re-download CAM
entries after set_key.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Add a module parameter to select deep PS mode. And the mode
cannot be changed after the module has been inserted and probed.
If anyone wants to change the deep mode, should change the mode
and probe the device again to setup the changed deep mode.
When the device is probed, driver will check the deep PS mode
with different IC's PS mode suppotability. If none of the
PS mode is matched, the deep PS mode is changed to NONE,
means deep PS is disabled.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Sometimes LPS is not compatible with COEX's strategy, and
COEX will not allow driver to enter it.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Deep power save allows firmware/hardware to operate in a
lower power state. And the deep power save mode depends on
LPS mode. So, before entering deep PS, driver must first
enter LPS mode.
Under Deep PS, most of hardware functions are shutdown,
driver will not be able to read/write registers and transfer
data to the device. Hence TX path must be protected by each
interface. Take PCI for example, DMA engine should be idle,
and no nore activities on the PCI bus.
If driver wants to operate on the device, such as register
read/write, it must first acquire the mutex lock and wake
up from Deep PS, otherwise the behavior is undefined.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Dynamic mechanism requires BB/RF working to adjust
hardware settings. But PS state periodically turns
off BB/RF, could lead to wrong setting.
So leave PS state before DM to make sure it works.
And then check if we can enter PS state again.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Protect LPS enter/leave routine with rtwdev->mutex.
This helps to synchronize with driver's states correctly.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
This is no more used, remove it.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The original design of LPS enter/leave routines allows
to control the LPS state by each interface. But the
hardware cannot actually handle it that way. This means
the hardware can only enter LPS once with an associated
port, so there is no need to keep tracking the state of
each vif.
Hence the logic of enter/leave LPS state can be simple,
just to check the state of the device's flag. And for
leaving LPS state, it will get the same port id to send
to inform the hardware.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Remove PS related *_irqsafe functions to avoid entering/leaving PS
under interrupt context. Instead, make PS decision in watch_dog.
This could simplify the logic and make the code look clean.
But it could have a little side-effect that if the driver is having
heavy traffic before the every-2-second watch_dog detect the traffic
and decide to leave PS, the thoughput will be lower. Once traffic is
detected by watch_dog and left PS state, the throughput will resume
to the peak the hardware ought to have again.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
If the driver doesn't reset the host's and device's indexes
in a single write, the indexes will become different in a
short period. And it will confuse the DMA engine, make it
start to process non-existed entries.
Better to Write-1-to-reset the indexes, for the DMA engine
to know that this is a reset of the H2C queue, not a kick
off.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
These helper functions seems useless. And in some cases
we want to use test_and_[set/clear]_bit, these helpers
will make the code more complicated. So remove them.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c: In function rtl8723be_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c:2255:7: warning: variable reg_ecc set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c: In function rtl8723be_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c:2254:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable]
They are not used since commit a619d1abe20c ("rtlwifi:
rtl8723be: Add new driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c: In function rtl92ee_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c:2805:34: warning: variable reg_ecc set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c: In function rtl92ee_phy_iq_calibrate:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c:2804:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable]
They are not used since commit b1a3bfc97cd9 ("rtlwifi:
rtl8192ee: Move driver from staging to the regular tree")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c: In function rtl92ee_tx_fill_desc:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c:656:5: warning: variable short_gi set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c: In function rtl92ee_tx_fill_desc:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c:648:15: warning: variable buf_len set but not used [-Wunused-but-set-variable]
They are not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/efuse.c: In function efuse_pg_packet_write:
drivers/net/wireless/realtek/rtlwifi/efuse.c:937:24: warning: variable dataempty set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/efuse.c: In function efuse_get_current_size:
drivers/net/wireless/realtek/rtlwifi/efuse.c:1202:5: warning: variable hoffset set but not used [-Wunused-but-set-variable]
They are not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/ps.c: In function rtl_ps_set_rf_state:
drivers/net/wireless/realtek/rtlwifi/ps.c:71:19: warning: variable rtstate set but not used [-Wunused-but-set-variable]
It is not used since commit f1d2b4d338bf ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
In rtl8xxxu_submit_int_urb if usb_submit_urb fails the allocated urb
should be released.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
There is no need to check "rtlhal->interface == INTF_PCI" twice in
_rtl_ps_inactive_ps(). The nested check is always true. Thus, the
expression can be simplified.
Signed-off-by: Denis Efremov <efremov@linux.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
