* [PATCH v5 04/13] arm64: mm: Preserve non-contiguous descriptors when mapping DRAM
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Instead of blindly overwriting existing live entries with the contiguous
bit cleared when mapping DRAM regions, check whether the contiguous
region in question starts with a descriptor that has the valid bit set
and the contiguous bit cleared, and in that case, leave the contiguous
bit unset on the entire region. This permits the logic of mapping the
kernel's linear alias to be simplified in a subsequent patch.
Note that not setting the contiguous bit on any of the descriptors in
the contiguous region can only result in an invalid configuration if it
was already invalid to begin with.
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/include/asm/pgtable.h | 4 ++++
arch/arm64/mm/mmu.c | 6 ++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4dfa42b7d053..a1c5894332d9 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -181,6 +181,10 @@ 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 bd2764f02a7d..4c6ef0d35714 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -224,7 +224,8 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
/* use a contiguous mapping if the range is suitably aligned */
if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
- (flags & NO_CONT_MAPPINGS) == 0)
+ (flags & NO_CONT_MAPPINGS) == 0 &&
+ !pte_valid_noncont(__ptep_get(ptep)))
__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
init_pte(ptep, addr, next, phys, __prot);
@@ -324,7 +325,8 @@ static int alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
/* use a contiguous mapping if the range is suitably aligned */
if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
- (flags & NO_CONT_MAPPINGS) == 0)
+ (flags & NO_CONT_MAPPINGS) == 0 &&
+ !pte_valid_noncont(pmd_pte(READ_ONCE(*pmdp))))
__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
ret = init_pmd(pmdp, addr, next, phys, __prot, pgtable_alloc, flags);
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 06/13] arm64: mm: Drop redundant pgd_t* argument from map_mem()
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening, Kevin Brodsky
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
__map_memblock() and map_mem() always operate on swapper_pg_dir, so
there is no need to pass around a pgd_t pointer between them.
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 26 ++++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index cd841a392b44..0405fac18959 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1039,11 +1039,11 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
flush_tlb_kernel_range(virt, virt + size);
}
-static void __init __map_memblock(pgd_t *pgdp, phys_addr_t start,
- phys_addr_t end, pgprot_t prot, int flags)
+static void __init __map_memblock(phys_addr_t start, phys_addr_t end,
+ pgprot_t prot, int flags)
{
- early_create_pgd_mapping(pgdp, start, __phys_to_virt(start), end - start,
- prot, early_pgtable_alloc, flags);
+ early_create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
+ end - start, prot, early_pgtable_alloc, flags);
}
void __init mark_linear_text_alias_ro(void)
@@ -1091,13 +1091,13 @@ static phys_addr_t __init arm64_kfence_alloc_pool(void)
return kfence_pool;
}
-static void __init arm64_kfence_map_pool(phys_addr_t kfence_pool, pgd_t *pgdp)
+static void __init arm64_kfence_map_pool(phys_addr_t kfence_pool)
{
if (!kfence_pool)
return;
/* KFENCE pool needs page-level mapping. */
- __map_memblock(pgdp, kfence_pool, kfence_pool + KFENCE_POOL_SIZE,
+ __map_memblock(kfence_pool, kfence_pool + KFENCE_POOL_SIZE,
pgprot_tagged(PAGE_KERNEL),
NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
memblock_clear_nomap(kfence_pool, KFENCE_POOL_SIZE);
@@ -1133,11 +1133,11 @@ bool arch_kfence_init_pool(void)
#else /* CONFIG_KFENCE */
static inline phys_addr_t arm64_kfence_alloc_pool(void) { return 0; }
-static inline void arm64_kfence_map_pool(phys_addr_t kfence_pool, pgd_t *pgdp) { }
+static inline void arm64_kfence_map_pool(phys_addr_t kfence_pool) { }
#endif /* CONFIG_KFENCE */
-static void __init map_mem(pgd_t *pgdp)
+static void __init map_mem(void)
{
static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN);
phys_addr_t kernel_start = __pa_symbol(_text);
@@ -1182,7 +1182,7 @@ static void __init map_mem(pgd_t *pgdp)
* if MTE is present. Otherwise, it has the same attributes as
* PAGE_KERNEL.
*/
- __map_memblock(pgdp, start, end, pgprot_tagged(PAGE_KERNEL),
+ __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
@@ -1196,10 +1196,10 @@ static void __init map_mem(pgd_t *pgdp)
* Note that contiguous mappings cannot be remapped in this way,
* so we should avoid them here.
*/
- __map_memblock(pgdp, kernel_start, kernel_end,
- pgprot_tagged(PAGE_KERNEL), NO_CONT_MAPPINGS);
+ __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
+ NO_CONT_MAPPINGS);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
- arm64_kfence_map_pool(early_kfence_pool, pgdp);
+ arm64_kfence_map_pool(early_kfence_pool);
}
void mark_rodata_ro(void)
@@ -1421,7 +1421,7 @@ static void __init create_idmap(void)
void __init paging_init(void)
{
- map_mem(swapper_pg_dir);
+ map_mem();
memblock_allow_resize();
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 07/13] arm64: mm: Permit contiguous descriptors to be rewritten
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Currently, pgattr_change_is_safe() is overly pedantic when it comes to
descriptors with the contiguous hint attribute set, as it rejects
assignments even if the old and the new value are the same.
So relax the check to allow that.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 0405fac18959..7cecd25aa83b 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -134,10 +134,6 @@ bool pgattr_change_is_safe(pteval_t old, pteval_t new)
if (pte_pfn(__pte(old)) != pte_pfn(__pte(new)))
return false;
- /* live contiguous mappings may not be manipulated at all */
- if ((old | new) & PTE_CONT)
- return false;
-
/* Transitioning from Non-Global to Global is unsafe */
if (old & ~new & PTE_NG)
return false;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 09/13] arm64: mm: Permit contiguous attribute for preliminary mappings
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
There are a few cases where we omit the contiguous hint for mappings
that start out as read-write and are remapped read-only later, on the
basis that manipulating live descriptors with the PTE_CONT attribute set
is unsafe. When support for the contiguous hint was added to the code,
the ARM ARM was ambiguous about this, and so we erred on the side of
caution.
In the meantime, this has been clarified [0], and regions that will be
remapped in their entirety can use the contiguous hint both in the
initial mapping as well as the one that replaces it. Note that this
requires that the logic that may be called to remap overlapping regions
respects existing valid descriptors that have the contiguous bit
cleared.
So omit the NO_CONT_MAPPINGS flag in places where it is unneeded.
Thanks to Ryan for the reference.
[0] RJQQTC
For a TLB lookup in a contiguous region mapped by translation table entries that
have consistent values for the Contiguous bit, but have the OA, attributes, or
permissions misprogrammed, that TLB lookup is permitted to produce an OA, access
permissions, and memory attributes that are consistent with any one of the
programmed translation table values.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 224fec6ce9d7..d4ad9e4766a6 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1000,8 +1000,7 @@ void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
&phys, virt);
return;
}
- early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
- NO_CONT_MAPPINGS);
+ early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL, 0);
}
void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
@@ -1028,8 +1027,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
return;
}
- early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
- NO_CONT_MAPPINGS);
+ early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL, 0);
/* flush the TLBs after updating live kernel mappings */
flush_tlb_kernel_range(virt, virt + size);
@@ -1175,11 +1173,8 @@ static void __init map_mem(void)
* alternative patching has completed). This makes the contents
* of the region accessible to subsystems such as hibernate,
* but protects it from inadvertent modification or execution.
- * Note that contiguous mappings cannot be remapped in this way,
- * so we should avoid them here.
*/
- __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
- NO_CONT_MAPPINGS);
+ __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL), 0);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
}
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 11/13] arm64: mm: Don't abuse memblock NOMAP to check for overlaps
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Now that the DRAM mapping routines respect existing table mappings and
contiguous block and page mappings, it is no longer needed to fiddle
with the memblock tables to set and clear the NOMAP attribute in order
to omit text and rodata when creating the linear map.
Instead, map the kernel text and rodata alias first with the desired
attributes, so that they will not be remapped later with different
attributes when mapping the memblocks.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 24 +++++++-------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index d4ad9e4766a6..dcff1a538f20 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1148,12 +1148,15 @@ static void __init map_mem(void)
flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
/*
- * Take care not to create a writable alias for the
- * read-only text and rodata sections of the kernel image.
- * So temporarily mark them as NOMAP to skip mappings in
- * the following for-loop
+ * Map the linear alias of the [_text, __init_begin) interval
+ * as non-executable now, and remove the write permission in
+ * mark_linear_text_alias_ro() above (which will be called after
+ * alternative patching has completed). This makes the contents
+ * of the region accessible to subsystems such as hibernate,
+ * but protects it from inadvertent modification or execution.
*/
- memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
+ __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
+ flags);
/* map all the memory banks */
for_each_mem_range(i, &start, &end) {
@@ -1165,17 +1168,6 @@ static void __init map_mem(void)
__map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
-
- /*
- * Map the linear alias of the [_text, __init_begin) interval
- * as non-executable now, and remove the write permission in
- * mark_linear_text_alias_ro() below (which will be called after
- * alternative patching has completed). This makes the contents
- * of the region accessible to subsystems such as hibernate,
- * but protects it from inadvertent modification or execution.
- */
- __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL), 0);
- memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 13/13] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
The linear aliases of the kernel text and rodata are mapped read-only in
the linear map as well. Given that the contents of these regions are
mostly identical to the version in the loadable image, mapping them
read-only and leaving their contents visible is a reasonable hardening
measure.
Data and bss, however, are now also mapped read-only but the contents of
these regions are more likely to contain data that we'd rather not leak.
So let's unmap these entirely in the linear map when the kernel is
running normally.
When going into hibernation or waking up from it, these regions need to
be mapped, so map the region initially, and toggle the valid bit so
map/unmap the region as needed. (While the hibernation snapshot logic
seems able to map inaccessible pages as needed, it currently disregards
non-present pages entirely.)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 39 +++++++++++++++++---
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 136cfe0f7375..9b6d90deb6d5 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -24,6 +24,7 @@
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/set_memory.h>
+#include <linux/suspend.h>
#include <linux/kfence.h>
#include <linux/pkeys.h>
#include <linux/mm_inline.h>
@@ -1040,6 +1041,29 @@ static void __init __map_memblock(phys_addr_t start, phys_addr_t end,
end - start, prot, early_pgtable_alloc, flags);
}
+static void remap_linear_data_alias(bool unmap)
+{
+ set_memory_valid((unsigned long)lm_alias(__init_end),
+ (unsigned long)(__bss_stop - __init_end) / PAGE_SIZE,
+ !unmap);
+}
+
+static int arm64_hibernate_pm_notify(struct notifier_block *nb,
+ unsigned long mode, void *unused)
+{
+ switch (mode) {
+ default:
+ break;
+ case PM_POST_HIBERNATION:
+ remap_linear_data_alias(true);
+ break;
+ case PM_HIBERNATION_PREPARE:
+ remap_linear_data_alias(false);
+ break;
+ }
+ return 0;
+}
+
void __init mark_linear_text_alias_ro(void)
{
/*
@@ -1048,6 +1072,16 @@ void __init mark_linear_text_alias_ro(void)
update_mapping_prot(__pa_symbol(_text), (unsigned long)lm_alias(_text),
(unsigned long)__init_begin - (unsigned long)_text,
PAGE_KERNEL_RO);
+
+ remap_linear_data_alias(true);
+
+ if (IS_ENABLED(CONFIG_HIBERNATION)) {
+ static struct notifier_block nb = {
+ .notifier_call = arm64_hibernate_pm_notify
+ };
+
+ register_pm_notifier(&nb);
+ }
}
#ifdef CONFIG_KFENCE
@@ -1174,11 +1208,6 @@ static void __init map_mem(void)
__map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
-
- /* Map the kernel data/bss read-only in the linear map */
- __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
- flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
- (unsigned long)lm_alias(__bss_stop));
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 08/13] arm64: kfence: Avoid NOMAP tricks when mapping the early pool
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Now that the map_mem() routines respect existing page mappings and
contiguous granule sized blocks with the contiguous bit cleared, there
is no longer a reason to play tricks with the memblock NOMAP attribute.
Instead, the kfence pool can be allocated and mapped with page
granularity first, and this granularity will be respected when the rest
of DRAM is mapped later, even if block and contiguous mappings are
allowed for the remainder of those mappings.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 25 ++++----------------
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7cecd25aa83b..224fec6ce9d7 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1067,36 +1067,24 @@ static int __init parse_kfence_early_init(char *arg)
}
early_param("kfence.sample_interval", parse_kfence_early_init);
-static phys_addr_t __init arm64_kfence_alloc_pool(void)
+static void __init arm64_kfence_map_pool(void)
{
phys_addr_t kfence_pool;
if (!kfence_early_init)
- return 0;
+ return;
kfence_pool = memblock_phys_alloc(KFENCE_POOL_SIZE, PAGE_SIZE);
if (!kfence_pool) {
pr_err("failed to allocate kfence pool\n");
kfence_early_init = false;
- return 0;
- }
-
- /* Temporarily mark as NOMAP. */
- memblock_mark_nomap(kfence_pool, KFENCE_POOL_SIZE);
-
- return kfence_pool;
-}
-
-static void __init arm64_kfence_map_pool(phys_addr_t kfence_pool)
-{
- if (!kfence_pool)
return;
+ }
/* KFENCE pool needs page-level mapping. */
__map_memblock(kfence_pool, kfence_pool + KFENCE_POOL_SIZE,
pgprot_tagged(PAGE_KERNEL),
NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
- memblock_clear_nomap(kfence_pool, KFENCE_POOL_SIZE);
__kfence_pool = phys_to_virt(kfence_pool);
}
@@ -1128,8 +1116,7 @@ bool arch_kfence_init_pool(void)
}
#else /* CONFIG_KFENCE */
-static inline phys_addr_t arm64_kfence_alloc_pool(void) { return 0; }
-static inline void arm64_kfence_map_pool(phys_addr_t kfence_pool) { }
+static inline void arm64_kfence_map_pool(void) { }
#endif /* CONFIG_KFENCE */
@@ -1139,7 +1126,6 @@ static void __init map_mem(void)
phys_addr_t kernel_start = __pa_symbol(_text);
phys_addr_t kernel_end = __pa_symbol(__init_begin);
phys_addr_t start, end;
- phys_addr_t early_kfence_pool;
int flags = NO_EXEC_MAPPINGS;
u64 i;
@@ -1156,7 +1142,7 @@ static void __init map_mem(void)
BUILD_BUG_ON(pgd_index(direct_map_end - 1) == pgd_index(direct_map_end) &&
pgd_index(_PAGE_OFFSET(VA_BITS_MIN)) != PTRS_PER_PGD - 1);
- early_kfence_pool = arm64_kfence_alloc_pool();
+ arm64_kfence_map_pool();
linear_map_requires_bbml2 = !force_pte_mapping() && can_set_direct_map();
@@ -1195,7 +1181,6 @@ static void __init map_mem(void)
__map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
NO_CONT_MAPPINGS);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
- arm64_kfence_map_pool(early_kfence_pool);
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH 06/16] media: v4l2-common: Add missing tiled format info block sizes
From: Nicolas Dufresne @ 2026-05-19 15:18 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-7-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> Some YUV420 tiled format info definitions are missing block sizes.
> Add the missing block sizes (they are all 4x4).
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 77a0daa92c2b..e142d40c71b9 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -307,10 +307,12 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
>
> /* Tiled YUV formats */
> - { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
> + { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
.block_w = { 4, 2, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> { .format = V4L2_PIX_FMT_NV15_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> - { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
> + { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
.block_w = { 4, 2, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
This one is speecial, this format does not exists. I believe Jernej made that
one based on assumptions, the actual HW should produce NV15 4L4, but I don't own
that hardware, and so I never managed remove that last "user" of it, which is I
believe H6 VP9 decoder.
Nicolas
>
> /* YUV planar formats, non contiguous variant */
> { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v5 10/13] arm64: Move fixmap page tables to end of kernel image
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening, Kevin Brodsky
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Move the fixmap page tables out of the BSS section, and place them at
the end of the image, right before the init_pg_dir section where some of
the other statically allocated page tables live.
These page tables are currently the only data objects in vmlinux that
are meant to be accessed via the kernel image's linear alias, and so
placing them together allows the remainder of the data/bss section to be
remapped read-only or unmapped entirely.
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/kernel/vmlinux.lds.S | 10 ++++++++--
arch/arm64/mm/fixmap.c | 7 ++++---
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index e1ac876200a3..64c7bf4b7176 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -349,10 +349,16 @@ SECTIONS
_edata = .;
/* start of zero-init region */
- BSS_SECTION(SBSS_ALIGN, 0, 0)
+ BSS_SECTION(SBSS_ALIGN, 0, PAGE_SIZE)
__pi___bss_start = __bss_start;
- . = ALIGN(PAGE_SIZE);
+ /* fixmap BSS starts here - preceding data/BSS is omitted from the linear map */
+ .fixmap_pgdir : ALIGN(PAGE_SIZE) {
+ *(.fixmap_bss)
+ }
+ ASSERT(ADDR(.fixmap_pgdir) == __bss_stop, ".fixmap_pgdir should follow BSS")
+
+
__pi_init_pg_dir = .;
. += INIT_DIR_SIZE;
__pi_init_pg_end = .;
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index c5c5425791da..b649ea1a46e4 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -31,9 +31,10 @@ 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] __page_aligned_bss;
-static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss __maybe_unused;
-static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
+#define __fixmap_bss __section(".fixmap_bss") __aligned(PAGE_SIZE)
+static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __fixmap_bss;
+static pmd_t bm_pmd[PTRS_PER_PMD] __fixmap_bss __maybe_unused;
+static pud_t bm_pud[PTRS_PER_PUD] __fixmap_bss __maybe_unused;
static inline pte_t *fixmap_pte(unsigned long addr)
{
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 12/13] arm64: mm: Map the kernel data/bss read-only in the linear map
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
On systems where the bootloader adheres to the original arm64 boot
protocol, the placement of the kernel in the physical address space is
highly predictable, and this makes the placement of its linear alias in
the kernel virtual address space equally predictable, given the lack of
randomization of the linear map.
The linear aliases of the kernel text and rodata regions are already
mapped read-only, but the kernel data and bss are mapped read-write in
this region. This is not needed, so map them read-only as well.
Note that the statically allocated kernel page tables do need to be
modifiable via the linear map, so leave these mapped read-write.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dcff1a538f20..136cfe0f7375 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1122,7 +1122,9 @@ static void __init map_mem(void)
{
static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN);
phys_addr_t kernel_start = __pa_symbol(_text);
- phys_addr_t kernel_end = __pa_symbol(__init_begin);
+ phys_addr_t init_begin = __pa_symbol(__init_begin);
+ phys_addr_t init_end = __pa_symbol(__init_end);
+ phys_addr_t kernel_end = __pa_symbol(__bss_stop);
phys_addr_t start, end;
int flags = NO_EXEC_MAPPINGS;
u64 i;
@@ -1155,7 +1157,11 @@ static void __init map_mem(void)
* of the region accessible to subsystems such as hibernate,
* but protects it from inadvertent modification or execution.
*/
- __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
+ __map_memblock(kernel_start, init_begin, pgprot_tagged(PAGE_KERNEL),
+ flags);
+
+ /* Map the kernel data/bss so it can be remapped later */
+ __map_memblock(init_end, kernel_end, pgprot_tagged(PAGE_KERNEL),
flags);
/* map all the memory banks */
@@ -1168,6 +1174,11 @@ static void __init map_mem(void)
__map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
+
+ /* Map the kernel data/bss read-only in the linear map */
+ __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
+ flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
+ (unsigned long)lm_alias(__bss_stop));
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH v7 04/23] drm: bridge: dw_hdmi: Hold bridge ref until connector cleanup
From: Jonas Karlman @ 2026-05-19 15:18 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Heiko Stuebner,
Laurent Pinchart, Jernej Skrabec, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Cristian Ciocaltea, Louis Chauvet, Liu Ying, Sandy Huang,
Andy Yan, Chen-Yu Tsai, Christian Hewitt, Diederik de Haas,
Nicolas Frattaroli, Dmitry Baryshkov, dri-devel, linux-arm-kernel,
linux-rockchip, linux-amlogic, linux-sunxi, imx, linux-kernel
In-Reply-To: <177919241969.545972.18169905222569864569.b4-review@b4>
Hello Luca,
On 5/19/2026 2:06 PM, Luca Ceresoli wrote:
> On Mon, 18 May 2026 18:01:40 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
>
> Hello Jonas,
>
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index b7bfc0e9a6b2..9d795c550f8a 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2600,10 +2609,14 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
>>
>> drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
>>
>> - drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
>> - &dw_hdmi_connector_funcs,
>> - DRM_MODE_CONNECTOR_HDMIA,
>> - hdmi->ddc);
>> + ret = drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
>> + &dw_hdmi_connector_funcs,
>> + DRM_MODE_CONNECTOR_HDMIA,
>> + hdmi->ddc);
>> + if (ret)
>> + return ret;
>> +
>> + drm_bridge_get(&hdmi->bridge);
>
> I'm not fully following the code paths, but both the report and the fix
> make sense to me. Only I'd move the drm_bridge_get() before
> drm_connector_init_with_ddc(), to avoid a short window where no reference
> is held and the bridge might be destroyed before drm_bridge_get() is
> called. I'm not sure this can happen, but it's better to write the code in
> a way that clearly makes it impossible.
dw_hdmi_connector_create() is only called from dw_hdmi_bridge_attach()
so the bridge should already have a ref for the lifetime of this call.
I explicitly chose the placement after drm_connector_init_with_ddc()
to ensure ref count is correctly balanced without having to add a
drm_bridge_put() call in any error path. I.e. connector destroy() is
only called when drm_connector_init_with_ddc() succeeds.
This code/call is also planned to be removed in a future series, so I do
not think moving drm_bridge_get() is necessary unless you think we need
to protect against possible bad behavior from DRM core?
Regards,
Jonas
>
> Otherwise looks good.
>
> Luca
>
^ permalink raw reply
* Re: [PATCH v4 0/5] nvmem: Add Raspberry Pi OTP nvmem driver
From: Gregor Herburger @ 2026-05-19 15:20 UTC (permalink / raw)
To: Stefan Wahren
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Srinivas Kandagatla, Kees Cook, Gustavo A. R. Silva,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening
In-Reply-To: <d9e3e10a-c346-4391-b133-4b60fbee5dc3@gmx.net>
On Tue, May 19, 2026 at 04:55:10PM +0200, Stefan Wahren wrote:
> Hi Gregor,
>
> Am 08.05.26 um 16:42 schrieb Gregor Herburger:
> > Hi,
> >
> > This series adds support for the Raspberry Pis OTP registers. The
> > Raspberry Pi has one or more OTP regions. These registers are accessible
> > through the firmware. Add a driver for it and add updates the devicetree
> > for the Raspberry Pi 5.
> >
> > ---
> > Changes in v4:
> > - Additional patch to drop unnecessary select schema
> > - fix dt-bindings
> > - use __counted_by_le
> > - additional alignment check in read/write callbacks
> > - Link to v3: https://patch.msgid.link/20260506-rpi-otp-driver-v3-0-294602663695@linutronix.de
> >
> > Changes in v3:
> > - dts: add "raspberrypi,bcm2835-firmware" as fallback and fix dt-bindings
> > - Fix Kconfig depends
> > - Changed firmware data fields to __le32
> > - Add MODULE_ALIAS
> > - Link to v2: https://patch.msgid.link/20260505-rpi-otp-driver-v2-0-e9176ec72837@linutronix.de
> >
> > Changes in v2:
> > - register nvmem driver from firmware driver and drop firmware sub nodes
> > - Use struct_size and __counted_by for dynamic array
> > - Drop unneeded comment in Kconfig
> > - Use NVMEM_DEVID_NONE
> > - Use kzalloc
> > - Update module description
> > - Link to v1: https://patch.msgid.link/20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de
> >
> > ---
> > Gregor Herburger (5):
> > dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
> > nvmem: Add the Raspberry Pi OTP driver
> > firmware: raspberrypi: register nvmem driver
> > arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
> > dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
> >
> > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 ++--
> > .../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +-
> > drivers/firmware/raspberrypi.c | 59 +++++++++-
> > drivers/nvmem/Kconfig | 10 ++
> > drivers/nvmem/Makefile | 1 +
> > drivers/nvmem/raspberrypi-otp.c | 130 +++++++++++++++++++++
> > include/soc/bcm2835/raspberrypi-firmware.h | 14 +++
> > 7 files changed, 224 insertions(+), 14 deletions(-)
> since you plan to submit a V5 of this series, could you please append
> another patch to enable the driver as module for arm64/defconfig?
Good Idea, will add it.
Gregor
^ permalink raw reply
* Re: (subset) [PATCH v8 0/4] backlight: add new max25014 backlight driver
From: Frank.Li @ 2026-05-19 15:22 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Maud Spierings
Cc: Frank Li, dri-devel, linux-leds, devicetree, linux-kernel,
linux-fbdev, imx, linux-arm-kernel
In-Reply-To: <20260407-max25014-v8-0-14eac7ed673a@gocontroll.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 07 Apr 2026 16:41:41 +0200, Maud Spierings wrote:
> The Maxim MAX25014 is an automotive grade backlight driver IC. Its
> datasheet can be found at [1].
>
> With its integrated boost controller, it can power 4 channels (led
> strings) and has a number of different modes using pwm and or i2c.
> Currently implemented is only i2c control.
>
> [...]
Applied, thanks!
[3/4] arm64: dts: freescale: moduline-display-av101hdt-a10: add backlight
commit: 10fd5ba8fae66d60c65ec4bdb51fbbe5e34d9d83
[4/4] arm64: dts: freescale: moduline-display-av123z7m-n17: add backlight
commit: 159746425710c94befb317132816f5eece4ea25d
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 07/16] media: v4l2-common: Add NV12_16L16 pixel format to v4l2 format info
From: Nicolas Dufresne @ 2026-05-19 15:22 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-8-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> Represent the NV12_16L16 pixel format in the v4l2 format info table.
> This is a 16x16 tiled version of NV12.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index e142d40c71b9..6194d6eb9c56 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -313,6 +313,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> + { .format = V4L2_PIX_FMT_NV12_16L16, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 16, 16, 0, 0 }, .block_h = { 16, 16, 0, 0 }},
I suspect this is:
+ { .format = V4L2_PIX_FMT_NV12_16L16, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
+ .block_w = { 16, 8, 0, 0 }, .block_h = { 16, 16, 0, 0 }},
This was introduced for the Samsung MFC decoders on Exynos 5, has been matched
to V4L2_PIX_FMT_HM12, but I don't how it was tested though. But in this erra,
all the tiling was fixes dimensions in bytes, where your definition would make
the UV tiles twice the size of Y tiles.
Nicolas
>
> /* YUV planar formats, non contiguous variant */
> { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/6] Devicetree support for Glymur GPU
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Robin Murphy, Joerg Roedel, Akhil P Oommen
Cc: catalin.marinas, kernel-team, Will Deacon, linux-arm-msm,
devicetree, linux-kernel, dri-devel, freedreno, linux-arm-kernel,
iommu, Rajendra Nayak, Konrad Dybcio, Dmitry Baryshkov,
Manaf Meethalavalappu Pallikunhi
In-Reply-To: <20260513-glymur-gpu-dt-v4-0-f83832c3bc9a@oss.qualcomm.com>
On Wed, 13 May 2026 00:51:17 +0530, Akhil P Oommen wrote:
> This series adds the necessary Device Tree bits to enable GPU support
> on the Glymur-based CRD devices. The Adreno X2-85 GPU present in Glymur
> chipsets is based on the new Adreno A8x family of GPUs. It features a new
> slice architecture with 4 slices, significantly higher bandwidth
> throughput compared to mobile counterparts, raytracing support, and the
> highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among other
> improvements.
>
> [...]
Applied SMMU bindings update to iommu (arm/smmu/bindings), thanks!
[3/6] dt-bindings: arm-smmu: Update the description for Glymur GPU SMMU
https://git.kernel.org/iommu/c/23bc2dd17b20
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v3] iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Rob Clark, Robin Murphy, Joerg Roedel, Anna Maniscalco
Cc: catalin.marinas, kernel-team, Will Deacon, iommu, linux-arm-msm,
linux-arm-kernel, linux-kernel, Rob Clark
In-Reply-To: <20260507-qcom_smmu_pmfix-v3-1-af8cd05831a2@gmail.com>
On Thu, 07 May 2026 17:43:15 +0200, Anna Maniscalco wrote:
> arm_smmu_write_context_bank() assumes it is being called with RPM
> active, but it turns out that is not guaranteed in the path from
> qcom_adreno_smmu_set_ttbr0_cfg(), so it's possible for the register
> writes to get lost when configuring the context bank while the GPU is
> idle, leading to page faults later.
> Add the RPM calls here to make sure the SMMU is active before we touch
> it.
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg
https://git.kernel.org/iommu/c/8a0aab012b52
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] arm64/mm: Replace BUG_ON() with VM_WARN_ON_ONCE()
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: linux-arm-kernel, Anshuman Khandual
Cc: catalin.marinas, kernel-team, Will Deacon, Ryan Roberts,
David Hildenbrand, linux-kernel
In-Reply-To: <20260430053859.890613-1-anshuman.khandual@arm.com>
On Thu, 30 Apr 2026 06:38:59 +0100, Anshuman Khandual wrote:
> Avoid BUG_ON() while checking for inconsistent page table state conditions
> and instead replace them with VM_WARN_ON_ONCE().
>
>
Applied to arm64 (for-next/mm), thanks!
[1/1] arm64/mm: Replace BUG_ON() with VM_WARN_ON_ONCE()
https://git.kernel.org/arm64/c/13d0fdc09016
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 08/16] media: v4l2-common: Add NV12_32L32 pixel format to v4l2 format info
From: Nicolas Dufresne @ 2026-05-19 15:23 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-9-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> Represent the NV12_32L32 pixel format in the v4l2 format info table.
> This is a 32x32 tiled version of NV12.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 6194d6eb9c56..fe7141883ec5 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -315,6 +315,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> { .format = V4L2_PIX_FMT_NV12_16L16, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 16, 16, 0, 0 }, .block_h = { 16, 16, 0, 0 }},
> + { .format = V4L2_PIX_FMT_NV12_32L32, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 32, 32, 0, 0 }, .block_h = { 32, 32, 0, 0 }},
Same.
+ { .format = V4L2_PIX_FMT_NV12_32L32, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
+ .block_w = { 32, 16, 0, 0 }, .block_h = { 32, 32, 0, 0 }},
>
> /* YUV planar formats, non contiguous variant */
> { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update HiSilicon PMU driver maintainer to Yushan Wang
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Yushan Wang, Jie Zhan, Mark Rutland, linux-arm-kernel,
linux-perf-users, Jonathan Cameron
Cc: catalin.marinas, kernel-team, Will Deacon, linuxarm
In-Reply-To: <20260416095110.25612-1-Jonathan.Cameron@huawei.com>
On Thu, 16 Apr 2026 10:51:10 +0100, Jonathan Cameron wrote:
> Replace myself with Yushan Wang who is very familiar with the HiSilicon PMU
> drivers.
>
>
Applied to will (for-next/perf), thanks!
[1/1] MAINTAINERS: Update HiSilicon PMU driver maintainer to Yushan Wang
https://git.kernel.org/will/c/dbd7d67b1318
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/9] Remove SMMUv3 struct arm_smmu_cmdq_ent
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Jason Gunthorpe
Cc: catalin.marinas, kernel-team, Will Deacon, David Matlack,
Nicolin Chen, Pasha Tatashin, patches, Pranjal Shrivastava,
Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <0-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, 13 May 2026 20:57:39 -0300, Jason Gunthorpe wrote:
> [ This is part of the patch pile to move SMMUv3 over to the generic page
> table:
> 1) Introduction of new gather items and RISCV usage
> https://patch.msgid.link/r/0-v2-b5156f657dc1+25f-iommu_riscv_inv_jgg@nvidia.com
> 2) Remove SMMUv3 struct arm_smmu_cmdq_ent
> 3) Organize the SMMUv3 invalidation flow so iommupt can use it
> 4) Use the generic iommu page table for SMMUv3
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/9] iommu/arm-smmu-v3: Add struct arm_smmu_cmd to represent the HW format command
https://git.kernel.org/iommu/c/bf00a29234a4
[2/9] iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq selection functions
https://git.kernel.org/iommu/c/f59c5b6858d8
[3/9] iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq submission functions
https://git.kernel.org/iommu/c/d455e3a7bf0a
[4/9] iommu/arm-smmu-v3: Convert arm_smmu_cmdq_batch cmds to struct arm_smmu_cmd
https://git.kernel.org/iommu/c/27e02ca61552
[5/9] iommu/arm-smmu-v3: Remove CMDQ_OP_CFGI_CD_ALL from arm_smmu_cmdq_build_cmd()
https://git.kernel.org/iommu/c/c5758947cb7b
[6/9] iommu/arm-smmu-v3: Directly encode simple commands
https://git.kernel.org/iommu/c/6e771be45e8a
[7/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_ATC_INV
https://git.kernel.org/iommu/c/2eedb906f9c6
[8/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_SYNC
https://git.kernel.org/iommu/c/c3f84707ad4f
[9/9] iommu/arm-smmu-v3: Directly encode TLBI commands
https://git.kernel.org/iommu/c/be0d0b858861
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/5] POE sigreturn fix and extra tests
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: linux-arm-kernel, Kevin Brodsky
Cc: catalin.marinas, kernel-team, Will Deacon, Andrew Morton,
David Hildenbrand (Arm), Joey Gouly, Mark Brown, Shuah Khan,
linux-kselftest, linux-mm, linux-kernel
In-Reply-To: <20260427-poe_signal-v2-0-2bd9d6f16ab4@arm.com>
On Mon, 27 Apr 2026 13:03:32 +0100, Kevin Brodsky wrote:
> Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to
> avoid uaccess failures") introduced special handling for EL0 registers
> that impact uaccess. This did not however handle the case where a signal
> handler removes the relevant record (poe_context for POE) from the
> signal frame; this is clearly not typical behaviour but it is legal.
> That commit resulted in arbitrary data from the kernel stack being
> written to POR_EL0 in that case.
>
> [...]
Applied selftest updates to arm64 (for-next/selftests), thanks!
[2/5] selftests/mm: Fix resv_sz when parsing arm64 signal frame
https://git.kernel.org/arm64/c/c364aa56d673
[3/5] kselftest/arm64: Add POE as a feature in the signal tests
https://git.kernel.org/arm64/c/42c21954063e
[4/5] kselftest/arm64: Move/add POE helpers to test_signals_utils.h
https://git.kernel.org/arm64/c/925a082ec2a0
[5/5] kselftest/arm64: Add tests for POR_EL0 save/reset/restore
https://git.kernel.org/arm64/c/f2db075234c8
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Rob Clark, Robin Murphy, Joerg Roedel, bibek.patro
Cc: catalin.marinas, kernel-team, Will Deacon, Dmitry Baryshkov,
iommu, linux-arm-msm, linux-arm-kernel, linux-kernel,
srinivas.kandagatla, Dmitry Baryshkov, Shawn Guo
In-Reply-To: <20260423100230.3462214-1-bibek.patro@oss.qualcomm.com>
On Thu, 23 Apr 2026 15:32:30 +0530, bibek.patro@oss.qualcomm.com wrote:
> The qcom_smmu_actlr_client_of_match table contained "qcom,fastrpc" as
> the compatible string for applying ACTLR prefetch settings to FastRPC
> devices. However, "qcom,fastrpc" is the compatible string for the parent
> rpmsg channel node, which is not an IOMMU client — it carries no
> "iommus" property in the device tree and is never attached to an SMMU
> context bank.
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table
https://git.kernel.org/iommu/c/a6e1618a65d4
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: Implement support for 2025 dpISA extensions
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel,
linux-doc, linux-kselftest
In-Reply-To: <20260518-arm64-dpisa-2025-v2-0-b3367b73bd00@kernel.org>
On Mon, 18 May 2026 16:07:28 +0100, Mark Brown wrote:
> The 2025 dpISA extensions introduce a number of architecture features
> all of which are fairly straightforward from a kernel point of view
> since they only introduce new instructions, not any architecture state.
>
>
Applied selftest update to arm64 (for-next/selftests), thanks!
[2/2] kselftest/arm64: Add 2025 dpISA coverage to hwcaps
https://git.kernel.org/arm64/c/7da70f41da81
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v3 0/4] arm_mpam: Add support for the MPAM v0.1 architecture version
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, zengheng4, James Morse
Cc: catalin.marinas, kernel-team, Will Deacon, wangkefeng.wang,
xry111, yang, reinette.chatre, thuth, ben.horgan,
mrigendra.chaubey, fenghuay, ahmed.genidi
In-Reply-To: <20260508162341.3762549-1-james.morse@arm.com>
On Fri, 08 May 2026 17:23:37 +0100, James Morse wrote:
> This is a v3 of Zeng's series to add support for MPAM v0.1.
> Included are the changes Ben and I suggested, and a couple of bugs found while
> testing it.
>
> I've put the bug fixes first as you can hit these with mainline.
> The patches for v0.1 enable MPAM on those platforms as this extra ID register
> was missed.
>
> [...]
Applied to arm64 (for-next/mpam), thanks!
[1/4] arm_mpam: Fix false positive assert failure during mpam_disable()
(no commit info)
[2/4] arm_mpam: Check whether the config array is allocated before destroying it
(no commit info)
[3/4] arm64: cpufeature: Add support for the MPAM v0.1 architecture version
https://git.kernel.org/arm64/c/5302bc1493be
[4/4] arm_mpam: Update architecture version check for MPAM MSC
https://git.kernel.org/arm64/c/50a42e03cdbd
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] arm64: Implement _THIS_IP_ using inline asm
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Catalin Marinas, Marco Elver
Cc: kernel-team, Will Deacon, Thomas Huth, Nathan Chancellor,
Kees Cook, Vlastimil Babka, Harry Yoo, linux-arm-kernel,
linux-kernel, kasan-dev
In-Reply-To: <20260511201711.3249121-2-elver@google.com>
On Mon, 11 May 2026 22:16:59 +0200, Marco Elver wrote:
> Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to
> be broken:
>
> #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
>
> In particular, the address of a label is only expected to be used with a
> computed goto.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: Implement _THIS_IP_ using inline asm
https://git.kernel.org/arm64/c/d54e4fde9de2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
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