* 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
* Re: [PATCH v2 1/4] dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile A1
From: Krzysztof Kozlowski @ 2026-04-21 8:01 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260415233300.457892-2-marek.vasut+renesas@mailbox.org>
On Thu, Apr 16, 2026 at 01:31:38AM +0200, Marek Vasut wrote:
> Document ZT trace bus and ZTR trace clock on the R-Mobile A1.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
This might affect ABI, because you are basically requiring DTS to have
additional two clocks. Probably it does not affect anyone, but
technically is an ABI change, so should be explained in commit msg WHY
you are doing it and what is the impact, instead of saying WHAT you did.
If there is going to be a new version, please fix it and please keep the
feedback for future commits.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Krzysztof Kozlowski @ 2026-04-21 8:02 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260415233300.457892-4-marek.vasut+renesas@mailbox.org>
On Thu, Apr 16, 2026 at 01:31:40AM +0200, Marek Vasut wrote:
> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Add ztr/zt clock at the end of the list to match bindings
> ---
> arch/arm/boot/dts/renesas/r8a7740.dtsi | 2 +-
> include/dt-bindings/clock/r8a7740-clock.h | 2 ++
This goes to the binding patch.
Didn't you have also a checkpatch warning?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: David Hildenbrand (Arm) @ 2026-04-21 8:06 UTC (permalink / raw)
To: Dev Jain, 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: <5463cf34-bd8c-4ecb-b93a-fd8b2bd2976d@arm.com>
On 4/21/26 09:06, Dev Jain wrote:
>
>
> 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?
Right, we have to clear tags here even without kasan. God, what an ugly
mess people created here with these GFP flags.
Let me think about how to do that in the least ugly way.
--
Cheers,
David
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
From: Jian Hu via B4 Relay @ 2026-04-21 8:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu, Conor Dooley
In-Reply-To: <20260421-clkmsr_a1_t7-v3-0-efc00b0f9e6b@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add the Amlogic A1 and T7 compatible for the clk-measurer IP.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
.../devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
index 39d4637c2d08..b1200e6940ac 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
@@ -24,6 +24,8 @@ properties:
- amlogic,meson-sm1-clk-measure
- amlogic,c3-clk-measure
- amlogic,s4-clk-measure
+ - amlogic,a1-clk-measure
+ - amlogic,t7-clk-measure
reg:
maxItems: 1
--
2.47.1
^ permalink raw reply related
* [PATCH v3 3/4] arm64: dts: meson: a1: Add clk measure support
From: Jian Hu via B4 Relay @ 2026-04-21 8:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
In-Reply-To: <20260421-clkmsr_a1_t7-v3-0-efc00b0f9e6b@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add the clock measure device to the A1 SoC family.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index 348411411f3d..6f6a6145cba1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -576,6 +576,11 @@ saradc: adc@2c00 {
status = "disabled";
};
+ clock-measurer@3400 {
+ compatible = "amlogic,a1-clk-measure";
+ reg = <0x0 0x3400 0x0 0x1c>;
+ };
+
i2c1: i2c@5c00 {
compatible = "amlogic,meson-axg-i2c";
status = "disabled";
--
2.47.1
^ permalink raw reply related
* [PATCH v3 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Jian Hu via B4 Relay @ 2026-04-21 8:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
In-Reply-To: <20260421-clkmsr_a1_t7-v3-0-efc00b0f9e6b@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add the clock measure device to the T7 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed62..6a22b48a42b7 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -656,6 +656,11 @@ pwm_ao_gh: pwm@32000 {
status = "disabled";
};
+ clock-measurer@48000 {
+ compatible = "amlogic,t7-clk-measure";
+ reg = <0x0 0x48000 0x0 0x1c>;
+ };
+
pwm_ab: pwm@58000 {
compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
reg = <0x0 0x58000 0x0 0x24>;
--
2.47.1
^ permalink raw reply related
* [PATCH v3 0/4] soc: amlogic: clk-measure: add A1 and T7 support
From: Jian Hu via B4 Relay @ 2026-04-21 8:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu, Conor Dooley
This series adds Amlogic clock measurement support for A1 and T7 SoCs,
including binding updates, driver additions, and device tree enablement.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
Changes in v3:
- Place the clock-measure node after pwm_ao_gh node for t7.
- Link to v2: https://lore.kernel.org/r/20260415-clkmsr_a1_t7-v2-0-02b6314427e6@amlogic.com
Changes in v2:
- Add const for a1 and t7 clock measure table.
- Use b4 to send this series.
- Link to v1: https://lore.kernel.org/all/20260410100329.3167482-1-jian.hu@amlogic.com
---
Jian Hu (4):
dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
soc: amlogic: clk-measure: Add A1 and T7 support
arm64: dts: meson: a1: Add clk measure support
arm64: dts: amlogic: t7: Add clk measure support
.../soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 +
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +
drivers/soc/amlogic/meson-clk-measure.c | 272 +++++++++++++++++++++
4 files changed, 284 insertions(+)
---
base-commit: 401e5c73eedde8225e87bd11c794b8409248ff41
change-id: 20260415-clkmsr_a1_t7-9820984d0af1
Best regards,
--
Jian Hu <jian.hu@amlogic.com>
^ permalink raw reply
* [PATCH v3 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Jian Hu via B4 Relay @ 2026-04-21 8:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
In-Reply-To: <20260421-clkmsr_a1_t7-v3-0-efc00b0f9e6b@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add support for the A1 and T7 SoC family in amlogic clk measure.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++++++++++
1 file changed, 272 insertions(+)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index d862e30a244e..8c4f3cc8c8ab 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
};
+static const struct meson_msr_id clk_msr_a1[] = {
+ CLK_MSR_ID(0, "tdmout_b_sclk"),
+ CLK_MSR_ID(1, "tdmout_a_sclk"),
+ CLK_MSR_ID(2, "tdmin_lb_sclk"),
+ CLK_MSR_ID(3, "tdmin_b_sclk"),
+ CLK_MSR_ID(4, "tdmin_a_sclk"),
+ CLK_MSR_ID(5, "vad"),
+ CLK_MSR_ID(6, "resamplea"),
+ CLK_MSR_ID(7, "pdm_sysclk"),
+ CLK_MSR_ID(8, "pdm_dclk"),
+ CLK_MSR_ID(9, "locker_out"),
+ CLK_MSR_ID(10, "locker_in"),
+ CLK_MSR_ID(11, "spdifin"),
+ CLK_MSR_ID(12, "tdmin_vad"),
+ CLK_MSR_ID(13, "au_adc"),
+ CLK_MSR_ID(14, "au_dac"),
+ CLK_MSR_ID(16, "spicc_a"),
+ CLK_MSR_ID(17, "spifc"),
+ CLK_MSR_ID(18, "sd_emmc_a"),
+ CLK_MSR_ID(19, "dmcx4"),
+ CLK_MSR_ID(20, "dmc"),
+ CLK_MSR_ID(21, "psram"),
+ CLK_MSR_ID(22, "cecb"),
+ CLK_MSR_ID(23, "ceca"),
+ CLK_MSR_ID(24, "ts"),
+ CLK_MSR_ID(25, "pwm_f"),
+ CLK_MSR_ID(26, "pwm_e"),
+ CLK_MSR_ID(27, "pwm_d"),
+ CLK_MSR_ID(28, "pwm_c"),
+ CLK_MSR_ID(29, "pwm_b"),
+ CLK_MSR_ID(30, "pwm_a"),
+ CLK_MSR_ID(31, "saradc"),
+ CLK_MSR_ID(32, "usb_bus"),
+ CLK_MSR_ID(33, "dsp_b"),
+ CLK_MSR_ID(34, "dsp_a"),
+ CLK_MSR_ID(35, "axi"),
+ CLK_MSR_ID(36, "sys"),
+ CLK_MSR_ID(40, "rng_ring_osc0"),
+ CLK_MSR_ID(41, "rng_ring_osc1"),
+ CLK_MSR_ID(42, "rng_ring_osc2"),
+ CLK_MSR_ID(43, "rng_ring_osc3"),
+ CLK_MSR_ID(44, "dds_out"),
+ CLK_MSR_ID(45, "cpu_clk_div16"),
+ CLK_MSR_ID(46, "gpio_msr"),
+ CLK_MSR_ID(50, "osc_ring_cpu0"),
+ CLK_MSR_ID(51, "osc_ring_cpu1"),
+ CLK_MSR_ID(54, "osc_ring_top0"),
+ CLK_MSR_ID(55, "osc_ring_top1"),
+ CLK_MSR_ID(56, "osc_ring_ddr"),
+ CLK_MSR_ID(57, "osc_ring_dmc"),
+ CLK_MSR_ID(58, "osc_ring_dspa"),
+ CLK_MSR_ID(59, "osc_ring_dspb"),
+ CLK_MSR_ID(60, "osc_ring_rama"),
+ CLK_MSR_ID(61, "osc_ring_ramb"),
+};
+
+static const struct meson_msr_id clk_msr_t7[] = {
+ CLK_MSR_ID(0, "sys"),
+ CLK_MSR_ID(1, "axi"),
+ CLK_MSR_ID(2, "rtc"),
+ CLK_MSR_ID(3, "dspa"),
+ CLK_MSR_ID(4, "dspb"),
+ CLK_MSR_ID(5, "mali"),
+ CLK_MSR_ID(6, "sys_cpu_clk_div16"),
+ CLK_MSR_ID(7, "ceca"),
+ CLK_MSR_ID(8, "cecb"),
+ CLK_MSR_ID(10, "fclk_div5"),
+ CLK_MSR_ID(11, "mpll0"),
+ CLK_MSR_ID(12, "mpll1"),
+ CLK_MSR_ID(13, "mpll2"),
+ CLK_MSR_ID(14, "mpll3"),
+ CLK_MSR_ID(15, "mpll_50m"),
+ CLK_MSR_ID(16, "pcie_inp"),
+ CLK_MSR_ID(17, "pcie_inn"),
+ CLK_MSR_ID(18, "mpll_test_out"),
+ CLK_MSR_ID(19, "hifi_pll"),
+ CLK_MSR_ID(20, "gp0_pll"),
+ CLK_MSR_ID(21, "gp1_pll"),
+ CLK_MSR_ID(22, "eth_mppll_50m"),
+ CLK_MSR_ID(23, "sys_pll_div16"),
+ CLK_MSR_ID(24, "ddr_dpll_pt"),
+ CLK_MSR_ID(25, "earcrx_pll"),
+ CLK_MSR_ID(26, "paie1_clk_inp"),
+ CLK_MSR_ID(27, "paie1_clk_inn"),
+ CLK_MSR_ID(28, "amlgdc"),
+ CLK_MSR_ID(29, "gdc"),
+ CLK_MSR_ID(30, "mod_eth_phy_ref"),
+ CLK_MSR_ID(31, "mod_eth_tx"),
+ CLK_MSR_ID(32, "eth_clk125Mhz"),
+ CLK_MSR_ID(33, "eth_clk_rmii"),
+ CLK_MSR_ID(34, "co_clkin_to_mac"),
+ CLK_MSR_ID(35, "mod_eth_rx_clk_rmii"),
+ CLK_MSR_ID(36, "co_rx"),
+ CLK_MSR_ID(37, "co_tx"),
+ CLK_MSR_ID(38, "eth_phy_rxclk"),
+ CLK_MSR_ID(39, "eth_phy_plltxclk"),
+ CLK_MSR_ID(40, "ephy_test"),
+ CLK_MSR_ID(41, "dsi_b_meas"),
+ CLK_MSR_ID(42, "hdmirx_apl"),
+ CLK_MSR_ID(43, "hdmirx_tmds"),
+ CLK_MSR_ID(44, "hdmirx_cable"),
+ CLK_MSR_ID(45, "hdmirx_apll_clk_audio"),
+ CLK_MSR_ID(46, "hdmirx_5m"),
+ CLK_MSR_ID(47, "hdmirx_2m"),
+ CLK_MSR_ID(48, "hdmirx_cfg"),
+ CLK_MSR_ID(49, "hdmirx_hdcp2x_eclk"),
+ CLK_MSR_ID(50, "vid_pll0_div"),
+ CLK_MSR_ID(51, "hdmi_vid_pll"),
+ CLK_MSR_ID(54, "vdac_clk"),
+ CLK_MSR_ID(55, "vpu_clk_buf"),
+ CLK_MSR_ID(56, "mod_tcon_clko"),
+ CLK_MSR_ID(57, "lcd_an_clk_ph2"),
+ CLK_MSR_ID(58, "lcd_an_clk_ph3"),
+ CLK_MSR_ID(59, "hdmi_tx_pixel"),
+ CLK_MSR_ID(60, "vdin_meas"),
+ CLK_MSR_ID(61, "vpu_clk"),
+ CLK_MSR_ID(62, "vpu_clkb"),
+ CLK_MSR_ID(63, "vpu_clkb_tmp"),
+ CLK_MSR_ID(64, "vpu_clkc"),
+ CLK_MSR_ID(65, "vid_lock"),
+ CLK_MSR_ID(66, "vapbclk"),
+ CLK_MSR_ID(67, "ge2d"),
+ CLK_MSR_ID(68, "aud_pll"),
+ CLK_MSR_ID(69, "aud_sck"),
+ CLK_MSR_ID(70, "dsi_a_meas"),
+ CLK_MSR_ID(72, "mipi_csi_phy"),
+ CLK_MSR_ID(73, "mipi_isp"),
+ CLK_MSR_ID(76, "hdmitx_tmds"),
+ CLK_MSR_ID(77, "hdmitx_sys"),
+ CLK_MSR_ID(78, "hdmitx_fe"),
+ CLK_MSR_ID(80, "hdmitx_prif"),
+ CLK_MSR_ID(81, "hdmitx_200m"),
+ CLK_MSR_ID(82, "hdmitx_aud"),
+ CLK_MSR_ID(83, "hdmitx_pnx"),
+ CLK_MSR_ID(84, "spicc5"),
+ CLK_MSR_ID(85, "spicc4"),
+ CLK_MSR_ID(86, "spicc3"),
+ CLK_MSR_ID(87, "spicc2"),
+ CLK_MSR_ID(93, "vdec"),
+ CLK_MSR_ID(94, "wave521_aclk"),
+ CLK_MSR_ID(95, "wave521_cclk"),
+ CLK_MSR_ID(96, "wave521_bclk"),
+ CLK_MSR_ID(97, "hcodec"),
+ CLK_MSR_ID(98, "hevcb"),
+ CLK_MSR_ID(99, "hevcf"),
+ CLK_MSR_ID(100, "hdmi_aud_pll"),
+ CLK_MSR_ID(101, "hdmi_acr_ref"),
+ CLK_MSR_ID(102, "hdmi_meter"),
+ CLK_MSR_ID(103, "hdmi_vid"),
+ CLK_MSR_ID(104, "hdmi_aud"),
+ CLK_MSR_ID(105, "hdmi_dsd"),
+ CLK_MSR_ID(108, "dsi1_phy"),
+ CLK_MSR_ID(109, "dsi0_phy"),
+ CLK_MSR_ID(110, "smartcard"),
+ CLK_MSR_ID(111, "sar_adc"),
+ CLK_MSR_ID(113, "sd_emmc_c"),
+ CLK_MSR_ID(114, "sd_emmc_b"),
+ CLK_MSR_ID(115, "sd_emmc_a"),
+ CLK_MSR_ID(116, "gpio_msr"),
+ CLK_MSR_ID(117, "spicc1"),
+ CLK_MSR_ID(118, "spicc0"),
+ CLK_MSR_ID(119, "anakin"),
+ CLK_MSR_ID(121, "ts_clk(temp sensor)"),
+ CLK_MSR_ID(122, "ts_a73"),
+ CLK_MSR_ID(123, "ts_a53"),
+ CLK_MSR_ID(124, "ts_nna"),
+ CLK_MSR_ID(130, "audio_vad"),
+ CLK_MSR_ID(131, "acodec_dac_clk_x128"),
+ CLK_MSR_ID(132, "audio_locker_in"),
+ CLK_MSR_ID(133, "audio_locker_out"),
+ CLK_MSR_ID(134, "audio_tdmout_c_sclk"),
+ CLK_MSR_ID(135, "audio_tdmout_b_sclk"),
+ CLK_MSR_ID(136, "audio_tdmout_a_sclk"),
+ CLK_MSR_ID(137, "audio_tdmin_lb_sclk"),
+ CLK_MSR_ID(138, "audio_tdmin_c_sclk"),
+ CLK_MSR_ID(139, "audio_tdmin_b_sclk"),
+ CLK_MSR_ID(140, "audio_tdmin_a_sclk"),
+ CLK_MSR_ID(141, "audio_resamplea"),
+ CLK_MSR_ID(142, "audio_pdm_sysclk"),
+ CLK_MSR_ID(143, "audio_spdifoutb_mst"),
+ CLK_MSR_ID(144, "audio_spdifout_mst"),
+ CLK_MSR_ID(145, "audio_spdifin_mst"),
+ CLK_MSR_ID(146, "audio_pdm_dclk"),
+ CLK_MSR_ID(147, "audio_resampleb"),
+ CLK_MSR_ID(148, "earcrx_pll_dmac"),
+ CLK_MSR_ID(156, "pwm_ao_h"),
+ CLK_MSR_ID(157, "pwm_ao_g"),
+ CLK_MSR_ID(158, "pwm_ao_f"),
+ CLK_MSR_ID(159, "pwm_ao_e"),
+ CLK_MSR_ID(160, "pwm_ao_d"),
+ CLK_MSR_ID(161, "pwm_ao_c"),
+ CLK_MSR_ID(162, "pwm_ao_b"),
+ CLK_MSR_ID(163, "pwm_ao_a"),
+ CLK_MSR_ID(164, "pwm_f"),
+ CLK_MSR_ID(165, "pwm_e"),
+ CLK_MSR_ID(166, "pwm_d"),
+ CLK_MSR_ID(167, "pwm_c"),
+ CLK_MSR_ID(168, "pwm_b"),
+ CLK_MSR_ID(169, "pwm_a"),
+ CLK_MSR_ID(170, "aclkm"),
+ CLK_MSR_ID(171, "mclk_pll"),
+ CLK_MSR_ID(172, "a73_sys_pll_div16"),
+ CLK_MSR_ID(173, "a73_cpu_clk_div16"),
+ CLK_MSR_ID(176, "rng_ring_0"),
+ CLK_MSR_ID(177, "rng_ring_1"),
+ CLK_MSR_ID(178, "rng_ring_2"),
+ CLK_MSR_ID(179, "rng_ring_3"),
+ CLK_MSR_ID(180, "am_ring_out0"),
+ CLK_MSR_ID(181, "am_ring_out1"),
+ CLK_MSR_ID(182, "am_ring_out2"),
+ CLK_MSR_ID(183, "am_ring_out3"),
+ CLK_MSR_ID(184, "am_ring_out4"),
+ CLK_MSR_ID(185, "am_ring_out5"),
+ CLK_MSR_ID(186, "am_ring_out6"),
+ CLK_MSR_ID(187, "am_ring_out7"),
+ CLK_MSR_ID(188, "am_ring_out8"),
+ CLK_MSR_ID(189, "am_ring_out9"),
+ CLK_MSR_ID(190, "am_ring_out10"),
+ CLK_MSR_ID(191, "am_ring_out11"),
+ CLK_MSR_ID(192, "am_ring_out12"),
+ CLK_MSR_ID(193, "am_ring_out13"),
+ CLK_MSR_ID(194, "am_ring_out14"),
+ CLK_MSR_ID(195, "am_ring_out15"),
+ CLK_MSR_ID(196, "am_ring_out16"),
+ CLK_MSR_ID(197, "am_ring_out17"),
+ CLK_MSR_ID(198, "am_ring_out18"),
+ CLK_MSR_ID(199, "am_ring_out19"),
+ CLK_MSR_ID(200, "mipi_csi_phy0"),
+ CLK_MSR_ID(201, "mipi_csi_phy1"),
+ CLK_MSR_ID(202, "mipi_csi_phy2"),
+ CLK_MSR_ID(203, "mipi_csi_phy3"),
+ CLK_MSR_ID(204, "vid_pll1_div"),
+ CLK_MSR_ID(205, "vid_pll2_div"),
+ CLK_MSR_ID(206, "am_ring_out20"),
+ CLK_MSR_ID(207, "am_ring_out21"),
+ CLK_MSR_ID(208, "am_ring_out22"),
+ CLK_MSR_ID(209, "am_ring_out23"),
+ CLK_MSR_ID(210, "am_ring_out24"),
+ CLK_MSR_ID(211, "am_ring_out25"),
+ CLK_MSR_ID(212, "am_ring_out26"),
+ CLK_MSR_ID(213, "am_ring_out27"),
+ CLK_MSR_ID(214, "am_ring_out28"),
+ CLK_MSR_ID(215, "am_ring_out29"),
+ CLK_MSR_ID(216, "am_ring_out30"),
+ CLK_MSR_ID(217, "am_ring_out31"),
+ CLK_MSR_ID(218, "am_ring_out32"),
+ CLK_MSR_ID(219, "enc0_if"),
+ CLK_MSR_ID(220, "enc2"),
+ CLK_MSR_ID(221, "enc1"),
+ CLK_MSR_ID(222, "enc0")
+};
+
static int meson_measure_id(struct meson_msr_id *clk_msr_id,
unsigned int duration)
{
@@ -1026,6 +1278,18 @@ static const struct meson_msr_data clk_msr_s4_data = {
.reg = &msr_reg_offset_v2,
};
+static const struct meson_msr_data clk_msr_a1_data = {
+ .msr_table = (void *)clk_msr_a1,
+ .msr_count = ARRAY_SIZE(clk_msr_a1),
+ .reg = &msr_reg_offset_v2,
+};
+
+static const struct meson_msr_data clk_msr_t7_data = {
+ .msr_table = (void *)clk_msr_t7,
+ .msr_count = ARRAY_SIZE(clk_msr_t7),
+ .reg = &msr_reg_offset_v2,
+};
+
static const struct of_device_id meson_msr_match_table[] = {
{
.compatible = "amlogic,meson-gx-clk-measure",
@@ -1059,6 +1323,14 @@ static const struct of_device_id meson_msr_match_table[] = {
.compatible = "amlogic,s4-clk-measure",
.data = &clk_msr_s4_data,
},
+ {
+ .compatible = "amlogic,a1-clk-measure",
+ .data = &clk_msr_a1_data,
+ },
+ {
+ .compatible = "amlogic,t7-clk-measure",
+ .data = &clk_msr_t7_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, meson_msr_match_table);
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v3 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Neil Armstrong @ 2026-04-21 8:20 UTC (permalink / raw)
To: jian.hu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260421-clkmsr_a1_t7-v3-4-efc00b0f9e6b@amlogic.com>
On 4/21/26 10:17, Jian Hu via B4 Relay wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add the clock measure device to the T7 SoC family.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 7fe72c94ed62..6a22b48a42b7 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -656,6 +656,11 @@ pwm_ao_gh: pwm@32000 {
> status = "disabled";
> };
>
> + clock-measurer@48000 {
> + compatible = "amlogic,t7-clk-measure";
> + reg = <0x0 0x48000 0x0 0x1c>;
> + };
> +
> pwm_ab: pwm@58000 {
> compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> reg = <0x0 0x58000 0x0 0x24>;
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v3 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION.
From: Jens Remus @ 2026-04-21 8:33 UTC (permalink / raw)
To: Dylan Hatch
Cc: Indu Bhagat, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina, Mark Rutland, Prasanna Kumar T S M,
Puranjay Mohan, Song Liu, joe.lawrence, linux-toolchains,
linux-kernel, live-patching, linux-arm-kernel, Heiko Carstens
In-Reply-To: <CADBMgpzBvKTvRKHmLbEF301S_DnCg6SRETkMh6jPo-1hOEEZVw@mail.gmail.com>
On 4/21/2026 3:29 AM, Dylan Hatch wrote:
> On Mon, Apr 20, 2026 at 5:31 AM Jens Remus <jremus@linux.ibm.com> wrote:
>>
>> On 4/20/2026 7:02 AM, Dylan Hatch wrote:
>>> On Thu, Apr 16, 2026 at 8:04 AM Jens Remus <jremus@linux.ibm.com> wrote:
>>>> On 4/6/2026 8:49 PM, Dylan Hatch wrote:
>>
>>>>> Generalize the __safe* helpers to support a non-user-access code path.
>>>>> Allow for kernel FDE read failures due to the presence of .rodata.text.
>>>>> This section contains code that can't be executed by the kernel
>>>>> direclty, and thus lies ouside the normal kernel-text bounds.
>>>>
>>>> Nits: s/direclty/directly/ s/ouside/outside/
>>>>
>>>> Could you please explain the issue? How/why does .sframe for
>>>> .rodata.text pose an issue for .sframe verification?
>>>
>>> __read_fde checks that the fde_addr it extracts is within the bounds
>>> of sec->text_start and sec->text_end. In the case of the vmlinux
>>
>> Looking at the existing check in __read_fde(), do you agree that it is
>> wrong, as sec->text_end IIUC points behind .text and thus the check
>> should be:
>>
>> if (func_addr < sec->text_start || func_addr >= sec->text_end)
>> return -EINVAL;
>
> I agree this is correct. Is this a fix that would be folded into your
> previous patch series?
Yes. I would send a new version once we have clarified how to move
forward in general.
>>> Alternatively, we can check for FDEs located
>>> in .rodata.text during validation, but this seems to only be present
>>> in arm64, so maybe we would need an arch-specific hook to do this? I'm
>>> open to suggestions.
>>
>> Maybe that is better than ignoring __read_fde() failures? I first
>> thought this would get nasty, but maybe it would not be too bad.
>> Following is what I came up with (note tabs replaced by spaces due to
>> copy&paste from terminal):
>> diff --git a/include/linux/sframe.h b/include/linux/sframe.h
>> @@ -63,6 +63,10 @@ struct sframe_section {
>> unsigned long sframe_end;
>> unsigned long text_start;
>> unsigned long text_end;
>> +#if defined(CONFIG_SFRAME_UNWINDER) && defined(CONFIG_ARM64)
>> + unsigned long rodatatext_start;
>> + unsigned long rodatatext_end;
>> +#endif
>
> It looks to me like .rodata.text only exists for vmlinux. I wonder if
> in sframe_func_start_addr_valid we can just use the global
> _srodatatext and _erodatatext after identifying if an sframe_section
> corresponds to vmlinux (kernel_sfsec)? That way we don't need to add
> these extra fields.
Sure. I don't have and preferences.
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v5 01/12] coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()
From: Suzuki K Poulose @ 2026-04-21 8:47 UTC (permalink / raw)
To: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel
Cc: mike.leach, james.clark, alexander.shishkin, leo.yan, jie.gan
In-Reply-To: <20260415165528.3369607-2-yeoreum.yun@arm.com>
On 15/04/2026 17:55, Yeoreum Yun wrote:
> According to Embedded Trace Macrocell Architecture Specification
> ETMv4.0 to ETM4.6 [0], TRCSSPCICR<n> is present only if all of
> the following are true:
>
> - TRCIDR4.NUMSSCC > n.
> - TRCIDR4.NUMPC > 0b0000.
> - TRCSSCSR<n>.PC == 0b1.
>
> Comment for etm4x_sspcicrn_present() is align with the specification.
> However, the check should use drvdata->nr_pe_cmp to check TRCIDR4.NUMPC
> not nr_pe.
>
> Link: https://developer.arm.com/documentation/ihi0064/latest/ [0]
Fixes: f6a18f354c58 ("coresight: etm4x: Handle access to TRCSSPCICRn")
With that looks good to me
Suzuki
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index d565a73f0042..74b7063d130e 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -89,7 +89,7 @@ static int etm4_probe_cpu(unsigned int cpu);
> static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n)
> {
> return (n < drvdata->nr_ss_cmp) &&
> - drvdata->nr_pe &&
> + drvdata->nr_pe_cmp &&
> (drvdata->config.ss_status[n] & TRCSSCSRn_PC);
> }
>
^ permalink raw reply
* Re: [PATCH v5 02/12] coresight: etm4x: fix underflow for nrseqstate
From: Suzuki K Poulose @ 2026-04-21 8:50 UTC (permalink / raw)
To: Leo Yan, Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, mike.leach,
james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260416151102.GL356832@e132581.arm.com>
On 16/04/2026 16:11, Leo Yan wrote:
> On Wed, Apr 15, 2026 at 05:55:18PM +0100, Yeoreum Yun wrote:
>> TCRSEQEVR<n> is implemented only when TCRIDR5.NUMSEQSTATE is 0b100,
>> in which case n ranges from 0 to 2; otherwise, TCRIDR5.NUMSEQSTATE is 0b000.
>
> My suggestion in previous version is not quite right, thanks for
> making this correct.
>
> [...]
>
>> @@ -1395,6 +1395,8 @@ static ssize_t seq_idx_store(struct device *dev,
>> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> struct etmv4_config *config = &drvdata->config;
>>
>> + if (!drvdata->nrseqstate)
>> + return -EINVAL;
>
> For "nrseqstate = 0" case, would it return -EOPNOTSUPP instead?
Or should we make this only visible if the nrseqstore is meaningful ?
Suzuki
>
> Otherwise, LGTM:
>
> Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH v5 02/12] coresight: etm4x: fix underflow for nrseqstate
From: Suzuki K Poulose @ 2026-04-21 8:50 UTC (permalink / raw)
To: Leo Yan, Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, mike.leach,
james.clark, alexander.shishkin, jie.gan
In-Reply-To: <fdfd353d-f198-4806-81d2-61f26b678dea@arm.com>
On 21/04/2026 09:50, Suzuki K Poulose wrote:
> On 16/04/2026 16:11, Leo Yan wrote:
>> On Wed, Apr 15, 2026 at 05:55:18PM +0100, Yeoreum Yun wrote:
>>> TCRSEQEVR<n> is implemented only when TCRIDR5.NUMSEQSTATE is 0b100,
>>> in which case n ranges from 0 to 2; otherwise, TCRIDR5.NUMSEQSTATE is
>>> 0b000.
>>
>> My suggestion in previous version is not quite right, thanks for
>> making this correct.
>>
>> [...]
>>
>>> @@ -1395,6 +1395,8 @@ static ssize_t seq_idx_store(struct device *dev,
>>> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> struct etmv4_config *config = &drvdata->config;
>>> + if (!drvdata->nrseqstate)
>>> + return -EINVAL;
>>
>> For "nrseqstate = 0" case, would it return -EOPNOTSUPP instead?
>
> Or should we make this only visible if the nrseqstore is meaningful ?
>
> Suzuki
>
>>
>> Otherwise, LGTM:
>>
>> Reviewed-by: Leo Yan <leo.yan@arm.com>
>
Also, please add Fixes: tag for these bug fixes
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Sudeep Holla @ 2026-04-21 8:51 UTC (permalink / raw)
To: Yeoreum Yun
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <aecf57rWloQwDh6v@e129823.arm.com>
On Tue, Apr 21, 2026 at 07:57:43AM +0100, Yeoreum Yun wrote:
[...]
>
> Also, the FF-A initialization is not driven by a device probe, but rather
> happens as part of the bus registration itself,
> so it does not fit well with a device_link or probe deferral based approach.
>
> Instead, perhaps we could go with the idea I mentioned previously:
> either introduce a notifier, or create a pseudo ffa_device
> once pKVM initialization has completed, and
> then let the ffa driver perform the additional initialization from there.
>
> Am I missing something?
>
In order to handle/cleanup some ugliness in interrupt management in the
FF-A driver, we may introduce DT node eventually. But it will take sometime.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: Lorenzo Bianconi @ 2026-04-21 8:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Do not wake every netdev TX queue across all ports sharing the QDMA
running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs()
but only the ones that are mapped the specific QDMA stopped hw TX queue.
This patch can potentially avoid waking already stopped netdev TX queues
that are mapped to a different QDMA hw TX queue.
Introduce airoha_qdma_get_txq utility routine.
Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 19 +++++++++++++++----
drivers/net/ethernet/airoha/airoha_eth.h | 5 +++++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 19f67c7dd8e1..2ca569501045 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -847,13 +847,24 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
{
struct airoha_qdma *qdma = q->qdma;
struct airoha_eth *eth = qdma->eth;
- int i;
+ int i, qid = q - &qdma->q_tx[0];
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
+ int j;
+
+ if (!port)
+ continue;
- if (port && port->qdma == qdma)
- netif_tx_wake_all_queues(port->dev);
+ if (port->qdma != qdma)
+ continue;
+
+ for (j = 0; j < port->dev->num_tx_queues; j++) {
+ if (airoha_qdma_get_txq(qdma, j) != qid)
+ continue;
+
+ netif_wake_subqueue(port->dev, j);
+ }
}
q->txq_stopped = false;
}
@@ -1965,7 +1976,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
u16 index;
u8 fport;
- qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx);
+ qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
tag = airoha_get_dsa_tag(skb, dev);
msg0 = FIELD_PREP(QDMA_ETH_TXMSG_CHAN_MASK,
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 87b328cfefb0..c3ea7aadbd82 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -631,6 +631,11 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
#define airoha_qdma_clear(qdma, offset, val) \
airoha_rmw((qdma)->regs, (offset), (val), 0)
+static inline u16 airoha_qdma_get_txq(struct airoha_qdma *qdma, u16 qid)
+{
+ return qid % ARRAY_SIZE(qdma->q_tx);
+}
+
static inline bool airoha_is_lan_gdm_port(struct airoha_gdm_port *port)
{
/* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
---
base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
change-id: 20260421-airoha-wake_netdev_txqs-optmization-65171ce4ebad
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH V3] dmaengine: imx-sdma: Fix SPBA bus detection on multi-SPBA platforms
From: Marco Felsch @ 2026-04-21 8:53 UTC (permalink / raw)
To: Shengjiu Wang
Cc: vkoul, Frank.Li, s.hauer, kernel, festevam, dmaengine, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260420100854.2095549-1-shengjiu.wang@nxp.com>
On 26-04-20, Shengjiu Wang wrote:
> i.MX8M platforms have multiple SPBA buses under different AIPS buses.
> The current code searches the entire device tree and returns the first
> SPBA bus found, which may not be under the same AIPS bus as the SDMA
> controller.
>
> This breaks SDMA P2P transfers because the SDMA script needs to know
> if peripherals are on SPBA or AIPS to configure watermark levels
> correctly. Using the wrong SPBA bus causes DMA timeouts and transfer
> failures.
>
> Fix by searching for the SPBA bus under the SDMA's parent node (AIPS)
> first, then falling back to a global search for backward compatibility.
>
> Example device tree showing the issue:
> aips1 {
> spba1 { sai@...; }; /* Correct SPBA for sdma1 */
> sdma1@...;
> };
> aips2 {
> spba2 { uart@...; }; /* Wrong SPBA - found first by old code */
> };
>
> Fixes: 8391ecf465ec ("dmaengine: imx-sdma: Add device to device support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> changs in v3:
> - add fallback to a global search for backward compatibility, which is
> to address comments from sashiko.dev
> - update commit subject and commit message
> - add comments in code.
> - add Cc stable tag
> - Don't add Frank's RB on v2 as there are several other changes.
>
> changes in v2:
> - add fixes tag
> - use __free(device_node) for auto release.
>
> drivers/dma/imx-sdma.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 3d527883776b..592705af2319 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -2364,7 +2364,18 @@ static int sdma_probe(struct platform_device *pdev)
> return dev_err_probe(&pdev->dev, ret,
> "failed to register controller\n");
>
> - spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
> + /*
> + * On i.MX8M platforms with multiple SPBA buses, we need to find
> + * the SPBA bus that's under the same AIPS bus as this SDMA controller.
> + * First check the SDMA's parent (AIPS bus) for a child SPBA bus.
> + * If not found, fall back to searching the entire device tree for
> + * backward compatibility with older platforms.
> + */
> + struct device_node *sdma_parent_np __free(device_node) = of_get_parent(np);
> +
> + spba_bus = of_get_compatible_child(sdma_parent_np, "fsl,spba-bus");
> + if (!spba_bus)
> + spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
And yet the search is still broken for i.MX8MP case since this platform
has two sdma engines below the bus@30df0000.
Regards,
Marco
> ret = of_address_to_resource(spba_bus, 0, &spba_res);
> if (!ret) {
> sdma->spba_start_addr = spba_res.start;
> --
> 2.34.1
>
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* Re: [PATCH v3 6/8] ARM: zte: Bring back zx29 UART support
From: Linus Walleij @ 2026-04-21 8:55 UTC (permalink / raw)
To: Stefan Dösinger
Cc: linux-arm-kernel, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <5075672.GXAFRqVoOG@strix>
On Mon, Apr 20, 2026 at 11:22 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> > Interesting with the AMBA pseudo-ID, but I kind of like the idea.
>
> It wasn't my idea. That's - as the description says - the code that was once
> upstream before it got removed in 89d4f98ae90d. This is also why the
> ZX_UART011_* defines still exist.
Aha!
> I re-checked if the device identifies itself in the mmio area in any way, and
> that I maybe got the size wrong - but that was not the case, everything past
> the ZX_UART011_* registers is zero until the next device starts.
Yeah it's common that vendors just forget about this and set it all
to zero.
> Another idea I considered is using ZTE's 0x8c (assuming that "Microelectronics
> Institute ZTE" is the same ZTE that made the board), but then I would have to
> invent a device number, ideally without clashing with an existing ZTE device.
I think that's a great idea! At least that is what was supposed to be done,
maybe the ZTE HW engineers will get the message one day.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 04/12] coresight: etm4x: exclude ss_status from drvdata->config
From: Suzuki K Poulose @ 2026-04-21 8:57 UTC (permalink / raw)
To: Leo Yan, Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, mike.leach,
james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260416155118.GM356832@e132581.arm.com>
On 16/04/2026 16:51, Leo Yan wrote:
> On Wed, Apr 15, 2026 at 05:55:20PM +0100, Yeoreum Yun wrote:
>
> [...]
>
>> @@ -573,11 +573,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
>> etm4x_relaxed_write32(csa, config->res_ctrl[i], TRCRSCTLRn(i));
>>
>> for (i = 0; i < caps->nr_ss_cmp; i++) {
>> - /* always clear status bit on restart if using single-shot */
>> - if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
>> - config->ss_status[i] &= ~TRCSSCSRn_STATUS;
>> etm4x_relaxed_write32(csa, config->ss_ctrl[i], TRCSSCCRn(i));
>> - etm4x_relaxed_write32(csa, config->ss_status[i], TRCSSCSRn(i));
>> + /* always clear status and pending bits on restart if using single-shot */
>> + etm4x_relaxed_write32(csa, 0x0, TRCSSCSRn(i));
>
> In Arm ARM, D24.4.60 TRCSSCSR<n>, bits[0..3] are RO. I think it is
> fine for directly clear the regiser with zero (means it will only
> clear status / pending bits).
>
> [...]
>
>> @@ -1841,10 +1839,11 @@ static ssize_t sshot_status_show(struct device *dev,
>> {
>> unsigned long val;
>> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> + const struct etmv4_caps *caps = &drvdata->caps;
>> struct etmv4_config *config = &drvdata->config;
>>
>> raw_spin_lock(&drvdata->spinlock);
>> - val = config->ss_status[config->ss_idx];
>> + val = caps->ss_cmp[config->ss_idx];
>> raw_spin_unlock(&drvdata->spinlock);
>> return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> }
>
> This sysfs knob never can print out a realtime status for sshot, I am
Won't it give the status, when the ETM was disabled (and saved back to
config), for as sysfs mode operation, where the user collects
information about the status via sysfs ? ( The question of if someone
actually makes use of this is a different question )
Cheers
Suzuki
> fine for only printing caps->ss_cmp, this can avoid any misleading.
>
> @Suzuki, @Mike, do you agree with the change above?
>
> If maintainers agree with this, as Jie suggested, it is good to add a
> comment in the code and update the document:
>
> Documentation/trace/coresight/coresight-etm4x-reference.rst
>
> Thanks,
> Leo
^ permalink raw reply
* Re: [PATCH v25 0/7] firmware: imx: driver for NXP secure-enclave
From: Frank Li @ 2026-04-21 8:57 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Pankaj Gupta, Jonathan Corbet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <e5989438-c063-4395-919c-2beaf8e937c8@kontron.de>
On Tue, Apr 21, 2026 at 09:52:13AM +0200, Frieder Schrempf wrote:
> 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?
Thank you test this. I just took over imx ownship from shawn. I need get
famillar with work flow and get dts part merge smoothly.
I will try to send this as independent pull request at earily of v7.1
Frank
>
> Thanks!
^ 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 9:03 UTC (permalink / raw)
To: david, dev.jain
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: <94fdc376-9c43-4334-b293-20a54acbdc3a@kernel.org>
On Tue, Apr 21, 2026 at 10:06:54AM +0200, David Hildenbrand (Arm) wrote:
>On 4/21/26 09:06, Dev Jain wrote:
>>
>>
>> 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?
>
>Right, we have to clear tags here even without kasan. God, what an ugly
>mess people created here with these GFP flags.
Yeah, with kasan=off, kasan_init_hw_tags() returns early, so
kasan_hw_tags_enabled() stays false and tag_clear_highpages() is still
skipped.
With the small debug change below, it still reproduces reliably:
---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);
---
Cheers,
Lance
^ permalink raw reply related
* RE: tpm: spi: do not call blocking ops when !TASK_RUNNING; during shutdown
From: Peng Fan @ 2026-04-21 9:04 UTC (permalink / raw)
To: Stefan Wahren, Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe
Cc: linux-arm-kernel@lists.infradead.org,
linux-integrity@vger.kernel.org, kernel@pengutronix.de, Frank Li,
Sascha Hauer, imx@lists.linux.dev
In-Reply-To: <e7974d35-0d50-4742-8747-822f28915e00@gmx.net>
> Subject: tpm: spi: do not call blocking ops when !TASK_RUNNING;
> during shutdown
>
> Hi,
> we use a custom i.MX93 board, which based on Phytec Phycore i.MX93
> with a TPM connected via SPI. If I enable
> CONFIG_DEBUG_ATOMIC_SLEEP=y in our kernel config with mainline
> kernel 6.18.23 and reboot our board, I will get the following warning:
> ffff0000000d8000
The issue seems at drivers/char/tpm/tpm_tis_core.c
94 rc = wait_event_interruptible_timeout(*queue,
95 wait_for_tpm_stat_cond(chip, sts_mask, check_cancel,
96 &canceled),
97 timeout);
wait_event_interruptible_timeout set task to !TASK_RUNNING,
but wait_for_tpm_stat_cond still calls into mutex_lock.
Regards
Peng
> [ 43.422135] Call trace:
> [ 43.424570] __might_sleep+0x74/0x7c (P)
> [ 43.428487] mutex_lock+0x24/0x80
> [ 43.431797] spi_bus_lock+0x20/0x50
> [ 43.435281] tpm_tis_spi_transfer_full+0x70/0x2c4
> [ 43.439979] tpm_tis_spi_read_bytes+0x3c/0x48
> [ 43.444321] tpm_tis_status+0x58/0xf8
> [ 43.447978] wait_for_tpm_stat_cond+0x30/0x90
> [ 43.452329] wait_for_tpm_stat+0x1cc/0x2e0
> [ 43.456419] tpm_tis_send_data+0xdc/0x334
> [ 43.460423] tpm_tis_send_main+0x74/0x160
> [ 43.464427] tpm_tis_send+0xd4/0x13c
> [ 43.467998] tpm_transmit+0xc4/0x3c4
> [ 43.471569] tpm_transmit_cmd+0x38/0xd4
> [ 43.475399] tpm2_shutdown+0x6c/0xa4
> [ 43.478970] tpm_class_shutdown+0x60/0x88
> [ 43.482974] device_shutdown+0x130/0x25c
> [ 43.486891] kernel_restart+0x44/0xa4
> [ 43.490549] __do_sys_reboot+0x114/0x254
> [ 43.494466] __arm64_sys_reboot+0x24/0x30
> [ 43.498470] invoke_syscall+0x48/0x10c
> [ 43.502214] el0_svc_common.constprop.0+0x40/0xe0
> [ 43.506911] do_el0_svc+0x1c/0x28
> [ 43.510222] el0_svc+0x34/0xec
> [ 43.513273] el0t_64_sync_handler+0xa0/0xe4
> [ 43.517441] el0t_64_sync+0x198/0x19c
>
> Best regards
^ permalink raw reply
* Re: [PATCH v5 04/12] coresight: etm4x: exclude ss_status from drvdata->config
From: Yeoreum Yun @ 2026-04-21 9:06 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Leo Yan, coresight, linux-arm-kernel, linux-kernel, mike.leach,
james.clark, alexander.shishkin, jie.gan
In-Reply-To: <57dbea1b-670b-4b8f-a590-1d4239bc2c76@arm.com>
Hi Suzuki,
> On 16/04/2026 16:51, Leo Yan wrote:
> > On Wed, Apr 15, 2026 at 05:55:20PM +0100, Yeoreum Yun wrote:
> >
> > [...]
> >
> > > @@ -573,11 +573,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> > > etm4x_relaxed_write32(csa, config->res_ctrl[i], TRCRSCTLRn(i));
> > > for (i = 0; i < caps->nr_ss_cmp; i++) {
> > > - /* always clear status bit on restart if using single-shot */
> > > - if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
> > > - config->ss_status[i] &= ~TRCSSCSRn_STATUS;
> > > etm4x_relaxed_write32(csa, config->ss_ctrl[i], TRCSSCCRn(i));
> > > - etm4x_relaxed_write32(csa, config->ss_status[i], TRCSSCSRn(i));
> > > + /* always clear status and pending bits on restart if using single-shot */
> > > + etm4x_relaxed_write32(csa, 0x0, TRCSSCSRn(i));
> >
> > In Arm ARM, D24.4.60 TRCSSCSR<n>, bits[0..3] are RO. I think it is
> > fine for directly clear the regiser with zero (means it will only
> > clear status / pending bits).
> >
> > [...]
> >
> > > @@ -1841,10 +1839,11 @@ static ssize_t sshot_status_show(struct device *dev,
> > > {
> > > unsigned long val;
> > > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > > + const struct etmv4_caps *caps = &drvdata->caps;
> > > struct etmv4_config *config = &drvdata->config;
> > > raw_spin_lock(&drvdata->spinlock);
> > > - val = config->ss_status[config->ss_idx];
> > > + val = caps->ss_cmp[config->ss_idx];
> > > raw_spin_unlock(&drvdata->spinlock);
> > > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > > }
> >
> > This sysfs knob never can print out a realtime status for sshot, I am
>
> Won't it give the status, when the ETM was disabled (and saved back to
> config), for as sysfs mode operation, where the user collects
> information about the status via sysfs ? ( The question of if someone
> actually makes use of this is a different question )
But I'm asking whether it's meaningful to give information
for PENDING and STATUS after "seesion" is disabled.
As you said, it gives a status after *disabled*.
However, Is this information meaningful and user can something with
these information? TBH I don't think so it would be better to remove
from config...
If this's required ... might be we need to move ss_status into
etm4_drvdata directly anyway.. (ss_status).
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v5 3/4] thermal: qoriq: workaround unexpected temperature readings from tmu
From: Frank Li @ 2026-04-21 9:11 UTC (permalink / raw)
To: Jacky Bai
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, linux-pm,
devicetree, imx, linux-arm-kernel
In-Reply-To: <20260421-imx93_tmu-v5-3-05ea1969bb9f@nxp.com>
On Tue, Apr 21, 2026 at 03:42:24PM +0800, Jacky Bai wrote:
> 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;
> + }
> + }
> +
The above two code blocks are the same. Use helper function to avoid
duplicat code. And why need check twice?
ret = qoriq_tmu_err052243()
if (ret)
return ret;
Frank
> 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
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-21 9:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <20260421-married-liberal-ammonite-dffda8@sudeepholla>
> On Tue, Apr 21, 2026 at 07:57:43AM +0100, Yeoreum Yun wrote:
>
> [...]
>
> >
> > Also, the FF-A initialization is not driven by a device probe, but rather
> > happens as part of the bus registration itself,
> > so it does not fit well with a device_link or probe deferral based approach.
> >
> > Instead, perhaps we could go with the idea I mentioned previously:
> > either introduce a notifier, or create a pseudo ffa_device
> > once pKVM initialization has completed, and
> > then let the ffa driver perform the additional initialization from there.
> >
> > Am I missing something?
> >
>
> In order to handle/cleanup some ugliness in interrupt management in the
> FF-A driver, we may introduce DT node eventually. But it will take sometime.
Unfortunately, I think this DT node wouldn't be helpful to solve
this situation for dependency with the kvm misc device...
IMHO, current situation, the notifier seems to good option. unless
we make the initcall to recongise this dependency.
--
Sincerely,
Yeoreum Yun
^ 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