If the chip can have an LED, register a struct led_classdev and enable
hardware-controlled blinking. When the chip is not transmitting or
receiving anything the LED is off. Otherwise the LED will blink
faster or slower according to the throughput.
The LED can be controlled from userspace by writing 0, 1, or 2 to
/sys/class/leds/rtl8xxxu-usbX-Y/brightness:
0 - solid off.
1 - solid on.
2 - hardware-controlled blinking.
In this patch none of the chips advertise having an LED. That will be
added in the next patches.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/b8235bca-60c3-d0fe-a958-53c6dd3ba3f6@gmail.com
Macros prefixed with CONFIG_ are intended to be defined only by
Kconfig scripts. Here we remove the prefix from the
CONFIG_AUTO_READ_MODE define to avoid confusion when reading the code.
This causes no change to functionality.
Signed-off-by: Peter Lafreniere <peter@n8pjl.ca>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230118185353.2422-1-peter@n8pjl.ca
In path of setting channel and setting TX power, the rtw89_chan instance
to be used is controlled by top and passed down. The set_tx_shape_dfir()
is in path of setting TX power, so it should use the passed rtw89_chan
instead of querying it itself. Otherwise, it might encounter mismatch
between parameters if multi-channel.
For example,
rtw89_8852ce 0000:04:00.0: set tx shape dfir by unknown ch: 155 on 2GHz
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/20230201032057.7349-1-pkshih@realtek.com
New firmware type NORMAL_CE is introduced to support P2P-PS and hardware
scan, but no LPS-PG mode. After this patch, old firmware with NORMAL type
can still work well.
The use of this new type is the same as before, so we add new type to
avoid taking wrong firmware. Then, driver log can also give clear
information about this change:
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 3
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123065401.14174-7-pkshih@realtek.com
For different firmware type, it could use different IDMEM mode, so reset
it to default to avoid encountering error during we bisect firmware
version, like
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 3
rtw89_8852be 0000:03:00.0: fw security fail
rtw89_8852be 0000:03:00.0: download firmware fail
rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x1E0 = 0x62
rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x83F2 = 0x8
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931150
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123065401.14174-5-pkshih@realtek.com
Driver can prepare pkt_list for firmware that only uses them to send out
the packets in specific situations. To understand the usage of current
status, and to check if there is leakage problem, dump bitmap and the
indices used by certain function.
An example looks like:
map:
...
pkt_ofld: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
[SCAN 0]: 3
[SCAN 1]: 4
[SCAN 3]: 5
VIF [0] xx:xx:xx:xx:xx:xx
...
pkt_ofld[GENERAL]: 0 1 2
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123065401.14174-4-pkshih@realtek.com
For upcoming firmware, driver needs to do packet offload to firmware to
ensure LPS protocol work properly, so we update current connection and
disconnect flow to maintain packet offload flow, and integrate with
current WoWLAN flow which also needs packet offload.
Signed-off-by: Chin-Yen Lee <timlee@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/20230123065401.14174-3-pkshih@realtek.com
To debug channel concurrency more centrally, we add a new debug flag,
RTW89_DBG_CHAN, for channel related things, especially channel concurrency.
Then, we change MCC (multi-channel concurrency) C2H (chip to host packets)
debug flag to it.
Besides, refine debug logs to show TSF in u64 directly.
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/20230119064342.65391-2-pkshih@realtek.com
RXI300 is a HW design to maintain stuffs across BUS, e.g. AXI, AHB, APB.
It will feedback an error when host does an invalid BUS operation.
For example,
* BUS master request without power/clock on.
* host reads/writes/accesses an invalid address.
They might lead to problems such as BUS timeout, platform hang, etc. So,
once if RXI300 feedback an error, it notifies that driver need a L2 SER
(system error recovery) to reset things.
Previously, driver did not parse the error scenario for RXI300. We add
it and assign a corresponding error code which will make SER flow do L2
reset.
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/20230119063529.61563-3-pkshih@realtek.com
Originally, rtw89_mac_port_tsf_sync() contains randomization logic
internally. However, not all situation, we need the randomization.
So, split out the generic part from it. And, make the full logic of
original one contained in rtw89_mac_port_tsf_sync_rand(). It will
still be used by its original caller as before. Then, the generic
one will be used in MCC (multi-channel concurrency) management flow.
MCC will implement its logic to decide the offset for TSF sync.
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/20230119062453.58341-3-pkshih@realtek.com
The origin code will enable TDMA WL:BT = 50:50 to prevent Wi-Fi
throughput suddenly drop to 0 in the moment while A2DP pause.
And this protection just a short moment, and will turn to Bluetooth
idle case when A2DP turn into sniff mode. But the raspberryPI simulated
A2DP device will not turn into sniff mode. So the protection will bring
the throughput drop.
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/20230117114109.4298-8-pkshih@realtek.com
Force firmware to update TDMA parameter when enter/exit power saving.
The TDMA instant feature will make firmware force update TDMA parameter
immediately when the TDMA parameter H2C to firmware. Without this feature,
it will have a low fail rate trigger Bluetooth audio sound glitch when
Wi-Fi is under power saving. Or Wi-Fi fail to turn in to power save state.
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/20230117114109.4298-4-pkshih@realtek.com
This code re-uses "i" to be the iterator for both the inside and outside
loops. It means the outside loop will exit earlier than intended.
Fixes: d219b7eb37 ("mwifiex: handle BT coex event to adjust Rx BA window size")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/Y+ERnaDaZD7RtLvX@kili
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct mwifiex_ie_types_rates_param_set.
These are the only binary differences I see after the change:
mwifiex.o
_@@ -50154,7 +50154,7 @@
23514: R_X86_64_32S kmalloc_caches+0x50
23518: call 2351d <mwifiex_scan_networks+0x11d>
23519: R_X86_64_PLT32 __tsan_read8-0x4
- 2351d: mov $0x225,%edx
+ 2351d: mov $0x224,%edx
23522: mov $0xdc0,%esi
23527: mov 0x0(%rip),%rdi # 2352e <mwifiex_scan_networks+0x12e>
2352a: R_X86_64_PC32 kmalloc_caches+0x4c
scan.o
_@@ -5582,7 +5582,7 @@
4394: R_X86_64_32S kmalloc_caches+0x50
4398: call 439d <mwifiex_scan_networks+0x11d>
4399: R_X86_64_PLT32 __tsan_read8-0x4
- 439d: mov $0x225,%edx
+ 439d: mov $0x224,%edx
43a2: mov $0xdc0,%esi
43a7: mov 0x0(%rip),%rdi # 43ae <mwifiex_scan_networks+0x12e>
43aa: R_X86_64_PC32 kmalloc_caches+0x4c
and the reason for that is the following line:
drivers/net/wireless/marvell/mwifiex/scan.c:
1517 scan_cfg_out = kzalloc(sizeof(union mwifiex_scan_cmd_config_tlv),
1518 GFP_KERNEL);
sizeof(union mwifiex_scan_cmd_config_tlv) is now one-byte smaller due to the
flex-array transformation:
46 union mwifiex_scan_cmd_config_tlv {
47 /* Scan configuration (variable length) */
48 struct mwifiex_scan_cmd_config config;
49 /* Max allocated block */
50 u8 config_alloc_buf[MAX_SCAN_CFG_ALLOC];
51 };
Notice that MAX_SCAN_CFG_ALLOC is defined in terms of
sizeof(struct mwifiex_ie_types_rates_param_set), see:
26 /* Memory needed to store supported rate */
27 #define RATE_TLV_MAX_SIZE (sizeof(struct mwifiex_ie_types_rates_param_set) \
28 + HOSTCMD_SUPPORTED_RATES)
37 /* Maximum memory needed for a mwifiex_scan_cmd_config with all TLVs at max */
38 #define MAX_SCAN_CFG_ALLOC (sizeof(struct mwifiex_scan_cmd_config) \
39 + sizeof(struct mwifiex_ie_types_num_probes) \
40 + sizeof(struct mwifiex_ie_types_htcap) \
41 + CHAN_TLV_MAX_SIZE \
42 + RATE_TLV_MAX_SIZE \
43 + WILDCARD_SSID_TLV_MAX_SIZE)
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/252
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/Y9xkjXeElSEQ0FPY@work
The Marvell SD8978 (aka NXP IW416) uses identical registers as SD8987,
so reuse the existing mwifiex_reg_sd8987 definition.
Note that mwifiex_reg_sd8977 and mwifiex_reg_sd8997 are likewise
identical, save for the fw_dump_ctrl register: They define it as 0xf0
whereas mwifiex_reg_sd8987 defines it as 0xf9. I've verified that
0xf9 is the correct value on SD8978. NXP's out-of-tree driver uses
0xf9 for all of them, so there's a chance that 0xf0 is not correct
in the mwifiex_reg_sd8977 and mwifiex_reg_sd8997 definitions. I cannot
test that for lack of hardware, hence am leaving it as is.
NXP has only released a firmware which runs Bluetooth over UART.
Perhaps Bluetooth over SDIO is unsupported by this chipset.
Consequently, only an "sdiouart" firmware image is referenced, not an
alternative "sdsd" image.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/536b4f17a72ca460ad1b07045757043fb0778988.1674827105.git.lukas@wunner.de
This chip exists in two revisions (B2=r3 and B3=r4) on different
platforms, and was added without regard to doing proper firmware
selection or differentiating between them. Fix this to have proper
per-revision firmwares and support Apple NVRAM selection.
Revision B2 is present on at least these Apple T2 Macs:
kauai: MacBook Pro 15" (Touch/2018-2019)
maui: MacBook Pro 13" (Touch/2018-2019)
lanai: Mac mini (Late 2018)
ekans: iMac Pro 27" (5K, Late 2017)
And these non-T2 Macs:
nihau: iMac 27" (5K, 2019)
Revision B3 is present on at least these Apple T2 Macs:
bali: MacBook Pro 16" (2019)
trinidad: MacBook Pro 13" (2020, 4 TB3)
borneo: MacBook Pro 16" (2019, 5600M)
kahana: Mac Pro (2019)
kahana: Mac Pro (2019, Rack)
hanauma: iMac 27" (5K, 2020)
kure: iMac 27" (5K, 2020, 5700/XT)
Also fix the firmware interface for 4364, from BCA to WCC.
Fixes: 24f0bd1362 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230212063813.27622-5-marcan@marcan.st
This chip is present on at least these Apple T2 Macs:
* hawaii: MacBook Air 13" (Late 2018)
* hawaii: MacBook Air 13" (True Tone, 2019)
Users report seeing PCI revision ID 12 for this chip, which Arend
reports should be revision C2, but Apple has the firmware tagged as
revision C1. Assume the right cutoff point for firmware versions is
revision ID 11 then, and leave older revisions using the non-versioned
firmware filename (Apple only uses C1 firmware builds).
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230212063813.27622-3-marcan@marcan.st
The commit that introduced support for this chip incorrectly claimed it
is a Cypress-specific part, while in actuality it is just a variant of
BCM4355 silicon (as evidenced by the chip ID).
The relationship between Cypress products and Broadcom products isn't
entirely clear but given what little information is available and prior
art in the driver, it seems the convention should be that originally
Broadcom parts should retain the Broadcom name.
Thus, rename the relevant constants and firmware file. Also rename the
specific 89459 PCIe ID to BCM43596, which seems to be the original
subvariant name for this PCI ID (as defined in the out-of-tree bcmdhd
driver).
Since Cypress added this part and will presumably be providing its
supported firmware, we keep the CYW designation for this device.
We also drop the RAW device ID in this commit. We don't do this for the
other chips since apparently some devices with them exist in the wild,
but there is already a 4355 entry with the Broadcom subvendor and WCC
firmware vendor, so adding a generic fallback to Cypress seems
redundant (no reason why a device would have the raw device ID *and* an
explicitly programmed subvendor).
Fixes: dce45ded76 ("brcmfmac: Support 89459 pcie")
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230212063813.27622-2-marcan@marcan.st
More Qualcomm driver updates for 6.3
The qcom_scm.h file is moved into firmware/qcom, to avoid having any
Qualcomm-specific files directly in include/linux.
Support for PMIC GLINK is introduced, which on newer Qualcomm platforms
provides an interface to the firmware implementing battery management
and USB Type-C handling. Together with the base driver comes the custom
altmode support driver.
SMD RPM gains support for IPQ9574, and socinfo is extended with support
for revision 17 of the information format and soc_id for IPQ5332 and
IPQ8064 are added.
The qcom_stats is changes not to fail when not all parts are
initialized.
* tag 'qcom-drivers-for-6.3-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: socinfo: Add IDs for IPQ5332 and its variant
dt-bindings: arm: qcom,ids: Add IDs for IPQ5332 and its variant
dt-bindings: power: qcom,rpmpd: add RPMH_REGULATOR_LEVEL_LOW_SVS_L1
firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/
MAINTAINERS: Update qcom CPR maintainer entry
dt-bindings: firmware: document Qualcomm SM8550 SCM
dt-bindings: firmware: qcom,scm: add qcom,scm-sa8775p compatible
soc: qcom: socinfo: Add Soc IDs for IPQ8064 and variants
dt-bindings: arm: qcom,ids: Add Soc IDs for IPQ8064 and variants
soc: qcom: socinfo: Add support for new field in revision 17
soc: qcom: smd-rpm: Add IPQ9574 compatible
soc: qcom: pmic_glink: remove redundant calculation of svid
soc: qcom: stats: Populate all subsystem debugfs files
dt-bindings: soc: qcom,rpmh-rsc: Update to allow for generic nodes
soc: qcom: pmic_glink: add CONFIG_NET/CONFIG_OF dependencies
soc: qcom: pmic_glink: Introduce altmode support
soc: qcom: pmic_glink: Introduce base PMIC GLINK driver
dt-bindings: soc: qcom: Introduce PMIC GLINK binding
soc: qcom: dcc: Drop driver for now
Link: https://lore.kernel.org/r/20230210182242.2023901-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
