Patch from Dipankar Sarma <dipankar@in.ibm.com>

All fs should be using dcache APIs to manipulate dcache hash lists.  This is
in line with the dcache cleanup patch (dcache_rcu-1) from Maneesh that Linus
accepted.  This seems like a reasonable cleanup.  One change though, we don't
need to grab dcache_lock while deleting dentries from the private list and
__d_drop() should suffice here.

make the adaptec driver compile

Patch from Rik van Riel <riel@conectiva.com.br>

the following patch, against today's BK tree, fixes a small
SMP race in disassociate_ctty.  This function gets called
from do_exit, without the BKL held.

However, it sets the *tty variable before grabbing the bkl,
then makes decisions on what the variable was set to before
the lock was grabbed, despite the fact that another process
could modify its ->tty pointer in this same function.

Patch from Oleg Drokin <green@namesys.com>, Nikita Danilov <Nikita@Namesys.COM>

There is no uniprocessor definition of _raw_write_trylock(), so
write_trylock() doesn't work on UP.

kdev_t.value is not an int.  Code looks fishy.

printk needs kernel.h

Don't assume that dev_t is unsigned.  Cast it.

cast dev_t when printing

Don't assume that dev_t is an unsigned.  Cast it.

Make the "duplicate const" warning go away.  Arguably a compiler bug...

I have a whole bunch of silly compile warning fixes here, arising from
building the kernel for a 64-bit target.  Some are trivial, some are genuine
printk bugs.

assuming dev_t is unsigned generates a warning on ppc64.  Cast it.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

More bits from Dominik.

Most cpufreq drivers (in fact, all except one, longrun) or even most
cpu frequency scaling algorithms only offer the CPU to be set to one
frequency. In order to offer dynamic frequency scaling, the cpufreq
core must be able to tell these drivers of a "target frequency". So
these specific drivers will be transformed to offer a "->target"
call instead of the existing "->setpolicy" call. For "longrun", all
stays the same, though.

How to decide what frequency within the CPUfreq policy should be used?
That's done using "cpufreq governors". Two are already in this patch
-- they're the already existing "powersave" and "performance" which
set the frequency statically to the lowest or highest frequency,
respectively. At least two more such governors will be ready for
addition in the near future, but likely many more as there are various
different theories and models about dynamic frequency scaling
around. Using such a generic interface as cpufreq offers to scaling
governors, these can be tested extensively, and the best one can be
selected for each specific use.

Basically, it's the following flow graph:

CPU can be set to switch independetly    |         CPU can only be set
      within specific "limits"           |       to specific frequencies

                                 "CPUfreq policy"
                consists of frequency limits (policy->{min,max})
                     and CPUfreq governor to be used
                         /                    \
                        /                      \
                       /                       the cpufreq governor decides
                      /                        (dynamically or statically)
                     /                         what target_freq to set within
                    /                          the limits of policy->{min,max}
                   /                                \
                  /                                  \
        Using the ->setpolicy call,              Using the ->target call,
            the limits and the                    the frequency closest
             "policy" is set.                     to target_freq is set.
                                                  It is assured that it
                                                  is within policy->{min,max}

From Dominik Brodowski

This fixes stack handling in acpi_wakeup.S, and makes stack smaller so
that wakeup code actually fits inside memory allocated for it. Plus
someone renamed .L1432 to something meaningful.

Export allow_signal().  It's needed by lockd, sunrpc and other modules.

Andi has asked that I send these straight forward compatibility patches
to you and he will fix up any merge problems later.  These are the
outstanding patches for x86_64 against 2.5.60.

At Linux Conf AU, Willy asked me to send any further parisc compatibility
changes directly to you, so this is what I have outstanding.  Basically,
it is just the uses of compat_sigset_t that seemed to have been missed in
the previous merges.

This brings the x86-64 port uptodate in 2.5.60. Unfortunately I cannot
test too much because i constantly get deadlocks in exit/wait in initscripts
on SMP bootup. The kernel seems to still lose a lot of SIGCHLD. 2.5.59/SMP
had the same problem. Uniprocessor and SMP kernel on UP seems to work.

This patch only touches x86-64 specific files. It requires a few simple
changes to arch independent files that I will send separately.

 - Fixed a lot of obsolete/misleading configure help texts.
 - Remove old bootblock disk loader and support fdimage target for syslinux
   instead (H. Peter Anvin)
 - Fix potential fpu signal restore problem on 32bit emulation.
 - Merge with 2.5.60 i386 (hugetlbfs, acpi etc.)
 - Some fixes for local apic disabled modus.
 - Beginngs of S3 ACPI wakeup from real-mode (not working yet, don't use)
 - Beginnings of NUMA/CONFIG_DISCONTIGMEM support for AMD K8 (work in progress,
   port from 2.4): clean up memory mapping at bootup, generalize bootmem etc.
 - Fix 64bit GS base reload problem and reenable (Karsten Keil)
 - Fix race with vmalloc accesses from interrupt handlers disturbing page fault/
   similar race for the debug handler (thanks to Andrew Morton)
 - Merge cpu access primitives with i386
 - Revert to private module list for now because putting modules
   nto vmlist triggered too many problems.
 - Some cleanups, removal of unneeded code.
 - Let early __get_free_pages see consistent pda
 - Preempt disabled for now because it is too broken right now
 - Signal handler fixes
 - Fix do_gettimeofday to be completely lockless and reenable vsyscalls
 - Optimize context switch path a bit (should be ported to i386)
 - Get thread_info via stack for better code
 - Don't leak pmd pages
 - Clean up hardcoded task stack sizes.

Since daemonize now blocks all signals, this simplification is trivially
correct.

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into tp1.ruhr-uni-bochum.de:/scratch/kai/kernel/v2.5/linux-2.5.make

nfs must not use MINORBITS - that fails with 32-bit dev_t

into kernel.bkbits.net:/home/davem/net-2.5

into kernel.bkbits.net:/home/davem/sparc-2.5

From Chris Wedgwood:

> fixdep doesn't close files when finished with them... normally this
> doesn't matter unless you have strict ulimits in place.
>
> Trivial fix is:

Not that it makes any difference on x86, but there may be
architectures that actually need it.

Add a name argument to daemonize() (va_arg) to avoid all the
kernel threads having to duplicate the name setting over and
over again.

Make daemonize() disable all signals by default, and add a
"allow_signal()" function to let daemons say they explicitly
want to support a signal.

Make flush_signal() take the signal lock, so that callers do
not need to.

Patch from Roland McGrath.

This patch replaces the assumption that > PAGE_OFFSET == kernel address
with testing for user_mode(regs) and inserting switch codes instead.

This patch allows the oprofilefs files to take entry in any base
instead of just base 10

This patch updates the horrible enum for the logical CPU type with a
string instead.

The below patch implements a P4 driver for OProfile, mostly written
by Graydon Hoare.

into home.transmeta.com:/home/torvalds/v2.5/linux

Done by Adam Belay.