The merge-tree version of LOADBASE actually loads the whole given
address from the toc for ppc64.  The matching OFF macro adjust for
this, using an offset of 0 for ppc64, but we weren't using that in
power4_idle.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

The _GLOBAL() macro is for text symbols only. Changed to using
.globl for .data symbols.
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

... since all platforms will have a device tree.
Signed-off-by: Paul Mackerras <paulus@samba.org>

Signed-off-by: Paul Mackerras <paulus@samba.org>

This introduces flush_{fp,altivec,spe}_to_thread and fixes a
branch-too-far error in linking.
Signed-off-by: Paul Mackerras <paulus@samba.org>

Signed-off-by: Paul Mackerras <paulus@samba.org>

Signed-off-by: Paul Mackerras <paulus@samba.org>

We were initializing the btext stuff from prom_init(), thus breaking
the rule that all communication between prom_init() and the rest of
the kernel has to be via the flattened device tree.  This removes
the btext initialization calls from prom_init() and initializes it
instead after the device tree is unflattened.  It would be nice to
do it earlier, but that needs some more infrastructure to find the
properties we need in the flattened device tree.
Signed-off-by: Paul Mackerras <paulus@samba.org>

instead of L1_CACHE_LINE_SIZE and LG_L1_CACHE_LINE_SIZE
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

I forgot a semicolon.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

This allows us to simplify a couple of things.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

The only real user of this file outside platforms/iseries was
drivers/net/iseries_veth.c but all it wanted was ISERIES_HV_ADDR()
so we move that to abs_addr.h (and lowercase it).
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

It will now give ppc64 on 64bit platforms and ppc on 32bit
platforms.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

and use start_thread for both 32 and 64 bit bineries.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

and use it in misc_32.S
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Also simplify arch/ppc64/kernel/Makefile
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

This removes three headers from include/asm-ppc64 that are now in
include/asm-powerpc and are sufficiently similar that they can be
used with ARCH=ppc64.
Signed-off-by: Paul Mackerras <paulus@samba.org>

Recent commits upstream have changed files which are currently
duplicated in arch/powerpc and include/asm-powerpc.  This updates
them with the corresponding changes.
Signed-off-by: Paul Mackerras <paulus@samba.org>

We weren't computing the size of the hash table correctly on iSeries
because the relevant code in prom.c was #ifdef CONFIG_PPC_PSERIES.
This moves the code to hash_utils_64.c, makes it unconditional, and
cleans it up a bit.
Signed-off-by: Paul Mackerras <paulus@samba.org>

On ARCH=ppc64 we were getting htab_hash_mask recalculated
to the correct value for our particular machine by accident.
In the merge tree, that code was commented out, so htab_hash_mask
was being corrupted.

We now set ppc64_pft_size instead which gets htab_has_mask
calculated correctly for us later.  We should put an
ibm,pft-size property in the device tree at some point.

Also set -mno-minimal-toc in some makefiles.
Allow iSeries to configure PROC_DEVICETREE.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

We were not doing alignment properly when remapping the kernel image.

What we want is a 4MB aligned physical address to map at KERNBASE.
Mistakedly we were 4MB aligning the virtual address where the kernel
initially sits, that's wrong.

Instead, we should PAGE align the virtual address, then 4MB align the
physical address result the prom gives to us.
Signed-off-by: David S. Miller <davem@davemloft.net>

Refuse to install a page into a mapping if the mapping count is already
ridiculously large.

You probably cannot trigger this on 32-bit architectures, but on a
64-bit setup we should protect against it.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Newer gcc's are generating this relocation, so the module loader needs to
handle it.
Signed-off-by: Peter Bergner <bergner@vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

* bttv-cards.c:
- Enable S-Video input on DViCO FusionHDTV5 Lite
Signed-off-by: Michael Krufky <mkrufky@m1k.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch prevents illegal traps from causing m32r kernel's infinite loop
execution.
Signed-off-by: Naoto Sugai <sugai@isl.melco.co.jp>
Signed-off-by: Hirokazu Takata <takata@linux-m32r.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Nir Tzachar <tzachar@cs.bgu.ac.il> points out that if an ELF file specifies a
zero-length bss at a whacky address, we cannot load that binary because
padzero() tries to zero out the end of the page at the whacky address, and
that may not be writeable.

See also http://bugzilla.kernel.org/show_bug.cgi?id=5411

So teach load_elf_binary() to skip the bss settng altogether if the elf file
has a zero-length bss segment.

Cc: Roland McGrath <roland@redhat.com>
Cc: Daniel Jacobowitz <dan@debian.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

I've noticed that the calculations for seg_size and nr_segs in
__dma_sync_page_highmem() (arch/ppc/kernel/dma-mapping.c) are wrong.  The
incorrect calculations can result in either an oops or a panic when running
fsck depending on the size of the partition.

The problem with the seg_size calculation is that it can result in a
negative number if size is offset > size.  The problem with the nr_segs
caculation is returns the wrong number of segments, e.g.  it returns 1 when
size is 200 and offset is 4095, when it should return 2 or more.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Revert this recent correctness change: Douglas Crosher <dcrosher@scieneer.com>
reported that it broke an existing application, and that madvise() works
without error on anonymous mappings on Solaris.

This means that madvise() will remain non-standards-compliant: we should
return -EBADF for all requests against non-file-backed vma's, but Linux only
does this for MADV_WILLNEED requests.
Signed-off-by: Suzuki K P <suzuki@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Here is a compatibility fix between Linux and Solaris when used with VxFS
filesystems: Solaris usually accepts acl entries in any order, but with
VxFS it replies with NFSERR_INVAL when it sees a four-entry acl that is not
in canonical form.  It may also fail with other non-canonical acls -- I
can't tell, because that case never triggers: We only send non-canonical
acls when we fake up an ACL_MASK entry.

Instead of adding fake ACL_MASK entries at the end, inserting them in the
correct position makes Solaris+VxFS happy.  The Linux client and server
sides don't care about entry order.  The three-entry-acl special case in
which we need a fake ACL_MASK entry was handled in xdr_nfsace_encode.  The
patch moves this into nfsacl_encode.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

v9fs_file_read and v9fs_file_write use kmalloc to allocate buffers as big
as the data buffer received as parameter.  kmalloc cannot be used to
allocate buffers bigger than 128K, so reading/writing data in chunks bigger
than 128k fails.

This patch reorganizes v9fs_file_read and v9fs_file_write to allocate only
buffers as big as the maximum data that can be sent in one 9P message.
Signed-off-by: Latchesar Ionkov <lucho@ionkov.net>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>