[PATCH 3/6] powerpc/secvar: Handle format string in the consumer

2022-12-27 Thread Russell Currey
The code that handles the format string in secvar-sysfs.c is entirely
OPAL specific, so create a new "format" op in secvar_operations to make
the secvar code more generic.  No functional change.

Signed-off-by: Russell Currey 
---
 arch/powerpc/include/asm/secvar.h|  1 +
 arch/powerpc/kernel/secvar-sysfs.c   | 21 +---
 arch/powerpc/platforms/powernv/opal-secvar.c | 25 
 3 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/include/asm/secvar.h 
b/arch/powerpc/include/asm/secvar.h
index 4cc35b58b986..3b7e5a3625bd 100644
--- a/arch/powerpc/include/asm/secvar.h
+++ b/arch/powerpc/include/asm/secvar.h
@@ -20,6 +20,7 @@ struct secvar_operations {
uint64_t keybufsize);
int (*set)(const char *key, uint64_t key_len, u8 *data,
   uint64_t data_size);
+   ssize_t (*format)(char *buf);
 };
 
 #ifdef CONFIG_PPC_SECURE_BOOT
diff --git a/arch/powerpc/kernel/secvar-sysfs.c 
b/arch/powerpc/kernel/secvar-sysfs.c
index 1ee4640a2641..daf28b11866f 100644
--- a/arch/powerpc/kernel/secvar-sysfs.c
+++ b/arch/powerpc/kernel/secvar-sysfs.c
@@ -21,26 +21,7 @@ static struct kset *secvar_kset;
 static ssize_t format_show(struct kobject *kobj, struct kobj_attribute *attr,
   char *buf)
 {
-   ssize_t rc = 0;
-   struct device_node *node;
-   const char *format;
-
-   node = of_find_compatible_node(NULL, NULL, "ibm,secvar-backend");
-   if (!of_device_is_available(node)) {
-   rc = -ENODEV;
-   goto out;
-   }
-
-   rc = of_property_read_string(node, "format", );
-   if (rc)
-   goto out;
-
-   rc = sprintf(buf, "%s\n", format);
-
-out:
-   of_node_put(node);
-
-   return rc;
+   return secvar_ops->format(buf);
 }
 
 
diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c 
b/arch/powerpc/platforms/powernv/opal-secvar.c
index 14133e120bdd..cd5b5c06c091 100644
--- a/arch/powerpc/platforms/powernv/opal-secvar.c
+++ b/arch/powerpc/platforms/powernv/opal-secvar.c
@@ -101,10 +101,35 @@ static int opal_set_variable(const char *key, uint64_t 
ksize, u8 *data,
return opal_status_to_err(rc);
 }
 
+static ssize_t opal_secvar_format(char *buf)
+{
+   ssize_t rc = 0;
+   struct device_node *node;
+   const char *format;
+
+   node = of_find_compatible_node(NULL, NULL, "ibm,secvar-backend");
+   if (!of_device_is_available(node)) {
+   rc = -ENODEV;
+   goto out;
+   }
+
+   rc = of_property_read_string(node, "format", );
+   if (rc)
+   goto out;
+
+   rc = sprintf(buf, "%s\n", format);
+
+out:
+   of_node_put(node);
+
+   return rc;
+}
+
 static const struct secvar_operations opal_secvar_ops = {
.get = opal_get_variable,
.get_next = opal_get_next_variable,
.set = opal_set_variable,
+   .format = opal_secvar_format,
 };
 
 static int opal_secvar_probe(struct platform_device *pdev)
-- 
2.38.1



[PATCH 5/6] powerpc/secvar: Extend sysfs to include config vars

2022-12-27 Thread Russell Currey
The forthcoming pseries consumer of the secvar API wants to expose a
number of config variables.  Allowing secvar implementations to provide
their own sysfs attributes makes it easy for consumers to expose what
they need to.

This is not being used by the OPAL secvar implementation at present, and
the config directory will not be created if no attributes are set.

Signed-off-by: Russell Currey 
---
I played around with adding an API call to facilitate a more generic
key/value interface for config variables and it seemed like unnecessary
complexity.  I think this is cleaner.  If there was ever a secvar
interface other than sysfs we'd have to rework it, though.

 arch/powerpc/include/asm/secvar.h  |  3 +++
 arch/powerpc/kernel/secvar-sysfs.c | 40 ++
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/secvar.h 
b/arch/powerpc/include/asm/secvar.h
index 92d2c051918b..250e7066b6da 100644
--- a/arch/powerpc/include/asm/secvar.h
+++ b/arch/powerpc/include/asm/secvar.h
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 
 extern const struct secvar_operations *secvar_ops;
 
@@ -27,10 +28,12 @@ struct secvar_operations {
 #ifdef CONFIG_PPC_SECURE_BOOT
 
 extern void set_secvar_ops(const struct secvar_operations *ops);
+extern void set_secvar_config_attrs(const struct attribute **attrs);
 
 #else
 
 static inline void set_secvar_ops(const struct secvar_operations *ops) { }
+static inline void set_secvar_config_attrs(const struct attribute **attrs) { }
 
 #endif
 
diff --git a/arch/powerpc/kernel/secvar-sysfs.c 
b/arch/powerpc/kernel/secvar-sysfs.c
index ea408763dc78..0c3790345403 100644
--- a/arch/powerpc/kernel/secvar-sysfs.c
+++ b/arch/powerpc/kernel/secvar-sysfs.c
@@ -15,9 +15,17 @@
 
 #define NAME_MAX_SIZE 1024
 
+const struct attribute **secvar_config_attrs __ro_after_init = NULL;
+
 static struct kobject *secvar_kobj;
 static struct kset *secvar_kset;
 
+void set_secvar_config_attrs(const struct attribute **attrs)
+{
+   WARN_ON_ONCE(secvar_config_attrs);
+   secvar_config_attrs = attrs;
+}
+
 static ssize_t format_show(struct kobject *kobj, struct kobj_attribute *attr,
   char *buf)
 {
@@ -134,6 +142,16 @@ static int update_kobj_size(void)
return 0;
 }
 
+static int secvar_sysfs_config(struct kobject *kobj)
+{
+   struct attribute_group config_group = {
+   .name = "config",
+   .attrs = (struct attribute **)secvar_config_attrs,
+   };
+
+   return sysfs_create_group(kobj, _group);
+}
+
 static int secvar_sysfs_load(void)
 {
char *name;
@@ -196,26 +214,38 @@ static int secvar_sysfs_init(void)
 
rc = sysfs_create_file(secvar_kobj, _attr.attr);
if (rc) {
-   kobject_put(secvar_kobj);
-   return -ENOMEM;
+   pr_err("secvar: Failed to create format object\n");
+   rc = -ENOMEM;
+   goto err;
}
 
secvar_kset = kset_create_and_add("vars", NULL, secvar_kobj);
if (!secvar_kset) {
pr_err("secvar: sysfs kobject registration failed.\n");
-   kobject_put(secvar_kobj);
-   return -ENOMEM;
+   rc = -ENOMEM;
+   goto err;
}
 
rc = update_kobj_size();
if (rc) {
pr_err("Cannot read the size of the attribute\n");
-   return rc;
+   goto err;
+   }
+
+   if (secvar_config_attrs) {
+   rc = secvar_sysfs_config(secvar_kobj);
+   if (rc) {
+   pr_err("secvar: Failed to create config directory\n");
+   goto err;
+   }
}
 
secvar_sysfs_load();
 
return 0;
+err:
+   kobject_put(secvar_kobj);
+   return rc;
 }
 
 late_initcall(secvar_sysfs_init);
-- 
2.38.1



[PATCH 1/6] powerpc/pseries: Log hcall return codes for PLPKS debug

2022-12-27 Thread Russell Currey
The plpks code converts hypervisor return codes into their Linux
equivalents so that users can understand them.  Having access to the
original return codes is really useful for debugging, so add a
pr_debug() so we don't lose information from the conversion.

Signed-off-by: Russell Currey 
---
 arch/powerpc/platforms/pseries/plpks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/plpks.c 
b/arch/powerpc/platforms/pseries/plpks.c
index 9e4401aabf4f..820218eb894f 100644
--- a/arch/powerpc/platforms/pseries/plpks.c
+++ b/arch/powerpc/platforms/pseries/plpks.c
@@ -131,6 +131,8 @@ static int pseries_status_to_err(int rc)
err = -EINVAL;
}
 
+   pr_debug("Converted hypervisor code %d to Linux %d\n", rc, err);
+
return err;
 }
 
-- 
2.38.1



[PATCH 2/6] powerpc/secvar: WARN_ON_ONCE() if multiple secvar ops are set

2022-12-27 Thread Russell Currey
The secvar code only supports one consumer at a time.

Multiple consumers aren't possible at this point in time, but we'd want
it to be obvious if it ever could happen.

Signed-off-by: Russell Currey 
---
 arch/powerpc/kernel/secvar-ops.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/secvar-ops.c b/arch/powerpc/kernel/secvar-ops.c
index 6a29777d6a2d..aa1b2adc2710 100644
--- a/arch/powerpc/kernel/secvar-ops.c
+++ b/arch/powerpc/kernel/secvar-ops.c
@@ -8,10 +8,12 @@
 
 #include 
 #include 
+#include 
 
-const struct secvar_operations *secvar_ops __ro_after_init;
+const struct secvar_operations *secvar_ops __ro_after_init = NULL;
 
 void set_secvar_ops(const struct secvar_operations *ops)
 {
+   WARN_ON_ONCE(secvar_ops);
secvar_ops = ops;
 }
-- 
2.38.1



[PATCH 0/6] pseries dynamic secure boot interface using secvar

2022-12-27 Thread Russell Currey
This series exposes an interface to userspace for reading and writing
secure variables contained within the PowerVM LPAR Platform KeyStore
(PLPKS) for the purpose of configuring dynamic secure boot.

This series builds on past work by Nayna Jain[0] in exposing PLPKS
variables to userspace.  Rather than being a generic interface for
interacting with the keystore, however, we use the existing powerpc
secvar infrastructure to only expose objects in the keystore used
for dynamic secure boot.  This has the benefit of leveraging an
existing interface and making the implementation relatively minimal.

This series needs to be applied on top of Andrew's recent bugfix
series[1].

There are a few relevant details to note about the implementation:

 * New additions to the secvar API, format() and max_size()
 * New optional sysfs directory "config/" for arbitrary ASCII variables
 * Some OPAL-specific code has been relocated from secvar-sysfs.c to
powernv platform code.  Would appreciate any powernv testing!
 * Variable names are fixed and only those used for secure boot are
exposed.  This is not a generic PLPKS interface, but also
doesn't preclude one being added in future.

With this series, both powernv and pseries platforms support dynamic
secure boot through the same interface.

[0]: 
https://lore.kernel.org/linuxppc-dev/20221106210744.603240-1-na...@linux.ibm.com/
[1]: 
https://lore.kernel.org/linuxppc-dev/20221220071626.1426786-1-...@linux.ibm.com/

Russell Currey (6):
  powerpc/pseries: Log hcall return codes for PLPKS debug
  powerpc/secvar: WARN_ON_ONCE() if multiple secvar ops are set
  powerpc/secvar: Handle format string in the consumer
  powerpc/secvar: Handle max object size in the consumer
  powerpc/secvar: Extend sysfs to include config vars
  powerpc/pseries: Implement secvars for dynamic secure boot

 Documentation/ABI/testing/sysfs-secvar|   8 +
 arch/powerpc/include/asm/secvar.h |   5 +
 arch/powerpc/kernel/secvar-ops.c  |   4 +-
 arch/powerpc/kernel/secvar-sysfs.c|  76 +++---
 arch/powerpc/platforms/powernv/opal-secvar.c  |  44 +++
 arch/powerpc/platforms/pseries/Kconfig|  13 +
 arch/powerpc/platforms/pseries/Makefile   |   4 +-
 arch/powerpc/platforms/pseries/plpks-secvar.c | 250 ++
 arch/powerpc/platforms/pseries/plpks.c|   2 +
 9 files changed, 365 insertions(+), 41 deletions(-)
 create mode 100644 arch/powerpc/platforms/pseries/plpks-secvar.c

-- 
2.38.1



[PATCH 6/6] powerpc/pseries: Implement secvars for dynamic secure boot

2022-12-27 Thread Russell Currey
The pseries platform can support dynamic secure boot (i.e. secure boot
using user-defined keys) using variables contained with the PowerVM LPAR
Platform KeyStore (PLPKS).  Using the powerpc secvar API, expose the
relevant variables for pseries dynamic secure boot through the existing
secvar filesystem layout.

The relevant variables for dynamic secure boot are signed in the
keystore, and can only be modified using the H_PKS_SIGNED_UPDATE hcall.
Object labels in the keystore are encoded using ucs2 format.  With our
fixed variable names we don't have to care about encoding outside of the
necessary byte padding.

When a user writes to a variable, the first 8 bytes of data must contain
the signed update flags as defined by the hypervisor.

When a user reads a variable, the first 4 bytes of data contain the
policies defined for the object.

Limitations exist due to the underlying implementation of sysfs binary
attributes, as is the case for the OPAL secvar implementation -
partial writes are unsupported and writes cannot be larger than PAGE_SIZE.

Co-developed-by: Nayna Jain 
Signed-off-by: Nayna Jain 
Co-developed-by: Andrew Donnellan 
Signed-off-by: Andrew Donnellan 
Signed-off-by: Russell Currey 
---
 Documentation/ABI/testing/sysfs-secvar|   8 +
 arch/powerpc/platforms/pseries/Kconfig|  13 +
 arch/powerpc/platforms/pseries/Makefile   |   4 +-
 arch/powerpc/platforms/pseries/plpks-secvar.c | 250 ++
 4 files changed, 273 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/pseries/plpks-secvar.c

diff --git a/Documentation/ABI/testing/sysfs-secvar 
b/Documentation/ABI/testing/sysfs-secvar
index feebb8c57294..e6fef664c9c8 100644
--- a/Documentation/ABI/testing/sysfs-secvar
+++ b/Documentation/ABI/testing/sysfs-secvar
@@ -44,3 +44,11 @@ Contact: Nayna Jain 
 Description:   A write-only file that is used to submit the new value for the
variable. The size of the file represents the maximum size of
the variable data that can be written.
+
+What:  /sys/firmware/secvar/config
+Date:  December 2022
+Contact:   Nayna Jain 
+Description:   This optional directory contains read-only config attributes as
+   defined by the secure variable implementation.  All data is in
+   ASCII format. The directory is only created if the backing
+   implementation provides variables to populate it.
diff --git a/arch/powerpc/platforms/pseries/Kconfig 
b/arch/powerpc/platforms/pseries/Kconfig
index a3b4d99567cb..94e08c405d50 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -162,6 +162,19 @@ config PSERIES_PLPKS
 
  If unsure, select N.
 
+config PSERIES_PLPKS_SECVAR
+   depends on PSERIES_PLPKS
+   depends on PPC_SECURE_BOOT
+   bool "Support for the PLPKS secvar interface"
+   help
+ PowerVM can support dynamic secure boot with user-defined keys
+ through the PLPKS. Keystore objects used in dynamic secure boot
+ can be exposed to the kernel and userspace through the powerpc
+ secvar infrastructure. Select this to enable the PLPKS backend
+ for secvars for use in pseries dynamic secure boot.
+
+ If unsure, select N.
+
 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 92310202bdd7..807756991f9d 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -27,8 +27,8 @@ obj-$(CONFIG_PAPR_SCM)+= papr_scm.o
 obj-$(CONFIG_PPC_SPLPAR)   += vphn.o
 obj-$(CONFIG_PPC_SVM)  += svm.o
 obj-$(CONFIG_FA_DUMP)  += rtas-fadump.o
-obj-$(CONFIG_PSERIES_PLPKS) += plpks.o
-
+obj-$(CONFIG_PSERIES_PLPKS)+= plpks.o
+obj-$(CONFIG_PSERIES_PLPKS_SECVAR) += plpks-secvar.o
 obj-$(CONFIG_SUSPEND)  += suspend.o
 obj-$(CONFIG_PPC_VAS)  += vas.o vas-sysfs.o
 
diff --git a/arch/powerpc/platforms/pseries/plpks-secvar.c 
b/arch/powerpc/platforms/pseries/plpks-secvar.c
new file mode 100644
index ..3f9ff16c03c8
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/plpks-secvar.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Secure variable implementation using the PowerVM LPAR Platform KeyStore 
(PLPKS)
+ *
+ * Copyright 2022, IBM Corporation
+ * Authors: Russell Currey
+ *  Andrew Donnellan
+ *  Nayna Jain
+ */
+
+#define pr_fmt(fmt) "secvar: "fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "plpks.h"
+
+// Config attributes for sysfs
+#define PLPKS_CONFIG_ATTR(name, fmt, func) \
+   static ssize_t name##_show(struct kobject *kobj,\
+  struct 

[PATCH 4/6] powerpc/secvar: Handle max object size in the consumer

2022-12-27 Thread Russell Currey
Currently the max object size is handled in the core secvar code with an
entirely OPAL-specific implementation, so create a new max_size() op and
move the existing implementation into the powernv platform.  Should be
no functional change.

Signed-off-by: Russell Currey 
---
 arch/powerpc/include/asm/secvar.h|  1 +
 arch/powerpc/kernel/secvar-sysfs.c   | 17 +++--
 arch/powerpc/platforms/powernv/opal-secvar.c | 19 +++
 3 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/include/asm/secvar.h 
b/arch/powerpc/include/asm/secvar.h
index 3b7e5a3625bd..92d2c051918b 100644
--- a/arch/powerpc/include/asm/secvar.h
+++ b/arch/powerpc/include/asm/secvar.h
@@ -21,6 +21,7 @@ struct secvar_operations {
int (*set)(const char *key, uint64_t key_len, u8 *data,
   uint64_t data_size);
ssize_t (*format)(char *buf);
+   int (*max_size)(uint64_t *max_size);
 };
 
 #ifdef CONFIG_PPC_SECURE_BOOT
diff --git a/arch/powerpc/kernel/secvar-sysfs.c 
b/arch/powerpc/kernel/secvar-sysfs.c
index daf28b11866f..ea408763dc78 100644
--- a/arch/powerpc/kernel/secvar-sysfs.c
+++ b/arch/powerpc/kernel/secvar-sysfs.c
@@ -122,27 +122,16 @@ static struct kobj_type secvar_ktype = {
 static int update_kobj_size(void)
 {
 
-   struct device_node *node;
u64 varsize;
-   int rc = 0;
+   int rc = secvar_ops->max_size();
 
-   node = of_find_compatible_node(NULL, NULL, "ibm,secvar-backend");
-   if (!of_device_is_available(node)) {
-   rc = -ENODEV;
-   goto out;
-   }
-
-   rc = of_property_read_u64(node, "max-var-size", );
if (rc)
-   goto out;
+   return rc;
 
data_attr.size = varsize;
update_attr.size = varsize;
 
-out:
-   of_node_put(node);
-
-   return rc;
+   return 0;
 }
 
 static int secvar_sysfs_load(void)
diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c 
b/arch/powerpc/platforms/powernv/opal-secvar.c
index cd5b5c06c091..3ef6b9afd129 100644
--- a/arch/powerpc/platforms/powernv/opal-secvar.c
+++ b/arch/powerpc/platforms/powernv/opal-secvar.c
@@ -125,11 +125,30 @@ static ssize_t opal_secvar_format(char *buf)
return rc;
 }
 
+static int opal_secvar_max_size(uint64_t *max_size)
+{
+   int rc;
+   struct device_node *node;
+
+   node = of_find_compatible_node(NULL, NULL, "ibm,secvar-backend");
+   if (!of_device_is_available(node)) {
+   rc = -ENODEV;
+   goto out;
+   }
+
+   rc = of_property_read_u64(node, "max-var-size", max_size);
+
+out:
+   of_node_put(node);
+   return rc;
+}
+
 static const struct secvar_operations opal_secvar_ops = {
.get = opal_get_variable,
.get_next = opal_get_next_variable,
.set = opal_set_variable,
.format = opal_secvar_format,
+   .max_size = opal_secvar_max_size,
 };
 
 static int opal_secvar_probe(struct platform_device *pdev)
-- 
2.38.1



Re: [PATCH] fbdev: make offb driver tristate

2022-12-27 Thread Helge Deller

On 12/27/22 19:48, Nathan Chancellor wrote:

On Sat, Dec 10, 2022 at 05:35:06PM +0100, Helge Deller wrote:

On 11/26/22 14:40, Thomas Zimmermann wrote:

Am 26.11.22 um 01:04 schrieb Randy Dunlap:

Make the offb (Open Firmware frame buffer) driver tristate,
i.e., so that it can be built as a loadable module.

However, it still depends on the setting of DRM_OFDRM
so that both of these drivers cannot be builtin at the same time
nor can one be builtin and the other one a loadable module.

Build-tested successfully with all combination of DRM_OFDRM and FB_OF.

This fixes a build issue that Michal reported when FB_OF=y and
DRM_OFDRM=m:

powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): undefined 
reference to `cfb_fillrect'
powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x60): undefined 
reference to `cfb_copyarea'
powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x68): undefined 
reference to `cfb_imageblit'

Signed-off-by: Randy Dunlap 
Suggested-by: Arnd Bergmann 
Cc: Masahiro Yamada 
Cc: Thomas Zimmermann 
Cc: Michal Suchánek 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org


Acked-by: Thomas Zimmermann 


applied.


Is this going to make it to Linus soon? We are now seeing this error in
our CI, which has the configuration describe in this commit.

https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/3785609002/jobs/6437398666#step:5:149

https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2JUMSmjAoSJoKfl6PPjfU66JGit/build.log



It didn't applied cleanly earlier.
I've now added it to the fbdev for-next branch, and if no problems
show up in the next few days I'll push it before next weekend.
https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/log/?h=for-next

Helge



Cheers,
Nathan


---
   drivers/video/fbdev/Kconfig |    4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -456,8 +456,8 @@ config FB_ATARI
     chipset found in Ataris.
   config FB_OF
-    bool "Open Firmware frame buffer device support"
-    depends on (FB = y) && PPC && (!PPC_PSERIES || PCI)
+    tristate "Open Firmware frame buffer device support"
+    depends on FB && PPC && (!PPC_PSERIES || PCI)
   depends on !DRM_OFDRM
   select APERTURE_HELPERS
   select FB_CFB_FILLRECT









[PATCH AUTOSEL 4.9 2/3] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 arch/powerpc/sysdev/ppc4xx_hsta_msi.c  | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index 8b55c5f19d4c..f78dc043f370 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -298,6 +298,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
 
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index d9cd510c8865..6e54377663db 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -74,6 +74,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 8a244828782e..aa9dd3a92f2a 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -137,6 +137,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index cfc1c57d760f..26db91c8feff 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -116,6 +116,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 
diff --git a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c 
b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
index 9926ad67af76..ac5fbb2492aa 100644
--- a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
@@ -121,6 +121,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
-- 
2.35.1



[PATCH AUTOSEL 4.9 1/3] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 641f3e4c3380..9a8bd24a 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -733,10 +733,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 4.14 3/4] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c 
b/arch/powerpc/platforms/4xx/hsta_msi.c
index 9926ad67af76..ac5fbb2492aa 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -121,6 +121,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index e98b61c06a81..1c889a9e1a4f 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -299,6 +299,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
 
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index d9cd510c8865..6e54377663db 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -74,6 +74,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index d43d3d1b27ed..83c6ea6a82e0 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -137,6 +137,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index cfc1c57d760f..26db91c8feff 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -116,6 +116,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 
-- 
2.35.1



[PATCH AUTOSEL 4.14 2/4] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 914d71879536..5d84b412b2fd 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -733,10 +733,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 4.14 1/4] powerpc/rtas: avoid device tree lookups in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]

rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.

Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-4-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index dd20e87f18f2..914d71879536 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -716,6 +716,7 @@ void __noreturn rtas_halt(void)
 
 /* Must be in the RMO region, so we place it here */
 static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
 
 void rtas_os_term(char *str)
 {
@@ -727,14 +728,13 @@ void rtas_os_term(char *str)
 * this property may terminate the partition which we want to avoid
 * since it interferes with panic_timeout.
 */
-   if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
-   RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+   if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
do {
-   status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+   status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
 
@@ -1331,6 +1331,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
rtas.entry = no_entry ? rtas.base : entry;
 
+   /*
+* Discover these now to avoid device tree lookups in the
+* panic path.
+*/
+   if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+   ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.35.1



[PATCH AUTOSEL 4.19 3/4] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c 
b/arch/powerpc/platforms/4xx/hsta_msi.c
index 1c18f2955f7d..8af640339de4 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -121,6 +121,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index 946a09ae9fb2..e6b35c25be21 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -299,6 +299,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
 
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index d9cd510c8865..6e54377663db 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -74,6 +74,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 44aedb6b9f55..870cff74ecc2 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -137,6 +137,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index cfc1c57d760f..26db91c8feff 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -116,6 +116,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 
-- 
2.35.1



[PATCH AUTOSEL 4.19 2/4] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 4c9ed28465b3..a3f08a380c99 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -734,10 +734,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 4.19 1/4] powerpc/rtas: avoid device tree lookups in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]

rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.

Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-4-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index b492cb1c36fd..4c9ed28465b3 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -717,6 +717,7 @@ void __noreturn rtas_halt(void)
 
 /* Must be in the RMO region, so we place it here */
 static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
 
 void rtas_os_term(char *str)
 {
@@ -728,14 +729,13 @@ void rtas_os_term(char *str)
 * this property may terminate the partition which we want to avoid
 * since it interferes with panic_timeout.
 */
-   if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
-   RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+   if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
do {
-   status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+   status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
 
@@ -1332,6 +1332,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
rtas.entry = no_entry ? rtas.base : entry;
 
+   /*
+* Discover these now to avoid device tree lookups in the
+* panic path.
+*/
+   if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+   ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.35.1



[PATCH AUTOSEL 5.4 5/7] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c 
b/arch/powerpc/platforms/4xx/hsta_msi.c
index c950fed43b32..4f65bd0cf111 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -117,6 +117,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index ba33140e671d..d141f64150e8 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -295,6 +295,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
 
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index d38944a1e258..76393c158ada 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -69,6 +69,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index d276c5e96445..5c3f3173638e 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -132,6 +132,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 3861023d378a..43686c82e483 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -111,6 +111,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 
-- 
2.35.1



[PATCH AUTOSEL 5.4 4/7] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 8ec69ea81fb4..139377f37b74 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -731,10 +731,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 5.4 3/7] powerpc/rtas: avoid device tree lookups in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]

rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.

Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-4-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 35e246e39705..8ec69ea81fb4 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -714,6 +714,7 @@ void __noreturn rtas_halt(void)
 
 /* Must be in the RMO region, so we place it here */
 static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
 
 void rtas_os_term(char *str)
 {
@@ -725,14 +726,13 @@ void rtas_os_term(char *str)
 * this property may terminate the partition which we want to avoid
 * since it interferes with panic_timeout.
 */
-   if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
-   RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+   if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
do {
-   status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+   status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
 
@@ -1215,6 +1215,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
rtas.entry = no_entry ? rtas.base : entry;
 
+   /*
+* Discover these now to avoid device tree lookups in the
+* panic path.
+*/
+   if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+   ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.35.1



[PATCH AUTOSEL 5.10 5/7] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c 
b/arch/powerpc/platforms/4xx/hsta_msi.c
index c950fed43b32..4f65bd0cf111 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -117,6 +117,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index ffbc7d2e9464..9f77dde61f31 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -295,6 +295,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
 
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index d38944a1e258..76393c158ada 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -69,6 +69,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index d276c5e96445..5c3f3173638e 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -132,6 +132,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 3861023d378a..43686c82e483 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -111,6 +111,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 
-- 
2.35.1



[PATCH AUTOSEL 5.10 4/7] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index aa66317a9a49..014229c40435 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -732,10 +732,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 5.10 3/7] powerpc/rtas: avoid device tree lookups in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]

rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.

Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-4-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index bf962051af0a..aa66317a9a49 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -715,6 +715,7 @@ void __noreturn rtas_halt(void)
 
 /* Must be in the RMO region, so we place it here */
 static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
 
 void rtas_os_term(char *str)
 {
@@ -726,14 +727,13 @@ void rtas_os_term(char *str)
 * this property may terminate the partition which we want to avoid
 * since it interferes with panic_timeout.
 */
-   if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
-   RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+   if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
do {
-   status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+   status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
 
@@ -1267,6 +1267,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
rtas.entry = no_entry ? rtas.base : entry;
 
+   /*
+* Discover these now to avoid device tree lookups in the
+* panic path.
+*/
+   if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+   ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.35.1



[PATCH AUTOSEL 5.15 20/22] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c 
b/arch/powerpc/platforms/4xx/hsta_msi.c
index c950fed43b32..4f65bd0cf111 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -117,6 +117,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index f630693c8de7..2bcd9c54bce3 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -295,6 +295,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
 
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index d38944a1e258..76393c158ada 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -69,6 +69,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index c55ccec0a169..173d585c1be8 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -132,6 +132,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 3861023d378a..43686c82e483 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -111,6 +111,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 
-- 
2.35.1



[PATCH AUTOSEL 5.15 19/22] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 4d8de49c9d4b..2dae702e7a5a 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -805,10 +805,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 5.15 18/22] powerpc/rtas: avoid device tree lookups in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]

rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.

Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-4-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 7834ce3aa7f1..4d8de49c9d4b 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -788,6 +788,7 @@ void __noreturn rtas_halt(void)
 
 /* Must be in the RMO region, so we place it here */
 static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
 
 void rtas_os_term(char *str)
 {
@@ -799,14 +800,13 @@ void rtas_os_term(char *str)
 * this property may terminate the partition which we want to avoid
 * since it interferes with panic_timeout.
 */
-   if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
-   RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+   if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
do {
-   status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+   status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
 
@@ -1167,6 +1167,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
rtas.entry = no_entry ? rtas.base : entry;
 
+   /*
+* Discover these now to avoid device tree lookups in the
+* panic path.
+*/
+   if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+   ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.35.1



[PATCH AUTOSEL 6.0 25/27] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c 
b/arch/powerpc/platforms/4xx/hsta_msi.c
index d4f7fff1fc87..e11b57a62b05 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -115,6 +115,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index 5b012abca773..0c11aad896c7 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -289,6 +289,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
msi_for_each_desc(entry, >dev, MSI_DESC_ASSOCIATED) {
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index dc1846660005..166c97fff16d 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -66,6 +66,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 }
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 73c2d70706c0..57978a44d55b 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -132,6 +132,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 }
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 1d8cfdfdf115..492cb03c0b62 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -108,6 +108,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 }
-- 
2.35.1



[PATCH AUTOSEL 6.0 22/27] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 082b0c9e0c8a..5a873d4fbd7b 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -892,10 +892,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 6.0 21/27] powerpc/rtas: avoid device tree lookups in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]

rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.

Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-4-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 0b8a858aa847..082b0c9e0c8a 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -875,6 +875,7 @@ void __noreturn rtas_halt(void)
 
 /* Must be in the RMO region, so we place it here */
 static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
 
 void rtas_os_term(char *str)
 {
@@ -886,14 +887,13 @@ void rtas_os_term(char *str)
 * this property may terminate the partition which we want to avoid
 * since it interferes with panic_timeout.
 */
-   if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
-   RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+   if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
do {
-   status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+   status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
 
@@ -1255,6 +1255,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
rtas.entry = no_entry ? rtas.base : entry;
 
+   /*
+* Discover these now to avoid device tree lookups in the
+* panic path.
+*/
+   if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+   ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.35.1



[PATCH AUTOSEL 6.1 26/28] powerpc/msi: Fix deassociation of MSI descriptors

2022-12-27 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]

Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.

The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.

Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.

Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.

Reported-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Link: 
https://lore.kernel.org/r/70dab88e-6119-0c12-7c6a-61bcbe239...@roeck-us.net
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 1 +
 arch/powerpc/platforms/pasemi/msi.c| 1 +
 arch/powerpc/sysdev/fsl_msi.c  | 1 +
 arch/powerpc/sysdev/mpic_u3msi.c   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c 
b/arch/powerpc/platforms/4xx/hsta_msi.c
index d4f7fff1fc87..e11b57a62b05 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -115,6 +115,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
 entry->irq, irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/cell/axon_msi.c 
b/arch/powerpc/platforms/cell/axon_msi.c
index 5b012abca773..0c11aad896c7 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -289,6 +289,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
msi_for_each_desc(entry, >dev, MSI_DESC_ASSOCIATED) {
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
}
 }
 
diff --git a/arch/powerpc/platforms/pasemi/msi.c 
b/arch/powerpc/platforms/pasemi/msi.c
index dc1846660005..166c97fff16d 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -66,6 +66,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 
ALLOC_CHUNK);
}
 }
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 73c2d70706c0..57978a44d55b 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -132,6 +132,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_data->bitmap, hwirq, 1);
}
 }
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 1d8cfdfdf115..492cb03c0b62 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -108,6 +108,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+   entry->irq = 0;
msi_bitmap_free_hwirqs(_mpic->msi_bitmap, hwirq, 1);
}
 }
-- 
2.35.1



[PATCH AUTOSEL 6.1 22/28] powerpc/rtas: avoid scheduling in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
BUG: sleeping function called from invalid context at 
arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G  D
6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c7b8f000] [c1337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c7b8f040] [c02440e4] __might_resched+0x394/0x3c0
[c7b8f0e0] [c004f680] rtas_busy_delay+0x120/0x1b0
[c7b8f100] [c0052d04] rtas_os_term+0xb8/0xf4
[c7b8f180] [c01150fc] pseries_panic+0x50/0x68
[c7b8f1f0] [c0036354] ppc_panic_platform_handler+0x34/0x50
[c7b8f210] [c02303c4] notifier_call_chain+0xd4/0x1c0
[c7b8f2b0] [c02306cc] atomic_notifier_call_chain+0xac/0x1c0
[c7b8f2f0] [c01d62b8] panic+0x228/0x4d0
[c7b8f390] [c01e573c] do_exit+0x140c/0x1420
[c7b8f480] [c01e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-5-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 6b5f49c9ad79..767ab166933b 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -906,10 +906,15 @@ void rtas_os_term(char *str)
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
+   /*
+* Keep calling as long as RTAS returns a "try again" status,
+* but don't use rtas_busy_delay(), which potentially
+* schedules.
+*/
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
-   } while (rtas_busy_delay(status));
+   } while (rtas_busy_delay_time(status));
 
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
-- 
2.35.1



[PATCH AUTOSEL 6.1 21/28] powerpc/rtas: avoid device tree lookups in rtas_os_term()

2022-12-27 Thread Sasha Levin
From: Nathan Lynch 

[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]

rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.

Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.

Signed-off-by: Nathan Lynch 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Andrew Donnellan 
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20221118150751.469393-4-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/rtas.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index e847f9b1c5b9..6b5f49c9ad79 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -889,6 +889,7 @@ void __noreturn rtas_halt(void)
 
 /* Must be in the RMO region, so we place it here */
 static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
 
 void rtas_os_term(char *str)
 {
@@ -900,14 +901,13 @@ void rtas_os_term(char *str)
 * this property may terminate the partition which we want to avoid
 * since it interferes with panic_timeout.
 */
-   if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
-   RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+   if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
 
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
 
do {
-   status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+   status = rtas_call(ibm_os_term_token, 1, 1, NULL,
   __pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
 
@@ -1277,6 +1277,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
rtas.entry = no_entry ? rtas.base : entry;
 
+   /*
+* Discover these now to avoid device tree lookups in the
+* panic path.
+*/
+   if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+   ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.35.1



Re: [PATCH] fbdev: make offb driver tristate

2022-12-27 Thread Nathan Chancellor
On Sat, Dec 10, 2022 at 05:35:06PM +0100, Helge Deller wrote:
> On 11/26/22 14:40, Thomas Zimmermann wrote:
> > Am 26.11.22 um 01:04 schrieb Randy Dunlap:
> > > Make the offb (Open Firmware frame buffer) driver tristate,
> > > i.e., so that it can be built as a loadable module.
> > > 
> > > However, it still depends on the setting of DRM_OFDRM
> > > so that both of these drivers cannot be builtin at the same time
> > > nor can one be builtin and the other one a loadable module.
> > > 
> > > Build-tested successfully with all combination of DRM_OFDRM and FB_OF.
> > > 
> > > This fixes a build issue that Michal reported when FB_OF=y and
> > > DRM_OFDRM=m:
> > > 
> > > powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): 
> > > undefined reference to `cfb_fillrect'
> > > powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x60): 
> > > undefined reference to `cfb_copyarea'
> > > powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x68): 
> > > undefined reference to `cfb_imageblit'
> > > 
> > > Signed-off-by: Randy Dunlap 
> > > Suggested-by: Arnd Bergmann 
> > > Cc: Masahiro Yamada 
> > > Cc: Thomas Zimmermann 
> > > Cc: Michal Suchánek 
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Cc: Daniel Vetter 
> > > Cc: Helge Deller 
> > > Cc: linux-fb...@vger.kernel.org
> > > Cc: dri-de...@lists.freedesktop.org
> > 
> > Acked-by: Thomas Zimmermann 
> 
> applied.

Is this going to make it to Linus soon? We are now seeing this error in
our CI, which has the configuration describe in this commit.

https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/3785609002/jobs/6437398666#step:5:149

https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2JUMSmjAoSJoKfl6PPjfU66JGit/build.log

Cheers,
Nathan

> > > ---
> > >   drivers/video/fbdev/Kconfig |    4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > > --- a/drivers/video/fbdev/Kconfig
> > > +++ b/drivers/video/fbdev/Kconfig
> > > @@ -456,8 +456,8 @@ config FB_ATARI
> > >     chipset found in Ataris.
> > >   config FB_OF
> > > -    bool "Open Firmware frame buffer device support"
> > > -    depends on (FB = y) && PPC && (!PPC_PSERIES || PCI)
> > > +    tristate "Open Firmware frame buffer device support"
> > > +    depends on FB && PPC && (!PPC_PSERIES || PCI)
> > >   depends on !DRM_OFDRM
> > >   select APERTURE_HELPERS
> > >   select FB_CFB_FILLRECT
> > 
> 
> 


Re: [PATCH v2 00/50] KVM: Rework kvm_init() and hardware enabling

2022-12-27 Thread Paolo Bonzini
Queued, thanks.  I will leave this in kvm/queue after testing everything
else and moving it to kvm/next; this way, we can wait for test results
on other architectures.

Paolo




[RFC PATCH 9/9] powerpc/64: modules support building with PCREL addresing

2022-12-27 Thread Nicholas Piggin
Build modules using PCREL addressing when the kernel PCREL build option
is selected.

The module loader must handle several new relocation types:
- R_PPC64_REL24_NOTOC is a function cal handled like R_PPC_REL24, but
  does not restore r2 upon return. The external function call stub is
  changed to use PCREL addressing to load the function pointer rather
  than based on the module TOC.
- R_PPC64_GOT_PCREL34 is a reference to external data. A GOT table must
  be built by hand, because the linker adds this during the final link
  (which is not done for kernel modules). The GOT table is built
  similarly to the way the external function call stub table is. This
  section is called .mygot because .got has a special meaning for the
  linker which can upset it.
- R_PPC64_PCREL34 is used for local data addressing. There is a special
  case where the percpu section is moved at load-time to the percpu
  area which is out of range of this relocation, that case gets converted
  to a GOT address (XXX: is this kosher? Must restrict this case to only
  percpu so it doesn't paper over any bugs).

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/Makefile   |   5 +-
 arch/powerpc/include/asm/module.h   |   9 +-
 arch/powerpc/include/asm/ppc_asm.h  |   6 +-
 arch/powerpc/include/uapi/asm/elf.h |   4 +
 arch/powerpc/kernel/module_64.c | 294 
 5 files changed, 269 insertions(+), 49 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 7bd83d124c1e..833247e1a81a 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -107,9 +107,7 @@ LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) += -z notext
 LDFLAGS_vmlinux:= $(LDFLAGS_vmlinux-y)
 
 ifdef CONFIG_PPC64
-ifdef CONFIG_PPC_KERNEL_PCREL
-   KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-pcrel)
-endif
+ifndef CONFIG_PPC_KERNEL_PCREL
 ifeq ($(call cc-option-yn,-mcmodel=medium),y)
# -mcmodel=medium breaks modules because it uses 32bit offsets from
# the TOC pointer to create pointers where possible. Pointers into the
@@ -124,6 +122,7 @@ else
export NO_MINIMAL_TOC := -mno-minimal-toc
 endif
 endif
+endif
 
 CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
 ifndef CONFIG_CC_IS_CLANG
diff --git a/arch/powerpc/include/asm/module.h 
b/arch/powerpc/include/asm/module.h
index 09e2ffd360bb..f3d12a553863 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -27,8 +27,12 @@ struct ppc_plt_entry {
 struct mod_arch_specific {
 #ifdef __powerpc64__
unsigned int stubs_section; /* Index of stubs section in module */
+#ifdef CONFIG_PPC_KERNEL_PCREL
+   unsigned int got_section;   /* What section is the GOT? */
+#else
unsigned int toc_section;   /* What section is the TOC? */
bool toc_fixed; /* Have we fixed up .TOC.? */
+#endif
 
/* For module function descriptor dereference */
unsigned long start_opd;
@@ -52,12 +56,15 @@ struct mod_arch_specific {
 
 /*
  * Select ELF headers.
- * Make empty section for module_frob_arch_sections to expand.
+ * Make empty sections for module_frob_arch_sections to expand.
  */
 
 #ifdef __powerpc64__
 #ifdef MODULE
asm(".section .stubs,\"ax\",@nobits; .align 3; .previous");
+#ifdef CONFIG_PPC_KERNEL_PCREL
+   asm(".section .mygot,\"a\",@nobits; .align 3; .previous");
+#endif
 #endif
 #else
 #ifdef MODULE
diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index 9315f007d010..1a00523559e7 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -183,7 +183,7 @@
 /*
  * Used to name C functions called from asm
  */
-#if defined(CONFIG_PPC_KERNEL_PCREL) && !defined(MODULE)
+#ifdef CONFIG_PPC_KERNEL_PCREL
 #define CFUNC(name) name@notoc
 #else
 #define CFUNC(name) name
@@ -216,7 +216,7 @@
.globl name; \
 name:
 
-#if defined(CONFIG_PPC_KERNEL_PCREL) && !defined(MODULE)
+#ifdef CONFIG_PPC_KERNEL_PCREL
 #define _GLOBAL_TOC _GLOBAL
 #else
 #define _GLOBAL_TOC(name) \
@@ -379,7 +379,7 @@ GLUE(.,name):
ori reg, reg, (expr)@l; \
rldimi  reg, tmp, 32, 0
 
-#if defined(CONFIG_PPC_KERNEL_PCREL) && !defined(MODULE)
+#ifdef CONFIG_PPC_KERNEL_PCREL
 #define LOAD_REG_ADDR(reg,name)\
pla reg,name@pcrel
 
diff --git a/arch/powerpc/include/uapi/asm/elf.h 
b/arch/powerpc/include/uapi/asm/elf.h
index 308857123a08..dbc4a5b8d02d 100644
--- a/arch/powerpc/include/uapi/asm/elf.h
+++ b/arch/powerpc/include/uapi/asm/elf.h
@@ -279,8 +279,12 @@ typedef elf_fpreg_t elf_vsrreghalf_t32[ELF_NVSRHALFREG];
 #define R_PPC64_TLSLD  108
 #define R_PPC64_TOCSAVE109
 
+#define R_PPC64_REL24_NOTOC116
 #define R_PPC64_ENTRY  118
 
+#define R_PPC64_PCREL34132
+#define R_PPC64_GOT_PCREL34133
+
 #define R_PPC64_REL16  249
 #define 

[RFC PATCH 8/9] powerpc/64: vmlinux support building with PCREL addresing

2022-12-27 Thread Nicholas Piggin
PC-Relative or PCREL addressing is an extension to the ELF ABI which
uses Power ISA v3.1 PC-relative instructions to calculate addresses,
rather than the traditional TOC scheme.

Add an option to build vmlinux using PCREL addressing. Modules continue
to use TOC addressing.

- TOC address helpers and r2 are poisoned with -1 when running vmlinux.
  r2 could be used for something useful once things are ironed out.

- Assembly must call C functions with @notoc annotation, or the linker
  complains aobut a missing nop after the call. This is done with the
  CFUNC macro introduced earlier.

- Boot: with the exception of prom_init, the execution branches to the
  kernel virtual address early in boot, before any addresses are
  generated, which ensures 34-bit pcrel addressing does not miss the
  high PAGE_OFFSET bits. TOC relative addressing has a similar
  requirement. prom_init does not go to the virtual address and its
  addresses should not carry over to the post-prom kernel.

- Ftrace trampolines must be converted from TOC addressing to PCREL
  addressing, including module ftrace trampolines that currently use the
  kernel TOC to find ftrace target functions.

- BPF function prologue and function calling generation must be
  converted from TOC to PCREL (XXX: not well tested yet).

- copypage_64.S has an interesting problem, prefixed instructions have
  alignment restrictions so the linker can add padding, which makes the
  assembler treat the difference between two local labels as
  non-constant even if alignment is arranged so padding is not required.
  This may need toolchain help to solve nicely, for now move the prefix
  instruction out of the alternate patch section to work around it.

This reduces kernel text size by about 6%.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/Kconfig   |  3 ++
 arch/powerpc/Makefile  |  7 +++
 arch/powerpc/include/asm/paca.h|  2 +
 arch/powerpc/include/asm/ppc-opcode.h  |  8 
 arch/powerpc/include/asm/ppc_asm.h | 19 
 arch/powerpc/include/asm/sections.h|  5 +++
 arch/powerpc/kernel/asm-offsets.c  |  2 +
 arch/powerpc/kernel/head_64.S  | 14 ++
 arch/powerpc/kernel/irq.c  |  8 
 arch/powerpc/kernel/module_64.c| 60 +++---
 arch/powerpc/kernel/paca.c |  2 +
 arch/powerpc/kernel/trace/ftrace.c | 50 -
 arch/powerpc/kernel/vector.S   |  6 +++
 arch/powerpc/kernel/vmlinux.lds.S  |  6 +++
 arch/powerpc/lib/copypage_64.S |  4 +-
 arch/powerpc/net/bpf_jit.h | 10 +++--
 arch/powerpc/net/bpf_jit_comp64.c  | 35 +++
 arch/powerpc/platforms/Kconfig.cputype | 18 
 arch/powerpc/xmon/xmon.c   |  2 +
 19 files changed, 221 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index f8ee94785f8c..8679f9ac1406 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -7,6 +7,9 @@ config CC_HAS_ELFV2
 config CC_HAS_PREFIXED
def_bool PPC64 && $(cc-option, -mcpu=power10 -mprefixed)
 
+config CC_HAS_PCREL
+   def_bool PPC64 && $(cc-option, -mcpu=power10 -mpcrel)
+
 config 32BIT
bool
default y if PPC32
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 5b6c276bb690..7bd83d124c1e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -107,6 +107,9 @@ LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) += -z notext
 LDFLAGS_vmlinux:= $(LDFLAGS_vmlinux-y)
 
 ifdef CONFIG_PPC64
+ifdef CONFIG_PPC_KERNEL_PCREL
+   KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-pcrel)
+endif
 ifeq ($(call cc-option-yn,-mcmodel=medium),y)
# -mcmodel=medium breaks modules because it uses 32bit offsets from
# the TOC pointer to create pointers where possible. Pointers into the
@@ -198,7 +201,11 @@ KBUILD_CFLAGS += $(call cc-option,-mprefixed)
 else
 KBUILD_CFLAGS += $(call cc-option,-mno-prefixed)
 endif
+ifdef CONFIG_PPC_KERNEL_PCREL
+KBUILD_CFLAGS += $(call cc-option,-mpcrel)
+else
 KBUILD_CFLAGS += $(call cc-option,-mno-pcrel)
+endif
 
 # No AltiVec or VSX or MMA instructions when building kernel
 KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 09f1790d0ae1..366ce872e6f3 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -88,7 +88,9 @@ struct paca_struct {
u16 lock_token; /* Constant 0x8000, used in locks */
 #endif
 
+#ifndef CONFIG_PPC_KERNEL_PREFIXED
u64 kernel_toc; /* Kernel TOC address */
+#endif
u64 kernelbase; /* Base address of kernel */
u64 kernel_msr; /* MSR while running in kernel */
void *emergency_sp; /* pointer to emergency stack */
diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
b/arch/powerpc/include/asm/ppc-opcode.h
index 

[RFC PATCH 7/9] powerpc/64: Add support to build with prefixed instructions

2022-12-27 Thread Nicholas Piggin
Add an option to build kernel and module with prefixed instructions if
the CPU and toolchain support it.

This is not related to kernel support for userspace execution of
prefixed instructions.

Building with prefixed instructions breaks some extended inline asm
memory addressing, for example it will provide immediates that exceed
the range of simple load/store displacement. Whether this is a
toolchain or a kernel asm problem remains to be seen. For now, these
are replaced with simpler and less efficient direct register addressing
when compiling with prefixed.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/Kconfig   |  3 +++
 arch/powerpc/Makefile  |  4 +++
 arch/powerpc/include/asm/atomic.h  | 24 ++---
 arch/powerpc/include/asm/io.h  | 37 ++
 arch/powerpc/include/asm/uaccess.h | 28 +--
 arch/powerpc/kernel/trace/ftrace.c |  2 ++
 arch/powerpc/platforms/Kconfig.cputype | 20 ++
 7 files changed, 112 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b8c4ac56bddc..f8ee94785f8c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -4,6 +4,9 @@ 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)
+
 config 32BIT
bool
default y if PPC32
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dc4cbf0a5ca9..5b6c276bb690 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -193,7 +193,11 @@ ifdef CONFIG_476FPE_ERR46
 endif
 
 # No prefix or pcrel
+ifdef CONFIG_PPC_KERNEL_PREFIXED
+KBUILD_CFLAGS += $(call cc-option,-mprefixed)
+else
 KBUILD_CFLAGS += $(call cc-option,-mno-prefixed)
+endif
 KBUILD_CFLAGS += $(call cc-option,-mno-pcrel)
 
 # No AltiVec or VSX or MMA instructions when building kernel
diff --git a/arch/powerpc/include/asm/atomic.h 
b/arch/powerpc/include/asm/atomic.h
index 486ab7889121..50212c44be2a 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -27,14 +27,22 @@ static __inline__ int arch_atomic_read(const atomic_t *v)
 {
int t;
 
-   __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m<>"(v->counter));
+   /* -mprefixed can generate offsets beyond range, fall back hack */
+   if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
+   __asm__ __volatile__("lwz %0,0(%1)" : "=r"(t) : 
"b"(>counter));
+   else
+   __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : 
"m<>"(v->counter));
 
return t;
 }
 
 static __inline__ void arch_atomic_set(atomic_t *v, int i)
 {
-   __asm__ __volatile__("stw%U0%X0 %1,%0" : "=m<>"(v->counter) : "r"(i));
+   /* -mprefixed can generate offsets beyond range, fall back hack */
+   if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
+   __asm__ __volatile__("stw %1,0(%2)" : "=m"(v->counter) : 
"r"(i), "b"(>counter));
+   else
+   __asm__ __volatile__("stw%U0%X0 %1,%0" : "=m<>"(v->counter) : 
"r"(i));
 }
 
 #define ATOMIC_OP(op, asm_op, suffix, sign, ...)   \
@@ -226,14 +234,22 @@ static __inline__ s64 arch_atomic64_read(const atomic64_t 
*v)
 {
s64 t;
 
-   __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) : "m<>"(v->counter));
+   /* -mprefixed can generate offsets beyond range, fall back hack */
+   if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
+   __asm__ __volatile__("ld %0,0(%1)" : "=r"(t) : 
"b"(>counter));
+   else
+   __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) : 
"m<>"(v->counter));
 
return t;
 }
 
 static __inline__ void arch_atomic64_set(atomic64_t *v, s64 i)
 {
-   __asm__ __volatile__("std%U0%X0 %1,%0" : "=m<>"(v->counter) : "r"(i));
+   /* -mprefixed can generate offsets beyond range, fall back hack */
+   if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
+   __asm__ __volatile__("std %1,0(%2)" : "=m"(v->counter) : 
"r"(i), "b"(>counter));
+   else
+   __asm__ __volatile__("std%U0%X0 %1,%0" : "=m<>"(v->counter) : 
"r"(i));
 }
 
 #define ATOMIC64_OP(op, asm_op)
\
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index fc112a91d0c2..f1e657c9bbe8 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -97,6 +97,42 @@ extern bool isa_io_special;
  *
  */
 
+/* -mprefixed can generate offsets beyond range, fall back hack */
+#ifdef CONFIG_PPC_KERNEL_PREFIXED
+#define DEF_MMIO_IN_X(name, size, insn)\
+static inline u##size name(const volatile u##size __iomem *addr)   \
+{  \
+   u##size ret;\
+   __asm__ 

[RFC PATCH 6/9] powerpc: add CFUNC assembly label annotation

2022-12-27 Thread Nicholas Piggin
This macro is to be used in assembly where C functions are called.
pcrel addressing mode requires branches to functions with a
localentry value of 1 to have either a trailing nop or @notoc.
This macro permits the latter without changing callers.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/ppc_asm.h  |   5 ++
 arch/powerpc/kernel/exceptions-64s.S| 112 
 arch/powerpc/kernel/head_64.S   |  12 +--
 arch/powerpc/kernel/interrupt_64.S  |  28 +++---
 arch/powerpc/kernel/misc_64.S   |   2 +-
 arch/powerpc/kernel/vdso/gettimeofday.S |   6 +-
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |  16 ++--
 arch/powerpc/lib/copypage_power7.S  |   4 +-
 arch/powerpc/lib/copyuser_power7.S  |   8 +-
 arch/powerpc/lib/hweight_64.S   |   8 +-
 arch/powerpc/lib/memcmp_64.S|   4 +-
 arch/powerpc/lib/memcpy_power7.S|   6 +-
 arch/powerpc/platforms/pseries/hvCall.S |   4 +-
 13 files changed, 112 insertions(+), 103 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index d2f44612f4b0..9f64f9a6a897 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -180,6 +180,11 @@
 
 #ifdef __KERNEL__
 
+/*
+ * Used to name C functions called from asm
+ */
+#define CFUNC(name) name
+
 /*
  * We use __powerpc64__ here because we want the compat VDSO to use the 32-bit
  * version below in the else case of the ifdef.
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 6441a1ba57ac..c33c8ebf8641 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1075,7 +1075,7 @@ EXC_COMMON_BEGIN(system_reset_common)
__GEN_COMMON_BODY system_reset
 
addir3,r1,STACK_INT_FRAME_REGS
-   bl  system_reset_exception
+   bl  CFUNC(system_reset_exception)
 
/* Clear MSR_RI before setting SRR0 and SRR1. */
li  r9,0
@@ -1223,9 +1223,9 @@ BEGIN_FTR_SECTION
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
addir3,r1,STACK_INT_FRAME_REGS
 BEGIN_FTR_SECTION
-   bl  machine_check_early_boot
+   bl  CFUNC(machine_check_early_boot)
 END_FTR_SECTION(0, 1) // nop out after boot
-   bl  machine_check_early
+   bl  CFUNC(machine_check_early)
std r3,RESULT(r1)   /* Save result */
ld  r12,_MSR(r1)
 
@@ -1286,7 +1286,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
 * Queue up the MCE event so that we can log it later, while
 * returning from kernel or opal call.
 */
-   bl  machine_check_queue_event
+   bl  CFUNC(machine_check_queue_event)
MACHINE_CHECK_HANDLER_WINDUP
RFI_TO_KERNEL
 
@@ -1312,7 +1312,7 @@ EXC_COMMON_BEGIN(machine_check_common)
 */
GEN_COMMON machine_check
addir3,r1,STACK_INT_FRAME_REGS
-   bl  machine_check_exception_async
+   bl  CFUNC(machine_check_exception_async)
b   interrupt_return_srr
 
 
@@ -1322,7 +1322,7 @@ EXC_COMMON_BEGIN(machine_check_common)
  * done. Queue the event then call the idle code to do the wake up.
  */
 EXC_COMMON_BEGIN(machine_check_idle_common)
-   bl  machine_check_queue_event
+   bl  CFUNC(machine_check_queue_event)
 
/*
 * GPR-loss wakeups are relatively straightforward, because the
@@ -1361,7 +1361,7 @@ EXC_COMMON_BEGIN(unrecoverable_mce)
 BEGIN_FTR_SECTION
li  r10,0 /* clear MSR_RI */
mtmsrd  r10,1
-   bl  disable_machine_check
+   bl  CFUNC(disable_machine_check)
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
ld  r10,PACAKMSR(r13)
li  r3,MSR_ME
@@ -1378,14 +1378,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
 * the early handler which is a true NMI.
 */
addir3,r1,STACK_INT_FRAME_REGS
-   bl  machine_check_exception
+   bl  CFUNC(machine_check_exception)
 
/*
 * We will not reach here. Even if we did, there is no way out.
 * Call unrecoverable_exception and die.
 */
addir3,r1,STACK_INT_FRAME_REGS
-   bl  unrecoverable_exception
+   bl  CFUNC(unrecoverable_exception)
b   .
 
 
@@ -1440,16 +1440,16 @@ EXC_COMMON_BEGIN(data_access_common)
bne-1f
 #ifdef CONFIG_PPC_64S_HASH_MMU
 BEGIN_MMU_FTR_SECTION
-   bl  do_hash_fault
+   bl  CFUNC(do_hash_fault)
 MMU_FTR_SECTION_ELSE
-   bl  do_page_fault
+   bl  CFUNC(do_page_fault)
 ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
 #else
-   bl  do_page_fault
+   bl  CFUNC(do_page_fault)
 #endif
b   interrupt_return_srr
 
-1: bl  do_break
+1: bl  CFUNC(do_break)
/*
 * do_break() may have changed the NV GPRS while handling a breakpoint.
 * If so, we need to restore them with their updated 

[RFC PATCH 5/9] powerpc/64s: Run at the kernel virtual address earlier in boot

2022-12-27 Thread Nicholas Piggin
This mostly consolidates the Book3E and Book3S behaviour in boot WRT
executing from the physical or virtual address.

Book3E sets up kernel virtual linear map in start_initialization_book3e
and runs from the virtual linear alias after that. This change makes
Book3S begin to execute from the virtual alias at the same point. Book3S
can not use its MMU for that at this point, but when the MMU is disabled,
the virtual linear address correctly aliases to physical memory because
the top bits of the address are ignored with MMU disabled.

Secondaries execute from the virtual address similarly early.

This reduces the differences between subarchs, but the main motivation
was to enable the PC-relative addressing ABI for Book3S, where pointer
calculations must execute from the virtual address or the top bits of
the pointer will be lost. This is similar to the requirement the TOC
relative addressing already has that the TOC pointer use its virtual
address.

XXX: I expect this to blow up everywhere, I've not tested a huge range
of platforms, and mostly in QEMU.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/head_64.S | 83 +++
 1 file changed, 45 insertions(+), 38 deletions(-)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 63f3b9b3cf7e..33a5fbfdc180 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -76,6 +76,13 @@
  *   2. The kernel is entered at __start
  */
 
+/*
+ * boot_from_prom and prom_init run at the physical address. Everything
+ * after prom and kexec entry run at the virtual address (PAGE_OFFSET).
+ * Secondaries run at the virtual address from generic_secondary_common_init
+ * onward.
+ */
+
 OPEN_FIXED_SECTION(first_256B, 0x0, 0x100)
 USE_FIXED_SECTION(first_256B)
/*
@@ -303,13 +310,11 @@ _GLOBAL(fsl_secondary_thread_init)
/* turn on 64-bit mode */
bl  enable_64b_mode
 
-   /* get a valid TOC pointer, wherever we're mapped at */
-   bl  relative_toc
-   tovirt(r2,r2)
-
/* Book3E initialization */
mr  r3,r24
bl  book3e_secondary_thread_init
+   bl  relative_toc
+
b   generic_secondary_common_init
 
 #endif /* CONFIG_PPC_BOOK3E_64 */
@@ -331,16 +336,12 @@ _GLOBAL(generic_secondary_smp_init)
/* turn on 64-bit mode */
bl  enable_64b_mode
 
-   /* get a valid TOC pointer, wherever we're mapped at */
-   bl  relative_toc
-   tovirt(r2,r2)
-
 #ifdef CONFIG_PPC_BOOK3E_64
/* Book3E initialization */
mr  r3,r24
mr  r4,r25
bl  book3e_secondary_core_init
-
+   /* Now NIA and r2 are relocated to PAGE_OFFSET if not already */
 /*
  * After common core init has finished, check if the current thread is the
  * one we wanted to boot. If not, start the specified thread and stop the
@@ -378,6 +379,16 @@ _GLOBAL(generic_secondary_smp_init)
 10:
b   10b
 20:
+#else
+   /* Now the MMU is off, can branch to our PAGE_OFFSET address */
+   bcl 20,31,$+4
+1: mflrr11
+   addir11,r11,(2f - 1b)
+   tovirt(r11, r11)
+   mtctr   r11
+   bctr
+2:
+   bl  relative_toc
 #endif
 
 generic_secondary_common_init:
@@ -492,6 +503,8 @@ start_initialization_book3s:
/* Switch off MMU if not already off */
bl  __mmu_off
 
+   /* Now the MMU is off, can return to our PAGE_OFFSET address */
+   tovirt(r25,r25)
mtlrr25
blr
 #endif
@@ -530,16 +543,19 @@ __start_initialization_multiplatform:
mr  r29,r9
 #endif
 
+   /* These functions return to the virtual (PAGE_OFFSET) address */
 #ifdef CONFIG_PPC_BOOK3E_64
bl  start_initialization_book3e
 #else
bl  start_initialization_book3s
 #endif /* CONFIG_PPC_BOOK3E_64 */
 
-   /* Get TOC pointer */
+   /* Get TOC pointer, virtual */
bl  relative_toc
 
/* find out where we are now */
+
+   /* OPAL doesn't pass base address in r4, have to derive it. */
bcl 20,31,$+4
 0: mflrr26 /* r26 = runtime addr here */
addis   r26,r26,(_stext - 0b)@ha
@@ -550,7 +566,7 @@ __start_initialization_multiplatform:
 __REF
 __boot_from_prom:
 #ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE
-   /* Get TOC pointer */
+   /* Get TOC pointer, non-virtual */
bl  relative_toc
 
/* find out where we are now */
@@ -599,18 +615,11 @@ __boot_from_prom:
 __after_prom_start:
 #ifdef CONFIG_RELOCATABLE
/* process relocations for the final address of the kernel */
-   lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */
-   sldir25,r25,32
-#if defined(CONFIG_PPC_BOOK3E_64)
-   tovirt(r26,r26) /* on booke, we already run at PAGE_OFFSET */
-#endif
lwz r7,(FIXED_SYMBOL_ABS_ADDR(__run_at_load))(r26)
-#if defined(CONFIG_PPC_BOOK3E_64)
-   tophys(r26,r26)
-#endif

[RFC PATCH 4/9] powerpc/64: Move initial base and TOC pointer calculation

2022-12-27 Thread Nicholas Piggin
A later change moves the non-prom case to run at the virtual address
earlier, which calls for virtual TOC and kernel base. Split these two
calculations for prom and non-prom to make that change simpler.

Signed: Nicholas Piggin 
---
 arch/powerpc/kernel/head_64.S | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 3a7266fa8a18..63f3b9b3cf7e 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -514,15 +514,6 @@ __start_initialization_multiplatform:
/* Zero r13 (paca) so early program check / mce don't use it */
li  r13,0
 
-   /* Get TOC pointer (current runtime address) */
-   bl  relative_toc
-
-   /* find out where we are now */
-   bcl 20,31,$+4
-0: mflrr26 /* r26 = runtime addr here */
-   addis   r26,r26,(_stext - 0b)@ha
-   addir26,r26,(_stext - 0b)@l /* current runtime base addr */
-
/*
 * Are we booted from a PROM Of-type client-interface ?
 */
@@ -544,11 +535,30 @@ __start_initialization_multiplatform:
 #else
bl  start_initialization_book3s
 #endif /* CONFIG_PPC_BOOK3E_64 */
+
+   /* Get TOC pointer */
+   bl  relative_toc
+
+   /* find out where we are now */
+   bcl 20,31,$+4
+0: mflrr26 /* r26 = runtime addr here */
+   addis   r26,r26,(_stext - 0b)@ha
+   addir26,r26,(_stext - 0b)@l /* current runtime base addr */
+
b   __after_prom_start
 
 __REF
 __boot_from_prom:
 #ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE
+   /* Get TOC pointer */
+   bl  relative_toc
+
+   /* find out where we are now */
+   bcl 20,31,$+4
+0: mflrr26 /* r26 = runtime addr here */
+   addis   r26,r26,(_stext - 0b)@ha
+   addir26,r26,(_stext - 0b)@l /* current runtime base addr */
+
/* Save parameters */
mr  r31,r3
mr  r30,r4
-- 
2.37.2



[RFC PATCH 3/9] powerpc/64e: Simplify address calculation in secondary hold loop

2022-12-27 Thread Nicholas Piggin
As the earlier comment explains, __secondary_hold_spinloop does not have
to be accessed at its virtual address, slightly simplifying code.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/head_64.S | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 5af2e473b195..3a7266fa8a18 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -160,12 +160,8 @@ __secondary_hold:
std r24,(ABS_ADDR(__secondary_hold_acknowledge, first_256B))(0)
sync
 
-   li  r26,0
-#ifdef CONFIG_PPC_BOOK3E_64
-   tovirt(r26,r26)
-#endif
/* All secondary cpus wait here until told to start. */
-100:   ld  r12,(ABS_ADDR(__secondary_hold_spinloop, first_256B))(r26)
+100:   ld  r12,(ABS_ADDR(__secondary_hold_spinloop, first_256B))(0)
cmpdi   0,r12,0
beq 100b
 
-- 
2.37.2



[RFC PATCH 2/9] powerpc/64s: Refactor initialisation after prom

2022-12-27 Thread Nicholas Piggin
Move some basic Book3S initialisation after prom to a function similar
to what Book3E looks like. Book3E returns from this function at the
virtual address mapping, and Book3S will do the same in a later change,
so making them look similar helps with that.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/head_64.S | 44 ---
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 7558ba4eb864..5af2e473b195 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -475,8 +475,30 @@ SYM_FUNC_START_LOCAL(__mmu_off)
rfid
b   .   /* prevent speculative execution */
 SYM_FUNC_END(__mmu_off)
-#endif
 
+start_initialization_book3s:
+   mflrr25
+
+   /* Setup some critical 970 SPRs before switching MMU off */
+   mfspr   r0,SPRN_PVR
+   srwir0,r0,16
+   cmpwi   r0,0x39 /* 970 */
+   beq 1f
+   cmpwi   r0,0x3c /* 970FX */
+   beq 1f
+   cmpwi   r0,0x44 /* 970MP */
+   beq 1f
+   cmpwi   r0,0x45 /* 970GX */
+   bne 2f
+1: bl  __cpu_preinit_ppc970
+2:
+
+   /* Switch off MMU if not already off */
+   bl  __mmu_off
+
+   mtlrr25
+   blr
+#endif
 
 /*
  * Here is our main kernel entry point. We support currently 2 kind of entries
@@ -523,26 +545,10 @@ __start_initialization_multiplatform:
 
 #ifdef CONFIG_PPC_BOOK3E_64
bl  start_initialization_book3e
-   b   __after_prom_start
 #else
-   /* Setup some critical 970 SPRs before switching MMU off */
-   mfspr   r0,SPRN_PVR
-   srwir0,r0,16
-   cmpwi   r0,0x39 /* 970 */
-   beq 1f
-   cmpwi   r0,0x3c /* 970FX */
-   beq 1f
-   cmpwi   r0,0x44 /* 970MP */
-   beq 1f
-   cmpwi   r0,0x45 /* 970GX */
-   bne 2f
-1: bl  __cpu_preinit_ppc970
-2:
-
-   /* Switch off MMU if not already off */
-   bl  __mmu_off
-   b   __after_prom_start
+   bl  start_initialization_book3s
 #endif /* CONFIG_PPC_BOOK3E_64 */
+   b   __after_prom_start
 
 __REF
 __boot_from_prom:
-- 
2.37.2



[RFC PATCH 0/9] powerpc/64: Build with PC-Relative addressing

2022-12-27 Thread Nicholas Piggin
This is a more complete change than my earlier hack. Namely fixed the
boot code so it's more unified rather than adding a special case for
Book3S+PCREL. Lots of bug fixes, and adding some of the ftrace and BPF
trampoline/stubs. And added module support, which might be the most
interesting bit.

This won't see a lot of real use until POWER10 is the oldest supported
CPU for distros, but being as we're quite a unique user of toolchain I'd
like to start ironing things out earlier rather than later. I'm making a
list of observations here, https://github.com/linuxppc/issues/issues/455
and will take them to toolchan developers after the kernel work is a bit
further along.

Thanks,
Nick

Nicholas Piggin (9):
  crypto: powerpc - Use address generation helper for asm
  powerpc/64s: Refactor initialisation after prom
  powerpc/64e: Simplify address calculation in secondary hold loop
  powerpc/64: Move initial base and TOC pointer calculation
  powerpc/64s: Run at the kernel virtual address earlier in boot
  powerpc: add CFUNC assembly label annotation
  powerpc/64: Add support to build with prefixed instructions
  powerpc/64: vmlinux support building with PCREL addresing
  powerpc/64: modules support building with PCREL addresing

 arch/powerpc/Kconfig|   6 +
 arch/powerpc/Makefile   |  10 +
 arch/powerpc/crypto/crc32-vpmsum_core.S |  13 +-
 arch/powerpc/include/asm/atomic.h   |  24 +-
 arch/powerpc/include/asm/io.h   |  37 +++
 arch/powerpc/include/asm/module.h   |   9 +-
 arch/powerpc/include/asm/paca.h |   2 +
 arch/powerpc/include/asm/ppc-opcode.h   |   8 +
 arch/powerpc/include/asm/ppc_asm.h  |  24 ++
 arch/powerpc/include/asm/sections.h |   5 +
 arch/powerpc/include/asm/uaccess.h  |  28 +-
 arch/powerpc/include/uapi/asm/elf.h |   4 +
 arch/powerpc/kernel/asm-offsets.c   |   2 +
 arch/powerpc/kernel/exceptions-64s.S| 112 
 arch/powerpc/kernel/head_64.S   | 179 +++-
 arch/powerpc/kernel/interrupt_64.S  |  28 +-
 arch/powerpc/kernel/irq.c   |   8 +
 arch/powerpc/kernel/misc_64.S   |   2 +-
 arch/powerpc/kernel/module_64.c | 344 
 arch/powerpc/kernel/paca.c  |   2 +
 arch/powerpc/kernel/trace/ftrace.c  |  52 +++-
 arch/powerpc/kernel/vdso/gettimeofday.S |   6 +-
 arch/powerpc/kernel/vector.S|   6 +
 arch/powerpc/kernel/vmlinux.lds.S   |   6 +
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |  16 +-
 arch/powerpc/lib/copypage_64.S  |   4 +-
 arch/powerpc/lib/copypage_power7.S  |   4 +-
 arch/powerpc/lib/copyuser_power7.S  |   8 +-
 arch/powerpc/lib/hweight_64.S   |   8 +-
 arch/powerpc/lib/memcmp_64.S|   4 +-
 arch/powerpc/lib/memcpy_power7.S|   6 +-
 arch/powerpc/net/bpf_jit.h  |  10 +-
 arch/powerpc/net/bpf_jit_comp64.c   |  35 ++-
 arch/powerpc/platforms/Kconfig.cputype  |  38 +++
 arch/powerpc/platforms/pseries/hvCall.S |   4 +-
 arch/powerpc/xmon/xmon.c|   2 +
 36 files changed, 793 insertions(+), 263 deletions(-)

-- 
2.37.2



[RFC PATCH 1/9] crypto: powerpc - Use address generation helper for asm

2022-12-27 Thread Nicholas Piggin
Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/crypto/crc32-vpmsum_core.S | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/crypto/crc32-vpmsum_core.S 
b/arch/powerpc/crypto/crc32-vpmsum_core.S
index a16a717c809c..b0f87f595b26 100644
--- a/arch/powerpc/crypto/crc32-vpmsum_core.S
+++ b/arch/powerpc/crypto/crc32-vpmsum_core.S
@@ -113,9 +113,7 @@ FUNC_START(CRC_FUNCTION_NAME)
 #endif
 
 #ifdef BYTESWAP_DATA
-   addis   r3,r2,.byteswap_constant@toc@ha
-   addir3,r3,.byteswap_constant@toc@l
-
+   LOAD_REG_ADDR(r3, .byteswap_constant)
lvx byteswap,0,r3
addir3,r3,16
 #endif
@@ -150,8 +148,7 @@ FUNC_START(CRC_FUNCTION_NAME)
addir7,r7,-1
mtctr   r7
 
-   addis   r3,r2,.constants@toc@ha
-   addir3,r3,.constants@toc@l
+   LOAD_REG_ADDR(r3, .constants)
 
/* Find the start of our constants */
add r3,r3,r8
@@ -506,8 +503,7 @@ FUNC_START(CRC_FUNCTION_NAME)
 
 .Lbarrett_reduction:
/* Barrett constants */
-   addis   r3,r2,.barrett_constants@toc@ha
-   addir3,r3,.barrett_constants@toc@l
+   LOAD_REG_ADDR(r3, .barrett_constants)
 
lvx const1,0,r3
lvx const2,off16,r3
@@ -610,8 +606,7 @@ FUNC_START(CRC_FUNCTION_NAME)
cmpdi   r5,0
beq .Lzero
 
-   addis   r3,r2,.short_constants@toc@ha
-   addir3,r3,.short_constants@toc@l
+   LOAD_REG_ADDR(r3, .short_constants)
 
/* Calculate where in the constant table we need to start */
subfic  r6,r5,256
-- 
2.37.2



Re: Build regressions/improvements in v6.2-rc1

2022-12-27 Thread Geert Uytterhoeven

On Tue, 27 Dec 2022, Geert Uytterhoeven wrote:

Below is the list of build error/warning regressions/improvements in
v6.2-rc1[1] compared to v6.1[2].

Summarized:
 - build errors: +11/-13


amd-...@lists.freedesktop.org
linux-arm-ker...@lists.infradead.org
linux-me...@vger.kernel.org
linux-wirel...@vger.kernel.org
linux-m...@vger.kernel.org
linux...@vger.kernel.org
linux-f2fs-de...@lists.sourceforge.net
linuxppc-dev@lists.ozlabs.org
kasan-...@googlegroups.com
linux-xte...@linux-xtensa.org

  + 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:
 error: the frame size of 2224 bytes is larger than 2048 bytes 
[-Werror=frame-larger-than=]:  => 7082:1
  + 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:
 error: the frame size of 2208 bytes is larger than 2048 bytes 
[-Werror=frame-larger-than=]:  => 7127:1

arm64-gcc5/arm64-allmodconfig

  + /kisskb/src/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c: error: array 
subscript 2 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} 
[-Werror=array-bounds]:  => 641:28
  + /kisskb/src/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c: error: array 
subscript 3 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} 
[-Werror=array-bounds]:  => 641:28

m68k-gcc8/m68k-allmodconfig
See also 
https://lore.kernel.org/all/camuhmdwppx2mpqfewjjbjsqvdbqoxyjjdpknqu9qurauvzx...@mail.gmail.com

  + /kisskb/src/include/linux/bitfield.h: error: call to '__field_overflow' 
declared with attribute error: value doesn't fit into mask:  => 151:3

In function 'u32_encode_bits',
inlined from 'ieee80211_mlo_multicast_tx' at 
/kisskb/src/net/mac80211/tx.c:4435:17,
inlined from 'ieee80211_subif_start_xmit' at 
/kisskb/src/net/mac80211/tx.c:4483:3:

mipsel-gcc5/mips-allmodconfig

  + /kisskb/src/include/linux/compiler_types.h: error: call to 
'__compiletime_assert_262' declared with attribute error: Unsupported access size 
for {READ,WRITE}_ONCE().:  => 358:45
  + /kisskb/src/include/linux/compiler_types.h: error: call to 
'__compiletime_assert_263' declared with attribute error: Unsupported access size 
for {READ,WRITE}_ONCE().:  => 358:45

In function 'follow_pmd_mask',
inlined from 'follow_pud_mask' at /kisskb/src/mm/gup.c:735:9,
inlined from 'follow_p4d_mask' at /kisskb/src/mm/gup.c:752:9,
inlined from 'follow_page_mask' at /kisskb/src/mm/gup.c:809:9:

sh4-gcc11/sh-defconfig (Günter wondered if pmd_t should use union)

  + /kisskb/src/include/linux/fortify-string.h: error: '__builtin_memcpy' offset 
[0, 127] is out of the bounds [0, 0] [-Werror=array-bounds]:  => 57:33

/kisskb/src/arch/s390/kernel/setup.c: In function 'setup_lowcore_dat_on':
s390x-gcc11/s390-all{mod,yes}config

  + /kisskb/src/include/linux/fortify-string.h: error: '__builtin_memset' pointer 
overflow between offset [28, 898293814] and size [-898293787, -1] 
[-Werror=array-bounds]:  => 59:33

/kisskb/src/fs/f2fs/inline.c: In function 'f2fs_move_inline_dirents':

powerpc-gcc11/ppc64_book3e_allmodconfig
powerpc-gcc11/powerpc-all{mod,yes}config

  + /kisskb/src/kernel/kcsan/kcsan_test.c: error: the frame size of 1680 bytes is 
larger than 1536 bytes [-Werror=frame-larger-than=]:  => 257:1

xtensa-gcc11/xtensa-allmodconfig (patch available)

  + {standard input}: Error: unknown pseudo-op: `.cfi_def_c':  => 1718

sh4-gcc11/sh-allmodconfig (ICE = internal compiler error)


[1] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/1b929c02afd37871d5afb9d498426f83432e71c2/
 (all 152 configs)
[2] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/830b3c68c1fb1e9176028d02ef86f3cf76aa2476/
 (all 152 configs)


Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds