[PATCH] powerpc/64: Use -mprofile-kernel for big endian ELFv2 kernels
-mprofile-kernel is an optimised calling convention for mcount that
Linux has only implemented with the ELFv2 ABI, so it was disabled for
big endian kernels. However it does work with ELFv2 big endian, so let's
allow that if the compiler supports it.
Cc: Naveen N. Rao
Suggested-by: Christophe Leroy
Signed-off-by: Nicholas Piggin
---
Christophe had the good idea that we could use -mprofile-kernel for
ELFv2 BE. Unfortunately can't remove -pg due to lack of -mprofile-kernel
in clang, but this gives BE the nicer ftrace code with GCC at least.
Function tracer works for me with a BE kernel.
Thanks,
Nick
arch/powerpc/Kconfig| 6 --
arch/powerpc/tools/gcc-check-mprofile-kernel.sh | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a64bfd9b8a1d..bd2ee7af1342 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -547,8 +547,10 @@ config LD_HEAD_STUB_CATCH
If unsure, say "N".
config MPROFILE_KERNEL
- depends on PPC64 && CPU_LITTLE_ENDIAN && FUNCTION_TRACER
- def_bool
$(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC)
-I$(srctree)/include -D__KERNEL__)
+ depends on PPC64 && FUNCTION_TRACER
+ depends on CPU_LITTLE_ENDIAN || PPC64_BIG_ENDIAN_ELF_ABI_V2
+ def_bool
$(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC)
-mlittle-endian) if CPU_LITTLE_ENDIAN
+ def_bool
$(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC)
-mbig-endian) if CPU_BIG_ENDIAN
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
diff --git a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
index 137f3376ac2b..e78c599251ff 100755
--- a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
+++ b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
@@ -14,13 +14,13 @@ set -o pipefail
# Test whether the compile option -mprofile-kernel exists and generates
# profiling code (ie. a call to _mcount()).
echo "int func() { return 0; }" | \
-$* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+$* -m64 -S -x c -O2 -p -mprofile-kernel - -o - \
2> /dev/null | grep -q "_mcount"
# Test whether the notrace attribute correctly suppresses calls to _mcount().
echo -e "#include \nnotrace int func() { return 0; }" | \
-$* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+$* -m64 -S -x c -O2 -p -mprofile-kernel - -o - \
2> /dev/null | grep -q "_mcount" && \
exit 1
--
2.40.1
[PATCH] powerpc/embedded6xx: select MPC10X_BRIDGE only if PCI is set
When CONFIG_SMP is not set, CONFIG_BROKEN_ON_SMP is set, and CONFIG_PCI is not set, there can be a kconfig warning: WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI Depends on [n]: PCI [=n] Selected by [y]: - MPC10X_BRIDGE [=y] To fix that, make the selects of MPC10X_BRIDGE be conditional on PCI. Signed-off-by: Randy Dunlap Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/platforms/embedded6xx/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -- a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig --- a/arch/powerpc/platforms/embedded6xx/Kconfig +++ b/arch/powerpc/platforms/embedded6xx/Kconfig @@ -10,7 +10,7 @@ config LINKSTATION select FSL_SOC select PPC_UDBG_16550 if SERIAL_8250 select DEFAULT_UIMAGE - select MPC10X_BRIDGE + select MPC10X_BRIDGE if PCI help Select LINKSTATION if configuring for one of PPC- (MPC8241) based NAS systems from Buffalo Technology. So far only @@ -24,7 +24,7 @@ config STORCENTER select MPIC select FSL_SOC select PPC_UDBG_16550 if SERIAL_8250 - select MPC10X_BRIDGE + select MPC10X_BRIDGE if PCI help Select STORCENTER if configuring for the iomega StorCenter with an 8241 CPU in it.
Re: [PATCH 1/4] powerpc/64: Force ELFv2 when building with LLVM linker
Hi Nick, + our mailing list, helps with review and making sure that we are not missing anything :) On Fri, May 05, 2023 at 05:18:47PM +1000, Nicholas Piggin wrote: > The LLVM linker does not support ELFv1 at all, so BE kernels must be > built with ELFv2. The LLD version check was added to be conservative, > but previous LLD versions would simply fail to link ELFv1 entirely. The > only would be to require LLD >= 15 for BE builds, but let's instead > remove that restriction until proven otherwise (LLD 14.0 links a booting > ELFv2 BE vmlinux for me). > > The minimum binutils has increased such that ELFv2 is always supported, > so remove that check while we're here. > > Cc: Nathan Chancellor > Signed-off-by: Nicholas Piggin Thanks for this change! I ran it through my (admittedly limited set of) build tests with LD=ld.lld for big endian configurations and I saw no build errors with LLVM 11.1.0 through 16.0.3 (and currently, a 17.0.0 built from main); my simple QEMU boot testing passed as well. Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor One small comment below. > --- > arch/powerpc/Kconfig | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index acbd5d77..e5d81645c902 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -624,10 +624,11 @@ config ARCH_HAS_KEXEC_PURGATORY > def_bool KEXEC_FILE > > config PPC64_BIG_ENDIAN_ELF_ABI_V2 > - bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" > + prompt "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" if > LD_IS_BFD > + bool This could be bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" if LD_IS_BFD which is the syntactic sugar equivalent of what you already have. The rest looks good to me. > + default y if LD_IS_LLD > depends on PPC64 && CPU_BIG_ENDIAN > depends on CC_HAS_ELFV2 > - depends on LD_VERSION >= 22400 || LLD_VERSION >= 15 > help > This builds the kernel image using the "Power Architecture 64-Bit ELF > V2 ABI Specification", which has a reduced stack overhead and faster > @@ -638,8 +639,6 @@ config PPC64_BIG_ENDIAN_ELF_ABI_V2 > it is less well tested by kernel and toolchain. However some distros > build userspace this way, and it can produce a functioning kernel. > > - This requires GCC and binutils 2.24 or newer. > - > config RELOCATABLE > bool "Build a relocatable kernel" > depends on PPC64 || (FLATMEM && (44x || PPC_85xx)) > -- > 2.40.1 >
[PATCH v5 0/4] generic and PowerPC SED Opal keystore
From: Greg Joyce Generic functions have been defined for accessing SED Opal keys. The generic functions are defined as weak so that they may be superseded by keystore specific versions. PowerPC/pseries versions of these functions provide read/write access to SED Opal keys in the PLPKS keystore. The SED block driver has been modified to read the SED Opal keystore to populate a key in the SED Opal keyring. Changes to the SED Opal key will be written to the SED Opal keystore. Patch 3 "keystore access for SED Opal keys" is dependent on: https://lore.kernel.org/keyrings/20220818143045.680972-4-gjo...@linux.vnet.ibm.com/T/#u Changelog v5: - updated to reflect changes in PLPKS API v4: - scope reduced to cover just SED Opal keys - base SED Opal keystore is now in SED block driver - removed use of enum to indicate type - refactored common code into common function that read and write use - removed cast to void - added use of SED Opal keystore functions to SED block driver v3: - No code changes, but per reviewer requests, adding additional mailing lists(keyring, EFI) for wider review. v2: - Include feedback from Gregory Joyce, Eric Richter and Murilo Opsfelder Araujo. - Include suggestions from Michael Ellerman. - Moved a dependency from generic SED code to this patchset. This patchset now builds of its own. Greg Joyce (4): block:sed-opal: SED Opal keystore powerpc/pseries: PLPKS SED Opal keystore support block: sed-opal: keystore access for SED Opal keys powerpc/pseries: update SED for PLPKS api changes arch/powerpc/platforms/pseries/Kconfig| 6 + arch/powerpc/platforms/pseries/Makefile | 1 + .../powerpc/platforms/pseries/plpks_sed_ops.c | 114 ++ block/Kconfig | 1 + block/Makefile| 2 +- block/sed-opal-key.c | 24 block/sed-opal.c | 18 ++- include/linux/sed-opal-key.h | 15 +++ 8 files changed, 178 insertions(+), 3 deletions(-) create mode 100644 arch/powerpc/platforms/pseries/plpks_sed_ops.c create mode 100644 block/sed-opal-key.c create mode 100644 include/linux/sed-opal-key.h base-commit: 6a8f57ae2eb07ab39a6f0ccad60c760743051026 -- gjo...@linux.vnet.ibm.com
[PATCH 2/4] powerpc/pseries: PLPKS SED Opal keystore support
From: Greg Joyce
Define operations for SED Opal to read/write keys
from POWER LPAR Platform KeyStore(PLPKS). This allows
non-volatile storage of SED Opal keys.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
arch/powerpc/platforms/pseries/Makefile | 1 +
.../powerpc/platforms/pseries/plpks_sed_ops.c | 126 ++
2 files changed, 127 insertions(+)
create mode 100644 arch/powerpc/platforms/pseries/plpks_sed_ops.c
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 53c3b91af2f7..4242aed0d5d3 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_PPC_SVM) += svm.o
obj-$(CONFIG_FA_DUMP) += rtas-fadump.o
obj-$(CONFIG_PSERIES_PLPKS)+= plpks.o
obj-$(CONFIG_PPC_SECURE_BOOT) += plpks-secvar.o
+obj-$(CONFIG_PSERIES_PLPKS_SED)+= plpks-sed.o
obj-$(CONFIG_SUSPEND) += suspend.o
obj-$(CONFIG_PPC_VAS) += vas.o vas-sysfs.o
diff --git a/arch/powerpc/platforms/pseries/plpks_sed_ops.c
b/arch/powerpc/platforms/pseries/plpks_sed_ops.c
new file mode 100644
index ..086934b319a9
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/plpks_sed_ops.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * POWER Platform specific code for non-volatile SED key access
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * Define operations for SED Opal to read/write keys
+ * from POWER LPAR Platform KeyStore(PLPKS).
+ *
+ * Self Encrypting Drives(SED) key storage using PLPKS
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "plpks.h"
+
+/*
+ * structure that contains all SED data
+ */
+struct plpks_sed_object_data {
+ u_char version;
+ u_char pad1[7];
+ u_long authority;
+ u_long range;
+ u_int key_len;
+ u_char key[32];
+};
+
+#define PLPKS_PLATVAR_POLICYWORLDREADABLE
+#define PLPKS_PLATVAR_OS_COMMON 4
+
+#define PLPKS_SED_OBJECT_DATA_V00
+#define PLPKS_SED_MANGLED_LABEL "/default/pri"
+#define PLPKS_SED_COMPONENT "sed-opal"
+#define PLPKS_SED_KEY "opal-boot-pin"
+
+/*
+ * authority is admin1 and range is global
+ */
+#define PLPKS_SED_AUTHORITY 0x000900010001
+#define PLPKS_SED_RANGE 0x08020001
+
+void plpks_init_var(struct plpks_var *var, char *keyname)
+{
+ var->name = keyname;
+ var->namelen = strlen(keyname);
+ if (strcmp(PLPKS_SED_KEY, keyname) == 0) {
+ var->name = PLPKS_SED_MANGLED_LABEL;
+ var->namelen = strlen(keyname);
+ }
+ var->policy = PLPKS_PLATVAR_POLICY;
+ var->os = PLPKS_PLATVAR_OS_COMMON;
+ var->data = NULL;
+ var->datalen = 0;
+ var->component = PLPKS_SED_COMPONENT;
+}
+
+/*
+ * Read the SED Opal key from PLPKS given the label
+ */
+int sed_read_key(char *keyname, char *key, u_int *keylen)
+{
+ struct plpks_var var;
+ struct plpks_sed_object_data data;
+ u_int offset;
+ int ret;
+ u_int len;
+
+ plpks_init_var(, keyname);
+ var.data =
+ var.datalen = sizeof(data);
+
+ ret = plpks_read_os_var();
+ if (ret != 0)
+ return ret;
+
+ offset = offsetof(struct plpks_sed_object_data, key);
+ if (offset > var.datalen) {
+ return -EINVAL;
+ }
+
+ len = min(be32_to_cpu(data.key_len), *keylen);
+
+ memcpy(key, data.key, len);
+ kfree(var.data);
+
+ key[len] = '\0';
+ *keylen = len;
+
+ return 0;
+}
+
+/*
+ * Write the SED Opal key to PLPKS given the label
+ */
+int sed_write_key(char *keyname, char *key, u_int keylen)
+{
+ struct plpks_var var;
+ struct plpks_sed_object_data data;
+ struct plpks_var_name vname;
+
+ plpks_init_var(, keyname);
+
+ var.datalen = sizeof(struct plpks_sed_object_data);
+ var.data = (u8 *)
+
+ /* initialize SED object */
+ data.version = PLPKS_SED_OBJECT_DATA_V0;
+ data.authority = cpu_to_be64(PLPKS_SED_AUTHORITY);
+ data.range = cpu_to_be64(PLPKS_SED_RANGE);
+ memset(, '\0', sizeof(data.pad1));
+ data.key_len = cpu_to_be32(keylen);
+ memcpy(data.key, (char *)key, keylen);
+
+ /*
+* Key update requires remove first. The return value
+* is ignored since it's okay if the key doesn't exist.
+*/
+ vname.namelen = var.namelen;
+ vname.name = var.name;
+ plpks_remove_var(var.component, var.os, vname);
+
+ return plpks_write_var(var);
+}
--
gjo...@linux.vnet.ibm.com
[PATCH 4/4] powerpc/pseries: update SED for PLPKS api changes
From: Greg Joyce
Changes to the PLPKS API require minor updates to the SED Opal
PLPKS keystore code.
Signed-off-by: Greg Joyce
---
arch/powerpc/platforms/pseries/Kconfig| 6 +
arch/powerpc/platforms/pseries/Makefile | 2 +-
.../powerpc/platforms/pseries/plpks_sed_ops.c | 22 +--
block/Kconfig | 1 +
4 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index 21b22bf16ce6..c2f8a29e7b9b 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -163,6 +163,12 @@ config PSERIES_PLPKS
# This option is selected by in-kernel consumers that require
# access to the PKS.
+config PSERIES_PLPKS_SED
+ depends on PPC_PSERIES
+ bool
+ # This option is selected by in-kernel consumers that require
+ # access to the SED PKS keystore.
+
config PAPR_SCM
depends on PPC_PSERIES && MEMORY_HOTPLUG && LIBNVDIMM
tristate "Support for the PAPR Storage Class Memory interface"
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 4242aed0d5d3..1476c5e4433c 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_PPC_SVM) += svm.o
obj-$(CONFIG_FA_DUMP) += rtas-fadump.o
obj-$(CONFIG_PSERIES_PLPKS)+= plpks.o
obj-$(CONFIG_PPC_SECURE_BOOT) += plpks-secvar.o
-obj-$(CONFIG_PSERIES_PLPKS_SED)+= plpks-sed.o
+obj-$(CONFIG_PSERIES_PLPKS_SED)+= plpks_sed_ops.o
obj-$(CONFIG_SUSPEND) += suspend.o
obj-$(CONFIG_PPC_VAS) += vas.o vas-sysfs.o
diff --git a/arch/powerpc/platforms/pseries/plpks_sed_ops.c
b/arch/powerpc/platforms/pseries/plpks_sed_ops.c
index 086934b319a9..c1d08075e850 100644
--- a/arch/powerpc/platforms/pseries/plpks_sed_ops.c
+++ b/arch/powerpc/platforms/pseries/plpks_sed_ops.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include "plpks.h"
+#include
/*
* structure that contains all SED data
@@ -28,9 +28,6 @@ struct plpks_sed_object_data {
u_char key[32];
};
-#define PLPKS_PLATVAR_POLICYWORLDREADABLE
-#define PLPKS_PLATVAR_OS_COMMON 4
-
#define PLPKS_SED_OBJECT_DATA_V00
#define PLPKS_SED_MANGLED_LABEL "/default/pri"
#define PLPKS_SED_COMPONENT "sed-opal"
@@ -50,8 +47,8 @@ void plpks_init_var(struct plpks_var *var, char *keyname)
var->name = PLPKS_SED_MANGLED_LABEL;
var->namelen = strlen(keyname);
}
- var->policy = PLPKS_PLATVAR_POLICY;
- var->os = PLPKS_PLATVAR_OS_COMMON;
+ var->policy = PLPKS_WORLDREADABLE;
+ var->os = PLPKS_VAR_COMMON;
var->data = NULL;
var->datalen = 0;
var->component = PLPKS_SED_COMPONENT;
@@ -64,28 +61,19 @@ int sed_read_key(char *keyname, char *key, u_int *keylen)
{
struct plpks_var var;
struct plpks_sed_object_data data;
- u_int offset;
int ret;
u_int len;
plpks_init_var(, keyname);
- var.data =
+ var.data = (u8 *)
var.datalen = sizeof(data);
ret = plpks_read_os_var();
if (ret != 0)
return ret;
- offset = offsetof(struct plpks_sed_object_data, key);
- if (offset > var.datalen) {
- return -EINVAL;
- }
-
- len = min(be32_to_cpu(data.key_len), *keylen);
-
+ len = min_t(u16, be32_to_cpu(data.key_len), var.datalen);
memcpy(key, data.key, len);
- kfree(var.data);
-
key[len] = '\0';
*keylen = len;
diff --git a/block/Kconfig b/block/Kconfig
index 76b23114fdeb..75d4db34df5a 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -182,6 +182,7 @@ config BLK_SED_OPAL
bool "Logic for interfacing with Opal enabled SEDs"
depends on KEYS
select PSERIES_PLPKS if PPC_PSERIES
+ select PSERIES_PLPKS_SED if PPC_PSERIES
help
Builds Logic for interfacing with Opal enabled controllers.
Enabling this option enables users to setup/unlock/lock
--
gjo...@linux.vnet.ibm.com
[PATCH 3/4] block: sed-opal: keystore access for SED Opal keys
From: Greg Joyce
Allow for permanent SED authentication keys by
reading/writing to the SED Opal non-volatile keystore.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
block/sed-opal.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/block/sed-opal.c b/block/sed-opal.c
index 7f5f235a9048..1e8cfa00b609 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2803,7 +2804,13 @@ static int opal_set_new_pw(struct opal_dev *dev, struct
opal_new_pw *opal_pw)
if (ret)
return ret;
- /* update keyring with new password */
+ /* update keyring and key store with new password */
+ ret = sed_write_key(OPAL_AUTH_KEY,
+ opal_pw->new_user_pw.opal_key.key,
+ opal_pw->new_user_pw.opal_key.key_len);
+ if (ret != -EOPNOTSUPP)
+ pr_warn("error updating SED key: %d\n", ret);
+
ret = update_sed_opal_key(OPAL_AUTH_KEY,
opal_pw->new_user_pw.opal_key.key,
opal_pw->new_user_pw.opal_key.key_len);
@@ -3050,6 +3057,8 @@ EXPORT_SYMBOL_GPL(sed_ioctl);
static int __init sed_opal_init(void)
{
struct key *kr;
+ char init_sed_key[OPAL_KEY_MAX];
+ int keylen = OPAL_KEY_MAX - 1;
kr = keyring_alloc(".sed_opal",
GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
@@ -3062,6 +3071,11 @@ static int __init sed_opal_init(void)
sed_opal_keyring = kr;
- return 0;
+ if (sed_read_key(OPAL_AUTH_KEY, init_sed_key, ) < 0) {
+ memset(init_sed_key, '\0', sizeof(init_sed_key));
+ keylen = OPAL_KEY_MAX - 1;
+ }
+
+ return update_sed_opal_key(OPAL_AUTH_KEY, init_sed_key, keylen);
}
late_initcall(sed_opal_init);
--
gjo...@linux.vnet.ibm.com
[PATCH 1/4] block:sed-opal: SED Opal keystore
From: Greg Joyce
Add read and write functions that allow SED Opal keys to stored
in a permanent keystore.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
block/Makefile | 2 +-
block/sed-opal-key.c | 24
include/linux/sed-opal-key.h | 15 +++
3 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 block/sed-opal-key.c
create mode 100644 include/linux/sed-opal-key.h
diff --git a/block/Makefile b/block/Makefile
index 4e01bb71ad6e..464a9f209552 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -35,7 +35,7 @@ obj-$(CONFIG_BLK_DEV_ZONED) += blk-zoned.o
obj-$(CONFIG_BLK_WBT) += blk-wbt.o
obj-$(CONFIG_BLK_DEBUG_FS) += blk-mq-debugfs.o
obj-$(CONFIG_BLK_DEBUG_FS_ZONED)+= blk-mq-debugfs-zoned.o
-obj-$(CONFIG_BLK_SED_OPAL) += sed-opal.o
+obj-$(CONFIG_BLK_SED_OPAL) += sed-opal.o sed-opal-key.o
obj-$(CONFIG_BLK_PM) += blk-pm.o
obj-$(CONFIG_BLK_INLINE_ENCRYPTION)+= blk-crypto.o blk-crypto-profile.o \
blk-crypto-sysfs.o
diff --git a/block/sed-opal-key.c b/block/sed-opal-key.c
new file mode 100644
index ..16f380164c44
--- /dev/null
+++ b/block/sed-opal-key.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * SED key operations.
+ *
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * These are the accessor functions (read/write) for SED Opal
+ * keys. Specific keystores can provide overrides.
+ *
+ */
+
+#include
+#include
+#include
+
+int __weak sed_read_key(char *keyname, char *key, u_int *keylen)
+{
+ return -EOPNOTSUPP;
+}
+
+int __weak sed_write_key(char *keyname, char *key, u_int keylen)
+{
+ return -EOPNOTSUPP;
+}
diff --git a/include/linux/sed-opal-key.h b/include/linux/sed-opal-key.h
new file mode 100644
index ..c9b1447986d8
--- /dev/null
+++ b/include/linux/sed-opal-key.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * SED key operations.
+ *
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * These are the accessor functions (read/write) for SED Opal
+ * keys. Specific keystores can provide overrides.
+ *
+ */
+
+#include
+
+int sed_read_key(char *keyname, char *key, u_int *keylen);
+int sed_write_key(char *keyname, char *key, u_int keylen);
--
gjo...@linux.vnet.ibm.com
[PATCH v4 3/3] block: sed-opal: keyring support for SED keys
From: Greg Joyce
Extend the SED block driver so it can alternatively
obtain a key from a sed-opal kernel keyring. The SED
ioctls will indicate the source of the key, either
directly in the ioctl data or from the keyring.
This allows the use of SED commands in scripts such as
udev scripts so that drives may be automatically unlocked
as they become available.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
block/Kconfig | 2 +
block/sed-opal.c | 174 +-
include/linux/sed-opal.h | 3 +
include/uapi/linux/sed-opal.h | 8 +-
4 files changed, 184 insertions(+), 3 deletions(-)
diff --git a/block/Kconfig b/block/Kconfig
index 941b2dca70db..76b23114fdeb 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -180,6 +180,8 @@ config BLK_DEBUG_FS_ZONED
config BLK_SED_OPAL
bool "Logic for interfacing with Opal enabled SEDs"
+ depends on KEYS
+ select PSERIES_PLPKS if PPC_PSERIES
help
Builds Logic for interfacing with Opal enabled controllers.
Enabling this option enables users to setup/unlock/lock
diff --git a/block/sed-opal.c b/block/sed-opal.c
index 5b277eaabbc7..7f5f235a9048 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -20,6 +20,9 @@
#include
#include
#include
+#include
+#include
+#include
#include "opal_proto.h"
@@ -29,6 +32,8 @@
/* Number of bytes needed by cmd_finalize. */
#define CMD_FINALIZE_BYTES_NEEDED 7
+static struct key *sed_opal_keyring;
+
struct opal_step {
int (*fn)(struct opal_dev *dev, void *data);
void *data;
@@ -265,6 +270,101 @@ static void print_buffer(const u8 *ptr, u32 length)
#endif
}
+/*
+ * Allocate/update a SED Opal key and add it to the SED Opal keyring.
+ */
+static int update_sed_opal_key(const char *desc, u_char *key_data, int keylen)
+{
+ key_ref_t kr;
+
+ if (!sed_opal_keyring)
+ return -ENOKEY;
+
+ kr = key_create_or_update(make_key_ref(sed_opal_keyring, true), "user",
+ desc, (const void *)key_data, keylen,
+ KEY_USR_VIEW | KEY_USR_SEARCH | KEY_USR_WRITE,
+ KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_BUILT_IN |
+ KEY_ALLOC_BYPASS_RESTRICTION);
+ if (IS_ERR(kr)) {
+ pr_err("Error adding SED key (%ld)\n", PTR_ERR(kr));
+ return PTR_ERR(kr);
+ }
+
+ return 0;
+}
+
+/*
+ * Read a SED Opal key from the SED Opal keyring.
+ */
+static int read_sed_opal_key(const char *key_name, u_char *buffer, int buflen)
+{
+ int ret;
+ key_ref_t kref;
+ struct key *key;
+
+ if (!sed_opal_keyring)
+ return -ENOKEY;
+
+ kref = keyring_search(make_key_ref(sed_opal_keyring, true),
+ _type_user, key_name, true);
+
+ if (IS_ERR(kref))
+ ret = PTR_ERR(kref);
+
+ key = key_ref_to_ptr(kref);
+ down_read(>sem);
+ ret = key_validate(key);
+ if (ret == 0) {
+ if (buflen > key->datalen)
+ buflen = key->datalen;
+
+ ret = key->type->read(key, (char *)buffer, buflen);
+ }
+ up_read(>sem);
+
+ key_ref_put(kref);
+
+ return ret;
+}
+
+static int opal_get_key(struct opal_dev *dev, struct opal_key *key)
+{
+ int ret = 0;
+
+ switch (key->key_type) {
+ case OPAL_INCLUDED:
+ /* the key is ready to use */
+ break;
+ case OPAL_KEYRING:
+ /* the key is in the keyring */
+ ret = read_sed_opal_key(OPAL_AUTH_KEY, key->key, OPAL_KEY_MAX);
+ if (ret > 0) {
+ if (ret > U8_MAX) {
+ ret = -ENOSPC;
+ goto error;
+ }
+ key->key_len = ret;
+ key->key_type = OPAL_INCLUDED;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ if (ret < 0)
+ goto error;
+
+ /* must have a PEK by now or it's an error */
+ if (key->key_type != OPAL_INCLUDED || key->key_len == 0) {
+ ret = -EINVAL;
+ goto error;
+ }
+ return 0;
+error:
+ pr_debug("Error getting password: %d\n", ret);
+ return ret;
+}
+
static bool check_tper(const void *data)
{
const struct d0_tper_features *tper = data;
@@ -2271,6 +2371,9 @@ static int opal_secure_erase_locking_range(struct
opal_dev *dev,
};
int ret;
+ ret = opal_get_key(dev, _session->opal_key);
+ if (ret)
+ return ret;
mutex_lock(>dev_lock);
setup_opal_dev(dev);
ret = execute_steps(dev, erase_steps, ARRAY_SIZE(erase_steps));
@@ -2304,6 +2407,9 @@ static int opal_revertlsp(struct opal_dev
[PATCH v4 1/3] block: sed-opal: Implement IOC_OPAL_DISCOVERY
From: Greg Joyce
Add IOC_OPAL_DISCOVERY ioctl to return raw discovery data to a SED Opal
application. This allows the application to display drive capabilities
and state.
Signed-off-by: Greg Joyce
Reviewed-by: Christoph Hellwig
Reviewed-by: Jonathan Derrick
---
block/sed-opal.c | 38 ---
include/linux/sed-opal.h | 1 +
include/uapi/linux/sed-opal.h | 6 ++
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/block/sed-opal.c b/block/sed-opal.c
index c320093c14f1..b55a8eb29f5b 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -457,8 +457,11 @@ static int execute_steps(struct opal_dev *dev,
return error;
}
-static int opal_discovery0_end(struct opal_dev *dev)
+static int opal_discovery0_end(struct opal_dev *dev, void *data)
{
+ struct opal_discovery *discv_out = data; /* may be NULL */
+ u8 __user *buf_out;
+ u64 len_out;
bool found_com_id = false, supported = true, single_user = false;
const struct d0_header *hdr = (struct d0_header *)dev->resp;
const u8 *epos = dev->resp, *cpos = dev->resp;
@@ -474,6 +477,15 @@ static int opal_discovery0_end(struct opal_dev *dev)
return -EFAULT;
}
+ if (discv_out) {
+ buf_out = (u8 __user *)(uintptr_t)discv_out->data;
+ len_out = min_t(u64, discv_out->size, hlen);
+ if (buf_out && copy_to_user(buf_out, dev->resp, len_out))
+ return -EFAULT;
+
+ discv_out->size = hlen; /* actual size of data */
+ }
+
epos += hlen; /* end of buffer */
cpos += sizeof(*hdr); /* current position on buffer */
@@ -559,13 +571,13 @@ static int opal_discovery0(struct opal_dev *dev, void
*data)
if (ret)
return ret;
- return opal_discovery0_end(dev);
+ return opal_discovery0_end(dev, data);
}
static int opal_discovery0_step(struct opal_dev *dev)
{
const struct opal_step discovery0_step = {
- opal_discovery0,
+ opal_discovery0, NULL
};
return execute_step(dev, _step, 0);
@@ -2247,6 +2259,22 @@ static int opal_secure_erase_locking_range(struct
opal_dev *dev,
return ret;
}
+static int opal_get_discv(struct opal_dev *dev, struct opal_discovery *discv)
+{
+ const struct opal_step discovery0_step = {
+ opal_discovery0, discv
+ };
+ int ret = 0;
+
+ mutex_lock(>dev_lock);
+ setup_opal_dev(dev);
+ ret = execute_step(dev, _step, 0);
+ mutex_unlock(>dev_lock);
+ if (ret)
+ return ret;
+ return discv->size; /* modified to actual length of data */
+}
+
static int opal_erase_locking_range(struct opal_dev *dev,
struct opal_session_info *opal_session)
{
@@ -2814,6 +2842,10 @@ int sed_ioctl(struct opal_dev *dev, unsigned int cmd,
void __user *arg)
case IOC_OPAL_GET_STATUS:
ret = opal_get_status(dev, arg);
break;
+ case IOC_OPAL_DISCOVERY:
+ ret = opal_get_discv(dev, p);
+ break;
+
default:
break;
}
diff --git a/include/linux/sed-opal.h b/include/linux/sed-opal.h
index 31ac562a17d7..8e824ab908e9 100644
--- a/include/linux/sed-opal.h
+++ b/include/linux/sed-opal.h
@@ -45,6 +45,7 @@ static inline bool is_sed_ioctl(unsigned int cmd)
case IOC_OPAL_WRITE_SHADOW_MBR:
case IOC_OPAL_GENERIC_TABLE_RW:
case IOC_OPAL_GET_STATUS:
+ case IOC_OPAL_DISCOVERY:
return true;
}
return false;
diff --git a/include/uapi/linux/sed-opal.h b/include/uapi/linux/sed-opal.h
index d7a1524023db..98f216cf2241 100644
--- a/include/uapi/linux/sed-opal.h
+++ b/include/uapi/linux/sed-opal.h
@@ -151,6 +151,11 @@ struct opal_status {
__u32 reserved;
};
+struct opal_discovery {
+ __u64 data;
+ __u64 size;
+};
+
#define IOC_OPAL_SAVE _IOW('p', 220, struct opal_lock_unlock)
#define IOC_OPAL_LOCK_UNLOCK _IOW('p', 221, struct opal_lock_unlock)
#define IOC_OPAL_TAKE_OWNERSHIP_IOW('p', 222, struct opal_key)
@@ -168,5 +173,6 @@ struct opal_status {
#define IOC_OPAL_WRITE_SHADOW_MBR _IOW('p', 234, struct opal_shadow_mbr)
#define IOC_OPAL_GENERIC_TABLE_RW _IOW('p', 235, struct
opal_read_write_table)
#define IOC_OPAL_GET_STATUS _IOR('p', 236, struct opal_status)
+#define IOC_OPAL_DISCOVERY _IOW('p', 237, struct opal_discovery)
#endif /* _UAPI_SED_OPAL_H */
--
gjo...@linux.vnet.ibm.com
[PATCH v4 2/3] block: sed-opal: Implement IOC_OPAL_REVERT_LSP
From: Greg Joyce
This is used in conjunction with IOC_OPAL_REVERT_TPR to return a drive to
Original Factory State without erasing the data. If IOC_OPAL_REVERT_LSP
is called with opal_revert_lsp.options bit OPAL_PRESERVE set prior
to calling IOC_OPAL_REVERT_TPR, the drive global locking range will not
be erased.
Signed-off-by: Greg Joyce
Reviewed-by: Christoph Hellwig
Reviewed-by: Jonathan Derrick
---
block/opal_proto.h| 4
block/sed-opal.c | 40 +++
include/linux/sed-opal.h | 1 +
include/uapi/linux/sed-opal.h | 11 ++
4 files changed, 56 insertions(+)
diff --git a/block/opal_proto.h b/block/opal_proto.h
index 7152aa1f1a49..c3b5bff0b9e4 100644
--- a/block/opal_proto.h
+++ b/block/opal_proto.h
@@ -215,6 +215,10 @@ enum opal_parameter {
OPAL_SUM_SET_LIST = 0x06,
};
+enum opal_revertlsp {
+ OPAL_KEEP_GLOBAL_RANGE_KEY = 0x06,
+};
+
/* Packets derived from:
* TCG_Storage_Architecture_Core_Spec_v2.01_r1.00
* Secion: 3.2.3 ComPackets, Packets & Subpackets
diff --git a/block/sed-opal.c b/block/sed-opal.c
index b55a8eb29f5b..5b277eaabbc7 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -1634,6 +1634,26 @@ static int internal_activate_user(struct opal_dev *dev,
void *data)
return finalize_and_send(dev, parse_and_check_status);
}
+static int revert_lsp(struct opal_dev *dev, void *data)
+{
+ struct opal_revert_lsp *rev = data;
+ int err;
+
+ err = cmd_start(dev, opaluid[OPAL_THISSP_UID],
+ opalmethod[OPAL_REVERTSP]);
+ add_token_u8(, dev, OPAL_STARTNAME);
+ add_token_u64(, dev, OPAL_KEEP_GLOBAL_RANGE_KEY);
+ add_token_u8(, dev, (rev->options & OPAL_PRESERVE) ?
+ OPAL_TRUE : OPAL_FALSE);
+ add_token_u8(, dev, OPAL_ENDNAME);
+ if (err) {
+ pr_debug("Error building REVERT SP command.\n");
+ return err;
+ }
+
+ return finalize_and_send(dev, parse_and_check_status);
+}
+
static int erase_locking_range(struct opal_dev *dev, void *data)
{
struct opal_session_info *session = data;
@@ -2275,6 +2295,23 @@ static int opal_get_discv(struct opal_dev *dev, struct
opal_discovery *discv)
return discv->size; /* modified to actual length of data */
}
+static int opal_revertlsp(struct opal_dev *dev, struct opal_revert_lsp *rev)
+{
+ /* controller will terminate session */
+ const struct opal_step steps[] = {
+ { start_admin1LSP_opal_session, >key },
+ { revert_lsp, rev }
+ };
+ int ret;
+
+ mutex_lock(>dev_lock);
+ setup_opal_dev(dev);
+ ret = execute_steps(dev, steps, ARRAY_SIZE(steps));
+ mutex_unlock(>dev_lock);
+
+ return ret;
+}
+
static int opal_erase_locking_range(struct opal_dev *dev,
struct opal_session_info *opal_session)
{
@@ -2842,6 +2879,9 @@ int sed_ioctl(struct opal_dev *dev, unsigned int cmd,
void __user *arg)
case IOC_OPAL_GET_STATUS:
ret = opal_get_status(dev, arg);
break;
+ case IOC_OPAL_REVERT_LSP:
+ ret = opal_revertlsp(dev, p);
+ break;
case IOC_OPAL_DISCOVERY:
ret = opal_get_discv(dev, p);
break;
diff --git a/include/linux/sed-opal.h b/include/linux/sed-opal.h
index 8e824ab908e9..bf2f9d7e11eb 100644
--- a/include/linux/sed-opal.h
+++ b/include/linux/sed-opal.h
@@ -46,6 +46,7 @@ static inline bool is_sed_ioctl(unsigned int cmd)
case IOC_OPAL_GENERIC_TABLE_RW:
case IOC_OPAL_GET_STATUS:
case IOC_OPAL_DISCOVERY:
+ case IOC_OPAL_REVERT_LSP:
return true;
}
return false;
diff --git a/include/uapi/linux/sed-opal.h b/include/uapi/linux/sed-opal.h
index 98f216cf2241..720725f1c42a 100644
--- a/include/uapi/linux/sed-opal.h
+++ b/include/uapi/linux/sed-opal.h
@@ -56,6 +56,10 @@ struct opal_key {
__u8 key[OPAL_KEY_MAX];
};
+enum opal_revert_lsp_opts {
+ OPAL_PRESERVE = 0x01,
+};
+
struct opal_lr_act {
struct opal_key key;
__u32 sum;
@@ -156,6 +160,12 @@ struct opal_discovery {
__u64 size;
};
+struct opal_revert_lsp {
+ struct opal_key key;
+ __u32 options;
+ __u32 __pad;
+};
+
#define IOC_OPAL_SAVE _IOW('p', 220, struct opal_lock_unlock)
#define IOC_OPAL_LOCK_UNLOCK _IOW('p', 221, struct opal_lock_unlock)
#define IOC_OPAL_TAKE_OWNERSHIP_IOW('p', 222, struct opal_key)
@@ -174,5 +184,6 @@ struct opal_discovery {
#define IOC_OPAL_GENERIC_TABLE_RW _IOW('p', 235, struct
opal_read_write_table)
#define IOC_OPAL_GET_STATUS _IOR('p', 236, struct opal_status)
#define IOC_OPAL_DISCOVERY _IOW('p', 237, struct opal_discovery)
+#define IOC_OPAL_REVERT_LSP _IOW('p', 238, struct opal_revert_lsp)
#endif /* _UAPI_SED_OPAL_H */
--
[PATCH v4 0/3] sed-opal: keyrings, discovery, revert, key store
From: Greg Joyce TCG SED Opal is a specification from The Trusted Computing Group that allows self encrypting storage devices (SED) to be locked at power on and require an authentication key to unlock the drive. The current SED Opal implementation in the block driver requires that authentication keys be provided in an ioctl so that they can be presented to the underlying SED capable drive. Currently, the key is typically entered by a user with an application like sedutil or sedcli. While this process works, it does not lend itself to automation like unlock by a udev rule. The SED block driver has been extended so it can alternatively obtain a key from a sed-opal kernel keyring. The SED ioctls will indicate the source of the key, either directly in the ioctl data or from the keyring. Two new SED ioctls have also been added. These are: 1) IOC_OPAL_REVERT_LSP to revert LSP state 2) IOC_OPAL_DISCOVERY to discover drive capabilities/state change log v4: - rebase to 6.3-rc7 - replaced "255" magic number with U8_MAX change log: - rebase to 6.x - added latest reviews - removed platform functions for persistent key storage - replaced key update logic with key_create_or_update() - minor bracing and padding changes - add error returns - opal_key structure is application provided but kernel verified - added brief description of TCG SED Opal Greg Joyce (3): block: sed-opal: Implement IOC_OPAL_DISCOVERY block: sed-opal: Implement IOC_OPAL_REVERT_LSP block: sed-opal: keyring support for SED keys block/Kconfig | 2 + block/opal_proto.h| 4 + block/sed-opal.c | 252 +- include/linux/sed-opal.h | 5 + include/uapi/linux/sed-opal.h | 25 +++- 5 files changed, 282 insertions(+), 6 deletions(-) Signed-off-by: Greg Joyce base-commit: 6a8f57ae2eb07ab39a6f0ccad60c760743051026 -- gjo...@linux.vnet.ibm.com
Re: [PATCH v4 2/3] PCI/AER: Disable AER interrupt on suspend
On Mon, Apr 24, 2023 at 01:52:48PM +0800, Kai-Heng Feng wrote:
> PCIe service that shares IRQ with PME may cause spurious wakeup on
> system suspend.
>
> PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
> that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
> (D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose
> much here to disable AER during system suspend.
>
> This is very similar to previous attempts to suspend AER and DPC [1],
> but with a different reason.
What is the reason? I assume it's something to do with the bugzilla
below, but the commit log should outline the user-visible problem this
fixes. The commit log basically makes the case for "why should we
merge this patch."
I assume it's along the lines of "I tried to suspend this system, but
it immediately woke up again because of an AER interrupt, and
disabling AER during suspend avoids this problem. And disabling
the AER interrupt is not a problem because X"
> [1]
> https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.f...@canonical.com/
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
>
> Reviewed-by: Mika Westerberg
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/pci/pcie/aer.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 1420e1f27105..9c07fdbeb52d 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1356,6 +1356,26 @@ static int aer_probe(struct pcie_device *dev)
> return 0;
> }
>
> +static int aer_suspend(struct pcie_device *dev)
> +{
> + struct aer_rpc *rpc = get_service_data(dev);
> + struct pci_dev *pdev = rpc->rpd;
> +
> + aer_disable_irq(pdev);
> +
> + return 0;
> +}
> +
> +static int aer_resume(struct pcie_device *dev)
> +{
> + struct aer_rpc *rpc = get_service_data(dev);
> + struct pci_dev *pdev = rpc->rpd;
> +
> + aer_enable_irq(pdev);
> +
> + return 0;
> +}
> +
> /**
> * aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP
> * @dev: pointer to Root Port, RCEC, or RCiEP
> @@ -1420,6 +1440,8 @@ static struct pcie_port_service_driver aerdriver = {
> .service= PCIE_PORT_SERVICE_AER,
>
> .probe = aer_probe,
> + .suspend= aer_suspend,
> + .resume = aer_resume,
> .remove = aer_remove,
> };
>
> --
> 2.34.1
>
[PATCH] iommu/powerpc: Incorrect DDW Table is referenced for SR-IOV device
For an SR-IOV device, while enabling DDW, a new table is created and added
at index 1 in the group. In the below 2 scenarios, the table is incorrectly
referenced at index 0 (which is where the table is for default DMA window).
1. When adding DDW
This issue is exposed with "slub_debug". Error thrown out from
dma_iommu_dma_supported()
Warning: IOMMU offset too big for device mask
mask: 0x, table offset: 0x800
2. During Dynamic removal of the PCI device.
Error is from iommu_tce_table_put() since a NULL table pointer is
passed in.
Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect
mapping")
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/kernel/dma-iommu.c| 4 +++-
arch/powerpc/platforms/pseries/iommu.c | 13 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 038ce8d9061d..8920862ffd79 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -144,7 +144,7 @@ static bool dma_iommu_bypass_supported(struct device *dev,
u64 mask)
/* We support DMA to/from any memory page via the iommu */
int dma_iommu_dma_supported(struct device *dev, u64 mask)
{
- struct iommu_table *tbl = get_iommu_table_base(dev);
+ struct iommu_table *tbl;
if (dev_is_pci(dev) && dma_iommu_bypass_supported(dev, mask)) {
/*
@@ -162,6 +162,8 @@ int dma_iommu_dma_supported(struct device *dev, u64 mask)
return 1;
}
+ tbl = get_iommu_table_base(dev);
+
if (!tbl) {
dev_err(dev, "Warning: IOMMU dma not supported: mask 0x%08llx,
table unavailable\n", mask);
return 0;
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index c74b71d4733d..a8acd3b402d7 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -85,19 +85,24 @@ static struct iommu_table_group
*iommu_pseries_alloc_group(int node)
static void iommu_pseries_free_group(struct iommu_table_group *table_group,
const char *node_name)
{
- struct iommu_table *tbl;
-
if (!table_group)
return;
- tbl = table_group->tables[0];
#ifdef CONFIG_IOMMU_API
if (table_group->group) {
iommu_group_put(table_group->group);
BUG_ON(table_group->group);
}
#endif
- iommu_tce_table_put(tbl);
+
+ /* Default DMA window table is at index 0, while DDW at 1. SR-IOV
+* adapters only have table on index 1.
+*/
+ if (table_group->tables[0])
+ iommu_tce_table_put(table_group->tables[0]);
+
+ if (table_group->tables[1])
+ iommu_tce_table_put(table_group->tables[1]);
kfree(table_group);
}
--
[PATCH] powerpc: dts: turris1x.dts: Fix PCIe MEM size for pci2 node
Freescale PCIe controllers on their PCIe Root Ports do not have any
mappable PCI BAR allocate from PCIe MEM.
Information about 1MB window on BAR0 of PCIe Root Port was misleading
because Freescale PCIe controllers have at BAR0 position different register
PEXCSRBAR, and kernel correctly skipts BAR0 for these Freescale PCIe Root
Ports.
So update comment about P2020 PCIe Root Port and decrease PCIe MEM size
required for PCIe controller (pci2 node) on which is on-board xHCI
controller.
lspci confirms that on P2020 PCIe Root Port is no PCI BAR and /proc/iomem
sees that only c000-c000 and c001-c0011fff ranges are used.
Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers")
Signed-off-by: Pali Rohár
---
arch/powerpc/boot/dts/turris1x.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/turris1x.dts
b/arch/powerpc/boot/dts/turris1x.dts
index 6612160c19d5..dff1ea074d9d 100644
--- a/arch/powerpc/boot/dts/turris1x.dts
+++ b/arch/powerpc/boot/dts/turris1x.dts
@@ -476,12 +476,12 @@
* channel 1 (but only USB 2.0 subset) to USB 2.0 pins on mPCIe
* slot 1 (CN5), channels 2 and 3 to connector P600.
*
-* P2020 PCIe Root Port uses 1MB of PCIe MEM and xHCI controller
+* P2020 PCIe Root Port does not use PCIe MEM and xHCI
controller
* uses 64kB + 8kB of PCIe MEM. No PCIe IO is used or required.
-* So allocate 2MB of PCIe MEM for this PCIe bus.
+* So allocate 128kB of PCIe MEM for this PCIe bus.
*/
reg = <0 0xffe08000 0 0x1000>;
- ranges = <0x0200 0x0 0xc000 0 0xc000 0x0
0x0020>, /* MEM */
+ ranges = <0x0200 0x0 0xc000 0 0xc000 0x0
0x0002>, /* MEM */
<0x0100 0x0 0x 0 0xffc2 0x0
0x0001>; /* IO */
pcie@0 {
--
2.20.1
[PATCH] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present
Commit e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges"
parsing") broke PASemi Nemo board booting. The issue is the ISA I/O
range was not getting mapped as the logic to handle no "ranges" was
inverted. If phb_io_base_phys is non-zero, then the ISA range defaults
to the first 64K of the PCI I/O space. phb_io_base_phys should only be 0
when looking for a non-PCI ISA region.
Fixes: e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges" parsing")
Link:
https://lore.kernel.org/all/301595ad-0edf-2113-b55f-f5b8051ed...@xenosoft.de/
Reported-by: Christian Zigotzky
Signed-off-by: Rob Herring
---
Untested, but I think this should fix the issue.
arch/powerpc/kernel/isa-bridge.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index 85bdd7d3652f..48e0eaf1ad61 100644
--- a/arch/powerpc/kernel/isa-bridge.c
+++ b/arch/powerpc/kernel/isa-bridge.c
@@ -93,11 +93,12 @@ static int process_ISA_OF_ranges(struct device_node
*isa_node,
}
inval_range:
- if (!phb_io_base_phys) {
+ if (phb_io_base_phys) {
pr_err("no ISA IO ranges or unexpected isa range, mapping
64k\n");
remap_isa_base(phb_io_base_phys, 0x1);
+ return 0;
}
- return 0;
+ return -EINVAL;
}
--
2.39.2
Re: [PATCH v4 11/17] watchdog/hardlockup: Rename some "NMI watchdog" constants/function
Hi, On Thu, May 4, 2023 at 8:07 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > Do a search and replace of: > > - NMI_WATCHDOG_ENABLED => HARD_WATCHDOG_ENABLED > > - watchdog_nmi_ => watchdog_hardlockup_ > > These are just making prefixes inconsistent again. > > If you really want to do a prefix, I would call it hardlockup which > probably best matches existing code and sysctl / boot stuff, and > concentrate on non-static symbols. As with other similar patches, I'm happy to drop this and am doing it at Petr's request. [1] https://lore.kernel.org/r/ZFErmshcrcikrSU1@alley
Re: [PATCH v4 08/17] watchdog/hardlockup: Style changes to watchdog_hardlockup_check() / ..._is_lockedup()
Hi, On Thu, May 4, 2023 at 8:02 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > These are tiny style changes: > > - Add a blank line before a "return". > > - Renames two globals to use the "watchdog_hld" prefix. > > Particularly static ones don't really need the namespace prefixes. Renames are mostly at Petr's request. If I've misunderstood what he wants here that I'm happy to remove them. > Not sure if processed is better than warn. I can undo this one if you want. It felt like we were doing more than just warning, but if people think "warn" is a better way to describe it then that's fine with me. > allcpu_dumped is better > than dumped_stacks though because the all-CPUs-dump is a particular > thing. OK, I can undo this and leave it as "allcpu_dumped". [1] https://lore.kernel.org/r/ZFErmshcrcikrSU1@alley
Re: [PATCH v4 07/17] watchdog/hardlockup: Move perf hardlockup checking/panic to common watchdog.c
Hi, On Thu, May 4, 2023 at 7:58 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > The perf hardlockup detector works by looking at interrupt counts and > > seeing if they change from run to run. The interrupt counts are > > managed by the common watchdog code via its watchdog_timer_fn(). > > > > Currently the API between the perf detector and the common code is a > > function: is_hardlockup(). When the hard lockup detector sees that > > function return true then it handles printing out debug info and > > inducing a panic if necessary. > > > > Let's change the API a little bit in preparation for the buddy > > hardlockup detector. The buddy hardlockup detector wants to print > > I think the name change is a gratuitous. Especially since it's now > static. > > watchdog_hardlockup_ is a pretty long prefix too, hardlockup_ > should be enough? > > Seems okay otherwise though. I went back and forth on names far too much when constructing this patch series. Mostly I was trying to balance what looked good to me and what Petr suggested [1]. I'm not super picky about the names and I'm happy to change them all to a "hardlockup_" prefix. I'd love to hear Petr's opinion. [1] https://lore.kernel.org/r/ZFErmshcrcikrSU1@alley
Re: [PATCH v4 05/17] watchdog/hardlockup: Rename touch_nmi_watchdog() to touch_hardlockup_watchdog()
Hi, On Thu, May 4, 2023 at 7:51 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > In preparation for the buddy hardlockup detector, rename > > touch_nmi_watchdog() to touch_hardlockup_watchdog() to make it clear > > that it will touch whatever hardlockup detector is configured. We'll > > add a #define for the old name (touch_nmi_watchdog) so that we don't > > have to touch every piece of code referring to the old name. > > Is this really helpful? Now it's got two names Could just leave it. > If you insist then it'd be better just to rename everything in one > go at the end of a merge window IMO. Conflicts would be trivial. I'm not picky here. I changed the name since Petr requested names to be changed for any code I was touching [1] and so I threw this out as a proposal. I agree that having two names can be confusing, but in this case it didn't feel too terrible to me. I'd love to hear Petr's opinion on this name change. I'm happy with: a) This patch as it is. b) Dropping this patch (or perhaps just changing it to add comments). c) Changing this patch to rename all 70 uses of the old name. Assuming this will go through Andrew Morton's tree, I'd be interested in whether he's OK w/ this. d) Dropping this patch from this series but putting it on the backburner to try to do later (so that the rename can happen at a time when it's least disruptive). > > Ideally this change would also rename the arch_touch_nmi_watchdog(), > > but that is harder since arch_touch_nmi_watchdog() is exported with > > EXPORT_SYMBOL() and thus is ABI. Add a comment next to the call to > > hopefully alleviate some of the confusion here. > > We don't keep ABI fixed upstream. I'm happy to be corrected, but my understanding was that kernel devs made an effort not to mess with things exported via "EXPORT_SYMBOL", but things exported via "EXPORT_SYMBOL_GPL" were fair game. I guess maybe my patch calling it "ABI" is a stronger statement than that, though. Doing a little more research, nobody wants to say that things exported with "EXPORT_SYMBOL" are ABI, they just want to say that we make an effort to have them be more stable. So certainly I should adjust my patch series not to call it ABI, but I'm still on the fence about whether I should rename this or not. I'd love to hear other opinions. This rename actually would be a lot easier than the touch_nmi_watchdog() one since the code referencing the name "arch_touch_nmi_watchdog" isn't spread so broadly through the kernel. [1] https://lore.kernel.org/r/ZFErmshcrcikrSU1@alley -Doug
Re: [PATCH v4 13/17] watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Hi, On Thu, May 4, 2023 at 7:36 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > From: Colin Cross > > > > Implement a hardlockup detector that doesn't doesn't need any extra > > arch-specific support code to detect lockups. Instead of using > > something arch-specific we will use the buddy system, where each CPU > > watches out for another one. Specifically, each CPU will use its > > softlockup hrtimer to check that the next CPU is processing hrtimer > > interrupts by verifying that a counter is increasing. > > Powerpc's watchdog has an SMP checker, did you see it? No, I wasn't aware of it. Interesting, it seems to basically enable both types of hardlockup detectors together. If that really catches more lockups, it seems like we could do the same thing for the buddy system. If people want, I don't think it would be very hard to make the buddy system _not_ exclusive of the perf system. Instead of having the buddy system implement the "weak" functions I could just call the buddy functions in the right places directly and leave the "weak" functions for a more traditional hardlockup detector to implement. Opinions? Maybe after all this lands, the powerpc watchdog could move to use the common code? As evidenced by this patch series, there's not really a reason for the SMP detection to be platform specific. > It's all to > all rather than buddy which makes it more complicated but arguably > bit better functionality. Can you come up with an example crash where the "all to all" would work better than the simple buddy system provided by this patch? It seems like they would be equivalent, but I could be missing something. Specifically they both need at least one non-locked-up CPU to detect a problem. If one or more CPUs is locked up then we'll always detect it. I suppose maybe you could provide a better error message at lockup time saying that several CPUs were locked up and that could be helpful. For now, I'd keep the current buddy system the way it is and if you want to provide a patch improving things to be "all-to-all" in the future that would be interesting to review.
RE: [PATCH] mm: kfence: Fix false positives on big endian
From: Michael Ellerman
> Sent: 05 May 2023 04:51
>
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U64 encodes the
> address of each byte in its value, so it needs to be byte swapped on big
> endian machines.
>
> The compiler is smart enough to do the le64_to_cpu() at compile time, so
> there is no runtime overhead.
>
> Fixes: 1ba3cbf3ec3b ("mm: kfence: improve the performance of __kfence_alloc()
> and __kfence_free()")
> Signed-off-by: Michael Ellerman
> ---
> mm/kfence/kfence.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h
> index 2aafc46a4aaf..392fb273e7bd 100644
> --- a/mm/kfence/kfence.h
> +++ b/mm/kfence/kfence.h
> @@ -29,7 +29,7 @@
> * canary of every 8 bytes is the same. 64-bit memory can be filled and
> checked
> * at a time instead of byte by byte to improve performance.
> */
> -#define KFENCE_CANARY_PATTERN_U64 ((u64)0x ^
> (u64)(0x0706050403020100))
> +#define KFENCE_CANARY_PATTERN_U64 ((u64)0x ^
> (u64)(le64_to_cpu(0x0706050403020100)))
What at the (u64) casts for?
The constants should probably have a ul (or ull) suffix.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH v4 1/3] PCI/AER: Factor out interrupt toggling into helpers
On Mon, 24 Apr 2023 13:52:47 +0800
Kai-Heng Feng wrote:
> There are many places that enable and disable AER interrput, so move
interrupt
> them into helpers.
Otherwise looks like a good clean up to me.
FWIW
Reviewed-by: Jonathan Cameron
>
> Reviewed-by: Mika Westerberg
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/pci/pcie/aer.c | 45 +-
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index f6c24ded134c..1420e1f27105 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1227,6 +1227,28 @@ static irqreturn_t aer_irq(int irq, void *context)
> return IRQ_WAKE_THREAD;
> }
>
> +static void aer_enable_irq(struct pci_dev *pdev)
> +{
> + int aer = pdev->aer_cap;
> + u32 reg32;
> +
> + /* Enable Root Port's interrupt in response to error messages */
> + pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> + reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> + pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> +}
> +
> +static void aer_disable_irq(struct pci_dev *pdev)
> +{
> + int aer = pdev->aer_cap;
> + u32 reg32;
> +
> + /* Disable Root's interrupt in response to error messages */
> + pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> + reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> + pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> +}
> +
> /**
> * aer_enable_rootport - enable Root Port's interrupts when receiving
> messages
> * @rpc: pointer to a Root Port data structure
> @@ -1256,10 +1278,7 @@ static void aer_enable_rootport(struct aer_rpc *rpc)
> pci_read_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, );
> pci_write_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, reg32);
>
> - /* Enable Root Port's interrupt in response to error messages */
> - pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_enable_irq(pdev);
> }
>
> /**
> @@ -1274,10 +1293,7 @@ static void aer_disable_rootport(struct aer_rpc *rpc)
> int aer = pdev->aer_cap;
> u32 reg32;
>
> - /* Disable Root's interrupt in response to error messages */
> - pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_disable_irq(pdev);
>
> /* Clear Root's error status reg */
> pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_STATUS, );
> @@ -1372,12 +1388,8 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
> *dev)
>*/
> aer = root ? root->aer_cap : 0;
>
> - if ((host->native_aer || pcie_ports_native) && aer) {
> - /* Disable Root's interrupt in response to error messages */
> - pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
> - }
> + if ((host->native_aer || pcie_ports_native) && aer)
> + aer_disable_irq(root);
>
> if (type == PCI_EXP_TYPE_RC_EC || type == PCI_EXP_TYPE_RC_END) {
> rc = pcie_reset_flr(dev, PCI_RESET_DO_RESET);
> @@ -1396,10 +1408,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
> *dev)
> pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, );
> pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
>
> - /* Enable Root Port's interrupt in response to error messages */
> - pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_enable_irq(root);
> }
>
> return rc ? PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_RECOVERED;
Re: [PATCH 0/4] powerpc/64: ELFv2 conversion
Michael Ellerman wrote: Christophe Leroy writes: Le 05/05/2023 à 09:18, Nicholas Piggin a écrit : This series has the steps to remove ELFv1 from the kernel build. Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is really a separate issue that concerns userspace. 4 removes v1 support. Super glad to see this! I see CONFIG_MPROFILE_KERNEL is restricted to LITTLE_ENDIAN. Is that correct ? Don't we have mprofile_kernel as well on BIG ENDIAN once switched to ABI v2 ? If so, can we drop the -pg based profiling completely, or is CLANG still not supporting mprofile_kernel ? Clang does not support -mprofile-kernel. AIUI they would like us to switch to -fpatchable-function-entry which could then be supported on GCC & clang. That would be a nice cleanup but also a bunch of work that no one has found time to do. https://github.com/linuxppc/issues/issues/447 https://github.com/llvm/llvm-project/issues/57031 GCC's support for -fpatchable-function-entry needed fixes for ABIv2, which have landed in the recent v13.1 release. I am looking into adding support for that. So for now we need to keep the -pg based version. Indeed, but removing elf v1 support does help cleaning up and simplifying some of the tracing code. Much of the -pg code is already separate, so it should be easy to drop that once clang picks up support for -fpatchable-function-entry. - Naveen
Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1
On Thu, May 4, 2023 at 11:52 PM Christian Zigotzky
wrote:
>
> On 03 May 2023 at 08:15 pm, Rob Herring wrote:
> > On Wed, May 3, 2023 at 12:40 PM Christian Zigotzky
> > wrote:
> >>
> >>
> >>> On 3. May 2023, at 18:51, Rob Herring wrote:
> >>>
> >>> On Wed, May 3, 2023 at 11:27 AM Christophe Leroy
> >>> wrote:
> +Rob as he's the commit's Author.
>
> > Le 03/05/2023 à 17:46, Christian Zigotzky a écrit :
> > On 02 May 2023 at 11:28 am, Michael Ellerman wrote:
> >> Christian Zigotzky writes:
> >>> Hello,
> >>>
> >>> Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1
> >>> [2].
> >>>
> >>> The kernel hangs right after the booting Linux via __start() @
> >>> 0x ...
> >>>
> >>> I was able to revert the PowerPC updates 6.4-1 [2] with the following
> >>> command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1
> >>>
> >>> After a re-compiling, the kernel boots without any problems without
> >>> the
> >>> PowerPC updates 6.4-1 [2].
> >>>
> >>> Could you please explain me, what you have done in the boot area?
> >> There's a few possibilities, but nothing obvious.
> >>
> >> To begin with can you please test the following commits?
> >>
> >> 77e69ee7ce07
> >> e4ab08be5b49
> >> eeac8ede1755
> >>
> >> cheers
> > git revert e4ab08be5b4902e5b350b0e1e1a3c25eb21d76d4
> >
> > [master 0086e2cbbec0] Revert "powerpc/isa-bridge: Remove open coded
> > "ranges" parsing"
> > 1 file changed, 129 insertions(+), 37 deletions(-)
> >
> > After a recompiling it boots without any problems.
> >
> > e4ab08be5b49 -- powerpc/isa-bridge: Remove open coded "ranges" parsing
> > is the bad commit.
> >>> Could I get a DT file for this board?
> >>>
> >>> In the meantime, just revert this commit. I don't think I'll be able
> >>> to fix it before I'm out on sabbatical.
> >>>
> >>> Rob
> >> FYI:
> >>
> >> Darren Stevens wrote:
> >>
> >> The dtb passed by the CFE firmware has a number of issues, which up till
> >> now have been fixed by use of patches applied to the mainline kernel.
> >> This occasionally causes problems with changes made to mainline.
> > Changing the firmware is not the only way to modify the DT. Perhaps a
> > DT overlay would work better than carrying patches if the patches
> > aren't upstreamable. It kind of depends on how early you'd need to
> > apply the overlay and whether you'd need external phandles (aka
> > __symbols__ node, which the base DTB wouldn't support).
> >
> > Looking at the DT, I think this change might fix it. Can you test this
> > change:
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index e692809ff822..475b74413fdd 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -284,7 +284,7 @@ EXPORT_SYMBOL(of_range_to_resource);
> >
> > static int of_bus_isa_match(struct device_node *np)
> > {
> > - return of_node_name_eq(np, "isa");
> > + return of_node_is_type(np, "isa") || of_node_name_eq(np, "isa");
> > }
> >
> > static void of_bus_isa_count_cells(struct device_node *child,
> I tested this patch today but unfortunately the Nemo board doesn't boot.
Do you have a dmesg log with debug enabled for a successful boot? I
searched archives and forum, but couldn't find one. isa-bridge.c has
debug enabled so you should get a few messages.
>From looking at the DT, the isa node has no ranges, so the difference
in parsing code shouldn't even matter. You should be seeing this
message:
printk(KERN_ERR "no ISA IO ranges or unexpected isa range, "
"mapping 64k\n");
Rob
Re: [PATCH 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA
On Fri, May 5, 2023, at 07:47, Guo Ren wrote: > On Mon, Mar 27, 2023 at 8:15 PM Arnd Bergmann wrote: >> >> riscv also invalidates the caches before the transfer, which does >> not appear to serve any purpose. > Yes, we can't guarantee the CPU pre-load cache lines randomly during > dma working. > > But I've two purposes to keep invalidates before dma transfer: > - We clearly tell the CPU these cache lines are invalid. The caching > algorithm would use these invalid slots first instead of replacing > valid ones. > - Invalidating is very cheap. Actually, flush and clean have the same > performance in our machine. The main purpose of the series was to get consistent behavior on all machines, so I really don't want a custom optimization on one architecture. You make a good point about cacheline reuse after invalidation, but if we do that, I'd suggest doing this across all architectures. > So, how about: > > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index d919efab6eba..2c52fbc15064 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -22,8 +22,6 @@ void arch_sync_dma_for_device(phys_addr_t paddr, size_t > size, > ALT_CMO_OP(clean, vaddr, size, riscv_cbom_block_size); > break; > case DMA_FROM_DEVICE: > - ALT_CMO_OP(clean, vaddr, size, riscv_cbom_block_size); > - break; > case DMA_BIDIRECTIONAL: > ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); > break; This is something we can consider. Unfortunately, this is something that no architecture (except pa-risc, which has other problems) does at the moment, so we'd probably need to have a proper debate about this. We already have two conflicting ways to handle DMA_FROM_DEVICE, either invalidate/invalidate, or clean/invalidate. I can see that flush/invalidate may be a sensible option as well, but I'd want to have that discussion after the series is complete, so we can come to a generic solution that has the same documented behavior across all architectures. In particular, if we end up moving arm64 and riscv back to the traditional invalidate/invalidate for DMA_FROM_DEVICE and document that driver must not rely on buffers getting cleaned before a partial DMA_FROM_DEVICE, the question between clean or flush becomes moot as well. > @@ -42,7 +40,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size, > break; > case DMA_FROM_DEVICE: > case DMA_BIDIRECTIONAL: > /* I'm not sure all drivers have guaranteed cacheline > alignment. If not, this inval would cause problems */ > - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); > + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size); > break; This is my original patch, and I would not mix it with the other change. The problem with non-aligned DMA_BIDIRECTIONAL buffers in is that both flush and inval would be wrong if you get simultaneous writes from device and cpu to the same cache line, so there is no way to win this. Using inval instead of flush would at least work if the CPU data in the cacheline is read-only from the CPU, so that seems better than something that is always wrong. The documented API is that sharing the cache line is not allowed at all, so anything that would observe a difference between the two is also a bug. One idea that we have considered already is that we could overwrite the unused bits of the cacheline with poison values and/or mark them as invalid using KASAN for debugging purposes, to find drivers that already violate this. Arnd
Re: [PATCH v6 4/4] risc/purgatory: Add linker script
On Mon, May 01, 2023 at 09:54:43PM +0200, Ricardo Ribalda wrote:
> On Mon, 1 May 2023 at 19:41, Conor Dooley wrote:
> > On Mon, May 01, 2023 at 02:38:22PM +0200, Ricardo Ribalda wrote:
> > > If PGO is enabled, the purgatory ends up with multiple .text sections.
> > > This is not supported by kexec and crashes the system.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Fixes: 930457057abe ("kernel/kexec_file.c: split up
> > > __kexec_load_puragory")
> > > Signed-off-by: Ricardo Ribalda
> > > ---
> > > arch/riscv/purgatory/Makefile | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile
> > > index 5730797a6b40..cf3a44121a90 100644
> > > --- a/arch/riscv/purgatory/Makefile
> > > +++ b/arch/riscv/purgatory/Makefile
> > > @@ -35,6 +35,11 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS
> > > CFLAGS_string.o := -D__DISABLE_EXPORTS
> > > CFLAGS_ctype.o := -D__DISABLE_EXPORTS
> > >
> > > +# When profile optimization is enabled, llvm emits two different
> > > overlapping
> > > +# text sections, which is not supported by kexec. Remove profile
> > > optimization
> > > +# flags.
> > > +KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
> > > -fprofile-use=%,$(KBUILD_CFLAGS))
> >
> > With the caveat of not being au fait with the workings of either PGO or
> > of purgatory, how come you modify KBUILD_CFLAGS here rather than the
> > purgatory specific PURGATORY_CFLAGS that are used later in the file?
>
> Definitely, not a Makefile expert here, but when I tried this:
>
> @@ -35,6 +40,7 @@ PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
> PURGATORY_CFLAGS := -mcmodel=large -ffreestanding
> -fno-zero-initialized-in-bss -g0
> PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
> PURGATORY_CFLAGS += -fno-stack-protector
> +PURGATORY_CFLAGS := $(filter-out -fprofile-sample-use=%
> -fprofile-use=%,$(KBUILD_CFLAGS))
>
> It did not work.
Unfortunately I am oh-so-far from an expert on this kind of thing, but I
had thought that PURGATORY_CFLAGS_REMOVE was intended for this sort of
purpose.
> Fixes: bde971a83bbf ("KVM: arm64: nvhe: Fix build with profile optimization")
>
> does this approach, so this is what I tried and worked.
That doesn't have a specific CFLAGS though afaict.
Perhaps Nick etc have a more informed opinion here than I do, sorry.
Thanks,
Conor.
> > > +
> > > # When linking purgatory.ro with -r unresolved symbols are not checked,
> > > # also link a purgatory.chk binary without -r to check for unresolved
> > > symbols.
> > > PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
> > >
> > > --
> > > 2.40.1.495.gc816e09b53d-goog
> > >
> > >
> > > ___
> > > linux-riscv mailing list
> > > linux-ri...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
>
>
> --
> Ricardo Ribalda
signature.asc
Description: PGP signature
Re: [PATCH 0/4] powerpc/64: ELFv2 conversion
Christophe Leroy writes: > Le 05/05/2023 à 09:18, Nicholas Piggin a écrit : >> This series has the steps to remove ELFv1 from the kernel build. >> Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is >> really a separate issue that concerns userspace. 4 removes v1 >> support. > > I see CONFIG_MPROFILE_KERNEL is restricted to LITTLE_ENDIAN. Is that > correct ? Don't we have mprofile_kernel as well on BIG ENDIAN once > switched to ABI v2 ? If so, can we drop the -pg based profiling > completely, or is CLANG still not supporting mprofile_kernel ? Clang does not support -mprofile-kernel. AIUI they would like us to switch to -fpatchable-function-entry which could then be supported on GCC & clang. That would be a nice cleanup but also a bunch of work that no one has found time to do. https://github.com/linuxppc/issues/issues/447 https://github.com/llvm/llvm-project/issues/57031 So for now we need to keep the -pg based version. cheers
Re: [PATCH] mm: kfence: Fix false positives on big endian
Marco Elver writes:
> On Fri, 5 May 2023 at 05:51, Michael Ellerman wrote:
>>
>> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
>> __kfence_alloc() and __kfence_free()"), kfence reports failures in
>> random places at boot on big endian machines.
>>
>> The problem is that the new KFENCE_CANARY_PATTERN_U64 encodes the
>> address of each byte in its value, so it needs to be byte swapped on big
>> endian machines.
>>
>> The compiler is smart enough to do the le64_to_cpu() at compile time, so
>> there is no runtime overhead.
>>
>> Fixes: 1ba3cbf3ec3b ("mm: kfence: improve the performance of
>> __kfence_alloc() and __kfence_free()")
>> Signed-off-by: Michael Ellerman
>
> Reviewed-by: Marco Elver
Thanks.
> Andrew, is the Fixes enough to make it to stable as well or do we also
> need Cc: stable?
That commit is not in any releases yet (or even an rc), so as long as it
gets picked up before v6.4 then it won't need to go to stable.
cheers
Re: [PATCH] mm: kfence: Fix false positives on big endian
On Fri, May 5, 2023 at 5:51 AM Michael Ellerman wrote:
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U64 encodes the
> address of each byte in its value, so it needs to be byte swapped on big
> endian machines.
>
> The compiler is smart enough to do the le64_to_cpu() at compile time, so
> there is no runtime overhead.
>
> Fixes: 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()")
> Signed-off-by: Michael Ellerman
>
Reviewed-by: Alexander Potapenko
Re: [PATCH 0/4] powerpc/64: ELFv2 conversion
Le 05/05/2023 à 09:18, Nicholas Piggin a écrit : > This series has the steps to remove ELFv1 from the kernel build. > Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is > really a separate issue that concerns userspace. 4 removes v1 > support. I see CONFIG_MPROFILE_KERNEL is restricted to LITTLE_ENDIAN. Is that correct ? Don't we have mprofile_kernel as well on BIG ENDIAN once switched to ABI v2 ? If so, can we drop the -pg based profiling completely, or is CLANG still not supporting mprofile_kernel ? Christophe > > Would like to try getting patch 1 in as a fix, then 2,3 merged in > the next merge window. > > Thanks, > Nick > > Nicholas Piggin (4): >powerpc/64: Force ELFv2 when building with LLVM linker >powerpc/64: Make ELFv2 the default for big-endian builds >powerpc/64s: Remove support for ELFv1 little endian userspace >powerpc/64: Remove support for kernel's built with ELFv1 ABI > > arch/powerpc/Kconfig | 21 -- > arch/powerpc/Makefile| 15 + > arch/powerpc/boot/Makefile | 4 +- > arch/powerpc/include/asm/code-patching.h | 36 ++ > arch/powerpc/include/asm/elf.h | 6 ++ > arch/powerpc/include/asm/kfence.h| 4 -- > arch/powerpc/include/asm/linkage.h | 9 --- > arch/powerpc/include/asm/module.h| 3 - > arch/powerpc/include/asm/ppc_asm.h | 38 +-- > arch/powerpc/include/asm/ptrace.h| 17 + > arch/powerpc/include/asm/sections.h | 4 -- > arch/powerpc/include/asm/thread_info.h | 6 +- > arch/powerpc/kernel/exceptions-64s.S | 2 +- > arch/powerpc/kernel/fadump.c | 6 +- > arch/powerpc/kernel/head_64.S| 5 +- > arch/powerpc/kernel/interrupt_64.S | 4 -- > arch/powerpc/kernel/kprobes.c| 39 +-- > arch/powerpc/kernel/misc_64.S| 4 -- > arch/powerpc/kernel/module.c | 8 --- > arch/powerpc/kernel/module_64.c | 84 > arch/powerpc/kernel/trace/ftrace.c | 10 --- > arch/powerpc/kernel/vdso/Makefile| 2 +- > arch/powerpc/kernel/vdso/gettimeofday.S | 2 +- > arch/powerpc/kernel/vmlinux.lds.S| 8 --- > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 36 +- > arch/powerpc/kvm/book3s_interrupts.S | 14 ++-- > arch/powerpc/kvm/book3s_rmhandlers.S | 12 +--- > arch/powerpc/net/bpf_jit.h | 6 -- > arch/powerpc/net/bpf_jit_comp.c | 14 ++-- > arch/powerpc/net/bpf_jit_comp64.c| 13 ++-- > arch/powerpc/platforms/Kconfig.cputype | 6 -- > drivers/crypto/vmx/Makefile | 4 -- > kernel/extable.c | 2 +- > kernel/trace/ftrace.c| 12 > 34 files changed, 79 insertions(+), 377 deletions(-) >
Re: [RFC PATCH 4/4] powerpc/64: Remove support for kernel's built with ELFv1 ABI
Le 05/05/2023 à 09:18, Nicholas Piggin a écrit : > User code must still support ELFv1, e.g., see is_elf2_task(). > > This one should wait a while until ELFv2 fallout settles, so > just posting it out of interest. Can't ELFv1 user code run on an ELFv2 kernel ? Christophe > > Thanks, > Nick > --- > arch/powerpc/Kconfig | 19 -- > arch/powerpc/Makefile| 15 + > arch/powerpc/boot/Makefile | 4 +- > arch/powerpc/include/asm/code-patching.h | 36 ++ > arch/powerpc/include/asm/kfence.h| 4 -- > arch/powerpc/include/asm/linkage.h | 9 --- > arch/powerpc/include/asm/module.h| 3 - > arch/powerpc/include/asm/ppc_asm.h | 38 +-- > arch/powerpc/include/asm/ptrace.h| 17 + > arch/powerpc/include/asm/sections.h | 4 -- > arch/powerpc/kernel/exceptions-64s.S | 2 +- > arch/powerpc/kernel/fadump.c | 6 +- > arch/powerpc/kernel/head_64.S| 5 +- > arch/powerpc/kernel/interrupt_64.S | 4 -- > arch/powerpc/kernel/kprobes.c| 39 +-- > arch/powerpc/kernel/misc_64.S| 4 -- > arch/powerpc/kernel/module.c | 8 --- > arch/powerpc/kernel/module_64.c | 84 > arch/powerpc/kernel/trace/ftrace.c | 10 --- > arch/powerpc/kernel/vdso/Makefile| 2 +- > arch/powerpc/kernel/vdso/gettimeofday.S | 2 +- > arch/powerpc/kernel/vmlinux.lds.S| 8 --- > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 36 +- > arch/powerpc/kvm/book3s_interrupts.S | 14 ++-- > arch/powerpc/kvm/book3s_rmhandlers.S | 12 +--- > arch/powerpc/net/bpf_jit.h | 6 -- > arch/powerpc/net/bpf_jit_comp.c | 14 ++-- > arch/powerpc/net/bpf_jit_comp64.c| 13 ++-- > arch/powerpc/platforms/Kconfig.cputype | 6 -- > drivers/crypto/vmx/Makefile | 4 -- > kernel/extable.c | 2 +- > kernel/trace/ftrace.c| 12 > 32 files changed, 68 insertions(+), 374 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index a64bfd9b8a1d..6cbcaf1d01a6 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -1,9 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > source "arch/powerpc/platforms/Kconfig.cputype" > > -config CC_HAS_ELFV2 > - def_bool PPC64 && $(cc-option, -mabi=elfv2) > - > config CC_HAS_PREFIXED > def_bool PPC64 && $(cc-option, -mcpu=power10 -mprefixed) > > @@ -232,7 +229,6 @@ config PPC > select HAVE_EFFICIENT_UNALIGNED_ACCESS > select HAVE_FAST_GUP > select HAVE_FTRACE_MCOUNT_RECORD > - select HAVE_FUNCTION_DESCRIPTORSif PPC64_ELF_ABI_V1 > select HAVE_FUNCTION_ERROR_INJECTION > select HAVE_FUNCTION_GRAPH_TRACER > select HAVE_FUNCTION_TRACER > @@ -623,21 +619,6 @@ config KEXEC_FILE > config ARCH_HAS_KEXEC_PURGATORY > def_bool KEXEC_FILE > > -config PPC64_BIG_ENDIAN_ELF_ABI_V2 > - prompt "Build big-endian kernel using ELF ABI V2" if LD_IS_BFD && EXPERT > - def_bool y > - depends on PPC64 && CPU_BIG_ENDIAN > - depends on CC_HAS_ELFV2 > - help > - This builds the kernel image using the "Power Architecture 64-Bit ELF > - V2 ABI Specification", which has a reduced stack overhead and faster > - function calls. This internal kernel ABI option does not affect > - userspace compatibility. > - > - The V2 ABI is standard for 64-bit little-endian, but for big-endian > - it is less well tested by kernel and toolchain. However some distros > - build userspace this way, and it can produce a functioning kernel. > - > config RELOCATABLE > bool "Build a relocatable kernel" > depends on PPC64 || (FLATMEM && (44x || PPC_85xx)) > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile > index dca73f673d70..8ddc779e675f 100644 > --- a/arch/powerpc/Makefile > +++ b/arch/powerpc/Makefile > @@ -72,10 +72,8 @@ endif > > ifdef CONFIG_PPC64 > ifndef CONFIG_CC_IS_CLANG > -cflags-$(CONFIG_PPC64_ELF_ABI_V1)+= $(call cc-option,-mabi=elfv1) > -cflags-$(CONFIG_PPC64_ELF_ABI_V1)+= $(call cc-option,-mcall-aixdesc) > -aflags-$(CONFIG_PPC64_ELF_ABI_V1)+= $(call cc-option,-mabi=elfv1) > -aflags-$(CONFIG_PPC64_ELF_ABI_V2)+= -mabi=elfv2 > +#Is this even needed? > +aflags-y += -mabi=elfv2 > endif > endif > > @@ -125,14 +123,7 @@ endif > endif > > CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no) > -ifdef CONFIG_PPC64_ELF_ABI_V2 > -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call > cc-option,-mcall-aixdesc)) > -else > -ifndef CONFIG_CC_IS_CLANG > -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) > -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc) > -endif > -endif > +CFLAGS-$(CONFIG_PPC64)
[PATCH] ASoC: fsl_sai: MCLK bind with TX/RX enable bit
On i.MX8MP, the sai MCLK is bound with TX/RX enable bit,
which means the TX/RE enable bit need to be enabled then
MCLK can be output on PAD.
Some codec (for example: WM8962) needs the MCLK output
earlier, otherwise there will be issue for codec
configuration.
Add new soc data "mclk_with_tere" for this platform and
enable the MCLK output in startup stage.
As "mclk_with_tere" only applied to i.MX8MP, currently
The soc data is shared with i.MX8MN, so need to add
an i.MX8MN own soc data with "mclk_with_tere" disabled.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_sai.c | 24 +---
sound/soc/fsl/fsl_sai.h | 2 ++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index abdaffb00fbd..d9344025dc16 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1400,7 +1400,9 @@ static int fsl_sai_probe(struct platform_device *pdev)
sai->cpu_dai_drv.symmetric_sample_bits = 0;
}
- if (of_property_read_bool(np, "fsl,sai-mclk-direction-output") &&
+ sai->mclk_direction_output = of_property_read_bool(np,
"fsl,sai-mclk-direction-output");
+
+ if (sai->mclk_direction_output &&
of_device_is_compatible(np, "fsl,imx6ul-sai")) {
gpr =
syscon_regmap_lookup_by_compatible("fsl,imx6ul-iomuxc-gpr");
if (IS_ERR(gpr)) {
@@ -1443,7 +1445,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
dev_warn(dev, "Error reading SAI version: %d\n", ret);
/* Select MCLK direction */
- if (of_property_read_bool(np, "fsl,sai-mclk-direction-output") &&
+ if (sai->mclk_direction_output &&
sai->soc_data->max_register >= FSL_SAI_MCTL) {
regmap_update_bits(sai->regmap, FSL_SAI_MCTL,
FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN);
@@ -1562,6 +1564,17 @@ static const struct fsl_sai_soc_data fsl_sai_imx8mm_data
= {
.max_register = FSL_SAI_MCTL,
};
+static const struct fsl_sai_soc_data fsl_sai_imx8mn_data = {
+ .use_imx_pcm = true,
+ .use_edma = false,
+ .fifo_depth = 128,
+ .reg_offset = 8,
+ .mclk0_is_mclk1 = false,
+ .pins = 8,
+ .flags = 0,
+ .max_register = FSL_SAI_MDIV,
+};
+
static const struct fsl_sai_soc_data fsl_sai_imx8mp_data = {
.use_imx_pcm = true,
.use_edma = false,
@@ -1571,6 +1584,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8mp_data
= {
.pins = 8,
.flags = 0,
.max_register = FSL_SAI_MDIV,
+ .mclk_with_tere = true,
};
static const struct fsl_sai_soc_data fsl_sai_imx8ulp_data = {
@@ -1606,7 +1620,7 @@ static const struct of_device_id fsl_sai_ids[] = {
{ .compatible = "fsl,imx8mm-sai", .data = _sai_imx8mm_data },
{ .compatible = "fsl,imx8mp-sai", .data = _sai_imx8mp_data },
{ .compatible = "fsl,imx8ulp-sai", .data = _sai_imx8ulp_data },
- { .compatible = "fsl,imx8mn-sai", .data = _sai_imx8mp_data },
+ { .compatible = "fsl,imx8mn-sai", .data = _sai_imx8mn_data },
{ .compatible = "fsl,imx93-sai", .data = _sai_imx93_data },
{ /* sentinel */ }
};
@@ -1671,6 +1685,10 @@ static int fsl_sai_runtime_resume(struct device *dev)
if (ret)
goto disable_rx_clk;
+ if (sai->soc_data->mclk_with_tere && sai->mclk_direction_output)
+ regmap_update_bits(sai->regmap, FSL_SAI_TCSR(ofs),
+ FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
+
return 0;
disable_rx_clk:
diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h
index 197748a888d5..3eb994aef36a 100644
--- a/sound/soc/fsl/fsl_sai.h
+++ b/sound/soc/fsl/fsl_sai.h
@@ -230,6 +230,7 @@ struct fsl_sai_soc_data {
bool use_imx_pcm;
bool use_edma;
bool mclk0_is_mclk1;
+ bool mclk_with_tere;
unsigned int fifo_depth;
unsigned int pins;
unsigned int reg_offset;
@@ -287,6 +288,7 @@ struct fsl_sai {
bool synchronous[2];
struct fsl_sai_dl_cfg *dl_cfg;
unsigned int dl_cfg_cnt;
+ bool mclk_direction_output;
unsigned int mclk_id[2];
unsigned int mclk_streams;
--
2.34.1
Re: [PATCH] mm: kfence: Fix false positives on big endian
On Fri, 5 May 2023 at 05:51, Michael Ellerman wrote:
>
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U64 encodes the
> address of each byte in its value, so it needs to be byte swapped on big
> endian machines.
>
> The compiler is smart enough to do the le64_to_cpu() at compile time, so
> there is no runtime overhead.
>
> Fixes: 1ba3cbf3ec3b ("mm: kfence: improve the performance of __kfence_alloc()
> and __kfence_free()")
> Signed-off-by: Michael Ellerman
Reviewed-by: Marco Elver
Andrew, is the Fixes enough to make it to stable as well or do we also
need Cc: stable?
Thanks,
-- Marco
> ---
> mm/kfence/kfence.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h
> index 2aafc46a4aaf..392fb273e7bd 100644
> --- a/mm/kfence/kfence.h
> +++ b/mm/kfence/kfence.h
> @@ -29,7 +29,7 @@
> * canary of every 8 bytes is the same. 64-bit memory can be filled and
> checked
> * at a time instead of byte by byte to improve performance.
> */
> -#define KFENCE_CANARY_PATTERN_U64 ((u64)0x ^
> (u64)(0x0706050403020100))
> +#define KFENCE_CANARY_PATTERN_U64 ((u64)0x ^
> (u64)(le64_to_cpu(0x0706050403020100)))
>
> /* Maximum stack depth for reports. */
> #define KFENCE_STACK_DEPTH 64
> --
> 2.40.1
>
[RFC PATCH 4/4] powerpc/64: Remove support for kernel's built with ELFv1 ABI
User code must still support ELFv1, e.g., see is_elf2_task(). This one should wait a while until ELFv2 fallout settles, so just posting it out of interest. Thanks, Nick --- arch/powerpc/Kconfig | 19 -- arch/powerpc/Makefile| 15 + arch/powerpc/boot/Makefile | 4 +- arch/powerpc/include/asm/code-patching.h | 36 ++ arch/powerpc/include/asm/kfence.h| 4 -- arch/powerpc/include/asm/linkage.h | 9 --- arch/powerpc/include/asm/module.h| 3 - arch/powerpc/include/asm/ppc_asm.h | 38 +-- arch/powerpc/include/asm/ptrace.h| 17 + arch/powerpc/include/asm/sections.h | 4 -- arch/powerpc/kernel/exceptions-64s.S | 2 +- arch/powerpc/kernel/fadump.c | 6 +- arch/powerpc/kernel/head_64.S| 5 +- arch/powerpc/kernel/interrupt_64.S | 4 -- arch/powerpc/kernel/kprobes.c| 39 +-- arch/powerpc/kernel/misc_64.S| 4 -- arch/powerpc/kernel/module.c | 8 --- arch/powerpc/kernel/module_64.c | 84 arch/powerpc/kernel/trace/ftrace.c | 10 --- arch/powerpc/kernel/vdso/Makefile| 2 +- arch/powerpc/kernel/vdso/gettimeofday.S | 2 +- arch/powerpc/kernel/vmlinux.lds.S| 8 --- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 36 +- arch/powerpc/kvm/book3s_interrupts.S | 14 ++-- arch/powerpc/kvm/book3s_rmhandlers.S | 12 +--- arch/powerpc/net/bpf_jit.h | 6 -- arch/powerpc/net/bpf_jit_comp.c | 14 ++-- arch/powerpc/net/bpf_jit_comp64.c| 13 ++-- arch/powerpc/platforms/Kconfig.cputype | 6 -- drivers/crypto/vmx/Makefile | 4 -- kernel/extable.c | 2 +- kernel/trace/ftrace.c| 12 32 files changed, 68 insertions(+), 374 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a64bfd9b8a1d..6cbcaf1d01a6 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -1,9 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 source "arch/powerpc/platforms/Kconfig.cputype" -config CC_HAS_ELFV2 - def_bool PPC64 && $(cc-option, -mabi=elfv2) - config CC_HAS_PREFIXED def_bool PPC64 && $(cc-option, -mcpu=power10 -mprefixed) @@ -232,7 +229,6 @@ config PPC select HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_FAST_GUP select HAVE_FTRACE_MCOUNT_RECORD - select HAVE_FUNCTION_DESCRIPTORSif PPC64_ELF_ABI_V1 select HAVE_FUNCTION_ERROR_INJECTION select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER @@ -623,21 +619,6 @@ config KEXEC_FILE config ARCH_HAS_KEXEC_PURGATORY def_bool KEXEC_FILE -config PPC64_BIG_ENDIAN_ELF_ABI_V2 - prompt "Build big-endian kernel using ELF ABI V2" if LD_IS_BFD && EXPERT - def_bool y - depends on PPC64 && CPU_BIG_ENDIAN - depends on CC_HAS_ELFV2 - help - This builds the kernel image using the "Power Architecture 64-Bit ELF - V2 ABI Specification", which has a reduced stack overhead and faster - function calls. This internal kernel ABI option does not affect - userspace compatibility. - - The V2 ABI is standard for 64-bit little-endian, but for big-endian - it is less well tested by kernel and toolchain. However some distros - build userspace this way, and it can produce a functioning kernel. - config RELOCATABLE bool "Build a relocatable kernel" depends on PPC64 || (FLATMEM && (44x || PPC_85xx)) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index dca73f673d70..8ddc779e675f 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -72,10 +72,8 @@ endif ifdef CONFIG_PPC64 ifndef CONFIG_CC_IS_CLANG -cflags-$(CONFIG_PPC64_ELF_ABI_V1) += $(call cc-option,-mabi=elfv1) -cflags-$(CONFIG_PPC64_ELF_ABI_V1) += $(call cc-option,-mcall-aixdesc) -aflags-$(CONFIG_PPC64_ELF_ABI_V1) += $(call cc-option,-mabi=elfv1) -aflags-$(CONFIG_PPC64_ELF_ABI_V2) += -mabi=elfv2 +#Is this even needed? +aflags-y += -mabi=elfv2 endif endif @@ -125,14 +123,7 @@ endif endif CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no) -ifdef CONFIG_PPC64_ELF_ABI_V2 -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc)) -else -ifndef CONFIG_CC_IS_CLANG -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc) -endif -endif +CFLAGS-$(CONFIG_PPC64) += -mabi=elfv2 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc)) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mlong-double-128) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 85cde5bf04b7..e6979f4ea571 100644 ---
[PATCH 3/4] powerpc/64s: Remove support for ELFv1 little endian userspace
ELFv2 was introduced together with little-endian. ELFv1 with LE has
never been a thing. The GNU toolchain can create such a beast, but
anyone doing that is a maniac who needs to be stopped so I consider
this patch a feature.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/elf.h | 6 ++
arch/powerpc/include/asm/thread_info.h | 6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 79f1c480b5eb..a26ca097d032 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -12,8 +12,14 @@
/*
* This is used to ensure we don't load something for the wrong architecture.
+ * 64le only supports ELFv2 64-bit binaries (64be supports v1 and v2).
*/
+#if defined(CONFIG_PPC64) && defined(CONFIG_CPU_LITTLE_ENDIAN)
+#define elf_check_arch(x) (((x)->e_machine == ELF_ARCH) && \
+ (((x)->e_flags & 0x3) == 0x2))
+#else
#define elf_check_arch(x) ((x)->e_machine == ELF_ARCH)
+#endif
#define compat_elf_check_arch(x) ((x)->e_machine == EM_PPC)
#define CORE_DUMP_USE_REGSET
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/powerpc/include/asm/thread_info.h
index bf5dde1a4114..bc5d39a835fe 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -183,9 +183,13 @@ static inline bool test_thread_local_flags(unsigned int
flags)
#define clear_tsk_compat_task(tsk) do { } while (0)
#endif
-#if defined(CONFIG_PPC64)
+#ifdef CONFIG_PPC64
+#ifdef CONFIG_CPU_BIG_ENDIAN
#define is_elf2_task() (test_thread_flag(TIF_ELF2ABI))
#else
+#define is_elf2_task() (1)
+#endif
+#else
#define is_elf2_task() (0)
#endif
--
2.40.1
[PATCH 2/4] powerpc/64: Make ELFv2 the default for big-endian builds
All supported toolchains now support ELFv2 on big-endian, so flip the default on this and hide the option behind EXPERT for the purpose of bug hunting. Signed-off-by: Nicholas Piggin --- arch/powerpc/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e5d81645c902..a64bfd9b8a1d 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -624,9 +624,8 @@ config ARCH_HAS_KEXEC_PURGATORY def_bool KEXEC_FILE config PPC64_BIG_ENDIAN_ELF_ABI_V2 - prompt "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" if LD_IS_BFD - bool - default y if LD_IS_LLD + prompt "Build big-endian kernel using ELF ABI V2" if LD_IS_BFD && EXPERT + def_bool y depends on PPC64 && CPU_BIG_ENDIAN depends on CC_HAS_ELFV2 help -- 2.40.1
[PATCH 1/4] powerpc/64: Force ELFv2 when building with LLVM linker
The LLVM linker does not support ELFv1 at all, so BE kernels must be built with ELFv2. The LLD version check was added to be conservative, but previous LLD versions would simply fail to link ELFv1 entirely. The only would be to require LLD >= 15 for BE builds, but let's instead remove that restriction until proven otherwise (LLD 14.0 links a booting ELFv2 BE vmlinux for me). The minimum binutils has increased such that ELFv2 is always supported, so remove that check while we're here. Cc: Nathan Chancellor Signed-off-by: Nicholas Piggin --- arch/powerpc/Kconfig | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index acbd5d77..e5d81645c902 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -624,10 +624,11 @@ config ARCH_HAS_KEXEC_PURGATORY def_bool KEXEC_FILE config PPC64_BIG_ENDIAN_ELF_ABI_V2 - bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" + prompt "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" if LD_IS_BFD + bool + default y if LD_IS_LLD depends on PPC64 && CPU_BIG_ENDIAN depends on CC_HAS_ELFV2 - depends on LD_VERSION >= 22400 || LLD_VERSION >= 15 help This builds the kernel image using the "Power Architecture 64-Bit ELF V2 ABI Specification", which has a reduced stack overhead and faster @@ -638,8 +639,6 @@ config PPC64_BIG_ENDIAN_ELF_ABI_V2 it is less well tested by kernel and toolchain. However some distros build userspace this way, and it can produce a functioning kernel. - This requires GCC and binutils 2.24 or newer. - config RELOCATABLE bool "Build a relocatable kernel" depends on PPC64 || (FLATMEM && (44x || PPC_85xx)) -- 2.40.1
[PATCH 0/4] powerpc/64: ELFv2 conversion
This series has the steps to remove ELFv1 from the kernel build. Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is really a separate issue that concerns userspace. 4 removes v1 support. Would like to try getting patch 1 in as a fix, then 2,3 merged in the next merge window. Thanks, Nick Nicholas Piggin (4): powerpc/64: Force ELFv2 when building with LLVM linker powerpc/64: Make ELFv2 the default for big-endian builds powerpc/64s: Remove support for ELFv1 little endian userspace powerpc/64: Remove support for kernel's built with ELFv1 ABI arch/powerpc/Kconfig | 21 -- arch/powerpc/Makefile| 15 + arch/powerpc/boot/Makefile | 4 +- arch/powerpc/include/asm/code-patching.h | 36 ++ arch/powerpc/include/asm/elf.h | 6 ++ arch/powerpc/include/asm/kfence.h| 4 -- arch/powerpc/include/asm/linkage.h | 9 --- arch/powerpc/include/asm/module.h| 3 - arch/powerpc/include/asm/ppc_asm.h | 38 +-- arch/powerpc/include/asm/ptrace.h| 17 + arch/powerpc/include/asm/sections.h | 4 -- arch/powerpc/include/asm/thread_info.h | 6 +- arch/powerpc/kernel/exceptions-64s.S | 2 +- arch/powerpc/kernel/fadump.c | 6 +- arch/powerpc/kernel/head_64.S| 5 +- arch/powerpc/kernel/interrupt_64.S | 4 -- arch/powerpc/kernel/kprobes.c| 39 +-- arch/powerpc/kernel/misc_64.S| 4 -- arch/powerpc/kernel/module.c | 8 --- arch/powerpc/kernel/module_64.c | 84 arch/powerpc/kernel/trace/ftrace.c | 10 --- arch/powerpc/kernel/vdso/Makefile| 2 +- arch/powerpc/kernel/vdso/gettimeofday.S | 2 +- arch/powerpc/kernel/vmlinux.lds.S| 8 --- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 36 +- arch/powerpc/kvm/book3s_interrupts.S | 14 ++-- arch/powerpc/kvm/book3s_rmhandlers.S | 12 +--- arch/powerpc/net/bpf_jit.h | 6 -- arch/powerpc/net/bpf_jit_comp.c | 14 ++-- arch/powerpc/net/bpf_jit_comp64.c| 13 ++-- arch/powerpc/platforms/Kconfig.cputype | 6 -- drivers/crypto/vmx/Makefile | 4 -- kernel/extable.c | 2 +- kernel/trace/ftrace.c| 12 34 files changed, 79 insertions(+), 377 deletions(-) -- 2.40.1
