* [PATCH v9 20/20] coresight: sysfs: Validate CPU online status for per-CPU sources
From: Leo Yan @ 2026-04-01 18:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz
Cc: coresight, linux-arm-kernel, Leo Yan
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
The current SysFS flow first enables the links and sink, then rolls back
to disable them if the source fails to enable. This failure can occur if
the associated CPU is offline, which causes the SMP call to fail.
Validate whether the associated CPU is online for a per-CPU tracer. If
the CPU is offline, return -ENODEV and bail out.
Tested-by: James Clark <james.clark@linaro.org>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-sysfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index 75dd8c9f78174b7e604fbad6e8735656a2d643a0..b79c0abfeb77ed6f8fa299f083e0b6c656e0e6c1 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -184,6 +184,9 @@ static int coresight_validate_source_sysfs(struct coresight_device *csdev,
return -EINVAL;
}
+ if (coresight_is_percpu_source(csdev) && !cpu_online(csdev->cpu))
+ return -ENODEV;
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V5 0/2] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
From: Catalin Marinas @ 2026-04-01 18:13 UTC (permalink / raw)
To: linux-arm-kernel, Anshuman Khandual
Cc: Will Deacon, Ryan Roberts, David Hildenbrand, Yang Shi,
Christoph Lameter, linux-kernel
In-Reply-To: <20260309025725.455004-1-anshuman.khandual@arm.com>
On Mon, 09 Mar 2026 02:57:23 +0000, Anshuman Khandual wrote:
> This series enables batched TLB flush in unmap_hotplug_range() which avoids
> individual page TLB flush for potential CONT blocks in linear mapping while
> also improving performance due to range based TLB operation along with less
> synchronization barrier instructions.
>
> It also now rejects memory removal that might split a leaf entry in kernel
> mapping, which would have otherwise required re-structuring using the break
> before make (BBM) semantics. But kernel cannot tolerate BBM, so remapping to
> fine grained leaves would not be possible on systems without BBML2_NOABORT.
>
> [...]
Applied to arm64 (for-next/hotplug-batched-tlbi), thanks!
[1/2] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
https://git.kernel.org/arm64/c/48478b9f7913
[2/2] arm64/mm: Reject memory removal that splits a kernel leaf mapping
https://git.kernel.org/arm64/c/95a58852b0e5
^ permalink raw reply
* Re: [PATCH v2] arm64: mm: Use generic enum pgtable_level
From: Catalin Marinas @ 2026-04-01 18:13 UTC (permalink / raw)
To: linux-arm-kernel, Kevin Brodsky
Cc: Will Deacon, linux-kernel, David Hildenbrand (Arm), Ryan Roberts
In-Reply-To: <20260318092543.73331-1-kevin.brodsky@arm.com>
On Wed, 18 Mar 2026 09:25:43 +0000, Kevin Brodsky wrote:
> enum pgtable_type was introduced for arm64 by commit c64f46ee1377
> ("arm64: mm: use enum to identify pgtable level instead of
> *_SHIFT"). In the meantime, the generic enum pgtable_level got
> introduced by commit b22cc9a9c7ff ("mm/rmap: convert "enum
> rmap_level" to "enum pgtable_level"").
>
> Let's switch to the generic enum pgtable_level. The only difference
> is that it also includes PGD level; __pgd_pgtable_alloc() isn't
> expected to create PGD tables so we add a VM_WARN_ON() for that
> case.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: mm: Use generic enum pgtable_level
https://git.kernel.org/arm64/c/5e0deb0a6b4e
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Marc Zyngier @ 2026-04-01 18:28 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, joey.gouly, korneld, mrigendra.chaubey, oupton,
perlarsen, suzuki.poulose, will, yuzenghui
In-Reply-To: <ac1UNj7Z1uVL4Nf6@google.com>
On Wed, 01 Apr 2026 18:21:58 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> On Wed, Apr 01, 2026 at 03:55:11PM +0100, Marc Zyngier wrote:
> > On Wed, 01 Apr 2026 13:32:01 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > Make the SMC handlers accept a 64bit value for the function-id to keep
> > > it uniform with the rest of the code and prevent a u64 -> u32 -> u64
> > > conversion as it currently happens when we handle PSCI.
> >
> > That seems overly creative. The spec says (2.5, from ARM DEN 0028 1.6
> > G):
>
> I'm not plannig to be *overly creative*. Thanks for pointing out the ARM
> spec.
>
> >
> > "The Function Identifier is passed on W0 on every SMC and HVC
> > call. Its 32-bit integer value indicates which function is being
> > requested by the caller. It is always passed as the first argument to
> > every SMC or HVC call in R0 or W0."
> >
> > which indicates that it is *always* a 32bit value.
> >
> > So if you have a 64bit value somewhere, *that* should be fixed, not
> > propagated arbitrarily.
>
> If you have a non SMCCC call that happen to have the first 32-bits of
> the function-id matching either PSCI or FF-A you will end up handling
> them instead of forwarding it to Trustzone because func_id is declared as:
>
> DECLARE_REG(u64, func_id, host_ctxt, 0);
Again, the correct approach to prevent the propagation of something
that is known to be wrong. Something like this:
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 007fc993f2319..dae993a1d081b 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -694,6 +694,11 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
DECLARE_REG(u64, func_id, host_ctxt, 0);
bool handled;
+ if (upper_32_bits(func_id)) {
+ cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
+ kvm_skip_host_instr();
+ }
+
func_id &= ~ARM_SMCCC_CALL_HINTS;
handled = kvm_host_psci_handler(host_ctxt, func_id);
Because forwarding something that is blatantly illegal to the secure
side is not something we should accept at all (just like we now refuse
non-zero SMC immediate values).
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Marc Zyngier @ 2026-04-01 18:34 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, joey.gouly, korneld, mrigendra.chaubey, oupton,
perlarsen, suzuki.poulose, will, yuzenghui
In-Reply-To: <877bqqcz77.wl-maz@kernel.org>
On Wed, 01 Apr 2026 19:28:28 +0100,
Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 01 Apr 2026 18:21:58 +0100,
> Sebastian Ene <sebastianene@google.com> wrote:
> >
> > On Wed, Apr 01, 2026 at 03:55:11PM +0100, Marc Zyngier wrote:
> > > On Wed, 01 Apr 2026 13:32:01 +0100,
> > > Sebastian Ene <sebastianene@google.com> wrote:
> > > >
> > > > Make the SMC handlers accept a 64bit value for the function-id to keep
> > > > it uniform with the rest of the code and prevent a u64 -> u32 -> u64
> > > > conversion as it currently happens when we handle PSCI.
> > >
> > > That seems overly creative. The spec says (2.5, from ARM DEN 0028 1.6
> > > G):
> >
> > I'm not plannig to be *overly creative*. Thanks for pointing out the ARM
> > spec.
> >
> > >
> > > "The Function Identifier is passed on W0 on every SMC and HVC
> > > call. Its 32-bit integer value indicates which function is being
> > > requested by the caller. It is always passed as the first argument to
> > > every SMC or HVC call in R0 or W0."
> > >
> > > which indicates that it is *always* a 32bit value.
> > >
> > > So if you have a 64bit value somewhere, *that* should be fixed, not
> > > propagated arbitrarily.
> >
> > If you have a non SMCCC call that happen to have the first 32-bits of
> > the function-id matching either PSCI or FF-A you will end up handling
> > them instead of forwarding it to Trustzone because func_id is declared as:
> >
> > DECLARE_REG(u64, func_id, host_ctxt, 0);
>
> Again, the correct approach to prevent the propagation of something
> that is known to be wrong. Something like this:
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 007fc993f2319..dae993a1d081b 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -694,6 +694,11 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> bool handled;
>
> + if (upper_32_bits(func_id)) {
> + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> + kvm_skip_host_instr();
Plus the obviously missing:
+ return;
> + }
> +
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* RE: [PATCH v3 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by passing delay_us=0
From: Gupta, Suraj @ 2026-04-01 18:37 UTC (permalink / raw)
To: Alex Bereza, Vinod Koul, Frank Li, Simek, Michal,
Geert Uytterhoeven, Ulf Hansson, Arnd Bergmann, Tony Lindgren,
Rao, Appana Durga Kedareswara
Cc: dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-0-85508f0aedde@bereza.email>
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Alex Bereza <alex@bereza.email>
> Sent: Wednesday, April 1, 2026 4:27 PM
> To: Vinod Koul <vkoul@kernel.org>; Frank Li <Frank.Li@kernel.org>; Simek,
> Michal <michal.simek@amd.com>; Geert Uytterhoeven
> <geert+renesas@glider.be>; Ulf Hansson <ulf.hansson@linaro.org>; Arnd
> Bergmann <arnd@arndb.de>; Tony Lindgren <tony@atomide.com>; Rao,
> Appana Durga Kedareswara <appana.durga.kedareswara.rao@amd.com>
> Cc: dmaengine@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Alex Bereza <alex@bereza.email>
> Subject: [PATCH v3 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by
> passing delay_us=0
>
> [You don't often get email from alex@bereza.email. Learn why this is important
> at https://aka.ms/LearnAboutSenderIdentification ]
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Signed-off-by: Alex Bereza <alex@bereza.email>
> ---
For the series, Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Thanks!
Suraj
> Changes in v3:
> - patch 1/2:
> - Fix commit message: remove blank line between tags
> - patch 2/2: nothing
> - Link to v2: https://patch.msgid.link/20260401-fix-atomic-poll-timeout-
> regression-v2-0-68a265e3770f@bereza.email
>
> Changes in v2:
> - Fixed the Fixes: tags as suggested by Geert Uytterhoeven
> <geert+renesas@glider.be> - thanks!
> - Split the renaming of XILINX_DMA_LOOP_COUNT into separate commit
> - Link to v1: https://patch.msgid.link/20260331-fix-atomic-poll-timeout-
> regression-v1-1-5b7bd96eaca0@bereza.email
>
> ---
> Alex Bereza (2):
> dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
> dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
>
> drivers/dma/xilinx/xilinx_dma.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
> ---
> base-commit: b7560798466a07d9c3fb011698e92c335ab28baf
> change-id: 20260330-fix-atomic-poll-timeout-regression-4f4e3baf3fd7
>
> Best regards,
> --
> Alex Bereza <alex@bereza.email>
>
^ permalink raw reply
* [PATCH 1/2] media: cedrus: Fix missing cleanup in error path
From: Andrey Skvortsov @ 2026-04-01 19:14 UTC (permalink / raw)
To: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
Cc: Andrey Skvortsov
From: Samuel Holland <samuel@sholland.org>
From: Samuel Holland <samuel@sholland.org>
According to the documentation struct v4l2_fh has to be cleaned up with
v4l2_fh_exit() before being freed. [1]
1. https://docs.kernel.org/driver-api/media/v4l2-fh.html
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 6600245dff0e2..1d2130f35fffc 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -391,6 +391,7 @@ static int cedrus_open(struct file *file)
err_m2m_release:
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
err_free:
+ v4l2_fh_exit(&ctx->fh);
kfree(ctx);
mutex_unlock(&dev->dev_mutex);
--
2.51.0
^ permalink raw reply related
* [PATCH 2/2] media: cedrus: Fix failure to clean up hardware on probe failure
From: Andrey Skvortsov @ 2026-04-01 19:14 UTC (permalink / raw)
To: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
Cc: Andrey Skvortsov
In-Reply-To: <20260401191441.1217646-1-andrej.skvortzov@gmail.com>
From: Samuel Holland <samuel@sholland.org>
From: Samuel Holland <samuel@sholland.org>
cedrus_hw_remove undoes, that was done by cedrus_hw_probe previously,
like disabling runtime power management, releasing claimed sram.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 1d2130f35fffc..ee0e286add67d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -477,7 +477,7 @@ static int cedrus_probe(struct platform_device *pdev)
ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
if (ret) {
dev_err(&pdev->dev, "Failed to register V4L2 device\n");
- return ret;
+ goto err_hw;
}
vfd = &dev->vfd;
@@ -538,6 +538,8 @@ static int cedrus_probe(struct platform_device *pdev)
v4l2_m2m_release(dev->m2m_dev);
err_v4l2:
v4l2_device_unregister(&dev->v4l2_dev);
+err_hw:
+ cedrus_hw_remove(dev);
return ret;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 0/5] crc64: Tweak intrinsics code and enable it for ARM
From: Eric Biggers @ 2026-04-01 19:59 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel, Demian Shulhan
In-Reply-To: <20260330144630.33026-7-ardb@kernel.org>
On Mon, Mar 30, 2026 at 04:46:31PM +0200, Ard Biesheuvel wrote:
> Apply some tweaks to the new arm64 crc64 NEON intrinsics code, and wire
> it up for the 32-bit ARM build. Note that true 32-bit ARM CPUs usually
> don't implement the prerequisite 64x64 PMULL instructions, but 32-bit
> kernels are commonly used on 64-bit capable hardware too, which do
> implement the 32-bit versions of the crypto instructions if they are
> implemented for the 64-bit ISA (as per the architecture).
>
> Cc: Demian Shulhan <demyansh@gmail.com>
> Cc: Eric Biggers <ebiggers@kernel.org>
>
> Ard Biesheuvel (5):
> lib/crc: arm64: Drop unnecessary chunking logic from crc64
> lib/crc: arm64: Use existing macros for kernel-mode FPU cflags
> ARM: Add a neon-intrinsics.h header like on arm64
> lib/crc: arm64: Simplify intrinsics implementation
> lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
I think patches 3 and 4 should be swapped, so it's cleanups first (which
make sense regardless of the 32-bit ARM support) and then the 32-bit ARM
support.
I do think we should be aware that even with the code mostly shared
using the NEON intrinsics, the 32-bit ARM support (which works only on
CPUs that support PMULL, i.e. are also 64-bit capable) doesn't come for
free. We should expect to deal with occasional issues related to the
intrinsics with certain compiler versions, compiler flags, etc.
I assume that "32-bit kernels on ARMv8 CPUs" is currently still a big
enough niche to bother with this, despite that niche getting smaller
over time. But as I mentioned I do think we should try to simplify it
as much as possible, e.g. by supporting little-endian only and avoiding
#ifdefs based on things like the compiler whenever possible.
- Eric
^ permalink raw reply
* Re: [PATCH 6.1.y 5/8] nvme-apple: remove an extra queue reference
From: Fedor Pchelkin @ 2026-04-01 20:45 UTC (permalink / raw)
To: Heyne, Maximilian, Christoph Hellwig
Cc: Sagi Grimberg, stable@vger.kernel.org, Sven Peter,
Chaitanya Kulkarni, Keith Busch, Jens Axboe, Hector Martin,
Alyssa Rosenzweig, James E.J. Bottomley, Martin K. Petersen,
Alim Akhtar, Avri Altman, Bart Van Assche, Sasha Levin,
Peter Wang, Greg Kroah-Hartman, Seunghui Lee, Sanjeev Yadav,
Wonkon Kim, Brian Kao, Hannes Reinecke, Ming Lei,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <20260401-pliny-ashley-ff03a0b6@mheyne-amazon>
Hello,
"Heyne, Maximilian" <mheyne@amazon.de> wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> [ Upstream commit 941f7298c70c7668416e7845fa76eb72c07d966b ]
>
> Now that blk_mq_destroy_queue does not release the queue reference, there
> is no need for a second admin queue reference to be held by the
> apple_nvme structure.
This patch is probably buggy in upstream. It removes extra reference
->get, but doesn't remove the corresponding ->put which is located
inside apple_nvme_free_ctrl().
I'm reporting here currently just for the heads up - was looking at the
same nvme regression problem at 6.1.y, found this thread, and the
nvme-apple changes appeared suspicious.
nvme-apple patch is not required to fix the regression (this also holds
true for [PATCH 6.1.y 3/8] scsi: remove an extra queue reference). Maybe
they shouldn't go to stable.
That said, the other part of the backport series FWIW looks good to me,
and I've also verified it resolves the 6.1.y regression.
Thanks.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
> Reviewed-by: Sven Peter <sven@svenpeter.dev>
> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
> Reviewed-by: Keith Busch <kbusch@kernel.org>
> Link: https://lore.kernel.org/r/20221018135720.670094-5-hch@lst.de
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
> ---
> drivers/nvme/host/apple.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
> index c5fc293c22123..c84ebfcfdeb88 100644
> --- a/drivers/nvme/host/apple.c
> +++ b/drivers/nvme/host/apple.c
> @@ -1507,15 +1507,6 @@ static int apple_nvme_probe(struct platform_device *pdev)
> goto put_dev;
> }
>
> - if (!blk_get_queue(anv->ctrl.admin_q)) {
> - nvme_start_admin_queue(&anv->ctrl);
> - blk_mq_destroy_queue(anv->ctrl.admin_q);
> - blk_put_queue(anv->ctrl.admin_q);
> - anv->ctrl.admin_q = NULL;
> - ret = -ENODEV;
> - goto put_dev;
> - }
> -
> nvme_reset_ctrl(&anv->ctrl);
> async_schedule(apple_nvme_async_probe, anv);
>
> --
> 2.50.1
^ permalink raw reply
* Re: [RFT PATCH 0/7] perf tool: Support iostat for multiple platforms
From: Ian Rogers @ 2026-04-01 20:52 UTC (permalink / raw)
To: wangyushan
Cc: mike.leach, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, adrian.hunter, peterz, john.g.garry,
Jonathan.Cameron, shiju.jose, will, linux-perf-users,
linux-arm-kernel, linuxarm, liuyonglong, prime.zeng, fanghao11,
wangzhou1
In-Reply-To: <d8639ed9-63d9-4a61-8cce-72f4b7fcb872@huawei.com>
On Thu, Jan 29, 2026 at 7:15 AM wangyushan <wangyushan12@huawei.com> wrote:
>
>
>
> On 1/27/2026 1:01 AM, Ian Rogers wrote:
> > On Mon, Jan 26, 2026 at 4:35 AM Yushan Wang <wangyushan12@huawei.com> wrote:
> >> Currently, platform-specific iostat code for PMUs is implemented as a
> >> common iostat callback interface and invoked based on what is being
> >> built. This approach limits support for iostat across different types of
> >> PMUs.
> >>
> >> Support of HiSilicon PCIe PMU iostat was raised at [1], which uses the
> >> similar approach.
> >>
> >> To extend support of iostat across platforms, change common iostat
> >> interface to framework to allow perf to probe PMU capabilities during
> >> runtime and route iostat request to the correct PMU-specific functions.
> >> Then HiSilicon PCIe PMU iostat is supported with the new framework.
> >>
> >> Request For Test:
> >> Refactors has been made to x86 iostat to adapt the iostat framework, the
> >> probe function that checks if there's any PMU's name contains 'x86-iio'
> >> may not work properly, tests of that would be appreciated.
> >>
> >> [1] https://lore.kernel.org/all/4688a613-c94a-49b0-9d0f-09173c64082d@arm.com/
> >>
> >> Shiju Jose (2):
> >> perf-iostat: Extend iostat interface to support different iostat PMUs
> >> perf-iostat: Make x86 iostat compatible with new iostat framework
> >>
> >> Yicong Yang (1):
> >> perf-iostat: Enable iostat mode for HiSilicon PCIe PMU
> >>
> >> Yushan Wang (4):
> >> perf stat: Check color's length instead of the pointer
> >> perf stat: Save unnecessary print_metric() call
> >> perf-x86: iostat: Change iostat_prefix() to static
> >> perf-iostat: Support wilder wildcard-match for pmus
> > Hi,
> >
> > Thanks for the changes! Given the iostat code is display code, it'd be
> > great if we could avoid the arch directory usage. For example, I may
> > record data on a machine with a HiSilicon PCIe PMU but then want to
> > look at the data on an x86 laptop, as the code is under arch/arm64 it
> > won't get built.Given the PMU name is unique, is it possible to put
> > this code into tools/perf/util and determine whether to use it or not
> > by seeing if the PMU is present by its name? I know that means
> > refactoring the x86 code that hasn't done this.
>
> Yes, iostat itself didn't do much more than rearrange the display
> format. I can try to refactor that to the util directory, though x86
> iostat may need even more testing :)
>
> > A thought that is away from the iostat code and may simplify the code
> > base is that we could introduce system PMU, rather than CPU, dependent
> > metrics. Perhaps the iostat code could be replaced by a particular
> > metric group like Default or TopdownL1, so `perf iostat` becomes
> > something of a synonym for `perf stat -M iostat`. An example of what
> > this may look like is (unmerged):
> > https://lore.kernel.org/lkml/20260108191105.695131-34-irogers@google.com/
> > where I introduce a memory bandwidth saturation metric dependent on
> > uncore PMUs (either cbox or cha) on Intel. There is a metric
> > "have_event" function that can be used to make a metric conditional.
> > If you `perf stat record` a metric today and then look at the
> > perf.data with `perf script --fields metric` (IIRC) then every metric
> > that has the recorded events within it will be computed, although the
> > code needs better testing, etc. I suspect the biggest downside to this
> > approach is in how the output looks, but perhaps that can be tweaked.
> > For example, the `ilist.py` command:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/python/ilist.py?h=perf-tools-next
> > supports regular metrics.
> Since iostat is a small sub-command with not many events involved,
> it is great to have some events extracted as system metrics, like PCIe
> bandwidth etc.
>
> But the variety of bdf filtering and display may be difficult to adapt
> to the way metric does it. What do you think if we leave the iostat as
> is for now and maybe merge it to system metric infrastructure later?
>
> > That said, I'm not against the changes, the arch directory usage, not
> > using json metrics, etc. and this change is doing clean up, following
> > existing patterns, etc. Sometimes the codebase has evolved but certain
> > commands haven't kept up. I think `perf iostat` is a command like
> > that.
>
> And we are trying to make it follow up!
Hi Yushan, thanks for your effort on iostat! Did you have chance to
work on follow up?
Thanks,
Ian
> > Thanks,
> > Ian
>
> Thanks for the feedback!
> Yushan
> >> tools/perf/arch/arm64/util/Build | 1 +
> >> tools/perf/arch/arm64/util/hisi-iostat.c | 479 +++++++++++++++++++++++
> >> tools/perf/arch/x86/util/iostat.c | 105 +++--
> >> tools/perf/builtin-script.c | 2 +-
> >> tools/perf/util/iostat.c | 79 ++--
> >> tools/perf/util/iostat.h | 21 +-
> >> tools/perf/util/pmus.c | 12 +-
> >> tools/perf/util/pmus.h | 3 +
> >> tools/perf/util/stat-display.c | 4 +-
> >> tools/perf/util/stat-shadow.c | 4 +-
> >> 10 files changed, 638 insertions(+), 72 deletions(-)
> >> create mode 100644 tools/perf/arch/arm64/util/hisi-iostat.c
> >>
> >> --
> >> 2.33.0
> >>
>
^ permalink raw reply
* [GIT PULL] Rockchip dts64 changes for 7.1 #2
From: Heiko Stuebner @ 2026-04-01 21:27 UTC (permalink / raw)
To: arm; +Cc: soc, linux-rockchip, linux-arm-kernel
Hi soc maintainers,
please find below some more Rockchip DT changes for the merge-window
for 7.1 .
This time they have also marinated longer in next without complaints.
Please pull.
Thanks
Heiko
The following changes since commit d7787a77cf8b129304f590233032556dec10dfc6:
arm64: dts: rockchip: enable vicap dvp on wolfvision pf5 io expander (2026-03-13 21:39:34 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.1-rockchip-dts64-2
for you to fetch changes up to 6cb4ec63ba9a5831621cf951b7af55c67beeb97b:
arm64: dts: rockchip: configure hdmirx in Rock 5 ITX (2026-03-26 00:34:54 +0100)
----------------------------------------------------------------
New board, the Khadas Edge 2L. Newly added peripherals are the
OTP nvmem controllers for RK3528, RK3562 and RK3566/8, SPDIF on RK3576.
The RK3566/8 SoCs now also control the Pipe-clocks on their PCIe
controllers and UFSHC controller on RK3576 got an additional reset line.
Apart from that are of course individual board changes and fixes for
older issues that are not specific to the current development cycle.
----------------------------------------------------------------
Anand Moon (1):
arm64: dts: rockchip: Enable PCIe CLKREQ# for RK3588 on Rock 5b-5bp-5t series
Chris Morgan (2):
arm64: dts: rockchip: Correct Fan Supply for Gameforce Ace
arm64: dts: rockchip: Correct Joystick Axes on Gameforce Ace
David Heidelberg (1):
arm64: dts: rockchip: assign pipe clock to rk356x PCIe lanes
Gray Huang (2):
dt-bindings: arm: rockchip: Add Khadas Edge 2L board
arm64: dts: rockchip: Add Khadas Edge 2L board
Heiko Stuebner (2):
arm64: dts: rockchip: Enable OTP controller for RK3562
arm64: dts: rockchip: Enable OTP controller for RK356x
Jonas Karlman (1):
arm64: dts: rockchip: Enable OTP controller for RK3528
Ming Wang (1):
arm64: dts: rockchip: Fix Bluetooth stability on LCKFB TaiShan Pi
Pedro Alves (1):
arm64: dts: rockchip: configure hdmirx in Rock 5 ITX
Robin Murphy (1):
Revert "arm64: dts: rockchip: add SPDIF audio to Beelink A1"
Sebastian Reichel (2):
arm64: dts: rockchip: Add SPDIF nodes to RK3576 device tree
arm64: dts: rockchip: add SD/eMMC aliases for ArmSom Sige5
Shawn Lin (1):
arm64: dts: rockchip: Add mphy reset to ufshc node
谢致邦 (XIE Zhibang) (1):
arm64: dts: rockchip: Fix RK3562 EVB2 model name
.../devicetree/bindings/arm/rockchip.yaml | 5 ++
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 23 ------
arch/arm64/boot/dts/rockchip/rk3528.dtsi | 47 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3562-evb2-v10.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3562.dtsi | 46 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts | 4 +-
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 12 ++-
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 52 ++++++++++++-
.../boot/dts/rockchip/rk3576-armsom-sige5.dts | 2 +
.../boot/dts/rockchip/rk3576-khadas-edge-2l.dts | 34 +++++++++
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 87 +++++++++++++++++++++-
arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 12 +++
.../boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 6 +-
.../boot/dts/rockchip/rk3588s-gameforce-ace.dts | 12 +--
15 files changed, 303 insertions(+), 42 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
^ permalink raw reply
* [GIT PULL] ARM: soc/omap updates for v7.1
From: Kevin Hilman @ 2026-04-01 21:28 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.1/soc-signed
for you to fetch changes up to 9ceb17ccd15ea32f19c9066f5f1b340d8340bd0b:
ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4 (2026-03-30 14:21:20 -0700)
----------------------------------------------------------------
ARM: soc/omap updates for v7.1
----------------------------------------------------------------
Aaro Koskinen (1):
ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX
Julian Braha (1):
ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4
Randy Dunlap (1):
ARM: omap: fix all kernel-doc warnings
Thorsten Blum (1):
ARM: omap2: Replace scnprintf with strscpy in omap3_cpuinfo
arch/arm/mach-omap1/clock_data.c | 4 ++--
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-omap2/id.c | 3 ++-
include/linux/platform_data/voltage-omap.h | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply
* [GIT PULL] arm: OMAP defconfig updates for v7.1
From: Kevin Hilman @ 2026-04-01 21:29 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.1/defconfig-signed
for you to fetch changes up to adcf290f9de2fc4768e5ba07c700e91faf9c86bf:
arm: multi_v7_defconfig: Enable more OMAP 3/4 related configs (2026-03-05 16:45:57 -0800)
----------------------------------------------------------------
arm: OMAP defconfig updates for v7.1
----------------------------------------------------------------
Andreas Kemnade (1):
arm: multi_v7_defconfig: Enable more OMAP 3/4 related configs
Kory Maincent (TI) (1):
ARM: multi_v7_defconfig: omap2plus_defconfig: Enable ITE IT66121 driver
arch/arm/configs/multi_v7_defconfig | 28 ++++++++++++++++++++++++++++
arch/arm/configs/omap2plus_defconfig | 1 +
2 files changed, 29 insertions(+)
^ permalink raw reply
* [GIT PULL] ARM: dts: updates for ti/omap for v7.1
From: Kevin Hilman @ 2026-04-01 21:29 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.1/dt-signed
for you to fetch changes up to 2c4059f54f65ff1ee2d430fa023d25487cfb5b99:
ARM: dts: am335x: Add Seeed Studio BeagleBone HDMI cape overlay (2026-03-31 17:15:17 -0700)
----------------------------------------------------------------
ARM: dts: updates for ti/omap for v7.1
----------------------------------------------------------------
Andrew Goodbody (1):
ARM: dts: omap: dm816x: Correct pinctrl register
Charan Pedumuru (1):
arm: dts: ti: omap: align node patterns with established convention
Kory Maincent (TI) (2):
ARM: dts: ti: Enable overlays for am335x BeagleBoard devicetrees
ARM: dts: am335x: Add Seeed Studio BeagleBone HDMI cape overlay
Mithil Bavishi (8):
ARM: dts: twl6032: Add DTS file for TWL6032 PMIC
dt-bindings: vendor-prefixes: Add Doestek
dt-bindings: display: bridge: lvds-codec: add doestek,dtc34lm85am
dt-bindings: display: panel-lvds: Add compatibles for Samsung LTN070NL01 and LTN101AL03 panels
ARM: dts: ti: omap: espresso-common: Add common device tree for Samsung Galaxy Tab 2 series
dt-bindings: omap: Add Samsung Galaxy Tab 2 7.0 and 10.1
ARM: dts: ti: omap: samsung-espresso7: Add initial support for Galaxy Tab 2 7.0
ARM: dts: ti: omap: samsung-espresso10: Add initial support for Galaxy Tab 2 10.1
Documentation/devicetree/bindings/arm/ti/omap.yaml | 2 +
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 4 +
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/ti/omap/Makefile | 15 ++++
arch/arm/boot/dts/ti/omap/am335x-bone-hdmi-00a0.dtso | 157 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/ti/omap/dm816x.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-samsung-espresso-common.dtsi | 744 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/ti/omap/omap4-samsung-espresso10.dts | 101 +++++++++++++++++++++
arch/arm/boot/dts/ti/omap/omap4-samsung-espresso7.dts | 70 +++++++++++++++
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/twl6032.dtsi | 77 ++++++++++++++++
14 files changed, 1180 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/ti/omap/am335x-bone-hdmi-00a0.dtso
create mode 100644 arch/arm/boot/dts/ti/omap/omap4-samsung-espresso-common.dtsi
create mode 100644 arch/arm/boot/dts/ti/omap/omap4-samsung-espresso10.dts
create mode 100644 arch/arm/boot/dts/ti/omap/omap4-samsung-espresso7.dts
create mode 100644 arch/arm/boot/dts/ti/omap/twl6032.dtsi
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-rc6, upstream-arm-next, 90aebc1e)
From: cki-project @ 2026-04-01 21:52 UTC (permalink / raw)
To: will, linux-arm-kernel, catalin.marinas
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge remote-tracking branch 'origin/nocache-cleanup' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2424361415
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v10 04/12] arm64: support WFET in smp_cond_load_relaxed_timeout()
From: Ankur Arora @ 2026-04-01 22:31 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ankur Arora, linux-kernel, linux-arch, linux-arm-kernel, linux-pm,
bpf, arnd, will, peterz, akpm, mark.rutland, harisokn, cl, ast,
rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai, rdunlap,
david.laight.linux, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <acz3D1SkqDqyH0Dy@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> On Sun, Mar 15, 2026 at 06:36:43PM -0700, Ankur Arora wrote:
>> To handle WFET use __cmpwait_timeout() similarly to __cmpwait(). These
>> call out to the respective __cmpwait_case_timeout_##sz(),
>> __cmpwait_case_##sz() functions.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Great. Thanks Catalin.
--
ankur
^ permalink raw reply
* Re: [PATCH v15 4/5] ring-buffer: Add persistent ring buffer invalid-page inject test
From: Steven Rostedt @ 2026-04-01 22:40 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <177494619065.71933.9842685686800241005.stgit@mhiramat.tok.corp.google.com>
I replied with mostly grammar fixes and some rewrites of text.
On Tue, 31 Mar 2026 17:36:30 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> Add a self-destractive test for the persistent ring buffer.
"self-destractive"? Do you mean "self-destructive"?
Probably better to call it a "self-corrupting test".
>
> This will inject erroneous value to some sub-buffer pages (where
inject an erroneous
> the index is even or multiples of 5) in the persistent ring buffer
> when kernel gets panic, and check whether the number of detected
when the kernel panics, and checks whether
> invalid pages and the total entry_bytes are the same as recorded
same as the recorded
> values after reboot.
>
> This can ensure the kernel correctly recover partially corrupted
This ensures that the kernel can correctly recover a partially corrupted
> persistent ring buffer when boot.
after a reboot or panic.
>
> The test only runs on the persistent ring buffer whose name is
> "ptracingtest". And user has to fill it up with events before
The user has to fill it with events before a kernel panic.
> kernel panics.
>
> To run the test, enable CONFIG_RING_BUFFER_PERSISTENT_INJECT
> and you have to setup the kernel cmdline;
and add the following kernel cmdline:
Note, it's more proper to use a colon (:) than a semi-colon (;) when
referencing an example on the next line.
>
> reserve_mem=20M:2M:trace trace_instance=ptracingtest^traceoff@trace
> panic=1
>
> And run following commands after the 1st boot;
Run the following commands after the 1st boot:
>
> cd /sys/kernel/tracing/instances/ptracingtest
> echo 1 > tracing_on
> echo 1 > events/enable
> sleep 3
> echo c > /proc/sysrq-trigger
>
> After panic message, the kernel will reboot and run the verification
> on the persistent ring buffer, e.g.
>
> Ring buffer meta [2] invalid buffer page detected
> Ring buffer meta [2] is from previous boot! (318 pages discarded)
> Ring buffer testing [2] invalid pages: PASSED (318/318)
> Ring buffer testing [2] entry_bytes: PASSED (1300476/1300476)
>
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
> Changes in v15:
> - Use pr_warn() for test result.
> - Inject errors on the page index is multiples of 5 so that
> this can reproduce contiguous empty pages.
> Changes in v14:
> - Rename config to CONFIG_RING_BUFFER_PERSISTENT_INJECT.
> - Clear meta->nr_invalid/entry_bytes after testing.
> - Add test commands in config comment.
> Changes in v10:
> - Add entry_bytes test.
> - Do not compile test code if CONFIG_RING_BUFFER_PERSISTENT_SELFTEST=n.
> Changes in v9:
> - Test also reader pages.
> ---
> include/linux/ring_buffer.h | 1 +
> kernel/trace/Kconfig | 31 ++++++++++++++++++
> kernel/trace/ring_buffer.c | 74 +++++++++++++++++++++++++++++++++++++++++++
> kernel/trace/trace.c | 4 ++
> 4 files changed, 110 insertions(+)
>
> diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
> index 994f52b34344..0670742b2d60 100644
> --- a/include/linux/ring_buffer.h
> +++ b/include/linux/ring_buffer.h
> @@ -238,6 +238,7 @@ int ring_buffer_subbuf_size_get(struct trace_buffer *buffer);
>
> enum ring_buffer_flags {
> RB_FL_OVERWRITE = 1 << 0,
> + RB_FL_TESTING = 1 << 1,
> };
>
> #ifdef CONFIG_RING_BUFFER
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index e130da35808f..07305ed6d745 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -1202,6 +1202,37 @@ config RING_BUFFER_VALIDATE_TIME_DELTAS
> Only say Y if you understand what this does, and you
> still want it enabled. Otherwise say N
>
> +config RING_BUFFER_PERSISTENT_INJECT
> + bool "Enable persistent ring buffer error injection test"
> + depends on RING_BUFFER
> + help
> + Run a selftest on the persistent ring buffer which names
> + "ptracingtest" (and its backup) when panic_on_reboot by
Does this do anything with the backup?
> + invalidating ring buffer pages.
This option will have the kernel check if the persistent ring
buffer is named "ptracingtest", and if so, it will corrupt some
of its pages on a kernel panic. This is used to test if the
persistent ring buffer can recover from some of its sub-buffers
being corrupted.
[space]
> + To use this, boot kernel with "ptracingtest" persistent
, boot a kernel with a "ptracingtest" persistent
> + ring buffer, e.g.
> +
> + reserve_mem=20M:2M:trace trace_instance=ptracingtest@trace panic=1
> +
> + And after the 1st boot, run test command, like;
, run the following commands:
> +
> + cd /sys/kernel/tracing/instances/ptracingtest
> + echo 1 > events/enable
> + echo 1 > tracing_on
> + sleep 3
> + echo c > /proc/sysrq-trigger
> +
> + After panic message, the kernel reboots and show test results
> + on the boot log.
After the panic message, the kernel will reboot and will show the
test results in the console output.
> +
> + Note that user has to enable events on the persistent ring
> + buffer manually to fill up ring buffers before rebooting.
Note that events for the ring buffer needs to be enabled prior to
crashing the kernel so that the ring buffer has content that the
test will corrupt.
> + Since this invalidates the data on test target ring buffer,
> + "ptracingtest" persistent ring buffer must not be used for
> + actual tracing, but only for testing.
As the test will corrupt events in the "ptracingtest" persistent
ring buffer, it should not be used for any other purpose other
than his test.
> +
> + If unsure, say N
> +
> config MMIOTRACE_TEST
> tristate "Test module for mmiotrace"
> depends on MMIOTRACE && m
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 5ff632ca3858..fb098b0b4505 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -64,6 +64,10 @@ struct ring_buffer_cpu_meta {
> unsigned long commit_buffer;
> __u32 subbuf_size;
> __u32 nr_subbufs;
> +#ifdef CONFIG_RING_BUFFER_PERSISTENT_INJECT
> + __u32 nr_invalid;
> + __u32 entry_bytes;
> +#endif
> int buffers[];
> };
>
> @@ -2079,6 +2083,21 @@ static void rb_meta_validate_events(struct
> ring_buffer_per_cpu *cpu_buffer) if (discarded)
> pr_cont(" (%d pages discarded)", discarded);
> pr_cont("\n");
> +
> +#ifdef CONFIG_RING_BUFFER_PERSISTENT_INJECT
> + if (meta->nr_invalid)
> + pr_warn("Ring buffer testing [%d] invalid pages: %s (%d/%d)\n",
> + cpu_buffer->cpu,
> + (discarded == meta->nr_invalid) ? "PASSED" : "FAILED",
> + discarded, meta->nr_invalid);
> + if (meta->entry_bytes)
> + pr_warn("Ring buffer testing [%d] entry_bytes: %s (%ld/%ld)\n",
> + cpu_buffer->cpu,
> + (entry_bytes == meta->entry_bytes) ? "PASSED" : "FAILED",
> + (long)entry_bytes, (long)meta->entry_bytes);
> + meta->nr_invalid = 0;
> + meta->entry_bytes = 0;
> +#endif
> return;
>
> invalid:
> @@ -2559,12 +2578,67 @@ static void rb_free_cpu_buffer(struct
> ring_buffer_per_cpu *cpu_buffer) kfree(cpu_buffer);
> }
>
> +#ifdef CONFIG_RING_BUFFER_PERSISTENT_INJECT
> +static void rb_test_inject_invalid_pages(struct trace_buffer *buffer)
> +{
> + struct ring_buffer_per_cpu *cpu_buffer;
> + struct ring_buffer_cpu_meta *meta;
> + struct buffer_data_page *dpage;
> + u32 entry_bytes = 0;
> + unsigned long ptr;
> + int subbuf_size;
> + int invalid = 0;
> + int cpu;
> + int i;
> +
> + if (!(buffer->flags & RB_FL_TESTING))
> + return;
> +
> + guard(preempt)();
> + cpu = smp_processor_id();
> +
> + cpu_buffer = buffer->buffers[cpu];
> + meta = cpu_buffer->ring_meta;
> + ptr = (unsigned long)rb_subbufs_from_meta(meta);
> + subbuf_size = meta->subbuf_size;
> +
> + for (i = 0; i < meta->nr_subbufs; i++) {
> + int idx = meta->buffers[i];
> +
> + dpage = (void *)(ptr + idx * subbuf_size);
> + /* Skip unused pages */
> + if (!local_read(&dpage->commit))
> + continue;
> +
> + /*
> + * Invalidate even pages or multiples of 5. This will lead 3
This will cause 3
-- Steve
> + * contiguous invalidated(empty) pages.
> + */
> + if (!(i & 0x1) || !(i % 5)) {
> + local_add(subbuf_size + 1, &dpage->commit);
> + invalid++;
> + } else {
> + /* Count total commit bytes. */
> + entry_bytes += local_read(&dpage->commit);
> + }
> + }
> +
> + pr_info("Inject invalidated %d pages on CPU%d, total size: %ld\n",
> + invalid, cpu, (long)entry_bytes);
> + meta->nr_invalid = invalid;
> + meta->entry_bytes = entry_bytes;
> +}
^ permalink raw reply
* Re: [PATCH v3 2/2] dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
From: Frank Li @ 2026-04-01 22:40 UTC (permalink / raw)
To: Alex Bereza
Cc: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana,
dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-2-85508f0aedde@bereza.email>
On Wed, Apr 01, 2026 at 12:56:33PM +0200, Alex Bereza wrote:
> Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because the
> former is incorrect. It is a timeout value for polling various register
> bits in microseconds. It is not a loop count.
Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because it is a
timeout value, not a loop count for polling register in microseconds.
No functional changes.
Frank
>
> Signed-off-by: Alex Bereza <alex@bereza.email>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 345a738bab2c..253c27fd1a0e 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -165,8 +165,8 @@
> #define XILINX_DMA_FLUSH_MM2S 2
> #define XILINX_DMA_FLUSH_BOTH 1
>
> -/* Delay loop counter to prevent hardware failure */
> -#define XILINX_DMA_LOOP_COUNT 1000000
> +/* Timeout for polling various registers */
> +#define XILINX_DMA_POLL_TIMEOUT_US 1000000
> /* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
> #define XILINX_DMA_POLL_DELAY_US 10
>
> @@ -1336,7 +1336,7 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> val & XILINX_DMA_DMASR_HALTED,
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
> }
>
> /**
> @@ -1352,7 +1352,7 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> val & XILINX_DMA_DMASR_IDLE,
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
> }
>
> /**
> @@ -1370,7 +1370,7 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> !(val & XILINX_DMA_DMASR_HALTED),
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
>
> if (err) {
> dev_err(chan->dev, "Cannot start channel %p: %x\n",
> @@ -1787,7 +1787,7 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
> !(tmp & XILINX_DMA_DMACR_RESET),
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
>
> if (err) {
> dev_err(chan->dev, "reset timeout, cr %x, sr %x\n",
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Frank Li @ 2026-04-01 22:45 UTC (permalink / raw)
To: Alex Bereza
Cc: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana,
dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-1-85508f0aedde@bereza.email>
On Wed, Apr 01, 2026 at 12:56:32PM +0200, Alex Bereza wrote:
> Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a
> condition that is never fulfilled, the CPU busy-waits for prolonged time
> and the timeout triggers only with a massive delay causing a CPU stall.
>
> This happens due to a huge underestimation of wall clock time in
> poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use
> timekeeping in read_poll_timeout_atomic()") changed the behavior to no
> longer use ktime_get at the expense of underestimation of wall clock
> time which appears to be very large for delay_us=0. Instead of timing
> out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout
> takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for
> loop in poll_timeout_us_atomic takes) which is in the range of several
> minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero
> value for delay_us. Use delay_us=10 to keep the delay in the hot path of
> starting DMA transfers minimal but still avoid CPU stalls in case of
> unexpected hardware failures.
>
> One-off measurement with delay_us=0 causes the cpu to busy wait around 7
> minutes in the timeout case. After applying this patch with delay_us=10
> the measured timeout was 1053428 microseconds which is roughly
> equivalent to the expected 1000000 microseconds specified in
> XILINX_DMA_LOOP_COUNT.
>
> Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.
>
> Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's")
> Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()")
> Signed-off-by: Alex Bereza <alex@bereza.email>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/dma/xilinx/xilinx_dma.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 02a05f215614..345a738bab2c 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -167,6 +167,8 @@
>
> /* Delay loop counter to prevent hardware failure */
> #define XILINX_DMA_LOOP_COUNT 1000000
> +/* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
> +#define XILINX_DMA_POLL_DELAY_US 10
>
> /* AXI DMA Specific Registers/Offsets */
> #define XILINX_DMA_REG_SRCDSTADDR 0x18
> @@ -1332,7 +1334,8 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
>
> /* Wait for the hardware to halt */
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> - val & XILINX_DMA_DMASR_HALTED, 0,
> + val & XILINX_DMA_DMASR_HALTED,
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
> }
>
> @@ -1347,7 +1350,8 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
> u32 val;
>
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> - val & XILINX_DMA_DMASR_IDLE, 0,
> + val & XILINX_DMA_DMASR_IDLE,
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
> }
>
> @@ -1364,7 +1368,8 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
>
> /* Wait for the hardware to start */
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> - !(val & XILINX_DMA_DMASR_HALTED), 0,
> + !(val & XILINX_DMA_DMASR_HALTED),
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
>
> if (err) {
> @@ -1780,7 +1785,8 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
>
> /* Wait for the hardware to finish reset */
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
> - !(tmp & XILINX_DMA_DMACR_RESET), 0,
> + !(tmp & XILINX_DMA_DMACR_RESET),
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
>
> if (err) {
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v15 5/5] ring-buffer: Show commit numbers in buffer_meta file
From: Steven Rostedt @ 2026-04-01 22:49 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <177494619878.71933.15471023049227398684.stgit@mhiramat.tok.corp.google.com>
On Tue, 31 Mar 2026 17:36:38 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> In addition to the index number, show the commit numbers of
> each data page in per_cpu buffer_meta file.
in the per_cpu buffer_meta file.
-- Steve
> This is useful for understanding the current status of the
> persistent ring buffer. (Note that this file is shown
> only for persistent ring buffer and its backup instance)
>
^ permalink raw reply
* Re: [PATCH] usb: dwc3: imx8mp: fix memory leak on probe failure path
From: Thinh Nguyen @ 2026-04-01 22:55 UTC (permalink / raw)
To: Xiaolei Wang
Cc: Thinh Nguyen, gregkh@linuxfoundation.org, Frank.Li@nxp.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-usb@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260401134938.686748-1-xiaolei.wang@windriver.com>
On Wed, Apr 01, 2026, Xiaolei Wang wrote:
> When platform_get_drvdata() returns NULL and probe defers, the error
> path jumps to the 'depopulate' label, skipping put_device() for the
> reference acquired by of_find_device_by_node(). This extra reference
> prevents the child platform device from being freed when
> of_platform_depopulate() is called, resulting in memory leaks reported
> by kmemleak:
>
> unreferenced object 0xffff0000c92c1480 (size 64):
> comm "kworker/u16:2", pid 50, jiffies 4294895789
> backtrace (crc 49d507d0):
> kmemleak_alloc+0x34/0x40
> __kmalloc_noprof+0x430/0x670
> of_device_alloc+0xec/0x26c
> of_platform_device_create_pdata+0x60/0x1f0
> of_platform_bus_create+0x290/0x610
> of_platform_populate+0x74/0x118
> dwc3_imx8mp_probe+0x228/0x734
>
> Fixes: 86767625f525 ("usb: dwc3: imx8mp: disable auto suspend for host role")
> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
> ---
> drivers/usb/dwc3/dwc3-imx8mp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
> index b3d7252bd910..1cf96540b66e 100644
> --- a/drivers/usb/dwc3/dwc3-imx8mp.c
> +++ b/drivers/usb/dwc3/dwc3-imx8mp.c
> @@ -263,7 +263,7 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
> dwc3 = platform_get_drvdata(dwc3_imx->dwc3_pdev);
> if (!dwc3) {
> err = dev_err_probe(dev, -EPROBE_DEFER, "failed to get dwc3 platform data\n");
> - goto depopulate;
> + goto put_dwc3;
> }
>
> dwc3->glue_ops = &dwc3_imx_glue_ops;
> --
> 2.43.0
>
Thanks for the catch.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Thanks,
Thinh
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-2-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:08 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
> we are going to follow Debian Stable's Rust versions as our minimum
> supported version.
>
> Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
> still uses to this day [3] (i.e. no update to Rust 1.85.1).
>
> [...]
Acked-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 02/33] rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-3-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:09 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Following the Rust compiler bump, we can now update Clippy's MSRV we
> set in the configuration, which will improve the diagnostics it generates.
>
> Thus do so and clean a few of the `allow`s that are not needed anymore.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 03/33] rust: simplify `RUSTC_VERSION` Kconfig conditions
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-4-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:10 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> With the Rust version bump in place, several Kconfig conditions based on
> `RUSTC_VERSION` are always true.
>
> Thus simplify them.
>
> The minimum supported major LLVM version by our new Rust minimum version
> is now LLVM 18, instead of LLVM 16. However, there are no possible
> cleanups for `RUSTC_LLVM_VERSION`.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ 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