[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[Laurent Pinchart]

Hello,

(Resending due to a typo in an e-mail address that caused LAKML to reject the
mails. Sorry about the noise.)

This patch set reworks Ezequiel Garcia's previous fix [1] of an out of vmalloc
space bug on PXA2[57]x platforms caused by an attempt to map the start of
physical uncached outside of the vmalloc space.

This first three patches perform a couple of cleanups, and the last patch
fixes the problem. I've decided to map the memory at address 0xfe000000 to
minimize changes to the code, but this causes a bit of fragmentation of
vmalloc space. I could map it to the very end of vmalloc space (0xfef00000)
instead if preferred, which would involve replacing a mov by an ldr in
pxa2[57]x_finish_suspend and pm_enter_standby_start.

I've tested the patch set on a PXA270-based system.

[1] https://lkml.org/lkml/2013/11/28/474

Ezequiel Garcia (1):
  ARM: pxa: Move iotable mapping inside vmalloc region

Laurent Pinchart (3):
  ARM: pxa: Don't hardcode addresses and size in map_desc tables
  ARM: pxa: Move UNCACHED_PHYS_0 mapping from generic.c to pxa2[57]x.c
  ARM: pxa: pxa27x: Don't map IMEMC region statically

 arch/arm/mach-pxa/generic.c               | 11 +++--------
 arch/arm/mach-pxa/include/mach/hardware.h |  4 ++--
 arch/arm/mach-pxa/pxa25x.c                |  7 ++++++-
 arch/arm/mach-pxa/pxa27x.c                | 10 +++++-----
 arch/arm/mach-pxa/pxa3xx.c                |  2 +-
 5 files changed, 17 insertions(+), 17 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH v3 1/4] ARM: pxa: Don't hardcode addresses and size in map_desc tables

[Laurent Pinchart]

The virtual address, physical address and size of all regions for which
we create static mappings are defined in PXA headers. Replaced the
hardcoded values with macros.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-pxa/generic.c               | 10 +++++-----
 arch/arm/mach-pxa/include/mach/hardware.h |  2 +-
 arch/arm/mach-pxa/pxa25x.c                |  2 +-
 arch/arm/mach-pxa/pxa27x.c                |  8 ++++----
 arch/arm/mach-pxa/pxa3xx.c                |  2 +-
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 4225417..4bc0a2c 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -79,14 +79,14 @@ EXPORT_SYMBOL(get_clk_frequency_khz);
  */
 static struct map_desc common_io_desc[] __initdata = {
   	{	/* Devs */
-		.virtual	=  0xf2000000,
-		.pfn		= __phys_to_pfn(0x40000000),
-		.length		= 0x02000000,
+		.virtual	= (unsigned long)PERIPH_VIRT,
+		.pfn		= __phys_to_pfn(PERIPH_PHYS),
+		.length		= PERIPH_SIZE,
 		.type		= MT_DEVICE
 	}, {	/* UNCACHED_PHYS_0 */
-		.virtual	= 0xff000000,
+		.virtual	= UNCACHED_PHYS_0,
 		.pfn		= __phys_to_pfn(0x00000000),
-		.length		= 0x00100000,
+		.length		= UNCACHED_PHYS_0_SIZE,
 		.type		= MT_DEVICE
 	}
 };
diff --git a/arch/arm/mach-pxa/include/mach/hardware.h b/arch/arm/mach-pxa/include/mach/hardware.h
index ccb06e4..efb3965 100644
--- a/arch/arm/mach-pxa/include/mach/hardware.h
+++ b/arch/arm/mach-pxa/include/mach/hardware.h
@@ -20,7 +20,7 @@
  * The mapping is set in mach-pxa/generic.c.
  */
 #define UNCACHED_PHYS_0		0xff000000
-#define UNCACHED_ADDR		UNCACHED_PHYS_0
+#define UNCACHED_PHYS_0_SIZE	0x00100000
 
 /*
  * Intel PXA2xx internal register mapping:
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index f2c2897..926c506 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -331,7 +331,7 @@ static struct map_desc pxa25x_io_desc[] __initdata = {
 	{	/* Mem Ctl */
 		.virtual	= (unsigned long)SMEMC_VIRT,
 		.pfn		= __phys_to_pfn(PXA2XX_SMEMC_BASE),
-		.length		= 0x00200000,
+		.length		= SMEMC_SIZE,
 		.type		= MT_DEVICE
 	},
 };
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 301471a..4405644 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -402,12 +402,12 @@ static struct map_desc pxa27x_io_desc[] __initdata = {
 	{	/* Mem Ctl */
 		.virtual	= (unsigned long)SMEMC_VIRT,
 		.pfn		= __phys_to_pfn(PXA2XX_SMEMC_BASE),
-		.length		= 0x00200000,
+		.length		= SMEMC_SIZE,
 		.type		= MT_DEVICE
 	}, {	/* IMem ctl */
-		.virtual	=  0xfe000000,
-		.pfn		= __phys_to_pfn(0x58000000),
-		.length		= 0x00100000,
+		.virtual	= (unsigned long)IMEMC_VIRT,
+		.pfn		= __phys_to_pfn(IMEMC_PHYS),
+		.length		= IMEMC_SIZE,
 		.type		= MT_DEVICE
 	},
 };
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index 87011f3..593ccd35 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -416,7 +416,7 @@ static struct map_desc pxa3xx_io_desc[] __initdata = {
 	{	/* Mem Ctl */
 		.virtual	= (unsigned long)SMEMC_VIRT,
 		.pfn		= __phys_to_pfn(PXA3XX_SMEMC_BASE),
-		.length		= 0x00200000,
+		.length		= SMEMC_SIZE,
 		.type		= MT_DEVICE
 	}
 };
-- 
1.8.3.2

[PATCH v3 2/4] ARM: pxa: Move UNCACHED_PHYS_0 mapping from generic.c to pxa2[57]x.c

[Laurent Pinchart]

The UNCACHED_PHYS_0 mapping is only needed on PXA25x and PXA27x
platforms. Move it to pxa25x.c and pxa27x.c to avoid wasting vmalloc
space on PXA3xx.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-pxa/generic.c | 5 -----
 arch/arm/mach-pxa/pxa25x.c  | 5 +++++
 arch/arm/mach-pxa/pxa27x.c  | 5 +++++
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 4bc0a2c..6bd7f36 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -83,11 +83,6 @@ static struct map_desc common_io_desc[] __initdata = {
 		.pfn		= __phys_to_pfn(PERIPH_PHYS),
 		.length		= PERIPH_SIZE,
 		.type		= MT_DEVICE
-	}, {	/* UNCACHED_PHYS_0 */
-		.virtual	= UNCACHED_PHYS_0,
-		.pfn		= __phys_to_pfn(0x00000000),
-		.length		= UNCACHED_PHYS_0_SIZE,
-		.type		= MT_DEVICE
 	}
 };
 
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 926c506..66e4a2b 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -333,6 +333,11 @@ static struct map_desc pxa25x_io_desc[] __initdata = {
 		.pfn		= __phys_to_pfn(PXA2XX_SMEMC_BASE),
 		.length		= SMEMC_SIZE,
 		.type		= MT_DEVICE
+	}, {	/* UNCACHED_PHYS_0 */
+		.virtual	= UNCACHED_PHYS_0,
+		.pfn		= __phys_to_pfn(0x00000000),
+		.length		= UNCACHED_PHYS_0_SIZE,
+		.type		= MT_DEVICE
 	},
 };
 
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 4405644..6cc0f46 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -409,6 +409,11 @@ static struct map_desc pxa27x_io_desc[] __initdata = {
 		.pfn		= __phys_to_pfn(IMEMC_PHYS),
 		.length		= IMEMC_SIZE,
 		.type		= MT_DEVICE
+	}, {	/* UNCACHED_PHYS_0 */
+		.virtual	= UNCACHED_PHYS_0,
+		.pfn		= __phys_to_pfn(0x00000000),
+		.length		= UNCACHED_PHYS_0_SIZE,
+		.type		= MT_DEVICE
 	},
 };
 
-- 
1.8.3.2

[PATCH v3 3/4] ARM: pxa: pxa27x: Don't map IMEMC region statically

[Laurent Pinchart]

The IMEMC mapping not only has no user, but maps a reserved memory
space. It just wastes vmalloc space, remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-pxa/pxa27x.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 6cc0f46..b040d7d 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -404,11 +404,6 @@ static struct map_desc pxa27x_io_desc[] __initdata = {
 		.pfn		= __phys_to_pfn(PXA2XX_SMEMC_BASE),
 		.length		= SMEMC_SIZE,
 		.type		= MT_DEVICE
-	}, {	/* IMem ctl */
-		.virtual	= (unsigned long)IMEMC_VIRT,
-		.pfn		= __phys_to_pfn(IMEMC_PHYS),
-		.length		= IMEMC_SIZE,
-		.type		= MT_DEVICE
 	}, {	/* UNCACHED_PHYS_0 */
 		.virtual	= UNCACHED_PHYS_0,
 		.pfn		= __phys_to_pfn(0x00000000),
-- 
1.8.3.2

[PATCH v3 4/4] ARM: pxa: Move iotable mapping inside vmalloc region

[Laurent Pinchart]

From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

In order to remove the following ugly message:

  BUG: mapping for 0x00000000 at 0xff000000 out of vmalloc space

the iotable mappings should be re-located inside the vmalloc
region. Such move was introduced at commit:

commit 0536bdf33faff4d940ac094c77998cfac368cfff
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Thu Aug 25 00:35:59 2011 -0400

    ARM: move iotable mappings within the vmalloc region

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
[laurent.pinchart at ideasonboard.com: Hardcode the virtual address]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-pxa/include/mach/hardware.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-pxa/include/mach/hardware.h b/arch/arm/mach-pxa/include/mach/hardware.h
index efb3965..8d63c21 100644
--- a/arch/arm/mach-pxa/include/mach/hardware.h
+++ b/arch/arm/mach-pxa/include/mach/hardware.h
@@ -19,7 +19,7 @@
  * Workarounds for at least 2 errata so far require this.
  * The mapping is set in mach-pxa/generic.c.
  */
-#define UNCACHED_PHYS_0		0xff000000
+#define UNCACHED_PHYS_0		0xfe000000
 #define UNCACHED_PHYS_0_SIZE	0x00100000
 
 /*
-- 
1.8.3.2

[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[Nicolas Pitre]

On Wed, 9 Apr 2014, Laurent Pinchart wrote:

> Hello,
> 
> (Resending due to a typo in an e-mail address that caused LAKML to reject the
> mails. Sorry about the noise.)
> 
> This patch set reworks Ezequiel Garcia's previous fix [1] of an out of vmalloc
> space bug on PXA2[57]x platforms caused by an attempt to map the start of
> physical uncached outside of the vmalloc space.
> 
> This first three patches perform a couple of cleanups, and the last patch
> fixes the problem. I've decided to map the memory at address 0xfe000000 to
> minimize changes to the code, but this causes a bit of fragmentation of
> vmalloc space. I could map it to the very end of vmalloc space (0xfef00000)
> instead if preferred, which would involve replacing a mov by an ldr in
> pxa2[57]x_finish_suspend and pm_enter_standby_start.
> 
> I've tested the patch set on a PXA270-based system.

For those patches:

Acked-by: Nicolas Pitre <nico@linaro.org>



> 
> [1] https://lkml.org/lkml/2013/11/28/474
> 
> Ezequiel Garcia (1):
>   ARM: pxa: Move iotable mapping inside vmalloc region
> 
> Laurent Pinchart (3):
>   ARM: pxa: Don't hardcode addresses and size in map_desc tables
>   ARM: pxa: Move UNCACHED_PHYS_0 mapping from generic.c to pxa2[57]x.c
>   ARM: pxa: pxa27x: Don't map IMEMC region statically
> 
>  arch/arm/mach-pxa/generic.c               | 11 +++--------
>  arch/arm/mach-pxa/include/mach/hardware.h |  4 ++--
>  arch/arm/mach-pxa/pxa25x.c                |  7 ++++++-
>  arch/arm/mach-pxa/pxa27x.c                | 10 +++++-----
>  arch/arm/mach-pxa/pxa3xx.c                |  2 +-
>  5 files changed, 17 insertions(+), 17 deletions(-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[Laurent Pinchart]

On Wednesday 09 April 2014 15:05:26 Nicolas Pitre wrote:
> On Wed, 9 Apr 2014, Laurent Pinchart wrote:
> > Hello,
> > 
> > (Resending due to a typo in an e-mail address that caused LAKML to reject
> > the mails. Sorry about the noise.)
> > 
> > This patch set reworks Ezequiel Garcia's previous fix [1] of an out of
> > vmalloc space bug on PXA2[57]x platforms caused by an attempt to map the
> > start of physical uncached outside of the vmalloc space.
> > 
> > This first three patches perform a couple of cleanups, and the last patch
> > fixes the problem. I've decided to map the memory at address 0xfe000000 to
> > minimize changes to the code, but this causes a bit of fragmentation of
> > vmalloc space. I could map it to the very end of vmalloc space
> > (0xfef00000)
> > instead if preferred, which would involve replacing a mov by an ldr in
> > pxa2[57]x_finish_suspend and pm_enter_standby_start.
> > 
> > I've tested the patch set on a PXA270-based system.
> 
> For those patches:
> 
> Acked-by: Nicolas Pitre <nico@linaro.org>

Thank you.

MAINTAINERS lists three maintainers for the PXA architecture, and two git 
trees that seem to be either dead or even deleted. Who picks up patches for 
PXA ? Should I send a pull request ?

> > [1] https://lkml.org/lkml/2013/11/28/474
> > 
> > Ezequiel Garcia (1):
> >   ARM: pxa: Move iotable mapping inside vmalloc region
> > 
> > Laurent Pinchart (3):
> >   ARM: pxa: Don't hardcode addresses and size in map_desc tables
> >   ARM: pxa: Move UNCACHED_PHYS_0 mapping from generic.c to pxa2[57]x.c
> >   ARM: pxa: pxa27x: Don't map IMEMC region statically
> >  
> >  arch/arm/mach-pxa/generic.c               | 11 +++--------
> >  arch/arm/mach-pxa/include/mach/hardware.h |  4 ++--
> >  arch/arm/mach-pxa/pxa25x.c                |  7 ++++++-
> >  arch/arm/mach-pxa/pxa27x.c                | 10 +++++-----
> >  arch/arm/mach-pxa/pxa3xx.c                |  2 +-
> >  5 files changed, 17 insertions(+), 17 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[Nicolas Pitre]

On Fri, 11 Apr 2014, Laurent Pinchart wrote:

> On Wednesday 09 April 2014 15:05:26 Nicolas Pitre wrote:
> > On Wed, 9 Apr 2014, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > (Resending due to a typo in an e-mail address that caused LAKML to reject
> > > the mails. Sorry about the noise.)
> > > 
> > > This patch set reworks Ezequiel Garcia's previous fix [1] of an out of
> > > vmalloc space bug on PXA2[57]x platforms caused by an attempt to map the
> > > start of physical uncached outside of the vmalloc space.
> > > 
> > > This first three patches perform a couple of cleanups, and the last patch
> > > fixes the problem. I've decided to map the memory at address 0xfe000000 to
> > > minimize changes to the code, but this causes a bit of fragmentation of
> > > vmalloc space. I could map it to the very end of vmalloc space
> > > (0xfef00000)
> > > instead if preferred, which would involve replacing a mov by an ldr in
> > > pxa2[57]x_finish_suspend and pm_enter_standby_start.
> > > 
> > > I've tested the patch set on a PXA270-based system.
> > 
> > For those patches:
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> 
> Thank you.
> 
> MAINTAINERS lists three maintainers for the PXA architecture, and two git 
> trees that seem to be either dead or even deleted. Who picks up patches for 
> PXA ? Should I send a pull request ?

If no one else answers, then just send a pull request to the ARM-SOC 
team (arm at kernel.org) and CC the linux-arm-kernel mailing list.


Nicolas

[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[Ezequiel Garcia]

On 10 Apr 08:31 PM, Nicolas Pitre wrote:
> On Fri, 11 Apr 2014, Laurent Pinchart wrote:
> 
> > On Wednesday 09 April 2014 15:05:26 Nicolas Pitre wrote:
> > > On Wed, 9 Apr 2014, Laurent Pinchart wrote:
> > > > Hello,
> > > > 
> > > > (Resending due to a typo in an e-mail address that caused LAKML to reject
> > > > the mails. Sorry about the noise.)
> > > > 
> > > > This patch set reworks Ezequiel Garcia's previous fix [1] of an out of
> > > > vmalloc space bug on PXA2[57]x platforms caused by an attempt to map the
> > > > start of physical uncached outside of the vmalloc space.
> > > > 
> > > > This first three patches perform a couple of cleanups, and the last patch
> > > > fixes the problem. I've decided to map the memory at address 0xfe000000 to
> > > > minimize changes to the code, but this causes a bit of fragmentation of
> > > > vmalloc space. I could map it to the very end of vmalloc space
> > > > (0xfef00000)
> > > > instead if preferred, which would involve replacing a mov by an ldr in
> > > > pxa2[57]x_finish_suspend and pm_enter_standby_start.
> > > > 
> > > > I've tested the patch set on a PXA270-based system.
> > > 
> > > For those patches:
> > > 
> > > Acked-by: Nicolas Pitre <nico@linaro.org>
> > 
> > Thank you.
> > 
> > MAINTAINERS lists three maintainers for the PXA architecture, and two git 
> > trees that seem to be either dead or even deleted. Who picks up patches for 
> > PXA ? Should I send a pull request ?
> 
> If no one else answers, then just send a pull request to the ARM-SOC 
> team (arm at kernel.org) and CC the linux-arm-kernel mailing list.
> 

What ever happened to this?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[Olof Johansson]

On Thu, Jul 10, 2014 at 5:10 AM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> On 10 Apr 08:31 PM, Nicolas Pitre wrote:
>> On Fri, 11 Apr 2014, Laurent Pinchart wrote:
>>
>> > On Wednesday 09 April 2014 15:05:26 Nicolas Pitre wrote:
>> > > On Wed, 9 Apr 2014, Laurent Pinchart wrote:
>> > > > Hello,
>> > > >
>> > > > (Resending due to a typo in an e-mail address that caused LAKML to reject
>> > > > the mails. Sorry about the noise.)
>> > > >
>> > > > This patch set reworks Ezequiel Garcia's previous fix [1] of an out of
>> > > > vmalloc space bug on PXA2[57]x platforms caused by an attempt to map the
>> > > > start of physical uncached outside of the vmalloc space.
>> > > >
>> > > > This first three patches perform a couple of cleanups, and the last patch
>> > > > fixes the problem. I've decided to map the memory at address 0xfe000000 to
>> > > > minimize changes to the code, but this causes a bit of fragmentation of
>> > > > vmalloc space. I could map it to the very end of vmalloc space
>> > > > (0xfef00000)
>> > > > instead if preferred, which would involve replacing a mov by an ldr in
>> > > > pxa2[57]x_finish_suspend and pm_enter_standby_start.
>> > > >
>> > > > I've tested the patch set on a PXA270-based system.
>> > >
>> > > For those patches:
>> > >
>> > > Acked-by: Nicolas Pitre <nico@linaro.org>
>> >
>> > Thank you.
>> >
>> > MAINTAINERS lists three maintainers for the PXA architecture, and two git
>> > trees that seem to be either dead or even deleted. Who picks up patches for
>> > PXA ? Should I send a pull request ?
>>
>> If no one else answers, then just send a pull request to the ARM-SOC
>> team (arm at kernel.org) and CC the linux-arm-kernel mailing list.
>>
>
> What ever happened to this?

Nothing, from the looks of it. I can apply them directly unless someone objects.

Laurent, care to rebase and send a fresh copy? cc arm at kernel.org.


-Olof

[PATCH v3 0/4] ARM: pxa: Fix out of vmalloc space bug

[Laurent Pinchart]

Hi Olof,

On Thursday 10 July 2014 09:56:32 Olof Johansson wrote:
> On Thu, Jul 10, 2014 at 5:10 AM, Ezequiel Garcia wrote:
> > On 10 Apr 08:31 PM, Nicolas Pitre wrote:
> >> On Fri, 11 Apr 2014, Laurent Pinchart wrote:
> >>> On Wednesday 09 April 2014 15:05:26 Nicolas Pitre wrote:
> >>>> On Wed, 9 Apr 2014, Laurent Pinchart wrote:
> >>>>> Hello,
> >>>>> 
> >>>>> (Resending due to a typo in an e-mail address that caused LAKML to
> >>>>> reject the mails. Sorry about the noise.)
> >>>>> 
> >>>>> This patch set reworks Ezequiel Garcia's previous fix [1] of an out
> >>>>> of vmalloc space bug on PXA2[57]x platforms caused by an attempt to
> >>>>> map the start of physical uncached outside of the vmalloc space.
> >>>>> 
> >>>>> This first three patches perform a couple of cleanups, and the last
> >>>>> patch fixes the problem. I've decided to map the memory at address
> >>>>> 0xfe000000 to minimize changes to the code, but this causes a bit
> >>>>> of fragmentation of vmalloc space. I could map it to the very end
> >>>>> of vmalloc space (0xfef00000) instead if preferred, which would
> >>>>> involve replacing a mov by an ldr in
> >>>>> pxa2[57]x_finish_suspend and pm_enter_standby_start.
> >>>>> 
> >>>>> I've tested the patch set on a PXA270-based system.
> >>>> 
> >>>> For those patches:
> >>>> 
> >>>> Acked-by: Nicolas Pitre <nico@linaro.org>
> >>> 
> >>> Thank you.
> >>> 
> >>> MAINTAINERS lists three maintainers for the PXA architecture, and two
> >>> git trees that seem to be either dead or even deleted. Who picks up
> >>> patches for PXA ? Should I send a pull request ?
> >> 
> >> If no one else answers, then just send a pull request to the ARM-SOC
> >> team (arm at kernel.org) and CC the linux-arm-kernel mailing list.
> > 
> > What ever happened to this?
> 
> Nothing, from the looks of it. I can apply them directly unless someone
> objects.
> 
> Laurent, care to rebase and send a fresh copy? cc arm at kernel.org.

Sure. Done.

-- 
Regards,

Laurent Pinchart