This patch is for supporting IDE interface for M3A-2170(Mappi-III) board.
Signed-off-by: NMamoru Sakugawa <sakugawa@linux-m32r.org>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch fixes a deadlock problem of the m32r SMP kernel.

In the m32r kernel, sys_tas() system call is provided as a test-and-set
function for userspace, for backward compatibility.

In some multi-threading application program, deadlocks were rarely caused
at sys_tas() funcion.  Such a deadlock was caused due to a collision of
__pthread_lock() and __pthread_unlock() operations.

The "tas" syscall is repeatedly called by pthread_mutex_lock() to get a
lock, while a lock variable's value is not 0.  On the other hand,
pthead_mutex_unlock() sets the lock variable to 0 for unlocking.

In the previous implementation of sys_tas() routine, there was a
possibility that a unlock operation was ignored in the following case:

- Assume a lock variable (*addr) was equal to 1 before sys_tas() execution.
- __pthread_unlock() operation is executed by the other processor
  and the lock variable (*addr) is set to 0, between a read operation
  ("oldval = *addr;") and the following write operation ("*addr = 1;")
  during a execution of sys_tas().

In this case, the following write operation ("*addr = 1;") overwrites the
__pthread_unlock() result, and sys_tas() fails to get a lock in the next
turn and after that.

According to the attatched patch, sys_tas() returns 0 value in the next
turn and deadlocks never happen.
Signed-off-by: NHitoshi Yamamoto <Yamamoto.Hitoshi@ap.MitsubishiElectric.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>

The attached patch implements a bunch of small changes to the FRV arch to
make it work again.

It deals with the following problems:

 (1) SEM_DEBUG should be SEMAPHORE_DEBUG.

 (2) The argument list to pcibios_penalize_isa_irq() has changed.

 (3) CONFIG_HIGHMEM can't be used directly in #if as it may not be defined.

 (4) page->private is no longer directly accessible.

 (5) linux/hardirq.h assumes asm/hardirq.h will include linux/irq.h

 (6) The IDE MMIO access functions are given pointers, not integers, and so
     get type casting errors.

 (7) __pa() is passed an explicit u64 type in drivers/char/mem.c, but that
     can't be cast directly to a pointer on a 32-bit platform.

 (8) SEMAPHORE_DEBUG should not be contingent on WAITQUEUE_DEBUG as that no
     longer exists.

 (9) PREEMPT_ACTIVE is too low a value.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Here are the Sparc bits.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This replaces the (in my opinion horrible) VM_UNMAPPED logic with very
explicit support for a "remapped page range" aka VM_PFNMAP.  It allows a
VM area to contain an arbitrary range of page table entries that the VM
never touches, and never considers to be normal pages.

Any user of "remap_pfn_range()" automatically gets this new
functionality, and doesn't even have to mark the pages reserved or
indeed mark them any other way.  It just works.  As a side effect, doing
mmap() on /dev/mem works for arbitrary ranges.

Sparc update from David in the next commit.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Blah.  The patch [0] I recently sent fixing errors with
in_hugepage_area() and prepare_hugepage_range() for powerpc itself has
an off-by-one bug.  Furthermore, the related functions
touches_hugepage_*_range() and within_hugepage_*_range() are also
buggy.  Some of the bugs, like those addressed in [0] originated with
commit 7d24f0b8 where we tweaked the
semantics of where hugepages are allowed.  Other bugs have been there
essentially forever, and are due to the undefined behaviour of '<<'
with shift counts greater than the type width (LOW_ESID_MASK could
return non-zero for high ranges with the right congruences).

The good news is that I now have a testsuite which should pick up
things like this if they creep in again.

[0] "powerpc-fix-for-hugepage-areas-straddling-4gb-boundary"
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

With the removal of include/asm-powerpc, we no longer need
arch/powerpc/include/asm for the 64 bit build.  We also do not need
-Iarch/powerpc for the 64 bit build either.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The DBG() call where updated with the appropriate KERN_* symbol.
Signed-off-by: NDaniel Marjamki <daniel.marjamaki@comhem.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When attempting to hotadd a PCI card with a bridge on it, I saw
the kernel reporting resource collision errors even when there were
really no collisions. The problem is that the code doesn't skip
over "invalid" resources with their resource type flag not set.
Others have reported similar problems at boot time and for
non-bridge PCI card hotplug too, where the code flags a
resource collision for disabled ROMs. This patch fixes both
problems.
Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Modified common.c so it's using the appropriate KERN_* in printk() calls.
Signed-off-by: NDaniel Marjamkia <daniel.marjamaki@comhem.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Commit 7d24f0b8 fixed bugs in the ppc64 SLB
miss handler with respect to hugepage handling, and in the process tweaked
the semantics of the hugepage address masks in mm_context_t.

Unfortunately, it left out a couple of necessary changes to go with that
change.  First, the in_hugepage_area() macro was not updated to match,
second prepare_hugepage_range() was not updated to correctly handle
hugepages regions which straddled the 4GB point.

The latter appears only to cause process-hangs when attempting to map such
a region, but the former can cause oopses if a get_user_pages() is
triggered at the wrong point.  This patch addresses both bugs.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix a bug in kprobes that can cause an Oops or even a crash when a return
probe is installed on one of the following functions: sys_execve,
do_execve, load_*_binary, flush_old_exec, or flush_thread.  The fix is to
remove the call to kprobe_flush_task() in flush_thread().  This fix has
been tested on all architectures for which the return-probes feature has
been implemented (i386, x86_64, ppc64, ia64).  Please apply.

BACKGROUND

Up to now, we have called kprobe_flush_task() under two situations: when a
task exits, and when it execs.  Flushing kretprobe_instances on exit is
correct because (a) do_exit() doesn't return, and (b) one or more
return-probed functions may be active when a task calls do_exit().  Neither
is the case for sys_execve() and its callees.

Initially, the mistaken call to kprobe_flush_task() on exec was harmless
because we put the "real" return address of each active probed function
back in the stack, just to be safe, when we recycled its
kretprobe_instance.  When support for ppc64 and ia64 was added, this safety
measure couldn't be employed, and was eventually dropped even for i386 and
x86_64.  sys_execve() and its callees were informally blacklisted for
return probes until this fix was developed.
Acked-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
Signed-off-by: NJim Keniston <jkenisto@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Restore an earlier mod which went missing in the powerpc reshuffle: the 4xx
mmu_mapin_ram does not need to take init_mm.page_table_lock.
Signed-off-by: NHugh Dickins <hugh@veritas.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>

Update comments (only) on page_table_lock and mmap_sem in arch/powerpc.
Removed the comment on page_table_lock from hash_huge_page: since it's no
longer taking page_table_lock itself, it's irrelevant whether others are; but
how it is safe (even against huge file truncation?) I can't say.
Signed-off-by: NHugh Dickins <hugh@veritas.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>

Email address update, changing old work address to personal (permanent)
one.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Earlier I unifdefed PageCompound, so that snd_pcm_mmap_control_nopage and
others can give out a 0-order component of a higher-order page, which won't
be mistakenly freed when zap_pte_range unmaps it.  But many Bad page states
reported a PG_reserved was freed after all: I had missed that we need to
say __GFP_COMP to get compound page behaviour.

Some of these higher-order pages are allocated by snd_malloc_pages, some by
snd_malloc_dev_pages; or if SBUS, by sbus_alloc_consistent - but that has
no gfp arg, so add __GFP_COMP into its sparc32/64 implementations.

I'm still rather puzzled that DRM seems not to need a similar change.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Although we tend to associate VM_RESERVED with remap_pfn_range, quite a few
drivers set VM_RESERVED on areas which are then populated by nopage.  The
PageReserved removal in 2.6.15-rc1 changed VM_RESERVED not to free pages in
zap_pte_range, without changing those drivers not to set it: so their pages
just leak away.

Let's not change miscellaneous drivers now: introduce VM_UNPAGED at the core,
to flag the special areas where the ptes may have no struct page, or if they
have then it's not to be touched.  Replace most instances of VM_RESERVED in
core mm by VM_UNPAGED.  Force it on in remap_pfn_range, and the sparc and
sparc64 io_remap_pfn_range.

Revert addition of VM_RESERVED to powerpc vdso, it's not needed there.  Is it
needed anywhere?  It still governs the mm->reserved_vm statistic, and special
vmas not to be merged, and areas not to be core dumped; but could probably be
eliminated later (the drivers are probably specifying it because in 2.4 it
kept swapout off the vma, but in 2.6 we work from the LRU, which these pages
don't get on).

Use the VM_SHM slot for VM_UNPAGED, and define VM_SHM to 0: it serves no
purpose whatsoever, and should be removed from drivers when we clean up.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Acked-by: NWilliam Irwin <wli@holomorphy.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On some systems, libc PAGE_SIZE calls getpagesize, which can't happen from a
stub.  So, I use UM_KERN_PAGE_SIZE, which is less variable in its definition,
instead.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch makes stub_segv use the stub_syscall macros.  This was needed
anyway, but the bug that prompted this was the discovery that gcc was storing
stuff in RCX, which is trashed across a system call.  This is exactly the sort
of problem that the new macros fix.

There is a stub_syscall0 for getpid.  stub_segv was changed to be a libc file,
and that caused some include changes.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This gives a name to the anonymous union introduced in skas-hold-own-ldt,
allowing to build on a wider range of gccs.

It also removes ldt.h, which somehow became real, and replaces it with a
symlink, and creates ldt-x86_64.h as a copy of ldt-i386.h for now.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We have a bug in the i386 stub_syscall6 which pushes ebp before the system
call and pops it afterwards.  Because we use syscall6 to remap the stack, the
old contents of the stack (and the former value of ebp) are no longer
available.  Some versions of gcc make from a real local, accessed through ebp,
despite my efforts to make it obvious that references to from are really
constants.  This patch attempts to make it even more obvious by eliminating
from and using a macro to access the stub's data explicitly with constants.

My original thinking on this was to replace syscall6 with a remap_stack
interface which saved ebp someplace and restored it afterwards.  The problem
is that there are no registers to put it in, except for esp.  That could work,
since we can store a constant in esp after the mmap because we just replaced
the stack.  However, this approach seems a tad cleaner.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The nasid_index was not being incremented if the
pointer was null, causing an infinite loop.

Signed-off-by: Russ Anderson (rja@sgi.com)
Signed-off-by: NTony Luck <tony.luck@intel.com>

The kernel's use of the for_each_*cpu(i) macros has allowed for sparse CPU
numbering.  When I hacked the kernel to test sparse cpu_present_map[] and
cpu_possible_map[] cpumasks, I discovered one remaining spot, in
sn_hwperf_ioctl() during sn initialization, that needs to be fixed.
Signed-off-by: NJohn Hawkes <hawkes@sgi.com>
Signed-off-by: NDean Roe <roe@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Patch to prevent sn2_ptc_init code from attempting to load on non-sn2 systems
when sn2_smp.c is built-in to generic kernel.
Signed-off-by: NPrarit Bhargava <prarit@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

core.c:263: warning: initialization makes integer from pointer without a cast
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

assabet.c:291: warning: 'scr' may be used uninitialized in this function
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Dirk Opfer

Fix an error in tosa.c after the platform device conversion.
Signed-off-by: NDirk Opfer <Dirk@Opfer-Online.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Needed to make the earlier use disabled CPUs for CPU hotplug patch
actually work.

Need to register disabled processors as well, so we can count them
towards cpu_possible_map as hot pluggable cpus.
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

bigsmp is reported to work on large Opteron systems on 32bit too.
Enable it by default there.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We were using udelay in the loop on the primary cpu waiting for the
secondary cpu to take the timebase value.  Unfortunately now that
udelay uses the timebase, and the timebase is stopped at this point,
the udelay never terminated.  This fixes it by not using udelay, and
increases the number of loops before we time out to compensate.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Patch from Daniel Jacobowitz

After delivering a signal (creating its stack frame) we must check for
additional pending unblocked signals before returning to userspace.
Otherwise signals may be delayed past the next syscall or reschedule.

Once that was fixed it became obvious that the ARM signal mask manipulation
was broken.  It was a little bit broken before the recent SA_NODEFER
changes, and then very broken after them.  We must block the requested
signals before starting the handler or the same signal can be delivered
again before the handler even gets a chance to run.
Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It's only used by arch/powerpc/kernel/ptrace{,32}.c.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This involves some minor changes: a few unused functions that the
ppc32 pci.c provides are no longer declared here or exported;
pcibios_assign_all_busses now just refers to the pci_assign_all_buses
variable on both 32-bit and 64-bit; pcibios_scan_all_fns is now
just 0 instead of a function that always returns 0 on 64-bit.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

asm-ppc64/imalloc.h is only included from files in arch/powerpc/mm.
We already have a header for mm local definitions,
arch/powerpc/mm/mmu_decl.h.  Thus, this patch moves the contents of
imalloc.h into mmu_decl.h.  The only exception are the definitions of
PHBS_IO_BASE, IMALLOC_BASE and IMALLOC_END.  Those are moved into
pgtable.h, next to similar definitions of VMALLOC_START and
VMALLOC_SIZE.

Built for multiplatform 32bit and 64bit (ARCH=powerpc).
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Trying to set the priority would just disable the interrupt due to an
incorrect mask used. We rarely use that call, in fact, I think only in
the powermac code for the cmd-power key combo that triggers xmon. So it
got unnoticed for a while.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Unfortunately, later gcc versions error out when our get_user is passed
a const pointer, since we write to a temporary variable declared as
typeof(*(p)) which propagates the const-ness.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

make defconfig will now use arch/powerpc/configs/ppc64_defconfig
if running on a ppc64 system.  I need to add an
arch/powerpc/configs/ppc_defconfig sometime.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

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

This makes 32-bit CHRP systems use the RTAS time-of-day routines if
available.  It fixes a bug in the RTAS time-of-day routines where they
were storing a 64-bit timebase value in an unsigned long by making
those variables u64.  Also, the direct-access time-of-day routines
had the wrong convention for the month and year in the struct rtc_time.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

pseries_dedicated_idle() was using __get_tb which used to be defined
in asm/delay.h.  Change it to use get_tb from asm/time.h, which is
in fact exactly the same thing.
Signed-off-by: NPaul Mackerras <paulus@samba.org>