Several platforms use their own copy of what is essentially the same code,
using RTAS to synchronize the timebases when bringing up new CPUs. This
moves it all into a single common implementation and additionally
turns the spinlock into a raw spinlock since the former can rely on
the timebase not being frozen when spinlock debugging is enabled, and finally
masks interrupts while the timebase is disabled.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

RTAS currently uses a normal spinlock. However it can be called from
contexts where this is not necessarily a good idea. For example, it
can be called while syncing timebases, with the core timebase being
frozen. Unfortunately, that will deadlock in case of lock contention
when spinlock debugging is enabled as the spin lock debugging code
will try to use __delay() which ... relies on the timebase being
enabled.

Also RTAS can be used in some low level IRQ handling code path so it
may as well be a raw spinlock for -rt sake.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Based on initial work from: Dale Farnsworth <dale@farnsworth.org>

Add the low level irq tracing hooks for 32-bit powerpc needed
to enable full lockdep functionality.

The approach taken to deal with the code in entry_32.S is that
we don't trace all the transitions of MSR:EE when we just turn
it off to peek at TI_FLAGS without races. Only when we are
calling into C code or returning from exceptions with a state
that have changed from what lockdep thinks.

There's a little bugger though: If we take an exception that
keeps interrupts enabled (such as an alignment exception) while
interrupts are enabled, we will call trace_hardirqs_on() on the
way back spurriously. Not a big deal, but to get rid of it would
require remembering in pt_regs that the exception was one of the
type that kept interrupts enabled which we don't know at this
stage. (Well, we could test all cases for regs->trap but that
sucks too much).
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: NKumar Gala <galak@kernel.crashing.org>

On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote:
> On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
> > Sonny Rao writes:
> >
> > > Fix the BSR driver to allow small BSR devices, which are limited to a
> > > single 4k space, on a 64k page kernel.  Previously the driver would
> > > reject the mmap since the size was smaller than PAGESIZE (or because
> > > the size was greater than the size of the device).  Now, we check for
> > > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
> > > as the remap_pfn functions will do this for us.
> >
> > Thanks.
> >
> > Do we know that the BSR size will always be 4k if it's not a multiple
> > of 64k?  Is it possible that we could get 8k, 16k or 32k or BSRs?
> > If it is possible, what does the user need to be able to do?  Do they
> > just want to map 4k, or might then want to map the whole thing?
>
>
> Hi Paul, I took a look at changing the driver to reject a request for
> mapping more than a single 4k page, however the only indication we get
> of the requested size in the mmap function is the vma size, and this
> is always one page at minimum.  So, it's not possible to determine if
> the user wants one 4k page or more.  As I noted in my first response,
> there is only one case where this is even possible and I don't think
> it is a significant concern.
>
> I did notice that I left out the check to see if the user is trying to
> map more than the device length, so I fixed that.  Here's the revised
> patch.

Alright, I've reworked this now so that if we get one of these cases
where there's a bsr that's > 4k and < 64k on a 64k kernel we'll only
advertise that it is a 4k BSR to userspace.  I think this is the best
solution since user programs are only supposed to look at sysfs to
determine how much can be mapped, and libbsr does this as well.

Please consider for 2.6.31 as a fix, thanks.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Add a 4096 byte BSR size which will be used on new machines.  Also, remove
the warning when we run into an unknown size, as this can spam the kernel
log excessively.
Signed-off-by: NSonny Rao <sonnyrao@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The 32-bit kernel relies on some memory being mapped covering
the kernel text,data and bss at least, early during boot before
the full MMU setup is done. On 32-bit "classic" processors, this
is done using BAT registers.

On 601, the size of BATs is limited to 8M and we use 2 of them
for that initial mapping. This can become quite tight when enabling
features like lockdep, so let's use a 3rd one to bump that mapping
from 16M to 24M. We keep the 4th BAT free as it can be useful for
debugging early boot code to map things like serial ports.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The macio_dev's created to map devices inside the MacIO ASICs
don't have proper dma_ops. This causes crashes on some machines
since the SCSI code calls dma_map_* on our behalf using the
device we hang from.

This fixes it by copying the parent PCI device dma_ops into
the macio_dev when creating it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Those functions are way too big to be inline, besides, kmap_atomic()
wants to call debug_kmap_atomic() which isn't exported for modules
and causes module link failures.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Since we can use kmalloc earlier we are getting the following since the
mpic_alloc() code calls alloc_bootmem().  Move to using kzalloc() to
remove the warning.

------------[ cut here ]------------
Badness at c0583248 [verbose debug info unavailable]
NIP: c0583248 LR: c0583210 CTR: 00000004
REGS: c0741de0 TRAP: 0700   Not tainted  (2.6.30-06736-g12a31df)
MSR: 00021000 <ME,CE>  CR: 22024024  XER: 00000000
TASK = c070d3b8[0] 'swapper' THREAD: c0740000 CPU: 0
<6>GPR00: 00000001 c0741e90 c070d3b8 00000001 00000210 00000020 3fffffff 00000000
<6>GPR08: 00000000 c0c85700 c04f8c40 0000002d 22044022 1004a388 7ffd9400 00000000
<6>GPR16: 00000000 7ffcd100 7ffcd100 7ffcd100 c04f8c40 00000000 c059f62c c075a0c0
<6>GPR24: c059f648 00000000 0000000f 00000210 00000020 00000000 3fffffff 00000210
NIP [c0583248] alloc_arch_preferred_bootmem+0x50/0x80
LR [c0583210] alloc_arch_preferred_bootmem+0x18/0x80
Call Trace:
[c0741e90] [c07343b0] devtree_lock+0x0/0x24 (unreliable)
[c0741ea0] [c0583b14] ___alloc_bootmem_nopanic+0x54/0x108
[c0741ee0] [c0583e18] ___alloc_bootmem+0x18/0x50
[c0741ef0] [c057b9cc] mpic_alloc+0x48/0x710
[c0741f40] [c057ecf4] mpc85xx_ds_pic_init+0x190/0x1b8
[c0741f90] [c057633c] init_IRQ+0x24/0x34
[c0741fa0] [c05738b8] start_kernel+0x260/0x3dc
[c0741ff0] [c00003c8] skpinv+0x2e0/0x31c
Instruction dump:
409e001c 7c030378 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c0c8
39295700 80090004 7c000034 5400d97e <0f000000> 2f800000 409e001c 38800000

BenH: Changed to use GFP_KERNEL, the allocator will do the right thing
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

For some reason we've had an explicit KERN_INFO for GPR dumps.  With
recent changes we get output like:

<6>GPR00: 00000000 ef855eb0 ef858000 00000001 000000d0 f1000000 ffbc8000 ffffffff

The KERN_INFO is causing the <6>.  Don't see any reason to keep it
around.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The old PowerSurge SMP (ie, dual or quad 604 machines) code has
numerous issues in modern world.

One is cpu_possible_map is set too late (the device-tree is bogus)
so we fail to allocate the interrupt stacks and crash. Another
problem is the fact the timebase is frozen by the bringup of the
second CPU so the delays in the generic code will hang, we need
to move some of the calling procedure to inside the powermac code.

This makes it boot again for me
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The kernel reserves the I/O address space from 0x0 to 0xfff for legacy
ISA devices. Change the ranges property for the PCI2ISA bridge to match
the kernels behavior, even if the ranges property isn't used for now.
Signed-off-by: NGerhard Pircher <gerhard_pircher@gmx.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

A change to the i2c subsystem breaks the warp platform code. The patch
is cleaner anyway, the old way was a bit crufty.

For those with keen eyes, the gratuitous change in the string from
PIKA to Warp is just so the logs look a bit nicer. The following two
lines tend to be printed one after another.

  Warp POST OK
  Warp DTM thread running.

Yeah, this will be the third patch to warp.c submitted in this
release....

Cheers,
   Sean

The i2c_client struct changed, breaking the code that looked for the ad7414
chip. Use the new of_find_i2c_device_by_node function added in 2.6.29.
Signed-off-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Have git ignore generated files from dtc compile
Signed-off-by: NJon Smirl <jonsmirl@gmail.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit 31207dab
"Fix incorrect allocation of interrupt rev-map"
introduced a regression crashing on boot on machines using
a "DCR" based MPIC, such as the Cell blades.

The reason is that the irq host data structure is initialized
much later as a result of that patch, causing our calls to
mpic_map() do be done before we have a host setup.

Unfortunately, this breaks _mpic_map_dcr() which uses the
mpic->irqhost to get to the device node.

This fixes it by, instead, passing the device node explicitely
to mpic_map().
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NAkira Tsukamoto <akirat@rd.scei.sony.co.jp>

Turning on SWIOTLB selects or enables PPC_NEED_DMA_SYNC_OPS, which means
we get the non empty versions of dma_sync_* in asm/dma-mapping.h

On my pseries machine the dma_ops have no such routines and we die with
a null pointer - this patch gets it booting, is there a more elegant way
to do it?
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (28 commits)
  drm: remove unused #include <linux/version.h>'s
  drm/radeon: fix driver initialization order so radeon kms can be builtin
  drm: Fix shifts which were miscalculated when converting from bitfields.
  drm/radeon: Clear surface registers at initialization time.
  drm/radeon: Don't initialize acceleration related fields of struct fb_info.
  drm/radeon: fix radeon kms framebuffer device
  drm/i915: initialize fence registers to zero when loading GEM
  drm/i915: Fix HDMI regression introduced in new chipset support
  drm/i915: fix LFP data fetch
  drm/i915: set TV detection mode when tv is already connected
  drm/i915: Catch up to obj_priv->page_list rename in disabled debug code.
  drm/i915: Fix size_t handling in off-by-default debug printfs
  drm/i915: Don't change the blank/sync width when calculating scaled modes
  drm/i915: Add support for changing LVDS panel fitting using an output property.
  drm/i915: correct suspend/resume ordering
  drm/i915: Add missing dependency on Intel AGP support.
  drm/i915: Generate 2MHz clock for display port aux channel I/O. Retry I/O.
  drm/i915: Clarify error returns from display port aux channel I/O
  drm/i915: Add CLKCFG register definition
  drm/i915: Split array of DAC limits into separate structures.
  ...

* 'futexes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  futex: request only one page from get_user_pages()

This commit 335f8514 has stopped
properly checking if there is any usb serial associated with the tty in
the close function. It happens the close function is called by releasing
the terminal right after opening the device fails.

As an example, open fails with a non-existing device, when probe has
never been called, because the device has never been plugged. This is
common in systems with static modules and no udev.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This commit 10077d4a has stopped
checking if there was a valid acm device associated to the tty, which is
not true right after open fails and tty subsystem tries to close the
device.

As an example, open fails with a non-existing device, when probe has
never been called, because the device has never been plugged. This is
common in systems with static modules and no udev.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is required, otherwise a user will get a EINVAL while opening a
non-existing device, instead of ENODEV.

This is what I get with this patch applied now instead of an "Invalid
argument".

  cascardo@vespa:~$ cat /dev/ttyACM0
  cat: /dev/ttyACM0: No such device
  cascardo@vespa:~$
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
  ide cs5520: Initialize second port's interrupt number.
  ide: improve handling of Power Management requests
  ide: add QUANTUM FIREBALLct20 30 with firmware APL.090 to ivb_list[]
  ide: relax DMA info validity checking
  ide-cd: Improve "weird block size" error message
  ide-cd: Don't warn on bogus block size unless it actually matters.
  ide: fix handling of unexpected IRQs vs request_irq()

Currently the 4th parameter of get_user_pages() is called len, but its
in pages, not bytes. Rename the thing to nr_pages to avoid future
confusion.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

UML: Fix some apparent bitrot

- migration of net_device methods into net_device_ops
- dma_sync_single() changes
Signed-off-by: NPaul Menage <menage@google.com>
Acked-by: NAmerigo Wang <xiyou.wangcong@gmail.com>
--

This version is split from my earlier patch, including just the
portions that ar required for Linus' tree.

Fixes the following compile errors:

include/linux/dma-mapping.h:113: error: redefinition of 'dma_sync_single'
arch/um/include/asm/dma-mapping.h:84: error: previous definition of 'dma_sync_single' was here
include/linux/dma-mapping.h: In function 'dma_sync_single':
include/linux/dma-mapping.h:117: error: implicit declaration of function 'dma_sync_single_for_cpu'
include/linux/dma-mapping.h: At top level:
include/linux/dma-mapping.h:120: error: redefinition of 'dma_sync_sg'
arch/um/include/asm/dma-mapping.h:91: error: previous definition of 'dma_sync_sg' was here
include/linux/dma-mapping.h: In function 'dma_sync_sg':
include/linux/dma-mapping.h:124: error: implicit declaration of function 'dma_sync_sg_for_cpu'

arch/um/drivers/slirp_kern.c: In function 'slirp_init':
arch/um/drivers/slirp_kern.c:35: error: 'struct net_device' has no member named 'init'
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This build error triggers on x86:

 drivers/built-in.o: In function `i2c_dw_init':
 i2c-designware.c:(.text+0x4e37ca): undefined reference to `clk_get_rate'
 drivers/built-in.o: In function `dw_i2c_probe':
 i2c-designware.c:(.devinit.text+0x51f5e): undefined reference to `clk_get'
 i2c-designware.c:(.devinit.text+0x51f76): undefined reference to `clk_enable'
 i2c-designware.c:(.devinit.text+0x520ff): undefined reference to `clk_disable'
 i2c-designware.c:(.devinit.text+0x52108): undefined reference to `clk_put'

Because this new driver uses the clk_*() facilities which is an
ARM-only thing currently.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Yanmin noticed that fault_in_user_writeable() requests 4 pages instead
of one.

That's the result of blindly trusting Linus' proposal :) I even looked
up the prototype to verify the correctness: the argument in question
is confusingly enough named "len" while in reality it means number of
pages.
Pointed-out-by: NYanmin Zhang <yanmin_zhang@linux.intel.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

This reverts commit 9e9f46c4.

Quoting from the commit message:

 "At this point, it seems to solve more problems than it causes, so let's
  try using it by default.  It's an easy revert if it ends up causing
  trouble."

And guess what? The _CRS code causes trouble.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* git://git.infradead.org/battery-2.6:
  da9030_battery: Fix race between event handler and monitor
  Add MAX17040 Fuel Gauge driver
  w1: ds2760_battery: add support for sleep mode feature
  w1: ds2760: add support for EEPROM read and write
  ds2760_battery: cleanups in ds2760_battery_probe()

Merge branches 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/{vfs-2.6,audit-current}

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
  another race fix in jfs_check_acl()
  Get "no acls for this inode" right, fix shmem breakage
  inline functions left without protection of ifdef (acl)

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current:
  audit: inode watches depend on CONFIG_AUDIT not CONFIG_AUDIT_SYSCALL

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Even though one cannot make use of the audit watch code without
CONFIG_AUDIT_SYSCALL the spaghetti nature of the audit code means that
the audit rule filtering requires that it at least be compiled.

Thus build the audit_watch code when we build auditfilter like it was
before cfcad62c

Clearly this is a point of potential future cleanup..
Reported-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

* 'futexes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  futex: Fix the write access fault problem for real

commit 64d1304a (futex: setup writeable mapping for futex ops which
modify user space data) did address only half of the problem of write
access faults.

The patch was made on two wrong assumptions:

1) access_ok(VERIFY_WRITE,...) would actually check write access.

   On x86 it does _NOT_. It's a pure address range check.

2) a RW mapped region can not go away under us.

   That's wrong as well. Nobody can prevent another thread to call
   mprotect(PROT_READ) on that region where the futex resides. If that
   call hits between the get_user_pages_fast() verification and the
   actual write access in the atomic region we are toast again.

The solution is to not rely on access_ok and get_user() for any write
access related fault on private and shared futexes. Instead we need to
fault it in with verification of write access.

There is no generic non destructive write mechanism which would fault
the user page in trough a #PF, but as we already know that we will
fault we can as well call get_user_pages() directly and avoid the #PF
overhead.

If get_user_pages() returns -EFAULT we know that we can not fix it
anymore and need to bail out to user space.

Remove a bunch of confusing comments on this issue as well.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org

SLUB uses higher order allocations by default but falls back to small
orders under memory pressure. Make sure the GFP mask used in the initial
allocation doesn't include __GFP_NOFAIL.
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Traditionally, we never failed small orders (even regardless of any
__GFP_NOFAIL flags), and slab will allocate order-1 allocations even for
small allocations that could fit in a single page (in order to avoid
excessive fragmentation).

Maybe we should remove this warning entirely, but before making that
judgement, at least limit it to bigger allocations.
Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  Staging: octeon-ethernet: Fix race freeing transmit buffers.
  Staging: octeon-ethernet: Convert to use net_device_ops.
  MIPS: Cavium: Add CPU hotplugging code.
  MIPS: SMP: Allow suspend and hibernation if CPU hotplug is available
  MIPS: Add arch generic CPU hotplug
  DMA: txx9dmac: use dma_unmap_single if DMA_COMPL_{SRC,DEST}_UNMAP_SINGLE set
  MIPS: Sibyte: Fix build error if CONFIG_SERIAL_SB1250_DUART is undefined.
  MIPS: MIPSsim: Fix build error if MSC01E_INT_BASE is undefined.
  MIPS: Hibernation: Remove SMP TLB and cacheflushing code.
  MIPS: Build fix - include <linux/smp.h> into all smp_processor_id() users.
  MIPS: bug.h Build fix - include <linux/compiler.h>.

The existing code had the following race:

Thread-1                       Thread-2

inc/read in_use
                               inc/read in_use
inc tx_free_list[qos].len
                               inc tx_free_list[qos].len

The actual in_use value was incremented twice, but thread-1 is going
to free memory based on its stale value, and will free one too many
times.  The result is that memory is freed back to the kernel while
its packet is still in the transmit buffer.  If the memory is
overwritten before it is transmitted, the hardware will put a valid
checksum on it and send it out (just like it does with good packets).
If by chance the TCP flags are clobbered but not the addresses or
ports, the result can be a broken TCP stream.

The fix is to track the number of freed packets in a single location
(a Fetch-and-Add Unit register).  That way it can never get out of sync
with itself.

We try to free up to MAX_SKB_TO_FREE (currently 10) buffers at a time.
If fewer are available we adjust the free count with the difference.
The action of claiming buffers to free is atomic so two threads cannot
claim the same buffers.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>