Patch from Ben Dooks

Do not export items that are not needed by symbol name
elsewhere
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

The items in the export table do not need to be
exported elsehwere, so quash the sparse warning
by making the symbol for the table entry static.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

The s3c2410 serial driver is missing static declerations
on several functions that are not exported, and have no
need of being exported outside the driver
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

arch/arm/mach-s3c2410/time.c is missing include
of cpu.h, causing the declaration of the timer
struct (s3c24xx_timer) to be flagged as missing
the declaration.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Nicolas Pitre

Either no one is using an ARM710 with recent kernels, or all ARM710s
still in use are not afflicted by this swi bug.  Nevertheless, the code
to work around the ARM710 swi bug is itself currently buggy since it
uses r8 as a pointer to S_PC while in fact it holds the spsr content
these days. Fix that, and simplify the code as well.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NDavid 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: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

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

This patch prevents illegal traps from causing m32r kernel's infinite loop
execution.
Signed-off-by: NNaoto Sugai <sugai@isl.melco.co.jp>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NSuzuki K P <suzuki@in.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NAndreas Gruenbacher <agruen@suse.de>
Acked-by: NTrond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NLatchesar Ionkov <lucho@ionkov.net>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In the current dell_rbu code ver 2.0 the packet update mechanism makes the
user app dump every individual packet in to the driver.

This adds in efficiency as every packet update makes the
/sys/class/firmware/dell_rbu/loading and data files to disappear and reappear
again.  Thus the user app needs to wait for the files to reappear to dump
another packet.  This slows down the packet update tremendously in case of
large number of packets.  I am submitting a new patch for dell_rbu which will
change the way we do packet updates;

In the new method the user app will create a new single file which has already
packetized the rbu image and all the packets are now staged in this file.

This driver also creates a new entry in
/sys/devices/platform/dell_rbu/packet_size ; the user needs to echo the packet
size here before downloading the packet file.

The user should do the following:

 create one single file which has all the packets stacked together.
 echo the packet size in to /sys/devices/platform/dell_rbu/packet_size.
 echo 1 > /sys/class/firmware/dell_rbu/loading
 cat the packetfile > /sys/class/firmware/dell_rbu/data
 echo 0 > /sys/class/firmware/dell_rbu/loading

The driver takes the file which came through /sys/class/firmware/dell_rbu/data
and takes chunks of paket_size data from it and place in contiguous memory.

This makes packet update process very efficient and fast.  As all the packet
update happens in one single operation.  The user can still read back the
downloaded file from /sys/devices/platform/dell_rbu/data.
Signed-off-by: NAbhay Salunke <abhay_salunke@dell.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

pSeries_irq_bus_setup is marked __devinit but references s7a_workaround
which is marked __initdata.

Depending on who got the memory for s7a_workaround (and if the value was
now positive), it was possible for PCI hotplugged devices to have 3
subtracted from their interrupt number.  This would happen randomly and
caused me much confusion :)
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Search for a disconnect ccw_device on the ccw bus rather than on the css
bus (was a typo in patch I did for the klist conversion).  A cast to an
embedding ccw_device from an embedded device in a struct subchannel will
lead us to oopses.
Signed-off-by: NCornelia Huck <cohuck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Breakage noted by Al Viro.

It breaks non-PCI builds, it's probably better to have a more
direct implementation on sparc32, and which driver actually
needs this is still questionable.

We can resolve this in 2.6.15
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Incorrect uart_write_wakeup() calls cause reference to a
NULL tty pointer in sunsab and sunzilog serial drivers.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Need to use long long, not long when RMWing a MSR. I think
it's harmless right now, but still should be better fixed
if AMD adds any bits in the upper 32bit of HWCR.

Bug was introduced with the TLB flush filter fix for i386
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

CPU hotplug fills up the possible map to NR_CPUs, but it did that after
setting up per CPU data. This lead to CPU data not getting allocated
for all possible CPUs, which lead to various side effects.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

All the same issues - we can't just save the pointer to the thread, we
must save the pid/uid/euid combination.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

If a process issues an URB from userspace and (starts to) terminate
before the URB comes back, we run into the issue described above.  This
is because the urb saves a pointer to "current" when it is posted to the
device, but there's no guarantee that this pointer is still valid
afterwards.

In fact, there are three separate issues:

1) the pointer to "current" can become invalid, since the task could be
   completely gone when the URB completion comes back from the device.

2) Even if the saved task pointer is still pointing to a valid task_struct,
   task_struct->sighand could have gone meanwhile.

3) Even if the process is perfectly fine, permissions may have changed,
   and we can no longer send it a signal.

So what we do instead, is to save the PID and uid's of the process, and
introduce a new kill_proc_info_as_uid() function.
Signed-off-by: NHarald Welte <laforge@gnumonks.org>
[ Fixed up types and added symbol exports ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On the boot processor, we need to do the move onto the Linux trap
table a little bit differently else we'll take unhandlable faults in
the firmware address space.

Previously we would do the following:

1) Disable PSTATE_IE in %pstate.
2) Set %tba by hand to sparc64_ttable_tl0
3) Initialize alternate, mmu, and interrupt global
   trap registers.
4) Call prom_set_traptable()

That doesn't work very well actually with the way we boot the kernel
VM these days.  It worked by luck on many systems because the firmware
accesses for the prom_set_traptable() call happened to be loaded into
the TLB already, something we cannot assume.

So the new scheme is this:

1) Clear PSTATE_IE in %pstate and set %pil to 15
2) Call prom_set_traptable()
3) Initialize alternate, mmu, and interrupt global
   trap registers.

and this works quite well.  This sequence has been moved into a
callable function in assembler named setup-trap_table().  The idea is
that eventually trampoline.S can use this code as well.  That isn't
possible currently due to some complications, but eventually we should
be able to do it.

Thanks to Meelis Roos for the Ultra5 boot failure report.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Noticed by Terence Ripperda

Undo wrong change in global_flush_tlb. We need to flush the caches in all
cases, not just when pages were reverted. This was a bogus optimization
added earlier, but it was wrong.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Patch from Vincent Sanders

Add a defconfig for the ARM Collie platform
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NVincent Sanders <vince@arm.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Vincent Sanders

Add a defconfig for the ARM Corgi Zarus platform
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NVincent Sanders <vince@arm.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Vincent Sanders

Add a defconfig for the ARM Poodle Zarus platform
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NVincent Sanders <vince@arm.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Vincent Sanders

Add a defconfig for the ARM Spitz Zarus platform
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NVincent Sanders <vince@arm.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Nicolas Pitre

drivers/mfd/ucb1x00-core.c: In function 'ucb1x00_probe':
drivers/mfd/ucb1x00-core.c:482: error: 'ucb1x00_class' undeclared (first use in this function)
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This fixes the setup of the alignment of the signal frame, so that all
signal handlers are run with a properly aligned stack frame.

The current code "over-aligns" the stack pointer so that the stack frame
is effectively always mis-aligned by 4 bytes.  But what we really want
is that on function entry ((sp + 4) & 15) == 0, which matches what would
happen if the stack were aligned before a "call" instruction.
Signed-off-by: NMarkus F.X.J. Oberhumer <markus@oberhumer.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The logic in ide_do_request() doesn't guarantee that both drives will be
serviced after a call.  It may "forget" to service one in some
circumstances, including when one of the drive is suspended (it will
eventually fail to service the slave when the master is suspended for
example).  This prevents the wakeup requests that gets queued on wakeup
from sleep from beeing serviced in some cases when 2 drives are sharing
an IDE bus.

The problem is deep enough in the way this code works (and there are
probably a few other problematic but rare corner cases) and fixing it
would require some major rethinking of the way IDE decides which channel
to service.  This is not 2.6.14 material.  However, in the meantime,
Bart has accepted this simple workaround that will fix the crash on
wakeup from sleep since this specific corner case is actually hitting
users to get into 2.6.14.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The third param in this call to vmap shouldn't be GFP_KERNEL, which
makes no sense, but rather VM_MAP.  Thanks to Al Viro for spotting
this.
Signed-off-by: NTom Zanussi <zanussi@us.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>