* 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 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 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 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 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] 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 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 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] 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] 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] 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 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 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] 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] 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] 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] 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] 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 v3 0/4] arm_mpam: Add support for the MPAM v0.1 architecture version
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, zengheng4, James Morse
Cc: catalin.marinas, kernel-team, Will Deacon, wangkefeng.wang,
xry111, yang, reinette.chatre, thuth, ben.horgan,
mrigendra.chaubey, fenghuay, ahmed.genidi
In-Reply-To: <20260508162341.3762549-1-james.morse@arm.com>
On Fri, 08 May 2026 17:23:37 +0100, James Morse wrote:
> This is a v3 of Zeng's series to add support for MPAM v0.1.
> Included are the changes Ben and I suggested, and a couple of bugs found while
> testing it.
>
> I've put the bug fixes first as you can hit these with mainline.
> The patches for v0.1 enable MPAM on those platforms as this extra ID register
> was missed.
>
> [...]
Applied to arm64 (for-next/mpam), thanks!
[1/4] arm_mpam: Fix false positive assert failure during mpam_disable()
(no commit info)
[2/4] arm_mpam: Check whether the config array is allocated before destroying it
(no commit info)
[3/4] arm64: cpufeature: Add support for the MPAM v0.1 architecture version
https://git.kernel.org/arm64/c/5302bc1493be
[4/4] arm_mpam: Update architecture version check for MPAM MSC
https://git.kernel.org/arm64/c/50a42e03cdbd
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: Implement support for 2025 dpISA extensions
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel,
linux-doc, linux-kselftest
In-Reply-To: <20260518-arm64-dpisa-2025-v2-0-b3367b73bd00@kernel.org>
On Mon, 18 May 2026 16:07:28 +0100, Mark Brown wrote:
> The 2025 dpISA extensions introduce a number of architecture features
> all of which are fairly straightforward from a kernel point of view
> since they only introduce new instructions, not any architecture state.
>
>
Applied selftest update to arm64 (for-next/selftests), thanks!
[2/2] kselftest/arm64: Add 2025 dpISA coverage to hwcaps
https://git.kernel.org/arm64/c/7da70f41da81
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Rob Clark, Robin Murphy, Joerg Roedel, bibek.patro
Cc: catalin.marinas, kernel-team, Will Deacon, Dmitry Baryshkov,
iommu, linux-arm-msm, linux-arm-kernel, linux-kernel,
srinivas.kandagatla, Dmitry Baryshkov, Shawn Guo
In-Reply-To: <20260423100230.3462214-1-bibek.patro@oss.qualcomm.com>
On Thu, 23 Apr 2026 15:32:30 +0530, bibek.patro@oss.qualcomm.com wrote:
> The qcom_smmu_actlr_client_of_match table contained "qcom,fastrpc" as
> the compatible string for applying ACTLR prefetch settings to FastRPC
> devices. However, "qcom,fastrpc" is the compatible string for the parent
> rpmsg channel node, which is not an IOMMU client — it carries no
> "iommus" property in the device tree and is never attached to an SMMU
> context bank.
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table
https://git.kernel.org/iommu/c/a6e1618a65d4
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/5] POE sigreturn fix and extra tests
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: linux-arm-kernel, Kevin Brodsky
Cc: catalin.marinas, kernel-team, Will Deacon, Andrew Morton,
David Hildenbrand (Arm), Joey Gouly, Mark Brown, Shuah Khan,
linux-kselftest, linux-mm, linux-kernel
In-Reply-To: <20260427-poe_signal-v2-0-2bd9d6f16ab4@arm.com>
On Mon, 27 Apr 2026 13:03:32 +0100, Kevin Brodsky wrote:
> Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to
> avoid uaccess failures") introduced special handling for EL0 registers
> that impact uaccess. This did not however handle the case where a signal
> handler removes the relevant record (poe_context for POE) from the
> signal frame; this is clearly not typical behaviour but it is legal.
> That commit resulted in arbitrary data from the kernel stack being
> written to POR_EL0 in that case.
>
> [...]
Applied selftest updates to arm64 (for-next/selftests), thanks!
[2/5] selftests/mm: Fix resv_sz when parsing arm64 signal frame
https://git.kernel.org/arm64/c/c364aa56d673
[3/5] kselftest/arm64: Add POE as a feature in the signal tests
https://git.kernel.org/arm64/c/42c21954063e
[4/5] kselftest/arm64: Move/add POE helpers to test_signals_utils.h
https://git.kernel.org/arm64/c/925a082ec2a0
[5/5] kselftest/arm64: Add tests for POR_EL0 save/reset/restore
https://git.kernel.org/arm64/c/f2db075234c8
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/9] Remove SMMUv3 struct arm_smmu_cmdq_ent
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Jason Gunthorpe
Cc: catalin.marinas, kernel-team, Will Deacon, David Matlack,
Nicolin Chen, Pasha Tatashin, patches, Pranjal Shrivastava,
Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <0-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, 13 May 2026 20:57:39 -0300, Jason Gunthorpe wrote:
> [ This is part of the patch pile to move SMMUv3 over to the generic page
> table:
> 1) Introduction of new gather items and RISCV usage
> https://patch.msgid.link/r/0-v2-b5156f657dc1+25f-iommu_riscv_inv_jgg@nvidia.com
> 2) Remove SMMUv3 struct arm_smmu_cmdq_ent
> 3) Organize the SMMUv3 invalidation flow so iommupt can use it
> 4) Use the generic iommu page table for SMMUv3
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/9] iommu/arm-smmu-v3: Add struct arm_smmu_cmd to represent the HW format command
https://git.kernel.org/iommu/c/bf00a29234a4
[2/9] iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq selection functions
https://git.kernel.org/iommu/c/f59c5b6858d8
[3/9] iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq submission functions
https://git.kernel.org/iommu/c/d455e3a7bf0a
[4/9] iommu/arm-smmu-v3: Convert arm_smmu_cmdq_batch cmds to struct arm_smmu_cmd
https://git.kernel.org/iommu/c/27e02ca61552
[5/9] iommu/arm-smmu-v3: Remove CMDQ_OP_CFGI_CD_ALL from arm_smmu_cmdq_build_cmd()
https://git.kernel.org/iommu/c/c5758947cb7b
[6/9] iommu/arm-smmu-v3: Directly encode simple commands
https://git.kernel.org/iommu/c/6e771be45e8a
[7/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_ATC_INV
https://git.kernel.org/iommu/c/2eedb906f9c6
[8/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_SYNC
https://git.kernel.org/iommu/c/c3f84707ad4f
[9/9] iommu/arm-smmu-v3: Directly encode TLBI commands
https://git.kernel.org/iommu/c/be0d0b858861
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update HiSilicon PMU driver maintainer to Yushan Wang
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Yushan Wang, Jie Zhan, Mark Rutland, linux-arm-kernel,
linux-perf-users, Jonathan Cameron
Cc: catalin.marinas, kernel-team, Will Deacon, linuxarm
In-Reply-To: <20260416095110.25612-1-Jonathan.Cameron@huawei.com>
On Thu, 16 Apr 2026 10:51:10 +0100, Jonathan Cameron wrote:
> Replace myself with Yushan Wang who is very familiar with the HiSilicon PMU
> drivers.
>
>
Applied to will (for-next/perf), thanks!
[1/1] MAINTAINERS: Update HiSilicon PMU driver maintainer to Yushan Wang
https://git.kernel.org/will/c/dbd7d67b1318
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 08/16] media: v4l2-common: Add NV12_32L32 pixel format to v4l2 format info
From: Nicolas Dufresne @ 2026-05-19 15:23 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-9-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> Represent the NV12_32L32 pixel format in the v4l2 format info table.
> This is a 32x32 tiled version of NV12.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 6194d6eb9c56..fe7141883ec5 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -315,6 +315,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> { .format = V4L2_PIX_FMT_NV12_16L16, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 16, 16, 0, 0 }, .block_h = { 16, 16, 0, 0 }},
> + { .format = V4L2_PIX_FMT_NV12_32L32, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 32, 32, 0, 0 }, .block_h = { 32, 32, 0, 0 }},
Same.
+ { .format = V4L2_PIX_FMT_NV12_32L32, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
+ .block_w = { 32, 16, 0, 0 }, .block_h = { 32, 32, 0, 0 }},
>
> /* YUV planar formats, non contiguous variant */
> { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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