sys_splice() moves data to/from pipes with a file input/output. sys_vmsplice()
moves data to a pipe, with the input being a user address range instead.

This uses an approach suggested by Linus, where we can hold partial ranges
inside the pages[] map. Hopefully this will be useful for network
receive support as well.
Signed-off-by: NJens Axboe <axboe@suse.de>

Every time a new syscall gets added, a BUILD_BUG_ON in
arch/powerpc/platforms/cell/spu_callbacks.c gets triggered.
Since the addition of a new syscall is rather harmless,
the error should just be removed.

While we're here, add sys_tee to the list and add a comment
to systbl.S to remind people that there is another list
on powerpc.
Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Turn on the DART already at 1GB. This is needed because of crippled
devices in some systems, i.e. Airport Extreme cards, only supporting
30-bit DMA addresses.

Otherwise, users with between 1 and 2GB of memory will need to manually
enable it with iommu=force, and that's no good.

Some simple performance tests show that there's a slight impact of
enabling DART, but it's in the 1-3% range (kernel build with disk I/O
as well as over NFS).

iommu=off can still be used for those who don't want to deal with the
overhead (and don't need it for any devices).
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Some devices don't support full 32-bit DMA address space, which we currently
assume. Add the required mask-passing to the IOMMU allocators.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Andrew Morton pointed out that compiler might not inline the functions
marked for inline in kprobes.  There-by allowing the insertion of probes
on these kprobes routines, which might cause recursion.

This patch removes all such inline and adds them to kprobes section
there by disallowing probes on all such routines.  Some of the routines
can even still be inlined, since these routines gets executed after the
kprobes had done necessay setup for reentrancy.
Signed-off-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We weren't using the recommended sequence for putting the CPU into
nap mode.  When I changed the idle loop, for some reason 7447A cpus
started hanging when we put them into nap mode.  Changing to the
recommended sequence fixes that.

The complexity here is that the recommended sequence is a loop that
keeps putting the cpu back into nap mode.  Clearly we need some way
to break out of the loop when an interrupt (external interrupt,
decrementer, performance monitor) occurs.  Here we use a bit in
the thread_info struct to indicate that we need this, and the exception
entry code notices this and arranges for the exception to return
to the value in the link register, thus breaking out of the loop.
We use a new `local_flags' field in the thread_info which we can
alter without needing to use an atomic update sequence.

The PPC970 has the same recommended sequence, so we do the same thing
there too.

This also fixes a bug in the kernel stack overflow handling code on
32-bit, since it was causing a value that we needed in a register to
get trashed.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

In e8222502 the detection of machine types
in prom_init broke for some machines. We should be checking /device_type
instead of /model. This should make Power3 and Power4 boot again. Haven't
been able to test this.  We also need to relocate before comparing.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Fix __initcall return in proc_rtas_init and rtas_init.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Since external and decrementer interrupts set the runlatch on, we need
to ensure its set off again in the idle loop. At the moment we dont turn
it off in the inner loop.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Basically an in-kernel implementation of tee, which uses splice and the
pipe buffers as an intelligent way to pass data around by reference.

Where the user space tee consumes the input and produces a stdout and
file output, this syscall merely duplicates the data inside a pipe to
another pipe. No data is copied, the output just grabs a reference to the
input pipe data.
Signed-off-by: NJens Axboe <axboe@suse.de>

The iSeries Hypervisor only allows us to specify IRQ numbers up to 255 (it
has a u8 field to pass it in).  This patch allows platforms to specify a
maximum to the virtual IRQ numbers we will use and has iSeries set that
to 255.  If not set, the maximum is NR_IRQS - 1 (as before).
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>

We have a strncasecmp so we might as well export it
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

(We'd only added the number, which meant that actually trying
to use splice just went off into la-la-land)
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Since the powerpc 64k pages patch went in, systems that have SLBs
(like Power4 iSeries) needed to have slb_initialize called to set up
some variables for the SLB miss handler.  This was not being called
on the boot processor on iSeries, so on single cpu iSeries machines,
we would get apparent memory curruption as soon as we entered user mode.

This patch fixes that by calling slb_initialize on the boot cpu if the
processor has an SLB.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

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

This fixes several problems with the lparcfg code.  In case
someone gets a sense of deja-vu, part of this was submitted last Sep, I
thought the changes went in, but either got backed out, or just got
lost.

First, change the local_buffer declaration to be unsigned char *.  We
had a bad-math problem in a 2.4 tree which was built with a
"-fsigned-char" parm.  I dont believe we ever build with that parm
now-a-days, but to be safe, I'd prefer the declaration be explicit.

Second, fix a bad math calculation for splpar_strlen.

Third, on the rtas_call for get-system-parameter, pass in
RTAS_DATA_BUF_SIZE for the rtas_data_buf size, instead of letting random
data determine the size.   Until recently, we've had a sufficiently
large 'random data' value get passed in, so the function just happens to
have worked OK.   Now it's getting passed a '0', which causes the
rtas_call to return success, but no data shows up in the buffer.
(oops!).   This was found by the LTC test org.

This is in a branch of code that only gets run on SPLPAR systems.
Tested on power5 Lpar.
Signed-off-by: NWill Schmidt <willschm@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Also cleans up some nearby whitespace problems.
Signed-off-by: NSegher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The only user of get_wchan is the proc fs - and proc can't be built modular.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The boot cmdline is parsed in parse_early_param() and
parse_args(,unknown_bootoption).

And __setup() is used in obsolete_checksetup().

	start_kernel()
		-> parse_args()
			-> unknown_bootoption()
				-> obsolete_checksetup()

If __setup()'s callback (->setup_func()) returns 1 in
obsolete_checksetup(), obsolete_checksetup() thinks a parameter was
handled.

If ->setup_func() returns 0, obsolete_checksetup() tries other
->setup_func().  If all ->setup_func() that matched a parameter returns 0,
a parameter is seted to argv_init[].

Then, when runing /sbin/init or init=app, argv_init[] is passed to the app.
If the app doesn't ignore those arguments, it will warning and exit.

This patch fixes a wrong usage of it, however fixes obvious one only.
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Mark unwind info for signal trampolines using the new S augmentation flag
introduced in: http://gcc.gnu.org/PR26208.

GCC 4.2 (or patched earlier GCC) will be able to special case unwinding
through frames right above signal trampolines.  As the augmentations start
with z flag and S is at the very end of the augmentation string, older GCCs
will just skip the S flag as unknown (that's why an augmentation flag was
chosen over say a new CFA opcode).
Signed-off-by: NJakub Jelinek <jakub@redhat.com>
Cc: Andi Kleen <ak@muc.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Removed platform_init usage on 83xx and 85xx and use define_machine and
probe().  For now we always return true in the problem since you can only
build for one specific board at a time.  This is an artificial constraint.
When we get ride of it we will need to update the Kconfig's for these
sub-arch's and make the board's probe() functions actually do something.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Make machine_check_exception handling code path the same on ppc32 & ppc64.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

for_each_cpu() actually iterates across all possible CPUs.  We've had mistakes
in the past where people were using for_each_cpu() where they should have been
iterating across only online or present CPUs.  This is inefficient and
possibly buggy.

We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the
future.

This patch replaces for_each_cpu with for_each_possible_cpu.
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This removes statically assigned platform numbers and reworks the
powerpc platform probe code to use a better mechanism.  With this,
board support files can simply declare a new machine type with a
macro, and implement a probe() function that uses the flattened
device-tree to detect if they apply for a given machine.

We now have a machine_is() macro that replaces the comparisons of
_machine with the various PLATFORM_* constants.  This commit also
changes various drivers to use the new macro instead of looking at
_machine.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

OCP isn't used in arch/powerpc and hopefully will never be.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

We used to assume that a DMA mapping request with a NULL dev was for
ISA DMA.  This assumption was broken at some point.  Now we explicitly
pass the detected ISA PCI device in the floppy setup.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Non zero initcalls (except for -ENODEV) have started warning at boot.
Fix smt_setup and init_ras_IRQ.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

A bug in the RTAS services incorrectly interprets some bits in the CR
when called from the OS.  Specifically, bits in CR4.  The result could
be a firmware crash that also takes down the partition.  A firmware
fix is in the works.  We have seen this situation when performing DLPAR
operations.  As a temporary workaround, clear the CR in enter_rtas().
Note that enter_rtas() will not set any bits in CR4 before calling RTAS.

Also note that the 32 bit version of enter_rtas() should have the same
work around even though the chances of hitting the bug are much smaller
due to the lack of DLPAR on 32 bit kernels.  However, my assembly skills
are a bit rusty and the 32 bit code doesn't seem to follow the conventions
for where things should be saved.  In addition, I don't have a system
to test 32 bit kernels.  Help creating and at least touch testing the
same workaround for 32 bit would be appreciated.
Signed-off-by: NMike Kravetz <kravetz@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

*) When setting a sighandler using sigaction() call, if the flag
SA_ONSTACK is set and no alternate stack is provided via sigaltstack(),
the kernel still try to install the alternate stack. This behavior is
the opposite of the one which is documented in Single Unix
Specifications V3.

*) Also when setting an alternate stack using sigaltstack() with the
flag SS_DISABLE, the kernel try to install the alternate stack on
signal delivery.

These two use cases makes the process crash at signal delivery.

This fixes it.
Signed-off-by: NLaurent Meyer <meyerlau@fr.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

We need to export ppc64_firmware_features for modules. Before we do that
I think we should probably rename it to powerpc_firmware_features.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Export validate_sp so we can use it in the oprofile calltrace code.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Use memparse() instead of our own code for handling the parsing of mem=
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This fixes a mistake I made when editing these functions - when I
took out the interrupt disabling code (because interrupts are now
disabled by the caller) I left the register that is used for the MSR
value to be used during doze/nap uninitialized.  This fixes it.

Also updated some of the comments in idle_power4.S and removed some
code that was copied over from idle_6xx.S but is no longer relevant
(we don't ever clear the CPU_FTR_CAN_NAP bit at runtime for POWER4).
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The kernel's implementation of notifier chains is unsafe.  There is no
protection against entries being added to or removed from a chain while the
chain is in use.  The issues were discussed in this thread:

    http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2

We noticed that notifier chains in the kernel fall into two basic usage
classes:

	"Blocking" chains are always called from a process context
	and the callout routines are allowed to sleep;

	"Atomic" chains can be called from an atomic context and
	the callout routines are not allowed to sleep.

We decided to codify this distinction and make it part of the API.  Therefore
this set of patches introduces three new, parallel APIs: one for blocking
notifiers, one for atomic notifiers, and one for "raw" notifiers (which is
really just the old API under a new name).  New kinds of data structures are
used for the heads of the chains, and new routines are defined for
registration, unregistration, and calling a chain.  The three APIs are
explained in include/linux/notifier.h and their implementation is in
kernel/sys.c.

With atomic and blocking chains, the implementation guarantees that the chain
links will not be corrupted and that chain callers will not get messed up by
entries being added or removed.  For raw chains the implementation provides no
guarantees at all; users of this API must provide their own protections.  (The
idea was that situations may come up where the assumptions of the atomic and
blocking APIs are not appropriate, so it should be possible for users to
handle these things in their own way.)

There are some limitations, which should not be too hard to live with.  For
atomic/blocking chains, registration and unregistration must always be done in
a process context since the chain is protected by a mutex/rwsem.  Also, a
callout routine for a non-raw chain must not try to register or unregister
entries on its own chain.  (This did happen in a couple of places and the code
had to be changed to avoid it.)

Since atomic chains may be called from within an NMI handler, they cannot use
spinlocks for synchronization.  Instead we use RCU.  The overhead falls almost
entirely in the unregister routine, which is okay since unregistration is much
less frequent that calling a chain.

Here is the list of chains that we adjusted and their classifications.  None
of them use the raw API, so for the moment it is only a placeholder.

  ATOMIC CHAINS
  -------------
arch/i386/kernel/traps.c:		i386die_chain
arch/ia64/kernel/traps.c:		ia64die_chain
arch/powerpc/kernel/traps.c:		powerpc_die_chain
arch/sparc64/kernel/traps.c:		sparc64die_chain
arch/x86_64/kernel/traps.c:		die_chain
drivers/char/ipmi/ipmi_si_intf.c:	xaction_notifier_list
kernel/panic.c:				panic_notifier_list
kernel/profile.c:			task_free_notifier
net/bluetooth/hci_core.c:		hci_notifier
net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_chain
net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_expect_chain
net/ipv6/addrconf.c:			inet6addr_chain
net/netfilter/nf_conntrack_core.c:	nf_conntrack_chain
net/netfilter/nf_conntrack_core.c:	nf_conntrack_expect_chain
net/netlink/af_netlink.c:		netlink_chain

  BLOCKING CHAINS
  ---------------
arch/powerpc/platforms/pseries/reconfig.c:	pSeries_reconfig_chain
arch/s390/kernel/process.c:		idle_chain
arch/x86_64/kernel/process.c		idle_notifier
drivers/base/memory.c:			memory_chain
drivers/cpufreq/cpufreq.c		cpufreq_policy_notifier_list
drivers/cpufreq/cpufreq.c		cpufreq_transition_notifier_list
drivers/macintosh/adb.c:		adb_client_list
drivers/macintosh/via-pmu.c		sleep_notifier_list
drivers/macintosh/via-pmu68k.c		sleep_notifier_list
drivers/macintosh/windfarm_core.c	wf_client_list
drivers/usb/core/notify.c		usb_notifier_list
drivers/video/fbmem.c			fb_notifier_list
kernel/cpu.c				cpu_chain
kernel/module.c				module_notify_list
kernel/profile.c			munmap_notifier
kernel/profile.c			task_exit_notifier
kernel/sys.c				reboot_notifier_list
net/core/dev.c				netdev_chain
net/decnet/dn_dev.c:			dnaddr_chain
net/ipv4/devinet.c:			inetaddr_chain

It's possible that some of these classifications are wrong.  If they are,
please let us know or submit a patch to fix them.  Note that any chain that
gets called very frequently should be atomic, because the rwsem read-locking
used for blocking chains is very likely to incur cache misses on SMP systems.
(However, if the chain's callout routines may sleep then the chain cannot be
atomic.)

The patch set was written by Alan Stern and Chandra Seetharaman, incorporating
material written by Keith Owens and suggestions from Paul McKenney and Andrew
Morton.

[jes@sgi.com: restructure the notifier chain initialization macros]
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: NJes Sorensen <jes@sgi.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

... and rename it to module_32.c since it is the 32-bit version.
The 32-bit and 64-bit ABIs are sufficiently different that having
a merged version isn't really practical.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

... and rename it to swsusp_32.S, since it's 32-bit only at this stage.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Also renamed temp.c to tau_6xx.c (for thermal assist unit) and updated
the Kconfig option description and help text for CONFIG_TAU.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

No functional changes, but call it l2cr_6xx.S since it is specific
to 6xx-family (including G3/750 and G4/74xx) processors.
Signed-off-by: NPaul Mackerras <paulus@samba.org>