* Re: [PATCH v2 1/2] selftests/powerpc: Add missing clobbered register to to ptrace TM tests
From: Michael Ellerman @ 2021-08-27 13:16 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe; +Cc: mikey
In-Reply-To: <20210729041317.366612-1-jniethe5@gmail.com>
On Thu, 29 Jul 2021 14:13:16 +1000, Jordan Niethe wrote:
> ISA v3.1 removes TM but includes a synthetic implementation for
> backwards compatibility. With this implementation, the tests
> ptrace-tm-spd-gpr and ptrace-tm-gpr should never be able to make any
> forward progress and eventually should be killed by the timeout.
> Instead on a P10 running in P9 mode, ptrace_tm_gpr fails like so:
>
> test: ptrace_tm_gpr
> tags: git_version:unknown
> Starting the child
> ...
> ...
> GPR[27]: 1 Expected: 2
> GPR[28]: 1 Expected: 2
> GPR[29]: 1 Expected: 2
> GPR[30]: 1 Expected: 2
> GPR[31]: 1 Expected: 2
> [FAIL] Test FAILED on line 98
> failure: ptrace_tm_gpr
> selftests: ptrace-tm-gpr [FAIL]
>
> [...]
Applied to powerpc/next.
[1/2] selftests/powerpc: Add missing clobbered register to to ptrace TM tests
https://git.kernel.org/powerpc/c/c95278a0534449efc64ac8169382bce217963be2
[2/2] selftests: Skip TM tests on synthetic TM implementations
https://git.kernel.org/powerpc/c/e42edf9b9d126bb1c743f2e7984877ba27f09fe7
cheers
^ permalink raw reply
* Re: [PATCH v2 0/3] powerpc: mpc855_ads defconfig fixes
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman, Joel Stanley, Christophe Leroy
In-Reply-To: <20210817045407.2445664-1-joel@jms.id.au>
On Tue, 17 Aug 2021 14:24:04 +0930, Joel Stanley wrote:
> v2: fix typos, split out mtd fix from savedefconfig patch
>
> The first patch fixes a build warning I noticed when testing something
> unrelated.
>
> The second fixes a regression where the MTD partition support dropped out
> of the config. I have enabled the dependency so this is still part of
> the config.
>
> [...]
Applied to powerpc/next.
[1/3] powerpc/config: Fix IPV6 warning in mpc855_ads
https://git.kernel.org/powerpc/c/c5ac55b6cbc604ad4144c380feae20f69453df91
[2/3] powerpc/config: Renable MTD_PHYSMAP_OF
https://git.kernel.org/powerpc/c/d0e28a6145c3455b69991245e7f6147eb914b34a
[3/3] powerpc/configs: Regenerate mpc885_ads_defconfig
https://git.kernel.org/powerpc/c/87e0d46bf68913f4c87dba94aadc00da658a874b
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf/hv-gpci: Fix the logic to compute counter value from the hcall result buffer.
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: linuxppc-dev, Kajol Jain, mpe; +Cc: suka, atrajeev, maddy, rnsastry
In-Reply-To: <20210813082158.429023-1-kjain@linux.ibm.com>
On Fri, 13 Aug 2021 13:51:58 +0530, Kajol Jain wrote:
> H_GetPerformanceCounterInfo (0xF080) hcall returns the counter data in the
> result buffer. Result buffer has specific format defined in the PAPR
> specification. One of the field is counter offset and width of the counter
> data returned.
>
> Counter data are returned in a unsigned char array. To
> get the final counter data, these values should be left shifted
> byte at a time. But commit 220a0c609ad17 ("powerpc/perf: Add support
> for the hv gpci (get performance counter info) interface") made the
> shifting bitwise. Because of this, hcall counters values could end up
> in lower side, which messes the counter prev vs now calculation. This
> lead to huge counter value reporting
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/perf/hv-gpci: Fix the logic to compute counter value from the hcall result buffer.
https://git.kernel.org/powerpc/c/f9addd85fbfacf0d155e83dbee8696d6df5ed0c7
cheers
^ permalink raw reply
* Re: [PATCH v4 1/3] powerpc/perf: Use stack siar instead of mfspr
From: Michael Ellerman @ 2021-08-27 13:16 UTC (permalink / raw)
To: linuxppc-dev, christophe.leroy, mpe, Kajol Jain; +Cc: atrajeev, maddy, rnsastry
In-Reply-To: <20210818171556.36912-1-kjain@linux.ibm.com>
On Wed, 18 Aug 2021 22:45:54 +0530, Kajol Jain wrote:
> Minor optimization in the 'perf_instruction_pointer' function code by
> making use of stack siar instead of mfspr.
>
>
>
>
Applied to powerpc/next.
[1/3] powerpc/perf: Use stack siar instead of mfspr
https://git.kernel.org/powerpc/c/b1643084d164cea0c107a39bcdf0119fc52619af
[2/3] powerpc/perf: Drop the case of returning 0 as instruction pointer
https://git.kernel.org/powerpc/c/cc90c6742ef5b438f4cb86029d7a794bd0a44a06
[3/3] powerpc/perf: Fix the check for SIAR value
https://git.kernel.org/powerpc/c/3c69a5f22223fa3e312689ec218b5059784d49d7
cheers
^ permalink raw reply
* Re: [PATCH v2 0/2] Kconfig symbol fixes on powerpc
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: Lukas Bulwahn, linuxppc-dev, Michael Neuling, kvm-ppc,
Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
Anshuman Khandual
Cc: kernel-janitors, stable, linux-kernel
In-Reply-To: <20210819113954.17515-1-lukas.bulwahn@gmail.com>
On Thu, 19 Aug 2021 13:39:52 +0200, Lukas Bulwahn wrote:
> The script ./scripts/checkkconfigsymbols.py warns on invalid references to
> Kconfig symbols (often, minor typos, name confusions or outdated references).
>
> This patch series addresses all issues reported by
> ./scripts/checkkconfigsymbols.py in ./drivers/usb/ for Kconfig and Makefile
> files. Issues in the Kconfig and Makefile files indicate some shortcomings in
> the overall build definitions, and often are true actionable issues to address.
>
> [...]
Patch 1 applied to powerpc/next.
[1/2] powerpc: kvm: remove obsolete and unneeded select
https://git.kernel.org/powerpc/c/c26d4c5d4f0df7207da3975458261927f9305465
cheers
^ permalink raw reply
* Re: [PATCH v2] ppc: add "-z notext" flag to disable diagnostic
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: Daniel Axtens, Paul Mackerras, linuxppc-dev, clang-built-linux,
Nathan Chancellor, Fangrui Song, Benjamin Herrenschmidt,
Michael Ellerman, linux-kernel, Nick Desaulniers, Bill Wendling
Cc: Itaru Kitayama
In-Reply-To: <20210813200511.1905703-1-morbo@google.com>
On Fri, 13 Aug 2021 13:05:11 -0700, Bill Wendling wrote:
> Object files used to link .tmp_vmlinux.kallsyms1 have many R_PPC64_ADDR64
> relocations in non-SHF_WRITE sections. There are many text relocations (e.g. in
> .rela___ksymtab_gpl+* and .rela__mcount_loc sections) in a -pie link and are
> disallowed by LLD:
>
> ld.lld: error: can't create dynamic relocation R_PPC64_ADDR64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
> >>> defined in arch/powerpc/kernel/head_64.o
> >>> referenced by arch/powerpc/kernel/head_64.o:(__restart_table+0x10)
>
> [...]
Applied to powerpc/next.
[1/1] ppc: add "-z notext" flag to disable diagnostic
https://git.kernel.org/powerpc/c/0355785313e2191be4e1108cdbda94ddb0238c48
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Fix build error when NUMA=n
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman; +Cc: ldufour
In-Reply-To: <20210816041032.2839343-1-mpe@ellerman.id.au>
On Mon, 16 Aug 2021 14:10:32 +1000, Michael Ellerman wrote:
> As reported by lkp, if NUMA=n we see a build error:
>
> arch/powerpc/platforms/pseries/hotplug-cpu.c: In function 'pseries_cpu_hotplug_init':
> arch/powerpc/platforms/pseries/hotplug-cpu.c:1022:8: error: 'node_to_cpumask_map' undeclared
> 1022 | node_to_cpumask_map[node]);
>
> Use cpumask_of_node() which has an empty stub for NUMA=n, and when
> NUMA=y does a lookup from node_to_cpumask_map[].
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/pseries: Fix build error when NUMA=n
https://git.kernel.org/powerpc/c/8b893ef190b0c440877de04f767efca4bf4d6af8
cheers
^ permalink raw reply
* Re: (subset) [PATCH v2 00/60] KVM: PPC: Book3S HV P9: entry/exit optimisations
From: Michael Ellerman @ 2021-08-27 13:16 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <20210811160134.904987-1-npiggin@gmail.com>
On Thu, 12 Aug 2021 02:00:34 +1000, Nicholas Piggin wrote:
> This reduces radix guest full entry/exit latency on POWER9 and POWER10
> by 2x.
>
> Nested HV guests should see smaller improvements in their L1 entry/exit,
> but this is also combined with most L0 speedups also applying to nested
> entry. nginx localhost throughput test in a SMP nested guest is improved
> about 10% (in a direct guest it doesn't change much because it uses XIVE
> for IPIs) when L0 and L1 are patched.
>
> [...]
Applied to powerpc/next.
[01/60] KVM: PPC: Book3S HV: Initialise vcpu MSR with MSR_ME
https://git.kernel.org/powerpc/c/fd42b7b09c602c904452c0c3e5955ca21d8e387a
[02/60] KVM: PPC: Book3S HV: Remove TM emulation from POWER7/8 path
https://git.kernel.org/powerpc/c/daac40e8d7a63ab8608132a7cfce411986feac32
[03/60] KVM: PPC: Book3S HV P9: Fixes for TM softpatch interrupt NIP
https://git.kernel.org/powerpc/c/4782e0cd0d184d727ad3b0cfe20d1d44d9f98239
[04/60] KVM: PPC: Book3S HV Nested: Fix TM softpatch HFAC interrupt emulation
https://git.kernel.org/powerpc/c/d82b392d9b3556b63e3f9916cf057ea847e173a9
[05/60] KVM: PPC: Book3S HV Nested: Sanitise vcpu registers
https://git.kernel.org/powerpc/c/7487cabc7ed2f7716bf304e4e97c57fd995cf70e
[06/60] KVM: PPC: Book3S HV Nested: Make nested HFSCR state accessible
https://git.kernel.org/powerpc/c/8b210a880b35ba75eb42b79dfd65e369c1feb119
[07/60] KVM: PPC: Book3S HV Nested: Stop forwarding all HFUs to L1
https://git.kernel.org/powerpc/c/7c3ded5735141ff4d049747c9f76672a8b737c49
[08/60] KVM: PPC: Book3S HV Nested: save_hv_return_state does not require trap argument
https://git.kernel.org/powerpc/c/f2e29db156523bf08a0524e0f4306a641912c6d9
[09/60] KVM: PPC: Book3S HV Nested: Reflect guest PMU in-use to L0 when guest SPRs are live
https://git.kernel.org/powerpc/c/1782663897945a5cf28e564ba5eed730098e9aa4
[10/60] powerpc/64s: Remove WORT SPR from POWER9/10
https://git.kernel.org/powerpc/c/0c8fb653d487d2873f5eefdcaf4cecff4e103828
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/head_check: use stdout for error messages
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Chen, Rong A, Nicholas Piggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <20210815222334.9575-1-rdunlap@infradead.org>
On Sun, 15 Aug 2021 15:23:34 -0700, Randy Dunlap wrote:
> Prefer stderr instead of stdout for error messages.
> This is a good practice and can help CI error detecting and
> reporting (0day in this case).
>
>
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/head_check: use stdout for error messages
https://git.kernel.org/powerpc/c/47c258d71ebfc832a760a1dc6540cf3c33968023
cheers
^ permalink raw reply
* Re: [PATCH v2 0/4] Some improvements on regs usage
From: Michael Ellerman @ 2021-08-27 13:16 UTC (permalink / raw)
To: linuxppc-dev, sxwjean
Cc: ravi.bangoria, Xiongwei Song, npiggin, oleg, efremov,
linux-kernel, paulus, aneesh.kumar
In-Reply-To: <20210807010239.416055-1-sxwjean@me.com>
On Sat, 7 Aug 2021 09:02:35 +0800, sxwjean@me.com wrote:
> From: Xiongwei Song <sxwjean@gmail.com>
>
> When CONFIG_4xx=y or CONFIG_BOOKE=y, currently in code we reference dsisr
> to get interrupt reasons and reference dar to get excepiton address.
> However, in reference manuals, esr is used for interrupt reasons and dear
> is used for excepiton address, so the patchset changes dsisr -> esr,
> dar -> dear for CONFIG_4xx=y or CONFIG_BOOKE=y.
>
> [...]
Applied to powerpc/next.
[1/4] powerpc: Optimize register usage for esr register
https://git.kernel.org/powerpc/c/4f8e78c0757e3c5a65d9d8ac76e2434c71a78f5a
[2/4] powerpc/64e: Get esr offset with _ESR macro
https://git.kernel.org/powerpc/c/cfa47772ca8d53d7a6c9b331a7f6e7c4c9827214
[3/4] powerpc: Optimize register usage for dear register
https://git.kernel.org/powerpc/c/4872cbd0ca35ca5b20d52e2539e7e1950f126e7b
[4/4] powerpc/64e: Get dear offset with _DEAR macro
https://git.kernel.org/powerpc/c/d9db6e420268b2d561731468a31f0b15e2e9a145
cheers
^ permalink raw reply
* Re: [PATCH] [v2] arch: powerpc: Remove duplicate includes
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: Frederic Weisbecker, Paul Mackerras, Christophe Leroy,
Pingfan Liu, linuxppc-dev, linux-kernel, Wan Jiabing,
Ganesh Goudar, Benjamin Herrenschmidt, Randy Dunlap,
Cédric Le Goater, Michael Ellerman, Geert Uytterhoeven,
Aneesh Kumar K.V, Nicholas Piggin, Michal Suchanek
Cc: kael_w
In-Reply-To: <20210323062916.295346-1-wanjiabing@vivo.com>
On Tue, 23 Mar 2021 14:29:05 +0800, Wan Jiabing wrote:
> mmu-hash.h: asm/bug.h has been included at line 12, so remove
> the duplicate one at line 21.
> interrupt.c: asm/interrupt.h has been included at line 12, so
> remove the duplicate one at line 10.
> time.c: linux/sched/clock.h has been included at line 33,so
> remove the duplicate one at line 56 and move sched/cputime.h
> under sched including segament.
>
> [...]
Applied to powerpc/next.
[1/1] arch: powerpc: Remove duplicate includes
https://git.kernel.org/powerpc/c/e225c4d6bc389701f2f63fc246420a1da3465ab5
cheers
^ permalink raw reply
* Re: [PATCH -next] selftests/powerpc: Remove duplicated include from tm-poison.c
From: Michael Ellerman @ 2021-08-27 13:15 UTC (permalink / raw)
To: Zheng Yongjun, Michael Ellerman, Shuah Khan
Cc: kernel-janitors, linuxppc-dev, linux-kselftest, Hulk Robot
In-Reply-To: <20210326064808.3262568-1-zhengyongjun3@huawei.com>
On Fri, 26 Mar 2021 14:48:08 +0800, Zheng Yongjun wrote:
> Remove duplicated include.
>
>
>
>
Applied to powerpc/next.
[1/1] selftests/powerpc: Remove duplicated include from tm-poison.c
https://git.kernel.org/powerpc/c/6af0b5570b59ce8dd1608a8e48f59eff3f4bdd04
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Fix build error when NUMA=n
From: Laurent Dufour @ 2021-08-27 13:24 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Michael Ellerman
In-Reply-To: <163007014079.52768.17457843527177515212.b4-ty@ellerman.id.au>
Le 27/08/2021 à 15:15, Michael Ellerman a écrit :
> On Mon, 16 Aug 2021 14:10:32 +1000, Michael Ellerman wrote:
>> As reported by lkp, if NUMA=n we see a build error:
>>
>> arch/powerpc/platforms/pseries/hotplug-cpu.c: In function 'pseries_cpu_hotplug_init':
>> arch/powerpc/platforms/pseries/hotplug-cpu.c:1022:8: error: 'node_to_cpumask_map' undeclared
>> 1022 | node_to_cpumask_map[node]);
>>
>> Use cpumask_of_node() which has an empty stub for NUMA=n, and when
>> NUMA=y does a lookup from node_to_cpumask_map[].
>>
>> [...]
>
> Applied to powerpc/next.
>
> [1/1] powerpc/pseries: Fix build error when NUMA=n
> https://git.kernel.org/powerpc/c/8b893ef190b0c440877de04f767efca4bf4d6af8
>
> cheers
>
Thanks, Michael, for fixing my bugs !
^ permalink raw reply
* Re: [PATCH v2] powerpc/32s: Fix random crashes by adding isync() after locking/unlocking KUEP
From: Michael Ellerman @ 2021-08-27 13:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy, fthain,
userm57, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4856f5574906e2aec0522be17bf3848a22b2cd0b.1629269345.git.christophe.leroy@csgroup.eu>
On Wed, 18 Aug 2021 06:49:29 +0000 (UTC), Christophe Leroy wrote:
> Commit b5efec00b671 ("powerpc/32s: Move KUEP locking/unlocking in C")
> removed the 'isync' instruction after adding/removing NX bit in user
> segments. The reasoning behind this change was that when setting the
> NX bit we don't mind it taking effect with delay as the kernel never
> executes text from userspace, and when clearing the NX bit this is
> to return to userspace and then the 'rfi' should synchronise the
> context.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/32s: Fix random crashes by adding isync() after locking/unlocking KUEP
https://git.kernel.org/powerpc/c/ef486bf448a057a6e2d50e40ae879f7add6585da
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/mm: Fix set_memory_*() against concurrent accesses
From: Michael Ellerman @ 2021-08-27 13:25 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman
Cc: lvivier, jniethe5, aneesh.kumar, npiggin, farosas
In-Reply-To: <20210818120518.3603172-1-mpe@ellerman.id.au>
On Wed, 18 Aug 2021 22:05:18 +1000, Michael Ellerman wrote:
> Laurent reported that STRICT_MODULE_RWX was causing intermittent crashes
> on one of his systems:
>
> kernel tried to execute exec-protected page (c008000004073278) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch
> Faulting instruction address: 0xc008000004073278
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: drm virtio_console fuse drm_panel_orientation_quirks ...
> CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 5.14.0-rc4+ #12
> Workqueue: events control_work_handler [virtio_console]
> NIP: c008000004073278 LR: c008000004073278 CTR: c0000000001e9de0
> REGS: c00000002e4ef7e0 TRAP: 0400 Not tainted (5.14.0-rc4+)
> MSR: 800000004280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 200400cf
> ...
> NIP fill_queue+0xf0/0x210 [virtio_console]
> LR fill_queue+0xf0/0x210 [virtio_console]
> Call Trace:
> fill_queue+0xb4/0x210 [virtio_console] (unreliable)
> add_port+0x1a8/0x470 [virtio_console]
> control_work_handler+0xbc/0x1e8 [virtio_console]
> process_one_work+0x290/0x590
> worker_thread+0x88/0x620
> kthread+0x194/0x1a0
> ret_from_kernel_thread+0x5c/0x64
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/mm: Fix set_memory_*() against concurrent accesses
https://git.kernel.org/powerpc/c/9f7853d7609d59172eecfc5e7ccf503bc1b690bd
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Do not mark xive_request_ipi() as __init
From: Michael Ellerman @ 2021-08-27 13:24 UTC (permalink / raw)
To: Nathan Chancellor, Michael Ellerman
Cc: Nick Desaulniers, linux-kernel, clang-built-linux, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20210816185711.21563-1-nathan@kernel.org>
On Mon, 16 Aug 2021 11:57:11 -0700, Nathan Chancellor wrote:
> Compiling ppc64le_defconfig with clang-14 shows a modpost warning:
>
> WARNING: modpost: vmlinux.o(.text+0xa74e0): Section mismatch in
> reference from the function xive_setup_cpu_ipi() to the function
> .init.text:xive_request_ipi()
> The function xive_setup_cpu_ipi() references
> the function __init xive_request_ipi().
> This is often because xive_setup_cpu_ipi lacks a __init
> annotation or the annotation of xive_request_ipi is wrong.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/xive: Do not mark xive_request_ipi() as __init
https://git.kernel.org/powerpc/c/3f78c90f9eb2e228f44ecc8f4377753f0e11dbab
cheers
^ permalink raw reply
* Re: [PATCH v1] powerpc/64s: Fix scv implicit soft-mask table for relocated kernels
From: Michael Ellerman @ 2021-08-27 13:25 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin; +Cc: Hari Bathini
In-Reply-To: <20210820103431.1701240-1-npiggin@gmail.com>
On Fri, 20 Aug 2021 20:34:31 +1000, Nicholas Piggin wrote:
> The implict soft-mask table addresses get relocated if they use a
> relative symbol like a label. This is right for code that runs relocated
> but not for unrelocated. The scv interrupt vectors run unrelocated, so
> absolute addresses are required for their soft-mask table entry.
>
> This fixes crashing with relocated kernels, usually an asynchronous
> interrupt hitting in the scv handler, then hitting the trap that checks
> whether r1 is in userspace.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/64s: Fix scv implicit soft-mask table for relocated kernels
https://git.kernel.org/powerpc/c/787c70f2f9990b5a197320152d2fc32cd8a6ad1a
cheers
^ permalink raw reply
* Re: [PATCH v2 0/2] Kconfig symbol fixes on powerpc
From: Michael Ellerman @ 2021-08-27 13:28 UTC (permalink / raw)
To: Michael Neuling, Anshuman Khandual, Paul Mackerras, kvm-ppc,
Michael Ellerman, Lukas Bulwahn, Benjamin Herrenschmidt,
linuxppc-dev
Cc: kernel-janitors, linux-kernel, stable
In-Reply-To: <20210819113954.17515-1-lukas.bulwahn@gmail.com>
On Thu, 19 Aug 2021 13:39:52 +0200, Lukas Bulwahn wrote:
> The script ./scripts/checkkconfigsymbols.py warns on invalid references to
> Kconfig symbols (often, minor typos, name confusions or outdated references).
>
> This patch series addresses all issues reported by
> ./scripts/checkkconfigsymbols.py in ./drivers/usb/ for Kconfig and Makefile
> files. Issues in the Kconfig and Makefile files indicate some shortcomings in
> the overall build definitions, and often are true actionable issues to address.
>
> [...]
Patch 2 applied to powerpc/fixes.
[2/2] powerpc: rectify selection to ARCH_ENABLE_SPLIT_PMD_PTLOCK
https://git.kernel.org/powerpc/c/310d2e83cb9b7f1e7232319880e3fcb57592fa10
cheers
^ permalink raw reply
* Re: [RFC PATCH] powerpc: Investigate static_call concept
From: Peter Zijlstra @ 2021-08-27 14:18 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-kernel, Steven Rostedt, Jason Baron, Paul Mackerras,
Josh Poimboeuf, linuxppc-dev, Ard Biesheuvel
In-Reply-To: <8077899fee81f08a7dffbf185569d3a1f7a2ab68.1630057495.git.christophe.leroy@csgroup.eu>
On Fri, Aug 27, 2021 at 09:45:37AM +0000, Christophe Leroy wrote:
> This RFC is to validate the concept of static_call on powerpc.
>
> Highly copied from x86.
>
> It replaces ppc_md.get_irq() which is called at every IRQ, by
> a static call.
The code looks saner, but does it actually improve performance? I'm
thinking the double branch also isn't free.
> When updating the call, we just replace the instruction at the
> trampoline address by a relative jump to the function.
>
> For the time being, the case of out-of-range functions is not handled.
The paranoid in me would've made it:
BUG_ON(patch_branch(...));
just to make sure to notice the target not fitting. Ohh, patch_branch()
doesn't return the create_branch() error, perhaps that wants to be
fixed?
Did you see the arm64 variant that deals with out-of-range functions in
their trampoline?
https://lore.kernel.org/linux-arm-kernel/20201120082103.4840-1-ardb@kernel.org/
Not exactly 'nice' but supposedly that works.
> +#define ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name) \
> + asm(".pushsection .text, \"ax\" \n" \
> + ".align 4 \n" \
> + ".globl " STATIC_CALL_TRAMP_STR(name) " \n" \
> + STATIC_CALL_TRAMP_STR(name) ": \n" \
> + " blr \n" \
> + ".type " STATIC_CALL_TRAMP_STR(name) ", @function \n" \
> + ".size " STATIC_CALL_TRAMP_STR(name) ", . - " STATIC_CALL_TRAMP_STR(name) " \n" \
> + ".popsection \n")
> +
Since you support CALL_NULL_TRAMP, your patch function below:
> +void arch_static_call_transform(void *site, void *tramp, void *func, bool tail)
> +{
> + mutex_lock(&text_mutex);
> +
> + if (tramp)
> + patch_branch(tramp, (unsigned long)func, 0);
> +
> + mutex_unlock(&text_mutex);
> +}
> +EXPORT_SYMBOL_GPL(arch_static_call_transform);
Ought to patch in "blr" when !func to be consistent :-)
I'm thinking that your core kernel text all fits in the native range and
only modules need out-of-range ?
^ permalink raw reply
* Re: [PATCH] ppc: add "-z notext" flag to disable diagnostic
From: Segher Boessenkool @ 2021-08-27 14:40 UTC (permalink / raw)
To: Fāng-ruì Sòng
Cc: Nick Desaulniers, linux-kernel, Nathan Chancellor,
clang-built-linux, Paul Mackerras, Bill Wendling, linuxppc-dev,
Daniel Axtens
In-Reply-To: <CAFP8O3LZ3ZtpkF=RdyDyyXn40oYeDkqgY6NX7YRsBWeVnmPv1A@mail.gmail.com>
Hi!
On Sat, Aug 14, 2021 at 12:34:15PM -0700, Fāng-ruì Sòng wrote:
> On Sat, Aug 14, 2021 at 5:59 AM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Fri, Aug 13, 2021 at 01:05:08PM -0700, Fangrui Song wrote:
> > > Text relocations are considered very awful by linker developers.
> >
> > By very few linker developers.
> https://groups.google.com/g/generic-abi/c/Ckq19PfLxyk/m/uW29sgkoAgAJ
> Ali Bahrami: "My opinion is that no one wants text relocations, but
> not labeling them if they do exist doesn't seem right. I find the
> presence of DF_TEXTREL very interesting when diagnosing various
> issues."
I don't know who that is, and that post has no context.
> https://gcc.gnu.org/legacy-ml/gcc/2016-04/msg00138.html
> ( "So why not simply create 'dynamic text relocations' then? Is that
> possible with a pure linker change?" )
> Cary Coutant: "Ugh. Besides being a bad idea from a performance point
> of view, it's not even always possible to do. Depending on the
> architecture, a direct reference from an executable to a variable in a
> shared library may not have the necessary reach."
That is about a very specific kind of relocation.
> binutils-gdb commit "Add linker option: --warn-shared-textrel to
> produce warnings when adding a DT_TEXTREL to a shared object."
> Nick Clifton
That does not say text relocations are bad. Of course you want to know
if they are there, for various reasons, like, if they are disallowed on
some systems.
> https://www.openwall.com/lists/musl/2020/09/26/3
> Szabolcs Nagy: "nice. and gcc passes -z text for static pie code so
> that case should not end up with text rels."
That does not say text relocations are bad.
> Someone wrote "Overall, the overhead of processing text relocations
> can cause serious performance degradation." in Solaris' Linker and
> Libraries Guide.
In process startup, sure. And it can make those processes run faster
as well. That is the tradeoff with *all* relocations; you can make any
code without any relocations. Relocations are a tradeoff, like most
things.
> > How would this be a benefit to security?
>
> https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
This means that those "hardening techniques" have some serious
weaknesses, that is all. And hardening is not part of security
anyway; it is impact mitigation.
> FWIW I contributed a glibc patch allowing TEXTREL to co-exist with ifunc.
> It requires temporary mapping the text segment W^X.
What does W^X mean here? It normally means no mapping is both writable
and executable at the same time.
> > > There are no text relocations, therefore no need for -z notext.
> >
> > This is a choice by the compiler, nothing more. It saves some process
> > startup time, and allows slightly more maps to be shared by processes
> > that run the same images. But it is a tradeoff, so it might change; and
> > of course it is not an ABI requirement.
> Text relocations are generally awful.
Great arguments, thanks! :-P
> GNU ld and gold's traditional "add DF_TEXTREL on-demand" behavior made
> such user errors easy to make.
That has no bearing on if text relocations are useful or not.
> I understand that kernels are special applications where we apply
> relocations once and many user-space objection can be less of a
> concern/ignored.
> However, the Linux kernel is already in a position where many linker
> options are controlled and thus should specify -z notext to make
> the intention explicit, or fix the problems (I think x86-64 is good;
> that said, powerpc
> has a higher cost using PC-relative instructions so pay the oneshot relocation
> time cost probably isn't a bad choice)
I have no idea what you mean.
Segher
^ permalink raw reply
* Re: [PATCH v4 6/6] sched/fair: Consider SMT in ASYM_PACKING load balance
From: Peter Zijlstra @ 2021-08-27 14:48 UTC (permalink / raw)
To: Vincent Guittot
Cc: Juri Lelli, Aubrey Li, Srikar Dronamraju, Ravi V. Shankar,
Ricardo Neri, Ben Segall, Srinivas Pandruvada,
Joel Fernandes (Google), Ingo Molnar, Rafael J. Wysocki,
Steven Rostedt, Mel Gorman, Len Brown, Ricardo Neri,
Nicholas Piggin, Aubrey Li, Dietmar Eggemann, Tim Chen,
Quentin Perret, linuxppc-dev, linux-kernel,
Daniel Bristot de Oliveira
In-Reply-To: <CAKfTPtArtmhLG5QYR6TzKevDrEuiQu2HJxm_C3pe549XdGU-1g@mail.gmail.com>
On Fri, Aug 27, 2021 at 12:13:42PM +0200, Vincent Guittot wrote:
> > +/**
> > + * asym_smt_can_pull_tasks - Check whether the load balancing CPU can pull tasks
> > + * @dst_cpu: Destination CPU of the load balancing
> > + * @sds: Load-balancing data with statistics of the local group
> > + * @sgs: Load-balancing statistics of the candidate busiest group
> > + * @sg: The candidate busiet group
> > + *
> > + * Check the state of the SMT siblings of both @sds::local and @sg and decide
> > + * if @dst_cpu can pull tasks. If @dst_cpu does not have SMT siblings, it can
> > + * pull tasks if two or more of the SMT siblings of @sg are busy. If only one
> > + * CPU in @sg is busy, pull tasks only if @dst_cpu has higher priority.
> > + *
> > + * If both @dst_cpu and @sg have SMT siblings, even the number of idle CPUs
> > + * between @sds::local and @sg. Thus, pull tasks from @sg if the difference
> > + * between the number of busy CPUs is 2 or more. If the difference is of 1,
> > + * only pull if @dst_cpu has higher priority. If @sg does not have SMT siblings
> > + * only pull tasks if all of the SMT siblings of @dst_cpu are idle and @sg
> > + * has lower priority.
> > + */
> > +static bool asym_smt_can_pull_tasks(int dst_cpu, struct sd_lb_stats *sds,
> > + struct sg_lb_stats *sgs,
> > + struct sched_group *sg)
> > +{
> > +#ifdef CONFIG_SCHED_SMT
> > + bool local_is_smt, sg_is_smt;
> > + int sg_busy_cpus;
> > +
> > + local_is_smt = sds->local->flags & SD_SHARE_CPUCAPACITY;
> > + sg_is_smt = sg->flags & SD_SHARE_CPUCAPACITY;
> > +
> > + sg_busy_cpus = sgs->group_weight - sgs->idle_cpus;
> > +
> > + if (!local_is_smt) {
> > + /*
> > + * If we are here, @dst_cpu is idle and does not have SMT
> > + * siblings. Pull tasks if candidate group has two or more
> > + * busy CPUs.
> > + */
> > + if (sg_is_smt && sg_busy_cpus >= 2)
> > + return true;
> > +
> > + /*
> > + * @dst_cpu does not have SMT siblings. @sg may have SMT
> > + * siblings and only one is busy. In such case, @dst_cpu
> > + * can help if it has higher priority and is idle.
> > + */
> > + return !sds->local_stat.group_util &&
>
> sds->local_stat.group_util can't be used to decide if a CPU or group
> of CPUs is idle. util_avg is usually not null when a CPU becomes idle
> and you can have to wait more than 300ms before it becomes Null
> At the opposite, the utilization of a CPU can be null but a task with
> null utilization has just woken up on it.
> Utilization is used to reflect the average work of the CPU or group of
> CPUs but not the current state
If you want immediate idle, sgs->nr_running == 0 or sgs->idle_cpus ==
sgs->group_weight come to mind.
> > + sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu);
> > + }
> > +
> > + /* @dst_cpu has SMT siblings. */
> > +
> > + if (sg_is_smt) {
> > + int local_busy_cpus = sds->local->group_weight -
> > + sds->local_stat.idle_cpus;
> > + int busy_cpus_delta = sg_busy_cpus - local_busy_cpus;
> > +
> > + /* Local can always help to even the number busy CPUs. */
>
> default behavior of the load balance already tries to even the number
> of idle CPUs.
Right, but I suppose this is because we're trapped here and have to deal
with the SMT-SMT case too. Ricardo, can you clarify?
> > + if (busy_cpus_delta >= 2)
> > + return true;
> > +
> > + if (busy_cpus_delta == 1)
> > + return sched_asym_prefer(dst_cpu,
> > + sg->asym_prefer_cpu);
> > +
> > + return false;
> > + }
> > +
> > + /*
> > + * @sg does not have SMT siblings. Ensure that @sds::local does not end
> > + * up with more than one busy SMT sibling and only pull tasks if there
> > + * are not busy CPUs. As CPUs move in and out of idle state frequently,
> > + * also check the group utilization to smoother the decision.
> > + */
> > + if (!sds->local_stat.group_util)
>
> same comment as above about the meaning of group_util == 0
>
> > + return sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu);
> > +
> > + return false;
> > +#else
> > + /* Always return false so that callers deal with non-SMT cases. */
> > + return false;
> > +#endif
> > +}
> > +
> > static inline bool
> > sched_asym(struct lb_env *env, struct sd_lb_stats *sds, struct sg_lb_stats *sgs,
> > struct sched_group *group)
> > {
> > + /* Only do SMT checks if either local or candidate have SMT siblings */
> > + if ((sds->local->flags & SD_SHARE_CPUCAPACITY) ||
> > + (group->flags & SD_SHARE_CPUCAPACITY))
> > + return asym_smt_can_pull_tasks(env->dst_cpu, sds, sgs, group);
> > +
> > return sched_asym_prefer(env->dst_cpu, group->asym_prefer_cpu);
> > }
^ permalink raw reply
* Re: [PATCH v4 6/6] sched/fair: Consider SMT in ASYM_PACKING load balance
From: Vincent Guittot @ 2021-08-27 15:17 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Juri Lelli, Aubrey Li, Srikar Dronamraju, Ravi V. Shankar,
Ricardo Neri, Ben Segall, Srinivas Pandruvada,
Joel Fernandes (Google), Ingo Molnar, Rafael J. Wysocki,
Steven Rostedt, Mel Gorman, Len Brown, Ricardo Neri,
Nicholas Piggin, Aubrey Li, Dietmar Eggemann, Tim Chen,
Quentin Perret, linuxppc-dev, linux-kernel,
Daniel Bristot de Oliveira
In-Reply-To: <YSj7PrVGVpcKf/vz@hirez.programming.kicks-ass.net>
On Fri, 27 Aug 2021 at 16:50, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Aug 27, 2021 at 12:13:42PM +0200, Vincent Guittot wrote:
> > > +/**
> > > + * asym_smt_can_pull_tasks - Check whether the load balancing CPU can pull tasks
> > > + * @dst_cpu: Destination CPU of the load balancing
> > > + * @sds: Load-balancing data with statistics of the local group
> > > + * @sgs: Load-balancing statistics of the candidate busiest group
> > > + * @sg: The candidate busiet group
> > > + *
> > > + * Check the state of the SMT siblings of both @sds::local and @sg and decide
> > > + * if @dst_cpu can pull tasks. If @dst_cpu does not have SMT siblings, it can
> > > + * pull tasks if two or more of the SMT siblings of @sg are busy. If only one
> > > + * CPU in @sg is busy, pull tasks only if @dst_cpu has higher priority.
> > > + *
> > > + * If both @dst_cpu and @sg have SMT siblings, even the number of idle CPUs
> > > + * between @sds::local and @sg. Thus, pull tasks from @sg if the difference
> > > + * between the number of busy CPUs is 2 or more. If the difference is of 1,
> > > + * only pull if @dst_cpu has higher priority. If @sg does not have SMT siblings
> > > + * only pull tasks if all of the SMT siblings of @dst_cpu are idle and @sg
> > > + * has lower priority.
> > > + */
> > > +static bool asym_smt_can_pull_tasks(int dst_cpu, struct sd_lb_stats *sds,
> > > + struct sg_lb_stats *sgs,
> > > + struct sched_group *sg)
> > > +{
> > > +#ifdef CONFIG_SCHED_SMT
> > > + bool local_is_smt, sg_is_smt;
> > > + int sg_busy_cpus;
> > > +
> > > + local_is_smt = sds->local->flags & SD_SHARE_CPUCAPACITY;
> > > + sg_is_smt = sg->flags & SD_SHARE_CPUCAPACITY;
> > > +
> > > + sg_busy_cpus = sgs->group_weight - sgs->idle_cpus;
> > > +
> > > + if (!local_is_smt) {
> > > + /*
> > > + * If we are here, @dst_cpu is idle and does not have SMT
> > > + * siblings. Pull tasks if candidate group has two or more
> > > + * busy CPUs.
> > > + */
> > > + if (sg_is_smt && sg_busy_cpus >= 2)
> > > + return true;
> > > +
> > > + /*
> > > + * @dst_cpu does not have SMT siblings. @sg may have SMT
> > > + * siblings and only one is busy. In such case, @dst_cpu
> > > + * can help if it has higher priority and is idle.
> > > + */
> > > + return !sds->local_stat.group_util &&
> >
> > sds->local_stat.group_util can't be used to decide if a CPU or group
> > of CPUs is idle. util_avg is usually not null when a CPU becomes idle
> > and you can have to wait more than 300ms before it becomes Null
> > At the opposite, the utilization of a CPU can be null but a task with
> > null utilization has just woken up on it.
> > Utilization is used to reflect the average work of the CPU or group of
> > CPUs but not the current state
>
> If you want immediate idle, sgs->nr_running == 0 or sgs->idle_cpus ==
> sgs->group_weight come to mind.
yes, I have the same in mind
>
> > > + sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu);
> > > + }
> > > +
> > > + /* @dst_cpu has SMT siblings. */
> > > +
> > > + if (sg_is_smt) {
> > > + int local_busy_cpus = sds->local->group_weight -
> > > + sds->local_stat.idle_cpus;
> > > + int busy_cpus_delta = sg_busy_cpus - local_busy_cpus;
> > > +
> > > + /* Local can always help to even the number busy CPUs. */
> >
> > default behavior of the load balance already tries to even the number
a> > of idle CPUs.
>
> Right, but I suppose this is because we're trapped here and have to deal
> with the SMT-SMT case too. Ricardo, can you clarify?
IIUC, this function is used in sg_lb_stats to set
sgs->group_asym_packing which is then used to set the group state to
group_asym_packing and force asym migration.
But if we only want to even the number of busy CPUs between the group,
we should not need to set the group state to group_asym_packing
>
> > > + if (busy_cpus_delta >= 2)
> > > + return true;
> > > +
> > > + if (busy_cpus_delta == 1)
> > > + return sched_asym_prefer(dst_cpu,
> > > + sg->asym_prefer_cpu);
> > > +
> > > + return false;
> > > + }
> > > +
> > > + /*
> > > + * @sg does not have SMT siblings. Ensure that @sds::local does not end
> > > + * up with more than one busy SMT sibling and only pull tasks if there
> > > + * are not busy CPUs. As CPUs move in and out of idle state frequently,
> > > + * also check the group utilization to smoother the decision.
> > > + */
> > > + if (!sds->local_stat.group_util)
> >
> > same comment as above about the meaning of group_util == 0
> >
> > > + return sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu);
> > > +
> > > + return false;
> > > +#else
> > > + /* Always return false so that callers deal with non-SMT cases. */
> > > + return false;
> > > +#endif
> > > +}
> > > +
> > > static inline bool
> > > sched_asym(struct lb_env *env, struct sd_lb_stats *sds, struct sg_lb_stats *sgs,
> > > struct sched_group *group)
> > > {
> > > + /* Only do SMT checks if either local or candidate have SMT siblings */
> > > + if ((sds->local->flags & SD_SHARE_CPUCAPACITY) ||
> > > + (group->flags & SD_SHARE_CPUCAPACITY))
> > > + return asym_smt_can_pull_tasks(env->dst_cpu, sds, sgs, group);
> > > +
> > > return sched_asym_prefer(env->dst_cpu, group->asym_prefer_cpu);
> > > }
^ permalink raw reply
* Re: [RFC PATCH] powerpc: Investigate static_call concept
From: Segher Boessenkool @ 2021-08-27 16:04 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Steven Rostedt, Jason Baron, Paul Mackerras,
Josh Poimboeuf, linuxppc-dev, Ard Biesheuvel
In-Reply-To: <YSj0R6g6HeboSk9n@hirez.programming.kicks-ass.net>
On Fri, Aug 27, 2021 at 04:18:47PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 27, 2021 at 09:45:37AM +0000, Christophe Leroy wrote:
> > This RFC is to validate the concept of static_call on powerpc.
> >
> > Highly copied from x86.
> >
> > It replaces ppc_md.get_irq() which is called at every IRQ, by
> > a static call.
>
> The code looks saner, but does it actually improve performance? I'm
> thinking the double branch also isn't free.
It isn't, but it is very cheap, while the branch-to-count is not, even
*if* it is correctly predicted.
> The paranoid in me would've made it:
>
> BUG_ON(patch_branch(...));
>
> just to make sure to notice the target not fitting. Ohh, patch_branch()
> doesn't return the create_branch() error, perhaps that wants to be
> fixed?
Should that be allowed to fail ever? I.e., should a failure be a fatal
error? Sounds very fragile otherwise.
Segher
^ permalink raw reply
* [RFC PATCH 0/6] powerpc: Make hash MMU code build configurable
From: Nicholas Piggin @ 2021-08-27 16:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
Now that there's a platform that can make good use of it, here's
a series that can prevent the hash MMU code being built for 64s
platforms that don't need it.
Thanks,
Nick
Nicholas Piggin (6):
powerpc: Remove unused FW_FEATURE_NATIVE references
powerpc: Rename PPC_NATIVE to PPC_HASH_MMU_NATIVE
powerpc/pseries: Stop selecting PPC_HASH_MMU_NATIVE
powerpc/64s: Make hash MMU code build configurable
powerpc/microwatt: select POWER9_CPU
powerpc/microwatt: Stop building the hash MMU code
arch/powerpc/Kconfig | 1 +
arch/powerpc/configs/microwatt_defconfig | 2 +-
arch/powerpc/include/asm/book3s/64/mmu.h | 22 +++-
.../include/asm/book3s/64/tlbflush-hash.h | 7 ++
arch/powerpc/include/asm/book3s/64/tlbflush.h | 4 -
arch/powerpc/include/asm/book3s/pgtable.h | 4 +
arch/powerpc/include/asm/firmware.h | 8 --
arch/powerpc/include/asm/mmu.h | 38 +++++-
arch/powerpc/include/asm/mmu_context.h | 2 +
arch/powerpc/include/asm/paca.h | 8 ++
arch/powerpc/kernel/asm-offsets.c | 2 +
arch/powerpc/kernel/dt_cpu_ftrs.c | 10 +-
arch/powerpc/kernel/entry_64.S | 4 +-
arch/powerpc/kernel/exceptions-64s.S | 16 +++
arch/powerpc/kernel/mce.c | 2 +-
arch/powerpc/kernel/mce_power.c | 10 +-
arch/powerpc/kernel/paca.c | 18 ++-
arch/powerpc/kernel/process.c | 13 +-
arch/powerpc/kernel/prom.c | 2 +
arch/powerpc/kernel/setup_64.c | 4 +
arch/powerpc/kexec/core_64.c | 4 +-
arch/powerpc/kexec/ranges.c | 4 +
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/mm/book3s64/Makefile | 19 +--
arch/powerpc/mm/book3s64/hash_native.c | 104 ----------------
arch/powerpc/mm/book3s64/hash_pgtable.c | 1 -
arch/powerpc/mm/book3s64/hash_utils.c | 116 ++++++++++++++++--
.../{hash_hugetlbpage.c => hugetlbpage.c} | 6 +
arch/powerpc/mm/book3s64/mmu_context.c | 16 +++
arch/powerpc/mm/book3s64/pgtable.c | 22 +++-
arch/powerpc/mm/book3s64/radix_pgtable.c | 4 +
arch/powerpc/mm/book3s64/slb.c | 16 ---
arch/powerpc/mm/copro_fault.c | 2 +
arch/powerpc/mm/fault.c | 17 +++
arch/powerpc/mm/pgtable.c | 10 +-
arch/powerpc/platforms/52xx/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig | 4 +-
arch/powerpc/platforms/Kconfig.cputype | 21 +++-
arch/powerpc/platforms/cell/Kconfig | 3 +-
arch/powerpc/platforms/chrp/Kconfig | 2 +-
arch/powerpc/platforms/embedded6xx/Kconfig | 2 +-
arch/powerpc/platforms/maple/Kconfig | 3 +-
arch/powerpc/platforms/microwatt/Kconfig | 2 +-
arch/powerpc/platforms/pasemi/Kconfig | 3 +-
arch/powerpc/platforms/powermac/Kconfig | 3 +-
arch/powerpc/platforms/powernv/Kconfig | 2 +-
arch/powerpc/platforms/powernv/idle.c | 2 +
arch/powerpc/platforms/powernv/setup.c | 2 +
arch/powerpc/platforms/pseries/Kconfig | 1 -
arch/powerpc/platforms/pseries/lpar.c | 68 +++++-----
arch/powerpc/platforms/pseries/lparcfg.c | 2 +-
arch/powerpc/platforms/pseries/mobility.c | 6 +
arch/powerpc/platforms/pseries/ras.c | 4 +
arch/powerpc/platforms/pseries/reconfig.c | 2 +
arch/powerpc/platforms/pseries/setup.c | 6 +-
arch/powerpc/xmon/xmon.c | 8 +-
56 files changed, 427 insertions(+), 240 deletions(-)
rename arch/powerpc/mm/book3s64/{hash_hugetlbpage.c => hugetlbpage.c} (95%)
--
2.23.0
^ permalink raw reply
* [RFC PATCH 1/6] powerpc: Remove unused FW_FEATURE_NATIVE references
From: Nicholas Piggin @ 2021-08-27 16:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210827163410.1177154-1-npiggin@gmail.com>
FW_FEATURE_NATIVE_ALWAYS and FW_FEATURE_NATIVE_POSSIBLE are always
zero and never do anything. Remove them.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/firmware.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
index 7604673787d6..df9e4aae917e 100644
--- a/arch/powerpc/include/asm/firmware.h
+++ b/arch/powerpc/include/asm/firmware.h
@@ -79,8 +79,6 @@ enum {
FW_FEATURE_POWERNV_ALWAYS = 0,
FW_FEATURE_PS3_POSSIBLE = FW_FEATURE_LPAR | FW_FEATURE_PS3_LV1,
FW_FEATURE_PS3_ALWAYS = FW_FEATURE_LPAR | FW_FEATURE_PS3_LV1,
- FW_FEATURE_NATIVE_POSSIBLE = 0,
- FW_FEATURE_NATIVE_ALWAYS = 0,
FW_FEATURE_POSSIBLE =
#ifdef CONFIG_PPC_PSERIES
FW_FEATURE_PSERIES_POSSIBLE |
@@ -90,9 +88,6 @@ enum {
#endif
#ifdef CONFIG_PPC_PS3
FW_FEATURE_PS3_POSSIBLE |
-#endif
-#ifdef CONFIG_PPC_NATIVE
- FW_FEATURE_NATIVE_ALWAYS |
#endif
0,
FW_FEATURE_ALWAYS =
@@ -104,9 +99,6 @@ enum {
#endif
#ifdef CONFIG_PPC_PS3
FW_FEATURE_PS3_ALWAYS &
-#endif
-#ifdef CONFIG_PPC_NATIVE
- FW_FEATURE_NATIVE_ALWAYS &
#endif
FW_FEATURE_POSSIBLE,
--
2.23.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox