DTS coding style prefers hyphens instead of underscores in the node
names. Change should be safe, because node names are not considered an
ABI.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://patch.msgid.link/20251223152510.155463-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Similar to commit 835a507535 ("selftests/bpf: Add -fms-extensions to
bpf build flags") and commit 639f58a0f4 ("bpftool: Fix build warnings
due to MS extensions")
The kernel is now built with -fms-extensions, therefore
generated vmlinux.h contains types like:
struct slab {
..
struct freelist_counters;
};
Use -fms-extensions and -Wno-microsoft-anon-tag flags
to build bpf programs that #include "vmlinux.h"
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Similar to commit 835a507535 ("selftests/bpf: Add -fms-extensions to
bpf build flags") and commit 639f58a0f4 ("bpftool: Fix build warnings
due to MS extensions")
The kernel is now built with -fms-extensions, therefore
generated vmlinux.h contains types like:
struct slab {
..
struct freelist_counters;
};
Use -fms-extensions and -Wno-microsoft-anon-tag flags
to build bpf programs that #include "vmlinux.h"
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Commit 85b21fdec9 ("thermal/drivers/generic-adc: Register thermal
zones as hwmon sensors") made "generic-adc-thermal" also register hwmon
attributes. That means we now have the temperature sensor shown twice:
- once from iio-hwmon
- and another time from generic-adc-thermal
We need the latter for SoC temperature control, so simply drop the
former so userspace doesn't see duplicate sensors. Also
generic-adc-thermal provides a better name to userspace
("soc_thermal-virtual-0") than iio_hwmon.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://patch.msgid.link/20251108211503.1578711-1-martin.blumenstingl@googlemail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
For use the init_srcu_struct*() to initialized srcu structure,
the srcu structure's->srcu_sup and sda use GFP_KERNEL flags to
allocate memory. similarly, if set SRCU_SIZING_INIT, the
srcu_sup's->node can still use GFP_KERNEL flags to allocate
memory, not need to use GFP_ATOMIC flags all the time.
Signed-off-by: Zqiang <qiang.zhang@linux.dev>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Tested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Lack of parentheses causes the ->exp_current() function, for example,
srcu_expedite_current(), to be called only once in four billion times
instead of the intended once in 256 times. This commit therefore adds
the needed parentheses.
Reported-by: Chris Mason <clm@meta.com>
Reported-by: Joel Fernandes <joelagnelf@nvidia.com>
Fixes: 950063c6e8 ("rcutorture: Test srcu_expedite_current()")
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
If an expedited RCU CPU stall ends just at the stall-warning timeout,
the current code will print an expedited stall-warning message, but one
that doesn't identify any CPUs or tasks causing the stall. This is most
likely to happen for short-timeout stalls, for example, the 20-millisecond
timeouts that are sometimes used for small embedded devices. Needless to
say, these semi-empty stall-warning messages can be rather confusing.
One option would be to suppress the stall-warning message entirely in
this case, but the near-miss information can be quite valuable.
Detect this race condition and emits a "INFO: Expedited stall ended
before state dump start" message to clarify matters.
[boqun: Apply feedback from Borislav]
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
After resume from suspend to RAM, the following splash is generated if
the HDMI driver is probed (independent of a connected cable):
[ 1194.484052] irq 80: nobody cared (try booting with the "irqpoll" option)
[ 1194.484074] CPU: 0 UID: 0 PID: 627 Comm: rtcwake Not tainted 6.17.0-rc7-g96f1a11414b3 #1 PREEMPT
[ 1194.484082] Hardware name: Rockchip RK3576 EVB V10 Board (DT)
[ 1194.484085] Call trace:
[ 1194.484087] ... (stripped)
[ 1194.484283] handlers:
[ 1194.484285] [<00000000bc363dcb>] dw_hdmi_qp_main_hardirq [dw_hdmi_qp]
[ 1194.484302] Disabling IRQ #80
Apparently the HDMI IP is losing part of its state while the system
is suspended and generates spurious interrupts during resume. The
bug has not yet been noticed, as system suspend does not yet work
properly on upstream kernel with either the Rockchip RK3588 or RK3576
platform.
Fixes: 128a9bf8ac ("drm/rockchip: Add basic RK3588 HDMI output support")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251014-rockchip-hdmi-suspend-fix-v1-1-983fcbf44839@collabora.com
The value of FPEX32_EL2 has no effect on execution in AArch64 state, and
consequently there's no need for an ISB after writing to it in the hyp
code (which executes in AArch64 state). When performing an exception
return to AArch32 state, the exception return will provide the necessary
context synchronization event.
Remove the redundant ISB.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260106173707.3292074-4-mark.rutland@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
There's a gap in the KVM_HOST_DATA_FLAG_* indices since the removal of
KVM_HOST_DATA_FLAG_HOST_SVE_ENABLED and
KVM_HOST_DATA_FLAG_HOST_SME_ENABLED in commits:
* 459f059be7 ("KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN")
* 407a99c465 ("KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN")
Shuffle the indices to remove the gap, as Oliver requested at the time of
the removals:
https://lore.kernel.org/linux-arm-kernel/Z6qC4qn47ONfDCSH@linux.dev/
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20260106173707.3292074-3-mark.rutland@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
The comment in fpsimd_lazy_switch_to_host() erroneously says guest traps
for FPSIMD/SVE/SME are disabled by fpsimd_lazy_switch_to_guest(). In
reality, the traps are disabled by __activate_cptr_traps(), and
fpsimd_lazy_switch_to_guest() only manipulates the SVE vector length.
This was mistake; I accidentally copy+pasted the wrong function name in
commit:
59419f1004 ("KVM: arm64: Eagerly switch ZCR_EL{1,2}")
Fix the comment.
Fixes: 59419f1004 ("KVM: arm64: Eagerly switch ZCR_EL{1,2}")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260106173707.3292074-2-mark.rutland@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
It already have default for error case (A), no need to have
SND_SOC_DAIFMT_RIGHT_J for error (B). Remove it.
static int es8375_set_dai_fmt(...)
...
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_RIGHT_J:
(B) return -EINVAL;
...
default:
(A) return -EINVAL;
}
...
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87eco20zn3.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If manipulating big-endian data, make the pointers be big-endian
instead of host-endian. This should stop the following sparse
warnigns about endian-conversion:
sound/soc/soc-ops.c:547:33: warning: invalid assignment: &=
sound/soc/soc-ops.c:547:33: left side has type unsigned short
sound/soc/soc-ops.c:547:33: right side has type restricted __be16
sound/soc/soc-ops.c:551:33: warning: invalid assignment: &=
sound/soc/soc-ops.c:551:33: left side has type unsigned int
sound/soc/soc-ops.c:551:33: right side has type restricted __be32
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260106225846.83580-1-ben.dooks@codethink.co.uk
Signed-off-by: Mark Brown <broonie@kernel.org>
linux-next merge complains about build break with make htmldocs :
Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda:45: ERROR: Unexpected indentation. [docutils]
Closes: https://lkml.kernel.org/r/20260106114933.638b073f@canb.auug.org.au
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jie Gan <jie.gan@oss.qualcomm.com>
Cc: Tao Zhang <tao.zhang@oss.qualcomm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
In order to enable the HDMI output support on Mediatek Genio 510-EVK,
700-EVK, and 1200-EVK boards, enable the driver for it in the default
configuration.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
It's a requirement that DT overlays be applied at build time in order to
validate them as overlays are not validated on their own.
Add missing target for mt8395-radxa hd panel overlay.
Fixes: 4c8ff61199 ("arm64: dts: mediatek: mt8395-radxa-nio-12l: Add Radxa 8 HD panel")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: AngeloGioacchino Del Regno <angelogiaocchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Build devicetree binaries for testing overlays and providing users
full dtb without using overlays for Bananapi R4 (pro) variants.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
DTS coding style prefers hyphens instead of underscores in the node
names. Change should be safe, because node names are not considered an
ABI.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
We allocate memory for the GPIO lookup table at the top of
gpio_shared_add_proxy_lookup() but we don't use it until the very end.
Depending on the timing, we may return earlier. Move the allocation
towards the end.
Fixes: a060b8c511 ("gpiolib: implement low-level, shared GPIO support")
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20260106-gpio-shared-fixes-v2-3-c7091d2f7581@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
When matching the reset-gpio reference with the actual firmware node
consuming the GPIO, we also need to lock the structure associated with
the latter as it can change while we're doing it.
Due to triggering lockdep false-positives, we need to use a per-reference
lockdep class but accidentally, this also allows us to remove the
previous lockdep workaround for cleaner code.
Fixes: 49416483a9 ("gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20260106-gpio-shared-fixes-v2-2-c7091d2f7581@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
When we defer probe due to unlucky timing of adding the lookup table, we
assign the matching firmware node to the shared reference for the future
probing. However, the fwnode we assign is wrong so fix it and assign the
one associated with the reset-gpio device.
Fixes: 49416483a9 ("gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20260106-gpio-shared-fixes-v2-1-c7091d2f7581@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
voltages over internal rails. Implement power sequencing support for
this generation of WCN chips. Unlike later devices, they don't have
separate enable GPIO lines, letting the chip figure out the necessary
parts on its own.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-5-0386204328be@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
WCN3990 and other similar WiFi/BT chips incorporate a simple on-chip PMU
(clearly described as such in the documentation). Provide DT schema
covering other Qualcomm WiFi/BT chips to cover these devices too.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-1-0386204328be@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Use the generic fwnode interface for retrieving device match data
instead of the OF-specific one.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20251125134700.29135-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Use the correct function names and add a function parameter description
to avoid kernel-doc warnings:
hda_jack.h:97: warning: Function parameter or struct member 'cb' not
described in 'snd_hda_jack_detect_enable_callback'
hda_jack.h:97: warning: expecting prototype for snd_hda_jack_detect_enable().
Prototype was for snd_hda_jack_detect_enable_callback() instead
hda_local.h:441: warning: expecting prototype for _snd_hda_set_pin_ctl().
Prototype was for snd_hda_set_pin_ctl() instead
Fixes: cdd03cedc5 ("ALSA: hda - Introduce snd_hda_set_pin_ctl*() helper functions")
Fixes: 5204a05d70 ("ALSA: hda - Add DP-MST jack support")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260106185951.2179242-1-rdunlap@infradead.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When building with clang older than 17 targeting architectures that use
asm goto for their get_user() and put_user(), such as arm64, after
commit f3d233daf0 ("ALSA: pcm: Relax __free() variable declarations"),
there are bogus errors around skipping over a variable declared with the
cleanup attribute:
sound/core/pcm_native.c:3308:6: error: cannot jump from this asm goto statement to one of its possible targets
if (put_user(result, &_xfern->result))
^
...
arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_mem_asm'
asm goto(
^
sound/core/pcm_native.c:3295:6: note: possible target of asm goto statement
if (put_user(0, &_xfern->result))
^
...
sound/core/pcm_native.c:3300:8: note: jump exits scope of variable with __attribute__((cleanup))
void *bufs __free(kfree) =
^
clang-17 fixed a bug in clang's jump scope checker [1] where all labels
in a function were checked as valid targets for all asm goto instances
in a function, regardless of whether they were actual targets in a
paricular asm goto's provided list of labels.
To workaround this, revert the change done to
snd_pcm_xfern_frames_ioctl() by commit f3d233daf0 ("ALSA: pcm: Relax
__free() variable declarations") to avoid a variable declared with
cleanup from existing between multiple uses of asm goto. There are no
other uses of cleanup in this function so there should be low risk from
moving this variable back to the top of the function.
Link: https://github.com/ClangBuiltLinux/linux/issues/1886 [1]
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512190802.i4Jzbcsl-lkp@intel.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260106-pcm_native-revert-var-move-free-for-old-clang-v1-1-06a03693423d@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The RFE type 5 should set different DSWR parameters when card power on.
Therefore, add the corresponding register settings for this type.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-12-pkshih@realtek.com
During fuzz testing, it was discovered that bss_conf->beacon_int
might be zero, which could result in a division by zero error in
subsequent calculations. Set a default value of 100 TU if the
interval is zero to ensure stability.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-11-pkshih@realtek.com
The H2C command rtw89_fw_h2c_rf_pre_ntfy_mcc have different format.
8922A after FW 0.35.49.0 use v0, after FW 0.35.84.0 use v1. The coming
8922D will use v2.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-10-pkshih@realtek.com
Actually, WITH_RFK_PRE_NOTIFY means supporting one of RFK_PRE_NOTIFY_Vx.
So, change it to be a FW feature group which contains RFK_PRE_NOTIFY_Vx.
Then, because WITH_RFK_PRE_NOTIFY is abandoned after some FW versions by
chip, disable WITH_RFK_PRE_NOTIFY correspondingly in FW feature table.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-9-pkshih@realtek.com
In the FW feature table, V0 and V1 was configured by lt, less than. So, V1
flag was also set in the range of V0. However, in RFK_PRE_NOTIFY handling,
rtw89_fw_h2c_rf_pre_ntfy, V1 is tested before V0. Things would process as
V1 even if V0 should be used.
Tweak FW feature configuration by ge, greater or equal, to align handling.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-7-pkshih@realtek.com
Some FW features (groups) may be valid only in a range of FW versions,
i.e. after some FW versions, they can no longer be used. So, introduce
some helper macros to configure this kind of things in FW feature table.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-6-pkshih@realtek.com
Originally, FW feature map was declared as a u32. But, the number of FW
feature flags is going to be over than 32. So, change it to a BITMAP and
update the corresponding macros.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-5-pkshih@realtek.com
The Wi-Fi 7 RF calibration flow has a new design which mainly affect
MLO cases. Before, old RFK H2C command can just send the used channels
and MLO mode even if there are multiple active links. After, each RFK
H2C command should send one channel corresponding to one active link.
For example, connect MLD AP (channel X) and then activate second link
(channel X + channel Y)
Before:
RFK#1: channel X (path A + path B)
RFK#2: channel X (path A) + channel Y (path B)
After:
RFK#1: channel X (path A + path B)
[set MLO mode to focus on 2nd link/channel]
RFK#2: channel Y (path A + path B)
[set MLO mode back to target case]
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-4-pkshih@realtek.com
The pre-notify is to notify firmware the configured channels, and then
RF calibration in firmware can use these values to calibrate RF properly.
Since we need more information, change and add the new H2C command format.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-3-pkshih@realtek.com
The H2C command of RFK pre info is to tell current operating channels to
firmware, so RF calibrations can rely on these information as arguments
to configure hardware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-2-pkshih@realtek.com
The tee bus got dedicated callbacks for probe and remove.
Make use of these. This fixes a runtime warning about the driver needing
to be converted to the bus methods.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
tee_client_driver_register() is typed more strongly and cares about
assigning the driver's bus. Similar for tee_client_driver_unregister().
Make use of these functions.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
The tee bus got dedicated callbacks for probe and remove.
Make use of these. This fixes a runtime warning about the driver needing
to be converted to the bus methods.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
The tee subsystem recently got a set of dedicated functions to register
(and unregister) a tee driver. Make use of them. These care for setting the
driver's bus (so the explicit assignment can be dropped) and the driver
owner (which is an improvement this driver benefits from).
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
The tee bus got dedicated callbacks for probe and remove.
Make use of these. This fixes a runtime warning about the driver needing
to be converted to the bus methods.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reduce boilerplate by using the newly introduced module_tee_client_driver().
That takes care of assigning the driver's bus, so the explicit assigning
in this driver can be dropped.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
The tee bus got dedicated callbacks for probe and remove.
Make use of these. This fixes a runtime warning about the driver needing
to be converted to the bus methods. Note that the return value of .remove()
was already ignored before, so there is no problem introduced by dropping
the error returns.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reduce boilerplate by using the newly introduced module_tee_client_driver().
That takes care of assigning the driver's bus, so the explicit assigning
in this driver can be dropped.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
