linux-toradex.git, branch v2.6.32.35

Linux 2.6.32.35

2011-03-24T15:06:25+00:00

Revert "perf: Handle stopped state with tracepoints"

2011-03-24T15:01:34+00:00

This reverts commit 6f197b73304b3bd3d5a43b931383a5331d6b2987, which was
originally commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream.

This breaks the build, thanks to Jiri Slaby for pointing this out.

Reported-by: Jiri Slaby 
Cc: Frederic Weisbecker 
Signed-off-by: Greg Kroah-Hartman

Linux 2.6.32.34

2011-03-23T20:17:22+00:00

hwmon: (sht15) Fix integer overflow in humidity calculation

2011-03-23T20:16:59+00:00

commit ccd32e735de7a941906e093f8dca924bb05c5794 upstream.

An integer overflow occurs in the calculation of RHlinear when the
relative humidity is greater than around 30%. The consequence is a subtle
(but noticeable) error in the resulting humidity measurement.

Signed-off-by: Vivien Didelot 
Signed-off-by: Jean Delvare 
Cc: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

x86, binutils, xen: Fix another wrong size directive

2011-03-23T20:16:58+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

powerpc: rtas_flash needs to use rtas_data_buf

2011-03-23T20:16:58+00:00

commit bd2b64a12bf55bec0d1b949e3dca3f8863409646 upstream.

When trying to flash a machine via the update_flash command, Anton received the
following error:

    Restarting system.
    FLASH: kernel bug...flash list header addr above 4GB

The code in question has a comment that the flash list should be in
the kernel data and therefore under 4GB:

        /* NOTE: the "first" block list is a global var with no data
         * blocks in the kernel data segment.  We do this because
         * we want to ensure this block_list addr is under 4GB.
         */

Unfortunately the Kconfig option is marked tristate which means the variable
may not be in the kernel data and could be above 4GB.

Instead of relying on the data segment being below 4GB, use the static
data buffer allocated by the kernel for use by rtas.  Since we don't
use the header struct directly anymore, convert it to a simple pointer.

Reported-By: Anton Blanchard 
Signed-Off-By: Milton Miller 
Tested-By: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Kamalesh Babulal 
Signed-off-by: Greg Kroah-Hartman

powerpc/kdump: Fix race in kdump shutdown

2011-03-23T20:16:58+00:00

commit 60adec6226bbcf061d4c2d10944fced209d1847d upstream.

When we are crashing, the crashing/primary CPU IPIs the secondaries to
turn off IRQs, go into real mode and wait in kexec_wait.  While this
is happening, the primary tears down all the MMU maps.  Unfortunately
the primary doesn't check to make sure the secondaries have entered
real mode before doing this.

On PHYP machines, the secondaries can take a long time shutting down
the IRQ controller as RTAS calls are need.  These RTAS calls need to
be serialised which resilts in the secondaries contending in
lock_rtas() and hence taking a long time to shut down.

We've hit this on large POWER7 machines, where some secondaries are
still waiting in lock_rtas(), when the primary tears down the HPTEs.

This patch makes sure all secondaries are in real mode before the
primary tears down the MMU.  It uses the new kexec_state entry in the
paca.  It times out if the secondaries don't reach real mode after
10sec.

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Kamalesh Babulal 
cc: Anton Blanchard 
Signed-off-by: Greg Kroah-Hartman

powerpc/kexec: Fix race in kexec shutdown

2011-03-23T20:16:57+00:00

commit 1fc711f7ffb01089efc58042cfdbac8573d1b59a upstream.

In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to
kexec_smp_down().  kexec_smp_down() calls kexec_smp_wait() which sets
the hw_cpu_id() to -1.  The primary does this while leaving IRQs on
which means the primary can take a timer interrupt which can lead to
the IPIing one of the secondary CPUs (say, for a scheduler re-balance)
but since the secondary CPU now has a hw_cpu_id = -1, we IPI CPU
-1... Kaboom!

We are hitting this case regularly on POWER7 machines.

There is also a second race, where the primary will tear down the MMU
mappings before knowing the secondaries have entered real mode.

Also, the secondaries are clearing out any pending IPIs before
guaranteeing that no more will be received.

This changes kexec_prepare_cpus() so that we turn off IRQs in the
primary CPU much earlier.  It adds a paca flag to say that the
secondaries have entered the kexec_smp_down() IPI and turned off IRQs,
rather than overloading hw_cpu_id with -1.  This new paca flag is
again used to in indicate when the secondaries has entered real mode.

It also ensures that all CPUs have their IRQs off before we clear out
any pending IPI requests (in kexec_cpu_down()) to ensure there are no
trailing IPIs left unacknowledged.

Signed-off-by: Michael Neuling 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamalesh Babulal 
cc: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt

mmc: sdio: remember new card RCA when redetecting card

2011-03-23T20:16:57+00:00

commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream.

During redetection of a SDIO card, a request for a new card RCA
was submitted to the card, but was then overwritten by the old RCA.
This caused the card to be deselected instead of selected when using
the incorrect RCA.  This bug's been present since the "oldcard"
handling was introduced in 2.6.32.

Signed-off-by: Stefan Nilsson XK 
Reviewed-by: Ulf Hansson 
Reviewed-by: Pawel Wieczorkiewicz 
Signed-off-by: Linus Walleij 
Signed-off-by: Chris Ball 
Signed-off-by: Greg Kroah-Hartman

i2c: Fix typo in instantiating-devices document

2011-03-23T20:16:56+00:00

commit 6ced9e6b3901af4ab6ac0a11231402c888286ea6 upstream.

The struct i2c_board_info member holding the name is "type", not
"name".

Signed-off-by: Roman Fietze 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman