[PATCH v7] ARM: PJ4B: fix for 3.10-rc

[PATCH v7] ARM: PJ4B: fix for 3.10-rc

[Gregory CLEMENT]

Hello,

This path allows to fix one errata for PJ4B CPUs.

Without this the Armada 370 based board can't boot anymore since
3.10-rc1. So this one really need to be applied on 3.10-rc.

Willy Tarreau have reported that with the last version the kernel
crashed in !SMP. The problem was that all the pj4b cpu functions were
defined in the __CPU_INIT section and in !SMP the code was removed
from the memory once the kernel initialization done. In this version I
fixed this issue by moving the code outside this section, and the
kernel now boots in SMP and !SMP.

Nicolas, would you agree to give your acked-by on this new version
before I sumbit it to Russell King's patch system?

Thanks,

V1 -> V2;
 - Fixed various coding style and typo issues
 - Replaced the "mcr p15, 0, r0, c7, c10, 4" by  "dsb"

V2 -> v3:
 - As suggested by Russell, the first errata is now applied
   dynamically according to the processor type

v3 -> v4:
 - Moved the glob_equ maco into proc-macro.S
 - Split the patch in 2 parts, one for fixing the ID and mask of the
   PJ4B and the second for fixing the errata itself

v4 -> v5:
- Added #ifdef all the places the new symbols conditionally defined
  are used.

v5 -> v6:
- Selected the fix by default if MACH_ARMADA_370 is selected, as
  without it there is no point to use Armada 370 base board.

v6 -> v7:
- Move the pj4b cpu functions outside the CPU_INIT section


Gregory CLEMENT (1):
  ARM PJ4B: Add support for errata 4742

 arch/arm/Kconfig                 | 14 ++++++++++++++
 arch/arm/include/asm/glue-proc.h |  9 +++++++++
 arch/arm/mm/proc-macros.S        |  5 +++++
 arch/arm/mm/proc-v7.S            | 34 +++++++++++++++++++++++++++++++---
 4 files changed, 59 insertions(+), 3 deletions(-)

-- 
1.8.1.2

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Gregory CLEMENT]

This commit fixes the regression on Armada 370 (the kernal hang during
boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".

When coming out of either a Wait for Interrupt (WFI) or a Wait for
Event (WFE) IDLE states, a specific timing sensitivity exists between
the retiring WFI/WFE instructions and the newly issued subsequent
instructions. This sensitivity can result in a CPU hang scenario.  The
workaround is to insert either a Data Synchronization Barrier (DSB) or
Data Memory Barrier (DMB) command immediately after the WFI/WFE
instruction.

This commit was based on the work of Lior Amsalem, but heavily
modified to apply the errata fix dynamically according to the
processor type thanks to the suggestions of Russell King and Nicolas
Pitre.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
---
 arch/arm/Kconfig                 | 14 ++++++++++++++
 arch/arm/include/asm/glue-proc.h |  9 +++++++++
 arch/arm/mm/proc-macros.S        |  5 +++++
 arch/arm/mm/proc-v7.S            | 34 +++++++++++++++++++++++++++++++---
 4 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2651b1d..136f263 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1087,6 +1087,20 @@ if !MMU
 source "arch/arm/Kconfig-nommu"
 endif
 
+config PJ4B_ERRATA_4742
+	bool "PJ4B Errata 4742: IDLE Wake Up Commands can Cause the CPU Core to Cease Operation"
+	depends on CPU_PJ4B && MACH_ARMADA_370
+	default y
+	help
+	  When coming out of either a Wait for Interrupt (WFI) or a Wait for
+	  Event (WFE) IDLE states, a specific timing sensitivity exists between
+	  the retiring WFI/WFE instructions and the newly issued subsequent
+	  instructions.  This sensitivity can result in a CPU hang scenario.
+	  Workaround:
+	  The software must insert either a Data Synchronization Barrier (DSB)
+	  or Data Memory Barrier (DMB) command immediately after the WFI/WFE
+	  instruction
+
 config ARM_ERRATA_326103
 	bool "ARM errata: FSR write bit incorrect on a SWP to read-only memory"
 	depends on CPU_V6
diff --git a/arch/arm/include/asm/glue-proc.h b/arch/arm/include/asm/glue-proc.h
index ac1dd54..8017e94 100644
--- a/arch/arm/include/asm/glue-proc.h
+++ b/arch/arm/include/asm/glue-proc.h
@@ -230,6 +230,15 @@
 # endif
 #endif
 
+#ifdef CONFIG_CPU_PJ4B
+# ifdef CPU_NAME
+#  undef  MULTI_CPU
+#  define MULTI_CPU
+# else
+#  define CPU_NAME cpu_pj4b
+# endif
+#endif
+
 #ifndef MULTI_CPU
 #define cpu_proc_init			__glue(CPU_NAME,_proc_init)
 #define cpu_proc_fin			__glue(CPU_NAME,_proc_fin)
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index f9a0aa7..e3c48a3 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -333,3 +333,8 @@ ENTRY(\name\()_tlb_fns)
 	.endif
 	.size	\name\()_tlb_fns, . - \name\()_tlb_fns
 .endm
+
+.macro globl_equ x, y
+	.globl	\x
+	.equ	\x, \y
+.endm
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 4c8c9c1..e35fec3 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -140,6 +140,29 @@ ENTRY(cpu_v7_do_resume)
 ENDPROC(cpu_v7_do_resume)
 #endif
 
+#ifdef CONFIG_CPU_PJ4B
+	globl_equ	cpu_pj4b_switch_mm,     cpu_v7_switch_mm
+	globl_equ	cpu_pj4b_set_pte_ext,	cpu_v7_set_pte_ext
+	globl_equ	cpu_pj4b_proc_init,	cpu_v7_proc_init
+	globl_equ	cpu_pj4b_proc_fin, 	cpu_v7_proc_fin
+	globl_equ	cpu_pj4b_reset,	   	cpu_v7_reset
+#ifdef CONFIG_PJ4B_ERRATA_4742
+ENTRY(cpu_pj4b_do_idle)
+	dsb					@ WFI may enter a low-power mode
+	wfi
+	dsb					@barrier
+	mov	pc, lr
+ENDPROC(cpu_pj4b_do_idle)
+#else
+	globl_equ	cpu_pj4b_do_idle,  	cpu_v7_do_idle
+#endif
+	globl_equ	cpu_pj4b_dcache_clean_area,	cpu_v7_dcache_clean_area
+	globl_equ	cpu_pj4b_do_suspend,	cpu_v7_do_suspend
+	globl_equ	cpu_pj4b_do_resume,	cpu_v7_do_resume
+	globl_equ	cpu_pj4b_suspend_size,	cpu_v7_suspend_size
+
+#endif
+
 	__CPUINIT
 
 /*
@@ -350,6 +373,9 @@ __v7_setup_stack:
 
 	@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
 	define_processor_functions v7, dabort=v7_early_abort, pabort=v7_pabort, suspend=1
+#ifdef CONFIG_CPU_PJ4B
+	define_processor_functions pj4b, dabort=v7_early_abort, pabort=v7_pabort, suspend=1
+#endif
 
 	.section ".rodata"
 
@@ -362,7 +388,7 @@ __v7_setup_stack:
 	/*
 	 * Standard v7 proc info content
 	 */
-.macro __v7_proc initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0
+.macro __v7_proc initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0, proc_fns = v7_processor_functions
 	ALT_SMP(.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
 			PMD_SECT_AF | PMD_FLAGS_SMP | \mm_mmuflags)
 	ALT_UP(.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
@@ -375,7 +401,7 @@ __v7_setup_stack:
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_FAST_MULT | \
 		HWCAP_EDSP | HWCAP_TLS | \hwcaps
 	.long	cpu_v7_name
-	.long	v7_processor_functions
+	.long	\proc_fns
 	.long	v7wbi_tlb_fns
 	.long	v6_user_fns
 	.long	v7_cache_fns
@@ -407,12 +433,14 @@ __v7_ca9mp_proc_info:
 	/*
 	 * Marvell PJ4B processor.
 	 */
+#ifdef CONFIG_CPU_PJ4B
 	.type   __v7_pj4b_proc_info, #object
 __v7_pj4b_proc_info:
 	.long	0x560f5800
 	.long	0xff0fff00
-	__v7_proc __v7_pj4b_setup
+	__v7_proc __v7_pj4b_setup, proc_fns = pj4b_processor_functions
 	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
+#endif
 
 	/*
 	 * ARM Ltd. Cortex A7 processor.
-- 
1.8.1.2

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Willy Tarreau]

On Fri, Jun 21, 2013 at 05:31:04PM +0200, Gregory CLEMENT wrote:
> This commit fixes the regression on Armada 370 (the kernal hang during
> boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
> TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".
> 
> When coming out of either a Wait for Interrupt (WFI) or a Wait for
> Event (WFE) IDLE states, a specific timing sensitivity exists between
> the retiring WFI/WFE instructions and the newly issued subsequent
> instructions. This sensitivity can result in a CPU hang scenario.  The
> workaround is to insert either a Data Synchronization Barrier (DSB) or
> Data Memory Barrier (DMB) command immediately after the WFI/WFE
> instruction.
> 
> This commit was based on the work of Lior Amsalem, but heavily
> modified to apply the errata fix dynamically according to the
> processor type thanks to the suggestions of Russell King and Nicolas
> Pitre.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
> Cc: <stable@vger.kernel.org>

Works fine here, kudos Greg! Feel free to add my Tested-by if you
want :

    Tested-By: Willy Tarreau <w@1wt.eu>

Best regards,
Willy

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Ezequiel Garcia]

Hi Greg,

On Fri, Jun 21, 2013 at 05:31:04PM +0200, Gregory CLEMENT wrote:
> This commit fixes the regression on Armada 370 (the kernal hang during
> boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
> TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".
> 
> When coming out of either a Wait for Interrupt (WFI) or a Wait for
> Event (WFE) IDLE states, a specific timing sensitivity exists between
> the retiring WFI/WFE instructions and the newly issued subsequent
> instructions. This sensitivity can result in a CPU hang scenario.  The
> workaround is to insert either a Data Synchronization Barrier (DSB) or
> Data Memory Barrier (DMB) command immediately after the WFI/WFE
> instruction.
> 
> This commit was based on the work of Lior Amsalem, but heavily
> modified to apply the errata fix dynamically according to the
> processor type thanks to the suggestions of Russell King and Nicolas
> Pitre.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
> Cc: <stable@vger.kernel.org>

This patch doesn't seem to apply on any 3.10-rcX;
maybe I'm doing something wrong, but could you double-check this?

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Willy Tarreau]

On Sat, Jun 22, 2013 at 12:44:22PM -0300, Ezequiel Garcia wrote:
> Hi Greg,
> 
> On Fri, Jun 21, 2013 at 05:31:04PM +0200, Gregory CLEMENT wrote:
> > This commit fixes the regression on Armada 370 (the kernal hang during
> > boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
> > TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".
> > 
> > When coming out of either a Wait for Interrupt (WFI) or a Wait for
> > Event (WFE) IDLE states, a specific timing sensitivity exists between
> > the retiring WFI/WFE instructions and the newly issued subsequent
> > instructions. This sensitivity can result in a CPU hang scenario.  The
> > workaround is to insert either a Data Synchronization Barrier (DSB) or
> > Data Memory Barrier (DMB) command immediately after the WFI/WFE
> > instruction.
> > 
> > This commit was based on the work of Lior Amsalem, but heavily
> > modified to apply the errata fix dynamically according to the
> > processor type thanks to the suggestions of Russell King and Nicolas
> > Pitre.
> >
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Reviewed-by: Will Deacon <will.deacon@arm.com>
> > Cc: <stable@vger.kernel.org>
> 
> This patch doesn't seem to apply on any 3.10-rcX;
> maybe I'm doing something wrong, but could you double-check this?

Interesting, I had the same issue and thought it was because of my
tree, though visually I couldn't spot the issue. It probably was a
space/tab issue only.

Willy

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Willy Tarreau]

On Sat, Jun 22, 2013 at 05:51:03PM +0200, Willy Tarreau wrote:
> On Sat, Jun 22, 2013 at 12:44:22PM -0300, Ezequiel Garcia wrote:
> > Hi Greg,
> > 
> > On Fri, Jun 21, 2013 at 05:31:04PM +0200, Gregory CLEMENT wrote:
> > > This commit fixes the regression on Armada 370 (the kernal hang during
> > > boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
> > > TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".
> > > 
> > > When coming out of either a Wait for Interrupt (WFI) or a Wait for
> > > Event (WFE) IDLE states, a specific timing sensitivity exists between
> > > the retiring WFI/WFE instructions and the newly issued subsequent
> > > instructions. This sensitivity can result in a CPU hang scenario.  The
> > > workaround is to insert either a Data Synchronization Barrier (DSB) or
> > > Data Memory Barrier (DMB) command immediately after the WFI/WFE
> > > instruction.
> > > 
> > > This commit was based on the work of Lior Amsalem, but heavily
> > > modified to apply the errata fix dynamically according to the
> > > processor type thanks to the suggestions of Russell King and Nicolas
> > > Pitre.
> > >
> > > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > > Reviewed-by: Will Deacon <will.deacon@arm.com>
> > > Cc: <stable@vger.kernel.org>
> > 
> > This patch doesn't seem to apply on any 3.10-rcX;
> > maybe I'm doing something wrong, but could you double-check this?
> 
> Interesting, I had the same issue and thought it was because of my
> tree, though visually I couldn't spot the issue. It probably was a
> space/tab issue only.

OK it was probably because of other pending changes since rc6, because
it applied perfectly on top of 3.10-rc7.

Willy

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Russell King - ARM Linux]

On Sun, Jun 23, 2013 at 09:20:58AM +0200, Willy Tarreau wrote:
> On Sat, Jun 22, 2013 at 05:51:03PM +0200, Willy Tarreau wrote:
> > Interesting, I had the same issue and thought it was because of my
> > tree, though visually I couldn't spot the issue. It probably was a
> > space/tab issue only.
> 
> OK it was probably because of other pending changes since rc6, because
> it applied perfectly on top of 3.10-rc7.

It needs its counterpart patch:

049be07053ebbf0ee8543caea23ae7bdf0765bb2
ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B

which did made it into -rc7.

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Willy Tarreau]

On Sun, Jun 23, 2013 at 09:30:55AM +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 23, 2013 at 09:20:58AM +0200, Willy Tarreau wrote:
> > On Sat, Jun 22, 2013 at 05:51:03PM +0200, Willy Tarreau wrote:
> > > Interesting, I had the same issue and thought it was because of my
> > > tree, though visually I couldn't spot the issue. It probably was a
> > > space/tab issue only.
> > 
> > OK it was probably because of other pending changes since rc6, because
> > it applied perfectly on top of 3.10-rc7.
> 
> It needs its counterpart patch:
> 
> 049be07053ebbf0ee8543caea23ae7bdf0765bb2
> ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B
> 
> which did made it into -rc7.

Yes I had it, but maybe an earlier improperly formated version.

Thanks,
Willy

[PATCH v7] ARM PJ4B: Add support for errata 4742

[Ezequiel Garcia]

On Sun, Jun 23, 2013 at 09:30:55AM +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 23, 2013 at 09:20:58AM +0200, Willy Tarreau wrote:
> > On Sat, Jun 22, 2013 at 05:51:03PM +0200, Willy Tarreau wrote:
> > > Interesting, I had the same issue and thought it was because of my
> > > tree, though visually I couldn't spot the issue. It probably was a
> > > space/tab issue only.
> > 
> > OK it was probably because of other pending changes since rc6, because
> > it applied perfectly on top of 3.10-rc7.
> 
> It needs its counterpart patch:
> 
> 049be07053ebbf0ee8543caea23ae7bdf0765bb2
> ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B
> 

Yeap, that's the one I needed.

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH v7] ARM: PJ4B: fix for 3.10-rc

[Nicolas Pitre]

On Fri, 21 Jun 2013, Gregory CLEMENT wrote:

> Hello,
> 
> This path allows to fix one errata for PJ4B CPUs.
> 
> Without this the Armada 370 based board can't boot anymore since
> 3.10-rc1. So this one really need to be applied on 3.10-rc.
> 
> Willy Tarreau have reported that with the last version the kernel
> crashed in !SMP. The problem was that all the pj4b cpu functions were
> defined in the __CPU_INIT section and in !SMP the code was removed
> from the memory once the kernel initialization done. In this version I
> fixed this issue by moving the code outside this section, and the
> kernel now boots in SMP and !SMP.
> 
> Nicolas, would you agree to give your acked-by on this new version
> before I sumbit it to Russell King's patch system?

Yes, you may add my ACK.


> 
> Thanks,
> 
> V1 -> V2;
>  - Fixed various coding style and typo issues
>  - Replaced the "mcr p15, 0, r0, c7, c10, 4" by  "dsb"
> 
> V2 -> v3:
>  - As suggested by Russell, the first errata is now applied
>    dynamically according to the processor type
> 
> v3 -> v4:
>  - Moved the glob_equ maco into proc-macro.S
>  - Split the patch in 2 parts, one for fixing the ID and mask of the
>    PJ4B and the second for fixing the errata itself
> 
> v4 -> v5:
> - Added #ifdef all the places the new symbols conditionally defined
>   are used.
> 
> v5 -> v6:
> - Selected the fix by default if MACH_ARMADA_370 is selected, as
>   without it there is no point to use Armada 370 base board.
> 
> v6 -> v7:
> - Move the pj4b cpu functions outside the CPU_INIT section
> 
> 
> Gregory CLEMENT (1):
>   ARM PJ4B: Add support for errata 4742
> 
>  arch/arm/Kconfig                 | 14 ++++++++++++++
>  arch/arm/include/asm/glue-proc.h |  9 +++++++++
>  arch/arm/mm/proc-macros.S        |  5 +++++
>  arch/arm/mm/proc-v7.S            | 34 +++++++++++++++++++++++++++++++---
>  4 files changed, 59 insertions(+), 3 deletions(-)
> 
> -- 
> 1.8.1.2
> 

[PATCH v7] ARM: PJ4B: fix for 3.10-rc

[Thomas Petazzoni]

Hello,

On Fri, 21 Jun 2013 17:31:03 +0200, Gregory CLEMENT wrote:

> This path allows to fix one errata for PJ4B CPUs.
> 
> Without this the Armada 370 based board can't boot anymore since
> 3.10-rc1. So this one really need to be applied on 3.10-rc.

I'd like to point out that this patch is really needed for 3.10-rc,
*OR* ae8a8b9553 ("ARM: 7691/1: mm: kill unused
TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead") should be
reverted, as it introduces a regression compared to 3.9.

Without one of those two solutions, 3.10 cannot boot on Armada 370
platforms, which is a clear regression compared to 3.9.

Linus has just released 3.10-rc7 and said it would most likely be the
last rc.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v7] ARM: PJ4B: fix for 3.10-rc

[Russell King - ARM Linux]

On Sun, Jun 23, 2013 at 10:20:36AM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 21 Jun 2013 17:31:03 +0200, Gregory CLEMENT wrote:
> 
> > This path allows to fix one errata for PJ4B CPUs.
> > 
> > Without this the Armada 370 based board can't boot anymore since
> > 3.10-rc1. So this one really need to be applied on 3.10-rc.
> 
> I'd like to point out that this patch is really needed for 3.10-rc,
> *OR* ae8a8b9553 ("ARM: 7691/1: mm: kill unused
> TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead") should be
> reverted, as it introduces a regression compared to 3.9.
> 
> Without one of those two solutions, 3.10 cannot boot on Armada 370
> platforms, which is a clear regression compared to 3.9.
> 
> Linus has just released 3.10-rc7 and said it would most likely be the
> last rc.

The only thing I can say is that it would have been in -rc7 if the previous
revision hadn't contained a mistake.

And I also see no sign of this patch in the patch system yet.

[PATCH v7] ARM: PJ4B: fix for 3.10-rc

[Gregory CLEMENT]

On 06/23/2013 10:27 AM, Russell King - ARM Linux wrote:
> On Sun, Jun 23, 2013 at 10:20:36AM +0200, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Fri, 21 Jun 2013 17:31:03 +0200, Gregory CLEMENT wrote:
>>
>>> This path allows to fix one errata for PJ4B CPUs.
>>>
>>> Without this the Armada 370 based board can't boot anymore since
>>> 3.10-rc1. So this one really need to be applied on 3.10-rc.
>>
>> I'd like to point out that this patch is really needed for 3.10-rc,
>> *OR* ae8a8b9553 ("ARM: 7691/1: mm: kill unused
>> TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead") should be
>> reverted, as it introduces a regression compared to 3.9.
>>
>> Without one of those two solutions, 3.10 cannot boot on Armada 370
>> platforms, which is a clear regression compared to 3.9.
>>
>> Linus has just released 3.10-rc7 and said it would most likely be the
>> last rc.
> 
> The only thing I can say is that it would have been in -rc7 if the previous
> revision hadn't contained a mistake.
> 
> And I also see no sign of this patch in the patch system yet.
> 

It is now on the pacth system. I was waiting for at least a few hours,
to let people give their feedback and test it.


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com