Age | Commit message (Collapse) | Author |
|
There are reports that 8822CE fails to work rtw88 with "failed to read DBI
register" error. Also I have a system with 8723DE which freezes the whole
system when the rtw88 is probing the device.
According to [1], platform firmware may not properly power manage the
device during shutdown. I did some expirements and putting the device to
D3 can workaround the issue.
So let's power cycle the device by putting the device to D3 at shutdown
to prevent the issue from happening.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=206411#c9
BugLink: https://bugs.launchpad.net/bugs/1872984
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200928165508.20775-1-kai.heng.feng@canonical.com
|
|
This handles the situation when firmware crashes.
When firmware crashes, it will send an interrupt, and driver will queue
a work for recovery.
In the work, driver will reset it's internal association state, which
includes removing associated sta's macid, resetting vifs' states
and removing keys. After resetting the driver's state, driver will call
rtw_enter_ips() to force the chipset power off to reset the chip.
Finally, driver calls ieee80211_restart_hw() to inform mac80211 stack
to restart.
Since only 8822c firmware supports this feature, the interrupt will only
be triggered when 8822c chipset is loaded.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200925061219.23754-3-tehuang@realtek.com
|
|
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'rtw_pci_init_tx_ring()' and
'rtw_pci_init_rx_ring()' GFP_KERNEL can be used because both functions are
called from a probe function and no spinlock is taken.
The call chain is:
rtw_pci_probe
--> rtw_pci_setup_resource
--> rtw_pci_init
--> rtw_pci_init_trx_ring
--> rtw_pci_init_tx_ring
--> rtw_pci_init_rx_ring
@@
@@
- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL
@@
@@
- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE
@@
@@
- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE
@@
@@
- PCI_DMA_NONE
+ DMA_NONE
@@
expression e1, e2, e3;
@@
- pci_alloc_consistent(e1, e2, e3)
+ dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
- pci_zalloc_consistent(e1, e2, e3)
+ dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
- pci_free_consistent(e1, e2, e3, e4)
+ dma_free_coherent(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_map_single(e1, e2, e3, e4)
+ dma_map_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_unmap_single(e1, e2, e3, e4)
+ dma_unmap_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
- pci_map_page(e1, e2, e3, e4, e5)
+ dma_map_page(&e1->dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
- pci_unmap_page(e1, e2, e3, e4)
+ dma_unmap_page(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_map_sg(e1, e2, e3, e4)
+ dma_map_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_unmap_sg(e1, e2, e3, e4)
+ dma_unmap_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+ dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_dma_sync_single_for_device(e1, e2, e3, e4)
+ dma_sync_single_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+ dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+ dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2;
@@
- pci_dma_mapping_error(e1, e2)
+ dma_mapping_error(&e1->dev, e2)
@@
expression e1, e2;
@@
- pci_set_dma_mask(e1, e2)
+ dma_set_mask(&e1->dev, e2)
@@
expression e1, e2;
@@
- pci_set_consistent_dma_mask(e1, e2)
+ dma_set_coherent_mask(&e1->dev, e2)
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200820150643.148219-1-christophe.jaillet@wanadoo.fr
|
|
Some platforms cannot read the DBI register successfully for the
ASPM settings. After the read failed, the bus could be unstable,
and the device just became unavailable [1]. For those platforms,
the ASPM should be disabled. But as the ASPM can help the driver
to save the power consumption in power save mode, the ASPM is still
needed. So, add a module parameter for them to disable it, then
the device can still work, while others can benefit from the less
power consumption that brings by ASPM enabled.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=206411
[2] Note that my lenovo T430 is the same.
Fixes: 3dff7c6e3749 ("rtw88: allows to enable/disable HCI link PS mechanism")
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200605074703.32726-1-yhchuang@realtek.com
|
|
remove the unused about pci after extracting chip modules
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-7-yhchuang@realtek.com
|
|
Make objects about 8723d functions and 8723d tables,
i.e. rtw8723d.o and rtw8723d_table.o, an individual
kernel module called rtw88_8723d.ko.
For 8723d pcie chip, i.e. 8723DE chip, add a chip
entry point module called rtw88_8723de.ko which
will depend on rtw88_8723d.ko and rtwpci.ko.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-6-yhchuang@realtek.com
|
|
Make objects about 8822b functions and 8822b tables,
i.e. rtw8822b.o and rtw8822b_table.o, an individual
kernel module called rtw88_8822b.ko.
For 8822b pcie chip, i.e. 8822BE chip, add a chip
entry point module called rtw88_8822be.ko which
will depend on rtw88_8822b.ko and rtwpci.ko.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-5-yhchuang@realtek.com
|
|
Make objects about 8822c functions and 8822c tables,
i.e. rtw8822c.o and rtw8822c_table.o, an individual
kernel module called rtw88_8822c.ko.
For 8822c pcie chip, i.e. 8822CE chip, add a chip
entry point module called rtw88_8822ce.ko which
will depend on rtw88_8822c.ko and rtwpci.ko.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-4-yhchuang@realtek.com
|
|
In the current design, chip entry points are built into
the pci module. That makes the pci module depend on chips.
According to dependence, once the pci module is loaded,
kernel will load chip functionalities, including those that
may not be currently used.
We plan to split chip entry points from the pci module.
Thence we export pci symbols that will be used in chip
entry point modules.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-3-yhchuang@realtek.com
|
|
Without this patch, wifi card can't initialize properly due to BT in USB
suspend state. So, we disable BT USB suspend (wakeup) in shutdown callback
that is the moment before rebooting. To save BT USB power, we can't do this
in 'remove' callback.
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>
Link: https://lore.kernel.org/r/20200512102621.5148-5-yhchuang@realtek.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for v5.8
First set of patches for v5.8. Changes all over, ath10k apparently
seeing most new features this time. rtw88 also had lots of changes due
to preparation for new hardware support.
In this pull request there's also a new macro to include/linux/iopoll:
read_poll_timeout_atomic(). This is needed by rtw88 for atomic
polling.
Major changes:
ath11k
* add debugfs file for testing ADDBA and DELBA
* add 802.11 encapsulation offload on hardware support
* add htt_peer_stats_reset debugfs file
ath10k
* enable VHT160 and VHT80+80 modes
* enable radar detection in secondary segment
* sdio: disable TX complete indication to improve throughput
* sdio: decrease power consumption
* sdio: add HTT TX bundle support to increase throughput
* sdio: add rx bitrate reporting
ath9k
* improvements to AR9002 calibration logic
carl9170
* remove buggy P2P_GO support
p54usb
* add support for AirVasT USB stick
rtw88
* add support for antenna configuration
ti wlcore
* add support for AES_CMAC cipher
iwlwifi
* support for a few new FW API versions
* new hw configs
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
the related system resources were not released when pci_iomap() return
error in the rtw_pci_io_mapping() function. add pci_release_regions() to
fix it.
Fixes: e3037485c68ec1a ("rtw88: new Realtek 802.11ac driver")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504083442.3033-1-zhengdejin5@gmail.com
|
|
H2C queue is used to send command to firmware. Since 8723D doesn't support
this queue, this commit check wlan_cpu flag to avoid to set H2C related
registers.
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>
Link: https://lore.kernel.org/r/20200422034607.28747-6-yhchuang@realtek.com
|
|
RTL8723DE is an 11n 1x1 2.4G single band chip with the
following capabilities:
- TX/RX BD size: 16/8
- TX/RX desc size: 40/24
- physical/logical/protected efuse size: 512/512/96
- TX gain index factor: 1
- max TX power index: 0x3F
- band: 2G
- HT: support
- VHT: Not support
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>
Link: https://lore.kernel.org/r/20200420055054.14592-2-yhchuang@realtek.com
|
|
The rtw88 driver defines emtpy functions with multiple indirections
but gets one of these wrong:
drivers/net/wireless/realtek/rtw88/pci.c:1347:12: error: 'rtw_pci_resume' defined but not used [-Werror=unused-function]
1347 | static int rtw_pci_resume(struct device *dev)
| ^~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/pci.c:1342:12: error: 'rtw_pci_suspend' defined but not used [-Werror=unused-function]
1342 | static int rtw_pci_suspend(struct device *dev)
Better simplify it to rely on the conditional reference in
SIMPLE_DEV_PM_OPS(), and mark the functions as __maybe_unused to avoid
warning about it.
I'm not sure if these are needed at all given that the functions
don't do anything, but they were only recently added.
Fixes: 44bc17f7f5b3 ("rtw88: support wowlan feature for 8822c")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200408185413.218643-1-arnd@arndb.de
|
|
Driver used to kick off every TX packets, that will waste some
time while we can do better to kick off the TX packets once after
they are all prepared to be transmitted.
For PCI, it uses DMA engine to transfer the SKBs to the device,
and the transition of the state of the DMA engine could be a cost.
Driver can save some time to kick off multiple SKBs once so that
the DMA engine will have only one transition.
So, split rtw_hci_ops::tx() to rtw_hci_ops::tx_write() and
rtw_hci_ops::tx_kick_off() to explicitly kick the SKBs off after
they are written to the prepared buffer. For packets come from
ieee80211_ops::tx(), write one and then kick it off immediately.
For packets queued in TX queue, which come from
ieee80211_ops::wake_tx_queue(), we can dequeue them, write them
to the buffer, and then kick them off together.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-6-yhchuang@realtek.com
|
|
Add a macro TRX_BD_IDX_MASK for access the TX/RX BD indexes.
The hardware has only 12 bits for TX/RX BD indexes, we should not
initialize a TX/RX ring or access the TX/RX BD index with a length
that is larger than TRX_BD_IDX_MASK.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-5-yhchuang@realtek.com
|
|
Extract skb allocation routines for rsvd_page and h2c.
These routines should also be used by USB and SDIO.
This should not change the logic at all.
memset() for pkt_info is unnecessary, just declare as {0}.
Also skb_put()/memcpy() can be replaced by skb_put_data().
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-3-yhchuang@realtek.com
|
|
This driver generally only needs to ensure that
(a) it doesn't try to process TX interrupts at the same time as
power-save operations (and similar)
(b) the device interrupt gets disabled while we're still handling the
last set of interrupts
For (a), all the operations (e.g., PS transitions, packet handling)
happens in non-atomic contexts (e.g., threaded IRQ).
For (b), we only need mutual exclusion for brief sections (i.e., while
we're actually manipulating the interrupt mask/status).
So, we can introduce a separate lock for handling (b), disabling IRQs
while we do it. For (a), we can demote the locking to BH only, now that
(b) (the only steps done in atomic context) and that has its own lock.
This helps reduce the amount of time this driver spends with IRQs off.
Notably, transitioning out of power-save modes can take >3 milliseconds,
and this transition is done under the protection of 'irq_lock'.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-2-yhchuang@realtek.com
|
|
Reduce the data size 2kb or 3kb by making tables const.
Add const to pointer declarations to make compilation work too.
(x86-64 defconfig)
$ size drivers/net/wireless/realtek/rtw88/rtw8822?.o*
text data bss dec hex filename
25054 672 8 25734 6486 drivers/net/wireless/realtek/rtw88/rtw8822b.o.new
23870 1872 8 25750 6496 drivers/net/wireless/realtek/rtw88/rtw8822b.o.old
53646 828 0 54474 d4ca drivers/net/wireless/realtek/rtw88/rtw8822c.o.new
52846 1652 0 54498 d4e2 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old
(x86-64 allyesconfig)
$ size drivers/net/wireless/realtek/rtw88/rtw8822?.o*
text data bss dec hex filename
45811 6280 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.new
44211 7880 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.old
100195 8128 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.new
98947 9376 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Since RTL8822CE has enabled reference clock auto calibration,
there is no need to add any clock delay for covering the timing
gap of the reference clock.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Sometimes the TX queue may be empty and we could possible
dequeue a NULL pointer, crash the kernel. If the skb is NULL
then there is nothing to do, just leave the ISR.
And the TX queue should not be empty here, so print an error
to see if there is anything wrong for DMA ring.
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>
|
|
Wake on WLAN(wowlan) is a feature which allows devices
to be woken up from suspend state through wlan events.
When user enables wowlan feature and then let the device
enter suspend state, wowlan firmware will be loaded by
the driver and periodically monitors wifi packets.
Power consumption of wifi chip will be reduced in this
state.
If wowlan firmware detects that specific wlan event
happens, it will issue wakeup signal to trigger resume
process. Driver will load normal firmware and let wifi
chip return to the original state.
Currently supported wlan events include receiving magic packet,
rekey packet and deauth packet, and disconnecting from AP.
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>
|
|
Some devices need to configure interface/HCI related reigsters
in power on flow. Add interface_cfg for HCI for the settings.
The driver only supports RTL8822BE/RTL8822CE now, and since
RTL8822BE does not need to configure PCIE, the configuration
is only added for RTL8822CE. Without it, some of the RTL8822CE
device can crash and disconnected to host in suspend/wowlan mode.
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>
|
|
When PCI trx rings are reset, the DMA engine should also be reset.
Otherswise, the rx_tag of rx flow is not synchronous to hw.
Remove DMA reset when rtw_pci_start() as we added it in
rtw_pci_setup().
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
When skbs queued for each TX ring are relased in PCI stop flow,
the ring index should be reset at the same time.
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>
|
|
Different interfaces have its own link-related power save mechanism.
Such as PCI can enter L1 state based on the traffic on the link, and
sometimes driver needs to enable/disable it to avoid some issues, like
throughput degrade when PCI trying to enter L1 state even if driver is
having heavy traffic.
For now, rtw88 only supports PCIE chips, and they just need to disable
ASPM L1 when driver is not in power save mode, such as IPS and LPS.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
By Realtek's design, there are two HW modules associated for CLKREQ,
one is responsible to follow the PCIE host settings, and another
is to actually working on it. But the module that is actually working
on it is default disabled, and driver should enable that module if
host and device have successfully sync'ed with each other.
The module is default disabled because sometimes the host does not
support it, and if there is any incorrect settings (ex. CLKREQ# is
not Bi-Direction), device can be lost and disconnected to the host.
So driver should first check after host and device are sync'ed, and
the host does support the function and set it in configuration
space, then driver can turn on the HW module to working on it.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Use a for loop to polling DBI/MDIO read/write flags to avoid
infinite loop happens
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Add some register and bit macros to access DBI/MDIO register. This
should not change the logic.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Chip info such as cut_version is required to configure
PCI phy. Move rtw_pci_phy_config after rtw_chip_info_setup.
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>
|
|
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>
|
|
Interrupt is disabled to stop PCI, which means the skbs
queued for each TX ring will not be released via DMA
interrupt. To avoid those skbs remained being left in
the skb queue until PCI has been removed, driver needs
to release skbs by itself.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
These skbs free routines could be used when driver wants
to stop PCI bus, because some of the skbs remained in the
queue may not have been returned via DMA interrupt.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
MSI interrupt should be enabled on certain platform.
Add a module parameter disable_msi to disable MSI interrupt,
driver will then use legacy interrupt instead.
One could rebind the PCI device, probe() will pick up the
new value of the module parameter. Such as:
echo '0000:01:00.0' > /sys/bus/pci/drivers/rtw_pci/unbind
echo '0000:01:00.0' > /sys/bus/pci/drivers/rtw_pci/bind
Tested-by: Ján Veselý <jano.vesely@gmail.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Yu-Yen Ting <steventing@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Some of the c2h operations are small and can be done
under interrupt context. For the rest that requires
more operations or can go sleep, enqueue onto c2h queue.
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/rtw88/pci.c: In function 'rtw_pci_phy_cfg':
drivers/net/wireless/realtek/rtw88/pci.c:993:6: warning:
variable 'ip_sel' set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Since each skb in RX ring is reused instead of new allocation, we can
treat the DMA in a more efficient way by DMA synchronization.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Testing with RTL8822BE hardware, when available memory is low, we
frequently see a kernel panic and system freeze.
First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
rx routine starvation
WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
[ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
Then we see a variety of different error conditions and kernel panics,
such as this one (trimmed):
rtw_pci 0000:02:00.0: pci bus timeout, check dma status
skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:105!
invalid opcode: 0000 [#1] SMP NOPTI
RIP: 0010:skb_panic+0x43/0x45
When skb allocation fails and the "rx routine starvation" is hit, the
function returns immediately without updating the RX ring. At this
point, the RX ring may continue referencing an old skb which was already
handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
bad things happen.
This patch allocates a new, data-sized skb first in RX ISR. After
copying the data in, we pass it to the upper layers. However, if skb
allocation fails, we effectively drop the frame. In both cases, the
original, full size ring skb is reused.
In addition, to fixing the kernel crash, the RX routine should now
generally behave better under low memory conditions.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Dump warning messages when we get a q_mapping larger than the AC
numbers. And pick BE queue as default.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
AC numbers are defined as enum in mac80211, use them instead of bare
0-3 indexing.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
This is a new mac80211 driver for Realtek 802.11ac wireless network chips.
rtw88 now supports RTL8822BE/RTL8822CE now, with basic station mode
functionalities. The firmware for both can be found at linux-firmware.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
For RTL8822BE: rtw88/rtw8822b_fw.bin
For RTL8822CE: rtw88/rtw8822c_fw.bin
And for now, only PCI buses (RTL8xxxE) are supported. We will add support
for USB and SDIO in the future. The bus interface abstraction can be seen
in this driver such as hci.h. Most of the hardware setting are the same
except for some TRX path or probing setup should be separated.
Supported:
* Basic STA/AP/ADHOC mode, and TDLS (STA is well tested)
Missing feature:
* WOW/PNO
* USB & SDIO bus (such as RTL8xxxU/RTL8xxxS)
* BT coexistence (8822B/8822C are combo ICs)
* Multiple interfaces (for now single STA is better supported)
* Dynamic hardware calibrations (to improve/stabilize performance)
Potential problems:
* static calibration spends too much time, and it is painful for
driver to leave IDLE state. And slows down associate process.
But reload function are under development, will be added soon!
* TRX statictics misleading, as we are not reporting status correctly,
or say, not reporting for "every" packet.
The next patch set should have BT coexistence code since RTL8822B/C are
combo ICs, and the driver for BT can be found after Linux Kernel v4.20.
So it is better to add it first to make WiFi + BT work concurrently.
Although now rtw88 is simple but we are developing more features for it.
Even we want to add support for more chips such as RTL8821C/RTL8814B.
Finally, rtw88 has many authors, listed alphabetically:
Ping-Ke Shih <pkshih@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|