kernel.git/arch/powerpc/platforms/microwatt, branch linux-rolling-stable

powerpc/microwatt: Add SMP support

2025-02-26T15:46:48Z

This adds support for Microwatt systems with more than one core, and updates the device tree for a 2-core version. The secondary CPUs are started and sent to spin in __secondary_hold very early on, in the platform probe function. The reason for doing this is so that they are there when smp_release_cpus() gets called, which is before the platform init_smp function or even the platform setup_arch function gets called. Note that having two CPUs in the device tree doesn't preclude operation with only one CPU. The SYSCON_CPU_CTRL register has a read-only field which indicates the number of CPU cores, so microwatt_init_smp() will only start as many CPU cores as are present in the system, and any extra CPU device-tree nodes will just be ignored. Signed-off-by: Paul Mackerras Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/Z5xt8aooKyXZv6Kf@thinks.paulus.ozlabs.org

powerpc/microwatt: Define an idle power-save function

2025-02-26T15:46:48Z

This uses the 'wait' instruction to pause instruction execution when idle until an interrupt occurs. Signed-off-by: Paul Mackerras Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/Z5xtl1m_Gqc-HLjY@thinks.paulus.ozlabs.org

powerpc/microwatt: Select COMMON_CLK in order to get the clock framework

2025-02-26T15:46:48Z

This is to allow us to select Litex MMC host controller driver, which drives the litesdcard gateware. Signed-off-by: Paul Mackerras Acked-by: Nicholas Piggin Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/Z5xtT47QsnFpxc5E@thinks.paulus.ozlabs.org

powerpc: Make generic_calibrate_decr() the default

2023-03-15T21:56:48Z

ppc_md.calibrate_decr() is a mandatory item. Its nullity is never checked so it must be non null on all platforms. Most platforms define generic_calibrate_decr() as their ppc_md.calibrate_decr(). Have time_init() call generic_calibrate_decr() when ppc_md.calibrate_decr() is NULL, and remove default assignment from all machines. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://msgid.link/6cb9865d916231c38401ba34ad1a98c249fae135.1676711562.git.christophe.leroy@csgroup.eu

powerpc/platforms: Use 'compatible' property for simple cases

2023-03-14T13:52:10Z

Use the new 'compatible' property for simple cases. checkpatch complains about the new compatible being undocumented but in reality nothing is new so just ignore it for the time being. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://msgid.link/6cb9865d916231c38401ba34ad1a98c249fae135.1676711562.git.christophe.leroy@csgroup.eu

random: remove CONFIG_ARCH_RANDOM

2022-07-18T13:03:37Z

When RDRAND was introduced, there was much discussion on whether it should be trusted and how the kernel should handle that. Initially, two mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and "nordrand", a boot-time switch. Later the thinking evolved. With a properly designed RNG, using RDRAND values alone won't harm anything, even if the outputs are malicious. Rather, the issue is whether those values are being *trusted* to be good or not. And so a new set of options were introduced as the real ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu". With these options, RDRAND is used, but it's not always credited. So in the worst case, it does nothing, and in the best case, maybe it helps. Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the center and became something certain platforms force-select. The old options don't really help with much, and it's a bit odd to have special handling for these instructions when the kernel can deal fine with the existence or untrusted existence or broken existence or non-existence of that CPU capability. Simplify the situation by removing CONFIG_ARCH_RANDOM and using the ordinary asm-generic fallback pattern instead, keeping the two options that are actually used. For now it leaves "nordrand" for now, as the removal of that will take a different route. Acked-by: Michael Ellerman Acked-by: Catalin Marinas Acked-by: Borislav Petkov Acked-by: Heiko Carstens Acked-by: Greg Kroah-Hartman Signed-off-by: Jason A. Donenfeld

powerpc/microwatt: wire up rng during setup_arch()

2022-06-18T00:19:10Z

The platform's RNG must be available before random_init() in order to be useful for initial seeding, which in turn means that it needs to be called from setup_arch(), rather than from an init call. Fortunately, each platform already has a setup_arch function pointer, which means it's easy to wire this up. This commit also removes some noisy log messages that don't add much. Fixes: c25769fddaec ("powerpc/microwatt: Add support for hardware random number generator") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Jason A. Donenfeld Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220611151015.548325-2-Jason@zx2c4.com

powerpc/microwatt: add POWER9_CPU, clear PPC_64S_HASH_MMU

2021-12-09T11:41:16Z

Microwatt implements a subset of ISA v3.0 (which is equivalent to the POWER9_CPU option). It is radix-only, so does not require hash MMU support. This saves 20kB compressed dtbImage and 56kB vmlinux size. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211201144153.2456614-19-npiggin@gmail.com

powerpc/64s: Make hash MMU support configurable

2021-12-09T11:40:24Z

This adds Kconfig selection which allows 64s hash MMU support to be disabled. It can be disabled if radix support is enabled, the minimum supported CPU type is POWER9 (or higher), and KVM is not selected. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211201144153.2456614-17-npiggin@gmail.com

powerpc: Rename PPC_NATIVE to PPC_HASH_MMU_NATIVE

2021-12-02T11:57:22Z

PPC_NATIVE now only controls the native HPT code, so rename it to be more descriptive. Restrict it to Book3S only. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211201144153.2456614-3-npiggin@gmail.com