From: Nathan Lynch
Allocate one identifying code (the first column of the ioctl-number
table) for the collection of PAPR miscdev drivers to share.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/uapi/asm/papr-miscdev.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powe
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 a
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 A
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
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 ver
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 be
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
spa
From: Nathan Lynch
Take the papr-vpd driver's internal mutex when sys_rtas performs
ibm,get-vpd calls. This prevents sys_rtas(ibm,get-vpd) calls from
interleaving with sequences performed by the driver, ensuring that
such sequences are not disrupted.
However, it cannot prevent the driver from in
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 A
From: Nathan Lynch
Take the papr-vpd driver's internal mutex when sys_rtas performs
ibm,get-vpd calls. This prevents sys_rtas(ibm,get-vpd) calls from
interleaving with sequences performed by the driver, ensuring that
such sequences are not disrupted.
However, it cannot prevent the driver from in
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 ver
From: Nathan Lynch
Allocate one identifying code (the first column of the ioctl-number
table) for the collection of PAPR miscdev drivers to share.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/uapi/asm/papr-miscdev.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powe
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 be
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
spa
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 a
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
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
spa
From: Nathan Lynch
Allocate one identifying code (the first column of the ioctl-number
table) for the collection of PAPR miscdev drivers to share.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/uapi/asm/papr-miscdev.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powe
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 be
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 functions
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 ver
From: Nathan Lynch
Move the function descriptor table lookup out of rtas_function_token()
into a separate routine for use in new code to follow. No functional
change.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 31 +++
1 file changed, 19 insertions(
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 A
From: Nathan Lynch
Use the function lock API 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
no advantag
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 a
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
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
From: Nathan Lynch
>From a W=1 build:
>> arch/powerpc/kernel/rtas-proc.c:771: warning: Function parameter or member
>> 'm' not described in
>> 'ppc_rtas_rmo_buf_show'
>> arch/powerpc/kernel/rtas-proc.c:771: warning: Function parameter or member
>> 'v' not described in
>> 'ppc_rtas_rmo_buf_show
From: Nathan Lynch
This header occasionally gains new function declarations without the
leading extern in accordance with current style rules. Leaving the
legacy externs in place is making the header more difficult to read
over time because of the inconsistency. Remove them.
Signed-off-by: Natha
From: Nathan Lynch
>From a W=1 build:
>> arch/powerpc/platforms/pseries/rtas-work-area.c:189: warning: Function
>> parameter or member 'limit' not
>> described in 'rtas_work_area_reserve_arena'
Add the missing description of the limit parameter.
Signed-off-by: Nathan Lynch
Reported-by: kerne
From: Nathan Lynch
rtas_service_present() has no more users.
rtas_function_implemented() is now the appropriate API for determining
whether a given RTAS function is available to call.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 1 -
arch/powerpc/kernel/rtas.c | 5 --
From: Nathan Lynch
Use scripts/cleanfile to remove instances of trailing space in the
core RTAS code and header.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 6 +++---
arch/powerpc/kernel/rtas.c | 18 +-
2 files changed, 12 insertions(+), 12 deletions
* 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.
---
Nathan Lynch (7):
powerpc/pseries/rtas-work-area: Fix rt
From: Nathan Lynch
The call_rtas() function has never been a part of arch/powerpc, and
its implementation was removed from arch/ppc by 0a26b1364f14 ("ppc:
Remove CHRP, POWER3 and POWER4 support from arch/ppc").
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 2 --
1 file chan
From: Nathan Lynch
This is a pseries-specific function declaration that doesn't belong in
rtas.h. Move it to the pseries platform code and adjust
pseries/suspend.c accordingly.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 1 -
arch/powerpc/platforms/pseries/pserie
From: Nathan Lynch
Callers of dlpar_add_lmb() are responsible for first acquiring the DRC
and releasing it if dlpar_add_lmb() fails.
However, dlpar_add_lmb() performs a dlpar_release_drc() in one error
branch. There is no corresponding dlpar_acquire_drc() in the
function, nor is there any state
From: Nathan Lynch
dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
la
From: Nathan Lynch
When an add operation for multiple LMBs fails, there is currently
little indication from the kernel of what went wrong. Be a little more
verbose about error conditions in the add paths.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 7 +
This includes a fix for an array bounds read overrun that can be
triggered when debug messages are enabled.
---
Nathan Lynch (3):
powerpc/pseries/memhp: Fix access beyond end of drmem array
powerpc/pseries/memhp: Remove unbalanced dlpar_release_drc() call
powerpc/pseries/memhp: L
From: Nathan Lynch
Use scripts/cleanfile to remove instances of trailing space in the
core RTAS code and header.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 6 +++---
arch/powerpc/kernel/rtas.c | 18 +-
2 files changed, 12 insertions(+), 12 deletions
From: Nathan Lynch
The call_rtas() function has never been a part of arch/powerpc, and
its implementation was removed from arch/ppc by commit 0a26b1364f14
("ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc").
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 2 --
1 fi
* 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.
---
Changes in v2:
- Address various checkpatch issues missed in v1.
- Drop kernel-doc fixes already applied.
- C
From: Nathan Lynch
This is a pseries-specific function declaration that doesn't belong in
rtas.h. Move it to the pseries platform code and adjust
pseries/suspend.c accordingly.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 1 -
arch/powerpc/platforms/pseries/pserie
From: Nathan Lynch
This header occasionally gains new function declarations without the
leading extern in accordance with current style rules. Leaving the
legacy externs in place is making the header more difficult to read
over time because of the inconsistency. Remove them, fixing up
checkpatch
From: Nathan Lynch
rtas_service_present() has no more users.
rtas_function_implemented() is now the appropriate API for determining
whether a given RTAS function is available to call.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/asm/rtas.h | 1 -
arch/powerpc/kernel/rtas.c | 5 --
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
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 be
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.
Signed-off-by: Nathan Lynch
---
arch/powerp
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 functions
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 A
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.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 9 +++--
1
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
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 ver
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
spa
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 a
From: Nathan Lynch
Use the function lock API 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
no advantag
From: Nathan Lynch
Allocate one identifying code (the first column of the ioctl-number
table) for the collection of PAPR miscdev drivers to share.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/uapi/asm/papr-miscdev.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powe
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
Move the function descriptor table lookup out of rtas_function_token()
into a separate routine for use in new code to follow. No functional
change.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 31 +++
1 file changed, 19 insertions(
From: Nathan Lynch
With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the
/proc/powerpc/rtas/firmware_update interface to prepare a system
firmware update yields a BUG():
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR
From: Nathan Lynch
With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the
/proc/powerpc/rtas/firmware_update interface to prepare a system
firmware update yields a BUG():
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR
Just some minor things to tidy up I noticed when adding tests.
---
Nathan Lynch (2):
powerpc/selftests: sort mm/.gitignore, add exec_prot
selftests/powerpc: add const qualification where possible
tools/testing/selftests/powerpc/harness.c | 4 ++--
tools/testing/selftests/pow
From: Nathan Lynch
Add exec_prot to to mm/.gitignore and sort the result.
Signed-off-by: Nathan Lynch
---
tools/testing/selftests/powerpc/mm/.gitignore | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/powerpc/mm/.gitignore
b/tools/t
From: Nathan Lynch
Various char * parameters in the common powerpc selftest APIs can be
const.
Signed-off-by: Nathan Lynch
---
tools/testing/selftests/powerpc/harness.c | 4 ++--
tools/testing/selftests/powerpc/include/subunit.h | 16
tools/testing/selftests/powerpc/i
This is a proposal for adding chardev-based access to a select subset
of RTAS functions on the pseries platform.
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
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 ver
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 a
From: Nathan Lynch
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.
The prototypes for these functions in asm/ppc-pc
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 functions
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)
Signed-o
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
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 be
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
---
arch/po
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
sy
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 n
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
spa
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
lookup
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
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 A
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
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 ver
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 a
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
lookup
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 n
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
sy
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 A
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
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)
Signed-o
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
---
arch/po
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
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 a
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 be
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 functions
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
spa
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 ver
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
From: Nathan Lynch
It's not an error or exceptional situation when the hosting
environment does not expose a name for the LP/guest via RTAS or the
device tree. This happens with qemu when run without the '-name'
option. The message also lacks a newline. Remove it.
Signed-off-by: Nathan Lynch
--
From: Nathan Lynch
Although the H_PAGE_INIT hcall's H_PAGE_SET_UNUSED historically has
been tied to the cooperative memory overcommit (CMO) platform feature,
the flag also is treated by the PowerVM hypervisor as a hint that the
page contents need not be copied to the destination during a live
par
From: Nathan Lynch
The static hardware description buffer is populated by arch code
during boot and should not change afterwards, so mark it
__ro_after_init.
Signed-off-by: Nathan Lynch
---
lib/dump_stack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/dump_stack.c
From: Nathan Lynch
pseries_add_hw_description() will be used after boot to update the
hardware description string emitted in stack dumps. Remove the __init
and make it take a seq_buf * parameter instead of referencing
ppc_hw_desc directly.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms
1 - 100 of 123 matches
Mail list logo
