linux.git/arch/arm64/kernel/setup.c, branch v5.10

memblock: use separate iterators for memory and reserved regions

2020-10-14T01:38:35+00:00

for_each_memblock() is used to iterate over memblock.memory in a few
places that use data from memblock_region rather than the memory ranges.

Introduce separate for_each_mem_region() and
for_each_reserved_mem_region() to improve encapsulation of memblock
internals from its users.

Signed-off-by: Mike Rapoport 
Signed-off-by: Andrew Morton 
Reviewed-by: Baoquan He 
Acked-by: Ingo Molnar 			[x86]
Acked-by: Thomas Bogendoerfer 	[MIPS]
Acked-by: Miguel Ojeda 	[.clang-format]
Cc: Andy Lutomirski 
Cc: Benjamin Herrenschmidt 
Cc: Borislav Petkov 
Cc: Catalin Marinas 
Cc: Christoph Hellwig 
Cc: Daniel Axtens 
Cc: Dave Hansen 
Cc: Emil Renner Berthing 
Cc: Hari Bathini 
Cc: Ingo Molnar 
Cc: Jonathan Cameron 
Cc: Marek Szyprowski 
Cc: Max Filippov 
Cc: Michael Ellerman 
Cc: Michal Simek 
Cc: Palmer Dabbelt 
Cc: Paul Mackerras 
Cc: Paul Walmsley 
Cc: Peter Zijlstra 
Cc: Russell King 
Cc: Stafford Horne 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: Yoshinori Sato 
Link: https://lkml.kernel.org/r/20200818151634.14343-18-rppt@kernel.org
Signed-off-by: Linus Torvalds

memblock: implement for_each_reserved_mem_region() using __next_mem_region()

2020-10-14T01:38:35+00:00

Iteration over memblock.reserved with for_each_reserved_mem_region() used
__next_reserved_mem_region() that implemented a subset of
__next_mem_region().

Use __for_each_mem_range() and, essentially, __next_mem_region() with
appropriate parameters to reduce code duplication.

While on it, rename for_each_reserved_mem_region() to
for_each_reserved_mem_range() for consistency.

Signed-off-by: Mike Rapoport 
Signed-off-by: Andrew Morton 
Acked-by: Miguel Ojeda 	[.clang-format]
Cc: Andy Lutomirski 
Cc: Baoquan He 
Cc: Benjamin Herrenschmidt 
Cc: Borislav Petkov 
Cc: Catalin Marinas 
Cc: Christoph Hellwig 
Cc: Daniel Axtens 
Cc: Dave Hansen 
Cc: Emil Renner Berthing 
Cc: Hari Bathini 
Cc: Ingo Molnar 
Cc: Ingo Molnar 
Cc: Jonathan Cameron 
Cc: Marek Szyprowski 
Cc: Max Filippov 
Cc: Michael Ellerman 
Cc: Michal Simek 
Cc: Palmer Dabbelt 
Cc: Paul Mackerras 
Cc: Paul Walmsley 
Cc: Peter Zijlstra 
Cc: Russell King 
Cc: Stafford Horne 
Cc: Thomas Bogendoerfer 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: Yoshinori Sato 
Link: https://lkml.kernel.org/r/20200818151634.14343-17-rppt@kernel.org
Signed-off-by: Linus Torvalds

arm64: Remove exporting cpu_logical_map symbol

2020-09-02T07:35:28+00:00

Commit eaecca9e7710 ("arm64: Fix __cpu_logical_map undefined issue")
exported cpu_logical_map in order to fix tegra194-cpufreq module build
failure.

As this might potentially cause problem while supporting physical CPU
hotplug, tegra194-cpufreq module was reworded to avoid use of
cpu_logical_map() via the commit 93d0c1ab2328 ("cpufreq: replace
cpu_logical_map() with read_cpuid_mpir()")

Since cpu_logical_map was exported to fix the module build temporarily,
let us remove the same before it gains any user again.

Signed-off-by: Sudeep Holla 
Link: https://lore.kernel.org/r/20200901095229.56793-1-sudeep.holla@arm.com
Signed-off-by: Catalin Marinas

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2020-08-08T21:16:12+00:00

Pull arm64 fixes from Catalin Marinas:

 - Fix tegra194-cpufreq module build failure caused by __cpu_logical_map
   not being exported.

 - Improve fixed_addresses comment regarding the fixmap buffer sizes.

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: Fix __cpu_logical_map undefined issue
  arm64/fixmap: make notes of fixed_addresses more precisely

arm64: Fix __cpu_logical_map undefined issue

2020-08-08T18:25:04+00:00

The __cpu_logical_map undefined issue occued when the new
tegra194-cpufreq drvier building as a module.

ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko] undefined!

The driver using cpu_logical_map() macro which will expand to
__cpu_logical_map, we can't access it in a drvier. Let's turn
cpu_logical_map() into a C wrapper and export it to fix the
build issue.

Also create a function set_cpu_logical_map(cpu, hwid) when assign
a value to cpu_logical_map(cpu).

Reported-by: Hulk Robot 
Signed-off-by: Kefeng Wang 
Signed-off-by: Catalin Marinas

kasan, arm64: don't instrument functions that enable kasan

2020-08-07T18:33:28+00:00

This patch prepares Software Tag-Based KASAN for stack tagging support.

With stack tagging enabled, KASAN tags stack variable in each function in
its prologue.  In start_kernel() stack variables get tagged before KASAN
is enabled via setup_arch()->kasan_init().  As the result the tags for
start_kernel()'s stack variables end up in the temporary shadow memory.
Later when KASAN gets enabled, switched to normal shadow, and starts
checking tags, this leads to false-positive reports, as proper tags are
missing in normal shadow.

Disable KASAN instrumentation for start_kernel().  Also disable it for
arm64's setup_arch() as a precaution (it doesn't have any stack variables
right now).

[andreyknvl@google.com: reorder attributes for start_kernel()]
  Link: http://lkml.kernel.org/r/26fb6165a17abcf61222eda5184c030fb6b133d1.1596544734.git.andreyknvl@google.com

Signed-off-by: Andrey Konovalov 
Signed-off-by: Andrew Morton 
Acked-by: Catalin Marinas 	[arm64]
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Dmitry Vyukov 
Cc: Elena Petrova 
Cc: Marco Elver 
Cc: Vincenzo Frascino 
Cc: Walter Wu 
Cc: Ard Biesheuvel 
Link: http://lkml.kernel.org/r/55d432671a92e931ab8234b03dc36b14d4c21bfb.1596199677.git.andreyknvl@google.com
Signed-off-by: Linus Torvalds

arm64/panic: Unify all three existing notifier blocks

2020-07-02T14:44:50+00:00

Currently there are three different registered panic notifier blocks. This
unifies all of them into a single one i.e arm64_panic_block, hence reducing
code duplication and required calling sequence during panic. This preserves
the existing dump sequence. While here, just use device_initcall() directly
instead of __initcall() which has been a legacy alias for the earlier. This
replacement is a pure cleanup with no functional implications.

Signed-off-by: Anshuman Khandual 
Acked-by: Mark Rutland 
Cc: Will Deacon 
Cc: Steve Capper 
Cc: Mark Rutland 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/1593405511-7625-1-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas

arm64: warn on incorrect placement of the kernel by the bootloader

2020-06-11T13:13:13+00:00

Commit cfa7ede20f133c ("arm64: set TEXT_OFFSET to 0x0 in preparation for
removing it entirely") results in boot failures when booting kernels that
are built without KASLR support on broken bootloaders that ignore the
TEXT_OFFSET value passed via the header, and use the default of 0x80000
instead.

To work around this, turn CONFIG_RELOCATABLE on by default, even if KASLR
itself (CONFIG_RANDOMIZE_BASE) is turned off, and require CONFIG_EXPERT
to be enabled to deviate from this. Then, emit a warning into the kernel
log if we are not booting via the EFI stub (which is permitted to deviate
from the placement restrictions) and the kernel base address is not placed
according to the rules as laid out in Documentation/arm64/booting.rst.

Signed-off-by: Ard Biesheuvel 
Link: https://lore.kernel.org/r/20200611124330.252163-1-ardb@kernel.org
Signed-off-by: Will Deacon

arm64: Introduce get_cpu_ops() helper function

2020-03-24T17:24:19+00:00

This introduces get_cpu_ops() to return the CPU operations according to
the given CPU index. For now, it simply returns the @cpu_ops[cpu] as
before. Also, helper function __cpu_try_die() is introduced to be shared
by cpu_die() and ipi_cpu_crash_stop(). So it shouldn't introduce any
functional changes.

Signed-off-by: Gavin Shan 
Signed-off-by: Catalin Marinas 
Acked-by: Mark Rutland

arm64: Rename cpu_read_ops() to init_cpu_ops()

2020-03-24T17:24:13+00:00

This renames cpu_read_ops() to init_cpu_ops() as the function is only
called in initialization phase. Also, we will introduce get_cpu_ops() in
the subsequent patches, to retireve the CPU operation by the given CPU
index. The usage of cpu_read_ops() and get_cpu_ops() are difficult to be
distinguished from their names.

Signed-off-by: Gavin Shan 
Acked-by: Mark Rutland 
Signed-off-by: Catalin Marinas