* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Krzysztof Kozlowski @ 2026-03-30 11:01 UTC (permalink / raw)
To: Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <02927f87-fa91-457d-af2b-a7610ef481e8@aliel.fr>
On 30/03/2026 13:01, Ronald Claveau wrote:
> On 3/30/26 12:38 PM, Krzysztof Kozlowski wrote:
>> On 30/03/2026 12:21, Ronald Claveau wrote:
>>> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>>>
>>> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>>>
>>
>> Fixes commit?
>>
>
> Thanks for your review I will add a Fixes tag like that:
> Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power
> regulators")
>
>> Why there is no such change in recent next? Was it just merged?
>>
>
> Yes it is in next-20260327
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts?h=next-20260327&id=60eff75ac67bbf5445bdbd2842b0109ac591441c
Thanks, With fixes tag added:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260330110135.10316-1-khushalchitturi@gmail.com>
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v2 -> v3:
- Used generic node name "poweroff" instead of "gemini-poweroff".
v1 -> v2:
- Renamed the node from "power-controller" to "gemini-poweroff" to resolve dtschema warnings.
Note:
* This patch series is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
2 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..ef5e04f86be1
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ poweroff@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/2] dt-bindings: power: reset: cortina: Convert to DT schema and rename node
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema and update corresponding dtsi file with new node name
---
Khushal Chitturi (2):
dt-bindings: power: reset: cortina,gemini-power-controller: convert to
DT schema
ARM: dts: gemini: Rename power controller node to poweroff
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
3 files changed, 43 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
--
2.53.0
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Ronald Claveau @ 2026-03-30 11:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <36822ad1-c73d-4903-bd39-091874558f10@kernel.org>
On 3/30/26 12:38 PM, Krzysztof Kozlowski wrote:
> On 30/03/2026 12:21, Ronald Claveau wrote:
>> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>>
>> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>>
>
> Fixes commit?
>
Thanks for your review I will add a Fixes tag like that:
Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power
regulators")
> Why there is no such change in recent next? Was it just merged?
>
Yes it is in next-20260327
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts?h=next-20260327&id=60eff75ac67bbf5445bdbd2842b0109ac591441c
> Best regards,
> Krzysztof
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: André Draszik @ 2026-03-30 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <b66d7230-a495-40a4-ac75-378d0727afed@kernel.org>
On Mon, 2026-03-30 at 12:55 +0200, Krzysztof Kozlowski wrote:
> On 30/03/2026 12:52, André Draszik wrote:
> > > Your patchset is organized in odd way - first patch for me, then not for
> > > me, then again two patches for me. Please keep it consistent. Or better,
> > > decouple since there are no dependencies according to cover letter.
> >
> > I'll update the cover letter to describe the dependencies. 4 depends on 2,
>
>
> How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency?
4 updates the soc-level pmu binding of gs101 to have gs101-power-domain
child-nodes, which are introduced in 2
A.
^ permalink raw reply
* Re: [PATCH v13 34/48] arm64: RMI: support RSI_HOST_CALL
From: Suzuki K Poulose @ 2026-03-30 10:58 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Joey Gouly, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-35-steven.price@arm.com>
On 18/03/2026 15:53, Steven Price wrote:
> From: Joey Gouly <joey.gouly@arm.com>
>
> Forward RSI_HOST_CALLS to KVM's HVC handler.
Minor nit: Please could we add a line or two, explaining what
RSI_HOST_CALL is ? e.g.:
Realm's can talk to the hypervisor using the RSI_HOST_CALL, which
the RMM forwards to the KVM. Handle them as regular hypercalls.
Suzuki
>
> Signed-off-by: Joey Gouly <joey.gouly@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> ---
> Changes since v7:
> * Avoid turning a negative return from kvm_smccc_call_handler() into a
> error response to the guest. Instead propogate the error back to user
> space.
> Changes since v4:
> * Setting GPRS is now done by kvm_rec_enter() rather than
> rec_exit_host_call() (see previous patch - arm64: RME: Handle realm
> enter/exit). This fixes a bug where the registers set by user space
> were being ignored.
> ---
> arch/arm64/kvm/rmi-exit.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/kvm/rmi-exit.c b/arch/arm64/kvm/rmi-exit.c
> index b4843f094615..7eff6967530c 100644
> --- a/arch/arm64/kvm/rmi-exit.c
> +++ b/arch/arm64/kvm/rmi-exit.c
> @@ -116,6 +116,19 @@ static int rec_exit_ripas_change(struct kvm_vcpu *vcpu)
> return -EFAULT;
> }
>
> +static int rec_exit_host_call(struct kvm_vcpu *vcpu)
> +{
> + int i;
> + struct realm_rec *rec = &vcpu->arch.rec;
> +
> + vcpu->stat.hvc_exit_stat++;
> +
> + for (i = 0; i < REC_RUN_GPRS; i++)
> + vcpu_set_reg(vcpu, i, rec->run->exit.gprs[i]);
> +
> + return kvm_smccc_call_handler(vcpu);
> +}
> +
> static void update_arch_timer_irq_lines(struct kvm_vcpu *vcpu)
> {
> struct realm_rec *rec = &vcpu->arch.rec;
> @@ -183,6 +196,8 @@ int handle_rec_exit(struct kvm_vcpu *vcpu, int rec_run_ret)
> return rec_exit_psci(vcpu);
> case RMI_EXIT_RIPAS_CHANGE:
> return rec_exit_ripas_change(vcpu);
> + case RMI_EXIT_HOST_CALL:
> + return rec_exit_host_call(vcpu);
> }
Probably we should move the RMI_EXIT_HOST_CALL case addition in
kvm_rec_pre_enter() to this hunk to keep all in one place ?
Otherwise, looks good to me.
Suzuki
>
> kvm_pr_unimpl("Unsupported exit reason: %u\n",
^ permalink raw reply
* Re: [PATCH v8 07/10] pmdomain: samsung: add support for google,gs101-pd
From: André Draszik @ 2026-03-30 10:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <177409897341.266364.10743294916208405425.b4-review@b4>
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:52 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > On Google gs101, direct mmio register access to the PMU registers
> > doesn't work and access must happen via a regmap created by the PMU
> > driver instead.
> >
> > Add a flag to the device match data to denote this case, and obtain
> > the regmap using the parent node in DT if true, while keeping to use
> > the traditional direct mmio regmap otherwise.
> >
> > Additionally, the status is just one bit on gs101.
> >
> > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
>
> There are few reviews from Sashiko which seem legitimate. Please check
> them. If they are false positives, just reply that you carefully went
> through them.
Thanks for pointing out Sashiko, seems like a useful tool! I'll go
through it.
A.
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: Krzysztof Kozlowski @ 2026-03-30 10:55 UTC (permalink / raw)
To: André Draszik
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <6f0be0a71c74e7a7959e9ad02e93aff1cb8ef712.camel@linaro.org>
On 30/03/2026 12:52, André Draszik wrote:
>> Your patchset is organized in odd way - first patch for me, then not for
>> me, then again two patches for me. Please keep it consistent. Or better,
>> decouple since there are no dependencies according to cover letter.
>
> I'll update the cover letter to describe the dependencies. 4 depends on 2,
How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-30 10:54 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, linux-kernel, android-kvm
Cc: catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
sebastianene, suzuki.poulose, tabba, vdonnefort, will, yuzenghui
The ARM Service Calling Convention (SMCCC) specifies that the function
identifier and parameters should be passed in registers, leaving the
16-bit immediate field un-handled in pKVM when an SMC instruction is
trapped.
Since the HVC is a private interface between EL2 and the host,
enforce the host kernel running under pKVM to use an immediate value
of 0 only when using SMCs to make it clear for non-compliant software
talking to Trustzone that we only use SMCCC.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
v2 -> current:
- move the ESR decoding of the imm16 in the handle_host_smc where it
was supposed to be
- updated the commit message to include the reason behind while we are
not doing for HVCs as well
- updated the commit message to clarify that pKVM is not handling the
imm16
v1 -> v2:
- Dropped injecting an UNDEF and return an error instead
(SMCCC_RET_NOT_SUPPORTED)
- Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
- Updated the title of the commit message from:
"[PATCH] KVM: arm64: Inject UNDEF when host is executing an
smc with imm16 != 0"
Link to v2:
https://lore.kernel.org/all/20260325113138.4171430-1-sebastianene@google.com/
Link to v1:
https://lore.kernel.org/all/20260324135728.3532400-1-sebastianene@google.com/
---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index e7790097db93..461cf5cb5ac7 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -676,8 +676,14 @@ static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(u64, func_id, host_ctxt, 0);
+ u64 esr = read_sysreg_el2(SYS_ESR);
bool handled;
+ if (esr & ESR_ELx_xVC_IMM_MASK) {
+ cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
+ goto exit_skip_instr;
+ }
+
func_id &= ~ARM_SMCCC_CALL_HINTS;
handled = kvm_host_psci_handler(host_ctxt, func_id);
@@ -686,6 +692,7 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
if (!handled)
default_host_smc_handler(host_ctxt);
+exit_skip_instr:
/* SMC was trapped, move ELR past the current PC. */
kvm_skip_host_instr();
}
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-30 10:53 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <ebc6da60-d49f-4a44-9ecb-3ae70413a248@kernel.org>
On 30/03/2026 12:48, Krzysztof Kozlowski wrote:
> On 30/03/2026 12:44, Jian Hu wrote:
>>
>> On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>>>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>>>
>>>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
>>> Please run scripts/checkpatch.pl on the patches and fix reported
>>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>>> patches and (probably) fix more warnings. Some warnings can be ignored,
>>> especially from --strict run, but the code here looks like it needs a
>>> fix. Feel free to get in touch if the warning is not clear.
>>
>>
>> Thanks for your review.
>>
>>
>> This series is based on the clk-next branch (version v7.0-rc1).
>>
>>
>> Here are the check results without --strict:
>>
>
> I checked before. Now I double checked:
>
> b4 shazam...
> git format-patch -3
> scripts/checkpatch.pl 0*
>
> Clearly a warning, also on v7.0-rc1.
>
> So maybe you don't do it on the kernel you are claiming or just doing it
> on different code than you sent.
>
It looks like it is b4 shazam problem which duplicates the Fixes tag. I
don't quite get why the tag is duplicated. I don't see anything on the
lists which would add wrong tag.
Well, that will be problem when applying, but nothing to be fixed here, so:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 05/10] pmdomain: samsung: convert to using regmap
From: André Draszik @ 2026-03-30 10:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <177409897341.266364.2957933304869869135.b4-review@b4>
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:50 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > diff --git a/drivers/pmdomain/samsung/exynos-pm-domains.c b/drivers/pmdomain/samsung/exynos-pm-domains.c
> > index 5c3aa8983087..68b1e7ba8729 100644
> > --- a/drivers/pmdomain/samsung/exynos-pm-domains.c
> > +++ b/drivers/pmdomain/samsung/exynos-pm-domains.c
> > @@ -120,9 +140,26 @@ static int exynos_pd_probe(struct platform_device *pdev)
> > [ ... skip 20 lines ... ]
> > +
> > + reg_config.max_register = resource_size(res) - reg_config.reg_stride;
> > + pd->regmap = devm_regmap_init_mmio(dev, base, ®_config);
> > + if (IS_ERR(pd->regmap))
> > + return dev_err_probe(dev, PTR_ERR(base),
> > + "failed to init regmap\n");
>
> PTR_ERR(pd->regmap)
Thanks!
A.
^ permalink raw reply
* Re: [PATCH v13 32/48] arm64: Don't expose stolen time for realm guests
From: Suzuki K Poulose @ 2026-03-30 10:52 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-33-steven.price@arm.com>
On 18/03/2026 15:53, Steven Price wrote:
> It doesn't make much sense as a realm guest wouldn't want to trust the
> host. It will also need some extra work to ensure that KVM will only
> attempt to write into a shared memory region. So for now just disable
> it.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v7:
> * Update the documentation to add a note about stolen time being
> unavailable in a realm.
> ---
> Documentation/virt/kvm/api.rst | 3 +++
> arch/arm64/kvm/arm.c | 5 ++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index bc180c853faf..70911fe6d435 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -9240,6 +9240,9 @@ is supported, than the other should as well and vice versa. For arm64
> see Documentation/virt/kvm/devices/vcpu.rst "KVM_ARM_VCPU_PVTIME_CTRL".
> For x86 see Documentation/virt/kvm/x86/msr.rst "MSR_KVM_STEAL_TIME".
>
> +Note that steal time accounting is not available when a guest is running
> +within a Arm CCA realm (machine type KVM_VM_TYPE_ARM_REALM).
> +
> 8.25 KVM_CAP_S390_DIAG318
> -------------------------
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 61182eb0cf70..7d92ddb06460 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -469,7 +469,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> r = system_supports_mte();
> break;
> case KVM_CAP_STEAL_TIME:
> - r = kvm_arm_pvtime_supported();
> + if (kvm_is_realm(kvm))
> + r = 0;
> + else
> + r = kvm_arm_pvtime_supported();
Could this be handled in kvm_realm_ext_allowed() ?
Suzuki
> break;
> case KVM_CAP_ARM_EL1_32BIT:
> r = cpus_have_final_cap(ARM64_HAS_32BIT_EL1);
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: André Draszik @ 2026-03-30 10:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <177409897339.266364.69715997034739052.b4-review@b4>
Hi Krzysztof,
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:47 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > diff --git a/Documentation/devicetree/bindings/power/pd-samsung.yaml b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > index 9c2c51133457..3f1a2dc17862 100644
> > --- a/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > +++ b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > @@ -44,11 +45,28 @@ properties:
> > power-domains:
> > maxItems: 1
> >
> > + samsung,dtzpc:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Distributed TrustZone Protection Control (DTZPC) node.
>
> For what purpose?
It is part of the domain.
Furthermore, TZ configuration is lost as part of power-domain power
cycle, so this allows a driver to take necessary actions (inform the
EL3 firmware). I believe this handle to be similar to e.g. the existing
samsung,sysreg
> Your patchset is organized in odd way - first patch for me, then not for
> me, then again two patches for me. Please keep it consistent. Or better,
> decouple since there are no dependencies according to cover letter.
I'll update the cover letter to describe the dependencies. 4 depends on 2,
and 2 depends on 1, hence the ordering.
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH v13 31/48] KVM: arm64: WARN on injected undef exceptions
From: Suzuki K Poulose @ 2026-03-30 10:50 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-32-steven.price@arm.com>
On 18/03/2026 15:53, Steven Price wrote:
> The RMM doesn't allow injection of a undefined exception into a realm
> guest. Add a WARN to catch if this ever happens.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Changes since v6:
> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
> ---
> arch/arm64/kvm/inject_fault.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index 6492397b73d7..613f223bc7a3 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
> */
> void kvm_inject_undefined(struct kvm_vcpu *vcpu)
> {
> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
> if (vcpu_el1_is_32bit(vcpu))
> inject_undef32(vcpu);
> else
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-30 10:48 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <9830ff89-a145-41d1-98e9-1412f497d3f2@amlogic.com>
On 30/03/2026 12:44, Jian Hu wrote:
>
> On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>>
>>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
>> Please run scripts/checkpatch.pl on the patches and fix reported
>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>> patches and (probably) fix more warnings. Some warnings can be ignored,
>> especially from --strict run, but the code here looks like it needs a
>> fix. Feel free to get in touch if the warning is not clear.
>
>
> Thanks for your review.
>
>
> This series is based on the clk-next branch (version v7.0-rc1).
>
>
> Here are the check results without --strict:
>
I checked before. Now I double checked:
b4 shazam...
git format-patch -3
scripts/checkpatch.pl 0*
Clearly a warning, also on v7.0-rc1.
So maybe you don't do it on the kernel you are claiming or just doing it
on different code than you sent.
Especially the second case would be a waste of my time to investigate
and read this patch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] iommu/arm-smmu-v3: Add basic debugfs framework
From: Nicolin Chen @ 2026-03-30 10:46 UTC (permalink / raw)
To: Qinxin Xia
Cc: robin.murphy, will, jpb, linux-arm-kernel, iommu, wangzhou1,
prime.zeng, fanghao11, jonathan.cameron, wuyifan50, linuxarm
In-Reply-To: <20260328101706.3448655-2-xiaqinxin@huawei.com>
On Sat, Mar 28, 2026 at 06:17:02PM +0800, Qinxin Xia wrote:
> Add basic debugfs framework for ARM SMMUv3 driver.This creates the
Needs a space after "."
> +static int smmu_debugfs_capabilities_show(struct seq_file *seq, void *unused)
> +{
> + struct arm_smmu_device *smmu = seq->private;
> +
> + if (!smmu) {
> + seq_puts(seq, "SMMU not available\n");
> + return 0;
> + }
> +
> + seq_puts(seq, "SMMUv3 Capabilities:\n");
> + seq_printf(seq, " Stage1 Translation: %s\n",
> + smmu->features & ARM_SMMU_FEAT_TRANS_S1 ? "Yes" : "No");
> + seq_printf(seq, " Stage2 Translation: %s\n",
> + smmu->features & ARM_SMMU_FEAT_TRANS_S2 ? "Yes" : "No");
> + seq_printf(seq, " Coherent Walk: %s\n",
> + smmu->features & ARM_SMMU_FEAT_COHERENCY ? "Yes" : "No");
> + seq_printf(seq, " ATS Support: %s\n",
> + smmu->features & ARM_SMMU_FEAT_ATS ? "Yes" : "No");
> + seq_printf(seq, " PRI Support: %s\n",
> + smmu->features & ARM_SMMU_FEAT_PRI ? "Yes" : "No");
> + seq_printf(seq, " Stream Table Size: %d\n", 1 << smmu->sid_bits);
> + seq_printf(seq, " Command Queue Depth: %d\n",
> + 1 << smmu->cmdq.q.llq.max_n_shift);
> + seq_printf(seq, " Event Queue Depth: %d\n",
> + 1 << smmu->evtq.q.llq.max_n_shift);
Nit: should we do all sizes or all depths? Any good reason to mix
them here?
> +/**
> + * arm_smmu_debugfs_remove() - Clean up debugfs entries for an SMMU device
> + * @smmu: SMMU device
> + *
> + * This function removes the debugfs directories created by setup.
> + */
> +void arm_smmu_debugfs_remove(struct arm_smmu_device *smmu)
> +{
> + struct arm_smmu_debugfs *debugfs;
> +
> + scoped_guard(mutex, &arm_smmu_debugfs_lock) {
It could be just normal guard().
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 4d00d796f078..cbb3fccc501b 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4904,6 +4904,15 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> /* Check for RMRs and install bypass STEs if any */
> arm_smmu_rmr_install_bypass_ste(smmu);
>
> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
> + char name[32];
This could be moved to the top, as iommu_device_sysfs_add() can use
it, whether CONFIG_ARM_SMMU_V3_DEBUGFS=y or =n.
> + snprintf(name, sizeof(name), "smmu3.%pa", &ioaddr);
And this could be moved after ioaddr gets a copy from res->start.
>
> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
> +struct arm_smmu_debugfs {
> + struct dentry *smmu_dir;
A personal preference: for new structures, maybe drop those tabs?
> /* An SMMUv3 instance */
> struct arm_smmu_device {
> struct device *dev;
> @@ -803,6 +813,11 @@ struct arm_smmu_device {
>
> struct rb_root streams;
> struct mutex streams_mutex;
> +
> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
> + /* DebugFS Info */
Doesn't seem very useful. I'd drop it.
> + struct arm_smmu_debugfs *debugfs;
> +#endif
Nicolin
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Jian Hu @ 2026-03-30 10:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <20260327-rough-spry-hyrax-8236de@quoll>
On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>
>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
Thanks for your review.
This series is based on the clk-next branch (version v7.0-rc1).
Here are the check results without --strict:
$ ./scripts/checkpatch.pl
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch
total: 0 errors, 0 warnings, 8 lines checked
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch
total: 0 errors, 0 warnings, 46 lines checked
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch
total: 0 errors, 0 warnings, 149 lines checked
Here are the check results with --strict (I had also checked them with
this script before submitting these patches):
$ ./scripts/checkpatch.pl --strict
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch
total: 0 errors, 0 warnings, 0 checks, 8 lines checked
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl --strict
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch
total: 0 errors, 0 warnings, 0 checks, 46 lines checked
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl --strict
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch
total: 0 errors, 0 warnings, 0 checks, 149 lines checked
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch has no
obvious style problems and is ready for submission.
I have also run the script on the latest v7.0-rc5, and no warnings are
reported.
Could you tell me which version of the checkpatch script you are using?
If you are using a locally modified script, kindly let me know which
warnings I need to fix.
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Krzysztof Kozlowski @ 2026-03-30 10:38 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot
In-Reply-To: <20260330-fix-invalid-property-v1-1-e829c4d806cb@aliel.fr>
On 30/03/2026 12:21, Ronald Claveau wrote:
> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>
> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>
Fixes commit?
Why there is no such change in recent next? Was it just merged?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v13 30/48] KVM: arm64: Handle Realm PSCI requests
From: Suzuki K Poulose @ 2026-03-30 10:36 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-31-steven.price@arm.com>
On 18/03/2026 15:53, Steven Price wrote:
> The RMM needs to be informed of the target REC when a PSCI call is made
> with an MPIDR argument. Expose an ioctl to the userspace in case the PSCI
> is handled by it.
>
> [NOTE: A future version of the RMM specification is likely to remove the
> need for this ioctl.]
This will need to stay for the PSCI_CPU_ON case, where the host has to
acknowledge the onlining of a vCPU.
>
> Co-developed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
For the record, we can drop the UAPI following our discussions and
implicitly do the PSCI complete before REC_ENTER, similar to what
we do for the SET_RIPAS request. The VMM/KVM can treat the case
as a normal PSCI_CPU_ON request and return the result as in normal
VMs.
The target REC may ENTER before we complete the reporting, but we can
handle this error case (RMI_ERROR_REC) and return -EAGAIN to the
userspace.
Suzuki
> ---
> Changes since v12:
> * Chance return code for non-realms to -ENXIO to better represent that
> the ioctl is invalid for non-realms (checkpatch is insistent that
> "ENOSYS means 'invalid syscall nr' and nothing else").
> Changes since v11:
> * RMM->RMI renaming.
> Changes since v6:
> * Use vcpu_is_rec() rather than kvm_is_realm(vcpu->kvm).
> * Minor renaming/formatting fixes.
> ---
> arch/arm64/include/asm/kvm_rmi.h | 3 +++
> arch/arm64/kvm/arm.c | 25 +++++++++++++++++++++++++
> arch/arm64/kvm/psci.c | 30 ++++++++++++++++++++++++++++++
> arch/arm64/kvm/rmi.c | 14 ++++++++++++++
> 4 files changed, 72 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
> index 38208be3c602..1ee5ed0f5ab2 100644
> --- a/arch/arm64/include/asm/kvm_rmi.h
> +++ b/arch/arm64/include/asm/kvm_rmi.h
> @@ -117,6 +117,9 @@ int realm_map_non_secure(struct realm *realm,
> unsigned long size,
> enum kvm_pgtable_prot prot,
> struct kvm_mmu_memory_cache *memcache);
> +int realm_psci_complete(struct kvm_vcpu *source,
> + struct kvm_vcpu *target,
> + unsigned long status);
>
> static inline bool kvm_realm_is_private_address(struct realm *realm,
> unsigned long addr)
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 304fb1f2b3ff..61182eb0cf70 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1846,6 +1846,22 @@ static int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> return __kvm_arm_vcpu_set_events(vcpu, events);
> }
>
> +static int kvm_arm_vcpu_rmi_psci_complete(struct kvm_vcpu *vcpu,
> + struct kvm_arm_rmi_psci_complete *arg)
> +{
> + struct kvm_vcpu *target = kvm_mpidr_to_vcpu(vcpu->kvm, arg->target_mpidr);
> +
> + if (!target)
> + return -EINVAL;
> +
> + /*
> + * RMM v1.0 only supports PSCI_RET_SUCCESS or PSCI_RET_DENIED
> + * for the status. But, let us leave it to the RMM to filter
> + * for making this future proof.
> + */
> + return realm_psci_complete(vcpu, target, arg->psci_status);
> +}
> +
> long kvm_arch_vcpu_ioctl(struct file *filp,
> unsigned int ioctl, unsigned long arg)
> {
> @@ -1974,6 +1990,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>
> return kvm_arm_vcpu_finalize(vcpu, what);
> }
> + case KVM_ARM_VCPU_RMI_PSCI_COMPLETE: {
> + struct kvm_arm_rmi_psci_complete req;
> +
> + if (!vcpu_is_rec(vcpu))
> + return -ENXIO;
> + if (copy_from_user(&req, argp, sizeof(req)))
> + return -EFAULT;
> + return kvm_arm_vcpu_rmi_psci_complete(vcpu, &req);
> + }
> default:
> r = -EINVAL;
> }
> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index 3b5dbe9a0a0e..a68f3c1878a5 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -103,6 +103,12 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>
> reset_state->reset = true;
> kvm_make_request(KVM_REQ_VCPU_RESET, vcpu);
> + /*
> + * Make sure we issue PSCI_COMPLETE before the VCPU can be
> + * scheduled.
> + */
> + if (vcpu_is_rec(vcpu))
> + realm_psci_complete(source_vcpu, vcpu, PSCI_RET_SUCCESS);
>
> /*
> * Make sure the reset request is observed if the RUNNABLE mp_state is
> @@ -115,6 +121,11 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>
> out_unlock:
> spin_unlock(&vcpu->arch.mp_state_lock);
> + if (vcpu_is_rec(vcpu) && ret != PSCI_RET_SUCCESS) {
> + realm_psci_complete(source_vcpu, vcpu,
> + ret == PSCI_RET_ALREADY_ON ?
> + PSCI_RET_SUCCESS : PSCI_RET_DENIED);
> + }
> return ret;
> }
>
> @@ -142,6 +153,25 @@ static unsigned long kvm_psci_vcpu_affinity_info(struct kvm_vcpu *vcpu)
> /* Ignore other bits of target affinity */
> target_affinity &= target_affinity_mask;
>
> + if (vcpu_is_rec(vcpu)) {
> + struct kvm_vcpu *target_vcpu;
> +
> + /* RMM supports only zero affinity level */
> + if (lowest_affinity_level != 0)
> + return PSCI_RET_INVALID_PARAMS;
> +
> + target_vcpu = kvm_mpidr_to_vcpu(kvm, target_affinity);
> + if (!target_vcpu)
> + return PSCI_RET_INVALID_PARAMS;
> +
> + /*
> + * Provide the references of the source and target RECs to the
> + * RMM so that the RMM can complete the PSCI request.
> + */
> + realm_psci_complete(vcpu, target_vcpu, PSCI_RET_SUCCESS);
> + return PSCI_RET_SUCCESS;
> + }
> +
> /*
> * If one or more VCPU matching target affinity are running
> * then ON else OFF
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 30292814b1ec..e56c8af2ad61 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -353,6 +353,20 @@ static void free_rtt(phys_addr_t phys)
> kvm_account_pgtable_pages(phys_to_virt(phys), -1);
> }
>
> +int realm_psci_complete(struct kvm_vcpu *source, struct kvm_vcpu *target,
> + unsigned long status)
> +{
> + int ret;
> +
> + ret = rmi_psci_complete(virt_to_phys(source->arch.rec.rec_page),
> + virt_to_phys(target->arch.rec.rec_page),
> + status);
> + if (ret)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static int realm_rtt_create(struct realm *realm,
> unsigned long addr,
> int level,
^ permalink raw reply
* [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Ronald Claveau @ 2026-03-30 10:21 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Ronald Claveau
Fix introduced invalid property for Khadas VIM4 sdcard regulator.
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603290828.5gt393t6-lkp@intel.com/
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 11bfbc99191b6..003b3bcdaf2bc 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -65,7 +65,6 @@ sd_3v3: regulator-sdcard-3v3 {
vin-supply = <&vddao_3v3>;
gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
regulator-boot-on;
- enable-active-low;
regulator-always-on;
};
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260330-fix-invalid-property-bbe54d933f71
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply related
* Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Manivannan Sadhasivam @ 2026-03-30 10:18 UTC (permalink / raw)
To: Hongxing Zhu
Cc: Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Qiang Yu
In-Reply-To: <AS8PR04MB8833AE3B8D106CE446EF89E58C52A@AS8PR04MB8833.eurprd04.prod.outlook.com>
On Mon, Mar 30, 2026 at 09:02:57AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Manivannan Sadhasivam <mani@kernel.org>
> > Sent: 2026年3月30日 15:23
> > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de; lpieralisi@kernel.org;
> > kwilczynski@kernel.org; robh@kernel.org; bhelgaas@google.com;
> > s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> > linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > imx@lists.linux.dev; linux-kernel@vger.kernel.org; stable@vger.kernel.org;
> > Qiang Yu <qiang.yu@oss.qualcomm.com>
> > Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> > i.MX7D/i.MX8M
> >
> > + Qiang
> >
> > On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > > The MSI trigger mechanism for endpoint devices connected to i.MX7D,
> > > i.MX8MM, and i.MX8MQ PCIe root complex ports depends on the MSI
> > > capability register settings in the root complex. Removing the MSI
> > > capability breaks MSI functionality for these endpoints.
> > >
> >
> > What is the relation between Root Port MSI and endpoint MSI? Endpoint MSIs
> > should be routed to the platform MSI controller (DWC i.MSI-RX or External like
> > GIC-ITS) independent of the Root Port MSI state.
> Hi Mani:
> Thank for your kindly concern.
> The MSI controller (DWC i.MSI-RX) on i.MX7D, i.MX8MM, and i.MX8MQ platforms
> requires the RC's MSI capability to remain enabled. Removing it breaks MSI
> routing from endpoints to the platform MSI controller.
>
I understand that MSI is broken on your hardware, but I was trying to understand
'why' specifically. Because, Root Port MSI capability doesn't have anything to
do with the endpoint MSIs. And since you mentioned that this issue happens only
on one platform, could be that the hardware designers have mistakenly wired the
Root Port's 'MSI Enable' to iMSI-RX's enable signal or something similar?
If so, we can introduce a flag 'dw_pcie_rp::keep_rp_msi_en' or something
similar, set it for affected SoCs and skip the capability removal in
pcie-designware-host.c
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v5 6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
From: Ronald Claveau @ 2026-03-30 10:18 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Johannes Berg, van Spriel
In-Reply-To: <416d42a6-8d99-421c-91aa-e705f23576e2@linaro.org>
On 3/30/26 9:55 AM, Neil Armstrong wrote:
> On 3/26/26 10:59, Ronald Claveau wrote:
>> Add voltage regulator nodes describing the VIM4 power tree,
>> required by peripheral nodes such as the SD card controller.
>>
>> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 ++++++++++++
>> ++++++++++
>> 1 file changed, 90 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-
>> vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
>> index fffdab96b12eb..2450084d37642 100644
>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
>> @@ -6,6 +6,8 @@
>> /dts-v1/;
>> #include "amlogic-t7.dtsi"
>> +#include <dt-bindings/gpio/amlogic,t7-periphs-pinctrl.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> / {
>> model = "Khadas vim4";
>> @@ -45,6 +47,94 @@ xtal: xtal-clk {
>> #clock-cells = <0>;
>> };
>> + dc_in: regulator-dc-in {
>> + compatible = "regulator-fixed";
>> + regulator-name = "DC_IN";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + regulator-always-on;
>> + };
>> +
>> + sd_3v3: regulator-sdcard-3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "SD_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + vin-supply = <&vddao_3v3>;
>> + gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
>> + regulator-boot-on;
>
>> + enable-active-low;
>
> This properly is invalid, please send follow up patch removing this,
>
> Thanks,
> Neil
>
> <snip>
Sure. I am on it.
Thanks,
--
Best regards,
Ronald
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 10:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFrK3NLwaii-9FEmyaTzUAuVkMkLL3rWBQwQvT-M+PzEHA@mail.gmail.com>
On 30/03/2026 12:13, Ulf Hansson wrote:
> On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 23/03/2026 12:13, Ulf Hansson wrote:
>>> Hi Krzysztof,
>>>
>>> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>
>>>>
>>>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
>>>>> This series adds support for the power domains on Google GS101.
>>>>>
>>>>> There are a few differences compared to SoCs already supported by this
>>>>> driver:
>>>>> * register access does not work via plain ioremap() / readl() /
>>>>> writel().
>>>>> Instead, the regmap created by the PMU driver must be used (which
>>>>> uses Arm SMCC calls under the hood).
>>>>> * DTZPC: a call needs to be made before and after power domain off/on,
>>>>> to inform the EL3 firmware of the request.
>>>>> * power domains can and are fed by a regulator rail and therefore
>>>>> regulator control needed be implemented.
>>>>>
>>>>> [...]
>>>>
>>>> Applied, thanks!
>>>>
>>>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
>>>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
>>>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
>>>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
>>>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
>>>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
>>>>
>>>> Best regards,
>>>
>>> Usually I pick up the power-domain related changes for the DT bindings
>>> and host them via an immutable branch called "dt". If needed, SOC
>>> maintainers can pull it to apply/test the corresponding DTS changes.
>>>
>>> That said, I am open to whatever you think is best here. Perhaps it's
>>> easier if you can drop the DT patches and provide your acks instead or
>>> if you can share them via an immutable branch for me to pull?
>>
>>
>> I did not pick up any pmdomain binding patches. I picked up only soc and
>> according to cover letter there are no dependencies between anything here.
>
> As I understand it, they are all related and some even depend on each
I raised exactly that questions but no answers.
> other. I think keeping all four DT patches together makes sense.
Why? What is the dependency?
>
> Although, as I said, if you think it's best to funnel them through
> your tree, please do and then share them via an immutable branch, so I
> can apply the pmdomain driver changes.
soc must go via my tree, but there is no reason to take the pmdomain
binding patch. So I did not take.
But anyway, I just noticed that I dropped everything: this introduces
new warnings which were nowhere addressed or explained. So regardless
how this should go, please do not apply anything - it's broken and
author is silent.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 10:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <1fbf5c54-8793-4585-be33-ded77019adb2@kernel.org>
On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 23/03/2026 12:13, Ulf Hansson wrote:
> > Hi Krzysztof,
> >
> > On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >>
> >> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> >>> This series adds support for the power domains on Google GS101.
> >>>
> >>> There are a few differences compared to SoCs already supported by this
> >>> driver:
> >>> * register access does not work via plain ioremap() / readl() /
> >>> writel().
> >>> Instead, the regmap created by the PMU driver must be used (which
> >>> uses Arm SMCC calls under the hood).
> >>> * DTZPC: a call needs to be made before and after power domain off/on,
> >>> to inform the EL3 firmware of the request.
> >>> * power domains can and are fed by a regulator rail and therefore
> >>> regulator control needed be implemented.
> >>>
> >>> [...]
> >>
> >> Applied, thanks!
> >>
> >> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
> >> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
> >> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
> >> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
> >> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
> >> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
> >>
> >> Best regards,
> >
> > Usually I pick up the power-domain related changes for the DT bindings
> > and host them via an immutable branch called "dt". If needed, SOC
> > maintainers can pull it to apply/test the corresponding DTS changes.
> >
> > That said, I am open to whatever you think is best here. Perhaps it's
> > easier if you can drop the DT patches and provide your acks instead or
> > if you can share them via an immutable branch for me to pull?
>
>
> I did not pick up any pmdomain binding patches. I picked up only soc and
> according to cover letter there are no dependencies between anything here.
As I understand it, they are all related and some even depend on each
other. I think keeping all four DT patches together makes sense.
Although, as I said, if you think it's best to funnel them through
your tree, please do and then share them via an immutable branch, so I
can apply the pmdomain driver changes.
Kind regards
Uffe
^ permalink raw reply
* [PATCH 1/2] crypto: atmel-ecc - add support for atecc608b
From: Thorsten Blum @ 2026-03-30 10:08 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Tested on hardware with an ATECC608B at 0x60. The device binds
successfully, passes the driver's sanity check, and registers the
ecdh-nist-p256 KPP algorithm.
The hardware ECDH path was also exercised using a minimal KPP test
module, covering private key generation, public key derivation, and
shared secret computation.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index b6a77c8d439c..5793e0c44113 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -371,6 +371,8 @@ static void atmel_ecc_remove(struct i2c_client *client)
static const struct of_device_id atmel_ecc_dt_ids[] = {
{
.compatible = "atmel,atecc508a",
+ }, {
+ .compatible = "atmel,atecc608b",
}, {
/* sentinel */
}
@@ -380,6 +382,7 @@ MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
static const struct i2c_device_id atmel_ecc_id[] = {
{ "atecc508a" },
+ { "atecc608b" },
{ }
};
MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
^ 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