* [PATCH v2 1/5] media: v4l2: Add callback for show_fdinfo
From: Detlev Casanova @ 2026-06-17 18:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
Detlev Casanova, linux-arm-kernel
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-0-d298e98ce06a@collabora.com>
Allow v4l2 drivers to add information in the fdinfo file matching the
opened /dev/videoX file.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
drivers/media/v4l2-core/v4l2-dev.c | 10 ++++++++++
include/media/v4l2-dev.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
index 6ce623a1245a..3878fa2ff73e 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -481,6 +481,15 @@ static int v4l2_release(struct inode *inode, struct file *filp)
return ret;
}
+/* Override for the show_fdinfo function */
+static void v4l2_show_fdinfo(struct seq_file *m, struct file *filp)
+{
+ struct video_device *vdev = video_devdata(filp);
+
+ if (vdev->fops->show_fdinfo)
+ vdev->fops->show_fdinfo(m, filp);
+}
+
static const struct file_operations v4l2_fops = {
.owner = THIS_MODULE,
.read = v4l2_read,
@@ -494,6 +503,7 @@ static const struct file_operations v4l2_fops = {
#endif
.release = v4l2_release,
.poll = v4l2_poll,
+ .show_fdinfo = v4l2_show_fdinfo,
};
/**
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 2e0f6d2e6a78..1635ab186f21 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -212,6 +212,7 @@ struct v4l2_file_operations {
int (*mmap) (struct file *, struct vm_area_struct *);
int (*open) (struct file *);
int (*release) (struct file *);
+ void (*show_fdinfo)(struct seq_file *, struct file *);
};
/*
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Stefan Dösinger @ 2026-06-17 17:47 UTC (permalink / raw)
To: Conor Dooley
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617-tabasco-pulsate-454ed3f8f0b6@spud>
[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]
Am Mittwoch, 17. Juni 2026, 19:08:02 Ostafrikanische Zeit schrieb Conor
Dooley:
> On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
> > +F: Documentation/devicetree/zte,zx297520v3-*
>
> Sashiko complaint here looks valid.
Yes, it is valid.
It also brought up another concern in patch 12 that has an impact on this
binding:
Am Dienstag, 16. Juni 2026, 23:42:19 Ostafrikanische Zeit schrieb sashiko-
bot@kernel.org:
> issue(s) to consider: - [Low] The `syscon-reboot` node is incorrectly
> defined at the root level using the explicitly deprecated `regmap`
> property. --
And indeed "regmap" is deprecated and I missed it somehow. As far as I
understand, to put syscon-reboot as a child of the clock, I need to add the
simple-mfd .compatible:
Either
topclk: clock-controller@13b000 {
compatible = "zte,zx297520v3-topclk", "syscon", "simple-mfd";
reg = <0x0013b000 0x400>;
...
syscon-reboot {
compatible = "syscon-reboot";
regmap = <&topclk>;
offset = <0x0>;
mask = <0x1>;
};
};
--- or ---
something@13b000 {
compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
reg = <0x0013b000 0x400>;
ranges;
topclk: clock-controller@0 {
compatible = "zte,zx297520v3-topclk";
...
}
syscon-reboot {
compatible = "syscon-reboot";
offset = <0x0>;
mask = <0x1>;
};
};
I see both ways in existing DTS files (e.g. imx6sl.dtsi for the fomer,
uniphier-pro4.dtsi for the latter). Is there a preferred way? I have a mild
preference for the first, as it would keep all 3 clocks in the same way. If I
go for the second, the clock driver would have to query its own node and the
parent node for the regmap.
AFAIU unrelated to syscon-reboot option 2 would give me the opportunity to
have separate clock and reset nodes and bindings and skip the aux bus, but
this would not be a correct representation of how the hardware works.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add Fuad Tabba as a reviewer
From: Marc Zyngier @ 2026-06-17 17:43 UTC (permalink / raw)
To: Oliver Upton, Fuad Tabba
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, kvmarm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617131237.2842619-1-tabba@google.com>
On Wed, 17 Jun 2026 14:12:36 +0100, Fuad Tabba wrote:
> I have been working on KVM/arm64 for a couple of years, mostly on
> pKVM, and am currently upstreaming protected guest support, with more
> to come later. I already review KVM/arm64 patches more broadly, and
> am happy to continue doing so in an official capacity.
>
> Add myself to the KVM/arm64 reviewer list.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Add Fuad Tabba as a reviewer
commit: fcda30b134d262a1b1826555352bd7349051486e
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add Fuad Tabba as a reviewer
From: Marc Zyngier @ 2026-06-17 17:42 UTC (permalink / raw)
To: Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, kvmarm, linux-arm-kernel,
linux-kernel
In-Reply-To: <ajLZXw3m4QGaYeTa@kernel.org>
On Wed, 17 Jun 2026 18:29:03 +0100,
Oliver Upton <oupton@kernel.org> wrote:
>
> On Wed, Jun 17, 2026 at 02:12:36PM +0100, Fuad Tabba wrote:
> > I have been working on KVM/arm64 for a couple of years, mostly on
> > pKVM, and am currently upstreaming protected guest support, with more
> > to come later. I already review KVM/arm64 patches more broadly, and
> > am happy to continue doing so in an official capacity.
> >
> > Add myself to the KVM/arm64 reviewer list.
> >
> > Signed-off-by: Fuad Tabba <tabba@google.com>
>
> Welcome to the party! Marc, I'm guessing you'll take this as a fix so
> Fuad can suffer through reviews ASAP :)
Yup. Though it doesn't apply to the current kvmarm/fixes tree, as it
is missing Steffen who has been in the same boat since 7.1-rc4! I've
fixed that.
>
> Acked-by: Oliver Upton <oupton@kernel.org>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Bjorn Andersson @ 2026-06-17 17:41 UTC (permalink / raw)
To: Ayushi Makhija
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260409122110.214680-1-ayushi.makhija@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 05:51:09PM +0530, Ayushi Makhija wrote:
Here's a link to "v1":
https://lore.kernel.org/all/20260323102229.1546504-1-quic_amakhija@quicinc.com/
Which makes this v2.
You also ignored my feedback.
Thank you,
Bjorn
> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
>
> Fixes: 4fca6849864d ("drm/panel: Add Novatek NT37801 panel driver")
> Signed-off-by: Ayushi Makhija <ayushi.makhija@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> index 3837f6785320..6ba4e69bf377 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
>
> vreg_l12b_1p8: ldo12 {
> regulator-name = "vreg_l12b_1p8";
> - regulator-min-microvolt = <1200000>;
> + regulator-min-microvolt = <1650000>;
> regulator-max-microvolt = <1800000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> regulator-allow-set-load;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Marc Zyngier @ 2026-06-17 17:36 UTC (permalink / raw)
To: Oliver Upton, kvmarm, linux-arm-kernel, Fuad Tabba
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Jintack Lim, Ganapatrao Kulkarni,
Christoffer Dall, linux-kernel
In-Reply-To: <20260617144907.2972095-1-tabba@google.com>
On Wed, 17 Jun 2026 15:49:07 +0100, Fuad Tabba wrote:
> kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> R_VWJHB takes them from the SPSR being returned to and leaves
> PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> and PM were not applied at all.
>
> Build the PSTATE by taking those fields from the SPSR while preserving
> EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
commit: 0e8e955b9bcf84a70f20079390e19971fec1586d
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v9 9/9] perf test: Add Arm CoreSight callchain test
From: James Clark @ 2026-06-17 17:35 UTC (permalink / raw)
To: Leo Yan
Cc: linux-arm-kernel, coresight, linux-perf-users,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, Paschalis Mpeis, Amir Ayupov
In-Reply-To: <20260617150828.GE31870@e132581.arm.com>
On 17/06/2026 4:08 pm, Leo Yan wrote:
> On Wed, Jun 17, 2026 at 01:33:22PM +0100, Coresight ML wrote:
>> On Wed, Jun 17, 2026 at 11:03:07AM +0100, James Clark wrote:
>>
>> [...]
>>
>>>> + # It is safe to use 'i3i' with a three-instruction interval, since the
>>>> + # workload is compiled with -O0.
>>>> + perf script --itrace=g16i3il64 -i "$data" > "$script"
>>>
>>> Is there a reason we don't generate callstacks on branch samples and use
>>> --itrace=g16bl64? That removes the magic number 3 and reduces the output
>>> file size and test runtime a bit.
>>
>> I checked Intel-PT which does not generate callchain and branch stack for
>> branch samples. I just keep cs-etm aligned.
>>
>> I can add callstack / branch stack for branch samples.
>
> Tried a bit for this.
>
> The branch stack is skipped due the check:
>
> if (is_bts_event(attr)) {
> perf_sample__fprintf_bts(sample, evsel, thread, al, addr_al, machine, fp);
> return;
> }
>
> For the callstack attached to branch samples, the output seems not
> directive:
>
> callchain_test 4372 [003] 75596.459422: 1 branches:
> aaaaabdb0794 print+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test)
> aaaaabdb0798 print+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test)
> aaaaabdb07b0 foo+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test)
> aaaaabdb07c8 main+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test)
> ffff9a10225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6)
> ffff9a10233c call_init+0x9c (inlined)
> ffff9a10233c __libc_start_main_impl+0x9c (inlined)
> aaaaabdb0670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test)
> ffff9a2206a0 __libc_early_init+0x100 (/usr/lib/aarch64-linux-gnu/libc.so.6)
> => aaaaabdb0768 do_svc+0x0 (/home/kernel/leoy/test_cs_callchain/callchain_test)
>
> It is hard to digest the log as it separates branch from address
> (aaaaabdb0794 print+0x8) and to address (aaaaabdb0768 do_svc+0x0),
> and put the callchain in the middle of from and to ranges.
>
> Given this is not enabled by other hardware trace (e.g., Intel-PT),
> and we need to change the common code to make it better, I'd first
> enable callchain/branch stack for instruction samples. Let's see if
> further requirement after get this done.
>
> Thanks,
> Leo
Yep that sounds ok to me
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Marc Zyngier @ 2026-06-17 17:32 UTC (permalink / raw)
To: Fuad Tabba
Cc: Oliver Upton, kvmarm, linux-arm-kernel, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Jintack Lim, Ganapatrao Kulkarni, Christoffer Dall, linux-kernel
In-Reply-To: <CA+EHjTyv107RDF_MG1AtqqpJsiRbFx=xbrp12TgSu_N8dS55oA@mail.gmail.com>
On Wed, 17 Jun 2026 18:19:20 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> On Wed, 17 Jun 2026 at 17:45, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 17 Jun 2026 15:49:07 +0100,
> > Fuad Tabba <tabba@google.com> wrote:
> > >
> > > kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> > > masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> > > R_VWJHB takes them from the SPSR being returned to and leaves
> > > PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> > > and PM were not applied at all.
> > >
> > > Build the PSTATE by taking those fields from the SPSR while preserving
> > > EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
> > >
> > > Fixes: 47f3a2fc765a ("KVM: arm64: nv: Support virtual EL2 exceptions")
> > > Suggested-by: Marc Zyngier <maz@kernel.org>
> > > Link: https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > ---
> > > This is a modified version of Marc's suggested diff [1]. That diff applied
> > > a single mask to the incoming SPSR, which also takes PSTATE.{EL,SP,nRW}
> > > (and EXLOCK) from the SPSR. The ARM ARM leaves those fields unchanged on an
> > > illegal exception return. This path is reached precisely because SPSR.M is
> > > illegal (EL3, M[1]=1, AArch32, EL1 under TGE), so this version preserves
> > > EL/SP/nRW/EXLOCK from the current PSTATE and takes only the flags, masks
> > > and PAN/ALLINT/PM from the SPSR.
> > >
> > > [1] https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > > ---
> > > arch/arm64/kvm/emulate-nested.c | 33 +++++++++++++++++++++++----------
> > > 1 file changed, 23 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > > index dba7ced74ca5..ace2b40cf875 100644
> > > --- a/arch/arm64/kvm/emulate-nested.c
> > > +++ b/arch/arm64/kvm/emulate-nested.c
> > > @@ -2738,17 +2738,30 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > > (spsr & PSR_MODE32_BIT) ||
> > > (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> > > mode == PSR_MODE_EL1h))) {
> > > - /*
> > > - * The guest is playing with our nerves. Preserve EL, SP,
> > > - * masks, flags from the existing PSTATE, and set IL.
> > > - * The HW will then generate an Illegal State Exception
> > > - * immediately after ERET.
> > > - */
> > > - spsr = *vcpu_cpsr(vcpu);
> > > + u64 cpsr = *vcpu_cpsr(vcpu);
> > > + u64 mask;
> > >
> > > - spsr &= (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > > - PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT |
> > > - PSR_MODE_MASK | PSR_MODE32_BIT);
> > > + /*
> > > + * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> > > + * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> > > + * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> > > + * HW generates an Illegal State Exception right after ERET.
> > > + */
> > > + mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > > + PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> > > +
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, PAN, IMP))
> > > + mask |= PSR_PAN_BIT;
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, NMI, IMP))
> > > + mask |= ALLINT_ALLINT;
> > > + /* FEAT_SPE_EXC and FEAT_TRBE_EXC also gate PSTATE.PM one day... */
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64DFR1_EL1, EBEP, IMP))
> > > + mask |= BIT_ULL(32); /* PSTATE.PM */
> > > +
> > > + spsr &= mask;
> > > + spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> > > + spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> > > spsr |= PSR_IL_BIT;
> > > }
> >
> > While I'm happy that you caught the bugs I left for you to address,
> > the overall structure is a bit inconsistent. I'd like to have:
> >
> > - a mask of the bits we preserve from SPSR, and apply that to SPSR
> > itself
> >
> > - a mask of the bits we preserve from PSTATE, and transfer them to
> > SPSR
> >
> > - the comment at the top to describe this in that particular order.
> >
> > With that, I reworked your patch as follows:
> >
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index bb335fa16f7cc..243e5e26f7018 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2746,14 +2746,14 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > (spsr & PSR_MODE32_BIT) ||
> > (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> > mode == PSR_MODE_EL1h))) {
> > - u64 cpsr = *vcpu_cpsr(vcpu);
> > u64 mask;
> >
> > /*
> > - * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> > - * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> > - * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> > - * HW generates an Illegal State Exception right after ERET.
> > + * On an illegal exception return, the flags and masks are
> > + * taken from the SPSR while PSTATE.{EL,SP,nRW} and, if
> > + * FEAT_GCS, PSTATE.EXLOCK are unchanged (R_VWJHB). Set IL
> > + * so the HW generates an Illegal State Exception right
> > + * after ERET.
> > */
> > mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> > @@ -2767,9 +2767,12 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > mask |= BIT_ULL(32); /* PSTATE.PM */
> >
> > spsr &= mask;
> > - spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> > +
> > + mask = PSR_MODE_MASK | PSR_MODE32_BIT;
> > if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> > - spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> > + mask |= BIT_ULL(34); /* PSTATE.EXLOCK */
> > +
> > + spsr |= *vcpu_cpsr(vcpu) & mask;
> > spsr |= PSR_IL_BIT;
> > }
> >
> > Does that work for you?
>
> Yes, that's cleaner, thanks. The two-mask form (take from SPSR, then
> preserve from PSTATE) reads better than my interleaved version.
>
> Would you like me to send a v2 (which would be identical to the above?
> :) ), or would you fold it in?
I've squashed that in.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add Fuad Tabba as a reviewer
From: Oliver Upton @ 2026-06-17 17:29 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, kvmarm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260617131237.2842619-1-tabba@google.com>
On Wed, Jun 17, 2026 at 02:12:36PM +0100, Fuad Tabba wrote:
> I have been working on KVM/arm64 for a couple of years, mostly on
> pKVM, and am currently upstreaming protected guest support, with more
> to come later. I already review KVM/arm64 patches more broadly, and
> am happy to continue doing so in an official capacity.
>
> Add myself to the KVM/arm64 reviewer list.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
Welcome to the party! Marc, I'm guessing you'll take this as a fix so
Fuad can suffer through reviews ASAP :)
Acked-by: Oliver Upton <oupton@kernel.org>
Thanks,
Oliver
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c3fe46d7c4bc..61eb5dc2bd03 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13991,6 +13991,7 @@ F: virt/kvm/*
> KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
> M: Marc Zyngier <maz@kernel.org>
> M: Oliver Upton <oupton@kernel.org>
> +R: Fuad Tabba <tabba@google.com>
> R: Joey Gouly <joey.gouly@arm.com>
> R: Suzuki K Poulose <suzuki.poulose@arm.com>
> R: Zenghui Yu <yuzenghui@huawei.com>
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Fuad Tabba @ 2026-06-17 17:19 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, linux-arm-kernel, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Jintack Lim, Ganapatrao Kulkarni, Christoffer Dall, linux-kernel
In-Reply-To: <86se6lru7w.wl-maz@kernel.org>
On Wed, 17 Jun 2026 at 17:45, Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 17 Jun 2026 15:49:07 +0100,
> Fuad Tabba <tabba@google.com> wrote:
> >
> > kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> > masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> > R_VWJHB takes them from the SPSR being returned to and leaves
> > PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> > and PM were not applied at all.
> >
> > Build the PSTATE by taking those fields from the SPSR while preserving
> > EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
> >
> > Fixes: 47f3a2fc765a ("KVM: arm64: nv: Support virtual EL2 exceptions")
> > Suggested-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > Signed-off-by: Fuad Tabba <tabba@google.com>
> > ---
> > This is a modified version of Marc's suggested diff [1]. That diff applied
> > a single mask to the incoming SPSR, which also takes PSTATE.{EL,SP,nRW}
> > (and EXLOCK) from the SPSR. The ARM ARM leaves those fields unchanged on an
> > illegal exception return. This path is reached precisely because SPSR.M is
> > illegal (EL3, M[1]=1, AArch32, EL1 under TGE), so this version preserves
> > EL/SP/nRW/EXLOCK from the current PSTATE and takes only the flags, masks
> > and PAN/ALLINT/PM from the SPSR.
> >
> > [1] https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > ---
> > arch/arm64/kvm/emulate-nested.c | 33 +++++++++++++++++++++++----------
> > 1 file changed, 23 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index dba7ced74ca5..ace2b40cf875 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2738,17 +2738,30 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > (spsr & PSR_MODE32_BIT) ||
> > (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> > mode == PSR_MODE_EL1h))) {
> > - /*
> > - * The guest is playing with our nerves. Preserve EL, SP,
> > - * masks, flags from the existing PSTATE, and set IL.
> > - * The HW will then generate an Illegal State Exception
> > - * immediately after ERET.
> > - */
> > - spsr = *vcpu_cpsr(vcpu);
> > + u64 cpsr = *vcpu_cpsr(vcpu);
> > + u64 mask;
> >
> > - spsr &= (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > - PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT |
> > - PSR_MODE_MASK | PSR_MODE32_BIT);
> > + /*
> > + * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> > + * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> > + * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> > + * HW generates an Illegal State Exception right after ERET.
> > + */
> > + mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > + PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> > +
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, PAN, IMP))
> > + mask |= PSR_PAN_BIT;
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, NMI, IMP))
> > + mask |= ALLINT_ALLINT;
> > + /* FEAT_SPE_EXC and FEAT_TRBE_EXC also gate PSTATE.PM one day... */
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64DFR1_EL1, EBEP, IMP))
> > + mask |= BIT_ULL(32); /* PSTATE.PM */
> > +
> > + spsr &= mask;
> > + spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> > + spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> > spsr |= PSR_IL_BIT;
> > }
>
> While I'm happy that you caught the bugs I left for you to address,
> the overall structure is a bit inconsistent. I'd like to have:
>
> - a mask of the bits we preserve from SPSR, and apply that to SPSR
> itself
>
> - a mask of the bits we preserve from PSTATE, and transfer them to
> SPSR
>
> - the comment at the top to describe this in that particular order.
>
> With that, I reworked your patch as follows:
>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index bb335fa16f7cc..243e5e26f7018 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2746,14 +2746,14 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> (spsr & PSR_MODE32_BIT) ||
> (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> mode == PSR_MODE_EL1h))) {
> - u64 cpsr = *vcpu_cpsr(vcpu);
> u64 mask;
>
> /*
> - * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> - * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> - * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> - * HW generates an Illegal State Exception right after ERET.
> + * On an illegal exception return, the flags and masks are
> + * taken from the SPSR while PSTATE.{EL,SP,nRW} and, if
> + * FEAT_GCS, PSTATE.EXLOCK are unchanged (R_VWJHB). Set IL
> + * so the HW generates an Illegal State Exception right
> + * after ERET.
> */
> mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> @@ -2767,9 +2767,12 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> mask |= BIT_ULL(32); /* PSTATE.PM */
>
> spsr &= mask;
> - spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> +
> + mask = PSR_MODE_MASK | PSR_MODE32_BIT;
> if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> - spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> + mask |= BIT_ULL(34); /* PSTATE.EXLOCK */
> +
> + spsr |= *vcpu_cpsr(vcpu) & mask;
> spsr |= PSR_IL_BIT;
> }
>
> Does that work for you?
Yes, that's cleaner, thanks. The two-mask form (take from SPSR, then
preserve from PSTATE) reads better than my interleaved version.
Would you like me to send a v2 (which would be identical to the above?
:) ), or would you fold it in?
Cheers,
/fuad
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: Cristian Marussi @ 2026-06-17 17:11 UTC (permalink / raw)
To: Christian Brauner
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek, d-gole,
jic23, elif.topuz, lukasz.luba, philip.radford,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <20260617-waten-allabendlich-zueinander-93d4b1367b8c@brauner>
On Wed, Jun 17, 2026 at 02:58:09PM +0200, Christian Brauner wrote:
> On Fri, Jun 12, 2026 at 11:37:30PM +0100, Cristian Marussi wrote:
> > Hi all,
> >
Hi Christian,
thanks for having had a look at this, first of all.
A few remarks down below...
> > --------------------------------------------------------------------------------
> > [TLDR Summary]
> > This series introduces a new SCMI driver which uses a new Telemetry FS to expose
> > and configure SCMI Telemetry Data Events retrieved from the platform SCMI FW
> > at runtime. The patches carrying the new STLMFS Filesystem support are tagged
> > with 'stlmfs'.
> > --------------------------------------------------------------------------------
> >
> > the upcoming SCMI v4.0 specification [0] introduces a new SCMI protocol
> > dedicated to System Telemetry.
> >
> > In a nutshell, the SCMI Telemetry protocol allows an agent to discover at
> > runtime the set of Telemetry Data Events (DEs) available on a specific
> > platform and provides the means to configure the set of DEs that a user is
> > interested into, while reading them back using the collection method that
> > is deeemed more suitable for the usecase at hand. (...amongst the various
> > possible collection methods allowed by SCMI specification)
> >
> > Without delving into the gory details of the whole SCMI Telemetry protocol
> > let's just say that the SCMI platform/server firmware advertises a number
> > of Telemetry Data Events, each one identified by a 32bit unique ID, and an
> > SCMI agent/client, like Linux, can discover them and read back at will the
> > associated data value in a number of ways.
> > Data collection is mainly intended to happen on demand via shared memory
> > areas exposed by the platform firmware, discovered dynamically via SCMI
> > Telemetry and accessed by Linux on-demand, but some DE can also be reported
> > via SCMI Notifications asynchronous messages or via direct dedicated
> > FastChannels (another kind of SCMI memory based access): all of this
> > underlying mechanism is anyway hidden to the user since it is mediated by
> > the kernel driver which will return the proper data value when queried.
> >
> > Anyway, the set of well-known architected DE IDs defined by the spec is
> > limited to a dozen IDs, which means that the vast majority of DE IDs are
> > customizable per-platform: as a consequence, though, the same ID, say
> > '0x1234', could represent completely different things on different systems.
> >
> > Precise definitions and semantic of such custom Data Event IDs are out of
> > the scope of the SCMI Telemetry specification and of this implementation:
> > they are supposed to be provided using some kind of JSON-like description
> > file that will have to be consumed by a userspace tool which would be
> > finally in charge of making sense of the set of available DEs.
> >
> > IOW, in turn, this means that even though the DEs enumerated via SCMI come
> > with some sort of topological and qualitative description provided by the
> > protocol (like unit of measurements, name, topology info etc), kernel-wise
> > we CANNOT be completely sure of "what is what" without being fed-back some
> > sort of information about the DEs by the afore mentioned userspace tool.
> >
> > For these reasons, currently this series does NOT attempt to register any
> > of these DEs with any of the usual in-kernel subsystems (like HWMON, IIO,
> > PERF etc), simply because we cannot be sure which DE is suitable, or even
> > desirable, for a given subsystem. This also means there are NO in-kernel
> > users of these Telemetry data events as of now.
> >
> > So, while we do not exclude, for the future, to feed/register some of the
> > discovered DEs to/with some of the above mentioned Kernel subsystems, as
> > of now we have ONLY modeled a custom userspace API to make SCMI Telemetry
> > available to userspace tools.
> >
> > In deciding which kind of interface to expose SCMI Telemetry data to a
> > user, this new SCMI Telemetry driver aims at satisfying 2 main reqs:
> >
> > - exposing an FS-based human-readable interface that can be used to
> > discover, configure and access our Telemetry data directly also from
> > the shell without special tools
> >
> > - exposing alternative machine-friendly, more-performant, binary
> > interfaces that can be used to avoid the overhead of multiple accesses
> > to the VFS and that can be more suitable to access with custom tools
> >
> > In the initial RFC posted a few months ago [1], the above was achieved
> > with a combination of a SysFS interface, for the human-readable side of
> > the story, and a classic chardev/ioctl for the plain binary access.
> >
> > Since V1, instead, we moved away from this combined approach, especially
> > away from SysFS, for the following reason:
> >
> > 1. "Abusing SysFS": SysFS is a handy way to expose device related
> > properties in a common way, using a few common helpers built on
> > kernfs; this means, though, that unfortunately in our scenario I had
> > to generate a dummy simple device for EACH SCMI Telemetry DataEvent
> > that I got to discover at runtime and attach to them, all of the
> > properties I need.
> > This by itself seemed to me abusing the SysFS framework, but, even
> > ignoring this, the impact on the system when we have to deal with
> > hundreds or tens of thousands of DEs is sensible.
> > In some test scenario I ended with 50k DE devices and half-a-millon
> > related property files ... O_o
> >
> > 2. "SysFS constraints": SysFS usage itself has its well-known constraints
> > and best practices, like the one-file/one-value rule, and due to the
> > fact that any virtual file with a complex structure or handling logic
> > is frowned upon, you can forget about IOCTLs and mmap'ing to provide
> > a more performant interface within SysFs, which is the reason why,
> > in the previous RFC, there was an additional alternative chardev
> > interface.
> > These latter limitations around the implementation of files with a
> > more complex semantic (i.e. with a broader set of file_operations)
> > derive from the underlying KernFS support, so KernFS is equally not
> > suitable as a building block for our implementation.
> >
> > 2. "Chardev limitations": Given the nature of the protocol, the hybrid
> > approach employing character devices was itself problematic: first
> > of all because there is an upper limit on the number of chardev we
> > can create, dictated by the range of available minor numbers, and
> > then because the fact itself to have to maintain 2 completely
> > different interfaces (FS + chardev) is painful.
> >
> > As a final remark, please NOTE THAT all of this is supposed to be available
> > in production systems across a number of heterogeneous platforms: for these
> > reasons the easy choice, debugFS, is NOT an option here.
> >
> > Due to the above reasoning, since V1 we opted for a new approach with the
> > proposed interfaces now based on a full fledged, unified, virtual pseudo
> > filesystem implemented from scratch, so that we can:
> >
> > - expose all the DEs property we like as before with SysFS, but without
> > any of the constraint imposed by the usage of SysFs or kernfs.
> >
> > - easily expose additional alternative views of the same set of DEs
> > using symlinking capabilities (e.g. alternative topological view)
> >
> > - additionally expose a few alternative and more performant interfaces
> > by embedding in that same FS, a few special virtual files:
> >
> > + 'control': to issue IOCTLs for quicker discovery and on-demand access
> > to data
> > + 'pipe' [TBD]: to provide a stream of events using a virtual
> > infinite-style file
> > + 'raw_<N>' [TBD]: to provide direct memory mapped access to the raw
> > SCMI Telemetry data from userspace
>
> A filsystem driver for telemetry like this is really misguided. I think
> shell access is really not an argument for adding a filesystem into the
> kernel like this. That's just not appropriate justification to push
> thousand and thousands of lines of code into the kernel.
>
> You're building completely new infrastructure. The format is whatever it
> is. If you stream it somehow just add a binary that userspace can use to
> consume or translate it. If you need a filesystem interface for
> convenience build it via FUSE on top of whatever streams that data and
> get it ouf of the kernels way.
>
...I would not say that this was the kind of feedback I was hoping for,
but I am NOT gonna argue, given that you shot down already what I thought
were all my best selling points :P
At this point my understanding is that the way forward must be to use
a custom tool to configure/extract/translate the raw Telemetry data and
move up into userspace the whole human readable FS layer via FUSE, if
really needed.
I suppose that the new kernel/user interface has to be some dedicated char
device implementing proper fops. (like I did previously in early versions
of this series and then abandoned...)
Is this you have in mind ? Dedicated character device(s) with enough fops
to be able to configure/extract Telemetry data with a custom tool ?
Should/could such a tool live in the kernel tree (tools/) at least for
ease of development/deployment ?
> You also buy into all kinds of really wonky properties. If you split it
> over multiple files you can never get a snapshot of data that is
> consistent if it's across multiple files.
There were also bulk read-all-together interfaces but it does not matter
at this point...
>
> Telemetry over a filesystem is just not a great idea. If you did it via
> sysfs I really wouldn't care because all because the infrastructure
> already exists and I couldn't be bothered if this grew yet another wart
> but as a separate massive hand-rolled pseudofs, no I'm not seeing it.
...well, I am sure Greg would have shot down the SysFS approach even
more quickly, given the amount of abuse I had to carry-on to be able
to fit my Telemetry sources on top of a zillion dummy devices created
just to be representable in SysFS; indeed I did try to use SysFS in the
initial RFC and it was also a lot of pain to play that game in my
context from the implementation point of view...
...so I thought that adopting this new unified FS approach would have
been much cleaner and acceptable upstream... :D
Thanks again,
Cristian
^ permalink raw reply
* Re: [PATCH v22 00/13] Implement PSCI reboot mode driver for PSCI resets
From: Shivendra Pratap @ 2026-06-17 17:00 UTC (permalink / raw)
To: Lorenzo Pieralisi, Arnd Bergmann
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Bartosz Golaszewski, Song Xue, Sebastian Reichel, Mark Rutland,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer,
Bartosz Golaszewski, Sudeep Holla
In-Reply-To: <0c6636b0-f6c7-49dc-b335-2b4fac16b848@oss.qualcomm.com>
On 29-05-2026 19:00, Shivendra Pratap wrote:
>
>
> On 14-05-2026 19:55, Shivendra Pratap wrote:
>> Userspace should be able to initiate device reboots using the various
>> PSCI SYSTEM_RESET and SYSTEM_RESET2 types defined by PSCI spec. This
>> patch series introduces psci-reboot-mode driver that will induce
>> command-based resets to psci driver for executing the device reset.
>>
>> The PSCI system reset calls takes two arguments: reset_type and cookie.
>> It defines predefined reset types, such as warm and cold reset, and
>> vendor-specific reset types which are SoC vendor specific. To support
>> these requirements, the reboot-mode framework is enhanced in two key
>> ways:
>
> Hi Lorenzo,
>
> Can you please review the if its aligning towards the suggestion in v20?
>
Hi Lorenzo,
Was planning to address the mfd, and other comments, for re-post. Any
feedbacks, that we should take care in next post?
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Marc Zyngier @ 2026-06-17 16:45 UTC (permalink / raw)
To: Fuad Tabba
Cc: Oliver Upton, kvmarm, linux-arm-kernel, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Jintack Lim, Ganapatrao Kulkarni, Christoffer Dall, linux-kernel
In-Reply-To: <20260617144907.2972095-1-tabba@google.com>
On Wed, 17 Jun 2026 15:49:07 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> R_VWJHB takes them from the SPSR being returned to and leaves
> PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> and PM were not applied at all.
>
> Build the PSTATE by taking those fields from the SPSR while preserving
> EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
>
> Fixes: 47f3a2fc765a ("KVM: arm64: nv: Support virtual EL2 exceptions")
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> This is a modified version of Marc's suggested diff [1]. That diff applied
> a single mask to the incoming SPSR, which also takes PSTATE.{EL,SP,nRW}
> (and EXLOCK) from the SPSR. The ARM ARM leaves those fields unchanged on an
> illegal exception return. This path is reached precisely because SPSR.M is
> illegal (EL3, M[1]=1, AArch32, EL1 under TGE), so this version preserves
> EL/SP/nRW/EXLOCK from the current PSTATE and takes only the flags, masks
> and PAN/ALLINT/PM from the SPSR.
>
> [1] https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> ---
> arch/arm64/kvm/emulate-nested.c | 33 +++++++++++++++++++++++----------
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index dba7ced74ca5..ace2b40cf875 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2738,17 +2738,30 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> (spsr & PSR_MODE32_BIT) ||
> (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> mode == PSR_MODE_EL1h))) {
> - /*
> - * The guest is playing with our nerves. Preserve EL, SP,
> - * masks, flags from the existing PSTATE, and set IL.
> - * The HW will then generate an Illegal State Exception
> - * immediately after ERET.
> - */
> - spsr = *vcpu_cpsr(vcpu);
> + u64 cpsr = *vcpu_cpsr(vcpu);
> + u64 mask;
>
> - spsr &= (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> - PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT |
> - PSR_MODE_MASK | PSR_MODE32_BIT);
> + /*
> + * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> + * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> + * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> + * HW generates an Illegal State Exception right after ERET.
> + */
> + mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> + PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> +
> + if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, PAN, IMP))
> + mask |= PSR_PAN_BIT;
> + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, NMI, IMP))
> + mask |= ALLINT_ALLINT;
> + /* FEAT_SPE_EXC and FEAT_TRBE_EXC also gate PSTATE.PM one day... */
> + if (kvm_has_feat(vcpu->kvm, ID_AA64DFR1_EL1, EBEP, IMP))
> + mask |= BIT_ULL(32); /* PSTATE.PM */
> +
> + spsr &= mask;
> + spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> + spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> spsr |= PSR_IL_BIT;
> }
While I'm happy that you caught the bugs I left for you to address,
the overall structure is a bit inconsistent. I'd like to have:
- a mask of the bits we preserve from SPSR, and apply that to SPSR
itself
- a mask of the bits we preserve from PSTATE, and transfer them to
SPSR
- the comment at the top to describe this in that particular order.
With that, I reworked your patch as follows:
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index bb335fa16f7cc..243e5e26f7018 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2746,14 +2746,14 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
(spsr & PSR_MODE32_BIT) ||
(vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
mode == PSR_MODE_EL1h))) {
- u64 cpsr = *vcpu_cpsr(vcpu);
u64 mask;
/*
- * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
- * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
- * and masks are taken from the SPSR (R_VWJHB). Set IL so the
- * HW generates an Illegal State Exception right after ERET.
+ * On an illegal exception return, the flags and masks are
+ * taken from the SPSR while PSTATE.{EL,SP,nRW} and, if
+ * FEAT_GCS, PSTATE.EXLOCK are unchanged (R_VWJHB). Set IL
+ * so the HW generates an Illegal State Exception right
+ * after ERET.
*/
mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
@@ -2767,9 +2767,12 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
mask |= BIT_ULL(32); /* PSTATE.PM */
spsr &= mask;
- spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
+
+ mask = PSR_MODE_MASK | PSR_MODE32_BIT;
if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
- spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
+ mask |= BIT_ULL(34); /* PSTATE.EXLOCK */
+
+ spsr |= *vcpu_cpsr(vcpu) & mask;
spsr |= PSR_IL_BIT;
}
Does that work for you?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH v4 1/3] dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
From: Heiner Kallweit @ 2026-06-17 16:43 UTC (permalink / raw)
To: ricardo, nic_swsd, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-1-2bd38922d129@pardini.net>
On 17.06.2026 14:58, Ricardo Pardini via B4 Relay wrote:
> From: Ricardo Pardini <ricardo@pardini.net>
>
> Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
> controller.
>
> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
> compatibles documented in their own bindings (e.g. microchip,lan95xx)
> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
> these PCI function nodes can be validated.
>
> Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
> ---
> .../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 44 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> new file mode 100644
> index 0000000000000..eee13fbc1e6a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/realtek,rtl8125.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek RTL8125 2.5 Gigabit PCIe Ethernet Controller
> +
> +maintainers:
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +description:
> + The Realtek RTL8125 is a 2.5GBASE-T Ethernet controller with a PCIe host
> + interface.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + const: pci10ec,8125
IIRC we came to the conclusion that the compatible string isn't used in the
relevant code path. Then why add it here? Is there an alignment on this?
If it should be added here, then an explaining comment would be helpful.
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet@0,0 {
> + compatible = "pci10ec,8125";
> + reg = <0x10000 0 0 0 0>;
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c8d4b913f26c1..e5fbd82946aec 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
> M: nic_swsd@realtek.com
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> F: drivers/net/ethernet/realtek/r8169*
>
> 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
>
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-17 16:32 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <2i6yzwu2yk5bngq723g75yeqzeg4ihvtbuydzunceltl526tjp@vnt6nmxxkfut>
On 6/16/2026 5:52 AM, Dmitry Baryshkov wrote:
> On Mon, Jun 15, 2026 at 06:55:45PM +0530, Bibek Kumar Patro wrote:
>>
>>
>> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>>>> On some SoCs the SMMU registers require an active interconnect
>>>> bandwidth vote to be accessible. While other clients typically
>>>> satisfy this requirement implicitly, certain corner cases (e.g.
>>>> during sleep/wakeup transitions) can leave the SMMU without a
>>>> vote, causing intermittent register access failures.
>>>>
>>>> Add support for an optional interconnect path to the arm-smmu
>>>> driver and vote for bandwidth while the SMMU is active. The path
>>>> is acquired from DT if present and ignored otherwise.
>>>>
>>>> The bandwidth vote is enabled before accessing SMMU registers
>>>> during probe and runtime resume, and released during runtime
>>>> suspend and on error paths.
>>>>
>>>> Generally, from an architectural perspective, GEM_NOC and DDR are
>>>> expected to have an active vote whenever the adreno_smmu block is
>>>> powered on. In most common use cases, this requirement is implicitly
>>>> satisfied because other GPU-related clients (for example, the GMU
>>>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>>>
>>>> However, there are certain corner cases, such as during sleep/wakeup
>>>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>>>> is powered down. If adreno_smmu is then accessed while the interconnect
>>>> vote is missing, it can lead to the observed failures. Because of the
>>>> precise ordering involved, this scenario is difficult to reproduce
>>>> consistently.
>>>> (also GDSC is involved in adreno usecases can have an independent vote)
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>> ---
>>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> @@ -53,6 +53,11 @@
>>>> #define MSI_IOVA_BASE 0x8000000
>>>> #define MSI_IOVA_LENGTH 0x100000
>>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>>
>>> totally random numbers, which might be different for non-Qualcomm platform.
>>>
>>>> +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
>>>> +
>>>> static int force_stage;
>>>> module_param(force_stage, int, S_IRUGO);
>>>> MODULE_PARM_DESC(force_stage,
>>>> @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
>>>> }
>>>> }
>>>> +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
>>>> +{
>>>> + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
>>>
>>> Is there always only one bus / path in question?
>>>
>>
>> <Apologies, missed to respond to this query>
>> Yes for TCU, it needs to only have a vote on GEM_NOC interconnect
>> while accessing the DDR in downstream path (client->TCU->DDR), which we are
>> addressing here.
>> Hence it's only one icc path in question here.
>
> Again, you are describing Qualcomm platform, while the code part is
> generic.
>
ah yes, single icc path is specific to Qualcomm platforms as of now.
As per my assumption, it's possible for other vendors/ARM-SMMU users to
have one or more than one icc path to reach DDR in downstream flow
(similar to clocks).
I will revisit the logic for icc_voting to check for possibility on
additional icc path as well, so the generic code can cater to other arm-
smmu users.
Thanks & regards,
Bibek
>
^ permalink raw reply
* Re: [PATCH v15 00/11] arm64: entry: Convert to Generic Entry
From: Ada Couprie Diaz @ 2026-06-17 16:27 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-1-ruanjinjie@huawei.com>
Hi Jinjie,
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
> maintainers' work easier and codes more elegant. arm64 has already
> successfully switched to the Generic IRQ Entry in commit
> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
> time to completely convert arm64 to Generic Entry.
>
> [...]
>
> It was tested ok with following test cases on QEMU virt platform:
> - Stress-ng CPU stress test.
> - Hackbench stress test.
> - "sud" selftest testcase.
> - get_set_sud, get_syscall_info, set_syscall_info, peeksiginfo
> in tools/testing/selftests/ptrace.
> - breakpoint_test_arm64 in selftests/breakpoints.
> - syscall-abi and ptrace in tools/testing/selftests/arm64/abi
> - fp-ptrace, sve-ptrace, za-ptrace in selftests/arm64/fp.
> - vdso_test_getrandom in tools/testing/selftests/vDSO
> - Strace tests.
>
> The test QEMU configuration is as follows:
>
> qemu-system-aarch64 \
> -M virt \
> -enable-kvm \
> -cpu host \
> -kernel Image \
> -smp 8 \
> -m 512m \
> -nographic \
> -no-reboot \
> -device virtio-rng-pci \
> -append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
> earlycon irqchip.gicv3_pseudo_nmi=1" \
> -drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
> -device virtio-blk-device,drive=hd0 \
Thanks for the series and the extensive test coverage !
I did some additional testing on my side with the series rebased
on -rc5, to get the latest fixes from Mark Rutland, focusing on stability
rather than performance, with the following configurations :
- Systems
- M1SDP (4 CPU, 16 GiB RAM, GICv3)
- QEMU/KVM on M1SDP (4 CPU, 4 GiB RAM, GICv3)
- Host running upstream
- Host running this series
- AMD Seattle (4 CPU, 8 GiB RAM, GICv2)
- Kernel configurations (+ debug options[1])
- defconfig
- pseudo-NMI (except on Seattle)
- PREEMPT_RT
- PREEMPT_RT + pseudo-NMI (except on Seattle)
- Tests
- stress-ng
- CPU stress test
- Interrupt stress tests
- Virtual Memory stress tests
- Syscall validation tests
- Hackbench
- pseudo-NMI load tests via perf
- debug exception entry load tests
- memcached stress test via mc-crusher
- The above plus high system load/low available memory
- Suspend test via /sys/power/pm_test
- Hibernate (QEMU only)
All tests were able to complete without major issues !
However, when combining pseudo-NMIs with PREEMPT_RT under heavy pNMI load,
I was able to trigger a new warning compared to upstream :
BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
Specifically, this was when running `stress-ng --all 100 --class vm -t
300` with
`perf top -a -e 'cycles'` in another shell.
This does not feel like a major issue : from my understanding it only
happens
when running the full suite for some time and with many stressors (I was not
able to reproduce it by running individual tests), and flooding the
system with
pseudo-NMIs.
Given that this only happen with PREEMPT_RT, my guess is that it interacts
with generic entry in a way that can lead to more nesting than before,
leading to an easier exhaustion of the limit on lockdep.
As the system was still able to recover and did not lock up, I think it
can be OK
as-is, or simply bumped a bit ? Happy for more opinions on that.
Otherwise, this is
Tested-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
As this is an important change, any other testing, especially on real
workloads
as well as on very large systems (which we haven't covered), would be
very welcome !
I will take some time soon to review this latest version, now that I am
able to.
Thanks again,
Kind regards
Ada
[0] BUG dump
BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
turning off the locking correctness validator.
CPU: 0 UID: 0 PID: 77252 Comm: stress-ng-shm-s Tainted: G W 7.1.0-rc5-pnmi-rt-00011-g856fda168b7e #477 PREEMPT_RT
Tainted: [W]=WARN
Hardware name: ARM LTD Morello System Development Platform, BIOS EDK II Mar 7 2024
Call trace:
show_stack+0x20/0x38 (C)
dump_stack_lvl+0xf8/0x1b8
dump_stack+0x18/0x28
__lock_acquire+0x1a50/0x1f78
lock_acquire+0x260/0x448
_raw_spin_lock+0x50/0x70
rcu_note_context_switch+0x11c/0x608
__schedule+0x100/0x1280
preempt_schedule_irq+0x58/0x158
raw_irqentry_exit_cond_resched+0x4c/0x78
arm64_exit_to_kernel_mode+0xa8/0x158
el1_interrupt+0x58/0xb0
el1h_64_irq_handler+0x18/0x28
el1h_64_irq+0x80/0x88
lock_acquire+0x3b0/0x448 (P)
rt_spin_lock+0x11c/0x218
new_inode+0x38/0x78
__shmem_get_inode+0xa8/0x408
__shmem_file_setup+0x16c/0x1b0
shmem_kernel_file_setup+0x38/0x50
newseg+0x100/0x3d8
ipcget+0x464/0x5f0
__arm64_sys_shmget+0x64/0xa0
invoke_syscall.constprop.0+0x58/0x118
do_el0_svc+0x64/0x3d8
el0_svc+0x54/0x310
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x1ac/0x1b0
[1] Debug options defconfig :
CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y
CONFIG_PM_DEBUG=y
CONFIG_PM_ADVANCED_DEBUG=y
CONFIG_KPROBES=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_IRQFLAGS=y
CONFIG_RCU_EQS_DEBUG=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FPROBE=y
CONFIG_USER_EVENTS=y
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: dts: qcom: kodiak: Add GEM_NOC interconnect for adreno SMMU
From: Bibek Kumar Patro @ 2026-06-17 16:20 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <zhdacu4upv5kyvyqx5hcm6im4p7r3z5bsnup7hqu2okxyxmeib@snpseurpvhtc>
On 6/16/2026 5:49 AM, Dmitry Baryshkov wrote:
> On Mon, Jun 08, 2026 at 08:07:07PM +0530, Bibek Kumar Patro wrote:
>>
>>
>> On 6/8/2026 7:27 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 26, 2026 at 08:12:04PM +0530, Bibek Kumar Patro wrote:
>>>> On Kodiak platforms, the Adreno SMMU requires a bandwidth vote on
>>>> the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers
>>>> are accessible. Without this vote, the SMMU may become unreachable,
>>>> leading to intermittent probe failures and runtime issues.
>>>>
>>>> Add the required interconnect to ensure reliable register access.
>>>
>>> Does it only concern the GPU SMMU? What about the APPS SMMU? Should it
>>> be voting on other interconnects too? I guess so, because currently I
>>> see that TBUs vote for various interconnects. BTW: should apps_smmu also
>>> vote on the power domains?
>>>
>>
>> This race mainly occurs in GPU SMMU, where the GDSC can have an
>> independent vote on the Adreno SMMU. However, the GEM_NOC vote may
>> already have been removed by the GPU (or any consumer of adreno_smmu,
>> e.g gmu), unless it is explicitly voted by the GPU SMMU (which acts as a
>> supplier for the GPU). This mismatch can lead to SHUB timeouts or NoC
>> errors.
>>
>> Mostly this race reported in suspend/resume cycle (when gpu/gmu devices
>> moves to slumber/suspend state before adreno_smmu powers down
>> and the later doesn't have explicit interconnect voting).
>>
>> In the case of APPS SMMU, such a race is not expected for any known
>> use case. APPS SMMU is part of a shared infrastructure block, and its
>> power is typically kept enabled as long as attached master devices are
>> active. Therefore, explicit power-domain voting from APPS SMMU may not
>> be required.
>
> This looks like a good part of the commit message. Please add it where
> it belongs.
>
Ack, thanks for this suggestion. It seems like i haven't explained this
specific info in any of the patches in this series.
Will take care of this in the next revision.
Thanks & regards,
Bibek
>>
>> Thanks,
>> Bibek
>>
>>
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index fa540d8c2615dc02d941eb16bc7253204c2750bd..eefa4b836a81374ff437ab4bbcbc3fecc1590ab6 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -3386,6 +3386,8 @@ adreno_smmu: iommu@3da0000 {
>>>> power-domains = <&gpucc GPU_CC_CX_GDSC>;
>>>> dma-coherent;
>>>> + interconnects = <&gem_noc MASTER_GPU_TCU QCOM_ICC_TAG_ALWAYS
>>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>>>> };
>>>> gfx_0_tbu: tbu@3dd9000 {
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-17 16:20 UTC (permalink / raw)
To: Conor Dooley
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260617-deviate-sulk-c57104ef939f@spud>
Hi Conor,
Am 17.06.2026 um 17:51 schrieb Conor Dooley:
> On Wed, Jun 17, 2026 at 02:23:14PM +0200, Gerald Loacker wrote:
>> Add support for the optional rockchip,clk-lane-phase device tree property
>> to allow board-specific tuning of the clock lane sampling phase for
>> improved signal integrity across supported data rates.
>>
>> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
>> ---
>> Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> index 03950b3cad08c..0d824d1511bc0 100644
>> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> @@ -56,6 +56,13 @@ properties:
>> description:
>> Some additional phy settings are access through GRF regs.
>>
>> + rockchip,clk-lane-phase:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 7
>> + description:
>> + Clock lane sampling phase in 40 ps steps. The hardware default is 3.
>
> Can this instead become rockchip,clk-lane-phase-ps and be listed in the
> actual unit?
> With the -ps suffix, you can then drop the $ref.
> The default should be listed as "default: 3" (or default: 120)
>
> pw-bot: changes-requested
>
Thanks for the suggestion.
The phase setting is a hardware tap index (0–7) selecting a delay line
position. The datasheet mentions “about 40 ps” per step, but this is not
a calibrated or guaranteed value and may vary with PVT.
Because of that, I’d prefer to keep the property as an index and
document the approximate delay in the description:
Clock lane sampling phase selection (hardware tap index 0–7). Each step
corresponds to an approximately 40 ps delay as described in the hardware
specification.
This matches the hardware model more closely. Happy to adjust if needed.
>> +
>> required:
>> - compatible
>> - reg
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH RFC v4 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:12 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-3-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]
On Tue, Jun 16, 2026 at 11:26:23PM +0300, Stefan Dösinger wrote:
> +
> + matrixclk: clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
> + <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
> + <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
> + <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
> + <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
> + <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
> + <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
> + <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
> + <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
> + <&topclk ZX297520V3_UPLL_D16>,
> + <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
> + <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
> + <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
> + <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
> + <&topclk ZX297520V3_DPLL_D16>,
> + <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
> + <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
> + <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
> + <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
> + <&topclk ZX297520V3_GPLL_D16>;
> + clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3",
> + "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
> + "mpll_d16", "mpll_d26", "upll", "upll_d2", "upll_d3",
> + "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
> + "upll_d16", "dpll", "dpll_d2", "dpll_d3", "dpll_d4",
> + "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12", "dpll_d16",
> + "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5",
> + "gpll_d6", "gpll_d8", "gpll_d12", "gpll_d16";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + clock-controller@1400000 {
> + compatible = "zte,zx297520v3-lspclk";
> + reg = <0x01400000 0x100>;
> + clocks = <&matrixclk ZX297520V3_LSP_MPLL_D5_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D4_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D6_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D8_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D12_WCLK>,
> + <&matrixclk ZX297520V3_LSP_OSC26M_WCLK>,
> + <&matrixclk ZX297520V3_LSP_OSC32K_WCLK>,
> + <&matrixclk ZX297520V3_LSP_PCLK>,
> + <&matrixclk ZX297520V3_LSP_TDM_WCLK>,
> + <&matrixclk ZX297520V3_LSP_DPLL_D4_WCLK>;
> + clock-names = "mpll_d5", "mpll_d4", "mpll_d6", "mpll_d8", "mpll_d12",
> + "osc26m", "osc32k", "pclk", "tdm_wclk", "dpll_d4";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
Same comment here on what's in scope.
pw-bot: changes-requested
Otherwise, once again, looks okay.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v4 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:11 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-2-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]
On Tue, Jun 16, 2026 at 11:26:22PM +0300, Stefan Dösinger wrote:
> I split matrixclk into its own controller again because syscon/regmap
> deals poorly with device nodes that have more than one memory region. As
> a consequence I am passing all PLL outputs generated on Topclk down to
> Matrixclk.
This type of commentary FWIW can go below the --- line and instead just
write a normal commit message.
I do appreciate though that you put the information in the individual
patch.
> The syscon is used to generate the regmap shared between the clock and
> auxiliary reset drivers. The register space also contains at least one
> extra block of functionality, hardware spinlocks, that I expect will be
> necessary to communicate correctly with the LTE DSP firmware blob.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + topclk: clock-controller@13b000 {
> + compatible = "zte,zx297520v3-topclk", "syscon";
> + reg = <0x0013b000 0x400>;
> + clocks = <&osc26m>, <&osc32k>;
> + clock-names = "osc26m", "osc32k";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
This should be removed from here, the tooling will satisfy the topclk
references, just as it has done for osc26m and osc32k. The example
should just contain the node the binding documents (and its children).
pw-bot: changes-requested
Looks fine otherwise.
Cheers,
Conor.
> +
> + clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
> + <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
> + <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
> + <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
> + <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
> + <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
> + <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
> + <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
> + <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
> + <&topclk ZX297520V3_UPLL_D16>,
> + <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
> + <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
> + <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
> + <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
> + <&topclk ZX297520V3_DPLL_D16>,
> + <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
> + <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
> + <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
> + <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
> + <&topclk ZX297520V3_GPLL_D16>;
> + clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3",
> + "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
> + "mpll_d16", "mpll_d26", "upll", "upll_d2", "upll_d3",
> + "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
> + "upll_d16", "dpll", "dpll_d2", "dpll_d3", "dpll_d4",
> + "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12", "dpll_d16",
> + "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5",
> + "gpll_d6", "gpll_d8", "gpll_d12", "gpll_d16";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:08 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-1-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5389 bytes --]
On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
> These SoCs have 3 clock and reset controllers: Top, Matrix and LSP. The
> separation of concerns between Top and Matrix and the interface between
> them is poorly defined in the hardware, so the bindings list all
> potential PLL clocks that might be passed between them.
>
> Generally every device has two clocks (one work clock, and one that
> connects it to the bus, I call it PCLK), two reset bits (I don't know
> what the difference is - sometimes asserting one is enough to reset the
> device, sometimes both need to be asserted). PCLK and WCLK are
> controlled by individual gates. Some devices have a mux and/or a
> divider for their work clock. Some devices, like the GPIO controller,
> only have reset bits and no clocks.
>
> The top clock controller is fed by a 26mhz external oscillator and has 4
> PLLs to generate other clock rates. ZTE's kernel mostly relies on the
> boot ROM to set up PLLs, but one LTE-Related PLL is not configured
> on some boards. Therefore my driver contains code to program PLLs. It
> produces identical settings as the boot ROM for the pre-programmed
> frequencies.
>
> Not all clocks will have an explicit user in the end. I am defining a
> lot of them simply to shut them off. The boot loader sets up a few of
> the proprietary timers, which will send regular IRQs (although the
> kernel of course doesn't need to listen to them). I don't plan to add a
> driver for the proprietary timer as I see no use for them - the ARM arch
> timer works just fine. I will add a driver for the very similar
> proprietary watchdog though.
>
> The clock list in this patch is pretty complete but not exhaustive.
> There are other bits that are enabled, but I couldn't deduce what they
> are controlling by trial and error. Some of them seem to do nothing.
> Others cause an instant hang of the board when disabled. It is quite
> likely that a handful more clocks will be added in the future, but not a
> large number.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> .../bindings/clock/zte,zx297520v3-topclk.yaml | 70 ++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/clock/zte,zx297520v3-clk.h | 118 +++++++++++++++++++++
> 3 files changed, 190 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml b/Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml
> new file mode 100644
> index 000000000000..374f63891288
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/zte,zx297520v3-topclk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ZTE zx297520v3 SoC top clock and reset controller
> +
> +maintainers:
> + - Stefan Dösinger <stefandoesinger@gmail.com>
> +
> +description: |
> + The zx297520v3's top clock controller generates clocks for core devices on the
> + board like the main bus, USB and timers. In addition to clocks it has reset
> + controls for peripherals, a global board reset and watchdog reset controls.
> +
> + The controller has two clock inputs: a 26 MHz and a 32 KHz external
> + oscillator. They need to be provided as input clocks. The controller provides
> + clocks to the downstream Matrix clock controller.
> +
> + All available clocks are defined as preprocessor macros in the
> + 'dt-bindings/clock/zte,zx297520v3-clk.h' header.
> +
> +properties:
> + compatible:
> + items:
> + - const: zte,zx297520v3-topclk
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: 26 MHz external oscillator
> + - description: 32 KHz external oscillator
> +
> + clock-names:
> + items:
> + - const: osc26m
> + - const: osc32k
> +
> + "#clock-cells":
> + const: 1
> +
> + "#reset-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - '#clock-cells'
> + - '#reset-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + clock-controller@13b000 {
> + compatible = "zte,zx297520v3-topclk", "syscon";
> + reg = <0x0013b000 0x400>;
> + clocks = <&osc26m>, <&osc32k>;
> + clock-names = "osc26m", "osc32k";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8629ed2aa82f..0cc1ede3c80c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3867,8 +3867,10 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Odd fixes
> F: Documentation/arch/arm/zte/
> F: Documentation/devicetree/bindings/arm/zte.yaml
> +F: Documentation/devicetree/zte,zx297520v3-*
Sashiko complaint here looks valid.
FWIW
/scripts/get_maintainer.pl --self-test=patterns
will catch these kinds of things.
pw-bot: changes-requested
Cheers,
Conor.
> F: arch/arm/boot/dts/zte/
> F: arch/arm/mach-zte/
> +F: include/dt-bindings/clock/zte,zx297520v3-clk.h
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v7 5/7] KVM: arm64: Validate the offset to the mem access descriptor
From: Sebastian Ene @ 2026-06-17 14:51 UTC (permalink / raw)
To: catalin.marinas, oupton, sudeep.holla, will
Cc: jens.wiklander, joey.gouly, kvmarm, linux-arm-kernel,
linux-kernel, android-kvm, maz, mrigendra.chaubey, op-tee,
perlarsen, sebastianene, seiden, smostafa, sumit.garg,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260617145130.3729015-1-sebastianene@google.com>
Prevent the pKVM hypervisor from making assumptions that the
endpoint memory access descriptor (EMAD) comes right after the
FF-A memory region header.
Prior to FF-A version 1.1 the header of the memory region
didn't contain an offset to the endpoint memory access descriptor.
The layout of a memory transaction looks like this from 1.1 onward:
Type | Field name | Offset
[ Header | ffa_mem_region | 0
EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset
]
Verify that the offset to the first endpoint memory access descriptor
is within the mailbox buffer bounds.
Also, fix one hardcoded sizeof(struct ffa_mem_region_attributes) that
should be replaced ffa_emad_size_get() for compatibility with FFA v1.0.
Fixes: 42fb33dde42b ("KVM: arm64: Use FF-A 1.1 with pKVM")
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 2d211661952e..1a2abd0154c6 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -476,11 +476,14 @@ static void __do_ffa_mem_xfer(const u64 func_id,
DECLARE_REG(u32, fraglen, ctxt, 2);
DECLARE_REG(u64, addr_mbz, ctxt, 3);
DECLARE_REG(u32, npages_mbz, ctxt, 4);
+ u32 offset, nr_ranges, checked_offset, em_mem_access_off;
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
struct ffa_mem_region *buf;
- u32 offset, nr_ranges, checked_offset;
int ret = 0;
+ size_t mem_region_len = !FFA_MEM_REGION_HAS_EP_MEM_OFFSET(hyp_ffa_version) ?
+ offsetof(struct ffa_mem_region, ep_mem_offset) :
+ sizeof(struct ffa_mem_region);
if (addr_mbz || npages_mbz || fraglen > len ||
fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
@@ -488,8 +491,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
goto out;
}
- if (fraglen < sizeof(struct ffa_mem_region) +
- sizeof(struct ffa_mem_region_attributes)) {
+ if (fraglen < mem_region_len + ffa_emad_size_get(hyp_ffa_version)) {
ret = FFA_RET_INVALID_PARAMETERS;
goto out;
}
@@ -508,8 +510,13 @@ static void __do_ffa_mem_xfer(const u64 func_id,
buf = hyp_buffers.tx;
memcpy(buf, host_buffers.tx, fraglen);
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
ret = FFA_RET_INVALID_PARAMETERS;
@@ -574,9 +581,9 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, handle_lo, ctxt, 1);
DECLARE_REG(u32, handle_hi, ctxt, 2);
DECLARE_REG(u32, flags, ctxt, 3);
+ u32 offset, len, fraglen, fragoff, em_mem_access_off;
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
- u32 offset, len, fraglen, fragoff;
struct ffa_mem_region *buf;
int ret = 0;
u64 handle;
@@ -599,8 +606,14 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
len = res->a1;
fraglen = res->a2;
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ ffa_rx_release(res);
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
/*
* We can trust the SPMD to get this right, but let's at least
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH v7 4/4] arm64: tegra: Reorder reg and reg-names to match bindings
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding
In-Reply-To: <20260617-tegra264-pcie-v7-0-eae7ae964629@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
The ECAM region cannot be the first entry in the "reg" property, because
in that case the unit-address wouldn't match the first entry. The order
of the nodes can also not be changed to match the ECAM entry because the
ECAM region is global and outside of any of the control busses.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v5:
- rebase onto v7.1-rc1
Changes in v4:
- revert ECAM "reg" entry order
Changes in v2:
- order ECAM "reg" entry before others
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 48 ++++++++++++++++----------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 8f4350c7793b..4c701abd25a8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3513,11 +3513,11 @@ cmdqv4: cmdqv@b200000 {
pci@c000000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xd0 0xb0000000 0x0 0x10000000>,
- <0x00 0x0c000000 0x0 0x00004000>,
+ reg = <0x00 0x0c000000 0x0 0x00004000>,
<0x00 0x0c004000 0x0 0x00001000>,
- <0x00 0x0c005000 0x0 0x00001000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri";
+ <0x00 0x0c005000 0x0 0x00001000>,
+ <0xd0 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3893,12 +3893,12 @@ gpio_uphy: gpio@8300000 {
pci@8400000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xa8 0xb0000000 0x0 0x10000000>,
- <0x00 0x08400000 0x0 0x00004000>,
+ reg = <0x00 0x08400000 0x0 0x00004000>,
<0x00 0x08404000 0x0 0x00001000>,
<0x00 0x08405000 0x0 0x00001000>,
- <0x00 0x08410000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08410000 0x0 0x00010000>,
+ <0xa8 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3925,12 +3925,12 @@ pci@8400000 {
pci@8420000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xb0 0xb0000000 0x0 0x10000000>,
- <0x00 0x08420000 0x0 0x00004000>,
+ reg = <0x00 0x08420000 0x0 0x00004000>,
<0x00 0x08424000 0x0 0x00001000>,
<0x00 0x08425000 0x0 0x00001000>,
- <0x00 0x08430000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08430000 0x0 0x00010000>,
+ <0xb0 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3957,12 +3957,12 @@ pci@8420000 {
pci@8440000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xb8 0xb0000000 0x0 0x10000000>,
- <0x00 0x08440000 0x0 0x00004000>,
+ reg = <0x00 0x08440000 0x0 0x00004000>,
<0x00 0x08444000 0x0 0x00001000>,
<0x00 0x08445000 0x0 0x00001000>,
- <0x00 0x08450000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08450000 0x0 0x00010000>,
+ <0xb8 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3989,12 +3989,12 @@ pci@8440000 {
pci@8460000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xc0 0xb0000000 0x0 0x10000000>,
- <0x00 0x08460000 0x0 0x00004000>,
+ reg = <0x00 0x08460000 0x0 0x00004000>,
<0x00 0x08464000 0x0 0x00001000>,
<0x00 0x08465000 0x0 0x00001000>,
- <0x00 0x08470000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08470000 0x0 0x00010000>,
+ <0xc0 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -4021,12 +4021,12 @@ pci@8460000 {
pci@8480000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xc8 0xb0000000 0x0 0x10000000>,
- <0x00 0x08480000 0x0 0x00004000>,
+ reg = <0x00 0x08480000 0x0 0x00004000>,
<0x00 0x08484000 0x0 0x00001000>,
<0x00 0x08485000 0x0 0x00001000>,
- <0x00 0x08490000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08490000 0x0 0x00010000>,
+ <0xc8 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.54.0
^ permalink raw reply related
* [PATCH v7 3/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <20260617-tegra264-pcie-v7-0-eae7ae964629@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
driver is very small, with its main purpose being to set up the address
translation registers and then creating a standard PCI host using ECAM.
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v7:
- select PCI_ECAM to satisfy the build dependency (Jonathan Hunter)
- remove pre-silicon support patch to avoid extra build dependency
Changes in v6:
- remove unneeded pm_runtime_disable() call (Sashiko)
- do not use noirq suspend/resume callbacks (Sashiko)
- wrap PM ops in pm_ptr() macro (Sashiko)
- use standard wait times with msleep() (Lukas Wunner)
- properly check errors for wake IRQs
- fix build failures /o\
Changes in v5:
- make PCIE_TEGRA264 symbol tristate
- drop dependency on PCI_MSI
- reorganize tegra264_pcie struct
- use standard wake-gpios property
- rename tegra264_pcie_bpmp_set_rp_state() to tegra264_pcie_power_off()
- use dev_err() instead of dev_info() for some error messages
- add clarifying comment as to why bandwidth requests aren't fatal
- address some compiler warnings on 32-bit physical address platforms
- drop needless comments
- explicitly deinitialize controller on suspend
- use devm_pm_runtime_active_enabled()
- rename "free" label to "free_ecam"
- use dev_err_probe() in more places
- reselect default pin state during resume, not probe
- return early on absence of wake GPIO
- simplify BW value calculation
Changes in v2:
- specify generations applicable for PCI_TEGRA driver to avoid confusion
- drop SPDX-FileCopyrightText tag
- rename link_state to link_up to clarify meaning
- replace memset() by an empty initializer
- sanity-check only enable BAR regions
- bring PCI link out of reset in case firmware didn't
- use common wait times instead of defining our own
- use core helpers to parse and print PCI link speed
- fix multi-line comment
- use dev_err_probe() more ubiquitously
- fix probe sequence and error cleanup
- use DEFINE_NOIRQ_DEV_PM_OPS() to avoid warnings for !PM_SUSPEND
- reuse more standard registers and remove unused register definitions
- use %pe and ERR_PTR() to print symbolic errors
- add signed-off-by from Manikanta as the original author
- add myself as author after significantly modifying the driver
pcie: remove pre-silicon conditionals
---
drivers/pci/controller/Kconfig | 10 +-
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-tegra264.c | 538 +++++++++++++++++++++++++++++++++
3 files changed, 548 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 2247709ef6d6..3045c8aecc7e 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -255,7 +255,15 @@ config PCI_TEGRA
select IRQ_MSI_LIB
help
Say Y here if you want support for the PCIe host controller found
- on NVIDIA Tegra SoCs.
+ on NVIDIA Tegra SoCs (Tegra20 through Tegra186).
+
+config PCIE_TEGRA264
+ tristate "NVIDIA Tegra264 PCIe controller"
+ depends on ARCH_TEGRA || COMPILE_TEST
+ select PCI_ECAM
+ help
+ Say Y here if you want support for the PCIe host controller found
+ on NVIDIA Tegra264 SoCs.
config PCIE_RCAR_HOST
bool "Renesas R-Car PCIe controller (host mode)"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index ac8db283f0fe..d478743b5142 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PCI_HYPERV_INTERFACE) += pci-hyperv-intf.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
+obj-$(CONFIG_PCIE_TEGRA264) += pcie-tegra264.o
obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
obj-$(CONFIG_PCIE_RCAR_HOST) += pcie-rcar.o pcie-rcar-host.o
obj-$(CONFIG_PCIE_RCAR_EP) += pcie-rcar.o pcie-rcar-ep.o
diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
new file mode 100644
index 000000000000..e2d295ea4403
--- /dev/null
+++ b/drivers/pci/controller/pcie-tegra264.c
@@ -0,0 +1,538 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PCIe host controller driver for Tegra264 SoC
+ *
+ * Copyright (c) 2022-2026, NVIDIA CORPORATION. All rights reserved.
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/init.h>
+#include <linux/interconnect.h>
+#include <linux/interrupt.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci-ecam.h>
+#include <linux/pci.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/pm_wakeirq.h>
+
+#include <soc/tegra/bpmp.h>
+#include <soc/tegra/bpmp-abi.h>
+#include <soc/tegra/fuse.h>
+
+#include "../pci.h"
+
+/* XAL registers */
+#define XAL_RC_ECAM_BASE_HI 0x00
+#define XAL_RC_ECAM_BASE_LO 0x04
+#define XAL_RC_ECAM_BUSMASK 0x08
+#define XAL_RC_IO_BASE_HI 0x0c
+#define XAL_RC_IO_BASE_LO 0x10
+#define XAL_RC_IO_LIMIT_HI 0x14
+#define XAL_RC_IO_LIMIT_LO 0x18
+#define XAL_RC_MEM_32BIT_BASE_HI 0x1c
+#define XAL_RC_MEM_32BIT_BASE_LO 0x20
+#define XAL_RC_MEM_32BIT_LIMIT_HI 0x24
+#define XAL_RC_MEM_32BIT_LIMIT_LO 0x28
+#define XAL_RC_MEM_64BIT_BASE_HI 0x2c
+#define XAL_RC_MEM_64BIT_BASE_LO 0x30
+#define XAL_RC_MEM_64BIT_LIMIT_HI 0x34
+#define XAL_RC_MEM_64BIT_LIMIT_LO 0x38
+#define XAL_RC_BAR_CNTL_STANDARD 0x40
+#define XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN BIT(0)
+#define XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN BIT(1)
+#define XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN BIT(2)
+
+/* XTL registers */
+#define XTL_RC_PCIE_CFG_LINK_STATUS 0x5a
+
+#define XTL_RC_MGMT_PERST_CONTROL 0x218
+#define XTL_RC_MGMT_PERST_CONTROL_PERST_O_N BIT(0)
+
+#define XTL_RC_MGMT_CLOCK_CONTROL 0x47c
+#define XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT BIT(9)
+
+struct tegra264_pcie {
+ struct device *dev;
+
+ /* I/O memory */
+ void __iomem *xal;
+ void __iomem *xtl;
+ void __iomem *ecam;
+
+ /* bridge configuration */
+ struct pci_config_window *cfg;
+ struct pci_host_bridge *bridge;
+
+ /* wake IRQ */
+ struct gpio_desc *wake_gpio;
+ unsigned int wake_irq;
+
+ /* BPMP and bandwidth management */
+ struct icc_path *icc_path;
+ struct tegra_bpmp *bpmp;
+ u32 ctl_id;
+
+ bool link_up;
+};
+
+static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
+{
+ struct device *dev = pcie->dev;
+ int err;
+
+ pcie->wake_gpio = devm_gpiod_get_optional(dev, "wake", GPIOD_IN);
+ if (IS_ERR(pcie->wake_gpio))
+ return PTR_ERR(pcie->wake_gpio);
+
+ if (!pcie->wake_gpio)
+ return 0;
+
+ err = gpiod_to_irq(pcie->wake_gpio);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to get wake IRQ\n");
+
+ pcie->wake_irq = (unsigned int)err;
+
+ err = devm_device_init_wakeup(dev);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to initialize wakeup\n");
+
+ err = devm_pm_set_wake_irq(dev, pcie->wake_irq);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to set wakeup IRQ\n");
+
+ return 0;
+}
+
+static void tegra264_pcie_power_off(struct tegra264_pcie *pcie)
+{
+ struct tegra_bpmp_message msg = {};
+ struct mrq_pcie_request req = {};
+ int err;
+
+ req.cmd = CMD_PCIE_RP_CONTROLLER_OFF;
+ req.rp_ctrlr_off.rp_controller = pcie->ctl_id;
+
+ msg.mrq = MRQ_PCIE;
+ msg.tx.data = &req;
+ msg.tx.size = sizeof(req);
+
+ err = tegra_bpmp_transfer(pcie->bpmp, &msg);
+ if (err)
+ dev_err(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
+ pcie->ctl_id, ERR_PTR(err));
+
+ if (msg.rx.ret)
+ dev_err(pcie->dev, "failed to turn off PCIe #%u: %d\n",
+ pcie->ctl_id, msg.rx.ret);
+}
+
+static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
+{
+ u32 value, speed, width;
+ int err;
+
+ value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
+ speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
+ width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
+
+ value = Mbps_to_icc(width * PCIE_SPEED2MBS_ENC(pcie_link_speed[speed]));
+
+ /*
+ * We don't want to error out here because a boot-critical device
+ * could be connected to this root port. Failure to set the bandwidth
+ * request may have an adverse impact on performance, but it is not
+ * generally fatal, so we opt to continue regardless so that users
+ * get a chance to fix things.
+ */
+ err = icc_set_bw(pcie->icc_path, value, value);
+ if (err < 0)
+ dev_err(pcie->dev,
+ "failed to request bandwidth (%u MBps): %pe\n",
+ value, ERR_PTR(err));
+}
+
+/*
+ * The various memory regions used by the controller (I/O, memory, ECAM) are
+ * set up during early boot and have hardware-level protections in place. If
+ * the DT ranges don't match what's been setup, the controller won't be able
+ * to write the address endpoints properly, so make sure to validate that DT
+ * and firmware programming agree on these ranges.
+ */
+static bool tegra264_pcie_check_ranges(struct platform_device *pdev)
+{
+ struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
+ struct device_node *np = pcie->dev->of_node;
+ struct of_pci_range_parser parser;
+ phys_addr_t phys, limit, hi, lo;
+ struct of_pci_range range;
+ struct resource *res;
+ bool status = true;
+ u32 value;
+ int err;
+
+ err = of_pci_range_parser_init(&parser, np);
+ if (err < 0)
+ return false;
+
+ for_each_of_pci_range(&parser, &range) {
+ unsigned int addr_hi, addr_lo, limit_hi, limit_lo, enable;
+ unsigned long type = range.flags & IORESOURCE_TYPE_BITS;
+ phys_addr_t start, end, mask;
+ const char *region = NULL;
+
+ end = range.cpu_addr + range.size - 1;
+ start = range.cpu_addr;
+
+ switch (type) {
+ case IORESOURCE_IO:
+ addr_hi = XAL_RC_IO_BASE_HI;
+ addr_lo = XAL_RC_IO_BASE_LO;
+ limit_hi = XAL_RC_IO_LIMIT_HI;
+ limit_lo = XAL_RC_IO_LIMIT_LO;
+ enable = XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN;
+ mask = SZ_64K - 1;
+ region = "I/O";
+ break;
+
+ case IORESOURCE_MEM:
+ if (range.flags & IORESOURCE_PREFETCH) {
+ addr_hi = XAL_RC_MEM_64BIT_BASE_HI;
+ addr_lo = XAL_RC_MEM_64BIT_BASE_LO;
+ limit_hi = XAL_RC_MEM_64BIT_LIMIT_HI;
+ limit_lo = XAL_RC_MEM_64BIT_LIMIT_LO;
+ enable = XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN;
+ region = "prefetchable memory";
+ } else {
+ addr_hi = XAL_RC_MEM_32BIT_BASE_HI;
+ addr_lo = XAL_RC_MEM_32BIT_BASE_LO;
+ limit_hi = XAL_RC_MEM_32BIT_LIMIT_HI;
+ limit_lo = XAL_RC_MEM_32BIT_LIMIT_LO;
+ enable = XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN;
+ region = "memory";
+ }
+
+ mask = SZ_1M - 1;
+ break;
+ }
+
+ /* not interested in anything that's not I/O or memory */
+ if (!region)
+ continue;
+
+ /* don't check regions that haven't been enabled */
+ value = readl(pcie->xal + XAL_RC_BAR_CNTL_STANDARD);
+ if ((value & enable) == 0)
+ continue;
+
+ hi = readl(pcie->xal + addr_hi);
+ lo = readl(pcie->xal + addr_lo);
+ phys = ((hi << 16) << 16) | lo;
+
+ hi = readl(pcie->xal + limit_hi);
+ lo = readl(pcie->xal + limit_lo);
+ limit = ((hi << 16) << 16) | lo | mask;
+
+ if (phys != start || limit != end) {
+ dev_err(pcie->dev,
+ "%s region mismatch: %pap-%pap -> %pap-%pap\n",
+ region, &phys, &limit, &start, &end);
+ status = false;
+ }
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
+ if (!res)
+ return false;
+
+ hi = readl(pcie->xal + XAL_RC_ECAM_BASE_HI);
+ lo = readl(pcie->xal + XAL_RC_ECAM_BASE_LO);
+ phys = ((hi << 16) << 16) | lo;
+
+ value = readl(pcie->xal + XAL_RC_ECAM_BUSMASK);
+ limit = phys + ((value + 1) << 20) - 1;
+
+ if (phys != res->start || limit != res->end) {
+ dev_err(pcie->dev,
+ "ECAM region mismatch: %pap-%pap -> %pap-%pap\n",
+ &phys, &limit, &res->start, &res->end);
+ status = false;
+ }
+
+ return status;
+}
+
+static bool tegra264_pcie_link_up(struct tegra264_pcie *pcie,
+ enum pci_bus_speed *speed)
+{
+ u16 value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
+
+ if (value & PCI_EXP_LNKSTA_DLLLA) {
+ if (speed)
+ *speed = pcie_link_speed[FIELD_GET(PCI_EXP_LNKSTA_CLS,
+ value)];
+
+ return true;
+ }
+
+ return false;
+}
+
+static void tegra264_pcie_init(struct tegra264_pcie *pcie)
+{
+ enum pci_bus_speed speed;
+ unsigned int i;
+ u32 value;
+
+ /* bring the endpoint out of reset */
+ value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+ value |= XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
+ writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+
+ for (i = 0; i < PCIE_LINK_WAIT_MAX_RETRIES; i++) {
+ if (tegra264_pcie_link_up(pcie, NULL))
+ break;
+
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
+ }
+
+ if (tegra264_pcie_link_up(pcie, &speed)) {
+ msleep(PCIE_RESET_CONFIG_WAIT_MS);
+ dev_info(pcie->dev, "PCIe #%u link is up (speed: %s)\n",
+ pcie->ctl_id, pci_speed_string(speed));
+ tegra264_pcie_icc_set(pcie);
+ pcie->link_up = true;
+ } else {
+ dev_info(pcie->dev, "PCIe #%u link is down\n", pcie->ctl_id);
+
+ value = readl(pcie->xtl + XTL_RC_MGMT_CLOCK_CONTROL);
+
+ /*
+ * Set link state only when link fails and no hot-plug feature
+ * is present.
+ */
+ if ((value & XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT) == 0) {
+ dev_info(pcie->dev,
+ "PCIe #%u link is down and not hotplug-capable, turning off\n",
+ pcie->ctl_id);
+ tegra264_pcie_power_off(pcie);
+ pcie->link_up = false;
+ } else {
+ pcie->link_up = true;
+ }
+ }
+}
+
+static void tegra264_pcie_deinit(struct tegra264_pcie *pcie)
+{
+ u32 value;
+
+ /* take the endpoint into reset */
+ value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+ value &= ~XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
+ writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+}
+
+static int tegra264_pcie_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pci_host_bridge *bridge;
+ struct tegra264_pcie *pcie;
+ struct resource_entry *bus;
+ struct resource *res;
+ int err;
+
+ bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct tegra264_pcie));
+ if (!bridge)
+ return dev_err_probe(dev, -ENOMEM,
+ "failed to allocate host bridge\n");
+
+ pcie = pci_host_bridge_priv(bridge);
+ platform_set_drvdata(pdev, pcie);
+ pcie->bridge = bridge;
+ pcie->dev = dev;
+
+ err = tegra264_pcie_parse_dt(pcie);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to parse device tree\n");
+
+ pcie->xal = devm_platform_ioremap_resource_byname(pdev, "xal");
+ if (IS_ERR(pcie->xal))
+ return dev_err_probe(dev, PTR_ERR(pcie->xal),
+ "failed to map XAL memory\n");
+
+ pcie->xtl = devm_platform_ioremap_resource_byname(pdev, "xtl-pri");
+ if (IS_ERR(pcie->xtl))
+ return dev_err_probe(dev, PTR_ERR(pcie->xtl),
+ "failed to map XTL-PRI memory\n");
+
+ bus = resource_list_first_type(&bridge->windows, IORESOURCE_BUS);
+ if (!bus)
+ return dev_err_probe(dev, -ENODEV,
+ "failed to get bus resources\n");
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
+ if (!res)
+ return dev_err_probe(dev, -ENXIO,
+ "failed to get ECAM resource\n");
+
+ pcie->icc_path = devm_of_icc_get(dev, "write");
+ if (IS_ERR(pcie->icc_path))
+ return dev_err_probe(dev, PTR_ERR(pcie->icc_path),
+ "failed to get ICC\n");
+
+ pcie->bpmp = tegra_bpmp_get_with_id(dev, &pcie->ctl_id);
+ if (IS_ERR(pcie->bpmp))
+ return dev_err_probe(dev, PTR_ERR(pcie->bpmp),
+ "failed to get BPMP\n");
+
+ err = devm_pm_runtime_set_active_enabled(dev);
+ if (err < 0) {
+ dev_err_probe(dev, err, "failed to enable runtime PM\n");
+ goto put_bpmp;
+ }
+
+ err = pm_runtime_get_sync(dev);
+ if (err < 0) {
+ dev_err_probe(dev, err, "failed to power on device\n");
+ goto put_bpmp;
+ }
+
+ /* sanity check that programmed ranges match what's in DT */
+ if (!tegra264_pcie_check_ranges(pdev)) {
+ err = -EINVAL;
+ goto put_pm;
+ }
+
+ pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
+ if (IS_ERR(pcie->cfg)) {
+ err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
+ "failed to create ECAM\n");
+ goto put_pm;
+ }
+
+ bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
+ bridge->sysdata = pcie->cfg;
+ pcie->ecam = pcie->cfg->win;
+
+ tegra264_pcie_init(pcie);
+
+ if (!pcie->link_up)
+ return 0;
+
+ err = pci_host_probe(bridge);
+ if (err < 0) {
+ dev_err_probe(dev, err, "failed to register host\n");
+ goto free_ecam;
+ }
+
+ return 0;
+
+free_ecam:
+ pci_ecam_free(pcie->cfg);
+put_pm:
+ pm_runtime_put_sync(dev);
+put_bpmp:
+ tegra_bpmp_put(pcie->bpmp);
+
+ return err;
+}
+
+static void tegra264_pcie_remove(struct platform_device *pdev)
+{
+ struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
+
+ /*
+ * If we undo tegra264_pcie_init() then link goes down and need
+ * controller reset to bring up the link again. Remove intention is
+ * to clean up the root bridge and re-enumerate during bind.
+ */
+ pci_lock_rescan_remove();
+ pci_stop_root_bus(pcie->bridge->bus);
+ pci_remove_root_bus(pcie->bridge->bus);
+ pci_unlock_rescan_remove();
+
+ pm_runtime_put_sync(&pdev->dev);
+ tegra_bpmp_put(pcie->bpmp);
+ pci_ecam_free(pcie->cfg);
+}
+
+static int tegra264_pcie_suspend(struct device *dev)
+{
+ struct tegra264_pcie *pcie = dev_get_drvdata(dev);
+ int err;
+
+ tegra264_pcie_deinit(pcie);
+
+ if (pcie->wake_gpio && device_may_wakeup(dev)) {
+ err = enable_irq_wake(pcie->wake_irq);
+ if (err < 0)
+ dev_err(dev, "failed to enable wake IRQ: %pe\n",
+ ERR_PTR(err));
+ }
+
+ return 0;
+}
+
+static int tegra264_pcie_resume(struct device *dev)
+{
+ struct tegra264_pcie *pcie = dev_get_drvdata(dev);
+ int err;
+
+ err = pinctrl_pm_select_default_state(dev);
+ if (err < 0)
+ dev_err(dev, "failed to configure sideband pins: %pe\n",
+ ERR_PTR(err));
+
+ if (pcie->wake_gpio && device_may_wakeup(dev)) {
+ err = disable_irq_wake(pcie->wake_irq);
+ if (err < 0)
+ dev_err(dev, "failed to disable wake IRQ: %pe\n",
+ ERR_PTR(err));
+ }
+
+ if (pcie->link_up == false)
+ return 0;
+
+ tegra264_pcie_init(pcie);
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(tegra264_pcie_pm_ops,
+ tegra264_pcie_suspend,
+ tegra264_pcie_resume);
+
+static const struct of_device_id tegra264_pcie_of_match[] = {
+ {
+ .compatible = "nvidia,tegra264-pcie",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tegra264_pcie_of_match);
+
+static struct platform_driver tegra264_pcie_driver = {
+ .probe = tegra264_pcie_probe,
+ .remove = tegra264_pcie_remove,
+ .driver = {
+ .name = "tegra264-pcie",
+ .pm = pm_ptr(&tegra264_pcie_pm_ops),
+ .of_match_table = tegra264_pcie_of_match,
+ },
+};
+module_platform_driver(tegra264_pcie_driver);
+
+MODULE_AUTHOR("Manikanta Maddireddy <mmaddireddy@nvidia.com>");
+MODULE_AUTHOR("Thierry Reding <treding@nvidia.com>");
+MODULE_DESCRIPTION("NVIDIA Tegra264 PCIe host controller driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v7 2/4] PCI: Use standard wait times for PCIe link monitoring
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding
In-Reply-To: <20260617-tegra264-pcie-v7-0-eae7ae964629@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Instead of defining the wait values for each driver, use common values
defined in the core pci.h header file. Note that while most drivers use
the usleep_range(), it looks like these were mostly cargo culted and
msleep() is a better choice given the fixed delay that the specification
calls for. Convert all drivers to msleep() and use the existing
definition.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v7:
- rebase on top of next-20260615 (resolve pci-aardvark.c conflict)
Changes in v6:
- convert all drivers to use msleep() (Lukas Wunner)
Changes in v2:
- fix build for Cadence
---
drivers/pci/controller/cadence/pcie-cadence-host-common.c | 6 ++++--
drivers/pci/controller/cadence/pcie-cadence-lga-regs.h | 5 -----
drivers/pci/controller/mobiveil/pcie-mobiveil.c | 4 ++--
drivers/pci/controller/mobiveil/pcie-mobiveil.h | 5 -----
drivers/pci/controller/pci-aardvark.c | 7 ++-----
drivers/pci/controller/pcie-xilinx-nwl.c | 9 ++-------
drivers/pci/controller/plda/pcie-starfive.c | 9 ++-------
7 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
index 18e4b6c760b5..0ef4396151b4 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
@@ -16,6 +16,8 @@
#include "pcie-cadence-host-common.h"
#include "../pci-host-common.h"
+#include "../../pci.h"
+
#define LINK_RETRAIN_TIMEOUT HZ
u64 bar_max_size[] = {
@@ -54,12 +56,12 @@ int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie,
int retries;
/* Check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (pcie_link_up(pcie)) {
dev_info(dev, "Link up\n");
return 0;
}
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
return -ETIMEDOUT;
diff --git a/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h b/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h
index 857b2140c5d2..15dc4fcaf45d 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h
+++ b/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h
@@ -10,11 +10,6 @@
#include <linux/bitfield.h>
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
-
/* Local Management Registers */
#define CDNS_PCIE_LM_BASE 0x00100000
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.c b/drivers/pci/controller/mobiveil/pcie-mobiveil.c
index 62ecbaeb0a60..e8346851c49b 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.c
@@ -218,11 +218,11 @@ int mobiveil_bringup_link(struct mobiveil_pcie *pcie)
int retries;
/* check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (mobiveil_pcie_link_up(pcie))
return 0;
- usleep_range(LINK_WAIT_MIN, LINK_WAIT_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
dev_err(&pcie->pdev->dev, "link never came up\n");
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index 7246de6a7176..11010a99e27c 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -122,11 +122,6 @@
#define IB_WIN_SIZE ((u64)256 * 1024 * 1024 * 1024)
#define MAX_PIO_WINDOWS 8
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_MIN 90000
-#define LINK_WAIT_MAX 100000
-
#define PAGED_ADDR_BNDRY 0xc00
#define OFFSET_TO_PAGE_ADDR(off) \
((off & PAGE_LO_MASK) | PAGED_ADDR_BNDRY)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fd9c7d53e8a7..272c5c8fc1e5 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -256,9 +256,6 @@ enum {
#define PIO_RETRY_CNT 750000 /* 1.5 s */
#define PIO_RETRY_DELAY 2 /* 2 us*/
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
#define RETRAIN_WAIT_MAX_RETRIES 10
#define RETRAIN_WAIT_USLEEP_US 2000
@@ -350,13 +347,13 @@ static int advk_pcie_wait_for_link(struct advk_pcie *pcie)
int retries;
/* check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (advk_pcie_link_up(pcie)) {
pci_host_common_link_train_delay(pcie->link_gen);
return 0;
}
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
return -ETIMEDOUT;
diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
index 7db2c96c6cec..0dee19fa24ca 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -140,11 +140,6 @@
#define PCIE_PHY_LINKUP_BIT BIT(0)
#define PHY_RDY_LINKUP_BIT BIT(1)
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
-
struct nwl_msi { /* MSI information */
DECLARE_BITMAP(bitmap, INT_PCI_MSI_NR);
struct irq_domain *dev_domain;
@@ -203,10 +198,10 @@ static int nwl_wait_for_link(struct nwl_pcie *pcie)
int retries;
/* check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (nwl_phy_link_up(pcie))
return 0;
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
dev_err(dev, "PHY link never came up\n");
diff --git a/drivers/pci/controller/plda/pcie-starfive.c b/drivers/pci/controller/plda/pcie-starfive.c
index 298036c3e7f9..2835c7af965e 100644
--- a/drivers/pci/controller/plda/pcie-starfive.c
+++ b/drivers/pci/controller/plda/pcie-starfive.c
@@ -45,11 +45,6 @@
#define STG_SYSCON_LNKSTA_OFFSET 0x170
#define DATA_LINK_ACTIVE BIT(5)
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
-
struct starfive_jh7110_pcie {
struct plda_pcie_rp plda;
struct reset_control *resets;
@@ -217,12 +212,12 @@ static int starfive_pcie_host_wait_for_link(struct starfive_jh7110_pcie *pcie)
int retries;
/* Check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (starfive_pcie_link_up(&pcie->plda)) {
dev_info(pcie->plda.dev, "port link up\n");
return 0;
}
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
return -ETIMEDOUT;
--
2.54.0
^ 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