Correct the MAINTAINERS file patterns for PS3.  Removes some PS3
patterns that were under 'CELL BROADBAND ENGINE ARCHITECTURE', and
adds missing PS3 sound and RTC driver patterns.

CC: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Fix build warnings like these when CONFIG_PS3_FLASH=n:

  arch/powerpc/platforms/ps3/os-area.c: warning: 'update_flash_db' defined but not used
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Now that ppc32 implements address randomization it also wants to inherit
personality flags like ADDR_NO_RANDOMIZE across exec, for things like
`setarch ppc -R' to work.  But the ppc32 version of SET_PERSONALITY
forcefully sets PER_LINUX, clearing all personality flags.  So be
careful about preserving the flags.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

early_init_mmu_secondary() is called at CPU hotplug time, so it
must be marked as __cpuinit, not __init.

Caused by 757c74d2 ("powerpc/mm: Introduce early_init_mmu() on 64-bit").
Tested-by: NSachin Sant <sachinp@in.ibm.com>
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Since the vast majority of 85xx platforms are UP we introduce a new SMP
config for the few platforms that have more than one core.  Beyond
CONFIG_SMP=y and its dependencies this should be identical to
mpc85xx_defconfig.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

* Add new 85xx boards
* Added QE/FSL gpio
* Enabled PHY drivers that exist on various boards
* Enabled FS_ENET & UCC ethernet drivers (CPM2 & QE)
* FSL HW Crypto Engine
* CPM I2C
* QE Serial
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The ULI 1575 PCI quirk function for the Freescale MPC8610 HPCD was disabling
the SATA INTx interrupt, even when SATA support was enabled.  This was safe,
because the SATA driver re-enabled it.  But with commit a5bfc471 ("ahci: drop
intx manipulation on msi enable"), the driver no longer does this, and so SATA
support on the 8610 HPCD is broken.

The original quirk function disabled INTx because it caused some other
interrupt problem during early development on this board, but no one remembers
any more what that problem was, and it doesn't seem to occur any more.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The driver should pass a device that specifies internal DMA ops, but
currently NULL pointer is passed, therefore following bug appears
during boot up:

  ------------[ cut here ]------------
  Kernel BUG at c0018a7c [verbose debug info unavailable]
  Oops: Exception in kernel mode, sig: 5 [#1]
  [...]
  NIP [c0018a7c] fsl_rio_doorbell_init+0x34/0x60
  LR [c0018a70] fsl_rio_doorbell_init+0x28/0x60
  Call Trace:
  [ef82bda0] [c0018a70] fsl_rio_doorbell_init+0x28/0x60 (unreliable)
  [ef82bdc0] [c0019160] fsl_rio_setup+0x6b8/0x84c
  [ef82be20] [c02d28ac] fsl_of_rio_rpn_probe+0x30/0x50
  [ef82be40] [c0234f20] of_platform_device_probe+0x5c/0x84
  [...]
  ---[ end trace 561bb236c800851f ]---

This patch fixes the issue.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Add binding for mtd nodes with multiple reg tuples.  Multiple reg tuples
are used when the flash region covers multiple devices of the same type,
but not necessarily the same size.
Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

It's easier to find bindings descriptions in separate files.  So factor
out the MTD physmap bindings into a separate file to not clutter
booting-without-of.txt more.
Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

In commit 364fdbc0 ("spi_mpc83xx:
rework chip selects handling"), I merged activate_cs and deactivate_cs
hooks into cs_control, but I overlooked that mpc52xx_psc_spi driver
is using these hooks too. And that resulted in the following build
failure:

CC      drivers/spi/mpc52xx_psc_spi.o
drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_do_probe':
drivers/spi/mpc52xx_psc_spi.c:398: error: 'struct fsl_spi_platform_data'
has no member named 'activate_cs'
drivers/spi/mpc52xx_psc_spi.c:399: error: 'struct fsl_spi_platform_data'
has no member named 'deactivate_cs'
make[2]: *** [drivers/spi/mpc52xx_psc_spi.o] Error 1

This patch simply adds the legacy hooks back for 2.6.30, and for
2.6.31 we'll convert the driver to ->cs_control.
Reported-by: NSubrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

A randconfig build on powerpc failed with:

dtl.c: In function 'dtl_init':
dtl.c:238: error: implicit declaration of function 'firmware_has_feature'
dtl.c:238: error: 'FW_FEATURE_SPLPAR' undeclared (first use in this function)

- We need firmware.h for these definitions.
Signed-off-by: NSachin Sant <sachinp@in.ibm.com>
Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Richard Henderson pointed out that the powerpc __futex_atomic_op has a
bug: it will write the wrong value if the stwcx. fails and it has to
retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten
by the result from the first time around the loop.  This happens
because it uses the same register for 'oparg' (an input) as it uses
for the result.

This fixes it by using separate registers for 'oparg' and 'ret'.

Cc: stable@kernel.org
Signed-off-by: NPaul Mackerras <paulus@samba.org>

While adding native EEH support to Emulex and Qlogic drivers, it was
discovered that dev->error_state was set to pci_io_channel_normal too
late in the recovery process. These drivers rely on error_state to
determine if they can access the device in their slot_reset callback,
thus error_state needs to be set to pci_io_channel_normal in
eeh_report_reset(). Below is a detailed explanation (courtesy of Richard
Lary) as to why this is necessary.

Background:
PCI MMIO or DMA accesses to a frozen slot generate additional EEH
errors. If the number of additional EEH errors exceeds EEH_MAX_FAILS the
adapter will be shutdown. To avoid triggering excessive EEH errors and
an undesirable adapter shutdown, some drivers use the
pci_channel_offline(dev) wrapper function to return a Boolean value
based on the value of pci_dev->error_state to determine if PCI MMIO or
DMA accesses are safe. If the wrapper returns TRUE, drivers must not
make PCI MMIO or DMA access to their hardware.

The pci_dev structure member error_state reflects one of three values,
1) pci_channel_io_normal, 2) pci_channel_io_frozen, 3)
pci_channel_io_perm_failure.  Function pci_channel_offline(dev) returns
TRUE if error_state is pci_channel_io_frozen or pci_channel_io_perm_failure.

The EEH driver sets pci_dev->error_state to pci_channel_io_frozen at the
point where the PCI slot is frozen. Currently, the EEH driver restores
dev->error_state to pci_channel_io_normal in eeh_report_resume() before
calling the driver's resume callback. However, when the EEH driver calls
the driver's slot_reset callback() from eeh_report_reset(), it
incorrectly indicates the error state is still pci_channel_io_frozen.

Waiting until eeh_report_resume() to restore dev->error_state to
pci_channel_io_normal is too late for Emulex and QLogic FC drivers and
any other drivers which are designed to use common code paths in these
two cases: i) those called after the driver's slot_reset callback() and
ii) those called after the PCI slot is frozen but before the driver's
slot_reset callback is called. Case i) all driver paths executed to
reinitialize the hardware after a reset and case ii) all code paths
executed by driver kernel threads that run asynchronous to the main
driver thread, such as interrupt handlers and worker threads to process
driver work queues.

Emulex and QLogic FC drivers are designed with common code paths which
require that pci_channel_offline(dev) reflect the true state of the
hardware. The state transitions that the hardware takes from Normal
Operations to Slot Frozen to Reset to Normal Operations are documented
in the Power Architecture™ Platform Requirements+ (PAPR+) in Table 75.
PE State Control.

PAPR defines the following 3 states:

0 -- Not reset, Not EEH stopped, MMIO load/store allowed, DMA allowed
     (Normal Operations)
1 -- Reset, Not EEH stopped, MMIO load/store disabled, DMA disabled
2 -- Not reset, EEH stopped, MMIO load/store disabled, DMA disabled
     (Slot Frozen)

An EEH error places the slot in state 2 (Frozen) and the adapter driver
is notified that an EEH error was detected. If the adapter driver
returns PCI_ERS_RESULT_NEED_RESET, the EEH driver calls
eeh_reset_device() to place the slot into state 1 (Reset) and
eeh_reset_device completes by placing the slot into State 0 (Normal
Operations). Upon return from eeh_reset_device(), the EEH driver calls
eeh_report_reset, which then calls the adapter's slot_reset callback. At
the time the adapter's slot_reset callback is called, the true state of
the hardware is Normal Operations and should be accurately reflected by
setting dev->error_state to pci_channel_io_normal.

The current implementation of EEH driver does not do so and requires
this change to correct this deficiency.
Signed-off-by: NMike Mason <mmlnx@us.ibm.com>
Acked-by: NLinas Vepstas <linasvepstas@gmail.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed,
let powerpc 256kB pages coexist with CONFIG_SHMEM again.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
  drm/i915: fix scheduling while holding the new active list spinlock
  drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.
  drm/i915: Correctly set the write flag for get_user_pages in pread.
  drm/i915: Fix use of uninitialized var in 40a5f0de
  drm/i915: indicate framebuffer restore key in SysRq help message
  drm/i915: sync hdmi detection by hdmi identifier with 2D
  drm/i915: Fix a mismerge of the IGD patch (new .find_pll hooks missed)
  drm/i915: Implement batch and ring buffer dumping

Revert part of af5c820a ("x86: cpumask:
use work_on_cpu in arch/x86/kernel/microcode_core.c")

That change is causing only one Intel CPU's microcode to be updated e.g.
microcode: CPU3 updated from revision 0x9 to 0x17, date = 2005-04-22
where before it announced that also for CPU0 and CPU1 and CPU2.

We cannot use work_on_cpu() in the CONFIG_MICROCODE_OLD_INTERFACE code,
because Intel's request_microcode_user() involves a copy_from_user() from
/sbin/microcode_ctl, which therefore needs to be on that CPU at the time.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

regression caused by commit 5e118f41:
i915_gem_object_move_to_inactive() should be called in task context,
as it calls fput();

Signed-off-by: Shaohua Li<shaohua.li@intel.com>
[anholt: Add more detail to the comment about the lock break that's added]
Signed-off-by: NEric Anholt <eric@anholt.net>

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

* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  lockdep: warn about lockdep disabling after kernel taint, fix

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
  fuse: fix "direct_io" private mmap
  fuse: fix argument type in fuse_get_user_pages()

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ryusuke/nilfs2:
  nilfs2: fix possible mismatch of sufile counters on recovery
  nilfs2: segment usage file cleanups
  nilfs2: fix wrong accounting and duplicate brelse in nilfs_sufile_set_error
  nilfs2: simplify handling of active state of segments fix
  nilfs2: remove module version
  nilfs2: fix lockdep recursive locking warning on meta data files
  nilfs2: fix lockdep recursive locking warning on bmap
  nilfs2: return f_fsid for statfs2

* 'fixes-for-linus' of git://git.monstr.eu/linux-2.6-microblaze:
  microblaze: Add missing FILE tag to MAINTAINERS
  microblaze: remove duplicated #include's
  microblaze: struct device - replace bus_id with dev_name()
  microblaze: Simplify copy_thread()
  microblaze: Add TIMESTAMPING constants to socket.h
  microblaze: Add missing empty ftrace.h file
  microblaze: Fix problem with removing zero length files

* git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
  sh: Add in PCI bus for DMA API debugging.
  sh: Pre-allocate a reasonable number of DMA debug entries.
  sh: sh7786: modify usb setup timeout judgment bug.
  MAINTAINERS: Update sh architecture file patterns.
  sh: ap325: use edge control for ov772x camera
  sh: Plug in support for ARCH=sh64 using sh SRCARCH.
  sh: urquell: Fix up address mapping in board comments.
  sh: Add support for DMA API debugging.
  sh: Provide cpumask_of_pcibus() to fix NUMA build.
  sh: urquell: Add board comment
  sh: wire up sys_preadv/sys_pwritev() syscalls.
  sh: sh7785lcr: fix PCI address map for 32-bit mode
  sh: intc: Added resume from hibernation support to the intc

Fix lpfc_parse_bg_err()'s use of do_div().  It should be passing a 64-bit
variable as the first parameter.  However, since it's only using a 32-bit
variable, it doesn't need to use do_div() at all, but can instead use the
division operator.

This deals with the following warnings:

    CC      drivers/scsi/lpfc/lpfc_scsi.o
  drivers/scsi/lpfc/lpfc_scsi.c: In function 'lpfc_parse_bg_err':
  drivers/scsi/lpfc/lpfc_scsi.c:1397: warning: comparison of distinct pointer types lacks a cast
  drivers/scsi/lpfc/lpfc_scsi.c:1397: warning: right shift count >= width of type
  drivers/scsi/lpfc/lpfc_scsi.c:1397: warning: passing argument 1 of '__div64_32' from incompatible pointer type
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Updates some usb_serial_port members documentation.
Signed-off-by: NLeandro Dorileo <ldorileo@gmail.com>
Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In commit 51dcdfec ("parport: Use the
PCI IRQ if offered") parport_pc_probe_port() gained an irqflags arg.
This isn't being supplied on powerpc.  This patch make powerpc fallback
to the old behaviour, that is using "0" for irqflags.

Fixes build failure:

  In file included from drivers/parport/parport_pc.c:68:
  arch/powerpc/include/asm/parport.h: In function 'parport_pc_find_nonpci_ports':
  arch/powerpc/include/asm/parport.h:32: error: too few arguments to function 'parport_pc_probe_port'
  arch/powerpc/include/asm/parport.h:32: error: too few arguments to function 'parport_pc_probe_port'
  arch/powerpc/include/asm/parport.h:32: error: too few arguments to function 'parport_pc_probe_port'
  make[3]: *** [drivers/parport/parport_pc.o] Error 1
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

These got overlooked first time around.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the ti-usb adapter returns an zero data length frame (which happens)
then we leak a kref.  Found by Christoph Mair <christoph.mair@gmail.com>
who proposed a patch.  The patch here is different as Christoph's patch
didn't work for the case where tty = NULL and data arrived but Christoph
did all the hard work chasing it down.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ACM sets the low latency flag but calls the flip buffer routines from
IRQ context which isn't permitted (and as of 2.6.29 causes a warning
hence this one was caught)

Fortunatelt ACM doesn't need to set this flag in the first place as it
only set it to work around problems in ancient (pre tty flip rewrite)
kernels.
Reported-by: NChuck Ebbert <cebbert@redhat.com>
Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NMichal Simek <monstr@monstr.eu>

Impact: build fix for Sparc and s390

Stephen Rothwell reported that the Sparc build broke:

 In file included from kernel/panic.c:12:
 include/linux/debug_locks.h: In function '__debug_locks_off':
 include/linux/debug_locks.h:15: error: implicit declaration of function 'xchg'

due to:

 9eeba613: lockdep: warn about lockdep disabling after kernel taint

There is some inconsistency between architectures about where exactly
xchg() is defined.

The traditional place is in system.h but the more logical point for it
is in atomic.h - where most architectures (especially new ones) have
it defined. These architecture also still offer it via system.h.

Some, such as Sparc or s390 only have it in asm/system.h and not available
via asm/atomic.h at all.

Use the widest set of headers in debug_locks.h and also include asm/system.h.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <20090414144317.026498df.sfr@canb.auug.org.au>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Remove duplicated #include's in
  arch/microblaze/include/asm/io.h
  arch/microblaze/kernel/prom.c
  arch/microblaze/kernel/ptrace.c
  arch/microblaze/kernel/signal.c
  arch/microblaze/kernel/sys_microblaze.c
Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: NMichal Simek <monstr@monstr.eu>

Signed-off-by: NMichal Simek <monstr@monstr.eu>