Under Xen 64 bit guests actually run their kernel in ring 3,
however the hypervisor takes care of squashing descriptor the
RPLs transparently (in order to allow them to continue to
differentiate between user and kernel space CS using the RPL).
Therefore the Xen paravirt backend should use RPL==0 instead of
1 (or 3). Using RPL==1 causes generic arch code to take
incorrect code paths because it uses "testl $3, <CS>, je foo"
type tests for a userspace CS and this considers 1==userspace.

This issue was previously masked because get_kernel_rpl() was
omitted when setting CS in kernel_thread(). This was fixed when
kernel_thread() was unified with 32 bit in
f443ff42.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Christian Kujau <lists@nerdbynature.de>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Brian Gerst <brgerst@gmail.com>
LKML-Reference: <1263377768-19600-2-git-send-email-ian.campbell@citrix.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Before the kernel_thread was converted into "C" we had
pt_regs::ss set to __KERNEL_DS (by SAVE_ALL asm macro).

Though I must admit I didn't find any *explicit* load of
%ss from this structure the better to be on a safe side
and set it to a known value.
Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Christian Kujau <lists@nerdbynature.de>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: Brian Gerst <brgerst@gmail.com>
LKML-Reference: <1263377768-19600-1-git-send-email-ian.campbell@citrix.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This fixes the regression introduced by the commit
f405d2c0.

The above commit fixes the following issue:

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

However, it doesn't work properly when you remove and insert the
agp_amd64 module again.

agp_amd64_init() and agp_amd64_cleanup should be called only
when gart_iommu is not called earlier (that is, the GART IOMMU
is not enabled). We need to use 'gart_iommu_aperture' to see if
GART IOMMU is enabled or not.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: mitov@issp.bas.bg
Cc: davej@redhat.com
LKML-Reference: <20100104161603L.fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This fixes the problem of the initialization code not correctly
mapping the entire MMIO space on a UV system.  A side effect is
the map_high() interface needed to be changed to accommodate
different address and size shifts.
Signed-off-by: NMike Travis <travis@sgi.com>
Reviewed-by: NMike Habeck <habeck@sgi.com>
Cc: <stable@kernel.org>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <4B479202.7080705@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Someone isn't reading their build output: Move the definition
out of the exported header.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: linux-kernel@vger.kernelorg
Signed-off-by: NIngo Molnar <mingo@elte.hu>

With the recent irq migration fixes (post 2.6.32), Gary Hade has noticed
"No IRQ handler for vector" messages during the 2.6.33-rc1 kernel boot on IBM
AMD platforms and root caused the issue to this commit:

> commit 23359a88
> Author: Suresh Siddha <suresh.b.siddha@intel.com>
> Date:   Mon Oct 26 14:24:33 2009 -0800
>
>    x86: Remove move_cleanup_count from irq_cfg

As part of this patch, we have removed the move_cleanup_count check
in smp_irq_move_cleanup_interrupt(). With this change, we can run into a
situation where an irq cleanup interrupt on a cpu can cleanup the vector
mappings associated with multiple irqs, of which one of the irq's migration
might be still in progress. As such when that irq hits the old cpu, we get
the "No IRQ handler" messages.

Fix this by checking for the irq_cfg's move_in_progress and if the move
is still in progress delay the vector cleanup to another irq cleanup
interrupt request (which will happen when the irq starts arriving at the
new cpu destination).
Reported-and-tested-by: NGary Hade <garyhade@us.ibm.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1262804191.2732.7.camel@sbs-t61.sc.intel.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Callers of copy_from_user() expect it to return the number of bytes
it could not copy. In no case it is supposed to return -EFAULT.

In case of a detected buffer overflow just return the requested
length. In addition one could think of a memset that would clear
the size of the target object.

[ hpa: code is not in .32 so not needed for -stable ]
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
LKML-Reference: <20100105131911.GC5480@osiris.boeblingen.de.ibm.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

This reverts commit ae1b22f6.

As Linus said in 982d007a: "There was something really messy about
cmpxchg8b and clone CPU's, so if you enable it on other CPUs later, do it
carefully."

This breaks lguest for those configs, but we can fix that by emulating
if we have to.

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14884Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
LKML-Reference: <201001051248.49700.rusty@rustcorp.com.au>
Cc: stable@kernel.org
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

It is above 0x100 (PCI-Express extended register space), so if mmconf
is not enable, we can't access it.

[ hpa: changed the bound from 0x200 to 0x120, which is the tight
  bound. ]
Reported-by: NJens Axboe <jens.axboe@oracle.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
LKML-Reference: <1261525263-13763-3-git-send-email-yinghai@kernel.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

fix for error that is introduced by
| x86: Use find_e820() instead of hard coded trampoline address

it should end with PAGE_SIZE + PAGE_SIZE
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
LKML-Reference: <1261525263-13763-2-git-send-email-yinghai@kernel.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Stephen Rothwell reported the following build warning:

 lib/dma-debug.c: In function 'dma_debug_device_change':
 lib/dma-debug.c:680: warning: 'return' with no value, in function returning non-void

Introduced by commit f797d988
("dma-debug: Do not add notifier when dma debugging is disabled").

Return 0 [notify-done] when disabled. (this is standard bus notifier behavior.)
Signed-off-by: NShaun Ruffell <sruffell@digium.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@kernel.org>
LKML-Reference: <20091231125624.GA14666@liondog.tnic>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

with CONFIG_GART_IOMMU enabled drivers/char/agp/amd64-agp.c has:

 #ifndef CONFIG_GART_IOMMU
 module_init(agp_amd64_init);
 module_exit(agp_amd64_cleanup);
 #endif

agp_amd64_init() was called via gart_iommu_init with
CONFIG_GART_IOMMU=y agp_amd64_init() was called via module_init
with CONFIG_GART_IOMMU=n

The commit 75f1cdf1 changes the
x86 dma initialization routine: gart_iommu_init() is called only
when GART IOMMU is detected. So when GART IOMMU isn't detected,
agp_amd64_init isn't called.

Marin Mitov reported this issue:

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

With this patch, agp_amd64_init() is always called via
module_init (the above ifndef is removed). If agp_amd64_init()
is called via gart_iommu_init() earlier, agp_amd64_init()
finishes without doing anything (when it is called via
module_init).
Reported-by: NMarin Mitov <mitov@issp.bas.bg>
Tested-by: NMarin Mitov <mitov@issp.bas.bg>
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: davej@redhat.com
LKML-Reference: <20091228181118C.fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The wrong address was being used to write the SCIR led regs on
remote hubs.  Also, there was an inconsistency between how BIOS
and the kernel indexed these regs.  Standardize on using the
lower 6 bits of the APIC ID as the index.

This patch fixes the problem of writing to an errant address to
a cpu # >= 64.
Signed-off-by: NMike Travis <travis@sgi.com>
Reviewed-by: NJack Steiner <steiner@sgi.com>
Cc: Robin Holt <holt@sgi.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@kernel.org
LKML-Reference: <4B3922F9.3060905@sgi.com>
[ v2: fix a number of annoying checkpatch artifacts and whitespace noise ]
Signed-off-by: NIngo Molnar <mingo@elte.hu>

As suggested by Vegard Nossum, use KERN_WARNING for error
reporting to make sure kmemcheck reports end up in syslog.
Suggested-by: NVegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <1261990935.4641.7.camel@penberg-laptop>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Andrew Morton reported a strange looking kmemcheck warning:

  WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88004fba6c20)
  0000000000000000310000000000000000000000000000002413000000c9ffff
   u u u u u u u u u u u u u u u u i i i i i i i i u u u u u u u u

   [<ffffffff810af3aa>] kmemleak_scan+0x25a/0x540
   [<ffffffff810afbcb>] kmemleak_scan_thread+0x5b/0xe0
   [<ffffffff8104d0fe>] kthread+0x9e/0xb0
   [<ffffffff81003074>] kernel_thread_helper+0x4/0x10
   [<ffffffffffffffff>] 0xffffffffffffffff

The above printout is missing register dump completely. The
problem here is that the output comes from syslog which doesn't
show KERN_INFO log-level messages. We didn't see this before
because both of us were testing on 32-bit kernels which use the
_default_ log-level.

Fix that up by explicitly using KERN_DEFAULT log-level for
__show_regs() printks.
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <1261988819.4641.2.camel@penberg-laptop>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Merge branch 'iommu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu into x86/urgent

Recently, some distros have started shipping versions of gcc which
default to -march=i686.  This breaks building kernels for pre-i686
machines, even if they have been selected in Kconfig, due to the
generation of CMOV instructions.

There isn't enough benefit to try to preserve the generation of these
instructions even when selected, so simply force -march=i386 for the
decompressor when building a 32-bit kernel.
Reported-and-tested-by: NChris Rankin <rankincj@yahoo.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
LKML-Reference: <219280.97558.qm@web52907.mail.re2.yahoo.com>

The assumption that acpi_table_parse passes the return value
of the hanlder function to the caller proved wrong
recently. The return value of the handler function is
totally ignored. This makes the initialization code for AMD
IOMMU buggy in a way that could cause a kernel panic on
initialization. This patch fixes the issue in the AMD IOMMU
driver.

Cc: stable@kernel.org
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

If CONFIG_HAVE_DMA_API_DEBUG is defined and "dma_debug=off" is
specified on the kernel command line, when you detach a driver from a
device you can cause the following NULL pointer dereference:

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<c0580d35>] dma_debug_device_change+0x5d/0x117

The problem is that the dma_debug_device_change notifier function is
added to the bus notifier chain even though the dma_entry_hash array
was never initialized.  If dma debugging is disabled, this patch both
prevents dma_debug_device_change notifiers from being added to the
chain, and additionally ensures that the dma_debug_device_change
notifier function is a no-op.

Cc: stable@kernel.org
Signed-off-by: NShaun Ruffell <sruffell@digium.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Different version of objdump says its version in different way;

GNU objdump 2.16.1

or

GNU objdump version 2.19.51.0.14-1.fc11 20090722

This patch uses the first argument which starts with a number
as version string.

Changes in v2:
 - Remove unneeded increment.
Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
LKML-Reference: <20091218154012.16960.5113.stgit@dhcp-100-2-132.bos.redhat.com>
Suggested-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

John Blackwood reported:
> on an older Dell PowerEdge 6650 system with 8 cpus (4 are hyper-threaded),
> and  32 bit (x86) kernel, once you change the irq smp_affinity of an irq
> to be less than all cpus in the system, you can never change really the
> irq smp_affinity back to be all cpus in the system (0xff) again,
> even though no error status is returned on the "/bin/echo ff >
> /proc/irq/[n]/smp_affinity" operation.
>
> This is due to that fact that BAD_APICID has the same value as
> all cpus (0xff) on 32bit kernels, and thus the value returned from
> set_desc_affinity() via the cpu_mask_to_apicid_and() function is treated
> as a failure in set_ioapic_affinity_irq_desc(), and no affinity changes
> are made.

set_desc_affinity() is already checking if the incoming cpu mask
intersects with the cpu online mask or not. So there is no need
for the apic op cpu_mask_to_apicid_and() to check again
and return BAD_APICID.

Remove the BAD_APICID return value from cpu_mask_to_apicid_and()
and also fix set_desc_affinity() to return -1 instead of using BAD_APICID
to represent error conditions (as cpu_mask_to_apicid_and() can return
logical or physical apicid values and BAD_APICID is really to represent
bad physical apic id).
Reported-by: NJohn Blackwood <john.blackwood@ccur.com>
Root-caused-by: NJohn Blackwood <john.blackwood@ccur.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1261103386.2535.409.camel@sbs-t61>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Merge branch 'cpumask-cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus

* 'cpumask-cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  cpumask: rename tsk_cpumask to tsk_cpus_allowed
  cpumask: don't recommend set_cpus_allowed hack in Documentation/cpu-hotplug.txt
  cpumask: avoid dereferencing struct cpumask
  cpumask: convert drivers/idle/i7300_idle.c to cpumask_var_t
  cpumask: use modern cpumask style in drivers/scsi/fcoe/fcoe.c
  cpumask: avoid deprecated function in mm/slab.c
  cpumask: use cpu_online in kernel/perf_event.c

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
  Keys: KEYCTL_SESSION_TO_PARENT needs TIF_NOTIFY_RESUME architecture support
  NOMMU: Optimise away the {dac_,}mmap_min_addr tests
  security/min_addr.c: make init_mmap_min_addr() static
  keys: PTR_ERR return of wrong pointer in keyctl_get_security()

Merge branch 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6

* 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6:
  OMAP3: serial - fix bug introduced in
  mfd: twl: fix twl4030 rename for remaining driver, board files
  USB ehci: replace mach header with plat
  omap3: Allow EHCI to be built on OMAP3

* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
  hwmon: (w83627hf) Fix for "No such device"
  hwmon: (sht15) Off-by-one error in array index + incorrect constants
  hwmon: Add driver for VIA CPU core temperature
  hwmon: (smsc47m1) Enable device if needed
  hwmon: (smsc47m1) Fail module loading on error
  hwmon: (smsc47m1) Only request I/O ports we really use
  hwmon: New driver for AMD Family 10h/11h CPUs

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (40 commits)
  [SCSI] 3w-9xxx fix bug in sgl loading
  [SCSI] fcoe, libfc: adds enable/disable for fcoe interface
  [SCSI] libfc: reduce hold time on SCSI host lock
  [SCSI] libfc: remote port gets stuck in restart state without really restarting
  [SCSI] pm8001: misc code cleanup
  [SCSI] pm8001: enable read HBA SAS address from VPD
  [SCSI] pm8001: do not reset local sata as it will not be found if reset
  [SCSI] pm8001: bit set pm8001_ha->flags
  [SCSI] pm8001:fix potential NULL pointer dereference
  [SCSI] pm8001: set SSC down-spreading only to get less errors on some 6G device.
  [SCSI] pm8001: fix endian issues with SAS address
  [SCSI] pm8001: enhance error handle for IO patch
  [SCSI] pm8001: Fix for sata io circular lock dependency.
  [SCSI] hpsa: add driver for HP Smart Array controllers.
  [SCSI] cxgb3i: always use negative errno in case of error
  [SCSI] bnx2i: minor code cleanup and update driver version
  [SCSI] bnx2i: Task management ABORT TASK fixes
  [SCSI] bnx2i: update CQ arming algorith for 5771x chipsets
  [SCSI] bnx2i: Adjust sq_size module parametr to power of 2 only if a non-zero value is specified
  [SCSI] bnx2i: Add 5771E device support to bnx2i driver
  ...

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: (71 commits)
  MIPS: Lasat: Fix botched changes to sysctl code.
  RTC: rtc-cmos.c: Fix warning on MIPS
  MIPS: Cleanup random differences beween lmo and Linus' kernel.
  MIPS: No longer hardwire CONFIG_EMBEDDED to y
  MIPS: Fix and enhance built-in kernel command line
  MIPS: eXcite: Remove platform.
  MIPS: Loongson: Cleanups of serial port support
  MIPS: Lemote 2F: Suspend CS5536 MFGPT Timer
  MIPS: Excite: move iodev_remove to .devexit.text
  MIPS: Lasat: Convert to proc_fops / seq_file
  MIPS: Cleanup signal code initialization
  MIPS: Modularize COP2 handling
  MIPS: Move EARLY_PRINTK to Kconfig.debug
  MIPS: Yeeloong 2F: Cleanup reset logic using the new ec_write function
  MIPS: Yeeloong 2F: Add LID open event as the wakeup event
  MIPS: Yeeloong 2F: Add basic EC operations
  MIPS: Move several variables from .bss to .init.data
  MIPS: Tracing: Make function graph tracer work with -mmcount-ra-address
  MIPS: Tracing: Reserve $12(t0) for mcount-ra-address of gcc 4.5
  MIPS: Tracing: Make ftrace for MIPS work without -fno-omit-frame-pointer
  ...

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
  Btrfs: make sure fallocate properly starts a transaction
  Btrfs: make metadata chunks smaller
  Btrfs: Show discard option in /proc/mounts
  Btrfs: deny sys_link across subvolumes.
  Btrfs: fail mount on bad mount options
  Btrfs: don't add extent 0 to the free space cache v2
  Btrfs: Fix per root used space accounting
  Btrfs: Fix btrfs_drop_extent_cache for skip pinned case
  Btrfs: Add delayed iput
  Btrfs: Pass transaction handle to security and ACL initialization functions
  Btrfs: Make truncate(2) more ENOSPC friendly
  Btrfs: Make fallocate(2) more ENOSPC friendly
  Btrfs: Avoid orphan inodes cleanup during committing transaction
  Btrfs: Avoid orphan inodes cleanup while replaying log
  Btrfs: Fix disk_i_size update corner case
  Btrfs: Rewrite btrfs_drop_extents
  Btrfs: Add btrfs_duplicate_item
  Btrfs: Avoid superfluous tree-log writeout

* 'kmemleak' of git://linux-arm.org/linux-2.6:
  kmemleak: fix kconfig for crc32 build error
  kmemleak: Reduce the false positives by checking for modified objects
  kmemleak: Show the age of an unreferenced object
  kmemleak: Release the object lock before calling put_object()
  kmemleak: Scan the _ftrace_events section in modules
  kmemleak: Simplify the kmemleak_scan_area() function prototype
  kmemleak: Do not use off-slab management with SLAB_NOLEAKTRACE

* 'next-spi' of git://git.secretlab.ca/git/linux-2.6:
  spi: spi_txx9.c: use resource_size()
  spi: spi_sh_sci.c: use resource_size()
  spi: spi_mpc8xxx.c: use resource_size()
  spi: spi_bfin5xx.c: use resource_size()
  spi: atmel_spi.c: use resource_size()
  spi: Add s3c64xx SPI Controller driver
  atmel_spi: fix dma addr calculation for len > BUFFER_SIZE
  spi_s3c24xx: add FIQ pseudo-DMA support
  spi: controller driver for Designware SPI core
  spidev: add proper section markers
  spidev: use DECLARE_BITMAP instead of declaring the array

* 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight:
  backlight: mbp_nvidia_bl - add two more MacBookPro variants
  backlight: Pass device through notify callback in the pwm driver
  backlight: PTR_ERR return of wrong pointer in cr_backlight_probe()
  backlight: Constify struct backlight_ops
  backlight/thinkpad-acpi: issue backlight class events

Fix up trivial conflicts in thinkpad-acpi support (backlight support
already merged earlier).

* 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds:
  leds: leds-pwm: Set led_classdev max_brightness
  leds: leds-lp3944.h - remove unneeded includes
  leds: use default-on trigger for Cobalt Qube
  leds: drivers/leds/leds-ss4200.c: fix return statement
  leds: leds-pca9532.h- indent with tabs, not spaces
  leds: Add LED class driver for regulator driven LEDs.
  leds: leds-cobalt-qube.c: use resource_size()
  leds: leds-cobalt-raq.c - use resource_size()
  leds: Add driver for ADP5520/ADP5501 MFD PMICs
  leds: Add driver for LT3593 controlled LEDs
  leds-ss4200: Check pci_enable_device return
  leds: leds-alix2c - take port address from MSR
  leds: LED driver for Intel NAS SS4200 series (v5)

* 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm:
  PCMCIA: fix pxa2xx_lubbock modular build error
  [ARM] Update mach-types
  [ARM] pxa: fix no reference of cpu_is_pxa25x() in devices.c
  [ARM] pxa/cm-x300: add PWM backlight support
  revert "[ARM] pxa/cm-x300: add PWM backlight support"
  ARM: use flush_kernel_dcache_area() for dmabounce
  ARM: add size argument to __cpuc_flush_dcache_page
  ARM: 5848/1: kill flush_ioremap_region()
  ARM: cache-l2x0: make better use of background cache handling
  ARM: cache-l2x0: avoid taking spinlock for every iteration
  [ARM] Kirkwood: Add LaCie Network Space v2 support
  ARM: dove: fix the mm mmu flags of the pj4 procinfo

Apparently not all versions of glibc and utilities treat an empty
LC_ALL as nonexistent, causing error messages to be garbled.  Instead,
explicitly unexport it from the environment.
Reported-and-tested-by: NMasami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
LKML-Reference: <4B2AC394.4030108@redhat.com>
Cc: Michal Marek <mmarek@sues.cz>
Cc: Roland Dreier <rdreier@cisco.com>
Cc: Sam Ravnborg <sam@ravnborg.org>

Fix kernel-doc warnings in printk.c:

Warning(kernel/printk.c:1422): No description found for parameter 'dumper'
Warning(kernel/printk.c:1422): Excess function parameter 'dump' description in 'kmsg_dump_register'
Warning(kernel/printk.c:1451): No description found for parameter 'dumper'
Warning(kernel/printk.c:1451): Excess function parameter 'dump' description in 'kmsg_dump_unregister'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I added blk_run_backing_dev on page_cache_async_readahead so readahead I/O
is unpluged to improve throughput on especially RAID environment.

The normal case is, if page N become uptodate at time T(N), then T(N) <=
T(N+1) holds.  With RAID (and NFS to some degree), there is no strict
ordering, the data arrival time depends on runtime status of individual
disks, which breaks that formula.  So in do_generic_file_read(), just
after submitting the async readahead IO request, the current page may well
be uptodate, so the page won't be locked, and the block device won't be
implicitly unplugged:

               if (PageReadahead(page))
                        page_cache_async_readahead()
                if (!PageUptodate(page))
                                goto page_not_up_to_date;
                //...
page_not_up_to_date:
                lock_page_killable(page);

Therefore explicit unplugging can help.

Following is the test result with dd.

#dd if=testdir/testfile of=/dev/null bs=16384

-2.6.30-rc6
1048576+0 records in
1048576+0 records out
17179869184 bytes (17 GB) copied, 224.182 seconds, 76.6 MB/s

-2.6.30-rc6-patched
1048576+0 records in
1048576+0 records out
17179869184 bytes (17 GB) copied, 206.465 seconds, 83.2 MB/s

(7Disks RAID-0 Array)

-2.6.30-rc6
1054976+0 records in
1054976+0 records out
17284726784 bytes (17 GB) copied, 212.233 seconds, 81.4 MB/s

-2.6.30-rc6-patched
1054976+0 records out
17284726784 bytes (17 GB) copied, 198.878 seconds, 86.9 MB/s

(7Disks RAID-5 Array)

The patch was found to improve performance with the SCST scsi target
driver.  See
http://sourceforge.net/mailarchive/forum.php?thread_name=a0272b440906030714g67eabc5k8f847fb1e538cc62%40mail.gmail.com&forum_name=scst-devel

[akpm@linux-foundation.org: unbust comment layout]
[akpm@linux-foundation.org: "fix" CONFIG_BLOCK=n]
Signed-off-by: NHisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>
Acked-by: NWu Fengguang <fengguang.wu@intel.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Tested-by: NRonald <intercommit@gmail.com>
Cc: Bart Van Assche <bart.vanassche@gmail.com>
Cc: Vladislav Bolkhovitin <vst@vlnb.net>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

RTC core won't allow wakeup alarms to be set if RTC devices' parent (i.e.
i2c_client or spi_device) isn't wakeup capable.

For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass via
board info, and if set, I2C core will initialize wakeup capability.  For
SPI devices there is no such flag at all.

I believe that it's not platform code responsibility to allow or disallow
wakeups, instead, drivers themselves should set the capability if a device
can trigger wakeups.

That's what drivers/base/power/sysfs.c says:

 * It is the responsibility of device drivers to enable (or disable)
 * wakeup signaling as part of changing device power states, respecting
 * the policy choices provided through the driver model.

I2C and SPI RTC devices send wakeup events via interrupt lines, so we
should set the wakeup capability if IRQ is routed.

Ideally we should also check irq for wakeup capability before setting
device's capability, i.e.

	if (can_irq_wake(irq))
		device_set_wakeup_capable(&client->dev, 1);

But there is no can_irq_wake() call exist, and it is not that trivial to
implement it for all interrupts controllers and complex/cascaded setups.

drivers/base/power/sysfs.c also covers these cases:

 * Devices may not be able to generate wakeup events from all power
 * states.  Also, the events may be ignored in some configurations;
 * for example, they might need help from other devices that aren't
 * active

So there is no guarantee that wakeup will actually work, and so I think
there is no point in being pedantic wrt checking IRQ wakeup capability.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add support for the Secure Digital Host Controller Interface found on the
"Hollywood" chipset of the Nintendo Wii video game console.
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>