From: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Dave Jones <davej@redhat.com>

From: Pavel Machek <pavel@ucw.cz>
- Add missing newlines
- 80-column goodness.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>

this is patch to fix obvious typo of gx-suspmod cpufreq driver.
Signed-off-by: Hiroshi Miura <miura@da-cha.org>
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dave Jones <davej@redhat.com>

From: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dave Jones <davej@redhat.com>

The /proc/sys/cpu/ interface was deprecated already when cpufreq was merged
into the kernel. With 2.7. not appearing soon, let's do the same what's
suggested for devfs and others: inform users of it being deprecated
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

The /proc/cpufreq interface was deprecated already when cpufreq was merged
into the kernel. With 2.7. not appearing soon, let's do the same what's
suggested for devfs and others: inform users of it being deprecated.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Avoid re-enabling the interrupts in "write_sequnlock_irq" in
cpufreq_timer_notifier() when it gets called in "CPUFREQ_RESUMECHANGE" state
-- that happens if the CPU frequency is detected to be different now from
what it was during suspension, and that's a resume call of a sys device, so
with interrupts off.

Without this patch, it can cause nasty oopses. IIRC resume is done on one
CPU only, so we don't need no lock anyways. Right?

Many thanks to Brian J. Murrell for debugging this issue.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Propagate the new CONFIG_X86_POWERNOW_K8_ACPI to powernow-k8.h to avoid
compile breakage. Fixes bug 3180.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

here's a patch on top of the above patch that adds all of the
dothan frequency/voltages for processors 715, 725, 735, 745, 755

Tested and working as it should so far with a 745. The stepping in the
model table for the others may need to be tweaked.

The Dothan processor datasheet 30218903.pdf defines 4 voltages for
each frequency (VID#A through VID#D) whereas Banias only suggests a
typical voltage and no min or max for each freq so i've used the OP
macro to allow definition of all voltages (A through D) but the macro
currently just uses VID#C at compile time (the second lowest voltage
profile).

The docs define these 4 profiles but don't say anywhere in which cases
they should be used. I guess it may be a case of usage of the differing
profiles based on the tolerance and accuracy of the power supply in use
for the specific application.

From: Michael Clark
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dave Jones <davej@redhat.com>

Do away with the prototype by just moving some code around.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dave Jones <davej@redhat.com>

At present, MSR based Enhanced Speedstep Technology (EST) is handled by
speedstep-centrino.c. The attached patch adds more features to
speedstep-centrino, making it more generic. With these changes, it can
run on SMP systems which supports EST, based on the information provided
by ACPI. The non-ACPI (static table based) driver will still be UP only.

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>

Compile fix for speedstep-ich.c: missing forward declaration.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Bugfix for #3012 @ http://bugme.osdl.org/show_bug.cgi?id=3012

The speedstep-ich driver only registers for CPU0 (which is a sane thing to
do). However, cpufreq_notify_transition() currently assumes the CPU
specified in the freqs.cpu parameter has actually been registered with the
CPUfreq core. This is obviously not the case for HT speedstep-ich CPUs,
causing an OOPS. The long-term solution will be to merge the "cpufreq
CPU group awareness patches" already RFC'ed to this list; but they still
need a bit of polishing and testing.

Thanks to Boris Fersing for reporting the bug and testing this fix.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

This is only used on Intel, and if some other vendor ever clones speedstep,
we can add an additional check in the init routine.
Signed-off-by: Dave Jones <davej@redhat.com>

- Only Intel makes EST CPUs.  (Some Cyrix M IIs have the EST bit set -
  I don't know what it means, but it isn't Enhanced Speedstep.)

- If it's a known Dothan, but we're looking in the tables, give a
   useful message about using ACPI rather than mailing me.

- Code cleanups:
  - Make the CPU ID stuff table driven
  - Turn centrino_verify_cpu_id into a proper boolean predicate

 - Diddle some whitespace
Signed-off-by: Dave Jones <davej@redhat.com>

i have noticed that the most recent vanilla kernel oopses on a P4M-HT
(because only one CPU is registered in sysfs but 2 are informed of a
change of state). also there are some returns out of subroutines before
set_cpus_allowed() is performed to restore the mask prior to entering
the subroutine (this should not matter on uniprocessor systems, but
still...).
                                                                               
this patch should fix these 2 issues. for the first one, it registers
all logical cpu's and a tiny modification is made in cpufreq.c to
perform a policy change on all siblings.

From: Christian Hoelbling
Signed-off-by: Dave Jones <davej@redhat.com>

Some ACPI tables contain 0xffff'ed entries for "P-States". This is
obviously incorrect according to the ACPI specifications, nonetheless
it should "just work". So, simply ignore such invalid P-States instead
of aborting. Thanks to Frederik Reiss for testing (and fixing) this
patch.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

On at least one system, the GET_SPEEDSTEP_FREQS call to the BIOS
returns obviously incorrect data (0 and 4 MHz...). So, check whether
the results look sane, if not, use the already existing workaround
for ancient speedstep systems. Thanks to Pierre Maziere for reporting
this issue and testing the fix.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>

There is a lonstanding off-by-one error that results from an incorrect
comparison when checking whether a process has consumed CPU time in
excess of its RLIMIT_CPU limits. 

This means, for example, that if we use setrlimit() to set the soft CPU 
limit (rlim_cur) to 5 seconds and the hard limit (rlim_max) to 10 seconds, 
then the process only receives a SIGXCPU signal after consuming 6 seconds
of CPU time, and, if it continues consuming CPU after handling that
signal, only receives SIGKILL after consuming 11 seconds of CPU time.

The fix is trivial.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Author: Armin Schindler, Nishanth Aravamudan

Use kernel provided msleep() instead of own sleep
implementation.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

There's a stupid error in the fall back logic, it fails to increment the
user pointer so the wave file is corrupt. We should also clear
last_sense just to be sure.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Here are some oops I found in error paths in the mounting pathes while
debugging something else...  I sent it out a while ago, but it didn't seem
to get any traction....

The nfs_fill_super() fix is obvious and in nfs4_fill_super(), the
server->client ptr needs to be set before the cl_idmap check, since
rpc_shutdown_client() needs it when the check fails.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Remove the unused symbol_is() macro.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Below is a patch by Hans Ulrich Niedermann
<linux-kernel@n-dimensional.de> to change all references in comments to 
files in Documentation/ to start with Documentation/
Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This file does not exist in 2.6.
Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch
	- adds copyright and license info
	- changes sense of mmap config option (setting option enables mmap
	  instead of disabling it, to avoid the double negative)
	- removes an #ifdef CONFIG_IA64 now that acpi_register_gsi()
	  is generic.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Sync nmi_watchdog.txt with reality on x86-64.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Actually, the problem has its origin in my removal of all in-kernel
syscalls (except execve, which is non-trivial) earlier this year.  This
change was blindly reverted by the maintainer, while at the same time the
local errno variable was removed.  See also
http://linux.bkbits.net:8080/linux-2.5/hist/drivers/media/dvb/frontends/tda=
1004x.c

This patch is the one that was already merged earlier.  I'm now also
removing the definitions for the kernel syscalls on i386 to make it harder
to reintroduce them again.  This was already done for ppc64, the others
should probably follow.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Tom is looking after PPC8xx and the PPC boot code.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ACKed by the pmac folks a while ago.  Also moves the Kconfig entry to where
it belongs.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Revert the recent fdomain_cs config dependency "fix" and fix the linkage
error with ifdeffery instead.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Maciej has moved.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The "vector" terminology is architecture-dependent.  The PCI MSI interface
actually deals with Linux IRQ numbers (i.e., things you can pass to
request_irq()), and we shouldn't confuse things by calling them "vectors" just
because we're using MSI rather than an IOSAPIC.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>