* Re: [PATCH v2 7/7] arm64: dts: qcom: shikra-iqs-evk-imx577-camera: Add DT overlay
From: Vladimir Zapolskiy @ 2026-06-12 8:11 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-7-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra IQS is an industrial-grade variant using PM8150 PMIC, requiring
> different CSIPHY and sensor supply rails compared to the retail boards
> (CQM and CQS) which use PM4125.
>
> Add a dedicated overlay for optional IMX577 integration via CSIPHY1.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> .../dts/qcom/shikra-iqs-evk-imx577-camera.dtso | 70 ++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 9 +++
> 3 files changed, 81 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 76b8f144983827f4905a72935e8d5291a227dc97..09f2318d1c12c4239a6a7bac4ecbca38eb65ffa2 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -340,9 +340,11 @@ dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk.dtb
>
> shikra-cqm-evk-imx577-camera-dtbs := shikra-cqm-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> shikra-cqs-evk-imx577-camera-dtbs := shikra-cqs-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +shikra-iqs-evk-imx577-camera-dtbs := shikra-iqs-evk.dtb shikra-iqs-evk-imx577-camera.dtbo
>
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk-imx577-camera.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk-imx577-camera.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk-imx577-camera.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm4250-oneplus-billie2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm4450-qrd.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm6115-fxtec-pro1x.dtb
> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso
> new file mode 100644
> index 0000000000000000000000000000000000000000..340d6303adc6e1bea55f1bd0598175f0cb269737
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso
> @@ -0,0 +1,70 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/qcom,shikra-gcc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&camss {
> + vdd-csiphy-1p2-supply = <&pm8150_l11>;
> + vdd-csiphy-1p8-supply = <&pm8150_l12>;
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csiphy1_ep: endpoint {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&imx577_ep1>;
> + };
> + };
> + };
> +};
> +
> +&cci {
> + status = "okay";
> +};
> +
> +&cci_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@1a {
> + compatible = "sony,imx577";
> + reg = <0x1a>;
> +
> + reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&cam_mclk1_default &cam1_reset_default>;
> + pinctrl-names = "default";
> +
> + clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clock-rates = <24000000>;
> +
> + /*
> + * avdd and dvdd are supplied by on-board regulators on the
> + * IMX577 module from the connector's 3.3 V rail; they are
> + * not SoC-controlled. dovdd (1.8 V) powers the carrier board
> + * level-shifter that translates CCI I2C and reset lines
> + * between the SoC and the connector.
> + */
> + dovdd-supply = <&pm8150_l15>;
> +
> + port {
> + imx577_ep1: endpoint {
> + link-frequencies = /bits/ 64 <600000000>;
> + data-lanes = <0 1 2 3>;
Same as before, the numeration of data lanes starts from 1.
> + remote-endpoint = <&csiphy1_ep>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> index 3003a47bd7594206f0ac54957e0af509fa365f54..811fd5da4af7babd412d70fee84434849846dc2f 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
>
This part goes directly to the mezzanine .dtso file.
After fixing it,
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: qcom: shikra-cqm-cqs-evk-imx577-camera: Add DT overlay
From: Vladimir Zapolskiy @ 2026-06-12 8:10 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-6-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra CQM and CQS are retail variants sharing the same PM4125 PMIC
> and identical camera supply rails. The only difference between them
> is the integrated modem on CQM, which does not affect camera hardware.
>
> Add a shared overlay for optional IMX577 integration via CSIPHY1,
> used by both CQM and CQS EVK boards.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 6 ++
> .../dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso | 70 ++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 9 +++
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 9 +++
> 4 files changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index a9e9d829fb962386b3975f345ec006504607130a..76b8f144983827f4905a72935e8d5291a227dc97 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -337,6 +337,12 @@ dtb-$(CONFIG_ARCH_QCOM) += sdx75-idp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk.dtb
> +
> +shikra-cqm-evk-imx577-camera-dtbs := shikra-cqm-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +shikra-cqs-evk-imx577-camera-dtbs := shikra-cqs-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk-imx577-camera.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk-imx577-camera.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm4250-oneplus-billie2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm4450-qrd.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm6115-fxtec-pro1x.dtb
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
> new file mode 100644
> index 0000000000000000000000000000000000000000..e3dad7c81e5e8aeb1061c784b5b893965f914a6f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
> @@ -0,0 +1,70 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/qcom,shikra-gcc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&camss {
> + vdd-csiphy-1p2-supply = <&pm4125_l5>;
> + vdd-csiphy-1p8-supply = <&pm4125_l13>;
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csiphy1_ep: endpoint {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&imx577_ep1>;
> + };
> + };
> + };
> +};
> +
> +&cci {
> + status = "okay";
> +};
> +
> +&cci_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@1a {
> + compatible = "sony,imx577";
> + reg = <0x1a>;
> +
> + reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&cam_mclk1_default &cam1_reset_default>;
> + pinctrl-names = "default";
> +
> + clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clock-rates = <24000000>;
> +
> + /*
> + * avdd and dvdd are supplied by on-board regulators on the
> + * IMX577 module from the connector's 3.3 V rail; they are
> + * not SoC-controlled. dovdd (1.8 V) powers the carrier board
> + * level-shifter that translates CCI I2C and reset lines
> + * between the SoC and the connector.
> + */
> + dovdd-supply = <&pm4125_l15>;
> +
> + port {
> + imx577_ep1: endpoint {
> + link-frequencies = /bits/ 64 <600000000>;
> + data-lanes = <0 1 2 3>;
The numeration of data-lanes shall be started from 1, this has to be fixed.
> + remote-endpoint = <&csiphy1_ep>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> index 0a52ab9b7a4c34d371f5ac23efe59d1c9d2723f4..0d5c3e31b1f613157d4d2ec6947c630f1031b73b 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
Since it's a mezzanine specific pinctl assignment, it shall go to the
correspondent .dtso file.
It's a concidence that one .dtso file is good enough for describing the
mezzanine for two diffferent boards, but let's exploit it by keeping one
dt overlay file as it is now.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> index b3f19a64d7aed3121ef092df684b19a4de39b497..515af370ca014a668dc035ff944fb82b6e09ceeb 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH v1 06/11] KVM: arm64: Factor out reusable vCPU reset helpers
From: tabba @ 2026-06-12 6:59 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Will Deacon, Catalin Marinas, Quentin Perret,
Vincent Donnefort, Sebastian Ene, Per Larsen, Suzuki K Poulose,
Zenghui Yu, Joey Gouly, Steffen Eiden, Mark Rutland,
Jonathan Cameron, Hyunwoo Kim, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260612065925.755562-1-tabba@google.com>
Pull the reusable pieces out of kvm_reset_vcpu(): expose the reset
PSTATE values in kvm_arm.h, and split the core register reset and the
PSCI-driven reset into kvm_reset_vcpu_core() and kvm_reset_vcpu_psci().
A follow-up series reuses these to reset protected vCPUs at EL2.
No functional change intended.
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/include/asm/kvm_arm.h | 12 ++++++
arch/arm64/include/asm/kvm_emulate.h | 58 +++++++++++++++++++++++++++
arch/arm64/kvm/reset.c | 60 ++--------------------------
3 files changed, 73 insertions(+), 57 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 3f9233b5a130..aba4ec09acd2 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -348,4 +348,16 @@
{ PSR_AA32_MODE_UND, "32-bit UND" }, \
{ PSR_AA32_MODE_SYS, "32-bit SYS" }
+/*
+ * ARMv8 Reset Values
+ */
+#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
+ PSR_F_BIT | PSR_D_BIT)
+
+#define VCPU_RESET_PSTATE_EL2 (PSR_MODE_EL2h | PSR_A_BIT | PSR_I_BIT | \
+ PSR_F_BIT | PSR_D_BIT)
+
+#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
+ PSR_AA32_I_BIT | PSR_AA32_F_BIT)
+
#endif /* __ARM64_KVM_ARM_H__ */
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index aed9fc0b717b..8436e71c402d 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -704,4 +704,62 @@ static inline void vcpu_set_hcrx(struct kvm_vcpu *vcpu)
vcpu->arch.hcrx_el2 |= HCRX_EL2_EnASR;
}
}
+
+/* Reset a vcpu's core registers. */
+static inline void kvm_reset_vcpu_core(struct kvm_vcpu *vcpu)
+{
+ u32 pstate;
+
+ if (vcpu_el1_is_32bit(vcpu)) {
+ pstate = VCPU_RESET_PSTATE_SVC;
+ } else if (vcpu_has_nv(vcpu)) {
+ pstate = VCPU_RESET_PSTATE_EL2;
+ } else {
+ pstate = VCPU_RESET_PSTATE_EL1;
+ }
+
+ /* Reset core registers */
+ memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
+ memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
+ vcpu->arch.ctxt.spsr_abt = 0;
+ vcpu->arch.ctxt.spsr_und = 0;
+ vcpu->arch.ctxt.spsr_irq = 0;
+ vcpu->arch.ctxt.spsr_fiq = 0;
+ vcpu_gp_regs(vcpu)->pstate = pstate;
+}
+
+/* PSCI reset handling for a vcpu. */
+static inline void kvm_reset_vcpu_psci(struct kvm_vcpu *vcpu,
+ struct vcpu_reset_state *reset_state)
+{
+ unsigned long target_pc = reset_state->pc;
+
+ /* Gracefully handle Thumb2 entry point */
+ if (vcpu_mode_is_32bit(vcpu) && (target_pc & 1)) {
+ target_pc &= ~1UL;
+ vcpu_set_thumb(vcpu);
+ }
+
+ /* Propagate caller endianness */
+ if (reset_state->be)
+ kvm_vcpu_set_be(vcpu);
+
+ *vcpu_pc(vcpu) = target_pc;
+
+ /*
+ * We may come from a state where either a PC update was
+ * pending (SMC call resulting in PC being increpented to
+ * skip the SMC) or a pending exception. Make sure we get
+ * rid of all that, as this cannot be valid out of reset.
+ *
+ * Note that clearing the exception mask also clears PC
+ * updates, but that's an implementation detail, and we
+ * really want to make it explicit.
+ */
+ vcpu_clear_flag(vcpu, PENDING_EXCEPTION);
+ vcpu_clear_flag(vcpu, EXCEPT_MASK);
+ vcpu_clear_flag(vcpu, INCREMENT_PC);
+ vcpu_set_reg(vcpu, 0, reset_state->r0);
+}
+
#endif /* __ARM64_KVM_EMULATE_H__ */
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 60969d90bdd3..e22d0be9e57c 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -34,18 +34,6 @@
static u32 __ro_after_init kvm_ipa_limit;
unsigned int __ro_after_init kvm_host_sve_max_vl;
-/*
- * ARMv8 Reset Values
- */
-#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
- PSR_F_BIT | PSR_D_BIT)
-
-#define VCPU_RESET_PSTATE_EL2 (PSR_MODE_EL2h | PSR_A_BIT | PSR_I_BIT | \
- PSR_F_BIT | PSR_D_BIT)
-
-#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
- PSR_AA32_I_BIT | PSR_AA32_F_BIT)
-
unsigned int __ro_after_init kvm_sve_max_vl;
int __init kvm_arm_init_sve(void)
@@ -191,7 +179,6 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
{
struct vcpu_reset_state reset_state;
bool loaded;
- u32 pstate;
scoped_guard(spinlock, &vcpu->arch.mp_state_lock) {
reset_state = vcpu->arch.reset_state;
@@ -210,21 +197,8 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
kvm_vcpu_reset_sve(vcpu);
}
- if (vcpu_el1_is_32bit(vcpu))
- pstate = VCPU_RESET_PSTATE_SVC;
- else if (vcpu_has_nv(vcpu))
- pstate = VCPU_RESET_PSTATE_EL2;
- else
- pstate = VCPU_RESET_PSTATE_EL1;
-
/* Reset core registers */
- memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
- memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
- vcpu->arch.ctxt.spsr_abt = 0;
- vcpu->arch.ctxt.spsr_und = 0;
- vcpu->arch.ctxt.spsr_irq = 0;
- vcpu->arch.ctxt.spsr_fiq = 0;
- vcpu_gp_regs(vcpu)->pstate = pstate;
+ kvm_reset_vcpu_core(vcpu);
/* Reset system registers */
kvm_reset_sys_regs(vcpu);
@@ -233,36 +207,8 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
* Additional reset state handling that PSCI may have imposed on us.
* Must be done after all the sys_reg reset.
*/
- if (reset_state.reset) {
- unsigned long target_pc = reset_state.pc;
-
- /* Gracefully handle Thumb2 entry point */
- if (vcpu_mode_is_32bit(vcpu) && (target_pc & 1)) {
- target_pc &= ~1UL;
- vcpu_set_thumb(vcpu);
- }
-
- /* Propagate caller endianness */
- if (reset_state.be)
- kvm_vcpu_set_be(vcpu);
-
- *vcpu_pc(vcpu) = target_pc;
-
- /*
- * We may come from a state where either a PC update was
- * pending (SMC call resulting in PC being increpented to
- * skip the SMC) or a pending exception. Make sure we get
- * rid of all that, as this cannot be valid out of reset.
- *
- * Note that clearing the exception mask also clears PC
- * updates, but that's an implementation detail, and we
- * really want to make it explicit.
- */
- vcpu_clear_flag(vcpu, PENDING_EXCEPTION);
- vcpu_clear_flag(vcpu, EXCEPT_MASK);
- vcpu_clear_flag(vcpu, INCREMENT_PC);
- vcpu_set_reg(vcpu, 0, reset_state.r0);
- }
+ if (reset_state.reset)
+ kvm_reset_vcpu_psci(vcpu, &reset_state);
/* Reset timer */
kvm_timer_vcpu_reset(vcpu);
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* Re: [PATCH v2 5/7] arm64: dts: qcom: shikra: Add pin configuration for mclks
From: Vladimir Zapolskiy @ 2026-06-12 8:02 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-5-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add pinctrl configuration for the four available camera master clocks.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index fed71131491ebf6e261bfcd14b5d4a2624837878..2f0f7710c2897e140495afd8d4e8bde50f356096 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -380,6 +380,34 @@ cci_i2c1_sleep: cci-i2c1-sleep-state {
> bias-pull-down;
> };
>
> + cam_mclk0_default: cam-mclk0-default-state {
> + pins = "gpio34";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk1_default: cam-mclk1-default-state {
> + pins = "gpio35";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk2_default: cam-mclk2-default-state {
> + pins = "gpio96";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk3_default: cam-mclk3-default-state {
> + pins = "gpio98";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> qup_uart0_default: qup-uart0-default-state {
> pins = "gpio0", "gpio1";
> function = "qup0_se0";
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 4/7] arm64: dts: qcom: shikra: Add CCI definitions
From: Vladimir Zapolskiy @ 2026-06-12 8:01 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-4-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Qualcomm Shikra SoC has one Camera Control Interface (CCI)
> containing two I2C hosts.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 70 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index b93ce4a92a998ea5d9d4268d2fd46030fafc4084..fed71131491ebf6e261bfcd14b5d4a2624837878 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -348,6 +348,38 @@ tlmm: pinctrl@500000 {
> gpio-ranges = <&tlmm 0 0 165>;
> wakeup-parent = <&mpm>;
>
> + cci_i2c0_default: cci-i2c0-default-state {
> + /* SDA, SCL */
> + pins = "gpio36", "gpio37";
> + function = "cci_i2c0";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +
> + cci_i2c0_sleep: cci-i2c0-sleep-state {
> + /* SDA, SCL */
> + pins = "gpio36", "gpio37";
> + function = "cci_i2c0";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> + cci_i2c1_default: cci-i2c1-default-state {
> + /* SDA, SCL */
> + pins = "gpio41", "gpio42";
> + function = "cci_i2c1";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +
> + cci_i2c1_sleep: cci-i2c1-sleep-state {
> + /* SDA, SCL */
> + pins = "gpio41", "gpio42";
> + function = "cci_i2c1";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> qup_uart0_default: qup-uart0-default-state {
> pins = "gpio0", "gpio1";
> function = "qup0_se0";
> @@ -701,6 +733,44 @@ port@1 {
> reg = <1>;
> };
> };
> +
> + };
> +
> + cci: cci@5c1b000 {
> + compatible = "qcom,shikra-cci", "qcom,msm8996-cci";
> + reg = <0x0 0x05c1b000 0x0 0x1000>;
> +
> + interrupts = <GIC_SPI 206 IRQ_TYPE_EDGE_RISING 0>;
> +
> + clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_CCI_0_CLK>;
> + clock-names = "ahb",
> + "cci";
> +
> + power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
> +
> + pinctrl-0 = <&cci_i2c0_default &cci_i2c1_default>;
> + pinctrl-1 = <&cci_i2c0_sleep &cci_i2c1_sleep>;
> + pinctrl-names = "default", "sleep";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "disabled";
> +
> + cci_i2c0: i2c-bus@0 {
> + reg = <0>;
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + cci_i2c1: i2c-bus@1 {
> + reg = <1>;
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
>
> qupv3_0: geniqup@4ac0000 {
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v5 0/4] PCI: Add DOE support for endpoint
From: Aksh Garg @ 2026-06-12 7:58 UTC (permalink / raw)
To: Frank Li
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <aise1tIyTj4WLU89@lizhi-Precision-Tower-5810>
On 12/06/26 02:17, Frank Li wrote:
> On Wed, Jun 10, 2026 at 03:32:52PM +0530, Aksh Garg wrote:
>> This patch series introduces the framework for supporting the Data
>> Object Exchange (DOE) feature for PCIe endpoint devices. Please refer
>> to the documentation added in patch 4 for details on the feature and
>> implementation architecture.
>>
>> The implementation provides a common framework for all PCIe endpoint
>> controllers, not specific to any particular SoC vendor.
>>
Hi Frank,
>
> General question, does DOE generate irq when received msg for HOST? I have
> not related irq handle code.
>
The EPC hardware is expected to raise IRQ when it receives DOE signals
from the host. The example IRQ code handler have been provided below.
When the response DOE is ready for the host, the signal_task_complete()
in pci-ep-doe.c invokes completion callback function, through which the
EPC driver handles to send the response back to the host using the DOE
mailbox.
> Any program to test it? such as pci_endpoint_test, need at least one real
> user to use it.
>
Currently there is no EPC driver upstream which support DOE yet.
However, you can refer to the conversation at [1] where the plan to add
user for this framework has been discussed.
Regards,
Aksh Garg
> Frank
>
>> The changes since v1 are documented in the respective patch descriptions.
>>
>> v4: https://lore.kernel.org/all/20260522052434.802034-1-a-garg7@ti.com/
>> v3: https://lore.kernel.org/all/20260427051725.223704-1-a-garg7@ti.com/
>> v2: https://lore.kernel.org/all/20260401073022.215805-1-a-garg7@ti.com/
>> v1 (RFC): https://lore.kernel.org/all/20260213123603.420941-1-a-garg7@ti.com/
>>
>> Below is a code demonstration showing the integration of DOE-EP APIs with
>> EPC drivers.
>>
>> Note: The provided code is just to show how an EPC driver is expected to
>> utilize the pci_ep_doe_process_request() and pci_ep_doe_abort() APIs,
>> and might not cover all the corner cases. The below implementation
>> also expects the EPC hardware to have some memory buffer to store the
>> data from(for) write_mailbox(read_mailbox) DOE capability registers.
>>
>> ============================================================================
>>
>> /* ========== DOE Completion Callback (invoked by DOE-EP core) ========== */
>>
>> static void doe_completion_cb(struct pci_epc *epc, u8 func_no, u16 cap_offset,
>> int status, u16 vendor, u8 type,
>> void *response_pl, size_t response_pl_sz)
>> {
>> struct epc_driver *drv = epc_get_drvdata(epc);
>> u32 *response = (u32 *)response_pl;
>> u32 header1, header2;
>> int payload_dw, i;
>>
>> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
>> /* Aborted: do not send response */
>> goto free;
>> }
>>
>> if (status < 0) {
>> /* Error: set ERROR bit in DOE Status register */
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> goto free;
>> }
>>
>> /* Success: write DOE headers first, then response to the read memory */
>>
>> /* Header 1: Vendor ID (bits 15:0) | Type (bits 23:16) */
>> header1 = (type << 16) | vendor;
>> writel(header1, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Header 2: Length in DW (including 2 DW of headers + payload) */
>> payload_dw = DIV_ROUND_UP(response_pl_sz, sizeof(u32));
>> header2 = 2 + payload_dw; /* 2 header DWs + payload */
>> writel(header2, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Set READY bit to signal response ready */
>> writel(1 << DOE_STATUS_READY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> /* Write response payload DWORDs to Read memory */
>> for (i = 0; i < payload_dw; i++)
>> writel(response[i],
>> drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Wait for the memory to empty before clearing the READY bit */
>> while (!RD_MEMORY_EMPTY()) {/* wait */}
>>
>> writel(0 << DOE_STATUS_READY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> free:
>> /* unset BUSY bit */
>> writel(0 << DOE_STATUS_BUSY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> kfree(response_pl);
>> }
>>
>> /* ========== DOE Interrupt Handler (triggered on GO bit from root complex) ========== */
>>
>> static irqreturn_t doe_interrupt_handler(int irq, void *priv)
>> {
>> struct epc_driver *drv = priv;
>> u16 cap_offset = extract_cap_offset_from_irq(irq);
>> u8 func_no = extract_func_from_irq(irq);
>> u32 header1, header2, length_dw, *request;
>> u16 vendor;
>> u8 type;
>> int i, ret;
>>
>> /* Read first header DWORD: Vendor ID (bits 15:0) | Type (bits 23:16) */
>> header1 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> vendor = header1 & 0xFFFF;
>> type = (header1 >> 16) & 0xFF;
>>
>> /* Read second header DWORD: Length in DW (includes 2 DW of headers) */
>> header2 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> length_dw = header2 & 0x3FFFF; /* Bits 17:0 */
>>
>> if (!length_dw)
>> length_dw = PCI_DOE_MAX_LENGTH;
>>
>> length_dw -= 2; /* Subtract 2 DW of headers to get payload length */
>> /* Allocate buffer for complete request (headers + payload) */
>> request = kzalloc(length_dw * sizeof(u32), GFP_ATOMIC);
>> if (!request) {
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> return IRQ_HANDLED;
>> }
>>
>> /* Read remaining payload DWORDs from Write memory */
>> for (i = 0; i < length_dw; i++) {
>> while (WR_MEMORY_EMPTY()) { /* wait */ }
>> request[i] = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> }
>>
>> mutex_lock(&lock);
>> /* Check the ABORT bit, if set then return */
>> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
>> kfree(request);
>> mutex_unlock(&lock);
>> return IRQ_HANDLED;
>> }
>>
>> /* Set BUSY bit */
>> writel(1 << DOE_STATUS_BUSY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> mutex_unlock(&lock);
>>
>> /* Hand off to DOE-EP core for asynchronous processing */
>> ret = pci_ep_doe_process_request(drv->epc, func_no, cap_offset,
>> vendor, type, (void *)request,
>> length_dw * sizeof(u32),
>> doe_completion_cb);
>> if (ret) {
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> kfree(request);
>> }
>>
>> return IRQ_HANDLED;
>> }
>>
>> /* ========== Abort Handler (triggered on ABORT bit from root complex) ========== */
>>
>> static irqreturn_t doe_abort_handler(int irq, void *priv)
>> {
>> struct epc_driver *drv = priv;
>> u16 cap_offset = extract_cap_offset_from_irq(irq);
>> u8 func_no = extract_func_from_irq(irq);
>>
>> mutex_lock(&lock);
>>
>> /* call abort API only if BUSY bit set (pci_ep_doe_process_request() called) */
>> if (readl(drv->base + PF_DOE_STATUS_REG(func_no, cap_offset)) & DOE_STATUS_BUSY)
>> pci_ep_doe_abort(drv->epc, func_no, cap_offset);
>>
>> mutex_unlock(&lock);
>>
>> /* Discard Write memory contents */
>> writel(DOE_WR_MEMORY_CTRL_DISCARD,
>> drv->base + PF_DOE_WR_MEMORY_CTRL_REG(func_no, cap_offset));
>>
>> /* Clear status bits */
>> writel((0 << DOE_STATUS_ERROR) | (0 << DOE_STATUS_READY),
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> return IRQ_HANDLED;
>> }
>>
>> ====================================================================================
>>
>> Aksh Garg (4):
>> PCI/DOE: Move common definitions to the header file
>> PCI: endpoint: Add DOE mailbox support for endpoint functions
>> PCI: endpoint: Add support for DOE initialization and setup in EPC
>> core
>> Documentation: PCI: Add documentation for DOE endpoint support
>>
>> Documentation/PCI/endpoint/index.rst | 1 +
>> .../PCI/endpoint/pci-endpoint-doe.rst | 333 ++++++++++
>> drivers/pci/doe.c | 11 -
>> drivers/pci/endpoint/Kconfig | 14 +
>> drivers/pci/endpoint/Makefile | 1 +
>> drivers/pci/endpoint/pci-ep-doe.c | 594 ++++++++++++++++++
>> drivers/pci/endpoint/pci-epc-core.c | 104 +++
>> drivers/pci/pci.h | 48 ++
>> include/linux/pci-doe.h | 8 +
>> include/linux/pci-epc.h | 9 +
>> 10 files changed, 1112 insertions(+), 11 deletions(-)
>> create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
>> create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v2 3/7] arm64: dts: qcom: shikra: Add CAMSS node
From: Vladimir Zapolskiy @ 2026-06-12 7:56 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-3-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add the Camera Subsystem node. Shikra shares the same IP as QCM2290
> with two CSIPHYs, two CSIDs and two VFEs, but does not include CDM
> and OPE blocks, so only a single IOMMU context bank is needed.
>
> Co-developed-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
> Signed-off-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 99 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..b93ce4a92a998ea5d9d4268d2fd46030fafc4084 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -604,6 +604,105 @@ opp-384000000 {
> };
> };
>
> + camss: camss@5c11000 {
> + compatible = "qcom,shikra-camss", "qcom,qcm2290-camss";
> +
> + reg = <0x0 0x05c11000 0x0 0x1000>,
> + <0x0 0x05c6e000 0x0 0x1000>,
> + <0x0 0x05c75000 0x0 0x1000>,
> + <0x0 0x05c52000 0x0 0x1000>,
> + <0x0 0x05c53000 0x0 0x1000>,
> + <0x0 0x05c66000 0x0 0x400>,
> + <0x0 0x05c68000 0x0 0x400>,
> + <0x0 0x05c6f000 0x0 0x4000>,
> + <0x0 0x05c76000 0x0 0x4000>;
> + reg-names = "top",
> + "csid0",
> + "csid1",
> + "csiphy0",
> + "csiphy1",
> + "csitpg0",
> + "csitpg1",
> + "vfe0",
> + "vfe1";
> +
> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
> + <&gcc GCC_CAMSS_AXI_CLK>,
> + <&gcc GCC_CAMSS_NRT_AXI_CLK>,
> + <&gcc GCC_CAMSS_RT_AXI_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CSID_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CSID_CLK>,
> + <&gcc GCC_CAMSS_CPHY_0_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_CPHY_1_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CPHY_RX_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CPHY_RX_CLK>;
> + clock-names = "ahb",
> + "axi",
> + "camnoc_nrt_axi",
> + "camnoc_rt_axi",
> + "csi0",
> + "csi1",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy1",
> + "csiphy1_timer",
> + "top_ahb",
> + "vfe0",
> + "vfe0_cphy_rx",
> + "vfe1",
> + "vfe1_cphy_rx";
> +
> + interrupts = <GIC_SPI 210 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 212 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 72 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 73 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 309 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 310 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 211 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 213 IRQ_TYPE_EDGE_RISING 0>;
> + interrupt-names = "csid0",
> + "csid1",
> + "csiphy0",
> + "csiphy1",
> + "csitpg0",
> + "csitpg1",
> + "vfe0",
> + "vfe1";
> +
> + interconnects = <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
> + &config_noc SLAVE_CAMERA_CFG RPM_ACTIVE_TAG>,
> + <&mmrt_virt MASTER_CAMNOC_HF RPM_ALWAYS_TAG
> + &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
> + <&mmnrt_virt MASTER_CAMNOC_SF RPM_ALWAYS_TAG
> + &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>;
> + interconnect-names = "ahb",
> + "hf_mnoc",
> + "sf_mnoc";
> +
> + iommus = <&apps_smmu 0x400 0x0>;
> + power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
Please add an empty line between the properties above.
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + };
> +
> + port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
> qupv3_0: geniqup@4ac0000 {
> compatible = "qcom,geni-se-qup";
> reg = <0x0 0x04ac0000 0x0 0x2000>;
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: i2c: qcom-cci: Document Shikra compatible
From: Vladimir Zapolskiy @ 2026-06-12 7:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Wolfram Sang
In-Reply-To: <20260608-shikra-camss-review-v2-2-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add Shikra compatible consistent with CAMSS CCI interfaces.
> It requires only two clocks.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Vladimir Zapolskiy @ 2026-06-12 7:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-1-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra contains the same Camera Subsystem IP as QCM2290. Document the
> platform-specific compatible string, using qcom,qcm2290-camss as
> fallback.
>
> Unlike QCM2290, Shikra omits the CDM and OPE blocks, requiring only a
> single IOMMU context bank instead of four.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> .../devicetree/bindings/media/qcom,qcm2290-camss.yaml | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> index 391d0f6f67ef5fdfea31dd3683477561516b1556..4f39eefb4898ebc22117407f26cfb4f41deb111b 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> @@ -14,8 +14,11 @@ description:
>
> properties:
> compatible:
> - const: qcom,qcm2290-camss
> -
> + oneOf:
> + - items:
> + - const: qcom,shikra-camss
> + - const: qcom,qcm2290-camss
> + - const: qcom,qcm2290-camss
> reg:
> maxItems: 9
>
> @@ -76,7 +79,14 @@ properties:
> - const: sf_mnoc
>
> iommus:
> - maxItems: 4
> + oneOf:
> + - items:
> + - description: S1 HLOS VFE non-protected (VFE only)
> + - items:
> + - description: S1 HLOS VFE non-protected
> + - description: S1 HLOS CDM non-protected
> + - description: S1 HLOS OPE read non-protected
> + - description: S1 HLOS OPE write non-protected
>
> power-domains:
> items:
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
From: Philipp Zabel @ 2026-06-12 7:51 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <airL0l3pgGRaPFVt@lizhi-Precision-Tower-5810>
On Thu, Jun 11, 2026 at 10:53:06AM -0400, Frank Li wrote:
> On Thu, Jun 11, 2026 at 10:18:59AM +0200, Philipp Zabel wrote:
> > Configure HDMI DDC SCL/SDA pins to support reading EDID.
> >
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
>
> Fix tags here?
Fixes: 95d7d7d2ad27 ("arm64: dts: imx8mp-frdm: add sd, ethernet, wifi, usb and hdmi support")
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 04/16] usb: hub: Return actual error from hub_configure() in hub_probe()
From: Chen-Yu Tsai @ 2026-06-12 7:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ailytpKQcvYTUH7j@ashevche-desk.local>
On Wed, Jun 10, 2026 at 11:20 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:38PM +0800, Chen-Yu Tsai wrote:
> > The addition of power sequencing descriptor handling in the USB hub code
> > requires dealing with deferred probing from pwrseq_get(). The power
> > sequencing provider may not yet be available when the USB hub probes.
> >
> > Return the actual error code from hub_configure() when it fails, so that
> > the driver core can notice the deferred probe request.
>
> Makes sense to me.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> One nit-pick, though.
>
> ...
>
> > - if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) {
> > + ret = hub_configure(hub, &desc->endpoint[0].desc);
> > + if (ret >= 0) {
> > onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
> >
> > return 0;
> > }
> >
> > hub_disconnect(intf);
> > - return -ENODEV;
> > + return ret;
>
> Can we convert to regular pattern, id est checking for errors first?
Sure. Will do it together in the next version.
ChenYu
> ret = hub_configure(hub, &desc->endpoint[0].desc);
> if (ret < 0) {
> hub_disconnect(intf);
> return ret;
> }
>
> onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
>
> return 0;
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v2 6/6] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Lorenzo Pieralisi @ 2026-06-12 7:46 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Sunil V L, Marc Zyngier, Thomas Gleixner, Huacai Chen,
Anup Patel, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, linux-riscv, linux-kernel, linux-acpi,
linux-arm-kernel, loongarch
In-Reply-To: <CAJZ5v0ibZKfzJwGyUb92-K1N9C_ab0QujpAKCrvMdyygquS1Vw@mail.gmail.com>
On Mon, Jun 08, 2026 at 07:18:15PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 3, 2026 at 10:21 AM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >
> > Register an ACPI hook in the ACPI interrupt management code for GICv5 to
> > retrieve the ACPI interrupt controller handle (if any) of the controller
> > handling a specific GSI, by updating the acpi_set_irq_model() call with
> > the gic_v5_get_gsi_handle() function pointer parameter.
> >
> > gicv5_get_gsi_handle() allows ACPI core to detect the ACPI handle
> > of the controller that manages a specific GSI interrupt.
> >
> > Update the IWB driver to clear device dependencies in ACPI core once the
> > IWB driver has probed.
> >
> > Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: Thomas Gleixner <tglx@kernel.org>
> > Cc: Marc Zyngier <maz@kernel.org>
> > ---
> > drivers/irqchip/irq-gic-v5-iwb.c | 5 +++++
> > drivers/irqchip/irq-gic-v5.c | 13 +++++++++++--
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-gic-v5-iwb.c b/drivers/irqchip/irq-gic-v5-iwb.c
> > index 9103feb70ce8..a02cb9537b15 100644
> > --- a/drivers/irqchip/irq-gic-v5-iwb.c
> > +++ b/drivers/irqchip/irq-gic-v5-iwb.c
> > @@ -269,6 +269,11 @@ static int gicv5_iwb_device_probe(struct platform_device *pdev)
> > if (IS_ERR(iwb_node))
> > return PTR_ERR(iwb_node);
> >
> > +#ifdef CONFIG_ACPI
> > + if (has_acpi_companion(&pdev->dev))
> > + acpi_dev_clear_dependencies(ACPI_COMPANION(&pdev->dev));
> > +#endif
>
> I would rather add a wrapper for this, along with an empty stub for
> the !CONFIG_ACPI case.
Given that this has no OF counterpart, I'd rather add an empty stub
for acpi_dev_clear_dependencies() and remove the ifdef - I am not
sure that adding a FW agnostic:
dev_clear_dependencies()
would help much but that's just my opinion. Then the question is whether I
should convert all other acpi_dev_clear_dependencies() users (with ifdeffery
included) in tree.
Thanks,
Lorenzo
>
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
> > index 03cc2830b260..26cfaea1af41 100644
> > --- a/drivers/irqchip/irq-gic-v5.c
> > +++ b/drivers/irqchip/irq-gic-v5.c
> > @@ -1217,11 +1217,19 @@ static struct fwnode_handle *gsi_domain_handle;
> > static struct fwnode_handle *gic_v5_get_gsi_domain_id(u32 gsi)
> > {
> > if (FIELD_GET(GICV5_GSI_IC_TYPE, gsi) == GICV5_GSI_IWB_TYPE)
> > - return iort_iwb_handle(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
> > + return iort_iwb_handle_fwnode(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
>
> Why is this change needed?
>
> >
> > return gsi_domain_handle;
> > }
> >
> > +static acpi_handle gic_v5_get_gsi_handle(u32 gsi)
> > +{
> > + if (FIELD_GET(GICV5_GSI_IC_TYPE, gsi) == GICV5_GSI_IWB_TYPE)
> > + return iort_iwb_handle(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
> > +
> > + return NULL;
> > +}
> > +
> > static int __init gic_acpi_init(union acpi_subtable_headers *header, const unsigned long end)
> > {
> > struct acpi_madt_gicv5_irs *irs = (struct acpi_madt_gicv5_irs *)header;
> > @@ -1242,7 +1250,8 @@ static int __init gic_acpi_init(union acpi_subtable_headers *header, const unsig
> > if (ret)
> > goto out_irs;
> >
> > - acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id, NULL);
> > + acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id,
> > + gic_v5_get_gsi_handle);
> >
> > return 0;
> >
> >
> > --
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] Add standard stats for HSR/PRP
From: MD Danish Anwar @ 2026-06-12 7:39 UTC (permalink / raw)
To: Andrew Lunn, Felix Maurer
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Jacob Keller, David Carlier,
Vadim Fedorenko, Kevin Hao, Markus Elfring, Hangbin Liu,
Fernando Fernandez Mancera, Jan Vaclav, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Luka Gejak
In-Reply-To: <e8965004-f286-4589-a834-309ccaa1d575@lunn.ch>
Hi Andrew,
On 11/06/26 9:20 pm, Andrew Lunn wrote:
> On Thu, Jun 11, 2026 at 03:20:32PM +0530, MD Danish Anwar wrote:
>> Add standard stats for HSR / PRP. This series was initially adding HSR/PRP
>> related stats for ICSSG driver. Based on maintainers' comments on v2 I am
>> now adding support to dump standard stats for HSR/PRP.
>>
>> The drivers which support offload can populate these standard stats.
>>
>> This series only implements offloaded stats. For software-only interfaces
>> Felix Maurer had said he will do it later [1]
>
> That is ideally the wrong way around. Offloading it used to accelerate
> what Linux can already do in software. Statistics should be part of
> this, you first define software statistics, and then get the hardware
> to report those.
On v2 of the series Felix commented saying I should go ahead with the
hardware stats first and he can later implement for software only
interfaces [1]. This is the reason I went ahead with this. Initially
this series was not standardizing the stats of HSR/PPR interfaces, it
was only meant for dumping those stats for ICSSG via ethtool -S.
Felix and Jakub commented saying I should standardize these stats.
Hi Felix, When can you implement the same for software only interfaces?
If we can't add support for hardware interfaces before software only
interfaces, then what should be the next steps?
[1]
https://lore.kernel.org/all/ag87pBZfOyccPZTc@thinkpad/#:~:text=(no%20need%20to%20implement%20it%20for%20the%20software%2Donly%20interfaces%0Ain%20this%20patch%20series%2C%20I%20can%20do%20that%20afterwards%20as%20well)
>
> So please get the software statistics merged first.
>
> Andrew
--
Thanks and Regards,
Danish
^ permalink raw reply
* Re: [PATCH 2/2] cpufreq: add ACPM-based CPU DVFS driver for Exynos SoCs
From: Viresh Kumar @ 2026-06-12 7:39 UTC (permalink / raw)
To: Alexey Klimov
Cc: Tudor Ambarus, Sam Protsenko, Krzysztof Kozlowski, Peter Griffin,
Alim Akhtar, Rafael J. Wysocki, Sudeep Holla, linux-samsung-soc,
linux-arm-kernel, linux-pm, kernel-team, linux-kernel
In-Reply-To: <20260612-acpm-fast-xfer-v1-2-1aa6cd2268ba@linaro.org>
On 12-06-26, 05:34, Alexey Klimov wrote:
> Exynos-based SoCs (e.g., Exynos850, gs101) manage CPU DVFS via an
> ACPM co-processor (sometimes co-processor specifically called APM).
> Historically, routing CPU frequencies through the clock framework
> breaks fast frequency switching as it is implemented in cpufreq-dt.
> The clk_set_rate() uses mutexes, which prevents the scheduler to
> utilize schedutil's fast path.
The OPP core can be configured with a "config_clks" helper, which can let you
call a custom callback instead of clk_set_rate(). With that you can still use
cpufreq-dt ? This may need minor update in OPP core though, as we don't allow
the custom callback for single clocks for now.
> Introduce a dedicated ACPM-based cpufreq driver that bypasses the clock
> framework and communicates directly with the ACPM firmware protocol.
> It implements ->fast_switch() to rely on acpm_dvfs_set_rate_fast(),
> enabling faster frequency transitions.
>
> Add Google gs101 and Samsung exynos850 to the cpufreq-dt-platdev
> blocklist to prevent driver cpufreq-dt initialisation.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> drivers/cpufreq/Kconfig.arm | 8 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/acpm-cpufreq.c | 195 +++++++++++++++++++++++++++++++++++
> drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
> 4 files changed, 207 insertions(+)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index a441668f9e0c..891ff4b6ec22 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -24,6 +24,14 @@ config ARM_AIROHA_SOC_CPUFREQ
> help
> This adds the CPUFreq driver for Airoha EN7581 SoCs.
>
> +config ARM_ACPM_CPUFREQ
> + tristate "ACPM based CPUFreq support"
> + depends on ARCH_EXYNOS || (COMPILE_TEST && 64BIT)
> + select PM_OPP
> + help
> + This adds the CPUFreq driver for Exynos-based machines
> + with ACPM firmware.
> +
> config ARM_APPLE_SOC_CPUFREQ
> tristate "Apple Silicon SoC CPUFreq support"
> depends on ARCH_APPLE || (COMPILE_TEST && 64BIT)
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 6c7a39b7f8d2..c54d2dd6629d 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_X86_AMD_FREQ_SENSITIVITY) += amd_freq_sensitivity.o
> ##################################################################################
> # ARM SoC drivers
> obj-$(CONFIG_ARM_AIROHA_SOC_CPUFREQ) += airoha-cpufreq.o
> +obj-$(CONFIG_ARM_ACPM_CPUFREQ) += acpm-cpufreq.o
> obj-$(CONFIG_ARM_APPLE_SOC_CPUFREQ) += apple-soc-cpufreq.o
> obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ) += armada-37xx-cpufreq.o
> obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ) += armada-8k-cpufreq.o
> diff --git a/drivers/cpufreq/acpm-cpufreq.c b/drivers/cpufreq/acpm-cpufreq.c
> new file mode 100644
> index 000000000000..20fb79169993
> --- /dev/null
> +++ b/drivers/cpufreq/acpm-cpufreq.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Exynos ACPM-based CPUFreq DVFS driver
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/cpufreq.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_opp.h>
> +#include <linux/slab.h>
> +
> +#include <linux/firmware/samsung/exynos-acpm-protocol.h>
Add this within the earlier list in alphabetic order.
> +#define ACPM_DVFS_TRANSITION_TIMEOUT 400
> +
> +struct acpm_cpu_priv {
> + struct device *cpu_dev;
> + struct acpm_handle *handle;
> + unsigned int acpm_chan_id;
> + unsigned int clk_id;
> +};
> +
> +static unsigned int acpm_soc_cpufreq_get_rate(unsigned int cpu)
> +{
> + struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
> + struct acpm_cpu_priv *priv;
> +
> + if (unlikely(!policy))
> + return 0;
> +
> + priv = policy->driver_data;
> +
> + /* return priv->handle->ops->dvfs.get_rate(priv->handle, priv->acpm_chan_id,
> + * priv->clk_id) / 1000;
> + */
Wrong multiline comment format.
> +
> + /* TODO: FIXME. Exynos850 doesn't return rate via ACPM */
:(
> + return policy->cur;
> +}
> +
> +static int acpm_soc_cpufreq_set_target(struct cpufreq_policy *policy,
> + unsigned int index)
> +{
> + struct acpm_cpu_priv *priv = policy->driver_data;
> + unsigned long freq_khz = policy->freq_table[index].frequency;
> +
> + /* standard slow path */
> + return priv->handle->ops->dvfs.set_rate(priv->handle, priv->acpm_chan_id,
> + priv->clk_id, freq_khz * 1000);
> +}
> +
> +static unsigned int acpm_soc_cpufreq_fast_switch(struct cpufreq_policy *policy,
> + unsigned int target_freq)
> +{
> + struct acpm_cpu_priv *priv = policy->driver_data;
> + int ret;
> +
> + ret = priv->handle->ops->dvfs.set_rate_fast(priv->handle, priv->acpm_chan_id,
> + priv->clk_id, target_freq * 1000);
> + if (ret < 0)
> + return 0;
> +
> + return target_freq;
> +}
> +
> +static int acpm_soc_cpufreq_init(struct cpufreq_policy *policy)
> +{
> + struct device *cpu_dev = get_cpu_device(policy->cpu);
> + struct cpufreq_frequency_table *freq_table;
> + struct acpm_cpu_priv *priv;
> + struct of_phandle_args args;
> + unsigned int transition_latency;
> + int ret;
> +
> + if (!cpu_dev)
> + return -ENODEV;
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + ret = of_parse_phandle_with_args(cpu_dev->of_node, "clocks",
> + "#clock-cells", 0, &args);
> + if (ret) {
> + dev_err(cpu_dev, "failed to parse clocks property\n");
> + goto out_free_priv;
> + }
> +
> + priv->clk_id = args.args[0];
> +
> + /*
> + * DVFS communication is expected to happen only via channel 0
> + * for now for known SoCs with ACPM firmware. Hardcoding.
> + */
> + priv->acpm_chan_id = 0;
> +
> + priv->handle = devm_acpm_get_by_node(cpu_dev, args.np);
devm on CPU node is incorrect. The resource won't be freed if you remove this
driver's module.
> + of_node_put(args.np);
> +
> + if (IS_ERR(priv->handle)) {
> + ret = PTR_ERR(priv->handle);
> + goto out_free_priv;
> + }
> +
> + priv->cpu_dev = cpu_dev;
> +
> + ret = dev_pm_opp_of_add_table(cpu_dev);
> + if (ret < 0) {
> + dev_err(cpu_dev, "failed to add OPP table: %d\n", ret);
> + goto out_free_priv;
> + }
> +
> + dev_pm_opp_of_get_sharing_cpus(cpu_dev, policy->cpus);
Check count before this ?
> + ret = dev_pm_opp_get_opp_count(cpu_dev);
> + if (ret <= 0) {
> + ret = -EPROBE_DEFER;
> + goto out_remove_table;
> + }
> +
> + ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
> + if (ret) {
> + dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
> + goto out_remove_table;
> + }
> +
> + policy->driver_data = priv;
> + policy->freq_table = freq_table;
> +
> + transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev);
> + if (!transition_latency)
> + transition_latency = ACPM_DVFS_TRANSITION_TIMEOUT * NSEC_PER_USEC;
> +
> + policy->cpuinfo.transition_latency = transition_latency;
> + policy->dvfs_possible_from_any_cpu = true;
> + policy->fast_switch_possible = true;
> + policy->suspend_freq = freq_table[0].frequency;
> +
> + /* TODO: FIXME. Exynos850 doesn't expose rate of clocks via ACPM (get_rate doesn't work) */
This makes the driver broken. I don't think we can merge with this.
> + policy->cur = freq_table[0].frequency;
> +
> + return 0;
> +
> +out_remove_table:
> + dev_pm_opp_of_remove_table(cpu_dev);
> +out_free_priv:
> + kfree(priv);
> + return ret;
> +}
> +
> +static void acpm_soc_cpufreq_exit(struct cpufreq_policy *policy)
> +{
> + struct acpm_cpu_priv *priv = policy->driver_data;
> +
> + dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
> + dev_pm_opp_of_remove_table(priv->cpu_dev);
> + kfree(priv);
> +}
> +
> +static struct cpufreq_driver acpm_soc_cpufreq_driver = {
> + .name = "acpm-cpufreq",
> + .flags = CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
> + CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_IS_COOLING_DEV,
> + .verify = cpufreq_generic_frequency_table_verify,
> + .get = acpm_soc_cpufreq_get_rate,
> + .init = acpm_soc_cpufreq_init,
> + .exit = acpm_soc_cpufreq_exit,
> + .target_index = acpm_soc_cpufreq_set_target,
> + .fast_switch = acpm_soc_cpufreq_fast_switch,
> + .register_em = cpufreq_register_em_with_opp,
> + .set_boost = cpufreq_boost_set_sw,
> + .suspend = cpufreq_generic_suspend,
> +};
> +
> +static int __init acpm_soc_cpufreq_module_init(void)
> +{
> + if (!of_machine_is_compatible("google,gs101") &&
> + !of_machine_is_compatible("samsung,exynos850"))
> + return -ENODEV;
> +
> + return cpufreq_register_driver(&acpm_soc_cpufreq_driver);
> +}
> +module_init(acpm_soc_cpufreq_module_init);
> +
> +static void __exit acpm_soc_cpufreq_module_exit(void)
> +{
> + cpufreq_unregister_driver(&acpm_soc_cpufreq_driver);
> +}
> +module_exit(acpm_soc_cpufreq_module_exit);
> +
> +MODULE_AUTHOR("Alexey Klimov <alexey.klimov@linaro.org>");
> +MODULE_DESCRIPTION("ACPM-based CPUfreq DVFS driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index ff1204c666b1..ae58aa92fc40 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -186,6 +186,9 @@ static const struct of_device_id blocklist[] __initconst = {
> { .compatible = "qcom,sm8550", },
> { .compatible = "qcom,sm8650", },
>
> + { .compatible = "google,gs101", },
> + { .compatible = "samsung,exynos850", },
> +
> { .compatible = "st,stih407", },
> { .compatible = "st,stih410", },
> { .compatible = "st,stih418", },
>
> --
> 2.51.0
--
viresh
^ permalink raw reply
* Re: [PATCH net-next 8/8] net: dsa: mt7530: implement port_change_conduit op
From: Chester A. Unal @ 2026-06-12 7:36 UTC (permalink / raw)
To: Daniel Golle, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <91ae0f87a6ca2cce3d072dba548545e02347bf13.1781119435.git.daniel@makrotopia.org>
On 10/06/2026 20:56, Daniel Golle wrote:
> Allow changing the CPU port affinity of user ports at runtime via
> the IFLA_DSA_CONDUIT netlink attribute. This updates the port matrix
> to forward to the new CPU port instead of the old one.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fabulous!
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
> ---
> drivers/net/dsa/mt7530.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index c96420c291d5..2f3e734b9f53 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -3206,6 +3206,34 @@ static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
> return 0;
> }
>
> +static int
> +mt753x_port_change_conduit(struct dsa_switch *ds, int port,
> + struct net_device *conduit,
> + struct netlink_ext_ack *extack)
> +{
> + struct dsa_port *new_cpu_dp = conduit->dsa_ptr;
> + struct dsa_port *dp = dsa_to_port(ds, port);
> + struct mt7530_priv *priv = ds->priv;
> +
> + if (priv->id != ID_MT7531)
> + return -EOPNOTSUPP;
Why do we limit this to MT7531 only?
Chester A.
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: Andrew Jeffery @ 2026-06-12 7:32 UTC (permalink / raw)
To: Grégoire Layet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260612072341.278591-1-gregoire.layet@9elements.com>
Hi Grégoire,
On Fri, 2026-06-12 at 07:23 +0000, Grégoire Layet wrote:
> It use the existing ast2600-pwm-tach driver.
> Placed according to bus adresses ordering.
>
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index 189bc3bbb47c..818d486b94ac 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -102,6 +102,15 @@ ahbc: bus@1e600000 {
> reg = <0x1e600000 0x100>;
> };
>
> + pwm_tach: pwm-tach-controller@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach";
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> fmc: spi@1e620000 {
> reg = <0x1e620000 0xc4>, <0x20000000 0x10000000>;
> #address-cells = <1>;
Thanks for the patch, however:
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git/commit/?h=aspeed/arm/dt&id=6cf976b2728f2494215c51c7339dd50b154125ce
You can also find the commit in linux-next.git master and soc.git
soc/dt, queued for v7.2.
Andrew
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Wandun @ 2026-06-12 7:28 UTC (permalink / raw)
To: Baoquan He
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, Rob Herring, saravanak,
bhe, rppt, pjw, palmer, aou, chenhuacai, kernel, catalin.marinas,
will, alex, akpm, pasha.tatashin, pratyush, ruirui.yang,
m.szyprowski, robin.murphy
In-Reply-To: <aiqkKe1gXPZ5LZ7t@MiWiFi-R3L-srv>
On 6/11/26 20:03, Baoquan He wrote:
> On 06/11/26 at 11:09am, Wandun wrote:
>>
>>
>> On 6/11/26 10:09, Wandun wrote:
>>>
>>>
>>> On 5/27/26 11:29, Wandun Chen wrote:
>>>> From: Wandun Chen <chenwandun@lixiang.com>
>>>>
>>>> On SoCs that carve out large firmware-owned reserved memory (GPU
>>>> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
>>>> those carveouts as part of system RAM even though their contents are
>>>> firmware state that is not useful for kernel crash analysis.
>>>>
>>>> This series introduces an opt-in 'dumpable' flag [1] on struct
>>>> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
>>>> DT-based architectures (arm64, riscv, loongarch). By default reserved
>>>> regions are treated as non-dumpable; CMA regions are explicitly opted
>>>> in because their pages are returned to the buddy allocator and may
>>>> carry key crash-analysis data.
>>>>
>>>> The series is organized as follows:
>>>> Patches 1-3: Pre-existing fixes and a small prep change.
>>>> Patches 4-5: Restructure to allow appending /memreserve/ entries.
>>>> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
>>>> Patch 8: Add generic kdump helpers.
>>>> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
>>>> elfcorehdr preparation.
>>> Hi,
>>>
>>> Gentle ping on this series.
>>>
>>> Status summary:
>>> -patch 03: respun separately per Rob's suggestion, picked up for 7.2
>>> -patch 06: Acked-by: Marek Szyprowski -patch 09: Acked-by: Will Deacon
>>> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
>>> awaiting review. your feedback would be greately appreciated. I know we
>>> are at the end of 7.1 -rc cycle, I don't want to rush this series, just
>>> collecting more feedback, and will send next version based on 7.2-rc1.
>>> If spliting the series into smaller logical group would make review
>>> easier, please let me know. Best regards, Wandun
>>
>> Apologies for the formatting issue in my previous email.
>> Here is the properly formatted version.
>>
>> Gentle ping on this series.
>
> Thanks for the effort, the overral looks good to me at 1st glance. I will
> check if there's concern on generic part. And meanwhile, I am wondering
> if there's any chance x86 or other ARCH-es w/o OF/FDT can also choose to
> not dump some areas, e.g GPU stolen memory. Surely, that's another story.
Thanks for the review, Baoquan.
IIUC, reserved memory is already excluded from vmcore on x86.
Reserved memory is typed as E820_TYPE_RESERVED in the e820 table, and
insert into iomem resource tree with IORESOURCE_MEM flag. The x86 kdump
patch uses walk_system_ram_res() which scan iomem resource tree, and
only collects ranges with IORESOURCE_SYSTEM_RAM flag, so reserved
regions are excluded.
Best regards,
Wandun
>
>>
>> Status summary:
>> - patch 03: respun separately per Rob's suggestion, picked up for 7.2
>> - patch 06: Acked-by: Marek Szyprowski
>> - patch 09: Acked-by: Will Deacon
>>
>> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
>> awaiting review. Your feedback would be greatly appreciated.
>>
>> I know we are at the end of 7.1-rc cycle, I don't want to rush this
>> series, just collecting more feedback, and will send next version based
>> on 7.2-rc1.
>>
>> If splitting the series into smaller logical groups would make review
>> easier, please let me know.
>>
>> Best regards,
>> Wandun
>>
>>
>>>>
>>>> v2 --> v3:
>>>> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
>>>> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
>>>> 3. Add some prepare patches.
>>>>
>>>> v1 --> v2:
>>>> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
>>>> feedback [1], v2 drop that property and exclude reserve memory
>>>> by default.
>>>> 2. Split some prepared patches from the original patches.
>>>> 3. Address coding-style comments on patch 5 from Rob.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-
>>>> robh@kernel.org/
>>>> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-
>>>> chenwandun%40lixiang.com?part=4
>>>>
>>>> Wandun Chen (11):
>>>> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
>>>> kexec/crash: provide crash_exclude_mem_range() stub when
>>>> CONFIG_CRASH_DUMP=n
>>>> of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()
>>>> fails
>>>> of: reserved_mem: zero total_reserved_mem_cnt if no valid
>>>> /reserved-memory entry
>>>> of: reserved_mem: split alloc_reserved_mem_array() from
>>>> fdt_scan_reserved_mem_late()
>>>> of: reserved_mem: add dumpable flag to opt-in vmcore
>>>> of: reserved_mem: save /memreserve/ entries into the reserved_mem
>>>> array
>>>> of: reserved_mem: add kdump helpers to exclude non-dumpable regions
>>>> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
>>>> riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
>>>> loongarch: kdump: exclude non-dumpable reserved memory regions from
>>>> vmcore
>>>>
>>>> arch/arm64/kernel/machine_kexec_file.c | 6 ++
>>>> arch/loongarch/kernel/machine_kexec_file.c | 6 ++
>>>> arch/riscv/kernel/machine_kexec_file.c | 4 +
>>>> drivers/of/fdt.c | 11 +-
>>>> drivers/of/of_private.h | 3 +
>>>> drivers/of/of_reserved_mem.c | 117 +++++++++++++++++++--
>>>> include/linux/crash_core.h | 6 ++
>>>> include/linux/of_reserved_mem.h | 15 +++
>>>> kernel/dma/contiguous.c | 1 +
>>>> 9 files changed, 157 insertions(+), 12 deletions(-)
>>>>
>>>
>>
^ permalink raw reply
* [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: Grégoire Layet @ 2026-06-12 7:23 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: Grégoire Layet, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
It use the existing ast2600-pwm-tach driver.
Placed according to bus adresses ordering.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 189bc3bbb47c..818d486b94ac 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -102,6 +102,15 @@ ahbc: bus@1e600000 {
reg = <0x1e600000 0x100>;
};
+ pwm_tach: pwm-tach-controller@1e610000 {
+ compatible = "aspeed,ast2600-pwm-tach";
+ reg = <0x1e610000 0x100>;
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
fmc: spi@1e620000 {
reg = <0x1e620000 0xc4>, <0x20000000 0x10000000>;
#address-cells = <1>;
--
2.51.2
^ permalink raw reply related
* [GIT PULL] soc: fixes for 7.3, part 3
From: Arnd Bergmann @ 2026-06-12 7:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: soc, linux-kernel, linux-arm-kernel
The following changes since commit 7fd2df204f342fc17d1a0bfcd474b24232fb0f32:
Linux 7.1-rc2 (2026-05-03 14:21:25 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-7.1-3
for you to fetch changes up to 9c648f3554920721d8878807cd794fe2d7f989e8:
Merge tag 'v7.1-rockchip-arm32fixe' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes (2026-06-09 09:16:26 +0200)
----------------------------------------------------------------
soc: fixes for 7.3, part 3
Two more small fixes came in, both addressing corner cases in platform
specific code: the microchip mpfs system controller probe and the CPU
power management on 32-bit rockchips SoCs.
----------------------------------------------------------------
Arnd Bergmann (2):
Merge tag 'riscv-soc-fixes-for-v7.1-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes
Merge tag 'v7.1-rockchip-arm32fixe' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
Felix Gu (1):
soc: microchip: mpfs-sys-controller: fix resource leak on probe error
Heiko Stuebner (1):
ARM: rockchip: keep reset control around
arch/arm/mach-rockchip/platsmp.c | 16 ++++++++++------
drivers/soc/microchip/mpfs-sys-controller.c | 6 ++++--
2 files changed, 14 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 02/16] device property: Add fwnode_graph_get_next_port_endpoint()
From: Chen-Yu Tsai @ 2026-06-12 7:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ailv8HpnrCH3Zb8C@ashevche-desk.local>
On Wed, Jun 10, 2026 at 11:08 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:36PM +0800, Chen-Yu Tsai wrote:
> > Due to design constraints of the power sequencing API, the consumer
> > must first be sure that the other side is actually a provider, or it
> > will continually get -EPROBE_DEFER when requesting the power
> > sequencing descriptor.
> >
> > In the upcoming USB power sequencing integration, the USB hub driver
> > first needs to check whether a graph connection exists, and whether
> > the other side of the connection is a supported connector type. The
> > USB port is tied to a "port" firmware node, and this new helper will
> > be used to get the endpoint under the known "port" firmware node.
>
> ...
>
> > +/**
> > + * fwnode_graph_get_next_port_endpoint - Get next endpoint firmware node in port
> > + * @port: Pointer to the target port firmware node
> > + * @prev: Previous endpoint node or %NULL to get the first
> > + *
> > + * The caller is responsible for calling fwnode_handle_put() on the returned
> > + * fwnode pointer. Note that this function also puts a reference to @prev
> > + * unconditionally.
> > + *
> > + * Return: an endpoint firmware node pointer or %NULL if no more endpoints
> > + * are available.
>
> Yeah, you see, even here is inconsistency with previously added kernel-doc.
>
> > + */
> > +struct fwnode_handle *fwnode_graph_get_next_port_endpoint(const struct fwnode_handle *port,
> > + struct fwnode_handle *prev)
> > +{
> > + struct fwnode_handle *ep;
>
> Unused?
>
> > + while (1) {
>
> This is usually harder to read and follow. It's like "pay much attention on
> the code", but here no rocket science, no code to really pay attention to.
>
> > + prev = fwnode_get_next_child_node(port, prev);
> > + if (!prev)
> > + break;
> > +
> > + if (WARN(!fwnode_name_eq(prev, "endpoint"),
> > + "non endpoint node is used (%pfw)", prev))
> > + continue;
> > +
> > + break;
> > + }
> > +
> > + return prev;
> > +}
>
> So, this can be rewritten as
>
> ep = prev;
> do {
> ep = fwnode_get_next_child_node(port, ep);
> if (fwnode_name_eq(ep, "endpoint"))
> break;
>
> WARN_ON(ep, ...);
> } while (ep);
>
> return ep;
>
> But also big question why? to WARN*(). There is no use in the entire
> property.c.
Will drop. This function was lifted from drivers/of/property.c then
adapted to the fwnode APIs, so it still has the structure of its
origin. With the WARN() gone, rewriting it as do {} while() becomes:
do {
prev = fwnode_get_next_child_node(port, prev);
if (prev && fwnode_name_eq(prev, "endpoint"))
break;
} while (prev);
return prev;
Thanks
ChenYu
^ permalink raw reply
* Re: [RFC PATCH 3/6] arm64: mm: fix restoring linear map permissions on execmem cache clean
From: Mike Rapoport @ 2026-06-12 7:17 UTC (permalink / raw)
To: Brendan Jackman
Cc: Adrian Barnaś, linux-arm-kernel, linux-mm, Catalin Marinas,
Will Deacon, Ryan Roberts, David Hildenbrand, Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman, owner-linux-mm
In-Reply-To: <DJ69RCVRBO0Y.3JCYSW50IC4RC@linux.dev>
On Thu, Jun 11, 2026 at 01:54:13PM +0000, Brendan Jackman wrote:
> On Thu Jun 11, 2026 at 1:01 PM UTC, =?UTF-8?q?Adrian=20Barna=C5=9B?= wrote:
> > Strip the read-only attribute from the selected memory range when
> > restoring the linear map after an execmem cache clean.
> >
> > An execmem cache clean is performed when a cache block becomes empty
> > after unloading a module. When making the memory valid again, the linear
> > memory alias must also have its read-only attribute cleared.
> >
> > Without this change, the linear memory alias remains read-only even
> > after the execmem cache block itself is freed, which prevents subsequent
> > allocations from writing to that memory.
> >
> > Signed-off-by: Adrian Barnaś <abarnas@google.com>
> > ---
> > arch/arm64/mm/pageattr.c | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> > index 88720bbba892..eaefdf90b0d5 100644
> > --- a/arch/arm64/mm/pageattr.c
> > +++ b/arch/arm64/mm/pageattr.c
> > @@ -239,6 +239,13 @@ int set_memory_x(unsigned long addr, int numpages)
> > __pgprot(PTE_PXN));
> > }
> >
> > +static int set_memory_default(unsigned long addr, int numpages)
> > +{
> > + return __change_memory_common(addr, PAGE_SIZE * numpages,
> > + __pgprot(PTE_VALID),
> > + __pgprot(PTE_RDONLY));
> > +}
> > +
> > int set_memory_valid(unsigned long addr, int numpages, int enable)
> > {
> > if (enable)
> > @@ -362,7 +369,15 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> > if (!can_set_direct_map())
> > return 0;
> >
> > - return set_memory_valid(addr, nr, valid);
> > + /*
> > + * Execmem cache uses this function to reset permissions on linear mapping
> > + * when freeing unused cache block. On x86 it makes memory RW which is
> > + * desirable.
>
> Hm, maybe desirable for execmem but that doesn't really mean the x86
> behaviour is correct. Maybe it makes more sense to change the x86
> to align with the arm64 behaviour here?
>
> BTW we should probably document this API a little bit, I never thought
> abut what "valid" actually means until now. I had thought of it as "I
> can access this memory" but that's an unclear concept and now I realise
> "valid" is a technical concept in Arm that's confusing. And it's extra
> confusing if the kernel API uses "valid" to mean a _different_ thing.
I've got confused too and that's how set_direct_map_valid() got into x86
with a different semantics than on arm64.
What execmem really needs is set_direct_map_default() variant that gets
nr_pages.
AFAIR, set_direct_map_default() has a single 'page' parameter because it
was added to reset permissions for the direct map alias for vmalloc()'ed
pages before there was VMALLOC_HUGE and each page had to be reset
independently anyway.
Maybe it's time to add nr_pages to set_direct_map_valid().
> Also, shouldn't execmem be using set_memory_default_noflush() before
> freeing anyway? I guess that shoudl even be documented as "if you change
> anything you need to call this before you free the page".
It does on x86 because there set_direct_map_valid() is the same as
set_direct_map_default().
> > On ARM64 set_memory_valid() just change valid bit which
> > + * leave direct mapping read-only so use set_memory_default instead.
> > + */
> > +
> > + return valid ? set_memory_default(addr, nr) :
> > + set_memory_valid(addr, nr, false);
> > }
> >
> > #ifdef CONFIG_DEBUG_PAGEALLOC
>
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 01/16] device property: Add fwnode_graph_get_port_by_id()
From: Chen-Yu Tsai @ 2026-06-12 7:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ailtMyYhbkOgaZWw@ashevche-desk.local>
On Wed, Jun 10, 2026 at 10:57 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:35PM +0800, Chen-Yu Tsai wrote:
> > In some cases the driver needs a reference to the port firmware node.
> > Once such case is the upcoming USB power sequencing integration. The
> > USB hub port is tied to the corresponding port firmware node if it
> > exists.
> >
> > Provide a helper for this.
>
> Okay, if it's really needed.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> ...
>
> > +/**
> > + * fwnode_graph_get_port_by_id - get the port matching a given id
> > + * @fwnode: parent fwnode_handle containing the graph
> > + * @id: id of the port
> > + *
> > + * Return: A 'port' firmware node pointer with refcount incremented.
> > + *
> > + * The caller is responsible for calling fwnode_handle_put() on the returned
> > + * fwnode pointer.
>
> Note, the Return section must be last one in the kernel-doc. The last paragraph
> sounds to me as a better fit for main description. Basically check how other
> kernel-doc(s) in this file are organised and follow that pattern.
Will fix. I likely just copied it from the nearest function which happened
to not have a Return section. I did a quick look through and it seems many
of them are missing this.
ChenYu
^ permalink raw reply
* Re: [PATCH v7 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Andrew Lunn @ 2026-06-12 7:04 UTC (permalink / raw)
To: Kyle Hsieh
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <CAF7HswOi3fPMFppPoGmh0QELiPz4Po4cyWuDrEHLY2vNMyKE9g@mail.gmail.com>
> The EEPROM is physically isolated by a hardware I2C multiplexer.
> By default, the mux connects the EEPROM directly to the Marvell switch
> for its routine operation and configuration loading. The BMC's I2C bus is
> physically disconnected from the EEPROM during this time.
I think some comments would be good. It was not clear to my how this
works.
Andrew
^ permalink raw reply
* [PATCH v1 09/11] KVM: arm64: Minimise EL2's exposure of host VGIC state during world switch
From: tabba @ 2026-06-12 6:59 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Will Deacon, Catalin Marinas, Quentin Perret,
Vincent Donnefort, Sebastian Ene, Per Larsen, Suzuki K Poulose,
Zenghui Yu, Joey Gouly, Steffen Eiden, Mark Rutland,
Jonathan Cameron, Hyunwoo Kim, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260612065925.755562-1-tabba@google.com>
From: Marc Zyngier <maz@kernel.org>
The host passes a vgic_v3_cpu_if pointer to the __vgic_v3_save_aprs and
__vgic_v3_restore_vmcr_aprs hypercalls, which EL2 dereferences
wholesale. That exposes the host's full VGIC emulation state to the
hypervisor, against pKVM's isolation goals.
Recover the host vCPU from the supplied cpu_if via container_of() and
copy only vgic_vmcr and the active priority registers between EL2's
hyp-side state and the host vCPU, so EL2 no longer dereferences the
host's vgic_v3_cpu_if directly.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Co-developed-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 67 ++++++++++++++++++++++++++++--
1 file changed, 63 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 420fb19a6476..2f165b6c7b07 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -7,6 +7,8 @@
#include <hyp/adjust_pc.h>
#include <hyp/switch.h>
+#include <linux/irqchip/arm-gic-v3.h>
+
#include <asm/pgtable-types.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
@@ -220,6 +222,16 @@ static struct kvm_vcpu *__get_host_hyp_vcpus(struct kvm_vcpu *arg,
__get_host_hyp_vcpus(__vcpu, hyp_vcpup); \
})
+#define get_host_hyp_vcpus_from_vgic_v3_cpu_if(ctxt, regnr, hyp_vcpup) \
+ ({ \
+ DECLARE_REG(struct vgic_v3_cpu_if *, cif, ctxt, regnr);\
+ struct kvm_vcpu *__vcpu = container_of(cif, \
+ struct kvm_vcpu, \
+ arch.vgic_cpu.vgic_v3); \
+ \
+ __get_host_hyp_vcpus(__vcpu, hyp_vcpup); \
+ })
+
static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
{
struct pkvm_hyp_vcpu *hyp_vcpu;
@@ -489,16 +501,63 @@ static void handle___vgic_v3_init_lrs(struct kvm_cpu_context *host_ctxt)
static void handle___vgic_v3_save_aprs(struct kvm_cpu_context *host_ctxt)
{
- DECLARE_REG(struct vgic_v3_cpu_if *, cpu_if, host_ctxt, 1);
+ struct pkvm_hyp_vcpu *hyp_vcpu;
+ struct kvm_vcpu *host_vcpu;
- __vgic_v3_save_aprs(kern_hyp_va(cpu_if));
+ host_vcpu = get_host_hyp_vcpus_from_vgic_v3_cpu_if(host_ctxt, 1,
+ &hyp_vcpu);
+ if (!host_vcpu)
+ return;
+
+ if (unlikely(hyp_vcpu)) {
+ struct vgic_v3_cpu_if *hyp_cpu_if, *host_cpu_if;
+ int i;
+
+ hyp_cpu_if = &hyp_vcpu->vcpu.arch.vgic_cpu.vgic_v3;
+ __vgic_v3_save_aprs(hyp_cpu_if);
+
+ host_cpu_if = &host_vcpu->arch.vgic_cpu.vgic_v3;
+ host_cpu_if->vgic_vmcr = hyp_cpu_if->vgic_vmcr;
+ for (i = 0; i < ARRAY_SIZE(host_cpu_if->vgic_ap0r); i++) {
+ host_cpu_if->vgic_ap0r[i] = hyp_cpu_if->vgic_ap0r[i];
+ host_cpu_if->vgic_ap1r[i] = hyp_cpu_if->vgic_ap1r[i];
+ }
+ } else {
+ __vgic_v3_save_aprs(&host_vcpu->arch.vgic_cpu.vgic_v3);
+ }
}
static void handle___vgic_v3_restore_vmcr_aprs(struct kvm_cpu_context *host_ctxt)
{
- DECLARE_REG(struct vgic_v3_cpu_if *, cpu_if, host_ctxt, 1);
+ struct pkvm_hyp_vcpu *hyp_vcpu;
+ struct kvm_vcpu *host_vcpu;
- __vgic_v3_restore_vmcr_aprs(kern_hyp_va(cpu_if));
+ host_vcpu = get_host_hyp_vcpus_from_vgic_v3_cpu_if(host_ctxt, 1,
+ &hyp_vcpu);
+ if (!host_vcpu)
+ return;
+
+ if (unlikely(hyp_vcpu)) {
+ struct vgic_v3_cpu_if *hyp_cpu_if, *host_cpu_if;
+ int i;
+
+ hyp_cpu_if = &hyp_vcpu->vcpu.arch.vgic_cpu.vgic_v3;
+ host_cpu_if = &host_vcpu->arch.vgic_cpu.vgic_v3;
+
+ hyp_cpu_if->vgic_vmcr = host_cpu_if->vgic_vmcr;
+ /* Should be a one-off */
+ hyp_cpu_if->vgic_sre = (ICC_SRE_EL1_DIB |
+ ICC_SRE_EL1_DFB |
+ ICC_SRE_EL1_SRE);
+ for (i = 0; i < ARRAY_SIZE(host_cpu_if->vgic_ap0r); i++) {
+ hyp_cpu_if->vgic_ap0r[i] = host_cpu_if->vgic_ap0r[i];
+ hyp_cpu_if->vgic_ap1r[i] = host_cpu_if->vgic_ap1r[i];
+ }
+
+ __vgic_v3_restore_vmcr_aprs(hyp_cpu_if);
+ } else {
+ __vgic_v3_restore_vmcr_aprs(&host_vcpu->arch.vgic_cpu.vgic_v3);
+ }
}
static void handle___pkvm_init(struct kvm_cpu_context *host_ctxt)
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH v1 11/11] KVM: arm64: Implement lazy vCPU state sync for non-protected guests
From: tabba @ 2026-06-12 6:59 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Will Deacon, Catalin Marinas, Quentin Perret,
Vincent Donnefort, Sebastian Ene, Per Larsen, Suzuki K Poulose,
Zenghui Yu, Joey Gouly, Steffen Eiden, Mark Rutland,
Jonathan Cameron, Hyunwoo Kim, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260612065925.755562-1-tabba@google.com>
pKVM copies a non-protected guest's register context between the host
and the hypervisor on every world switch, even when the host never
inspects it. Defer the copy: on entry, flush the host context into the
hyp vCPU only when the host marked it dirty (PKVM_HOST_STATE_DIRTY); on
exit, leave it in the hyp vCPU and copy it back only when the host needs
it, via a __pkvm_vcpu_sync_state hypercall on trap handling or at vcpu
put. A protected guest's context is copied as before, since lazy sync
only helps where the host is trusted to see the guest's registers.
The PC is the exception: it is copied back on every exit so the
kvm_exit tracepoint reports the guest's real exit PC rather than the
value left by the previous sync.
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kvm/arm.c | 7 +++
arch/arm64/kvm/handle_exit.c | 22 ++++++++
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 88 ++++++++++++++++++++++++++++--
5 files changed, 115 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 043495f7fc78..6e1135b3ded4 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -113,6 +113,7 @@ enum __kvm_host_smccc_func {
__KVM_HOST_SMCCC_FUNC___pkvm_finalize_teardown_vm,
__KVM_HOST_SMCCC_FUNC___pkvm_vcpu_load,
__KVM_HOST_SMCCC_FUNC___pkvm_vcpu_put,
+ __KVM_HOST_SMCCC_FUNC___pkvm_vcpu_sync_state,
__KVM_HOST_SMCCC_FUNC___pkvm_tlb_flush_vmid,
MARKER(__KVM_HOST_SMCCC_FUNC_MAX)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a49042bfa801..1ef660774adc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -1113,6 +1113,8 @@ struct kvm_vcpu_arch {
/* SError pending for nested guest */
#define NESTED_SERROR_PENDING __vcpu_single_flag(sflags, BIT(8))
+/* pKVM host vcpu state is dirty, needs resync (nVHE-only) */
+#define PKVM_HOST_STATE_DIRTY __vcpu_single_flag(iflags, BIT(4))
/* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
#define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) + \
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index c9f36932c980..a5c54e37778b 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -734,6 +734,10 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
if (is_protected_kvm_enabled()) {
kvm_call_hyp(__vgic_v3_save_aprs, &vcpu->arch.vgic_cpu.vgic_v3);
kvm_call_hyp_nvhe(__pkvm_vcpu_put);
+
+ /* __pkvm_vcpu_put implies a sync of the state */
+ if (!kvm_vm_is_protected(vcpu->kvm))
+ vcpu_set_flag(vcpu, PKVM_HOST_STATE_DIRTY);
}
kvm_vcpu_put_debug(vcpu);
@@ -961,6 +965,9 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
return ret;
if (is_protected_kvm_enabled()) {
+ /* Start with the vcpu in a dirty state */
+ if (!kvm_vm_is_protected(vcpu->kvm))
+ vcpu_set_flag(vcpu, PKVM_HOST_STATE_DIRTY);
ret = pkvm_create_hyp_vm(kvm);
if (ret)
return ret;
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 54aedf93c78b..dccc3786548b 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -422,6 +422,21 @@ static int handle_trap_exceptions(struct kvm_vcpu *vcpu)
{
int handled;
+ /*
+ * If we run a non-protected VM when protection is enabled
+ * system-wide, resync the state from the hypervisor and mark
+ * it as dirty on the host side if it wasn't dirty already
+ * (which could happen if preemption has taken place).
+ */
+ if (is_protected_kvm_enabled() && !kvm_vm_is_protected(vcpu->kvm)) {
+ preempt_disable();
+ if (!(vcpu_get_flag(vcpu, PKVM_HOST_STATE_DIRTY))) {
+ kvm_call_hyp_nvhe(__pkvm_vcpu_sync_state);
+ vcpu_set_flag(vcpu, PKVM_HOST_STATE_DIRTY);
+ }
+ preempt_enable();
+ }
+
/*
* See ARM ARM B1.14.1: "Hyp traps on instructions
* that fail their condition code check"
@@ -489,6 +504,13 @@ int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
/* For exit types that need handling before we can be preempted */
void handle_exit_early(struct kvm_vcpu *vcpu, int exception_index)
{
+ /*
+ * We just exited, so the state is clean from a hypervisor
+ * perspective.
+ */
+ if (is_protected_kvm_enabled())
+ vcpu_clear_flag(vcpu, PKVM_HOST_STATE_DIRTY);
+
if (ARM_SERROR_PENDING(exception_index)) {
if (this_cpu_has_cap(ARM64_HAS_RAS_EXTN)) {
u64 disr = kvm_vcpu_get_disr(vcpu);
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 23e644c24a03..02383b372258 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -139,6 +139,49 @@ static void sync_hyp_vgic_state(struct pkvm_hyp_vcpu *hyp_vcpu)
host_cpu_if->vgic_lr[i] = hyp_cpu_if->vgic_lr[i];
}
+
+static void __copy_vcpu_state(const struct kvm_vcpu *from_vcpu,
+ struct kvm_vcpu *to_vcpu)
+{
+ int i;
+
+ to_vcpu->arch.ctxt.regs = from_vcpu->arch.ctxt.regs;
+ to_vcpu->arch.ctxt.spsr_abt = from_vcpu->arch.ctxt.spsr_abt;
+ to_vcpu->arch.ctxt.spsr_und = from_vcpu->arch.ctxt.spsr_und;
+ to_vcpu->arch.ctxt.spsr_irq = from_vcpu->arch.ctxt.spsr_irq;
+ to_vcpu->arch.ctxt.spsr_fiq = from_vcpu->arch.ctxt.spsr_fiq;
+ to_vcpu->arch.ctxt.fp_regs = from_vcpu->arch.ctxt.fp_regs;
+
+ /*
+ * Copy the sysregs, but don't mess with the timer state which
+ * is directly handled by EL1 and is expected to be preserved.
+ * enum vcpu_sysreg is sparse: VNCR-mapped registers take values
+ * derived from their VNCR page offset, so the timer registers do
+ * not form a contiguous numeric range and must be skipped by name.
+ */
+ for (i = 1; i < NR_SYS_REGS; i++) {
+ switch (i) {
+ case CNTVOFF_EL2:
+ case CNTV_CVAL_EL0:
+ case CNTV_CTL_EL0:
+ case CNTP_CVAL_EL0:
+ case CNTP_CTL_EL0:
+ continue;
+ }
+ to_vcpu->arch.ctxt.sys_regs[i] = from_vcpu->arch.ctxt.sys_regs[i];
+ }
+}
+
+static void __sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
+{
+ __copy_vcpu_state(&hyp_vcpu->vcpu, hyp_vcpu->host_vcpu);
+}
+
+static void __flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
+{
+ __copy_vcpu_state(hyp_vcpu->host_vcpu, &hyp_vcpu->vcpu);
+}
+
static void flush_debug_state(struct pkvm_hyp_vcpu *hyp_vcpu)
{
struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu;
@@ -168,7 +211,17 @@ static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
fpsimd_sve_flush();
flush_debug_state(hyp_vcpu);
- hyp_vcpu->vcpu.arch.ctxt = host_vcpu->arch.ctxt;
+ /*
+ * If we deal with a non-protected guest and the state is potentially
+ * dirty (from a host perspective), copy the state back into the hyp
+ * vcpu.
+ */
+ if (!pkvm_hyp_vcpu_is_protected(hyp_vcpu)) {
+ if (vcpu_get_flag(host_vcpu, PKVM_HOST_STATE_DIRTY))
+ __flush_hyp_vcpu(hyp_vcpu);
+ } else {
+ hyp_vcpu->vcpu.arch.ctxt = host_vcpu->arch.ctxt;
+ }
hyp_vcpu->vcpu.arch.mdcr_el2 = host_vcpu->arch.mdcr_el2;
hyp_vcpu->vcpu.arch.hcr_el2 &= ~(HCR_TWI | HCR_TWE);
@@ -191,9 +244,11 @@ static void sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
fpsimd_sve_sync(&hyp_vcpu->vcpu);
sync_debug_state(hyp_vcpu);
- host_vcpu->arch.ctxt = hyp_vcpu->vcpu.arch.ctxt;
-
- host_vcpu->arch.hcr_el2 = hyp_vcpu->vcpu.arch.hcr_el2;
+ if (pkvm_hyp_vcpu_is_protected(hyp_vcpu))
+ host_vcpu->arch.ctxt = hyp_vcpu->vcpu.arch.ctxt;
+ else
+ /* Keep the PC current for the kvm_exit tracepoint (lazy ctxt sync). */
+ host_vcpu->arch.ctxt.regs.pc = hyp_vcpu->vcpu.arch.ctxt.regs.pc;
host_vcpu->arch.fault = hyp_vcpu->vcpu.arch.fault;
@@ -227,8 +282,30 @@ static void handle___pkvm_vcpu_put(struct kvm_cpu_context *host_ctxt)
{
struct pkvm_hyp_vcpu *hyp_vcpu = pkvm_get_loaded_hyp_vcpu();
- if (hyp_vcpu)
+ if (hyp_vcpu) {
+ struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu;
+
+ if (!pkvm_hyp_vcpu_is_protected(hyp_vcpu) &&
+ !vcpu_get_flag(host_vcpu, PKVM_HOST_STATE_DIRTY)) {
+ __sync_hyp_vcpu(hyp_vcpu);
+ }
+
pkvm_put_hyp_vcpu(hyp_vcpu);
+ }
+}
+
+static void handle___pkvm_vcpu_sync_state(struct kvm_cpu_context *host_ctxt)
+{
+ struct pkvm_hyp_vcpu *hyp_vcpu;
+
+ if (!is_protected_kvm_enabled())
+ return;
+
+ hyp_vcpu = pkvm_get_loaded_hyp_vcpu();
+ if (!hyp_vcpu || pkvm_hyp_vcpu_is_protected(hyp_vcpu))
+ return;
+
+ __sync_hyp_vcpu(hyp_vcpu);
}
static struct kvm_vcpu *__get_host_hyp_vcpus(struct kvm_vcpu *arg,
@@ -859,6 +936,7 @@ static const hcall_t host_hcall[] = {
HANDLE_FUNC(__pkvm_finalize_teardown_vm),
HANDLE_FUNC(__pkvm_vcpu_load),
HANDLE_FUNC(__pkvm_vcpu_put),
+ HANDLE_FUNC(__pkvm_vcpu_sync_state),
HANDLE_FUNC(__pkvm_tlb_flush_vmid),
};
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
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