linux-stable.git/arch, branch linux-2.6.33.y

Revert "MIPS: MTX-1: Make au1000_eth probe all PHY

2011-11-07T21:47:35+00:00

Commit 34dce55d was not applicable in 2.6.33 and introduces a build breakage.
Revert that commit since it is irrelevant for this kernel version.

Acked-by: Ralf Baechle 
Signed-off-by: Florian Fainelli

plat-mxc: iomux-v3.h: implicitly enable pull-up/down when that's desired

2011-11-07T21:47:33+00:00

commit 6571534b600b8ca1936ff5630b9e0947f21faf16 upstream.

To configure pads during the initialisation a set of special constants
is used, e.g.
#define MX25_PAD_FEC_MDIO__FEC_MDIO IOMUX_PAD(0x3c4, 0x1cc, 0x10, 0, 0, PAD_CTL_HYS | PAD_CTL_PUS_22K_UP)

The problem is that no pull-up/down is getting activated unless both
PAD_CTL_PUE (pull-up enable) and PAD_CTL_PKE (pull/keeper module
enable) set. This is clearly stated in the i.MX25 datasheet and is
confirmed by the measurements on hardware. This leads to some rather
hard to understand bugs such as misdetecting an absent ethernet PHY (a
real bug i had), unstable data transfer etc. This might affect mx25,
mx35, mx50, mx51 and mx53 SoCs.

It's reasonable to expect that if the pullup value is specified, the
intention was to have it actually active, so we implicitly add the
needed bits.

Signed-off-by: Paul Fertser 
Signed-off-by: Sascha Hauer 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Fix wrong shift direction

2011-11-07T21:47:31+00:00

commit fcd0861db1cf4e6ed99f60a815b7b72c2ed36ea4 upstream.

The shift direction was wrong because the function takes a
page number and i is the address is the loop.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

KVM: s390: check cpu_id prior to using it

2011-11-07T21:47:29+00:00

commit 4d47555a80495657161a7e71ec3014ff2021e450 upstream.

We use the cpu id provided by userspace as array index here. Thus we
clearly need to check it first. Ooops.

Signed-off-by: Carsten Otte 
Signed-off-by: Christian Borntraeger 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

x86: Fix compilation bug in kprobes' twobyte_is_boostable

2011-11-07T21:47:14+00:00

commit 315eb8a2a1b7f335d40ceeeb11b9e067475eb881 upstream.

When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I
noticed a warning about the asm operand for test_bit in kprobes'
can_boost.  I discovered that this caused only the first long of
twobyte_is_boostable[] to be output.

Jakub filed and fixed gcc PR50571 to correct the warning and this output
issue.  But to solve it for less current gcc, we can make kprobes'
twobyte_is_boostable[] non-const, and it won't be optimized out.

Before:

    CC      arch/x86/kernel/kprobes.o
  In file included from include/linux/bitops.h:22:0,
                   from include/linux/kernel.h:17,
                   from [...]/arch/x86/include/asm/percpu.h:44,
                   from [...]/arch/x86/include/asm/current.h:5,
                   from [...]/arch/x86/include/asm/processor.h:15,
                   from [...]/arch/x86/include/asm/atomic.h:6,
                   from include/linux/atomic.h:4,
                   from include/linux/mutex.h:18,
                   from include/linux/notifier.h:13,
                   from include/linux/kprobes.h:34,
                   from arch/x86/kernel/kprobes.c:43:
  [...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’:
  [...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input
        without lvalue in asm operand 1 is deprecated [enabled by default]

  $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
       551:	0f a3 05 00 00 00 00 	bt     %eax,0x0
                          554: R_386_32	.rodata.cst4

  $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o

  arch/x86/kernel/kprobes.o:     file format elf32-i386

  Contents of section .data:
   0000 48000000 00000000 00000000 00000000  H...............
  Contents of section .rodata.cst4:
   0000 4c030000                             L...

Only a single long of twobyte_is_boostable[] is in the object file.

After, without the const on twobyte_is_boostable:

  $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
       551:	0f a3 05 20 00 00 00 	bt     %eax,0x20
                          554: R_386_32	.data

  $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o

  arch/x86/kernel/kprobes.o:     file format elf32-i386

  Contents of section .data:
   0000 48000000 00000000 00000000 00000000  H...............
   0010 00000000 00000000 00000000 00000000  ................
   0020 4c030000 0f000200 ffff0000 ffcff0c0  L...............
   0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77  ....;.......&..w

Now all 32 bytes are output into .data instead.

Signed-off-by: Josh Stone 
Cc: Masami Hiramatsu 
Cc: Jakub Jelinek 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: davinci: da850 EVM: read mac address from SPI flash

2011-11-07T21:46:48+00:00

commit 810198bc9c109489dfadc57131c5183ce6ad2d7d upstream.

DA850/OMAP-L138 EMAC driver uses random mac address instead of
a fixed one because the mac address is not stuffed into EMAC
platform data.

This patch provides a function which reads the mac address
stored in SPI flash (registered as MTD device) and populates the
EMAC platform data. The function which reads the mac address is
registered as a callback which gets called upon addition of MTD
device.

NOTE: In case the MAC address stored in SPI flash is erased, follow
the instructions at [1] to restore it.

[1] http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash

Modifications in v2:
Guarded registering the mtd_notifier only when MTD is enabled.
Earlier this was handled using mtd_has_partitions() call, but
this has been removed in Linux v3.0.

Modifications in v3:
a. Guarded da850_evm_m25p80_notify_add() function and
   da850evm_spi_notifier structure with CONFIG_MTD macros.
b. Renamed da850_evm_register_mtd_user() function to
   da850_evm_setup_mac_addr() and removed the struct mtd_notifier
   argument to this function.
c. Passed the da850evm_spi_notifier structure to register_mtd_user()
   function.

Modifications in v4:
Moved the da850_evm_setup_mac_addr() function within the first
CONFIG_MTD ifdef construct.

Signed-off-by: Sudhakar Rajashekhara 
Signed-off-by: Sekhar Nori 
Signed-off-by: Greg Kroah-Hartman

xen/smp: Warn user why they keel over - nosmp or noapic and what to use instead.

2011-11-07T21:46:48+00:00

commit ed467e69f16e6b480e2face7bc5963834d025f91 upstream.

We have hit a couple of customer bugs where they would like to
use those parameters to run an UP kernel - but both of those
options turn of important sources of interrupt information so
we end up not being able to boot. The correct way is to
pass in 'dom0_max_vcpus=1' on the Xen hypervisor line and
the kernel will patch itself to be a UP kernel.

Fixes bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308

Acked-by: Ian Campbell 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen: x86_32: do not enable iterrupts when returning from exception in interrupt context

2011-11-07T21:46:47+00:00

commit d198d499148a0c64a41b3aba9e7dd43772832b91 upstream.

If vmalloc page_fault happens inside of interrupt handler with interrupts
disabled then on exit path from exception handler when there is no pending
interrupts, the following code (arch/x86/xen/xen-asm_32.S:112):

	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
	sete XEN_vcpu_info_mask(%eax)

will enable interrupts even if they has been previously disabled according to
eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99)

	testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp)
	setz XEN_vcpu_info_mask(%eax)

Solution is in setting XEN_vcpu_info_mask only when it should be set
according to
	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
but not clearing it if there isn't any pending events.

Reproducer for bug is attached to RHBZ 707552

Signed-off-by: Igor Mammedov 
Acked-by: Jeremy Fitzhardinge 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

powerpc/pci: Check devices status property when scanning OF tree

2011-11-07T21:46:46+00:00

commit 5b339bdf164d8aee394609768f7e2e4415b0252a upstream.

We ran into an issue where it looks like we're not properly ignoring a
pci device with a non-good status property when we walk the device tree
and instanciate the Linux side PCI devices.

However, the EEH init code does look for the property and disables EEH
on these devices. This leaves us in an inconsistent where we are poking
at a supposedly bad piece of hardware and RTAS will block our config
cycles because EEH isn't enabled anyway.

Signed-of-by: Sonny Rao 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

Revert "x86, hotplug: Use mwait to offline a processor, fix the legacy case"

2011-11-07T21:46:43+00:00

This reverts commit 226917b0735f31cf5c704e07fdd590d99bbfae58 (upstream
ea53069231f9317062910d6e772cca4ce93de8c8 and
a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a and
ce5f68246bf2385d6174856708d0b746dc378f20 all mushed together) as
Jonathan Nieder reports that this causes a regression on some hardware.

More details can be found at http://bugs.debian.org/622259

Cc: Jonathan Nieder 
Cc: H. Peter Anvin 
Cc: Len Brown 
Signed-off-by: Greg Kroah-Hartman