arm/arm64: Unify PSCI client support
Subsystems (6)
Mark Rutland
maintainerv5 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
Mark Rutland
maintainerPATCH 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Mark Rutland
maintainerPATCH v5 2/5 drivers: psci: support native SMC{32,64} calls
In reply to Mark RutlandA 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
@@ -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
Mark Rutland
maintainerPATCH v5 3/5 ARM: psci: boot_secondary: replace __pa with virt_to_idmap
In reply to Mark RutlandFrom: 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]>
--- arch/arm/kernel/psci_smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/kernel/psci_smp.c +1 -1
@@ -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
Mark Rutland
maintainerPATCH v5 4/5 ARM: migrate to common PSCI client code
In reply to Mark RutlandNow 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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Mark Rutland
maintainerPATCH v5 5/5 MAINTAINERS: add PSCI entry
In reply to Mark RutlandAdd myself and Lorenzo as maintainers of the PSCI client code.
--- MAINTAINERS | 9 +++++++++ 1 file changed, 9 insertions(+)
MAINTAINERS +9 -0
@@ -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
v5 cover arm/arm64: Unify PSCI client support
In reply to Mark RutlandHi 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 keeparch/armpatches 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 CalxedaCPU_SUSPENDparameters
Quoted 6 lines
Russell, are you happy with the
arch/armpatches? 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
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 keeparch/armpatches 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 CalxedaCPU_SUSPENDparametersQuoted 6 lines
Russell, are you happy with the
arch/armpatches? 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
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 keeparch/armpatches 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 CalxedaCPU_SUSPENDparametersQuoted 6 lines
Russell, are you happy with the
arch/armpatches? 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