* [PATCH v2 3/4] arm64: dts: ti: k3-am67a-beagley-ai: Add overlay for IMX219 on CSI0
From: Jai Luthra @ 2026-05-15 1:16 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Robert Nelson, Andrew Davis, Devarsh Thakkar, Tomi Valkeinen,
linux-arm-kernel, devicetree, linux-kernel, Jai Luthra
In-Reply-To: <20260515-beagley-cameras-v2-0-f6acb66c9995@ideasonboard.com>
RPi v2 Camera (IMX219) is an 8MP camera that can be used with BeagleY AI
through the 22-pin CSI-RX connectors. Add a DT overlay to enable use of
this camera sensor through the CSI0 connector.
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso | 121 +++++++++++++++++++++
2 files changed, 125 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 5269c9619b65..68a82e161c20 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -152,6 +152,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
# Boards with J722s SoC
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai-csi0-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
@@ -245,6 +246,8 @@ k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
+k3-am67a-beagley-ai-csi0-imx219-dtbs := k3-am67a-beagley-ai.dtb \
+ k3-am67a-beagley-ai-csi0-imx219.dtbo
k3-am68-sk-base-board-csi2-dual-imx219-dtbs := k3-am68-sk-base-board.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
k3-am68-sk-base-board-pcie1-ep-dtbs := k3-am68-sk-base-board.dtb \
@@ -318,6 +321,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am642-phyboard-electra-x27-gpio1-spi1-uart3.dtb \
k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
+ k3-am67a-beagley-ai-csi0-imx219.dtb \
k3-am68-phyboard-izar-lvds-ph128800t006.dtb \
k3-am68-phyboard-izar-peb-av-15.dtb \
k3-am68-sk-base-board-csi2-dual-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso
new file mode 100644
index 000000000000..998e178d8d1a
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * RPi Camera V2.1 on BeagleY AI CSI0 port
+ *
+ * Copyright (C) 2026 Ideas On Board Oy
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+ clk_imx219_csi0: imx219-csi0-xclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
+ reg_2p8v_csi0: regulator-2p8v-csi0 {
+ compatible = "regulator-fixed";
+ regulator-name = "2P8V_CSI0";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ reg_1p8v_csi0: regulator-1p8v-csi0 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V_CSI0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ reg_1p2v_csi0: regulator-1p2v-csi0 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P2V_CSI0";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+};
+
+&mcu_pmx0 {
+ cam0_reset_pins_default: cam0-default-reset-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x003c, PIN_OUTPUT, 7) /* (C1) MCU_MCAN1_TX.MCU_GPIO0_15 */
+ >;
+ };
+};
+
+&mcu_gpio0 {
+ status = "okay";
+};
+
+&main_i2c2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c2_pins_default>;
+ clock-frequency = <400000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx219_0: sensor@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+
+ clocks = <&clk_imx219_csi0>;
+
+ VANA-supply = <®_2p8v_csi0>;
+ VDIG-supply = <®_1p8v_csi0>;
+ VDDL-supply = <®_1p2v_csi0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam0_reset_pins_default>;
+
+ reset-gpios = <&mcu_gpio0 15 GPIO_ACTIVE_HIGH>;
+
+ port {
+ csi2_cam0: endpoint {
+ remote-endpoint = <&csi2rx0_in_sensor>;
+ link-frequencies = /bits/ 64 <456000000>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2rx0_in_sensor: endpoint {
+ remote-endpoint = <&csi2_cam0>;
+ bus-type = <4>; /* CSI2 DPHY. */
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: ti: k3-am67a-beagley-ai: Add overlay for IMX219 on CSI1
From: Jai Luthra @ 2026-05-15 1:16 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Robert Nelson, Andrew Davis, Devarsh Thakkar, Tomi Valkeinen,
linux-arm-kernel, devicetree, linux-kernel, Jai Luthra
In-Reply-To: <20260515-beagley-cameras-v2-0-f6acb66c9995@ideasonboard.com>
RPi v2 Camera (IMX219) is an 8MP camera that can be used with BeagleY AI
through the 22-pin CSI-RX connectors. Add a DT overlay to enable use of
this camera sensor through the CSI1 connector.
The CSI1 connector is muxed with DSI0, so ensure that we route it to
CSI1 (DSI_CSI_OE=0 and DSI_CSI_SEL=1).
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../dts/ti/k3-am67a-beagley-ai-csi1-imx219.dtso | 121 +++++++++++++++++++++
2 files changed, 125 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 68a82e161c20..51e74f26c803 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -153,6 +153,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
# Boards with J722s SoC
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai-csi0-imx219.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai-csi1-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
@@ -248,6 +249,8 @@ k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
k3-am67a-beagley-ai-csi0-imx219-dtbs := k3-am67a-beagley-ai.dtb \
k3-am67a-beagley-ai-csi0-imx219.dtbo
+k3-am67a-beagley-ai-csi1-imx219-dtbs := k3-am67a-beagley-ai.dtb \
+ k3-am67a-beagley-ai-csi1-imx219.dtbo
k3-am68-sk-base-board-csi2-dual-imx219-dtbs := k3-am68-sk-base-board.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
k3-am68-sk-base-board-pcie1-ep-dtbs := k3-am68-sk-base-board.dtb \
@@ -322,6 +325,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
k3-am67a-beagley-ai-csi0-imx219.dtb \
+ k3-am67a-beagley-ai-csi1-imx219.dtb \
k3-am68-phyboard-izar-lvds-ph128800t006.dtb \
k3-am68-phyboard-izar-peb-av-15.dtb \
k3-am68-sk-base-board-csi2-dual-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi1-imx219.dtso b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi1-imx219.dtso
new file mode 100644
index 000000000000..b3ae76e03fe3
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi1-imx219.dtso
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * RPi Camera V2.1 on BeagleY AI CSI1 port
+ *
+ * Copyright (C) 2026 Ideas On Board Oy
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+ clk_imx219_csi1: imx219-csi1-xclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
+ reg_2p8v_csi1: regulator-2p8v-csi1 {
+ compatible = "regulator-fixed";
+ regulator-name = "2P8V_CSI1";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ reg_1p8v_csi1: regulator-1p8v-csi1 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V_CSI1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ reg_1p2v_csi1: regulator-1p2v-csi1 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P2V_CSI1";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+};
+
+&main_pmx0 {
+ cam1_reset_pins_default: cam1-default-reset-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01d8, PIN_OUTPUT, 7) /* (D22) MCAN0_TX.GPIO1_24 */
+ >;
+ };
+};
+
+&dsi_csi_mux {
+ idle-state = <1>;
+};
+
+&main_i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c0_pins_default>;
+ clock-frequency = <400000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx219_1: sensor@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+
+ clocks = <&clk_imx219_csi1>;
+
+ VANA-supply = <®_2p8v_csi1>;
+ VDIG-supply = <®_1p8v_csi1>;
+ VDDL-supply = <®_1p2v_csi1>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam1_reset_pins_default>;
+
+ reset-gpios = <&main_gpio1 24 GPIO_ACTIVE_HIGH>;
+
+ port {
+ csi2_cam1: endpoint {
+ remote-endpoint = <&csi2rx1_in_sensor>;
+ link-frequencies = /bits/ 64 <456000000>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2rx1_in_sensor: endpoint {
+ remote-endpoint = <&csi2_cam1>;
+ bus-type = <4>; /* CSI2 DPHY. */
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 17/21] objtool/klp: Don't correlate arm64 mapping symbols
From: sashiko-bot @ 2026-05-15 1:19 UTC (permalink / raw)
To: x86
Cc: linux-kernel, Petr Mladek, Song Liu, live-patching, Mark Rutland,
Peter Zijlstra, linux-arm-kernel, Will Deacon, Miroslav Benes,
Catalin Marinas, Joe Lawrence
In-Reply-To: <48efc64058f667159d3dedf367c1d4cdedf84f1c.1778642120.git.jpoimboe@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `is_mapping_sym()` function relies on an overly broad substring match (`strchr(sym->name, '$')`), which risks falsely classifying any unannotated (`STT_NOTYPE`) symbol containing a `$` as an ARM64 mapping symbol.
--
commit fb925cb10f7a9c6ab8ecefca87d3cd3b4e4da879
Author: Josh Poimboeuf <jpoimboe@kernel.org>
objtool/klp: Don't correlate arm64 mapping symbols
This commit updates the livepatch diff tool to skip the correlation of arm64
mapping symbols. These symbols mark transitions between code and data but are
not standard symbols that require correlation.
> diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
> index eb21f3bf3120b..e1d4d94c9d77c 100644
> --- a/tools/objtool/klp-diff.c
> +++ b/tools/objtool/klp-diff.c
> @@ -501,6 +501,7 @@ static bool dont_correlate(struct symbol *sym)
> is_prefix_func(sym) ||
> is_uncorrelated_static_local(sym) ||
> is_local_label(sym) ||
> + is_mapping_sym(sym) ||
Does this code risk falsely classifying user-defined or macro-generated
assembly labels as mapping symbols?
Looking at the definition:
tools/objtool/include/objtool/elf.h:is_mapping_sym() {
return is_notype_sym(sym) && strchr(sym->name, '$');
}
Because it relies on a broad substring match, could this exclude valid
unannotated STT_NOTYPE symbols containing a $ from correlation across all
architectures?
Triggering a livepatching failure would require an unusual edge case, but
would it be safer to use a stricter match for standard arm64 mapping symbol
formats like $x or $d?
> is_string_sec(sym->sec) ||
> is_anonymous_rodata(sym) ||
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778642120.git.jpoimboe@kernel.org?part=17
^ permalink raw reply
* Re: [PATCH] PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro
From: Krzysztof Wilczyński @ 2026-05-15 1:27 UTC (permalink / raw)
To: lirongqing
Cc: Ryder Lee, Jianjun Wang, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Bjorn Helgaas, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pci, linux-mediatek,
linux-arm-kernel
In-Reply-To: <20260515005552.2343-1-lirongqing@baidu.com>
Hello,
> The original PCIE_FTS_NUM_L0(x) macro was buggy due to improper operator
> precedence, where ((x) & 0xff << 8) was evaluated as ((x) & 0xff00).
>
> Instead of just fixing the parentheses, use the standard FIELD_PREP()
> macro. This makes the code more robust by automatically handling masks
> and shifts, while also adding compile-time type and range checking to
> ensure the value fits within PCIE_FTS_NUM_MASK.
>
> Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller support")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> drivers/pci/controller/pcie-mediatek.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 7572252..00f0e29 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -61,7 +61,7 @@
> /* MediaTek specific configuration registers */
> #define PCIE_FTS_NUM 0x70c
> #define PCIE_FTS_NUM_MASK GENMASK(15, 8)
> -#define PCIE_FTS_NUM_L0(x) ((x) & 0xff << 8)
> +#define PCIE_FTS_NUM_L0(x) FIELD_PREP(PCIE_FTS_NUM_MASK, x)
Aww. Nice catch! Thank you for fixing this!
Happy to offer:
Reviewed-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
All the best,
Krzysztof
^ permalink raw reply
* [PATCH] Enable stage 2 translation in L2
From: Itaru Kitayama @ 2026-05-15 1:48 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Paolo Bonzini, Shuah Khan
Cc: linux-arm-kernel, kvmarm, kvm, linux-kselftest, linux-kernel,
Itaru Kitayama
IPA size and start level are configurable at build time.
Signed-off-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
---
Enable stage 2 translation in L2, but keep stage 1 remain off
as Wei Lin prefers. Types are changed accordingly due to the
recent selftest-wide changes.
---
tools/testing/selftests/kvm/arm64/hello_nested.c | 11 +-
tools/testing/selftests/kvm/include/arm64/nested.h | 38 ++-
tools/testing/selftests/kvm/lib/arm64/hyp-entry.S | 5 +
tools/testing/selftests/kvm/lib/arm64/nested.c | 279 ++++++++++++++++++++-
4 files changed, 322 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/kvm/arm64/hello_nested.c b/tools/testing/selftests/kvm/arm64/hello_nested.c
index 69f4d8e750e2..1ac045894b89 100644
--- a/tools/testing/selftests/kvm/arm64/hello_nested.c
+++ b/tools/testing/selftests/kvm/arm64/hello_nested.c
@@ -18,9 +18,9 @@
/*
* TPIDR_EL2 is used to store vcpu id, so save and restore it.
*/
-static vm_paddr_t ucall_translate_to_gpa(void *gva)
+static gpa_t ucall_translate_to_gpa(void *gva)
{
- vm_paddr_t gpa;
+ gpa_t gpa;
u64 vcpu_id = read_sysreg(tpidr_el2);
GUEST_SYNC2(XLATE2GPA, gva);
@@ -50,7 +50,7 @@ static void guest_code(void)
struct vcpu vcpu;
struct hyp_data hyp_data;
int ret;
- vm_paddr_t l2_pc, l2_stack_top;
+ gpa_t l2_pc, l2_stack_top;
/* force 16-byte alignment for the stack pointer */
u8 l2_stack[L2STACKSZ] __attribute__((aligned(16)));
u64 arg1, arg2;
@@ -92,7 +92,7 @@ int main(void)
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
struct ucall uc;
- vm_paddr_t gpa;
+ gpa_t gpa;
TEST_REQUIRE(kvm_check_cap(KVM_CAP_ARM_EL2));
vm = vm_create(1);
@@ -102,13 +102,14 @@ int main(void)
vcpu = aarch64_vcpu_add(vm, 0, &init, guest_code);
kvm_arch_vm_finalize_vcpus(vm);
+ prepare_hyp_state(vm, vcpu);
while (true) {
vcpu_run(vcpu);
switch (get_ucall(vcpu, &uc)) {
case UCALL_SYNC:
if (uc.args[0] == XLATE2GPA) {
- gpa = addr_gva2gpa(vm, (vm_vaddr_t)uc.args[1]);
+ gpa = addr_gva2gpa(vm, (gva_t)uc.args[1]);
vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_TPIDR_EL2), gpa);
}
break;
diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
index b16a72488858..b4ccca3593db 100644
--- a/tools/testing/selftests/kvm/include/arm64/nested.h
+++ b/tools/testing/selftests/kvm/include/arm64/nested.h
@@ -18,14 +18,44 @@
#include <asm/ptrace.h>
#include "kvm_util.h"
+#include "processor.h"
extern char hyp_vectors[];
+#ifdef CONFIG_ARM64_64K_PAGES
+
+#define VTCR_EL2_TGRAN 64K
+#define VTCR_EL2_TGRAN_SL0_BASE 3UL
+
+#elif defined(CONFIG_ARM64_16K_PAGES)
+
+#define VTCR_EL2_TGRAN 16K
+#define VTCR_EL2_TGRAN_SL0_BASE 3UL
+
+#else /* 4K */
+
+#define VTCR_EL2_TGRAN 4K
+#define VTCR_EL2_TGRAN_SL0_BASE 2UL
+
+#endif
+
+struct s2_config {
+ u64 granule;
+ u8 ia_bits;
+ u8 oa_bits;
+ u8 start_level;
+};
+
+u64 get_l1_vtcr(const struct s2_config *cfg);
+
+void nested_map(struct kvm_vm *vm, const struct s2_config *cfg, gpa_t guest_pgd, uint64_t nested_paddr, uint64_t paddr, uint64_t size);
+void nested_map_memslot(struct kvm_vm *vm, const struct s2_config *cfg, gpa_t guest_pgd, u32 memslot);
+
enum vcpu_sysreg {
__INVALID_SYSREG__, /* 0 is reserved as an invalid value */
SP_EL1,
-
+ ESR_EL2,
NR_SYS_REGS
};
@@ -47,12 +77,14 @@ struct hyp_data {
};
void prepare_hyp(void);
-void init_vcpu(struct vcpu *vcpu, vm_paddr_t l2_pc, vm_paddr_t l2_stack_top);
+void init_vcpu(struct vcpu *vcpu, gpa_t l2_pc, gpa_t l2_stack_top);
int run_l2(struct vcpu *vcpu, struct hyp_data *hyp_data);
u64 do_hvc(u64 action, u64 arg1, u64 arg2);
+u64 vcpu_get_esr_el2(struct vcpu *vcpu);
+
u64 __guest_enter(struct vcpu *vcpu, struct cpu_context *hyp_context);
-void __hyp_exception(u64 type);
+void __hyp_exception(u64 type, u64 esr, u64 elr, u64 far, u64 hpfar, u64 spsr);
void __sysreg_save_el1_state(struct cpu_context *ctxt);
void __sysreg_restore_el1_state(struct cpu_context *ctxt);
diff --git a/tools/testing/selftests/kvm/lib/arm64/hyp-entry.S b/tools/testing/selftests/kvm/lib/arm64/hyp-entry.S
index 6341f6e05c90..fcf7bb303b77 100644
--- a/tools/testing/selftests/kvm/lib/arm64/hyp-entry.S
+++ b/tools/testing/selftests/kvm/lib/arm64/hyp-entry.S
@@ -30,6 +30,11 @@ el1_error:
b __guest_exit
el2_sync:
+ mrs x1, esr_el2
+ mrs x2, elr_el2
+ mrs x3, far_el2
+ mrs x4, hpfar_el2
+ mrs x5, spsr_el2
mov x0, #ARM_EXCEPTION_EL2_TRAP
b __hyp_exception
diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
index b30d20b101c4..104c98d29eb9 100644
--- a/tools/testing/selftests/kvm/lib/arm64/nested.c
+++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
@@ -7,15 +7,269 @@
#include "processor.h"
#include "test_util.h"
#include <asm/sysreg.h>
+#include <linux/sizes.h>
+
+static const struct s2_config default_s2_cfg = {
+ .granule = SZ_4K,
+ .ia_bits = 40,
+ .oa_bits = 40,
+ .start_level = 0,
+};
+
+static u64 s2_alloc_page_table(struct kvm_vm *vm, const struct s2_config *cfg)
+{
+ u64 nr_pages = cfg->granule >> vm->page_shift;
+
+ TEST_ASSERT(!(cfg->granule & (vm->page_size - 1)),
+ "S2 granule 0x%lx smaller/not aligned to VM page size 0x%x",
+ cfg->granule, vm->page_size);
+
+ return vm_phy_pages_alloc(vm, nr_pages,
+ KVM_GUEST_PAGE_TABLE_MIN_PADDR,
+ vm->memslots[MEM_REGION_PT]);
+}
void prepare_hyp(void)
{
- write_sysreg(HCR_EL2_E2H | HCR_EL2_RW, hcr_el2);
+ write_sysreg(HCR_EL2_E2H | HCR_EL2_RW | HCR_EL2_VM, hcr_el2);
write_sysreg(hyp_vectors, vbar_el2);
isb();
}
-void init_vcpu(struct vcpu *vcpu, vm_paddr_t l2_pc, vm_paddr_t l2_stack_top)
+static unsigned int s2_granule_shift(const struct s2_config *cfg)
+{
+ switch (cfg->granule) {
+ case SZ_4K:
+ return 12;
+ case SZ_16K:
+ return 14;
+ case SZ_64K:
+ return 16;
+ default:
+ TEST_FAIL("Unsupported stage-2 granule %u", cfg->granule);
+ }
+}
+
+static unsigned int s2_level_stride(const struct s2_config *cfg)
+{
+ return s2_granule_shift(cfg) - 3;
+}
+
+static unsigned int s2_ptrs_per_table(const struct s2_config *cfg)
+{
+ return 1U << s2_level_stride(cfg);
+}
+
+static u64 s2_index_mask(const struct s2_config *cfg)
+{
+ return s2_ptrs_per_table(cfg) - 1;
+}
+
+static unsigned int s2_last_level(const struct s2_config *cfg)
+{
+ return 3;
+}
+
+static unsigned int s2_level_shift(const struct s2_config *cfg,
+ unsigned int level)
+{
+ return s2_granule_shift(cfg) +
+ (s2_last_level(cfg) - level) * s2_level_stride(cfg);
+}
+
+static u64 s2_table_mask(const struct s2_config *cfg)
+{
+ return GENMASK_ULL(cfg->ia_bits - 1, s2_granule_shift(cfg));
+}
+
+static u64 s2_output_mask(const struct s2_config *cfg)
+{
+ return GENMASK_ULL(cfg->oa_bits - 1, s2_granule_shift(cfg));
+}
+
+static u64 s2_desc_table(u64 paddr, const struct s2_config *cfg)
+{
+ return (paddr & s2_table_mask(cfg)) | 0x3;
+}
+
+#define S2_MEMATTR_NORMAL_WB 0xfUL
+#define S2_MEMATTR_SHIFT 2
+
+#define S2_S2AP_R BIT(6)
+#define S2_S2AP_W BIT(7)
+
+#define S2_SH_INNER (3UL << 8)
+
+
+static u64 s2_desc_page(u64 paddr, u64 flags, const struct s2_config *cfg)
+{
+ u64 desc;
+
+ desc = paddr & s2_output_mask(cfg);
+
+ /* Stage-2 lower attrs */
+ desc |= S2_MEMATTR_NORMAL_WB << S2_MEMATTR_SHIFT;
+ desc |= S2_S2AP_R | S2_S2AP_W;
+ desc |= S2_SH_INNER;
+ desc |= PTE_AF;
+
+ /* L3 page descriptor: bits[1:0] = 0b11 */
+ desc |= PTE_TYPE_PAGE;
+ desc |= PTE_VALID;
+
+ return desc;
+}
+
+static inline int ipa_bits_to_ps(unsigned int ipa_bits)
+{
+ switch (ipa_bits) {
+ case 32:
+ return 0b000;
+ case 36:
+ return 0b001;
+ case 40:
+ return 0b010;
+ case 42:
+ return 0b011;
+ case 44:
+ return 0b100;
+ case 48:
+ return 0b101;
+ case 52:
+ return 0b110;
+ default:
+ return -EINVAL;
+ }
+}
+
+u64 get_l1_vtcr(const struct s2_config *cfg)
+{
+ if (!cfg)
+ cfg = &default_s2_cfg;
+
+ return FIELD_PREP(VTCR_EL2_PS, ipa_bits_to_ps(cfg->ia_bits)) |
+ FIELD_PREP(VTCR_EL2_TG0, VTCR_EL2_TG0_4K) |
+ FIELD_PREP(VTCR_EL2_ORGN0_MASK, VTCR_EL2_ORGN0_WBWA) |
+ FIELD_PREP(VTCR_EL2_IRGN0_MASK, VTCR_EL2_IRGN0_WBWA) |
+ FIELD_PREP(VTCR_EL2_SH0_MASK, VTCR_EL2_SH0_INNER) |
+ FIELD_PREP(VTCR_EL2_SL0, VTCR_EL2_TGRAN_SL0_BASE - cfg->start_level) |
+ FIELD_PREP(VTCR_EL2_T0SZ_MASK, 64 - cfg->ia_bits);
+}
+
+void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
+{
+ const struct s2_config *cfg = &default_s2_cfg;
+ u64 guest_pgd;
+
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTCR_EL2), get_l1_vtcr(cfg));
+
+ guest_pgd = s2_alloc_page_table(vm, cfg);
+ nested_map_memslot(vm, cfg, guest_pgd, 0);
+
+ pr_debug("cfg=%p ia_bits=%u oa_bits=%u granule=%u\n",
+ cfg, cfg->ia_bits, cfg->oa_bits, cfg->granule);
+
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTTBR_EL2), guest_pgd);
+}
+
+static void __nested_pg_map(struct kvm_vm *vm,
+ const struct s2_config *cfg,
+ u64 guest_pgd,
+ u64 nested_paddr,
+ u64 paddr,
+ u64 flags)
+{
+ u64 granule = 1ULL << s2_granule_shift(cfg);
+ u64 *ptep;
+ unsigned int level;
+
+ TEST_ASSERT(!(nested_paddr & (granule - 1)),
+ "L2 IPA not granule aligned: 0x%lx granule 0x%lx",
+ nested_paddr, granule);
+
+ TEST_ASSERT(!(paddr & (granule - 1)),
+ "PA not granule aligned: 0x%lx granule 0x%lx",
+ paddr, granule);
+
+ ptep = addr_gpa2hva(vm, guest_pgd);
+
+ for (level = cfg->start_level; level < s2_last_level(cfg); level++) {
+ u64 idx;
+ u64 desc;
+
+ idx = (nested_paddr >> s2_level_shift(cfg, level)) &
+ s2_index_mask(cfg);
+
+ ptep += idx;
+ desc = *ptep;
+
+ if (!desc) {
+ u64 table = s2_alloc_page_table(vm, cfg);
+
+ desc = s2_desc_table(table, cfg);
+ *ptep = desc;
+ }
+
+ ptep = addr_gpa2hva(vm, desc & s2_table_mask(cfg));
+ }
+
+ ptep += (nested_paddr >> s2_granule_shift(cfg)) & s2_index_mask(cfg);
+ *ptep = s2_desc_page(paddr, flags, cfg);
+}
+
+void nested_map(struct kvm_vm *vm,
+ const struct s2_config *cfg,
+ gpa_t guest_pgd,
+ u64 nested_paddr,
+ u64 paddr,
+ u64 size)
+{
+ u64 granule;
+ size_t npages;
+
+ if (!cfg)
+ cfg = &default_s2_cfg;
+
+ granule = 1ULL << s2_granule_shift(cfg);
+
+ TEST_ASSERT(!(size & (granule - 1)),
+ "Mapping size 0x%lx not aligned to granule 0x%lx",
+ size, granule);
+
+ TEST_ASSERT(nested_paddr + size > nested_paddr, "IPA overflow");
+ TEST_ASSERT(paddr + size > paddr, "PA overflow");
+
+ npages = size / granule;
+
+ while (npages--) {
+ __nested_pg_map(vm, cfg, guest_pgd, nested_paddr, paddr,
+ MT_NORMAL);
+
+ nested_paddr += granule;
+ paddr += granule;
+ }
+}
+
+void nested_map_memslot(struct kvm_vm *vm,
+ const struct s2_config *cfg,
+ gpa_t guest_pgd,
+ u32 memslot)
+{
+ struct userspace_mem_region *region;
+ u64 gpa, end;
+
+ region = memslot2region(vm, memslot);
+
+ gpa = region->region.guest_phys_addr;
+ end = gpa + region->region.memory_size;
+
+ pr_debug("nested S2 map slot %u: GPA %#lx-%#lx\n", memslot, gpa, end);
+
+ for (; gpa < end; gpa += cfg->granule)
+ nested_map(vm, cfg, guest_pgd, gpa, gpa, cfg->granule);
+}
+
+void init_vcpu(struct vcpu *vcpu, gpa_t l2_pc, gpa_t l2_stack_top)
{
memset(vcpu, 0, sizeof(*vcpu));
vcpu->context.regs.pc = l2_pc;
@@ -46,13 +300,32 @@ int run_l2(struct vcpu *vcpu, struct hyp_data *hyp_data)
vcpu->context.regs.pc = read_sysreg(elr_el2);
vcpu->context.regs.pstate = read_sysreg(spsr_el2);
+ vcpu->context.sys_regs[ESR_EL2] = read_sysreg(esr_el2);
__sysreg_save_el1_state(&vcpu->context);
return ret;
}
-void __hyp_exception(u64 type)
+u64 vcpu_get_esr_el2(struct vcpu *vcpu)
{
+ return vcpu->context.sys_regs[ESR_EL2];
+
+}
+
+void __hyp_exception(u64 type, u64 esr, u64 elr, u64 far, u64 hpfar, u64 spsr)
+{
+ u64 ec = esr >> 26;
+ u64 iss = esr & GENMASK_ULL(24, 0);
+ u64 ipa = ((hpfar & GENMASK_ULL(39, 4)) << 8) |
+ (far & GENMASK_ULL(11, 0));
+
+ GUEST_FAIL("Unexpected hyp exception: type=%lu "
+ "ESR_EL2=%#lx EC=%#lx ISS=%#lx "
+ "ELR_EL2=%#lx FAR_EL2=%#lx HPFAR_EL2=%#lx IPA=%#lx "
+ "SPSR_EL2=%#lx",
+ type, esr, ec, iss, elr, far, hpfar, ipa, spsr);
GUEST_FAIL("Unexpected hyp exception! type: %lx\n", type);
+
+
}
---
base-commit: eb656a0272c639d43be7a9bdd1c5f31eff3afe86
change-id: 20260515-enable-s2-hello_nested-b360a2e9bb87
Best regards,
--
Itaru Kitayama <itaru.kitayama@fujitsu.com>
^ permalink raw reply related
* Re: [PATCH 2/4] ASoC: stm: stm32_i2s: Use guard() for spin locks
From: Mark Brown @ 2026-05-15 1:58 UTC (permalink / raw)
To: Bui Duc Phuc
Cc: Olivier Moysan, Arnaud Pouliquen, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Maxime Coquelin, Alexandre Torgue, linux-sound,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <CAABR9nHfXi5G4+sVnLbWWJctQHkWASTzTwiV424bO6BXZDqX+Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 148 bytes --]
On Thu, May 14, 2026 at 05:33:17PM +0700, Bui Duc Phuc wrote:
> I'll send a v2 of the whole series with this fix.
> Would that work for you?
Yes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 19/21] objtool/klp: Introduce objtool for arm64
From: sashiko-bot @ 2026-05-15 2:08 UTC (permalink / raw)
To: x86
Cc: live-patching, linux-kernel, Peter Zijlstra, Song Liu,
linux-arm-kernel, Petr Mladek, Joe Lawrence, Mark Rutland,
Will Deacon, Miroslav Benes, Catalin Marinas
In-Reply-To: <5b66146373b1ff1aba1318fd51867dea2eb882f6.1778642121.git.jpoimboe@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The arm64 instruction decoder misclassifies trap instructions (e.g., `brk #0x800` used for `BUG()`) as `INSN_OTHER` instead of `INSN_BUG`.
--
commit dd63f0c03bab6a47f34cfcb310454460653638ed
Author: Josh Poimboeuf <jpoimboe@kernel.org>
objtool/klp: Introduce objtool for arm64
This commit adds basic support for arm64 in objtool, initially enabling
only the "objtool klp" subcommands.
> diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c
> new file mode 100644
> index 0000000000000..47658c76e1af0
> --- /dev/null
> +++ b/tools/objtool/arch/arm64/decode.c
[ ... ]
> +int arch_decode_instruction(struct objtool_file *file, const struct section *sec,
> + unsigned long offset, unsigned int maxlen,
> + struct instruction *insn)
> +{
[ ... ]
> + if (ins == 0xd503201f) {
> + /* NOP: static branch */
> + insn->type = INSN_NOP;
> + } else if ((ins & 0xfc000000) == 0x14000000) {
[ ... ]
> + } else if ((ins & 0x7e000000) == 0x36000000) {
> + /* TBZ/TBNZ: intra-TU sibling call */
> + insn->type = INSN_JUMP_CONDITIONAL;
> + insn->immediate = sign_extend64((ins >> 5) & 0x3fff, 13);
> + } else {
> + insn->type = INSN_OTHER;
> + }
Does this code misclassify trap instructions?
On arm64, BUG() is implemented using the brk instruction (such as brk #0x800).
Since the decoder doesn't appear to check for brk, it will fall through to the
else block and classify it as INSN_OTHER.
If INSN_BUG is misclassified as a normal instruction, won't this lose dead-end
propagation and corrupt objtool's control-flow analysis?
> +
> + insn->len = 4;
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778642120.git.jpoimboe@kernel.org?part=19
^ permalink raw reply
* [PATCH] perf cs-etm: stamp pid/tid/EL on each buffered packet to fix cross-pid attribution
From: Amir Ayupov @ 2026-05-15 2:11 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, John Garry, Will Deacon, coresight,
linux-arm-kernel, linux-perf-users, linux-kernel
Cc: stable
In a system-wide `perf record -e cs_etm/.../u` capture on aarch64,
synthesized samples emitted by `perf script --itrace=il64` are
sometimes attributed to the WRONG sample.pid/tid (and to the wrong
EL/cpumode) for the chunk of branches that straddle a context-switch
boundary on a CPU. A branch actually retired by process A is emitted
with sample.pid set to the thread that next ran on the same CPU.
Mechanism:
1. ETM emits CONTEXTIDR/EL packets in-stream when the kernel updates
CONTEXTIDR_EL1 on context switch / EL change. OpenCSD turns these
into OCSD_GEN_TRC_ELEM_PE_CONTEXT elements interleaved with
OCSD_GEN_TRC_ELEM_INSTR_RANGE elements for retired branch ranges.
2. cs_etm_decoder__buffer_range() queues each INSTR_RANGE into
packet_queue->packet_buffer[]; packets carry start/end addrs,
instr_count, last-instruction info, etc., but NO owner identity.
3. PE_CONTEXT goes through cs_etm_decoder__set_tid() ->
cs_etm__set_thread(), which immediately mutates tidq->thread and
tidq->el. Queued packets are not drained first; reset_timestamp()
is called so the next TIMESTAMP triggers OCSD_RESP_WAIT and a
drain.
4. By drain time in cs_etm__process_traceid_queue() ->
cs_etm__sample(), sample.pid/tid is read from the now-mutated
tidq->thread and sample.cpumode from the now-mutated tidq->el.
Pre-context INSTR_RANGEs get the post-context owner.
The same race affects branch samples via tidq->prev_packet_thread /
tidq->prev_packet_el, captured at packet-swap time from
tidq->thread / tidq->el (which may already have flipped).
This is independent of PERF_RECORD_SWITCH_CPU_WIDE, which is
deliberately not used to assign sample identity in this path. The
bug applies to any cs_etm capture with in-stream CONTEXTIDR
(PIDFMT_CTXTID or PIDFMT_CTXTID2).
Effect on downstream tools: branches that should belong to the
previous thread on the CPU get attributed to the next thread. When
the two threads share a binary, leaked branches' VAs land in the
wrong thread's mappings; samples whose IPs land in r-x mappings
silently pollute that binary's profile, while samples landing in
R-only/RW mappings show up as out-of-range / non-text samples.
Either way, AutoFDO/BOLT profiles built from `perf script --itrace`
output of system-wide cs_etm captures contain misattributed samples.
Concrete example from `perf script --itrace=il64` of the same
captured branch (same timestamp, same IP, same from/to addrs) before
and after this fix:
before: launcher_multia 2638146/2638146 705897.219172: \
fffcda6b124c 0xfffcda641958/0xfffcda6b123c
after: ws-tcf-sr-io13 2736581/2741587 705897.219172: \
fffcda6b124c 0xfffcda641958/0xfffcda6b123c
The branch was retired by ws-tcf-sr-io13 (tid 2741587) but, before
the fix, was attributed to launcher_multia (the next thread to run on
that CPU after the context switch). After the fix, it is correctly
attributed to ws-tcf-sr-io13.
Why not "drain on PE_CONTEXT then switch" (deferred-set_thread):
tidq->thread has two consumers \u2014 sample emission needs the OUTGOING
identity for queued packets, but cs_etm__mem_access() needs the
CURRENT thread's maps to fetch instruction bytes for OpenCSD. The
two needs are temporally inverted; a single tidq->thread cannot
serve both. Keeping tidq->thread current and stamping owner identity
per packet is the only design that decouples them cleanly.
Fix: capture the owning pid/tid/EL on each buffered packet at
cs_etm_decoder__buffer_packet() time (before any subsequent
PE_CONTEXT can mutate tidq->thread / tidq->el), and read them at
sample emission time.
- struct cs_etm_packet gains pid_t pid, pid_t tid, int el (storing
an ocsd_ex_level value; typed as int so the struct does not
depend on OpenCSD headers, which are only included inside
HAVE_CSTRACE_SUPPORT).
- cs_etm__etmq_get_pid_tid_el() (formerly cs_etm__etmq_get_pid_tid)
returns all three.
- cs_etm__synth_instruction_sample() reads sample.pid / sample.tid
from tidq->packet->{pid,tid} and derives sample.cpumode from
tidq->packet->el.
- cs_etm__synth_branch_sample() reads sample.pid / sample.tid /
cpumode from tidq->prev_packet->{pid,tid,el}.
- The separate prev_packet_thread / prev_packet_el bookkeeping in
cs_etm__packet_swap() / cs_etm__init_traceid_queue() /
cs_etm__free_traceid_queues() is removed; the per-packet stamp
on prev_packet now carries that information.
Cost: 12 bytes added to struct cs_etm_packet (~12-16 KB per
packet_queue with CS_ETM_PACKET_MAX_BUFFER=1024), 16 bytes saved per
cs_etm_traceid_queue (one struct thread * + one ocsd_ex_level).
A residual gap: cs_etm__copy_insn() reads sample.insn bytes via
cs_etm__mem_access(), which still uses tidq->thread (the current
thread), so the inline insn bytes for an outgoing-thread sample may
be looked up against the wrong address space. Fixing this requires
threading the packet's owner pid through cs_etm__mem_access and is
left for a follow-up. sample.ip / sample.pid attribution \u2014 what
AutoFDO/BOLT consume \u2014 is correct.
A workaround for users on existing perf binaries:
`perf record -p PIDS \u2026` programs the ETM
TRCCONTEXTIDCTLR/TRCVMIDCCTLR registers so the trace stream itself
never carries foreign-PID instructions, eliminating the leak at the
trace source.
Signed-off-by: Amir Ayupov <aaupov@meta.com>
Signed-off-by: Amir Ayupov <aaupov@fb.com>
---
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 +++
tools/perf/util/cs-etm.c | 75 +++++++++++++------
tools/perf/util/cs-etm.h | 25 +++++++
3 files changed, 88 insertions(+), 24 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index dee3020ceaa91..ed99dfc7b0f8d 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -402,6 +402,18 @@ cs_etm_decoder__buffer_packet(struct cs_etm_queue *etmq,
packet_queue->packet_buffer[et].flags = 0;
packet_queue->packet_buffer[et].exception_number = UINT32_MAX;
packet_queue->packet_buffer[et].trace_chan_id = trace_chan_id;
+ /*
+ * Stamp the owner thread (pid/tid) onto the packet at buffer time.
+ * A subsequent OCSD_GEN_TRC_ELEM_PE_CONTEXT element will mutate
+ * tidq->thread before this packet is emitted as a sample; recording
+ * the identity here keeps each buffered packet correctly attributed
+ * to the thread that retired its instructions. See
+ * cs_etm__synth_instruction_sample().
+ */
+ cs_etm__etmq_get_pid_tid_el(etmq, trace_chan_id,
+ &packet_queue->packet_buffer[et].pid,
+ &packet_queue->packet_buffer[et].tid,
+ &packet_queue->packet_buffer[et].el);
if (packet_queue->packet_count == CS_ETM_PACKET_MAX_BUFFER - 1)
return OCSD_RESP_WAIT;
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 8a639d2e51a4c..ee3437488b753 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -86,8 +86,6 @@ struct cs_etm_traceid_queue {
size_t last_branch_pos;
union perf_event *event_buf;
struct thread *thread;
- struct thread *prev_packet_thread;
- ocsd_ex_level prev_packet_el;
ocsd_ex_level el;
struct branch_stack *last_branch;
struct branch_stack *last_branch_rb;
@@ -614,10 +612,9 @@ static int cs_etm__init_traceid_queue(struct cs_etm_queue *etmq,
queue = &etmq->etm->queues.queue_array[etmq->queue_nr];
tidq->trace_chan_id = trace_chan_id;
- tidq->el = tidq->prev_packet_el = ocsd_EL_unknown;
+ tidq->el = ocsd_EL_unknown;
tidq->thread = machine__findnew_thread(&etm->session->machines.host, -1,
queue->tid);
- tidq->prev_packet_thread = machine__idle_thread(&etm->session->machines.host);
tidq->packet = zalloc(sizeof(struct cs_etm_packet));
if (!tidq->packet)
@@ -740,6 +737,26 @@ struct cs_etm_packet_queue
return NULL;
}
+void cs_etm__etmq_get_pid_tid_el(struct cs_etm_queue *etmq, u8 trace_chan_id,
+ pid_t *pid, pid_t *tid, int *el)
+{
+ struct cs_etm_traceid_queue *tidq;
+
+ *pid = -1;
+ *tid = -1;
+ *el = ocsd_EL_unknown;
+
+ tidq = cs_etm__etmq_get_traceid_queue(etmq, trace_chan_id);
+ if (!tidq)
+ return;
+
+ *el = tidq->el;
+ if (tidq->thread) {
+ *pid = thread__pid(tidq->thread);
+ *tid = thread__tid(tidq->thread);
+ }
+}
+
static void cs_etm__packet_swap(struct cs_etm_auxtrace *etm,
struct cs_etm_traceid_queue *tidq)
{
@@ -748,23 +765,15 @@ static void cs_etm__packet_swap(struct cs_etm_auxtrace *etm,
if (etm->synth_opts.branches || etm->synth_opts.last_branch ||
etm->synth_opts.instructions) {
/*
- * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
- * the next incoming packet.
- *
- * Threads and exception levels are also tracked for both the
- * previous and current packets. This is because the previous
- * packet is used for the 'from' IP for branch samples, so the
- * thread at that time must also be assigned to that sample.
- * Across discontinuity packets the thread can change, so by
- * tracking the thread for the previous packet the branch sample
- * will have the correct info.
+ * Rotate PACKET into PREV_PACKET so the next decoded packet
+ * lands in PACKET. Owner identity (pid/tid/el) travels with
+ * the packet itself — it was stamped at
+ * cs_etm_decoder__buffer_packet() time — so no separate
+ * thread/EL tracking is needed here.
*/
tmp = tidq->packet;
tidq->packet = tidq->prev_packet;
tidq->prev_packet = tmp;
- tidq->prev_packet_el = tidq->el;
- thread__put(tidq->prev_packet_thread);
- tidq->prev_packet_thread = thread__get(tidq->thread);
}
}
@@ -938,7 +947,6 @@ static void cs_etm__free_traceid_queues(struct cs_etm_queue *etmq)
/* Free this traceid_queue from the array */
tidq = etmq->traceid_queues[idx];
thread__zput(tidq->thread);
- thread__zput(tidq->prev_packet_thread);
zfree(&tidq->event_buf);
zfree(&tidq->last_branch);
zfree(&tidq->last_branch_rb);
@@ -1570,15 +1578,24 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
perf_sample__init(&sample, /*all=*/true);
event->sample.header.type = PERF_RECORD_SAMPLE;
- event->sample.header.misc = cs_etm__cpu_mode(etmq, addr, tidq->el);
+ event->sample.header.misc = cs_etm__cpu_mode(etmq, addr,
+ (ocsd_ex_level)tidq->packet->el);
event->sample.header.size = sizeof(struct perf_event_header);
/* Set time field based on etm auxtrace config. */
sample.time = cs_etm__resolve_sample_time(etmq, tidq);
sample.ip = addr;
- sample.pid = thread__pid(tidq->thread);
- sample.tid = thread__tid(tidq->thread);
+ /*
+ * Read pid/tid (and EL above for cpumode) from the packet's
+ * stamped owner identity rather than tidq->thread / tidq->el,
+ * which reflect the thread that is current at sample emission
+ * time. A PE_CONTEXT element delivered between buffer time and
+ * emit time would otherwise misattribute pre-context packets to
+ * the next thread/EL on the CPU.
+ */
+ sample.pid = tidq->packet->pid;
+ sample.tid = tidq->packet->tid;
sample.id = etmq->etm->instructions_id;
sample.stream_id = etmq->etm->instructions_id;
sample.period = period;
@@ -1586,6 +1603,16 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
sample.flags = tidq->prev_packet->flags;
sample.cpumode = event->sample.header.misc;
+ /*
+ * Note: cs_etm__copy_insn() reads sample.insn bytes via
+ * cs_etm__mem_access(), which uses tidq->thread (the *current*
+ * thread). For samples whose pid/tid were stamped from an
+ * outgoing thread that has since been replaced by a PE_CONTEXT,
+ * the inline insn bytes may be looked up against the wrong
+ * address space. sample.ip / sample.pid attribution is correct;
+ * fixing the insn bytes requires threading the packet's owner
+ * pid through cs_etm__mem_access and is left for a follow-up.
+ */
cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
if (etm->synth_opts.last_branch)
@@ -1631,15 +1658,15 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
event->sample.header.type = PERF_RECORD_SAMPLE;
event->sample.header.misc = cs_etm__cpu_mode(etmq, ip,
- tidq->prev_packet_el);
+ (ocsd_ex_level)tidq->prev_packet->el);
event->sample.header.size = sizeof(struct perf_event_header);
/* Set time field based on etm auxtrace config. */
sample.time = cs_etm__resolve_sample_time(etmq, tidq);
sample.ip = ip;
- sample.pid = thread__pid(tidq->prev_packet_thread);
- sample.tid = thread__tid(tidq->prev_packet_thread);
+ sample.pid = tidq->prev_packet->pid;
+ sample.tid = tidq->prev_packet->tid;
sample.addr = cs_etm__first_executed_instr(tidq->packet);
sample.id = etmq->etm->branches_id;
sample.stream_id = etmq->etm->branches_id;
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index aa9bb4a32ecaf..6ba47604b8c52 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -10,6 +10,7 @@
#include "debug.h"
#include "util/event.h"
#include <linux/bits.h>
+#include <sys/types.h>
struct perf_session;
struct perf_pmu;
@@ -184,6 +185,20 @@ struct cs_etm_packet {
u8 last_instr_size;
u8 trace_chan_id;
int cpu;
+ /*
+ * Owner identity captured at cs_etm_decoder__buffer_packet() time.
+ * A subsequent PE_CONTEXT element will mutate tidq->thread/tidq->el
+ * before this packet is emitted as a sample; stamping pid/tid/el on
+ * the packet keeps each one attributed to the thread that actually
+ * retired its instructions and the EL it ran at. Read at sample
+ * emission time by cs_etm__synth_instruction_sample() and
+ * cs_etm__synth_branch_sample(). 'el' holds an ocsd_ex_level value
+ * but is typed as int so the struct does not depend on OpenCSD
+ * headers (which are only included inside HAVE_CSTRACE_SUPPORT).
+ */
+ pid_t pid;
+ pid_t tid;
+ int el;
};
#define CS_ETM_PACKET_MAX_BUFFER 1024
@@ -266,6 +281,16 @@ void cs_etm__etmq_set_traceid_queue_timestamp(struct cs_etm_queue *etmq,
u8 trace_chan_id);
struct cs_etm_packet_queue
*cs_etm__etmq_get_packet_queue(struct cs_etm_queue *etmq, u8 trace_chan_id);
+/*
+ * Read the pid/tid/EL currently associated with the given trace_chan_id.
+ * Called from cs_etm_decoder__buffer_packet() to stamp owner identity on
+ * each buffered packet at buffer time, before any subsequent PE_CONTEXT
+ * (CONTEXTIDR / EL change) can mutate tidq->thread / tidq->el. The stamp
+ * is consumed at sample emission time so that each sample is attributed
+ * to the thread/EL that actually retired its instructions.
+ */
+void cs_etm__etmq_get_pid_tid_el(struct cs_etm_queue *etmq, u8 trace_chan_id,
+ pid_t *pid, pid_t *tid, int *el);
int cs_etm__process_auxtrace_info_full(union perf_event *event __maybe_unused,
struct perf_session *session __maybe_unused);
u64 cs_etm__convert_sample_time(struct cs_etm_queue *etmq, u64 cs_timestamp);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v5 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Damon Ding @ 2026-05-15 2:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260514-elegant-agate-pug-449ec2@quoll>
Hi Krzysztof,
On 5/14/2026 6:03 PM, Krzysztof Kozlowski wrote:
> On Wed, May 13, 2026 at 03:44:05PM +0800, Damon Ding wrote:
>> RK3588 eDP controller requires HCLK_VO1 (video output bus clock)
>> to access the VO1 GRF registers and enable the video datapath.
>
> To access GRF? Then it is the same clock input.
Not the same as RK3399 case.
(The same as the descriptions in [0])
RK3588 hclk_vo1 related NOC design:
PD_VO1
hclk_vo1
└─ pclk_vo1_root
Then the clock tree design:
hclk_vo1 (200M)
├─ hclk_vo1_niu_en
│ └─ hclk_vo1_niu (200M)
├─ hclk_hdcp1_en
│ └─ hclk_hdcp1 (200M)
├─ hclk_i2s5_8ch_en
│ └─ hclk_i2s5_8ch (200M)
├─ hclk_spdif4_en
│ └─ hclk_spdif4 (200M)
├─ hclk_spdifrx1_en
│ └─ hclk_spdifrx1 (200M)
├─ hclk_i2s9_8ch_en
│ └─ hclk_i2s9_8ch (200M)
└─ hclk_i2s6_8ch_en
└─ hclk_i2s6_8ch (200M)
pclk_vo1_root (150M)
├─ pclk_edp0_en
│ └─ pclk_edp0 (150M)
├─ pclk_edp1_en
│ └─ pclk_edp1 (150M)
├─ pclk_hdmitx1_en
│ └─ pclk_hdmitx1 (150M)
├─ pclk_vo1grf_en
│ └─ pclk_vo1grf (150M)
├─ pclk_hdcp1_en
│ └─ pclk_hdcp1 (150M)
├─ pclk_hdmitx0_en
│ └─ pclk_hdmitx0 (150M)
└─ pclk_trng1_en
└─ pclk_trng1 (150M)
On RK3399, the 'grf' clock is only used exclusively for GRF register access.
But on RK3576/RK3588, the 'hclk' (HCLK_VO1) acts as the parent clock for
pclk_vo1_root in NOC design. Meanwhile pclk_vo1_root is further the
parent of pclk_vo1grf and pclk_edp0/pclk_edp1 in clock tree. So this
hclk affects both GRF register access and the overall APB clock domain
of the eDP controller, which makes it necessary to be listed independently.
>
> AGAIN (reiterated soooo many times by me): you describe here clock
> input, NOT OUTPUT.
>
You're absolutely right, thank you for the repeated clarification.
I used "video output bus clock" as a shorthand to refer to HCLK_VO1,
which clocks the entire video output domain including eDP and HDMI
interfaces.
I will rephrase the commit message more precisely in the next version.
>>
>> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
>> phandle reference, which allowed the eDP to work without explicitly
>> managing the hclk_vo1 clock. However, this is not safe or explicit.
>>
>> Enforce the correct third clock name on a per-compatible basis to
>> standardize clock requirements per SoC. This makes the clock
>> dependency clear and removes reliance on implicit clock enablement
>> from GRF phandle.
>>
>> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> ---
>>
>> Changes in v4:
>> - Modify the commit msg.
>>
>> Changes in v5:
>> - Enforce the correct third clock name on a per-compatible basis.
>> - Modify the commit msg simultaneously.
>> ---
>> .../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
>> 1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> index d99b23b88cc5..8001c1facf98 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> @@ -23,10 +23,7 @@ properties:
>>
>> clock-names:
>> minItems: 2
>> - items:
>> - - const: dp
>> - - const: pclk
>> - - const: grf
>
> What is 'grf' clock in such case?
>
The 'grf' clock here was specifically for RK3399, which is only used for
GRF register access.
Moreover, the control logic for the new 'hclk' clock is different from
'grf' clock:
- The 'grf' clock was gated dynamically before/after GRF register access;
- The 'hclk' needs to be enabled during probe and kept running
continuously [1].
Best regards,
Damon
[0]
https://lore.kernel.org/all/c349eaf2-5852-4bb6-9dac-f7240e1c8098@rock-chips.com/
[1]
https://lore.kernel.org/all/20260513074414.2053435-6-damon.ding@rock-chips.com/
^ permalink raw reply
* Re: [PATCH v3 21/21] klp-build: Add arm64 syscall patching macro
From: sashiko-bot @ 2026-05-15 2:44 UTC (permalink / raw)
To: x86
Cc: Miroslav Benes, live-patching, Peter Zijlstra, Will Deacon,
Joe Lawrence, Catalin Marinas, linux-arm-kernel, Mark Rutland,
Song Liu, linux-kernel, Petr Mladek
In-Reply-To: <3bf3cee43039fc4da84e83d0891a92e25f40f00f.1778642121.git.jpoimboe@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The arm64 __KLP_SYSCALL_DEFINEx macro omits the ALLOW_ERROR_INJECTION declaration, silently breaking BPF error injection for livepatched syscalls.
--
commit b4d1a9ea352f196a7fd3e7198fdade51440d08e5
Author: Josh Poimboeuf <jpoimboe@kernel.org>
klp-build: Add arm64 syscall patching macro
This commit adds arm64 support for KLP_SYSCALL_DEFINEx(). The commit
message states it is mirroring the arm64 __SYSCALL_DEFINEx() pattern from
arch/arm64/include/asm/syscall_wrapper.h.
> diff --git a/include/linux/livepatch_helpers.h b/include/linux/livepatch_helpers.h
> index 99d68d0773fa8..4b647b83865f9 100644
> --- a/include/linux/livepatch_helpers.h
> +++ b/include/linux/livepatch_helpers.h
> @@ -72,6 +72,25 @@
> } \
> static inline long __klp_do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
>
> +#elif defined(CONFIG_ARM64)
> +
> +#define __KLP_SYSCALL_DEFINEx(x, name, ...) \
> + static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)); \
> + static inline long __klp_do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
> + asmlinkage long __arm64_sys##name(const struct pt_regs *regs); \
> + asmlinkage long __arm64_sys##name(const struct pt_regs *regs) \
> + { \
> + return __se_sys##name(SC_ARM64_REGS_TO_ARGS(x,__VA_ARGS__));\
> + } \
Does this macro definition omit the ALLOW_ERROR_INJECTION declaration?
The standard arm64 __SYSCALL_DEFINEx() macro explicitly registers the top-level
syscall handler with ALLOW_ERROR_INJECTION() to enable BPF error injection
workflows like bpf_override_return(). The x86 implementation correctly
preserves this functionality.
Because this macro is missing that declaration, it looks like it might
introduce a regression where BPF cannot inject errors into the replacement
syscalls in a livepatch module on arm64.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778642120.git.jpoimboe@kernel.org?part=21
^ permalink raw reply
* Re: [PATCH] bus: sunxi-rsb: Always check register address validity
From: Chen-Yu Tsai @ 2026-05-15 2:44 UTC (permalink / raw)
To: Andrey Skvortsov, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <agY70wRwrkdI2pk4@skv.local>
On Fri, May 15, 2026 at 5:17 AM Andrey Skvortsov
<andrej.skvortzov@gmail.com> wrote:
>
>
> On 26-03-14 15:33, Chen-Yu Tsai wrote:
> > On Sun, Mar 1, 2026 at 10:50 PM Andrey Skvortsov
> > <andrej.skvortzov@gmail.com> wrote:
> > >
> > > From: Samuel Holland <samuel@sholland.org>
> > >
> > > The register address was already validated for read operations in
> > > regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations
> > > have the same set of possible addresses, and the address is being truncated
> > > from u32 to u8 here as well, so the same check is needed.
> > >
> > > Signed-off-by: Samuel Holland <samuel@sholland.org>
> > > Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
> >
> > Should probably have:
> >
> > Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced
> > Serial Bus")
> >
> > I will added (via b4) when applying.
> >
> > Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
>
> Hi,
>
> do I need to update and resend this patch?
Sorry this fell through the cracks. I've applied it now.
ChenYu
^ permalink raw reply
* Re: [PATCH] bus: sunxi-rsb: Always check register address validity
From: Chen-Yu Tsai @ 2026-05-15 2:45 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, linux-arm-kernel, linux-sunxi,
linux-kernel, Chen-Yu Tsai, Andrey Skvortsov
In-Reply-To: <20260301144939.1832806-1-andrej.skvortzov@gmail.com>
On Sun, 01 Mar 2026 17:49:39 +0300, Andrey Skvortsov wrote:
> The register address was already validated for read operations in
> regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations
> have the same set of possible addresses, and the address is being truncated
> from u32 to u8 here as well, so the same check is needed.
>
>
Applied to sunxi/fixes-for-7.1 in local tree, thanks!
[1/1] bus: sunxi-rsb: Always check register address validity
commit: 322f01103323199cdd9eff8cb6aacbf1248ce36e
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 2/3] dt-bindings: display: bridge: analogix-dp: Add data-lanes support for endpoint
From: Damon Ding @ 2026-05-15 2:53 UTC (permalink / raw)
To: Conor Dooley
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260514-jolly-confining-997882e502c7@spud>
Hi Conor,
On 5/15/2026 2:19 AM, Conor Dooley wrote:
> On Thu, May 14, 2026 at 03:01:32PM +0800, Damon Ding wrote:
>> Add data-lanes property support to the port@1 endpoint for physical
>> lane mapping configuration.
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>> ---
>> .../bindings/display/bridge/analogix,dp.yaml | 24 +++++++++++++++----
>> 1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
>> index 62f0521b0924..a82f9b7776c0 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
>> @@ -36,19 +36,35 @@ properties:
>> Hotplug detect GPIO.
>> Indicates which GPIO should be used for hotplug detection
>>
>> + data-lanes:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + deprecated: true
>
> Why are you adding a new property as deprecated? Why does this duplicate
> what you're adding to the port node? At the very least, your commit is
> lacking an explanation.
> pw-bot: changes-requested
>
Thank you for the review.
I referenced the implementation in
Documentation/devicetree/bindings/display/msm/dp-controller.yaml. After
evaluating QCOM DP driver and other drivers, I agree that implementing
'data-lanes' in the endpoint node is the preferred and common approach
nowadays.
The top-level `data-lanes` property together with the `deprecated` mark
was leftover content from my early reference and arrangement, which I
neglected to delete before submitting. It is redundant, unreasonable and
should not have been added at all.
I will fix it in the next version.
Best regards,
Damon
>
>> + minItems: 1
>> + maxItems: 4
>> + items:
>> + maximum: 3
>> +
>> ports:
>> $ref: /schemas/graph.yaml#/properties/ports
>>
>> properties:
>> port@0:
>> $ref: /schemas/graph.yaml#/properties/port
>> - description:
>> - Input node to receive pixel data.
>> + description: Input node to receive pixel data.
>>
>> port@1:
>> $ref: /schemas/graph.yaml#/properties/port
>> - description:
>> - Port node with one endpoint connected to a dp-connector node.
>> + description: Port node with one endpoint connected to sink device node.
>> + properties:
>> + endpoint:
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + unevaluatedProperties: false
>> + properties:
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> + items:
>> + enum: [ 0, 1, 2, 3 ]
>>
>> required:
>> - port@0
>> --
>> 2.34.1
>>
^ permalink raw reply
* [PATCH] PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro
From: lirongqing @ 2026-05-15 0:55 UTC (permalink / raw)
To: Ryder Lee, Jianjun Wang, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, Matthias Brugger, AngeloGioacchino Del Regno,
linux-pci, linux-mediatek, linux-arm-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
The original PCIE_FTS_NUM_L0(x) macro was buggy due to improper operator
precedence, where ((x) & 0xff << 8) was evaluated as ((x) & 0xff00).
Instead of just fixing the parentheses, use the standard FIELD_PREP()
macro. This makes the code more robust by automatically handling masks
and shifts, while also adding compile-time type and range checking to
ensure the value fits within PCIE_FTS_NUM_MASK.
Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller support")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
drivers/pci/controller/pcie-mediatek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 7572252..00f0e29 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -61,7 +61,7 @@
/* MediaTek specific configuration registers */
#define PCIE_FTS_NUM 0x70c
#define PCIE_FTS_NUM_MASK GENMASK(15, 8)
-#define PCIE_FTS_NUM_L0(x) ((x) & 0xff << 8)
+#define PCIE_FTS_NUM_L0(x) FIELD_PREP(PCIE_FTS_NUM_MASK, x)
#define PCIE_FC_CREDIT 0x73c
#define PCIE_FC_CREDIT_MASK (GENMASK(31, 31) | GENMASK(28, 16))
--
2.9.4
^ permalink raw reply related
* Re: [PATCH v5 3/8] arm64: entry: add unwind info for various kernel entries
From: Dylan Hatch @ 2026-05-15 3:30 UTC (permalink / raw)
To: Mark Rutland
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Jens Remus, Prasanna Kumar T S M, Puranjay Mohan,
Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
live-patching, linux-arm-kernel, Randy Dunlap
In-Reply-To: <afIjFLbUrdxWA6eR@J2N7QTR9R3.cambridge.arm.com>
On Wed, Apr 29, 2026 at 8:26 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> Hi Dylan,
>
> On Tue, Apr 28, 2026 at 06:36:38PM +0000, Dylan Hatch wrote:
> > From: Weinan Liu <wnliu@google.com>
> >
> > DWARF CFI (Call Frame Information) specifies how to recover the return
> > address and callee-saved registers at each PC in a given function.
> > Compilers are able to generate the CFI annotations when they compile
> > the code to assembly language. For handcrafted assembly, we need to
> > annotate them by hand.
> >
> > Annotate minimal CFI to enable stacktracing using SFrame for kernel
> > exception entries through el1*_64_*() paths
>
> I thought we were only consuming SFrame when unwinding an exeption
> boundary?
>
> We shouldn't be taking exceptions _from_ the entry assembly functions
> unless something has gone horribly wrong, and so I don't see why we'd
> need CFI entries for the entry assembly functions.
>
> Am I missing some reason we need CFI entries for the entry assembly
> functions? I strongly suspect it is not necessary to add these, and I'd
> prefer to omit them.
I believe the el1 entry functions are called in an exception, and are
called before call_on_irq_stack. Example stacktrace segment:
[ 262.119564] handle_percpu_devid_irq+0xb4/0x348
[ 262.119913] handle_irq_desc+0x3c/0x68
[ 262.120196] generic_handle_domain_irq+0x20/0x40
[ 262.120678] gic_handle_irq+0x48/0xe0
[ 262.121005] call_on_irq_stack+0x30/0x48
[ 262.121412] do_interrupt_handler+0x88/0xa0
[ 262.121779] el1_interrupt+0x38/0x58
[ 262.122089] el1h_64_irq_handler+0x18/0x30
[ 262.122617] el1h_64_irq+0x6c/0x70
[ 262.123159] _raw_spin_unlock_irq+0x10/0x60 (P)
[ 262.123720] __filemap_add_folio+0x200/0x580 (L)
[ 262.124145] filemap_add_folio+0xec/0x300
[ 262.124674] page_cache_ra_unbounded+0x128/0x368
[ 262.125338] do_page_cache_ra+0x70/0x98
[ 262.125875] page_cache_ra_order+0x460/0x4e0
Here, el1h_64_irq is the last function that appears in the exception
stack before _raw_spin_unlock_irq and __filemap_add_folio are
recovered from the saved PC and LR, respectively. So we therefore need
the CFI annotations in order to unwind through the full exception
boundary.
Is my interpretation here correct?
>
> > and irq entries through call_on_irq_stack()
>
> Needing some sort of unwind annotations for call_on_irq_stack() makes
> sense to me, but don't we need something for other assembly functions
> too?
>
> We can interrupt things like memset(); I assume we'll treat those as
> unreliable until annotated?
While looking into adding these annotations, I noticed a pattern where
a sibling call is made to a local function:
SYM_FUNC_START(__pi_memset)
alternative_if_not ARM64_HAS_MOPS
b __pi_memset_generic
alternative_else_nop_endif
mov dst, dstin
setp [dst]!, count!, val_x
setm [dst]!, count!, val_x
sete [dst]!, count!, val_x
ret
SYM_FUNC_END(__pi_memset)
In this case, do we consider the stacktrace unreliable since
__pi_memset may not appear in the trace? Or is this not important
because assembly functions cannot be directly livepatched anyway?
Thanks,
Dylan
^ permalink raw reply
* Re: [PATCH v2 0/9] Remove SMMUv3 struct arm_smmu_cmdq_ent
From: Nicolin Chen @ 2026-05-15 3:35 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <0-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:39PM -0300, Jason Gunthorpe wrote:
> [ This is part of the patch pile to move SMMUv3 over to the generic page
> table:
> 1) Introduction of new gather items and RISCV usage
> https://patch.msgid.link/r/0-v2-b5156f657dc1+25f-iommu_riscv_inv_jgg@nvidia.com
> 2) Remove SMMUv3 struct arm_smmu_cmdq_ent
> 3) Organize the SMMUv3 invalidation flow so iommupt can use it
> 4) Use the generic iommu page table for SMMUv3
>
> The whole branch is here:
> https://github.com/jgunthorpe/linux/commits/iommu_pt_arm64/
> ]
>
> The invalidation logic has this multi-step process where it first
> writes the command into a 32 byte struct arm_smmu_cmdq_ent, then it
> calls a function which converts it into a 16 byte HW struct, and
> sometimes it then edits the HW struct a little bit before passing it
> off to the batch or submission functions.
>
> Instead just generate the HW struct directly by moving the FIELD_PREP
> blocks out of the big case statement and into helper functions. Call the
> right function in all the places that were building arm_smmu_cmdq_ent.
>
> Add a type for the CMDQ entry similar to the STE/CD types that wraps the
> two u64s for clarity and use it everywhere.
>
> This is intended to have no functional change. It makes the following
> patches work better and removes a bunch of LOC. I've run several AI tools
> with instruction to look for functional changes, which did find one subtle
> mistake in PRI response.
>
> The removal of arm_smmu_cmdq_build_cmd() also achieves what Mostafa is
> doing in the pkvm series by making the command formation entirely header
> based with the arm_smmu_make_cmd_*() mini inlines.
>
> This series has no dependencies. Several people have already tested this
> on various ARM systems along with the full iommupt conversion.
>
> v2:
Sanity tested with SVA and nesting cases.
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* RE: [PATCH v7 net-next 10/15] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Wei Fang @ 2026-05-15 3:36 UTC (permalink / raw)
To: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, f.fainelli@gmail.com,
Frank Li, chleroy@kernel.org, horms@kernel.org,
linux@armlinux.org.uk, maxime.chevallier@bootlin.com,
andrew@lunn.ch, olteanv@gmail.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260513030454.1666570-11-wei.fang@nxp.com>
> diff --git a/drivers/net/dsa/netc/Kconfig b/drivers/net/dsa/netc/Kconfig new file
> mode 100644 index 000000000000..0f246ac9e018
> --- /dev/null
> +++ b/drivers/net/dsa/netc/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0-only config NET_DSA_NETC_SWITCH
> + tristate "NXP NETC Ethernet switch support"
> + depends on ARM64 || COMPILE_TEST
> + depends on NET_DSA && PCI
> + select NET_DSA_TAG_NETC
> + select FSL_ENETC_MDIO
> + select NXP_NTMP
> + select NXP_NETC_LIB
> + help
> + This driver supports the NXP NETC Ethernet switch, which is embedded
> + as a PCIe function of the NXP NETC IP. But note that this driver is
> + is only available for NETC v4.3 and later versions.
Sashiko reported there is a duplicated "is" in the help text. I will fix in v8.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: display: rockchip: analogix-dp: Expose inherited properties
From: Damon Ding @ 2026-05-15 3:57 UTC (permalink / raw)
To: Conor Dooley
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260514-upstate-sneer-0b6e78682798@spud>
Hi Conor,
On 5/15/2026 2:16 AM, Conor Dooley wrote:
> On Thu, May 14, 2026 at 03:01:31PM +0800, Damon Ding wrote:
>> Expose the inherited properties from the base analogix-dp schema
>> to satisfy unevaluatedProperties constraints.
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> Given it's unevaluatedProperties, not addtionalProperties, this patch
> shouldn't be needed?
>
When I remove both the top-level data-lanes property and those explicit
"xxx: true" property entries and run the dtbs check with:
make CHECK_DTBS=y CROSS_COMPILE=aarch64-linux-gnu- LT0=none LLVM=1
LLVM_IAS=1 ARCH=arm64 rockchip/rk3588-evb1-v10.dtb
rockchip/rk3588s-evb1-v10.dtb rockchip/rk3399-sapphire-excavator.dtb
rockchip/rk3576-evb1-v10.dtb -j4
It results in validation errors like these:
/home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
edp@27dc0000: ports:port@1:endpoint: Unevaluated properties are not
allowed ('data-lanes' was unexpected)
from schema $id:
http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
/home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
edp@27dc0000: Unevaluated properties are not allowed ('force-hpd',
'interrupts', 'phy-names', 'phys', 'ports', 'reg' were unexpected)
from schema $id:
http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
I suspect that the properties defined in the child binding are
overriding/masking all the inherited properties from the parent Analogix
DP schema.
Is there a better way to fix this issue without explicitly listing all
inherited properties as true?
Best regards,
Damon
>> ---
>> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> index bb75d898a5c5..896ded87880f 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> @@ -50,6 +50,13 @@ properties:
>> aux-bus:
>> $ref: /schemas/display/dp-aux-bus.yaml#
>>
>> + reg: true
>> + interrupts: true
>> + phys: true
>> + phy-names: true
>> + force-hpd: true
>> + ports: true
>> +
>> required:
>> - compatible
>> - clocks
>> --
>> 2.34.1
>>
>>
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Christoph Hellwig @ 2026-05-15 4:37 UTC (permalink / raw)
To: kreijack
Cc: Christoph Hellwig, David Sterba, Andrew Morton, Catalin Marinas,
Will Deacon, Ard Biesheuvel, Huacai Chen, WANG Xuerui,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <0a8d1ff4-f5a2-49e9-aa45-d25dbe4ded40@libero.it>
On Thu, May 14, 2026 at 09:51:59PM +0200, Goffredo Baroncelli wrote:
> I think that the David concern is : "what happens for an already
> existing btrfs raid6 3 disks filesystem when the user upgrade the kernel ?"
> (I am thinking when a new BG needs to be allocated)...
Then it will cleanly fail to mount instead of constantly corrupting data
and memory with every write, yes. Which clearly suggest that such
file systems don't exist in the wild.
But if btrfs wants to keep supporting this I'll just add a _unsafe
version without the check in the core library.
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Christoph Hellwig @ 2026-05-15 4:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: kreijack, Goffredo Baroncelli, Christoph Hellwig, David Sterba,
Andrew Morton, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <0507CCEF-0548-442F-8703-1D006B5E068B@zytor.com>
On Thu, May 14, 2026 at 12:57:53PM -0700, H. Peter Anvin wrote:
> That's what I'm saying – it should invoke the RAID-1 code under the
> cover (as with 3 disks, D = P = Q.)
Yes, if the btrfs maintainer cared for this setup that is what should
be done.
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: stm: stm32_i2s: Use guard() for spin locks
From: Bui Duc Phuc @ 2026-05-15 4:48 UTC (permalink / raw)
To: Mark Brown
Cc: Olivier Moysan, Arnaud Pouliquen, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Maxime Coquelin, Alexandre Torgue, linux-sound,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <agZ92TVjcYpEv_eH@sirena.co.uk>
Hi,
> > I'll send a v2 of the whole series with this fix.
> > Would that work for you?
>
> Yes.
Thank you for the confirmation.
By the way, I have an architectural question that came up during my cleanup...
I noticed that the STM drivers currently manage clk_prepare_enable()/
clk_disable_unprepare() directly from the dai_startup()/shutdown() paths.
After looking through various vendor audio drivers, I noticed that
PM/clock handling styles still vary quite a lot between implementations.
For example:
some Intel drivers enable clocks during dai_link init.
Samsung separates bus/interface clocks and operational clocks,
enabling them in different paths such as probe() and set_sysclk()
UX500 and STM enable clocks during DAI startup()/shutdown()
Tegra, Sunxi, and Rockchip often manage clocks through runtime
PM callbacks
From a maintainer perspective, is there generally interest in gradually
converging these drivers toward more modern/common PM patterns,
or is preserving existing hardware-specific sequencing usually preferred
unless there is a concrete issue to solve?
Best regard,
Phuc
^ permalink raw reply
* Re: [PATCH v3 3/4] PCI: endpoint: Add API for DOE initialization and setup in EPC core
From: Aksh Garg @ 2026-05-15 4:51 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <m4z3q3pe3ro5vkl4uq4zkewpjdqccgeact2hj4tjnkonttx4vr@ndan37zzwgxc>
On 14/05/26 13:38, Manivannan Sadhasivam wrote:
> On Mon, Apr 27, 2026 at 10:47:24AM +0530, Aksh Garg wrote:
>> Add pci_epc_setup_doe() API in EPC core driver to initialize and setup
>> the DOE framework for an endpoint controller. The API discovers the DOE
>> capabilities (extended capability ID 0x2E), and registers each discovered
>> DOE mailbox for all the functions in the endpoint controller. This API
>> should be invoked by the controller driver during probe based on the
>> doe_capable feature.
>>
>> Add pci_epc_destroy_doe() API in EPC core driver for cleanup of DOE
>> resources, which should be invoked by the controller driver during
>> controller cleanup based on the doe_capable feature.
>>
>> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Aksh Garg <a-garg7@ti.com>
>> ---
>>
>> Changes from v2 to v3:
>> - Rebased on 7.1-rc1.
>>
>> Changes since v1:
>> - New patch added to v2 (not present in v1)
>>
>> v2: https://lore.kernel.org/all/20260401073022.215805-4-a-garg7@ti.com/
>>
>> This patch is introduced based on the feedback provided by Manivannan
>> Sadhasivam at [1].
>>
>
> Sweet! But I was expecting you to add atleast one EPC driver implementation to
> make use of these APIs.
>
> Also, why can't you call these APIs from the EPC core directly? Maybe during
> pci_epc_init_notify() once the register accesses become valid.
Can we add the DOE initialization API to pci_epc_init_notify()? This
API seems to be called to notify the EPF drivers that the EPC device's
initialization has been completed, as the name and description suggests.
As 'pci_epc_doe_setup' is a part of EPC initialization, I thought the
EPC drivers should call this API before calling the pci_epc_init_notify().
However, I agree with your suggestion to call the DOE setup API directly
from the EPC core instead of sprinkling over the EPC drivers. I would
recommend renaming the pci_epc_init_notify() API (and hence the
pci_epc_deinit_notify() as well) to something like
pci_epc_init_complete(), and add the DOE setup API/logic just before the
logic of notifying the EPF devices.
Please suggest if the above would be acceptable.
Regards,
Aksh Garg
>
> - Mani
>
>> [1]: https://lore.kernel.org/all/p57x6jleaim5w7t2k3v7tioujnaxuovfpj5euop5ogefvw23se@y5fw3che5p5d/
>>
>> drivers/pci/endpoint/pci-epc-core.c | 71 +++++++++++++++++++++++++++++
>> include/linux/pci-epc.h | 21 +++++++++
>> 2 files changed, 92 insertions(+)
>>
>> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
>> index 6c3c58185fc5..5a95a07b7d3a 100644
>> --- a/drivers/pci/endpoint/pci-epc-core.c
>> +++ b/drivers/pci/endpoint/pci-epc-core.c
>> @@ -14,6 +14,8 @@
>> #include <linux/pci-epf.h>
>> #include <linux/pci-ep-cfs.h>
>>
>> +#include "../pci.h"
>> +
>> static const struct class pci_epc_class = {
>> .name = "pci_epc",
>> };
>> @@ -548,6 +550,75 @@ void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>> }
>> EXPORT_SYMBOL_GPL(pci_epc_mem_unmap);
>>
>> +/**
>> + * pci_epc_doe_setup() - Setup and discover DOE mailboxes for all functions
>> + * @epc: the EPC device on which DOE mailboxes has to be setup
>> + *
>> + * Discover DOE (Data Object Exchange) capabilities for all physical functions
>> + * in the endpoint controller and register DOE mailboxes.
>> + *
>> + * This API should be called by the controller driver during initialization
>> + * if DOE support is available (indicated by doe_capable in pci_epc_features).
>> + *
>> + * RETURNS: 0 on success, -errno on failure
>> + */
>> +int pci_epc_doe_setup(struct pci_epc *epc)
>> +{
>> + u16 cap_offset = 0;
>> + u8 func_no;
>> + int ret;
>> +
>> + if (!epc || !epc->ops || !epc->ops->find_ext_capability)
>> + return -EINVAL;
>> +
>> + /* Initialize DOE framework for this controller */
>> + ret = pci_ep_doe_init(epc);
>> + if (ret)
>> + return ret;
>> +
>> + /* Discover DOE capabilities for all functions */
>> + for (func_no = 0; func_no < epc->max_functions; func_no++) {
>> + while ((cap_offset = epc->ops->find_ext_capability(epc, func_no, 0,
>> + cap_offset,
>> + PCI_EXT_CAP_ID_DOE))) {
>> + /* Register this DOE mailbox */
>> + ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
>> + if (ret) {
>> + dev_err(&epc->dev,
>> + "[pf%d:offset %x] failed to add DOE mailbox\n",
>> + func_no, cap_offset);
>> + }
>> + }
>> + }
>> +
>> + dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_epc_doe_setup);
>> +
>> +/**
>> + * pci_epc_doe_destroy() - Destroy and cleanup DOE mailboxes
>> + * @epc: the EPC device on which DOE mailboxes has to be destroyed
>> + *
>> + * Destroy all DOE mailboxes registered on this endpoint controller and
>> + * free associated resources.
>> + *
>> + * This API should be called by the controller driver during controller cleanup
>> + * if DOE support is available (indicated by doe_capable in pci_epc_features).
>> + *
>> + * RETURNS: 0 on success, -errno on failure
>> + */
>> +int pci_epc_doe_destroy(struct pci_epc *epc)
>> +{
>> + if (!epc)
>> + return -EINVAL;
>> +
>> + pci_ep_doe_destroy(epc);
>> + dev_dbg(&epc->dev, "DOE mailboxes destroyed\n");
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_epc_doe_destroy);
>> +
>> /**
>> * pci_epc_clear_bar() - reset the BAR
>> * @epc: the EPC device for which the BAR has to be cleared
>> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
>> index dd26294c8175..7b0f258ef330 100644
>> --- a/include/linux/pci-epc.h
>> +++ b/include/linux/pci-epc.h
>> @@ -84,6 +84,8 @@ struct pci_epc_map {
>> * @start: ops to start the PCI link
>> * @stop: ops to stop the PCI link
>> * @get_features: ops to get the features supported by the EPC
>> + * @find_ext_capability: ops to find extended capability offset for a function
>> + * in endpoint controller
>> * @owner: the module owner containing the ops
>> */
>> struct pci_epc_ops {
>> @@ -115,6 +117,8 @@ struct pci_epc_ops {
>> void (*stop)(struct pci_epc *epc);
>> const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
>> u8 func_no, u8 vfunc_no);
>> + u16 (*find_ext_capability)(struct pci_epc *epc, u8 func_no,
>> + u8 vfunc_no, u16 start, u8 cap);
>> struct module *owner;
>> };
>>
>> @@ -270,6 +274,7 @@ struct pci_epc_bar_desc {
>> * @msi_capable: indicate if the endpoint function has MSI capability
>> * @msix_capable: indicate if the endpoint function has MSI-X capability
>> * @intx_capable: indicate if the endpoint can raise INTx interrupts
>> + * @doe_capable: indicate if the endpoint function has DOE capability
>> * @bar: array specifying the hardware description for each BAR
>> * @align: alignment size required for BAR buffer allocation
>> */
>> @@ -280,6 +285,7 @@ struct pci_epc_features {
>> unsigned int msi_capable : 1;
>> unsigned int msix_capable : 1;
>> unsigned int intx_capable : 1;
>> + unsigned int doe_capable : 1;
>> struct pci_epc_bar_desc bar[PCI_STD_NUM_BARS];
>> size_t align;
>> };
>> @@ -368,6 +374,21 @@ int pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>> void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>> struct pci_epc_map *map);
>>
>> +#ifdef CONFIG_PCI_ENDPOINT_DOE
>> +int pci_epc_doe_setup(struct pci_epc *epc);
>> +int pci_epc_doe_destroy(struct pci_epc *epc);
>> +#else
>> +static inline int pci_epc_doe_setup(struct pci_epc *epc)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static inline int pci_epc_doe_destroy(struct pci_epc *epc)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +#endif
>> +
>> #else
>> static inline void pci_epc_init_notify(struct pci_epc *epc)
>> {
>> --
>> 2.34.1
>>
>
^ permalink raw reply
* [PATCH v3] EDAC/altera: Guard SDRAM irq2 retrieval for Arria10 only
From: muhammad.nazim.amirul.nazle.asmade @ 2026-05-15 5:04 UTC (permalink / raw)
To: dinguyen, bp, tony.luck; +Cc: linux-edac, linux-arm-kernel, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Guard the irq2 retrieval with an of_machine_is_compatible() check so
that platform_get_irq(pdev, 1) is only called on Arria10 platforms.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
v3: Fix commit header formatting to follow EDAC/altera: prefix
convention as per maintainer feedback.
v2: Move irq2 = platform_get_irq(pdev, 1) inside the existing
of_machine_is_compatible("altr,socfpga-arria10") block instead of
adding a separate duplicate guard around it.
---
drivers/edac/altera_edac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 4edd2088c2db..ee6ced033f2c 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -347,9 +347,6 @@ static int altr_sdram_probe(struct platform_device *pdev)
return irq;
}
- /* Arria10 has a 2nd IRQ */
- irq2 = platform_get_irq(pdev, 1);
-
layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
layers[0].size = 1;
layers[0].is_virt_csrow = true;
@@ -395,6 +392,9 @@ static int altr_sdram_probe(struct platform_device *pdev)
/* Only the Arria10 has separate IRQs */
if (of_machine_is_compatible("altr,socfpga-arria10")) {
+ /* Arria10 has a 2nd IRQ */
+ irq2 = platform_get_irq(pdev, 1);
+
/* Arria10 specific initialization */
res = a10_init(mc_vbase);
if (res < 0)
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v2] drivers: altera_edac: Guard SDRAM irq2 retrieval for Arria10 only
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-05-15 5:07 UTC (permalink / raw)
To: Dinh Nguyen, bp@alien8.de, tony.luck@intel.com
Cc: linux-edac@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <055c980a-0282-422d-b224-4d65482c2155@kernel.org>
On 15/5/2026 1:23 am, Dinh Nguyen wrote:
> Please get into the habit of looking at previous commmits and their
> formatting.
>
> This commit header should be:
>
> EDAC/altera: Guard SDRAM irq2 retrieval for Arria10 only
>
> Dinh
Will be more aware next time, updated this on v3
https://lore.kernel.org/all/20260515050444.10380-1-muhammad.nazim.amirul.nazle.asmade@altera.com/
^ permalink raw reply
* Re: [PATCH] pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source
From: Sebin Francis @ 2026-05-15 5:21 UTC (permalink / raw)
To: Kendall Willis, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Ulf Hansson, Kevin Hilman, Dhruva Gole
Cc: linux-arm-kernel, linux-pm, linux-kernel, stable, tomi.valkeinen,
devarsht, vigneshr, vishalm, vitor.soares, ivitro
In-Reply-To: <20260506-wkup-constraint-v1-1-0a4bce791b29@ti.com>
On 07/05/26 08:46, Kendall Willis wrote:
> Set wakeup constraint for any device in a wakeup path. All parent devices
> of a wakeup device should not be turned off during suspend. This ensures
> the wakeup device is kept on while the system is suspended.
>
> Cc: stable@vger.kernel.org
> Fixes: 9d8aa0dd3be4 ("pmdomain: ti_sci: add wakeup constraint management")
> Reported-by: Vitor Soares <vitor.soares@toradex.com>
> Closes: https://lore.kernel.org/linux-pm/c0fe43a2339c802e9ce5900092cd530a2ba17a6b.camel@gmail.com/
> Signed-off-by: Kendall Willis <k-willis@ti.com>
> ---
Looks good to me.
Reviewed-by: Sebin Francis <sebin.francis@ti.com>
Sebin Francis
> drivers/pmdomain/ti/ti_sci_pm_domains.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> index 18d33bc35dee1b3bf6107af1e414db377d515199..949e4115f930b93b18216fde46131b5c8931c9aa 100644
> --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
> +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> @@ -86,7 +86,7 @@ static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
> const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
> int ret;
>
> - if (device_may_wakeup(dev)) {
> + if (device_may_wakeup(dev) || device_wakeup_path(dev)) {
> /*
> * If device can wakeup using IO daisy chain wakeups,
> * we do not want to set a constraint.
>
> ---
> base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
> change-id: 20260506-wkup-constraint-9b0261b04df1
> > Best regards,
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox