Skip to contentSkip to conversation

arm/arm64: Unify PSCI client support

PATCH New Mark Rutland 3 participants 9 messages Jul 31, 2015 – Aug 5, 2015

Subsystems (6)
lore
Share & tools
lore

Mark Rutland

author maintainer
#0 lore raw

v5 cover arm/arm64: Unify PSCI client support

This series unifies the 32-bit and 64-bit PSCI client code, moving the bulk of the FW invocation and probing out to a common location in drivers/firmware. The bulk of the PSCI 0.2 cleanups have hit mainline now, so this is just the unification portion.

This results in a reasonable saving in terms of lines of code, and will allow for PSCI 1.0 support to be unified form the beginning, avoiding further duplication.

Since v4 [1]:
* Apply Rob Herring's ack
* Rebase to v4.2-rc2 to handle a trivial conflict
* Reorder the series to keep arch/arm patches together Since v3 [2]:
* Drop the PSCI 0.2 patches as they're in mainline
* s/__pa/virt_to_idmap/ from Grygorii Strashko
* Use macros for Calxeda CPU_SUSPEND parameters

Russell, are you happy with the arch/arm patches? If so, are you happy for them to go via another tree, or would you prefer that I set up a stable branch for merging?

I was under the impression that you had already taken Grygorii's patch but I couldn't spot it in any branches. I can drop that if you already have it.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/353795.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346492.html

Grygorii Strashko (1):
ARM: psci: boot_secondary: replace __pa with virt_to_idmap

Mark Rutland (4):
arm64: psci: factor invocation code to drivers
drivers: psci: support native SMC{32,64} calls
ARM: migrate to common PSCI client code
MAINTAINERS: add PSCI entry

 MAINTAINERS                       |   9 +
 arch/arm/Kconfig                  |   1 +
 arch/arm/include/asm/psci.h       |  23 ---
 arch/arm/kernel/Makefile          |   2 +-
 arch/arm/kernel/psci.c            | 299 -----------------------------
 arch/arm/kernel/psci_smp.c        |  31 ++-
 arch/arm/kernel/setup.c           |   3 +-
 arch/arm/mach-highbank/highbank.c |   2 +-
 arch/arm/mach-highbank/pm.c       |  16 +-
 arch/arm64/Kconfig                |   1 +
 arch/arm64/include/asm/acpi.h     |   4 +-
 arch/arm64/include/asm/psci.h     |  28 ---
 arch/arm64/kernel/psci.c          | 361 +----------------------------------
 arch/arm64/kernel/setup.c         |   2 +-
 drivers/cpuidle/cpuidle-calxeda.c |  15 +-
 drivers/firmware/Kconfig          |   3 +
 drivers/firmware/Makefile         |   1 +
 drivers/firmware/psci.c           | 383 ++++++++++++++++++++++++++++++++++++++
 include/linux/psci.h              |  52 ++++++
 19 files changed, 501 insertions(+), 735 deletions(-)
 delete mode 100644 arch/arm/kernel/psci.c
 delete mode 100644 arch/arm64/include/asm/psci.h
 create mode 100644 drivers/firmware/psci.c
 create mode 100644 include/linux/psci.h
Signature · 1 line
1.9.1
author maintainer
#1 lore raw

PATCH v5 1/5 arm64: psci: factor invocation code to drivers

To enable sharing with arm, move the core PSCI framework code to drivers/firmware. This results in a minor gain in lines of code, but this will quickly be amortised by the removal of code currently duplicated in arch/arm.

---
 arch/arm64/Kconfig            |   1 +
 arch/arm64/include/asm/acpi.h |   4 +-
 arch/arm64/include/asm/psci.h |  28 ----
 arch/arm64/kernel/psci.c      | 361 +----------------------------------------
 arch/arm64/kernel/setup.c     |   2 +-
 drivers/firmware/Kconfig      |   3 +
 drivers/firmware/Makefile     |   1 +
 drivers/firmware/psci.c       | 370 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/psci.h          |  52 ++++++
 9 files changed, 432 insertions(+), 390 deletions(-)
 delete mode 100644 arch/arm64/include/asm/psci.h
 create mode 100644 drivers/firmware/psci.c
 create mode 100644 include/linux/psci.h
arch/arm64/Kconfig +1 -0
index 318175f..7c55a63 100644
@@ -20,6 +20,7 @@ config ARM64
 	select ARM_GIC_V2M if PCI_MSI
 	select ARM_GIC_V3
 	select ARM_GIC_V3_ITS if PCI_MSI
+	select ARM_PSCI_FW
 	select BUILDTIME_EXTABLE_SORT
 	select CLONE_BACKWARDS
 	select COMMON_CLK
arch/arm64/include/asm/acpi.h +2 -2
index 406485e..208cec0 100644
@@ -12,11 +12,11 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
-#include <linux/mm.h>
 #include <linux/irqchip/arm-gic-acpi.h>
+#include <linux/mm.h>
+#include <linux/psci.h>
 
 #include <asm/cputype.h>
-#include <asm/psci.h>
 #include <asm/smp_plat.h>
 
 /* Macros for consistency checks of the GICC subtable of MADT */
arch/arm64/include/asm/psci.h deleted +0 -28
deleted file mode 100644
index 49d7e1a..0000000
@@ -1,28 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * Copyright (C) 2013 ARM Limited
- */
-
-#ifndef __ASM_PSCI_H
-#define __ASM_PSCI_H
-
-int __init psci_dt_init(void);
-
-#ifdef CONFIG_ACPI
-int __init psci_acpi_init(void);
-bool __init acpi_psci_present(void);
-bool __init acpi_psci_use_hvc(void);
-#else
-static inline int psci_acpi_init(void) { return 0; }
-static inline bool acpi_psci_present(void) { return false; }
-#endif
-
-#endif /* __ASM_PSCI_H */
arch/arm64/kernel/psci.c +2 -359

396 lines not on this page · raw message

arch/arm64/kernel/setup.c +1 -1
index f3067d4..96ce264 100644
@@ -46,6 +46,7 @@
 #include <linux/of_platform.h>
 #include <linux/efi.h>
 #include <linux/personality.h>
+#include <linux/psci.h>
 
 #include <asm/acpi.h>
 #include <asm/fixmap.h>
@@ -61,7 +62,6 @@
 #include <asm/tlbflush.h>
 #include <asm/traps.h>
 #include <asm/memblock.h>
-#include <asm/psci.h>
 #include <asm/efi.h>
 #include <asm/virt.h>
 #include <asm/xen/hypervisor.h>
drivers/firmware/Kconfig +3 -0
index 99c69a3..d8de6a8 100644
@@ -5,6 +5,9 @@
 
 menu "Firmware Drivers"
 
+config ARM_PSCI_FW
+	bool
+
 config EDD
 	tristate "BIOS Enhanced Disk Drive calls determine boot disk"
 	depends on X86
drivers/firmware/Makefile +1 -0
index 4a4b897..000830f 100644
@@ -1,6 +1,7 @@
 #
 # Makefile for the linux kernel.
 #
+obj-$(CONFIG_ARM_PSCI_FW)	+= psci.o
 obj-$(CONFIG_DMI)		+= dmi_scan.o
 obj-$(CONFIG_DMI_SYSFS)		+= dmi-sysfs.o
 obj-$(CONFIG_EDD)		+= edd.o
drivers/firmware/psci.c new file +370 -0

370 lines not on this page · raw message

include/linux/psci.h new file +52 -0

52 lines not on this page · raw message

Signature · 1 line
1.9.1
author maintainer
#2 lore raw

PATCH v5 2/5 drivers: psci: support native SMC{32,64} calls

In reply to Mark Rutland

A 32-bit OS cannot make calls with SMC64 IDs, while a 64-bit OS must invoke some PSCI functions with SMC64 IDs.

This patch introduces and makes use of a new macro to choose the appropriate IDs based on the register width of the OS, which will allow 32-bit callers to use the PSCI client code.

---
 drivers/firmware/psci.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)
drivers/firmware/psci.c +19 -6
index 07b2daa..81b70da 100644
@@ -28,6 +28,18 @@
 #include <asm/smp_plat.h>
 
 /*
+ * While a 64-bit OS can make calls with SMC32 calling conventions, for some
+ * calls it is necessary to use SMC64 to pass or return 64-bit values. For such
+ * calls PSCI_0_2_FN_NATIVE(x) will choose the appropriate (native-width)
+ * function ID.
+ */
+#ifdef CONFIG_64BIT
+#define PSCI_0_2_FN_NATIVE(name)	PSCI_0_2_FN64_##name
+#else
+#define PSCI_0_2_FN_NATIVE(name)	PSCI_0_2_FN_##name
+#endif
+
+/*
  * The CPU any Trusted OS is resident on. The trusted OS may reject CPU_OFF
  * calls to its resident CPU, so we must avoid issuing those. We never migrate
  * a Trusted OS even if it claims to be capable of migration -- doing so will
@@ -122,8 +134,8 @@ static int psci_migrate(unsigned long cpuid)
 static int psci_affinity_info(unsigned long target_affinity,
 		unsigned long lowest_affinity_level)
 {
-	return invoke_psci_fn(PSCI_0_2_FN64_AFFINITY_INFO, target_affinity,
-			      lowest_affinity_level, 0);
+	return invoke_psci_fn(PSCI_0_2_FN_NATIVE(AFFINITY_INFO),
+			      target_affinity, lowest_affinity_level, 0);
 }
 
 static int psci_migrate_info_type(void)
@@ -133,7 +145,8 @@ static int psci_migrate_info_type(void)
 
 static unsigned long psci_migrate_info_up_cpu(void)
 {
-	return invoke_psci_fn(PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU, 0, 0, 0);
+	return invoke_psci_fn(PSCI_0_2_FN_NATIVE(MIGRATE_INFO_UP_CPU),
+			      0, 0, 0);
 }
 
 static int get_set_conduit_method(struct device_node *np)
@@ -211,16 +224,16 @@ static void __init psci_init_migrate(void)
 static void __init psci_0_2_set_functions(void)
 {
 	pr_info("Using standard PSCI v0.2 function IDs\n");
-	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
+	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN_NATIVE(CPU_SUSPEND);
 	psci_ops.cpu_suspend = psci_cpu_suspend;
 
 	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
 	psci_ops.cpu_off = psci_cpu_off;
 
-	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
+	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN_NATIVE(CPU_ON);
 	psci_ops.cpu_on = psci_cpu_on;
 
-	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
+	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN_NATIVE(MIGRATE);
 	psci_ops.migrate = psci_migrate;
 
 	psci_ops.affinity_info = psci_affinity_info;
Signature · 1 line
1.9.1
author maintainer
#3 lore raw

PATCH v5 3/5 ARM: psci: boot_secondary: replace __pa with virt_to_idmap

In reply to Mark Rutland

From: Grygorii Strashko <[email protected]>

On some PAE systems (e.g. TI Keystone), memory is above the 32-bit addressable limit, and the interconnect provides an aliased view of parts of physical memory in the 32-bit addressable space. This alias is strictly for boot time usage, and is not otherwise usable because of coherency limitations.

In this case, virt_to_phys(secondary_startup) would return the physical address of the secondary CPU boot entry point, but on such systems, this would be above the 4GB limit.

A separate function, virt_to_idmap(), has been provided to return a usable physical address for functions in the identity mapping, and this must be used in preference to virt_to_phys() or __pa() to find the physical entry point for functions in the identity mapping range.

For other systems, virt_to_idmap() and virt_to_phys() return identical physical addresses.

Tested-by Vitaly Andrianov <[email protected]>

[Mark: apply rmk's suggested rewording]
Cc Russell King <[email protected]>
---
 arch/arm/kernel/psci_smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/kernel/psci_smp.c +1 -1
index 28a1db4..244aadd 100644
@@ -51,7 +51,7 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
 	if (psci_ops.cpu_on)
 		return psci_ops.cpu_on(cpu_logical_map(cpu),
-				       __pa(secondary_startup));
+					virt_to_idmap(&secondary_startup));
 	return -ENODEV;
 }
 
Signature · 1 line
1.9.1
author maintainer
#4 lore raw

PATCH v5 4/5 ARM: migrate to common PSCI client code

In reply to Mark Rutland

Now that the common PSCI client code has been factored out to drivers/firmware, and made safe for 32-bit use, move the 32-bit ARM code over to it. This results in a moderate reduction of duplicated lines, and will prevent further duplication as the PSCI client code is updated for PSCI 1.0 and beyond.

The two legacy platform users of the PSCI invocation code are updated to account for interface changes. In both cases the power state parameter (which is constant) is now generated using macros, so that the pack/unpack logic can be killed in preparation for PSCI 1.0 power state changes.

Cc Catalin Marinas <[email protected]>
Cc Ashwin Chaugule <[email protected]>
Cc Lorenzo Pieralisi <[email protected]>
Cc Russell King <[email protected]>
Cc Will Deacon <[email protected]>
---
 arch/arm/Kconfig                  |   1 +
 arch/arm/include/asm/psci.h       |  23 ---
 arch/arm/kernel/Makefile          |   2 +-
 arch/arm/kernel/psci.c            | 299 --------------------------------------
 arch/arm/kernel/psci_smp.c        |  29 +++-
 arch/arm/kernel/setup.c           |   3 +-
 arch/arm/mach-highbank/highbank.c |   2 +-
 arch/arm/mach-highbank/pm.c       |  16 +-
 drivers/cpuidle/cpuidle-calxeda.c |  15 +-
 9 files changed, 46 insertions(+), 344 deletions(-)
 delete mode 100644 arch/arm/kernel/psci.c
arch/arm/Kconfig +1 -0
index 1c50210..f5cd684 100644
@@ -1496,6 +1496,7 @@ config HOTPLUG_CPU
 config ARM_PSCI
 	bool "Support for the ARM Power State Coordination Interface (PSCI)"
 	depends on CPU_V7
+	select ARM_PSCI_FW
 	help
 	  Say Y here if you want Linux to communicate with system firmware
 	  implementing the PSCI specification for CPU-centric power
arch/arm/include/asm/psci.h +0 -23
index c25ef3e..68ee3ce 100644
@@ -14,34 +14,11 @@
 #ifndef __ASM_ARM_PSCI_H
 #define __ASM_ARM_PSCI_H
 
-#define PSCI_POWER_STATE_TYPE_STANDBY		0
-#define PSCI_POWER_STATE_TYPE_POWER_DOWN	1
-
-struct psci_power_state {
-	u16	id;
-	u8	type;
-	u8	affinity_level;
-};
-
-struct psci_operations {
-	int (*cpu_suspend)(struct psci_power_state state,
-			   unsigned long entry_point);
-	int (*cpu_off)(struct psci_power_state state);
-	int (*cpu_on)(unsigned long cpuid, unsigned long entry_point);
-	int (*migrate)(unsigned long cpuid);
-	int (*affinity_info)(unsigned long target_affinity,
-			unsigned long lowest_affinity_level);
-	int (*migrate_info_type)(void);
-};
-
-extern struct psci_operations psci_ops;
 extern struct smp_operations psci_smp_ops;
 
 #ifdef CONFIG_ARM_PSCI
-int psci_init(void);
 bool psci_smp_available(void);
 #else
-static inline int psci_init(void) { return 0; }
 static inline bool psci_smp_available(void) { return false; }
 #endif
 
arch/arm/kernel/Makefile +1 -1
index e69f7a1..3b995f5 100644
@@ -89,7 +89,7 @@ obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
 ifeq ($(CONFIG_ARM_PSCI),y)
-obj-y				+= psci.o psci-call.o
+obj-y				+= psci-call.o
 obj-$(CONFIG_SMP)		+= psci_smp.o
 endif
 
arch/arm/kernel/psci.c deleted +0 -299

299 lines not on this page · raw message

arch/arm/kernel/psci_smp.c +22 -7
index 244aadd..61c04b0 100644
@@ -17,6 +17,8 @@
 #include <linux/smp.h>
 #include <linux/of.h>
 #include <linux/delay.h>
+#include <linux/psci.h>
+
 #include <uapi/linux/psci.h>
 
 #include <asm/psci.h>
@@ -56,17 +58,29 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle)
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
+int psci_cpu_disable(unsigned int cpu)
+{
+	/* Fail early if we don't have CPU_OFF support */
+	if (!psci_ops.cpu_off)
+		return -EOPNOTSUPP;
+
+	/* Trusted OS will deny CPU_OFF */
+	if (psci_tos_resident_on(cpu))
+		return -EPERM;
+
+	return 0;
+}
+
 void __ref psci_cpu_die(unsigned int cpu)
 {
-       const struct psci_power_state ps = {
-               .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
-       };
+	u32 state = PSCI_POWER_STATE_TYPE_POWER_DOWN <<
+		    PSCI_0_2_POWER_STATE_TYPE_SHIFT;
 
-       if (psci_ops.cpu_off)
-               psci_ops.cpu_off(ps);
+	if (psci_ops.cpu_off)
+		psci_ops.cpu_off(state);
 
-       /* We should never return */
-       panic("psci: cpu %d failed to shutdown\n", cpu);
+	/* We should never return */
+	panic("psci: cpu %d failed to shutdown\n", cpu);
 }
 
 int __ref psci_cpu_kill(unsigned int cpu)
@@ -109,6 +123,7 @@ bool __init psci_smp_available(void)
 struct smp_operations __initdata psci_smp_ops = {
 	.smp_boot_secondary	= psci_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
+	.cpu_disable		= psci_cpu_disable,
 	.cpu_die		= psci_cpu_die,
 	.cpu_kill		= psci_cpu_kill,
 #endif
arch/arm/kernel/setup.c +2 -1
index 36c18b7..9c38bd4 100644
@@ -31,6 +31,7 @@
 #include <linux/bug.h>
 #include <linux/compiler.h>
 #include <linux/sort.h>
+#include <linux/psci.h>
 
 #include <asm/unified.h>
 #include <asm/cp15.h>
@@ -972,7 +973,7 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	arm_dt_init_cpu_maps();
-	psci_init();
+	psci_dt_init();
 	xen_early_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
arch/arm/mach-highbank/highbank.c +1 -1
index 231fba0..6050a14 100644
@@ -28,8 +28,8 @@
 #include <linux/reboot.h>
 #include <linux/amba/bus.h>
 #include <linux/platform_device.h>
+#include <linux/psci.h>
 
-#include <asm/psci.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
arch/arm/mach-highbank/pm.c +9 -7
index 7f2bd85..4003116 100644
@@ -16,19 +16,21 @@
 
 #include <linux/cpu_pm.h>
 #include <linux/init.h>
+#include <linux/psci.h>
 #include <linux/suspend.h>
 
 #include <asm/suspend.h>
-#include <asm/psci.h>
+
+#include <uapi/linux/psci.h>
+
+#define HIGHBANK_SUSPEND_PARAM \
+	((0 << PSCI_0_2_POWER_STATE_ID_SHIFT) | \
+	 (1 << PSCI_0_2_POWER_STATE_AFFL_SHIFT) | \
+	 (PSCI_POWER_STATE_TYPE_POWER_DOWN << PSCI_0_2_POWER_STATE_TYPE_SHIFT))
 
 static int highbank_suspend_finish(unsigned long val)
 {
-	const struct psci_power_state ps = {
-		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
-		.affinity_level = 1,
-	};
-
-	return psci_ops.cpu_suspend(ps, __pa(cpu_resume));
+	return psci_ops.cpu_suspend(HIGHBANK_SUSPEND_PARAM, __pa(cpu_resume));
 }
 
 static int highbank_pm_enter(suspend_state_t state)
drivers/cpuidle/cpuidle-calxeda.c +10 -5
index c13feec..ea9728f 100644
@@ -25,16 +25,21 @@
 #include <linux/init.h>
 #include <linux/mm.h>
 #include <linux/platform_device.h>
+#include <linux/psci.h>
+
 #include <asm/cpuidle.h>
 #include <asm/suspend.h>
-#include <asm/psci.h>
+
+#include <uapi/linux/psci.h>
+
+#define CALXEDA_IDLE_PARAM \
+	((0 << PSCI_0_2_POWER_STATE_ID_SHIFT) | \
+	 (0 << PSCI_0_2_POWER_STATE_AFFL_SHIFT) | \
+	 (PSCI_POWER_STATE_TYPE_POWER_DOWN << PSCI_0_2_POWER_STATE_TYPE_SHIFT))
 
 static int calxeda_idle_finish(unsigned long val)
 {
-	const struct psci_power_state ps = {
-		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
-	};
-	return psci_ops.cpu_suspend(ps, __pa(cpu_resume));
+	return psci_ops.cpu_suspend(CALXEDA_IDLE_PARAM, __pa(cpu_resume));
 }
 
 static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
Signature · 1 line
1.9.1
author maintainer
#5 lore raw

PATCH v5 5/5 MAINTAINERS: add PSCI entry

In reply to Mark Rutland

Add myself and Lorenzo as maintainers of the PSCI client code.

---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)
MAINTAINERS +9 -0
index fd60784..5106f71 100644
@@ -8064,6 +8064,15 @@ S:	Maintained
 F:	include/linux/power_supply.h
 F:	drivers/power/
 
+POWER STATE COORDINATION INTERFACE (PSCI)
+M:	Mark Rutland <[email protected]>
+M:	Lorenzo Pieralisi <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	drivers/firmware/psci.c
+F:	include/linux/psci.h
+F:	include/uapi/linux/psci.h
+
 PNP SUPPORT
 M:	"Rafael J. Wysocki" <[email protected]>
 S:	Maintained
Signature · 1 line
1.9.1
#6 lore raw

v5 cover arm/arm64: Unify PSCI client support

In reply to Mark Rutland

Hi all,

Quoted 18 lines · Mark Rutland

This series unifies the 32-bit and 64-bit PSCI client code, moving the bulk of the FW invocation and probing out to a common location in drivers/firmware. The bulk of the PSCI 0.2 cleanups have hit mainline now, so this is just the unification portion.

This results in a reasonable saving in terms of lines of code, and will allow for PSCI 1.0 support to be unified form the beginning, avoiding further duplication.

Since v4 [1]:
* Apply Rob Herring's ack
* Rebase to v4.2-rc2 to handle a trivial conflict
* Reorder the series to keep arch/arm patches together Since v3 [2]:
* Drop the PSCI 0.2 patches as they're in mainline
* s/__pa/virt_to_idmap/ from Grygorii Strashko
* Use macros for Calxeda CPU_SUSPEND parameters

Quoted 6 lines

Russell, are you happy with the arch/arm patches? If so, are you happy for them to go via another tree, or would you prefer that I set up a stable branch for merging?

I was under the impression that you had already taken Grygorii's patch but I couldn't spot it in any branches. I can drop that if you already have it.

I've been looking at merging this, but it's a tad fiddly touching all of arm, arm64 and drivers. One way to do it would be:

(1) I create a branch containing patches 1,2 and 5 based on -rc2 and merge that into the arm64/for-next/core branch. There's a minor conflict, but it's easy to resolve.

(2) I create another branch, which is just the branch merged in (1) + patches 3 and 4 on top. I send a pull request for that to rmk.

(3) Torvalds will get the minor conflict resolved in (1) when he merges the arm and arm64 trees.

If we're not comfortable with (3), then the whole lot could go via arm-soc instead (including the conflict resolution).

Russell, Olof, any preferences?

Will

#7 lore raw

v5 cover arm/arm64: Unify PSCI client support

Hi,

Quoted 38 lines · Will Deacon

Hi all,

Quoted 18 lines · Mark Rutland

This series unifies the 32-bit and 64-bit PSCI client code, moving the bulk of the FW invocation and probing out to a common location in drivers/firmware. The bulk of the PSCI 0.2 cleanups have hit mainline now, so this is just the unification portion.

This results in a reasonable saving in terms of lines of code, and will allow for PSCI 1.0 support to be unified form the beginning, avoiding further duplication.

Since v4 [1]:
* Apply Rob Herring's ack
* Rebase to v4.2-rc2 to handle a trivial conflict
* Reorder the series to keep arch/arm patches together Since v3 [2]:
* Drop the PSCI 0.2 patches as they're in mainline
* s/__pa/virt_to_idmap/ from Grygorii Strashko
* Use macros for Calxeda CPU_SUSPEND parameters

Quoted 6 lines

Russell, are you happy with the arch/arm patches? If so, are you happy for them to go via another tree, or would you prefer that I set up a stable branch for merging?

I was under the impression that you had already taken Grygorii's patch but I couldn't spot it in any branches. I can drop that if you already have it.

I've been looking at merging this, but it's a tad fiddly touching all of arm, arm64 and drivers. One way to do it would be:

(1) I create a branch containing patches 1,2 and 5 based on -rc2 and merge that into the arm64/for-next/core branch. There's a minor conflict, but it's easy to resolve.

(2) I create another branch, which is just the branch merged in (1) + patches 3 and 4 on top. I send a pull request for that to rmk.

Quoted 7 lines

(3) Torvalds will get the minor conflict resolved in (1) when he merges the arm and arm64 trees.

If we're not comfortable with (3), then the whole lot could go via arm-soc instead (including the conflict resolution).

Russell, Olof, any preferences?

Wouldn't it be easiest to just get acks on patch 3 and 4 and just merge it all through your tree?

-Olof

#8 lore raw

v5 cover arm/arm64: Unify PSCI client support

Quoted 40 lines · Olof Johansson
Quoted 39 lines · Will Deacon
Quoted 18 lines · Mark Rutland

This series unifies the 32-bit and 64-bit PSCI client code, moving the bulk of the FW invocation and probing out to a common location in drivers/firmware. The bulk of the PSCI 0.2 cleanups have hit mainline now, so this is just the unification portion.

This results in a reasonable saving in terms of lines of code, and will allow for PSCI 1.0 support to be unified form the beginning, avoiding further duplication.

Since v4 [1]:
* Apply Rob Herring's ack
* Rebase to v4.2-rc2 to handle a trivial conflict
* Reorder the series to keep arch/arm patches together Since v3 [2]:
* Drop the PSCI 0.2 patches as they're in mainline
* s/__pa/virt_to_idmap/ from Grygorii Strashko
* Use macros for Calxeda CPU_SUSPEND parameters

Quoted 6 lines

Russell, are you happy with the arch/arm patches? If so, are you happy for them to go via another tree, or would you prefer that I set up a stable branch for merging?

I was under the impression that you had already taken Grygorii's patch but I couldn't spot it in any branches. I can drop that if you already have it.

I've been looking at merging this, but it's a tad fiddly touching all of arm, arm64 and drivers. One way to do it would be:

(1) I create a branch containing patches 1,2 and 5 based on -rc2 and merge that into the arm64/for-next/core branch. There's a minor conflict, but it's easy to resolve.

(2) I create another branch, which is just the branch merged in (1) + patches 3 and 4 on top. I send a pull request for that to rmk.

(3) Torvalds will get the minor conflict resolved in (1) when he merges the arm and arm64 trees.

Quoted 7 lines
Quoted 4 lines

If we're not comfortable with (3), then the whole lot could go via arm-soc instead (including the conflict resolution).

Russell, Olof, any preferences?

Wouldn't it be easiest to just get acks on patch 3 and 4 and just merge it all through your tree?

That would work if Russell is ok with it (it needs his acks).

Russell: would you prefer to ack 3+4 and have me take them via the arm64 tree or instead have me send you a pull request with a conflict resolution for Torvalds? Yet another option is to postpone the arch/arm/ part to 4.4.

Will