- 19 Sep, 2022 26 commits
-
-
Ping-Ke Shih authored
Seaprate calling of rtw89_h2c_tx() out of if-expression, and bypass the return value to upper caller. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220914035034.14521-2-pkshih@realtek.com
-
Chin-Yen Lee authored
Different chips use different register and mask for tx dma channels, so concentrate them. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Chin-Yen Lee authored
Some PCI and MAC registers are changed for different chips and correct them accordingly. And HCI MAD functions belongs to MAC core, so move it to mac.h/.c. Signed-off-by:
-
Zong-Zhe Yang authored
For 8852C, rtw89_pci_lv1rst_stop_dma() and rtw89_pci_lv1rst_start_dma() are offloaded to FW L1 reset flow. So, driver no longer needs to do them. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Kuan-Chung Chen authored
Add ops set_tid_config to support TID specific configuration. We currently only support ampdu setting. The command example is: iw wlan0 set tidconf tids 0x3 ampdu off iw wlan0 set tidconf peer xx:xx:xx:xx:xx:xx tids 0x2 ampdu on Signed-off-by:
Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by:
-
Kuan-Chung Chen authored
Support setting HE GI and LTF values to the kernel via nl80211. We currently only support some GI and LTF values settings. The command example is: iw wlan0 set bitrates he-gi-2.4 0.8 he-ltf-2.4 2 Signed-off-by:
-
Ping-Ke Shih authored
The variable cnt_connecting is to indicate if we are connecting to an AP. This is an important clue for coexistence to assign more time slot to WiFi side in this situation to ensure WiFi can establish connection. Without this patch, compiler warns: drivers/net/wireless/realtek/rtw89/coex.c:3244:25: warning: variable 'cnt_connecting' set but not used [-Wunused-but-set-variable] Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
-
Ching-Te Ku authored
To reduce register IO, combine set_gnt_wl/set_gnt_bt to set the same register one time. Because RTL8852C use different register to control antenna path, so make correction of path control related debug logs. Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
RTL8852C don't need to send the data trace_step which used to tell firmware how many TDMA steps should record. Remove the member. Signed-off-by:
-
Ching-Te Ku authored
Show TDMA information containing TDMA policy and time slot of Wi-Fi/BT in debug message to check things are in expected. The v1 format contains additional header, and remaining part is the same as original. So 8852CE selects v1 version, and then everything like original. Signed-off-by:
-
Ching-Te Ku authored
Parsing firmware error message from original version and v1 reports to show up exception counter of commands from firmware in debug message. Then, we can make sure exchange commands are correct totally. In the later version Wi-Fi firmware(v1), the report format was changed. With this update, we can yield correct report from proper struct. Signed-off-by:
-
Ching-Te Ku authored
Because RTL8852A/RTL8852C use different firmware buffer size to send C2H packet, it's necessary to use different size to parse C2H report. Signed-off-by:
-
Ching-Te Ku authored
The later version Wi-Fi firmware will report null data TX times, so the structure is different from before. Signed-off-by:
-
Ping-Ke Shih authored
With void pointer, we don't need to cast to 'u8 *' by one by. Signed-off-by:
-
Hector Martin authored
Add the new module-instance/antenna-sku properties required to select WiFi firmwares properly to all board device trees. Signed-off-by:
Hector Martin <marcan@marcan.st> Reviewed-by:
Mark Kettenis <kettenis@openbsd.org> Acked-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Hector Martin authored
This chip is present on Apple M1 (t8103) platforms: * atlantisb (apple,j274): Mac mini (M1, 2020) * honshu (apple,j293): MacBook Pro (13-inch, M1, 2020) * shikoku (apple,j313): MacBook Air (M1, 2020) * capri (apple,j456): iMac (24-inch, 4x USB-C, M1, 2020) * santorini (apple,j457): iMac (24-inch, 2x USB-C, M1, 2020) Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by:
-
Hector Martin authored
These newer PCIe core revisions include new sets of registers that must be used instead of the legacy ones. Introduce a brcmf_pcie_reginfo to hold the specific register offsets and values to use for a given platform, and change all the register accesses to indirect through it. Reviewed-by:
-
Hector Martin authored
Newer chips used on Apple platforms have a max_rxbufpost greater than 512, which causes warnings when brcmf_msgbuf_rxbuf_data_fill tries to put more entries in the ring than will fit. Increase the ring sizes to 1024. Reviewed-by:
-
Hector Martin authored
On Device Tree platforms, it is customary to be able to set the MAC address via the Device Tree, as it is often stored in system firmware. This is particularly relevant for Apple ARM64 platforms, where this information comes from system configuration and passed through by the bootloader into the DT. Implement support for this by fetching the platform MAC address and adding or replacing the macaddr= property in nvram. This becomes the dongle's default MAC address. On platforms with an SROM MAC address, this overrides it. On platforms without one, such as Apple ARM64 devices, this is required for the firmware to boot (it will fail if it does not have a valid MAC at all). Reviewed-by:
-
Hector Martin authored
On Apple platforms, firmware selection uses the following elements: Property Example Source ============== ======= ======================== * Chip name 4378 Device ID * Chip revision B1 OTP * Platform shikoku DT (ARM64) or ACPI (x86) * Module type RASP OTP * Module vendor m OTP * Module version 6.11 OTP * Antenna SKU X3 DT (ARM64) or ACPI (x86) In macOS, these firmwares are stored using filenames in this format under /usr/share/firmware/wifi: C-4378__s-B1/P-shikoku-X3_M-RASP_V-m__m-6.11.txt To prepare firmwares for Linux, we rename these to a scheme following the existing brcmfmac convention: brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<mod_type>-\ <mod_vendor>-<mod_version>-<antenna_sku>.txt The NVRAM uses all the components, while the firmware and CLM blob only use the chip/revision/platform/antenna_sku: brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<antenna_sku>.bin e.g. brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.bin In addition, since there are over 1000 files in total, many of which are symlinks or outright duplicates, we deduplicate and prune the firmware tree to reduce firmware filenames to fewer dimensions. For example, the shikoku platform (MacBook Air M1 2020) simplifies to just 4 files: brcm/brcmfmac4378b1-pcie.apple,shikoku.clm_blob brcm/brcmfmac4378b1-pcie.apple,shikoku.bin brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-u.txt This reduces the total file count to around 170, of which 75 are symlinks and 95 are regular files: 7 firmware blobs, 27 CLM blobs, and 61 NVRAM config files. We also slightly process NVRAM files to correct some formatting issues. To handle this, the driver must try the following path formats when looking for firmware files: brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.txt * brcm/brcmfmac4378b1-pcie.apple,shikoku.txt * Not relevant for NVRAM, only for firmware/CLM. The chip revision nominally comes from OTP on Apple platforms, but it can be mapped to the PCI revision number, so we ignore the OTP revision and continue to use the existing PCI revision mechanism to identify chip revisions, as the driver already does for other chips. Unfortunately, the mapping is not consistent between different chip types, so this has to be determined experimentally. Reviewed-by: -
Hector Martin authored
On Apple ARM64 platforms, firmware selection requires two properties that come from system firmware: the module-instance (aka "island", a codename representing a given hardware platform) and the antenna-sku. We map Apple's module codenames to board_types in the form "apple,<module-instance>". The mapped board_type is added to the DTS file in that form, while the antenna-sku is forwarded by our bootloader from the Apple Device Tree into the FDT. Grab them from the DT so firmware selection can use them. Reviewed-by:
-
Hector Martin authored
On Apple platforms, the One Time Programmable ROM in the Broadcom chips contains information about the specific board design (module, vendor, version) that is required to select the correct NVRAM file. Parse this OTP ROM and extract the required strings. Note that the user OTP offset/size is per-chip. This patch does not add any chips yet. Reviewed-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Hector Martin authored
Apple platforms have firmware and config files identified with multiple dimensions. We want to be able to find the most specific firmware available for any given platform, progressively trying more general firmwares. To do this, first add support for passing in multiple board_types, which will be tried in sequence. Since this will cause more log spam due to missing firmwares, also switch the secondary firmware fecthes to use the _nowarn variant, which will not log if the firmware is not found. Signed-off-by:
-
Hector Martin authored
Now that the firmware fetcher can handle per-board CLM files, load the CLM blob alongside the other firmware files and change the bus API to just return the existing blob, instead of fetching the filename. This enables per-board CLM blobs, which are required on Apple platforms. Acked-by:
-
Hector Martin authored
Teach brcm_alt_fw_paths to correctly split off variable length extensions, and enable alt firmware lookups for the CLM blob firmware requests. Apple platforms have per-board CLM blob files. Acked-by:
-
Hector Martin authored
This binding is currently used for SDIO devices, but these chips are also used as PCIe devices on DT platforms and may be represented in the DT. Re-use the existing binding and add chip compatibles used by Apple T2 and M1 platforms (the T2 ones are not known to be used in DT platforms, but we might as well document them). Then, add properties required for firmware selection and calibration on M1 machines. Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
- 12 Sep, 2022 14 commits
-
-
Bitterblue Smith authored
It looks like a leftover from copying rtl8xxxu_update_rate_mask, which is used with the gen1 chips. It wasn't causing any problems for my RTL8188FU test device, but it's clearly a mistake, so remove it. Fixes: f653e690 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function") Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by:
-
Bitterblue Smith authored
Found by comparing with the vendor driver. Currently this affects only the RTL8192EU, which is the only gen2 chip with 2 TX paths supported by this driver. It's unclear what kind of effect the mistake had in practice, since I don't have any RTL8192EU devices to test it. Fixes: e1547c53 ("rtl8xxxu: First stab at adding IQK calibration for 8723bu parts") Signed-off-by:
-
Po-Hao Huang authored
The size limit of H2C commands is 2048. With regulatory that enables U-NII-6 ~ UNII-8 channels, channel list length combining with channel info length will exceed that. Split the channel list to parts and do scan multiple times to workaround that. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
Po-Hao Huang authored
This enables hw_scan function for 52c. The mechanism is similar to 52a except that it adds modifications required for 6G channels and extends the command length to make driver compatible to both newer and existing firmware. Signed-off-by:
-
Chin-Yen Lee authored
8852c transmits packets with slow response in deep ps mode, and lead to low throughput. We need to call tx_wake for each pakcet to trigger firmware wake earlier to avoid it. Signed-off-by:
-
Chin-Yen Lee authored
rtw8852c could support deep ps mode if the firmware version is greater than 0.17.34. Signed-off-by:
-
Chia-Yuan Li authored
With suitable response rate, it can acknowledge peer packets are received. Otherwise, peer could re-transmit again due to missing of ACK frames. To achieve this, refer to RX rate and CMAC table to choose the smaller as initial response rate. Signed-off-by:
Chia-Yuan Li <leo.li@realtek.com> Signed-off-by:
-
Yi-Tang Chiu authored
With one path TX for 1SS rate, it can transmit higher power in 6GHz band to yield better performance in high attenuation circumstance. Signed-off-by:
Yi-Tang Chiu <chiuyitang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
The range of calibration time of RX DCK is quite wide from ~40us to ~1300us by experiments, and probability is about 0.1% for the cases larger than 1000us. Though it can retry calibration and get positive result, it will spend more time. Therefore, enlarge it to avoid warning and duplicate calibration. Signed-off-by:
-
Ping-Ke Shih authored
Enable MU-MIMO interference cancellation (MUIC) to yield expected performance of receiving MU-MIMO packets on 6GHz. Signed-off-by:
-
Eric Huang authored
Since control register address for DIG are different per IC, add a new struct rtw89_dig_regs in chip info for each IC to define their own address. Signed-off-by:
Eric Huang <echuang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
Check RSSI strength to decide which path is better, and then set TX path accordingly. Signed-off-by:
-
Ping-Ke Shih authored
Originally, we show average signal strength. To support TX diversity, this patch prepares strength per path, then we can decide TX path. RSSI: -54 dBm (raw=112, prev=110) [-57, -52] Signed-off-by:
-
Ping-Ke Shih authored
In order to support TX diversity, add a function to control TX path. Signed-off-by:
-
