Changes in Makefile

a9ff9447 - ARM: 9433/2: implement cacheinfo support

Tue, 14 Jan 2025 11:54:52 +0000

ARM: 9433/2: implement cacheinfo supportOn ARMv7 / v7m machines read CTR and CLIDR registers to provideinformation regarding the cache topology. Earlier machines shoulddescribe full cache topology in the device tree.Note, this follows the ARM64 cacheinfo support and provides only minimalsupport required to bootstrap cache info. All useful properties shouldbe decribed in Device Tree.Reviewed-by: Linus Walleij Signed-off-by: Dmitry Baryshkov Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/Makefile

8d75537b - perf/arm: Move 32-bit PMU drivers to drivers/perf/

Wed, 26 Jun 2024 22:32:27 +0000

perf/arm: Move 32-bit PMU drivers to drivers/perf/It is preferred to put drivers under drivers/ rather than under arch/.The PMU drivers also depend on arm_pmu.c, so it's better to place themall together.Acked-by: Mark Rutland Signed-off-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-3-c9784b4f4065@kernel.orgSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm/kernel/Makefile

b9920fdd - ARM: 9352/1: iwmmxt: Remove support for PJ4/PJ4B cores

Wed, 14 Feb 2024 07:03:24 +0000

ARM: 9352/1: iwmmxt: Remove support for PJ4/PJ4B coresPJ4 is a v7 core that incorporates a iWMMXt coprocessor. However, GCCdoes not support this combination (its iWMMXt configuration alwaysimplies v5te), and so there is no v6/v7 user space that actually makesuse of this, beyond generic support for things like setjmp() thatpreserve/restore the iWMMXt register file using generic LDC/STCinstructions emitted in assembler. As [0] appears to imply, this logicis triggered for the init process at boot, and so most user threads willhave a iWMMXt register context associated with it, even though it isnever used.At this point, it is highly unlikely that such GCC support will evermaterialize (and Clang does not implement support for iWMMXt to beginwith).This means that advertising iWMMXt support on these cores results incontext switch overhead without any associated benefit, and so it isbetter to simply ignore the iWMMXt unit on these systems. So rip out thesupport. Doing so also fixes the issue reported in [0] related to UNDEFhandling of co-processor #0/#1 instructions issued from user spacerunning in Thumb2 mode.The PJ4 cores are used in four platforms: Armada 370/xp, Dove (Cubox,d2plug), MMP2 (xo-1.75) and Berlin (Google TV). Out of these, only thefirst is still widely used, but that one actually doesn't have iWMMXtbut instead has only VFPV3-D16, and so it is not impacted by thischange.Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218427 [0]Fixes: 8bcba70cb5c22 ("ARM: entry: Disregard Thumb undef exception ...")Acked-by: Linus Walleij Acked-by: Arnd Bergmann Acked-by: Nicolas Pitre Reviewed-by: Jisheng Zhang Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/Makefile

199da871 - arch, crash: move arch_crash_save_vmcoreinfo() out to file vmcore_info.c

Mon, 29 Jan 2024 13:50:33 +0000

arch, crash: move arch_crash_save_vmcoreinfo() out to file vmcore_info.cNathan reported below building error:=====$ curl -LSso .config https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.armv7$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- olddefconfig all..arm-linux-gnueabi-ld: arch/arm/kernel/machine_kexec.o: in function `arch_crash_save_vmcoreinfo':machine_kexec.c:(.text+0x488): undefined reference to `vmcoreinfo_append_str'====On architecutres, like arm, s390, ppc, sh, functionarch_crash_save_vmcoreinfo() is located in machine_kexec.c and it canonly be compiled in when CONFIG_KEXEC_CORE=y.That's not right because arch_crash_save_vmcoreinfo() is used to exportarch specific vmcoreinfo. CONFIG_VMCORE_INFO is supposed to control itscompiling in. However, CONFIG_VMVCORE_INFO could be independent ofCONFIG_KEXEC_CORE, e.g CONFIG_PROC_KCORE=y will select CONFIG_VMVCORE_INFO.Or CONFIG_KEXEC/CONFIG_KEXEC_FILE is set while CONFIG_CRASH_DUMP isnot set, it will report linking error.So, on arm, s390, ppc and sh, move arch_crash_save_vmcoreinfo out toa new file vmcore_info.c. Let CONFIG_VMCORE_INFO decide if compiling inarch_crash_save_vmcoreinfo().[akpm@linux-foundation.org: remove stray newlines at eof]Link: https://lkml.kernel.org/r/20240129135033.157195-3-bhe@redhat.comSigned-off-by: Baoquan He Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/all/20240126045551.GA126645@dev-arch.thelio-3990X/T/#uCc: Al Viro Cc: Eric W. Biederman Cc: Hari Bathini Cc: Klara Modin Cc: Michael Kelley Cc: Pingfan Liu Cc: Stephen Rothwell Cc: Yang Li Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/arm/kernel/Makefile

dccf78d3 - kernel/Kconfig.kexec: drop select of KEXEC for CRASH_DUMP

Tue, 28 Nov 2023 05:44:57 +0000

kernel/Kconfig.kexec: drop select of KEXEC for CRASH_DUMPIgnat Korchagin complained that a potential config regression wasintroduced by commit 89cde455915f ("kexec: consolidate kexec and crashoptions into kernel/Kconfig.kexec"). Before the commit, CONFIG_CRASH_DUMPhas no dependency on CONFIG_KEXEC. After the commit, CRASH_DUMP selectsKEXEC. That enforces system to have CONFIG_KEXEC=y as long asCONFIG_CRASH_DUMP=Y which people may not want.In Ignat's case, he sets CONFIG_CRASH_DUMP=y, CONFIG_KEXEC_FILE=y andCONFIG_KEXEC=n because kexec_load interface could have security issue ifkernel/initrd has no chance to be signed and verified.CRASH_DUMP has select of KEXEC because Eric, author of above commit, met aLKP report of build failure when posting patch of earlier version. Pleasesee below link to get detail of the LKP report: https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@oracle.com/T/#uIn fact, that LKP report is triggered because arm's iswrapped in CONFIG_KEXEC ifdeffery scope. That is wrong. CONFIG_KEXECcontrols the enabling/disabling of kexec_load interface, but not kexecfeature. Removing the wrongly added CONFIG_KEXEC ifdeffery scope in of arm allows us to drop the select KEXEC for CRASH_DUMP. Meanwhile, change arch/arm/kernel/Makefile to let machine_kexec.orelocate_kernel.o depend on KEXEC_CORE.Link: https://lkml.kernel.org/r/20231128054457.659452-1-bhe@redhat.comFixes: 89cde455915f ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")Signed-off-by: Baoquan He Reported-by: Ignat Korchagin Tested-by: Ignat Korchagin [compile-time only]Tested-by: Alexander Gordeev Reviewed-by: Eric DeVolder Tested-by: Eric DeVolder Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/arm/kernel/Makefile

a2faac39 - ARM: 9263/1: use .arch directives instead of assembler command line flags

Mon, 24 Oct 2022 19:44:41 +0000

ARM: 9263/1: use .arch directives instead of assembler command line flagsSimilar to commit a6c30873ee4a ("ARM: 8989/1: use .fpu assemblerdirectives instead of assembler arguments").GCC and GNU binutils support setting the "sub arch" via -march=,-Wa,-march, target function attribute, and .arch assembler directive.Clang was missing support for -Wa,-march=, but this was implemented inclang-13.The behavior of both GCC and Clang is toprefer -Wa,-march= over -march= for assembler and assembler-with-cppsources, but Clang will warn about the -march= being unused.clang: warning: argument unused during compilation: '-march=armv6k'[-Wunused-command-line-argument]Since most assembler is non-conditionally assembled with one sub arch(modulo arch/arm/delay-loop.S which conditionally is assembled as armv4based on CONFIG_ARCH_RPC, and arch/arm/mach-at91/pm-suspend.S which isconditionally assembled as armv7-a based on CONFIG_CPU_V7), prefer the.arch assembler directive.Add a few more instances found in compile testing as found by Arnd andNathan.Link: https://github.com/llvm/llvm-project/commit/1d51c699b9e2ebc5bcfdbe85c74cc871426333d4Link: https://bugs.llvm.org/show_bug.cgi?id=48894Link: https://github.com/ClangBuiltLinux/linux/issues/1195Link: https://github.com/ClangBuiltLinux/linux/issues/1315Suggested-by: Arnd Bergmann Suggested-by: Nathan Chancellor Signed-off-by: Arnd Bergmann Tested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/Makefile

32164845 - kbuild: use obj-y instead extra-y for objects placed at the head

Sat, 24 Sep 2022 18:19:14 +0000

kbuild: use obj-y instead extra-y for objects placed at the headThe objects placed at the head of vmlinux need special treatments: - arch/$(SRCARCH)/Makefile adds them to head-y in order to place them before other archives in the linker command line. - arch/$(SRCARCH)/kernel/Makefile adds them to extra-y instead of obj-y to avoid them going into built-in.a.This commit gets rid of the latter.Create vmlinux.a to collect all the objects that are unconditionallylinked to vmlinux. The objects listed in head-y are moved to the headof vmlinux.a by using 'ar m'.With this, arch/$(SRCARCH)/kernel/Makefile can consistently use obj-yfor builtin objects.There is no *.o that is directly linked to vmlinux. Drop unneeded codein scripts/clang-tools/gen_compile_commands.py.$(AR) mPi needs 'T' to workaround the llvm-ar bug. The fix was suggestedby Nathan Chancellor [1].[1]: https://lore.kernel.org/llvm/YyjjT5gQ2hGMH0ni@dev-arch.thelio-3990X/Signed-off-by: Masahiro Yamada Tested-by: Nick Desaulniers Reviewed-by: Nicolas Schier List of files: /linux-6.15/arch/arm/kernel/Makefile

e7536617 - ARM: footbridge: move isa-dma support into footbridge

Fri, 01 Jul 2022 09:44:52 +0000

ARM: footbridge: move isa-dma support into footbridgeThe dma-isa.c was shared between footbridge and shark a long time ago,but as shark was removed, it can be made footbridge specific again.The fb_dma bits in turn are not used at all and can be removed.All the ISA related files are now built into the platform regardlessof CONFIG_ISA, as they just refer to on-chip devices rather than actualISA cards.Reviewed-by: Christoph Hellwig Tested-by: Marc Zyngier Signed-off-by: Arnd Bergmann List of files: /linux-6.15/arch/arm/kernel/Makefile

6845d64d - ARM: 9184/1: return_address: disable again for CONFIG_ARM_UNWIND=y

Wed, 02 Mar 2022 11:38:18 +0000

ARM: 9184/1: return_address: disable again for CONFIG_ARM_UNWIND=yCommit 41918ec82eb6 ("ARM: ftrace: enable the graph tracer with the EABIunwinder") removed the dummy version of return_address() that wasprovided for the CONFIG_ARM_UNWIND=y case, on the assumption that theremoval of the kernel_text_address() call from unwind_frame() in thepreceding patch made it safe to do so.However, this turns out not to be the case: Corentin reports warningsabout suspicious RCU usage and other strange behavior that seems tooriginate in the stack unwinding that occurs in return_address().Given that the function graph tracer (which is what these changes wereenabling for CONFIG_ARM_UNWIND=y builds) does not appear to care aboutthis distinction, let's revert return_address() to the old state.Cc: Corentin Labbe Fixes: 41918ec82eb6 ("ARM: ftrace: enable the graph tracer with the EABI unwinder")Signed-off-by: Ard Biesheuvel Reported-by: Corentin Labbe Tested-by: Corentin Labbe Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/Makefile

9dd78194 - ARM: report Spectre v2 status through sysfs

Fri, 11 Feb 2022 16:45:54 +0000

ARM: report Spectre v2 status through sysfsAs per other architectures, add support for reporting the Spectrevulnerability status via sysfs CPU.Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/Makefile

41918ec8 - ARM: ftrace: enable the graph tracer with the EABI unwinder

Tue, 25 Jan 2022 14:55:24 +0000

ARM: ftrace: enable the graph tracer with the EABI unwinderEnable the function graph tracer in combination with the EABI unwinder,so that Thumb2 builds or Clang ARM builds can make use of it.This involves using the unwinder to locate the return address of aninstrumented function on the stack, so that it can be overridden andmade to refer to the ftrace handling routines that need to be called atfunction return.Given that for these builds, it is not guaranteed that the value of thelink register is stored on the stack, fall back to the stack slot thatwill be used by the ftrace exit code to restore LR in the instrumentedfunction's execution context.Signed-off-by: Ard Biesheuvel Reviewed-by: Steven Rostedt (Google) List of files: /linux-6.15/arch/arm/kernel/Makefile

538b9265 - ARM: unwind: track location of LR value in stack frame

Mon, 24 Jan 2022 15:49:09 +0000

ARM: unwind: track location of LR value in stack frameThe ftrace graph tracer needs to override the return address of aninstrumented function, in order to install a hook that gets invoked whenthe function returns again.Currently, we only support this when building for ARM using GCC withframe pointers, as in this case, it is guaranteed that the function willreload LR from [FP, #-4] in all cases, and we can simply pass thataddress to the ftrace code.In order to support this for configurations that rely on the EABIunwinder, such as Thumb2 builds, make the unwinder keep track of theaddress from which LR was unwound, permitting ftrace to make use of thisin a subsequent patch.Drop the call to is_kernel_text_address(), which is problematic in termsof ftrace recursion, given that it may be instrumented itself. The callis redundant anyway, as no unwind directives will be found unless the PCpoints to memory that is known to contain executable code.Signed-off-by: Ard Biesheuvel Reviewed-by: Nick Desaulniers List of files: /linux-6.15/arch/arm/kernel/Makefile

4d576cab - ARM: 9028/1: disable KASAN in call stack capturing routines

Tue, 17 Nov 2020 09:23:28 +0000

ARM: 9028/1: disable KASAN in call stack capturing routinesKASAN uses the routines in stacktrace.c to capture the call stack eachtime memory gets allocated or freed. Some of these routines are alsoused to log CPU and memory context when exceptions are taken, and soin some cases, memory accesses may be made that are not strictly inline with the KASAN constraints, and may therefore trigger false KASANpositives.So follow the example set by other architectures, and simply disableKASAN instrumentation for these routines.Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King List of files: /linux-6.15/arch/arm/kernel/Makefile

3e3f354b - ARM: remove ebsa110 platform

Thu, 24 Sep 2020 18:25:46 +0000

ARM: remove ebsa110 platformRussell said that he is no longer using this machine, and it seems thatnobody else has in a long time, so it's time to say goodbye to it.As this is the last platform using CONFIG_ARCH_USES_GETTIMEOFFSET,there are some follow-up patches to remove that as well.Acked-by: Russell King Signed-off-by: Arnd Bergmann List of files: /linux-6.15/arch/arm/kernel/Makefile

eae78e1a - ARM: p2v: move patching code to separate assembler source file

Sun, 20 Sep 2020 15:51:55 +0000

ARM: p2v: move patching code to separate assembler source fileMove the phys2virt patching code into a separate .S file before doingsome work on it.Suggested-by: Nicolas Pitre Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/arch/arm/kernel/Makefile

5a735583 - arm/ftrace: Use __patch_text()

Tue, 15 Oct 2019 19:07:35 +0000

arm/ftrace: Use __patch_text()Instead of flipping text protection, use the patch_text infrastructurethat uses a fixmap alias where required.This removes the last user of set_all_modules_text_*().Tested-by: Will Deacon Signed-off-by: Peter Zijlstra (Intel) Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: ard.biesheuvel@linaro.orgCc: james.morse@arm.comCc: rabin@rab.inLink: https://lkml.kernel.org/r/20191113092636.GG4131@hirez.programming.kicks-ass.netSigned-off-by: Ingo Molnar List of files: /linux-6.15/arch/arm/kernel/Makefile

fb033c95 - ARM: 8918/2: only build return_address() if needed

Mon, 04 Nov 2019 17:15:15 +0000

ARM: 8918/2: only build return_address() if neededThe system currently warns if the config conditions forbuilding return_address in arch/arm/kernel/return_address.care not met, leaving just an EXPORT_SYMBOL_GPL(return_address)of a function defined to be 'static linline'.This is a result of aeea3592a13b ("ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h").Since we're not going to build anything other than an exportedsymbol for something that is already being defined to be aninline-able return of NULL, just avoid building the code toremove the following warning:Fixes: aeea3592a13b ("ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h")Signed-off-by: Ben Dooks Signed-off-by: Russell King List of files: /linux-6.15/arch/arm/kernel/Makefile

a5b9177f - ARM: bugs: prepare processor bug infrastructure

Thu, 10 May 2018 11:55:58 +0000

ARM: bugs: prepare processor bug infrastructurePrepare the processor bug infrastructure so that it can be expanded tocheck for per-processor bugs.Signed-off-by: Russell King Reviewed-by: Florian Fainelli Boot-tested-by: Tony Lindgren Reviewed-by: Tony Lindgren Acked-by: Marc Zyngier List of files: /linux-6.15/arch/arm/kernel/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/arch/arm/kernel/Makefile

ca8b5d97 - ARM: XIP kernel: store .data compressed in ROM

Fri, 25 Aug 2017 04:54:18 +0000

ARM: XIP kernel: store .data compressed in ROMThe .data segment stored in ROM is only copied to RAM once at boot timeand never referenced afterwards. This is arguably a suboptimal usage ofROM resources.This patch allows for compressing the .data segment before storing itinto ROM and decompressing it to RAM rather than simply copying it,saving on precious ROM space.Because global data is not available yet (obviously) we must allocatedecompressor workspace memory on the stack. The .bss area is used as astack area for that purpose before it is cleared. The required stackframe is 9568 bytes for __inflate_kernel_data() alone, so make surethe .bss is large enough to cope with that plus extra room for calledfunctions or fail the build.Those numbers were picked arbitrarily based on the above 9568 bytestack frame:10240 (2.5 * PAGE_SIZE): used to override -Wframe-larger-than whosedefault value is 1024.12288 (3 * PAGE_SIZE): minimum .bss size to contain the stack.Signed-off-by: Nicolas Pitre Reviewed-by: Ard Biesheuvel Tested-by: Chris Brandt List of files: /linux-6.15/arch/arm/kernel/Makefile