user/sven/linux.git/Documentation/features/vm, branch v5.10.42

s390/pci: Implement ioremap_wc/prot() with MIO

2020-09-14T08:30:07Z

With our current support for the new MIO PCI instructions, write combining/write back MMIO memory can be obtained via the pci_iomap_wc() and pci_iomap_wc_range() functions. This is achieved by using the write back address for a specific bar as provided in clp_store_query_pci_fn() These functions are however not widely used and instead drivers often rely on ioremap_wc() and ioremap_prot(), which on other platforms enable write combining using a PTE flag set through the pgrprot value. While we do not have a write combining flag in the low order flag bits of the PTE like x86_64 does, with MIO support, there is a write back bit in the physical address (bit 1 on z15) and thus also the PTE. Which bit is used to toggle write back and whether it is available at all, is however not fixed in the architecture. Instead we get this information from the CLP Store Logical Processor Characteristics for PCI command. When the write back bit is not provided we fall back to the existing behavior. Signed-off-by: Niklas Schnelle Reviewed-by: Pierre Morel Reviewed-by: Gerald Schaefer Signed-off-by: Vasily Gorbik

arch: remove unicore32 port

2020-07-01T09:09:13Z

The unicore32 port do not seem maintained for a long time now, there is no upstream toolchain that can create unicore32 binaries and all the links to prebuilt toolchains for unicore32 are dead. Even compilers that were available are not supported by the kernel anymore. Guenter Roeck says: I have stopped building unicore32 images since v4.19 since there is no available compiler that is still supported by the kernel. I am surprised that support for it has not been removed from the kernel. Remove unicore32 port. Signed-off-by: Mike Rapoport Acked-by: Arnd Bergmann Acked-by: Guenter Roeck

mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option

2020-06-04T03:09:43Z

CONFIG_HAVE_MEMBLOCK_NODE_MAP is used to differentiate initialization of nodes and zones structures between the systems that have region to node mapping in memblock and those that don't. Currently all the NUMA architectures enable this option and for the non-NUMA systems we can presume that all the memory belongs to node 0 and therefore the compile time configuration option is not required. The remaining few architectures that use DISCONTIGMEM without NUMA are easily updated to use memblock_add_node() instead of memblock_add() and thus have proper correspondence of memblock regions to NUMA nodes. Still, free_area_init_node() must have a backward compatible version because its semantics with and without CONFIG_HAVE_MEMBLOCK_NODE_MAP is different. Once all the architectures will use the new semantics, the entire compatibility layer can be dropped. To avoid addition of extra run time memory to store node id for architectures that keep memblock but have only a single node, the node id field of the memblock_region is guarded by CONFIG_NEED_MULTIPLE_NODES and the corresponding accessors presume that in those cases it is always 0. Signed-off-by: Mike Rapoport Signed-off-by: Andrew Morton Tested-by: Hoan Tran [arm64] Acked-by: Catalin Marinas [arm64] Cc: Baoquan He Cc: Brian Cain Cc: "David S. Miller" Cc: Geert Uytterhoeven Cc: Greentime Hu Cc: Greg Ungerer Cc: Guan Xuetao Cc: Guo Ren Cc: Heiko Carstens Cc: Helge Deller Cc: "James E.J. Bottomley" Cc: Jonathan Corbet Cc: Ley Foon Tan Cc: Mark Salter Cc: Matt Turner Cc: Max Filippov Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Simek Cc: Nick Hu Cc: Paul Walmsley Cc: Richard Weinberger Cc: Rich Felker Cc: Russell King Cc: Stafford Horne Cc: Thomas Bogendoerfer Cc: Tony Luck Cc: Vineet Gupta Cc: Yoshinori Sato Link: http://lkml.kernel.org/r/20200412194859.12663-4-rppt@kernel.org Signed-off-by: Linus Torvalds

Documentation/features: Refresh the arch support status files

2020-05-25T16:17:11Z

I was manually editing the arch-support.txt for eBPF-JIT, when I realized the refresh script [1] has not been run for a while. Let's fix that, so that the entries are more up-to-date. [1] Documentation/features/scripts/features-refresh.sh Signed-off-by: Björn Töpel Link: https://lore.kernel.org/r/20200523191135.21889-1-bjorn.topel@gmail.com Signed-off-by: Jonathan Corbet

documentation: vm: Advertise support for pte_special in riscv

2020-02-19T09:41:01Z

Risc-V architecture has actually supported pte_special since its merge upstream, simply add this info to the documentation. Signed-off-by: Alexandre Ghiti Signed-off-by: Jonathan Corbet

Documentation/features: Add csky kernel features

2019-01-07T14:22:16Z

MIPS: Enable IOREMAP_PROT config option for MIPS cpus

2018-11-05T18:15:28Z

Allows the users of ptrace to access memory mapped by the ptraced process using the same cache coherency attributes as the original process. For example while using gdb with ioremap_prot() incorporated, both gdb and the process being traced will have same cache coherency attributes. Signed-off-by: Hassan Naveed Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20955/ Cc:

mm: introduce ARCH_HAS_PTE_SPECIAL

2018-06-08T00:34:35Z

Currently the PTE special supports is turned on in per architecture header files. Most of the time, it is defined in arch/*/include/asm/pgtable.h depending or not on some other per architecture static definition. This patch introduce a new configuration variable to manage this directly in the Kconfig files. It would later replace __HAVE_ARCH_PTE_SPECIAL. Here notes for some architecture where the definition of __HAVE_ARCH_PTE_SPECIAL is not obvious: arm __HAVE_ARCH_PTE_SPECIAL which is currently defined in arch/arm/include/asm/pgtable-3level.h which is included by arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set. So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE. powerpc __HAVE_ARCH_PTE_SPECIAL is defined in 2 files: - arch/powerpc/include/asm/book3s/64/pgtable.h - arch/powerpc/include/asm/pte-common.h The first one is included if (PPC_BOOK3S & PPC64) while the second is included in all the other cases. So select ARCH_HAS_PTE_SPECIAL all the time. sparc: __HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) && defined(__arch64__) which are defined through the compiler in sparc/Makefile if !SPARC32 which I assume to be if SPARC64. So select ARCH_HAS_PTE_SPECIAL if SPARC64 There is no functional change introduced by this patch. Link: http://lkml.kernel.org/r/1523433816-14460-2-git-send-email-ldufour@linux.vnet.ibm.com Signed-off-by: Laurent Dufour Suggested-by: Jerome Glisse Reviewed-by: Jerome Glisse Acked-by: David Rientjes Cc: Michal Hocko Cc: "Aneesh Kumar K . V" Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Jonathan Corbet Cc: Catalin Marinas Cc: Will Deacon Cc: Yoshinori Sato Cc: Rich Felker Cc: David S. Miller Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Vineet Gupta Cc: Palmer Dabbelt Cc: Albert Ou Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: David Rientjes Cc: Robin Murphy Cc: Christophe LEROY Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Revert "Documentation/features/vm: Remove arch support status file for 'pte_special'"

2018-05-10T21:42:22Z

The removal of this file appears to have been premature; it's not a feature enabled by Kconfig, but it's a arch-level feature regardless. Put it back for now until some happy future time when we decide how we really want to document such features. This reverts commit 2bef69a385b4c1c01d8abae0aa035f0ffa051f07. Signed-off-by: Jonathan Corbet

Documentation/features/vm: Remove arch support status file for 'pte_special'

2018-05-08T15:28:33Z

Suggested-by: Ingo Molnar Signed-off-by: Andrea Parri Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Andrew Morton Signed-off-by: Jonathan Corbet