[GIT PULL] nommu fixes for 3.17-rc1

[GIT PULL] nommu fixes for 3.17-rc1

[Uwe Kleine-König]

Hello Russell,

the following changes since commit 4c834452aad01531db949414f94f817a86348d59:

  Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk

for you to fetch changes up to 7343ab2ad6772f29d6bbb286a7aa0265a7aa5d3b:

  ARM: make user_addr_max more robust (2014-06-30 15:48:30 +0200)

----------------------------------------------------------------
A small collection of ARM-nommu related fixes and cleanups.

Regarding the small user base ("Hello, anyone out there apart from me?") and
the problem being fixed exists since 3.6-rc1 I don't consider the patches
serious enough to justify them going in before the next merge window.

This series makes efm32 boot again.
----------------------------------------------------------------

I have chosen -rc3 as base because -rc1 and -rc2 don't work for me as
they don't have 6980c3e2514e (ARM: 8086/1: Set memblock limit for
nommu).

Uwe Kleine-K?nig (5):
      ARM: nommu: drop support for ARM740T, ARM940T and ARM946E-S processors
      ARM: nommu: don't limit TASK_SIZE
      ARM: nommu: simplify definition of MODULES_END
      ARM: nommu: drop unused Kconfig symbol DRAM_SIZE
      ARM: make user_addr_max more robust

 Documentation/devicetree/bindings/arm/cpus.txt |   3 -
 arch/arm/Kconfig                               |   5 +-
 arch/arm/Kconfig-nommu                         |   4 -
 arch/arm/Makefile                              |   3 -
 arch/arm/configs/at91x40_defconfig             |   1 -
 arch/arm/configs/efm32_defconfig               |   1 -
 arch/arm/include/asm/glue-cache.h              |  16 -
 arch/arm/include/asm/glue-proc.h               |  27 --
 arch/arm/include/asm/memory.h                  |  10 +-
 arch/arm/include/asm/uaccess.h                 |   2 +-
 arch/arm/mm/Kconfig                            |  67 +---
 arch/arm/mm/Makefile                           |   3 -
 arch/arm/mm/proc-arm740.S                      | 151 ---------
 arch/arm/mm/proc-arm940.S                      | 374 ---------------------
 arch/arm/mm/proc-arm946.S                      | 429 -------------------------
 15 files changed, 12 insertions(+), 1084 deletions(-)
 delete mode 100644 arch/arm/mm/proc-arm740.S
 delete mode 100644 arch/arm/mm/proc-arm940.S
 delete mode 100644 arch/arm/mm/proc-arm946.S

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[GIT PULL] nommu fixes for 3.17-rc1

[Uwe Kleine-König]

Hello again,

On Mon, Jun 30, 2014 at 04:43:55PM +0200, Uwe Kleine-K?nig wrote:
> Hello Russell,
argh, I misstyped rmk's email alias and so the mail was sent to a wrong
address. This mail is correct.

Best regards
Uwe

> 
> the following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> 
>   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> 
> for you to fetch changes up to 7343ab2ad6772f29d6bbb286a7aa0265a7aa5d3b:
> 
>   ARM: make user_addr_max more robust (2014-06-30 15:48:30 +0200)
> 
> ----------------------------------------------------------------
> A small collection of ARM-nommu related fixes and cleanups.
> 
> Regarding the small user base ("Hello, anyone out there apart from me?") and
> the problem being fixed exists since 3.6-rc1 I don't consider the patches
> serious enough to justify them going in before the next merge window.
> 
> This series makes efm32 boot again.
> ----------------------------------------------------------------
> 
> I have chosen -rc3 as base because -rc1 and -rc2 don't work for me as
> they don't have 6980c3e2514e (ARM: 8086/1: Set memblock limit for
> nommu).
> 
> Uwe Kleine-K?nig (5):
>       ARM: nommu: drop support for ARM740T, ARM940T and ARM946E-S processors
>       ARM: nommu: don't limit TASK_SIZE
>       ARM: nommu: simplify definition of MODULES_END
>       ARM: nommu: drop unused Kconfig symbol DRAM_SIZE
>       ARM: make user_addr_max more robust
> 
>  Documentation/devicetree/bindings/arm/cpus.txt |   3 -
>  arch/arm/Kconfig                               |   5 +-
>  arch/arm/Kconfig-nommu                         |   4 -
>  arch/arm/Makefile                              |   3 -
>  arch/arm/configs/at91x40_defconfig             |   1 -
>  arch/arm/configs/efm32_defconfig               |   1 -
>  arch/arm/include/asm/glue-cache.h              |  16 -
>  arch/arm/include/asm/glue-proc.h               |  27 --
>  arch/arm/include/asm/memory.h                  |  10 +-
>  arch/arm/include/asm/uaccess.h                 |   2 +-
>  arch/arm/mm/Kconfig                            |  67 +---
>  arch/arm/mm/Makefile                           |   3 -
>  arch/arm/mm/proc-arm740.S                      | 151 ---------
>  arch/arm/mm/proc-arm940.S                      | 374 ---------------------
>  arch/arm/mm/proc-arm946.S                      | 429 -------------------------
>  15 files changed, 12 insertions(+), 1084 deletions(-)
>  delete mode 100644 arch/arm/mm/proc-arm740.S
>  delete mode 100644 arch/arm/mm/proc-arm940.S
>  delete mode 100644 arch/arm/mm/proc-arm946.S
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> 

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[GIT PULL] nommu fixes for 3.17-rc1

[Arnd Bergmann]

On Monday 30 June 2014 16:43:55 Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> the following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> 
>   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> 
> for you to fetch changes up to 7343ab2ad6772f29d6bbb286a7aa0265a7aa5d3b:
> 
>   ARM: make user_addr_max more robust (2014-06-30 15:48:30 +0200)
> 
> ----------------------------------------------------------------
> A small collection of ARM-nommu related fixes and cleanups.
> 
> Regarding the small user base ("Hello, anyone out there apart from me?") and
> the problem being fixed exists since 3.6-rc1 I don't consider the patches
> serious enough to justify them going in before the next merge window.
> 
> This series makes efm32 boot again.
> ----------------------------------------------------------------
> 
> I have chosen -rc3 as base because -rc1 and -rc2 don't work for me as
> they don't have 6980c3e2514e (ARM: 8086/1: Set memblock limit for
> nommu).
> 
> Uwe Kleine-K?nig (5):
>       ARM: nommu: drop support for ARM740T, ARM940T and ARM946E-S processors
>       ARM: nommu: don't limit TASK_SIZE
>       ARM: nommu: simplify definition of MODULES_END
>       ARM: nommu: drop unused Kconfig symbol DRAM_SIZE
>       ARM: make user_addr_max more robust
> 

I seem to have missed the patches when you posted them a couple of weeks
ago. I do have one last-minute comment about dropping ARM740T/940T/946T:

Your reasoning is that mach-integrator now doesn't work with !MMU any more
since it selects ARM_PATCH_PHYS_VIRT, and that no other platform uses
these CPUs. The change to integrator was done as a preparation for
multiplatform support and probably did not mean to remove support for !MMU
integrator. We do plan to remove support for at91x40 in the future, which
is the last ARM7TDMI user, and there is no upstream ARM9TDMI user nor has
there been at least for a couple of years.

I don't think it makes any sense to remove ARM740T and ARM94x but to leave
the option to build other ARMv4/v5 cores with MMU disabled. It would
be more consistent to either fix the build for these (ondoing the
ARM_PATCH_PHYS_VIRT change) or to remove all support for ARMv4/v5 !MMU,
possible also all !MMU support other than ARMv7-M.

Either way, I think it should be a conscious decision, not just a matter
of "this broke a while ago, let's assume nobody cares about it" as we
tend to do it for odd device drivers. There are still people using
arm7tdmi (in particular Russell still maintains a port for oki/lapis
ml67xxx), but at some point the last production deployment will have
upgraded to a new kernel or moved on to a cortex-m based chip.

	Arnd

[GIT PULL] nommu fixes for 3.17-rc1

[Linus Walleij]

On Mon, Jun 30, 2014 at 5:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> Your reasoning is that mach-integrator now doesn't work with !MMU any more
> since it selects ARM_PATCH_PHYS_VIRT, and that no other platform uses
> these CPUs. The change to integrator was done as a preparation for
> multiplatform support and probably did not mean to remove support for !MMU
> integrator.

Well actually the !MMU case has probably never really worked on the
Integrator. I never heard of anyone doing that. The only person who ever
mentioned running !MMU tiles (such as the 740 or 94x variants) was Will
Deacon and I don't know if he ever got it anywhere.

However if it is a good testbase for people synthesizing these old non-MMU
ARM cores still and using Linux with them, then it would make sense to
get that into shape and supported I guess? Especially now that the
Integrator machine is soon-ish even multiplatform (famous last words).

So we need some input here ...

Yours,
Linus Walleij

[GIT PULL] nommu fixes for 3.17-rc1

[Will Deacon]

On Mon, Jun 30, 2014 at 06:00:37PM +0100, Linus Walleij wrote:
> On Mon, Jun 30, 2014 at 5:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Your reasoning is that mach-integrator now doesn't work with !MMU any more
> > since it selects ARM_PATCH_PHYS_VIRT, and that no other platform uses
> > these CPUs. The change to integrator was done as a preparation for
> > multiplatform support and probably did not mean to remove support for !MMU
> > integrator.
> 
> Well actually the !MMU case has probably never really worked on the
> Integrator. I never heard of anyone doing that. The only person who ever
> mentioned running !MMU tiles (such as the 740 or 94x variants) was Will
> Deacon and I don't know if he ever got it anywhere.

I booted a 740t on an Integrator AP at the start of last year without issues
(once I'd fixed up proc-arm740.S -- the patches are in mainline). It wasn't
for anything useful though, I'm just sad that way.

> However if it is a good testbase for people synthesizing these old non-MMU
> ARM cores still and using Linux with them, then it would make sense to
> get that into shape and supported I guess? Especially now that the
> Integrator machine is soon-ish even multiplatform (famous last words).
> 
> So we need some input here ...

To be honest, I'm finding it more and more difficult to care about uclinux
outside of Cortex-M. Could we simply decide to support only v7m and rip out
the code for other !MMU targets, or are there actually users of those things
with mainline kernels?

Will

[GIT PULL] nommu fixes for 3.17-rc1

[Uwe Kleine-König]

Hello Arnd,

On Mon, Jun 30, 2014 at 05:52:45PM +0200, Arnd Bergmann wrote:
> On Monday 30 June 2014 16:43:55 Uwe Kleine-K?nig wrote:
> > Hello Russell,
> > 
> > the following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> > 
> >   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> > 
> > for you to fetch changes up to 7343ab2ad6772f29d6bbb286a7aa0265a7aa5d3b:
> > 
> >   ARM: make user_addr_max more robust (2014-06-30 15:48:30 +0200)
> > 
> > ----------------------------------------------------------------
> > A small collection of ARM-nommu related fixes and cleanups.
> > 
> > Regarding the small user base ("Hello, anyone out there apart from me?") and
> > the problem being fixed exists since 3.6-rc1 I don't consider the patches
> > serious enough to justify them going in before the next merge window.
> > 
> > This series makes efm32 boot again.
> > ----------------------------------------------------------------
> > 
> > I have chosen -rc3 as base because -rc1 and -rc2 don't work for me as
> > they don't have 6980c3e2514e (ARM: 8086/1: Set memblock limit for
> > nommu).
> > 
> > Uwe Kleine-K?nig (5):
> >       ARM: nommu: drop support for ARM740T, ARM940T and ARM946E-S processors
> >       ARM: nommu: don't limit TASK_SIZE
> >       ARM: nommu: simplify definition of MODULES_END
> >       ARM: nommu: drop unused Kconfig symbol DRAM_SIZE
> >       ARM: make user_addr_max more robust
> > 
> 
> I seem to have missed the patches when you posted them a couple of weeks
> ago. I do have one last-minute comment about dropping ARM740T/940T/946T:
> 
> Your reasoning is that mach-integrator now doesn't work with !MMU any more
> since it selects ARM_PATCH_PHYS_VIRT, and that no other platform uses
> these CPUs. The change to integrator was done as a preparation for
> multiplatform support and probably did not mean to remove support for !MMU
> integrator. We do plan to remove support for at91x40 in the future, which
> is the last ARM7TDMI user, and there is no upstream ARM9TDMI user nor has
> there been at least for a couple of years.
I don't care much here, so for now I will reshuffle my series to make
efm32 boot again and drop the patches removing the armv4/v4-nommu archs.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[GIT PULL v2] nommu fixes for 3.17-rc1

[Uwe Kleine-König]

Hello Russell,

I updated my tag to pull to not include the commit that drops ARM740T,
ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups
that depended on this one are dropped.

(As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is
broken on nommu. 

The following changes since commit 4c834452aad01531db949414f94f817a86348d59:

  Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk

for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c:

  ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200)

----------------------------------------------------------------
Two different fixes for the same problem making some ARM nommu configurations
not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest
available RAM address which makes some copy_from_user variants fail to read
from XIP memory.

Even in the presence of one of the two fixes the other still makes sense, so
both patches are included here.

This problem was the last one preventing efm32 boot to a prompt with mainline.

----------------------------------------------------------------
Uwe Kleine-K?nig (2):
      ARM: nommu: don't limit TASK_SIZE
      ARM: make user_addr_max more robust

 arch/arm/include/asm/memory.h  | 4 +---
 arch/arm/include/asm/uaccess.h | 2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[GIT PULL] nommu fixes for 3.17-rc1

[Arnd Bergmann]

On Monday 30 June 2014 18:07:38 Will Deacon wrote:
> On Mon, Jun 30, 2014 at 06:00:37PM +0100, Linus Walleij wrote:
> > However if it is a good testbase for people synthesizing these old non-MMU
> > ARM cores still and using Linux with them, then it would make sense to
> > get that into shape and supported I guess? Especially now that the
> > Integrator machine is soon-ish even multiplatform (famous last words).
> > 
> > So we need some input here ...

(adding Greg Ungerer to Cc)

FWIW, qemu supports integrator with arm946e in principle. There are a few
bugs that I found recently with the qemu model running recent Linux kernels,
but they are all trivially fixable. I haven't tried running !MMU though,
only ARM926 and ARM1026 with MMU, as I haven't managed to find or build
a user space image.

> To be honest, I'm finding it more and more difficult to care about uclinux
> outside of Cortex-M. Could we simply decide to support only v7m and rip out
> the code for other !MMU targets, or are there actually users of those things
> with mainline kernels?

As I said here earlier, at91x40 is the only pre-v7-m platform we support
upstream that doesn't have an MMU, and we are going to remove it at the
point when mach-at91 moves to multiplatform.

I suppose uClinux is the place for arm7tdmi these days, I just downloaded
their latest release and found support for these additional platforms
that were never upstreamed:

* S5C7375 (arm940t)
* S3C2500 (arm940t)
* S3C3410 (arm7tdmi)
* S3C4510B (arm7tdmi)
* S3C44B0 (arm7tdmi)
* P2001 (arm9tdmi)
* LPC22XX (arm7tdmi)
* LPC28XX (arm7tdmi)

The last one of these is the only one that actually builds, all the other
ones have been broken for many years as far as I can tell and were just
kept in the tree for reference, or because nobody bothered to remove
them. In contrast, the latest uclinux-2.4 kernel supports 23 (!) platforms
that I assume all work to some degree. This supports the position that
people using armv4t-nommu are either going to stay on ancient kernels
or moving on to other CPUs later.

There are a few other semi-recent kernel trees outside of uClinux-dist:

* at91x40 (to be dropped, as mentioned above)
* lapis ml67xxxx (also mentioned before)
* nuvoton nuc700 (abandoned at 3.1?)
  https://github.com/rhuitl/linux/commits/nuc700
* multiple cortex-m on 2.6.33 (actively maintained by emcraft)
  https://github.com/EmcraftSystems/linux-emcraft

Greg, do you have any other input? Do you think anybody is still
interested in upstream !MMU Linux on ARMv4T or ARMv5?

	Arnd

[GIT PULL v2] nommu fixes for 3.17-rc1

[Uwe Kleine-König]

Hi Russell,

On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> I updated my tag to pull to not include the commit that drops ARM740T,
> ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups
> that depended on this one are dropped.
> 
> (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is
> broken on nommu. 
> 
> The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> 
>   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> 
> for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c:
> 
>   ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200)
> 
> ----------------------------------------------------------------
> Two different fixes for the same problem making some ARM nommu configurations
> not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest
> available RAM address which makes some copy_from_user variants fail to read
> from XIP memory.
> 
> Even in the presence of one of the two fixes the other still makes sense, so
> both patches are included here.
> 
> This problem was the last one preventing efm32 boot to a prompt with mainline.
You neither commented nor pulled this request (at least I didn't find it
in your repository). Is it still on your radar?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[GIT PULL v2] nommu fixes for 3.17-rc1

[Uwe Kleine-König]

Hi Russell,

On Fri, Jul 11, 2014 at 09:30:54AM +0200, Uwe Kleine-K?nig wrote:
> On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-K?nig wrote:
> > I updated my tag to pull to not include the commit that drops ARM740T,
> > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups
> > that depended on this one are dropped.
> > 
> > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is
> > broken on nommu. 
> > 
> > The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> > 
> >   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> > 
> > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c:
> > 
> >   ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200)
> > 
> > ----------------------------------------------------------------
> > Two different fixes for the same problem making some ARM nommu configurations
> > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest
> > available RAM address which makes some copy_from_user variants fail to read
> > from XIP memory.
> > 
> > Even in the presence of one of the two fixes the other still makes sense, so
> > both patches are included here.
> > 
> > This problem was the last one preventing efm32 boot to a prompt with mainline.
> You neither commented nor pulled this request (at least I didn't find it
> in your repository). Is it still on your radar?
I'd really like to have this in 3.17. Any chances? Would you prefer to
get these patches into your patch tracker?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[GIT PULL v2] nommu fixes for 3.17-rc1

[Russell King - ARM Linux]

On Tue, Jul 22, 2014 at 09:42:46AM +0200, Uwe Kleine-K?nig wrote:
> Hi Russell,
> 
> On Fri, Jul 11, 2014 at 09:30:54AM +0200, Uwe Kleine-K?nig wrote:
> > On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-K?nig wrote:
> > > I updated my tag to pull to not include the commit that drops ARM740T,
> > > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups
> > > that depended on this one are dropped.
> > > 
> > > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is
> > > broken on nommu. 
> > > 
> > > The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> > > 
> > >   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> > > 
> > > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c:
> > > 
> > >   ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200)
> > > 
> > > ----------------------------------------------------------------
> > > Two different fixes for the same problem making some ARM nommu configurations
> > > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest
> > > available RAM address which makes some copy_from_user variants fail to read
> > > from XIP memory.
> > > 
> > > Even in the presence of one of the two fixes the other still makes sense, so
> > > both patches are included here.
> > > 
> > > This problem was the last one preventing efm32 boot to a prompt with mainline.
> > You neither commented nor pulled this request (at least I didn't find it
> > in your repository). Is it still on your radar?
> I'd really like to have this in 3.17. Any chances? Would you prefer to
> get these patches into your patch tracker?

Hmm, the key thing for pull requests that you want me to pull is to send
them to linux+pull at ... rather than plain linux at ... for the simple reason
that most people are incapable of addressing their emails correctly.

It is very difficult to sort out which messages that contain "GIT PULL"
are meant for me - especially when people put me in the To: field of
all sorts of random emails with very little thought.  Because of that
behaviour, which has recently spread to replies by various mailers too,
I no longer take any notice of which header field my email address
appears in any message.

The actions of various people and various email programs which don't
understand the meaning of To: and Cc: has made this much harder than
it otherwise needs to be, so now we need to invent new ways to work
around that "bug" in many humans on this planet.

Based on your subject line, I'm queuing this for the merge window.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[GIT PULL v2] nommu fixes for 3.17-rc1

[Uwe Kleine-König]

Hi Russell,

On Tue, Jul 29, 2014 at 11:35:43PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 22, 2014 at 09:42:46AM +0200, Uwe Kleine-K?nig wrote:
> > On Fri, Jul 11, 2014 at 09:30:54AM +0200, Uwe Kleine-K?nig wrote:
> > > On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-K?nig wrote:
> > > > I updated my tag to pull to not include the commit that drops ARM740T,
> > > > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups
> > > > that depended on this one are dropped.
> > > > 
> > > > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is
> > > > broken on nommu. 
> > > > 
> > > > The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> > > > 
> > > >   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> > > > 
> > > > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c:
> > > > 
> > > >   ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200)
> > > > 
> > > > ----------------------------------------------------------------
> > > > Two different fixes for the same problem making some ARM nommu configurations
> > > > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest
> > > > available RAM address which makes some copy_from_user variants fail to read
> > > > from XIP memory.
> > > > 
> > > > Even in the presence of one of the two fixes the other still makes sense, so
> > > > both patches are included here.
> > > > 
> > > > This problem was the last one preventing efm32 boot to a prompt with mainline.
> > > You neither commented nor pulled this request (at least I didn't find it
> > > in your repository). Is it still on your radar?
> > I'd really like to have this in 3.17. Any chances? Would you prefer to
> > get these patches into your patch tracker?
> 
> Hmm, the key thing for pull requests that you want me to pull is to send
> them to linux+pull at ... rather than plain linux at ... for the simple reason
> that most people are incapable of addressing their emails correctly.
Mine was sent to rmk+linux at ..., but I assume that's just an alias for
linux at ... and I noted to use the new address in the future.

> It is very difficult to sort out which messages that contain "GIT PULL"
> are meant for me - especially when people put me in the To: field of
> all sorts of random emails with very little thought.  Because of that
> behaviour, which has recently spread to replies by various mailers too,
> I no longer take any notice of which header field my email address
> appears in any message.
You could make life easier for contributors (and maybe also yourself) by
assuming that a mail that lists only you in To: was sent by someone
who got the difference between To and Cc and put it into your linux+pull
folder. Just a suggestion.

> The actions of various people and various email programs which don't
> understand the meaning of To: and Cc: has made this much harder than
> it otherwise needs to be, so now we need to invent new ways to work
> around that "bug" in many humans on this planet.
> 
> Based on your subject line, I'm queuing this for the merge window.
That's what I intended.

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[GIT PULL v2] nommu fixes for 3.17-rc1

[Russell King - ARM Linux]

On Wed, Jul 30, 2014 at 09:06:10AM +0200, Uwe Kleine-K?nig wrote:
> Hi Russell,
>...
> Mine was sent to rmk+linux at ..., but I assume that's just an alias for
> linux at ... and I noted to use the new address in the future.

It isn't, it's an alias for rmk at ...

> On Tue, Jul 29, 2014 at 11:35:43PM +0100, Russell King - ARM Linux wrote:
> > It is very difficult to sort out which messages that contain "GIT PULL"
> > are meant for me - especially when people put me in the To: field of
> > all sorts of random emails with very little thought.  Because of that
> > behaviour, which has recently spread to replies by various mailers too,
> > I no longer take any notice of which header field my email address
> > appears in any message.
> 
> You could make life easier for contributors (and maybe also yourself) by
> assuming that a mail that lists only you in To: was sent by someone
> who got the difference between To and Cc and put it into your linux+pull
> folder. Just a suggestion.

How about people making my life easier by following the Internet RFCs
when it comes to which addresses should be in To: and Cc: ?

Then I can follow the information which my mail client gives me - that
is, the marking of each message which indicates whether I'm listed in
the To: header or the Cc: header, or indeed not listed at all.

Right now, scanning my mailbox for messages with me in the To: header
leads to /lots/ of crap.  This is precisely why I stated a while back
that I want pull requests for me to pull to go to linux+pull at ...  I
can then get my mail client to filter the mailbox for messages addressed
"To:" that address, which then gives me all the pull requests that people
want me to action.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.