[GIT PULL] Linux support for ARM LPAE

[GIT PULL] Linux support for ARM LPAE

[Catalin Marinas]

Hi Russell,

If there are no further comments, could you please pull the ARM LPAE
branch below? They should be merged after Will's idmap patches (no real
conflict, just correctly functioning setup_mm_for_reboot).

Thanks.

The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416:

  Linux 3.2-rc4 (2011-12-01 14:56:01 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux.git for-next

Catalin Marinas (12):
      ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud
      ARM: LPAE: Move page table maintenance macros to pgtable-2level.h
      ARM: LPAE: Move the FSR definitions to separate files
      ARM: LPAE: Factor out classic-MMU specific code into proc-v7-2level.S
      ARM: LPAE: Introduce the 3-level page table format definitions
      ARM: LPAE: Page table maintenance for the 3-level format
      ARM: LPAE: MMU setup for the 3-level page table format
      ARM: LPAE: Invalidate the TLB before freeing the PMD
      ARM: LPAE: Add fault handling support
      ARM: LPAE: Add context switching support
      ARM: LPAE: Add identity mapping support for the 3-level page table format
      ARM: LPAE: Add the Kconfig entries

Russell King (1):
      ARM: pgtable: switch to use pgtable-nopud.h

Will Deacon (2):
      ARM: LPAE: add ISBs around MMU enabling code
      ARM: LPAE: mark memory banks with start > ULONG_MAX as highmem

 arch/arm/Kconfig                            |    2 +-
 arch/arm/boot/compressed/head.S             |    1 +
 arch/arm/include/asm/assembler.h            |   11 ++
 arch/arm/include/asm/page.h                 |    4 +
 arch/arm/include/asm/pgalloc.h              |   26 ++++-
 arch/arm/include/asm/pgtable-2level.h       |   41 ++++++
 arch/arm/include/asm/pgtable-3level-hwdef.h |   77 ++++++++++++
 arch/arm/include/asm/pgtable-3level-types.h |   70 +++++++++++
 arch/arm/include/asm/pgtable-3level.h       |  155 +++++++++++++++++++++++
 arch/arm/include/asm/pgtable-hwdef.h        |    4 +
 arch/arm/include/asm/pgtable.h              |   43 +------
 arch/arm/include/asm/proc-fns.h             |   21 +++
 arch/arm/include/asm/system.h               |    8 ++
 arch/arm/include/asm/tlb.h                  |   12 ++-
 arch/arm/kernel/head.S                      |   47 +++++++-
 arch/arm/kernel/hw_breakpoint.c             |    8 +-
 arch/arm/kernel/sleep.S                     |    2 +
 arch/arm/mm/Kconfig                         |   17 +++
 arch/arm/mm/alignment.c                     |    2 +-
 arch/arm/mm/context.c                       |   19 +++-
 arch/arm/mm/fault.c                         |  111 +++--------------
 arch/arm/mm/fault.h                         |   27 ++++-
 arch/arm/mm/fsr-2level.c                    |   78 ++++++++++++
 arch/arm/mm/fsr-3level.c                    |   68 ++++++++++
 arch/arm/mm/idmap.c                         |   34 +++++-
 arch/arm/mm/ioremap.c                       |   39 ++++---
 arch/arm/mm/mmu.c                           |   46 +++++++-
 arch/arm/mm/pgd.c                           |   51 +++++++-
 arch/arm/mm/proc-macros.S                   |    5 +-
 arch/arm/mm/proc-v7-2level.S                |  171 ++++++++++++++++++++++++++
 arch/arm/mm/proc-v7-3level.S                |  150 +++++++++++++++++++++++
 arch/arm/mm/proc-v7.S                       |  177 +++------------------------
 32 files changed, 1204 insertions(+), 323 deletions(-)
 create mode 100644 arch/arm/include/asm/pgtable-3level-hwdef.h
 create mode 100644 arch/arm/include/asm/pgtable-3level-types.h
 create mode 100644 arch/arm/include/asm/pgtable-3level.h
 create mode 100644 arch/arm/mm/fsr-2level.c
 create mode 100644 arch/arm/mm/fsr-3level.c
 create mode 100644 arch/arm/mm/proc-v7-2level.S
 create mode 100644 arch/arm/mm/proc-v7-3level.S

[GIT PULL] Linux support for ARM LPAE

[Russell King - ARM Linux]

On Fri, Dec 02, 2011 at 06:20:54PM +0000, Catalin Marinas wrote:
> Hi Russell,
> 
> If there are no further comments, could you please pull the ARM LPAE
> branch below? They should be merged after Will's idmap patches (no real
> conflict, just correctly functioning setup_mm_for_reboot).

Err, your tree contains a serious error.

tree bb5f2f68dd26a97343d255bb0b66f327cece91a5
parent b4521e369180054ddaacecbe83eadac8878f3501
author Russell King <rmk+kernel@arm.linux.org.uk> 1321983028 +0000
committer Catalin Marinas <catalin.marinas@arm.com> 1322842272 +0000

ARM: pgtable: switch to use pgtable-nopud.h

Nick Piggin noted upon introducing 4level-fixup.h:

| Add a temporary "fallback" header so architectures can run with
| the 4level pagetables patch without modification. All architectures
| should be converted to use the folding headers (include/asm-generic/
| pgtable-nop?d.h) as soon as possible, and the fallback header removed.

This makes ARM compliant with this statement.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

If you commit a patch into a git tree, _you_ are supposed to _always_
add your own sign-off line to it unless it's already there.

Because of this, I'm going to _have_ to throw out the merge of this from
the devel-stable branch (sorry folks) because it's not compliant with the
DCO standards required.

[GIT PULL] Linux support for ARM LPAE

[Catalin Marinas]

On Tue, Dec 06, 2011 at 12:41:09PM +0000, Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2011 at 06:20:54PM +0000, Catalin Marinas wrote:
> > If there are no further comments, could you please pull the ARM LPAE
> > branch below? They should be merged after Will's idmap patches (no real
> > conflict, just correctly functioning setup_mm_for_reboot).
> 
> Err, your tree contains a serious error.

I would say minor error but I agree, it needs fixing. This patch wasn't
originally part of my LPAE series as I hoped you would have merged it
during the last cycle. Now it had to be part of the pull request as LPAE
patches depend on it.

Anyway, I'll fix this and send you another pull request. Unless you
already merged your nopud patch in the devel-stable branch and I can
rebase LPAE on top, just let me know which one you'd prefer (and a
commit id if the latter).

Thanks.

-- 
Catalin

P.S. I say it's minor because it has the committer information. If you
     would pull someone else's branch which results in a fast-forward,
     you can't really tell whether it was a merge or cherry-pick, so the
     rule is not entirely consistent (unless you also mandate --no-ff
     for merges).

[GIT PULL] Linux support for ARM LPAE

[Russell King - ARM Linux]

On Tue, Dec 06, 2011 at 02:07:29PM +0000, Catalin Marinas wrote:
> On Tue, Dec 06, 2011 at 12:41:09PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Dec 02, 2011 at 06:20:54PM +0000, Catalin Marinas wrote:
> > > If there are no further comments, could you please pull the ARM LPAE
> > > branch below? They should be merged after Will's idmap patches (no real
> > > conflict, just correctly functioning setup_mm_for_reboot).
> > 
> > Err, your tree contains a serious error.
> 
> I would say minor error but I agree, it needs fixing.

The DCO is a viewed by many as having legal implications.  Not doing
it means - in this case - that you do not believe you have the right
to pass the change on.  In that case, I can't accept it from you.

If you don't understand that, please, go read Documentation/SubmittingPatches
to learn about when you are required to sign off on patches before
committing them.

> This patch wasn't
> originally part of my LPAE series as I hoped you would have merged it
> during the last cycle. Now it had to be part of the pull request as LPAE
> patches depend on it.

I've stated many times why it's not merged, and for the N'th time: it
generates warnings.  I'm _not_ merging something that is known to add
warnings such as those which this patch produces without there being a
fix for it.  You know that _very well_ because I've said it several
times, not only by email but also on our various phone calls.

I've dealt with this patch in exactly the same way at every merge window
we've had for the last _year_ - I've queued it up with the expectation
that hopefully someone would fix the warnings, the warnings didn't get
fixed, so it got dropped from the pull request.  Immediately after the
merge window (which includes this) it gets reinstated back into
linux-next.

> P.S. I say it's minor because it has the committer information. If you
>      would pull someone else's branch which results in a fast-forward,
>      you can't really tell whether it was a merge or cherry-pick, so the
>      rule is not entirely consistent (unless you also mandate --no-ff
>      for merges).

That is a known and accepted "limitation" - as is the "limitation" that
you can't add the sign-off to each commit you've pulled in.  What Linus
really wants is stuff to be tracked to the point it enters into git via
sign-offs.  From then on, the accountability trail follows the merge
commits.

[GIT PULL] Linux support for ARM LPAE

[Catalin Marinas]

On Tue, Dec 06, 2011 at 11:30:58PM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 02:07:29PM +0000, Catalin Marinas wrote:
> > This patch wasn't
> > originally part of my LPAE series as I hoped you would have merged it
> > during the last cycle. Now it had to be part of the pull request as LPAE
> > patches depend on it.
> 
> I've stated many times why it's not merged, and for the N'th time: it
> generates warnings.  I'm _not_ merging something that is known to add
> warnings such as those which this patch produces without there being a
> fix for it.  You know that _very well_ because I've said it several
> times, not only by email but also on our various phone calls.
> 
> I've dealt with this patch in exactly the same way at every merge window
> we've had for the last _year_ - I've queued it up with the expectation
> that hopefully someone would fix the warnings, the warnings didn't get
> fixed, so it got dropped from the pull request.  Immediately after the
> merge window (which includes this) it gets reinstated back into
> linux-next.

Yes, I'm fully aware, and I sent you a fix-up in the past. I can
re-write that fix-up in a few other ways if you don't like the current
one, just let me know.

-- 
Catalin

[GIT PULL] Linux support for ARM LPAE

[Catalin Marinas]

On Wed, Dec 07, 2011 at 11:23:20AM +0000, Catalin Marinas wrote:
> On Tue, Dec 06, 2011 at 11:30:58PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Dec 06, 2011 at 02:07:29PM +0000, Catalin Marinas wrote:
> > > This patch wasn't
> > > originally part of my LPAE series as I hoped you would have merged it
> > > during the last cycle. Now it had to be part of the pull request as LPAE
> > > patches depend on it.
> > 
> > I've stated many times why it's not merged, and for the N'th time: it
> > generates warnings.  I'm _not_ merging something that is known to add
> > warnings such as those which this patch produces without there being a
> > fix for it.  You know that _very well_ because I've said it several
> > times, not only by email but also on our various phone calls.
> > 
> > I've dealt with this patch in exactly the same way at every merge window
> > we've had for the last _year_ - I've queued it up with the expectation
> > that hopefully someone would fix the warnings, the warnings didn't get
> > fixed, so it got dropped from the pull request.  Immediately after the
> > merge window (which includes this) it gets reinstated back into
> > linux-next.
> 
> Yes, I'm fully aware, and I sent you a fix-up in the past. I can
> re-write that fix-up in a few other ways if you don't like the current
> one, just let me know.

OK, I took the time to implement another RFC fix-up for this. It's only
compile-tested at the moment and may need a few more tweaks but it gives
you an idea on what it tries to achieve. With the classic MMU, all the
pud_alloc/pmd_alloc just translate to pud_offset/pmd_offset so the
current behaviour should not be affected. In theory, it could work with
LPAE as well as it allocates the pmd at run-time (we don't really need
freeing them during unmap). Any thoughts?


ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud

From: Catalin Marinas <catalin.marinas@arm.com>

With the arch/arm code conversion to pgtable-nopud.h, the section and
supersection (un|re)map code triggers compiler warnings on UP systems.
This is caused by pmd_offset() being given a pgd_t argument rather than
a pud_t one. This patch makes the necessary conversion via pud_alloc()
and pmd_alloc().

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/mm/ioremap.c |   50 ++++++++++++++++++++++++++++++++-----------------
 1 files changed, 33 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index bdb248c..4827851 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -78,13 +78,20 @@ void __check_kvm_seq(struct mm_struct *mm)
 static void unmap_area_sections(unsigned long virt, unsigned long size)
 {
 	unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1));
-	pgd_t *pgd;
 
 	flush_cache_vunmap(addr, end);
-	pgd = pgd_offset_k(addr);
 	do {
-		pmd_t pmd, *pmdp = pmd_offset(pgd, addr);
+		pgd_t *pgd = pgd_offset_k(addr);
+		pud_t *pud;
+		pmd_t pmd, *pmdp;
 
+		if (pgd_none(*pgd))
+			continue;
+		pud = pud_offset(pgd, addr);
+		if (pud_none(*pud))
+			continue;
+
+		pmdp = pmd_offset(pud, addr);
 		pmd = *pmdp;
 		if (!pmd_none(pmd)) {
 			/*
@@ -103,10 +110,7 @@ static void unmap_area_sections(unsigned long virt, unsigned long size)
 			if ((pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_TABLE)
 				pte_free_kernel(&init_mm, pmd_page_vaddr(pmd));
 		}
-
-		addr += PGDIR_SIZE;
-		pgd++;
-	} while (addr < end);
+	} while (addr += PMD_SIZE, addr < end);
 
 	/*
 	 * Ensure that the active_mm is up to date - we want to
@@ -123,7 +127,6 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
 		    size_t size, const struct mem_type *type)
 {
 	unsigned long addr = virt, end = virt + size;
-	pgd_t *pgd;
 
 	/*
 	 * Remove and free any PTE-based mapping, and
@@ -131,9 +134,17 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
 	 */
 	unmap_area_sections(virt, size);
 
-	pgd = pgd_offset_k(addr);
 	do {
-		pmd_t *pmd = pmd_offset(pgd, addr);
+		pgd_t *pgd = pgd_offset_k(addr);
+		pud_t *pud;
+		pmd_t *pmd;
+
+		pud = pud_alloc(&init_mm, pgd, addr);
+		if (!pud)
+			return -ENOMEM;
+		pmd = pmd_alloc(&init_mm, pud, addr);
+		if (!pmd)
+			return -ENOMEM;
 
 		pmd[0] = __pmd(__pfn_to_phys(pfn) | type->prot_sect);
 		pfn += SZ_1M >> PAGE_SHIFT;
@@ -141,8 +152,7 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
 		pfn += SZ_1M >> PAGE_SHIFT;
 		flush_pmd_entry(pmd);
 
-		addr += PGDIR_SIZE;
-		pgd++;
+		addr += PMD_SIZE;
 	} while (addr < end);
 
 	return 0;
@@ -153,7 +163,6 @@ remap_area_supersections(unsigned long virt, unsigned long pfn,
 			 size_t size, const struct mem_type *type)
 {
 	unsigned long addr = virt, end = virt + size;
-	pgd_t *pgd;
 
 	/*
 	 * Remove and free any PTE-based mapping, and
@@ -161,23 +170,30 @@ remap_area_supersections(unsigned long virt, unsigned long pfn,
 	 */
 	unmap_area_sections(virt, size);
 
-	pgd = pgd_offset_k(virt);
 	do {
+		pgd_t *pgd = pgd_offset_k(addr);
+		pud_t *pud;
 		unsigned long super_pmd_val, i;
 
+		pud = pud_alloc(&init_mm, pgd, addr);
+		if (!pud)
+			return -ENOMEM;
 		super_pmd_val = __pfn_to_phys(pfn) | type->prot_sect |
 				PMD_SECT_SUPER;
 		super_pmd_val |= ((pfn >> (32 - PAGE_SHIFT)) & 0xf) << 20;
 
 		for (i = 0; i < 8; i++) {
-			pmd_t *pmd = pmd_offset(pgd, addr);
+			pmd_t *pmd;
+
+			pmd = pmd_alloc(&init_mm, pud, addr);
+			if (!pmd)
+				return -ENOMEM;
 
 			pmd[0] = __pmd(super_pmd_val);
 			pmd[1] = __pmd(super_pmd_val);
 			flush_pmd_entry(pmd);
 
-			addr += PGDIR_SIZE;
-			pgd++;
+			addr += PMD_SIZE;
 		}
 
 		pfn += SUPERSECTION_SIZE >> PAGE_SHIFT;

-- 
Catalin

[GIT PULL] Linux support for ARM LPAE

[Russell King - ARM Linux]

On Wed, Dec 07, 2011 at 11:23:20AM +0000, Catalin Marinas wrote:
> On Tue, Dec 06, 2011 at 11:30:58PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Dec 06, 2011 at 02:07:29PM +0000, Catalin Marinas wrote:
> > > This patch wasn't
> > > originally part of my LPAE series as I hoped you would have merged it
> > > during the last cycle. Now it had to be part of the pull request as LPAE
> > > patches depend on it.
> > 
> > I've stated many times why it's not merged, and for the N'th time: it
> > generates warnings.  I'm _not_ merging something that is known to add
> > warnings such as those which this patch produces without there being a
> > fix for it.  You know that _very well_ because I've said it several
> > times, not only by email but also on our various phone calls.
> > 
> > I've dealt with this patch in exactly the same way at every merge window
> > we've had for the last _year_ - I've queued it up with the expectation
> > that hopefully someone would fix the warnings, the warnings didn't get
> > fixed, so it got dropped from the pull request.  Immediately after the
> > merge window (which includes this) it gets reinstated back into
> > linux-next.
> 
> Yes, I'm fully aware, and I sent you a fix-up in the past. I can
> re-write that fix-up in a few other ways if you don't like the current
> one, just let me know.

So you mean you're submitting me my patch that I've been avoiding merging
into mainline _without_ the fixup patch?  It seems not - you do have it
in your pull request:

	ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud

So what's the issue?  Why do you want to rewrite it yet again?

My guess is that you haven't actually READ what I said above (which is
quoted).  And what is quoted above is _me_ explaining _why_ I have not
merged my own patch and why _I_ _consider_ _the_ _patch_ _as_ _it_
_stands_ _to_ _not_ _be_ _immediately_ _suitable_ _for_ _merging_
___on___ ___its___ ___own___.

The fact is, with the "fix" patch, it _does_ become suitable for merging.

Are you getting the message yet?

Provided you've fixed the sign-off (which you say you have) the only
remaining problem is the conflict between your tree and Will's tree
which you actually require for LPAE to be buildable.  Which, I'll point
out, I'm not looking at at the moment because I'm writing this email to
you this evening instead.

[GIT PULL] Linux support for ARM LPAE

[Russell King - ARM Linux]

On Wed, Dec 07, 2011 at 12:25:44PM +0000, Catalin Marinas wrote:
> ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud
> 
> From: Catalin Marinas <catalin.marinas@arm.com>
> 
> With the arch/arm code conversion to pgtable-nopud.h, the section and
> supersection (un|re)map code triggers compiler warnings on UP systems.
> This is caused by pmd_offset() being given a pgd_t argument rather than
> a pud_t one. This patch makes the necessary conversion via pud_alloc()
> and pmd_alloc().
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

So, do I now take this email as you saying that _your_ LPAE tree is
not ready for merging because you want to rework this patch, or what?

Because you've decided to go down the path of reworking this patch,
I consider it dangerous for me to just pull from your tree again - I've
no idea what I'd get, and I've no idea whether what's there is what you
want me to merge.

So, this is causing extra delay, and there's nothing _I_ can do about
it at my end.

This is getting completely out of hand.

What I want from you - by 5pm tomorrow so I can get this stuff merged -
is a pull request for the LPAE stuff as it was in your v2 pull request,
either based on top of _either_ my devel-stable (if you can get it - as
the machine is having severe problems running git atm) or with Will's
idmap changes merged into it _before_ the LPAE changes.

I suspect you'll have to do the latter though, because I don't think I
can sort out git on the server at the moment.

[GIT PULL] Linux support for ARM LPAE

[Catalin Marinas]

On 7 December 2011 20:29, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Dec 07, 2011 at 12:25:44PM +0000, Catalin Marinas wrote:
>> ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud
>>
>> From: Catalin Marinas <catalin.marinas@arm.com>
>>
>> With the arch/arm code conversion to pgtable-nopud.h, the section and
>> supersection (un|re)map code triggers compiler warnings on UP systems.
>> This is caused by pmd_offset() being given a pgd_t argument rather than
>> a pud_t one. This patch makes the necessary conversion via pud_alloc()
>> and pmd_alloc().
>>
>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>
> So, do I now take this email as you saying that _your_ LPAE tree is
> not ready for merging because you want to rework this patch, or what?

No, I'm not, it's you saying that your nopud patch does not have any
fix for the warnings, even though I had fixes posted for months. The
same fix that's in my LPAE series was sent to you to include with your
patch but instead you kept saying (even twice in the past week) that
those warning had no fix. From that, I understand that you really
don't consider my patch a proper fix for the compiler warnings.

> Because you've decided to go down the path of reworking this patch,
> I consider it dangerous for me to just pull from your tree again - I've
> no idea what I'd get, and I've no idea whether what's there is what you
> want me to merge.

I haven't changed anything in my LPAE branch, just posted an
alternative fix-up for the nopud patch. Please _state_ clearly whether
you consider my original (in the LPAE series) fixup valid or not. If
yes, I'm happy that I don't have to rework anything.

> What I want from you - by 5pm tomorrow so I can get this stuff merged -
> is a pull request for the LPAE stuff as it was in your v2 pull request,
> either based on top of _either_ my devel-stable (if you can get it - as
> the machine is having severe problems running git atm) or with Will's
> idmap changes merged into it _before_ the LPAE changes.
>
> I suspect you'll have to do the latter though, because I don't think I
> can sort out git on the server at the moment.

Yes, that's fine with me, I already talked to Will about this earlier
today but wanted to get your reply first.

-- 
Catalin

[GIT PULL] Linux support for ARM LPAE

[Russell King - ARM Linux]

On Wed, Dec 07, 2011 at 10:15:24PM +0000, Catalin Marinas wrote:
> On 7 December 2011 20:29, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Dec 07, 2011 at 12:25:44PM +0000, Catalin Marinas wrote:
> >> ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud
> >>
> >> From: Catalin Marinas <catalin.marinas@arm.com>
> >>
> >> With the arch/arm code conversion to pgtable-nopud.h, the section and
> >> supersection (un|re)map code triggers compiler warnings on UP systems.
> >> This is caused by pmd_offset() being given a pgd_t argument rather than
> >> a pud_t one. This patch makes the necessary conversion via pud_alloc()
> >> and pmd_alloc().
> >>
> >> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> >
> > So, do I now take this email as you saying that _your_ LPAE tree is
> > not ready for merging because you want to rework this patch, or what?
> 
> No, I'm not, it's you saying that your nopud patch does not have any
> fix for the warnings, even though I had fixes posted for months.

Stop it Catalin.  You're being utterly rediculous.  You asked why I
hadn't merged my patch during the last merge window.  So I told you -
just like I've been telling you by email and during our monthly calls
why I've not been merging it.  You asked the question (again) so I
told you why (again).

> The
> same fix that's in my LPAE series was sent to you to include with your
> patch but instead you kept saying (even twice in the past week) that
> those warning had no fix.

Utter rubbish.  I'll say it again.  You asked why I hadn't merged my
patch.  So I told you - just like I've been telling you by email and
during our monthly calls why I've not been merging it.  You asked the
question (again) so I told you why.

> From that, I understand that you really
> don't consider my patch a proper fix for the compiler warnings.

WTF.

> > Because you've decided to go down the path of reworking this patch,
> > I consider it dangerous for me to just pull from your tree again - I've
> > no idea what I'd get, and I've no idea whether what's there is what you
> > want me to merge.
> 
> I haven't changed anything in my LPAE branch, just posted an
> alternative fix-up for the nopud patch. Please _state_ clearly whether
> you consider my original (in the LPAE series) fixup valid or not. If
> yes, I'm happy that I don't have to rework anything.

Oh for god sake.  I think I've already stated very clearly what I want.
I see no reason to repeat myself yet again.

[GIT PULL] Linux support for ARM LPAE

[Russell King - ARM Linux]

On Wed, Dec 07, 2011 at 08:29:12PM +0000, Russell King - ARM Linux wrote:
> What I want from you - by 5pm tomorrow so I can get this stuff merged -
> is a pull request for the LPAE stuff as it was in your v2 pull request,
> either based on top of _either_ my devel-stable (if you can get it - as
> the machine is having severe problems running git atm) or with Will's
> idmap changes merged into it _before_ the LPAE changes.

For the avoidance of any doubt - and any argument - the 5pm time limit
is there to bring this debacle to a close in a reasonable period.  It's
purely there because I want to get this merged by end of Thursday and
no later.

To summarise, my objections are quite simply:

1. Your lack of sign-off on my patch which you merged (which you've
   addressed in pull v2.)
2. The combined point of the merge conflict between your tree and Will's
   idmap tree, plus the dependency your tree _does_ have on the idmap
   changes means it _should_ include Will's idmap changes to ensure
   bisectability - and this has the side effect of solving the merge
   conflict which shouldn't be there.

Any other objections which you think I've made are a purely a figment
of your imagination.

Now, one thing I haven't checked is the ordering of the commits -
particularly the ordering of the 'fix' patch and my patch.  Unfortunately,
standard git pull messages don't give the order so it's not something I
can readily check.  I commented on this issue when you posted the patch
set.  I hope it will be correct for pull v3 (iow, the fix patch first,
then my patch.)