On Wed, Dec 06, 2023 at 05:13:33PM +0100, Christophe Leroy wrote:
> of_machine_compatible_match() works with a table of strings.
> of_machine_is_compatible() is a simplier version with only one string.
>
> Re-implement of_machine_is_compatible() by setting a table of strings
> with a single
On Wed, 06 Dec 2023 17:13:32 +0100, Christophe Leroy wrote:
> From: Michael Ellerman
>
> We have of_machine_is_compatible() to check if a machine is compatible
> with a single compatible string. However some code is able to support
> multiple compatible boards, and so wants to check for one of
On Wed, Dec 06, 2023 at 05:13:35PM +0100, Christophe Leroy wrote:
> Replace all usages of of_root by of_find_node_by_path("/")
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/secure_boot.c| 8 ++--
> arch/powerpc/kexec/ranges.c | 8 +---
>
On Wed, 08 Nov 2023 13:58:21 +0100, Arnd Bergmann wrote:
> I slightly dropped the ball on this since last sending the series in
> August, but a number of warning fixes have made it into the kernel in
> the meantime, both from my earlier submission and from architecture
> maintainers.
>
> I have
On Wed, Dec 06, 2023 at 05:13:34PM +0100, Christophe Leroy wrote:
> Most probe functions that do not use the 'compatible' string do
> nothing else than checking whether the machine is compatible with
> one of the strings in a NULL terminated table of strings.
>
> Define that table of strings in
On 12/6/23 16:02, Waiman Long wrote:
On 12/6/23 14:55, Hans de Goede wrote:
Hi,
On 12/6/23 19:58, George Stark wrote:
Hello Hans
Thanks for the review.
On 12/6/23 18:01, Hans de Goede wrote:
Hi George,
On 12/4/23 19:05, George Stark wrote:
Using of devm API leads to certain order of
From: Nathan Lynch
Not all of the generic RTAS function statuses specified in PAPR have
symbolic constants and descriptions in rtas.h. Fix this, providing a
little more background, slightly updating the existing wording, and
improving the formatting.
Reviewed-by: Aneesh Kumar K.V (IBM)
From: Nathan Lynch
If the function descriptor has a populated lock member, then callers
are required to hold it across calls. Now that the firmware activation
sequence is appropriately guarded, we can warn when the requirement
isn't satisfied.
__do_enter_rtas_trace() gets reorganized a bit as a
ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Signed-off-by: Samuel Holland
---
arch/arm/Kconfig | 1 +
arch/arm/Makefile
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Signed-off-by: Samuel Holland
---
arch/arm/lib/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/lib/Makefile
PowerPC provides an equivalent to the common kernel-mode FPU API, but in
a different header and using different function names. The PowerPC API
also requires a non-preemptible context. Add a wrapper header, and
export the CFLAGS adjustments.
Signed-off-by: Samuel Holland
---
This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.
Use a similar trick as ARM to force placing floating-point code in a
separate
x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a
different header. Add a wrapper header, and export the CFLAGS
adjustments as found in lib/Makefile.
Signed-off-by: Samuel Holland
---
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 20
Now that ARCH_HAS_KERNEL_FPU_SUPPORT provides a common way to compile
and run floating-point code, this test is no longer x86-specific.
Signed-off-by: Samuel Holland
---
lib/Kconfig.debug | 2 +-
lib/Makefile| 25 ++---
lib/test_fpu_glue.c | 5 -
3 files
arm64 provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Signed-off-by: Samuel Holland
---
arch/arm64/Kconfig | 1 +
LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
asm/fpu.h, so it only needs to add kernel_fpu_available() and export
the CFLAGS adjustments.
Signed-off-by: Samuel Holland
---
arch/loongarch/Kconfig | 1 +
arch/loongarch/Makefile | 5 -
Now that all previously-supported architectures select
ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
of the existing list of architectures. It can also take advantage of the
common kernel-mode FPU API and method of adjusting CFLAGS.
Signed-off-by: Samuel Holland
---
This series supersedes my earier RISC-V specific series[1].
This series unifies the kernel-mode FPU API across several architectures
by wrapping the existing functions (where needed) in consistently-named
functions placed in a consistent header location, with mostly the same
semantics: they can
Several architectures provide an API to enable the FPU and run
floating-point SIMD code in kernel space. However, the function names,
header locations, and semantics are inconsistent across architectures,
and FPU support may be gated behind other Kconfig options.
Provide a standard way for
This ensures no compiler-generated floating-point code can appear
outside kernel_fpu_{begin,end}() sections, and some architectures
enforce this separation.
Signed-off-by: Samuel Holland
---
lib/Makefile| 3 ++-
lib/{test_fpu.c => test_fpu_glue.c} | 32
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Signed-off-by: Samuel Holland
---
lib/raid6/Makefile | 31 ---
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git
From: Nathan Lynch
Consistently testing system parameter access is a bit difficult by
nature -- the set of parameters available depends on the model and
system configuration, and updating a parameter should be considered a
destructive operation reserved for the admin.
So we validate some of the
Add character devices that expose PAPR-specific system parameters and
VPD to user space.
The problem: important platform features are enabled on Linux VMs
through the powerpc-specific rtas() syscall in combination with
writeable mappings of /dev/mem. In typical usage, this is encapsulated
behind
From: Nathan Lynch
Enabling any of the powerpc:rtas_* tracepoints at boot is likely to
result in an oops on RTAS platforms. For example, booting a QEMU
pseries model with 'trace_event=powerpc:rtas_input' in the command
line leads to:
BUG: Kernel NULL pointer dereference on read at 0x0008
From: Nathan Lynch
rtas_token_to_function() WARNs when passed an invalid token; it's
meant to catch bugs in kernel-based users of RTAS functions. However,
user space controls the token value passed to rtas_token_to_function()
by block_rtas_call(), so user space with sufficient privilege to use
From: Nathan Lynch
Use rtas_ibm_activate_firmware_lock to prevent interleaving call
sequences of the ibm,activate-firmware RTAS function, which typically
requires multiple calls to complete the update. While the spec does
not specifically prohibit interleaved sequences, there's almost
certainly
From: Nathan Lynch
PowerVM LPARs may retrieve Vital Product Data (VPD) for system
components using the ibm,get-vpd RTAS function.
We can expose this to user space with a /dev/papr-vpd character
device, where the programming model is:
struct papr_location_code plc = { .str = "", }; /* obtain
From: Nathan Lynch
Add selftests for /dev/papr-vpd, exercising the common expected use
cases:
* Retrieve all VPD by passing an empty location code.
* Retrieve the "system VPD" by passing a location code derived from DT
root node properties, as done by the vpdupdate command.
The tests also
From: Nathan Lynch
The ability to get and set system parameters will be exposed to user
space, so let's get a little more strict about malformed
papr_sysparm_buf objects.
* Create accessors for the length field of struct papr_sysparm_buf.
The length is always stored in MSB order and this is
From: Nathan Lynch
Add a convenience macro for iterating over every element of the
internal function table and convert the one site that can use it. An
additional user of the macro is anticipated in changes to follow.
Reviewed-by: Aneesh Kumar K.V (IBM)
Signed-off-by: Nathan Lynch
---
Hi Christoph,
On 2023-11-22 2:40 AM, Christoph Hellwig wrote:
>> -select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) ||
>> (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
>> +select DRM_AMD_DC_FP if ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG
>> +select DRM_AMD_DC_FP if PPC64
From: Nathan Lynch
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS
Christophe Leroy writes:
> Le 31/03/2023 à 12:53, Michael Ellerman a écrit :
>> "Daniel Kolesa" writes:
>>> Commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
>>> introduced this check as a workaround for the driver not building
>>> with toolchains that default to 64-bit long
From: Nathan Lynch
Until now the papr_sysparm APIs have been kernel-internal. But user
space needs access to PAPR system parameters too. The only method
available to user space today to get or set system parameters is using
sys_rtas() and /dev/mem to pass RTAS-addressable buffers between user
From: Nathan Lynch
The rtas system call handler sys_rtas() delegates certain input
validation steps to a helper function: block_rtas_call(). One of these
steps ensures that the user-supplied token value maps to a known RTAS
function. This is done by performing a "reverse" token-to-function
Vaibhav Jain writes:
> From: Jordan Niethe
>
> An L0 must invalidate the L2's RPT during H_GUEST_DELETE if this has not
> already been done. This is a slow operation that means H_GUEST_DELETE
> must return H_BUSY multiple times before completing. Invalidating the
> tables before deleting the
On Tue 05-12-23 21:22:59, Yury Norov wrote:
> On Mon, Dec 04, 2023 at 07:51:01PM +0100, Jan Kara wrote:
> > > This series is a result of discussion [1]. All find_bit() functions imply
> > > exclusive access to the bitmaps. However, KCSAN reports quite a number
> > > of warnings related to
Le 07/12/2023 à 13:02, Andy Shevchenko a écrit :
> On Thu, Dec 7, 2023 at 1:23 AM George Stark wrote:
>> On 12/7/23 01:37, Christophe Leroy wrote:
>>> Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
>
> ...
>
>>> Looking at it closer, I have the feeling that you want to do similar to
>>>
Le 07/12/2023 à 12:59, Andy Shevchenko a écrit :
> On Thu, Dec 7, 2023 at 1:23 AM George Stark wrote:
>> On 12/7/23 01:37, Christophe Leroy wrote:
>>> Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
Le 06/12/2023 à 19:58, George Stark a écrit :
> On 12/6/23 18:01, Hans de Goede
On Thu, 30 Nov 2023 00:19:15 +1100, Michael Ellerman wrote:
> With HIBERNATION=y the build breaks with:
>
> arch/powerpc/kernel/swsusp_64.c:14:6: error: no previous prototype for
> ‘do_after_copyback’ [-Werror=missing-prototypes]
> 14 | void do_after_copyback(void)
> |
On Tue, 21 Nov 2023 10:54:36 +1100, Michael Ellerman wrote:
> Building with GCC 13 (which has -array-bounds enabled) there are several
> warnings in sstep.c along the lines of:
>
> In function ‘do_byte_reverse’,
> inlined from ‘do_vec_load’ at arch/powerpc/lib/sstep.c:691:3,
>
On Mon, 13 Nov 2023 16:19:29 +1100, Michael Ellerman wrote:
> The call to grackle_set_stg() ("Store Gathering") has always been inside
> an #ifdef 0, since the code was first merged in v2.3.43pre7.
>
> Apparently it was suspected of causing problems on some hardware so was
> disabled. No one has
On Tue, 24 Oct 2023 22:27:25 +1100, Michael Ellerman wrote:
> Enable CONFIG_MEM_SOFT_DIRTY to get some test coverage. Distros enable
> it, and it has been broken previously. See commit 66b2ca086210
> ("powerpc/64s/radix: Fix soft dirty tracking").
>
>
Applied to powerpc/next.
[1/1]
On Mon, 06 Nov 2023 07:42:52 -0600, Nathan Lynch wrote:
> * Fix recently introduced kernel-doc warnings.
> * Make minor coding style adjustments for readability.
> * Remove rtas_service_present() and an old call_rtas() declaration.
> * Move a pseries-specific function prototype to pseries code.
>
On Mon, 27 Nov 2023 18:40:09 -0600, Nathan Lynch wrote:
> The rtas_read_config() and rtas_write_config() functions in
> kernel/rtas_pci.c have external linkage and two users in arch/powerpc:
> the rtas_pci code itself and the pseries platform's "enhanced error
> handling" (EEH) support code.
>
>
On Thu, Dec 7, 2023 at 2:31 PM Christophe Leroy
wrote:
> Le 07/12/2023 à 12:59, Andy Shevchenko a écrit :
> > On Thu, Dec 7, 2023 at 1:23 AM George Stark
> > wrote:
> >> On 12/7/23 01:37, Christophe Leroy wrote:
> >>> Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
> Le 06/12/2023 à
On 12/7/23 15:28, Christophe Leroy wrote:
Le 07/12/2023 à 13:02, Andy Shevchenko a écrit :
On Thu, Dec 7, 2023 at 1:23 AM George Stark wrote:
On 12/7/23 01:37, Christophe Leroy wrote:
Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
...
Looking at it closer, I have the feeling that
On Thu, 23 Nov 2023 12:47:05 +0530, Naveen N Rao wrote:
> Some of the fp/vmx code in sstep.c assume a certain maximum size for the
> instructions being emulated. The size of those operations however is
> determined separately in analyse_instr().
>
> Add a check to validate the assumption on the
Le 07/12/2023 à 13:51, George Stark a écrit :
>
>
> On 12/7/23 15:28, Christophe Leroy wrote:
>>
>>
>> Le 07/12/2023 à 13:02, Andy Shevchenko a écrit :
>>> On Thu, Dec 7, 2023 at 1:23 AM George Stark
>>> wrote:
On 12/7/23 01:37, Christophe Leroy wrote:
> Le 06/12/2023 à 23:14,
On Thu, Dec 7, 2023 at 1:23 AM George Stark wrote:
> On 12/7/23 01:37, Christophe Leroy wrote:
> > Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
> >> Le 06/12/2023 à 19:58, George Stark a écrit :
> >>> On 12/6/23 18:01, Hans de Goede wrote:
> On 12/4/23 19:05, George Stark wrote:
...
>
On Tue, 21 Nov 2023 08:23:32 +0900, Masahiro Yamada wrote:
> crtsavres.o is linked to modules. However, as explained in commit
> d0e628cd817f ("kbuild: doc: clarify the difference between extra-y
> and always-y"), 'make modules' does not build extra-y.
>
> For example, the following command
On Thu, 30 Nov 2023 22:44:32 +1100, Michael Ellerman wrote:
> With NUMA=n and FA_DUMP=y or PRESERVE_FA_DUMP=y the build fails with:
>
> arch/powerpc/kernel/fadump.c:1739:22: error: no previous prototype for
> ‘arch_reserved_kernel_pages’ [-Werror=missing-prototypes]
> 1739 | unsigned long
On Wed, 29 Nov 2023 15:58:45 +0800, Zhao Ke wrote:
> HeXin Tech Co. has applied for a new PVN from the OpenPower Community
> for its new processor C2000. The OpenPower has assigned a new PVN
> and this newly assigned PVN is 0x0066, add pvr register related
> support for this PVN.
>
>
Applied to
On Mon, 13 Nov 2023 09:45:33 +0800, Li zeming wrote:
> The link pointer does not need to cast the type.
>
>
Applied to powerpc/next.
[1/1] misc: ocxl: link: Remove unnecessary (void*) conversions
https://git.kernel.org/powerpc/c/220f3ced8e42b1efe9c6b84778fb0c77c0c56611
cheers
On Mon, 13 Nov 2023 09:15:43 +0800, Li zeming wrote:
> The ctx pointer does not need to cast the type.
>
>
Applied to powerpc/next.
[1/1] misc: ocxl: context: Remove unnecessary (void*) conversions
https://git.kernel.org/powerpc/c/82d30723d58fccbd2d7d707fab7649b541fafa1b
cheers
On Thu, 30 Nov 2023 12:29:47 +0530, Naveen N Rao wrote:
> Commit 41a506ef71eb ("powerpc/ftrace: Create a dummy stackframe to fix
> stack unwind") added use of a new stack frame on ftrace entry to fix
> stack unwind. However, the commit missed updating the offset used while
> tearing down the
On 12/7/23 16:01, Christophe Leroy wrote:
Le 07/12/2023 à 13:51, George Stark a écrit :
On 12/7/23 15:28, Christophe Leroy wrote:
Le 07/12/2023 à 13:02, Andy Shevchenko a écrit :
On Thu, Dec 7, 2023 at 1:23 AM George Stark
wrote:
On 12/7/23 01:37, Christophe Leroy wrote:
Le
On Thu, Dec 7, 2023 at 1:23 AM George Stark wrote:
> On 12/7/23 01:37, Christophe Leroy wrote:
> > Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
...
> > Looking at it closer, I have the feeling that you want to do similar to
> > devm_gpio_request() in linux/gpio.h :
> >
> > In
On Mon, 13 Nov 2023 09:52:29 +0800, Li kunyu wrote:
> rc is assigned first, so it does not need to initialize the assignment.
>
>
Applied to powerpc/next.
[1/1] misc: ocxl: main: Remove unnecessary ‘0’ values from rc
On Fri, 24 Nov 2023 11:02:37 +0100, Dario Binacchi wrote:
> s/singals/signals/
>
>
Applied to powerpc/next.
[1/1] powerpc/85xx: Fix typo in code comment
https://git.kernel.org/powerpc/c/a9e1e4d6e8c77c732e8084b03bae0c78cafdceb0
cheers
On Wed, 22 Nov 2023 11:06:51 +0800, Kunwu Chan wrote:
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
>
>
Applied to powerpc/next.
[1/1] powerpc/xics: Check return value
On Tue, 14 Nov 2023 11:01:52 -0600, Nathan Lynch wrote:
> This includes a fix for an array bounds read overrun that can be
> triggered when debug messages are enabled.
>
Patches 1 and 3 applied to powerpc/next.
[1/3] powerpc/pseries/memhp: Fix access beyond end of drmem array
On Wed, 25 Oct 2023 12:24:52 +1100, Michael Ellerman wrote:
> The cpu_spec is a struct holding various information about the CPU the
> kernel is executing on. It's populated early in boot and must not change
> after that.
>
> In particular the cpu_features and mmu_features hold the set of
>
On Mon, 13 Nov 2023 15:39:47 +1100, Michael Ellerman wrote:
> Commit fb5a515704d7 ("powerpc: Remove platforms/wsp and associated
> pieces") removed the A2 CPU support, but missed removal of reg_a2.h.
>
> None of the defines contained in it are used, with the exception of the
> SPRN_TEN* values,
On Mon, 13 Nov 2023 09:22:02 +0800, Li zeming wrote:
> The irq pointer does not need to cast the type.
>
>
Applied to powerpc/next.
[1/1] misc: ocxl: afu_irq: Remove unnecessary (void*) conversions
https://git.kernel.org/powerpc/c/84ba5d3675e23e6fa824a2268c5b6a04b52dde4d
cheers
On Thu, 30 Nov 2023 21:51:59 -0800, Randy Dunlap wrote:
> Fix build errors when CURRITUCK=y and I2C is not builtin (=m or is
> not set). Fixes these build errors:
>
> powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function
> `avr_halt_system':
> ppc476.c:(.text+0x58): undefined
Le 31/03/2023 à 12:53, Michael Ellerman a écrit :
> "Daniel Kolesa" writes:
>> Commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
>> introduced this check as a workaround for the driver not building
>> with toolchains that default to 64-bit long double.
> ...
>> In mainline,
The preventive sfence.vma were emitted because new mappings must be made
visible to the page table walker, either the uarch caches invalid
entries or not.
Actually, there is no need to preventively sfence.vma on new mappings for
userspace, this should be handled only in the page fault path.
This
This is useful for testing/benchmarking.
Signed-off-by: Alexandre Ghiti
---
arch/riscv/include/asm/pgtable.h | 6 --
arch/riscv/include/asm/tlbflush.h | 4
arch/riscv/kernel/sbi.c | 12
arch/riscv/mm/tlbflush.c | 17 +
4 files changed,
Le 07/12/2023 à 16:03, Alexandre Ghiti a écrit :
> In 6.5, we removed the vmalloc fault path because that can't work (see
> [1] [2]). Then in order to make sure that new page table entries were
> seen by the page table walker, we had to preventively emit a sfence.vma
> on all harts [3] but this
In RISC-V, after a new mapping is established, a sfence.vma needs to be
emitted for different reasons:
- if the uarch caches invalid entries, we need to invalidate it otherwise
we would trap on this invalid entry,
- if the uarch does not cache invalid entries, a reordered access could fail
to
In 6.5, we removed the vmalloc fault path because that can't work (see
[1] [2]). Then in order to make sure that new page table entries were
seen by the page table walker, we had to preventively emit a sfence.vma
on all harts [3] but this solution is very costly since it relies on IPI.
And even
This mechanism allows to completely bypass the sfence.vma introduced by
the previous commit for uarchs that do not cache invalid TLB entries.
Signed-off-by: Alexandre Ghiti
---
arch/riscv/mm/init.c | 124 +++
1 file changed, 124 insertions(+)
diff --git
Le 07/12/2023 à 16:03, Alexandre Ghiti a écrit :
> This mechanism allows to completely bypass the sfence.vma introduced by
> the previous commit for uarchs that do not cache invalid TLB entries.
>
> Signed-off-by: Alexandre Ghiti
> ---
> arch/riscv/mm/init.c | 124
On Wed, Dec 06, 2023, Jim Mattson wrote:
> kvm_vcpu_check_block() is called while not in TASK_RUNNING, and therefore
> it cannot sleep. Writing to guest memory is therefore forbidden, but it
> can happen on AMD processors if kvm_check_nested_events() causes a vmexit.
>
> Fortunately, all events
The subject says "riscv:" but it changes core part and several arch.
Maybe this commit should be split in two commits, one for API changes
that changes flush_tlb_fix_spurious_fault() to
flush_tlb_fix_spurious_write_fault() and adds
flush_tlb_fix_spurious_read_fault() including the change in
76 matches
Mail list logo
