summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89/fw.h
AgeCommit message (Collapse)Author
2024-01-12wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operationPing-Ke Shih
Since coming WiFi 7 and existing chips use different update_beacon() format, add to abstract selection of H2C command. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091359.67636-1-pkshih@realtek.com
2024-01-12wifi: rtw89: add H2C command to download beacon frame for WiFi 7 chipsPing-Ke Shih
The firmware of coming WiFi 7 chips can support more AP functions, like virtual AP, so extend format of download beacon frame to configure them. Currently rtw89 only enables AP mode as old chips, so leave new fields zeros. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091333.67484-1-pkshih@realtek.com
2024-01-12wifi: rtw89: use struct to fill H2C command to download beacon framePing-Ke Shih
Download beacon frame via H2C command for AP mode, and then firmware can issues beacon periodically. Originally TIM offset minus fixed 24 bytes of frame header implicitly in macro, and this patch explicitly uses ieee80211_hdrlen() to get header length, but expected to change nothing at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091325.67424-1-pkshih@realtek.com
2024-01-12wifi: rtw89: add new H2C command to pause/sleep transmitting by MAC IDPing-Ke Shih
New H2C command is introduced to pause/sleep transmitting. That extends more bits to support more MAC ID, and currently we still configure 256 MAC ID at most. This new command is always used by coming WiFi 7 chips, and existing chips can use old or new command because firmware still preserves the old one. Add a firmware feature flag to determine which command is adopted according to firmware version. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091315.67358-1-pkshih@realtek.com
2024-01-12wifi: rtw89: fw: use struct to fill BA CAM H2C commandsPing-Ke Shih
The WiFi 6 chips use these commands to create BA CAM entry when RX BA session is established, this BA CAM can record whether packets are received or not, then reply BA for current status. This patch doesn't change logic. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091245.67220-1-pkshih@realtek.com
2024-01-12wifi: rtw89: add chip_ops::h2c_ba_cam() to configure BA CAMPing-Ke Shih
Since chips could use different version of BA CAM H2C command, add a chip_ops to abstract the operation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-4-pkshih@realtek.com
2024-01-12wifi: rtw89: mac: add feature_init to initialize BA CAM V1Ping-Ke Shih
Add a call of feature_init() when bringing interface up. For now, the feature is to reset BA CAM V1 that is only used by upcoming 8922A. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-3-pkshih@realtek.com
2024-01-12wifi: rtw89: add firmware H2C command of BA CAM V1Ping-Ke Shih
BA CAM is used to generate BA frame for received AMPDU packets. To support WiFi 7, change format from V0 to have more fields and enlarge entry number for new need. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-2-pkshih@realtek.com
2023-12-15wifi: rtw89: add DBCC H2C to notify firmware the statusPing-Ke Shih
To support MLO of WiFi 7, we should configure hardware as DBCC mode, and notify this status to firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-6-pkshih@realtek.com
2023-12-15wifi: rtw89: phy: print out RFK log with formatted stringPing-Ke Shih
With formatted string loaded from firmware file, we can use the formatted string ID and get corresponding string, and then use regular rtw89_debug() to show the message if debug mask of RFK is enabled. If the string ID doesn't present, fallback to print plain hexadecimal. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-7-pkshih@realtek.com
2023-12-15wifi: rtw89: parse and print out RFK log from C2H eventsPing-Ke Shih
RFK log events contains two types. One called RUN log is to reflect state during RFK is running, and it replies on formatted string loaded from firmware file, but print this type as plain hexadecimal only in this patch. The other is REPORT log that reflects the final result of a RFK, and each calibration has its own struct to carry many specific information. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-6-pkshih@realtek.com
2023-12-15wifi: rtw89: load RFK log format string from firmware filePing-Ke Shih
To debug RFK (RF calibration) in firmware, it sends log via firmware C2H events to driver with string format ID and four arguments. Load formatted string from firmware file, and the string ID can get back its string. Then, use regular print format to show the message. This firmware element layout looks like +============================================+ | elm ID | elm size | version | | +----------+----------+----------+-----------+ | | nr |rsvd |rfk_id|rsvd| +--------------------------------------------+ | offset[] (__le16 * nr) | | ... | +--------------------------------------------+ | formatted string with null termintor (*nr) | | ... | +============================================+ * a firmware file can contains more than one elements with this element ID named RTW89_FW_ELEMENT_ID_RFKLOG_FMT (19), because many RFK needs its own formatted strings, so add 'rfk_id' to know it belongs to which RFK. * the 'formatted string' just follow 'offset[]' without padding to align 32bits. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-4-pkshih@realtek.com
2023-12-15wifi: rtw89: fw: add version field to BB MCU firmware elementPing-Ke Shih
8922AE has more than one hardware version, and they use different BB MCU firmware, so occupy a byte from element priv[] to annotate version. Since there are more than one firmware and only matched version is adopted, return 1 to ignore not matched firmware. +===========================================+ | elm ID | elm size | version | | +----------+----------+----------+----------+ | | element_priv[] | +-------------------------------------------+ change to | v +===========================================+ | elm ID | elm size | version | | +----------+----------+----------+----------+ | | cv | element_rsvd[] | +-------------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-3-pkshih@realtek.com
2023-12-15wifi: rtw89: fw: load TX power track tables from fw_elementPing-Ke Shih
The TX power track tables are used to define compensation power reflected to thermal value. Currently, we have 16 (2 * 4 * 2) tables made by combinations of {negative/positive thermal value, 2GHz/2GHz-CCK/5GHz/6GHz, path A/B} Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-2-pkshih@realtek.com
2023-12-07wifi: rtw89: 8922a: configure CRASH_TRIGGER FW featureZong-Zhe Yang
RTL8922A FW supports CRASH_TRIGGER feature from v0.34.30.0. After it, debugfs fw_crash can accept type 1 on RTL8922A to trigger firmware crash and verify L2 recovery. Besides, RTL8922A sync address offset of reserved payload engine. And, SER (system error recovery) tweaks conversion from WCPU address to indirect access address for RTL8922A. The new conversion works for all supported chips. 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/20231204080751.15354-2-pkshih@realtek.com
2023-09-22wifi: rtw89: load TX power related tables from FW elementsZong-Zhe Yang
The following FW elements are recognized, and then the valid entries in them are loaded into SW struct case by case. * TX power by rate * TX power limit 2 GHz * TX power limit 5 GHz * TX power limit 6 GHz * TX power limit RU 2 GHz * TX power limit RU 5 GHz * TX power limit RU 6 GHz * TX shape limit * TX shape limit RU One single firmware file can contain multiples of each of the above FW elements. Each of them is configured with a target RFE (RF front end) type. We choose one of the multiples to load based on RFE type. If there are multiples of the same FW elements with the same target RFE type. The last one will be applied. We don't want to have many loading variants for above FW elements. Even if between different chips or between different generations, we would like to maintain only one single set of loadings. So, the loadings are designed to consider compatibility. The main concepts are listed below. * The driver structures, which are used to cast binary entry from FW, cannot insert new members in the middle. If there are something new, they should always be appended at the tail. * Each binary entry from FW uses a dictionary way containing a key set and a data. The keys in the key set indicate where to put the data. * If size of driver struct and size of binary entry do not match when loading, it means the number of keys in the key set are different. Then, we deal with compatibility. No matter which one has more keys, we take/use zero on those mismatched keys. If driver struct is bigger (backward compatibility): e.g. SW uses two keys, but FW is built with one key. Then, put the data of FW(keyX) into SW[keyX][0]. If binary entry is bigger (forward compatibility): e.g. FW is built with two keys, but SW uses one key. Then, only take the data of FW(keyX, keyY = 0) into SW[keyX] Besides, chip info setup flow is tweaked a bit for the following. * Before loading FW elements, we need to determine chip RFE via efuse. * Setting up RFE parameters depends on loading FW elements ahead. 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/20230920074322.42898-8-pkshih@realtek.com
2023-09-18wifi: rtw89: mcc: track beacon offset and update when neededZong-Zhe Yang
In MCC STA+GC mode, the offset between TBTTs of remote AP and remote GO might change. If the change is larger than tolerance, we should update MCC after re-calculating parameters for new things. So, we track that in rtw89_track_work() now. And, we add MCC update flow to tell FW either to change durations of roles or to replace entire pattern according to how MCC plans BT slot. 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/20230908031145.20931-6-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: propagate an argument include_bb for BB MCU firmwarePing-Ke Shih
Though WiFi 7 chips need BB MCU firmware, we don't download it in probe stage. Instead, only bring interface up under normal operation or WoWLAN mode. So, add an argument to assist download flow to setup download settings properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-6-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: add checking type for variant type of firmwarePing-Ke Shih
For WiFi 6 chips, there is only single one firmware i.e. WiFi CPU firmware, so no need an argument to discriminate them. For WiFi 7 chips, BB MCU firmware is introduced, and we need to check it ready after downloading. For each type of firmware, we need to check corresponding hardware ready bit. After downloading all firmware, check status code to determine if all things are ready. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-5-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: move polling function of firmware path ready to an ↵Ping-Ke Shih
individual function To download firmware, we need to check path is ready. There are two kinds of path -- one is to download firmware header, and the other is to download firmware body. Since the polling method is different from WiFi 7 chips, make it to be an individual function, and then we can reuse the download flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-2-pkshih@realtek.com
2023-09-07wifi: rtw89: fix typo of rtw89_fw_h2c_mcc_macid_bitmap()Zong-Zhe Yang
Fix a typo where `bitamp` should be `bitmap`. Don't change functionality at all. 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/20230831053133.24015-6-pkshih@realtek.com
2023-08-03wifi: rtw89: return failure if needed firmware elements are not recognizedPing-Ke Shih
WiFi 7 chips doesn't have static const tables defined in driver. If tables aren't loaded properly from firmware file, driver can get NULL pointer access exception. One way is to add the checking statements when trying to access these tables, but I choose to check them right after loading firmware elements from firmware file, so I don't need to add error handlers everywhere. Currently, the needed firmware elements of WiFi 6 chips are all zero, and coming WiFi 7 chip will need at least BB MCU, parameters of BB and RF. We will add them after 8922AE is verified. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-9-pkshih@realtek.com
2023-08-03wifi: rtw89: add to parse firmware elements of BB and RF tablesPing-Ke Shih
The tables of BB and RF parameters are pairs of {addr, value}. Load them and convert from little-endian to CPU order, and show the version to clear which version we are using. rtw89_8922ae 0000:03:00.0: Firmware element BB version: 00 04 00 00 rtw89_8922ae 0000:03:00.0: Firmware element radio A version: 00 13 00 00 rtw89_8922ae 0000:03:00.0: Firmware element NCTL version: 00 05 00 00 We use tables defined in firmware elements with higher priority than original static const tables defined in driver, because WiFi 7 chips will not define the tables in driver, and existing chips can possibly migrate to the new design one by one. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-8-pkshih@realtek.com
2023-08-03wifi: rtw89: introduce infrastructure of firmware elementsPing-Ke Shih
In order to pack more data into firmware file, we introduce firmware elements and append BB_MCU firmware first. The first part of new firmware file is still unchanged firmware of WiFi CPU, so the new firmware format can be backward compatible to old format. The new elements part consists of ID and size basically, which can append more elements simply. To avoid unaligned access in certain platform and be easy to read, headers of all elements start at 16-byte aligned address. +===========================================+ | original firmware | | +-------------+ | | padding | +===========================================+ | elm ID 1 | elm size | other header data | +----------+----------+ | | | +-------------------------------------------+ | content (variable length) | | +-------------+ | | padding | +===========================================+ | elm ID 2 | elm size | other header data | +----------+----------+ | | | +-------------------------------------------+ | content (variable length) | | +-----------------------+ | | (no padding for the last one) +===================+ More detail of element header is shown below. The additional fields 'version' and 'element_priv[]' are meta data of elements, so that we can know element version easily, and element_priv[] provide specific fields for certain element, such as RF path index for RF parameter tables. +===========================================+ | elm ID | elm size | version | rsvd0 | +----------+----------+----------+----------+ | rsvd1/2 | element_priv[] | +-------------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-7-pkshih@realtek.com
2023-08-03wifi: rtw89: add firmware parser for v1 formatPing-Ke Shih
A firmware with v1 format contains many sections to download. Add parser to read section type, target address, length, checksum and so on, and then download the section to WiFi CPU with proper location. The additional dynamic header length named dynamic_hdr_len is used to skip content of dynamic header containing compiler flags of firmware, which can help to determine variant firmware build, but currently rtw89 only use single one variant. So, just skip the content. The layout of a WiFi CPU firmware with v1 format looks like: +---------------------------------------+ | Header (12 words) | +---------------------------------------+ | Section header 1 (4 words) | | Section header 2 (4 words) | | Section header 3 (4 words) | | ... | +---------------------------------------+ | Dynamic header (variable length) | +---------------------------------------+ | Data used & pointed by section | | ... | +---------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-5-pkshih@realtek.com
2023-08-03wifi: rtw89: introduce v1 format of firmware headerPing-Ke Shih
New firmware header is used by upcoming WiFi 7 chips to have more information, so use common field w3[31:24] to determine header version, and then use corresponding function to read firmware version and commit ID: rtw89_8852be 0000:03:00.0: Firmware version 0.29.29.1 (799134c3), cmd version 1, type 5 rtw89_8852be 0000:03:00.0: Firmware version 0.29.29.1 (799134c3), cmd version 1, type 3 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-4-pkshih@realtek.com
2023-08-03wifi: rtw89: support firmware log with formatted textChin-Yen Lee
Original firmware log which is sent via C2H message bloats code size of firmware and is also length-limited. So we put some common log into format file, and firmware could use a log ID and some variables in C2H message to map a formatted text via pre-designed rule. 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/20230801021127.15919-3-pkshih@realtek.com
2023-08-01wifi: rtw89: add C2H RA event V1 to support WiFi 7 chipsPing-Ke Shih
WiFi 7 chips have more rate mode (EHT), higher MCS and more bandwidth, so define and use reserved bits to carry these information in C2H events. Also, the SS/MCS encoded bits of VHT and HE are changed, so define V1 masks for them. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-9-pkshih@realtek.com
2023-08-01wifi: rtw89: use struct to access RA reportPing-Ke Shih
RA (rate adaptive), a mechanism to select proper rate, is implemented in firmware, and this report is used to tell driver TX rate it is currently using. Use struct to access this report, and 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/20230728070252.66525-8-pkshih@realtek.com
2023-08-01wifi: rtw89: use struct to access firmware C2H event headerPing-Ke Shih
Firmware C2H events contain two-word header which can indicate category, class, function and length of received events. Use struct to access them, and 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/20230728070252.66525-7-pkshih@realtek.com
2023-08-01wifi: rtw89: add H2C RA command V1 to support WiFi 7 chipsPing-Ke Shih
H2C RA V1 command adds two words to support WiFi 7 chips, which can possibly support up to 4SS rates. Because current chips have only 2SS rates, leave the fields blank for now. The main changes are to set extended bits of EHT mode and bandwidth -- add a bit for EHT mode; add a bit to enumerate 320MHz channel bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-6-pkshih@realtek.com
2023-08-01wifi: rtw89: use struct to set RA H2C commandPing-Ke Shih
RA (rate adaptive) H2C command is used to tell firmware which rates can be used for specified MAC ID. Basically, this commit doesn't change result. Only change to set two 32-bit instead of continual 8-byte rate masks one by one. Originally, we only set 5-byte masks, because existing WiFi 6 2SS chips only need 5-byte masks. Setting two 32-bit masks will be more efficient and also can support coming WiFi 7 2SS chips containing more rates. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-5-pkshih@realtek.com
2023-06-21wifi: rtw89: use struct to parse firmware headerPing-Ke Shih
A firmware contains basic header, sections and optional dynamic header. Define them by a struct, so it will be easier to understand the layout, and also simply access these elements. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230616060601.28460-1-pkshih@realtek.com
2023-06-08wifi: rtw89: 8851b: enable hw_scan supportPo-Hao Huang
This enables hw_scan for 8851b after firmware version 0.29.37.1. Extend the channel info struct with padding zeros so newer firmware can work properly, this change is backward compatible with older firmware. Signed-off-by: Po-Hao Huang <phhuang@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/20230531060713.57203-2-pkshih@realtek.com
2023-05-25wifi: rtw89: use struct to access register-based H2C/C2HPing-Ke Shih
The register-based H2C/C2H are used to exchange commands and events with firmware. The exchange data is limited, but it is relatively simple, because it can work before HCI initialization. To make these code clean, use struct to access them. This patch 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/20230522122513.13559-6-pkshih@realtek.com
2023-05-05wifi: rtw89: change naming of BA CAM from V1 to V0_EXTPing-Ke Shih
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
2023-05-05wifi: rtw89: scan offload wait for FW done ACKZong-Zhe Yang
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
2023-05-05wifi: rtw89: packet offload wait for FW responseZong-Zhe Yang
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
2023-05-05wifi: rtw89: refine packet offload delete flow of 6 GHz probeZong-Zhe Yang
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
2023-04-17wifi: rtw89: update statistics to FW for fine-tuning performancePo-Hao Huang
Since firmware can't have proper statistics, driver update the statistics periodically to firmware to assist in tuning performance. Signed-off-by: Po-Hao Huang <phhuang@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/20230415034900.15679-5-pkshih@realtek.com
2023-04-17wifi: rtw89: use struct instead of macros to set H2C command of hardware scanPing-Ke Shih
Remove macros that set H2C data. Instead, use struct and le32_encode_bits() with mask definition to make it clean. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230415034900.15679-4-pkshih@realtek.com
2023-04-17wifi: rtw89: refine scan function after chanctxPo-Hao Huang
Since we can get the current channel definition each interface maps to, remove store_op function that is no longer required to make things simple. Signed-off-by: Po-Hao Huang <phhuang@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/20230415034900.15679-3-pkshih@realtek.com
2023-04-17wifi: rtw89: coex: send more hardware module info to firmware for 8851BPing-Ke Shih
8851B has various hardware module types, so BT coexistence in firmware needs these information to make decision. Add them to make 8851B work well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230412012831.10519-5-pkshih@realtek.com
2023-04-14wifi: rtw89: add firmware format version to backward compatible with older ↵Ping-Ke Shih
drivers In the discuss threads [1] [2], new firmware format break user space because older drivers can't recognize new firmware format. To avoid this, the new format will be named rtw89/rtw8852b_fw-1.bin and only new driver try to load it. Old drivers only load original and understandable firmware rtw89/rtw8852b_fw.bin. More, new driver will be still backward compatible with old firmware, so original firmware can be used by new driver. If there is newer firmware format is introduced, rtw89/rtw8852b_fw-2.bin will be given. The same rules will be applied like above. So, we will have firmware like below in linux-firmware in the future. rtw89/rtw8852b_fw-2.bin rtw89/rtw8852b_fw-1.bin rtw89/rtw8852b_fw.bin After this patch, MODULE_FIRMWARE() of 8852A/B/C become rtw89/rtw8852a_fw.bin rtw89/rtw8852b_fw-1.bin rtw89/rtw8852c_fw.bin [1] https://lore.kernel.org/linux-wireless/df1ce994-3368-a57e-7078-8bdcccf4a1fd@gmail.com/T/#m24cb43be31a762d0ea70bf07f27ae96c59f6931b [2] https://bugzilla.kernel.org/show_bug.cgi?id=217207 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230320130606.20777-4-pkshih@realtek.com
2023-04-14wifi: rtw89: use schedule_work to request firmwarePing-Ke Shih
Since we are going to load more than one firmware and some are not presented or optional, using asynchronous API request_firmware_nowait() will become complicated. Also, we want to use firmware_request_nowarn() to avoid warning messages when loading optional files. So, use schedule_work to be simpler. To abstract loading a firmware or file, define a struct rtw89_fw_req_info containing a struct firmware and a completion to ensure this firmware is loaded completely. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230320130606.20777-3-pkshih@realtek.com
2023-04-14wifi: rtw89: fw: use generic flow to set/check featuresZong-Zhe Yang
In early feature bitmap obtained from rtw89_early_fw_feature_recognize(), the bits needed to check get increased. It's more friendly to work with RTW89_CHK_FW_FEATURE(). So, we concentrate the flow of iterating FW feature configures and calling RTW89_SET_FW_FEATURE() for various uses. And then, we adjust rtw89_early_fw_feature_recognize() for RTW89_CHK_FW_FEATURE(). 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/20230320130606.20777-2-pkshih@realtek.com
2023-04-14wifi: rtw89: 8852c: add beacon filter and CQM supportPo-Hao Huang
Adding this supports beacon filter and connection quality monitor. To make host CPU wake up less, let firmware perform signal monitoring and beacon processing, then notify driver upon signal changes or beacon loss. This feature needs firmware 0.27.56 or newer to support it. Signed-off-by: Po-Hao Huang <phhuang@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/20230411124832.14965-2-pkshih@realtek.com
2023-03-13wifi: rtw89: coex: Add traffic TX/RX info and its H2CChing-Te Ku
There is a new mechanism which can do some real time performance tuning for WiFi and BT. This TX/RX info is a condition provide to firmware to do traffic analysis. Signed-off-by: Ching-Te Ku <ku920601@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/20230308053225.24377-4-pkshih@realtek.com
2023-03-13wifi: rtw89: coex: Add WiFi role info v2Ching-Te Ku
Remove WiFi traffic busy level & traffic rate from active role information. This information will move to v5 version TDMA cycle info. Signed-off-by: Ching-Te Ku <ku920601@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/20230308053225.24377-3-pkshih@realtek.com
2023-02-22wifi: rtw89: add RNR support for 6 GHz scanPo-Hao Huang
Since 6 GHz band has around 60 channels and more strict rules for active probing. Reduced neighbor report can be used to reduce the channels we scan and get specific target BSS info to probe for. Declare flag WIPHY_FLAG_SPLIT_SCAN_6GHZ so the scan request could be divided into two portions: legacy bands and 6 GHz bands. So RNR information from legacy bands could later be used when 6 GHz scan. When the scan flag NL80211_SCAN_FLAG_COLOCATED_6GHZ is set, cfg80211 will pass down a reduced channel set which contains PSCs and non-PSC with RNR info received in the 2 GHz/5 GHz band. This reduces the scan duration by allowing us to only scan for channels in which APs are currently operating. Signed-off-by: Po-Hao Huang <phhuang@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/20230217120007.8835-1-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-05-11 14:50:10 +0000