* Re: [PATCH] KVM: arm64: Inject UNDEF when host is executing an smc with imm16 != 0
From: Fuad Tabba @ 2026-03-24 15:13 UTC (permalink / raw)
To: Sebastian Ene
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, vdonnefort, will, yuzenghui
In-Reply-To: <20260324135728.3532400-1-sebastianene@google.com>
Hi Seb,
On Tue, 24 Mar 2026 at 13:57, Sebastian Ene <sebastianene@google.com> wrote:
>
> The ARM Service Calling Convention (SMCCC) specifies that the function
> identifier and parameters should be passed in registers, leaving the
> 16-bit immediate field of the SMC instruction un-handled.
> Currently, our pKVM handler ignores the immediate value, which could lead
> to non-compliant software relying on implementation-defined behavior.
> Enforce the host kernel running under pKVM to use an immediate value
> of 0 by decoding the ISS from the ESR_EL2 and inject an undefined
> instruction exception back to the caller.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index e7790097db93..ff6a90a4a4c7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -756,13 +756,18 @@ static bool handle_host_mte(u64 esr)
> void handle_trap(struct kvm_cpu_context *host_ctxt)
> {
> u64 esr = read_sysreg_el2(SYS_ESR);
> + u16 imm16;
>
> switch (ESR_ELx_EC(esr)) {
> case ESR_ELx_EC_HVC64:
> handle_host_hcall(host_ctxt);
> break;
> case ESR_ELx_EC_SMC64:
> - handle_host_smc(host_ctxt);
> + imm16 = esr & U16_MAX;
> + if (!imm16)
Do we need to introduce a new variable for this? This isn't easier to read than:
+ if (!(esr & U16_MAX))
Also, we have a mask for this: ESR_ELx_xVC_IMM_MASK , please use that instead
Cheers,
/fuad
> + handle_host_smc(host_ctxt);
> + else
> + inject_undef64();
> break;
> case ESR_ELx_EC_IABT_LOW:
> case ESR_ELx_EC_DABT_LOW:
> --
> 2.53.0.983.g0bb29b3bc5-goog
>
^ permalink raw reply
* Re: [PATCH 0/2] iommu/tegra241-cmdqv: Fix initialization and uAPI related to HYP_OWN
From: Will Deacon @ 2026-03-24 15:08 UTC (permalink / raw)
To: robin.murphy, kevin.tian, Jason Gunthorpe, Nicolin Chen
Cc: catalin.marinas, kernel-team, Will Deacon, joro, linux-tegra,
linux-arm-kernel, iommu, linux-kernel, eric.auger, skolothumtho
In-Reply-To: <cover.1773361875.git.nicolinc@nvidia.com>
On Thu, 12 Mar 2026 17:36:33 -0700, Nicolin Chen wrote:
> Eric and Shameer found a bug in kernel driver that supports_cmd is set in
> an incorrect order related to the hyp_own finalization. This results in a
> unnecessary command filter in the host environment that sends unsupported
> (non-invalidation) commands to the SMMU CMDQ.
>
> Also, Eric pointed it out that the requirement of VMM wiring HYP_OWN to 0
> is unclear.
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/2] iommu/tegra241-cmdqv: Set supports_cmd op in tegra241_vcmdq_hw_init()
https://git.kernel.org/iommu/c/803e41f36d22
[2/2] iommu/tegra241-cmdqv: Update uAPI to clarify HYP_OWN requirement
https://git.kernel.org/iommu/c/9dcef98dbee3
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] perf/arm-cmn: Stop claiming entire iomem region
From: Will Deacon @ 2026-03-24 15:08 UTC (permalink / raw)
To: Robin Murphy
Cc: catalin.marinas, kernel-team, Will Deacon, mark.rutland,
linux-arm-kernel, linux-perf-users, ilkka, James Morse
In-Reply-To: <b6275655818f5af7e5fb07a9e18d1451b08b7e05.1771522073.git.robin.murphy@arm.com>
On Thu, 19 Feb 2026 17:27:53 +0000, Robin Murphy wrote:
> So far, the PMU has been the only thing of interest in the vast mass
> of CMN registers, so we've gotten away with simply claiming the entire
> iomem region. However, now that we can support other features like MPAM
> controllers for the system caches, the PMU driver needs to stop being
> selfish and learn to share. Similarly to arm-ni, requesting just the
> DTC node(s) should suffice for staking our exclusive claim to the PMU
> features, as requesting hundreds of tiny regions for all the individual
> pmu_event_sel registers is definitely not worth the considerable bother.
>
> [...]
Applied to will (for-next/perf), thanks!
[1/1] perf/arm-cmn: Stop claiming entire iomem region
https://git.kernel.org/will/c/5394396ff548
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-v3: Update Arm errata
From: Will Deacon @ 2026-03-24 15:08 UTC (permalink / raw)
To: joro, Robin Murphy
Cc: catalin.marinas, kernel-team, Will Deacon, iommu,
linux-arm-kernel, daizhiyuan
In-Reply-To: <4c4664b2427cef212a06efdd78a9faa8d9ded302.1773933699.git.robin.murphy@arm.com>
On Thu, 19 Mar 2026 15:24:34 +0000, Robin Murphy wrote:
> MMU-700 r1p1 has subsequently fixed some of the errata for which we've
> been applying the workarounds unconditionally, so we can now make those
> conditional. However, there have also been some more new cases
> identified where we must rely on range invalidation commands, and thus
> still nominally avoid DVM being inadvertently enabled.
>
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu/arm-smmu-v3: Update Arm errata
https://git.kernel.org/iommu/c/3b793983834e
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 0/2] iommu/arm-smmu-v3: Fix bugs and typos in arm_smmu_invs series
From: Will Deacon @ 2026-03-24 15:08 UTC (permalink / raw)
To: Nicolin Chen
Cc: catalin.marinas, kernel-team, Will Deacon, robin.murphy, joro,
linux-arm-kernel, iommu, linux-kernel, Jason Gunthorpe
In-Reply-To: <20260321225041.11090-1-nicolinc@nvidia.com>
On Sat, 21 Mar 2026 15:50:39 -0700, Nicolin Chen wrote:
> Thank you for taking the series!
>
> I found a couple of small issues in those commits. And here are the fixes.
>
> Thanks
> Nicolin
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/2] iommu/arm-smmu-v3: Do not continue in __arm_smmu_domain_inv_range()
https://git.kernel.org/iommu/c/6a01b9f0a5ec
[2/2] iommu/arm-smmu-v3: Fix typos introduced by arm_smmu_invs
https://git.kernel.org/iommu/c/86bf8580d5b8
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v1] irqchip: fix mask alignment in gic-v2m
From: Thomas Gleixner @ 2026-03-24 15:08 UTC (permalink / raw)
To: Marc Zyngier, Javier Achirica; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <86zf3y4qfp.wl-maz@kernel.org>
On Mon, Mar 23 2026 at 13:37, Marc Zyngier wrote:
> On Sat, 21 Mar 2026 14:12:16 +0000,
> Javier Achirica <jachirica@gmail.com> wrote:
>>
>> commit 2ef3886ce626dcdab0cbc452dbbebc19f57133d8 ("irqchip/gic-v2m: Handle
>> Multiple MSI base IRQ Alignment") introduced a regression in kernel 6.12.58
>> affecting PCIe devices using GICv2m MSI on a Qualcomm (arm64) platform.
>>
>> It uses nr_irqs parameter to generate a mask to align the MSI base address,
>> but this mask isn't properly generated when nr_irqs isn't a power of two.
>> This bug was found while adding support for the TCL HH500V router in OpenWrt.
>>
>> This patch fixes the issue, can be cleanly applied to the 6.12.x tree and,
>> with a small fuzz, to 7.0.x.
>>
>> Signed-off-by: Javier Achirica <jachirica@gmail.com>
>> Cc: stable@vger.kernel.org
>> ---
>> --- a/drivers/irqchip/irq-gic-v2m.c 2026-03-20 09:45:22.170192561 +0100
>> +++ b/drivers/irqchip/irq-gic-v2m.c 2026-03-20 09:45:26.284210783 +0100
>> @@ -158,7 +158,7 @@
>> struct v2m_data *v2m = NULL, *tmp;
>> int hwirq, i, err = 0;
>> unsigned long offset;
>> - unsigned long align_mask = nr_irqs - 1;
>> + unsigned long align_mask = roundup_pow_of_two(nr_irqs) - 1;
>>
>> spin_lock(&v2m_lock);
>> list_for_each_entry(tmp, &v2m_nodes, entry) {
>>
>
> This looks wrong for a bunch of reasons:
>
> - you're hacking the allocation path, but not the free path -- what
> could possibly go wrong?
>
> - nr_irqs not being a power of two to start with is more indicative of
> a bug somewhere else in the system. The only case where we allocate
> more than a single IRQ at a time is for Multi-MSI, and that is
> definitely a power-of-two construct.
Right. Though the PCI/MSI core has never enforced it.
It just ensures that the number of requested interrupts is less than or
equal the power of 2 aligned number in the Multiple Message Capable
field of the Message Control word.
It only writes back round_up_power_of_two(nvec) to the Multiple Message
Enable field and hands the non power of two aligned allocation request
(nvec) down to the domain.
x86 handles this silently under the hood forever. The IRTE allocation
rounds nvec up to the next power of two.
If the driver requests minvec = 3 and maxvec = 5 and the hardware
supports 8 pci_msi_enable_range() it will allocate 5 in the device
domain, resulting in a table size of 8 and 5 actually allocted
interrupts.
The PCI/MSI core could allocate 8 in the device domain and stay
backwards compatible by returning 5 to the caller. The downside would be
that this fully allocates 3 extra unused interrupts descriptors and
resources throughout the domain hierarchy.
It's mostly memory and the only problematic case would be affinity
managed interrupts where the over-allocation actually affects the scarse
x86 vector space. I can't tell from the top of my head whether managed
mode is actually supported with MULTI-MSI or not. It might be, but that
needs some investigation.
Can't we have nice things for once?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 0/3] KVM: arm64: Read PMUVer as unsigned
From: Will Deacon @ 2026-03-24 15:08 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Colton Lewis, Alexandru Elisei,
James Clark
Cc: kernel-team, Will Deacon, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260305-james-kvm-pmuver-sign-v2-0-ee80a125af9b@linaro.org>
On Thu, 05 Mar 2026 16:28:16 +0000, James Clark wrote:
> Fix some issues with the signedness of PMUVer and PerfMon ID fields.
>
> I ran into the first issue when testing "ARM64 PMU Partitioning" patches
> on the FVP. The second issue was only found by inspection.
>
>
Applied to will (for-next/perf), thanks!
[1/3] KVM: arm64: Read PMUVer as unsigned
https://git.kernel.org/will/c/2e30447b233a
[2/3] arm64: cpufeature: Make PMUVer and PerfMon unsigned
https://git.kernel.org/will/c/d1dcc20bcc40
[3/3] arm64: cpufeature: Use pmuv3_implemented() function
https://git.kernel.org/will/c/15ed3fa23cbc
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v3 0/8] perf: add NVIDIA Tegra410 Uncore PMU support
From: Will Deacon @ 2026-03-24 15:08 UTC (permalink / raw)
To: suzuki.poulose, robin.murphy, ilkka, jonathan.cameron,
Besar Wicaksono
Cc: catalin.marinas, kernel-team, Will Deacon, linux-arm-kernel,
linux-kernel, linux-tegra, mark.rutland, treding, jonathanh,
vsethi, rwiley, sdonthineni, skelley, mochs, nirmoyd, bhelgaas,
wangyushan12, shiju.jose, linux-pci
In-Reply-To: <20260324012952.1923296-1-bwicaksono@nvidia.com>
On Tue, 24 Mar 2026 01:29:44 +0000, Besar Wicaksono wrote:
> This series adds driver support for the following Uncore PMUs in
> NVIDIA Tegra410 SoC:
> - Unified Coherence Fabric (UCF)
> - PCIE
> - PCIE-TGT
> - CPU Memory (CMEM) Latency
> - NVLink-C2C
> - NV-CLink
> - NV-DLink
>
> [...]
Applied first seven to will (for-next/perf), thanks!
[1/8] perf/arm_cspmu: nvidia: Rename doc to Tegra241
https://git.kernel.org/will/c/d332424d1d06
[2/8] perf/arm_cspmu: nvidia: Add Tegra410 UCF PMU
https://git.kernel.org/will/c/f5caf26fd6c7
[3/8] perf/arm_cspmu: Add arm_cspmu_acpi_dev_get
https://git.kernel.org/will/c/bc86281fe4bd
[4/8] perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU
https://git.kernel.org/will/c/bf585ba14726
[5/8] perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT PMU
https://git.kernel.org/will/c/3dd73022306b
[6/8] perf: add NVIDIA Tegra410 CPU Memory Latency PMU
https://git.kernel.org/will/c/429b7638b2df
[7/8] perf: add NVIDIA Tegra410 C2C PMU
https://git.kernel.org/will/c/2f89b7f78c50
The defconfig change should go separately via arm-soc (Arnd).
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Inject UNDEF when host is executing an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-24 15:05 UTC (permalink / raw)
To: Vincent Donnefort
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <acKdHK1FbHM_-zdl@google.com>
On Tue, Mar 24, 2026 at 02:18:04PM +0000, Vincent Donnefort wrote:
> On Tue, Mar 24, 2026 at 02:09:50PM +0000, Vincent Donnefort wrote:
> > On Tue, Mar 24, 2026 at 02:06:40PM +0000, Vincent Donnefort wrote:
> > > On Tue, Mar 24, 2026 at 01:57:28PM +0000, Sebastian Ene wrote:
> > > > The ARM Service Calling Convention (SMCCC) specifies that the function
> > > > identifier and parameters should be passed in registers, leaving the
> > > > 16-bit immediate field of the SMC instruction un-handled.
> > > > Currently, our pKVM handler ignores the immediate value, which could lead
> > > > to non-compliant software relying on implementation-defined behavior.
> > > > Enforce the host kernel running under pKVM to use an immediate value
> > > > of 0 by decoding the ISS from the ESR_EL2 and inject an undefined
> > > > instruction exception back to the caller.
> > > >
> > > > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > > > ---
> > > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 ++++++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > > index e7790097db93..ff6a90a4a4c7 100644
> > > > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > > @@ -756,13 +756,18 @@ static bool handle_host_mte(u64 esr)
> > > > void handle_trap(struct kvm_cpu_context *host_ctxt)
> > > > {
> > > > u64 esr = read_sysreg_el2(SYS_ESR);
> > > > + u16 imm16;
> > > >
> > > > switch (ESR_ELx_EC(esr)) {
> > > > case ESR_ELx_EC_HVC64:
> > > > handle_host_hcall(host_ctxt);
> > > > break;
> > > > case ESR_ELx_EC_SMC64:
> > > > - handle_host_smc(host_ctxt);
> > > > + imm16 = esr & U16_MAX;
> > > > + if (!imm16)
> > >
> > > if (ESR_ELx_xVC_IMM_MASK(esr)) ?
> > >
> > > Also, I can't find void inject_undef64(void); I think you need a vcpu for that?
> >
> > Ah my bad, handle_host_mte() introduced it!
> >
> > >
> > > > + handle_host_smc(host_ctxt);
> > > > + else
> > > > + inject_undef64();
>
> Could it be better to return SMCCC_RET_NOT_SUPPORTED?
Right, I will do that since it seems this is the correct approach.
>
> > > > break;
> > > > case ESR_ELx_EC_IABT_LOW:
> > > > case ESR_ELx_EC_DABT_LOW:
> > > > --
> > > > 2.53.0.983.g0bb29b3bc5-goog
> > > >
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Inject UNDEF when host is executing an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-24 15:04 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, oupton, suzuki.poulose,
tabba, vdonnefort, will, yuzenghui
In-Reply-To: <86tsu547ao.wl-maz@kernel.org>
On Tue, Mar 24, 2026 at 02:43:27PM +0000, Marc Zyngier wrote:
> On Tue, 24 Mar 2026 13:57:28 +0000,
> Sebastian Ene <sebastianene@google.com> wrote:
> >
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field of the SMC instruction un-handled.
> > Currently, our pKVM handler ignores the immediate value, which could lead
> > to non-compliant software relying on implementation-defined behavior.
> > Enforce the host kernel running under pKVM to use an immediate value
> > of 0 by decoding the ISS from the ESR_EL2 and inject an undefined
> > instruction exception back to the caller.
Hi Marc,
>
> No, that's completely wrong. SMC never UNDEFs, unless EL3 isn't
> implemented. You can't just decide to generate an UNDEF because you
> don't like the immediate.
>
> All you are allowed to do is to return an error code.
Thanks for letting me know, I will update the patch to do this.
>
> Thanks,
>
> M.
>
Cheers,
Sebastian
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 0/2] Add AST2700 support for aspeed sdhci
From: Ulf Hansson @ 2026-03-24 15:03 UTC (permalink / raw)
To: Ryan Chen
Cc: Andrew Jeffery, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Ryan Chen, Adrian Hunter, Philipp Zabel,
Andrew Jeffery, linux-aspeed, openbmc, linux-mmc, devicetree,
linux-arm-kernel, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260324-sdhci-v4-0-c8c2060ccb5c@aspeedtech.com>
On Tue, 24 Mar 2026 at 02:58, Ryan Chen <ryan_chen@aspeedtech.com> wrote:
>
> This series add aspeed sdhci support for AST2700. The AST2700 sdhci
> requires an reset. This series updates the binding and driver to
> support reset requirements.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v4:
> - 2/2 rebase git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
> next branch fix the conflit.
> - Link to v3: https://lore.kernel.org/r/20260323-sdhci-v3-0-93555b8f6411@aspeedtech.com
>
The series applied for next, thanks!
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 2/9] dt-bindings: mmc: amlogic: Add compatible for T7 mmc
From: Ulf Hansson @ 2026-03-24 15:03 UTC (permalink / raw)
To: Ronald Claveau
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Johannes Berg,
van Spriel, linux-arm-kernel, linux-amlogic, devicetree,
linux-kernel, linux-mmc, linux-wireless
In-Reply-To: <20260323-add-emmc-t7-vim4-v3-2-5159d90a984c@aliel.fr>
On Mon, 23 Mar 2026 at 10:58, Ronald Claveau <linux-kernel-dev@aliel.fr> wrote:
>
> Add amlogic,t7-mmc compatible string, falling back to amlogic,meson-axg-mmc
> as the T7 MMC controller is compatible with the AXG implementation.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Applied for next, thanks!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
> index 57646575a13f8..40dccf9715781 100644
> --- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
> @@ -19,7 +19,10 @@ allOf:
> properties:
> compatible:
> oneOf:
> - - const: amlogic,meson-axg-mmc
> + - items:
> + - enum:
> + - amlogic,t7-mmc
> + - const: amlogic,meson-axg-mmc
> - items:
> - const: amlogic,meson-gx-mmc
> - const: amlogic,meson-gxbb-mmc
>
> --
> 2.49.0
>
^ permalink raw reply
* Re: (subset) [PATCH 0/7] arm64: dts: Drop CPU masks from GICv3 PPI interrupts
From: Frank Li @ 2026-03-24 14:56 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Peter Griffin, André Draszik, Tudor Ambarus, Alim Akhtar,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Bjorn Andersson, Konrad Dybcio, Thierry Reding, Marc Zyngier,
Geert Uytterhoeven
Cc: linux-arm-kernel, linux-amlogic, linux-samsung-soc, imx,
linux-arm-msm, linux-renesas-soc, linux-kernel
In-Reply-To: <cover.1772643434.git.geert+renesas@glider.be>
On Wed, 04 Mar 2026 18:10:57 +0100, Geert Uytterhoeven wrote:
> Hi all,
>
> Unlike older GIC variants, the GICv3 DT bindings do not support
> specifying a CPU mask in PPI interrupt specifiers. Hence this patch
> series drop all such masks where they are still present.
>
> This has been compile-tested only. But note that all such masks were
> removed before from Renesas SoCs in commit 8b6a006c914aac17 ("arm64:
> dts: renesas: Drop specifying the GIC_CPU_MASK_SIMPLE() for GICv3
> systems")).
>
> [...]
Applied, thanks!
[3/7] arm64: dts: fsl-ls1028a: Drop CPU masks from GICv3 PPI interrupts
commit: 7348e8d71c593792df4ebf653d98a576c04c851c
[4/7] arm64: dts: freescale: imx: Drop CPU masks from GICv3 PPI interrupts
commit: f6c18c1c4ba574005d3b95faab0e8a3796cf3346
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v10 28/30] KVM: arm64: selftests: Skip impossible invalid value tests
From: Mark Brown @ 2026-03-24 14:56 UTC (permalink / raw)
To: Ben Horgan
Cc: Marc Zyngier, Joey Gouly, Catalin Marinas, Suzuki K Poulose,
Will Deacon, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Oliver Upton, Dave Martin, Fuad Tabba, Mark Rutland,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <0f8d0966-4e05-4d5a-a523-098b3dbcf7d9@arm.com>
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
On Tue, Mar 24, 2026 at 02:54:54PM +0000, Ben Horgan wrote:
> On 3/6/26 17:01, Mark Brown wrote:
> > + default:
> > + *skip = true;
> > + break;
> > + }
> > }
> I hacked up a quick loop to check what this function is doing.
> With a mask=0x1 I see some value returned that have bits set
> outside of the mask.
Thanks, do you happen to still have that to hand?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v10 28/30] KVM: arm64: selftests: Skip impossible invalid value tests
From: Ben Horgan @ 2026-03-24 14:54 UTC (permalink / raw)
To: Mark Brown, Marc Zyngier, Joey Gouly, Catalin Marinas,
Suzuki K Poulose, Will Deacon, Paolo Bonzini, Jonathan Corbet,
Shuah Khan, Oliver Upton
Cc: Dave Martin, Fuad Tabba, Mark Rutland, linux-arm-kernel, kvmarm,
linux-kernel, kvm, linux-doc, linux-kselftest, Peter Maydell,
Eric Auger
In-Reply-To: <20260306-kvm-arm64-sme-v10-28-43f7683a0fb7@kernel.org>
Hi Mark,
On 3/6/26 17:01, Mark Brown wrote:
> The set_id_regs test currently assumes that there will always be invalid
> values available in bitfields for it to generate but this may not be the
> case if the architecture has defined meanings for every possible value for
> the bitfield. An assert added in commit bf09ee918053e ("KVM: arm64:
> selftests: Remove ARM64_FEATURE_FIELD_BITS and its last user") refuses to
> run for single bit fields which will show the issue most readily but there
> is no reason wider ones can't show the same issue.
>
> Rework the tests for invalid value to check if an invalid value can be
> generated and skip the test if not, removing the assert.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> tools/testing/selftests/kvm/arm64/set_id_regs.c | 63 +++++++++++++++++++++----
> 1 file changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/arm64/set_id_regs.c b/tools/testing/selftests/kvm/arm64/set_id_regs.c
> index bfca7be3e766..928e7d9e5ab7 100644
> --- a/tools/testing/selftests/kvm/arm64/set_id_regs.c
> +++ b/tools/testing/selftests/kvm/arm64/set_id_regs.c
> @@ -317,11 +317,12 @@ uint64_t get_safe_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> }
>
> /* Return an invalid value to a given ftr_bits an ftr value */
> -uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> +uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr,
> + bool *skip)
> {
> uint64_t ftr_max = ftr_bits->mask >> ftr_bits->shift;
>
> - TEST_ASSERT(ftr_max > 1, "This test doesn't support single bit features");
> + *skip = false;
>
> if (ftr_bits->sign == FTR_UNSIGNED) {
> switch (ftr_bits->type) {
> @@ -329,42 +330,81 @@ uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> ftr = max((uint64_t)ftr_bits->safe_val + 1, ftr + 1);
> break;
> case FTR_LOWER_SAFE:
> + if (ftr == ftr_max)
> + *skip = true;
> ftr++;
> break;
> case FTR_HIGHER_SAFE:
> + if (ftr == 0)
> + *skip = true;
> ftr--;
> break;
> case FTR_HIGHER_OR_ZERO_SAFE:
> - if (ftr == 0)
> + switch (ftr) {
> + case 0:
> ftr = ftr_max;
> - else
> + break;
> + case 1:
> + *skip = true;
> + break;
> + default:
> ftr--;
> + break;
> + }
> break;
> default:
> + *skip = true;
> break;
> }
> } else if (ftr != ftr_max) {
> switch (ftr_bits->type) {
> case FTR_EXACT:
> ftr = max((uint64_t)ftr_bits->safe_val + 1, ftr + 1);
> + if (ftr >= ftr_max)
> + *skip = true;
> break;
> case FTR_LOWER_SAFE:
> ftr++;
> break;
> case FTR_HIGHER_SAFE:
> - ftr--;
> + /* FIXME: "need to check for the actual highest." */
> + if (ftr == ftr_max)
> + *skip = true;
> + else
> + ftr--;
> break;
> case FTR_HIGHER_OR_ZERO_SAFE:
> - if (ftr == 0)
> - ftr = ftr_max - 1;
> - else
> + switch (ftr) {
> + case 0:
> + if (ftr_max > 1)
> + ftr = ftr_max - 1;
> + else
> + *skip = true;
> + break;
> + case 1:
> + *skip = true;
> + break;
> + default:
> ftr--;
> + break;
> + }
> break;
> default:
> + *skip = true;
> break;
> }
> } else {
> - ftr = 0;
> + switch (ftr_bits->type) {
> + case FTR_LOWER_SAFE:
> + if (ftr == 0)
> + *skip = true;
> + else
> + ftr = 0;
> + break;
> + default:
> + *skip = true;
> + break;
> + }
> }
I hacked up a quick loop to check what this function is doing.
With a mask=0x1 I see some value returned that have bits set
outside of the mask.
safe_val ftr out
UNSIGNED
FTR_EXACT
0x0 0x0 0x1
0x0 0x1 0x2 # out of range
0x1 0x0 0x2 # out of range
0x1 0x1 0x2 # out of range
FTR_LOWER_SAFE
0x0 0x0 0x1
0x0 0x1 SKIP
0x1 0x0 0x1
0x1 0x1 SKIP
FTR_HIGHER_SAFE
0x0 0x0 SKIP
0x0 0x1 0x0
0x1 0x0 SKIP
0x1 0x1 0x0
FTR_HIGHER_OR_ZERO_SAFE
0x0 0x0 0x1
0x0 0x1 SKIP
0x1 0x0 0x1
0x1 0x1 SKIP
SIGNED
FTR_EXACT
0x0 0x0 SKIP
0x0 0x1 SKIP
0x1 0x0 SKIP
0x1 0x1 SKIP
FTR_LOWER_SAFE
0x0 0x0 0x1
0x0 0x1 0x0
0x1 0x0 0x1
0x1 0x1 0x0
FTR_HIGHER_SAFE
0x0 0x0 0xffffffffffffffff # out of range
0x0 0x1 SKIP
0x1 0x0 0xffffffffffffffff # out of range
0x1 0x1 SKIP
FTR_HIGHER_OR_ZERO_SAFE
0x0 0x0 SKIP
0x0 0x1 SKIP
0x1 0x0 SKIP
0x1 0x1 SKIP
Thanks,
Ben
>
> return ftr;
> @@ -399,12 +439,15 @@ static void test_reg_set_fail(struct kvm_vcpu *vcpu, uint64_t reg,
> uint8_t shift = ftr_bits->shift;
> uint64_t mask = ftr_bits->mask;
> uint64_t val, old_val, ftr;
> + bool skip;
> int r;
>
> val = vcpu_get_reg(vcpu, reg);
> ftr = (val & mask) >> shift;
>
> - ftr = get_invalid_value(ftr_bits, ftr);
> + ftr = get_invalid_value(ftr_bits, ftr, &skip);
> + if (skip)
> + return;
>
> old_val = val;
> ftr <<= shift;
>
^ permalink raw reply
* [PATCH net 2/2] net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-24 14:53 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
In-Reply-To: <20260324145353.1899248-1-suraj.gupta2@amd.com>
When a TX packet spans multiple buffer descriptors (scatter-gather),
the per-BD byte count is accumulated into a local variable that resets
on each NAPI poll. If the BDs for a single packet complete across
different polls, the earlier bytes are lost and never credited to BQL.
This causes BQL to think bytes are permanently in-flight, eventually
stalling the TX queue.
Fix this by replacing the local accumulator with a persistent counter
(tx_compl_bytes) that survives across polls and is reset only after
updating BQL and stats.
Fixes: c900e49d58eb ("net: xilinx: axienet: Implement BQL")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 3 +++
.../net/ethernet/xilinx/xilinx_axienet_main.c | 20 +++++++++----------
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 602389843342..a4444c939451 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -509,6 +509,8 @@ struct skbuf_dma_descriptor {
* complete. Only updated at runtime by TX NAPI poll.
* @tx_bd_tail: Stores the index of the next Tx buffer descriptor in the ring
* to be populated.
+ * @tx_compl_bytes: Accumulates TX completion length until a full packet is
+ * reported to the stack.
* @tx_packets: TX packet count for statistics
* @tx_bytes: TX byte count for statistics
* @tx_stat_sync: Synchronization object for TX stats
@@ -592,6 +594,7 @@ struct axienet_local {
u32 tx_bd_num;
u32 tx_bd_ci;
u32 tx_bd_tail;
+ u32 tx_compl_bytes;
u64_stats_t tx_packets;
u64_stats_t tx_bytes;
struct u64_stats_sync tx_stat_sync;
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index b06e4c37ff61..95bf61986cb7 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -692,6 +692,8 @@ static void axienet_dma_stop(struct axienet_local *lp)
axienet_lock_mii(lp);
__axienet_device_reset(lp);
axienet_unlock_mii(lp);
+
+ lp->tx_compl_bytes = 0;
}
/**
@@ -770,8 +772,6 @@ static int axienet_device_reset(struct net_device *ndev)
* @first_bd: Index of first descriptor to clean up
* @nr_bds: Max number of descriptors to clean up
* @force: Whether to clean descriptors even if not complete
- * @sizep: Pointer to a u32 filled with the total sum of all bytes
- * in all cleaned-up descriptors. Ignored if NULL.
* @budget: NAPI budget (use 0 when not called from NAPI poll)
*
* Would either be called after a successful transmit operation, or after
@@ -780,7 +780,7 @@ static int axienet_device_reset(struct net_device *ndev)
* Return: The number of packets handled.
*/
static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
- int nr_bds, bool force, u32 *sizep, int budget)
+ int nr_bds, bool force, int budget)
{
struct axidma_bd *cur_p;
unsigned int status;
@@ -819,8 +819,8 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
cur_p->cntrl = 0;
cur_p->status = 0;
- if (sizep)
- *sizep += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
+ if (!force)
+ lp->tx_compl_bytes += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
}
if (!force) {
@@ -999,18 +999,18 @@ static int axienet_tx_poll(struct napi_struct *napi, int budget)
{
struct axienet_local *lp = container_of(napi, struct axienet_local, napi_tx);
struct net_device *ndev = lp->ndev;
- u32 size = 0;
int packets;
packets = axienet_free_tx_chain(lp, lp->tx_bd_ci, lp->tx_bd_num, false,
- &size, budget);
+ budget);
if (packets) {
- netdev_completed_queue(ndev, packets, size);
+ netdev_completed_queue(ndev, packets, lp->tx_compl_bytes);
u64_stats_update_begin(&lp->tx_stat_sync);
u64_stats_add(&lp->tx_packets, packets);
- u64_stats_add(&lp->tx_bytes, size);
+ u64_stats_add(&lp->tx_bytes, lp->tx_compl_bytes);
u64_stats_update_end(&lp->tx_stat_sync);
+ lp->tx_compl_bytes = 0;
/* Matches barrier in axienet_start_xmit */
smp_mb();
@@ -1115,7 +1115,7 @@ axienet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
netdev_err(ndev, "TX DMA mapping error\n");
ndev->stats.tx_dropped++;
axienet_free_tx_chain(lp, orig_tail_ptr, ii + 1,
- true, NULL, 0);
+ true, 0);
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
--
2.49.1
^ permalink raw reply related
* [PATCH net 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-24 14:53 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
This patch series fixes two issues in the Xilinx AXI Ethernet driver:
1. Corrects the BD length masks to match the AXIDMA IP spec.
2. Fixes BQL accounting for multi-BD TX packets.
Suraj Gupta (2):
net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
drivers/net/ethernet/xilinx/xilinx_axienet.h | 7 +++++--
.../net/ethernet/xilinx/xilinx_axienet_main.c | 20 +++++++++----------
2 files changed, 15 insertions(+), 12 deletions(-)
--
2.49.1
^ permalink raw reply
* [PATCH net 1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
From: Suraj Gupta @ 2026-03-24 14:53 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
In-Reply-To: <20260324145353.1899248-1-suraj.gupta2@amd.com>
The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK
macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP
product guide (PG021) specifies the buffer length field as bits 25:0
(26 bits). Update both masks to 0x03FFFFFF to match the IP
documentation.
In practice this had no functional impact, since Ethernet frames are
far smaller than 2^23 bytes and the extra bits were always zero, but
the masks should still reflect the hardware specification.
Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 5ff742103beb..602389843342 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -105,7 +105,7 @@
#define XAXIDMA_BD_HAS_DRE_MASK 0xF00 /* Whether has DRE mask */
#define XAXIDMA_BD_WORDLEN_MASK 0xFF /* Whether has DRE mask */
-#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
+#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x03FFFFFF /* Requested len */
#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
@@ -130,7 +130,7 @@
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
-#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
+#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x03FFFFFF /* Actual len */
#define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
#define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
#define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
--
2.49.1
^ permalink raw reply related
* Re: [PATCH v7 12/41] KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE
From: Mark Brown @ 2026-03-24 14:53 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sascha Bischoff, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, kvm@vger.kernel.org, nd,
oliver.upton@linux.dev, Joey Gouly, Suzuki Poulose,
yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes, jonathan.cameron@huawei.com
In-Reply-To: <86se9p472z.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
On Tue, Mar 24, 2026 at 02:48:04PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > We're also seeing an issue with this in the aarch32_id_regs test:
...
> > which for some reason only manifests on TX2 of the platforms I've
> > seen.
> Is your TX2 the only machine you have that is AArch64 only at all ELs?
Yes, that should be the case.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v7 12/41] KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE
From: Marc Zyngier @ 2026-03-24 14:48 UTC (permalink / raw)
To: Mark Brown
Cc: Sascha Bischoff, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, kvm@vger.kernel.org, nd,
oliver.upton@linux.dev, Joey Gouly, Suzuki Poulose,
yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes, jonathan.cameron@huawei.com
In-Reply-To: <638a3453-91c9-4a76-8241-25d5c27ca518@sirena.org.uk>
On Tue, 24 Mar 2026 12:47:24 +0000,
Mark Brown <broonie@kernel.org> wrote:
>
> [1 <text/plain; us-ascii (7bit)>]
> On Thu, Mar 19, 2026 at 03:52:50PM +0000, Sascha Bischoff wrote:
> > Add in a sanitization function for ID_AA64PFR2_EL1, preserving the
> > already-present behaviour for the FPMR, MTEFAR, and MTESTOREONLY
> > fields. Add sanitisation for the GCIE field, which is set to IMP if
> > the host supports a GICv5 guest and NI, otherwise.
>
> We're also seeing an issue with this in the aarch32_id_regs test:
>
> # selftests: kvm: aarch32_id_regs
> # Random seed: 0x6b8b4567
> # ==== Test Assertion Failure ====
> # arm64/aarch32_id_regs.c:25: read_sysreg_s((((3) << 19) | ((0) << 16) | ((0) << 12) | ((1) << 8) | ((1) << 5))) == 0
> # pid=3111 tid=3111 errno=4 - Interrupted system call
> # sh: 1: addr2line: not found
> # 0x10000000 != 0x0 (read_sysreg_s((((3) << 19) | ((0) << 16) | ((0) << 12) | ((1) << 8) | ((1) << 5))) != 0)
> not ok 9 selftests: kvm: aarch32_id_regs # exit=254
>
> which for some reason only manifests on TX2 of the platforms I've
> seen.
Is your TX2 the only machine you have that is AArch64 only at all ELs?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH V2] arm64: dts: imx8mp-evk: Disable PCIe bus in the default dts
From: Frank Li @ 2026-03-24 14:46 UTC (permalink / raw)
To: Sherry Sun
Cc: s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Hongxing Zhu, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB121140F94476DBC9D2F845ADC9248A@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Mar 24, 2026 at 02:45:39AM +0000, Sherry Sun wrote:
> > > Subject: Re: [PATCH V2] arm64: dts: imx8mp-evk: Disable PCIe bus in
> > > the default dts
> > >
> > > On Fri, Mar 20, 2026 at 05:03:53PM +0800, Sherry Sun wrote:
> > > > Disable the PCIe bus in the default device tree to avoid shared
> > > > regulator conflicts between SDIO and PCIe buses. The
> > > > non-deterministic probe order between these two buses can break the
> > > > PCIe initialization sequence, causing PCIe devices to fail detection
> > intermittently.
> > > >
> > > > On i.MX8MP EVK board, the M.2 connector is physically wired to both
> > > > USDHC1 and PCIe0, however the out-of-box module is SDIO IW612 WiFi,
> > > > so enable the SDIO WiFi in the default imx8mp-evk.dts, and provide a
> > > > separate device tree overlay (imx8mp-evk-pcie.dtso) to enable the
> > > > PCIe bus when needed.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > ---
> > > > Chanegs in V2:
> > > > 1. Improve the commit message to clarify SDIO WiFi is the out-of-box
> > > module on
> > > > i.MX8MP EVK board.
> > > > ---
> > > > arch/arm64/boot/dts/freescale/Makefile | 4 +++-
> > > > .../boot/dts/freescale/imx8mp-evk-pcie.dtso | 19
> > +++++++++++++++++++
> > > > arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
> > > > 3 files changed, 24 insertions(+), 3 deletions(-) create mode
> > > > 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > > > b/arch/arm64/boot/dts/freescale/Makefile
> > > > index 780682258e71..107ca270ef32 100644
> > > > --- a/arch/arm64/boot/dts/freescale/Makefile
> > > > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > > > @@ -333,12 +333,14 @@ imx8mp-evk-lvds0-imx-lvds-hdmi-dtbs +=
> > > > imx8mp-evk.dtb imx8mp-evk-lvds0-imx-lvds-
> > > > imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0-dtbs += imx8mp-evk.dtb
> > > > imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtbo
> > > > imx8mp-evk-lvds1-imx-lvds-hdmi-dtbs += imx8mp-evk.dtb
> > > > imx8mp-evk-lvds1-imx-lvds-hdmi.dtbo
> > > > imx8mp-evk-mx8-dlvds-lcd1-dtbs += imx8mp-evk.dtb
> > > > imx8mp-evk-mx8-dlvds-lcd1.dtbo -imx8mp-evk-pcie-ep-dtbs +=
> > > > imx8mp-evk.dtb imx-pcie0-ep.dtbo
> > > > +imx8mp-evk-pcie-dtbs := imx8mp-evk.dtb imx8mp-evk-pcie.dtbo
> > > > +imx8mp-evk-pcie-ep-dtbs += imx8mp-evk-pcie.dtb imx-pcie0-ep.dtbo
> > > > dtb-$(CONFIG_ARCH_MXC) +=
> > > > imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtb
> > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds0-imx-lvds-hdmi.dtb
> > > > dtb-$(CONFIG_ARCH_MXC) +=
> > > > imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtb
> > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds1-imx-lvds-hdmi.dtb
> > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-mx8-dlvds-lcd1.dtb
> > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-pcie.dtb
> > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-pcie-ep.dtb
> > > >
> > > > imx8mp-tqma8mpql-mba8mpxl-lvds-tm070jvhg33-dtbs +=
> > > > imx8mp-tqma8mpql-mba8mpxl.dtb
> > > > imx8mp-tqma8mpql-mba8mpxl-lvds-tm070jvhg33.dtbo
> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > > b/arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > > new file mode 100644
> > > > index 000000000000..4f6546d442bf
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > > @@ -0,0 +1,19 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > +/*
> > > > + * Copyright 2026 NXP
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +/plugin/;
> > > > +
> > > > +&pcie_phy {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > +&pcie0 {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > +&usdhc1 {
> > > > + status = "disabled";
> > > > +};
> > >
> > > Please use one overlay for both imx95 and imx8mp to enable pcie0 and
> > > disable usdhc1.
> >
> > Hi Frank,
> >
> > imx8mp has a specific pcie_phy, I disabled it in the default imx8mp-evk.dts
Suppose, you needn't disable phy.
> > and enabled it in xxx-pcie.dtso, if we use one overlay for both imx95 and
> > imx8mp, is it acceptable that we need to keep the 8mp pcie_phy enabled
> > even in non-PCIe usage scenarios?
> >
>
> In addition, another difference between imx8mp and imx95 is that imx8mp connects usdhc1 to the M.2 connector, while imx95 connects usdhc3 to the M.2 connector. The usdhc interfaces are different, so we cannot use the same DTSO file.
you use addtional label.
for example
m2_usdhc: &usdhc1 {
...
};
in overlay file
&m2_usdhc {
status = "disabled";
}
Frank
>
> Best Regards
> Sherry
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Inject UNDEF when host is executing an smc with imm16 != 0
From: Marc Zyngier @ 2026-03-24 14:43 UTC (permalink / raw)
To: Sebastian Ene
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, oupton, suzuki.poulose,
tabba, vdonnefort, will, yuzenghui
In-Reply-To: <20260324135728.3532400-1-sebastianene@google.com>
On Tue, 24 Mar 2026 13:57:28 +0000,
Sebastian Ene <sebastianene@google.com> wrote:
>
> The ARM Service Calling Convention (SMCCC) specifies that the function
> identifier and parameters should be passed in registers, leaving the
> 16-bit immediate field of the SMC instruction un-handled.
> Currently, our pKVM handler ignores the immediate value, which could lead
> to non-compliant software relying on implementation-defined behavior.
> Enforce the host kernel running under pKVM to use an immediate value
> of 0 by decoding the ISS from the ESR_EL2 and inject an undefined
> instruction exception back to the caller.
No, that's completely wrong. SMC never UNDEFs, unless EL3 isn't
implemented. You can't just decide to generate an UNDEF because you
don't like the immediate.
All you are allowed to do is to return an error code.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-evk: Specify ADV7535 register addresses
From: Frank Li @ 2026-03-24 14:42 UTC (permalink / raw)
To: Liu Ying
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324-imx8mp-evk-adv7535-cec-reg-addr-v1-1-52dbdd63d5a4@nxp.com>
On Tue, Mar 24, 2026 at 01:52:03PM +0800, Liu Ying wrote:
> MIPI DSI to HDMI bridge ADV7535 CEC default register address is 0x3c
> on an I2C bus. And, OV5640 camera uses the same address on the same
> I2C bus. To resolve this conflict, use 0x3b as ADV7535 CEC register
> address by specifying all ADV7535 register addresses.
Does cec start address programmable? generally i2c address is fixed or
controller by some gpio.
Frank
>
> Fixes: 6f6c18cba16f ("arm64: dts: imx8mp-evk: add camera ov5640 and related nodes")
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> index aedc09937716..d0a2bd975a18 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> @@ -602,7 +602,8 @@ ov5640_mipi_0_ep: endpoint {
>
> hdmi@3d {
> compatible = "adi,adv7535";
> - reg = <0x3d>;
> + reg = <0x3d>, <0x3f>, <0x3b>, <0x38>;
> + reg-names = "main", "edid", "cec", "packet";
> interrupt-parent = <&gpio1>;
> interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
> adi,dsi-lanes = <4>;
>
> ---
> base-commit: 09c0f7f1bcdbc3c37a5a760cbec76bf18f278406
> change-id: 20260324-imx8mp-evk-adv7535-cec-reg-addr-2de67760133a
>
> Best regards,
> --
> Liu Ying <victor.liu@nxp.com>
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Inject UNDEF when host is executing an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-24 14:41 UTC (permalink / raw)
To: Vincent Donnefort
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <acKacAd6aV32624m@google.com>
On Tue, Mar 24, 2026 at 02:06:40PM +0000, Vincent Donnefort wrote:
> On Tue, Mar 24, 2026 at 01:57:28PM +0000, Sebastian Ene wrote:
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field of the SMC instruction un-handled.
> > Currently, our pKVM handler ignores the immediate value, which could lead
> > to non-compliant software relying on implementation-defined behavior.
> > Enforce the host kernel running under pKVM to use an immediate value
> > of 0 by decoding the ISS from the ESR_EL2 and inject an undefined
> > instruction exception back to the caller.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index e7790097db93..ff6a90a4a4c7 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -756,13 +756,18 @@ static bool handle_host_mte(u64 esr)
> > void handle_trap(struct kvm_cpu_context *host_ctxt)
> > {
> > u64 esr = read_sysreg_el2(SYS_ESR);
> > + u16 imm16;
> >
> > switch (ESR_ELx_EC(esr)) {
> > case ESR_ELx_EC_HVC64:
> > handle_host_hcall(host_ctxt);
> > break;
> > case ESR_ELx_EC_SMC64:
> > - handle_host_smc(host_ctxt);
> > + imm16 = esr & U16_MAX;
> > + if (!imm16)
>
Hi Vincent,
> if (ESR_ELx_xVC_IMM_MASK(esr)) ?
Yes we can use this instead.
>
> Also, I can't find void inject_undef64(void); I think you need a vcpu for that?
>
Right, there is one version that does that.
> > + handle_host_smc(host_ctxt);
> > + else
> > + inject_undef64();
> > break;
> > case ESR_ELx_EC_IABT_LOW:
> > case ESR_ELx_EC_DABT_LOW:
> > --
> > 2.53.0.983.g0bb29b3bc5-goog
> >
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH 1/2] iommu/arm-smmu-v3: Do not continue in __arm_smmu_domain_inv_range()
From: Pranjal Shrivastava @ 2026-03-24 14:40 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jgg, linux-arm-kernel, iommu,
linux-kernel
In-Reply-To: <20260321225041.11090-2-nicolinc@nvidia.com>
On Sat, Mar 21, 2026 at 03:50:40PM -0700, Nicolin Chen wrote:
> The loop in the __arm_smmu_domain_inv_range() is a while loop, not a for
> loop. So, using "continue" is wrong that would fail to move the needle.
>
> Meanwhile, though the current command is skipped, the batch still has to
> go through arm_smmu_invs_end_batch() to be issued accordingly.
>
> Thus, use "break" to fix the issue.
>
> Fixes: 587bb3e56a2c ("iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range()")
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ 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