Hi all,
this is the tenth version of the patch series to move virt_smp_ops out
of mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops. The last patch
introduces smp_init.
Changes in v10:
- add include <linux/types.h> to mach/arch.h.
Jon Medhurst (1):
ARM: Enable selection of SMP operations at boot time
Stefano Stabellini (1):
arm: introduce psci_smp_ops
arch/arm/include/asm/mach/arch.h | 5 ++
arch/arm/include/asm/psci.h | 9 ++++
arch/arm/kernel/Makefile | 5 ++-
arch/arm/kernel/psci.c | 7 +--
arch/arm/kernel/psci_smp.c | 90 ++++++++++++++++++++++++++++++++++++++
arch/arm/kernel/setup.c | 9 +++-
arch/arm/mach-virt/Makefile | 1 -
arch/arm/mach-virt/platsmp.c | 58 ------------------------
arch/arm/mach-virt/virt.c | 3 -
9 files changed, 119 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/kernel/psci_smp.c
delete mode 100644 arch/arm/mach-virt/platsmp.c
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-ops-10-tag
Cheers,
Stefano
From: Jon Medhurst <[email protected]>
Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value. The hook must return true when smp_ops are initialized.
If false the static mdesc->smp_ops will be used by default.
Add the definition of "bool" by including the linux/types.h file to
asm/mach/arch.h and make it self-contained.
Signed-off-by: Jon Medhurst <[email protected]>
Signed-off-by: Nicolas Pitre <[email protected]>
Signed-off-by: Stefano Stabellini <[email protected]>
Signed-off-by: Nicolas Ferre <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Changes in v10:
- add include <linux/types.h> to mach/arch.h.
---
arch/arm/include/asm/mach/arch.h | 5 +++++
arch/arm/kernel/setup.c | 10 ++++++----
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..75bf079 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <linux/types.h>
+
#ifndef __ASSEMBLY__
struct tag;
@@ -16,8 +18,10 @@ struct pt_regs;
struct smp_operations;
#ifdef CONFIG_SMP
#define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
#else
#define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (bool (*)(void))NULL
#endif
struct machine_desc {
@@ -41,6 +45,7 @@ struct machine_desc {
unsigned char reserve_lp2 :1; /* never has lp2 */
char restart_mode; /* default restart mode */
struct smp_operations *smp; /* SMP operations */
+ bool (*smp_init)(void);
void (*fixup)(struct tag *, char **,
struct meminfo *);
void (*reserve)(void);/* reserve mem blocks */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index dad3048..22cc863 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,12 @@ void __init setup_arch(char **cmdline_p)
psci_init();
#ifdef CONFIG_SMP
if (is_smp()) {
- if (psci_smp_available())
- smp_set_ops(&psci_smp_ops);
- else if (mdesc->smp)
- smp_set_ops(mdesc->smp);
+ if (!mdesc->smp_init || !mdesc->smp_init()) {
+ if (psci_smp_available())
+ smp_set_ops(&psci_smp_ops);
+ else if (mdesc->smp)
+ smp_set_ops(mdesc->smp);
+ }
smp_init_cpus();
}
#endif
--
1.7.2.5
Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
Add a cpu_die smp_op based on psci_ops.cpu_off.
Initialize PSCI before setting smp_ops in setup_arch.
If PSCI is available on the platform, prefer psci_smp_ops over the
platform smp_ops.
Changes in v9:
- move comment about PSCI interface from psci.h to psci_smp.c.
Changes in v8:
- merge "prefer psci_smp_ops over mdesc->smp" into this patch.
Changes in v6:
- fixed return values for psci_smp_available and psci_init ifndef
CONFIG_ARM_PSCI.
Changes in v5:
- document psci_operations;
- psci_init returns NULL.
Signed-off-by: Stefano Stabellini <[email protected]>
Acked-by: Will Deacon <[email protected]>
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
---
arch/arm/include/asm/psci.h | 9 ++++
arch/arm/kernel/Makefile | 5 ++-
arch/arm/kernel/psci.c | 7 +--
arch/arm/kernel/psci_smp.c | 90 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/kernel/setup.c | 7 +++-
arch/arm/mach-virt/Makefile | 1 -
arch/arm/mach-virt/platsmp.c | 58 ---------------------------
arch/arm/mach-virt/virt.c | 3 -
8 files changed, 112 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/kernel/psci_smp.c
delete mode 100644 arch/arm/mach-virt/platsmp.c
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..c4ae171 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -32,5 +32,14 @@ struct psci_operations {
};
extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { }
+static inline bool psci_smp_available(void) { return false; }
+#endif
#endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL) += debug.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-$(CONFIG_ARM_VIRT_EXT) += hyp-stub.o
-obj-$(CONFIG_ARM_PSCI) += psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y += psci.o
+obj-$(CONFIG_SMP) += psci_smp.o
+endif
extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
{},
};
-static int __init psci_init(void)
+void __init psci_init(void)
{
struct device_node *np;
const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
np = of_find_matching_node(NULL, psci_of_match);
if (!np)
- return 0;
+ return;
pr_info("probing function IDs from device-tree\n");
@@ -206,6 +206,5 @@ static int __init psci_init(void)
out_put_node:
of_node_put(np);
- return 0;
+ return;
}
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 0000000..6ef139d
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,90 @@
+/*
+ * 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) 2012 ARM Limited
+ *
+ * Author: Will Deacon <[email protected]>
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+
+#include <asm/psci.h>
+#include <asm/smp_plat.h>
+
+/*
+ * psci_smp assumes that the following is true about PSCI:
+ *
+ * cpu_suspend Suspend the execution on a CPU
+ * @state we don't currently describe affinity levels, so just pass 0.
+ * @entry_point the first instruction to be executed on return
+ * returns 0 success, < 0 on failure
+ *
+ * cpu_off Power down a CPU
+ * @state we don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_on Power up a CPU
+ * @cpuid cpuid of target CPU, as from MPIDR
+ * @entry_point the first instruction to be executed on return
+ * returns 0 success, < 0 on failure
+ *
+ * migrate Migrate the context to a different CPU
+ * @cpuid cpuid of target CPU, as from MPIDR
+ * returns 0 success, < 0 on failure
+ *
+ */
+
+extern void secondary_startup(void);
+
+static int __cpuinit 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));
+ return -ENODEV;
+}
+
+static void __cpuinit psci_secondary_init(unsigned int cpu)
+{
+ gic_secondary_init(0);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __ref psci_cpu_die(unsigned int cpu)
+{
+ const struct psci_power_state ps = {
+ .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+ };
+
+ if (psci_ops.cpu_off)
+ psci_ops.cpu_off(ps);
+
+ /* We should never return */
+ panic("psci: cpu %d failed to shutdown\n", cpu);
+}
+#else
+#define psci_cpu_die NULL
+#endif
+
+bool __init psci_smp_available(void)
+{
+ /* is cpu_on available at least? */
+ return (psci_ops.cpu_on != NULL);
+}
+
+struct smp_operations __initdata psci_smp_ops = {
+ .smp_secondary_init = psci_secondary_init,
+ .smp_boot_secondary = psci_boot_secondary,
+ .cpu_die = psci_cpu_die,
+};
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..dad3048 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
#include <asm/cputype.h>
#include <asm/elf.h>
#include <asm/procinfo.h>
+#include <asm/psci.h>
#include <asm/sections.h>
#include <asm/setup.h>
#include <asm/smp_plat.h>
@@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
unflatten_device_tree();
arm_dt_init_cpu_maps();
+ psci_init();
#ifdef CONFIG_SMP
if (is_smp()) {
- smp_set_ops(mdesc->smp);
+ if (psci_smp_available())
+ smp_set_ops(&psci_smp_ops);
+ else if (mdesc->smp)
+ smp_set_ops(mdesc->smp);
smp_init_cpus();
}
#endif
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
index 042afc1..7ddbfa6 100644
--- a/arch/arm/mach-virt/Makefile
+++ b/arch/arm/mach-virt/Makefile
@@ -3,4 +3,3 @@
#
obj-y := virt.o
-obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-virt/platsmp.c b/arch/arm/mach-virt/platsmp.c
deleted file mode 100644
index 8badaab..0000000
--- a/arch/arm/mach-virt/platsmp.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Dummy Virtual Machine - does what it says on the tin.
- *
- * Copyright (C) 2012 ARM Ltd
- * Author: Will Deacon <[email protected]>
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/of.h>
-
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/psci.h>
-#include <asm/smp_plat.h>
-
-extern void secondary_startup(void);
-
-static void __init virt_smp_init_cpus(void)
-{
-}
-
-static void __init virt_smp_prepare_cpus(unsigned int max_cpus)
-{
-}
-
-static int __cpuinit virt_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));
- return -ENODEV;
-}
-
-static void __cpuinit virt_secondary_init(unsigned int cpu)
-{
- gic_secondary_init(0);
-}
-
-struct smp_operations __initdata virt_smp_ops = {
- .smp_init_cpus = virt_smp_init_cpus,
- .smp_prepare_cpus = virt_smp_prepare_cpus,
- .smp_secondary_init = virt_secondary_init,
- .smp_boot_secondary = virt_boot_secondary,
-};
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..4438ed0 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -43,12 +43,9 @@ static const char *virt_dt_match[] = {
NULL
};
-extern struct smp_operations virt_smp_ops;
-
DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
.init_irq = irqchip_init,
.init_time = virt_timer_init,
.init_machine = virt_init,
- .smp = smp_ops(virt_smp_ops),
.dt_compat = virt_dt_match,
MACHINE_END
--
1.7.2.5
ping
On Tue, 30 Apr 2013, Stefano Stabellini wrote:
> Hi all,
> this is the tenth version of the patch series to move virt_smp_ops out
> of mach-virt and make it a generic set of reusable PSCI based smp_ops.
> psci_smp_ops are preferred over the platform smp_ops. The last patch
> introduces smp_init.
>
> Changes in v10:
> - add include <linux/types.h> to mach/arch.h.
>
>
>
> Jon Medhurst (1):
> ARM: Enable selection of SMP operations at boot time
>
> Stefano Stabellini (1):
> arm: introduce psci_smp_ops
>
> arch/arm/include/asm/mach/arch.h | 5 ++
> arch/arm/include/asm/psci.h | 9 ++++
> arch/arm/kernel/Makefile | 5 ++-
> arch/arm/kernel/psci.c | 7 +--
> arch/arm/kernel/psci_smp.c | 90 ++++++++++++++++++++++++++++++++++++++
> arch/arm/kernel/setup.c | 9 +++-
> arch/arm/mach-virt/Makefile | 1 -
> arch/arm/mach-virt/platsmp.c | 58 ------------------------
> arch/arm/mach-virt/virt.c | 3 -
> 9 files changed, 119 insertions(+), 68 deletions(-)
> create mode 100644 arch/arm/kernel/psci_smp.c
> delete mode 100644 arch/arm/mach-virt/platsmp.c
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-ops-10-tag
>
> Cheers,
>
> Stefano
>
Hi Stefano,
On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> ping
Is this a ping to have this pulled into Russell's tree? If so, might be
worth sending a pull request to [email protected].
Has this been in -next?
Will
On Thu, 2 May 2013, Will Deacon wrote:
> Hi Stefano,
>
> On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> > ping
>
> Is this a ping to have this pulled into Russell's tree?
I thought that we agreed that the patches should go via the arm-soc
tree, after Russell acks them.
The ping is for Russell to ack them and Arnd to merge them.
> If so, might be
> worth sending a pull request to [email protected].
>
> Has this been in -next?
Yes they have, because I temporarily added them to my branch in
linux-next.
In fact Stephen found and solved a merge conflict here:
http://marc.info/?l=linux-arm-kernel&m=136722292031420&w=2
On Thu, May 02, 2013 at 06:20:32PM +0100, Stefano Stabellini wrote:
> On Thu, 2 May 2013, Will Deacon wrote:
> > Hi Stefano,
> >
> > On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> > > ping
> >
> > Is this a ping to have this pulled into Russell's tree?
>
> I thought that we agreed that the patches should go via the arm-soc
> tree, after Russell acks them.
>
> The ping is for Russell to ack them and Arnd to merge them.
Sorry but I tend not to be around on Tuesdays and Wednesdays, which leads
to a hell of an email problem on Thursdays. I haven't looked at them in
any great detail (I just paged through them so far and on to the next
email.)
I don't really have sufficient time to properly deal with all the email
traffic that is now on this list - even from just flicking through the
messages. It's far too much.
On Thu, 2 May 2013, Russell King - ARM Linux wrote:
> On Thu, May 02, 2013 at 06:20:32PM +0100, Stefano Stabellini wrote:
> > On Thu, 2 May 2013, Will Deacon wrote:
> > > Hi Stefano,
> > >
> > > On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> > > > ping
> > >
> > > Is this a ping to have this pulled into Russell's tree?
> >
> > I thought that we agreed that the patches should go via the arm-soc
> > tree, after Russell acks them.
> >
> > The ping is for Russell to ack them and Arnd to merge them.
>
> Sorry but I tend not to be around on Tuesdays and Wednesdays, which leads
> to a hell of an email problem on Thursdays. I haven't looked at them in
> any great detail (I just paged through them so far and on to the next
> email.)
No problems, if there is one person that can understand being flooded by
emails, that's me.
> I don't really have sufficient time to properly deal with all the email
> traffic that is now on this list - even from just flicking through the
> messages. It's far too much.
This patches have been discussed in great details, would you be content
with Will Deacon and Nicolas Pitre's Acks?
Nobody objected again them so far.
On Thu, May 02, 2013 at 06:20:32PM +0100, Stefano Stabellini wrote:
> On Thu, 2 May 2013, Will Deacon wrote:
> > Hi Stefano,
> >
> > On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> > > ping
> >
> > Is this a ping to have this pulled into Russell's tree?
>
> I thought that we agreed that the patches should go via the arm-soc
> tree, after Russell acks them.
Okay, well, is there a reason for them to go through arm-soc? They
look more like core code to me than SoC specific - they only minimally
touch mach-virt.
On Thu, 2 May 2013, Russell King - ARM Linux wrote:
> On Thu, May 02, 2013 at 06:20:32PM +0100, Stefano Stabellini wrote:
> > On Thu, 2 May 2013, Will Deacon wrote:
> > > Hi Stefano,
> > >
> > > On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> > > > ping
> > >
> > > Is this a ping to have this pulled into Russell's tree?
> >
> > I thought that we agreed that the patches should go via the arm-soc
> > tree, after Russell acks them.
>
> Okay, well, is there a reason for them to go through arm-soc? They
> look more like core code to me than SoC specific - they only minimally
> touch mach-virt.
The original reason is that some SoC specific code depends on this
series (Calxeda I believe).
But you are probably right, if you prefer that I issue a pull request
for your tree, I have no problems with that.
On Thu, May 02, 2013 at 07:42:58PM +0100, Stefano Stabellini wrote:
> On Thu, 2 May 2013, Russell King - ARM Linux wrote:
> > On Thu, May 02, 2013 at 06:20:32PM +0100, Stefano Stabellini wrote:
> > > On Thu, 2 May 2013, Will Deacon wrote:
> > > > Hi Stefano,
> > > >
> > > > On Thu, May 02, 2013 at 06:12:12PM +0100, Stefano Stabellini wrote:
> > > > > ping
> > > >
> > > > Is this a ping to have this pulled into Russell's tree?
> > >
> > > I thought that we agreed that the patches should go via the arm-soc
> > > tree, after Russell acks them.
> >
> > Okay, well, is there a reason for them to go through arm-soc? They
> > look more like core code to me than SoC specific - they only minimally
> > touch mach-virt.
>
> The original reason is that some SoC specific code depends on this
> series (Calxeda I believe).
>
> But you are probably right, if you prefer that I issue a pull request
> for your tree, I have no problems with that.
The only issue that there is is where we are in the development cycle
(almost mid merge window), and I've yet to push anything to Linus thanks
to late discovery of various messups in other chunks of code submitted
via my tree - I'm starting to drop stuff from my tree in the hope that
I'll get back to something that's going to be suitable for mainline.
I really don't want to go pulling anything else at the moment in the
hope of getting what I currently have out the door.
And in any case, we shouldn't be adding any new code to our trees at
this point in time.
On Thursday 02 May 2013, Russell King - ARM Linux wrote:
> The only issue that there is is where we are in the development cycle
> (almost mid merge window), and I've yet to push anything to Linus thanks
> to late discovery of various messups in other chunks of code submitted
> via my tree - I'm starting to drop stuff from my tree in the hope that
> I'll get back to something that's going to be suitable for mainline.
>
> I really don't want to go pulling anything else at the moment in the
> hope of getting what I currently have out the door.
>
> And in any case, we shouldn't be adding any new code to our trees at
> this point in time.
Agreed. I would have like to see the patches in 3.10, but the timing
didn't work out.
Stefano, I'm sure we can queue it up early for 3.11 if you send them
again after the merge window. Sorry you had to go through 10 versions
and not getting it merged in time in the end.
Arnd
Hi,
On Thu, May 2, 2013 at 12:03 PM, Arnd Bergmann <[email protected]> wrote:
> On Thursday 02 May 2013, Russell King - ARM Linux wrote:
>> The only issue that there is is where we are in the development cycle
>> (almost mid merge window), and I've yet to push anything to Linus thanks
>> to late discovery of various messups in other chunks of code submitted
>> via my tree - I'm starting to drop stuff from my tree in the hope that
>> I'll get back to something that's going to be suitable for mainline.
>>
>> I really don't want to go pulling anything else at the moment in the
>> hope of getting what I currently have out the door.
>>
>> And in any case, we shouldn't be adding any new code to our trees at
>> this point in time.
>
> Agreed. I would have like to see the patches in 3.10, but the timing
> didn't work out.
>
> Stefano, I'm sure we can queue it up early for 3.11 if you send them
> again after the merge window. Sorry you had to go through 10 versions
> and not getting it merged in time in the end.
Yeah, sorry for being quiet on this; I've seen the patches go by but
also haven't looked closely at them since timing was pointing more
towards 3.11 material. 3.10 is already a very busy release for us on
arm-soc.
If there's SoC code that needs this as a base, we can do a shared
branch with Russell. That has worked well in the past -- he merges it
but we bring in a copy of the topic in our tree.
-Olof
On 05/02/2013 03:34 PM, Olof Johansson wrote:
> Hi,
>
> On Thu, May 2, 2013 at 12:03 PM, Arnd Bergmann <[email protected]> wrote:
>> On Thursday 02 May 2013, Russell King - ARM Linux wrote:
>>> The only issue that there is is where we are in the development cycle
>>> (almost mid merge window), and I've yet to push anything to Linus thanks
>>> to late discovery of various messups in other chunks of code submitted
>>> via my tree - I'm starting to drop stuff from my tree in the hope that
>>> I'll get back to something that's going to be suitable for mainline.
>>>
>>> I really don't want to go pulling anything else at the moment in the
>>> hope of getting what I currently have out the door.
>>>
>>> And in any case, we shouldn't be adding any new code to our trees at
>>> this point in time.
>>
>> Agreed. I would have like to see the patches in 3.10, but the timing
>> didn't work out.
>>
>> Stefano, I'm sure we can queue it up early for 3.11 if you send them
>> again after the merge window. Sorry you had to go through 10 versions
>> and not getting it merged in time in the end.
>
> Yeah, sorry for being quiet on this; I've seen the patches go by but
> also haven't looked closely at them since timing was pointing more
> towards 3.11 material. 3.10 is already a very busy release for us on
> arm-soc.
>
> If there's SoC code that needs this as a base, we can do a shared
> branch with Russell. That has worked well in the past -- he merges it
> but we bring in a copy of the topic in our tree.
Yes, there will be. I've got highbank about ready to go.
Rob