linux-toradex.git/arch, branch v2.6.38.2

x86: Cleanup highmap after brk is concluded

2011-03-27T18:36:27+00:00

commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e upstream.

Now cleanup_highmap actually is in two steps: one is early in head64.c
and only clears above _end; a second one is in init_memory_mapping() and
tries to clean from _brk_end to _end.
It should check if those boundaries are PMD_SIZE aligned but currently
does not.
Also init_memory_mapping() is called several times for numa or memory
hotplug, so we really should not handle initial kernel mappings there.

This patch moves cleanup_highmap() down after _brk_end is settled so
we can do everything in one step.
Also we honor max_pfn_mapped in the implementation of cleanup_highmap.

Signed-off-by: Yinghai Lu 
Signed-off-by: Stefano Stabellini 
LKML-Reference: 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

sh: Fix ptrace hw_breakpoint handling

2011-03-27T18:36:13+00:00

commit fb7f045ace0624f1e59a7db8497e460bd54b1cbc upstream.

Since commit 34d0b5af50a063cded842716633501b38ff815fb it is no longer
possible to debug an application using singlestep. The old commit
converted singlestep handling via ptrace to hw_breakpoints. The
hw_breakpoint is disabled when an event is triggered and not re-enabled
again. This patch re-enables the existing hw_breakpoint before the
existing breakpoint is reused.

Signed-off-by: David Engraf 
Signed-off-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

sh: Fix ptrace fpu state initialisation

2011-03-27T18:36:12+00:00

commit c49b6ecf0870e78fa40497cd8b142915c1d5c7c9 upstream.

Commit 0ea820cf introduced the PTRACE_GETFPREGS/SETFPREGS cmds,
but gdb-server still accesses the FPU state using the
PTRACE_PEEKUSR/POKEUSR commands. In this case, xstate was not
initialised.

Signed-off-by: Phil Edworthy 
Signed-off-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

x86: Fix binutils-2.21 symbol related build failures

2011-03-27T18:36:00+00:00

commit 2ae9d293b14d17f35eff624272cfecac7979a2ee upstream.
[only 1/2 of the upstream commit was needed for stable - gkh]

New binutils version 2.21.0.20110302-1 started checking that the symbol
parameter to the .size directive matches the entry name's
symbol parameter, unearthing two mismatches:

  AS      arch/x86/kernel/acpi/wakeup_rm.o
  arch/x86/kernel/acpi/wakeup_rm.S: Assembler messages:
  arch/x86/kernel/acpi/wakeup_rm.S:12: Error: .size expression with symbol `wakeup_code_start' does not evaluate to a constant

  arch/x86/kernel/entry_32.S: Assembler messages:
  arch/x86/kernel/entry_32.S:1421: Error: .size expression with
  symbol `apf_page_fault' does not evaluate to a constant

The problem was discovered while using Debian's binutils
(2.21.0.20110302-1) and experimenting with binutils from
upstream.

Thanks Alexander and H.J. for the vital help.

Signed-off-by: Sedat Dilek 
Cc: Alexander van Heukelum 
Cc: H.J. Lu 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Rafael J. Wysocki 
LKML-Reference: <1299620364-21644-1-git-send-email-sedat.dilek@gmail.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xen: set max_pfn_mapped to the last pfn mapped

2011-03-27T18:35:52+00:00

commit 14988a4d350ce3b41ecad4f63c4f44c56f5ae34d upstream.

Do not set max_pfn_mapped to the end of the initial memory mappings,
that also contain pages that don't belong in pfn space (like the mfn
list).

Set max_pfn_mapped to the last real pfn mapped in the initial memory
mappings that is the pfn backing _end.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
LKML-Reference: 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

ASoC: mini2440: Fix uda134x codec problem.

2011-03-27T18:35:40+00:00

commit a110f4ef810ee29d810876df725f41d66629733e upstream.

ASoC audio for mini2440 platform in current kenrel doesn't work.
First problem is samsung_asoc_dma device is missing in initialization.
Next problem is with codec. Codec is initialized but never probed
because no platform_device exist for codec driver. It leads to errors
during codec binding to asoc dai. Next problem was platform data which
was passed from board to asoc main driver but not passed to codec when
called codec_soc_probe().

Following patch should fix issues. But not sure if in correct way.
Please review.

Signed-off-by: Marek Belisko 
Acked-by: Liam Girdwood 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

davinci: DM644x EVM: register MUSB device earlier

2011-03-23T20:04:15+00:00

commit 60d97a840175d3becb2e6de36537a5cdfc0ec3a9 upstream.

The MUSB driver doesn't see its platform device on DM644x EVM board anymore
since commit 73b089b052a69020b953312a624a6e1eb5b81fab (usb: musb: split davinci
to its own platform_driver) because the new probe is called as subsys_initcall()
now, and the device is registered later than that by the board code.  Move the
registration to davinci_evm_init() -- it's safe to do so because the MUSB core
device still gets initialized as fs_initcall() -- which is late enough for the
I2C GPIO expander (which controls VBUS) to be initialized.

Signed-off-by: Sergei Shtylyov 
Acked-by: Felipe Balbi 
Tested-by: Sekhar Nori 
Signed-off-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

x86, binutils, xen: Fix another wrong size directive

2011-03-23T20:04:14+00:00

commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream.

The latest binutils (2.21.0.20110302/Ubuntu) breaks the build
yet another time, under CONFIG_XEN=y due to a .size directive that
refers to a slightly differently named (hence, to the now very
strict and unforgiving assembler, non-existent) symbol.

[ mingo:

   This unnecessary build breakage caused by new binutils
   version 2.21 gets escallated back several kernel releases spanning
   several years of Linux history, affecting over 130,000 upstream
   kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially
   affecting all major Linux distro kernel configs).

   Git annotate tells us that this slight debug symbol code mismatch
   bug has been introduced in 2008 in commit 3d75e1b8:

     3d75e1b8        (Jeremy Fitzhardinge    2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)

   The 'bug' is just a slight assymetry in ENTRY()/END()
   debug-symbols sequences, with lots of assembly code between the
   ENTRY() and the END():

     ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
       ...
     END(do_hypervisor_callback)

   Human reviewers almost never catch such small mismatches, and binutils
   never even warned about it either.

   This new binutils version thus breaks the Xen build on all upstream kernels
   since v2.6.27, out of the blue.

   This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels
   impossible on such binutils, for a bisection window of over hundred
   thousand historic commits. (!)

   This is a major fail on the side of binutils and binutils needs to turn
   this show-stopper build failure into a warning ASAP. ]

Signed-off-by: Alexander van Heukelum 
Cc: Jeremy Fitzhardinge 
Cc: Jan Beulich 
Cc: H.J. Lu 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: "H. Peter Anvin" 
Cc: Kees Cook 
LKML-Reference: <1299877178-26063-1-git-send-email-heukelum@fastmail.fm>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

fix per-cpu flag problem in the cpu affinity checkers

2011-03-23T20:04:10+00:00

commit 9804c9eaeacfe78651052c5ddff31099f60ef78c upstream.

The CHECK_IRQ_PER_CPU is wrong, it should be checking
irq_to_desc(irq)->status not just irq.

Signed-off-by: Thomas Gleixner 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

x86: Flush TLB if PGD entry is changed in i386 PAE mode

2011-03-23T20:04:08+00:00

commit 4981d01eada5354d81c8929d5b2836829ba3df7b upstream.

According to intel CPU manual, every time PGD entry is changed in i386 PAE
mode, we need do a full TLB flush. Current code follows this and there is
comment for this too in the code.

But current code misses the multi-threaded case. A changed page table
might be used by several CPUs, every such CPU should flush TLB. Usually
this isn't a problem, because we prepopulate all PGD entries at process
fork. But when the process does munmap and follows new mmap, this issue
will be triggered.

When it happens, some CPUs keep doing page faults:

  http://marc.info/?l=linux-kernel&m=129915020508238&w=2

Reported-by: Yasunori Goto
Tested-by: Yasunori Goto
Reviewed-by: Rik van Riel 
Signed-off-by: Shaohua Li
Cc: Mallick Asit K 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: linux-mm 
LKML-Reference: <1300246649.2337.95.camel@sli10-conroe>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman