into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

Fix a horribly wrong memcpy instruction in cpufreq_update_policy which
caused it to oops.

into home.osdl.org:/home/torvalds/v2.5/linux

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

- remove unnecessary usage of flags.performance
- remove double check of _PPC in acpi-cpufreq driver as it's handled in
  drivers/acpi/processor.c already
- remove unneeded EXPORT_SYMBOL
- allocation of memory only for probed CPUs
- add unregistration function to the core
- fix OOPS when PST has core_frequency values of zero
- fix cpufreq_get() output
- fix /proc/acpi/processor/*/performance write support [deprecated]

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

updates the _PPC handling. It is handled as a CPUfreq
policy notifier which adjusts the maximum CPU speed
according to the current platform limit.

from Dominik Brodowski

The acpi cpufreq driver includes a test at startup which detects whether
ACPI P-States are supported on any CPU, and whether transitions work.
However, this test is faulty: it is only run _after_ the acpi driver is
registered, causing race situations. Also, it doesn't save anything _as_ the
driver is already registered. So, it can safely be removed.

	from Dominik Brodowski

The current algorithm used by Linux ACPI for passive thermal management has
two shortcomings:

- if increasing the CPU processing power as a thermal situation goes away,
  throttling states are decreased later than performance states. This is
  not wise -- it should be the opposite ordering of going "up".

- only if the ACPI CPUfreq driver is used, performance states are used.
  A generalized approach would offer passive cooling even if the ACPI
  P-States cpufreq driver cannot be used (faulty BIOS, FixedHW access, etc.)

From: Dominik Brodowski <linux@dominikbrodowski.de>

This brown paper bag patch is needed to assure cpufreq_update_policy works
correctly.

Please apply, else the next ACPI patch will cause trouble with thermal
management [it needs cpufreq_update_policy to work properly].

Fix a horribly wrong memcpy instruction in cpufreq_update_policy which
caused it to oops.

From: Torsten Duwe <duwe@suse.de>

pmdisk.c uses struct new_utsname, so give it the header.

From: Christoph Hellwig <hch@lst.de>

Put kernel_flag back to where it used to be, near its comment and its
EXPORT_SYMBOL.

From: Andi Kleen <ak@muc.de>

Just fix two warnings on x86-64 that were recently introduced (one by me
and the other by the sort extable changes)

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

from Jes Sorensen

into home.osdl.org:/home/torvalds/v2.5/linux

  - Fix kconfig botch (bk automerge can be rather flakey)
  - The gadgetfs patches going with the kconfig cleanups

into home.osdl.org:/home/torvalds/v2.5/linux

into kroah.com:/home/greg/linux/BK/i2c-2.6

into kroah.com:/home/greg/linux/BK/usb-2.6

Here is a patch that brings the lm75 and lm78 drivers in compliance with
sysfs naming conventions. The drivers as found in existing 2.6 kernels
do not have a digit appended to the temperature-related files names as
the sysfs naming conversion recommends (obviously because they each have
a single temperature channel). As a result, libsensors won't find the
files.

It was discussed on the list wether a '1' should be appended in this
case, and our conclusion was that it would be better to do so because it
helps automatic processing of the sysfs exported files. Please apply if
you agree with this.

On Tue, 27 Jan 2004, Greg KH wrote:

> Hm, can you send me a patch to fix up snd_usb_extigy_boot_quirk() in
> sound/usb/usbaudio.c now that this patch broke that code?  :)

Here it is.  The problem with changing things in the core is always that
you may miss some of the repercussions.  In this case the patch will
restore the code's original functionality.

However the whole thing looks a bit creaky to me.  Changing device
descriptors and who knows what else without informing usbcore isn't a good
idea.  What this code _really_ appears to need is some form of
usb_device_reenumerate().  Such a function would fit very nicely into the
framework I've worked out for the revised usb_device_reset(); maybe I'll
add it in there.  It would do essentially the same thing as device_reset
except for skipping the actual port reset.

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

I accidentally left a debug printk in the sn2 timer_interrupt().

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

into home.osdl.org:/home/torvalds/v2.5/linux

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

        from ia64 via Alex Williamson