Modified existing dprintks, and removed the driver-only debug module
parameter.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Modified existing dprintks.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

and add some dprintks which might be / have been of interest.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Modified existing dprintks and added a few which might be / have been
of interest.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Modified existing dprintks and added a few which might be / have
been of interest, and cleared some whitespace/tab confusion. The big
comment regarding which frequency to pass as "old" value wasn't up to
date any longer in two regards: the driver's behaviour had changed, and
the core is know able to handle such things... anyways, the comment could
be removed.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Modified existing dprintks and added a few which might be / have been
of interest.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Modified existing dprintks and added a few which might be / have been
of interest.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Modified existing dprintks and added a few which might be / have been
of interest.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

cpufreq_debug_printk will print messages if

a) debugging for the specified part is activated (add
        1 for core,
        2 for drivers,
        4 for governors
   and pass value as
        cpufreq.debug=<value>
   on the kernel command line).

b) and either
        b1) printk_ratelimit() allows it to be printed,
        b2) the user disables ratelimit'ing by passing
                cpufreq.debug_ratelimit=0
            on the kernel command line, _or_
        b3) during driver initialization [unless a different
            driver has been initialized successfully] and
            unloading, and whenever a new policy is set.

            The last point may cause for numerous messages
            if an userspace-based dynamic governor is used
            which mis-uses the policy interface to set specific
            frequencies. Oh, the ACPI processor.c interface
            to the file "performance" uses the same trick,
            but that interface is marked deprecated as well,
            so I don't care. And debugging isn't activated
            normally, you know...
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Clarify that cpufreq_set() and cpufreq_setmax() are parts of the 2.4. API
to the userspace governor which will be removed soon after 2005-01-01.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

The "acpi" cpufreq driver uses the far too generic module name "acpi".
Fix it by renaming it to "cpufreq-acpi". A MODULE_ALIAS("acpi"); will
allow for backwards-compatible naming until 2005-06-30.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

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

Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

 
Some BIOSes export invalid _PSS entries where all bits are set to one. While
this is totally contrary to the ACPI specification, BIOS vendors try to
tell userspace that these entries should not be considered or used. In order
to not fail on such entries, the speedstep-centrino already contains a
method to ignore these things. However, due to a wrong ordering of checks
the driver aborts nonetheless. So move some checks around.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Sometimes, a user or userspace daemon wants a specific frequency is set,
but that frequency is (temporarily) unavailable or becomes unavailable
due to e.g. thermal considerations. As soon as this situation changes,
the user wish should be re-evaluated. The attached patch saves the user
wish in "cpu_set_freq", and re-uses that whenever appropriate.

Thanks to Thomas Renninger for testing.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

We decided to do this a different way.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

In general it is not safe to do any non-ptrace wakeup of a thread in
TASK_TRACED, because the waking thread could race with a ptrace call
that could be doing things like mucking directly with its kernel stack. 

AFAIK noone has established that whatever clobberation ptrace can do to
a running thread is safe even if it will never return to user mode, so
we can't allow this even for SIGKILL.

What we _can_ safely do is make a thread switching out of TASK_TRACED
resume rather than sitting in TASK_STOPPED if it has a pending SIGKILL
or SIGCONT.  The following patch does this.

This should be sufficient for the shutdown case.  When killing all
processes, if the tracer gets killed first, the tracee goes into
TASK_STOPPED and will be woken and killed by the SIGKILL (same as
before).  If the tracee gets killed first, it gets a pending SIGKILL and
doesn't wake up immediately--but, now, when the tracer gets killed, the
tracee will then wake up to die. 

This will also fix the (same) situations that can arise now where you
have used gdb (or whatever ptrace caller), killed -9 the gdb and the
process being debugged, but still have to kill -CONT the process before
it goes away (now it should just go away either the first time or when
you kill gdb). 
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This is a batch of sparse fixes for things in arch/ppc64/* and
include/asm-ppc64/*

More to come of course...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

My latest 8250 patch prevented registration of "empty" ports (ports that
have a 0 iobase in the static table). Unfortunately, some archs seem to rely
on this, and so broke. This patch reverts that part of the patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This adds support for the Maple 970FX Eval Board.  It adds the basic
arch support.  For the Maple to be fully functional, it needs a couple
more patches to be applied for IDE and Ethernet that are currently
pending with the respective maintainers of those subsystems.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The iommu_free_table() patch broke g5 only build by adding back some
incestuous relationship between generic code and pSeries code. 

This wraps this in #ifdef as a quick fix until the original author of
the patch comes up with a better solution.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

On machines using the "ISU" mecanism for the MPIC, the new driver didn't properly
calculate the new interrupt count when an ISU was added. That would cause later on
failure to request interrupts in the offending range.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The ppc64 PCI code, when parsing the OF tree, may end up getting empty
regions in addition to the "normal" ones for the PHB (some pSeries OF
device-tree contains weird "ranges" properties). These are harmless but
do trigger some annoying warnings during boot, so let's ignore them.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

CONFIG_NET_HW_FLOWCONTROL is entirely unused now, and superceded by NAPI in
practice, so remove the dead code
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

into pobox.com:/garz/repo/net-drivers-2.6

into pobox.com:/garz/repo/net-drivers-2.6

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

into pobox.com:/garz/repo/netdev-2.6/e1000-2

Fix for updated pci_{save,restore}_state()
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

into pobox.com:/garz/repo/netdev-2.6/misc

into nuts.davemloft.net:/disk1/BK/net-2.6

into nuts.davemloft.net:/disk1/BK/net-2.6