* Re: [PATCH] arm64: Implement _THIS_IP_ using inline asm
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Catalin Marinas, Marco Elver
Cc: kernel-team, Will Deacon, Thomas Huth, Nathan Chancellor,
Kees Cook, Vlastimil Babka, Harry Yoo, linux-arm-kernel,
linux-kernel, kasan-dev
In-Reply-To: <20260511201711.3249121-2-elver@google.com>
On Mon, 11 May 2026 22:16:59 +0200, Marco Elver wrote:
> Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to
> be broken:
>
> #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
>
> In particular, the address of a label is only expected to be used with a
> computed goto.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: Implement _THIS_IP_ using inline asm
https://git.kernel.org/arm64/c/d54e4fde9de2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: qcom: Add compatible for Qualcomm Shikra SoC
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Robin Murphy, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Komal Bajaj
Cc: catalin.marinas, kernel-team, Will Deacon, linux-arm-kernel,
iommu, devicetree, linux-kernel
In-Reply-To: <20260430-shikra-smmu-binding-v1-1-1a28572ebccf@oss.qualcomm.com>
On Thu, 30 Apr 2026 17:54:44 +0530, Komal Bajaj wrote:
> Qualcomm Shikra SoC includes an apps SMMU that implements arm,mmu-500,
> which is used to translate device-visible virtual addresses to physical
> addresses. Add compatible for it.
>
>
Applied to iommu (arm/smmu/bindings), thanks!
[1/1] dt-bindings: arm-smmu: qcom: Add compatible for Qualcomm Shikra SoC
https://git.kernel.org/iommu/c/5091bfe5d4c6
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Robin Murphy, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-kernel, iommu, devicetree, linux-kernel,
Krzysztof Kozlowski
Cc: catalin.marinas, kernel-team, Will Deacon, Shawn Guo
In-Reply-To: <20260519074059.61405-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 19 May 2026 09:41:00 +0200, Krzysztof Kozlowski wrote:
> Many of SMMU on Qualcomm SoCs come in two flavors using the same front
> compatible but a bit different fallback:
>
> 1. For application processor, usually without any controllable
> clocks,
>
> 2. For the Adreno GPU, with some controllable clock(s) and using
> additionally qcom,adreno-smmu fallback compatible.
>
> [...]
!! Please note: this conflicted with the Glymur GPU bindings update. That
was trivial to fix, but I've also queued an update adding
"qcom,shikra-smmu-500" which you may want in your list of platforms
where clocks are disallowed?
Applied to iommu (arm/smmu/bindings), thanks!
[1/1] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
https://git.kernel.org/iommu/c/75949eb02653
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] perf: qcom: Unify user-visible "Qualcomm" name
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Mark Rutland, linux-arm-kernel, linux-perf-users, linux-kernel,
Krzysztof Kozlowski
Cc: catalin.marinas, kernel-team, Will Deacon, =Bjorn Andersson,
Konrad Dybcio, linux-arm-msm
In-Reply-To: <20260427070056.18140-2-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 27 Apr 2026 09:00:57 +0200, Krzysztof Kozlowski wrote:
> Various names for Qualcomm as a company are used in user-visible config
> options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
> "Qualcomm" so it will be easier for users to identify the options when
> for example running menuconfig.
>
>
Applied to will (for-next/perf), thanks!
[1/1] perf: qcom: Unify user-visible "Qualcomm" name
https://git.kernel.org/will/c/3ef020a3c9eb
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-v3: Limit queue allocation retry boundary to PAGE_SIZE
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Leo Jiang
Cc: catalin.marinas, kernel-team, Will Deacon, Robin Murphy,
Pranjal Shrivastava, Joerg Roedel, iommu, linux-arm-kernel
In-Reply-To: <tencent_F13723B53F68DC857410D3DBE4F6C895C106@qq.com>
On Sat, 09 May 2026 15:07:33 +0800, Leo Jiang wrote:
> Stop retrying queue allocation when qsz reaches PAGE_SIZE.
>
>
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu/arm-smmu-v3: Limit queue allocation retry boundary to PAGE_SIZE
https://git.kernel.org/iommu/c/2b9f593dad46
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm-smmu: qcom: Add Hawi compatible for Application processor
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Robin Murphy, Mukesh Ojha
Cc: catalin.marinas, kernel-team, Will Deacon, Robin Murphy,
linux-arm-kernel, iommu, devicetree, linux-kernel
In-Reply-To: <20260427174915.3639641-1-mukesh.ojha@oss.qualcomm.com>
On Mon, 27 Apr 2026 23:19:15 +0530, Mukesh Ojha wrote:
> Commit 5e8323c3d528 ("dt-bindings: arm-smmu: qcom: Add compatible for
> Hawi SoC") was intended for the APSS SMMU but was mistakenly placed
> under the Adreno GPU SMMU section. Since that compatible is also valid
> for the Hawi GPU SMMU, keep that commit as-is and add proper
> documentation for the Hawi APSS SMMU here.
>
>
> [...]
Applied to iommu (arm/smmu/bindings), thanks!
[1/1] dt-bindings: arm-smmu: qcom: Add Hawi compatible for Application processor
https://git.kernel.org/iommu/c/c3f9dabf58bb
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] arm64: panic from init_IRQ if IRQ handler stacks cannot be allocated
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Catalin Marinas, Ard Biesheuvel, Ryo Takakura, Breno Leitao,
Mark Rutland, linux-arm-kernel, linux-kernel, Osama Abdelkader
Cc: kernel-team, Will Deacon
In-Reply-To: <20260326225755.50297-1-osama.abdelkader@gmail.com>
On Thu, 26 Mar 2026 23:57:52 +0100, Osama Abdelkader wrote:
> init_irq_stacks() and init_irq_scs() may fail when arch_alloc_vmap_stack
> or scs_alloc return NULL. Return -ENOMEM from both and call panic() once
> from init_IRQ(), covering per-CPU IRQ stacks and shadow IRQ stacks
> consistently.
>
>
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: panic from init_IRQ if IRQ handler stacks cannot be allocated
https://git.kernel.org/arm64/c/7dc6922f7fdd
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Nicolin Chen
Cc: catalin.marinas, kernel-team, Will Deacon, Joerg Roedel,
Jean-Philippe Brucker, Robin Murphy, Pranjal Shrivastava,
Mikołaj Lenczewski, linux-arm-kernel, iommu, linux-kernel,
Jason Gunthorpe
In-Reply-To: <20260503135413.1108138-1-nicolinc@nvidia.com>
On Sun, 03 May 2026 06:54:12 -0700, Nicolin Chen wrote:
> HTTU is introduced by utilizing the Dirty Bit Modifier (DBM) in the PTE.
> When kernel maps a clean but writable page, it will set PTE_READONLY and
> PTE_DBM (aka PTE_WRITE) at the same time. When a write occurs, an HTTU-
> capable MMU will automatically clear the PTE_RDONLY bit without software
> intervention.
>
> On the other hand, SMMU has the same HTTU feature, yet it is not enabled
> in the SVA CD. As a result, SMMU will not clear the PTE_RDONLY bit while
> sharing the CPU page table, resulting in unnecessary stalls.
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits
https://git.kernel.org/iommu/c/74fa4c177ad0
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-qcom: Add glymur MDSS to ACTLR client table
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Rob Clark, Robin Murphy, Joerg Roedel, Lokanadha M R
Cc: catalin.marinas, kernel-team, Will Deacon, iommu, linux-arm-msm,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260428-add_glymur_mdss_compatible-v1-1-8416df5a26f4@oss.qualcomm.com>
On Tue, 28 Apr 2026 15:13:50 +0530, Lokanadha M R wrote:
> Add qcom,glymur-mdss to the qcom_smmu_actlr_client_of_match[]
> table to configure the SMMU-500 context bank for the display
> subsystem (MDSS) on the Glymur platform.
>
> The settings disable the next-page prefetcher while keeping
> macro TLB caching enabled. Without this entry,
> qcom_smmu_set_actlr_dev() finds no match for the glymur MDSS
> device and leaves the context bank ACTLR at its reset value.
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu/arm-smmu-qcom: Add glymur MDSS to ACTLR client table
https://git.kernel.org/iommu/c/8bcad9e3a674
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Reformat table for IDs
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: catalin.marinas, Robin Murphy
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-doc
In-Reply-To: <0d4c8f3968e5c5c0a6f3dc295c3e9f696b9006f4.1777657487.git.robin.murphy@arm.com>
On Fri, 01 May 2026 18:52:28 +0100, Robin Murphy wrote:
> We have some inconsistency where multiple errata for the same component
> share the same Kconfig workaround; some are one ID per line, some are
> smooshed together, and some are entirely separate entries. Standardise
> on the single entry, one ID per line format so that things render nice
> and consistently in the HTML docs, and it's simple and clear to add new
> IDs to existing workarounds without churning the table too much.
>
> [...]
I think I intended to send this upstream at -rc1, but it didn't happen.
However, we don't (yet) seem to have any new workarounds in linux-next
so I'll take it on its own branch for 7.2.
Applied to arm64 (for-next/errata), thanks!
[1/1] arm64: errata: Reformat table for IDs
https://git.kernel.org/arm64/c/ede94377d855
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v3] arm64: smp: Do not mark secondary CPUs possible under nosmp
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: catalin.marinas, Pengjie Zhang
Cc: kernel-team, Will Deacon, maz, timothy.hayes, lpieralisi,
mrigendra.chaubey, arnd, linux-arm-kernel, linux-kernel, zhanjie9,
zhenglifeng1, lihuisong, yubowen8, linhongye, linuxarm, wangzhi12
In-Reply-To: <20260506090851.1858467-1-zhangpengjie2@huawei.com>
On Wed, 06 May 2026 17:08:51 +0800, Pengjie Zhang wrote:
> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>
> smp_prepare_cpus() already treats this as a UP-mandated boot and returns
> before marking secondary CPUs present. However, smp_init_cpus() may still
> enumerate firmware-described secondary CPUs and mark them possible before
> that point.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: smp: Do not mark secondary CPUs possible under nosmp
https://git.kernel.org/arm64/c/e7cec385d2c6
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64/cpufeature: Define hwcaps for 2025 dpISA features
From: Will Deacon @ 2026-05-19 15:24 UTC (permalink / raw)
To: Mark Brown
Cc: Catalin Marinas, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260518-arm64-dpisa-2025-v2-1-b3367b73bd00@kernel.org>
On Mon, May 18, 2026 at 04:07:29PM +0100, Mark Brown wrote:
> The features added by the 2025 dpISA are all straightforward instruction
> only features so there is no state to manage, we can just expose hwcaps to
> let userspace know they are available.
>
> F16MM is slightly odd in that the feature is FEAT_F16MM but it is discovered
> via ID_AA64FPFR0_EL1.F16MM2. We follow the feature name.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> Documentation/arch/arm64/elf_hwcaps.rst | 24 ++++++++++++++++++++++++
> arch/arm64/include/uapi/asm/hwcap.h | 8 ++++++++
> arch/arm64/kernel/cpufeature.c | 11 +++++++++++
> arch/arm64/kernel/cpuinfo.c | 8 ++++++++
> 4 files changed, 51 insertions(+)
>
> diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
> index 97315ae6c0da..07ff9ea1d605 100644
> --- a/Documentation/arch/arm64/elf_hwcaps.rst
> +++ b/Documentation/arch/arm64/elf_hwcaps.rst
> @@ -451,6 +451,30 @@ HWCAP3_LS64
> of CPU. User should only use ld64b/st64b on supported target (device)
> memory location, otherwise fallback to the non-atomic alternatives.
>
> +HWCAP3_SVE_B16MM
> + Functionality implied by ID_AA64ZFR0_EL1.B16B16 == 0b0011
> +
> +HWCAP3_SVE2P3
> + Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0100
> +
> +HWCAP3_SME_LUT6
> + Functionality implied by ID_AA64SMFR0_EL1.LUT6 == 0b1
> +
> +HWCAP3_SME2P3
> + Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0100
> +
> +HWCAP3_F16MM
> + Functionality implied by ID_AA64FPFR0_EL1.F16MM2 == 0b1
> +
> +HWCAP3_F16F32DOT
> + Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0010
> +
> +HWCAP3_F16F32MM
> + Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0011
> +
> +HWCAP3_SVE_LUT6
> + Functionality implied by ID_AA64ISAR2_EL1.LUT == 0b0010 and
> + ID_AA64PFR0_EL1.SVE == 0b0001.
I've queued this, but I'm curious why you've called out the
'ID_AA64PFR0_EL1.SVE == 0b0001' part here and not for any of the other
SVE caps you're adding? It's also formatted inconsistently from
pre-existing entries (such as HWCAP2_SVE_B16B16) which put the
ID_AA64PFR0_EL1.SVE part of the antecedent first.
Will
^ permalink raw reply
* Re: [PATCH] arm64: proton-pack: use sysfs_emit in sysfs show functions
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: Catalin Marinas, shechenglong, Zenghui Yu, Kuninori Morimoto,
Jonathan Marek, Jinqian Yang, Thorsten Blum
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel
In-Reply-To: <20260513115756.447661-2-thorsten.blum@linux.dev>
On Wed, 13 May 2026 13:57:55 +0200, Thorsten Blum wrote:
> Replace sprintf() with sysfs_emit() in sysfs show functions, which is
> preferred for formatting sysfs output because it provides safer bounds
> checking.
>
> While the current code only emits fixed strings that fit easily within
> PAGE_SIZE, use sysfs_emit() to follow secure coding best practices.
>
> [...]
Applied to arm64 (for-next/errata), thanks!
[1/1] arm64: proton-pack: use sysfs_emit in sysfs show functions
https://git.kernel.org/arm64/c/243c1d75a01e
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: maz, oupton, catalin.marinas, corbet, pbonzini, Tian Zheng
Cc: kernel-team, Will Deacon, yuzenghui, wangzhou1, liuyonglong,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose, leo.bras,
Jonathan Cameron
In-Reply-To: <20260225040421.2683931-1-zhengtian10@huawei.com>
On Wed, 25 Feb 2026 12:04:16 +0800, Tian Zheng wrote:
> This series of patches add support to the Hardware Dirty state tracking
> Structure(HDBSS) feature, which is introduced by the ARM architecture
> in the DDI0601(ID121123) version.
>
> The HDBSS feature is an extension to the architecture that enhances
> tracking translation table descriptors' dirty state, identified as
> FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
> page tracking, aiming to significantly reduce the overhead of scanning
> for dirty pages.
>
> [...]
Applied sysreg definitions to arm64 (for-next/sysregs), thanks!
[1/5] arm64/sysreg: Add HDBSS related register information
https://git.kernel.org/arm64/c/72f7be0c2e30
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-19 15:27 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Mostafa Saleh, iommu, linux-arm-kernel, linux-kernel, linux-coco,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5abjebsaid.fsf@kernel.org>
On Tue, May 19, 2026 at 08:37:54PM +0530, Aneesh Kumar K.V wrote:
> if we get force_dma_unencrypted(dev) correct, we won't need the above.
>
> for dma_direct_alloc and dma_direct_alloc_pages() we have
>
> if (force_dma_unencrypted(dev))
> attrs |= DMA_ATTR_CC_SHARED;
>
>
> for dma_direct_map_phys(), if we have swiotlb bouncing forced,
>
> swiotlb_tbl_map_single():
>
> if ((attrs & DMA_ATTR_CC_SHARED) || force_dma_unencrypted(dev))
> require_decrypted = true;
IMHO I really do prefer the DMA_ATTR_CC_SHARED flows closer to the
thing that did the decryption. While the above is possibly sound it is
very obtuse to be guessing what kind of memory swiotlb decided to
return..
Can we pass a pointer to the attrs into the swiotlb stuff and it can
update it based on the kind of memory it has allocated?
Jason
^ permalink raw reply
* Re: [PATCH v3 2/3] hwmon: raspberrypi: Add voltage input support
From: Florian Fainelli @ 2026-05-19 15:28 UTC (permalink / raw)
To: Shubham Chakraborty, Guenter Roeck, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260517080445.103962-3-chakrabortyshubham66@gmail.com>
On 5/17/26 01:04, Shubham Chakraborty wrote:
> Extend the raspberrypi-hwmon driver to expose firmware-provided
> voltage measurements through the hwmon subsystem.
>
> The driver now exports the following voltage inputs:
>
> - in0_input (core)
> - in1_input (sdram_c)
> - in2_input (sdram_i)
> - in3_input (sdram_p)
>
> Voltage values returned by firmware are converted from microvolts
> to millivolts as expected by the hwmon subsystem.
>
> Update the documentation related to it.
>
> The existing undervoltage sticky alarm handling is preserved and
> associated with the first voltage channel.
>
> Tested in -
> - Raspberry Pi 3b+ (Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT
> Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux)
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 1/3] soc: bcm2835: raspberrypi-firmware: Add voltage domain IDs
From: Florian Fainelli @ 2026-05-19 15:29 UTC (permalink / raw)
To: Shubham Chakraborty, Guenter Roeck, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260517080445.103962-2-chakrabortyshubham66@gmail.com>
On 5/17/26 01:04, Shubham Chakraborty wrote:
> Add Raspberry Pi firmware voltage domain identifiers for the mailbox
> property interface.
>
> Also add the voltage request structure used with
> RPI_FIRMWARE_GET_VOLTAGE so firmware clients can share the common API
> definition from the firmware header.
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 1/2] pmdomain: imx: Fix i.MX8MP power notifier
From: Frank Li @ 2026-05-19 15:29 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Ulf Hansson, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-pm, imx, linux-arm-kernel, linux-kernel,
Peng Fan, stable
In-Reply-To: <20260409-imx8mp-vc8000e-pm-v3-1-3e023eaa245b@nxp.com>
On Thu, Apr 09, 2026 at 04:07:17PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Using imx8mm_vpu_power_notifier() for i.MX8MP is wrong, as it ungates
> the VPU clocks to provide the ADB clock, which is necessary on i.MX8MM,
> but on i.MX8MP there is a separate gate (bit 3) for the NoC. So add
> imx8mp_vpu_power_notifier() for i.MX8MP.
>
> Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl")
> Cc: stable@vger.kernel.org
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/pmdomain/imx/imx8m-blk-ctrl.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> index 19e992d2ee3b845bc9382bcd494a5d96f9c6ac44..e13a47eeed75d7189aa15370a7bee4cceb05a1d6 100644
> --- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> +++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> @@ -514,9 +514,34 @@ static const struct imx8m_blk_ctrl_domain_data imx8mp_vpu_blk_ctl_domain_data[]
> },
> };
>
> +static int imx8mp_vpu_power_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct imx8m_blk_ctrl *bc = container_of(nb, struct imx8m_blk_ctrl,
> + power_nb);
> +
> + if (action == GENPD_NOTIFY_ON) {
> + /*
> + * On power up we have no software backchannel to the GPC to
> + * wait for the ADB handshake to happen, so we just delay for a
> + * bit. On power down the GPC driver waits for the handshake.
> + */
> +
> + udelay(5);
> +
> + /* set "fuse" bits to enable the VPUs */
> + regmap_set_bits(bc->regmap, 0x8, 0xffffffff);
> + regmap_set_bits(bc->regmap, 0xc, 0xffffffff);
> + regmap_set_bits(bc->regmap, 0x10, 0xffffffff);
> + regmap_set_bits(bc->regmap, 0x14, 0xffffffff);
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> static const struct imx8m_blk_ctrl_data imx8mp_vpu_blk_ctl_dev_data = {
> .max_reg = 0x18,
> - .power_notifier_fn = imx8mm_vpu_power_notifier,
> + .power_notifier_fn = imx8mp_vpu_power_notifier,
> .domains = imx8mp_vpu_blk_ctl_domain_data,
> .num_domains = ARRAY_SIZE(imx8mp_vpu_blk_ctl_domain_data),
> };
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH v3 2/2] pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
From: Frank Li @ 2026-05-19 15:31 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Ulf Hansson, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-pm, imx, linux-arm-kernel, linux-kernel,
Peng Fan, stable
In-Reply-To: <20260409-imx8mp-vc8000e-pm-v3-2-3e023eaa245b@nxp.com>
On Thu, Apr 09, 2026 at 04:07:18PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Per errata[1]:
> ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX
> power up/down cycling.
> Description: VC8000E reset de-assertion edge and AXI clock may have a
> timing issue.
> Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
> both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
> VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
> de-asserted by HW)
>
> Add a bool variable is_errata_err050531 in
> 'struct imx8m_blk_ctrl_domain_data' to represent whether the workaround
> is needed. If is_errata_err050531 is true, first clear the clk before
> powering up gpc, then enable the clk after powering up gpc.
>
> [1] https://www.nxp.com/webapp/Download?colCode=IMX8MP_1P33A
>
> Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl")
> Cc: stable@vger.kernel.org
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/pmdomain/imx/imx8m-blk-ctrl.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> index e13a47eeed75d7189aa15370a7bee4cceb05a1d6..1cd0a22ce3e533358dd7449da9989162b36c5fe6 100644
> --- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> +++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> @@ -54,6 +54,15 @@ struct imx8m_blk_ctrl_domain_data {
> * register.
> */
> u32 mipi_phy_rst_mask;
> +
> + /*
> + * VC8000E reset de-assertion edge and AXI clock may have a timing issue.
> + * Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
> + * both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
> + * VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
> + * de-asserted by HW)
> + */
> + bool is_errata_err050531;
sorry, where set it? suppose at least one platfomr need set it true.
Frank
> };
>
> #define DOMAIN_MAX_CLKS 4
> @@ -108,7 +117,11 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd)
> dev_err(bc->dev, "failed to enable clocks\n");
> goto bus_put;
> }
> - regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
> +
> + if (data->is_errata_err050531)
> + regmap_clear_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
> + else
> + regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
>
> /* power up upstream GPC domain */
> ret = pm_runtime_get_sync(domain->power_dev);
> @@ -117,6 +130,9 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd)
> goto clk_disable;
> }
>
> + if (data->is_errata_err050531)
> + regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
> +
> /* wait for reset to propagate */
> udelay(5);
>
>
> --
> 2.37.1
>
^ permalink raw reply
* [PATCH v17 03/14] dmaengine: qcom: bam_dma: convert tasklet to a BH workqueue
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski,
Dmitry Baryshkov
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
BH workqueues are a modern mechanism, aiming to replace legacy tasklets.
Let's convert the BAM DMA driver to using the high-priority variant of
the BH workqueue.
[Vinod: suggested using the BG workqueue instead of the regular one
running in process context]
Suggested-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/dma/qcom/bam_dma.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index cea44833201d641ce6a657840d354abb443501b5..e2f16efcdb55f7465950fb81e22acb451e63ba0c 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -42,6 +42,7 @@
#include <linux/pm_runtime.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
+#include <linux/workqueue.h>
#include "../dmaengine.h"
#include "../virt-dma.h"
@@ -397,8 +398,8 @@ struct bam_device {
struct clk *bamclk;
int irq;
- /* dma start transaction tasklet */
- struct tasklet_struct task;
+ /* dma start transaction workqueue */
+ struct work_struct work;
};
/**
@@ -863,7 +864,7 @@ static u32 process_channel_irqs(struct bam_device *bdev)
/*
* if complete, process cookie. Otherwise
* push back to front of desc_issued so that
- * it gets restarted by the tasklet
+ * it gets restarted by the work queue.
*/
if (!async_desc->num_desc) {
vchan_cookie_complete(&async_desc->vd);
@@ -893,9 +894,9 @@ static irqreturn_t bam_dma_irq(int irq, void *data)
srcs |= process_channel_irqs(bdev);
- /* kick off tasklet to start next dma transfer */
+ /* kick off the work queue to start next dma transfer */
if (srcs & P_IRQ)
- tasklet_schedule(&bdev->task);
+ queue_work(system_bh_highpri_wq, &bdev->work);
ret = pm_runtime_get_sync(bdev->dev);
if (ret < 0)
@@ -1091,14 +1092,14 @@ static void bam_start_dma(struct bam_chan *bchan)
}
/**
- * dma_tasklet - DMA IRQ tasklet
- * @t: tasklet argument (bam controller structure)
+ * bam_dma_work() - DMA interrupt work queue callback
+ * @work: work queue struct embedded in the BAM controller device struct
*
* Sets up next DMA operation and then processes all completed transactions
*/
-static void dma_tasklet(struct tasklet_struct *t)
+static void bam_dma_work(struct work_struct *work)
{
- struct bam_device *bdev = from_tasklet(bdev, t, task);
+ struct bam_device *bdev = from_work(bdev, work, work);
struct bam_chan *bchan;
unsigned int i;
@@ -1111,14 +1112,13 @@ static void dma_tasklet(struct tasklet_struct *t)
if (!list_empty(&bchan->vc.desc_issued) && !IS_BUSY(bchan))
bam_start_dma(bchan);
}
-
}
/**
* bam_issue_pending - starts pending transactions
* @chan: dma channel
*
- * Calls tasklet directly which in turn starts any pending transactions
+ * Calls work queue directly which in turn starts any pending transactions
*/
static void bam_issue_pending(struct dma_chan *chan)
{
@@ -1286,14 +1286,14 @@ static int bam_dma_probe(struct platform_device *pdev)
if (ret)
goto err_disable_clk;
- tasklet_setup(&bdev->task, dma_tasklet);
+ INIT_WORK(&bdev->work, bam_dma_work);
bdev->channels = devm_kcalloc(bdev->dev, bdev->num_channels,
sizeof(*bdev->channels), GFP_KERNEL);
if (!bdev->channels) {
ret = -ENOMEM;
- goto err_tasklet_kill;
+ goto err_workqueue_cancel;
}
/* allocate and initialize channels */
@@ -1359,8 +1359,8 @@ static int bam_dma_probe(struct platform_device *pdev)
err_bam_channel_exit:
for (i = 0; i < bdev->num_channels; i++)
tasklet_kill(&bdev->channels[i].vc.task);
-err_tasklet_kill:
- tasklet_kill(&bdev->task);
+err_workqueue_cancel:
+ cancel_work_sync(&bdev->work);
err_disable_clk:
clk_disable_unprepare(bdev->bamclk);
@@ -1394,7 +1394,7 @@ static void bam_dma_remove(struct platform_device *pdev)
bdev->channels[i].fifo_phys);
}
- tasklet_kill(&bdev->task);
+ cancel_work_sync(&bdev->work);
clk_disable_unprepare(bdev->bamclk);
}
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Leonardo Bras @ 2026-05-19 15:35 UTC (permalink / raw)
To: Will Deacon
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
Tian Zheng, kernel-team, yuzenghui, wangzhou1, liuyonglong,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose, Jonathan Cameron
In-Reply-To: <177918656142.736362.17906576792384645789.b4-ty@kernel.org>
On Tue, May 19, 2026 at 04:23:12PM +0100, Will Deacon wrote:
> On Wed, 25 Feb 2026 12:04:16 +0800, Tian Zheng wrote:
> > This series of patches add support to the Hardware Dirty state tracking
> > Structure(HDBSS) feature, which is introduced by the ARM architecture
> > in the DDI0601(ID121123) version.
> >
> > The HDBSS feature is an extension to the architecture that enhances
> > tracking translation table descriptors' dirty state, identified as
> > FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
> > page tracking, aiming to significantly reduce the overhead of scanning
> > for dirty pages.
> >
> > [...]
>
> Applied sysreg definitions to arm64 (for-next/sysregs), thanks!
>
> [1/5] arm64/sysreg: Add HDBSS related register information
> https://git.kernel.org/arm64/c/72f7be0c2e30
>
Thanks!
Leo
> Cheers,
> --
> Will
>
> https://fixes.arm64.dev
> https://next.arm64.dev
> https://will.arm64.dev
^ permalink raw reply
* [PATCH v17 02/14] dmaengine: qcom: bam_dma: free interrupt before the clock in error path
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
The BAM interrupt is requested with a devres helper and so on error it's
freed after probe() returns. We disable the clock before freeing or
masking it so it may still fire and we may end up reading BAM registers
with clock disabled.
Stop using devres for interrupts as we free it in remove() manually
anyway. Add an appropriate label and free the interrupt before disabling
the clock in error path.
Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
Closes: https://sashiko.dev/#/patchset/20260427-qcom-qce-cmd-descr-v16-0-945fd1cafbbc%40oss.qualcomm.com?part=2
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/dma/qcom/bam_dma.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 19116295f8325767a0d97a7848077885b118241c..cea44833201d641ce6a657840d354abb443501b5 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -1302,8 +1302,7 @@ static int bam_dma_probe(struct platform_device *pdev)
for (i = 0; i < bdev->num_channels; i++)
bam_channel_init(bdev, &bdev->channels[i], i);
- ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
- IRQF_TRIGGER_HIGH, "bam_dma", bdev);
+ ret = request_irq(bdev->irq, bam_dma_irq, IRQF_TRIGGER_HIGH, "bam_dma", bdev);
if (ret)
goto err_bam_channel_exit;
@@ -1336,7 +1335,7 @@ static int bam_dma_probe(struct platform_device *pdev)
ret = dma_async_device_register(&bdev->common);
if (ret) {
dev_err(bdev->dev, "failed to register dma async device\n");
- goto err_bam_channel_exit;
+ goto err_free_irq;
}
ret = of_dma_controller_register(pdev->dev.of_node, bam_dma_xlate,
@@ -1355,6 +1354,8 @@ static int bam_dma_probe(struct platform_device *pdev)
err_unregister_dma:
dma_async_device_unregister(&bdev->common);
+err_free_irq:
+ free_irq(bdev->irq, bdev);
err_bam_channel_exit:
for (i = 0; i < bdev->num_channels; i++)
tasklet_kill(&bdev->channels[i].vc.task);
@@ -1379,7 +1380,7 @@ static void bam_dma_remove(struct platform_device *pdev)
/* mask all interrupts for this execution environment */
writel_relaxed(0, bam_addr(bdev, 0, BAM_IRQ_SRCS_MSK_EE));
- devm_free_irq(bdev->dev, bdev->irq, bdev);
+ free_irq(bdev->irq, bdev);
for (i = 0; i < bdev->num_channels; i++) {
bam_dma_terminate_all(&bdev->channels[i].vc.chan);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support
From: Tudor Ambarus @ 2026-05-19 15:46 UTC (permalink / raw)
To: Alexey Klimov
Cc: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones,
Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <DILRJBWU9SKV.2P7EJN7ECEJB7@linaro.org>
Hi, Alexey,
On 5/18/26 2:24 PM, Alexey Klimov wrote:
> Thinking further about this I'd humbly suggest that even
>
> if (fw_err >= 0)
> return 0;
>
> pr_debug_ratelimited("ACPM tmu call returned: %x\n", fw_err);
> or pr_debug(...);
>
> if (fw_err == -1)
> return -EACCES;
>
> some debug message would do.
> Perhaps we need some convertation, for instance as it is done in scmi
> code (scmi_to_linux_errno(), scmi_linux_errmap[]). But I don't have any
> data for mapping acpm errors to some human meanings.
I did that for the pmic helpers. I don't need any debug prints for
gs101 TMU as I have clear instructions from firmware: 0 for success,
-1 for error.
You may update it for e850 later on if you need it.
Cheers,
ta
^ permalink raw reply
* [PATCH v7 00/13] fix several inconsistencies with sysfs configuration in etmX
From: Yeoreum Yun @ 2026-05-19 15:47 UTC (permalink / raw)
To: coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan, jie.gan, Yeoreum Yun
The current ETMx configuration via sysfs can lead to the following
inconsistencies:
- If a configuration is modified via sysfs while a perf session is
active, the running configuration may differ between before
a sched-out and after a subsequent sched-in.
- If a perf session and sysfs session tries to enable concurrently,
configuration from configfs could be corrupted (etm4).
- There is chance to corrupt drvdata->config if perf session tries
to enabled among handling cscfg_csdev_disable_active_config()
in etm4_disable_sysfs() (etm4).
To resolve these inconsistencies, the configuration should be separated into:
- active_config, which is applied configuration for the current session
- config, which stores the settings configured via sysfs.
and apply configuration from configfs after taking a mode.
Also, This patch set includes some small fixes:
- missing trace id release in etm4x.
- underflow issue for nrseqstate.
- wrong check in etm4x_sspcicrn_present().
- missing call of cscfg_csdev_disable_active_config()
This patch based on coresight tree's next
Patch History
=============
from v6 to v7:
- rebase on coresight/next
- add ETM_MAX_SEQ_TRANSITIONS define
- remove redundant patch relavent cpu-hotplug as coresight-pm patch
merged.
- https://lore.kernel.org/all/20260422132203.977549-1-yeoreum.yun@arm.com/
from v5 to v6:
- fix missing of calling cscfg_csdev_disable_active_config()
- add rb & fixes tags.
- add ss_status field in etm4x_drvdata to expose STATUS and PENDING bits.
- https://lore.kernel.org/all/20260415165528.3369607-1-yeoreum.yun@arm.com/
from v4 to v5:
- add rb-tag.
- fix underflow issue for nrseqstate.
- fix wrong check in etm4_sspcicrn_present().
- remove redundant fields on etmv4_save_state.
- rename caps->ss_status to ss_cmp.
- fix wrong location of etm4_release_trace_id.
- https://lore.kernel.org/all/20260413142003.3549310-1-yeoreum.yun@arm.com/
from v3 to v4:
- change etm_drvdata->spinlock type to raw_spin_lock_t
- remove redundant call etmX_enable_hw() with starting_cpu() callsback.
- fix missing trace id release.
- add missing docs.
- https://lore.kernel.org/all/20260412175506.412301-1-yeoreum.yun@arm.com/
from v2 to v3:
- fix build error for etm3x.
- fix checkpatch warning.
- https://lore.kernel.org/all/20260410074310.2693385-1-yeoreum.yun@arm.com/
from v1 to v2
- rebased to v7.0-rc7.
- introduce etmX_caps structure to save etmX's capabilities.
- remove ss_status from etmv4_config.
- modify active_config after taking a mode (perf/sysfs).
- https://lore.kernel.org/all/20260317181705.2456271-1-yeoreum.yun@arm.com/
Yeoreum Yun (13):
coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()
coresight: etm4x: fix underflow for nrseqstate
coresight: etm4x: introduce ETM_MAX_SEQ_TRANSITIONS
coresight: etm4x: introduce struct etm4_caps
coresight: etm4x: exclude ss_status from drvdata->config
coresight: etm4x: remove redundant fields in etmv4_save_state
coresight: etm4x: fix leaked trace id
coresight: etm4x: fix inconsistencies with sysfs configuration
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf
enable
coresight: etm3x: change drvdata->spinlock type to raw_spin_lock_t
coresight: etm3x: introduce struct etm_caps
coresight: etm3x: fix inconsistencies with sysfs configuration
coresight: etm3x: remove redundant cpu online check on
etm_enable_sysfs()
drivers/hwtracing/coresight/coresight-etm.h | 46 ++-
.../coresight/coresight-etm3x-core.c | 96 ++---
.../coresight/coresight-etm3x-sysfs.c | 159 ++++----
.../hwtracing/coresight/coresight-etm4x-cfg.c | 5 +-
.../coresight/coresight-etm4x-core.c | 379 ++++++++++--------
.../coresight/coresight-etm4x-sysfs.c | 202 ++++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 195 ++++-----
7 files changed, 592 insertions(+), 490 deletions(-)
base-commit: a5dd853fb7774c9543aed272a8614c15ebce3173
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply
* [PATCH v7 01/13] coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()
From: Yeoreum Yun @ 2026-05-19 15:48 UTC (permalink / raw)
To: coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan, jie.gan, Yeoreum Yun
In-Reply-To: <20260519154812.254884-1-yeoreum.yun@arm.com>
According to Embedded Trace Macrocell Architecture Specification
ETMv4.0 to ETM4.6 [0], TRCSSPCICR<n> is present only if all of
the following are true:
- TRCIDR4.NUMSSCC > n.
- TRCIDR4.NUMPC > 0b0000.
- TRCSSCSR<n>.PC == 0b1.
Comment for etm4x_sspcicrn_present() is align with the specification.
However, the check should use drvdata->nr_pe_cmp to check TRCIDR4.NUMPC
not nr_pe.
Link: https://developer.arm.com/documentation/ihi0064/latest/ [0]
Fixes: f6a18f354c58 ("coresight: etm4x: Handle access to TRCSSPCICRn")
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 14bb31bd6a0b..1e3b0344dc00 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -93,7 +93,7 @@ static int etm4_probe_cpu(unsigned int cpu);
static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n)
{
return (n < drvdata->nr_ss_cmp) &&
- drvdata->nr_pe &&
+ drvdata->nr_pe_cmp &&
(drvdata->config.ss_status[n] & TRCSSCSRn_PC);
}
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox