* [PATCH v2 4/6] arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
index c249883a8a8d..b0020e667882 100644
--- a/arch/arm64/boot/dts/ti/k3-am625.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/6] dt-bindings: opp: ti-cpu: Add ti,soc-info property
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Add ti,soc-info property to allow OPP tables to reference the SoC info
device (chipid) for establishing device link dependencies.
This is used on K3 SoCs (AM625, AM62A7, AM62L3, AM62P5) to ensure proper
probe ordering between ti-cpufreq and k3-socinfo drivers. The ti-cpufreq
driver depends on k3-socinfo registering the SoC device for revision
detection via soc_device_match().
The device link also prevents unbinding k3-socinfo while ti-cpufreq is
using it, maintaining system stability.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
.../bindings/opp/operating-points-v2-ti-cpu.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
index 624d1f3f1382..f318494d5295 100644
--- a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
+++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
@@ -34,6 +34,16 @@ properties:
points to syscon node representing the control module
register space of the SoC.
+ ti,soc-info:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Optional phandle to the SoC info device (chipid). Used on K3 SoCs
+ to establish device link dependencies ensuring proper probe ordering
+ (ti-cpufreq after k3-socinfo) and preventing unbinding of k3-socinfo
+ while the OPP table is in use. This is needed because ti-cpufreq uses
+ soc_device_match() to detect SoC revision information provided by
+ k3-socinfo.
+
opp-shared: true
patternProperties:
@@ -82,6 +92,7 @@ examples:
opp-table {
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
+ ti,soc-info = <&chipid>;
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/6] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
index b6e5eee99370..6d1459e9ea71 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v13 12/48] arm64: RMI: Basic infrastructure for creating a realm.
From: Steven Price @ 2026-04-01 10:54 UTC (permalink / raw)
To: Wei-Lin Chang, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <xpl4tvzm22ruavicwzgpcw7dsh5mtclhsp5tnkkyybgrxiwptj@f4tmkuyutitp>
On 21/03/2026 16:34, Wei-Lin Chang wrote:
> On Wed, Mar 18, 2026 at 03:53:36PM +0000, Steven Price wrote:
>> Introduce the skeleton functions for creating and destroying a realm.
>> The IPA size requested is checked against what the RMM supports.
>>
>> The actual work of constructing the realm will be added in future
>> patches.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v12:
>> * Drop the RMM_PAGE_{SHIFT,SIZE} defines - the RMM is now configured to
>> be the same as the host's page size.
>> * Rework delegate/undelegate functions to use the new RMI range based
>> operations.
>> Changes since v11:
>> * Major rework to drop the realm configuration and make the
>> construction of realms implicit rather than driven by the VMM
>> directly.
>> * The code to create RDs, handle VMIDs etc is moved to later patches.
>> Changes since v10:
>> * Rename from RME to RMI.
>> * Move the stage2 cleanup to a later patch.
>> Changes since v9:
>> * Avoid walking the stage 2 page tables when destroying the realm -
>> the real ones are not accessible to the non-secure world, and the RMM
>> may leave junk in the physical pages when returning them.
>> * Fix an error path in realm_create_rd() to actually return an error value.
>> Changes since v8:
>> * Fix free_delegated_granule() to not call kvm_account_pgtable_pages();
>> a separate wrapper will be introduced in a later patch to deal with
>> RTTs.
>> * Minor code cleanups following review.
>> Changes since v7:
>> * Minor code cleanup following Gavin's review.
>> Changes since v6:
>> * Separate RMM RTT calculations from host PAGE_SIZE. This allows the
>> host page size to be larger than 4k while still communicating with an
>> RMM which uses 4k granules.
>> Changes since v5:
>> * Introduce free_delegated_granule() to replace many
>> undelegate/free_page() instances and centralise the comment on
>> leaking when the undelegate fails.
>> * Several other minor improvements suggested by reviews - thanks for
>> the feedback!
>> Changes since v2:
>> * Improved commit description.
>> * Improved return failures for rmi_check_version().
>> * Clear contents of PGD after it has been undelegated in case the RMM
>> left stale data.
>> * Minor changes to reflect changes in previous patches.
>> ---
>> arch/arm64/include/asm/kvm_emulate.h | 5 ++
>> arch/arm64/include/asm/kvm_rmi.h | 16 +++++
>> arch/arm64/kvm/arm.c | 12 ++++
>> arch/arm64/kvm/mmu.c | 11 +++-
>> arch/arm64/kvm/rmi.c | 88 ++++++++++++++++++++++++++++
>> 5 files changed, 129 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>> index f38b50151ce8..39310d9b4e16 100644
>> --- a/arch/arm64/include/asm/kvm_emulate.h
>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>> @@ -701,6 +701,11 @@ static inline enum realm_state kvm_realm_state(struct kvm *kvm)
>> return READ_ONCE(kvm->arch.realm.state);
>> }
>>
>> +static inline bool kvm_realm_is_created(struct kvm *kvm)
>> +{
>> + return kvm_is_realm(kvm) && kvm_realm_state(kvm) != REALM_STATE_NONE;
>> +}
>> +
>> static inline bool vcpu_is_rec(struct kvm_vcpu *vcpu)
>> {
>> return false;
>> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
>> index 3506f50b05cd..0ada525af18f 100644
>> --- a/arch/arm64/include/asm/kvm_rmi.h
>> +++ b/arch/arm64/include/asm/kvm_rmi.h
>> @@ -6,6 +6,8 @@
>> #ifndef __ASM_KVM_RMI_H
>> #define __ASM_KVM_RMI_H
>>
>> +#include <asm/rmi_smc.h>
>> +
>> /**
>> * enum realm_state - State of a Realm
>> */
>> @@ -46,11 +48,25 @@ enum realm_state {
>> * struct realm - Additional per VM data for a Realm
>> *
>> * @state: The lifetime state machine for the realm
>> + * @rd: Kernel mapping of the Realm Descriptor (RD)
>> + * @params: Parameters for the RMI_REALM_CREATE command
>> + * @num_aux: The number of auxiliary pages required by the RMM
>> + * @ia_bits: Number of valid Input Address bits in the IPA
>> */
>> struct realm {
>> enum realm_state state;
>> +
>> + void *rd;
>> + struct realm_params *params;
>> +
>> + unsigned long num_aux;
>> + unsigned int ia_bits;
>> };
>>
>> void kvm_init_rmi(void);
>> +u32 kvm_realm_ipa_limit(void);
>> +
>> +int kvm_init_realm_vm(struct kvm *kvm);
>> +void kvm_destroy_realm(struct kvm *kvm);
>>
>> #endif /* __ASM_KVM_RMI_H */
>> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
>> index 274d7866efdc..9b17bdfaf0c2 100644
>> --- a/arch/arm64/kvm/arm.c
>> +++ b/arch/arm64/kvm/arm.c
>> @@ -253,6 +253,13 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>>
>> bitmap_zero(kvm->arch.vcpu_features, KVM_VCPU_MAX_FEATURES);
>>
>> + /* Initialise the realm bits after the generic bits are enabled */
>> + if (kvm_is_realm(kvm)) {
>> + ret = kvm_init_realm_vm(kvm);
>> + if (ret)
>> + goto err_free_cpumask;
>> + }
>> +
>> return 0;
>>
>> err_free_cpumask:
>> @@ -312,6 +319,8 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>> kvm_unshare_hyp(kvm, kvm + 1);
>>
>> kvm_arm_teardown_hypercalls(kvm);
>> + if (kvm_is_realm(kvm))
>> + kvm_destroy_realm(kvm);
>> }
>>
>> static bool kvm_has_full_ptr_auth(void)
>> @@ -473,6 +482,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>> else
>> r = kvm_supports_cacheable_pfnmap();
>> break;
>> + case KVM_CAP_ARM_RMI:
>> + r = static_key_enabled(&kvm_rmi_is_available);
>> + break;
>>
>> default:
>> r = 0;
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 070a01e53fcb..d6094b60c4ce 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -872,12 +872,16 @@ static struct kvm_pgtable_mm_ops kvm_s2_mm_ops = {
>> .icache_inval_pou = invalidate_icache_guest_page,
>> };
>>
>> -static int kvm_init_ipa_range(struct kvm_s2_mmu *mmu, unsigned long type)
>> +static int kvm_init_ipa_range(struct kvm *kvm,
>> + struct kvm_s2_mmu *mmu, unsigned long type)
>> {
>> u32 kvm_ipa_limit = get_kvm_ipa_limit();
>> u64 mmfr0, mmfr1;
>> u32 phys_shift;
>>
>> + if (kvm_is_realm(kvm))
>> + kvm_ipa_limit = kvm_realm_ipa_limit();
>> +
>> if (type & ~KVM_VM_TYPE_ARM_IPA_SIZE_MASK)
>> return -EINVAL;
>>
>> @@ -974,7 +978,7 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
>> return -EINVAL;
>> }
>>
>> - err = kvm_init_ipa_range(mmu, type);
>> + err = kvm_init_ipa_range(kvm, mmu, type);
>> if (err)
>> return err;
>>
>> @@ -1113,7 +1117,8 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
>> write_unlock(&kvm->mmu_lock);
>>
>> if (pgt) {
>> - kvm_stage2_destroy(pgt);
>> + if (!kvm_is_realm(kvm))
>> + kvm_stage2_destroy(pgt);
>
> Hi,
>
> Question:
> Since kvm_stage2_destroy() is only called for non-realm VMs, then where
> does the root level RTT pages get freed?
> After searching for a while I feel like it is missed, but I am not
> certain.
You're absolutely right. I do have a bug fix locally for this:
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 9cfb8c434aa5..3e55c1ff046c 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1148,6 +1148,8 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
if (pgt) {
if (!kvm_is_realm(kvm))
kvm_stage2_destroy(pgt);
+ else
+ kvm_pgtable_stage2_destroy_pgd(pgt);
kfree(pgt);
}
}
The issue here is that we don't want to talk the tables (because they
will have been scrubbed by the RMM), but I apparently forgot to add the
call to free the actual memory.
Thanks,
Steve
> Thanks,
> Wei-Lin Chang
>
>> kfree(pgt);
>> }
>> }
>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>> index 80aedc85e94a..700b8c935d29 100644
>> --- a/arch/arm64/kvm/rmi.c
>> +++ b/arch/arm64/kvm/rmi.c
>> @@ -6,6 +6,8 @@
>> #include <linux/kvm_host.h>
>> #include <linux/memblock.h>
>>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_mmu.h>
>> #include <asm/kvm_pgtable.h>
>> #include <asm/rmi_cmds.h>
>> #include <asm/virt.h>
>> @@ -182,6 +184,92 @@ static int rmi_init_metadata(void)
>> return 0;
>> }
>>
>> +u32 kvm_realm_ipa_limit(void)
>> +{
>> + return u64_get_bits(rmm_feat_reg0, RMI_FEATURE_REGISTER_0_S2SZ);
>> +}
>> +
>> +static int undelegate_range(phys_addr_t phys, unsigned long size)
>> +{
>> + unsigned long ret;
>> + unsigned long top = phys + size;
>> + unsigned long out_top;
>> +
>> + while (phys < top) {
>> + ret = rmi_granule_range_undelegate(phys, top, &out_top);
>> + if (ret == RMI_SUCCESS)
>> + phys = out_top;
>> + else if (ret != RMI_BUSY && ret != RMI_BLOCKED)
>> + return ret;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static int undelegate_page(phys_addr_t phys)
>> +{
>> + return undelegate_range(phys, PAGE_SIZE);
>> +}
>> +
>> +static int free_delegated_page(phys_addr_t phys)
>> +{
>> + if (WARN_ON(undelegate_page(phys))) {
>> + /* Undelegate failed: leak the page */
>> + return -EBUSY;
>> + }
>> +
>> + free_page((unsigned long)phys_to_virt(phys));
>> +
>> + return 0;
>> +}
>> +
>> +void kvm_destroy_realm(struct kvm *kvm)
>> +{
>> + struct realm *realm = &kvm->arch.realm;
>> + size_t pgd_size = kvm_pgtable_stage2_pgd_size(kvm->arch.mmu.vtcr);
>> +
>> + write_lock(&kvm->mmu_lock);
>> + kvm_stage2_unmap_range(&kvm->arch.mmu, 0,
>> + BIT(realm->ia_bits - 1), true);
>> + write_unlock(&kvm->mmu_lock);
>> +
>> + if (realm->params) {
>> + free_page((unsigned long)realm->params);
>> + realm->params = NULL;
>> + }
>> +
>> + if (!kvm_realm_is_created(kvm))
>> + return;
>> +
>> + WRITE_ONCE(realm->state, REALM_STATE_DYING);
>> +
>> + if (realm->rd) {
>> + phys_addr_t rd_phys = virt_to_phys(realm->rd);
>> +
>> + if (WARN_ON(rmi_realm_destroy(rd_phys)))
>> + return;
>> + free_delegated_page(rd_phys);
>> + realm->rd = NULL;
>> + }
>> +
>> + if (WARN_ON(undelegate_range(kvm->arch.mmu.pgd_phys, pgd_size)))
>> + return;
>> +
>> + WRITE_ONCE(realm->state, REALM_STATE_DEAD);
>> +
>> + /* Now that the Realm is destroyed, free the entry level RTTs */
>> + kvm_free_stage2_pgd(&kvm->arch.mmu);
>> +}
>> +
>> +int kvm_init_realm_vm(struct kvm *kvm)
>> +{
>> + kvm->arch.realm.params = (void *)get_zeroed_page(GFP_KERNEL);
>> +
>> + if (!kvm->arch.realm.params)
>> + return -ENOMEM;
>> + return 0;
>> +}
>> +
>> static int rmm_check_features(void)
>> {
>> if (kvm_lpa2_is_enabled() && !rmi_has_feature(RMI_FEATURE_REGISTER_0_LPA2)) {
>> --
>> 2.43.0
>>
^ permalink raw reply related
* [PATCH v2 6/6] arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
index 8982a7b9f1a6..1a498c5eb3d1 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
@@ -108,6 +108,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] Enable Mali G310 GPU support on i.MX952 board
From: Daniel Baluta @ 2026-04-01 10:58 UTC (permalink / raw)
To: Guangliu Ding, Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, Liviu Dudau, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260401-master-v2-0-20d3fbcd19d6@nxp.com>
On 4/1/26 13:19, Guangliu Ding wrote:
> This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
> IP as the instance on i.MX95 boards.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Please wait until there is a resolution to all the questions asked
by reviewers.
Otherwise, this v2 is just useless.
^ permalink raw reply
* Re: [PATCH v14 3/4] arm64: Use generic TIF bits for common thread flags
From: Catalin Marinas @ 2026-04-01 10:55 UTC (permalink / raw)
To: Jinjie Ruan
Cc: will, chenhuacai, kernel, hca, gor, agordeev, borntraeger, svens,
oleg, tglx, mingo, bp, dave.hansen, hpa, arnd, shuah,
kevin.brodsky, yeoreum.yun, anshuman.khandual, thuth,
ryan.roberts, mark.rutland, song, ziyao, linusw, schuster.simon,
jremus, akpm, mathieu.desnoyers, kmal, dvyukov,
reddybalavignesh9979, x86, linux-arm-kernel, linux-kernel,
loongarch, linux-s390, linux-arch, linux-kselftest
In-Reply-To: <20260320104222.1381274-4-ruanjinjie@huawei.com>
On Fri, Mar 20, 2026 at 06:42:21PM +0800, Jinjie Ruan wrote:
> Use the generic TIF bits defined in <asm-generic/thread_info_tif.h> for
> standard thread flags (TIF_SIGPENDING, TIF_NEED_RESCHED, TIF_NOTIFY_RESUME,
> TIF_RESTORE_SIGMASK, TIF_SINGLESTEP, etc.) instead of defining
> them locally.
>
> Arm64-specific bits (TIF_FOREIGN_FPSTATE, TIF_MTE_ASYNC_FAULT, TIF_SVE,
> TIF_SSBD, etc.) are renumbered to start at bit 16 to avoid conflicts.
>
> This enables RSEQ optimizations which require CONFIG_HAVE_GENERIC_TIF_BITS
> combined with the generic entry infrastructure (already used by arm64).
>
> By the way, remove TIF_FREEZE because this flag became unused since
> commit d88e4cb67197 ("freezer: remove now unused TIF_FREEZE").
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Given that it's touching multiple trees, I guess it's a series for
Andrew?
--
Catalin
^ permalink raw reply
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Jon Hunter @ 2026-04-01 10:40 UTC (permalink / raw)
To: Jason Gunthorpe, Alexandre Ghiti, AngeloGioacchino Del Regno,
Albert Ou, asahi, Baolin Wang, iommu, Janne Grunau,
Jernej Skrabec, Joerg Roedel, Jean-Philippe Brucker,
linux-arm-kernel, linux-mediatek, linux-riscv, linux-sunxi,
Matthias Brugger, Neal Gompa, Orson Zhai, Palmer Dabbelt,
Paul Walmsley, Samuel Holland, Sven Peter, virtualization,
Chen-Yu Tsai, Will Deacon, Yong Wu, Chunyan Zhang
Cc: Lu Baolu, Janusz Krzysztofik, Joerg Roedel, patches, Robin Murphy,
Samiullah Khawaja, stable, Vasant Hegde,
linux-tegra@vger.kernel.org
In-Reply-To: <0-v1-664d3acaabb9+78b-iommu_gather_always_jgg@nvidia.com>
On 31/03/2026 20:56, Jason Gunthorpe wrote:
> The fixed commit assumed that the gather would always be populated if
> an iotlb_sync was required.
>
> arm-smmu-v3, amd, VT-d, riscv, s390, mtk all use information from the
> gather during their iotlb_sync() and this approach works for them.
>
> However, arm-smmu, qcom_iommu, ipmmu-vmsa, sun50i, sprd, virtio,
> apple-dart all ignore the gather during their iotlb_sync(). They
> mostly issue a full flush.
>
> Unfortunately the latter set of drivers often don't bother to add
> anything to the gather since they don't intend on using it. Since the
> core code now blocks gathers that were never filled, this caused those
> drivers to stop getting their iotlb_sync() calls and breaks them.
>
> Since it is impossible to tell the difference between gathers that are
> empty because there is nothing to do and gathers that are empty
> because they are not used, fill in the gathers for the missing cases.
>
> io-pgtable might have intended to allow the driver to choose between
> gather or immediate flush because it passed gather to
> ops->tlb_add_page(), however no driver does anything with it.
>
> mtk uses io-pgtable-arm-v7s but added the range to the gather in the
> unmap callback. Move this into the io-pgtable-arm unmap itself. That
> will fix all the armv7 using drivers (arm-smmu, qcom_iommu,
> ipmmu-vmsa).
>
> arm-smmu uses both ARM_V7S and ARM LPAE formats. The LPAE formats
> already have the gather population because SMMUv3 requires it, so it
> becomes consistent.
>
> Add a trivial gather population to io-pgtable-dart.
>
> Add trivial populations to sprd, sun50i and virtio-iommu in their
> unmap functions.
>
> Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 4 +++-
> drivers/iommu/io-pgtable-dart.c | 3 +++
> drivers/iommu/mtk_iommu.c | 1 -
> drivers/iommu/sprd-iommu.c | 1 +
> drivers/iommu/sun50i-iommu.c | 1 +
> drivers/iommu/virtio-iommu.c | 2 ++
> 6 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 0208e5897c299a..8572713a42ca29 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -666,9 +666,11 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
> /* Clear the remaining entries */
> __arm_lpae_clear_pte(ptep, &iop->cfg, i);
>
> - if (gather && !iommu_iotlb_gather_queued(gather))
> + if (gather && !iommu_iotlb_gather_queued(gather)) {
> + iommu_iotlb_gather_add_range(gather, iova, i * size);
> for (int j = 0; j < i; j++)
> io_pgtable_tlb_add_page(iop, gather, iova + j * size, size);
> + }
>
> return i * size;
> } else if (iopte_leaf(pte, lvl, iop->fmt)) {
> diff --git a/drivers/iommu/io-pgtable-dart.c b/drivers/iommu/io-pgtable-dart.c
> index cbc5d6aa2daa23..75d699dc28e7b0 100644
> --- a/drivers/iommu/io-pgtable-dart.c
> +++ b/drivers/iommu/io-pgtable-dart.c
> @@ -330,6 +330,9 @@ static size_t dart_unmap_pages(struct io_pgtable_ops *ops, unsigned long iova,
> i++;
> }
>
> + if (i && !iommu_iotlb_gather_queued(gather))
> + iommu_iotlb_gather_add_range(gather, iova, i * pgsize);
> +
> return i * pgsize;
> }
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 2be990c108de2b..a2f80a92f51f2c 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -828,7 +828,6 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
> {
> struct mtk_iommu_domain *dom = to_mtk_domain(domain);
>
> - iommu_iotlb_gather_add_range(gather, iova, pgsize * pgcount);
> return dom->iop->unmap_pages(dom->iop, iova, pgsize, pgcount, gather);
> }
>
> diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
> index c1a34445d244fb..893ea67d322644 100644
> --- a/drivers/iommu/sprd-iommu.c
> +++ b/drivers/iommu/sprd-iommu.c
> @@ -340,6 +340,7 @@ static size_t sprd_iommu_unmap(struct iommu_domain *domain, unsigned long iova,
> spin_lock_irqsave(&dom->pgtlock, flags);
> memset(pgt_base_iova, 0, pgcount * sizeof(u32));
> spin_unlock_irqrestore(&dom->pgtlock, flags);
> + iommu_iotlb_gather_add_range(iotlb_gather, iova, size);
>
> return size;
> }
> diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
> index be3f1ce696ba29..b9aa4bbc82acad 100644
> --- a/drivers/iommu/sun50i-iommu.c
> +++ b/drivers/iommu/sun50i-iommu.c
> @@ -655,6 +655,7 @@ static size_t sun50i_iommu_unmap(struct iommu_domain *domain, unsigned long iova
>
> memset(pte_addr, 0, sizeof(*pte_addr));
> sun50i_table_flush(sun50i_domain, pte_addr, 1);
> + iommu_iotlb_gather_add_range(gather, iova, SZ_4K);
>
> return SZ_4K;
> }
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 587fc13197f122..5865b8f6c6e67a 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -897,6 +897,8 @@ static size_t viommu_unmap_pages(struct iommu_domain *domain, unsigned long iova
> if (unmapped < size)
> return 0;
>
> + iommu_iotlb_gather_add_range(gather, iova, unmapped);
> +
> /* Device already removed all mappings after detach. */
> if (!vdomain->nr_endpoints)
> return unmapped;
>
> base-commit: fcbe430399ca5c318e99bfda6df9beee90ab051c
Fixes the issue I was seeing ...
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Thanks!
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 2/2] dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
From: Alex Bereza @ 2026-04-01 10:56 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-0-85508f0aedde@bereza.email>
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.
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 related
* [PATCH v3 1/2] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Alex Bereza @ 2026-04-01 10:56 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-0-85508f0aedde@bereza.email>
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>
---
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 related
* [PATCH v3 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by passing delay_us=0
From: Alex Bereza @ 2026-04-01 10:56 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza
Signed-off-by: Alex Bereza <alex@bereza.email>
---
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
* Re: [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-04-01 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, praneeth, nm, vigneshr, kristo, robh,
krzk+dt, conor+dt, rafael, viresh.kumar, linux-arm-kernel,
devicetree, linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <da225ab1-d659-455d-b3c9-e7ff4864119e@kernel.org>
Hi Krzysztof,
On 30/03/26 18:52, Krzysztof Kozlowski wrote:
> On 30/03/2026 14:01, Akashdeep Kaur wrote:
>> opp_data->cpu_dev = get_cpu_device(0);
>> if (!opp_data->cpu_dev) {
>> @@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>> if (ret)
>> goto fail_put_node;
>>
>> + /* Create device link to k3-socinfo if specified in DT */
>> + if (opp_data->soc_data == &am625_soc_data ||
>> + opp_data->soc_data == &am62a7_soc_data ||
>> + opp_data->soc_data == &am62l3_soc_data ||
>> + opp_data->soc_data == &am62p5_soc_data) {
>> + struct device_node *socinfo_np;
>> +
>> + socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
>
> Undocumented ABI.
Added missing patch in next version, thanks for pointing this out.
Regards,
Akashdeep Kaur
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Alex Bereza @ 2026-04-01 10:59 UTC (permalink / raw)
To: Geert Uytterhoeven, Alex Bereza
Cc: Vinod Koul, Frank Li, Michal Simek, Ulf Hansson, Arnd Bergmann,
Tony Lindgren, Kedareswara rao Appana, dmaengine,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAMuHMdWGHzt8nB3EGAToxZibf-O6C5xb9bcWhQQApzL3-6pcCA@mail.gmail.com>
Hi Geert,
thank you for the quick and helpful replies.
>> 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()")
>>
>
> Please no blank line between tags.
Fixed. Sorry, was not aware of this formatting requirement.
BR
Alex
^ permalink raw reply
* RE: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 11:01 UTC (permalink / raw)
To: Krzysztof Kozlowski, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <2f4c4063-daf6-48f2-b830-9f58dc7af80d@kernel.org>
Hi Krzysztof
> On 01/04/2026 12:31, Guangliu Ding wrote:
> >> Either add the patch(es) that use the compatible to this series in
> >> v2, or put a comment in the commit message on where we can see the
> driver changes.
> >>
> >
> > According to discussions with the GPU vendor, this is a hardware
> > limitation of Mali-G310 rather than a hardware bug, and it has been
> > addressed in newer Mali GPU families.
> >
> > In addition, ipa_counters are not enabled in the current Panthor
> > driver. We observed this issue with the private Mali DDK where ipa_counters
> were enabled.
> > Therefore, keeping the compatible string is necessary to allow for future
> divergence.
>
> No one discusses here whether you need separate compatible string.
> writing bindings and all my talks are (e.g. DTS 101) are clearly expecting you.
>
> We discuss only the lack of compatibility in terms of DT, how DT sees
> compatible devices.
>
> And lack of driver code is clear indication that devices are compatible in terms
> how DT understands it. Feel encouraged to bring actual arguments in commit
> msgs in the future.
>
> Best regards,
> Krzysztof
So the best approach is only reserve "arm,mali-valhall-csf" for now, since currently there is
no need for an additional compatible entry from a DT compatibility perspective.
We can introduce "nxp,imx952-mali" in future commits if hardware or driver differences
actually require it, and include more detailed justification in the commit message. Right?
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 11:03 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707D758EC8B08C6D42F3A82F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 01/04/2026 13:01, Guangliu Ding wrote:
> Hi Krzysztof
>
>> On 01/04/2026 12:31, Guangliu Ding wrote:
>>>> Either add the patch(es) that use the compatible to this series in
>>>> v2, or put a comment in the commit message on where we can see the
>> driver changes.
>>>>
>>>
>>> According to discussions with the GPU vendor, this is a hardware
>>> limitation of Mali-G310 rather than a hardware bug, and it has been
>>> addressed in newer Mali GPU families.
>>>
>>> In addition, ipa_counters are not enabled in the current Panthor
>>> driver. We observed this issue with the private Mali DDK where ipa_counters
>> were enabled.
>>> Therefore, keeping the compatible string is necessary to allow for future
>> divergence.
>>
>> No one discusses here whether you need separate compatible string.
>> writing bindings and all my talks are (e.g. DTS 101) are clearly expecting you.
>>
>> We discuss only the lack of compatibility in terms of DT, how DT sees
>> compatible devices.
>>
>> And lack of driver code is clear indication that devices are compatible in terms
>> how DT understands it. Feel encouraged to bring actual arguments in commit
>> msgs in the future.
>>
>> Best regards,
>> Krzysztof
>
> So the best approach is only reserve "arm,mali-valhall-csf" for now, since currently there is
> no need for an additional compatible entry from a DT compatibility perspective.
> We can introduce "nxp,imx952-mali" in future commits if hardware or driver differences
> actually require it, and include more detailed justification in the commit message. Right?
So does that mean you decided not to read writing bindings document?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-01 11:12 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君]
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <8a4f558fdc6649be8c6239403e706621@realtek.com>
On 01/04/2026 13:10, Yu-Chun Lin [林祐君] wrote:
>>> + compatible = "realtek,rtd1625-isom-gpio";
>>> + reg = <0x89120 0x10>,
>>
>> 0x10 feels very short range.
>>
>>> + <0x89100 0x20>;
>>
>> And this means it's continuous. Are you sure these are two separate address
>> spaces?
>>
>> Best regards,
>> Krzysztof
>
> Agreed, they are continuous. I will merge them into a single region in v2.
I assume you checked in the datasheet/manual.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 1/3] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin [林祐君] @ 2026-04-01 11:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <20260401-idealistic-grinning-wallaby-8c3cd5@quoll>
> On Tue, Mar 31, 2026 at 07:38:33PM +0800, Yu-Chun Lin wrote:
> > + reg:
> > + items:
> > + - description: GPIO controller registers
> > + - description: GPIO interrupt registers
> > +
> > + interrupts:
> > + items:
> > + - description: Interrupt number of the assert GPIO interrupt, which
> is
> > + triggered when there is a rising edge.
> > + - description: Interrupt number of the deassert GPIO interrupt,
> which is
> > + triggered when there is a falling edge.
> > + - description: Interrupt number of the level-sensitive GPIO interrupt,
> > + triggered by a configured logic level.
> > +
> > + interrupt-controller: true
> > +
> > + "#interrupt-cells":
> > + const: 2
> > +
> > + gpio-ranges: true
> > +
> > + gpio-controller: true
> > +
> > + "#gpio-cells":
> > + const: 2
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - gpio-ranges
> > + - gpio-controller
> > + - "#gpio-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + gpio@89120 {
> > + compatible = "realtek,rtd1625-isom-gpio";
> > + reg = <0x89120 0x10>,
>
> 0x10 feels very short range.
>
> > + <0x89100 0x20>;
>
> And this means it's continuous. Are you sure these are two separate address
> spaces?
>
> Best regards,
> Krzysztof
Agreed, they are continuous. I will merge them into a single region in v2.
Best regards,
Yu-Chun
^ permalink raw reply
* [PATCH] clk: bcm: rpi: Mark VEC clock as CLK_IGNORE_UNUSED
From: Maíra Canal @ 2026-04-01 11:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Florian Fainelli,
Broadcom internal kernel review list, Mark Brown, Maxime Ripard,
Stefan Wahren, Dom Cobley, Dave Stevenson
Cc: linux-clk, linux-rpi-kernel, linux-arm-kernel, kernel-dev,
Maíra Canal
On Raspberry Pi 3B, the VEC clock is used by the VideoCore firmware
display driver, which remains active until the vc4 driver loads and
sends NOTIFY_DISPLAY_DONE. If this clock is disabled during boot, a bus
lockup happens and the firmware becomes unresponsive, causing a complete
system lockup.
Mark the VEC clock with CLK_IGNORE_UNUSED so it survives the unused
clock disablement and remains available until the vc4 driver takes over
display management.
Fixes: 672299736af6 ("clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks")
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
drivers/clk/bcm/clk-raspberrypi.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index df2d246eb6ef..f1a99de6de4f 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -160,6 +160,13 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = {
[RPI_FIRMWARE_VEC_CLK_ID] = {
.export = true,
.minimize = true,
+
+ /*
+ * If this clock is disabled during boot, it causes a bus
+ * lockup in RPi 3B. Therefore, make sure it's left enabled
+ * during boot.
+ */
+ .flags = CLK_IGNORE_UNUSED,
},
[RPI_FIRMWARE_DISP_CLK_ID] = {
.export = true,
--
2.53.0
^ permalink raw reply related
* [PATCH] firmware: arm_ffa: Use the correct buffer size during RXTX_MAP
From: Sebastian Ene @ 2026-04-01 11:17 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, android-kvm; +Cc: sudeep.holla, Sebastian Ene
Don't use the discovered buffer size from an FFA_FEATURES call directly
since we can run on a system that has the PAGE_SIZE larger than the
returned size which makes the alloc_pages_exact for the buffer to be
rounded up.
Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()")
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index f2f94d4d533e..d0c926aca120 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2078,7 +2078,7 @@ static int __init ffa_init(void)
ret = ffa_rxtx_map(virt_to_phys(drv_info->tx_buffer),
virt_to_phys(drv_info->rx_buffer),
- rxtx_bufsz / FFA_PAGE_SIZE);
+ DIV_ROUND_UP(rxtx_bufsz, PAGE_SIZE) / FFA_PAGE_SIZE);
if (ret) {
pr_err("failed to register FFA RxTx buffers\n");
goto free_pages;
--
2.53.0.1185.g05d4b7b318-goog
^ permalink raw reply related
* Re: [GIT PULL 2/2] Broadcom devicetree-arm64 changes for 7.1
From: Krzysztof Kozlowski @ 2026-04-01 11:18 UTC (permalink / raw)
To: Florian Fainelli
Cc: soc, Rob Herring, Gregor Herburger, Maíra Canal,
Stefan Wahren, linux-arm-kernel, arnd, khilman,
bcm-kernel-feedback-list
In-Reply-To: <20260323190239.1890505-2-florian.fainelli@broadcom.com>
On Mon, Mar 23, 2026 at 12:02:39PM -0700, Florian Fainelli wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-7.1/devicetree-arm64
>
> for you to fetch changes up to 0acb1de2b4df426a62dba33bcd80f3939636f97b:
>
> arm64: dts: broadcom: bcm2712: Move non simple-bus nodes to root level (2026-03-20 10:17:30 -0700)
Patches were good, I wanted to merge them, but then merge complained:
Can't check signature: No public key
I refreshed now my keyring with kernel.org and the same.
I think the same issue was last time and repo is non korg, so nothing
seems to improve.
I am moving on.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 2/3] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin [林祐君] @ 2026-04-01 11:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <20260401-liberal-nondescript-muskrat-0ebe93@quoll>
> On Tue, Mar 31, 2026 at 07:38:34PM +0800, Yu-Chun Lin wrote:
> > Add the GPIO node for the Realtek RTD1625 SoC.
> >
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > arch/arm64/boot/dts/realtek/kent.dtsi | 43
> ++++++++++++++++++++++++
> > arch/arm64/boot/dts/realtek/rtd1501.dtsi | 8 +++++
> > arch/arm64/boot/dts/realtek/rtd1861.dtsi | 8 +++++
> > arch/arm64/boot/dts/realtek/rtd1920.dtsi | 8 +++++
> > 4 files changed, 67 insertions(+)
> >
>
> Why the DTS is in the middle? Drivers cannot depend on it. Please read
> submitting patches (both documents).
>
I will move DTS to the end in v2.
> > diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi
> > b/arch/arm64/boot/dts/realtek/kent.dtsi
> > index 8d4293cd4c03..746932c26724 100644
> > --- a/arch/arm64/boot/dts/realtek/kent.dtsi
> > +++ b/arch/arm64/boot/dts/realtek/kent.dtsi
> > @@ -151,6 +151,39 @@ uart0: serial@7800 {
> > status = "disabled";
> > };
> >
> > + gpio: gpio@31100 {
> > + compatible = "realtek,rtd1625-iso-gpio";
> > + reg = <0x31100 0x398>,
> > + <0x31000 0x100>;
> > + gpio-controller;
> > + gpio-ranges = <&isom_pinctrl 0 0 2>,
> > + <&ve4_pinctrl 2 0 6>,
> > + <&iso_pinctrl 8 0 4>,
> > + <&ve4_pinctrl 12 6 2>,
> > + <&main2_pinctrl 14 0
> 2>,
> > + <&ve4_pinctrl 16 8 4>,
> > + <&main2_pinctrl 20 2
> 3>,
> > + <&ve4_pinctrl 23 12
> 3>,
> > + <&iso_pinctrl 26 4 2>,
> > + <&isom_pinctrl 28 2
> 2>,
> > + <&ve4_pinctrl 30 15
> 6>,
> > + <&main2_pinctrl 36 5
> 6>,
> > + <&ve4_pinctrl 42 21
> 3>,
> > + <&iso_pinctrl 45 6 6>,
> > + <&ve4_pinctrl 51 24
> 1>,
> > + <&iso_pinctrl 52 12
> 1>,
> > + <&ve4_pinctrl 53 25
> 11>,
> > + <&main2_pinctrl 64
> 11 28>,
> > + <&ve4_pinctrl 92 36
> 2>,
> > + <&iso_pinctrl 94 13
> 19>,
> > + <&iso_pinctrl 128 32
> 4>,
> > + <&ve4_pinctrl 132 38
> 13>,
> > + <&iso_pinctrl 145 36
> 19>,
> > + <&ve4_pinctrl 164 51
> 2>;
> > + #gpio-cells = <2>;
> > + status = "disabled";
>
> Why is it disabled? What is missing in the SoC? Which resources are missing?
>
Nothing is missing, so I will remove status = "disabled".
> > + };
> > +
> > iso_pinctrl: pinctrl@4e000 {
> > compatible =
> "realtek,rtd1625-iso-pinctrl";
> > reg = <0x4e000 0x1a4>; @@ -161,6
> +194,16
> > @@ main2_pinctrl: pinctrl@4f200 {
> > reg = <0x4f200 0x50>;
> > };
> >
> > + iso_m_gpio: gpio@89120 {
> > + compatible =
> "realtek,rtd1625-isom-gpio";
> > + reg = <0x89120 0x10>,
> > + <0x89100 0x20>;
> > + gpio-controller;
> > + gpio-ranges = <&isom_pinctrl 0 0 4>;
> > + #gpio-cells = <2>;
> > + status = "disabled";
> > + };
> > +
> > isom_pinctrl: pinctrl@146200 {
> > compatible =
> "realtek,rtd1625-isom-pinctrl";
> > reg = <0x146200 0x34>; diff --git
> > a/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > index 65f7ede3df73..ae246a01f126 100644
> > --- a/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > +++ b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > @@ -10,3 +10,11 @@
> > &uart0 {
> > status = "okay";
> > };
> > +
> > +&gpio {
>
> Why aren't you following DTS coding style? What style is applicable for
> Realtek?
>
> Best regards,
> Krzysztof
I should sort them in alphabetical order. But after removing the status property,
the board-level node will be removed entirely.
Best regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH v6 0/2] TQ-Systems TQMa62xx SoM and MBa62xx board
From: Nora Schiffer @ 2026-04-01 11:22 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kees Cook,
Tony Luck, Guilherme G. Piccoli, linux-arm-kernel, devicetree,
linux-kernel, linux
In-Reply-To: <6e34ecefae8e2f187c5ecfdfd343fb717711c21d.camel@ew.tq-group.com>
On Tue, 2026-03-17 at 10:08 +0100, Nora Schiffer wrote:
> On Mon, 2026-03-02 at 11:14 +0100, Nora Schiffer wrote:
> > This adds Device Trees for our AM62x-based SoM TQMa62xx and its
> > reference carrier board MBa62xx.
> >
> > Not yet included are overlays to enable LVDS display output and MIPI-CSI
> > camera input.
>
> Hi Nishanth,
>
> do you have any further comments on these patches? Can we get the series into
> v7.1?
>
> Best,
> Nora
Hi Vignesh,
ti-k3-dt-for-v7.1 is tagged now, does that mean we missed the window to get this
series applied again? If there are still any issues, I'll gladly fix them up,
but we have not received any review comments on this last revision of the
patches.
Best,
Nora
>
>
>
>
> >
> > Changed in v6:
> > - Update author information following name change
> > - Rebase onto latest ti-k3-dts-next
> > - Disable incomplete panel node
> > - Add various comments to explain why nodes are disabled
> > - Extend comment explaining disabled 1400MHz OPP
> > - Use consistent comment style for pinmux
> >
> > Changes in v5:
> > - Rebase onto latest ti-k3-dts-next
> >
> > Changes in v4:
> > - Rebase onto latest ti-k3-dts-next
> > - Reorder boot phase tags after other standard DT properties
> > - Add missing supply regulators in SPI-NOR flash and USB hub
> > - Set status = "okay" in &cpsw3g, as it is disabled in k3-am62-main.dtsi
> > now
> > - Add disabled 1400MHz OPP entry (will be enabled by bootloader if
> > supported by PMIC configuration)
> > - Update copyright years in new files
> >
> > Changes in v3:
> > - Rebased onto ti-k3-dt-for-v6.18
> > - 3 of the 5 patches in v2 have been applied already and are dropped
> > - Include k3-am62-ti-ipc-firmware.dtsi, drop now redundant configuration
> > - Change node name for MCU reserved memory to 'memory'
> > - Use rgmii-id PHY mode
> > - Drop now redundant ti,rx-internal-delay
> > - Update simple-audio-card,name to match other TQ SOMs with compatible
> > configuration
> > - Reference dss_pins in dss node (actual display support will be added
> > in a follow-up patch series)
> > - Consistently use GPIO_ACTIVE_HIGH define
> > - Drop unneeded usb0 quirk flags
> > - Add boot phase tags
> >
> > Changes in v2:
> > - Collected acks and reviews
> > - Rebased onto v6.13-rc1
> >
> >
> > Nora Schiffer (2):
> > dt-bindings: arm: ti: Add compatible for AM625-based TQMa62xx SOM
> > family and carrier board
> > arm64: dts: ti: Add TQ-Systems TQMa62xx SoM and MBa62xx carrier board
> > Device Trees
> >
> > .../devicetree/bindings/arm/ti/k3.yaml | 7 +
> > arch/arm64/boot/dts/ti/Makefile | 1 +
> > .../boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts | 1034 +++++++++++++++++
> > arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi | 360 ++++++
> > 4 files changed, 1402 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts
> > create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi
> >
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* [PATCH v3 1/2] arm64: dts: ti: k3-am62-lp-sk: Add system-power-controller
From: Akashdeep Kaur @ 2026-04-01 11:22 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
In-Reply-To: <20260401112257.1248437-1-a-kaur@ti.com>
On AM62-LP-SK, the TPS65219 PMIC is the system power controller
responsible for handling system poweroff. Add the "system-power-controller"
property to the PMIC node to explicitly designate it as such.
Among all in-tree device trees using the TPS65219 PMIC (verified via
compatible string), AM62-LP-SK was the only one missing this property.
This patch corrects that omission.
This property will be used by the PMIC driver to conditionally register
the poweroff handler, ensuring only the designated power controller
registers for system poweroff operations.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts b/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
index 3e2d8f669535..786a7d695b33 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
@@ -206,6 +206,7 @@ tps65219: pmic@30 {
interrupt-parent = <&gic500>;
interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ system-power-controller;
regulators {
buck1_reg: buck1 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Pranjal Shrivastava @ 2026-04-01 11:23 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Robin Murphy, Samiullah Khawaja, stable,
Vasant Hegde
In-Reply-To: <0-v1-664d3acaabb9+78b-iommu_gather_always_jgg@nvidia.com>
On Tue, Mar 31, 2026 at 04:56:22PM -0300, Jason Gunthorpe wrote:
> The fixed commit assumed that the gather would always be populated if
> an iotlb_sync was required.
>
> arm-smmu-v3, amd, VT-d, riscv, s390, mtk all use information from the
> gather during their iotlb_sync() and this approach works for them.
>
> However, arm-smmu, qcom_iommu, ipmmu-vmsa, sun50i, sprd, virtio,
> apple-dart all ignore the gather during their iotlb_sync(). They
> mostly issue a full flush.
>
> Unfortunately the latter set of drivers often don't bother to add
> anything to the gather since they don't intend on using it. Since the
> core code now blocks gathers that were never filled, this caused those
> drivers to stop getting their iotlb_sync() calls and breaks them.
>
> Since it is impossible to tell the difference between gathers that are
> empty because there is nothing to do and gathers that are empty
> because they are not used, fill in the gathers for the missing cases.
>
I believe the problem is a fundamental disagreement between the core
layer and these drivers. The core assumes an empty gather means there
is no work to do, while these drivers expect a sync regardless. With
this, it seems we're forcing the drivers to lie to the core by
populating a gather they don't actually use just to trigger the sync.
I was wondering if, as a longer-term direction, having an explicit flag
for these drivers to indicate they always require a sync would be a
cleaner way to handle this than the trivial population?
Just a thought, not a hard disagreement with the current approach..
> io-pgtable might have intended to allow the driver to choose between
> gather or immediate flush because it passed gather to
> ops->tlb_add_page(), however no driver does anything with it.
>
> mtk uses io-pgtable-arm-v7s but added the range to the gather in the
> unmap callback. Move this into the io-pgtable-arm unmap itself. That
> will fix all the armv7 using drivers (arm-smmu, qcom_iommu,
> ipmmu-vmsa).
>
> arm-smmu uses both ARM_V7S and ARM LPAE formats. The LPAE formats
> already have the gather population because SMMUv3 requires it, so it
> becomes consistent.
>
> Add a trivial gather population to io-pgtable-dart.
>
> Add trivial populations to sprd, sun50i and virtio-iommu in their
> unmap functions.
>
> Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 4 +++-
> drivers/iommu/io-pgtable-dart.c | 3 +++
> drivers/iommu/mtk_iommu.c | 1 -
> drivers/iommu/sprd-iommu.c | 1 +
> drivers/iommu/sun50i-iommu.c | 1 +
> drivers/iommu/virtio-iommu.c | 2 ++
> 6 files changed, 10 insertions(+), 2 deletions(-)
>
Acked-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Akashdeep Kaur @ 2026-04-01 11:24 UTC (permalink / raw)
To: Lee Jones
Cc: praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy, vishalm,
sebin.francis, d-gole, k-willis
In-Reply-To: <20260331101203.GA3795166@google.com>
Hi Lee,
On 31/03/26 15:42, Lee Jones wrote:
> ---
>
> On Tue, 24 Mar 2026, Akashdeep Kaur wrote:
>
>> Currently, the TPS65219 driver unconditionally registers a poweroff
>> handler. This causes issues on systems where a different component
>> (such as TF-A firmware) should handle system poweroff instead.
>>
>> Make the poweroff handler registration conditional based on the
>> "system-power-controller" device tree property. This follows the
>> standard kernel pattern where only the designated power controller
>> registers for system poweroff operations.
>>
>> On systems where the property is absent, the PMIC will not register
>> a poweroff handler, allowing other poweroff mechanisms to function.
>>
>> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
>> ---
>> drivers/mfd/tps65219.c | 14 ++++++++------
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
>> index 7275dcdb7c44..6fa202339a0c 100644
>> --- a/drivers/mfd/tps65219.c
>> +++ b/drivers/mfd/tps65219.c
>> @@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
>> return ret;
>> }
>>
>> - ret = devm_register_power_off_handler(tps->dev,
>> - tps65219_power_off_handler,
>> - tps);
>> - if (ret) {
>> - dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
>> - return ret;
>> + if (of_device_is_system_power_controller(tps->dev->of_node)) {
>> + ret = devm_register_power_off_handler(tps->dev,
>> + tps65219_power_off_handler,
>> + tps);
>> + if (ret)
>> + return dev_err_probe(tps->dev, ret,
>> + "failed to register power-off handler\n");
>
> Couple of nits to fix.
>
> The `"` should be aligned with the `(` and the `failed` should be capitalised.
Fixed the formatting issues.
>
>> }
>> +
>> return 0;
>> }
>>
>> --
>> 2.34.1
>>
>
Regards,
Akashdeep Kaur
^ 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