linux.git/arch/powerpc/kernel/prom.c, branch v6.12

powerpc/prom: Add CPU info to hardware description string later

2024-06-28T12:31:00+00:00

cur_cpu_spec->cpu_name is appended to ppc_hw_desc before cur_cpu_spec
has taken on its final value. This is illustrated on pseries by
comparing the CPU name as reported at boot ("POWER8E (raw)") to the
contents of /proc/cpuinfo ("POWER8 (architected)"):

  $ dmesg | grep Hardware
  Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 \
    of:IBM,FW860.50 (SV860_146) hv:phyp pSeries

  $ grep -m 1 ^cpu /proc/cpuinfo
  cpu             : POWER8 (architected), altivec supported

Some 44x models would appear to be affected as well; see
identical_pvr_fixup().

This results in incorrect CPU information in stack dumps --
ppc_hw_desc is an input to dump_stack_set_arch_desc().

Delay gathering the CPU name until after all potential calls to
identify_cpu().

Signed-off-by: Nathan Lynch 
Fixes: bd649d40e0f2 ("powerpc: Add PVR & CPU name to hardware description")
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240603-fix-cpu-hwdesc-v1-1-945f2850fcaa@linux.ibm.com

powerpc/fadump: pass additional parameters when fadump is active

2024-05-10T06:36:10+00:00

Append the additional parameters passed/set in the dedicated parameter
area (RTAS_FADUMP_PARAM_AREA) to bootargs in fadump capture kernel.

Signed-off-by: Hari Bathini 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240509115755.519982-4-hbathini@linux.ibm.com

powerpc: Fix preserved memory size for int-vectors

2024-05-07T13:23:35+00:00

The first 32k of memory is reserved for interrupt vectors, however for
powerpc64 this might not be enough. Fix this by reserving the maximum
size between 32k and the real size of interrupt vectors.

Signed-off-by: GUO Zihua 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240113080509.1598290-1-guozihua@huawei.com

powerpc/mm: Update the memory limit based on direct mapping restrictions

2024-04-19T06:09:14+00:00

memory limit value specified by the user are further updated such that
the value is 16MB aligned. This is because hash translation mode use
16MB as direct mapping page size. Make sure we update the global
variable 'memory_limit' with the 16MB aligned value such that all kernel
components will see the new aligned value of the memory limit.

Signed-off-by: Aneesh Kumar K.V (IBM) 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240403083611.172833-3-aneesh.kumar@kernel.org

powerpc/mm: Align memory_limit value specified using mem= kernel parameter

2024-04-19T06:09:14+00:00

The value specified for the memory limit is used to set a restriction on
memory usage. It is important to ensure that this restriction is within
the linear map kernel address space range. The hash page table
translation uses a 16MB page size to map the kernel linear map address
space. htab_bolt_mapping() function aligns down the size of the range
while mapping kernel linear address space. Since the memblock limit is
enforced very early during boot, before we can detect the type of memory
translation (radix vs hash), we align the memory limit value specified
as a kernel parameter to 16MB. This alignment value will work for both
hash and radix translations.

Signed-off-by: Aneesh Kumar K.V (IBM) 
Acked-by: Joel Savitz 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240403083611.172833-1-aneesh.kumar@kernel.org

powerpc/kdump: Split KEXEC_CORE and CRASH_DUMP dependency

2024-03-17T02:34:00+00:00

Remove CONFIG_CRASH_DUMP dependency on CONFIG_KEXEC. CONFIG_KEXEC_CORE
was used at places where CONFIG_CRASH_DUMP or CONFIG_CRASH_RESERVE was
appropriate. Replace with appropriate #ifdefs to support CONFIG_KEXEC
and !CONFIG_CRASH_DUMP configuration option. Also, make CONFIG_FA_DUMP
dependent on CONFIG_CRASH_DUMP to avoid unmet dependencies for FA_DUMP
with !CONFIG_KEXEC_CORE configuration option.

Signed-off-by: Hari Bathini 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240226103010.589537-4-hbathini@linux.ibm.com

powerpc/pseries: Set CPU_FTR_DBELL according to ibm,pi-features

2024-02-21T12:14:52+00:00

PAPR will define a new ibm,pi-features bit which says that doorbells
should not be used even on architectures where they exist. This could be
because they are emulated and slower than using the interrupt controller
directly for IPIs.

Wire this bit into the pi-features parser to clear CPU_FTR_DBELL, and
ensure CPU_FTR_DBELL is not in CPU_FTRS_ALWAYS.

Signed-off-by: Nicholas Piggin 
Tested-by: Vaibhav Jain 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240207035220.339726-2-npiggin@gmail.com

powerpc/pseries: Add a clear modifier to ibm,pa/pi-features parser

2024-02-21T12:14:49+00:00

When a new ibm,pa/pi-features bit is introduced that is intended to
apply to existing systems and features, it may have an "inverted"
meaning (i.e., bit clear => feature available; bit set => unavailable).
Depending on the nature of the feature, this may give the best
backward compatibility result where old firmware will continue to
have that bit clear and therefore the feature available.

The 'invert' modifier presumably was introduced for this type of
feature bit. However it invert will set the feature if the bit is
clear, which prevents it being used in the situation where an old
CPU lacks a feature that a new CPU has, then a new firmware comes
out to disable that feature on the new CPU if the bit is set.
Adding an 'invert' entry for that feature would incorrectly enable
it for the old CPU.

So add a 'clear' modifier that clears the feature if the bit is set,
but it does not set the feature if the bit is clear. The feature
is expected to be set in the cpu table.

This replaces the 'invert' modifier, which is unused since commit
7d4703455168 ("powerpc/feature: Remove CPU_FTR_NODSISRALIGN").

Signed-off-by: Nicholas Piggin 
Tested-by: Vaibhav Jain 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20240207035220.339726-1-npiggin@gmail.com

powerpc/smp: Remap boot CPU onto core 0 if >= nr_cpu_ids

2024-02-14T13:14:05+00:00

If nr_cpu_ids is too low to include the boot CPU, remap the boot CPU
onto logical core 0.

This is achieved in two stages. In early_init_dt_scan_cpus() the boot
CPU is renumbered to be on logical core 0, and the original boot core's
hardware ID is recorded.

Later in smp_setup_cpu_maps(), if the original boot core ID is set, the
logical CPU numbers on the 0th core are skipped in the normal device
tree search over CPU device tree nodes. Then the search is continued
until the device tree node matching the boot core is found, and those
CPUs are assigned the CPU numbers starting at 0.

This allows kdump kernels to be booted with low values for nr_cpu_ids
to conserve memory, while also allowing the crashing/boot CPU to be
any CPU.

Signed-off-by: Michael Ellerman 
Tested-by: Wen Xiong 
Link: https://msgid.link/20231229120107.2281153-5-mpe@ellerman.id.au

powerpc/smp: Increase nr_cpu_ids to include the boot CPU

2024-02-14T13:14:04+00:00

If nr_cpu_ids is too low to include the boot CPU adjust nr_cpu_ids
upward. Otherwise the kernel will BUG when trying to allocate a paca
for the boot CPU and fail to boot.

Cc: stable@vger.kernel.org
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231229120107.2281153-2-mpe@ellerman.id.au