module_trampoline_target() is quite a hot path used when
activating/deactivating function tracer.
Avoid the heavy copy_from_kernel_nofault() by doing four calls
to copy_inst_from_kernel_nofault().
Use __copy_inst_from_kernel_nofault() for the 3 last calls. First call
is done to copy_from_kernel_n
Replace all uses of PPC64_ELF_ABI_v1 and PPC64_ELF_ABI_v2 by
resp CONFIG_PPC64_ELF_ABI_V1 and CONFIG_PPC64_ELF_ABI_V2.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/code-patching.h | 12 ++--
arch/powerpc/include/asm/ftrace.h| 4 ++--
arch/powerpc/include/asm/link
Use PPC_LI_MASK and PPC_LI() instead of opencoding.
Signed-off-by: Christophe Leroy
---
v2: Utilisation de PPC_LI() et PPC_LI_MASK
---
arch/powerpc/kernel/module_32.c | 11 ---
arch/powerpc/kernel/module_64.c | 3 +--
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/p
At the time being, we use CONFIG_CPU_LITTLE_ENDIAN and
CONFIG_CPU_BIG_ENDIAN to pass -mabi=elfv1 or elfv2 to
compiler, then define a PPC64_ELF_ABI_v1 or PPC64_ELF_ABI_v2
macro in asm/types.h based on _CALL_ELF define set by the compiler.
Make it more straight forward with a CONFIG option that
is d
The following PPC_INST_XXX macros are not used anymore
outside ppc-opcode.h:
- PPC_INST_LD
- PPC_INST_STD
- PPC_INST_ADDIS
- PPC_INST_ADD
- PPC_INST_DIVD
Remove them.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ppc-opcode.h | 13 -
When we have CONFIG_DYNAMIC_FTRACE_WITH_ARGS,
prepare_ftrace_return() is called by ftrace_graph_func()
otherwise prepare_ftrace_return() is called from assembly.
Refactor prepare_ftrace_return() into a static
__prepare_ftrace_return() that will be called by both
prepare_ftrace_return() and ftrace_
A lot of #ifdefs can be replaced by IS_ENABLED()
Do so.
This requires to have kernel_toc_addr() defined at all time
as well as PPC_INST_LD_TOC and PPC_INST_STD_LR.
Signed-off-by: Christophe Leroy
---
v2: Moved the setup of pop outside of the big if()/else() in __ftrace_make_nop()
---
arch/powe
Since c93d4f6ecf4b ("powerpc/ftrace: Add module_trampoline_target()
for PPC32"), __ftrace_make_nop() for PPC32 is very similar to the
one for PPC64.
Same for __ftrace_make_call().
Make them common.
Signed-off-by: Christophe Leroy
---
v2:
- Fixed comment to -mprofile-kernel versus -mkernel_profi
Avoid ifdefs around expected_nop_sequence().
While at it make it a bool.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c
b/arch/powerpc/kernel/t
PPC_RAW_xxx() macros are self explanatory and less error prone
than open coding.
Use them in ftrace.c
Signed-off-by: Christophe Leroy
---
v2:
- Replaced PPC_INST_OFFSET24_MASK by PPC_LI_MASK and added PPC_LI().
- Fix ADDI instead of ADDIS
---
arch/powerpc/include/asm/ppc-opcode.h | 5 +
ar
Convert last users of PPC_INST_BL to PPC_RAW_BL()
And remove PPC_INST_BL.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ppc-opcode.h | 1 -
arch/powerpc/net/bpf_jit.h| 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opc
Use is_offset_in_branch_range() instead of create_branch()
to check if a target is within branch range.
This patch together with the previous one improves
ftrace activation time by 7%
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace.c | 8 ++--
1 file changed, 2 insertio
To make it explicit, use BRANCH_SET_LINK instead of value 1
when calling create_branch().
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c
b/arch/powerpc/kernel/trace/ftr
Instead of returning -EPERM when patch_instruction() fails,
just return what patch_instruction returns.
That simplifies ftrace_modify_code():
0: 94 21 ff c0 stwur1,-64(r1)
4: 93 e1 00 3c stw r31,60(r1)
8: 7c 7f 1b 79 mr. r31,r3
Inlining ftrace_modify_code(), it increases a bit the
size of ftrace code but brings 5% improvment on ftrace
activation.
Usually in C files we let gcc decide what to do but here
it really help to 'help' gcc to decide to inline, thought
we don't want to force it with an __always_inline that
would b
Convert last users of PPC_INST_BRANCH to PPC_RAW_BRANCH()
And remove PPC_INST_BRANCH.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ppc-opcode.h | 3 +--
arch/powerpc/lib/feature-fixups.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/incl
Since commit 7bea7ac0ca01 ("powerpc/syscalls: Fix syscall tracing")
ftrace.o is not needed anymore for CONFIG_FTRACE_SYSCALLS.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/trace/Makefile
b/arch/powe
On the same model as get_user() versus __get_user(),
introduce __copy_inst_from_kernel_nofault() which doesn't
check address.
To be used by callers that have already checked that the adress
is a kernel address.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/inst.h | 13 +--
create_branch() is a good candidate for inlining because:
- Flags can be folded in.
- Range tests are likely to be already done.
Hence reducing the create_branch() to only a set of instructions.
So inline it.
It improves ftrace activation by 10%.
Signed-off-by: Christophe Leroy
---
arch/power
Since commit 0c0c52306f47 ("powerpc: Only support DYNAMIC_FTRACE not
static"), CONFIG_DYNAMIC_FTRACE is always selected when
CONFIG_FUNCTION_TRACER is selected.
To avoid confusion and have the reader wonder what's happen when
CONFIG_FUNCTION_TRACER is selected and CONFIG_DYNAMIC_FTRACE is not,
use
This series provides optimisation and cleanup of ftrace on powerpc.
With this series ftrace activation is about 20% faster on an 8xx.
At the end of the series come additional cleanups around ppc-opcode,
that would likely conflict with this series if posted separately.
Main changes since v1 (deta
Now that we have CONFIG_PPC64_ELF_ABI_V1 and CONFIG_PPC64_ELF_ABI_V2,
get rid of all indirect detection of ABI version.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig| 2 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/include/asm/types.h| 8
Since commit d5937db114e4 ("powerpc/code-patching: Fix patch_branch()
return on out-of-range failure") patch_branch() fails with -ERANGE
when trying to branch out of range.
No need to perform the test twice. Remove redundant create_branch()
calls.
Signed-off-by: Christophe Leroy
---
arch/powerp
Test in is_offset_in_branch_range() and is_offset_in_cond_branch_range()
are simple tests that are worth inlining.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/code-patching.h | 29 ++--
arch/powerpc/lib/code-patching.c | 27 --
2 f
ftrace_plt_tramps table is never filled so it is useless.
Remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c
b/arch/powerpc/kernel/trace/ftrace.c
index f89bcaa5f0fc..010
0x8000 is SZ_2G. Use it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c
b/arch/powerpc/kernel/trace/ftrace.c
index ac3f97dd1729..346b5485e7ef 100644
--- a/arch/powe
Having all the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer, the target specification
generation script, the version detection script and a few
other bits.
Co-developed-by: Alex Gaynor
Signed-off-by
On Sat, May 7, 2022 at 11:02 AM Herbert Xu wrote:
>
> On Sat, May 07, 2022 at 12:25:32AM +0900, Masahiro Yamada wrote:
> >
> > Sorry, I just noticed the 0day bot had reported the error.
> >
> > I sent v2.(CONFIG_LITTLE_ENDIAN --> CONFIG_CPU_LITTLE_ENDIAN)
> >
> > https://lore.kernel.org/lkml/
Rust support
This is the patch series (v6) to add support for Rust as a second
language to the Linux kernel.
If you are interested in following this effort, please join us in
the mailing list at:
rust-for-li...@vger.kernel.org
and take a look at the project itself at:
https://github.co
When I refactored this Makefile, I accidentally changed the CONFIG
option.
Fixes: b52455a73db9 ("crypto: vmx - Align the short log with Makefile cleanups")
Reported-by: kernel test robot
Signed-off-by: Masahiro Yamada
---
drivers/crypto/vmx/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 de
On 5/7/2022 1:56 AM, Mike Kravetz wrote:
On 5/5/22 20:39, Baolin Wang wrote:
On 5/6/2022 7:53 AM, Mike Kravetz wrote:
On 4/29/22 01:14, Baolin Wang wrote:
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
On Sat, May 07, 2022 at 12:25:32AM +0900, Masahiro Yamada wrote:
>
> Sorry, I just noticed the 0day bot had reported the error.
>
> I sent v2.(CONFIG_LITTLE_ENDIAN --> CONFIG_CPU_LITTLE_ENDIAN)
>
> https://lore.kernel.org/lkml/20220506150820.1310802-1-masahi...@kernel.org/
>
>
> Could you
On 5/7/2022 2:55 AM, Mike Kravetz wrote:
On 4/29/22 01:14, Baolin Wang wrote:
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
On Fri, 6 May 2022, Niklas Schnelle wrote:
> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> >
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> >
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > > > On
Hi Masahiro,
On Thu, May 05, 2022 at 04:22:29PM +0900, Masahiro Yamada wrote:
>
> This is the third batch of cleanups in this development cycle.
>
> Major changes in v3:
>
> - Generate symbol CRCs as C code, and remove CONFIG_MODULE_REL_CRCS.
>
> Major changes in v2:
>
> - V1 did not work w
On Fri, May 06 2022 at 23:41, Thomas Gleixner wrote:
> On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>> Programming an HPET channel as periodic requires setting the
>> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
>> register must be written twice (once for the comparato
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Programming an HPET channel as periodic requires setting the
> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
> register must be written twice (once for the comparator value and once for
> the periodic value). Since this pro
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> + *
> + * Also, NMIs do not have an associated vector. No need for cleanup.
They have a vector and what the heck is this cleanup comment for here?
There is nothing cleanup alike anywhere near.
Adding confusing comments is worse than ad
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>
> + if (info->flags & X86_IRQ_ALLOC_AS_NMI) {
> + /* Only one IRQ per NMI */
> + if (nr_irqs != 1)
> + return -EINVAL;
See previous reply.
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> The Intel IOMMU interrupt remapping driver already programs correctly the
> delivery mode of individual irqs as per their irq_data. Improve handling
> of NMIs. Allow only one irq per NMI. Also, it is not necessary to cleanup
> irq vectors after up
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Vectors are meaningless when allocating IRQs with NMI as the delivery
> mode.
Vectors are not meaningless. NMI has a fixed vector.
The point is that for a fixed vector there is no vector management
required.
Can you spot the difference?
> In s
P2020 also contains Power Management Controller and their registers at
offset 0xe0070 compatible with mpc8548. So add PMC node into DTS include
file fsl/p2020si-post.dtsi
Signed-off-by: Pali Rohár
---
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> There are no restrictions in hardware to set MSI messages with its
> own delivery mode.
"messages with its own" ? Plural/singular confusion.
> Use the mode specified in the provided IRQ hardware
> configuration data. Since most of the IRQs are
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Currently, the delivery mode of all interrupts is set to the mode of the
> APIC driver in use. There are no restrictions in hardware to configure the
> delivery mode of each interrupt individually. Also, certain IRQs need
> to be
s/IRQ/interrupt/
Ricardo,
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Certain types of interrupts, such as NMI, do not have an associated vector.
> They, however, target specific CPUs. Thus, when assigning the destination
> CPU, it is beneficial to select the one with the lowest number of
> vectors.
Why i
On 5/3/22 03:03, Gerald Schaefer wrote:
> On Tue, 3 May 2022 10:19:46 +0800
> Baolin Wang wrote:
>
>>
>>
>> On 5/2/2022 10:02 PM, Gerald Schaefer wrote:
>>> On Sat, 30 Apr 2022 11:22:33 +0800
>>> Baolin Wang wrote:
>>>
On 4/30/2022 4:02 AM, Gerald Schaefer wrote:
> On Fri, 29
On 4/29/22 01:14, Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When unmapping a hugetlb page, we
A handful of WAN drivers use custom napi weights,
switch them to the new API.
Signed-off-by: Jakub Kicinski
---
CC: qiang.z...@nxp.com
CC: k...@pm.waw.pl
CC: m...@dev.tdt.de
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-...@vger.kernel.org
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
drivers/net/wan
Capture register data for secondary CPUs in crash_smp_send_stop()
instead of doing it much later in crash_kexec_prepare_cpus() function
with another set of NMI IPIs to secondary CPUs. This change avoids
unnecessarily tricky post processing of data to get the right
backtrace for these CPUs.
Signed-
Hi Herbert,
On Fri, May 6, 2022 at 7:23 PM Herbert Xu wrote:
>
> On Sun, May 01, 2022 at 10:07:49PM +0900, Masahiro Yamada wrote:
> > I notieced the log is not properly aligned:
> >
> > PERL drivers/crypto/vmx/aesp8-ppc.S
> > CC [M] fs/xfs/xfs_reflink.o
> > PERL drivers/crypto/vmx/ghashp
I notieced the log is not properly aligned:
PERL drivers/crypto/vmx/aesp8-ppc.S
CC [M] fs/xfs/xfs_reflink.o
PERL drivers/crypto/vmx/ghashp8-ppc.S
CC [M] drivers/crypto/vmx/aes.o
Add some spaces after 'PERL'.
While I was here, I cleaned up the Makefile:
- Merge the two similar rules
Hi Geert,
> > Sane access would require a single CPU instruction to read or write from
> > the configuration space. To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space. Such amount of address space seems affo
Hi David
On Fri, May 6, 2022 at 4:05 PM David Laight wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> >
Hi Maciej,
On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > > It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need fo
On Fri, 6 May 2022, David Laight wrote:
> > It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture. Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
>
Alexey Kardashevskiy writes:
> When KVM_CAP_PPC_ENABLE_HCALL was introduced, H_GET_TCE and H_PUT_TCE
> were already implemented and enabled by default; however H_GET_TCE
> was missed out on PR KVM (probably because the handler was in
> the real mode code at the time).
>
> This enables H_GET_TCE b
From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > e
On Fri, 6 May 2022, Geert Uytterhoeven wrote:
> A lng time ago, it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl()
From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
>
> > > The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO. Thank y
Hi Athira,
Some comments below :)
Athira Rajeev writes:
> Add caps support under "/sys/bus/event_source/devices//"
> for powerpc. This directory can be used to expose some of the
> specific features that powerpc PMU supports to the user.
> Example: pmu_name. The name of PMU registered will depen
On Fri, 6 May 2022, Arnd Bergmann wrote:
> > So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument? Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> Not sure. My best guess is that it would actually work as you'd expect
On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> >
> > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the addre
On Fri, 6 May 2022, David Laight wrote:
> > The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO. Thank you for your explanation.
>
> Actually I think x86 was the i
On Fri, May 6, 2022 at 2:56 PM David Laight wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase. So
On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architec
From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architecture th
On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architectu
On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> > I think I'm missing something here. IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> >
> > (It has to
On Fri, 6 May 2022, Arnd Bergmann wrote:
> > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase. So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
>
Le 18/04/2022 à 08:40, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> Since c93d4f6ecf4b ("powerpc/ftrace: Add module_trampoline_target()
>> for PPC32"), __ftrace_make_nop() for PPC32 is very similar to the
>> one for PPC64.
>>
>> Same for __ftrace_make_call().
>>
>> Make them common.
>>
>>
Le 18/04/2022 à 09:00, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> Since commit 0c0c52306f47 ("powerpc: Only support DYNAMIC_FTRACE not
>> static"), CONFIG_DYNAMIC_FTRACE is always selected when
>> CONFIG_FUNCTION_TRACER is selected.
>>
>> To avoid confusion and have the reader wonder wh
On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
> I think I'm missing something here. IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
> (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> onl
On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
>
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
>
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
On Sun, May 01, 2022 at 10:07:49PM +0900, Masahiro Yamada wrote:
> I notieced the log is not properly aligned:
>
> PERL drivers/crypto/vmx/aesp8-ppc.S
> CC [M] fs/xfs/xfs_reflink.o
> PERL drivers/crypto/vmx/ghashp8-ppc.S
> CC [M] drivers/crypto/vmx/aes.o
>
> Add some spaces after 'PERL'
On Thu, May 05, 2022 at 06:09:45PM -0700, Josh Poimboeuf wrote:
> With CONFIG_GENERIC_BUG_RELATIVE_POINTERS, the addr/file relative
> pointers are calculated weirdly: based on the beginning of the bug_entry
> struct address, rather than their respective pointer addresses.
>
> Make the relative poi
On Thu, 5 May 2022, Arnd Bergmann wrote:
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't. That makes me think
> > s390 could do something similar.
>
> No, this is actually the current situation, and it makes absolutely n
On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what
Hi Kajol,
Thanks for the patch. Minor review comment below:
Kajol Jain writes:
> With CONFIG_FORTIFY_SOURCE enabled, string functions will also perform
> dynamic checks for string size which can panic the kernel,
> like incase of overflow detection.
>
> In papr_scm, papr_scm_pmu_check_events fu
> On 05-May-2022, at 10:51 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Thu, May 05, 2022 at 03:30:39PM +0530, Athira Rajeev escreveu:
>> Perf BPF filter test fails in environment where "clang"
>> is not installed.
>>
>> Test failure logs:
>>
>> <<>>
>> 42: BPF filter:
>> 4
> On 05-May-2022, at 10:54 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Thu, May 05, 2022 at 03:09:59PM +0530, Athira Rajeev escreveu:
>> /proc/cpuinfo provides information about type of processor, number
>> of CPU's etc. Reading /proc/cpuinfo file outputs useful information
>> by field name lik
Josh Poimboeuf writes:
> With CONFIG_GENERIC_BUG_RELATIVE_POINTERS, the addr/file relative
> pointers are calculated weirdly: based on the beginning of the bug_entry
> struct address, rather than their respective pointer addresses.
>
> Make the relative pointers less surprising to both humans and
Trying to remove asm/ppc_asm.h from all places that don't need it
leads to several failures linked to firmware_has_feature().
To fix it, include asm/firmware.h in all files using
firmware_has_feature()
All users found with:
git grep -L "firmware\.h" ` git grep -l "firmware_has_feature("`
asm/ppc_asm.h is not needed in any of the header it is included.
It is only needed by irq.c. Include it there and remove it from
other headers.
word-at-a-time.h only need ex_table.h, so include it instead.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/io.h | 1 -
arc
On Thu, 5 May 2022, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what hap
From: Athira Rajeev
Add new folder for enabling perf event code tests which
includes checking for group constraints, valid/invalid events,
also checks for event excludes, alternatives so on. A new folder
"event_code_tests", is created under "selftests/powerpc/pmu".
Also updates the corresponding
The testcase uses "instructions" event to check if the
Instruction filtering mode(IFM) bits are programmed correctly
for indirect branch type. Testcase checks if IFM bits are
programmed correctly to Monitor Mode Control Register A (MMCRA)
via perf interface for ISA v3.1 platform.
Signed-off-by: Ka
The testcase checks if the transalation of a generic hardware cache
event is done properly via perf interface. The hardware cache events
has type as PERF_TYPE_HW_CACHE and each event points to raw event
code id.
Testcase checks different combination of cache level,
cache event operation type and c
Thresh compare bits for a event is used to program thresh compare
field in Monitor Mode Control Register A (MMCRA: 9-18 bits for
power9 and MMCRA: 8-18 bits for power10). When scheduling events
as a group, all events in that group should match value in
thresh compare bits. Otherwise event open for
Thresh select bits in the event code is used to program thresh_sel
field in Monitor Mode Control Register A (MMCRA: 45-47). When scheduling
events as a group, all events in that group should match value in these
bits. Otherwise event open for the sibling events will fail.
Testcase uses event code
Thresh control bits in the event code is used to program thresh_ctl
field in Monitor Mode Control Register A (MMCRA: 48-55). When scheduling
events as a group, all events in that group should match value in these
bits. Otherwise event open for the sibling events will fail.
Testcase uses event code
From: Athira Rajeev
Testcase for reserved bits in Monitor Mode Control
Register A (MMCRA) Random Sampling Mode (SM) value.
As per Instruction Set Architecture (ISA), the values
0x5, 0x9, 0xD, 0x19, 0x1D, 0x1A, 0x1E are reserved
for sampling mode field. Test that having these reserved
bit values s
Unit and pmu bits in the event code is used to program unit and pmc
fields in Monitor Mode Control Register 1 (MMCR1). For power9 platform,
incase unit field value is within 6 to 9, one of the event in the group
should use PMC4. Otherwise event_open should fail for that group.
Signed-off-by: Kajol
Data and instruction cache qualifier bits in the event code is
used to program cache select field in Monitor Mode Control
Register 1 (MMCR1: 16-17). When scheduling events as a group, all
events in that group should match value in these bits. Otherwise
event open for the sibling events will fail.
The testcase uses "instructions" event to generate the
samples and fetch Monitor Mode Control Register A (MMCRA)
when overflow. Branch History Rolling Buffer(bhrb) disable bit
is part of MMCRA which need to be verified by perf interface.
Testcase checks if the bhrb disable bit of MMCRA register is
In power10, L2L3 select bits in the event code is used to
program l2l3_sel field in Monitor Mode Control Register 0
(MMCR0: 56-60). When scheduling events as a group,
all events in that group should match value in these bits.
Otherwise event open for the sibling events will fail.
Testcase uses eve
From: Athira Rajeev
Testcase to ensure that using invalid event in generic
event for PERF_TYPE_HARDWARE will fail. Invalid generic
events in power10 are:
- PERF_COUNT_HW_BUS_CYCLES
- PERF_COUNT_HW_STALLED_CYCLES_FRONTEND
- PERF_COUNT_HW_STALLED_CYCLES_BACKEND
- PERF_COUNT_HW_REF_CPU_CYCLES
Inval
From: Athira Rajeev
Platform specific PMU supports alternative event for some
of the event codes. During perf_event_open, it any event
group doesn't match constraint check criteria, further lookup
is done to find alternative event. Code checks to see if
it is possible to schedule event as group u
From: Athira Rajeev
Platform specific PMU supports alternative event for some
of the event codes. During perf_event_open, it any event
group doesn't match constraint check criteria, further lookup
is done to find alternative event. Code checks to see if
it is possible to schedule event as group u
From: Athira Rajeev
Testcase for reserved bits in Monitor Mode
Control Register A (MMCRA) thresh_ctl bits.
For MMCRA[48:51]/[52:55]) Threshold Start/Stop,
0b/0b is reserved.
Signed-off-by: Athira Rajeev
---
.../powerpc/pmu/event_code_tests/Makefile | 2 +-
.../reserved_bit
From: Athira Rajeev
Some of the events are blacklisted in power9. The list
of blacklisted events are noted in power9-events-list.h
When trying to do event open for any of these blacklisted
event will cause a failure. Testcase ensures that using
blacklisted events will cause event_open to fail in
1 - 100 of 123 matches
Mail list logo
