Update Acorn SCSI drivers for the recent SCSI device ID/Lun changes.

Prevent a corrupted kernel stack causing an infinite dumping of
backtrace.

into flint.arm.linux.org.uk:/usr/src/linux-bk-2.5/linux-2.5-rmk

Patch from Deepak Saxena

jiffies is defined as pointing to jiffies_64 for backwards comptability (I think, not 100% sure why we don't just use jiffies_64 everywhere?). On BE systems, we need to point to the upper 4 bytes of jiffies_64 or we will never get past calibrate_delay. This is what is done in PPC, SH, and other big endian architectures.

My printf manpage says:

       z      A  following  integer  conversion  corresponds to a
              size_t or ssize_t argument. (Linux libc5 has Z with
              this meaning. Don't use it.)

And the opengroup spec says

z Specifies that a following d , i , o , u , x , or X conversion specifier
  applies to a size_t or the corresponding signed integer type argument; or
  that a following n conversion specifier applies to a pointer to a signed
  integer type corresponding to a size_t argument.


yet our vsnprintf implementation has

				/* 'z' support added 23/7/1999 S.H.    */
				/* 'z' changed to 'Z' --davidm 1/25/99 */


I guess the path of least surprise is to support both.  gcc-3.2.1 doesn't
  seem to care.

The return type of sizeof() is size_t.  On many architectrues size_t is
unsigned long, and may not be printed with %d.  Use %Zu instead.

Need to reenable interrupts around the call to scsi_register(), which blocks.

An anonymous fixed mmap with CONFIG_HUGETLB_PAGE=y will dereference NULL.  We
recur into the pagefault handler with mmap_sem held and lock up.

Patch from Davide Libenzi <davidel@xmailserver.org>

Changes :
 - Timeout overflow check
 - Ceil()ing of ms->jif conversion
 - Syscalls return type int->long

Patch from: Peter Waechtler <pwaechtler@mac.com>

Addresses BUGME bug #331.  "OSS CS4232 nasty spinlock printks on boot"

The locking in some OSS modules is really lousy.
Because save_flags/cli/restore_flags could be used recursivly - the
programmers pushed the locking too far the lower level.

Because on ISA cards the register sets are usually multiplexed
you had to write to an address latch and then access the data port
in an "atomic" manner.

I suggest removing the locking from ad_read/ad_write +
ad_{enter|leave}_MCE and clamping the locks wherever the functions
are called. I hope the attached patch does that correctly.

Yes, I don't like all the timeout loops while holding the locks:
high chances that a cpu is spinning in interrupt context :(

Patch from: David Mosberger <davidm@napali.hpl.hp.com>

Please remember to declare the return-type of syscall stubs as "long".
On 64-bit platforms, it's generally necessary to ensure that the
entire 64-bit return value is valid (and can be checked against
negative values).

Patch from: Frank Davis <fdavis@si.rr.com>

The following addresses bugzilla bug # 340.

Patch from: Frank Davis <fdavis@si.rr.com>

The following patch addresses bugzilla bug # 341.

Patch from: john stultz <johnstul@us.ibm.com>

This patch simply fixes the summit subarch to allow summit kernels to
boot on normal systems.

Someone typed `config' when they meant `conf'.

Also fix a function-defined-but-not-used warning.

This driver is calling down into scsi_register with local interrupts
disabled.  scsi_register performs blocking allocations, starts kernel
threads, etc.  slab debugging gets offended by someone performing blocking
operations with local interrupts disabled.

Patch from Tim Schmielau <tim@physik3.uni-rostock.de>

Converts many open-coded jiffy comparisons to use time_after/before/etc.

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.

There are edge triggered interrupt controllers around where the
"enable" control is before the edge detection.  This means that
we must keep the interrupts enabled, even when disable_irq() is
in effect, and mark such interrupts for later processing.

To make matters worse, some of these interrupt controllers do not
provide any method to re-trigger the interrupt.  We are unable
to call the handler direct from enable_irq() since we may be
in an IRQ-protected context.

Therefore, we add such interrupts to a list of pending interrupts,
which we process at the next hardware interrupt.

into flint.arm.linux.org.uk:/usr/src/linux-bk-2.5/linux-2.5-rmk

Patch from Dirk Behme

Fix two typos (CR instead of CD) and add a macro for reading the configuration register of coprocessor 15.