en so a WARN_ON(!machine_id) should be
enough, the developper that hits it is able to go to the given file:line
and understand what happened.
> + machine_id == _##name; \
> })
>
> static inline void log_error(char *buf, unsigned int err_type,
Hello:
This series was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Wed, 8 Feb 2023 23:13:36 -0800 you wrote:
> Correct many spelling errors in Documentation/ as reported by codespell.
>
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches,
From: Masahiro Yamada
commit a494398bde273143c2352dd373cad8211f7d94b2 upstream.
Nathan Chancellor reports that the s390 vmlinux fails to link with
GNU ld < 2.36 since commit 99cb0d917ffa ("arch: fix broken BuildID
for arm64 and riscv").
It happens for defconfig, or more specifically for
From: Masahiro Yamada
commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
In the previous discussion (see the Link tag), Ard pointed out that
arm/arm64/kernel/head.o does not need any special treatment - the only
piece that must appear right at the start of the binary image is the
image
From: Masahiro Yamada
commit a494398bde273143c2352dd373cad8211f7d94b2 upstream.
Nathan Chancellor reports that the s390 vmlinux fails to link with
GNU ld < 2.36 since commit 99cb0d917ffa ("arch: fix broken BuildID
for arm64 and riscv").
It happens for defconfig, or more specifically for
commit c1c551bebf928889e7a8fef7415b44f9a64975f4 upstream.
sh vmlinux fails to link with GNU ld < 2.40 (likely < 2.36) since
commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv").
This is similar to fixes for powerpc and s390:
commit 4b9880dbf3bd ("powerpc/vmlinux.lds: Define
From: Michael Ellerman
commit 07b050f9290ee012a407a0f64151db902a1520f5 upstream.
Relocatable kernels must not discard relocations, they need to be
processed at runtime. As such they are included for CONFIG_RELOCATABLE
builds in the powerpc linker script (line 340).
However they are also
From: Michael Ellerman
commit 4b9880dbf3bdba3a7c56445137c3d0e30aaa0a40 upstream.
The powerpc linker script explicitly includes .exit.text, because
otherwise the link fails due to references from __bug_table and
__ex_table. The code is freed (discarded) at runtime along with
.init.text and data.
From: Masahiro Yamada
commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux
since commit 994b7ac1697b ("arm64: remove special treatment for the
link order of head.o").
The issue is that the type of .notes section,
.lds.S| 2 ++
arch/sh/kernel/vmlinux.lds.S | 1 +
arch/x86/kernel/vmlinux.lds.S | 1 +
include/asm-generic/vmlinux.lds.h | 16 ++--
5 files changed, 23 insertions(+), 3 deletions(-)
---
base-commit: 59342376e8f0c704299dc7a2c14fed07ffb962e2
change-id: 20230210-tsaeger
From: "H.J. Lu"
commit 84d5f77fc2ee4e010c2c037750e32f06e55224b0 upstream.
In the x86 kernel, .exit.text and .exit.data sections are discarded at
runtime, not by the linker. Add RUNTIME_DISCARD_EXIT to generic DISCARDS
and define it in the x86 kernel linker script to keep them.
The sections are
From: Masahiro Yamada
commit a494398bde273143c2352dd373cad8211f7d94b2 upstream.
Nathan Chancellor reports that the s390 vmlinux fails to link with
GNU ld < 2.36 since commit 99cb0d917ffa ("arch: fix broken BuildID
for arm64 and riscv").
It happens for defconfig, or more specifically for
commit c1c551bebf928889e7a8fef7415b44f9a64975f4 upstream.
sh vmlinux fails to link with GNU ld < 2.40 (likely < 2.36) since
commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv").
This is similar to fixes for powerpc and s390:
commit 4b9880dbf3bd ("powerpc/vmlinux.lds: Define
From: Michael Ellerman
commit 07b050f9290ee012a407a0f64151db902a1520f5 upstream.
Relocatable kernels must not discard relocations, they need to be
processed at runtime. As such they are included for CONFIG_RELOCATABLE
builds in the powerpc linker script (line 340).
However they are also
x.lds.h | 5 +
4 files changed, 13 insertions(+), 1 deletion(-)
---
base-commit: a5acb54d4066f27e9707af9d93f047f542d5ad88
change-id: 20230210-tsaeger-upstream-linux-5-10-y-e443820440f6
Best regards,
--
Tom Saeger
From: Michael Ellerman
commit 4b9880dbf3bdba3a7c56445137c3d0e30aaa0a40 upstream.
The powerpc linker script explicitly includes .exit.text, because
otherwise the link fails due to references from __bug_table and
__ex_table. The code is freed (discarded) at runtime along with
.init.text and data.
From: Masahiro Yamada
commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux
since commit 994b7ac1697b ("arm64: remove special treatment for the
link order of head.o").
The issue is that the type of .notes section,
commit c1c551bebf928889e7a8fef7415b44f9a64975f4 upstream.
sh vmlinux fails to link with GNU ld < 2.40 (likely < 2.36) since
commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv").
This is similar to fixes for powerpc and s390:
commit 4b9880dbf3bd ("powerpc/vmlinux.lds: Define
From: Masahiro Yamada
commit a494398bde273143c2352dd373cad8211f7d94b2 upstream.
Nathan Chancellor reports that the s390 vmlinux fails to link with
GNU ld < 2.36 since commit 99cb0d917ffa ("arch: fix broken BuildID
for arm64 and riscv").
It happens for defconfig, or more specifically for
From: Michael Ellerman
commit 07b050f9290ee012a407a0f64151db902a1520f5 upstream.
Relocatable kernels must not discard relocations, they need to be
processed at runtime. As such they are included for CONFIG_RELOCATABLE
builds in the powerpc linker script (line 340).
However they are also
From: Michael Ellerman
commit 4b9880dbf3bdba3a7c56445137c3d0e30aaa0a40 upstream.
The powerpc linker script explicitly includes .exit.text, because
otherwise the link fails due to references from __bug_table and
__ex_table. The code is freed (discarded) at runtime along with
.init.text and data.
x.lds.h | 5 +
4 files changed, 13 insertions(+), 1 deletion(-)
---
base-commit: 85d7786c66b69d3f07cc149ac2f78d8f330c7c11
change-id: 20230210-tsaeger-upstream-linux-stable-5-15-f7bf45952c23
Best regards,
--
Tom Saeger
From: Masahiro Yamada
commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux
since commit 994b7ac1697b ("arm64: remove special treatment for the
link order of head.o").
The issue is that the type of .notes section,
commit c1c551bebf928889e7a8fef7415b44f9a64975f4 upstream.
sh vmlinux fails to link with GNU ld < 2.40 (likely < 2.36) since
commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv").
This is similar to fixes for powerpc and s390:
commit 4b9880dbf3bd ("powerpc/vmlinux.lds: Define
From: Michael Ellerman
commit 07b050f9290ee012a407a0f64151db902a1520f5 upstream.
Relocatable kernels must not discard relocations, they need to be
processed at runtime. As such they are included for CONFIG_RELOCATABLE
builds in the powerpc linker script (line 340).
However they are also
From: Michael Ellerman
commit 4b9880dbf3bdba3a7c56445137c3d0e30aaa0a40 upstream.
The powerpc linker script explicitly includes .exit.text, because
otherwise the link fails due to references from __bug_table and
__ex_table. The code is freed (discarded) at runtime along with
.init.text and data.
), 3 deletions(-)
---
base-commit: d60c95efffe84428e3611431bf688f50bfc13f4e
change-id: 20230210-tsaeger-upstream-linux-6-1-y-06c93fbe5bc8
Best regards,
--
Tom Saeger
From: Masahiro Yamada
commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux
since commit 994b7ac1697b ("arm64: remove special treatment for the
link order of head.o").
The issue is that the type of .notes section,
From: Jisheng Zhang
commit 2348e6bf44213c5f447ff698e43c089185241ed7 upstream.
arch/riscv/kernel/head.o does not need any special treatment - the only
requirement is the ".head.text" section must be placed before the
normal ".text" section.
The linker script does the right thing to do. The
Reviewed-by: Alok Tiwari
On 2/9/2023 8:40 PM, Frank Li wrote:
From: Xiaowei Bao
Add PCIe EP mode support for ls1028a.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
Signed-off-by: Frank Li
Acked-by: Roy Zang
---
Change from v2 to v3
order by .compatible
Change from v2 to v2
During GQSPI driver probe set ctlr->multi-cs-cap for enabling multi CS
capability of the controller. In parallel mode the controller can either
split the data between both the flash or can send the same data to both the
flashes, this is determined by the STRIPE bit. While sending commands to
the
The current implementation assumes that a maximum of two flashes are
connected in parallel mode. The QSPI controller splits the data evenly
between both the flashes so, both the flashes that are connected in
parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 &
GQSPI supports two chip select CS0 & CS1. Update the driver to
assert/de-assert the appropriate chip select as per the bits set in
qspi->cs_index_mask.
Signed-off-by: Amit Kumar Mahapatra
---
drivers/spi/spi-zynqmp-gqspi.c | 21 +
1 file changed, 13 insertions(+), 8
Each flash that is connected in stacked mode should have a separate
parameter structure. So, the flash parameter member(*params) of the spi_nor
structure is changed to an array (*params[2]). The array is used to store
the parameters of each flash connected in stacked configuration.
The current
Supporting multi-cs in spi-nor would require the *params member of
struct spi_nor to be an array. To make the transition smoother introduced
spi_nor_get_params() & spi_nor_set_params() APIs to get & set nor->params,
added a new local variable (struct spi_nor_flash_parameter *params) to hold
the
In further patches the nor->params references in
spi_nor_otp_region_len(nor) & spi_nor_otp_n_regions(nor) macros will be
replaced with spi_nor_get_params() API. To make the transition smoother,
first converting the macros into static inline functions.
Suggested-by: Michal Simek
Signed-off-by:
For supporting multiple CS the SPI device need to be aware of all the CS
values. So, the "chip_select" member in the spi_device structure is now an
array that holds all the CS values.
spi_device structure now has a "cs_index_mask" member. This acts as an
index to the chip_select array. If nth bit
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
This patch is in the continuation to the discussions which happened on
'commit f89504300e94 ("spi: Stacked/parallel memories bindings")' for
adding dt-binding support for stacked/parallel memories.
This patch series updated the spi-nor, spi core and the spi drivers
to add stacked and parallel
-20230210
arm allmodconfig
arm allyesconfig
arm defconfig
arm randconfig-r046-20230210
arm64allyesconfig
arm64 defconfig
csky
may be tested in the coming days.
gcc tested configs:
alphaallyesconfig
alpha defconfig
arc allyesconfig
arc defconfig
arc randconfig-r043-20230210
arm
On 2/3/23 18:06, Shuah Khan wrote:
On 2/1/23 19:07, Shuah Khan wrote:
Hi Mathieu,
On 1/30/23 15:29, Shuah Khan wrote:
On 1/27/23 06:57, Mathieu Desnoyers wrote:
Hi,
This series fixes incorrect kernel header search path in kernel
selftests.
Near the end of the series, a few changes are not
== _##name; \
})
static inline void log_error(char *buf, unsigned int err_type, int fatal)
---
base-commit: 0bfb97203f5f300777624a2ad6f8f84aea3e8658
change-id: 20230210-warn-on-machine-is-before-probe-machine-37515b1f43bb
Best regards,
--
Nathan Lynch
The CXL driver expects internal error reporting to be enabled via
pci_enable_pcie_error_reporting(). It is likely other drivers expect the same.
Dave submitted a patch to enable the CXL side[1] but the PCI AER registers
still mask errors.
PCIe v6.0 Uncorrectable Mask Register (7.8.4.3) and
On 2/10/23 16:23, Stefan Berger wrote:
+
+// PLPKS dynamic secure boot doesn't give us a format string in the same way
OPAL does.
+// Instead, report the format using the SB_VERSION variable in the keystore.
+// The string is made up by us, and takes the form "ibm,plpks-sb-v" (or
On 2/10/23 03:03, Andrew Donnellan wrote:
From: Russell Currey
The pseries platform can support dynamic secure boot (i.e. secure boot
using user-defined keys) using variables contained with the PowerVM LPAR
Platform KeyStore (PLPKS). Using the powerpc secvar API, expose the
relevant
On 2/10/23 03:03, Andrew Donnellan wrote:
From: Russell Currey
Before interacting with the PLPKS, we ask the hypervisor to generate a
password for the current boot, which is then required for most further
PLPKS operations.
If we kexec into a new kernel, the new kernel will try and fail to
On 2/10/23 03:03, Andrew Donnellan wrote:
From: Russell Currey
The secvar code only supports one consumer at a time.
Multiple consumers aren't possible at this point in time, but we'd want
it to be obvious if it ever could happen.
Signed-off-by: Russell Currey
Co-developed-by: Andrew
On 2/10/23 03:03, Andrew Donnellan wrote:
When the H_PKS_GEN_PASSWORD hcall returns H_IN_USE, operations that require
authentication (i.e. anything other than reading a world-readable variable)
will not work.
The current error message doesn't explain this clearly enough. Reword it
to
Reviewed-by: Alok Tiwari
On 2/9/2023 8:40 PM, Frank Li wrote:
From: Xiaowei Bao
Add PCIe EP mode support for ls1028a.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
Signed-off-by: Frank Li
Acked-by: Roy Zang
---
Change from v2 to v3
order by .compatible
Change from v2 to v2
On Fri, Feb 10, 2023 at 11:51:46PM +0530, ALOK TIWARI wrote:
> LGTM,
Thanks a lot for looking at this!
In the Linux world, "LGTM" is not something a maintainer can really
act on. If you respond with a "Reviewed-by" tag as described here:
From: Nathan Lynch
Various pseries-specific RTAS functions take a temporary "work area"
parameter - a buffer in memory accessible to RTAS. Typically such
functions are passed the statically allocated rtas_data_buf buffer as
the argument. This buffer is protected by a global spinlock. So users
of
From: Nathan Lynch
Convert the TLB block invalidate characteristics discovery to the new
papr_sysparm API. This occurs too early in boot to use
papr_sysparm_buf_alloc(), so use a static buffer.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/lpar.c | 37
From: Nathan Lynch
Convert the direct invocation of the ibm,get-system-parameter RTAS
function to papr_sysparm_get().
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/setup.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git
From: Nathan Lynch
Add two sets of tracepoints to be used around RTAS entry:
* rtas_input/rtas_output, which emit the function name, its inputs,
the returned status, and any other outputs. These produce an API-level
record of OS<->RTAS activity.
* rtas_ll_entry/rtas_ll_exit, which are
From: Nathan Lynch
Make do_enter_rtas() take a pointer to struct rtas_args and do the
__pa() conversion in one place instead of leaving it to callers. This
also makes it possible to introduce enter/exit tracepoints that access
the rtas_args struct fields.
There's no apparent reason to force
From: Nathan Lynch
Introduce a set of APIs for retrieving and updating PAPR system
parameters. This encapsulates the toil of temporary RTAS work area
management, RTAS function call retries, and translation of RTAS call
statuses to conventional error values.
There are several places in the
From: Nathan Lynch
Hold a work area object for the duration of the RTAS
ibm,configure-connector sequence, eliminating locking and copying
around each RTAS call.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/dlpar.c | 27 +--
1 file changed, 9
From: Nathan Lynch
Users of rtas_token() supply a string argument that can't be validated
at build time. A typo or misspelling has to be caught by inspection or
by observing wrong behavior at runtime.
Since the core RTAS code now has consolidated the names of all
possible RTAS functions and
From: Nathan Lynch
Decompose the RTAS entry C code into tracing and non-tracing variants,
calling the just-added tracepoints in the tracing-enabled path. Skip
tracing in contexts known to be unsafe (real mode, CPU offline).
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 59
From: Nathan Lynch
With the tokens for all implemented RTAS functions now available via
rtas_function_token(), which is optimal and safe for arbitrary
contexts, there is no need to use rtas_token() or cache its result.
Most conversions are trivial, but a few are worth describing in more
detail:
From: Nathan Lynch
The new papr_sysparm API handles the details of system parameter
retrieval. Use that instead of open-coding the RTAS call, work area
management, and retries.
Signed-off-by: Nathan Lynch
---
arch/powerpc/perf/hv-24x7.c | 37 +++--
1 file
From: Nathan Lynch
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on
From: Nathan Lynch
/proc/powerpc/lparcfg derives the LPAR name and SPLPAR characteristics
it reports using bare calls to the RTAS ibm,get-system-parameter
function. Convert these to the higher-level papr_sysparm API, which
handles the tedious details.
While the SPLPAR string parsing code could
From: Nathan Lynch
Some RTAS functions that have work area parameters impose alignment
requirements on the work area passed to them by the OS. Examples
include:
- ibm,configure-connector
- ibm,update-nodes
- ibm,update-properties
4KB is the greatest alignment required by PAPR for such
buffers.
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again.
pSeries_cmo_feature_init() ignores this, making it possible to fail to
detect cooperative memory overcommit capabilities during boot.
Move the RTAS call into a
From: Nathan Lynch
The pseries platform has been LPAR-only for several generations, and
the PAPR spec:
* Guarantees that timebase synchronization is performed by
the platform ("The timebase registers are synchronized by the
platform before CPUs are given to the OS" - 7.3.8 SMP Support).
*
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again. read_24x7_sys_info()
ignores this, allowing transient failures in reporting processor
module information.
Move the RTAS call into a coventional
From: Nathan Lynch
Some code that runs early in boot calls RTAS functions that can return
-2 or 990x statuses, which mean the caller should retry. An example is
pSeries_cmo_feature_init(), which invokes ibm,get-system-parameter but
treats these benign statuses as errors instead of retrying.
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again.
pseries_lpar_read_hblkrm_characteristics() ignores this, making it
possible to incorrectly detect TLB block invalidation characteristics
at boot.
Move the RTAS
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again.
lparcfg's parse_system_parameter_string() ignores this, making it
possible to intermittently report incorrect SPLPAR characteristics.
Move the RTAS call into a
Proposed changes for the RTAS subsystem and client code.
Fixes that are subject to backporting are at the front of the queue.
The rest of the queue is roughly ordered with respect to maturity:
i.e. patches that have already garnered some review and discussion
precede newer, more experimental
LGTM,
Thanks,
Alok
On 2/9/2023 8:40 PM, Frank Li wrote:
From: Xiaowei Bao
Add PCIe EP mode support for ls1028a.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
Signed-off-by: Frank Li
Acked-by: Roy Zang
---
Change from v2 to v3
order by .compatible
Change from v2 to v2
Added
Hi Sasha,
On 09/02/23 16:44, Sasha Levin wrote:
From: Sathvika Vasireddy
[ Upstream commit fe6de81b610e5d0b9d2231acff2de74a35482e7d ]
objtool throws the following warning:
arch/powerpc/kvm/booke.o: warning: objtool: kvmppc_fill_pt_regs+0x30:
unannotated intra-function call
Fix the
Hi Sasha,
On 09/02/23 16:44, Sasha Levin wrote:
From: Sathvika Vasireddy
[ Upstream commit 8afffce6aa3bddc940ac1909627ff1e772b6cbf1 ]
objtool throws the following warning:
arch/powerpc/kernel/head_85xx.o: warning: objtool: .head.text+0x1a6c:
unannotated intra-function call
Fix the
It seems a bit unnecessary for the PLPKS code to have a user-visible
config option when it doesn't do anything on its own, and there's existing
options for enabling Secure Boot-related features.
It should be enabled by PPC_SECURE_BOOT, which will eventually be what
uses PLPKS to populate
plpks_confirm_object_flushed() uses the H_PKS_CONFIRM_OBJECT_FLUSHED hcall
to check whether changes to an object in the Platform KeyStore have been
flushed to non-volatile storage.
The hcall returns two output values, the return code and the flush status.
plpks_confirm_object_flushed() polls the
From: Russell Currey
Move plpks.h from platforms/pseries/ to include/asm/. This is necessary
for later patches to make use of the PLPKS from code in other subsystems.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
Reviewed-by: Stefan Berger
---
v3: New patch
---
From: Russell Currey
The pseries platform can support dynamic secure boot (i.e. secure boot
using user-defined keys) using variables contained with the PowerVM LPAR
Platform KeyStore (PLPKS). Using the powerpc secvar API, expose the
relevant variables for pseries dynamic secure boot through the
From: Nayna Jain
The Platform Keystore provides a signed update interface which can be used
to create, replace or append to certain variables in the PKS in a secure
fashion, with the hypervisor requiring that the update be signed using the
Platform Key.
Implement an interface to the
From: Russell Currey
Add support for loading keys from the PLPKS on pseries machines, with the
"ibm,plpks-sb-v1" format.
The object format is expected to be the same, so there shouldn't be any
functional differences between objects retrieved on powernv or pseries.
Unlike on powernv, on pseries
From: Russell Currey
The forthcoming pseries consumer of the secvar API wants to expose a
number of config variables. Allowing secvar implementations to provide
their own sysfs attributes makes it easy for consumers to expose what
they need to.
This is not being used by the OPAL secvar
From: Russell Currey
Add helper function to get the PLPKS password length. This will be used
in a later patch to support passing the password between kernels over
kexec.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
Reviewed-by: Stefan Berger
---
v3: New patch
v5: Drop
Currently, plpks_read_var() allocates a buffer to pass to the
H_PKS_READ_OBJECT hcall, then allocates another buffer into which the data
is copied, and returns that buffer to the caller.
This is a bit over the top - while we probably still want to allocate a
separate buffer to pass to the
From: Russell Currey
Move the constants defined in plpks.c to plpks.h, and standardise their
naming, so that PLPKS consumers can make use of them later on.
Signed-off-by: Russell Currey
Co-developed-by: Andrew Donnellan
Signed-off-by: Andrew Donnellan
Reviewed-by: Stefan Berger
---
v3:
From: Russell Currey
Before interacting with the PLPKS, we ask the hypervisor to generate a
password for the current boot, which is then required for most further
PLPKS operations.
If we kexec into a new kernel, the new kernel will try and fail to
generate a new password, as the password has
From: Russell Currey
A few improvements to load_powerpc.c:
- include integrity.h for the pr_fmt()
- move all error reporting out of get_cert_list()
- use ERR_PTR() to better preserve error detail
- don't use pr_err() for missing keys
Reviewed-by: Mimi Zohar
Signed-off-by: Russell Currey
When the H_PKS_GEN_PASSWORD hcall returns H_IN_USE, operations that require
authentication (i.e. anything other than reading a world-readable variable)
will not work.
The current error message doesn't explain this clearly enough. Reword it
to emphasise that authenticated operations will fail.
From: Nayna Jain
The plpks driver uses the H_PKS_GET_CONFIG hcall to retrieve configuration
and status information about the PKS from the hypervisor.
Update _plpks_get_config() to handle some additional fields. Add getter
functions to allow the PKS configuration information to be accessed from
From: Russell Currey
The plpks code converts hypervisor return codes into their Linux
equivalents so that users can understand them. Having access to the
original return codes is really useful for debugging, so add a
pr_debug() so we don't lose information from the conversion.
Signed-off-by:
If attempting to read the size or data attributes of a non-existent
variable (which will be possible after a later patch to expose the PLPKS
via the secvar interface), don't spam the kernel log with error messages.
Only print errors for return codes that aren't ENOENT.
Reported-by: Sudhakar
Currently, the list of variables is populated by calling
secvar_ops->get_next() repeatedly, which is explicitly modelled on the
OPAL API (including the keylen parameter).
For the upcoming PLPKS backend, we have a static list of variable names.
It is messy to fit that into get_next(), so instead,
Due to sysfs constraints, when writing to a variable, we can only handle
writes of up to PAGE_SIZE.
It's possible that the maximum object size is larger than PAGE_SIZE, in
which case, print a warning on boot so that the user is aware.
Signed-off-by: Andrew Donnellan
Signed-off-by: Russell
1 - 100 of 109 matches
Mail list logo
