Disable runtime PM for the duration of reset/recovery so it is possible
to set the correct runtime PM state depending on the outcome of the
`ivpu_resume()`. Don’t suspend or reset the HW if the NPU is suspended
when the reset/recovery is requested. Also, move common reset/recovery
code to separate functions for better code readability.
Fixes: 27d19268cf ("accel/ivpu: Improve recovery and reset support")
Cc: stable@vger.kernel.org # v6.8+
Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250129124009.1039982-4-jacek.lawrynowicz@linux.intel.com
pm_runtime_resume_and_get() sets dev->power.runtime_error that causes
all subsequent pm_runtime_get_sync() calls to fail.
Clear the runtime_error using pm_runtime_set_suspended(), so the driver
doesn't have to be reloaded to recover when the NPU fails to boot during
runtime resume.
Fixes: 7d4b4c7443 ("accel/ivpu: Remove suspend_reschedule_counter")
Cc: stable@vger.kernel.org # v6.11+
Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250129124009.1039982-3-jacek.lawrynowicz@linux.intel.com
In the PX30-uQ7 (Ringneck) SoM, the hardware CTS and RTS pins for
uart5 cannot be used for the UART CTS/RTS, because they are already
allocated for different purposes. CTS pin is routed to SUS_S3#
signal, while RTS pin is used internally and is not available on
Q7 connector. Move definition of the pinctrl-0 property from
px30-ringneck-haikou.dts to px30-ringneck.dtsi.
This commit is a dependency to next commit in the patch series,
that disables DMA for uart5.
Cc: stable@vger.kernel.org
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Link: https://lore.kernel.org/r/20250121125604.3115235-2-lukasz.czechowski@thaumatec.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In general the delay should be added by the PHY instead of the MAC,
and this improves network stability on some boards which seem to
need different delay.
Fixes: 387b3bbac5 ("arm64: dts: rockchip: Add Xunlong OrangePi R1 Plus LTS")
Cc: stable@vger.kernel.org # 6.6+
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20250119091154.1110762-1-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The tsadc driver does not handle pinctrl "gpio" and "otpout".
Let's use the correct pinctrl names "default" and "sleep".
Additionally, Alexey Charkov's testing [1] has established that
it is necessary for pinctrl state to reference the &tsadc_shut_org
configuration rather than &tsadc_shut for the driver to function correctly.
[1] https://lkml.org/lkml/2025/1/24/966
Fixes: 32641b8ab1 ("arm64: dts: rockchip: add rk3588 thermal sensor")
Cc: stable@vger.kernel.org
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Link: https://lore.kernel.org/r/20250130053849.4902-1-eagle.alexander923@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The preferred way to denote hardware with non-coherent DMA is to use the
"dma-noncoherent" DT property, at both the GIC redistributor and the GIC ITS
levels, [1] instead of relying on the compatibles to handle hardware errata,
in this case the Rockchip 3588001 errata. [2]
Let's have the preferred way employed in the base Rockchip RK3588 SoC dtsi,
which also goes along with adding initial support for the Rockchip RK3582 SoC
variant, with its separate compatible. [2][3]
[1] Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
[2] https://lore.kernel.org/linux-rockchip/86msgoozqa.wl-maz@kernel.org/
[3] https://lore.kernel.org/linux-rockchip/20241222030355.2246-4-naoki@radxa.com/
Cc: Marc Zyngier <maz@kernel.org>
Cc: FUKAUMI Naoki <naoki@radxa.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/fa1a672dae3644bb3caa58f03216d0ca349db88b.1736279094.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary cooling map to enable the kernel's thermal subsystem
to manage the fan speed automatically depending on the overall SoC
package temperature on Radxa Rock 5C
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250120-rock-5c-fan-v1-2-5fb8446c981b@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa Heatsink 6540B, which is the official cooling accessory for the
Rock 5C board, includes a small 5V fan, which in my testing spins up
reliably at a PWM setting of 24 (out of 255). It is also quite loud
at the current minimum setting of 64, and noticeably less so at 24.
Introduce two intermediate PWM states at the lower end of the fan's
operating range to enable better balance between noise and cooling.
Note further that, in my testing, having the fan run at 44 is enough
to keep the system from thermal throttling with sustained 100% load
on its 8 CPU cores (in 22C ambient temperature and no case)
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Acked-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250120-rock-5c-fan-v1-1-5fb8446c981b@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In pmc_core_ltr_show(), promote 'val' to 'u64' to avoid possible integer
overflow. Values (10 bit) are multiplied by the scale, the result of
expression is in a range from 1 to 34,326,183,936 which is bigger then
UINT32_MAX. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com>
Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20250123220739.68087-1-d.kandybka@gmail.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
devm_platform_profile_register() expects a pointer to the private driver
data but instead an address of the pointer variable is passed due to a
typo. This leads to the crashes later:
BUG: unable to handle page fault for address: 00000000fe0d0044
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 6 UID: 0 PID: 1284 Comm: tuned Tainted: G W 6.13.0+ #7
Tainted: [W]=WARN
Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023
RIP: 0010:__mutex_lock.constprop.0+0x6bf/0x7f0
Call Trace:
<TASK>
dytc_profile_set+0x4a/0x140 [ideapad_laptop]
_store_and_notify+0x13/0x40 [platform_profile]
class_for_each_device+0x145/0x180
platform_profile_store+0xc0/0x130 [platform_profile]
kernfs_fop_write_iter+0x13e/0x1f0
vfs_write+0x290/0x450
ksys_write+0x6c/0xe0
do_syscall_64+0x82/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Found by Linux Verification Center (linuxtesting.org).
Fixes: 249c576f0f ("ACPI: platform_profile: Let drivers set drvdata to the class device")
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Reviewed-by: Kurt Borja <kuurtb@gmail.com>
Link: https://lore.kernel.org/r/20250127210202.568691-1-pchelkin@ispras.ru
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Replace ternary (condition ? "enable" : "disable") syntax with helpers
from string_choices.h because:
1. Simple function call with one argument is easier to read. Ternary
operator has three arguments and with wrapping might lead to quite
long code.
2. Is slightly shorter thus also easier to read.
3. It brings uniformity in the text - same string.
4. Allows deduping by the linker, which results in a smaller binary
file.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Doug Berger <opendmb@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250114191438.857656-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Bindings expect GPIO hog names to end with 'hog' suffix, so correct it
to fix dtbs_check warnings like:
da850-lego-ev3.dtb: batt_volt_en: $nodename:0: 'batt_volt_en' does not match '^.+-hog(-[0-9]+)?$'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: David Lechner <david@lechnology.com>
Link: https://lore.kernel.org/r/20250116090030.87452-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Commit c8c68c38b5 ("cpufreq: amd-pstate: initialize core precision
boost state") sets per-policy boost flag to false when boost fail.
However, this boost flag will be set to reverse value in
store_local_boost() and cpufreq_boost_trigger_state() in cpufreq.c. This
will cause the per-policy boost flag set to true when fail to set boost.
Remove the extra assignment in amd_pstate_set_boost() and keep all
operations on per-policy boost flag outside of set_boost() to fix this
problem.
Fixes: c8c68c38b5 ("cpufreq: amd-pstate: initialize core precision boost state")
Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250110091949.3610770-1-zhenglifeng1@huawei.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
The QCS8300 video clock controller is a derivative of SA8775P, but
QCS8300 has minor difference. Hence, reuse the SA8775P videocc bindings
for QCS8300 platform.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Link: https://lore.kernel.org/r/20250109-qcs8300-mm-patches-new-v4-5-63e8ac268b02@quicinc.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The QCS8300 camera clock controller is a derivative of SA8775P, but has
an additional clock and minor differences. Hence, reuse the SA8775P
camera bindings and add additional clock required for QCS8300.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Link: https://lore.kernel.org/r/20250109-qcs8300-mm-patches-new-v4-3-63e8ac268b02@quicinc.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The QCS8300 GPU clock controller is a derivative of SA8775P, but has few
additional clocks and minor differences. Hence, reuse gpucc bindings of
SA8775P and add additional clocks required for QCS8300.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Link: https://lore.kernel.org/r/20250109-qcs8300-mm-patches-new-v4-1-63e8ac268b02@quicinc.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
My sparc64 defconfig build failed like this:
drivers/block/sunvdc.c: In function 'vdc_queue_drain':
drivers/block/sunvdc.c:1130:9: error: too many arguments to function 'blk_mq_unquiesce_queue'
1130 | blk_mq_unquiesce_queue(q, memflags);
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/block/sunvdc.c:10:
include/linux/blk-mq.h:895:6: note: declared here
895 | void blk_mq_unquiesce_queue(struct request_queue *q);
| ^~~~~~~~~~~~~~~~~~~~~~
drivers/block/sunvdc.c:1131:9: error: too few arguments to function 'blk_mq_unfreeze_queue'
1131 | blk_mq_unfreeze_queue(q);
| ^~~~~~~~~~~~~~~~~~~~~
In file included from drivers/block/sunvdc.c:10:
include/linux/blk-mq.h:914:1: note: declared here
914 | blk_mq_unfreeze_queue(struct request_queue *q, unsigned int memflags)
| ^~~~~~~~~~~~~~~~~~~~~
Fixes: 1e1a9cecfa ("block: force noio scope in blk_mq_freeze_queue")
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Occasionally there is an EPROTO error during firmware download.
This error is converted to EAGAIN in the download function.
But nobody tries again and so device probe fails.
Implement download retry to fix this.
This error was observed (and fix tested) on a tbs2910 board [1]
with an embedded RTL8188EU (0bda:8179) device behind a USB hub.
[1] arch/arm/boot/dts/nxp/imx/imx6q-tbs2910.dts
Signed-off-by: Soeren Moch <smoch@web.de>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250127194828.599379-1-smoch@web.de
Some users want to plug two identical USB devices at the same time.
This static variable could theoretically cause them to use incorrect
TX power values.
Move the variable to the caller and pass a pointer to it to
rtw8821c_set_tx_power_index_by_rate().
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/fe42858c-9b9f-4f03-9aaa-737472c2cd90@gmail.com
Some users want to plug two identical USB devices at the same time.
This static variable could theoretically cause them to use incorrect
TX power values.
Move the variable to the caller and pass a pointer to it to
rtw8822b_set_tx_power_index_by_rate().
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/8a60f581-0ab5-4d98-a97d-dd83b605008f@gmail.com
Load the cros_ec_lpc driver based on a Framework FRMWC004 ACPI device,
which mirrors GOOG0004, but also applies npcx quirks for Framework
systems.
Matching on ACPI will let us avoid having to change the SMBIOS match
rules again and again.
Cc: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: linux@frame.work
Cc: Dustin L. Howett <dustin@howett.net>
Signed-off-by: Daniel Schaefer <dhs@frame.work>
Link: https://lore.kernel.org/r/20250128181329.8070-1-dhs@frame.work
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
This allows the driver to be used in wireless access point mode on the
AT91SAM9G25-based GARDENA smart Gateway.
Unfortunately, the data throughput in AP mode appears to be lower than
with the vendor driver (or in STA mode). Especially when sending, the
data rate is significantly lower. My measurements performed with iperf3
and an Edimax EW-7811Un (VID: 7392, PID: 7811) showed a maximum TX rate
of about 4 Mbits/sec compared to the ~24 Mbits/sec measured with the
rtl8192cu driver.
Although the performance might be good enough for our use case, this is
something that should be further looked into.
Signed-off-by: Ezra Buehler <ezra.buehler@husqvarnagroup.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122071512.10165-1-ezra@easyb.ch
Except probe/remove flow, the consumers of early_h2c list are interface
start and debugfs. There must be no race between probe/remove flow and
interface start. The failed probe flow is to free early_h2c list as well
as remove flow, at these two moments debugfs doesn't present. Thus, it is
safe to free early_h2c list without held wiphy_lock in these situations.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-11-pkshih@realtek.com
With spatch script, already remove most driver mutex and generate
lockdep_assert_wiphy(), and some are needed to refine manually further to
be expected:
- lockdep_assert_wiphy() always be the first statement in function
- return directly rather than unnecessary goto
- change assert from mutex to wiphy lock, which script can't convert
automatically.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-9-pkshih@realtek.com
If a debugfs entry takes driver mutex now, let it uses
wiphy_locked_debugfs_{read,write}() to take both driver mutex and
wiphy lock. Add rwlock option to support this.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-6-pkshih@realtek.com
Some debufs entries need output buffer over default size 4K. Since reading
of many debugfs entries is to access IO, it costs time to dynamically
re-allocate larger buffer and access IO again and again. Add an option to
specify the size it needs.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-5-pkshih@realtek.com
Since debugfs needs wiphy lock held, wiphy_locked_debugfs_{read,write}()
will be adopted, so implmenet file_ops::read/write along with their
arguments.
For reading part, it needs lots of changes because seq_file is not
suitable for wiphy_locked_debugfs_{read,write}(), so use spatch script
below to convert basically, and manually implement the functions.
@ rule1 @
identifier m;
@@
- seq_printf(m,
+ p += scnprintf(p, end - p,
...)
@ rule2 @
identifier m;
@@
- seq_puts(m,
+ p += scnprintf(p, end - p,
...)
For current version, only 4K buffer to output. To note ourselves, add
ellipsis symbol "..." to trailing if buffer is full. Later, add an option
to specify buffer size needed by a debugfs entry.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-4-pkshih@realtek.com
For certain works protected by driver mutex, use wiphy_work() directly
to have wiphy lock held naturally. Then every this kind of works is
protected by both wiphy lock and driver mutex.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-3-pkshih@realtek.com
The needed one was moved to rtwvif::roc_work. And, rtwdev::roc_work is
unused. So, remove it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250120034004.21135-1-pkshih@realtek.com
Add a few new members of ChromeOS USB team for the USB Type-C related
drivers for ChromeOS: cros_ec_typec, cros_ec_ucsi, and cros_usbpd_notify.
Łukasz Bartosik <ukaszb@chromium.org>
Jameson Thies <jthies@google.com>
Andrei Kuchynski <akuchynski@chromium.org>
Prashant has also moved to a different team, so by his request, remove him
from maintainers of these drivers too.
Signed-off-by: Benson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/Z5raIM_qhCF7oOB8@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The regulatory and wiphy setup should be done in rtw89_regd_setup(). And,
what rtw89_regd_init() should do is to initialize target regulatory domain
(regd), if and only if one is programmed in efuse. Since HW is registered
after rtw89_regd_setup() and before rtw89_regd_init(), do not fill fields
of regulatory in rtw89_regd_init(). So, move the regulatory->reg_6ghz_power
assignment into rtw89_regd_setup().
Besides, rtw89_regd_notifier is assigned in rtw89_regd_setup() instead of
rtw89_regd_init(). To reduce confusion, stop passing rtw89_regd_notifier to
rtw89_regd_init(). And, rename rtw89_regd_init() to rtw89_regd_init_hint().
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250120032723.19042-4-pkshih@realtek.com
There are two regulatory functions including TAS (Time Average SAR) and
DAG (Dynamic Antenna Gain) for now. They are used to improve RF behavior.
But, availability depends on country. Extend regd map to record the status
of whether a country allows to enable certain regulatory functions.
Also, extend the handling of loading regd map via FW element for this.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250120032723.19042-3-pkshih@realtek.com
Regd table is a table that we use to describe how to map Realtek RF TX
power settings on different countries. Originally, a common regd table
for all chips is implemented in driver. However, in order to work on all
chips, the common regd table might have some trade-off. So now, there are
also an individual regd table for some chips. And, we support loading it
from FW element.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250120032723.19042-2-pkshih@realtek.com
To have good performance, adjust hardware XTAL to track CFO (carrier
frequency offset). However, there is only one hardware XTAL, so it is not
possible to track on two PHY simultaneously. It also can't track on single
one PHY when two PHY are working, because the adjustment of XTAL will
affect all PHY. Thus, disable CFO track for this case.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-9-pkshih@realtek.com
The registers of EDCCA log for PHY 1 isn't a simple offset, so define
them accordingly. Then the function use register set to access reports
according to phy_idx.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-8-pkshih@realtek.com
Dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment) is to
dynamically adjusted to make EDCCA suitable for situations.
Use PHY context to support two PHY.
For the EDCCA log part, registers to report EDCCA for PHY 1 is not a
simple offset from PHY 0, so add them by separate patch.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-7-pkshih@realtek.com
The ch_info is to record current channel info such as minimum RSSI of
connected stations, and to assist in dynamic mechanisms of DIG and EDCCA.
Move the struct to PHY context, so the dynamic mechanisms can use the info
of the same PHY.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-6-pkshih@realtek.com
DIG standing for dynamic initial gain is to define RX coverage. Adjust this
value dynamically to gain good RX performance.
Use PHY context to extend DIG algorithm to support two PHY.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-5-pkshih@realtek.com
The env_monitor is to collect information of current operating channel as
helper to make decision with better hardware parameters to adopt current
environment.
Use PHY context as argument to control PHY accordingly, and use
rtw89_phy_{write32,read32}_idx with phy_idx to access registers.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-4-pkshih@realtek.com
To support MLO working on PHY 0 and PHY 1, extend existing PHY dynamic
mechanism from PHY 0 to PHY 0/1.
Implement a 2 elements array for two PHY instances, and pass pointer
of each element as argument to existing functions. Then existing algorithm
is kept, unchanged.
Also provide iterate and get function to access PHY context.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-3-pkshih@realtek.com
