* Re: [PATCH] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: Dev Jain @ 2026-04-21 7:06 UTC (permalink / raw)
To: David Hildenbrand (Arm), Catalin Marinas, Will Deacon,
Andrew Morton, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, Ryan Roberts
Cc: linux-arm-kernel, linux-kernel, linux-mm, stable
In-Reply-To: <20260420-zerotags-v1-1-3edc93e95bb4@kernel.org>
On 21/04/26 2:46 am, David Hildenbrand (Arm) wrote:
> __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this
> flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.
>
> If we run with init_on_free, we will zero out pages during
> __free_pages_prepare(), to skip zeroing on the allocation path.
>
> However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will
> consequently not only skip clearing page content, but also skip
> clearing tag memory.
>
> Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that
> will get mapped to user space through set_pte_at() later: set_pte_at() and
> friends will detect that the tags have not been initialized yet
> (PG_mte_tagged not set), and initialize them.
>
> However, for the huge zero folio, which will be mapped through a PMD
> marked as special, this initialization will not be performed, ending up
> exposing whatever tags were still set for the pages.
>
> The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state
> that allocation tags are set to 0 when a page is first mapped to user
> space. That no longer holds with the huge zero folio when init_on_free
> is enabled.
>
> Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to
> tag_clear_highpages() whether we want to also clear page content.
>
> As we are touching the interface either way, just clean it up by
> only calling it when HW tags are enabled, dropping the return value, and
> dropping the common code stub.
>
> Reproduced with the huge zero folio by modifying the check_buffer_fill
> arm64/mte selftest to use a 2 MiB area, after making sure that pages have
> a non-0 tag set when freeing (note that, during boot, we will not
> actually initialize tags, but only set KASAN_TAG_KERNEL in the page
> flags).
>
> $ ./check_buffer_fill
> 1..20
> ...
> not ok 17 Check initial tags with private mapping, sync error mode and mmap memory
> not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
> ...
>
> This code needs more cleanups; we'll tackle that next, like
> decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN, moving all the
> KASAN magic into a separate helper, and consolidating HW-tag handling.
>
> Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio")
> Cc: stable@vger.kernel.org
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
> arch/arm64/include/asm/page.h | 3 ---
> arch/arm64/mm/fault.c | 16 +++++-----------
> include/linux/gfp_types.h | 10 +++++-----
> include/linux/highmem.h | 10 +---------
> mm/page_alloc.c | 12 +++++++-----
> 5 files changed, 18 insertions(+), 33 deletions(-)
>
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index e25d0d18f6d7..5c6cbfbbd34c 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -33,9 +33,6 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
> unsigned long vaddr);
> #define vma_alloc_zeroed_movable_folio vma_alloc_zeroed_movable_folio
>
> -bool tag_clear_highpages(struct page *to, int numpages);
> -#define __HAVE_ARCH_TAG_CLEAR_HIGHPAGES
> -
> #define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
>
> typedef struct page *pgtable_t;
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 0f3c5c7ca054..32a3723f2d34 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -1018,21 +1018,15 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
> return vma_alloc_folio(flags, 0, vma, vaddr);
> }
>
> -bool tag_clear_highpages(struct page *page, int numpages)
> +void tag_clear_highpages(struct page *page, int numpages, bool clear_pages)
> {
> - /*
> - * Check if MTE is supported and fall back to clear_highpage().
> - * get_huge_zero_folio() unconditionally passes __GFP_ZEROTAGS and
> - * post_alloc_hook() will invoke tag_clear_highpages().
> - */
> - if (!system_supports_mte())
> - return false;
> -
> /* Newly allocated pages, shouldn't have been tagged yet */
> for (int i = 0; i < numpages; i++, page++) {
> WARN_ON_ONCE(!try_page_mte_tagging(page));
> - mte_zero_clear_page_tags(page_address(page));
> + if (clear_pages)
> + mte_zero_clear_page_tags(page_address(page));
> + else
> + mte_clear_page_tags(page_address(page));
> set_page_mte_tagged(page);
> }
> - return true;
> }
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 6c75df30a281..fd53a6fba33f 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -273,11 +273,11 @@ enum {
> *
> * %__GFP_ZERO returns a zeroed page on success.
> *
> - * %__GFP_ZEROTAGS zeroes memory tags at allocation time if the memory itself
> - * is being zeroed (either via __GFP_ZERO or via init_on_alloc, provided that
> - * __GFP_SKIP_ZERO is not set). This flag is intended for optimization: setting
> - * memory tags at the same time as zeroing memory has minimal additional
> - * performance impact.
> + * %__GFP_ZEROTAGS zeroes memory tags at allocation time. This flag is intended
> + * for optimization: setting memory tags at the same time as zeroing memory
> + * (e.g., with __GPF_ZERO) has minimal additional performance impact. However,
> + * __GFP_ZEROTAGS also zeroes the tags even if memory is not getting zeroed at
> + * allocation time (e.g., with init_on_free).
> *
> * %__GFP_SKIP_KASAN makes KASAN skip unpoisoning on page allocation.
> * Used for userspace and vmalloc pages; the latter are unpoisoned by
> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
> index af03db851a1d..62f589baa343 100644
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -345,15 +345,7 @@ static inline void clear_highpage_kasan_tagged(struct page *page)
> kunmap_local(kaddr);
> }
>
> -#ifndef __HAVE_ARCH_TAG_CLEAR_HIGHPAGES
> -
> -/* Return false to let people know we did not initialize the pages */
> -static inline bool tag_clear_highpages(struct page *page, int numpages)
> -{
> - return false;
> -}
> -
> -#endif
> +void tag_clear_highpages(struct page *to, int numpages, bool clear_pages);
>
> /*
> * If we pass in a base or tail page, we can zero up to PAGE_SIZE.
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 65e205111553..8c6821d25a00 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1808,9 +1808,9 @@ static inline bool should_skip_init(gfp_t flags)
> inline void post_alloc_hook(struct page *page, unsigned int order,
> gfp_t gfp_flags)
> {
> + const bool zero_tags = kasan_hw_tags_enabled() && (gfp_flags & __GFP_ZEROTAGS);
Sashiko:
https://sashiko.dev/#/patchset/20260420-zerotags-v1-1-3edc93e95bb4%40kernel.org
PROT_MTE works without KASAN_HW_TAGS, so probably just retain the
system_supports_mte() check in tag_clear_highpages(), and document
that GFP_ZEROTAGS is only for MTE?
> bool init = !want_init_on_free() && want_init_on_alloc(gfp_flags) &&
> !should_skip_init(gfp_flags);
> - bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS);
> int i;
>
> set_page_private(page, 0);
> @@ -1832,11 +1832,13 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
> */
>
> /*
> - * If memory tags should be zeroed
> - * (which happens only when memory should be initialized as well).
> + * Clearing tags can efficiently clear the memory for us as well, if
> + * required.
> */
> - if (zero_tags)
> - init = !tag_clear_highpages(page, 1 << order);
> + if (zero_tags) {
> + tag_clear_highpages(page, 1 << order, /* clear_pages= */init);
Micro-nit: ^ space
> + init = false;
> + }
>
> if (!should_skip_kasan_unpoison(gfp_flags) &&
> kasan_unpoison_pages(page, order, init)) {
>
> ---
> base-commit: f1541b40cd422d7e22273be9b7e9edfc9ea4f0d7
> change-id: 20260417-zerotags-343a3673e18d
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v5 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-04-21 7:13 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Julien Massot, Louis-Alexis Eyraud,
Akari Tsuyukusa, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-2-l.scorcia@gmail.com>
On Mon, Apr 20, 2026 at 10:30:00PM +0100, Luca Leonardo Scorcia wrote:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the currently supported bindings for the MT6392 PMIC. Its MFD driver
> does not use the compatible property to bind the regulator driver, so
> don't mark it as required.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../bindings/mfd/mediatek,mt6397.yaml | 27 ++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 05c121b0cb3d..2866e95e338b 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -40,6 +40,10 @@ properties:
> - mediatek,mt6358
> - mediatek,mt6359
> - mediatek,mt6397
> + - items:
> + - enum:
> + - mediatek,mt6392
> + - const: mediatek,mt6323
> - items:
> - enum:
> - mediatek,mt6366
> @@ -68,6 +72,10 @@ properties:
> - mediatek,mt6331-rtc
> - mediatek,mt6358-rtc
> - mediatek,mt6397-rtc
> + - items:
> + - enum:
> + - mediatek,mt6392-rtc
> + - const: mediatek,mt6323-rtc
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Please create a new binding file for your device. Having two ways to
define child is not making this binding easier to follow.
The style of defining children with compatibles should be followed by
"requierd: compatible". I am rather against of exceptions, unless needed
and this is not such case where you need one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-04-21 7:14 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Louis-Alexis Eyraud, Val Packett,
Julien Massot, Gary Bisson, Fabien Parent, Akari Tsuyukusa,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-4-l.scorcia@gmail.com>
On Mon, Apr 20, 2026 at 10:30:02PM +0100, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 76 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
Your patchset is obviously non-bisectable. This must be squashed.
Test/check individual patches please.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v11 12/14] cpuidle/poll_state: Wait for need-resched via tif_need_resched_relaxed_wait()
From: Catalin Marinas @ 2026-04-21 7:15 UTC (permalink / raw)
To: Ankur Arora
Cc: Okanovic, Haris, joao.m.martins@oracle.com,
xueshuai@linux.alibaba.com, david.laight.linux@gmail.com,
boris.ostrovsky@oracle.com, memxor@gmail.com, ashok.bhat@arm.com,
zhenglifeng1@huawei.com, konrad.wilk@oracle.com, cl@gentwo.org,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
ast@kernel.org, rdunlap@infradead.org, daniel.lezcano@linaro.org,
arnd@arndb.de, linux-arch@vger.kernel.org, will@kernel.org,
mark.rutland@arm.com, peterz@infradead.org, bpf@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, rafael@kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <87mryxh67j.fsf@oracle.com>
On Mon, Apr 20, 2026 at 10:50:08AM -0700, Ankur Arora wrote:
> Okanovic, Haris <harisokn@amazon.com> writes:
> > On Wed, 2026-04-08 at 17:55 +0530, Ankur Arora wrote:
> >> The inner loop in poll_idle() polls over the thread_info flags,
> >> waiting to see if the thread has TIF_NEED_RESCHED set. The loop
> >> exits once the condition is met, or if the poll time limit has
> >> been exceeded.
> >>
> >> To minimize the number of instructions executed in each iteration,
> >> the time check is rate-limited. In addition, each loop iteration
> >> executes cpu_relax() which on certain platforms provides a hint to
> >> the pipeline that the loop busy-waits, allowing the processor to
> >> reduce power consumption.
> >>
> >> Switch over to tif_need_resched_relaxed_wait() instead, since that
> >> provides exactly that.
> >>
> >> However, since we want to minimize power consumption in idle, building
> >> of cpuidle/poll_state.c continues to depend on CONFIG_ARCH_HAS_CPU_RELAX
> >> as that serves as an indicator that the platform supports an optimized
> >> version of tif_need_resched_relaxed_wait() (via
> >> smp_cond_load_acquire_timeout()).
> >>
> >> Cc: Rafael J. Wysocki <rafael@kernel.org>
> >> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> Cc: linux-pm@vger.kernel.org
> >> Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
> >> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> >> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
[...]
> > Tested atop latest mainline d60bc1401 with the rest of your haltpoll
> > changes from separate thread: ~10% improvement in `perf sched bench
> > pipe` micro and ~4-6% throughput improvements in mysql, postgresql,
> > cassandra, and memcached in under-loaded configurations. Tested on
> > AWS Graviton3 and Graviton4, ARM Neoverse V1 and V2 cores
> > respectively.
> >
> > I hope this series can merge soon. It's been stuck in review for more
> > than 2 years.
> >
> > Tested-by: Haris Okanovic <harisokn@amazon.com>
>
> Thanks Haris. Yeah, I don't think there are any open issues left on
> this.
I agree, though an ack from the atomic infrastructure people on the
generic bits would be nice.
--
Catalin
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: rng: mtk-rng: fix style problems in example
From: Krzysztof Kozlowski @ 2026-04-21 7:16 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <912fe579eccf577f3064b69d6c945e2c9087cab8.1776702734.git.daniel@makrotopia.org>
On Mon, Apr 20, 2026 at 05:34:45PM +0100, Daniel Golle wrote:
> Use 4 spaces for each level indentation, remove unused label, and add
> missing empty line between header include and body.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v4: new patch
When doing such trivial cleanups, fix all bindings in subsystem (rng),
not only one. Doing it one-by-one is simply churn and I DID NOT ASK to
fix existing example to match the expected style.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-21 7:17 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <63aa9d62fef13e0991c17b16a836d8b5667aca96.1776702734.git.daniel@makrotopia.org>
On Mon, Apr 20, 2026 at 05:35:09PM +0100, Daniel Golle wrote:
> Add compatible strings for MediaTek SoCs where the hardware random number
> generator is accessed via a vendor-defined Secure Monitor Call (SMC)
> rather than direct MMIO register access:
>
> - mediatek,mt7981-rng
> - mediatek,mt7987-rng
> - mediatek,mt7988-rng
>
> These variants require no reg, clocks, or clock-names properties since
> the RNG hardware is managed by ARM Trusted Firmware-A.
>
> Relax the $nodename pattern to also allow 'rng' in addition to the
> existing 'rng@...' pattern.
>
> Add a second example showing the minimal SMC variant binding.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 2/8] firmware: meson: sm: Thermal calibration read via secure monitor
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Add SM_THERMAL_CALIB_READ to the secure monitor command enum and
introduce meson_sm_get_thermal_calib() to allow drivers to retrieve
thermal sensor calibration data through the firmware interface.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/firmware/meson/meson_sm.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/firmware/meson/meson_sm.h b/include/linux/firmware/meson/meson_sm.h
index 8eaf8922ab020..3ebc2bd9a9760 100644
--- a/include/linux/firmware/meson/meson_sm.h
+++ b/include/linux/firmware/meson/meson_sm.h
@@ -12,6 +12,7 @@ enum {
SM_EFUSE_WRITE,
SM_EFUSE_USER_MAX,
SM_GET_CHIP_ID,
+ SM_THERMAL_CALIB_READ,
SM_A1_PWRC_SET,
SM_A1_PWRC_GET,
};
@@ -27,5 +28,7 @@ int meson_sm_call_read(struct meson_sm_firmware *fw, void *buffer,
unsigned int bsize, unsigned int cmd_index, u32 arg0,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
struct meson_sm_firmware *meson_sm_get(struct device_node *firmware_node);
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id);
#endif /* _MESON_SM_FW_H_ */
--
2.49.0
^ permalink raw reply related
* [PATCH v3 3/8] firmware: meson: sm: Add thermal calibration SMC call
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Add SM_THERMAL_CALIB_READ at SMC ID 0x82000047 in the command
table and implement meson_sm_get_thermal_calib(), which forwards the
tsensor_id argument to the secure monitor and returns the calibration data.
Also realign the CMD() column to improve readability.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/firmware/meson/meson_sm.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 3ab67aaa9e5da..4e57986724212 100644
--- a/drivers/firmware/meson/meson_sm.c
+++ b/drivers/firmware/meson/meson_sm.c
@@ -41,12 +41,13 @@ static const struct meson_sm_chip gxbb_chip = {
.cmd_shmem_in_base = 0x82000020,
.cmd_shmem_out_base = 0x82000021,
.cmd = {
- CMD(SM_EFUSE_READ, 0x82000030),
- CMD(SM_EFUSE_WRITE, 0x82000031),
+ CMD(SM_EFUSE_READ, 0x82000030),
+ CMD(SM_EFUSE_WRITE, 0x82000031),
CMD(SM_EFUSE_USER_MAX, 0x82000033),
- CMD(SM_GET_CHIP_ID, 0x82000044),
- CMD(SM_A1_PWRC_SET, 0x82000093),
- CMD(SM_A1_PWRC_GET, 0x82000095),
+ CMD(SM_GET_CHIP_ID, 0x82000044),
+ CMD(SM_THERMAL_CALIB_READ, 0x82000047),
+ CMD(SM_A1_PWRC_SET, 0x82000093),
+ CMD(SM_A1_PWRC_GET, 0x82000095),
{ /* sentinel */ },
},
};
@@ -245,6 +246,24 @@ struct meson_sm_firmware *meson_sm_get(struct device_node *sm_node)
}
EXPORT_SYMBOL_GPL(meson_sm_get);
+/**
+ *
+ * meson_sm_get_thermal_calib - Read thermal sensor calibration data.
+ * @fw: Pointer to secure-monitor firmware.
+ * @trim_info: Pointer to store the returned calibration data.
+ * @tsensor_id: Sensor index to identify which sensor's calibration data
+ * to retrieve
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id)
+{
+ return meson_sm_call(fw, SM_THERMAL_CALIB_READ, trim_info, tsensor_id,
+ 0, 0, 0, 0);
+}
+EXPORT_SYMBOL_GPL(meson_sm_get_thermal_calib);
+
#define SM_CHIP_ID_LENGTH 119
#define SM_CHIP_ID_OFFSET 4
#define SM_CHIP_ID_SIZE 12
--
2.49.0
^ permalink raw reply related
* [PATCH v3 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
Unlike existing variants which use a phandle to the ao-secure syscon,
the T7 relies on a secure monitor interface described by a phandle and
a sensor index argument.
The T7 integrates multiple thermal sensors, all accessed through the
same SMC call. The sensor index argument is required to identify which
sensor's calibration data the secure monitor should return, as a single
SM_THERMAL_CALIB_READ command serves all of them.
Introduce the amlogic,secure-monitor property as a phandle-array and
make amlogic,ao-secure or amlogic,secure-monitor conditionally required
depending on the compatible.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../bindings/thermal/amlogic,thermal.yaml | 37 ++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 70b273271754b..e28612510d679 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -21,7 +21,9 @@ properties:
- amlogic,g12a-cpu-thermal
- amlogic,g12a-ddr-thermal
- const: amlogic,g12a-thermal
- - const: amlogic,a1-cpu-thermal
+ - enum:
+ - amlogic,a1-cpu-thermal
+ - amlogic,t7-thermal
reg:
maxItems: 1
@@ -42,12 +44,34 @@ properties:
'#thermal-sensor-cells':
const: 0
+ amlogic,secure-monitor:
+ description: phandle to the secure monitor
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to the secure monitor
+ - description: sensor index to get specific calibration data
+
required:
- compatible
- reg
- interrupts
- clocks
- - amlogic,ao-secure
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,a1-cpu-thermal
+ - amlogic,g12a-thermal
+ then:
+ required:
+ - amlogic,ao-secure
+ else:
+ required:
+ - amlogic,secure-monitor
unevaluatedProperties: false
@@ -62,4 +86,13 @@ examples:
#thermal-sensor-cells = <0>;
amlogic,ao-secure = <&sec_AO>;
};
+ - |
+ temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
...
--
2.49.0
^ permalink raw reply related
* [PATCH v3 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Some SoCs (e.g. T7) expose thermal calibration data through the secure
monitor rather than a directly accessible eFuse register. Add a use_sm
flag to amlogic_thermal_data to select this path, and retrieve the
firmware handle and tsensor_id from the "amlogic,secure-monitor" DT
phandle with one fixed argument.
Also introduce the amlogic,t7-thermal compatible using this new path.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/thermal/amlogic_thermal.c | 58 +++++++++++++++++++++++++++++++++++----
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
index 5448d772db12a..11e3948cc0669 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -25,6 +25,7 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/thermal.h>
+#include <linux/firmware/meson/meson_sm.h>
#include "thermal_hwmon.h"
@@ -84,12 +85,14 @@ struct amlogic_thermal_soc_calib_data {
* @u_efuse_off: register offset to read fused calibration value
* @calibration_parameters: calibration parameters structure pointer
* @regmap_config: regmap config for the device
+ * @use_sm: read data from secure monitor instead of efuse
* This structure is required for configuration of amlogic thermal driver.
*/
struct amlogic_thermal_data {
int u_efuse_off;
const struct amlogic_thermal_soc_calib_data *calibration_parameters;
const struct regmap_config *regmap_config;
+ bool use_sm;
};
struct amlogic_thermal {
@@ -100,6 +103,8 @@ struct amlogic_thermal {
struct clk *clk;
struct thermal_zone_device *tzd;
u32 trim_info;
+ struct meson_sm_firmware *sm_fw;
+ u32 tsensor_id;
};
/*
@@ -138,6 +143,12 @@ static int amlogic_thermal_initialize(struct amlogic_thermal *pdata)
int ret = 0;
int ver;
+ if (pdata->data->use_sm) {
+ return meson_sm_get_thermal_calib(pdata->sm_fw,
+ &pdata->trim_info,
+ pdata->tsensor_id);
+ }
+
regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
&pdata->trim_info);
@@ -226,6 +237,12 @@ static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
.regmap_config = &amlogic_thermal_regmap_config_g12a,
};
+static const struct amlogic_thermal_data amlogic_thermal_t7_param = {
+ .use_sm = true,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
static const struct of_device_id of_amlogic_thermal_match[] = {
{
.compatible = "amlogic,g12a-ddr-thermal",
@@ -239,6 +256,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
.compatible = "amlogic,a1-cpu-thermal",
.data = &amlogic_thermal_a1_cpu_param,
},
+ {
+ .compatible = "amlogic,t7-thermal",
+ .data = &amlogic_thermal_t7_param,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
@@ -271,11 +292,38 @@ static int amlogic_thermal_probe(struct platform_device *pdev)
if (IS_ERR(pdata->clk))
return dev_err_probe(dev, PTR_ERR(pdata->clk), "failed to get clock\n");
- pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
- (pdev->dev.of_node, "amlogic,ao-secure");
- if (IS_ERR(pdata->sec_ao_map)) {
- dev_err(dev, "syscon regmap lookup failed.\n");
- return PTR_ERR(pdata->sec_ao_map);
+ if (pdata->data->use_sm) {
+ struct device_node *sm_np;
+ struct of_phandle_args ph_args;
+
+ ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
+ "amlogic,secure-monitor",
+ 1, 0, &ph_args);
+ if (ret)
+ return ret;
+
+ sm_np = ph_args.np;
+ if (!sm_np) {
+ dev_err(dev,
+ "Failed to parse secure monitor phandle\n");
+ return -ENODEV;
+ }
+
+ pdata->sm_fw = meson_sm_get(sm_np);
+ of_node_put(sm_np);
+ if (!pdata->sm_fw) {
+ dev_err(dev, "Failed to get secure monitor firmware\n");
+ return -EPROBE_DEFER;
+ }
+
+ pdata->tsensor_id = ph_args.args[0];
+ } else {
+ pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
+ (pdev->dev.of_node, "amlogic,ao-secure");
+ if (IS_ERR(pdata->sec_ao_map)) {
+ dev_err(dev, "syscon regmap lookup failed.\n");
+ return PTR_ERR(pdata->sec_ao_map);
+ }
}
pdata->tzd = devm_thermal_of_zone_register(&pdev->dev,
--
2.49.0
^ permalink raw reply related
* [PATCH v3 6/8] arm64: dts: amlogic: t7: Add thermal sensor nodes
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Add six temperature sensor nodes using the amlogic,t7-thermal compatible:
a73, a53, gpu, nna, vpu, and hevc. Each sensor retrieves its calibration
data from the secure monitor via the amlogic,secure-monitor phandle with
the corresponding tsensor_id argument.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 58 +++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7aec65f036a9c..62f259b2b17d2 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -656,6 +656,24 @@ sec_ao: ao-secure@10220 {
amlogic,has-chip-id;
};
+ a73_tsensor: temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
+
+ a53_tsensor: temperature-sensor@22000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x22000 0x0 0x50>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 2>;
+ };
+
pwm_ao_ef: pwm@30000 {
compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
reg = <0x0 0x30000 0x0 0x24>;
@@ -770,6 +788,46 @@ sd_emmc_c: mmc@8c000 {
assigned-clock-parents = <&xtal>;
status = "disabled";
};
+
+ gpu_tsensor: temperature-sensor@94000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x94000 0x0 0x50>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_MALI_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 3>;
+ };
+
+ nna_tsensor: temperature-sensor@96000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x96000 0x0 0x50>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_NNA_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 4>;
+ };
+
+ vpu_tsensor: temperature-sensor@98000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x98000 0x0 0x50>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_VPU_HDMI_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 6>;
+ };
+
+ hevc_tsensor: temperature-sensor@9a000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x9a000 0x0 0x50>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_DOS_HEVC_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 5>;
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH v3 0/8] arm64: amlogic: T7 thermal support
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
This series adds thermal monitoring support for the Amlogic T7 SoC,
used on the Khadas VIM4 board.
The T7 exposes six thermal sensors (a53, a73, gpu, nna, vpu, hevc),
each accessible through the secure monitor firmware interface rather
than a directly mapped eFuse register as on older SoCs.
The series is organized as follows:
- Patch 1 extends the amlogic,t7-thermal DT binding to describe the
new amlogic,secure-monitor property.
- Patches 2-3 extend the Meson secure monitor driver to expose a
thermal calibration read command (SMC ID 0x82000047).
- Patch 4 adds the secure monitor readout path to the amlogic thermal
driver and introduces the amlogic,t7-thermal compatible.
- Patches 5-7 wire up the T7 DTSI with CPU cooling cells, sensor
nodes, and thermal zones.
- Patch 8 extends the Khadas VIM4 DTS to map all thermal zones to the
on-board MCU fan controller (states 30–100, corresponding to the
FAN_CTRL register range 0x1E–0x64).
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v3:
- PATCH 1: Replace second if check by an else statement.
Remove unnecessary label in example according to Conor's feedback
- Link to v2: https://lore.kernel.org/r/20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr
Changes in v2:
- PATCH 1: change two const entries to enum, explain why sensor index is needed
reorder conditional compatible for required, and fallback only according to
Krzysztof's feedback.
- PATCH 3: Add kerneldoc for meson_sm_get_thermal_calib exported function
according to Krzysztof's feedback.
- Link to v1: https://lore.kernel.org/r/20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr
---
Ronald Claveau (8):
dt-bindings: thermal: amlogic: Add support for T7
firmware: meson: sm: Thermal calibration read via secure monitor
firmware: meson: sm: Add thermal calibration SMC call
thermal: amlogic: Add support for secure monitor calibration readout
arm64: dts: amlogic: t7: Add cooling cells to all CPUs
arm64: dts: amlogic: t7: Add thermal sensor nodes
arm64: dts: amlogic: t7: Add thermal zones
arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
.../bindings/thermal/amlogic,thermal.yaml | 37 +++-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 245 +++++++++++++++++++++
drivers/firmware/meson/meson_sm.c | 29 ++-
drivers/thermal/amlogic_thermal.c | 58 ++++-
include/linux/firmware/meson/meson_sm.h | 3 +
6 files changed, 462 insertions(+), 12 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260410-add-thermal-t7-vim4-00e571badcc1
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b:v2
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-patch-id: 34a2bbfe3ce30c530e69af5083aa26534b2c2560
prerequisite-patch-id: 406f88d7dabd3a870b358fb53c21686f29eb32b7
prerequisite-patch-id: d7a75ae3be0f54e0a7e81ccb0043a2f05423c9d0
prerequisite-patch-id: 5e19dc5ace12b532284246f5c2ff3f214d8a9c4f
prerequisite-patch-id: d6a87ebcf5246eb67b94ca0908afa3df9f9383fe
prerequisite-patch-id: 4809bbedf79f59e1abc52c17cffc0b1bbb43d365
prerequisite-patch-id: c050e8bac4b5491f6c7008a5ccb26f20fad38b46
prerequisite-patch-id: 30677db8fc57270787245103c0d5acf8791307b0
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH v3 5/8] arm64: dts: amlogic: t7: Add cooling cells to all CPUs
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Add #cooling-cells = <2> to all CPU nodes (both little and big cluster)
to allow them to be used as cooling devices in thermal zone mappings.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 560c9dce35266..7aec65f036a9c 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -63,6 +63,7 @@ cpu100: cpu@100 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu101: cpu@101 {
@@ -77,6 +78,7 @@ cpu101: cpu@101 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu102: cpu@102 {
@@ -91,6 +93,7 @@ cpu102: cpu@102 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu103: cpu@103 {
@@ -105,6 +108,7 @@ cpu103: cpu@103 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu0: cpu@0 {
@@ -119,6 +123,7 @@ cpu0: cpu@0 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -133,6 +138,7 @@ cpu1: cpu@1 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -147,6 +153,7 @@ cpu2: cpu@2 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -161,6 +168,7 @@ cpu3: cpu@3 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
l2_cache_l: l2-cache-cluster0 {
--
2.49.0
^ permalink raw reply related
* [PATCH v3 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Add an active trip at 50°C to all six thermal zones and map it to the
khadas_mcu fan controller, using cooling states 30 to 100.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++++++++++++++
1 file changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 5d7f5390f3a66..ba9219073dd0a 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -157,6 +157,74 @@ wifi32k: wifi32k {
};
};
+&a53_thermal {
+ trips {
+ a53_active: a53-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a53_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&a73_thermal {
+ trips {
+ a73_active: a73-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a73_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&gpu_thermal {
+ trips {
+ gpu_active: gpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&gpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&hevc_thermal {
+ trips {
+ hevc_active: hevc-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&hevc_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&i2c_m_ao_a {
status = "okay";
pinctrl-0 = <&i2c0_ao_d_pins>;
@@ -170,6 +238,23 @@ khadas_mcu: system-controller@18 {
};
};
+&nna_thermal {
+ trips {
+ nna_active: nna-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&nna_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_pins>;
@@ -266,3 +351,20 @@ &uart_a {
clocks = <&xtal>, <&xtal>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
};
+
+&vpu_thermal {
+ trips {
+ vpu_active: vpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&vpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
--
2.49.0
^ permalink raw reply related
* [PATCH v3 7/8] arm64: dts: amlogic: t7: Add thermal zones
From: Ronald Claveau @ 2026-04-21 7:19 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr>
Add thermal zones for all six sensors: a53, a73, gpu, nna, vpu, and hevc.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 179 ++++++++++++++++++++++++++++
1 file changed, 179 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 62f259b2b17d2..c6ea0f20a879f 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -9,6 +9,7 @@
#include <dt-bindings/clock/amlogic,t7-scmi.h>
#include <dt-bindings/clock/amlogic,t7-pll-clkc.h>
#include <dt-bindings/clock/amlogic,t7-peripherals-clkc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&gic>;
@@ -829,6 +830,184 @@ hevc_tsensor: temperature-sensor@9a000 {
amlogic,secure-monitor = <&sm 5>;
};
};
+ };
+
+ thermal-zones {
+ a53_thermal: a53-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a53_tsensor>;
+
+ trips {
+ a53_passive: a53-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a53_hot: a53-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a53_critical: a53-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a53 {
+ trip = <&a53_passive>;
+ cooling-device =
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ a73_thermal: a73-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a73_tsensor>;
+
+ trips {
+ a73_passive: a73-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a73_hot: a73-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a73_critical: a73-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a73 {
+ trip = <&a73_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ gpu_thermal: gpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&gpu_tsensor>;
+
+ trips {
+ gpu_passive: gpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ gpu_hot: gpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+ gpu_critical: gpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ hevc_thermal: hevc-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&hevc_tsensor>;
+
+ trips {
+ hevc_passive: hevc-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_hot: hevc-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_critical: hevc-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ nna_thermal: nna-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&nna_tsensor>;
+
+ trips {
+ nna_passive: nna-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_hot: nna-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_critical: nna-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ vpu_thermal: vpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&vpu_tsensor>;
+
+ trips {
+ vpu_passive: vpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_hot: vpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_critical: vpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
};
};
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v6 1/2] dma: arm-dma350: enable ANYCH interrupt for shared IRQ wiring
From: Jun Guo @ 2026-04-21 7:24 UTC (permalink / raw)
To: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel
In-Reply-To: <20260325112159.663881-2-jun.guo@cixtech.com>
Hi Robin,
Just pinging. I’d like to ask if you have any comments on the latest patch?
On 3/25/2026 7:21 PM, Jun Guo wrote:
> Enable DMANSECCTRL.INTREN_ANYCHINTR during probe so channel
> interrupts are propagated when integrators wire DMA-350 channels
> onto a shared IRQ line.
>
> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
> ---
> drivers/dma/arm-dma350.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/arm-dma350.c b/drivers/dma/arm-dma350.c
> index 84220fa83029..09403aca8bb0 100644
> --- a/drivers/dma/arm-dma350.c
> +++ b/drivers/dma/arm-dma350.c
> @@ -13,6 +13,11 @@
> #include "dmaengine.h"
> #include "virt-dma.h"
>
> +#define DMANSECCTRL 0x200
> +
> +#define NSEC_CTRL 0x0c
> +#define INTREN_ANYCHINTR_EN BIT(0)
> +
> #define DMAINFO 0x0f00
>
> #define DMA_BUILDCFG0 0xb0
> @@ -582,6 +587,10 @@ static int d350_probe(struct platform_device *pdev)
> dmac->dma.device_issue_pending = d350_issue_pending;
> INIT_LIST_HEAD(&dmac->dma.channels);
>
> + reg = readl_relaxed(base + DMANSECCTRL + NSEC_CTRL);
> + writel_relaxed(reg | INTREN_ANYCHINTR_EN,
> + base + DMANSECCTRL + NSEC_CTRL);
> +
> /* Would be nice to have per-channel caps for this... */
> memset = true;
> for (int i = 0; i < nchan; i++) {
^ permalink raw reply
* [PATCH v5 0/4] Update the thermal support for imx93
From: Jacky Bai @ 2026-04-21 7:42 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, Frank Li
Cc: linux-pm, devicetree, imx, linux-arm-kernel, Jacky Bai,
Conor Dooley, Alice Guo
The TMU (Thermal Monitoring Unit) on the i.MX93 requires specific
configurations and workarounds that differ from previous implementations.
So, using the 'fsl,qoriq-tmu' compatible string is not appropriate.
To address this, a dedicated compatible string and corresponding driver
changes need to be introduced to properly support the i.MX93 TMU.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
Changes in v5:
- Drop the unnecessary macro defines in patch 2/3
- Add the drvdata info for each of the platform as suggested by Daniel
- Link to v4: https://lore.kernel.org/r/20250821-imx93_tmu-v4-0-6cf5688bf016@nxp.com
Changes in v4:
- Include bitfield.h to fix the build error for RISC-V
- Use macro to define temp rate threshold related settings
- Link to v3: https://lore.kernel.org/r/20250818-imx93_tmu-v3-0-35f79a86c072@nxp.com
---
Jacky Bai (4):
dt-bindings: thermal: qoriq: Add compatible string for imx93
thermal: qoriq: add i.MX93 tmu support
thermal: qoriq: workaround unexpected temperature readings from tmu
arm64: dts: imx93: update the tmu compatible string
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 1 +
arch/arm64/boot/dts/freescale/imx93.dtsi | 2 +-
drivers/thermal/qoriq_thermal.c | 82 ++++++++++++++++++++--
3 files changed, 80 insertions(+), 5 deletions(-)
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20250804-imx93_tmu-7888c85d176e
Best regards,
--
Jacky Bai <ping.bai@nxp.com>
^ permalink raw reply
* [PATCH v5 1/4] dt-bindings: thermal: qoriq: Add compatible string for imx93
From: Jacky Bai @ 2026-04-21 7:42 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, Frank Li
Cc: linux-pm, devicetree, imx, linux-arm-kernel, Jacky Bai,
Conor Dooley
In-Reply-To: <20260421-imx93_tmu-v5-0-05ea1969bb9f@nxp.com>
Add i.MX93 compatible string 'fsl,imx93-tmu' because Thermal monitor
unit(TMU) on i.MX93 has differences with QorIQ platform and not fully
compatible with existing Platform, such as fsl,qoriq-tmu.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
- v5 changes:
- no
- v4 changes:
- no
- v3 changes:
- refine the commit log
- drop the compatible fallback support
- v2 changes:
- keep the enum
- refine the commit log to use i.MX93 and QorIQ name
---
Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
index aa756dae512a2c6e3f0b6bb1ab4a65c01e373ea7..f3b136f5e1cba1fff7e90678d7e3d7ec3ddd25c1 100644
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -25,6 +25,7 @@ properties:
enum:
- fsl,qoriq-tmu
- fsl,imx8mq-tmu
+ - fsl,imx93-tmu
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/4] thermal: qoriq: add i.MX93 tmu support
From: Jacky Bai @ 2026-04-21 7:42 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, Frank Li
Cc: linux-pm, devicetree, imx, linux-arm-kernel, Jacky Bai, Alice Guo
In-Reply-To: <20260421-imx93_tmu-v5-0-05ea1969bb9f@nxp.com>
For Thermal monitor unit(TMU) used on i.MX93, the HW revision info read
from the ID register is the same the one used on some of the QorIQ
platform, but the config has some slight differance. Add i.MX93 compatible
string and corresponding code for it.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
- v5 changes:
- drop the unnecessary GET_TEUMR0 helper macro
- add drvdata for each of the platforms
- v4 changes:
- no
- v3 changes:
- use the drv data struct for match data and refine the code
- update the copyright
- v2 changes:
- use the compatible match data to identify the i.MX93 TMU variant
---
drivers/thermal/qoriq_thermal.c | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 01b58be0dcc64d14ca5e4bba654eed8f15e827fc..297a855311f3d6a8d527794abe17ac86c47bf152 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
//
// Copyright 2016 Freescale Semiconductor, Inc.
+// Copyright 2025 NXP
#include <linux/clk.h>
#include <linux/err.h>
@@ -24,6 +25,7 @@
#define TMTMIR_DEFAULT 0x0000000f
#define TIER_DISABLE 0x0
#define TEUMR0_V2 0x51009c00
+#define TEUMR0_V21 0x55000c00
#define TMSARA_V2 0xe
#define TMU_VER1 0x1
#define TMU_VER2 0x2
@@ -73,12 +75,17 @@ struct qoriq_sensor {
int id;
};
+struct tmu_drvdata {
+ u32 teumr0;
+};
+
struct qoriq_tmu_data {
int ver;
u32 ttrcr[NUM_TTRCR_MAX];
struct regmap *regmap;
struct clk *clk;
struct qoriq_sensor sensor[SITES_MAX];
+ const struct tmu_drvdata *drvdata;
};
static struct qoriq_tmu_data *qoriq_sensor_to_data(struct qoriq_sensor *s)
@@ -225,6 +232,8 @@ static int qoriq_tmu_calibration(struct device *dev,
static void qoriq_tmu_init_device(struct qoriq_tmu_data *data)
{
+ u32 teumr0_val;
+
/* Disable interrupt, using polling instead */
regmap_write(data->regmap, REGS_TIER, TIER_DISABLE);
@@ -234,7 +243,8 @@ static void qoriq_tmu_init_device(struct qoriq_tmu_data *data)
regmap_write(data->regmap, REGS_TMTMIR, TMTMIR_DEFAULT);
} else {
regmap_write(data->regmap, REGS_V2_TMTMIR, TMTMIR_DEFAULT);
- regmap_write(data->regmap, REGS_V2_TEUMR(0), TEUMR0_V2);
+ teumr0_val = data->drvdata->teumr0;
+ regmap_write(data->regmap, REGS_V2_TEUMR(0), teumr0_val);
}
/* Disable monitoring */
@@ -319,6 +329,10 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
data->ver = (ver >> 8) & 0xff;
+ data->drvdata = of_device_get_match_data(&pdev->dev);
+ if (!data->drvdata)
+ return dev_err_probe(dev, -EINVAL, "Failed to get match data\n");
+
qoriq_tmu_init_device(data); /* TMU initialization */
ret = qoriq_tmu_calibration(dev, data); /* TMU calibration */
@@ -376,9 +390,22 @@ static int qoriq_tmu_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(qoriq_tmu_pm_ops,
qoriq_tmu_suspend, qoriq_tmu_resume);
+static const struct tmu_drvdata qoriq_tmu_data = {
+ .teumr0 = TEUMR0_V2,
+};
+
+static const struct tmu_drvdata imx8mq_tmu_data = {
+ .teumr0 = TEUMR0_V2,
+};
+
+static const struct tmu_drvdata imx93_data = {
+ .teumr0 = TEUMR0_V21,
+};
+
static const struct of_device_id qoriq_tmu_match[] = {
- { .compatible = "fsl,qoriq-tmu", },
- { .compatible = "fsl,imx8mq-tmu", },
+ { .compatible = "fsl,qoriq-tmu", .data = &qoriq_tmu_data },
+ { .compatible = "fsl,imx8mq-tmu", .data = &imx8mq_tmu_data },
+ { .compatible = "fsl,imx93-tmu", .data = &imx93_data },
{},
};
MODULE_DEVICE_TABLE(of, qoriq_tmu_match);
--
2.34.1
^ permalink raw reply related
* [PATCH v5 3/4] thermal: qoriq: workaround unexpected temperature readings from tmu
From: Jacky Bai @ 2026-04-21 7:42 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, Frank Li
Cc: linux-pm, devicetree, imx, linux-arm-kernel, Jacky Bai
In-Reply-To: <20260421-imx93_tmu-v5-0-05ea1969bb9f@nxp.com>
Invalid temperature measurements may be observed across the temperature
range specified in the device data sheet. The invalid temperature can
be read from any remote site and from any capture or report registers.
The invalid change in temperature can be positive or negative and the
resulting temperature can be outside the calibrated range, in which
case the TSR[ORL] or TSR[ORH] bit will be set.
Workaround:
Use the raising/falling edge threshold to filter out the invalid temp.
Check the TIDR register to make sure no jump happens When reading the temp.
i.MX93 ERR052243:
(https://www.nxp.com/webapp/Download?colCode=IMX93_2P87F&appType=license)
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
- v5 changes:
- replace the check errata macro with inline function
- v4 changes:
- include bitfield.h to fix compilation errors for RISC-V
- use macro define for temp rate related setting
- v3 changes:
- refine the code with FIELD_PREP macro
- add errata doc url link and refine the commit log
- v2 changes:
- no
---
drivers/thermal/qoriq_thermal.c | 49 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 297a855311f3d6a8d527794abe17ac86c47bf152..57c712b9b359d713f2ff4926eb890a0641aa96bd 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -3,6 +3,7 @@
// Copyright 2016 Freescale Semiconductor, Inc.
// Copyright 2025 NXP
+#include <linux/bitfield.h>
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
@@ -30,6 +31,9 @@
#define TMU_VER1 0x1
#define TMU_VER2 0x2
+/* errata ID info define */
+#define TMU_ERR052243 BIT(0)
+
#define REGS_TMR 0x000 /* Mode Register */
#define TMR_DISABLE 0x0
#define TMR_ME 0x80000000
@@ -45,6 +49,15 @@
#define REGS_TIER 0x020 /* Interrupt Enable Register */
#define TIER_DISABLE 0x0
+#define REGS_TIDR 0x24
+#define TEMP_RATE_IRQ_MASK GENMASK(25, 24)
+#define TMRTRCTR 0x70
+#define TMRTRCTR_EN BIT(31)
+#define TMRTRCTR_TEMP_MASK GENMASK(7, 0)
+#define TMFTRCTR 0x74
+#define TMFTRCTR_EN BIT(31)
+#define TMFTRCTR_TEMP_MASK GENMASK(7, 0)
+#define TEMP_RATE_THR_LVL 0x7
#define REGS_TTCFGR 0x080 /* Temperature Configuration Register */
#define REGS_TSCFGR 0x084 /* Sensor Configuration Register */
@@ -77,6 +90,7 @@ struct qoriq_sensor {
struct tmu_drvdata {
u32 teumr0;
+ u32 tmu_errata;
};
struct qoriq_tmu_data {
@@ -88,6 +102,12 @@ struct qoriq_tmu_data {
const struct tmu_drvdata *drvdata;
};
+static inline bool qoriq_tmu_has_errata(const struct tmu_drvdata *drvdata,
+ u32 flag)
+{
+ return drvdata->tmu_errata & flag;
+}
+
static struct qoriq_tmu_data *qoriq_sensor_to_data(struct qoriq_sensor *s)
{
return container_of(s, struct qoriq_tmu_data, sensor[s->id]);
@@ -97,7 +117,7 @@ static int tmu_get_temp(struct thermal_zone_device *tz, int *temp)
{
struct qoriq_sensor *qsensor = thermal_zone_device_priv(tz);
struct qoriq_tmu_data *qdata = qoriq_sensor_to_data(qsensor);
- u32 val;
+ u32 val, tidr;
/*
* REGS_TRITSR(id) has the following layout:
*
@@ -122,6 +142,15 @@ static int tmu_get_temp(struct thermal_zone_device *tz, int *temp)
if (!(val & TMR_ME))
return -EAGAIN;
+ /* ERR052243: If a raising or falling edge happens, try later */
+ if (qoriq_tmu_has_errata(qdata->drvdata, TMU_ERR052243)) {
+ regmap_read(qdata->regmap, REGS_TIDR, &tidr);
+ if (tidr & TEMP_RATE_IRQ_MASK) {
+ regmap_write(qdata->regmap, REGS_TIDR, TEMP_RATE_IRQ_MASK);
+ return -EAGAIN;
+ }
+ }
+
if (regmap_read_poll_timeout(qdata->regmap,
REGS_TRITSR(qsensor->id),
val,
@@ -130,6 +159,15 @@ static int tmu_get_temp(struct thermal_zone_device *tz, int *temp)
10 * USEC_PER_MSEC))
return -ENODATA;
+ /*ERR052243: If a raising or falling edge happens, try later */
+ if (qoriq_tmu_has_errata(qdata->drvdata, TMU_ERR052243)) {
+ regmap_read(qdata->regmap, REGS_TIDR, &tidr);
+ if (tidr & TEMP_RATE_IRQ_MASK) {
+ regmap_write(qdata->regmap, REGS_TIDR, TEMP_RATE_IRQ_MASK);
+ return -EAGAIN;
+ }
+ }
+
if (qdata->ver == TMU_VER1) {
*temp = (val & GENMASK(7, 0)) * MILLIDEGREE_PER_DEGREE;
} else {
@@ -247,6 +285,14 @@ static void qoriq_tmu_init_device(struct qoriq_tmu_data *data)
regmap_write(data->regmap, REGS_V2_TEUMR(0), teumr0_val);
}
+ /* ERR052243: Set the raising & falling edge monitor */
+ if (qoriq_tmu_has_errata(data->drvdata, TMU_ERR052243)) {
+ regmap_write(data->regmap, TMRTRCTR, TMRTRCTR_EN |
+ FIELD_PREP(TMRTRCTR_TEMP_MASK, TEMP_RATE_THR_LVL));
+ regmap_write(data->regmap, TMFTRCTR, TMFTRCTR_EN |
+ FIELD_PREP(TMFTRCTR_TEMP_MASK, TEMP_RATE_THR_LVL));
+
+ }
/* Disable monitoring */
regmap_write(data->regmap, REGS_TMR, TMR_DISABLE);
}
@@ -400,6 +446,7 @@ static const struct tmu_drvdata imx8mq_tmu_data = {
static const struct tmu_drvdata imx93_data = {
.teumr0 = TEUMR0_V21,
+ .tmu_errata = TMU_ERR052243,
};
static const struct of_device_id qoriq_tmu_match[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 4/4] arm64: dts: imx93: update the tmu compatible string
From: Jacky Bai @ 2026-04-21 7:42 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, Frank Li
Cc: linux-pm, devicetree, imx, linux-arm-kernel, Jacky Bai
In-Reply-To: <20260421-imx93_tmu-v5-0-05ea1969bb9f@nxp.com>
The i.MX93 TMU node compatible need to be updated to apply the SoC
specific configuration and TMU errata workaround.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
- v5 changes:
- no
- v4 changes:
- no
- v3 changes:
- drop the qoriq compatible
- v2 changes:
- no
---
arch/arm64/boot/dts/freescale/imx93.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index b9abe143cb567e722277960ff677d460154dfc8a..06443d52a4290f9525c320f8bcf5fba1a8435d11 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -80,7 +80,7 @@ mu1: mailbox@44230000 {
};
tmu: tmu@44482000 {
- compatible = "fsl,qoriq-tmu";
+ compatible = "fsl,imx93-tmu";
reg = <0x44482000 0x1000>;
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX93_CLK_TMC_GATE>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: KVM: Initialize vGIC before preempt-disabled section in kvm_reset_vcpu()
From: Marc Zyngier @ 2026-04-21 7:42 UTC (permalink / raw)
To: Deepanshu Kartikey
Cc: oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, drjones, christoffer.dall, linux-arm-kernel, kvmarm,
linux-kernel, syzbot+12b178b7c756664d2518
In-Reply-To: <CADhLXY4pL2BrPukVxr_kySzx48gMt7zFxOq8=eFSXqOB4at7aQ@mail.gmail.com>
On Tue, 21 Apr 2026 02:48:02 +0100,
Deepanshu Kartikey <kartikey406@gmail.com> wrote:
>
> On Thu, Apr 16, 2026 at 7:50 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Sun, 12 Apr 2026 09:04:37 +0100,
> > Deepanshu Kartikey <kartikey406@gmail.com> wrote:
> > >
> > > kvm_reset_vcpu() calls kvm_timer_vcpu_reset() inside a preempt-disabled
> > > section to avoid races with preempt notifiers that also call vcpu put/load.
> > >
> > > However, kvm_timer_vcpu_reset() eventually calls kvm_vgic_inject_irq()
> > > which triggers vgic_lazy_init() if the vGIC has not been initialized yet.
> > > vgic_lazy_init() acquires a mutex and calls vgic_init() which invokes
> > > synchronize_srcu_expedited() -- both of which may sleep. Sleeping inside
> > > a preempt-disabled section is illegal and causes:
> > >
> > > BUG: scheduling while atomic: syz.1.49/3699/0x00000002
> > >
> > > Fix this by calling vgic_lazy_init() before preempt_disable(). On the
> > > second call inside kvm_vgic_inject_irq(), vgic_initialized() will return
> > > true and vgic_lazy_init() will return immediately without sleeping.
> > >
> >
> > I think this really goes in the wrong direction. Forcing the vgic (a
> > global resource) to initialise when the vcpu's timer (a local
> > resource) is reset feels at best bizarre. Now you are promoting it to
> > be forced at vcpu reset. This makes things worse.
> >
> > You probably want to take a step back and look at *why* we end-up
> > here. The core reason seems to be that the timer emulation caches the
> > level in a per-timer structure, and tries hard not call into the vgic
> > unless the level changes. Which means that unless the vgic is
> > initialised and is able to latch that state, the initial pending state
> > will not be propagated to the guest.
> >
> > But do we need this optimisation? I don't think so. Other emulated
> > devices don't require it. We can let the vgic know the state of the
> > timer at every vcpu entry, just like we do for other virtual
> > interrupts that the kernel injects (PMU, vgic MI).
> >
> > Once you remove the this cache and the need for the vgic to buffer
> > things outside of normal execution, you can also drop the magic init
> > from the interrupt injection path, because the injection will happen
> > on the run path, just like any other PPI.
> >
> > That'd be a much better approach IMO.
> >
> > Thanks,
> >
> > M.
> >
> > --
> > Without deviation from the norm, progress is not possible.
>
>
> Hi Marc,
>
> Thank you for the detailed feedback! I apologize for the delayed
> response — I was away on holiday.
No need to apologise. I hadn't spotted this report (syzkaller badly
triaged it), so thanks for bring it to my attention.
>
> I understand your point. My fix addresses the symptom rather than the
> root cause. Forcing vGIC (a global resource) to initialize during
> timer (a local resource) reset is not the right approach.
>
> I will take your suggestion and work on:
>
> I will send a v2 once I have something ready.
I've posted my own take on this at [1], for which you are on Cc. Feel
free to review it if you have the time (I'll post a v2 anyway, as I
have accumulated a couple of additional fixes).
Cheers,
M.
[1] https://lore.kernel.org/r/20260417124612.2770268-1-maz@kernel.org
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: Lance Yang @ 2026-04-21 7:46 UTC (permalink / raw)
To: david
Cc: catalin.marinas, will, akpm, ljs, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, lance.yang, ryan.roberts,
linux-arm-kernel, linux-kernel, linux-mm, stable
In-Reply-To: <20260420-zerotags-v1-1-3edc93e95bb4@kernel.org>
On Mon, Apr 20, 2026 at 11:16:46PM +0200, David Hildenbrand (Arm) wrote:
>__GFP_ZEROTAGS semantics are currently a bit weird, but effectively this
>flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.
>
>If we run with init_on_free, we will zero out pages during
>__free_pages_prepare(), to skip zeroing on the allocation path.
>
>However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will
>consequently not only skip clearing page content, but also skip
>clearing tag memory.
>
>Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that
>will get mapped to user space through set_pte_at() later: set_pte_at() and
>friends will detect that the tags have not been initialized yet
>(PG_mte_tagged not set), and initialize them.
>
>However, for the huge zero folio, which will be mapped through a PMD
>marked as special, this initialization will not be performed, ending up
>exposing whatever tags were still set for the pages.
>
>The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state
>that allocation tags are set to 0 when a page is first mapped to user
>space. That no longer holds with the huge zero folio when init_on_free
>is enabled.
>
>Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to
>tag_clear_highpages() whether we want to also clear page content.
>
>As we are touching the interface either way, just clean it up by
>only calling it when HW tags are enabled, dropping the return value, and
>dropping the common code stub.
>
>Reproduced with the huge zero folio by modifying the check_buffer_fill
>arm64/mte selftest to use a 2 MiB area, after making sure that pages have
>a non-0 tag set when freeing (note that, during boot, we will not
>actually initialize tags, but only set KASAN_TAG_KERNEL in the page
>flags).
Good catch!
I can reproduce it reliably with this small debug change:
---8<---
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 970e077019b7..d5b6e2474f47 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -225,8 +225,7 @@ static bool get_huge_zero_folio(void)
if (likely(atomic_inc_not_zero(&huge_zero_refcount)))
return true;
- zero_folio = folio_alloc((GFP_TRANSHUGE | __GFP_ZERO | __GFP_ZEROTAGS) &
- ~__GFP_MOVABLE,
+ zero_folio = folio_alloc(GFP_TRANSHUGE | __GFP_ZERO | __GFP_ZEROTAGS,
HPAGE_PMD_ORDER);
if (!zero_folio) {
count_vm_event(THP_ZERO_PAGE_ALLOC_FAILED);
---
That makes it much easier to hit. Userspace can seed tagged 2 MB folios,
but only as __GFP_MOVABLE.
The original huge zero folio allocation uses "& ~__GFP_MOVABLE", so it
will only reach these folios through fallback, which is hard to force
reliably from userspace :(
Will get back once testing is done :P
Cheers,
Lance
^ permalink raw reply related
* Re: [PATCH v2] iommu/arm-smmu: Use pm_runtime in fault handlers
From: Prakash Gupta @ 2026-04-21 7:47 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Clark, Connor Abbott,
linux-arm-msm, linux-arm-kernel, iommu, linux-kernel,
Akhil P Oommen, Pratyush Brahma
In-Reply-To: <ac8j1jlFNxgZWzzK@google.com>
On 4/3/2026 7:50 AM, Pranjal Shrivastava wrote:
> On Fri, Mar 13, 2026 at 03:53:53PM +0530, Prakash Gupta wrote:
>> Commit d4a44f0750bb ("iommu/arm-smmu: Invoke pm_runtime across the driver")
>> enabled pm_runtime for the arm-smmu device. On systems where the SMMU
>> sits in a power domain, all register accesses must be done while the
>> device is runtime active to avoid unclocked register reads and
>> potential NoC errors.
>>
>> So far, this has not been an issue for most SMMU clients because
>> stall-on-fault is enabled by default. While a translation fault is
>> being handled, the SMMU stalls further translations for that context
>> bank, so the fault handler would not race with a powered-down
>> SMMU.
>>
>> Adreno SMMU now disables stall-on-fault in the presence of fault
>> storms to avoid saturating SMMU resources and hanging the GMU. With
>> stall-on-fault disabled, the SMMU can generate faults while its power
>> domain may no longer be enabled, which makes unclocked accesses to
>> fault-status registers in the SMMU fault handlers possible.
>>
>> Guard the context and global fault handlers with pm_runtime_get_if_active()
>> and pm_runtime_put_autosuspend() so that all SMMU fault register accesses
>> are done with the SMMU powered. In case pm_runtime is not active we can
>> safely ignore the fault as for pm runtime resume the smmu device is
>> reset and fault registers are cleared.
>>
>> Fixes: b13044092c1e ("drm/msm: Temporarily disable stall-on-fault after a page fault")
>> Co-developed-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
>> Signed-off-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
>> Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Switched from arm_smmu_rpm_get()/arm_smmu_rpm_put() wrappers to
>> pm_runtime_get_if_active()/pm_runtime_put_autosuspend() APIs
>> - Added support for smmu->impl->global_fault callback in global fault handler
>> - Remove threaded irq context fault restriction to allow modifying stall
>> mode for adreno smmu
>> - Link to v1: https://patch.msgid.link/20260127-smmu-rpm-v1-1-2ef2f4c85305@oss.qualcomm.com
>> ---
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 60 +++++++++++++++++++++++------------
>> 1 file changed, 39 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> index 5e690cf85ec9..f4c46491a03d 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> @@ -462,10 +462,20 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
>> int idx = smmu_domain->cfg.cbndx;
>> int ret;
>>
>> + if (!pm_runtime_get_if_active(smmu->dev))
>
> Note that the pm_runtime_get_if_active(dev) only returns a positive
> value if the device state is exactly RPM_ACTIVE. If the device is in the
> middle of its runtime_suspend callback, its state is RPM_SUSPENDING.
>
> Thus, if a fault races with the suspend callback, we'll return IRQ_NONE
> and the suspend callback doesn't seem to be disabling interrupts.
>
> This isn't any better if we're in a fault-storm caused by
> level-triggered interrupts, we'd simply keep entering this handler and
> return.
>
> I believe we should clear / handle any pending faults/interrupts or
> atleast mask interrupt in the suspend handler to avoid this situation.
>
Sorry for late response.
Thanks for feedback, I see the issue with level trigger causing
interrupt storm here.
I don't see how we can meaningfully handle all context bank faults in
suspend path. We can clear it, but the idea was that smmu device is
going to be suspended, and shouldn't have any active transactions at
this point. Any remaining fault is expected to be stale, which will be
cleared in resume. I think it would be better to just mask the
interrupts in suspend path to avoid interrupt storm.
Will address this in next patch.
>> + return IRQ_NONE;
>> +
>
> Maybe we could add another wrapped-helper to maintain consistency:
>
> static inline int arm_smmu_rpm_get_if_active(struct arm_smmu_device *smmu)
> {
> if (!pm_runtime_enabled(smmu->dev))
> return 1; // Assume active/powered if RPM is not used
> return pm_runtime_get_if_active(smmu->dev);
> }
>
> This returns -EINVAL otherwise which isn't a problem for the if
> condition but slightly cleaner.
>
>> + if (smmu->impl && smmu->impl->context_fault) {
>> + ret = smmu->impl->context_fault(irq, dev);
>> + goto out_power_off;
>> + }
>> +
>
Ack. Will update in next patch.
> We've moved impl-specific handlers here, I don't see a functional change.
> This looks fine.
>
>> arm_smmu_read_context_fault_info(smmu, idx, &cfi);
>>
>> - if (!(cfi.fsr & ARM_SMMU_CB_FSR_FAULT))
>> - return IRQ_NONE;
>> + if (!(cfi.fsr & ARM_SMMU_CB_FSR_FAULT)) {
>> + ret = IRQ_NONE;
>> + goto out_power_off;
>> + }
>>
>> ret = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
>> cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
>> @@ -480,7 +490,12 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
>> ret == -EAGAIN ? 0 : ARM_SMMU_RESUME_TERMINATE);
>> }
>>
>> - return IRQ_HANDLED;
>> + ret = IRQ_HANDLED;
>> +
>> +out_power_off:
>> + pm_runtime_put_autosuspend(smmu->dev);
>
> Nit: Please use arm_smmu_rpm_put() here.. while at it, I guess we can
> also bring back pm_runtime_put_autosuspend() in arm_smmu_rpm_put() since
> it is updated now to also mark last busy.
Ack. Will update in next patch.
>
>> +
>> + return ret;
>> }
>>
>> static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>> @@ -489,14 +504,25 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>> struct arm_smmu_device *smmu = dev;
>> static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
>> DEFAULT_RATELIMIT_BURST);
>> + int ret;
>> +
>> + if (!pm_runtime_get_if_active(smmu->dev))
>> + return IRQ_NONE;
>> +
>
> Same here.
>
>> + if (smmu->impl && smmu->impl->global_fault) {
>> + ret = smmu->impl->global_fault(irq, dev);
>> + goto out_power_off;
>> + }
>>
>> gfsr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSR);
>> gfsynr0 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR0);
>> gfsynr1 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR1);
>> gfsynr2 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR2);
>>
>> - if (!gfsr)
>> - return IRQ_NONE;
>> + if (!gfsr) {
>> + ret = IRQ_NONE;
>> + goto out_power_off;
>> + }
>>
>> if (__ratelimit(&rs)) {
>> if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
>> @@ -513,7 +539,11 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>> }
>>
>> arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_sGFSR, gfsr);
>> - return IRQ_HANDLED;
>> + ret = IRQ_HANDLED;
>> +
>> +out_power_off:
>> + pm_runtime_put_autosuspend(smmu->dev);
>> + return ret;
>> }
>>
>> static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>> @@ -683,7 +713,6 @@ static int arm_smmu_init_domain_context(struct arm_smmu_domain *smmu_domain,
>> enum io_pgtable_fmt fmt;
>> struct iommu_domain *domain = &smmu_domain->domain;
>> struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
>> - irqreturn_t (*context_fault)(int irq, void *dev);
>>
>> mutex_lock(&smmu_domain->init_mutex);
>> if (smmu_domain->smmu)
>> @@ -850,19 +879,14 @@ static int arm_smmu_init_domain_context(struct arm_smmu_domain *smmu_domain,
>> */
>> irq = smmu->irqs[cfg->irptndx];
>>
>> - if (smmu->impl && smmu->impl->context_fault)
>> - context_fault = smmu->impl->context_fault;
>> - else
>> - context_fault = arm_smmu_context_fault;
>> -
>> if (smmu->impl && smmu->impl->context_fault_needs_threaded_irq)
>> ret = devm_request_threaded_irq(smmu->dev, irq, NULL,
>> - context_fault,
>> + arm_smmu_context_fault,
>> IRQF_ONESHOT | IRQF_SHARED,
>> "arm-smmu-context-fault",
>> smmu_domain);
>> else
>> - ret = devm_request_irq(smmu->dev, irq, context_fault, IRQF_SHARED,
>> + ret = devm_request_irq(smmu->dev, irq, arm_smmu_context_fault, IRQF_SHARED,
>> "arm-smmu-context-fault", smmu_domain);
>>
>> if (ret < 0) {
>> @@ -2125,7 +2149,6 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>> struct device *dev = &pdev->dev;
>> int num_irqs, i, err;
>> u32 global_irqs, pmu_irqs;
>> - irqreturn_t (*global_fault)(int irq, void *dev);
>>
>> smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
>> if (!smmu) {
>> @@ -2205,18 +2228,13 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>> smmu->num_context_irqs = smmu->num_context_banks;
>> }
>>
>> - if (smmu->impl && smmu->impl->global_fault)
>> - global_fault = smmu->impl->global_fault;
>> - else
>> - global_fault = arm_smmu_global_fault;
>> -
>> for (i = 0; i < global_irqs; i++) {
>> int irq = platform_get_irq(pdev, i);
>>
>> if (irq < 0)
>> return irq;
>>
>> - err = devm_request_irq(dev, irq, global_fault, IRQF_SHARED,
>> + err = devm_request_irq(dev, irq, arm_smmu_global_fault, IRQF_SHARED,
>> "arm-smmu global fault", smmu);
>> if (err)
>> return dev_err_probe(dev, err,
>>
>
> Thanks,
> Praan
^ permalink raw reply
* Re: [PATCH v25 0/7] firmware: imx: driver for NXP secure-enclave
From: Frieder Schrempf @ 2026-04-21 7:52 UTC (permalink / raw)
To: Pankaj Gupta, Jonathan Corbet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Frank Li
In-Reply-To: <6543cf20-01e3-4dc2-b4b0-08935527f440@kontron.de>
On 24.02.26 12:18, Frieder Schrempf wrote:
> On 29.01.26 17:58, Pankaj Gupta wrote:
>> Hi Shawn,
>>
>> This is a gentle follow‑up regarding the patch-set.
>>
>> In v25, I addressed all automated feedback from kernel CI (warning fixes and checkpatch‑strict resolution), with no further changes requested by reviewers.
>> Patch 5/7 has also received a Reviewed-by tag from Frank Li (NXP).
>>
>> I have not seen additional feedback.
>> I would appreciate any update on the review/merge status, or guidance on further changes needed to move the series forward.
>>
>> Thanks for your time and continued support.
>
> How close are we to getting this patchset merged? Work on this has been
> ongoing for almost three years now and it would be really helpful to
> have this in the kernel.
>
> Thanks!
Gentle ping! Can someone please provide information on what needs to be
done to get this merged?
Thanks!
^ 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