| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For 8852CE, there is abnormal state called CMDPSR_FRZTO,
which occasionally happens in some platforms, and could be
found by firmware and fixed in current SER flow, so we add
suppress function to avoid verbose message for this resolved case.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508084335.42953-4-pkshih@realtek.com
|
|
Newer FW re-design SER (syetem error recovery) L1 (level 1) flow.
New L1 flow will expect two extra states before original L1 flow.
* Before:
fw --- M1 --> driver
fw <-- M2 --- driver
fw --- M3 --> driver
fw <-- M4 --- driver
fw --- M5 --> driver
* After:
fw --- pre-M0 --> driver
fw <-- post-M0 --- driver
fw --- M1 --> driver
fw <-- M2 --- driver
fw --- M3 --> driver
fw <-- M4 --- driver
fw --- M5 --> driver
Then before M1, FW gets one more interval to deal with things that FW
should have handled well. To consider backward/forward compatibility,
FW and driver won't change flow from M1 to M5. (only except that halt
trigger control will change a little bit.) So, there will be two differnt
starting points of SER L1.
* old FW: SER L1 starts from M1
* new FW: SER L1 starts from pre-M0
Then, driver adds the new SER L1 entry and also keep the original one
instead of changing it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508084335.42953-3-pkshih@realtek.com
|
|
RTL8851B keeps almost the same interrupt flow as RTL8852A and RTL8852B.
But, it uses a different bitmask for interrupt indicator of FW HALT C2H.
So, we make a chip judgement in pci when configuring interrupt mask.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508084335.42953-2-pkshih@realtek.com
|
|
U-NII-4 band, i.e 5.9GHz channels, can be supported by chip 8852C, 8852B
and 8851B. But, it is not supported by chip 8852A. Flag support_unii4 is
added in chip info and defined by chip accordingly to indicate that.
We reference this flag of runtime chip to decide whether to register
5.9GHz channels.
After that, we consider if U-NII-4 band is allowed by our regulatory
rule of U-NII-4. If chip::support_unii4 but not regd::allow_unii4,
we stll do not register 5.9GHz channels.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508081211.38760-4-pkshih@realtek.com
|
|
For realtek regulatory, there are following two kinds of configurations
to determine whether to allow UNII-4 band, i.e. 5.9GHz channels.
1. default setting according to whether chip support it or not
2. evaluate realtek ACPI DSM with RTW89_ACPI_DSM_FUNC_59G_EN (func. 6)
If (1) is false, we won't try (2) and just disallow UNII-4. Otherwise,
if (2) is not supported or returns a non-specific value, we follow the
default setting either. Besides, this commit aims to add decision logic
in rtw89 regulatory. Actually, driver doesn't register UNII-4 yet. That
will be handled by another commit.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508081211.38760-3-pkshih@realtek.com
|
|
Introduce realtek ACPI DSM method to get required BIOS
configurations. It will be used in the following commits.
And, enum rtw89_acpi_dsm_func is added for listing the functions
which are currently recognized.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230508081211.38760-2-pkshih@realtek.com
|
|
The type of "mwifiex_adapter->nd_info" is "struct cfg80211_wowlan_nd_info",
not "struct cfg80211_wowlan_nd_match".
Use struct_size() to ease the computation of the needed size.
The current code over-allocates some memory, so is safe.
But it wastes 32 bytes.
Fixes: 7d7f07d8c5d3 ("mwifiex: add wowlan net-detect support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/7a6074fb056d2181e058a3cc6048d8155c20aec7.1683371982.git.christophe.jaillet@wanadoo.fr
|
|
Call mutex_unlock(&rtwdev->mutex); before returning on this error path.
Fixes: f0e741e4ddbc ("wifi: rtw88: add bitmap for dynamic port settings")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/ddd10a74-5982-4f65-8c59-c1cca558d239@kili.mountain
|
|
In recent access points, information element is longer as they include
additional data which exceeds 256 bytes. To accommodate longer
association response, increase the ASSOC response buffer.
Signed-off-by: Amisha Patel <amisha.patel@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230509172811.4953-1-amisha.patel@microchip.com
|
|
Mandatory WFA testcase
CT_Security_WPA2Personal_STA_RSNEBoundsVerification-AbsentRSNCap,
performs bounds verfication on Beacon and/or Probe response frames. It
failed and observed the reason to be absence of cipher suite and AKM
suite in RSN information. To fix this, enable the RSN flag before extracting RSN
capabilities.
Fixes: cd21d99e595e ("wifi: wilc1000: validate pairwise and authentication suite offsets")
Signed-off-by: Amisha Patel <amisha.patel@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421181005.4865-1-amisha.patel@microchip.com
|
|
Smatch reports that:
drivers/net/wireless/mediatek/mt7601u/debugfs.c:130
mt7601u_init_debugfs() warn: 'dir' is an error pointer or valid".
Debugfs code is not supposed to need error checking so instead of
changing this to if (IS_ERR()) the correct thing is to just delete
the dead code.
Signed-off-by: Wang Jikai <wangjikai@hust.edu.cn>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421092200.24456-1-wangjikai@hust.edu.cn
|
|
mwifiex_wmm_list_len() is the same as list_count_nodes(), so use the latter
instead of hand writing it.
Turn 'ba_stream_num' and 'ba_stream_max' in size_t to keep the same type
as what is returned by list_count_nodes().
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/e77ed7f719787cb8836a93b6a6972f4147e40bc6.1682537509.git.christophe.jaillet@wanadoo.fr
|
|
The if statement is reversed so it will not record the chip version.
This was detected using Smatch:
drivers/net/wireless/realtek/rtw89/core.c:3593 rtw89_read_chip_ver()
error: uninitialized symbol 'val'.
Fixes: a6fb2bb84654 ("wifi: rtw89: read version of analog hardware")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/e4d912a2-37f8-4068-8861-7b9494ae731b@kili.mountain
|
|
IQ signal calibration is a very important calibration to yield good RF
performance. We do this calibration only if we are going to run on AP
channel. During scanning phase, without this calibration RF performance
is still acceptable because it transmits with low data rate at this phase.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230424065242.17477-6-pkshih@realtek.com
|
|
DACK (digital-to-analog converters calibration) is used to calibrate DAC
to output good quality signals.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230424065242.17477-5-pkshih@realtek.com
|
|
RCK is synchronize RC calibration. Driver triggers this calibration and
sets the result to register. This calibration is needed once when interface
is going to up.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230424065242.17477-4-pkshih@realtek.com
|
|
Automatic amplitude control calibration (AACK) is the calibration to ensure
the oscillator is biased for a constant output amplitude. We do this
calibration if card does power on.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230424065242.17477-3-pkshih@realtek.com
|
|
Add to set RF registers according to the channel we want to switch. The
callers will be added afterward.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230424065242.17477-2-pkshih@realtek.com
|
|
Configure DLE (data link engine) memory size for operating modes.
Similarly, HFC standing for HCI flow control is used to set quota
according to operating modes, which are SCC or download firmware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-9-pkshih@realtek.com
|
|
Add WoWLAN stub to 8851B, and decalre this chip can support magic packet
and disconnect wakeup.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-8-pkshih@realtek.com
|
|
BA CAM of 8852C has more entries and more fields of H2C, and needs
initialization before using. Due to differences from 8852A/8852B, we name
it as V1 before. However, real V1 of BA CAM is introduced now, so change
it to V0_EXT to avoid confusing with firmware design.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-7-pkshih@realtek.com
|
|
Previously, 8852B has smaller FIFO size than others, so I use chip_id to
choose debug_mask before. 8851B has similar design, so add a field to
chip_info as a general expression.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-6-pkshih@realtek.com
|
|
Since CFO XTAL registers of 8851B is different from 8852A, add a chip_info
field to define their difference. Other chips use another interface, so
fill NULL to this field.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-5-pkshih@realtek.com
|
|
NCTL (nano-controller) is used to assist RF calibration that sends
commands to NCTL so it can reduce IO from driver. 8851B needs additional
settings, so add a table to do things.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-4-pkshih@realtek.com
|
|
Add PCI entry to 8851BE with its device ID 10ec:b851, also fill PCI info
according to its capabilities.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-3-pkshih@realtek.com
|
|
8851B is a 1x1 80 MHz bandwidth chip working on 2/5 GHz. Add these basic
information, and more settings will be added by functions.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230421024551.29994-2-pkshih@realtek.com
|
|
The following are scan offload related H2C (host to chip) function types.
* H2C_FUNC_ADD_SCANOFLD_CH
* H2C_FUNC_SCANOFLD
Before doing FW scan, we will continuously send multiple H2Cs with above
types which are used to tell FW the scan configuration of this time. But,
if FW doesn't handle one of these H2Cs well, the FW scan process might
not run as expected and driver should notice it early.
So, this commits makes scan offload related H2Cs wait for FW done ACK via
rtw89_wait_for_cond() and rtw89_complete_cond(). And, we check the return
code of these H2Cs from FW.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/a15f4bd594f71d7602ea67698b035805143700c9.camel@realtek.com
|
|
We have some MAC H2Cs (host to chip packets), which have no clear
individual C2Hs (chip to host packets) to indicate FW execution
response, but they are going to require to wait for FW completion.
So, we have to deal with this via common MAC C2H receive/done ACKs.
This commit changes the context, where common MAC C2H receive/done
ACK handlers are executed, to interrupt context. And, code comments
are added to prevent future commits from using it incorrectly.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/c4d766885e00b9f9dcf7954a80096c8b9d21149b.camel@realtek.com
|
|
The H2Cs (host to chip packets) related to packet offload functions
need to wait for FW responses in case FW state machine gets wrong
and makes driver status no longer able to align FW one. In flow,
driver may continuously send multiple H2Cs of packet offload series.
If somehow FW doesn't deal with the former yet but the latter has
gotten in, it might cause the problem mentioned above.
So, we block these H2Cs by rtw89_wait_for_cond(). And then, when
the corresponding C2Hs (chip to host packets) is received, we call
rtw89_complete_cond(). Besides, RTW89_MAC_C2H_FUNC_PKT_OFLD_RSP's
C2H handler should be executed in interrupt context to make our
wait/complete process work as expected.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/9ae8c1f105901c65e3171276a9fd6c99ae51803f.camel@realtek.com
|
|
There are two places where offload packets of 6 GHz probe would be deleted
from FW, i.e. calling rtw89_fw_h2c_del_pkt_offload().
* rtw89_core_cancel_6ghz_probe_tx()
* rtw89_release_pkt_list()
It is possible that we try to delete the same one from FW twice. Although
it might not be a big problem for now, it will depend on the runtime chip
firmware. So, we add a check to avoid it. In case things becomes complex
due to racing problem, we don't choose to do list_del(info->list) and
kfree(info) in both sides.
Besides, rtw89_fw_h2c_del_pkt_offload() will needs to wait for completion
after the follow-up commit. However, rtw89_core_cancel_6ghz_probe_tx()
was called in interrupt context. So, we move the stuffs of calling
rtw89_fw_h2c_del_pkt_offload() from rtw89_core_cancel_6ghz_probe_tx()
into a work. Then, we also need a check there before we call it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/091966e5709cd7caecf9b81f7fd6388ae2b70a7e.camel@realtek.com
|
|
We have a pair of FW functions, rtw89_fw_h2c_add_pkt_offload() and
rtw89_fw_h2c_del_pkt_offload(). The rtw89_fw_h2c_add_pkt_offload()
acquires the bit itself, but the bit needs to be released by the
caller of rtw89_fw_h2c_del_pkt_offload(). This looks asymmetrical
and is not friendly to callers.
Second, if callers always releases the bits, it might make driver
unaligned to bitmap status of FW after some failures of calling
rtw89_fw_h2c_del_pkt_offload(). So, this commit move bit release
into rtw89_fw_h2c_del_pkt_offload().
In general, driver will call rtw89_fw_h2c_add_pkt_offload() and
rtw89_fw_h2c_del_pkt_offload(), and then, SW bitmap can align
with FW one. There is one exception when notify_fw is false.
It happens when driver detects FW problems and is going to
reset FW. Only in this case, driver needs to release bits
outside rtw89_fw_h2c_del_pkt_offload().
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/8cf5d45c5b04e7b680d4eb9dda62056cdce14cec.camel@realtek.com
|
|
Take EVM into consideration when doing antenna diversity, and the priority
is higher than RSSI. Since EVM is more relevant to performance than RSSI,
especially in OTA environment.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230418012820.5139-8-pkshih@realtek.com
|
|
RSSI statistics are grouped by CCK, OFDM or non-legacy rate. These
statistics will be collected in training state for both (main/aux)
antenna. There is a time period (ANTDIV_DELAY) for rate adaptive
settle down before start collect statistics when switch antenna.
Antenna diversity checks packet count from training state for each
group and use the most one as the final RSSI for comparison, and
then choose the better one as target antenna.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230418012820.5139-7-pkshih@realtek.com
|
|
Initialize basic antenna switch settings according to hardware module
design, and set to default antenna A. The set antenna function will be
called dynamically to switch antenna according to EVM and RSSI.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230418012820.5139-6-pkshih@realtek.com
|
|
To help debug performance problem, add EVM and SNR statistics to debugfs
that shows
EVM: [(26.75, 26.75) (25.75, 25.75)] SNR: 40
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230418012820.5139-5-pkshih@realtek.com
|
|
RSSI strength is only from PHY path A, but there are two antenna for the
module which supports antenna diversity. So, set RSSI value to index 1 of
RSSI array if current antenna is on antenna B. Then, debugfs can show
two RSSI values with a asterisk mark on selected antenna.
RSSI: -23 dBm (raw=174, prev=173) [-26, -23*]
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230418012820.5139-4-pkshih@realtek.com
|
|
TX antenna diversity is a mechanism to select a proper antenna from two
antenna for single one hardware PHY chip. It chooses antenna with better
EVM or RSSI, and use GPIO to control SPDT to switch selected antenna.
RFE type from efuse is used to define if a module can support TX antenna
diversity when (type % 3) is 2.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230418012820.5139-3-pkshih@realtek.com
|
|
status
To be more clear to know where it gets information from PHY IE0 data,
change to use struct and standard le32_get_bits() to access. This doesn't
change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230418012820.5139-2-pkshih@realtek.com
|
|
If there is a failure during copy_from_user or user-provided data
buffer is invalid, rtw_debugfs_set_* should return negative
error code instead of a positive value count.
Fix this bug by returning correct error code.
Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/tencent_53140CC2A3468101955F02EB66AA96780B05@qq.com
|
|
If there is a failure during copy_from_user or user-provided data
buffer is invalid, rtw_debugfs_copy_from_user should return negative
error code instead of a positive value count.
Fix this bug by returning correct error code. Moreover, the check
of buffer against null is removed since it will be handled by
copy_from_user.
Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/tencent_D2EB102CC7435C0110154E62ECA6A7D67505@qq.com
|
|
Remove a return statement at the end of a void function.
This fixes a checkpatch warning.
WARNING: void function return statements are not generally useful
6206: FILE: ./drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:6206:
+ return;
+}
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230427185936.923777-1-martin@kaiser.cx
|
|
The driver can receive several frames in the same USB transfer.
Add the code to handle this in rtl8xxxu_parse_rxdesc24(), even though
currently all the relevant chips send only one frame per USB transfer
(RTL8723BU, RTL8192EU, RTL8188FU, RTL8710BU).
This was tested with RTL8188FU, RTL8192EU, RTL8710BU, and RTL8192FU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/16d2d1ff-6438-10c9-347f-6e14dd358ccf@gmail.com
|
|
Set maximum number of associated stations supported in AP mode. For
8188f, the maximum number of supported macids is 16, reserve one for
broadcast/multicast frames.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-19-martin.kaistra@linutronix.de
|
|
Everything is in place now for AP mode, we can tell the system that we
support it. Put the feature behind a flag in priv->fops, because it is
not (yet) implemented for all chips.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-18-martin.kaistra@linutronix.de
|
|
As this driver uses HAS_RATE_CONTROL, rate_flags will not be provided by
mac80211.
Stop using tx_info->control.rates[0].flags and ieee80211_get_rts_cts_rate()
and use rts_threshold and bss_conf.use_cts_prot instead to determine
when to use RTS and CTS.
Send RTS with 24M rate like the vendor drivers. Also set this RTS rate
for ampdu_enable = true, because we also enable RTS for these frames.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-17-martin.kaistra@linutronix.de
|
|
As this driver uses HAS_RATE_CONTROL, tx_rates will not be provided by
mac80211.
For some frames c->control.rates[0].idx is negative, which means
ieee80211_get_tx_rate() will print a warning and return NULL.
Only management frames have USE_DRIVER_RATE set, so for all others the
rate info of txdesc is ignored anyway.
Remove call to ieee80211_get_tx_rate() and send management frames with
1M (rate info = 0).
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-16-martin.kaistra@linutronix.de
|
|
When RCR_CHECK_BSSID_MATCH is set in AP mode, we don't receive any data
frames. Rearrange RCR bits to filter flags to match other realtek drivers
and remove RCR_CHECK_BSSID_MATCH in AP mode.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-15-martin.kaistra@linutronix.de
|
|
Beacon frames are generated by the HW and therefore contain a HW
generated seq number. Enable HW sequence number for other frames to
match that.
mac80211 will tell us via IEEE80211_TX_CTL_ASSIGN_SEQ when that is
necessary.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-14-martin.kaistra@linutronix.de
|
|
The HW maintains a rate_mask for each connection, referenced by the
macid. Add a parameter to update_rate_mask and add the macid to the
h2c call in the gen2 implementation.
Also extend refresh_rate_mask to get the macid from sta_info.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-13-martin.kaistra@linutronix.de
|
|
Add a parameter macid to fill_txdesc(), implement setting it for the
gen2 version.
This is used to tell the HW who the recipient of the packet is, so that
the appropriate data rate can be selected.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230428150833.218605-12-martin.kaistra@linutronix.de
|
