kernel/linux.git/arch/arm/include/asm/memory.h, branch v6.19.11

asm-generic: provide generic page_to_phys and phys_to_page implementations

2024-10-28T21:44:28+00:00

page_to_phys is duplicated by all architectures, and from some strange reason placed in where it doesn't fit at all. phys_to_page is only provided by a few architectures despite having a lot of open coded users. Provide generic versions in to make these helpers more easily usable. Note with this patch powerpc loses the CONFIG_DEBUG_VIRTUAL pfn_valid check. It will be added back in a generic version later. Signed-off-by: Christoph Hellwig Signed-off-by: Arnd Bergmann

ARM: mm: Make virt_to_pfn() a static inline

2023-05-29T09:27:08+00:00

Making virt_to_pfn() a static inline taking a strongly typed (const void *) makes the contract of a passing a pointer of that type to the function explicit and exposes any misuse of the macro virt_to_pfn() acting polymorphic and accepting many types such as (void *), (unitptr_t) or (unsigned long) as arguments without warnings. Doing this is a bit intrusive: virt_to_pfn() requires PHYS_PFN_OFFSET and PAGE_SHIFT to be defined, and this is defined in , so this must be included *before* . The use of macros were obscuring the unclear inclusion order here, as the macros would eventually be resolved, but a static inline like this cannot be compiled with unresolved macros. The naive solution to include at the top of does not work, because sometimes includes at the end of itself, which would create a confusing inclusion loop. So instead, take the approach to always unconditionally include at the end of arch/arm uses explicitly in a lot of places, however it turns out that if we just unconditionally include into and switch all inclusions of to instead, we enforce the right order and will always have access to the definitions. Put an inclusion guard in place making it impossible to include explicitly. Link: https://lore.kernel.org/linux-mm/20220701160004.2ffff4e5ab59a55499f4c736@linux-foundation.org/ Signed-off-by: Linus Walleij

arm: include asm-generic/memory_model.h from page.h rather than memory.h

2023-02-10T00:51:40+00:00

Patch series "mm, arch: add generic implementation of pfn_valid() for FLATMEM", v2. Every architecture that supports FLATMEM memory model defines its own version of pfn_valid() that essentially compares a pfn to max_mapnr. Use mips/powerpc version implemented as static inline as a generic implementation of pfn_valid() and drop its per-architecture definitions This patch (of 4): Makes it consistent with other architectures and allows for generic definition of pfn_valid() in asm-generic/memory_model.h with clear override in arch/arm/include/asm/page.h Link: https://lkml.kernel.org/r/20230129124235.209895-1-rppt@kernel.org Link: https://lkml.kernel.org/r/20230129124235.209895-2-rppt@kernel.org Signed-off-by: Mike Rapoport (IBM) Reviewed-by: David Hildenbrand Cc: Arnd Bergmann Cc: Brian Cain Cc: "David S. Miller" Cc: Dinh Nguyen Cc: Geert Uytterhoeven Cc: Greg Ungerer Cc: Guo Ren Cc: Helge Deller Cc: Huacai Chen Cc: Huacai Chen Cc: Matt Turner Cc: Max Filippov Cc: Michael Ellerman Cc: Michal Simek Cc: Palmer Dabbelt Cc: Richard Weinberger Cc: Rich Felker Cc: Russell King Cc: Stafford Horne Cc: Thomas Bogendoerfer Cc: Vineet Gupta Cc: WANG Xuerui Cc: Yoshinori Sato Signed-off-by: Andrew Morton

ARM: footbridge: remove custom DMA address handling

2022-09-15T13:59:16+00:00

Footbridge is the last Arm platform that has its own __virt_to_bus()/__bus_to_virt()/phys_to_dma()/dma_to_phys() abstraction, but this is just a simple offset now. For PCI devices, the offset that is programmed into the PCI bridge must also be set in each device using dma_direct_set_offset(). As Arm does not have a pcibios_bus_add_device() helper yet, just use a bus notifier for this. For the ISA DMA, drivers now pass a non-translated physical address into set_dma_addr(), so they have to be converted back with the corresponding isa_bus_to_virt() function and then into the correct bus address with the offset using the isa_dma_dev. Tested-by: Marc Zyngier Signed-off-by: Arnd Bergmann

ARM/dma-mapping: use the generic versions of dma_to_phys/phys_to_dma by default

2022-07-07T16:18:57+00:00

Only the footbridge platforms provide their own DMA address translation helpers, so switch to the generic version for all other platforms, and consolidate the footbridge implementation to remove two levels of indirection. Signed-off-by: Christoph Hellwig Reviewed-by: Arnd Bergmann Tested-by: Marc Zyngier

ARM: 9104/2: Fix Keystone 2 kernel mapping regression

2021-08-10T11:17:25+00:00

This fixes a Keystone 2 regression discovered as a side effect of defining an passing the physical start/end sections of the kernel to the MMU remapping code. As the Keystone applies an offset to all physical addresses, including those identified and patches by phys2virt, we fail to account for this offset in the kernel_sec_start and kernel_sec_end variables. Further these offsets can extend into the 64bit range on LPAE systems such as the Keystone 2. Fix it like this: - Extend kernel_sec_start and kernel_sec_end to be 64bit - Add the offset also to kernel_sec_start and kernel_sec_end As passing kernel_sec_start and kernel_sec_end as 64bit invariably incurs BE8 endianness issues I have attempted to dry-code around these. Tested on the Vexpress QEMU model both with and without LPAE enabled. Fixes: 6e121df14ccd ("ARM: 9090/1: Map the lowmem and kernel separately") Reported-by: Nishanth Menon Suggested-by: Russell King Tested-by: Grygorii Strashko Tested-by: Nishanth Menon Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle)

ARM: 9097/1: mmu: Declare section start/end correctly

2021-06-21T10:39:39+00:00

The kernel test robot reported an interesting bug: A debug print was using %08x with kernel_sec_start and kernel_sec_end being phys_addr_t which can be either u32 or u64 (possibly more). Actually these should just be declared as u32 to begin with: they are declared as such in the assembly in head.S and the kernel definitely boots in a 32 bit physical address space. Redeclare the kernel_sec_start and kernel_sec_end to rid the bug. Reported-by: kernel test robot Fixes: 6e121df14ccd ("ARM: 9090/1: Map the lowmem and kernel separately") Signed-off-by: Linus Walleij Signed-off-by: Russell King

ARM: 9089/1: Define kernel physical section start and end

2021-06-13T17:16:41+00:00

When we are mapping the initial sections in head.S we know very well where the start and end of the kernel image in physical memory is placed. Later on it gets hard to determine this. Save the information into two variables named kernel_sec_start and kernel_sec_end for convenience for later work involving the physical start and end of the kernel. These variables are section-aligned corresponding to the early section mappings set up in head.S. Signed-off-by: Linus Walleij Signed-off-by: Russell King

ARM: 9088/1: Split KERNEL_OFFSET from PAGE_OFFSET

2021-06-13T17:16:40+00:00

We want to be able to compile the kernel into an address different from PAGE_OFFSET (start of lowmem) + TEXT_OFFSET, so start to pry apart the address of where the kernel is located from the address where the lowmem is located by defining and using KERNEL_OFFSET in a few key places. Signed-off-by: Linus Walleij Signed-off-by: Russell King

ARM: 9059/1: cache-v7: get rid of mini-stack

2021-03-09T10:25:18+00:00

Now that we have reduced the number of registers that we need to preserve when calling v7_invalidate_l1 from the boot code, we can use scratch registers to preserve the remaining ones, and get rid of the mini stack entirely. This works around any issues regarding cache behavior in relation to the uncached accesses to this memory, which is hard to get right in the general case (i.e., both bare metal and under virtualization) While at it, switch v7_invalidate_l1 to using ip as a scratch register instead of r4. This makes the function AAPCS compliant, and removes the need to stash r4 in ip across the call. Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King