* Re: [PATCH v7 10/20] KVM: arm64: Context swap Partitioned PMU guest registers
From: Colton Lewis @ 2026-05-14 18:59 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agRBzkVcR-qZZdx2@kernel.org>
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:03PM +0000, Colton Lewis wrote:
>> +
>> +/**
>> + * kvm_pmu_host_counter_mask() - Compute bitmask of host-reserved
>> counters
>> + * @pmu: Pointer to arm_pmu struct
>> + *
>> + * Compute the bitmask that selects the host-reserved counters in the
>> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
>> + * in HPMN..N
>> + *
>> + * Return: Bitmask
>> + */
>> +u64 kvm_pmu_host_counter_mask(struct arm_pmu *pmu)
>> +{
>> + u8 nr_counters = *host_data_ptr(nr_event_counters);
>> +
>> + if (kvm_pmu_is_partitioned(pmu))
>> + return GENMASK(nr_counters - 1, pmu->max_guest_counters);
>> +
>> + return ARMV8_PMU_CNT_MASK_ALL;
>> +}
>> +
>> +/**
>> + * kvm_pmu_guest_counter_mask() - Compute bitmask of guest-reserved
>> counters
>> + * @pmu: Pointer to arm_pmu struct
>> + *
>> + * Compute the bitmask that selects the guest-reserved counters in the
>> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
>> + * in 0..HPMN and the cycle and instruction counters.
>> + *
>> + * Return: Bitmask
>> + */
>> +u64 kvm_pmu_guest_counter_mask(struct arm_pmu *pmu)
>> +{
>> + if (kvm_pmu_is_partitioned(pmu))
>> + return ARMV8_PMU_CNT_MASK_C | GENMASK(pmu->max_guest_counters - 1, 0);
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * kvm_pmu_load() - Load untrapped PMU registers
>> + * @vcpu: Pointer to struct kvm_vcpu
>> + *
>> + * Load all untrapped PMU registers from the VCPU into the PCPU. Mask
>> + * to only bits belonging to guest-reserved counters and leave
>> + * host-reserved counters alone in bitmask registers.
>> + */
>> +void kvm_pmu_load(struct kvm_vcpu *vcpu)
>> +{
>> + struct arm_pmu *pmu;
>> + unsigned long guest_counters;
>> + u64 mask;
>> + u8 i;
>> + u64 val;
>> +
>> + /*
>> + * If we aren't guest-owned then we know the guest isn't using
>> + * the PMU anyway, so no need to bother with the swap.
>> + */
>> + if (!kvm_vcpu_pmu_is_partitioned(vcpu))
>> + return;
>> +
>> + preempt_disable();
>> +
>> + pmu = vcpu->kvm->arch.arm_pmu;
>> + guest_counters = kvm_pmu_guest_counter_mask(pmu);
>> +
>> + for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
>> + val = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i);
>> +
>> + if (i == ARMV8_PMU_CYCLE_IDX) {
>> + write_sysreg(val, pmccntr_el0);
>> + } else {
>> + write_sysreg(i, pmselr_el0);
>> + write_sysreg(val, pmxevcntr_el0);
> This is wrong, you would need an intervening ISB. It'd be better to
> avoid the ISB altogether and just use {read,write}_pmevcntrn().
Good catch, I was using {read,write}_pmevcntrn here before but changed
it after your feedback that:
> I'd prefer KVM directly accessed the PMU registers to
> avoid the possibility of taking some instrumented codepath in the
> future.
https://lore.kernel.org/kvm/aUH7oC41XaEMsXf_@kernel.org/
I assume this is a compromise with that.
^ permalink raw reply
* Re: [PATCH v2] soc: ti: knav_qmss_queue: Implement resource cleanup in remove()
From: Md Shofiqul Islam @ 2026-05-14 18:58 UTC (permalink / raw)
To: nm; +Cc: ssantosh, linux-arm-kernel, linux-kernel
In-Reply-To: <20260506154114.2288-1-shofiqtest@gmail.com>
Hi Nishanth,
Gentle ping on this patch. You suggested this fix — the patch
implements exactly what was discussed: stopping PDSPs and freeing
queue regions and queue ranges before disabling runtime PM,
mirroring the cleanup already done in the probe error path, and
setting device_ready to false before teardown.
Could you take a look and provide an Acked-by if it looks correct?
The patch has been waiting since November 2025 across several
versions with no reviewer feedback.
Link: https://lore.kernel.org/linux-arm-kernel/20260506154114.2288-1-shofiqtest@gmail.com/
Thanks,
Shofiq
^ permalink raw reply
* Re: [PATCH v7 09/20] KVM: arm64: Set up MDCR_EL2 to handle a Partitioned PMU
From: Colton Lewis @ 2026-05-14 18:43 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agQu9kLnbHjSni-C@kernel.org>
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:02PM +0000, Colton Lewis wrote:
>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
>> index 3ad6b7c6e4ba7..0ab89c91e19cb 100644
>> --- a/arch/arm64/kvm/debug.c
>> +++ b/arch/arm64/kvm/debug.c
>> @@ -36,20 +36,43 @@ static int cpu_has_spe(u64 dfr0)
>> */
>> static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)
>> {
>> + int hpmn = kvm_pmu_hpmn(vcpu);
>> +
>> preempt_disable();
>> /*
>> * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK
>> * to disable guest access to the profiling and trace buffers
>> */
>> - vcpu->arch.mdcr_el2 = FIELD_PREP(MDCR_EL2_HPMN,
>> - *host_data_ptr(nr_event_counters));
>> +
>> + vcpu->arch.mdcr_el2 = FIELD_PREP(MDCR_EL2_HPMN, hpmn);
>> vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
>> MDCR_EL2_TPMS |
>> MDCR_EL2_TTRF |
>> MDCR_EL2_TPMCR |
>> MDCR_EL2_TDRA |
>> - MDCR_EL2_TDOSA);
>> + MDCR_EL2_TDOSA |
>> + MDCR_EL2_HPME);
>> +
>> + if (kvm_vcpu_pmu_is_partitioned(vcpu)) {
>> + /*
>> + * Filtering these should be redundant because we trap
>> + * all the TYPER and FILTR registers anyway and ensure
>> + * they filter EL2, but set the bits if they are here.
>> + */
>> + if (is_pmuv3p1(read_pmuver()))
>> + vcpu->arch.mdcr_el2 |= MDCR_EL2_HPMD;
>> + if (is_pmuv3p5(read_pmuver()))
>> + vcpu->arch.mdcr_el2 |= MDCR_EL2_HCCD;
> Neither of these controls are of any consequence on unsupported
> hardware (RES0). Set them unconditionally?
Sure.
>> + /*
>> + * Take out the coarse grain traps if we are using
>> + * fine grain traps.
>> + */
>> + if (kvm_vcpu_pmu_use_fgt(vcpu))
> I think open coding the check here would actually improve readability.
> if (cpus_have_final_cap(ARM64_HAS_FGT) &&
> (cpus_have_final_cap(ARM64_HAS_HPMN0) ||
> vcpu->kvm->arch.nr_pmu_counters != 0))
> vcpu->arch.mdcr_el2 &= ~(MDCR_EL2_TPM | MDCR_EL2_TPMCR);
I disagree but I'll do it.
>> +
>> +/**
>> + * kvm_pmu_hpmn() - Calculate HPMN field value
>> + * @vcpu: Pointer to struct kvm_vcpu
>> + *
>> + * Calculate the appropriate value to set for MDCR_EL2.HPMN. If
>> + * partitioned, this is the number of counters set for the guest if
>> + * supported, falling back to max_guest_counters if needed. If we are
>> not
>> + * partitioned or can't set the implied HPMN value, fall back to the
>> + * host value.
>> + *
>> + * Return: A valid HPMN value
>> + */
>> +u8 kvm_pmu_hpmn(struct kvm_vcpu *vcpu)
>> +{
>> + u8 nr_guest_cntr = vcpu->kvm->arch.nr_pmu_counters;
>> +
>> + if (kvm_vcpu_pmu_is_partitioned(vcpu)
>> + && !vcpu_on_unsupported_cpu(vcpu)
>> + && (cpus_have_final_cap(ARM64_HAS_HPMN0) || nr_guest_cntr > 0))
>> + return nr_guest_cntr;
>> +
>> + return *host_data_ptr(nr_event_counters);
>> +}
> This helper isn't helpful. Just open code it in the place where we are
> computing MDCR_EL2.
I disagree but I'll do it.
>> @@ -542,6 +542,13 @@ u8 kvm_arm_pmu_get_max_counters(struct kvm *kvm)
>> if (cpus_have_final_cap(ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS))
>> return 1;
>> + /*
>> + * If partitioned then we are limited by the max counters in
>> + * the guest partition.
>> + */
>> + if (kvm_pmu_is_partitioned(arm_pmu))
>> + return arm_pmu->max_guest_counters;
>> +
> Ok, this is exactly what I was getting at earlier. What about a VM with
> an emulated PMU? It should use cntr_mask calculation, not the guest
> range.
True. I should use something different here.
> Thanks,
> Oliver
^ permalink raw reply
* Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts
From: Sudeep Holla @ 2026-05-14 18:42 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Alex Tran, Sudeep Holla, Jyoti Bhayana, David Lechner,
Nuno Sá, Andy Shevchenko, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <20260514164422.0eba9a61@jic23-huawei>
On Thu, May 14, 2026 at 04:44:22PM +0100, Jonathan Cameron wrote:
> On Wed, 13 May 2026 10:16:53 -0700
> Alex Tran <alex.tran@oss.qualcomm.com> wrote:
>
> > SCMI client drivers do not consistently log the number of supported
> > entities discovered from firmware. This information is useful during
> > debugging because it shows which domains or resources were exposed by
> > firmware during probe.
> >
> > Add logging of the number of supported entities to the SCMI cpufreq,
> > pinctrl, reset, hwmon, and powercap client drivers after a successful
> > probe. This aligns these drivers with the existing logging in the SCMI
> > power and performance domain drivers.
> >
> > Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
> Hi Alex,
>
> Just curious but why +CC linux-iio and IIO folk?
>
> May be you had a false suggestion to add them from get maintainers.
> If so be sure to check it's suggestions make sense!
>
My guess, the intention was to add similar logging in scmi_iio_dev_probe()
as well, may have got dropped {un/}intentionally, but the list remained
in place. The author of the driver is also cc-ed.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms
From: Frank Li @ 2026-05-14 18:38 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Sascha Hauer,
Fabio Estevam, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pengutronix Kernel Team, linux-arm-kernel, imx, devicetree,
linux-kernel, NXP S32 Linux, Christophe Lizzi, Alberto Ruiz,
Enric Balletbo
In-Reply-To: <20260514070605.996462-3-khristineandreea.barbulescu@oss.nxp.com>
On Thu, May 14, 2026 at 09:06:05AM +0200, Khristine Andreea Barbulescu wrote:
> Add devicetree binding example for the PIT timer as used on
> NXP S32G2 and S32G3 platforms.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
> .../devicetree/bindings/timer/fsl,vf610-pit.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> index 42e130654d58..8696696776b3 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> +++ b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> @@ -57,3 +57,11 @@ examples:
> clocks = <&clks VF610_CLK_PIT>;
> clock-names = "pit";
> };
> +
> + pit@40188000 {
> + compatible = "nxp,s32g2-pit";
> + reg = <0x40188000 0x3000>;
> + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + };
Needn't change example
Frank
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
From: Conor Dooley @ 2026-05-14 18:19 UTC (permalink / raw)
To: Prasanth Kumar Padarthi
Cc: joel, andrew, robh, krzk+dt, conor+dt, devicetree, linux-aspeed,
linux-arm-kernel
In-Reply-To: <20260514031622.1416922-2-prasanth.padarthi10@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 2/3] dt-bindings: display: bridge: analogix-dp: Add data-lanes support for endpoint
From: Conor Dooley @ 2026-05-14 18:19 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260514070133.2275069-3-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
On Thu, May 14, 2026 at 03:01:32PM +0800, Damon Ding wrote:
> Add data-lanes property support to the port@1 endpoint for physical
> lane mapping configuration.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> ---
> .../bindings/display/bridge/analogix,dp.yaml | 24 +++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> index 62f0521b0924..a82f9b7776c0 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> @@ -36,19 +36,35 @@ properties:
> Hotplug detect GPIO.
> Indicates which GPIO should be used for hotplug detection
>
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + deprecated: true
Why are you adding a new property as deprecated? Why does this duplicate
what you're adding to the port node? At the very least, your commit is
lacking an explanation.
pw-bot: changes-requested
Cheers,
Conor.
> + minItems: 1
> + maxItems: 4
> + items:
> + maximum: 3
> +
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> properties:
> port@0:
> $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Input node to receive pixel data.
> + description: Input node to receive pixel data.
>
> port@1:
> $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Port node with one endpoint connected to a dp-connector node.
> + description: Port node with one endpoint connected to sink device node.
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> + items:
> + enum: [ 0, 1, 2, 3 ]
>
> required:
> - port@0
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 08/20] KVM: arm64: Add Partitioned PMU register trap handlers
From: Colton Lewis @ 2026-05-14 18:18 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agQsM7XFsbxbFRLO@kernel.org>
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:01PM +0000, Colton Lewis wrote:
>> We may want a partitioned PMU but not have FEAT_FGT to untrap the
>> specific registers that would normally be untrapped. Add handling for
>> those trapped register accesses that does the right thing if the PMU
>> is partitioned.
>> For registers that shouldn't be written to hardware because they
>> require special handling (PMEVTYPER and PMOVS), write to the virtual
>> register. A later patch will ensure these are handled correctly at
>> vcpu_load time.
>> Signed-off-by: Colton Lewis <coltonlewis@google.com>
> I'd prefer an approach that provides a single accessor helper that takes
> a vcpu_sysreg enum as an argument and internally handles the dispatch
> between partitioned and emulated PMUs. That goes for all of the PMU
> sysregs.
That seems ugly to me. It'll need a giant switch or two to re-dispatch
to the correct sysreg handling when we were already dispatched courtesy
of the function we are in.
Are you thinking:
single_accessor(vcpu_sysreg)
{
if (is_partitioned) {
switch (vcpu_sysreg) {
...
}
return;
}
switch (vcpu_sysreg) {
...
}
}
or I could do the switch on the outside and duplicate the is_partitioned
check but that's the same as what happens now with extra steps.
> This will help you reuse some of the PMU emuation code that you'll still
> need for things like nested...
I'm not seeing what you mean. Could you explain further please?
> Thanks,
> Oliver
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: display: rockchip: analogix-dp: Expose inherited properties
From: Conor Dooley @ 2026-05-14 18:16 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260514070133.2275069-2-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Thu, May 14, 2026 at 03:01:31PM +0800, Damon Ding wrote:
> Expose the inherited properties from the base analogix-dp schema
> to satisfy unevaluatedProperties constraints.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Given it's unevaluatedProperties, not addtionalProperties, this patch
shouldn't be needed?
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index bb75d898a5c5..896ded87880f 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -50,6 +50,13 @@ properties:
> aux-bus:
> $ref: /schemas/display/dp-aux-bus.yaml#
>
> + reg: true
> + interrupts: true
> + phys: true
> + phy-names: true
> + force-hpd: true
> + ports: true
> +
> required:
> - compatible
> - clocks
> --
> 2.34.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms
From: Conor Dooley @ 2026-05-14 18:14 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pengutronix Kernel Team, linux-arm-kernel, imx,
devicetree, linux-kernel, NXP S32 Linux, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo
In-Reply-To: <20260514070605.996462-3-khristineandreea.barbulescu@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On Thu, May 14, 2026 at 09:06:05AM +0200, Khristine Andreea Barbulescu wrote:
> Add devicetree binding example for the PIT timer as used on
> NXP S32G2 and S32G3 platforms.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
This doesn't add anything to the binding of value, all properties appear
the same as the existing example?
pw-bot: rejected
Cheers,
Conor.
> ---
> .../devicetree/bindings/timer/fsl,vf610-pit.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> index 42e130654d58..8696696776b3 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> +++ b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> @@ -57,3 +57,11 @@ examples:
> clocks = <&clks VF610_CLK_PIT>;
> clock-names = "pit";
> };
> +
> + pit@40188000 {
> + compatible = "nxp,s32g2-pit";
> + reg = <0x40188000 0x3000>;
> + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + };
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 09/13] net: lan966x: add PCIe FDMA support
From: Daniel Machon @ 2026-05-14 18:14 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <73a19f89-ccd7-4762-8e07-812d8d95ead2@redhat.com>
> On 5/9/26 10:27 AM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
> >> +static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
> >> +{
> > [ ... ]
> >> + /* Get all received skbs. */
> >> + while (counter < weight) {
> >> + if (!fdma_has_frames(fdma))
> >> + break;
> >> + /* Order DONE read before DCB/frame reads below. */
> >> + dma_rmb();
> >> + counter++;
> >> + switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> >> + case FDMA_PASS:
> >> + break;
> >> + case FDMA_ERROR:
> >> + fdma_dcb_advance(fdma);
> >> + goto allocate_new;
> >> + }
> >> + skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
> >> + fdma_dcb_advance(fdma);
> >> + if (!skb)
> >> + goto allocate_new;
> >
> > If napi_alloc_skb() fails due to memory pressure, does branching to
> > allocate_new prematurely break out of the processing loop? Since the hardware
> > interrupt was already cleared, and napi_complete_done() is called below,
> > will this cause the RX queue to stall permanently for the remaining
> > unprocessed frames? Should the code drop the packet and continue instead?
>
> I went over the series and sashiko feedback, and generally speaking the
> series LGTM, but I think this one is real and should be addressed.
Thanks for reviewing. Before I respin, I'd like to sanity-check the design
expectation.
I had already looked at this and concluded it was fine — the reasoning being
that any leftover DCBs (frames) would be drained on the next IRQ when new
traffic arrives. Same pattern exists in all other Microchip FDMA drivers
(lan966x platform, sparx5/lan969x, ocelot) and has been running since their
introduction without a reported issue, AFAIK.
Is calling napi_complete_done() with DCBs still pending in the ring itself a
NAPI-contract violation — in that case this is a pattern that needs fixing
across all four drivers.
Happy to go either way — just want to make sure I understand the problem :-)
>
> Also it would be very helpful if you could (for future series/revision)
> reply to the (wrong) sashiko comments individually explaining with a few
> words why the are off: decoding the context requires much more time for
> whoever has not wrote the code itself.
Ack.
>
> I understand that dealing with AI feedback is a pain, but, paraphrasing
> a great aphorisms creator, I can assure you that ours (maintainers) pain
> is greater.
I can only imagine.
>
> Thanks,
>
> Paolo
>
/Daniel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm64: dts: airoha: Add an7583 entry
From: Conor Dooley @ 2026-05-14 18:09 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Felix Fietkau,
John Crispin, Matthias Brugger, AngeloGioacchino Del Regno,
Christian Marangi, devicetree, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260513-airoha-7583-v2-1-ee0d82b37ce7@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [arm-platforms:timers/el2-vtimer 1/17] Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
From: kernel test robot @ 2026-05-14 18:06 UTC (permalink / raw)
To: Marc Zyngier; +Cc: oe-kbuild-all, linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git timers/el2-vtimer
head: e793e78f4ead18e3dfe5a3a1be912a7ec5bc55d8
commit: c58180850debdd9b2306a86238860769137f40cd [1/17] ACPI: GTDT: Account for GTDTv3 size when walking the platform timer descriptors
config: arm64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260514/202605141925.PkUUh1mk-lkp@intel.com/config)
compiler: aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260514/202605141925.PkUUh1mk-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605141925.PkUUh1mk-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
>> Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v7 07/20] KVM: arm64: Set up FGT for Partitioned PMU
From: Colton Lewis @ 2026-05-14 17:49 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agQpbiD8Fi6fzomf@kernel.org>
Hi Oliver. Thanks for the review.
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:00PM +0000, Colton Lewis wrote:
>> +static void __compute_hdfgrtr(struct kvm_vcpu *vcpu)
>> +{
>> + __compute_fgt(vcpu, HDFGRTR_EL2);
>> +
>> + *vcpu_fgt(vcpu, HDFGRTR_EL2) |=
>> + HDFGRTR_EL2_PMOVS
>> + | HDFGRTR_EL2_PMCCFILTR_EL0
>> + | HDFGRTR_EL2_PMEVTYPERn_EL0
>> + | HDFGRTR_EL2_PMCEIDn_EL0
>> + | HDFGRTR_EL2_PMMIR_EL1;
>> +}
>> +
> I've given this feedback at least twice already...
> Operators go on the preceding line in the case of line continuations.
I apologize for letting that slip through again.
>> +
>> +/**
>> + * kvm_pmu_is_partitioned() - Determine if given PMU is partitioned
>> + * @pmu: Pointer to arm_pmu struct
>> + *
>> + * Determine if given PMU is partitioned by looking at hpmn field. The
>> + * PMU is partitioned if this field is less than the number of
>> + * counters in the system.
>> + *
>> + * Return: True if the PMU is partitioned, false otherwise
>> + */
>> +bool kvm_pmu_is_partitioned(struct arm_pmu *pmu)
>> +{
>> + if (!pmu)
>> + return false;
>> +
>> + return pmu->max_guest_counters >= 0 &&
>> + pmu->max_guest_counters <= *host_data_ptr(nr_event_counters);
>> +}
>> +
>> +/**
>> + * kvm_vcpu_pmu_is_partitioned() - Determine if given VCPU has a
>> partitioned PMU
>> + * @vcpu: Pointer to kvm_vcpu struct
>> + *
>> + * Determine if given VCPU has a partitioned PMU by extracting that
>> + * field and passing it to :c:func:`kvm_pmu_is_partitioned`
>> + *
>> + * Return: True if the VCPU PMU is partitioned, false otherwise
>> + */
>> +bool kvm_vcpu_pmu_is_partitioned(struct kvm_vcpu *vcpu)
>> +{
>> + return kvm_pmu_is_partitioned(vcpu->kvm->arch.arm_pmu) &&
>> + false;
>> +}
> Ok, I'm thoroughly confused about these predicates.
> Whether or not a vCPU is using a partitioned PMU is a per-VM property.
> This is separate from whether or not the backing arm_pmu has a range of
> available counters for the guest to use.
> It is entirely possible that a VM *isn't* using the partitioned PMU
> feature (i.e. backed with perf events) yet the supporting arm_pmu has a
> guest counter range.
Yes and I add that to this predicate in a later patch when I introduce
the flag. I can always reorder to introduce the flag before (or along
with) this predicate.
>> +#if !defined(__KVM_NVHE_HYPERVISOR__)
>> +bool kvm_vcpu_pmu_is_partitioned(struct kvm_vcpu *vcpu);
>> +bool kvm_vcpu_pmu_use_fgt(struct kvm_vcpu *vcpu);
>> +#else
>> +static inline bool kvm_vcpu_pmu_is_partitioned(struct kvm_vcpu *vcpu)
>> +{
>> + return false;
>> +}
>> +
>> +static inline bool kvm_vcpu_pmu_use_fgt(struct kvm_vcpu *vcpu)
>> +{
>> + return false;
>> +}
>> +#endif
>> +
> Don't use ifdeffery for this. Aim to have a single definition and rely
> on has_vhe() to do the rest of the work.
Will do.
> Thanks,
> Oliver
^ permalink raw reply
* [PATCH] Bluetooth: btmtk: Fix FUNC_CTRL parsing for devices with zero-length payloads
From: Shivam Kalra via B4 Relay @ 2026-05-14 17:48 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, Tristan Madani
Cc: Luiz Augusto von Dentz, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, stable, Shivam Kalra
From: Shivam Kalra <shivamkalra98@zohomail.in>
Commit 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length
before struct access") added strict SKB length checks to prevent OOB
memory reads when parsing WMT events.
However, when enabling the protocol (flag = 0), the MT7922 returns a WMT
event with a zero-length payload (skb->len == 7), omitting the 2-byte
status field entirely.
The strict sizeof() check unconditionally enforced the presence of the
status field for all BTMTK_WMT_FUNC_CTRL events. This caused the driver
to reject these payload-less responses with -EINVAL, failing Bluetooth
initialization ("Failed to send wmt func ctrl (-22)").
Fix this by making skb_pull_data() conditional: if the status payload is
present, parse it as before; if omitted, default to BTMTK_WMT_ON_UNDONE.
This restores the pre-regression initialization behavior while
maintaining the memory safety bounds of the previous patch.
Fixes: 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221511
Cc: stable@vger.kernel.org
Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
---
Tested on a laptop with a single MediaTek MT7922 (USB ID 0489:e0e0)
Bluetooth controller. Before this patch, Bluetooth initialization failed
with "Failed to send wmt func ctrl (-22)" on every boot. After applying
this patch, initialization succeeds reliably.
This regression is also reported by other users on the kernel bug
tracker [1].
Note: btmtksdio.c and btmtkuart.c have similar FUNC_CTRL parsing code
but were not modified by the original commit 634a4408c061, so they are
not affected by this regression and do not require changes.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=221511
---
drivers/bluetooth/btmtk.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index f70c1b0f8990..026e5a76b086 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -717,19 +717,19 @@ static int btmtk_usb_hci_wmt_sync(struct hci_dev *hdev,
status = BTMTK_WMT_PATCH_DONE;
break;
case BTMTK_WMT_FUNC_CTRL:
- if (!skb_pull_data(data->evt_skb,
- sizeof(wmt_evt_funcc->status))) {
- err = -EINVAL;
- goto err_free_skb;
- }
-
- wmt_evt_funcc = (struct btmtk_hci_wmt_evt_funcc *)wmt_evt;
- if (be16_to_cpu(wmt_evt_funcc->status) == 0x404)
- status = BTMTK_WMT_ON_DONE;
- else if (be16_to_cpu(wmt_evt_funcc->status) == 0x420)
- status = BTMTK_WMT_ON_PROGRESS;
- else
+ if (skb_pull_data(data->evt_skb,
+ sizeof(wmt_evt_funcc->status))) {
+ wmt_evt_funcc =
+ (struct btmtk_hci_wmt_evt_funcc *)wmt_evt;
+ if (be16_to_cpu(wmt_evt_funcc->status) == 0x404)
+ status = BTMTK_WMT_ON_DONE;
+ else if (be16_to_cpu(wmt_evt_funcc->status) == 0x420)
+ status = BTMTK_WMT_ON_PROGRESS;
+ else
+ status = BTMTK_WMT_ON_UNDONE;
+ } else {
status = BTMTK_WMT_ON_UNDONE;
+ }
break;
case BTMTK_WMT_PATCH_DWNLD:
if (wmt_evt->whdr.flag == 2)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260514-bluetooh-fix-mt7922-92bbbeff229b
Best regards,
--
Shivam Kalra <shivamkalra98@zohomail.in>
^ permalink raw reply related
* Re: [PATCH v2] perf record: Refactor ARM64 leaf caller setup out of arch
From: Ian Rogers @ 2026-05-14 17:38 UTC (permalink / raw)
To: acme, james.clark, namhyung
Cc: adrian.hunter, alexander.shishkin, dapeng1.mi, john.g.garry,
jolsa, leo.yan, linux-arm-kernel, linux-kernel, linux-perf-users,
mark.rutland, mike.leach, mingo, peterz, shimin.guo, will
In-Reply-To: <20260512054140.3427725-1-irogers@google.com>
On Mon, May 11, 2026 at 10:41 PM Ian Rogers <irogers@google.com> wrote:
>
> Code in tools/perf/arch causes portability issues/opaqueness and LTO
> issues due to the use of weak symbols. Move the adding of LR to the
> sample_user_regs into arm64-frame-pointer-unwind-support.c conditional
> on EM_HOST == EM_AARCH64 (false on all non-ARM64 builds). This also
> better encapsulates the use of the sampled registers by
> get_leaf_frame_caller_aarch64 and the set up by the new
> add_leaf_frame_caller_opts_aarch64, exposing opportunities for
> possibly sampling PC and SP to help the unwinder.
>
> Reviewed-by: James Clark <james.clark@linaro.org>
> Signed-off-by: Ian Rogers <irogers@google.com>
Ping.
Thanks,
Ian
> ---
> tools/perf/arch/arm64/util/Build | 1 -
> tools/perf/arch/arm64/util/machine.c | 12 ------------
> tools/perf/builtin-record.c | 11 +++++------
> tools/perf/util/arm64-frame-pointer-unwind-support.c | 6 ++++++
> tools/perf/util/arm64-frame-pointer-unwind-support.h | 2 ++
> tools/perf/util/callchain.h | 2 --
> 6 files changed, 13 insertions(+), 21 deletions(-)
> delete mode 100644 tools/perf/arch/arm64/util/machine.c
>
> diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
> index 4e06a08d281a..638aa6948ab5 100644
> --- a/tools/perf/arch/arm64/util/Build
> +++ b/tools/perf/arch/arm64/util/Build
> @@ -5,7 +5,6 @@ perf-util-y += ../../arm/util/pmu.o
> perf-util-y += arm-spe.o
> perf-util-y += header.o
> perf-util-y += hisi-ptt.o
> -perf-util-y += machine.o
> perf-util-y += mem-events.o
> perf-util-y += pmu.o
> perf-util-y += tsc.o
> diff --git a/tools/perf/arch/arm64/util/machine.c b/tools/perf/arch/arm64/util/machine.c
> deleted file mode 100644
> index 80fb13c958d9..000000000000
> --- a/tools/perf/arch/arm64/util/machine.c
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -
> -#include "callchain.h" // prototype of arch__add_leaf_frame_record_opts
> -#include "perf_regs.h"
> -#include "record.h"
> -
> -#define SMPL_REG_MASK(b) (1ULL << (b))
> -
> -void arch__add_leaf_frame_record_opts(struct record_opts *opts)
> -{
> - opts->sample_user_regs |= SMPL_REG_MASK(PERF_REG_ARM64_LR);
> -}
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 4a5eba498c02..272bba7f4b9e 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -14,6 +14,7 @@
> #include "util/parse-events.h"
> #include "util/config.h"
>
> +#include "util/arm64-frame-pointer-unwind-support.h"
> #include "util/callchain.h"
> #include "util/cgroup.h"
> #include "util/header.h"
> @@ -3230,10 +3231,6 @@ static int record__parse_off_cpu_thresh(const struct option *opt,
> return 0;
> }
>
> -void __weak arch__add_leaf_frame_record_opts(struct record_opts *opts __maybe_unused)
> -{
> -}
> -
> static int parse_control_option(const struct option *opt,
> const char *str,
> int unset __maybe_unused)
> @@ -4319,8 +4316,10 @@ int cmd_record(int argc, const char **argv)
>
> evlist__warn_user_requested_cpus(rec->evlist, rec->opts.target.cpu_list);
>
> - if (callchain_param.enabled && callchain_param.record_mode == CALLCHAIN_FP)
> - arch__add_leaf_frame_record_opts(&rec->opts);
> + if (callchain_param.enabled && callchain_param.record_mode == CALLCHAIN_FP) {
> + if (EM_HOST == EM_AARCH64)
> + add_leaf_frame_caller_opts_aarch64(&rec->opts);
> + }
>
> err = -ENOMEM;
> if (evlist__create_maps(rec->evlist, &rec->opts.target) < 0) {
> diff --git a/tools/perf/util/arm64-frame-pointer-unwind-support.c b/tools/perf/util/arm64-frame-pointer-unwind-support.c
> index 858ce2b01812..3af8c7a466e0 100644
> --- a/tools/perf/util/arm64-frame-pointer-unwind-support.c
> +++ b/tools/perf/util/arm64-frame-pointer-unwind-support.c
> @@ -2,6 +2,7 @@
> #include "arm64-frame-pointer-unwind-support.h"
> #include "callchain.h"
> #include "event.h"
> +#include "record.h"
> #include "unwind.h"
> #include <string.h>
>
> @@ -16,6 +17,11 @@ struct entries {
>
> #define SMPL_REG_MASK(b) (1ULL << (b))
>
> +void add_leaf_frame_caller_opts_aarch64(struct record_opts *opts)
> +{
> + opts->sample_user_regs |= SMPL_REG_MASK(PERF_REG_ARM64_LR);
> +}
> +
> static bool get_leaf_frame_caller_enabled(struct perf_sample *sample)
> {
> struct regs_dump *regs;
> diff --git a/tools/perf/util/arm64-frame-pointer-unwind-support.h b/tools/perf/util/arm64-frame-pointer-unwind-support.h
> index 42d3a45490f5..ba35b295bfcd 100644
> --- a/tools/perf/util/arm64-frame-pointer-unwind-support.h
> +++ b/tools/perf/util/arm64-frame-pointer-unwind-support.h
> @@ -5,8 +5,10 @@
> #include <linux/types.h>
>
> struct perf_sample;
> +struct record_opts;
> struct thread;
>
> +void add_leaf_frame_caller_opts_aarch64(struct record_opts *opts);
> u64 get_leaf_frame_caller_aarch64(struct perf_sample *sample, struct thread *thread, int user_idx);
>
> #endif /* __PERF_ARM_FRAME_POINTER_UNWIND_SUPPORT_H */
> diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
> index 06d463ccc7a0..b7702d65ad60 100644
> --- a/tools/perf/util/callchain.h
> +++ b/tools/perf/util/callchain.h
> @@ -277,8 +277,6 @@ static inline int arch_skip_callchain_idx(struct thread *thread __maybe_unused,
> }
> #endif
>
> -void arch__add_leaf_frame_record_opts(struct record_opts *opts);
> -
> char *callchain_list__sym_name(struct callchain_list *cl,
> char *bf, size_t bfsize, bool show_dso);
> char *callchain_node__scnprintf_value(struct callchain_node *node,
> --
> 2.54.0.563.g4f69b47b94-goog
>
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Jamie Nguyen @ 2026-05-14 17:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260514-generous-undetectable-mastiff-cc43d3@sudeepholla>
> On May 14, 2026, at 2:31 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
>> __ffa_partition_info_get_regs() walks the response with a hardcoded
>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
>> read into buf_sz and then thrown away.
>>
>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
>> strides over half a descriptor at a time and ends up parsing every
>> other entry from a slice of two adjacent ones.
>>
>> The FF-A spec (v1.2, section 18.5) says that the producer should
>> report the descriptor size, and the consumer is supposed to stride by
>> that size and ignore any trailing fields it doesn't understand. The
>> non-REGS path (__ffa_partition_info_get) does this already, and the
>> REGS path should match.
>>
>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
>> reports something we can't safely walk.
>>
>> Fixes: 7bc0f589c81d ("firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()")
>> Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
>> ---
>> drivers/firmware/arm_ffa/driver.c | 35 ++++++++++++++++++++++++++++---
>> 1 file changed, 32 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
>> index c72ee4756585..b712e8a03dab 100644
>> --- a/drivers/firmware/arm_ffa/driver.c
>> +++ b/drivers/firmware/arm_ffa/driver.c
>> @@ -321,6 +321,22 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
>> #define PART_INFO_ID(x) ((u16)(FIELD_GET(PART_INFO_ID_MASK, (x))))
>> #define PART_INFO_EXEC_CXT(x) ((u16)(FIELD_GET(PART_INFO_EXEC_CXT_MASK, (x))))
>> #define PART_INFO_PROPERTIES(x) ((u32)(FIELD_GET(PART_INFO_PROPS_MASK, (x))))
>> +
>> +/*
>> + * FF-A v1.2 section 13.9 Table 13.40: registers x3..x17 carry the partition
>> + * descriptors, i.e. 15 u64 of payload per FFA_PARTITION_INFO_GET_REGS call.
>> + */
>> +#define FFA_PART_INFO_REGS_PAYLOAD_U64 15
>> +
>> +/*
>> + * FF-A v1.1 partition information descriptor (FF-A v1.2 section 6.2.1
>> + * Table 6.1): id (2) + exec_ctxt (2) + properties (4) + UUID (16) = 24
>> + * bytes. This is the minimum size the SPMC must report; the kernel reads
>> + * exactly these fields and ignores any trailing ones per the forward-
>> + * compatibility rules in FF-A v1.2 section 18.5.
>> + */
>
> I can't see any such details is the above mention version and section.
> Can you confirm you are looking at [1] ?
Yes, I am looking at [1]. The size field and the rule are in two
different places:
- Section 13.9 Table 13.40, page 188:
x2 Bits[63:48] = "Size in bytes of each partition information
entry descriptor."
(read into buf_sz today and discarded)
- Section 18.5 page 264 rule 4:
"A consumer of this data structure uses the size corresponding
to the Framework version it implements to consume only fields
defined in its version. Additional fields in the producer's
version of this data structure are safely ignored enabling
forward compatibility."
If you agree, I'll rebase against linux-next and send a v2.
[1]: https://developer.arm.com/documentation/den0077/j
> --
> Regards,
> Sudeep
>
> [1] https://developer.arm.com/documentation/den0077/j
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Jamie Nguyen @ 2026-05-14 17:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260514-serious-bumblebee-of-prowess-b6bf2b@sudeepholla>
> On May 14, 2026, at 2:16 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> On Wed, May 13, 2026 at 07:48:05PM +0000, Jamie Nguyen wrote:
>>
>>
>>> On May 13, 2026, at 10:15 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>>>
>>> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
>>>> __ffa_partition_info_get_regs() walks the response with a hardcoded
>>>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
>>>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
>>>> read into buf_sz and then thrown away.
>>>>
>>>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
>>>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
>>>> strides over half a descriptor at a time and ends up parsing every
>>>> other entry from a slice of two adjacent ones.
>>>>
>>>> The FF-A spec (v1.2, section 18.5) says that the producer should
>>>> report the descriptor size, and the consumer is supposed to stride by
>>>> that size and ignore any trailing fields it doesn't understand. The
>>>> non-REGS path (__ffa_partition_info_get) does this already, and the
>>>> REGS path should match.
>>>>
>>>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
>>>> reports something we can't safely walk.
>>>>
>>>
>>> Can you check if the issue is addressed in -next by:
>>> Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")
>>
>> Thanks for the pointer. I tested 3974ea193840 on the same hardware
>> that reproduces the bug, but the descriptor-stride issue is still
>> present.
>>
>> The relevant loop at the end of __ffa_partition_info_get_regs()
>> still has:
>>
>> buf_sz = PARTITION_INFO_SZ(partition_info.a2);
>> if (buf_sz > sizeof(*buffer))
>> buf_sz = sizeof(*buffer);
>> ...
>> for (idx = 0; idx < nr_desc; idx++, buf++) {
>> ...
>> regs += 3; /* bug is here */
>> }
>>
>> With 48-byte descriptors the SPMC returns nr_desc = 2 per call,
>
> Well why is the firmware sending 48byte entry when 24byte is expected.
We're starting to test with a v1.3 SPMC implementation. UEFI brings
up its FF-A driver first and negotiates v1.3, which the SPMC then must
keep for the lifetime of the primary VM per DEN0077A v1.2 REL0 section
13.2.2 [0]:
"Once an FF-A version has been negotiated between a caller and a
callee, the version may not be changed for the lifetime of the
calling component.”
When Linux later asks for v1.2 the SPMC stays at 1.3 and emits the
48-byte v1.3 layout: DEN0077A v1.3 ALP4 section 13.9 [1]: "Size of each
descriptor is 48 bytes as per the FF-A v1.3 spec”.
[0]: https://developer.arm.com/documentation/den0077/j
[1]: https://developer.arm.com/documentation/den0077/o
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Mathieu Poirier @ 2026-05-14 17:35 UTC (permalink / raw)
To: Shenwei Wang
Cc: Arnaud POULIQUEN, Beleswar Prasad Padhi, Andrew Lunn,
Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <PAXPR04MB9185BFA6E7375FAD0B15B021893C2@PAXPR04MB9185.eurprd04.prod.outlook.com>
On Thu, May 07, 2026 at 07:43:33PM +0000, Shenwei Wang wrote:
>
>
> > -----Original Message-----
> > From: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Sent: Thursday, May 7, 2026 12:13 PM
> > To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
> > Cc: Beleswar Prasad Padhi <b-padhi@ti.com>; Shenwei Wang
> > <shenwei.wang@nxp.com>; Andrew Lunn <andrew@lunn.ch>; Linus Walleij
> > <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> > <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> > <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> > <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> > gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> > devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> > imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> > imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > > > From my perspective, based on your proposal:
> > > > > 1) Linux should send a get_config message to the remote proc (0x405 ->
> > 0xD). 2) The remote processor would respond with the list of ports, associated
> > > > > with an remote endpoint addresses.
> > > >
> > > >
> > > > Agreed, we can scale it for multiple remote endpoints like this.
> > > >
> > > > > 3) Linux would parse the response, compare it with the DT, enable the
> > GPIO
> > > > > ports accordingly, creating it local endpoint and associating it with
> > > > > the remote endpoint.
> > > > > Using name service to identify the ports should avoid step 1 & 2 ...
> > > >
> > > >
> > > > Yes, but won't that make a lot of hard-codings in the driver?
> > > >
> > > > +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > > + { .name = "rpmsg-io-25" },
> > > > + { .name = "rpmsg-io-32" },
> > > > + { .name = "rpmsg-io-35" },
> > > > + { },
> > > > +};
> > > >
> > > > What if tomorrow another vendor decides to add more remoteproc
> > > > controlled GPIO ports to Linux, they would have to update this
> > > > struct in the driver everytime. And the port indexes (25/32/35)
> > > > could also differ between vendors. We should make the driver dynamic
> > > > i.e. vendor agnostic.
> > > >
> > > > I think querying the remote firmware at runtime (step 1 & 2 above)
> > > > is a common design pattern and makes the driver vendor agnostic. But
> > > > feel free to correct me.
> > > >
> > >
> > > You are right. My proposal would require a patch in rpmsg-core. The
> > > idea of allowing a postfix in the compatible string has been discussed
> > > before, but, if I remember correctly, it was not concluded.
> > >
> >
> > I also remember discussing this. I even reviewed one of Arnaud's patch and
> > submitted one myself. This must have been in 2020 and the reason why it wasn't
> > merged has escaped my memory.
> >
> > > /* rpmsg devices and drivers are matched using the service name */
> > > static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> > > const struct rpmsg_device_id *id) {
> > > size_t len;
> > >
> > > + len = strnlen(id->name, RPMSG_NAME_SIZE);
> > > + if (len && id->name[len - 1] == '*')
> > > + return !strncmp(id->name, rpdev->id.name, len - 1);
> > >
> > > return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > > }
> > >
> > > Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty
> > > and a future rpmsg-i2c, we could use:
> > > static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > { .name = "rpmsg-io" },
> > > { .name = "rpmsg-io-*" },
> > > { },
> > > };
> >
> > That was my initial approach. We don't even need an additional "rpmsg-io-*" in
> > rpmsg_gpio_channel_id_table[]. All we need is:
> >
> > /* rpmsg devices and drivers are matched using the service name */ static inline
> > int rpmsg_id_match(const struct rpmsg_device *rpdev,
> > const struct rpmsg_device_id *id) {
> > + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
> >
> > - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > + return strncmp(id->name, rpdev->id.name, len) == 0;
> > }
> >
>
> If we encode the port index directly into ept->src, for example:
>
> ept->src = (baseaddr << 8) | port_index;
>
There is no rpmsg_endpoint::src. You likely meant ept->addr. This would work
but not optimal on two front:
(1) rpms_endpoint::addr is a u32 and idr_alloc() returns an 'int'. As such
there is a possibility of conflict. I concede the possibility is marginal, but
it still exists.
(2) By proceeding this way, the kernel exposes the GPIO controller it knows
about. It is preferrable to have the remote processor tell the kernel about the
GPIO controller it wants.
I am done reviewing this revision. Given the amount of refactoring needed, I
will not look at the code. Please refer to this reply [1] for what I am
expecting in the next revision.
[1]. https://lwn.net/ml/all/CANLsYkwBk0KbN-k9ce+5=oT+scdZ3nU5AOr3Fz4zT=0AFzghDA@mail.gmail.com/
> where baseaddr can be derived from the channel address, we can avoid the possible address conflict.
>
> With this approach, the patch to rpmsg-core would no longer be necessary.
>
> Thanks,
> Shenwei
>
> > And let the rpmsg-virtio-gpio driver parse @rpdev->id.name to match with a
> > GPIO controller in the DT.
> >
> > >
> > > If exact name matching is strongly required, then this proposal would
> > > not be suitablea.
> > >
> > > A third option would be a combination of both approaches: instantiate
> > > the device using the same name service from the remote side, as done
> > > in rpmsg-tty. In that case, a get_config message, or a similar
> > > mechanism, would also be needed to retrieve the port information from the
> > remote side.
> > >
> >
> > I'm not overly fond of a get_config message because it is one more thing we have
> > to define and maintain.
> >
> > Arnaud: is there a get_config message already defined for rpmsg_tty?
> >
> > Beleswar: Can you provide a link to a virtio device that would use a get_config
> > message?
> >
> > > Tanmaya also proposed another alternative based on reserved addresses.
> > >
> > > At this point, I suggest letting Mathieu review the discussion and
> > > recommend the most suitable approach.
> > >
> > > Thanks,
> > > Arnaud
> > >
> > > > >
> > > > > At the end, whatever solution is implemented, my main concern is
> > > > > that the Linux driver design should, if possible, avoid adding
> > > > > unnecessary complexity or limitations on the remote side (for instance in
> > openAMP project).
> > > >
> > > >
> > > > Yes definitely, I want the same. Feel free to let me know if this
> > > > does not suit with the OpenAMP project.
> > > >
> > > > Thanks,
> > > > Beleswar
> > > >
> > > > >
> > > > > Thanks,
> > > > > Arnaud
> > > > >
> > > > >
> > > > > > So Linux does not need to send the port idx everytime while
> > > > > > sending a gpio message anymore.
> > > > > >
> > > > > > Thanks,
> > > > > > Beleswar
> > > > > >
> > > > > > [...]
> > > > > >
> > > > >
> > >
^ permalink raw reply
* Re: [PATCH v2] drivers: altera_edac: Guard SDRAM irq2 retrieval for Arria10 only
From: Dinh Nguyen @ 2026-05-14 17:23 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade, bp, tony.luck
Cc: linux-edac, linux-arm-kernel, linux-kernel
In-Reply-To: <20260514034007.11541-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On 5/13/26 22:40, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Guard the irq2 retrieval with an of_machine_is_compatible() check so
> that platform_get_irq(pdev, 1) is only called on Arria10 platforms.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> v2: Move irq2 = platform_get_irq(pdev, 1) inside the existing
> of_machine_is_compatible("altr,socfpga-arria10") block instead of
> adding a separate duplicate guard around it.
> ---
Please get into the habit of looking at previous commmits and their
formatting.
This commit header should be:
EDAC/altera: Guard SDRAM irq2 retrieval for Arria10 only
Dinh
^ permalink raw reply
* Re: [PATCH] arm64: mm: drop redundant remap of FDT first page
From: Sang-Heon Jeon @ 2026-05-14 17:15 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: linux-arm-kernel
In-Reply-To: <20260513170101.1858213-1-ekffu200098@gmail.com>
On Thu, May 14, 2026 at 2:01 AM Sang-Heon Jeon <ekffu200098@gmail.com> wrote:
>
> fixmap_remap_fdt() calls create_mapping_noalloc() to map the first
> page of the FDT to read its magic and totalsize from the header. If
> the FDT does not fit in a single page, it calls create_mapping_noalloc()
> again to map the rest.
>
> The second mapping redundantly covers the first page that was just
> mapped by the first mapping.
>
> Start the second mapping at dt_phys_base + PAGE_SIZE so it only covers
> the pages that have not been mapped yet. No functional change.
>
> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> ---
> QEMU-based test results
>
> $ qemu-system-aarch64 -M virt -singlestep -d nochain,exec ...
>
> Count log lines from fixmap_remap_fdt() entry to return
> - entry PC : address of the <fixmap_remap_fdt> symbol
> - return PC : next address of each bl ... <fixmap_remap_fdt>
>
> 1) AS-IS
> - 1st call (KERNEL) : 4935
> - 2nd call (KERNEL_RO) : 14151
> 2) TO-BE
> - 1st call : 4888
> - 2nd call : 14104
>
> ---
> Hello,
>
> While looking into boot information, I found a minor cleanup point.
> If I misunderstood anything, please feel free to let me know.
>
> Thank you for taking valuable time to review this work.
>
> Best Regards,
> Sang-Heon Jeon
> ---
> arch/arm64/mm/fixmap.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
> index c5c5425791da..f8aea5572f7c 100644
> --- a/arch/arm64/mm/fixmap.c
> +++ b/arch/arm64/mm/fixmap.c
> @@ -167,8 +167,9 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
> return NULL;
>
> if (offset + *size > PAGE_SIZE) {
Based on sashiko review [1], I made another patch [2].
Please check that patch as well. Thank you.
[1] https://sashiko.dev/#/patchset/20260513170101.1858213-1-ekffu200098%40gmail.com
[2] https://lore.kernel.org/all/20260514171304.2034930-1-ekffu200098@gmail.com/
Best Regards,
Sang-Heon Jeon
> - create_mapping_noalloc(dt_phys_base, dt_virt_base,
> - offset + *size, prot);
> + create_mapping_noalloc(dt_phys_base + PAGE_SIZE,
> + dt_virt_base + PAGE_SIZE,
> + offset + *size - PAGE_SIZE, prot);
> }
>
> return dt_virt;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Greg KH @ 2026-05-14 17:14 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Suzuki K Poulose, linux-coco, linux-arm-kernel, linux-kernel,
Catalin Marinas, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price
In-Reply-To: <yq5alddm5a6w.fsf@kernel.org>
On Thu, May 14, 2026 at 08:07:27PM +0530, Aneesh Kumar K.V wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
>
> > On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> >> Hi Aneesh
> >>
> >> On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> >> > Make the SMCCC driver responsible for registering the arm-smccc platform
> >> > device and after confirming the relevant SMCCC function IDs, create
> >> > the arm_cca_guest auxiliary device.
> >> >
> >>
> >> There are a few changes squashed in to this patch. Please could we
> >> split the patch in the following order ?
> >>
> >> 1. Add platform device for arm-smccc
> >
> > Do not make any more "fake" platform devices please.
> >
> >> 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> >> it before the RSI changes)
> >
> > No, move it to the faux api please.
> >
>
>
> Maybe I was not complete in my previous reply. I did not want to repeat
> the entire thread, so I quoted the lore link for more details.
>
> 1. We have platform firmware-provided SMCCC interfaces. Based on the
> support/availability of these function IDs, we want to load multiple
> drivers.
> 2. This patch series adds a platform device to represent the
> firmware-provided SMCCC resource.
> 3. Different SMCCC ranges are now represented as auxiliary devices.
> 4. Different subsystems, such as TSM, can autoload their backend drivers
> based on the availability of these SMCCC ranges, which are now
> represented as auxiliary devices.
>
> You had agreed to all of this in the previous discussion here:
> https://lore.kernel.org/all/2025101516-handbook-hyphen-62ec@gregkh
Then why did someone say "this is a fake platform device with no actual
resources"? That's what I was triggering off of.
Again, if you have actual platform resources, GREAT, use a platform
device and aux. If you do not, then do NOT use a platform device.
totally confused,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Greg KH @ 2026-05-14 17:13 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Catalin Marinas, Suzuki K Poulose, linux-coco, linux-arm-kernel,
linux-kernel, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Sudeep Holla, Will Deacon, Steven Price
In-Reply-To: <yq5ajyt65a5y.fsf@kernel.org>
On Thu, May 14, 2026 at 08:08:01PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
>
> > On Thu, May 14, 2026 at 02:55:48PM +0200, Greg Kroah-Hartman wrote:
> >> On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> >> > On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> >> > > Make the SMCCC driver responsible for registering the arm-smccc platform
> >> > > device and after confirming the relevant SMCCC function IDs, create
> >> > > the arm_cca_guest auxiliary device.
> >> > >
> >> >
> >> > There are a few changes squashed in to this patch. Please could we
> >> > split the patch in the following order ?
> >> >
> >> > 1. Add platform device for arm-smccc
> >>
> >> Do not make any more "fake" platform devices please.
> >>
> >> > 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> >> > it before the RSI changes)
> >>
> >> No, move it to the faux api please.
> >
> > So should we end up with:
> >
> > /sys/devices/faux/arm-smccc/
> > smccc_trng/
> > arm-rsi-dev/
> > tsm/tsm0
> >
> > /sys/class/tsm/tsm0
> > -> ../../devices/faux/arm-smccc/arm-rsi-dev/tsm/tsm0
> >
> > /sys/firmware/cca/
> > realm_guest
>
> But we need the ability to autoload different TSM backend drivers based
> on the support/availability of these SMCCC function-id ranges. faux
> device don't support that.
If you really need to "autoload" things, then do it like any other
normal bus or class does this, and send the proper uevents as needed.
Don't abuse the auxbus code for this please!
thanks,
greg k-h
^ permalink raw reply
* [PATCH] arm64: mm: use u32 for FDT size in fixmap_remap_fdt()
From: Sang-Heon Jeon @ 2026-05-14 17:13 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: linux-arm-kernel, Sang-Heon Jeon
fixmap_remap_fdt() uses a signed int for the FDT size, so a malformed
totalsize bigger than INT_MAX wrongly passes the MAX_FDT_SIZE check.
Then create_mapping_noalloc() is called with a huge size and triggers
a BUG_ON() in the MMU code, with no diagnostic about the malformed FDT.
Change the FDT size from int to u32, which is the return type of
fdt_totalsize(). So a malformed totalsize no longer wrongly passes the
MAX_FDT_SIZE check, and setup_machine_fdt() prints a pr_crit
diagnostic for it, not a BUG_ON in the MMU code.
Fixes: 61bd93ce801b ("arm64: use fixmap region for permanent FDT mapping")
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
---
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/setup.c | 4 ++--
arch/arm64/mm/fixmap.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 5e1211c540ab..a6b388ef4c3f 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -68,7 +68,7 @@ extern void create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
pgprot_t prot, bool page_mappings_only);
-extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
+extern void *fixmap_remap_fdt(phys_addr_t dt_phys, u32 *size, pgprot_t prot);
extern void mark_linear_text_alias_ro(void);
extern int split_kernel_leaf_mapping(unsigned long start, unsigned long end);
extern void linear_map_maybe_split_to_ptes(void);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 23c05dc7a8f2..7cabac0546dc 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -169,7 +169,7 @@ static void __init smp_build_mpidr_hash(void)
static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
- int size = 0;
+ u32 size = 0;
void *dt_virt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
const char *name;
@@ -182,7 +182,7 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
*/
if (!early_init_dt_scan(dt_virt, dt_phys)) {
pr_crit("\n"
- "Error: invalid device tree blob: PA=%pa, VA=%px, size=%d bytes\n"
+ "Error: invalid device tree blob: PA=%pa, VA=%px, size=%u bytes\n"
"The dtb must be 8-byte aligned and must not exceed 2 MB in size.\n"
"\nPlease check your bootloader.\n",
&dt_phys, dt_virt, size);
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index c5c5425791da..c692e6ac2405 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -134,11 +134,11 @@ void __set_fixmap(enum fixed_addresses idx,
}
}
-void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
+void *__init fixmap_remap_fdt(phys_addr_t dt_phys, u32 *size, pgprot_t prot)
{
const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
phys_addr_t dt_phys_base;
- int offset;
+ u32 offset;
void *dt_virt;
/*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Catalin Marinas @ 2026-05-14 17:10 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Greg KH, Suzuki K Poulose, linux-coco, linux-arm-kernel,
linux-kernel, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Sudeep Holla, Will Deacon, Steven Price
In-Reply-To: <yq5ajyt65a5y.fsf@kernel.org>
On Thu, May 14, 2026 at 08:08:01PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> > On Thu, May 14, 2026 at 02:55:48PM +0200, Greg Kroah-Hartman wrote:
> >> On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> >> > On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> >> > > Make the SMCCC driver responsible for registering the arm-smccc platform
> >> > > device and after confirming the relevant SMCCC function IDs, create
> >> > > the arm_cca_guest auxiliary device.
> >> > >
> >> >
> >> > There are a few changes squashed in to this patch. Please could we
> >> > split the patch in the following order ?
> >> >
> >> > 1. Add platform device for arm-smccc
> >>
> >> Do not make any more "fake" platform devices please.
> >>
> >> > 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> >> > it before the RSI changes)
> >>
> >> No, move it to the faux api please.
> >
> > So should we end up with:
> >
> > /sys/devices/faux/arm-smccc/
> > smccc_trng/
> > arm-rsi-dev/
> > tsm/tsm0
> >
> > /sys/class/tsm/tsm0
> > -> ../../devices/faux/arm-smccc/arm-rsi-dev/tsm/tsm0
> >
> > /sys/firmware/cca/
> > realm_guest
>
> But we need the ability to autoload different TSM backend drivers based
> on the support/availability of these SMCCC function-id ranges. faux
> device don't support that.
It breaks this but can we not have some systemd rule that checks
/sys/firmware/cca/realm_guest and modprobes arm_cca_guest?
Alternatively, we could do a request_module("arm_cca_guest") if
RSI is available when we check it in smccc_devices_init(). Or make it
even fancier with a request_module("arm-smccc-service-...") (some ID
range while arm-cca-guest.c has a corresponding MODULE_ALIAS() for that
SMCCC range.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox