From Dominik.

These are totally pointless as most of the development is now done either
in bitkeeper, or patches directly to mainline.

We aren't supposed to blindly copy them from another part of the same
register, but instead, only program them with values we know about.

- missing KERN_INFO's
- Use PFX.

Dominik doesn't want maintainership any more (besides him still doing
lots of great work on it. 8-)

into tetrachloride.(none):/mnt/raid/src/kernel/2.5/trees/cpufreq

Correct the notification of the cpufreq core of the new frequency being
set in ich's speedstep_set, and print accurate debug info in this function.
(both bugs noted by Valdis Kletnieks, thanks!)

Implement per-CPU memory allocation. Is a bit cleaner than the
previous "once and for all" approach.

Remove the final instances of the now-deprecated
cpufreq_driver_sem. Also, the previous "one-frequency change at one
moment" limitation is gone. If it's needed by the cpufreq driver, it
should be implemented in its cpufreq_driver->{target,setpolicy}
callback.

Use the per-CPU policy->lock to lock the per-CPU "policy" data. Also,
use it to serialize the setting of new frequency policies on each CPU.

Split up cpufreq_governor into a locking and non-locking variant.

Finally implement the two different cpufreq_driver_target callbacks --
the one called while the per-CPU lock is held, the other while
not. While we're at it, clean up cpufreq_governor.

Change the function parameter of cpufreq_cpu_put to struct
cpufreq_policy *.

Make cpufreq_set_policy a bit more readable by storing the CPU's
cpufreq_policy into a pointer.

Make cpufreq_remove_dev a bit more readable. Also, assure that the
GOV_STOP and the cpufreq_driver->exit() call are indeed the last calls
done.

Change the return value of cpufreq_cpu_get from a nondescriptent int
to struct cpufreq_policy*. This will allow for cleaner code - and
later it will be expected that anyone who grabs a reference by calling
cpufreq_cpu_get must return this struct cpufreq_policy* to
cpufreq_cpu_put.

As the per-CPU initialization can fail, we need to deal with this
situation in cpufreq_remove_dev as the sysdev core doesn't (yet) do
this for us. The solution: add a "struct cpufreq_policy
*cpufreq_cpu_data[NR_CPUS]" array, which has a NULL pointer for each
CPU not managed by cpufreq (yet) and a pointer to the per-CPU data
for each CPU managed by cpufreq. It is locked by cpufreq_driver_lock.

First part in a series of patches from Dominik which clean up the locking in
cpufreq. It sort of worked, but is full of races. But to keep it
working at least as well it works now, add a new spinlock
cpufreq_driver_lock which will be what cpufreq_driver_sem intended to
be -- but it can indeed be a spinlock instead of a semaphore. 

This driver adds proper protection for struct cpufreq_driver
*cpufreq_driver which can only go away during cpufreq_unregister --
block this by increasing the driver's module reference count.

From Dominik

Instead of trying to guess what the user intended, fail if the user
requests a setting which is not supported by the longrun driver.

From Dominik

- the path to sysfs changed
- add the cpufreq_driver.owner requirement
- clarify another paragraph

This patch includes quite a few changes and updates for the shwdt driver (which
brings it in sync with LinuxSH CVS HEAD). This fixes up support for the SH-2,
and also fixes up some timer brain-damage.

This patch updates the sh-specific hd64465 pcmcia driver for the new API, as
well as fixing up some other issues (such as remap_page_range() abuse -- we
remap through P3 area instead) which caused it not to compile. Changes by
Dominik Brodowski and myself.

Here's an update for pvr2fb (with a patch this time), which makes it compile
again.

ppc64 machines can have PCI bus numbers larger than 8 bits, but it looks
like pci_device_to_OF_node already handles this case, in both 2.4 and
2.5.

We just need the space to store them.

This solves the unresolved symbol problem with modular intermezzo.  Also
update the MAINTAINERS entry.

send_IPI_self is needed to resend irqs with IRQ_PENDING status when
enabled.

Checked with Ingo, and it's in 2.4-ac for some time.

This should fix ide lost interrupts on UP with IO-APIC

Ide trigers it this way:
 - disable_irq
 - do stuff that triggers IRQ.
 - irq is IRQ_PENDING
 - enable_irq
 - IRQ is lost, needs to be resend.

I'll send the patch to fixup IDE disable_irq logic to Bart.