* Re: [PATCH v2] clk: keystone: don't cache clock rate
From: Brian Masney @ 2026-06-03 16:49 UTC (permalink / raw)
To: Nishanth Menon
Cc: Stephen Boyd, a-christidis, Tero Kristo, Santosh Shilimkar,
Michael Turquette, linux-arm-kernel, linux-kernel, linux-clk,
Michael Walle, Kevin Hilman, Randolph Sapp
In-Reply-To: <20260603160034.fbemt5n6pqyrmwke@strode>
Hi Nishanth,
On Wed, Jun 03, 2026 at 11:00:34AM -0500, Nishanth Menon wrote:
> On 12:16-20260512, Nishanth Menon wrote:
> > On 10:51-20260512, Brian Masney wrote:
> > > > Could you clarify if I need to take it via my tree to arnd or if this
> > > > patch will go via the clk tree?
> > >
> > > Sorry, I'm not sure what Stephen prefers here. An argument could be made
> > > for either approach. I would just go with whatever you have done in the
> > > past.
> >
> > Thanks Brian for the review.
> >
> > This usually will go via Stephen. Will wait, just trying to make sure
> > there is no change in expectations (given this patch missed a window).
> >
>
> Stephen, I'd like to clarify: would you pick this patch up directly,
> or would like me to send you a PR after collecting sci_clk patches? I am
> OK with either, would prefer to not have wrong expectations.
>
> I see two patches pending to be queued:
> * this one
> * https://lore.kernel.org/linux-arm-kernel/20260512110028.2999471-1-nm@ti.com/
Since Stephen hasn't replied yet, I would just include it in your pull
to him to make sure it gets in.
If he has an issue, then it will be straight forward to make a v2 pull
without this patch.
Brian
^ permalink raw reply
* Re: [PATCH v5 11/14] dt-bindings: media: mediatek: vcodec: add decoder dt-bindings for mt8196
From: Conor Dooley @ 2026-06-03 16:14 UTC (permalink / raw)
To: Kyrie Wu
Cc: Tiffany Lin, Andrew-CT Chen, Yunfei Dong, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Nicolas Dufresne, Ricardo Ribalda,
Kees Cook, Hans Verkuil, Haoxiang Li, Fei Shao, Chen-Yu Tsai,
Laurent Pinchart, Sebastian Fricke, Benjamin Gaignard,
Philipp Zabel, Qianfeng Rong, Jacopo Mondi, Irui Wang, Fan Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Sakari Ailus, Tzung-Bi Shih, Tomasz Figa
In-Reply-To: <20260603084045.17488-12-kyrie.wu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
On Wed, Jun 03, 2026 at 04:40:41PM +0800, Kyrie Wu wrote:
> From: Yunfei Dong <yunfei.dong@mediatek.com>
>
> The MT8196 decoder differs from previous generations in several
> key aspects, most notably in its use of VCP instead of SCP.
> Additionally, the MT8196 enhances codec capabilities by supporting
> HEVC Main10 profile decoding. To accommodate these hardware changes,
> the binding constraints specify a total of 12 clock inputs,
> consisting of 9 decoder clocks and 3 VCP interface clocks,
> along with 2 power domains covering both the decoder and VCP
> subsystems.
I'm pretty pretty confused by this statement about constraints, since
there's none added?
The vcodec-dec node doesn't even seem to permit clocks at all?
>
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> ---
> .../bindings/media/mediatek,vcodec-subdev-decoder.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> index bf8082d87ac0..74e1d88d3056 100644
> --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> @@ -76,6 +76,7 @@ properties:
> - mediatek,mt8186-vcodec-dec
> - mediatek,mt8188-vcodec-dec
> - mediatek,mt8195-vcodec-dec
> + - mediatek,mt8196-vcodec-dec
>
> reg:
> minItems: 1
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 3/4] arm64: mte: Disregard the zero page explicitly for manipulating tags
From: Ard Biesheuvel @ 2026-06-03 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, maz, Ard Biesheuvel,
Kevin Brodsky, Mark Brown
In-Reply-To: <20260603160949.3372482-6-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
The zero page is conceptually immutable, and will be moved into .rodata
to prevent inadvertent corruption.
Prepare the MTE code for this, by ensuring that the zero page is never
taken into account for tag manipulation, given that those actions will
no longer be permitted on the read-only alias of .rodata in the linear
map.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/include/asm/mte.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index 7f7b97e09996..093b34944aee 100644
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@ -80,6 +80,11 @@ static inline bool page_mte_tagged(struct page *page)
*/
static inline bool try_page_mte_tagging(struct page *page)
{
+ extern struct page *__zero_page;
+
+ if (page == __zero_page)
+ return false;
+
VM_WARN_ON_ONCE(folio_test_hugetlb(page_folio(page)));
if (!test_and_set_bit(PG_mte_lock, &page->flags.f))
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply related
* [PATCH 4/4] arm64: mm: Defer remap of linear alias of data/bss
From: Ard Biesheuvel @ 2026-06-03 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, maz, Ard Biesheuvel,
Kevin Brodsky, Mark Brown
In-Reply-To: <20260603160949.3372482-6-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Marking the linear alias of data/bss invalid involves calling
set_memory_valid(), which calls split_kernel_leaf_mapping() under the
hood.
On BBML2_NOABORT capable systems, this may result in the need to
allocate page tables at a time when the generic memory allocation APIs
are not yet available, resulting in a splat like
WARNING: arch/arm64/mm/mmu.c:821 at split_kernel_leaf_mapping+0x15c/0x170, CPU#0: swapper/0
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.1.0-rc6 #1 PREEMPT(undef)
pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : split_kernel_leaf_mapping+0x15c/0x170
lr : update_range_prot+0x40/0x128
sp : ffffc99ad3863c80
...
Call trace:
split_kernel_leaf_mapping+0x15c/0x170 (P)
update_range_prot+0x40/0x128
set_memory_valid+0x94/0xe0
mark_linear_data_alias_valid+0x54/0x68
map_mem+0x1fc/0x240
paging_init+0x48/0x210
setup_arch+0x274/0x338
start_kernel+0x98/0x538
__primary_switched+0x88/0x98
as reported by CKI automated testing.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index d68e691c093a..3134f1c1097c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1095,6 +1095,9 @@ void __init mark_linear_text_alias_ro(void)
(unsigned long)__init_begin - (unsigned long)_text,
PAGE_KERNEL_RO);
+ /* Map the kernel data/bss as invalid in the linear map */
+ mark_linear_data_alias_valid(false);
+
/*
* Register a PM notifier to remap the linear alias of data/bss as
* valid read-only before hibernation. This is needed because the
@@ -1237,9 +1240,6 @@ static void __init map_mem(void)
__map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
-
- /* Map the kernel data/bss as invalid in the linear map */
- mark_linear_data_alias_valid(false);
}
void mark_rodata_ro(void)
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply related
* [PATCH 1/4] arm64: Move generic KASAN page tables out of BSS too
From: Ard Biesheuvel @ 2026-06-03 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, maz, Ard Biesheuvel,
Kevin Brodsky, Mark Brown
In-Reply-To: <20260603160949.3372482-6-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Make sure that all KASAN page tables are emitted into the .pgdir section
(provided that the arch has one - otherwise, fall back to page aligned
BSS)
This is needed because BSS itself is no longer accessible via the linear
map.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/include/asm/linkage.h | 2 ++
arch/arm64/include/asm/mmu.h | 2 --
arch/arm64/kernel/vmlinux.lds.S | 8 ++++----
arch/arm64/mm/fixmap.c | 6 +++---
arch/arm64/mm/kasan_init.c | 2 +-
include/linux/linkage.h | 4 ++++
mm/kasan/init.c | 10 +++++-----
7 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
index 40bd17add539..8637f667667c 100644
--- a/arch/arm64/include/asm/linkage.h
+++ b/arch/arm64/include/asm/linkage.h
@@ -43,4 +43,6 @@
SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_A_ALIGN) \
bti c ;
+#define __bss_pgtbl __section(".bss..pgtbl") __aligned(PAGE_SIZE)
+
#endif
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index fb95754f2876..5e1211c540ab 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -13,8 +13,6 @@
#ifndef __ASSEMBLER__
-#define __pgtbl_bss __section(".pgdir.bss") __aligned(PAGE_SIZE)
-
#include <linux/refcount.h>
#include <asm/cpufeature.h>
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 2b0ebfb30c63..d3ed59abab38 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -352,11 +352,11 @@ SECTIONS
BSS_SECTION(SBSS_ALIGN, 0, PAGE_SIZE)
__pi___bss_start = __bss_start;
- /* fixmap BSS starts here - preceding data/BSS is omitted from the linear map */
- .pgdir.bss (NOLOAD) : ALIGN(PAGE_SIZE) {
- *(.pgdir.bss)
+ /* page table BSS starts here - preceding data/BSS is omitted from the linear map */
+ .pgtbl : ALIGN(PAGE_SIZE) {
+ *(.bss..pgtbl)
}
- ASSERT(ADDR(.pgdir.bss) == __bss_stop, ".pgdir.bss must follow BSS")
+ ASSERT(ADDR(.pgtbl) == __bss_stop, ".pgtbl must follow BSS")
. = ALIGN(PAGE_SIZE);
__pi_init_pg_dir = .;
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index 1a3bbd67dd76..f66a0016dd02 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -31,9 +31,9 @@ static_assert(NR_BM_PMD_TABLES == 1);
#define BM_PTE_TABLE_IDX(addr) __BM_TABLE_IDX(addr, PMD_SHIFT)
-static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __pgtbl_bss;
-static pmd_t bm_pmd[PTRS_PER_PMD] __pgtbl_bss __maybe_unused;
-static pud_t bm_pud[PTRS_PER_PUD] __pgtbl_bss __maybe_unused;
+static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __bss_pgtbl;
+static pmd_t bm_pmd[PTRS_PER_PMD] __bss_pgtbl __maybe_unused;
+static pud_t bm_pud[PTRS_PER_PUD] __bss_pgtbl __maybe_unused;
static inline pte_t *fixmap_pte(unsigned long addr)
{
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index dbf22cae82ee..3fcad956fdf7 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -214,7 +214,7 @@ asmlinkage void __init kasan_early_init(void)
* shadow pud_t[]/p4d_t[], which could end up getting corrupted
* when the linear region is mapped.
*/
- static pte_t tbl[PTRS_PER_PTE] __pgtbl_bss;
+ static pte_t tbl[PTRS_PER_PTE] __bss_pgtbl;
pgd_t *pgdp = pgd_offset_k(KASAN_SHADOW_START);
set_pgd(pgdp, __pgd(__pa_symbol(tbl) | PGD_TYPE_TABLE));
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index b11660b706c5..53fe1f48fd28 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -39,6 +39,10 @@
#define __page_aligned_data __section(".data..page_aligned") __aligned(PAGE_SIZE)
#define __page_aligned_bss __section(".bss..page_aligned") __aligned(PAGE_SIZE)
+#ifndef __bss_pgtbl
+#define __bss_pgtbl __page_aligned_bss
+#endif
+
/*
* For assembly routines.
*
diff --git a/mm/kasan/init.c b/mm/kasan/init.c
index 9c880f607c6a..66a883887987 100644
--- a/mm/kasan/init.c
+++ b/mm/kasan/init.c
@@ -26,10 +26,10 @@
* - Latter it reused it as zero shadow to cover large ranges of memory
* that allowed to access, but not handled by kasan (vmalloc/vmemmap ...).
*/
-unsigned char kasan_early_shadow_page[PAGE_SIZE] __page_aligned_bss;
+unsigned char kasan_early_shadow_page[PAGE_SIZE] __bss_pgtbl;
#if CONFIG_PGTABLE_LEVELS > 4
-p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D] __page_aligned_bss;
+p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D] __bss_pgtbl;
static inline bool kasan_p4d_table(pgd_t pgd)
{
return pgd_page(pgd) == virt_to_page(lm_alias(kasan_early_shadow_p4d));
@@ -41,7 +41,7 @@ static inline bool kasan_p4d_table(pgd_t pgd)
}
#endif
#if CONFIG_PGTABLE_LEVELS > 3
-pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD] __page_aligned_bss;
+pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD] __bss_pgtbl;
static inline bool kasan_pud_table(p4d_t p4d)
{
return p4d_page(p4d) == virt_to_page(lm_alias(kasan_early_shadow_pud));
@@ -53,7 +53,7 @@ static inline bool kasan_pud_table(p4d_t p4d)
}
#endif
#if CONFIG_PGTABLE_LEVELS > 2
-pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD] __page_aligned_bss;
+pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD] __bss_pgtbl;
static inline bool kasan_pmd_table(pud_t pud)
{
return pud_page(pud) == virt_to_page(lm_alias(kasan_early_shadow_pmd));
@@ -65,7 +65,7 @@ static inline bool kasan_pmd_table(pud_t pud)
}
#endif
pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]
- __page_aligned_bss;
+ __bss_pgtbl;
static inline bool kasan_pte_table(pmd_t pmd)
{
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply related
* [PATCH 2/4] arm64: Avoid double evaluation of __ptep_get()
From: Ard Biesheuvel @ 2026-06-03 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, maz, Ard Biesheuvel,
Kevin Brodsky, Mark Brown
In-Reply-To: <20260603160949.3372482-6-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Sashiko warns that the new pte_valid_noncont() macro is used in a manner
where the argument (which performs a READ_ONCE() of the descriptor) is
evaluated twice.
Drop the macro that we just added, and move the check into the newly
added users.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/include/asm/pgtable.h | 4 ----
arch/arm64/mm/mmu.c | 14 ++++++++++----
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 491ba0a6492d..c9e4e00a9af2 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -181,10 +181,6 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
* Returns true if the pte is valid and has the contiguous bit set.
*/
#define pte_valid_cont(pte) (pte_valid(pte) && pte_cont(pte))
-/*
- * Returns true if the pte is valid and has the contiguous bit cleared.
- */
-#define pte_valid_noncont(pte) (pte_valid(pte) && !pte_cont(pte))
/*
* Could the pte be present in the TLB? We must check mm_tlb_flush_pending
* so that we don't erroneously return false for pages that have been
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index be51f6cac86f..d68e691c093a 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -186,9 +186,12 @@ static void init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
static bool pte_range_has_valid_noncont(pte_t *ptep)
{
- for (int i = 0; i < CONT_PTES; i++)
- if (pte_valid_noncont(__ptep_get(&ptep[i])))
+ for (int i = 0; i < CONT_PTES; i++) {
+ pte_t pte = __ptep_get(&ptep[i]);
+
+ if (pte_valid(pte) && !pte_cont(pte))
return true;
+ }
return false;
}
@@ -291,9 +294,12 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
static bool pmd_range_has_valid_noncont(pmd_t *pmdp)
{
- for (int i = 0; i < CONT_PMDS; i++)
- if (pte_valid_noncont(pmd_pte(READ_ONCE(pmdp[i]))))
+ for (int i = 0; i < CONT_PMDS; i++) {
+ pte_t pte = pmd_pte(READ_ONCE(pmdp[i]));
+
+ if (pte_valid(pte) && !pte_cont(pte))
return true;
+ }
return false;
}
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply related
* [PATCH 0/4] fixes for data/bss linear alias unmap series
From: Ard Biesheuvel @ 2026-06-03 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, maz, Ard Biesheuvel,
Kevin Brodsky, Mark Brown
From: Ard Biesheuvel <ardb@kernel.org>
Fixes for the data/bss linear alias unmap series:
- Fix KASAN related issue reported by Mark, by moving all KASAN page
tables out of BSS [on arm64], not just the ones defined under
arch/arm64
- Fix two issues spotted by Sashiko
- Fix the CKI reported WARN() splat on BBML2_NOABORT systems that try to
split block mappings too early.
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Ard Biesheuvel (4):
arm64: Move generic KASAN page tables out of BSS too
arm64: Avoid double evaluation of __ptep_get()
arm64: mte: Disregard the zero page explicitly for manipulating tags
arm64: mm: Defer remap of linear alias of data/bss
arch/arm64/include/asm/linkage.h | 2 ++
arch/arm64/include/asm/mmu.h | 2 --
arch/arm64/include/asm/mte.h | 5 +++++
arch/arm64/include/asm/pgtable.h | 4 ----
arch/arm64/kernel/vmlinux.lds.S | 8 ++++----
arch/arm64/mm/fixmap.c | 6 +++---
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 20 +++++++++++++-------
include/linux/linkage.h | 4 ++++
mm/kasan/init.c | 10 +++++-----
10 files changed, 37 insertions(+), 26 deletions(-)
base-commit: 63e0b6a5b6934d6a919d1c65ea185303200a1874
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply
* Re: [PATCH v2] clk: keystone: don't cache clock rate
From: Nishanth Menon @ 2026-06-03 16:00 UTC (permalink / raw)
To: Stephen Boyd
Cc: a-christidis, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, linux-arm-kernel, linux-kernel, linux-clk,
Michael Walle, Kevin Hilman, Randolph Sapp, Brian Masney
In-Reply-To: <20260512171604.5ntgq65bmedb7jpc@stinger>
On 12:16-20260512, Nishanth Menon wrote:
> On 10:51-20260512, Brian Masney wrote:
> > Hi Nishanth,
> > > Could you clarify if I need to take it via my tree to arnd or if this
> > > patch will go via the clk tree?
> >
> > Sorry, I'm not sure what Stephen prefers here. An argument could be made
> > for either approach. I would just go with whatever you have done in the
> > past.
>
> Thanks Brian for the review.
>
> This usually will go via Stephen. Will wait, just trying to make sure
> there is no change in expectations (given this patch missed a window).
>
Stephen, I'd like to clarify: would you pick this patch up directly,
or would like me to send you a PR after collecting sci_clk patches? I am
OK with either, would prefer to not have wrong expectations.
I see two patches pending to be queued:
* this one
* https://lore.kernel.org/linux-arm-kernel/20260512110028.2999471-1-nm@ti.com/
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: Add Amlogic A9 peripherals clock controller
From: Conor Dooley @ 2026-06-03 15:52 UTC (permalink / raw)
To: jian.hu
Cc: Neil Armstrong, Jerome Brunet, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260603-a9_peripherals-v2-1-ee1b8c0a1e6c@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: Add Amlogic A9 AO clock controller
From: Conor Dooley @ 2026-06-03 15:51 UTC (permalink / raw)
To: jian.hu
Cc: Neil Armstrong, Jerome Brunet, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260603-a9_aoclk-v2-1-f47ea616ee78@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v14 08/44] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Steven Price @ 2026-06-03 15:48 UTC (permalink / raw)
To: Suzuki K Poulose, Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <e175cb7b-b4fa-4139-b46d-1986e2372d16@arm.com>
On 21/05/2026 16:39, Suzuki K Poulose wrote:
> On 21/05/2026 14:47, Marc Zyngier wrote:
>> On Wed, 13 May 2026 14:17:16 +0100,
>> Steven Price <steven.price@arm.com> wrote:
>>>
>>> The RMM maintains the state of all the granules in the system to make
>>> sure that the host is abiding by the rules. This state can be maintained
>>> at different granularity, per page (TRACKING_FINE) or per region
>>> (TRACKING_COARSE). The region size depends on the underlying
>>> "RMI_GRANULE_SIZE". For a "coarse" region all pages in the region must
>>> be of the same state, this implies we need to have "fine" tracking for
>>> DRAM, so that we can delegated individual pages.
>>>
>>> For now we only support a statically carved out memory for tracking
>>> granules for the "fine" regions. This can be extended in the future to
>>> allow modifying the tracking granularity and remove the need for a
>>> static allocation.
>>>
>>> Similarly, the firmware may create L0 GPT entries describing the total
>>> address space. But if we change the "PAS" (Physical Address Space) of a
>>> granule then the firmware may need to create L1 tables to track the PAS
>>> at a finer granularity.
>>>
>>> Note: support is currently missing for SROs which means that if the RMM
>>> needs memory donating this will fail (and render CCA unusable in Linux).
>>> This effectively means that the L1 GPT tables must be created before
>>> Linux starts.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> Changes since v13:
>>> * Moved out of KVM
>>> ---
>>> arch/arm64/include/asm/rmi_cmds.h | 2 +
>>> arch/arm64/kernel/rmi.c | 103 ++++++++++++++++++++++++++++++
>>> 2 files changed, 105 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/rmi_cmds.h b/arch/arm64/include/
>>> asm/rmi_cmds.h
>>> index 9179934925c5..9078a2920a7c 100644
>>> --- a/arch/arm64/include/asm/rmi_cmds.h
>>> +++ b/arch/arm64/include/asm/rmi_cmds.h
>>> @@ -33,6 +33,8 @@ struct rmi_sro_state {
>>> } while (RMI_RETURN_STATUS(res.a0) == RMI_BUSY || \
>>> RMI_RETURN_STATUS(res.a0) == RMI_BLOCKED)
>>> +bool rmi_is_available(void);
>>> +
>>> unsigned long rmi_sro_execute(struct rmi_sro_state *sro, gfp_t gfp);
>>> void rmi_sro_free(struct rmi_sro_state *sro);
>>> diff --git a/arch/arm64/kernel/rmi.c b/arch/arm64/kernel/rmi.c
>>> index a14ead5dedda..52a415e99500 100644
>>> --- a/arch/arm64/kernel/rmi.c
>>> +++ b/arch/arm64/kernel/rmi.c
>>> @@ -7,6 +7,8 @@
>>> #include <asm/rmi_cmds.h>
>>> +static bool arm64_rmi_is_available;
>>> +
>>> unsigned long rmm_feat_reg0;
>>> unsigned long rmm_feat_reg1;
>>> @@ -88,6 +90,102 @@ static int rmi_configure(void)
>>> return 0;
>>> }
>>> +/*
>>> + * For now we set the tracking_region_size to 0 for
>>> RMI_RMM_CONFIG_SET().
>>> + * TODO: Support other tracking sizes (via Kconfig option).
>>> + */
>>> +#ifdef CONFIG_PAGE_SIZE_4KB
>>> +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
>>> +#elif defined(CONFIG_PAGE_SIZE_16KB)
>>> +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
>>> +#elif defined(CONFIG_PAGE_SIZE_64KB)
>>> +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
>>> +#endif
>>
>> Basically, a level 2 mapping. Which means this whole block really is:
>>
>> #define RMM_GRANULE_TRAKING_SIZE (2 * PAGE_SHIFT - 3)
>>
>> (adjust for D128 as needed).
>
> True,
As Gavin pointed out we actually don't need this anymore because of the
move to a range based API.
It's also not quite that simple because for 4K PAGE_SIZED the RMM
doesn't support 2MB (which would be the level 2 size), instead jumping
to 1GB. And if we add a Kconfig option in the future then this could
change because of that.
For now I'll just delete this block since it's unused.
>>
>>> +
>>> +/*
>>> + * Make sure the area is tracked by RMM at FINE granularity.
>>> + * We do not support changing the tracking yet.
>>> + */
>>> +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t
>>> end)
>>> +{
>>> + while (start < end) {
>>> + unsigned long ret, category, state, next;
>>> +
>>> + ret = rmi_granule_tracking_get(start, end, &category,
>>> &state, &next);
>>> + if (ret != RMI_SUCCESS ||
>>> + state != RMI_TRACKING_FINE ||
>>> + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
>>> + /* TODO: Set granule tracking in this case */
>>> + pr_err("Granule tracking for region isn't fine/
>>> conventional: %llx",
>>> + start);
>>> + return -ENODEV;
>>
>> How is this triggered? Do we really need to spam the console with
>> this? A PA doesn't mean much, and there is no context (stack trace).
I'm not sure 1 message really counts as 'spam' - it provides the
information on why the RMI interface (and therefore realm guests) is
unavailable. The PA might help track down whether this physical region
was intended to be given to Linux.
> This could be triggered if the RMM doesn't have static carveout
> for tracking the DRAM granules. (state != RMI_TRACKING_FINE).
> This not worth WARN_ONCE(), we could simply not enable KVM.
> We plan to add support for donating memory to the RMM in
> the future. (Primarily we don't yet have an RMM implementation
> that does dynamic management via SRO. This can be added later
> as a separate series)
As Suzuki says - this case should be handled in the future - so it's a
limitation in the current implementation. So a WARN_ONCE is a bit strong
- it's not a "can never happen" situation - it's a "Linux doesn't
support this (yet)".
>>
>> If that's not expected, turn this into a WARN_ONCE().
>
>
>
>
>>
>>> + }
>>> + start = next;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static unsigned long rmi_l0gpt_size(void)
>>> +{
>>> + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
>>> + rmm_feat_reg1));
>>> +}
>>> +
>>> +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
>>> +{
>>> + unsigned long l0gpt_sz = rmi_l0gpt_size();
>>> +
>>> + start = ALIGN_DOWN(start, l0gpt_sz);
>>> + end = ALIGN(end, l0gpt_sz);
>>> +
>>> + while (start < end) {
>>> + int ret = rmi_gpt_l1_create(start);
>>> +
>>> + /*
>>> + * Make sure the L1 GPT tables are created for the region.
>>> + * RMI_ERROR_GPT indicates the L1 table already exists.
>>> + */
>>> + if (ret && ret != RMI_ERROR_GPT) {
>>> + /*
>>> + * FIXME: Handle SRO so that memory can be donated for
>>> + * the tables.
>>> + */
>>> + pr_err("GPT Level1 table missing for %llx\n", start);
>>> + return -ENOMEM;
>>
>> If any of this fails, where is the cleanup done? Is that part of the
>> missing SRO support that's indicated in the commit message?
>>
>
> For now, there is no cleanup required. What we essentially do here is
> making sure that the GPT tables have been created upto L1 (i.e.,
> by checking ret == RMI_ERROR_GPT).
>
> We do not donate any memory now, but only support RMMs with static
> memory carved out for L1 GPT. Support for dynamic RMMs could be added as
> a separate series, at which point, we could defer the table creation to
> the actual use case (e.g, RMI_GRANULE_DELEGATE).
>
> Clean up would be required when we donate memory to the RMM.
The missing SRO support is why we're not donating memory - with that
missing the clean up is unnecessary as Suzuki says.
>>> + }
>>> + start += l0gpt_sz;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int rmi_init_metadata(void)
>>> +{
>>> + phys_addr_t start, end;
>>> + const struct memblock_region *r;
>>> +
>>> + for_each_mem_region(r) {
>>> + int ret;
>>> +
>>> + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
>>> + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
>>> + ret = rmi_verify_memory_tracking(start, end);
>>> + if (ret)
>>> + return ret;
>>> + ret = rmi_create_gpts(start, end);
>>> + if (ret)
>>> + return ret;
>>> + }
>>
>> How does this work with, say, memory hotplug?
>
> Good point, we need a hook for hotpug to make sure this is taken care
> of. As mentioned above, when we add support for RMM with support for
> dynamic Tracking/GPT with SRO, this could be deferred to the actual
> use (handling RMI return codes, RMI_ERROR_TRACKING/RMI_ERROR_GPT)
Yep, that was an oversight - we definitely will need to handle hotplug.
Thanks,
Steve
> Suzuki
>
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +bool rmi_is_available(void)
>>> +{
>>> + return arm64_rmi_is_available;
>>> +}
>>> +
>>> static int __init arm64_init_rmi(void)
>>> {
>>> /* Continue without realm support if we can't agree on a
>>> version */
>>> @@ -101,6 +199,11 @@ static int __init arm64_init_rmi(void)
>>> if (rmi_configure())
>>> return 0;
>>> + if (rmi_init_metadata())
>>> + return 0;
>>> +
>>> + arm64_rmi_is_available = true;
>>> + pr_info("RMI configured");
>>> return 0;
>>> }
>>
>> Thanks,
>>
>> M.
>>
>
^ permalink raw reply
* Re: [PATCH v14 08/44] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Steven Price @ 2026-06-03 15:48 UTC (permalink / raw)
To: Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <2ad282da-88fd-49ab-8145-964ff298ca83@redhat.com>
On 21/05/2026 01:58, Gavin Shan wrote:
> Hi Steven,
>
> On 5/13/26 11:17 PM, Steven Price wrote:
>> The RMM maintains the state of all the granules in the system to make
>> sure that the host is abiding by the rules. This state can be maintained
>> at different granularity, per page (TRACKING_FINE) or per region
>> (TRACKING_COARSE). The region size depends on the underlying
>> "RMI_GRANULE_SIZE". For a "coarse" region all pages in the region must
>> be of the same state, this implies we need to have "fine" tracking for
>> DRAM, so that we can delegated individual pages.
>>
>> For now we only support a statically carved out memory for tracking
>> granules for the "fine" regions. This can be extended in the future to
>> allow modifying the tracking granularity and remove the need for a
>> static allocation.
>>
>> Similarly, the firmware may create L0 GPT entries describing the total
>> address space. But if we change the "PAS" (Physical Address Space) of a
>> granule then the firmware may need to create L1 tables to track the PAS
>> at a finer granularity.
>>
>> Note: support is currently missing for SROs which means that if the RMM
>> needs memory donating this will fail (and render CCA unusable in Linux).
>> This effectively means that the L1 GPT tables must be created before
>> Linux starts.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v13:
>> * Moved out of KVM
>> ---
>> arch/arm64/include/asm/rmi_cmds.h | 2 +
>> arch/arm64/kernel/rmi.c | 103 ++++++++++++++++++++++++++++++
>> 2 files changed, 105 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/rmi_cmds.h b/arch/arm64/include/
>> asm/rmi_cmds.h
>> index 9179934925c5..9078a2920a7c 100644
>> --- a/arch/arm64/include/asm/rmi_cmds.h
>> +++ b/arch/arm64/include/asm/rmi_cmds.h
>> @@ -33,6 +33,8 @@ struct rmi_sro_state {
>> } while (RMI_RETURN_STATUS(res.a0) == RMI_BUSY || \
>> RMI_RETURN_STATUS(res.a0) == RMI_BLOCKED)
>> +bool rmi_is_available(void);
>> +
>> unsigned long rmi_sro_execute(struct rmi_sro_state *sro, gfp_t gfp);
>> void rmi_sro_free(struct rmi_sro_state *sro);
>> diff --git a/arch/arm64/kernel/rmi.c b/arch/arm64/kernel/rmi.c
>> index a14ead5dedda..52a415e99500 100644
>> --- a/arch/arm64/kernel/rmi.c
>> +++ b/arch/arm64/kernel/rmi.c
>> @@ -7,6 +7,8 @@
>> #include <asm/rmi_cmds.h>
>> +static bool arm64_rmi_is_available;
>> +
>> unsigned long rmm_feat_reg0;
>> unsigned long rmm_feat_reg1;
>> @@ -88,6 +90,102 @@ static int rmi_configure(void)
>> return 0;
>> }
>> +/*
>> + * For now we set the tracking_region_size to 0 for
>> RMI_RMM_CONFIG_SET().
>> + * TODO: Support other tracking sizes (via Kconfig option).
>> + */
>> +#ifdef CONFIG_PAGE_SIZE_4KB
>> +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
>> +#elif defined(CONFIG_PAGE_SIZE_16KB)
>> +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
>> +#elif defined(CONFIG_PAGE_SIZE_64KB)
>> +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
>> +#endif
>> +
>
> RMM_GRANULE_TRACKING_SIZE is never used in this series.
Ah, good spot. In a previous version the tracking size was necessary
when walking below. But the spec was updated to a range based API so
this is no longer necessary.
>> +/*
>> + * Make sure the area is tracked by RMM at FINE granularity.
>> + * We do not support changing the tracking yet.
>> + */
>> +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t
>> end)
>> +{
>> + while (start < end) {
>> + unsigned long ret, category, state, next;
>> +
>> + ret = rmi_granule_tracking_get(start, end, &category, &state,
>> &next);
>> + if (ret != RMI_SUCCESS ||
>> + state != RMI_TRACKING_FINE ||
>> + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
>> + /* TODO: Set granule tracking in this case */
>> + pr_err("Granule tracking for region isn't fine/
>> conventional: %llx",
>> + start);
>> + return -ENODEV;
>> + }
>> + start = next;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static unsigned long rmi_l0gpt_size(void)
>> +{
>> + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
>> + rmm_feat_reg1));
>> +}
>> +
>
> rmi_l0gpt_size() is only used by rmi_create_gpts(), its logic can be
> combined to that function.
True - I think partly due to the long line I split this into a separate
function. But I could do something like:
unsigned long l0gpt_sz;
l0gpt_sz = 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
rmi_feat_reg(1)));
which isn't too bad.
Thanks,
Steve
>> +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
>> +{
>> + unsigned long l0gpt_sz = rmi_l0gpt_size();
>> +
>> + start = ALIGN_DOWN(start, l0gpt_sz);
>> + end = ALIGN(end, l0gpt_sz);
>> +
>> + while (start < end) {
>> + int ret = rmi_gpt_l1_create(start);
>> +
>> + /*
>> + * Make sure the L1 GPT tables are created for the region.
>> + * RMI_ERROR_GPT indicates the L1 table already exists.
>> + */
>> + if (ret && ret != RMI_ERROR_GPT) {
>> + /*
>> + * FIXME: Handle SRO so that memory can be donated for
>> + * the tables.
>> + */
>> + pr_err("GPT Level1 table missing for %llx\n", start);
>> + return -ENOMEM;
>> + }
>> + start += l0gpt_sz;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int rmi_init_metadata(void)
>> +{
>> + phys_addr_t start, end;
>> + const struct memblock_region *r;
>> +
>> + for_each_mem_region(r) {
>> + int ret;
>> +
>> + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
>> + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
>> + ret = rmi_verify_memory_tracking(start, end);
>> + if (ret)
>> + return ret;
>> + ret = rmi_create_gpts(start, end);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +bool rmi_is_available(void)
>> +{
>> + return arm64_rmi_is_available;
>> +}
>> +
>> static int __init arm64_init_rmi(void)
>> {
>> /* Continue without realm support if we can't agree on a version */
>> @@ -101,6 +199,11 @@ static int __init arm64_init_rmi(void)
>> if (rmi_configure())
>> return 0;
>> + if (rmi_init_metadata())
>> + return 0;
>> +
>> + arm64_rmi_is_available = true;
>> + pr_info("RMI configured");
>> return 0;
>> }
>
> Thanks,
> Gavin
>
^ permalink raw reply
* Re: [PATCH v14 08/44] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Steven Price @ 2026-06-03 15:48 UTC (permalink / raw)
To: Aneesh Kumar K.V, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <yq5aa4twt03b.fsf@kernel.org>
On 19/05/2026 06:55, Aneesh Kumar K.V wrote:
>> +
>> +bool rmi_is_available(void)
>> +{
>> + return arm64_rmi_is_available;
>> +}
>> +
>
> Can we rename to is_rmi_available(void) ?
Sure, will do.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v14 07/44] arm64: RMI: Configure the RMM with the host's page size
From: Steven Price @ 2026-06-03 15:48 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <86a4tsx536.wl-maz@kernel.org>
On 21/05/2026 14:30, Marc Zyngier wrote:
> On Wed, 13 May 2026 14:17:15 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> RMM v2.0 brings the ability to set the RMM's granule size. Check the
>> feature registers and configure the RMM so that it matches the host's
>> page size. This means that operations can be done with a granulatity
>> equal to PAGE_SIZE.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v13:
>> * Moved out of KVM.
>> ---
>> arch/arm64/kernel/rmi.c | 42 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/rmi.c b/arch/arm64/kernel/rmi.c
>> index 99c1ccc35c11..a14ead5dedda 100644
>> --- a/arch/arm64/kernel/rmi.c
>> +++ b/arch/arm64/kernel/rmi.c
>> @@ -49,6 +49,45 @@ static int rmi_check_version(void)
>> return 0;
>> }
>>
>> +static int rmi_configure(void)
>> +{
>> + struct rmm_config *config __free(free_page) = NULL;
>> + unsigned long ret;
>> +
>> + config = (struct rmm_config *)get_zeroed_page(GFP_KERNEL);
>> + if (!config)
>> + return -ENOMEM;
>
> This is the sort of buggy construct that is highlighted in
> include/linux/cleanup.h: initialising the object for cleanup with
> NULL, and only later assigning the expected value.
>
> It may not matter here, but it will catch you (or more probably me) in
> the future.
Good spot. I have to admit I'm still getting the hang of these cleanup
handlers.
>> +
>> + switch (PAGE_SIZE) {
>> + case SZ_4K:
>> + config->rmi_granule_size = RMI_GRANULE_SIZE_4KB;
>> + break;
>> + case SZ_16K:
>> + config->rmi_granule_size = RMI_GRANULE_SIZE_16KB;
>> + break;
>> + case SZ_64K:
>> + config->rmi_granule_size = RMI_GRANULE_SIZE_64KB;
>> + break;
>> + default:
>> + pr_err("Unsupported PAGE_SIZE for RMM\n");
>
> Do you really anticipate PAGE_SIZE being any other value? This is 100%
> dead code. If you want to be extra cautious, have a BUILD_BUg_ON().
No, but falling through is clearly wrong (and likely to trigger AI
review comments if nothing else) - BUILD_BUG() sounds like a good solution.
>> + return -EINVAL;
>> + }
>> +
>> + ret = rmi_rmm_config_set(virt_to_phys(config));
>> + if (ret) {
>> + pr_err("RMM config set failed\n");
>> + return -EINVAL;
>> + }
>
> What is the live cycle of the page when the call succeeds? Is it
> switched back to the NS PAS and allowed to be freed?
Yes, as Suzuki answered - it never leaves the NS PAS. The RMM just reads it.
Thanks,
Steve
>> +
>> + ret = rmi_rmm_activate();
>> + if (ret) {
>> + pr_err("RMM activate failed\n");
>> + return -ENXIO;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int __init arm64_init_rmi(void)
>> {
>> /* Continue without realm support if we can't agree on a version */
>> @@ -60,6 +99,9 @@ static int __init arm64_init_rmi(void)
>> if (WARN_ON(rmi_features(1, &rmm_feat_reg1)))
>> return 0;
>>
>> + if (rmi_configure())
>> + return 0;
>> +
>> return 0;
>> }
>> subsys_initcall(arm64_init_rmi);
>
> Thanks,
>
> M.
>
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()
From: Dylan Eskew @ 2026-06-03 15:43 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, linux-wireless,
linux-arm-kernel, linux-mediatek
In-Reply-To: <ah_TG4bkzitM4AER@lore-desk>
Hi Lore,
>> Hi Lore,
> Hi Dylan,
>
>> We have been seeing the token memory leak in our custom kernel. After
>> pulling your patch in, we are still getting the leak (validated with
>> kmemleak). How did you figure out where this potential leak was? I want to
>> determine if we are leaking because of our changes or if there's more areas
>> for token leakage.
> Can you please try to run kmemleak on Felix's tree to check if there are any
> leftover leaks not fixed yet?
Ran kmemleak with Felix's tree. I brought up only a few stations, no
traffic run yet and kmemleak flagged a possible leak, same allocation
location we've seen flagged in our custom kernel.
kmemleak trace:
```
unreferenced object 0xffff88811e6ca380 (size 128):
comm "mt76-tx phy0", pid 1164, jiffies 4295044455
hex dump (first 32 bytes):
44 00 00 1a 0a a0 4c ae 0d 00 00 00 02 78 00 30 D.....L......x.0
00 00 00 00 01 00 00 00 14 00 27 12 00 00 00 08 ..........'.....
backtrace (crc fba2c5a3):
__kmalloc_noprof+0x38e/0x480
mt76_dma_tx_queue_skb+0x522/0x890 [mt76]
__mt76_tx_queue_skb+0x3e/0xa0 [mt76]
mt76_txq_schedule_pending_wcid+0x12b/0x200 [mt76]
mt76_txq_schedule_pending+0x122/0x1b0 [mt76]
mt76_tx_worker_run+0x1b/0xc0 [mt76]
__mt76_worker_fn+0x49/0x90 [mt76]
kthread+0xdc/0x110
ret_from_fork+0x190/0x280
ret_from_fork_asm+0x11/0x20
```
In dma.c, line 19 is the where the kmemleak trace points:
```
10 static struct mt76_txwi_cache *
11 mt76_alloc_txwi(struct mt76_dev *dev)
12 {
13 struct mt76_txwi_cache *t;
14 dma_addr_t addr;
15 u8 *txwi;
16 int size;
17
18 size = L1_CACHE_ALIGN(dev->drv->txwi_size + sizeof(*t));
19 txwi = kzalloc(size, GFP_ATOMIC);
20 if (!txwi)
21 return NULL;
22
23 addr = dma_map_single(dev->dma_dev, txwi, dev->drv->txwi_size,
24 DMA_TO_DEVICE);
25 if (unlikely(dma_mapping_error(dev->dma_dev, addr))) {
26 kfree(txwi);
27 return NULL;
28 }
29
30 t = (struct mt76_txwi_cache *)(txwi + dev->drv->txwi_size);
31 t->dma_addr = addr;
32
33 return t;
34 }
```
Let me know if you need any other information.
-- Dylan
>
> Regards,
> Lorenzo
>
>> -- Dylan
>>
>> On 5/31/26 2:10 AM, Lorenzo Bianconi wrote:
>>> If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine,
>>> mt7996 driver leaks an already allocated tx token. Fix the issue
>>> releasing the token in case of error.
>>>
>>> Fixes: 7ef0c7ad735b0 ("wifi: mt76: mt7996: Implement MLD address translation for EAPOL")
>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 8 ++++++--
>>> drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
>>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> index c98446057282..8c56344d211b 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> @@ -1067,11 +1067,11 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
>>> link_conf = rcu_dereference(vif->link_conf[wcid->link_id]);
>>> if (!link_conf)
>>> - return -EINVAL;
>>> + goto error_relase_token;
>>> link_sta = rcu_dereference(sta->link[wcid->link_id]);
>>> if (!link_sta)
>>> - return -EINVAL;
>>> + goto error_relase_token;
>>> dma_sync_single_for_cpu(mdev->dma_dev, tx_info->buf[1].addr,
>>> tx_info->buf[1].len, DMA_TO_DEVICE);
>>> @@ -1176,6 +1176,10 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
>>> tx_info->nbuf = MT_CT_DMA_BUF_NUM;
>>> return 0;
>>> +
>>> +error_relase_token:
>>> + mt76_token_release(mdev, id, NULL);
>>> + return -EINVAL;
>>> }
>>> u32 mt7996_wed_init_buf(void *ptr, dma_addr_t phys, int token_id)
>>> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
>>> index 22f9690634c9..f96d9c471853 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/tx.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
>>> @@ -933,7 +933,7 @@ mt76_token_release(struct mt76_dev *dev, int token, bool *wake)
>>> #endif
>>> }
>>> - if (dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
>>> + if (wake && dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
>>> dev->phy.q_tx[0]->blocked)
>>> *wake = true;
>>>
>>> ---
>>> base-commit: 4913f44167cf35a9536e9eec7352e15b2de0c573
>>> change-id: 20260531-mt7996_tx_prepare_skb-token-leack-82e240d8c66f
>>>
>>> Best regards,
^ permalink raw reply
* [GIT PULL 2/2] arm64: dts: ti: K3 updates for v7.2
From: Nishanth Menon @ 2026-06-03 15:40 UTC (permalink / raw)
To: SoC, arm
Cc: SoC list, linux-arm-kernel, linux-kernel, Vignesh Raghavendra,
Nishanth Menon, Tero Kristo, Tony Lindgren, Santosh Shilimkar
[-- Attachment #1: Type: text/plain, Size: 6967 bytes --]
Hi ARM SoC maintainers,
checkpatch and dtbs_check reports the following on v7.1-rc1
ti,j722s-wiz-10g ti,j722s-phy-gmii-sel usb424,2514 st,24c02
riverdi,rvt101hvlnwc00
I picked those up in the interest of the community and these are clean
on dtbs_check on next-20260602, while the usb424,2514 and st,24c02
seem to be the usual regex artifact of checkpatch.
Please pull:
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-dt-for-v7.2
for you to fetch changes up to 837c7dbc5bee260768333c1f985dd0688b5aff8a:
arm64: dts: ti: k3-am62-verdin: Add Mezzanine with Toradex Display 10.1" LVDS (2026-05-29 14:59:32 -0500)
----------------------------------------------------------------
TI K3 device tree updates for v7.2
SoC Specific Features and Fixes:
J722S:
- Use ti,j7200-padconf compatible for pad configuration
- Add MCU and wakeup domain peripherals specific to J722S
- Use J722S-specific compatibles for WIZ, gmii-sel and CPSW3G nodes
Board Specific Features and Fixes:
AM62x (Toradex Verdin):
- Add display overlays: DSI-to-HDMI adapter, DSI-to-LVDS adapter with 10.1"
panel, capacitive touch displays in 7" DSI, 10.1" DSI and 10.1" LVDS
configurations, and Mezzanine with 10.1" LVDS display
- Add NAU8822 Bridge Tied Load audio support
- Add OV5640 CSI camera overlays
- Add Verdin Mezzanine CAN overlay
- Reserve UART_4 for Cortex-M4F use
AM625:
- Add support for TQ-Systems TQMa62xx SoM and MBa62xx carrier board,
including new dt-bindings compatible strings
AM62x (phyBOARD-Lyra):
- Add DT overlay for Lincoln LCD185-101CT OLDI panel
AM62-LP SK:
- Add system-power-controller node
AM62A7 SK:
- Add bootph-all tag to vqmmc regulator for proper boot sequencing
J721S2-som:
- Add bootph-pre-ram property to PMIC-B for proper early boot sequencing
----------------------------------------------------------------
Abhash Kumar Jha (1):
arm64: dts: ti: k3-j722s: Use ti,j7200-padconf compatible
Akashdeep Kaur (1):
arm64: dts: ti: k3-am62-lp-sk: Add system-power-controller
Judith Mendez (1):
arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc
Nora Schiffer (3):
dt-bindings: arm: ti: Add compatible for AM625-based TQMa62xx SOM family and carrier board
arm64: dts: ti: Add TQ-Systems TQMa62xx SoM and MBa62xx carrier board Device Trees
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
Richard Genoud (TI) (2):
arm64: dts: ti: k3-j722s: Add mcu domain peripherals specific to J722S
arm64: dts: ti: k3-j722s: Add wakeup domain peripherals specific to J722S
Thomas Richard (TI) (1):
arm64: dts: ti: k3-j721s2-som-p0: add bootph-pre-ram property to PMIC-B
Vitor Soares (10):
arm64: dts: ti: k3-am62-verdin: Add DSI to HDMI adapter overlay
arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with 10.1" display
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" DSI
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 7" DSI
arm64: dts: ti: k3-am62-verdin: Add NAU8822 Bridge Tied Load
arm64: dts: ti: k3-am62-verdin: Reserve UART_4 for Cortex-M4F
arm64: dts: ti: k3-am62-verdin: Add Toradex OV5640 CSI Cameras
arm64: dts: ti: k3-am62-verdin: Add Toradex Verdin Mezzanine CAN
arm64: dts: ti: k3-am62-verdin: Add Mezzanine with Toradex Display 10.1" LVDS
Wadim Egorov (1):
arm64: dts: ti: am62-phyboard-lyra: Add DT overlay for Lincoln LCD185-101CT panel
Documentation/devicetree/bindings/arm/ti/k3.yaml | 7 +
arch/arm64/boot/dts/ti/Makefile | 67 ++
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 1 +
.../dts/ti/k3-am62-phyboard-lyra-oldi-lcd185.dtso | 185 ++++
.../boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts | 1033 ++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi | 360 +++++++
.../dts/ti/k3-am625-verdin-dev-mezzanine-can.dtso | 28 +
...-dev-mezzanine-panel-cap-touch-10inch-lvds.dtso | 98 ++
.../dts/ti/k3-am625-verdin-dev-nau8822-btl.dtso | 14 +
.../boot/dts/ti/k3-am625-verdin-dsi-to-hdmi.dtso | 94 ++
...-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso | 124 +++
.../boot/dts/ti/k3-am625-verdin-ov5640-24mhz.dtso | 17 +
arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtsi | 71 ++
arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtso | 18 +
...k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso | 132 +++
...3-am625-verdin-panel-cap-touch-10inch-lvds.dtso | 120 +++
.../k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso | 132 +++
.../boot/dts/ti/k3-am625-verdin-uart4-mcu.dtso | 13 +
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 2 +
arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 32 +-
arch/arm64/boot/dts/ti/k3-j722s-mcu.dtsi | 15 +
arch/arm64/boot/dts/ti/k3-j722s-wakeup.dtsi | 18 +
arch/arm64/boot/dts/ti/k3-j722s.dtsi | 2 +
24 files changed, 2564 insertions(+), 20 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-phyboard-lyra-oldi-lcd185.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-can.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-nau8822-btl.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-hdmi.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640-24mhz.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-uart4-mcu.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-mcu.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-wakeup.dtsi
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [GIT PULL 1/2] soc: ti: Driver updates for v7.2
From: Nishanth Menon @ 2026-06-03 15:40 UTC (permalink / raw)
To: SoC, arm
Cc: SoC list, linux-arm-kernel, linux-kernel, Vignesh Raghavendra,
Nishanth Menon, Tero Kristo, Tony Lindgren, Santosh Shilimkar
[-- Attachment #1: Type: text/plain, Size: 4114 bytes --]
Hi ARM SoC maintainers,
There is a minor checkpatch report irq_lock - Check reports "struct
mutex definition without comment" but it is indeed part of the
structure documentation. Things look clean build wise and tests across
platforms are also good as of next-20260602.
Please pull:
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-driver-soc-for-v7.2
for you to fetch changes up to dc51f820bd32415445655aa6e3af9011b9e3e0f3:
firmware: ti_sci: Add support for restoring clock context during resume (2026-05-26 06:44:42 -0500)
----------------------------------------------------------------
TI SoC driver updates for v7.2
TI K3 TISCI:
- ti_sci: Add BOARDCFG_MANAGED mode for support system suspend/resume cycles
- ti_sci: Add support for restoring IRQ and clock contexts during resume.
- clk: keystone: sci-clk: Add clock restoration support.
SoC Drivers:
- k3-socinfo: Add support for identifying AM62P silicon variants via NVMEM,
along with corresponding dt-bindings update for nvmem-cells support
- k3-ringacc: Fix incorrect access mode for ring pop tail IO/proxy operations
Keystone Navigator (knav) Cleanup and Fixes:
- knav_qmss: Multiple code quality improvements
- knav_qmss_queue: Implement proper resource cleanup in the remove() path
General Cleanups:
- k3-ringacc: Use str_enabled_disabled() helper for consistency
- knav_qmss: Use %pe format specifier for PTR_ERR() printing
----------------------------------------------------------------
Judith Mendez (2):
dt-bindings: hwinfo: ti,k3-socinfo: Add nvmem-cells support
soc: ti: k3-socinfo: Add support for AM62P variants via NVMEM
Md Shofiqul Islam (1):
soc: ti: knav_qmss_queue: Implement resource cleanup in remove()
Nishanth Menon (11):
soc: ti: knav_qmss: Remove remaining redundant ENOMEM printks
soc: ti: knav_qmss: Rename global kdev to knav_qdev to fix -Wshadow
soc: ti: knav_qmss: Inline lockdep condition in for_each_handle_rcu
soc: ti: knav_qmss: Fix kernel-doc Return: tags
soc: ti: knav_qmss: Use %pe to print PTR_ERR()
soc: ti: knav_qmss: Fix __iomem annotations and __be32 type
soc: ti: knav_qmss_acc: Fix kernel-doc Return: tag
soc: ti: knav_dma: Remove unused DMA_PRIO_MASK macro
soc: ti: knav_dma: Remove dead check on unsigned args.args[0]
soc: ti: knav_dma: Use IOMEM_ERR_PTR() in pktdma_get_regs()
soc: ti: k3-ringacc: Use str_enabled_disabled() helper
Randy Dunlap (1):
soc: ti: knav_dma: fix all kernel-doc warnings in knav_dma.h
Siddharth Vadapalli (1):
soc: ti: k3-ringacc: Fix access mode for k3_ringacc_ring_pop_tail_io/proxy
Thomas Richard (TI) (4):
firmware: ti_sci: Add BOARDCFG_MANAGED mode support
firmware: ti_sci: Add support for restoring IRQs during resume
clk: keystone: sci-clk: Add restore_context() operation
firmware: ti_sci: Add support for restoring clock context during resume
.../devicetree/bindings/hwinfo/ti,k3-socinfo.yaml | 11 ++
drivers/clk/keystone/sci-clk.c | 45 ++++-
drivers/firmware/ti_sci.c | 201 +++++++++++++++++++--
drivers/firmware/ti_sci.h | 9 +
drivers/soc/ti/k3-ringacc.c | 7 +-
drivers/soc/ti/k3-socinfo.c | 41 ++++-
drivers/soc/ti/knav_dma.c | 8 +-
drivers/soc/ti/knav_qmss.h | 2 +-
drivers/soc/ti/knav_qmss_acc.c | 2 +-
drivers/soc/ti/knav_qmss_queue.c | 155 ++++++++--------
include/linux/soc/ti/knav_dma.h | 11 +-
11 files changed, 372 insertions(+), 120 deletions(-)
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/5] dt-bindings: clock: Move xlnx,zynqmp-clk to its own schema
From: Conor Dooley @ 2026-06-03 15:34 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, monstr, git, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
kishore Manne, moderated list:ARM/ZYNQ ARCHITECTURE,
open list:COMMON CLK FRAMEWORK
In-Reply-To: <23d848e29176706548612c4a0751481d46176f11.1780499520.git.michal.simek@amd.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1] ARM: devtree: Fix /cpus node reference leak
From: 최유호 @ 2026-06-03 15:33 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Russell King, linux-arm-kernel, linux-kernel
In-Reply-To: <b6764a7b-d288-486a-9feb-a7c6fa41d777@lunn.ch>
Dear Andrew
On Tue, 2 Jun 2026 at 23:09, Andrew Lunn <andrew@lunn.ch> wrote:
>
> But please think about what you are fixing. Is it theoretical? Is it
> old code which has been running perfectly well for 10 years? Is it
> something really early in the boot that if it fails, the machine is
> dead anyway, so who cares about a minor resource leak?
>
> Are these patches actual worth while?
That's a fair point.
I am still relatively new to Linux kernel development, and I think I
focused too much on correctness itself without giving enough thought
to the practical impact of the issue.
I appreciate your feedback. I'll try to consider the mentioned points
when evaluating future patches.
Best regards,
Yuho
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: firmware: xilinx: Add missing example for ZynqMP
From: Conor Dooley @ 2026-06-03 15:30 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, monstr, git, Conor Dooley, Krzysztof Kozlowski,
Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
kishore Manne, moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <da152696e367eee8717a644d9303d27df1a3107b.1780499520.git.michal.simek@amd.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 6/9] mailbox: imx: Move the RX part of the mailbox into the threaded handler
From: Sebastian Andrzej Siewior @ 2026-06-03 15:26 UTC (permalink / raw)
To: Daniel Baluta
Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <944c6eaa-05f2-437a-88e7-1573b64468c5@oss.nxp.com>
On 2026-06-03 16:45:16 [+0300], Daniel Baluta wrote:
> I would prefer to add the explanation for this in at least one commit
> message to be there in git log.
>
> Cover letter is not kept in git history.
You could merge is part of the series. But I could of course add the
rational behind this to the patch where I start adding the threaded
handler and move the TX bits.
I just finished of with sashiko. Do you have other human input?
Otherwise I would fix the one thing I did wrong, propagate the one error
sashiko mentioned. I'm not sure what to do about the long time outs it
complains about, I would keep them for now. That timeout check based on
jiffies is also odd.
Sebastian
^ permalink raw reply
* [PATCH v4 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-06-03 15:27 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <cover.1780498640.git.andrea.porta@suse.com>
From: Naushir Patuck <naush@raspberrypi.com>
The Raspberry Pi RP1 southbridge features an embedded PWM
controller with 4 output channels, alongside an RPM interface
to read the fan speed on the Raspberry Pi 5.
Add the supporting driver.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
Referring to the comments from:
https://sashiko.dev/#/patchset/cover.1776932336.git.andrea.porta%40suse.com
regarding the register synchronization, there is no race condition
because the pwm driver is not using the PHASE register at all,
while the (future) consumer driver will just read from that register.
---
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-rp1.c | 422 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 432 insertions(+)
create mode 100644 drivers/pwm/pwm-rp1.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 6f3147518376a..c3ddc0eb4774f 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -625,6 +625,15 @@ config PWM_ROCKCHIP
Generic PWM framework driver for the PWM controller found on
Rockchip SoCs.
+config PWM_RASPBERRYPI_RP1
+ tristate "RP1 PWM support"
+ depends on MISC_RP1 || COMPILE_TEST
+ depends on HAS_IOMEM
+ select REGMAP_MMIO
+ select MFD_SYSCON
+ help
+ PWM framework driver for Raspberry Pi RP1 controller.
+
config PWM_SAMSUNG
tristate "Samsung PWM support"
depends on PLAT_SAMSUNG || ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0dc0d2b69025d..59f29f60f9123 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_PWM_RENESAS_RZG2L_GPT) += pwm-rzg2l-gpt.o
obj-$(CONFIG_PWM_RENESAS_RZ_MTU3) += pwm-rz-mtu3.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
+obj-$(CONFIG_PWM_RASPBERRYPI_RP1) += pwm-rp1.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
obj-$(CONFIG_PWM_SL28CPLD) += pwm-sl28cpld.o
diff --git a/drivers/pwm/pwm-rp1.c b/drivers/pwm/pwm-rp1.c
new file mode 100644
index 0000000000000..052c3ae770569
--- /dev/null
+++ b/drivers/pwm/pwm-rp1.c
@@ -0,0 +1,422 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * pwm-rp1.c
+ *
+ * Raspberry Pi RP1 PWM.
+ *
+ * Copyright © 2026 Raspberry Pi Ltd.
+ *
+ * Author: Naushir Patuck (naush@raspberrypi.com)
+ *
+ * Based on the pwm-bcm2835 driver by:
+ * Bart Tanghe <bart.tanghe@thomasmore.be>
+ *
+ * Datasheet: https://pip-assets.raspberrypi.com/categories/892-raspberry-pi-5/documents/RP-008370-DS-1-rp1-peripherals.pdf?disposition=inline
+ *
+ * Limitations:
+ * - Channels can be enabled/disabled through a global update flag, while the
+ * period and duty per-channel registers are independently updatable, and
+ * they are latched on the end of (specific channel) period strobe.
+ * This means that period and duty changes might result in glitches if the
+ * period/duty is changed exactly during an end of period strobe.
+ * - Since the duty/period registers are freely updatable (do not depend on
+ * the global update flag), setting one of them close to the period end and
+ * the other right afterwards results in a mixed output for that cycle because
+ * the write ops are not atomic.
+ * - The global update flag prevents mis-sampling of multi-bit bus signals in
+ * the PWM clock domain. This ensures that all PWM channel settings update
+ * on the same PWM clock cycle. Channels start in sync only if they share the
+ * same period.
+ * - If both duty and period are set to 0, the output is a constant low signal
+ * if polarity is normal or a constant high signal if polarity is inversed.
+ * - When disabled the output is driven to 0 if polarity is normal, or to 1
+ * if polarity is inversed.
+ * - Disabling the PWM stops the output immediately, without waiting for current
+ * period to complete first.
+ * - Channels are phase-capable, but on RPi5, the firmware can use a channel
+ * phase register to report the RPM of the fan connected to that PWM
+ * channel. As a result, phase control will be ignored for now.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/units.h>
+
+#define RP1_PWM_GLB_CTRL 0x000
+#define RP1_PWM_GLB_CTRL_CHANNEL_ENABLE(chan) BIT(chan)
+#define RP1_PWM_GLB_CTRL_SET_UPDATE BIT(31)
+
+#define RP1_PWM_CHAN_CTRL(chan) (0x014 + ((chan) * 0x10))
+#define RP1_PWM_CHAN_CTRL_POLARITY BIT(3)
+#define RP1_PWM_CHAN_CTRL_FIFO_POP_MASK BIT(8)
+#define RP1_PWM_CHAN_CTRL_MODE GENMASK(2, 0)
+enum rp1_pwm_ctrl_mode {
+ RP1_PWM_CHAN_CTRL_MODE_ZERO,
+ RP1_PWM_CHAN_CTRL_MODE_TE_MS,
+ RP1_PWM_CHAN_CTRL_MODE_PC_MS,
+ RP1_PWM_CHAN_CTRL_MODE_PD_ENC,
+ RP1_PWM_CHAN_CTRL_MODE_MSB_SER,
+ RP1_PWM_CHAN_CTRL_MODE_PPM,
+ RP1_PWM_CHAN_CTRL_MODE_LE_MS,
+ RP1_PWM_CHAN_CTRL_MODE_LSB_SER,
+};
+
+#define RP1_PWM_CHAN_CTRL_DEFAULT (RP1_PWM_CHAN_CTRL_FIFO_POP_MASK + \
+ FIELD_PREP(RP1_PWM_CHAN_CTRL_MODE, \
+ RP1_PWM_CHAN_CTRL_MODE_TE_MS))
+
+#define RP1_PWM_RANGE(chan) (0x018 + ((chan) * 0x10))
+#define RP1_PWM_PHASE(chan) (0x01C + ((chan) * 0x10))
+#define RP1_PWM_DUTY(chan) (0x020 + ((chan) * 0x10))
+
+#define RP1_PWM_NUM_PWMS 4
+
+struct rp1_pwm {
+ struct regmap *regmap;
+ struct clk *clk;
+ unsigned long clk_rate;
+ bool clk_enabled;
+};
+
+struct rp1_pwm_waveform {
+ u32 period_ticks;
+ u32 duty_ticks;
+ bool enabled;
+ bool inverted_polarity;
+};
+
+static const struct regmap_config rp1_pwm_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x60,
+};
+
+static void rp1_pwm_apply_config(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ u32 value;
+
+ /* update the changed registers on the next strobe to avoid glitches */
+ regmap_read(rp1->regmap, RP1_PWM_GLB_CTRL, &value);
+ value |= RP1_PWM_GLB_CTRL_SET_UPDATE;
+ regmap_write(rp1->regmap, RP1_PWM_GLB_CTRL, value);
+}
+
+static int rp1_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+
+ /* init channel to reset defaults, preserving the polarity bit */
+ regmap_update_bits(rp1->regmap, RP1_PWM_CHAN_CTRL(pwm->hwpwm),
+ ~(u32)RP1_PWM_CHAN_CTRL_POLARITY, RP1_PWM_CHAN_CTRL_DEFAULT);
+ return 0;
+}
+
+static int rp1_pwm_round_waveform_tohw(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ const struct pwm_waveform *wf,
+ void *_wfhw)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ u64 period_ticks, duty_ticks, offset_ticks;
+ struct rp1_pwm_waveform *wfhw = _wfhw;
+ u64 clk_rate = rp1->clk_rate;
+ int ret = 0;
+
+ if (!wf->period_length_ns) {
+ wfhw->enabled = false;
+ return 0;
+ }
+
+ period_ticks = mul_u64_u64_div_u64(wf->period_length_ns, clk_rate, NSEC_PER_SEC);
+
+ /*
+ * The period is limited to U32_MAX - 1
+ * to allow 100% duty cycle.
+ */
+ if (period_ticks > U32_MAX) {
+ period_ticks = U32_MAX - 1;
+ } else if (!period_ticks) {
+ period_ticks = 2;
+ ret = 1;
+ }
+
+ duty_ticks = mul_u64_u64_div_u64(wf->duty_length_ns, clk_rate, NSEC_PER_SEC);
+ duty_ticks = min(duty_ticks, period_ticks);
+ offset_ticks = mul_u64_u64_div_u64(wf->duty_offset_ns, clk_rate, NSEC_PER_SEC);
+ if (offset_ticks >= period_ticks)
+ offset_ticks %= period_ticks;
+ if (duty_ticks && offset_ticks &&
+ duty_ticks + offset_ticks >= period_ticks) {
+ wfhw->duty_ticks = period_ticks - duty_ticks;
+ wfhw->inverted_polarity = true;
+ } else {
+ wfhw->duty_ticks = duty_ticks;
+ wfhw->inverted_polarity = false;
+ }
+ /* Account for the extra tick at the end of the period */
+ wfhw->period_ticks = period_ticks - 1;
+
+ wfhw->enabled = true;
+
+ return ret;
+}
+
+static int rp1_pwm_round_waveform_fromhw(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ const void *_wfhw,
+ struct pwm_waveform *wf)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ const struct rp1_pwm_waveform *wfhw = _wfhw;
+ u64 clk_rate = rp1->clk_rate;
+ u32 ticks;
+
+ *wf = (struct pwm_waveform){ };
+
+ if (!wfhw->enabled)
+ return 0;
+
+ wf->period_length_ns = DIV_ROUND_UP_ULL((u64)(wfhw->period_ticks + 1) * NSEC_PER_SEC,
+ clk_rate);
+
+ if (!wfhw->inverted_polarity) {
+ wf->duty_length_ns = DIV_ROUND_UP_ULL((u64)wfhw->duty_ticks * NSEC_PER_SEC,
+ clk_rate);
+ } else {
+ ticks = wfhw->period_ticks + 1 - wfhw->duty_ticks;
+ wf->duty_length_ns = DIV_ROUND_UP_ULL((u64)ticks * NSEC_PER_SEC, clk_rate);
+ wf->duty_offset_ns = wf->period_length_ns - wf->duty_length_ns;
+ }
+
+ return 0;
+}
+
+static int rp1_pwm_write_waveform(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ const void *_wfhw)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ const struct rp1_pwm_waveform *wfhw = _wfhw;
+ u32 value, ctrl;
+
+ /* early exit if disabled */
+ regmap_read(rp1->regmap, RP1_PWM_GLB_CTRL, &ctrl);
+ if (!wfhw->enabled) {
+ ctrl &= ~RP1_PWM_GLB_CTRL_CHANNEL_ENABLE(pwm->hwpwm);
+ goto exit_disable;
+ }
+
+ /* set period and duty cycle */
+ regmap_write(rp1->regmap,
+ RP1_PWM_RANGE(pwm->hwpwm), wfhw->period_ticks);
+ regmap_write(rp1->regmap,
+ RP1_PWM_DUTY(pwm->hwpwm), wfhw->duty_ticks);
+
+ /* set polarity */
+ regmap_read(rp1->regmap, RP1_PWM_CHAN_CTRL(pwm->hwpwm), &value);
+ if (!wfhw->inverted_polarity)
+ value &= ~RP1_PWM_CHAN_CTRL_POLARITY;
+ else
+ value |= RP1_PWM_CHAN_CTRL_POLARITY;
+ regmap_write(rp1->regmap, RP1_PWM_CHAN_CTRL(pwm->hwpwm), value);
+
+ /* enable the channel */
+ ctrl |= RP1_PWM_GLB_CTRL_CHANNEL_ENABLE(pwm->hwpwm);
+exit_disable:
+ regmap_write(rp1->regmap, RP1_PWM_GLB_CTRL, ctrl);
+
+ rp1_pwm_apply_config(chip, pwm);
+
+ return 0;
+}
+
+static int rp1_pwm_read_waveform(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ void *_wfhw)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ struct rp1_pwm_waveform *wfhw = _wfhw;
+ u32 value;
+
+ regmap_read(rp1->regmap, RP1_PWM_GLB_CTRL, &value);
+ wfhw->enabled = !!(value & RP1_PWM_GLB_CTRL_CHANNEL_ENABLE(pwm->hwpwm));
+
+ regmap_read(rp1->regmap, RP1_PWM_CHAN_CTRL(pwm->hwpwm), &value);
+ wfhw->inverted_polarity = !!(value & RP1_PWM_CHAN_CTRL_POLARITY);
+
+ if (wfhw->enabled) {
+ regmap_read(rp1->regmap, RP1_PWM_RANGE(pwm->hwpwm), &wfhw->period_ticks);
+ regmap_read(rp1->regmap, RP1_PWM_DUTY(pwm->hwpwm), &wfhw->duty_ticks);
+ } else {
+ wfhw->period_ticks = 0;
+ wfhw->duty_ticks = 0;
+ }
+
+ return 0;
+}
+
+static const struct pwm_ops rp1_pwm_ops = {
+ .sizeof_wfhw = sizeof(struct rp1_pwm_waveform),
+ .request = rp1_pwm_request,
+ .round_waveform_tohw = rp1_pwm_round_waveform_tohw,
+ .round_waveform_fromhw = rp1_pwm_round_waveform_fromhw,
+ .read_waveform = rp1_pwm_read_waveform,
+ .write_waveform = rp1_pwm_write_waveform,
+};
+
+static int rp1_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ unsigned long clk_rate;
+ struct pwm_chip *chip;
+ void __iomem *base;
+ struct rp1_pwm *rp1;
+ int ret;
+
+ chip = devm_pwmchip_alloc(dev, RP1_PWM_NUM_PWMS, sizeof(*rp1));
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ rp1 = pwmchip_get_drvdata(chip);
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ rp1->regmap = devm_regmap_init_mmio(dev, base, &rp1_pwm_regmap_config);
+ if (IS_ERR(rp1->regmap))
+ return dev_err_probe(dev, PTR_ERR(rp1->regmap), "Cannot initialize regmap\n");
+
+ rp1->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(rp1->clk))
+ return dev_err_probe(dev, PTR_ERR(rp1->clk), "Clock not found\n");
+
+ ret = clk_prepare_enable(rp1->clk);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to enable clock\n");
+ rp1->clk_enabled = true;
+
+ ret = devm_clk_rate_exclusive_get(dev, rp1->clk);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to get exclusive rate\n");
+ goto err_disable_clk;
+ }
+
+ clk_rate = clk_get_rate(rp1->clk);
+ if (!clk_rate) {
+ ret = dev_err_probe(dev, -EINVAL, "Failed to get clock rate\n");
+ goto err_disable_clk;
+ }
+ /*
+ * To prevent u64 overflow in period calculations:
+ * mul_u64_u64_div_u64(period_ns, clk_rate, NSEC_PER_SEC)
+ * If clk_rate > 1 GHz, the result can overflow.
+ */
+ if (clk_rate > HZ_PER_GHZ) {
+ ret = dev_err_probe(dev, -EINVAL, "Clock rate > 1 GHz is not supported\n");
+ goto err_disable_clk;
+ }
+ rp1->clk_rate = clk_rate;
+
+ chip->ops = &rp1_pwm_ops;
+
+ platform_set_drvdata(pdev, chip);
+
+ ret = pwmchip_add(chip);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to register PWM chip\n");
+ goto err_disable_clk;
+ }
+
+ ret = of_syscon_register_regmap(np, rp1->regmap);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to register syscon\n");
+ goto err_disable_clk;
+ }
+
+ return 0;
+
+err_disable_clk:
+ clk_disable_unprepare(rp1->clk);
+
+ return ret;
+}
+
+static void rp1_pwm_remove(struct platform_device *pdev)
+{
+ struct pwm_chip *chip = platform_get_drvdata(pdev);
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+
+ pwmchip_remove(chip);
+
+ if (rp1->clk_enabled) {
+ clk_disable_unprepare(rp1->clk);
+ rp1->clk_enabled = false;
+ }
+}
+
+static int rp1_pwm_suspend(struct device *dev)
+{
+ struct pwm_chip *chip = dev_get_drvdata(dev);
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+
+ if (rp1->clk_enabled) {
+ clk_disable_unprepare(rp1->clk);
+ rp1->clk_enabled = false;
+ }
+
+ return 0;
+}
+
+static int rp1_pwm_resume(struct device *dev)
+{
+ struct pwm_chip *chip = dev_get_drvdata(dev);
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ int ret;
+
+ ret = clk_prepare_enable(rp1->clk);
+ if (ret) {
+ dev_err(dev, "Failed to enable clock on resume: %pe\n", ERR_PTR(ret));
+ return ret;
+ }
+
+ rp1->clk_enabled = true;
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(rp1_pwm_pm_ops, rp1_pwm_suspend, rp1_pwm_resume);
+
+static const struct of_device_id rp1_pwm_of_match[] = {
+ { .compatible = "raspberrypi,rp1-pwm" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rp1_pwm_of_match);
+
+static struct platform_driver rp1_pwm_driver = {
+ .probe = rp1_pwm_probe,
+ .remove = rp1_pwm_remove,
+ .driver = {
+ .name = "rp1-pwm",
+ .of_match_table = rp1_pwm_of_match,
+ .pm = pm_ptr(&rp1_pwm_pm_ops),
+ .suppress_bind_attrs = true,
+ },
+};
+builtin_platform_driver(rp1_pwm_driver);
+
+MODULE_DESCRIPTION("RP1 PWM driver");
+MODULE_AUTHOR("Naushir Patuck <naush@raspberrypi.com>");
+MODULE_AUTHOR("Andrea della Porta <andrea.porta@suse.com>");
+MODULE_LICENSE("GPL");
--
2.35.3
^ permalink raw reply related
* [PATCH v4 3/3] arm64: dts: broadcom: rpi-5: Add RP1 PWM node
From: Andrea della Porta @ 2026-06-03 15:27 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <cover.1780498640.git.andrea.porta@suse.com>
From: Stanimir Varbanov <svarbanov@suse.de>
The RP1 chipset used on the Raspberry Pi 5 features an integrated
PWM controller to drive the cooling fan.
Add the corresponding DT node for this PWM controller.
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Co-developed-by: Andrea della Porta <andrea.porta@suse.com>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts | 12 ++++++++++++
arch/arm64/boot/dts/broadcom/rp1-common.dtsi | 9 +++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts
index 0fc57e72632ed..748be8f1ee9e2 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts
@@ -64,6 +64,12 @@ phy1: ethernet-phy@1 {
};
&rp1_gpio {
+ fan_pwm_default_state: fan-pwm-default-state {
+ function = "pwm1";
+ pins = "gpio45";
+ bias-pull-down;
+ };
+
usb_vbus_default_state: usb-vbus-default-state {
function = "vbus1";
groups = "vbus1";
@@ -94,6 +100,12 @@ &rp1_i2c6 {
pinctrl-names = "default";
};
+&rp1_pwm1 {
+ pinctrl-0 = <&fan_pwm_default_state>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&rp1_usb0 {
pinctrl-0 = <&usb_vbus_default_state>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
index 16f5359395835..df4c2d09c8d34 100644
--- a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
+++ b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
@@ -99,7 +99,16 @@ rp1_i2c6: i2c@40088000 {
clocks = <&rp1_clocks RP1_CLK_SYS>;
i2c-scl-rising-time-ns = <65>;
i2c-scl-falling-time-ns = <100>;
+ status = "disabled";
+ };
+ rp1_pwm1: pwm@4009c000 {
+ compatible = "raspberrypi,rp1-pwm";
+ reg = <0x00 0x4009c000 0x0 0x100>;
+ clocks = <&rp1_clocks RP1_CLK_PWM1>;
+ assigned-clocks = <&rp1_clocks RP1_CLK_PWM1>;
+ assigned-clock-rates = <50000000>;
+ #pwm-cells = <3>;
status = "disabled";
};
--
2.35.3
^ permalink raw reply related
* [PATCH v4 0/3] Add RP1 PWM controller support
From: Andrea della Porta @ 2026-06-03 15:27 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
This patchset adds support for the PWM controller found on the
Raspberry Pi RP1 southbridge. This is necessary to operate the
cooling fan connected to one of the PWM channels.
The tachometer pin for the fan speed is managed by the firmware
running on the RP1's M-core. It uses the PHASE2 register
to report the RPM, which is then exported by this driver via
syscon registers. A subsequent patch will add a new device
and driver to read the RPM and export this value via hwmon.
Subsequent patches will also add the CPU thermal zone, which
acts as a consumer of the PWM device.
Best regards,
Andrea
CHANGES in V4:
- s/rp1_pwm/rp1_pwm1/ in the DTS, so adding rp1_pwm0 in the
future will be unambiguous
- the driver can now be compiled as module. Since it cannot
be unloaded (due to syscon registration), substitute
builtin_platform_driver for module_platform_driver.
- preserved the polarity bit when setting up the channel on
rp1_pwm_request()
- rp1_pwm_round_waveform_tohw(): capped duty_ticks to be no
more than period_ticks, and adjusted offset_ticks
accordingly (best effort)
- the syscon registration is moved at the end of the probe
function, to avoid leaking if the probing bail out
prematurely
- fixed the erroneous casting about pwm_chip/rp1_pwm struct
in suspend/resume functions.
Naushir Patuck (2):
dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
pwm: rp1: Add RP1 PWM controller driver
Stanimir Varbanov (1):
arm64: dts: broadcom: rpi-5: Add RP1 PWM node
.../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++
.../boot/dts/broadcom/bcm2712-rpi-5-b.dts | 12 +
arch/arm64/boot/dts/broadcom/rp1-common.dtsi | 9 +
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-rp1.c | 422 ++++++++++++++++++
6 files changed, 507 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
create mode 100644 drivers/pwm/pwm-rp1.c
--
2.35.3
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-06-03 15:27 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
Cc: Krzysztof Kozlowski
In-Reply-To: <cover.1780498640.git.andrea.porta@suse.com>
From: Naushir Patuck <naush@raspberrypi.com>
Add the devicetree binding documentation for the PWM
controller found in the Raspberry Pi RP1 chipset.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Referring to the first comment from:
https://sashiko.dev/#/patchset/cover.1776932336.git.andrea.porta%40suse.com
regarding the DT-bindings, #pwm-cells is not required here because
that requirement is inherited from the referenced pwm.yaml
---
.../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
new file mode 100644
index 0000000000000..6f8461d0454f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/raspberrypi,rp1-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi RP1 PWM controller
+
+maintainers:
+ - Naushir Patuck <naush@raspberrypi.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+description: |
+ The PWM peripheral is a flexible waveform generator with a
+ variety of operational modes. It has the following features:
+ - four independent output channels
+ - 32-bit counter widths
+ - Seven output generation modes
+ - Optional per-channel output inversion
+ - Optional duty-cycle data FIFO with DMA support
+ - Optional sigma-delta noise shaping engine
+ Serves as a fan speed provider to other nodes for a PWM-connected
+ fan using shared registers (syscon).
+
+properties:
+ compatible:
+ const: raspberrypi,rp1-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@98000 {
+ compatible = "raspberrypi,rp1-pwm";
+ reg = <0x98000 0x100>;
+ clocks = <&rp1_clocks 17>;
+ #pwm-cells = <3>;
+ };
--
2.35.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox