PASEMI: PCI_SCAN_ALL_PCIE_DEVS

Hi All, Could you please add Olof‘s patch. Without this patch, we have to always add 'pci=pcie_scan_all' to the kernel boot arguments. Please add it. Olof's patch for P.A. Semi boards: --- arch/powerpc/platforms/pasemi/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCHv4 3/3] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.

From: Mahesh Salgaonkar The kernel boot parameter 'nr_cpus=' allows one to specify number of possible cpus in the system. In the normal scenario the first cpu (cpu0) that shows up is the boot cpu and hence it gets covered under nr_cpus limit. But this assumption will

[PATCHv4 2/3] powerpc, cpu: handling the special case when boot_cpuid greater than nr_cpus

For kexec -p, after boot_cpuid is mapping into the range of [0, threads_per_core), then if nr_cpus is small, we will have the bitmap [0,..., nr_cpus, ..., boot_cpuid, ...). This patch chooses cpus inside the range of [boot_cpuid - nr_cpus +1, ..., boot_cpuid] to be online. With this patch and the

[PATCHv4 1/3] powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt

For kexec -p, the boot cpu can be not the cpu0, this causes the problem to alloc paca[]. In theory, there is no requirement to assign cpu's logical id as its present seq by device tree. But we have something like cpu_first_thread_sibling(), which makes assumption on the mapping inside a core.

[PATCHv4 0/3] enable nr_cpus for powerpc

This topic has a very long history. It comes from Mahesh Salgaonkar For v3: https://patchwork.ozlabs.org/patch/834860/ In this series, I separate and change the mapping between cpu logical id and hwid. I hope we can acquire it for "kexec -p" Mahesh Salgaonkar (1):

Re: [PATCH v8 2/6] module: allow symbol exports to be disabled

On Sun, 11 Mar 2018, Ard Biesheuvel wrote: > To allow existing C code to be incorporated into the decompressor or > the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx > declarations into nops, and #define it in places where such exports > are undesirable. Note that this gets

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On Sun, Mar 11, 2018 at 1:35 PM, Ard Biesheuvel wrote: > > I'm sure all of these architectures define some kind of 32-bit place > relative relocation in their ELF psABI, and I see how it would be > cleaner to change everything at once, but I anticipate a long tail of >

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On 11 March 2018 at 20:20, Linus Torvalds wrote: > On Sun, Mar 11, 2018 at 5:38 AM, Ard Biesheuvel > wrote: >> Before updating certain subsystems to use place relative 32-bit >> relocations in special sections, to save space and reduce

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On Sun, Mar 11, 2018 at 5:38 AM, Ard Biesheuvel wrote: > Before updating certain subsystems to use place relative 32-bit > relocations in special sections, to save space and reduce the > number of absolute relocations that need to be processed at runtime > by

Re: [PATCH v8 0/6] add support for relative references in special sections

On Sun, Mar 11, 2018 at 5:44 AM, Ard Biesheuvel wrote: > On 11 March 2018 at 12:38, Ard Biesheuvel wrote: >> Cc: James Morris > > Note when replying: this ^^^ email address no longer works. James updated

Re: [PATCH v8 3/6] module: use relative references for __ksymtab entries

On 11 March 2018 at 12:38, Ard Biesheuvel wrote: > An ordinary arm64 defconfig build has ~64 KB worth of __ksymtab > entries, each consisting of two 64-bit fields containing absolute > references, to the symbol itself and to a char array containing > its name,

Re: [PATCH v8 0/6] add support for relative references in special sections

On 11 March 2018 at 12:38, Ard Biesheuvel wrote: ... > Cc: Arnd Bergmann > Cc: Kees Cook > Cc: Will Deacon > Cc: Michael Ellerman > Cc: Thomas Garnier > Cc: Thomas

[PATCH v8 6/6] kernel: tracepoints: add support for relative references

To avoid the need for relocating absolute references to tracepoint structures at boot time when running relocatable kernels (which may take a disproportionate amount of space), add the option to emit these tables as relative references instead. Cc: Ingo Molnar Acked-by: Steven

[PATCH v8 5/6] PCI: Add support for relative addressing in quirk tables

Allow the PCI quirk tables to be emitted in a way that avoids absolute references to the hook functions. This reduces the size of the entries, and, more importantly, makes them invariant under runtime relocation (e.g., for KASLR) Acked-by: Bjorn Helgaas Signed-off-by: Ard

[PATCH v8 4/6] init: allow initcall tables to be emitted using relative references

Allow the initcall tables to be emitted using relative references that are only half the size on 64-bit architectures and don't require fixups at runtime on relocatable kernels. Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt

[PATCH v8 3/6] module: use relative references for __ksymtab entries

An ordinary arm64 defconfig build has ~64 KB worth of __ksymtab entries, each consisting of two 64-bit fields containing absolute references, to the symbol itself and to a char array containing its name, respectively. When we build the same configuration with KASLR enabled, we end up with an

[PATCH v8 0/6] add support for relative references in special sections

This adds support for emitting special sections such as initcall arrays, PCI fixups and tracepoints as relative references rather than absolute references. This reduces the size by 50% on 64-bit architectures, but more importantly, it removes the need for carrying relocation metadata for these

[PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

Before updating certain subsystems to use place relative 32-bit relocations in special sections, to save space and reduce the number of absolute relocations that need to be processed at runtime by relocatable kernels, introduce the Kconfig symbol and define it for some architectures that should be

[PATCH v8 2/6] module: allow symbol exports to be disabled

To allow existing C code to be incorporated into the decompressor or the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx declarations into nops, and #define it in places where such exports are undesirable. Note that this gets rid of a rather dodgy redefine of linux/export.h's

[PATCH] powerpc: Use common error handling code in setup_new_fdt()

From: Markus Elfring Date: Sun, 11 Mar 2018 09:03:42 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring