[PATCH] objtool: continue if find_insn() fails in decode_instructions()
Currently, decode_instructions() is failing if it is not able to find
instruction, and this is happening since commit dbcdbdfdf137b4
("objtool: Rework instruction -> symbol mapping") because it is
expecting instruction for STT_NOTYPE symbols.
Due to this, the following objtool warnings are seen:
[1] arch/powerpc/kernel/optprobes_head.o: warning: objtool:
optprobe_template_end(): can't find starting instruction
[2] arch/powerpc/kernel/kvm_emul.o: warning: objtool: kvm_template_end():
can't find starting instruction
[3] arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): can't
find starting instruction
The warnings are thrown because find_insn() is failing for symbols that
are at the end of the file, or at the end of the section. Given how
STT_NOTYPE symbols are currently handled in decode_instructions(),
continue if the instruction is not found, instead of throwing warning
and returning.
Signed-off-by: Naveen N. Rao
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/check.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 4350be739f4f..bce2be5ebf36 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -430,11 +430,8 @@ static int decode_instructions(struct objtool_file *file)
if (func->return_thunk || func->alias != func)
continue;
- if (!find_insn(file, sec, func->offset)) {
- WARN("%s(): can't find starting instruction",
-func->name);
- return -1;
- }
+ if (!find_insn(file, sec, func->offset))
+ continue;
sym_for_each_insn(file, func, insn) {
insn->sym = func;
--
2.31.1
Re: [PATCH] perf test: Update event group check for support of uncore event
On 07-Dec-22 10:28 PM, Athira Rajeev wrote:
> Event group test checks group creation for combinations of
> hw, sw and uncore PMU events. Some of the uncore pmus may
> require additional permission to access the counters.
> For example, in case of hv_24x7, partition need to have
> permissions to access hv_24x7 pmu counters. If not, event_open
> will fail. Hence add a sanity check to see if event_open
> succeeds before proceeding with the test.
>
> Fixes: b20d9215a35f ("perf test: Add event group test for events in multiple
> PMUs")
> Signed-off-by: Athira Rajeev
Acked-by: Ravi Bangoria
Thanks,
Ravi
[PATCH] powerpc/pseries: fix potential memory leak in init_cpu_associativity()
If the vcpu_associativity alloc memory successfully but the
pcpu_associativity fails to alloc memory, the vcpu_associativity
memory leaks.
Fixes: d62c8deeb6e6 ("powerpc/pseries: Provide vcpu dispatch statistics")
Signed-off-by: Wang Yufen
---
arch/powerpc/platforms/pseries/lpar.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 97ef649..501ee6c 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -211,6 +211,7 @@ static int init_cpu_associativity(void)
if (!vcpu_associativity || !pcpu_associativity) {
pr_err("error allocating memory for associativity
information\n");
+ kfree(vcpu_associativity);
return -ENOMEM;
}
--
1.8.3.1
Re: [PATCH] ASoC: imx-audmux: use sysfs_emit() to instead of scnprintf()
On Mon, 05 Dec 2022 19:43:47 +0800, ye.xingc...@zte.com.cn wrote: > Follow the advice of the Documentation/filesystems/sysfs.rst and show() > should only use sysfs_emit() or sysfs_emit_at() when formatting the > value to be returned to user space. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-audmux: use sysfs_emit() to instead of scnprintf() commit: a39bc7cf8e284653fb6fd9d897f269f4ac80cf52 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
[PATCH] perf test: Update event group check for support of uncore event
Event group test checks group creation for combinations of
hw, sw and uncore PMU events. Some of the uncore pmus may
require additional permission to access the counters.
For example, in case of hv_24x7, partition need to have
permissions to access hv_24x7 pmu counters. If not, event_open
will fail. Hence add a sanity check to see if event_open
succeeds before proceeding with the test.
Fixes: b20d9215a35f ("perf test: Add event group test for events in multiple
PMUs")
Signed-off-by: Athira Rajeev
---
Note: The patch is based on tmp.perf/core branch
of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tools/perf/tests/event_groups.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/event_groups.c b/tools/perf/tests/event_groups.c
index 612c0444aaa8..029442b4e9c6 100644
--- a/tools/perf/tests/event_groups.c
+++ b/tools/perf/tests/event_groups.c
@@ -51,7 +51,7 @@ static int event_open(int type, unsigned long config, int
group_fd)
static int setup_uncore_event(void)
{
struct perf_pmu *pmu;
- int i;
+ int i, fd;
if (list_empty())
perf_pmu__scan(NULL);
@@ -62,6 +62,18 @@ static int setup_uncore_event(void)
pr_debug("Using %s for uncore pmu event\n",
pmu->name);
types[2] = pmu->type;
configs[2] = uncore_pmus[i].config;
+ /*
+* Check if the chosen uncore pmu event can be
+* used in the test. For example, incase of
accessing
+* hv_24x7 pmu counters, partition should have
+* additional permissions. If not, event open
will
+* fail. So check if the event open succeeds
+* before proceeding.
+*/
+ fd = event_open(types[2], configs[2], -1);
+ if (fd < 0)
+ return -1;
+ close(fd);
return 0;
}
}
--
2.31.1
[linux-next:master] BUILD REGRESSION 591cd61541b9b95401e17dca24be486e32104cb8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 591cd61541b9b95401e17dca24be486e32104cb8 Add linux-next specific files for 20221207 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202211090634.ryfkk0ws-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211242120.mzzvguln-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211282102.qur7hhrw-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211301634.cejlltjp-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211301840.y7rrob13-...@intel.com https://lore.kernel.org/oe-kbuild-all/202212070208.3fsky80h-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/loongarch/kernel/asm-offsets.c:265:6: warning: no previous prototype for 'output_pbe_defines' [-Wmissing-prototypes] arch/loongarch/power/hibernate.c:14:6: warning: no previous prototype for 'save_processor_state' [-Wmissing-prototypes] arch/loongarch/power/hibernate.c:26:6: warning: no previous prototype for 'restore_processor_state' [-Wmissing-prototypes] arch/loongarch/power/hibernate.c:38:5: warning: no previous prototype for 'pfn_is_nosave' [-Wmissing-prototypes] arch/loongarch/power/hibernate.c:48:5: warning: no previous prototype for 'swsusp_arch_suspend' [-Wmissing-prototypes] arch/loongarch/power/hibernate.c:56:5: warning: no previous prototype for 'swsusp_arch_resume' [-Wmissing-prototypes] arch/powerpc/kernel/kvm_emul.o: warning: objtool: kvm_template_end(): can't find starting instruction arch/powerpc/kernel/optprobes_head.o: warning: objtool: optprobe_template_end(): can't find starting instruction arch/powerpc/lib/qspinlock.c:304:2: error: call to undeclared function 'spin_end'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] arch/powerpc/lib/qspinlock.c:324:3: error: call to undeclared function 'spin_begin'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] arch/powerpc/lib/qspinlock.c:331:2: error: call to undeclared function 'spin_cpu_relax'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: warning: no previous prototype for 'to_dal_irq_source_dcn201' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for function 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for function 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for function 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for function 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable 'loc' set but not used [-Wunused-but-set-variable] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1474:38: warning: unused variable 'mt8173_jpeg_drvdata' [-Wunused-const-variable] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1489:38: warning: unused variable 'mtk_jpeg_drvdata' [-Wunused-const-variable] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1859:38: warning: unused variable 'mtk8195_jpegdec_drvdata' [-Wunused-const-variable] drivers/regulator/tps65219-regulator.c:310:60: warning: parameter 'dev' set but not used [-Wunused-but-set-parameter] drivers/regulator/tps65219-regulator.c:370:26: warning: ordered comparison of pointer with integer zero [-Wextra] include/linux/signal.h:113:11: error: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Werror,-Warray-bounds] include/linux/signal.h:97:11: error: array index 3 is past the end of the array (that has type 'unsigned long[2]') [-Werror,-Warray-bounds] vmlinux.o: warning: objtool: __btrfs_map_block+0x1d77: unreachable instruction Unverified Error/Warning (likely false positive, please contact us if interested): drivers/net/ipa/ipa_table.c:425 ipa_table_init_add() error: we previously assumed 'hash_mem' could be null (see line 416) Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-irq-dcn201-irq_service_dcn201
Re: [PATCH] powerpc/ftrace: fix syscall tracing on PPC64_ELF_ABI_V1
Le 07/12/2022 à 16:18, Mathieu Desnoyers a écrit : > On 2022-12-06 21:09, Michael Ellerman wrote: >> Mathieu Desnoyers writes: >>> On 2022-12-05 17:50, Michael Ellerman wrote: >>> IMHO the second option would be better because it does not increase the >>> kernel image size as much as KALLSYMS_ALL. >> >> Yes I agree. >> >> Even if that did break something, any breakage would be limited to >> arches which uses function descriptors, which are now all rare. > > Yes, it would only impact those arches using function descriptors, which > are broken today with respect to system call tracing. Are you aware of > other architectures other than PPC64 ELF ABI v1 supported by the Linux > kernel that use function descriptors ? $ git grep "select HAVE_FUNCTION_DESCRIPTORS" arch/ arch/ia64/Kconfig: select HAVE_FUNCTION_DESCRIPTORS arch/parisc/Kconfig:select HAVE_FUNCTION_DESCRIPTORS if 64BIT arch/powerpc/Kconfig: select HAVE_FUNCTION_DESCRIPTORSif PPC64_ELF_ABI_V1 Christophe
Re: [PATCH] powerpc/ftrace: fix syscall tracing on PPC64_ELF_ABI_V1
Hello, On Wed, Dec 07, 2022 at 10:18:13AM -0500, Mathieu Desnoyers wrote: > On 2022-12-06 21:09, Michael Ellerman wrote: > > Mathieu Desnoyers writes: > > > On 2022-12-05 17:50, Michael Ellerman wrote: > > > > Relatedly we have a patch in next to optionally use ABIv2 for 64-bit big > > endian builds. > > Interesting. Does it require a matching user-space ? (built with PPC64 ABIv2 No, the kernel and userspace ABI is separate. > ?) Does it handle legacy PPC32 executables ? Theoretically it should. No idea if anybody has tested it. Thanks Michal
Re: [PATCH] powerpc/ftrace: fix syscall tracing on PPC64_ELF_ABI_V1
On 2022-12-06 21:09, Michael Ellerman wrote: Mathieu Desnoyers writes: On 2022-12-05 17:50, Michael Ellerman wrote: Michael Jeanson writes: On 2022-12-05 15:11, Michael Jeanson wrote: Michael Jeanson writes: In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on PPC64_ELF_ABI_V1 this resulted in the symbols in the syscall table changing from their dot prefixed variant to the non-prefixed ones. Since ftrace prefixes a dot to the syscall names when matching them to build its syscall event list, this resulted in no syscall events being available. Remove the PPC64_ELF_ABI_V1 specific version of arch_syscall_match_sym_name to have the same behavior across all powerpc variants. This doesn't seem to work for me. Event with it applied I still don't see anything in /sys/kernel/debug/tracing/events/syscalls Did we break it in some other way recently? cheers I did some further testing, my config also enabled KALLSYMS_ALL, when I remove it there is indeed no syscall events. Aha, OK that explains it I guess. I was using ppc64_guest_defconfig which has ABI_V1 and FTRACE_SYSCALLS, but does not have KALLSYMS_ALL. So I guess there's some other bug lurking in there. I don't have the setup handy to validate it, but I suspect it is caused by the way scripts/kallsyms.c:symbol_valid() checks whether a symbol entry needs to be integrated into the assembler output when --all-symbols is not specified. It only keeps symbols which addresses are in the text range. On PPC64_ELF_ABI_V1, this means only the dot-prefixed symbols will be kept (those point to the function begin), leaving out the non-dot-prefixed symbols (those point to the function descriptors). OK. So I guess it never worked without KALLSYMS_ALL. I suspect it worked prior to kernel v5.7, because back then the PPC64 ABIv1 system call table contained pointers to the text section (beginning of functions) rather than function descriptors. So changing this system call table to point to C functions introduced the dot-prefix match issue for syscall tracing as well as a dependency on KALLSYMS_ALL. It seems like most distros enable KALLSYMS_ALL, so I guess that's why we've never noticed. Or very few people run recent PPC64 ABIv1 kernels :) So I see two possible solutions there: either we ensure that FTRACE_SYSCALLS selects KALLSYMS_ALL on PPC64_ELF_ABI_V1, or we modify scripts/kallsyms.c:symbol_valid() to also include function descriptor symbols. This would mean accepting symbols pointing into the .opd ELF section. My only worry is that will cause some other breakage, because .opd symbols are not really "text" in the normal sense, ie. you can't execute them directly. AFAIU adding the .opd section to scripts/kallsyms.c text_ranges will only affect the result of symbol_valid(), which decides which symbols get pulled into a KALLSYMS=n/KALLSYMS_ALL=n kernel build. Considering that a KALLSYMS_ALL=y build pulls those function descriptor symbols into the image without breaking anything, I don't see why adding the .opd section to this script text_ranges would have any ill side-effect. On the other hand the help for KALLSYMS_ALL says: "Normally kallsyms only contains the symbols of functions" But without .opd included that's not really true. In practice it probably doesn't really matter, because eg. backtraces will point to dot symbols which can be resolved. Indeed, I don't see this affecting backtraces, but as soon as a lookup depends on comparing the C function pointer to a function descriptor, the .opd symbols are needed. Not having those function descriptor symbols in KALLSYMS_ALL=n builds seems rather error-prone. IMHO the second option would be better because it does not increase the kernel image size as much as KALLSYMS_ALL. Yes I agree. Even if that did break something, any breakage would be limited to arches which uses function descriptors, which are now all rare. Yes, it would only impact those arches using function descriptors, which are broken today with respect to system call tracing. Are you aware of other architectures other than PPC64 ELF ABI v1 supported by the Linux kernel that use function descriptors ? Relatedly we have a patch in next to optionally use ABIv2 for 64-bit big endian builds. Interesting. Does it require a matching user-space ? (built with PPC64 ABIv2 ?) Does it handle legacy PPC32 executables ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
Re: [PATCH 0/7] powerpc/85xx: p2020: Create one unified machine description
Le 04/12/2022 à 11:54, Pali Rohár a écrit :
> On Friday 19 August 2022 21:15:50 Pali Rohár wrote:
>> This patch series unifies all P2020 boards and machine descriptions into
>> one generic unified P2020 machine description. With this generic machine
>> description, kernel can boot on any P2020-based board with correct DTS
>> file.
>>
>> Tested on CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
>> Kernel during booting correctly detects P2020 and prints:
>> [0.00] Using Freescale P2020 machine description
>>
>> Pali Rohár (7):
>>powerpc/85xx: Mark mpc85xx_rdb_pic_init() as static
>>powerpc/85xx: Mark mpc85xx_ds_pic_init() as static
>>powerpc/85xx: p2020: Move all P2020 machine descriptions to p2020.c
>>powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks
>>powerpc/85xx: p2020: Define just one machine description
>>powerpc/85xx: p2020: Enable boards by new config option CONFIG_P2020
>>powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string
>
> Christophe, could you please summarize for me what is needed to change /
> fix / adjust in this patch series? We had discussion about all patches
> in this thread but I have not received reply for every my reaction. And
> I'm not sure what to do and what not. So I can prepare a V2 version.
I've been through all comments and answers once more. If I don't reply
to your explanation, it means I agree with it.
So I think you can proceed now with v2.
>
>> arch/powerpc/boot/dts/turris1x.dts| 2 +-
>> arch/powerpc/platforms/85xx/Kconfig | 22 ++-
>> arch/powerpc/platforms/85xx/Makefile | 1 +
>> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 25 +--
>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 46 +-
>> .../platforms/85xx/{mpc85xx_ds.c => p2020.c} | 144 +++---
>> 6 files changed, 75 insertions(+), 165 deletions(-)
>> copy arch/powerpc/platforms/85xx/{mpc85xx_ds.c => p2020.c} (53%)
>>
>> --
>> 2.20.1
>>
Re: [PATCH 3/7] powerpc/85xx: p2020: Move all P2020 machine descriptions to p2020.c
Le 26/09/2022 à 12:26, Pali Rohár a écrit :
> On Monday 26 September 2022 10:17:26 Christophe Leroy wrote:
>> Le 26/09/2022 à 11:53, Pali Rohár a écrit :
>>> On Monday 26 September 2022 09:48:02 Christophe Leroy wrote:
Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> This moves machine descriptions and all related code for all P2020 boards
> into new p2020.c source file. This is preparation for code deduplication
> and providing one unified machine description for all P2020 boards.
I'm having hard time to review this patch.
It looks like you are doing much more than just moving machine
descriptions and related code into p2020.c
Apparently p2020.c has a lot of code that doesn't seem be move from
somewhere else.
Maybe there is a need to tidy up in order to ease reviewing.
>>>
>>> This is probably harder to read due to how git format-patch generated
>>> this email. The important is:
>>>
>>>copy from arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>>copy to arch/powerpc/platforms/85xx/p2020.c
>>>
>>> Which means that git thinks that my newly introduced file p2020.c is
>>> similar to old file mpc85xx_ds.c and generated diff in format which do:
>>>
>>>1. copy mpc85xx_ds.c to p2020.c
>>>2. apply diff on newly introduced file p2020.c
>>>
>>> Code is really moved from mpc85xx_ds.c and mpc85xx_rdb.c files into file
>>> p2020.c.
>>>
>>> File p2020.c is new in this patch.
>>
>> Well, I didn't really look in how the patch was generated, I imported
>> your series and mainly reviewed it in git directly.
>>
>> For this patch I have the following diff stat:
>>
>> $ git show --stat e2d8c39e2e32855658d1c5f042a7ce88952f488a
>> commit e2d8c39e2e32855658d1c5f042a7ce88952f488a
>> Author: Pali Rohár
>> Date: Fri Aug 19 21:15:53 2022 +0200
>>
>> powerpc/85xx: p2020: Move all P2020 machine descriptions to p2020.c
>>
>> This moves machine descriptions and all related code for all P2020
>> boards
>> into new p2020.c source file. This is preparation for code
>> deduplication
>> and providing one unified machine description for all P2020 boards.
>>
>> Signed-off-by: Pali Rohár
>>
>>arch/powerpc/platforms/85xx/Makefile | 2 ++
>>arch/powerpc/platforms/85xx/mpc85xx_ds.c | 23 --
>>arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 44 --
>>arch/powerpc/platforms/85xx/p2020.c | 273
>> ++
>>4 files changed, 275 insertions(+), 67 deletions(-)
>>
>>
>> So there is a lot more code added than deleted.
>>
>> If it was really a code move as described in the commit message, I would
>> have approximately the same number of inserts as number of deletions.
>
> I see... The reason is that helper ds/rdb functions are copies (not
> moved) because they are needed still in ds/rdb boards. And in later
> patches in this patch series are then p2020 helper function cleaned and
> simplified.
>
> So as I see basically this change moves p2020 machine descriptions from
> ds/rdb files into p2020.c, plus copy helper functions.
>
If that's the case, that's fine. Please describe it like that in the
commit message.
> Not sure what should be the best case how to do it. I did not wanted to
> introduce regression in the code, so I rather did not touched non-p2020
> code in ds/rdb files.
>
>>
>>>
>
> Signed-off-by: Pali Rohár
> ---
> arch/powerpc/platforms/85xx/Makefile | 2 +
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 23 ---
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 44 --
> .../platforms/85xx/{mpc85xx_ds.c => p2020.c} | 134 --
> 4 files changed, 91 insertions(+), 112 deletions(-)
> copy arch/powerpc/platforms/85xx/{mpc85xx_ds.c => p2020.c} (65%)
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile
> b/arch/powerpc/platforms/85xx/Makefile
> index 260fbad7967b..1ad261b4eeb6 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -23,6 +23,8 @@ obj-$(CONFIG_P1010_RDB) += p1010rdb.o
> obj-$(CONFIG_P1022_DS)+= p1022_ds.o
> obj-$(CONFIG_P1022_RDK) += p1022_rdk.o
> obj-$(CONFIG_P1023_RDB) += p1023_rdb.o
> +obj-$(CONFIG_MPC85xx_DS) += p2020.o
> +obj-$(CONFIG_MPC85xx_RDB) += p2020.o
> obj-$(CONFIG_TWR_P102x) += twr_p102x.o
> obj-$(CONFIG_CORENET_GENERIC) += corenet_generic.o
> obj-$(CONFIG_FB_FSL_DIU) += t1042rdb_diu.o
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> index 9a6d637ef54a..05aac997b5ed 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> @@ -168,7
Re: [PATCH mm-unstable RFC 17/26] powerpc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit book3s
Le 06/12/2022 à 15:47, David Hildenbrand a écrit :
> We already implemented support for 64bit book3s in commit bff9beaa2e80
> ("powerpc/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE for book3s")
>
> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also in 32bit by reusing yet
> unused LSB 2 / MSB 29. There seems to be no real reason why that bit cannot
> be used, and reusing it avoids having to steal one bit from the swap
> offset.
>
> While at it, mask the type in __swp_entry().
>
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/include/asm/book3s/32/pgtable.h | 38 +---
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
> b/arch/powerpc/include/asm/book3s/32/pgtable.h
> index 75823f39e042..8107835b38c1 100644
> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
> @@ -42,6 +42,9 @@
> #define _PMD_PRESENT_MASK (PAGE_MASK)
> #define _PMD_BAD(~PAGE_MASK)
>
> +/* We borrow the _PAGE_USER bit to store the exclusive marker in swap PTEs.
> */
> +#define _PAGE_SWP_EXCLUSIVE _PAGE_USER
> +
> /* And here we include common definitions */
>
> #define _PAGE_KERNEL_RO 0
> @@ -363,17 +366,42 @@ static inline void __ptep_set_access_flags(struct
> vm_area_struct *vma,
> #define pmd_page(pmd) pfn_to_page(pmd_pfn(pmd))
>
> /*
> - * Encode and decode a swap entry.
> - * Note that the bits we use in a PTE for representing a swap entry
> - * must not include the _PAGE_PRESENT bit or the _PAGE_HASHPTE bit (if used).
> - * -- paulus
> + * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
> + * are !pte_none() && !pte_present().
> + *
> + * Format of swap PTEs (32bit PTEs):
> + *
> + * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> + * E H P <- type --> <- offset -->
That's in reversed order. _PAGE_HASHPTE is bit 30 and should be on the
right hand side. Etc ...
Some exemple in arch/powerpc/include/asm/nohash/32/pte-40x.h or
arch/powerpc/include/asm/nohash/32/pte-85xx.h
> + *
> + * E is the exclusive marker that is not stored in swap entries.
> + * _PAGE_PRESENT (P) and __PAGE_HASHPTE (H) must be 0.
> + *
> + * For 64bit PTEs, the offset is extended by 32bit.
>*/
> #define __swp_type(entry) ((entry).val & 0x1f)
> #define __swp_offset(entry) ((entry).val >> 5)
> -#define __swp_entry(type, offset)((swp_entry_t) { (type) | ((offset) <<
> 5) })
> +#define __swp_entry(type, offset)((swp_entry_t) { ((type) & 0x1f) |
> ((offset) << 5) })
> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte)
> >> 3 })
> #define __swp_entry_to_pte(x) ((pte_t) { (x).val << 3 })
>
> +#define __HAVE_ARCH_PTE_SWP_EXCLUSIVE
> +static inline int pte_swp_exclusive(pte_t pte)
> +{
> + return pte_val(pte) & _PAGE_SWP_EXCLUSIVE;
> +}
> +
> +static inline pte_t pte_swp_mkexclusive(pte_t pte)
> +{
> + return __pte(pte_val(pte) | _PAGE_SWP_EXCLUSIVE);
> +}
> +
> +static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> +{
> + return __pte(pte_val(pte) & ~_PAGE_SWP_EXCLUSIVE);
> +}
> +
> /* Generic accessors to PTE bits */
> static inline int pte_write(pte_t pte) { return
> !!(pte_val(pte) & _PAGE_RW);}
> static inline int pte_read(pte_t pte) { return 1; }
Re: [PATCH v3] powerpc/boot: Don't always pass -mcpu=powerpc when building 32-bit uImage
Le 26/11/2022 à 17:30, Pali Rohár a écrit : > On Wednesday 02 November 2022 14:05:35 Christophe Leroy wrote: >> Le 01/11/2022 à 23:12, Pali Rohár a écrit : >>> On Sunday 09 October 2022 13:06:52 Pali Rohár wrote: On Monday 29 August 2022 10:54:51 Pali Rohár wrote: > On Sunday 28 August 2022 17:43:53 Christophe Leroy wrote: >> Le 28/08/2022 à 19:41, Pali Rohár a écrit : >>> On Sunday 28 August 2022 17:39:25 Christophe Leroy wrote: Le 28/08/2022 à 19:33, Christophe Leroy a écrit : > > > Le 28/08/2022 à 11:56, Pali Rohár a écrit : >> When CONFIG_TARGET_CPU is specified then pass its value to the >> compiler >> -mcpu option. This fixes following build error when building kernel >> with >> powerpc e500 SPE capable cross compilers: >> >> BOOTAS arch/powerpc/boot/crt0.o >> powerpc-linux-gnuspe-gcc: error: unrecognized argument in >> option >> ‘-mcpu=powerpc’ >> powerpc-linux-gnuspe-gcc: note: valid arguments to ‘-mcpu=’ >> are: >> 8540 8548 native >> make[1]: *** [arch/powerpc/boot/Makefile:231: >> arch/powerpc/boot/crt0.o] Error 1 > > corenet64_smp_defconfig : > > BOOTAS arch/powerpc/boot/crt0.o > powerpc64-linux-gcc: error: missing argument to '-mcpu=' > make[1]: *** [arch/powerpc/boot/Makefile:237 : > arch/powerpc/boot/crt0.o] > Erreur 1 > make: *** [arch/powerpc/Makefile:253 : uImage] Erreur 2 > > Seems like in fact, E5500_CPU and E6500_CPU are not taken into account in CONFIG_TARGET_CPU, and get special treatment directly in arch/powerpc/Makefile. This goes unnoticed because of CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += $(call cc-option,-mcpu=$(CONFIG_TARGET_CPU)) I think we need to fix that prior to your patch. >>> >>> It looks like that CONFIG_TARGET_CPU is broken. >>> >>> $ make ARCH=powerpc corenet64_smp_defconfig >>> CROSS_COMPILE=powerpc64-linux-gnu- >>> ... >>> # configuration written to .config >>> >>> $ grep CONFIG_TARGET_CPU .config >>> CONFIG_TARGET_CPU_BOOL=y >>> >>> CONFIG_TARGET_CPU_BOOL is set but CONFIG_TARGET_CPU not! >> >> Yes, because there is no default value for E5500_CPU and E6500_CPU. We >> need to add one for each. > > I see... Will you prepare this fixup for your previous patch? > > And I think that following construct > > $(call cc-option,-mcpu=$(CONFIG_TARGET_CPU)) > > should be changed just to > > -mcpu=$(CONFIG_TARGET_CPU) > > Because if user specified that want build for specific target CPU, it > should not be silently ignored. Christophe, should I do something in this area? >>> >>> Christophe, any input from your side? >> >> Hi, sorry I was on holiday until today. I'll try to have a look in the >> coming days. > > Ok, Did you have a time to look at it? I just sent a patch for it. Christophe
[PATCH v1] powerpc/64: Set default CPU in Kconfig
Since 0069f3d14e7a ("powerpc/64e: Tie PPC_BOOK3E_64 to PPC_E500MC"),
the only possible BOOK3E/64 are E500, so no need of a default CPU
over the E5500.
When the user selects book3e, he must have a e500 compatible compiler,
and it won't work anymore with the default -mcpu=power64, see
commit d6b551b8f90c ("powerpc/64e: Fix build failure with GCC 12
(unrecognized opcode: `wrteei')")
For book3s/64, replace GENERIC_CPU by POWERPC64_CPU to match the PPC32
POWERPC_CPU, and set a default mpcu value in Kconfig directly.
When a user selects a particular CPU, he must ensure his compiler has
the requested capability. Therefore, remove hidden fallback, instead
offer user the possibility to say he wants to use toolchain default.
Reported-by: Pali Rohár
Signed-off-by: Christophe Leroy
---
arch/powerpc/Makefile | 22 +-
arch/powerpc/platforms/Kconfig.cputype | 12 +++-
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dc4cbf0a5ca9..bf5f0a998273 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -146,19 +146,6 @@ CFLAGS-$(CONFIG_PPC32) += $(call cc-option,
$(MULTIPLEWORD))
CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata)
-ifdef CONFIG_PPC_BOOK3S_64
-ifdef CONFIG_CPU_LITTLE_ENDIAN
-CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8
-else
-CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power4
-endif
-CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power10, \
- $(call cc-option,-mtune=power9, \
- $(call cc-option,-mtune=power8)))
-else ifdef CONFIG_PPC_BOOK3E_64
-CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
-endif
-
ifdef CONFIG_FUNCTION_TRACER
CC_FLAGS_FTRACE := -pg
ifdef CONFIG_MPROFILE_KERNEL
@@ -166,11 +153,12 @@ CC_FLAGS_FTRACE += -mprofile-kernel
endif
endif
-CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += $(call
cc-option,-mcpu=$(CONFIG_TARGET_CPU))
-AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += $(call
cc-option,-mcpu=$(CONFIG_TARGET_CPU))
+CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
+AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
-CFLAGS-$(CONFIG_E5500_CPU) += $(call cc-option,-mcpu=e500mc64,-mcpu=powerpc64)
-CFLAGS-$(CONFIG_E6500_CPU) += $(call cc-option,-mcpu=e6500,$(E5500_CPU))
+CFLAGS-$(CONFIG_POWERPC64_CPU) += $(call cc-option,-mtune=power10, \
+ $(call cc-option,-mtune=power9, \
+ $(call cc-option,-mtune=power8)))
asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 9563336e3348..31cea2eeb59e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -118,19 +118,18 @@ endchoice
choice
prompt "CPU selection"
- default GENERIC_CPU
help
This will create a kernel which is optimised for a particular CPU.
The resulting kernel may not run on other CPUs, so use this with care.
If unsure, select Generic.
-config GENERIC_CPU
+config POWERPC64_CPU
bool "Generic (POWER5 and PowerPC 970 and above)"
depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
select PPC_64S_HASH_MMU
-config GENERIC_CPU
+config POWERPC64_CPU
bool "Generic (POWER8 and above)"
depends on PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN
select ARCH_HAS_FAST_MULTIPLIER
@@ -233,13 +232,12 @@ config E500MC_CPU
config TOOLCHAIN_DEFAULT_CPU
bool "Rely on the toolchain's implicit default CPU"
- depends on PPC32
endchoice
config TARGET_CPU_BOOL
bool
- default !GENERIC_CPU && !TOOLCHAIN_DEFAULT_CPU
+ default !TOOLCHAIN_DEFAULT_CPU
config TARGET_CPU
string
@@ -251,6 +249,10 @@ config TARGET_CPU
default "power8" if POWER8_CPU
default "power9" if POWER9_CPU
default "power10" if POWER10_CPU
+ default "e500mc64" if E5500_CPU
+ default "e6500" if E6500_CPU
+ default "power4" if POWERPC64_CPU && !CPU_LITTLE_ENDIAN
+ default "power8" if POWERPC64_CPU && CPU_LITTLE_ENDIAN
default "405" if 405_CPU
default "440" if 440_CPU
default "464" if 464_CPU
--
2.38.1
Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
On Mon, Dec 05, 2022 at 10:15:16PM +0300, Arınç ÜNAL wrote: > As Jonas (on CC) pointed out, I only see this being used in the swconfig b53 > driver which uses the label to identify the cpu port. > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/net/phy/b53/b53_common.c;h=87d731ec3e2a868dc8389f554b1dc9ab42c30be2;hb=HEAD#l1508 > > Maybe this got into DSA dt-bindings unchecked before it was decided to move > forward with DSA instead of swconfig on Linux. Yes, but swconfig is not DSA and their bindings are not compatible anyway (swconfig lacks an ethernet = <> property that would allow DSA to work). Still waiting for Pali to clarify what he had in mind.
Re: [PATCH] powerpc: qspinlock: Use asm-generic definition for queued_spin_lock
Rohan McLure writes:
> asm-generic/qspinlock.h provides an identical implementation of
> queued_spin_lock. Remove the variant in asm/qspinlock.h.
This code has changed recently, so this patch no longer applies.
See 9f61521c7a28 ("powerpc/qspinlock: powerpc qspinlock implementation")
in powerpc/next.
cheers
> diff --git a/arch/powerpc/include/asm/qspinlock.h
> b/arch/powerpc/include/asm/qspinlock.h
> index b676c4fb90fd..bf5ba0f00258 100644
> --- a/arch/powerpc/include/asm/qspinlock.h
> +++ b/arch/powerpc/include/asm/qspinlock.h
> @@ -33,17 +33,6 @@ static inline void queued_spin_unlock(struct qspinlock
> *lock)
> extern void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
> #endif
>
> -static __always_inline void queued_spin_lock(struct qspinlock *lock)
> -{
> - u32 val = 0;
> -
> - if (likely(arch_atomic_try_cmpxchg_lock(>val, ,
> _Q_LOCKED_VAL)))
> - return;
> -
> - queued_spin_lock_slowpath(lock, val);
> -}
> -#define queued_spin_lock queued_spin_lock
> -
> #ifdef CONFIG_PARAVIRT_SPINLOCKS
> #define SPIN_THRESHOLD (1<<15) /* not tuned */
>
> --
> 2.37.2
[PATCH] [PATCH net-next] powerpc: iommu: delete redundant row
Signed-off-by: wangchuanlei --- arch/powerpc/kernel/iommu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index caebe1431596..dd010a733404 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -953,7 +953,6 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t size, size = PAGE_ALIGN(size); nio_pages = size >> tbl->it_page_shift; iommu_free(tbl, dma_handle, nio_pages); - size = PAGE_ALIGN(size); free_pages((unsigned long)vaddr, get_order(size)); } } -- 2.27.0
