linux-toradex.git/arch/arm/kernel/vmlinux-xip.lds.S, branch v6.8

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

Merge branches 'devel-stable' and 'misc' into for-linus

2021-11-02T09:04:22+00:00

ARM: 9140/1: allow compile-testing without machine record

2021-10-25T12:12:34+00:00

A lot of randconfig builds end up not selecting any machine type at
all. This is generally fine for the purpose of compile testing, but
of course it means that the kernel is not usable on actual hardware,
and it causes a warning about this fact.

As most of the build bots now force-enable CONFIG_COMPILE_TEST for
randconfig builds, use that as a guard to control whether we warn
on this type of broken configuration.

We could do the same for the missing-cpu-type warning, but those
configurations fail to build much earlier.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King (Oracle)

ARM: 9141/1: only warn about XIP address when not compile testing

2021-10-19T09:39:50+00:00

In randconfig builds, we sometimes come across this warning:

arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues

While this is helpful for actual systems to figure out why it
fails, the warning does not provide any benefit for build testing,
so guard it in a check for CONFIG_COMPILE_TEST, which is usually
set on randconfig builds.

Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King (Oracle)

ARM: 9138/1: fix link warning with XIP + frame-pointer

2021-10-19T09:38:22+00:00

When frame pointers are used instead of the ARM unwinder,
and the kernel is built using clang with an external assembler
and CONFIG_XIP_KERNEL, every file produces two warnings
like:

arm-linux-gnueabi-ld: warning: orphan section `.ARM.extab' from `net/mac802154/util.o' being placed in section `.ARM.extab'
arm-linux-gnueabi-ld: warning: orphan section `.ARM.exidx' from `net/mac802154/util.o' being placed in section `.ARM.exidx'

The same fix was already merged for the normal (non-XIP)

linker script, with a longer description.

Fixes: c39866f268f8 ("arm/build: Always handle .ARM.exidx and .ARM.extab sections")
Reviewed-by: Kees Cook 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King (Oracle)

arm/build: Assert for unwanted sections

2020-09-01T08:03:18+00:00

In preparation for warning on orphan sections, enforce
expected-to-be-zero-sized sections (since discarding them might hide
problems with them suddenly gaining unexpected entries).

Signed-off-by: Kees Cook 
Signed-off-by: Ingo Molnar 
Cc: Russell King 
Link: https://lore.kernel.org/r/20200821194310.3089815-19-keescook@chromium.org

arm/build: Add missing sections

2020-09-01T08:03:18+00:00

Add missing text stub sections .vfp11_veneer and .v4_bx, as well as
missing DWARF sections, when present in the build.

Signed-off-by: Kees Cook 
Signed-off-by: Ingo Molnar 
Reviewed-by: Nick Desaulniers 
Cc: Russell King 
Link: https://lore.kernel.org/r/20200821194310.3089815-18-keescook@chromium.org

arm/build: Explicitly keep .ARM.attributes sections

2020-09-01T08:03:18+00:00

In preparation for adding --orphan-handling=warn, explicitly keep the
.ARM.attributes section (at address 0[1]) by expanding the existing
ELF_DETAILS macro into ARM_DETAILS.

[1] https://reviews.llvm.org/D85867

Suggested-by: Nick Desaulniers 
Signed-off-by: Kees Cook 
Signed-off-by: Ingo Molnar 
Reviewed-by: Fangrui Song 
Cc: Russell King 
Link: https://lore.kernel.org/lkml/CAKwvOdk-racgq5pxsoGS6Vtifbtrk5fmkmnoLxrQMaOvV0nPWw@mail.gmail.com/
Link: https://lore.kernel.org/r/20200821194310.3089815-17-keescook@chromium.org

arm/build: Refactor linker script headers

2020-09-01T08:03:17+00:00

In preparation for adding --orphan-handling=warn, refactor the linker
script header includes, and extract common macros.

Signed-off-by: Kees Cook 
Signed-off-by: Ingo Molnar 
Cc: Russell King 
Link: https://lore.kernel.org/r/20200821194310.3089815-16-keescook@chromium.org

vmlinux.lds.h: Split ELF_DETAILS from STABS_DEBUG

2020-09-01T07:50:35+00:00

The .comment section doesn't belong in STABS_DEBUG. Split it out into a
new macro named ELF_DETAILS. This will gain other non-debug sections
that need to be accounted for when linking with --orphan-handling=warn.

Signed-off-by: Kees Cook 
Signed-off-by: Ingo Molnar 
Cc: linux-arch@vger.kernel.org
Link: https://lore.kernel.org/r/20200821194310.3089815-5-keescook@chromium.org