SER (system error recovery) can deal with different crash types by
different levels of processes. Previous FW crash simulation triggers
a CPU exception which is one kind of SER L2 type. It can verify SER L2
flow which includes HW/FW restart.
Now, we want to increase crash simulation types. A debug function is added
to trigger control error in purpose for SER L1 simulation/verification.
And, debugfs fw_crash is extended to accept different parameters.
echo 1 > fw_crash:
simulate CPU exception as before
(keep 1 for compatibility with previous)
It will be catched and handled by SER L2.
(this requires HW/FW restart)
echo 2 > fw_crash:
simulate control error
It will be catched and handled by SER L1.
(driver and FW cooperate to recover this)
Besides, in order to apply to the above two cases,
rename RTW89_FLAG_RESTART_TRIGGER to RTW89_FLAG_CRASH_SIMULATING
and adjust where SER flow clears this bit for both L1 and L2.
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/20220914035034.14521-5-pkshih@realtek.com
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: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220912021009.6011-1-pkshih@realtek.com
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 <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/20220913092546.43722-6-pkshih@realtek.com
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 <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/20220913092546.43722-5-pkshih@realtek.com
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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/E1oZDo8-0077aq-6I@rmk-PC.armlinux.org.uk
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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/E1oZDnx-0077ae-VK@rmk-PC.armlinux.org.uk
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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/E1oZDns-0077aY-Qn@rmk-PC.armlinux.org.uk
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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/E1oZDnn-0077aS-NA@rmk-PC.armlinux.org.uk
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 <marcan@marcan.st>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/E1oZDni-0077aM-I6@rmk-PC.armlinux.org.uk
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 <marcan@marcan.st>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/E1oZDnd-0077aG-Dk@rmk-PC.armlinux.org.uk
We have recently enabled resume flow based on notifications.
These notifications are sent by the FW when completing the resume flow.
From IWL_DEVICE_FAMILY_AX210 the resume flow is triggered by the
transport layer on iwl_trans_d3_resume.
On IWL_DEVICE_FAMILY_22000 and earlier we trigger the resume flow by
sending the D0I3 command.
Currently, we are waiting for the notifications before sending the
command, the notifications won't be sent by the FW since there is no
resume trigger to piggyback on.
Send the command before starting the wait flow to fix it.
Signed-off-by: Haim, Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.5f0f251edf9c.Ia49ab73105af6f52aa7d318f4984edecd3b0671a@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
IMR (Isolated Memory Regions) is a mechanism to protect memory regions
from unwarranted access by agents in the system that should not have access
to that memory.
When IMR is enabled, pages in the DRAM will be located within the IMR
memory space, accessible only by the device.
As a side effect, during S4 (a.k.a hibernate) the IMR memory space
is not retained.
While the DRAM is saved to the disk and restored by the OS upon resume,
the IMR, which is hidden from the OS neither saved upon suspend nor
restored upon resume.
As a consequence of the above, it turned out that commands cannot
be sent as part of the resume flow, and so after ending
d3 the FW needs to use notifications instead of cmd-resp.
The resume flow becomes asynchronous, with a series
of notifications, starting with wowlan_info_notif, through
wowlan_pkt_notif and complete the resume flow by d3_end_notif.
This patch adds the support for wowlan info notification.
The wake packet has been removed from the wowlan info struct
and will be handled in a dedicated notification.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.3ce8deefd929.Ieba8610e8bb4bec788076371ae38becb4a3d20d5@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
There's a bunch of duplicated code in the normal data RX and
the no-data RX paths, refactor that.
Note that we're evidently not implementing the 6 GHz band in
the no-data path correctly, need to fix that in firmware
first. Also, we were setting the NSS differently, keep doing
that, but just override the previous values.
Note also that we used to drop frames with bad rate data, to
simplify that just report rate 0 and continue.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.a81580d5e769.I3ee7a1fe1adf8684c48713dbbdc2cbc60bd24cd1@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Use the new DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros to
handle the .suspend/.resume callbacks. The new macros allow suspend
and resume functions to be automatically dropped without any #ifdef
guards.
Tested-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Use the new DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros to
handle the .suspend/.resume callbacks. The new macros allow suspend
and resume functions to be automatically dropped without any #ifdef
guards.
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
