With Kconfig and Makefile, we can build rtw89 and support 8852AE chip.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

SAR stands for specific absorption rate. Driver controls TX power to follow
the regulation of SAR.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Power saving contains two main types -- IPS (idle PS) and LPS (Leisure PS).
If there's no any connection, wifi can enter IPS mode that power
consumption is the lowest. After connecting to an AP, it can only wake up
at TBTT to receive beacon to check if AP is buffering any packets; this
case is called LPS mode that the average power is low, but peak appears
at TBTT. With heavy traffic, no power saving mechanism operates, and it
costs high power in this case.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

SER stands for System Error Recovery. When firmware detects error, it
interrupts driver. Driver read ser event code from register and do ser
processes as following:

1. driver stop TX
2. driver stop DMA
3. driver stop RX
4. reset TRX variable and counter
5. Inform FW driver reset is finish
   FW also resets itself when receiving driver's information
6. Wait FW to confirm reset finish
7. Enable DMA
8. driver resume rx
9. driver resume tx

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

PHY and RF parameters are used to set PHY and RF register initially.
Other tables are TX power by rate, limit and swing tables.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

PHY and RF parameters are used to set PHY and RF register initially.
Other tables are TX power by rate, limit and swing tables.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

PHY and RF parameters are used to set PHY and RF register initially.
Other tables are TX power by rate, limit and swing tables.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

PHY and RF parameters are used to set PHY and RF register initially.
Other tables are TX power by rate, limit and swing tables.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

PHY and RF parameters are used to set PHY and RF register initially.
Other tables are TX power by rate, limit and swing tables.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

RFK tables are used by RFK functions implemented by rtw8852a_rfk.c.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

RFK contains DACK, IQK, LOK, RCK, RX DCK, DPK and TSSI. They are called by
rfk_init, rfk_channel and rfk_track at the occasions of initialization,
channel switch and periodic track respectively.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

The 8852A specific chip info and ops are written in this file. The chip
info describes the chip specific capabilities, and chip ops are specific
efuse parser, FEM setup, set channel, RFK trigger, set TX power, and
WL/BT grant controlled by coex.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Interact with regulatory hints by below rules:
For a non-PGed chip, I assume that it is world-roaming, so accepts every
notifications except the following condition.
For a non-PGed chip and the current domain is set by userspace, the
country ie notification will be disabled. The reason is that the current
setting might come from the system of a distro, and I assume that they
do not expect the domain will be changed by connecting to an AP.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

There are three register domains -- MAC, PHY and RF whose ranges are
0x0000~0xFFFF, 0x10000~0x1FFFF and 0x00~0xFF respectively.

Since we access PHY register via a set of PHY access interfaces which do
0x10000 offset by themselves, so PHY registers are listed in range of
0x0000~0xFFFF.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Implement PHY functions, such as read/write PHY and RF registers, parser of
table, RA, CFO and DIG.

To manipulate PHY registers, we provide basic interfaces to read/write PHY
registers, and indirectly access to RF registers with rf_mutex protection.

The formatted tables of PHY and RF parameters that are written in
rtw8852a_table.c need a parser to set to registers.

RA (Rate adaptive)
RA is used to tell firmware rate mask that is used to transmit data;
the rate mask is decided by association capability and rssi strength.
RA report reported by firmware via C2H is used to calculate amsdu length.

CFO (Central frequency offset) tracking
Track CFO by accumulating CFO reported by RX PPDU status. Then, we have
average offset to adjust CFO crystal in track work every 2 seconds.

DIG (Dynamic initial gain) tracking
Track DIG by average RSSI reported by RX PPDU status basically, and
also measure channel loading to make decision.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

DMA data to/from device via TX/RX rings. There are totally 13 TX rings --
8 AC rings, 2 MGMT rings, 2 HI rings and one FW CMD ring. There are
totally 2 RX rings -- one is RX ring, and the other is report ring.

FW CMD TX ring is a special TX ring that is used to download firmware or
send H2C to firmware. The other TX rings are used to send normal data(skb),
and if the skb is sent, RX report ring will receive a report that tells
driver to free the skb. Normal RX packets, C2H and PPDU status are
received by RX rings accordingly.

One TX ring contains TX BD and TX WD. Both are allocated by
dma_alloc_coherent(), but their size can be different (#TX_BD <= #TX_WD).
When a skb is going to send, use a tx_req to hold skb and corresponding
description data, and then fill the request data to a free TX BD and a
free TX WD, finally kick off the TX BD. When TX BD DMA is done, read index
of register is increasing, and then TX BD can be freed, but free WD and skb
until report is received.

Since CMD TX ring doesn't send normal data, it doesn't need to wait for
sending data in air. Therefore, TX BD, TX WD and cmd skb can be freed, when
read index of register is increasing.

One entry of RX ring contains a RX BD and a skb. The skb is used to store
RX WD and frame. RX BD is allocated by dma_alloc_coherent(), and fill RX
size and point RX DMA address to skb->data. If size of RX packet exceeds
filled RX size, the packet will be divided into multiple RX BD with FS and
LS bit.

TX BD OK interrupt for normal AC ring is masked out, because it causes
frequent context switch. We defer to reclaim it until report is received.
The exception is FW CMD ring that doesn't wait for report, so we reclaim
it in interrupt.

With wake TX queue, we submit a bunch of TX skb in one go, and then kick
off DMA by writing write index of TX BD after the TX BD/WD/skb are filled.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Implement ops to interactive with mac80211. The ops contain start/stop,
TX, add/remove vif, config, sta state, key, ampdu action,
sw_scan_start/complete, and so on. To avoid racing between ieee80211
delayed work and ioctl, all of them are protected by rtwdev->mutex.
To yield better TX performance, wake TX queue is implemented.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Provide interfaces to access MAC function blocks including power-on/off
configuration.

MAC initialization does power-on, and then enable HCI to download firmware.
The BB, RF, DMAC and CMAC function blocks are enabled, and then configure
TXRX settings that contains DMAC, CMAC, interrupt mask, and RPQ parameters.
DMAC is short for data MAC, including data link engine (DLE), HCI function
control (HFC), MPDU processor, security engine and so on. CMAC is short for
control MAC, including scheduler, address CAM, RX filter, CCA control,
TMAC, RMAC, protocol component and so on.

The full MAC initialization is done for normal use case when user does
network interface up. When device is probing, driver does partial
initialization to do power-on and download firmware, because we need to
read hardware capabilities from efuse and firmware.

MAC supports five ports, so we can have five VIFs at most. To control MAC
port, we control a set of registers, and the most important one among them
is port_cfg register named R_AX_PORT_CFG_P0. We can turn on/off the port
function and configure network type (STA or AP mode) by this register.
The address and BSSID corresponding to this port are given by address
and BSSID CAM that is set by firmware via H2C command.

Since BT coexistence code needs to access coex registers, some help
functions are provided to make WiFi-only case work.

To access MAC registers, normally we use rtw89_writeXX/rtw89_readYY, but
we use rtw89_mac_txpwr_write32_ZZ to access TX power register with proper
address range checking.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

The firmware must be downloaded right after HCI basic initialization, and
then we can obtain hardware capabilities that are used to do mac80211
register hw.

To download firmware, we need to parse the header to know how many sections
the firmware has, and then download each section to proper location.

We introduce H2C and C2H to do bi-direction communication with firmware,
and both support packet-based and register-based methods.
Normally, we use packet-based H2C/C2H, because it has no number and size
limits. In contrast, register-based H2C/C2H has only one message and
fix-four-dword in size.

Header size of packet-based H2C/C2H is eight bytes (two dwords), which uses
a hierarchical IDs, containing type, category, class and function, to
classify a H2C or C2H command.

When a C2H is received in interrupt context, we don't process it right
there, but queue the skb and wake up a ieee80211 work to handle the skb.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Efuse is divided into several parts, in which physical map and PHY cap
parts are read and parsed by driver.

Storing main data, physical map is translated into logic map, and then use
chip specific map to explain the logic map. Then, we can have MAC address,
country code, thermal tracking calibration values, and so on.

PHY cap part is used to store PHY data. We don't need to translate it,
because it's a direct map, like logic map.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

To recognize issues happened in field, two debug methods, debug message and
debugfs, are added.

The debug messages are written to kernel log, and four levels can be chosen
according to the cases -- debug, info, warn and err.

Debugfs is used to read and write registers and driver status.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Implement main flows that contains register/unregister mac80211 hw with
hardware capability, power on/off sequence, STA state actions, and
TX/RX path.

The chip info is read from efuse while probing PCI, and then it can be
used to induce supported channel, band, bitrate, ht/vht/he capability,
and etc. Then, we register hardware with these capabilities.

When network interface is up, driver does power-on sequence to enable MAC,
BB and RF function blocks. Oppositely, do power-off sequence when
interface is going to down.

To maintain STA state, five callbacks are implemented -- add, assoc,
disassoc, disconnect and remove. In which state, driver tells firmware STA
info via H2C.

TX flow:
When a SKB is going to be transmitted, we must know its type first. If
the type is mgmt or fwcmd made by driver, SKB is queued into corresponding
DMA channel and PCI ring. The other type is data frame that is more
complex, because it needs to establish BA session to have better throughput
with AMPDU and AMSDU.
In order to have better PCI DMA efficiency, we don't kick off DMA every
SKB. With wake TX queue, kick off DMA after a bunch of SKBs are written.
To achieve this, we have two HCI ops -- tx_write and tx_kick_off.

BA establishment work:
For data frames, we start to establish BA session if the STA is associated
with APMDU capability and the TID session isn't established, and then the
BA work is used to ask mac80211 to start AMPDU actions. Driver implements
AMPDU action callbacks to know the session is established, so that we can
set AGG_EN bit in TX descriptor to enable AMPDU.

RX flow:
When a RX SKB is delivered from PCI, rtw89_core_rx() process it depneds on
its type -- WIFI, C2H or PPDU. If type is C2H, it's queued into a C2H
queue, and wake a work to handle the C2H packet. If type is WIFI, it's a
normal RX packet. When mgmt or data frame is received, it is queued
into pending RX SKB queue to wait for corresponding PPDU packet (another
RX packet with PPDU type) to fill its rx_status, like RSSI. And, then
indicate this packet to mac80211. When control frame is received, indicate
it to mac80211 immediately.

Track work:
Use track work to monitor PHY status to know the changes of environment,
and then update RA status or do RFK accordingly.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

BT coexistence uses TDMA-based mechanism to coordinate with WiFi and BT.
Now, we implement basic coexistence features for wide use cases, such as
HID and A2DP. More will be supported later.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Three kinds of CAM, security, address and bssid, are implemented in the
chip, and then we control them via H2C commands.

Every vif contains one address and one bssid CAM entries, and both are
allocated while vif is adding. Once any state is changed, driver notices
firmware. For example, add/remove vif, sta assoc/disassoc, and changed
security key.

When connecting to an AP with security, a security CAM entry is allocated
from security CAM pool and filled key values, and then attached to the
address CAM that contains seven keys entries for unicast, group and BIP
keys. Since the functions of these seven keys are predefined by firmware,
we should attach key to proper position depends on security entry mode and
key type.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Commit 1d89cae ("MAINTAINERS: mark prism54 obsolete") indicated the
prism54 driver as obsolete in July 2010.

Now, after being exposed for ten years to refactoring, general tree-wide
changes and various janitor clean-up, it is really time to delete the
driver for good.

This was discovered as part of a checkpatch evaluation, investigating all
reports of checkpatch's WARNING:OBSOLETE check.

p54 replaces prism54 so users should be unaffected. There was a one off chipset
someone long ago reported that p54 didn't work with but the reporter never
followed up on that. Additionally, distributions have been blacklisting prism54
for years now.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210713054025.32006-1-lukas.bulwahn@gmail.com

The label is only used once, so we delete it and use the
return statement instead of the goto statement.

Signed-off-by: dingsenjie <dingsenjie@yulong.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210625121108.162868-1-dingsenjie@163.com

After some crashes in the 3D engine (!) on the Samsung GT-I8530
it turns out that the main firmware file can be device dependent,
something that was previously only handled for the NVRAM
parameter file.

Rewrite the code a bit so we can a per-board suffixed firmware
binary as well, if this does not exist we fall back to the
canonical firmware name.

Example: a 4330 device with the OF board compatible is
"samsung,gavini". We will first try
"brcmfmac4330-sdio.samsung,gavini.bin" then "brcmfmac4330-sdio.bin"
if that does not work.

Cc: phone-devel@vger.kernel.org
Cc: newbyte@disroot.org
Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210711231659.255479-1-linus.walleij@linaro.org

…lo/ath.git

ath.git patches for v5.15. Major changes:

ath5k, ath9k, ath10k, ath11k:

* switch from 'pci_' to 'dma_' API

The dma_pool_zalloc combines dma_pool_alloc/memset. Therefore, the
dma_pool_alloc/memset can be replaced with dma_pool_zalloc which is
more compact.

Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Use dynamic interrupt moderation library to implement coalesce
adaptive feature for nfp driver.

Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
Signed-off-by: Yu Xiao <yu.xiao@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Packets are aggregated over the MBIM link and currently the MHI net
device will count each aggregated packet rather then the actual
packets themselves.

If a protocol handler module is specified, use that to count the
packets rather than directly in the MHI net device. This is in line
with the behaviour of the USB net cdc_mbim driver.

Signed-off-by: Richard Laing <richard.laing@alliedtelesis.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>

Simplify the code by removing unnecessary label and returning directly.

Signed-off-by: wengjianfeng <wengjianfeng@yulong.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Guangbin Huang says:

====================
net: hns3: add support devlink

This series adds devlink support for the HNS3 ethernet driver.

change log:
V2 -> V3:
1. remove two patches of setting rx/tx buffer size by devlink param.

V1 -> V2:
1. add more detailed descriptions of parameters in document hns3.rst.

RFC -> V1:
1. use DEVLINK_INFO_VERSION_GENERIC_FW instead of "fw-version".
2. add devlink documentation for hns3 driver.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

Add devlink reload support for HNS3 ethernet VF driver.

Signed-off-by: Hao Chen <chenhao288@hisilicon.com>
Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add devlink reload support for HNS3 ethernet PF driver.

Signed-off-by: Hao Chen <chenhao288@hisilicon.com>
Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>