aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-09-01riscv: boot: add Image.xz supportLasse Collin3-2/+8
The Image.* targets existed for other compressors already. Bootloader support is needed for decompression. This is for CONFIG_EFI_ZBOOT=n. With CONFIG_EFI_ZBOOT=y, XZ was already available. Comparision with Linux 6.10 RV64GC tinyconfig (in KiB): 1027 Image 594 Image.gz 541 Image.zst 510 Image.lzma 474 Image.xz Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Lasse Collin <[email protected]> Reviewed-by: Emil Renner Berthing <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Albert Ou <[email protected]> Cc: Jules Maselbas <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Joel Stanley <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Jubin Zhong <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Rui Li <[email protected]> Cc: Sam James <[email protected]> Cc: Simon Glass <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01arm64: boot: add Image.xz supportLasse Collin1-1/+4
The Image.* targets existed for other compressors already. Bootloader support is needed for decompression. This is for CONFIG_EFI_ZBOOT=n. With CONFIG_EFI_ZBOOT=y, XZ was already available. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Lasse Collin <[email protected]> Cc: Simon Glass <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Jules Maselbas <[email protected]> Cc: Albert Ou <[email protected]> Cc: Emil Renner Berthing <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Joel Stanley <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Jubin Zhong <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Rui Li <[email protected]> Cc: Sam James <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm: remove legacy install_special_mapping() codeLinus Torvalds5-22/+58
All relevant architectures had already been converted to the new interface (which just has an underscore in front of the name - not very imaginative naming), this just force-converts the stragglers. The modern interface is almost identical to the old one, except instead of the page pointer it takes a "struct vm_special_mapping" that describes the mapping (and contains the page pointer as one member), and it returns the resulting 'vma' instead of just the error code. Getting rid of the old interface also gets rid of some special casing, which had caused problems with the mremap extensions to "struct vm_special_mapping". [[email protected]: coding-style cleanups] Link: https://lkml.kernel.org/r/CAHk-=whvR+z=0=0gzgdfUiK70JTa-=+9vxD-4T=3BagXR6dciA@mail.gmail.comTested-by: Rob Landley <[email protected]> # arch/sh/ Link: https://lore.kernel.org/all/20240819195120.GA1113263@thelio-3990X/ Signed-off-by: Linus Torvalds <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Anton Ivanov <[email protected]> Cc: Brian Cain <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Dinh Nguyen <[email protected]> Cc: Guo Ren <[email protected]> Cc: Jeff Xu <[email protected]> Cc: Johannes Berg <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: Liam R. Howlett <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Rich Felker <[email protected]> Cc: Rob Landley <[email protected]> Cc: Yoshinori Sato <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01powerpc/vdso: refactor error handlingMichael Ellerman1-11/+7
Linus noticed that the error handling in __arch_setup_additional_pages() fails to clear the mm VDSO pointer if _install_special_mapping() fails. In practice there should be no actual bug, because if there's an error the VDSO pointer is cleared later in arch_setup_additional_pages(). However it's no longer necessary to set the pointer before installing the mapping. Commit c1bab64360e6 ("powerpc/vdso: Move to _install_special_mapping() and remove arch_vma_name()") reworked the code so that the VMA name comes from the vm_special_mapping.name, rather than relying on arch_vma_name(). So rework the code to only set the VDSO pointer once the mappings have been installed correctly, and remove the stale comment. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Michael Ellerman <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Jeff Xu <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm: remove arch_unmap()Michael Ellerman2-10/+0
Now that powerpc no longer uses arch_unmap() to handle VDSO unmapping, there are no meaningful implementions left. Drop support for it entirely, and update comments which refer to it. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Michael Ellerman <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Acked-by: David Hildenbrand <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Jeff Xu <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Pedro Falcato <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01powerpc/mm: handle VDSO unmapping via close() rather than arch_unmap()Michael Ellerman2-4/+17
Add a close() callback to the VDSO special mapping to handle unmapping of the VDSO. That will make it possible to remove the arch_unmap() hook entirely in a subsequent patch. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Michael Ellerman <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Jeff Xu <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm/x86: add missing pud helpersPeter Xu2-8/+61
Some new helpers will be needed for pud entry updates soon. Introduce these helpers by referencing the pmd ones. Namely: - pudp_invalidate(): this helper invalidates a huge pud before a split happens, so that the invalidated pud entry will make sure no race will happen (either with software, like a concurrent zap, or hardware, like a/d bit lost). - pud_modify(): this helper applies a new pgprot to an existing huge pud mapping. For more information on why we need these two helpers, please refer to the corresponding pmd helpers in the mprotect() code path. When at it, simplify the pud_modify()/pmd_modify() comments on shadow stack pgtable entries to reference pte_modify() to avoid duplicating the whole paragraph three times. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Jiang <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Rientjes <[email protected]> Cc: "Edgecombe, Rick P" <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm/x86: implement arch_check_zapped_pud()Peter Xu2-0/+16
Introduce arch_check_zapped_pud() to sanity check shadow stack on PUD zaps. It has the same logic as the PMD helper. One thing to mention is, it might be a good idea to use page_table_check in the future for trapping wrong setups of shadow stack pgtable entries [1]. That is left for the future as a separate effort. [1] https://lore.kernel.org/all/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Acked-by: David Hildenbrand <[email protected]> Cc: "Edgecombe, Rick P" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Jiang <[email protected]> Cc: David Rientjes <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm/x86: make pud_leaf() only care about PSE bitPeter Xu1-2/+1
When working on mprotect() on 1G dax entries, I hit an zap bad pud error when zapping a huge pud that is with PROT_NONE permission. Here the problem is x86's pud_leaf() requires both PRESENT and PSE bits set to report a pud entry as a leaf, but that doesn't look right, as it's not following the pXd_leaf() definition that we stick with so far, where PROT_NONE entries should be reported as leaves. To fix it, change x86's pud_leaf() implementation to only check against PSE bit to report a leaf, irrelevant of whether PRESENT bit is set. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Acked-by: Dave Hansen <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Jiang <[email protected]> Cc: David Rientjes <[email protected]> Cc: "Edgecombe, Rick P" <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm/powerpc: add missing pud helpersPeter Xu2-0/+23
Some new helpers will be needed for pud entry updates soon. Introduce these helpers by referencing the pmd ones. Namely: - pudp_invalidate(): this helper invalidates a huge pud before a split happens, so that the invalidated pud entry will make sure no race will happen (either with software, like a concurrent zap, or hardware, like a/d bit lost). - pud_modify(): this helper applies a new pgprot to an existing huge pud mapping. For more information on why we need these two helpers, please refer to the corresponding pmd helpers in the mprotect() code path. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Dave Jiang <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Rientjes <[email protected]> Cc: "Edgecombe, Rick P" <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm: rework accept memory helpersKirill A. Shutemov2-2/+2
Make accept_memory() and range_contains_unaccepted_memory() take 'start' and 'size' arguments instead of 'start' and 'end'. Remove accept_page(), replacing it with direct calls to accept_memory(). The accept_page() name is going to be used for a different function. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kirill A. Shutemov <[email protected]> Suggested-by: David Hildenbrand <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Mike Rapoport (Microsoft) <[email protected]> Cc: Tom Lendacky <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01s390/mm/fault: convert do_secure_storage_access() from follow_page() to ↵David Hildenbrand1-6/+10
folio_walk Let's get rid of another follow_page() user and perform the conversion under PTL: Note that this is also what follow_page_pte() ends up doing. Unfortunately we cannot currently optimize out the additional reference, because arch_make_folio_accessible() must be called with a raised refcount to protect against concurrent conversion to secure. We can just move the arch_make_folio_accessible() under the PTL, like follow_page_pte() would. We'll effectively drop the "writable" check implied by FOLL_WRITE: follow_page_pte() would also not check that when calling arch_make_folio_accessible(), so there is no good reason for doing that here. We'll lose the secretmem check from follow_page() as well, about which we shouldn't really care. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Gerald Schaefer <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Janosch Frank <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Zi Yan <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01s390/uv: convert gmap_destroy_page() from follow_page() to folio_walkDavid Hildenbrand1-6/+12
Let's get rid of another follow_page() user and perform the UV calls under PTL -- which likely should be fine. No need for an additional reference while holding the PTL: uv_destroy_folio() and uv_convert_from_secure_folio() raise the refcount, so any concurrent make_folio_secure() would see an unexpted reference and cannot set PG_arch_1 concurrently. Do we really need a writable PTE? Likely yes, because the "destroy" part is, in comparison to the export, a destructive operation. So we'll keep the writability check for now. We'll lose the secretmem check from follow_page(). Likely we don't care about that here. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Gerald Schaefer <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Janosch Frank <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Zi Yan <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01s390/uv: drop arch_make_page_accessible()David Hildenbrand2-7/+0
All code was converted to using arch_make_folio_accessible(), let's drop arch_make_page_accessible(). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Reviewed-by: Vishal Moola (Oracle) <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Janosch Frank <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Vasily Gorbik <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01powerpc/8xx: document and enforce that split PT locks are not usedDavid Hildenbrand1-0/+6
Right now, we cannot have split PT locks because 8xx does not support SMP. But for the sake of documentation *why* 8xx is fine regarding what we documented in huge_pte_lockptr(), let's just add code to enforce it at the same time as documenting it. This should also make everybody who wants to copy from the 8xx approach of supporting such unusual ways of mapping hugetlb folios aware that it gets tricky once multiple page tables are involved. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Dave Hansen <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Mike Rapoport (Microsoft) <[email protected]> Cc: Muchun Song <[email protected]> Cc: "Naveen N. Rao" <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Peter Xu <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm: turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig optionsDavid Hildenbrand2-6/+7
Patch series "mm: split PTE/PMD PT table Kconfig cleanups+clarifications". This series is a follow up to the fixes: "[PATCH v1 0/2] mm/hugetlb: fix hugetlb vs. core-mm PT locking" When working on the fixes, I wondered why 8xx is fine (-> never uses split PT locks) and how PT locking even works properly with PMD page table sharing (-> always requires split PMD PT locks). Let's improve the split PT lock detection, make hugetlb properly depend on it and make 8xx bail out if it would ever get enabled by accident. As an alternative to patch #3 we could extend the Kconfig SPLIT_PTE_PTLOCKS option from patch #2 -- but enforcing it closer to the code that actually implements it feels a bit nicer for documentation purposes, and there is no need to actually disable it because it should always be disabled (!SMP). Did a bunch of cross-compilations to make sure that split PTE/PMD PT locks are still getting used where we would expect them. [1] https://lkml.kernel.org/r/[email protected] This patch (of 3): Let's clean that up a bit and prepare for depending on CONFIG_SPLIT_PMD_PTLOCKS in other Kconfig options. More cleanups would be reasonable (like the arch-specific "depends on" for CONFIG_SPLIT_PTE_PTLOCKS), but we'll leave that for another day. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Acked-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Reviewed-by: Qi Zheng <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Dave Hansen <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Muchun Song <[email protected]> Cc: "Naveen N. Rao" <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Peter Xu <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-01mm: kvmalloc: align kvrealloc() with krealloc()Danilo Krummrich2-5/+1
Besides the obvious (and desired) difference between krealloc() and kvrealloc(), there is some inconsistency in their function signatures and behavior: - krealloc() frees the memory when the requested size is zero, whereas kvrealloc() simply returns a pointer to the existing allocation. - krealloc() behaves like kmalloc() if a NULL pointer is passed, whereas kvrealloc() does not accept a NULL pointer at all and, if passed, would fault instead. - krealloc() is self-contained, whereas kvrealloc() relies on the caller to provide the size of the previous allocation. Inconsistent behavior throughout allocation APIs is error prone, hence make kvrealloc() behave like krealloc(), which seems superior in all mentioned aspects. Besides that, implementing kvrealloc() by making use of krealloc() and vrealloc() provides oppertunities to grow (and shrink) allocations more efficiently. For instance, vrealloc() can be optimized to allocate and map additional pages to grow the allocation or unmap and free unused pages to shrink the allocation. [[email protected]: document concurrency restrictions] Link: https://lkml.kernel.org/r/[email protected] [[email protected]: disable KASAN when switching to vmalloc] Link: https://lkml.kernel.org/r/[email protected] [[email protected]: properly document __GFP_ZERO behavior] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Chandan Babu R <[email protected]> Cc: Christian König <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Rientjes <[email protected]> Cc: Hyeonggon Yoo <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Kees Cook <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Oliver Upton <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Uladzislau Rezki <[email protected]> Cc: Wedson Almeida Filho <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-09-02riscv: dts: sophgo: Add mcu device for Milk-V PioneerInochi Amaoto1-0/+60
Add mcu device and thermal zones node for Milk-V Pioneer. Tested-by: Chen Wang <[email protected]> Reviewed-by: Chen Wang <[email protected]> Link: https://lore.kernel.org/r/IA1PR20MB4953C675C28B35723E87A36BBB822@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Inochi Amaoto <[email protected]> Signed-off-by: Chen Wang <[email protected]>
2024-09-02riscv: sophgo: dts: add gpio controllers for SG2042 SoCChen Wang1-0/+66
Add support for the GPIO controller of Sophgo SG2042. SG2042 uses IP from Synopsys DesignWare APB GPIO and has three GPIO controllers. Signed-off-by: Chen Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Inochi Amaoto <[email protected]>
2024-09-02riscv: sophgo: dts: add mmc controllers for SG2042 SoCChen Wang2-0/+45
SG2042 has two MMC controller, one for emmc, another for sd-card. Signed-off-by: Chen Wang <[email protected]> Link: https://lore.kernel.org/r/03ac9ec9c23bbe4c3b30271e76537bdbe5638665.1722847198.git.unicorn_wang@outlook.com Signed-off-by: Inochi Amaoto <[email protected]>
2024-09-02riscv: dts: sophgo: Add i2c device support for sg2042Inochi Amaoto1-0/+52
The i2c ip of sg2042 is a standard Synopsys i2c ip, which is already supported by the mainline kernel. Add i2c device node for sg2042. Reviewed-by: Chen Wang <[email protected]> Tested-by: Chen Wang <[email protected]> Link: https://lore.kernel.org/r/IA1PR20MB49530E59974AF0FCA4FAB6DBBBB72@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Inochi Amaoto <[email protected]> Signed-off-by: Chen Wang <[email protected]>
2024-09-02riscv: dts: sophgo: Use common "interrupt-parent" for all peripherals for sg2042Inochi Amaoto1-1/+1
As all peripherals of sg2042 share the same "interrupt-parent", there is no need to use peripherals specific "interrupt-parent". Define "interrupt-parent" in the SoC level. Reviewed-by: Chen Wang <[email protected]> Tested-by: Chen Wang <[email protected]> Link: https://lore.kernel.org/r/IA1PR20MB49531F6DFD2F116207C1397DBBB72@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Inochi Amaoto <[email protected]> Signed-off-by: Chen Wang <[email protected]>
2024-09-02riscv: dts: sophgo: Add sdhci0 configuration for Huashan PiInochi Amaoto1-0/+9
Add configuration for sdhci0 for Huashan Pi to support sd card. Reviewed-by: Chen Wang <[email protected]> Link: https://lore.kernel.org/r/IA1PR20MB49538AC83C5DB314D10F7186BBA92@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Inochi Amaoto <[email protected]> Signed-off-by: Chen Wang <[email protected]>
2024-09-02riscv: dts: sophgo: cv18xx: add DMA controllerInochi Amaoto1-0/+16
Add DMA controller dt node for CV18XX/SG200x. Link: https://lore.kernel.org/r/IA1PR20MB4953BD73E12B8A1CDBD9E1A3BB042@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Inochi Amaoto <[email protected]> Signed-off-by: Chen Wang <[email protected]>
2024-09-02ARM: dts: imx6qdl-mba6b: remove doubled entry for I2C1 pinmuxMarkus Niebel1-9/+0
Since the muxing is described already in imx6qdl-tqma6 can be reused by this variant. No functional change. Signed-off-by: Markus Niebel <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-09-02ARM: dts: imx6qdl-mba6: improve compatible for LM75 temp sensorMarkus Niebel2-2/+2
Use national,lm75a to specify exact variant used. This should cause no functional changes. Signed-off-by: Markus Niebel <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-09-02ARM: dts: imx6qdl-tqma6: improve compatible for LM75 temp sensorMarkus Niebel2-4/+4
Use national,lm75a to specify exact variant used. This should cause no functional changes. While at it change node name to 'temperature-sensor@48' to describe the function of the IC. Signed-off-by: Markus Niebel <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-09-02ARM: dts: imx6qdl-tqma6: move i2c3 pinmux to imx6qdl-tqma6bMarkus Niebel2-14/+16
Move the pinmux entries to the variant where they are actual used. No functional changes. Signed-off-by: Markus Niebel <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-09-01Merge tag 'x86-urgent-2024-09-01' of ↵Linus Torvalds11-20/+61
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: - x2apic_disable() clears x2apic_state and x2apic_mode unconditionally, even when the state is X2APIC_ON_LOCKED, which prevents the kernel to disable it thereby creating inconsistent state. Reorder the logic so it actually works correctly - The XSTATE logic for handling LBR is incorrect as it assumes that XSAVES supports LBR when the CPU supports LBR. In fact both conditions need to be true. Otherwise the enablement of LBR in the IA32_XSS MSR fails and subsequently the machine crashes on the next XRSTORS operation because IA32_XSS is not initialized. Cache the XSTATE support bit during init and make the related functions use this cached information and the LBR CPU feature bit to cure this. - Cure a long standing bug in KASLR KASLR uses the full address space between PAGE_OFFSET and vaddr_end to randomize the starting points of the direct map, vmalloc and vmemmap regions. It thereby limits the size of the direct map by using the installed memory size plus an extra configurable margin for hot-plug memory. This limitation is done to gain more randomization space because otherwise only the holes between the direct map, vmalloc, vmemmap and vaddr_end would be usable for randomizing. The limited direct map size is not exposed to the rest of the kernel, so the memory hot-plug and resource management related code paths still operate under the assumption that the available address space can be determined with MAX_PHYSMEM_BITS. request_free_mem_region() allocates from (1 << MAX_PHYSMEM_BITS) - 1 downwards. That means the first allocation happens past the end of the direct map and if unlucky this address is in the vmalloc space, which causes high_memory to become greater than VMALLOC_START and consequently causes iounmap() to fail for valid ioremap addresses. Cure this by exposing the end of the direct map via PHYSMEM_END and use that for the memory hot-plug and resource management related places instead of relying on MAX_PHYSMEM_BITS. In the KASLR case PHYSMEM_END maps to a variable which is initialized by the KASLR initialization and otherwise it is based on MAX_PHYSMEM_BITS as before. - Prevent a data leak in mmio_read(). The TDVMCALL exposes the value of an initialized variabled on the stack to the VMM. The variable is only required as output value, so it does not have to exposed to the VMM in the first place. - Prevent an array overrun in the resource control code on systems with Sub-NUMA Clustering enabled because the code failed to adjust the index by the number of SNC nodes per L3 cache. * tag 'x86-urgent-2024-09-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/resctrl: Fix arch_mbm_* array overrun on SNC x86/tdx: Fix data leak in mmio_read() x86/kaslr: Expose and use the end of the physical memory address space x86/fpu: Avoid writing LBR bit to IA32_XSS unless supported x86/apic: Make x2apic_disable() work correctly
2024-09-01Merge tag 'perf-urgent-2024-09-01' of ↵Linus Torvalds1-2/+21
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fix from Thomas Gleixner: "A single fix for x86 performance monitoring. Haswell PMUs suffer from several errata and require a limit the minimal period for counter events, otherwise they suffer from endless loops in the PMU interrupt" * tag 'perf-urgent-2024-09-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Limit the period on Haswell
2024-09-01arm64: dts: ti: k3-j722s-evm: Enable Inter-Processor CommunicationApurva Nandan1-0/+157
The K3 J722S-EVM platform is based on the J722S SoC which has one single-core Arm Cortex-R5F processor in each of the WAKEUP, MCU and MAIN voltage domain, and two C71x DSP subsystems in MAIN voltage domain. The Inter-Processor communication between the A53 cores and these R5F and DSP remote cores is achieved through shared memory and Mailboxes. Thus, add the memory carveouts and enable the mailbox clusters required for communication. Also, The remoteproc firmware like of R5F and DSPs in the MAIN voltage domain use timers. Therefore, change the status of the timer nodes to "reserved" to avoid any clash during booting of remotecores. Usage is described as below: +===================+=============+ | Remoteproc Node | Timer Node | +===================+=============+ | main_r5fss0_core0 | main_timer0 | +-------------------+-------------+ | c7x_0 | main_timer1 | +-------------------+-------------+ | c7x_1 | main_timer2 | +-------------------+-------------+ Signed-off-by: Apurva Nandan <[email protected]> Signed-off-by: Beleswar Padhi <[email protected]> Reviewed-by: Udit Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-j722s-main: Add R5F and C7x remote processor nodesApurva Nandan1-0/+61
The K3 J722S SoCs have one single-core Arm Cortex-R5F processor in each of the WAKEUP, MCU and MAIN voltage domain, and two C71x DSP subsystems in MAIN voltage domain. Add the DT nodes to support Inter-Processor Communication. Signed-off-by: Apurva Nandan <[email protected]> [ refactoring changes to k3-j722s-main.dtsi ] Signed-off-by: Beleswar Padhi <[email protected]> Reviewed-by: Udit Kumar <[email protected]> Reviewed-by: Andrew Davis <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am68-sk-som: Update Partition info for OSPI FlashPrasanth Babu Mantena1-2/+2
Commit 73f1f26e2e4c ("arm64: dts: ti: k3-am68-sk-som: Add support for OSPI flash") introduced the flash node with discontinuous partitions. Updating the partition offset to be continuous from the previous partition to maintain linearity. Signed-off-by: Prasanth Babu Mantena <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: Add k3-am67a-beagley-aiRobert Nelson2-0/+394
BeagleBoard.org BeagleY-AI is an easy to use, affordable open source hardware single board computer based on the Texas Instruments AM67A, which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA), GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5 cores for low-power, low-latency GPIO control. https://beagley-ai.org/ https://openbeagle.org/beagley-ai/beagley-ai Signed-off-by: Robert Nelson <[email protected]> Reviewed-by: Roger Quadros <[email protected]> Reviewed-by: Jared McArthur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: iot2050: Declare Ethernet PHY ledsDiogo Ivo1-0/+46
Each Ethernet PHY on IOT2050 platforms drives 3 LEDs whose triggers can be configured to signal link properties such as connection status or speed. Declare the LEDs, exposing their trigger controls to userspace. Signed-off-by: Diogo Ivo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am65: Add ESM nodesJudith Mendez2-0/+16
Add Error Signaling Module (ESM) instances in MCU and MAIN domains, set ESM interrupt sources for rti as per TRM [0] 9.4 Interrupt Sources. There are no ESM0_ESM_INT* events routed to MCU ESM, so it is not possible to reset the CPU using watchdog and ESM0 configuration. However add ESM instances for device completion. Add comments to describe what interrupt sources are routed to ESM modules. [0] http://www.ti.com/lit/pdf/spruid7 Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am64: Add more ESM interrupt sourcesJudith Mendez2-2/+4
Add ESM interrupt sources for rti as per TRM [0] in 9.4 Interrupt Sources. [0] https://www.ti.com/lit/pdf/spruim2 Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am62a: Add ESM nodesJudith Mendez2-0/+16
Add Error Signaling Module (ESM) instances in MCU and MAIN domains, set ESM interrupt sources for rti as per TRM [0] 10.4 Interrupt Sources. Add comments to describe what interrupt sources are routed to ESM modules. [0] https://www.ti.com/lit/pdf/spruj16 Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am62: Add comments to ESM nodesJudith Mendez2-0/+2
Add comments to describe what interrupt sources are routed to ESM modules. There is no functional change. Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am62p: Fix ESM interrupt sourcesJudith Mendez2-2/+4
Fix interrupt sources for rti routed to the ESM0 as per [0], in 10.4 Interrupt Sources Add comments to describe what interrupt sources are routed to ESM modules. [0] https://www.ti.com/lit/pdf/spruj83 Fixes: b5080c7c1f7e ("arm64: dts: ti: k3-am62p: Add nodes for more IPs") Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am62p: Remove 'reserved' status for ESMSanthosh Kumar K1-1/+0
Remove 'reserved' status for MCU ESM node. Watchdog reset is propagated through ESM0 to MCU ESM to reset the CPU, so enable MCU ESM to reset the CPU with watchdog timeout. Signed-off-by: Santhosh Kumar K <[email protected]> Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-j721s2-evm-gesi-exp-board: Rename gpio-hog node nameNishanth Menon1-1/+1
Fix the gpio hog node name to p15-hog to match up with gpio-hog convention. This fixes dtbs_check warning: p15: $nodename:0: 'p15' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$' Acked-by: Siddharth Vadapalli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am642-evm-nand: Rename pinctrl node and gpio-hog namesNishanth Menon1-3/+3
Rename the pin mux and gpio-hog node names to match up with binding rules. This fixes dtbs_check warnings: 'gpmc0-pins-default' does not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+' 'gpio0-36' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$' While at it, change the phandle name to be consistent with the pinctrl naming. Reviewed-by: Dhruva Gole <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmasMD Danish Anwar1-6/+2
ICSSG doesn't use mgmnt rsp dmas. But these are added in the dmas for icssg1-eth and icssg0-eth node. These mgmnt rsp dmas result in below dtbs_check warnings. /workdir/arch/arm64/boot/dts/ti/k3-am654-idk.dtb: icssg1-eth: dmas: [[39, 49664], [39, 49665], [39, 49666], [39, 49667], [39, 49668], [39, 49669], [39, 49670], [39, 49671], [39, 16896], [39, 16897], [39, 16898], [39, 16899]] is too long from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# /workdir/arch/arm64/boot/dts/ti/k3-am654-idk.dtb: icssg0-eth: dmas: [[39, 49408], [39, 49409], [39, 49410], [39, 49411], [39, 49412], [39, 49413], [39, 49414], [39, 49415], [39, 16640], [39, 16641], [39, 16642], [39, 16643]] is too long from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# Fix these warnings by removing mgmnt rsp dmas from icssg1-eth and icssg0-eth nodes. Fixes: a4d5bc3214eb ("arm64: dts: ti: k3-am654-idk: Add ICSSG Ethernet ports") Signed-off-by: MD Danish Anwar <[email protected]> Reviewed-by: Roger Quadros <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-j784s4: Include entire FSS region in rangesAndrew Davis2-12/+10
Add FSS regions at 0x50000000, 0x400000000, and 0x600000000. Although not used currently by the Linux FSS driver, these regions belong to the FSS and should be included in the ranges mapping. While here, a couple of these numbers had missing zeros which was hidden by odd alignments, fix both these issues. Signed-off-by: Andrew Davis <[email protected]> Reviewed-by: Santhosh Kumar K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-j721s2: Include entire FSS region in rangesAndrew Davis2-7/+5
Add FSS regions at 0x50000000, 0x400000000, and 0x600000000. Although not used currently by the Linux FSS driver, these regions belong to the FSS and should be included in the ranges mapping. While here, a couple of these numbers had missing zeros which was hidden by odd alignments, fix both these issues. Signed-off-by: Andrew Davis <[email protected]> Reviewed-by: Santhosh Kumar K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-j721e: Include entire FSS region in rangesAndrew Davis2-10/+8
Add FSS regions at 0x50000000, 0x400000000, and 0x600000000. Although not used currently by the Linux FSS driver, these regions belong to the FSS and should be included in the ranges mapping. While here, a couple of these numbers had missing zeros which was hidden by odd alignments, fix both these issues. Signed-off-by: Andrew Davis <[email protected]> Reviewed-by: Santhosh Kumar K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am65: Include entire FSS region in rangesAndrew Davis2-11/+9
Add FSS regions at 0x50000000, 0x400000000, and 0x600000000. Although not used currently by the Linux FSS driver, these regions belong to the FSS and should be included in the ranges mapping. While here, a couple of these numbers had missing zeros which was hidden by odd alignments, fix both these issues. Signed-off-by: Andrew Davis <[email protected]> Reviewed-by: Santhosh Kumar K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01arm64: dts: ti: k3-am64: add USB fallback compatible to J721EThéo Lebrun1-1/+1
USB on AM64 is the same peripheral as on J721E. It has a specific compatible for potential integration details. Express this relationship, matching what the dt-bindings indicate. Signed-off-by: Théo Lebrun <[email protected]> Reviewed-by: Roger Quadros <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-09-01tinyconfig: remove unnecessary 'is not set' for choice blocksMasahiro Yamada1-4/+0
This reverts the following commits: - 236dec051078 ("kconfig: tinyconfig: provide whole choice blocks to avoid warnings") - b0f269728ccd ("x86/config: Fix warning for 'make ARCH=x86_64 tinyconfig'") Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"), it is no longer necessary to disable the remaining options in choice blocks. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Thomas Gleixner <[email protected]>