- 07 Dec, 2023 21 commits
-
-
Lorenzo Bianconi authored
This is a preliminary patch to introduce WED support for mt7996 Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Lorenzo Bianconi authored
Introduce mtk_wed_device pointer in mt76_queue structure in order to configure WED chip. Get rid of dev parameter in Q_READ and Q_WRITE macros. Introduce wed parameter to the following routine signatures: - mt76_init_queue - mt76_init_tx_queue This is a preliminary patch to introduce WED support for mt7996 since mt7996 runs two separate WED chips. Signed-off-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to introduce WED support for mt7996 Signed-off-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to introduce WED support for mt7996 Signed-off-by:
-
Lorenzo Bianconi authored
mt76_mmio_wed_offload_enable and mt76_mmio_wed_offload_disable routines will be reused by mt7996 driver for wed support. Signed-off-by:
-
Lorenzo Bianconi authored
Move mt76_mmio_wed_init_rx_buf and mt76_mmio_wed_release_rx_buf routines in common code. This is a preliminary patch to introduce WED support for mt7996 Signed-off-by:
-
Wu Yunchuan authored
No need cast (void *) to (struct mt7615_phy *). Signed-off-by:
Wu Yunchuan <yunchuan@nfschina.com> Signed-off-by:
-
Christian Marangi authored
Permit to load precal from NVMEM cell for mt7915. The NVMEM cell must be named "precal" to be correctly loaded. NVMEM cell must already account the correct offset and be placed after the EEPROM as the function expect the data right from the start. Tested-by:
Shiji Yang <yangshiji66@outlook.com> Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Signed-off-by:
-
Christian Marangi authored
Generilize mt76_get_of_eeprom_from_nvmem to use alternative cell name by passing the cell name as an arg and expose it. Rename it to mt76_get_of_data_from_nvmem to better reflect the now more generic usage. This is to permit driver to load additional cell, like precal cell. Tested-by:
-
Christian Marangi authored
Since mt76_get_of_eeprom is not used by mt7915 anymore, unexport it and make it static again. Also drop offset arg as it's only supported for MTD and was always set to 0, hardcode the MTD functio instead. Signed-off-by:
-
Christian Marangi authored
Limit support for precal loading for mt7915 only to MTD. Passing data from DT doesn't support offset and NVMEM require a different cell name and doesn't support offset hence only MTD way is actually supported. Rename mt76_get_of_eeprom_from_mtd to mt76_get_of_data_from_mtd as it is now used for a more generic purpose and export it. Signed-off-by:
-
Christian Marangi authored
Fix typo in mt76_get_of_eeprom_from_nvmem where eeprom was misspelled as epprom. Fixes: 5bef3a40 ("wifi: mt76: add support for providing eeprom in nvmem cells") Signed-off-by:
-
Christian Marangi authored
Commit 495184ac ("mt76: mt7915: add support for applying pre-calibration data") was fundamentally broken and never worked. The idea (before NVMEM support) was to expand the MTD function and pass an additional offset. For normal EEPROM load the offset would always be 0. For the purpose of precal loading, an offset was passed that was internally the size of EEPROM, since precal data is right after the EEPROM. Problem is that the offset value passed is never handled and is actually overwrite by offset = be32_to_cpup(list); ret = mtd_read(mtd, offset, len, &retlen, eep); resulting in the passed offset value always ingnored. (and even passing garbage data as precal as the start of the EEPROM is getting read) Fix this by adding to the current offset value, the offset from DT to correctly read the piece of data at the requested location. Cc: stable@vger.kernel.org Fixes: 495184ac ("mt76: mt7915: add support for applying pre-calibration data") Signed-off-by:
-
Yi-Chia Hsieh authored
Fix the uninitialized variable warning in mt7996_mac_tx_free. Fixes: 2461599f ("wifi: mt76: mt7996: get tx_retries and tx_failed from txfree") Signed-off-by:
Yi-Chia Hsieh <yi-chia.hsieh@mediatek.com> Signed-off-by:
-
Rong Yan authored
The mtcl table, configured by platform vendor, provides regulatory information for 5.9/6 GHz channels. mt792x should work on corresponding channels supported by mtcl. This patch would parse the settings in mtcl table and apply the result into chip side. Signed-off-by:
Rong Yan <rong.yan@mediatek.com> Co-developed-by:
Deren Wu <deren.wu@mediatek.com> Signed-off-by:
-
Ryder Lee authored
Add ability to explicitly forbid LED registration using DT led\status = "disabled". Tested-by:
Alexey D. Filimonov <alexey@filimonic.net> Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Ping-Ke Shih authored
Don't enable firmware debug mode to prevent SER flow stuck due to fail to reset payload buffer, and clear HALT_C2H_INT to avoid handling unexpected interrupt at beginning. 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-6-pkshih@realtek.com
-
Chia-Yuan Li authored
To diagnose the reason why firmware or hardware get abnormal, add to dump MAC registers related to counters and interrupt masks. With these values, people can classify problems and check if registers values are unexpected, and then correct them. However, it could possible false alarm because firmware triggers this SER event by wrong conditions that we should correct it at firmware or register settings. In field, SER might happen under special conditions, and very hard to happen again, so dump lots of registers to provide rich information to catch the problem. Signed-off-by:
Chia-Yuan Li <leo.li@realtek.com> Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
To activate SER (system error recovery) in firmware, we have to configure IMR to trigger interrupts, and then SER can check registers to know if it need to reset hardware or notify driver to re-configure whole settings. Signed-off-by:
-
Zong-Zhe Yang authored
Extend FW program counter dump for Wi-Fi 7 chip. They poll different addresses. Signed-off-by:
-
Zong-Zhe Yang authored
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:
-
- 06 Dec, 2023 2 commits
-
-
Johannes Berg authored
This is just a collection of data and we only read it, so make it const. Signed-off-by:Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This function has so many arguments already, before adding yet another one, refactor it to take a struct instead. Signed-off-by:
-
- 01 Dec, 2023 17 commits
-
-
Chih-Kang Chang authored
In concurrent mode, when STA interface is scanning, it causes AP interface TX beacon on wrong channel. We modified it to scan with the operating channel when one of the interfaces is already connected. Additionally, STA interface need to stop scan when AP interface is starting to avoid TX beacon on wrong channel. Finally, AP interface need to stop TX beacon when STA interface is scanning and switching to non-OP channel,This prevent other device to get beacons on wrong channel. Signed-off-by:
Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by:
-
Chih-Kang Chang authored
We add a scanning check to avoid entering IPS after ROC (remain on channel) during scanning. Additionally, When P2P scanning, the flow is `1. p2p_listen step` and `2. configure filter` and `3. p2p_scan starts` in wpas, but in kernel, cfg80211 uses another workqueue to notify driver the filter change, so sometimes we see (1 > 3 > 2), that will cause Rx filter related to scan to be cleared. Therefore, we add a scanning check when configure filter to avoid scan results to be filtered. Finally, we cancel the ROC delayed workqueue before entering ROC to avoid entering twice, which might cause leaving ROC too early. Signed-off-by:
-
Po-Hao Huang authored
The interval between sending each probe request is regulated. Before this patch, some packets are not sent out properly because of our HW limit. Extend the 6 GHz channel dwell time to cope with this. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
Po-Hao Huang authored
The attempt to enter power save mode might fail if there are still beacons pending in the queue. This sometimes happens after stopping P2P GO or AP mode. Extend stop AP function and flush all beacons to resolve this. Signed-off-by:
-
Stanislaw Gruszka authored
We can run PCI/MMIO devices together with USB devices in the system. Make watchdog parameter per device to avoid situation when plugin USB device change modparam_watchdog for PCI/MMIO device. Signed-off-by:
Stanislaw Gruszka <stf_xl@wp.pl> Tested-by:
-
Ilpo Järvinen authored
Neither vendorid nor deviceid in the struct mp_adapter is used so remove them. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
-
Ilpo Järvinen authored
The rtlwifi driver comes with a number of PCI related defines that are unused and many would be provided by PCI core anyway if they'd be needed again. Similarly, the struct rtl_pci_capabilities_header is unused and no driver should come up their own way to access PCI Capabilities anyway. Remove the unused/duplicated PCI related defines and struct. Signed-off-by:
-
Ilpo Järvinen authored
_rtl8821ae_clear_pci_pme_status() accesses the upper byte of the Power Management Control/Status register (PMCS) with literal 5 offset. Access the entire PMCS register using defines from pci_regs.h to improve code readability. While at it, remove the obvious comment and tweak debug prints slightly to not sound misleading. Signed-off-by:
-
Ilpo Järvinen authored
Add local variable pdev to shorten rtlpci->pdev. Signed-off-by:
-
Ilpo Järvinen authored
Instead of open coding the capability structure search, find the PM Capability using pci_find_capability(). While at it, rename the generic 'cap_pointer' to 'pm_cap' which makes the intent of the code more obvious. Signed-off-by:
-
Ilpo Järvinen authored
Check if PM Capability does not exists and return early which follows the usual error handling pattern. Signed-off-by:
-
Ilpo Järvinen authored
BIT(7) (PME_Status) is first checked and then set unnecessarily. Remove the unnecessary setting for the bit that is already on and adjust the comment related to it. Signed-off-by:
-
Ilpo Järvinen authored
The rtlwifi driver accesses PCIe capabilities through custom config offsets. Convert the accesses to use the normal PCIe capability accessors. Signed-off-by:
-
Ilpo Järvinen authored
The rtlwifi driver comes with custom code to write into PCIe Link Control register. RMW access for the Link Control register requires locking that is already provided by the standard PCIe capability accessors. Convert the custom RMW code writing into LNKCTL register to standard RMW capability accessors. The accesses are changed to cover the full LNKCTL register instead of touching just a single byte of the register. Fixes: 0c817338 ("rtl8192ce: Add new driver") Cc: stable@vger.kernel.org Signed-off-by:
-
Ilpo Järvinen authored
Ever since introduction in the commit 0c817338 ("rtl8192ce: Add new driver") the rtlwifi code has, according to comments, attempted to disable/enable ASPM of the upstream bridge by writing into its LNKCTL register. However, the code has never been correct because it performs the writes to the device instead of the upstream bridge. Worse yet, the offset where the PCIe capabilities reside is derived from the offset of the upstream bridge. As a result, the write will use an offset on the device that does not relate to the LNKCTL register making the ASPM disable/enable code outright dangerous. Because of those problems, there is no indication that the driver needs disable/enable ASPM on the upstream bridge. As the Capabilities offset is not correctly calculated for the write to target device's LNKCTL register, the code is not disabling/enabling device's ASPM either. Therefore, just remove the upstream bridge related ASPM disable/enable code entirely. The upstream bridge related ASPM code was the only user of the struct mp_adapter members num4bytes, pcibridge_pciehdr_offset, and pcibridge_linkctrlreg so those are removed as well. Note: This change does not remove the code related to changing the device's ASPM on purpose (which is independent of this flawed code related to upstream bridge's ASPM). Suggested-by:
Bjorn Helgaas <bhelgaas@kernel.org> Fixes: 0c817338 ("rtl8192ce: Add new driver") Fixes: 886e14b6 ("rtlwifi: Eliminate raw reads and writes from PCIe portion") Cc: stable@vger.kernel.org Signed-off-by:
-
Martin Blumenstingl authored
Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth combo card. The error he observed is identical to what has been fixed in commit e967229e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem. Lukas found that disabling or limiting RX aggregation works around the problem for some time (but does not fully fix it). In the following discussion a few key topics have been discussed which have an impact on this problem: - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller which prevents DMA transfers. Instead all transfers need to go through the controller SRAM which limits transfers to 1536 bytes - rtw88 chips don't split incoming (RX) packets, so if a big packet is received this is forwarded to the host in it's original form - rtw88 chips can do RX aggregation, meaning more multiple incoming packets can be pulled by the host from the card with one MMC/SDIO transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation and BIT_EN_PRE_CALC makes the chip honor the limits more effectively) Use multiple consecutive reads in rtw_sdio_read_port() and limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. This allows receiving a buffer that's larger than the hosts max_req_size (number of bytes which can be transferred in one MMC/SDIO transfer). As a result of this the skb_over_panic error is gone as the rtw88 driver is now able to receive more than 1536 bytes from the card (either because the incoming packet is larger than that or because multiple packets have been aggregated). In case of an receive errors (-EILSEQ has been observed by Lukas) we need to drain the remaining data from the card's buffer, otherwise the card will return corrupt data for the next rtw_sdio_read_port() call. Fixes: 65371a3f ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Reported-by:
Lukas F. Hartmann <lukas@mntre.com> Closes: https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/Suggested-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
-
Ping-Ke Shih authored
Add functions to configure HCI, DMAC (data MAC), DLE (data link engine), HFC (HCI flow control), PLE (payload engine) and etc for WiFi 7 chips. Signed-off-by:
-
