Age | Commit message (Collapse) | Author |
|
The coming WiFi 7 chip 8922A will support EHT, so declare EHT along with
hardware capabilities.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240112062640.36922-4-pkshih@realtek.com
|
|
Basically, all chips can support 20/40/80MHz bandwidth, and 8952C can
support 160MHz bandwidth, which is why we introduced support_bw160 before.
The coming WiFi 7 chips will support 320MHz optionally, so change it to
bit mask instead of adding another support_bw320.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240112062640.36922-3-pkshih@realtek.com
|
|
EHT capabilities are also stored in struct ieee80211_sband_iftype_data, so
adjust allocation of iftype_data as common part named init_he_eht_cap(),
and then init_eht_cap() can be added later. Don't change logic at all
by this patch.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240112062640.36922-2-pkshih@realtek.com
|
|
When 'sscanf()' is not needed to scan an input, prefer common
'kstrtoX_from_user()' over 'rtw_debugfs_copy_from_user()' with
following 'kstrtoX()'. Minor adjustments, compile tested only.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240110132930.438828-1-dmantipov@yandex.ru
|
|
The CSA countdown in the beacon frames, which are sent out by firmware,
needs to get updated by the driver. To achieve this, convert
update_beacon_work to delayed_work and schedule it with the beacon
interval in case CSA is active and the countdown is not complete.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240111163628.320697-3-martin.kaistra@linutronix.de
|
|
The workqueue might still be running, when the driver is stopped. To
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().
Fixes: e542e66b7c2e ("rtl8xxxu: add bluetooth co-existence support for single antenna")
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240111163628.320697-2-martin.kaistra@linutronix.de
|
|
Currently rtl_usb performs register writes using the async
usb_submit_urb() function. This appears to work fine for the RTL8192CU,
but the RTL8192DU (soon to be supported by rtlwifi) has a problem:
it transmits everything at the 1M rate in the 2.4 GHz band. (The 5 GHz
band is still untested.)
With this patch, rtl_usb performs the register writes using the
synchronous usb_control_msg() function, and the RTL8192DU works
normally. The RTL8192CU still works.
The vendor drivers use the async writes in only one function,
rtl8192du_trigger_gpio_0 / rtl8192cu_trigger_gpio_0, which probably
doesn't even run in real life. They use sync writes everywhere else.
Also, remove "sync" and "async" from the names of the members of
struct rtl_io to avoid confusion:
write{8,16,32}_async -> write{8,16,32}
read{8,16,32}_sync -> read{8,16,32}
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/fb71bae6-8b19-4b6e-b4a6-0d260f2139e1@gmail.com
|
|
Remove unreachable branches in 'rtl92ce_tx_fill_desc()',
'rtl92cu_tx_fill_desc()' and 'rtl8723e_tx_fill_desc()'.
Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240109104735.140550-1-dmantipov@yandex.ru
|
|
Since coming WiFi 7 and existing chips use different update_beacon()
format, add to abstract selection of H2C command.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091359.67636-1-pkshih@realtek.com
|
|
The firmware of coming WiFi 7 chips can support more AP functions, like
virtual AP, so extend format of download beacon frame to configure them.
Currently rtw89 only enables AP mode as old chips, so leave new fields
zeros.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091333.67484-1-pkshih@realtek.com
|
|
Download beacon frame via H2C command for AP mode, and then firmware can
issues beacon periodically. Originally TIM offset minus fixed 24 bytes of
frame header implicitly in macro, and this patch explicitly uses
ieee80211_hdrlen() to get header length, but expected to change nothing
at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091325.67424-1-pkshih@realtek.com
|
|
New H2C command is introduced to pause/sleep transmitting. That extends
more bits to support more MAC ID, and currently we still configure 256
MAC ID at most.
This new command is always used by coming WiFi 7 chips, and existing
chips can use old or new command because firmware still preserves the old
one. Add a firmware feature flag to determine which command is adopted
according to firmware version.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091315.67358-1-pkshih@realtek.com
|
|
To reuse this function to support extended H2C command that is used by
newer chip, change to use a pointer to fill pause ID and mask.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091307.67296-1-pkshih@realtek.com
|
|
The WiFi 6 chips use these commands to create BA CAM entry when RX BA
session is established, this BA CAM can record whether packets are received
or not, then reply BA for current status. This patch doesn't change logic.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091245.67220-1-pkshih@realtek.com
|
|
The total BA CAM number of 8922a is 32 instead of 16, and initial 8
entries are dynamic, so update the entry number to 24.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091134.67007-5-pkshih@realtek.com
|
|
Since chips could use different version of BA CAM H2C command, add a
chip_ops to abstract the operation.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091134.67007-4-pkshih@realtek.com
|
|
Add a call of feature_init() when bringing interface up. For now, the
feature is to reset BA CAM V1 that is only used by upcoming 8922A.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091134.67007-3-pkshih@realtek.com
|
|
BA CAM is used to generate BA frame for received AMPDU packets. To support
WiFi 7, change format from V0 to have more fields and enlarge entry number
for new need.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091134.67007-2-pkshih@realtek.com
|
|
rtl8xxxu_set_basic_rates() sets the wrong initial RTS rate. It sets the
next higher rate than the one it should set, e.g. 36M instead of 24M.
The while loop was supposed to find the index of the most significant
bit which is 1, but it was copied incorrectly from the vendor driver.
Use __fls() instead.
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://msgid.link/761e6836-6cd6-4930-91b6-0446834655c5@gmail.com
|
|
Some devices, like the Comfast CF-826F, use LED1, which already works.
Others, like Asus USB-N13 C1, use LED0, which doesn't work correctly.
Write the right values to the LED control registers to make LED0 work
as well.
This is unfortunately tested only with the Comfast CF-826F.
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://msgid.link/7a2c3158-3a45-4466-b11e-fc09802b20e2@gmail.com
|
|
Everything is in place now for concurrent mode, we can tell the system
that we support it.
We will allow a maximum of 2 virtual interfaces, one of them can be in
AP mode.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-22-martin.kaistra@linutronix.de
|
|
When the driver is used for concurrent mode, both virtual interfaces can
be set to station or AP mode, though only one can be in AP mode at the
same time.
In order to keep the code simple, use only hw port 0 for AP mode. When
an interface is added in AP mode which would be assigned to port 1, use
a switch_port function to transparently swap the mapping between virtual
interface and hw port.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-21-martin.kaistra@linutronix.de
|
|
Add a custom function for allocating entries in the sec cam. This allows
us to store multiple keys with the same keyidx.
The maximum number of sec cam entries for 8188f is 16 according to the
vendor driver. Add the number to rtl8xxxu_fileops, so that other chips
which might support more entries, can set a different number there.
Set the bssid as mac address for group keys instead of just using the
ethernet broadcast address and use BIT(6) in the sec cam ctrl entry
for differentiating them from pairwise keys like in the vendor driver.
Add the TXDESC_EN_DESC_ID bit and the hw_key_idx to tx
broadcast/multicast packets in AP mode.
Finally, allow the usage of rtl8xxxu_set_key() for AP mode.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-20-martin.kaistra@linutronix.de
|
|
Now that all uses of priv->vif have been converted to priv->vifs[]
remove the old attribute.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-19-martin.kaistra@linutronix.de
|
|
Until now, the driver only assigned a dedicated macid for connections
made in AP mode, in STA mode the return value of rtl8xxxu_get_macid()
was simply 0.
To differentiate between port 0 and 1, when both are in STA mode,
allocate a second macid (with value 1) and set sta_info->macid according
to the used port_num in rtl8xxxu_sta_add().
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-18-martin.kaistra@linutronix.de
|
|
Call set_bssid() with the correct port_num now.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-17-martin.kaistra@linutronix.de
|
|
Call set_linktype and set_bssid now with correct port_num. Call
stop_tx_beacon only for port 0, as we don't support beacons on port 1.
Explicit changes to BEACON will only happen for AP type interfaces, so
we don't need an additional check there.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-16-martin.kaistra@linutronix.de
|
|
Add a custom struct to store in vif->drv_priv with a reference to
port_num and fill it when a new interface is added. Choose a free
port_num for the newly added interface.
As we only want to support AP mode/sending beacons on port 0, only change
the beacon settings if a new interface is actually assigned to port 0.
Call set_linktype() and set_mac() with the appropriate port_num.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-15-martin.kaistra@linutronix.de
|
|
Check first whether priv->vifs[0] exists and is of type STATION, then go
to priv->vifs[1]. Make sure to call refresh_rate_mask for both
interfaces.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-14-martin.kaistra@linutronix.de
|
|
As we only want to support AP mode/sending beacons on port 0, change
from priv->vif to priv->vifs[0] in the check for AP mode.
Additionally, if we are in AP mode, don't filter RX beacon and probe
response frames to still allow working STATION mode on the other
interface.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-13-martin.kaistra@linutronix.de
|
|
As we only want to support AP mode/sending beacons on port 0, it is
enough to replace priv->vif with priv->vifs[0].
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-12-martin.kaistra@linutronix.de
|
|
In concurrent mode supported by this driver, both interfaces will use
the same channel and same wireless mode.
It is therefore possible to get the wireless mode by checking the first
connected interface.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-11-martin.kaistra@linutronix.de
|
|
To prepare for concurrent mode, enhance rtl8xxxu_set_bssid() to write the
BSSID of the respective interface to REG_BSSID or REG_BSSID1.
Like done with rtl8xxxu_set_mac(), call rtl8xxxu_set_bssid() with
port_num = 0, until the callers also support multiple interfaces.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-10-martin.kaistra@linutronix.de
|
|
If both interfaces are in STATION mode and both are connected to an AP,
there might be conflicting CFO values for the two connections. Ignore
the CFO information in this case.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-9-martin.kaistra@linutronix.de
|
|
The driver will support two interfaces soon, which both can be in
station mode, so extend the check, whether cfo information should be
parsed, to cover both interfaces.
For better code readability put the lines with priv->vifs[port_num] in a
separate function.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-8-martin.kaistra@linutronix.de
|
|
There are multiple places in the code where the current connection
status of wifi is checked. The driver will support two interfaces soon
and either one of them (or both) could be connected.
Convert all uses of (vif && vif->cfg.assoc) to a new helper
function rtl8xxxu_is_assoc() which checks both interfaces.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-7-martin.kaistra@linutronix.de
|
|
To prepare for concurrent mode, enhance rtl8xxxu_set_mac() to write the
mac address of the respective interface to REG_MACID or REG_MACID1.
Remove the call to rtl8xxxu_set_mac() from the init function as we set
it in rtl8xxxu_add_interface() later anyway.
Until rtl8xxxu_add_interface() can handle both interfaces, call
rtl8xxxu_set_mac() with port_num = 0.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-6-martin.kaistra@linutronix.de
|
|
The driver currently does not support AP or concurrent mode for 8188e,
so just use priv->vifs[0] instead of priv->vif for now.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-5-martin.kaistra@linutronix.de
|
|
To prepare for concurrent mode, enhance the set_linktype function to be
able to set the linktype in the MSR register for both hardware ports.
Until the users of set_linktype can handle multiple interfaces, use
port_num = 0.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-4-martin.kaistra@linutronix.de
|
|
To prepare for concurrent mode, add an array ("vifs") to rtl8xxxu_priv
to keep track of both interfaces.
Keep the old priv->vif as long there are still users of it and let
priv->vifs[0] point to the same location.
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-3-martin.kaistra@linutronix.de
|
|
priv->vif gets already set in rtl8xxxu_add_interface, there is no need
to set it also in rtl8xxxu_bss_info_changed().
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231222101442.626837-2-martin.kaistra@linutronix.de
|
|
Refine the power parameters for better step response especially at high
current ramp case that is caused by power inductor variation.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240103070155.119488-1-pkshih@realtek.com
|
|
There are two spelling mistakes in rtw89_err error messages. Fix these
and also add space between [ERR] and message text.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231220141831.10063-1-colin.i.king@gmail.com
|
|
The channel_info is hardware settings to reflect operational status, such
as scale factor, report unit, buffer matrix size, RU size and so on. Then,
we can get desired reports to do further tuning.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064440.36926-1-pkshih@realtek.com
|
|
TX power is controlled by BB layer basically, but it should interact with
MAC layer, so these registers are put on MAC register domain and called
BB wrapper, which contains TX power for each MAC ID, OFDMA RU power, and
consideration of power type table.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064433.36870-1-pkshih@realtek.com
|
|
NCTL standing for nano-controller is used to assist RF calibration.
Basically, we write settings from a table, but format of the table can't
describe register mask and additional conditions, so add a function to
set this kind of settings.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064422.36812-1-pkshih@realtek.com
|
|
BB parameter file is a list of tuple {addr, val} with conditional hardware
version. However, tuples within a condition can't be empty, so insert a
special dummy tuple for this case. Then, ignore this tuple when writing.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064407.36750-1-pkshih@realtek.com
|
|
DIG standing for dynamic initial gain that is used to adjust RX coverage,
and PD lower threshold is packet detection power level by received signal
strength to avoid false detection of the WiFi packet.
Because of the hardware is different between WiFi 7 and 6 ICs, we adjust
flow and add register definition for 8922A.
Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064228.36580-5-pkshih@realtek.com
|
|
Set values of LNA, TIA and RPL gain compensation read from firmware file
when channel is changed.
Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064228.36580-4-pkshih@realtek.com
|
|
Add RX gain offset dynamic setting flow according to different bands
and bandwidths. RX gain offset values will be different according to
different channel bands, therefore, this dynamic mechanism is needed
while channel is changed. Add this to parse data from the element of
firmware file, and then we can use them easier at runtime.
Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064228.36580-3-pkshih@realtek.com
|