- 21 Apr, 2023 13 commits
-
-
Michael Ellerman authored
Distros enable these options. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230414132415.821564-12-mpe@ellerman.id.au
-
Michael Ellerman authored
At least Fedora & SUSE enable it. VIRT_CPU_ACCOUNTING_GEN is selected so no longer needs to be in the defconfig. Signed-off-by:
-
Michael Ellerman authored
These options are enabled by most distros. Signed-off-by:
-
Michael Ellerman authored
Essentially all distros enable it. Signed-off-by:
-
Michael Ellerman authored
Traditionally on powerpc servers PREEMPT_NONE was used, but these days multiple distros are building with PREEMPT_VOLUNTARY - Ubuntu, Fedora & CentOS all enable it. So update the upstream config to reflect that, and get test coverage before code hits the distros. Signed-off-by:
-
Michael Ellerman authored
Tell the generic BPF code that the JIT should be enabled by default, rather than the interpreter. Most distros use CONFIG_BPF_JIT_ALWAYS_ON=y anyway, so this just updates upstream to more closely match that. Signed-off-by:
-
Michael Ellerman authored
Add the numerous options required to get secure boot enabled. Signed-off-by:
-
Michael Ellerman authored
This is a powerpc specific driver so add the symbols required to enable it so it gets some build/boot test coverage. Signed-off-by:
-
Michael Ellerman authored
These algorithms were marked obsolete in commit 1674aea5 ("crypto: Kconfig - mark unused ciphers as obsolete"). Signed-off-by:
-
Michael Ellerman authored
Since commit de551f2e ("net: Build IPv6 into kernel by default"), IPV6 is default y. Signed-off-by:
-
Michael Ellerman authored
SPLPAR is default y since commit 20c0e826 ("powerpc/pseries: Implement paravirt qspinlocks for SPLPAR"), so doesn't need to be in the defconfig. Signed-off-by:
-
Michael Ellerman authored
Update ppc64_defconfig to account for symbols moving around, no actual changes. Signed-off-by:
-
Michael Ellerman authored
Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by:
-
- 20 Apr, 2023 27 commits
-
-
Michael Ellerman authored
It's not necessary to prefix every command in archhelp with "@" (to suppress echoing the command), because that is done by the top level Makefile when it evaluates archhelp. Signed-off-by:
-
Michael Ellerman authored
Code in the idle path is not allowed to be instrumented because RCU is disabled, see commit 0e985e9d ("cpuidle: Add comments about noinstr/__cpuidle usage"). Force inlining of the inline functions called from cpuidle, to ensure they are not emitted out-of-line and then available for tracing. Signed-off-by:
-
Michael Ellerman authored
Code in the idle path is not allowed to be instrumented because RCU is disabled, see commit 0e985e9d ("cpuidle: Add comments about noinstr/__cpuidle usage"). Mark the cpuidle ->enter() callbacks as __cpuidle and use the raw_local_irq_*() routines to ensure that is the case. Reported-by:
Sachin Sant <sachinp@linux.ibm.com> Link: https://lore.kernel.org/all/4C073F6A-C812-4C4A-BB7A-ECD10B75FB88@linux.ibm.com/Suggested-by:
Peter Zijlstra <peterz@infradead.org> Tested-by:
-
Michael Ellerman authored
Since commit a01353cf ("cpuidle: Fix ct_idle_*() usage"), the cpuidle entry code calls trace_hardirqs_on() (actually trace_hardirqs_on_prepare()) in ct_cpuidle_enter() before calling into the cpuidle driver. Suggested-by:
-
Michael Ellerman authored
Code in the idle path is not allowed to be instrumented because RCU is disabled, see commit 0e985e9d ("cpuidle: Add comments about noinstr/__cpuidle usage"). Mark prep_irq_for_idle() __cpuidle, which is equivalent to noinstr, to enforce that. Suggested-by:
-
Michael Ellerman authored
check_return_regs_valid() is called from the middle of the irq exit handling, which is all notrace, so mark it notrace also. Reported-by:
-
Michael Ellerman authored
Add PPC_QEMU_E500 to corenet_base.config, which is then used to generate corenet64_smp_defconfig and corenet32_smp_defconfig. That then allows both those configs to build kernels that boot in qemu using the ppce500 machine type and respectively -cpu e5500 or -cpu e500mc. The code that is added by PPC_QEMU_E500 just defines another machine with a probe function that recognises qemu, so there should be no change when booting on actual hardware supported by CORENET_GENERIC. The increase in vmlinux size is less than 1KB. Signed-off-by:
-
Paul Gortmaker authored
With the two platforms depending on this shared code, and no others, we can remove the orphaned code and Kconfigs Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Paul Gortmaker authored
Based on documentation revision dates, this MPC82xx pq2fads system predates the MPC8272-ADS variant by about a year and only has 1/2 the amount of RAM (32MB) -- largely making it useless with a modern v6.x kernel from today. Similar to the MPC8272-ADS the pq2fads also supported other 82xx CPU variants, had 8MB flash, and like the 8272 ADS platform, was on a fairly large PCB in order to have space for breakout connectors for all features. These 82xx platforms are two decades old, and originally made for a small group of industry related people in order to assist in new OEM board designs. Given that, it makes sense to remove support today. Signed-off-by:
-
Paul Gortmaker authored
The MPC8272-ADS also supported other 82xx CPU variants, had 64MB RAM, 8MB flash, and like the 85xx ADS platforms, was on a fairly large PCB in order to have space for breakout connectors for all the features. These 82xx platforms are two decades old, and originally made for a small group of industry related people in order to assist in new OEM board designs. Given that, it makes sense to remove support today. Signed-off-by:
-
Paul Gortmaker authored
This evaluation platform was essentially a single core 8641 with integrated graphics/display support - in an effort to reduce chip count on kiosk and similar applications. Compared to other evaluation platforms considered for removal in other recent commits, this platform was relatively rare. Unlike all the other 10+ platforms, I couldn't find any documentation on it - just a link to downloading the 2007 era BSP in "LTIB" format as was done back then. With all that in mind, it seems prudent to remove it here in 2023. Signed-off-by:
-
Paul Gortmaker authored
There is no denying that this was an interesting platform in its day. Access to a SMP powerpc platform became a bit more obtainable for folks in the BSP industry in the 2007 era, thanks to this platform. Add to that the move to the black Antec case vs. the generic white 2005 era case of the MPC8548CDS or the retro 1950s 1/2 height horizontal case of the HPC II, and it was pretty interesting to people like myself then. However, like all the other evaluation platforms, the overall system was complex out of necessity, as it tried to showcase all possible features and use-cases. That included an AMP option, where you could run two bootloaders and two kernels over two serial consoles. Peripheral sharing got a bit more tricky when you got to the hard disk and similar. In any case we still have the same circumstance. A relatively rare and expensive evaluation platform that is now 15+ years old and not out there in large numbers in the general public. Removal in 2023 just makes sense. Signed-off-by:
-
Paul Gortmaker authored
This was an interesting platform - it was the 1st instance of a respin of earlier 130nm 74xx CPUs on 90nm and systems using MPC7448 were positioned as a rack server platform solution. Given that, the evaluation platform (at least the one I had) was shipped in a horizontal 1/2 height Antec desktop case with retro styling and colours, despite the fact the docs explicitly stated that the HPC II is not a desktop machine (noting it had no gfx or legacy PC I/O support). Historic trivia aside, this was the 1st introduction of the e600 procfam as an evolution from the earlier G4. However even with the claim to being "1st e600" it seems the 2005+ era was turning its attention to multicore support and from my memory this poor guy was quickly overshadowed by the dual core MPC8641D. All that aside, we are once again looking at 15+ year old evaluation platforms that were not widely distributed, so 2023 removal makes sense. Signed-off-by:
-
Paul Gortmaker authored
This final variant in the e300 family of Modular Development System (MDS) in this series was actually aimed at feature reduction - things like floating point and ethernet were removed in order to make for a lower power and lower cost system. Like all the MDS systems, it was meant as a vehicle to get the CPU out early to hardware OEMs so software and board development could take place in parallel. These were made in limited numbers and availability preference was given to partners who were planning to make their own boards. Given that the whole reason for existence was to assist in enabling new board designs [not happening for 10+ years], and that they weren't generally available, and that the hardware wasn't really hobbyist friendly even for retro computing, it makes sense to retire the support for this particular platform. Signed-off-by:
Li Yang <leoyang.li@nxp.com> [mpe: Drop stale reference to MPC832x_MDS in arch/powerpc/boot/Makefile] Signed-off-by:
-
Paul Gortmaker authored
This next evolutionary step in the e300 family of Modular Development System (MDS) still has, at its core component, a full length card with a PCI edge. No case. Serial and network connectors were on card, so it could optionally be fitted with plastic stand-offs and run stand-alone off a power brick. This is very similar to the MPC834x_MDS and MPC836x_MDS removed in the prior commits, but with this board variant as yet another evolutionary step. SATA and PCI-e were now available. But overall the form factor and design goals were unchanged. Like all the MDS systems, it was meant as a vehicle to get the CPU out early to hardware OEMs so software and board development could take place in parallel. These were made in limited numbers and availability preference was given to partners who were planning to make their own boards. Given that the whole reason for existence was to assist in enabling new board designs [not happening for 10+ years], and that they weren't generally available, and that the hardware wasn't really hobbyist friendly even for retro computing, it makes sense to retire the support for this particular platform. Signed-off-by:
-
Paul Gortmaker authored
This 2006 era Modular Development System (MDS) has, at its core component, a full length card with a PCI edge. No case. Serial and network connectors were on card, so it could optionally be fitted with plastic stand-offs and run stand-alone off a power brick. This is very similar to the MPC834x_MDS removed in the prior commit, but with this board variant as an evolutionary step. DDR2 was now an option, and the card edge was revised down to PCI-32 as PCI-64 never got traction. But overall the form factor and design goals were unchanged. Like all the MDS systems, it was meant as a vehicle to get the CPU out early to hardware OEMs so software and board development could take place in parallel. To that end, the BGA CPU was held in place with a mechanical spring loaded pressure assembly (vs. solder) so that early rev silicon could be replaced in the field. Not for COTS deployment! These were made in limited numbers and availability preference was given to partners who were planning to make their own boards. Given that the whole reason for existence was to assist in enabling new board designs [not happening for 10+ years], and that they weren't generally available, and that the hardware wasn't really hobbyist friendly even for retro computing, it makes sense to retire the support for this particular platform. Signed-off-by:
-
Paul Gortmaker authored
This 2006 era Modular Development System (MDS) has, at its core component, a full length card with a PCI-64 edge. No case. Serial and network connectors were on card, so it could optionally be fitted with plastic stand-offs and run stand-alone off a power brick. Like all the MDS systems, it was meant as a vehicle to get the CPU out early to hardware OEMs so software and board development could take place in parallel. To that end, the BGA CPU was held in place with a mechanical spring loaded pressure assembly (vs. solder) so that early rev silicon could be replaced in the field. Not for COTS deployment! These were made in limited numbers and availability preference was given to partners who were planning to make their own boards, like our WR SBC8349 [since retired in v4.18 (2017, commit 3bc6cf5a)] Given that the whole reason for existence was to assist in enabling new board designs [not happening for 10+ years], and that they weren't generally available, and that the hardware wasn't really hobbyist friendly even for retro computing, it makes sense to retire the support for this platform. Signed-off-by:
-
Andrew Donnellan authored
Add a firmware feature flag, FW_FEATURE_PLPKS, to indicate availability of Platform KeyStore related hcalls. Check this flag in plpks_is_available() and pseries_plpks_init() before trying to make an hcall. Suggested-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
-
Benjamin Gray authored
Reducing the time taken by dscr_sysfs_test.c allows restoring the default timeout, which was removed in commit 850507f3 ("selftests/powerpc: Turn off timeout setting for benchmarks, dscr, signal, tm") because that test took too long. Signed-off-by:
Benjamin Gray <bgray@linux.ibm.com> Signed-off-by:
-
Benjamin Gray authored
This test case is extremely slow, taking around a minute compared to most of the other DSCR tests taking a second at most. Perf shows most time is spent by the kernel switching to each CPU it reads in /sys/devices/system/cpu. This switching is an unavoidable consequnce of reading all the .../cpuN/dscr values. Remove the outer iteration loop from this test case, reducing the reads from 1600 to 16. This still updates the DSCR 16 times and verifies on every CPU each time, so I do not expect the lower coverage to be meaningful. The speedup is significant: back down to ~1 second like the other tests. Signed-off-by:
-
Benjamin Gray authored
The tests currently have a single writer thread updating the system DSCR with a 1/1000 chance looped only 100 times. So only around one in 10 runs actually do anything. * Add multiple threads to the dscr_explicit_random_test case. * Use a barrier to make all the threads start work as simultaneously as possible. * Use a rwlock and make all threads have a reasonable chance to write to the DSCR on each iteration. PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP is used to prevent writers from starving while all the other threads keep reading. Logging the reads/writes shows a decent mix across the whole test. * Allow all threads a chance to write. * Make the chance of writing more likely. Signed-off-by:
-
Benjamin Gray authored
Add new cases to the relevant tests that use explicitly synchronized threads to test the behaviour across context switches with less randomness. By locking the participants to the same CPU we guarantee a context switch occurs each time they make progress, which is a likely failure point if the kernel is not tracking the thread local DSCR correctly. The random case is left in to keep exercising potential edge cases. Signed-off-by:
-
Benjamin Gray authored
All current users of bind_to_cpu() don't care _which_ CPU they get, just that they are bound to a single free one. So alter the interface to 1. Accept a BIND_CPU_ANY value that tells it to automatically pick a CPU 2. Return the picked CPU And convert all these users to bind_to_cpu(BIND_CPU_ANY). Signed-off-by:
-
Benjamin Gray authored
This function will be useful in the DSCR test patches later in this series, so promote it to be shared by all powerpc selftests. Signed-off-by:
-
Benjamin Gray authored
Correct a couple of typos while working on other improvements to the DSCR tests. Signed-off-by:
-
Joel Stanley authored
There are two copies of these defines. Keep the older ones as they have associated bit definitions. Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Nicholas Piggin authored
Build modules using PCREL addressing when CONFIG_PPC_KERNEL_PCREL=y. - The module loader must handle several new relocation types: * R_PPC64_REL24_NOTOC is a function call handled like R_PPC_REL24, but does not restore r2 upon return. The external function call stub is changed to use pcrel addressing to load the function pointer rather than based on the module TOC. * R_PPC64_GOT_PCREL34 is a reference to external data. A GOT table must be built by hand, because the linker adds this during the final link (which is not done for kernel modules). The GOT table is built similarly to the way the external function call stub table is. This section is called .mygot because .got has a special meaning for the linker and can become upset. * R_PPC64_PCREL34 is used for local data addressing, but there is a special case where the percpu section is moved at load-time to the percpu area which is out of range of this relocation. This requires the PCREL34 relocations are converted to use GOT_PCREL34 addressing. Signed-off-by:Nicholas Piggin <npiggin@gmail.com> [mpe: Some coding style & formatting fixups] Signed-off-by:
-
