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 Dominik Brodowski

Add support for _PDC to the ACPI processor "Performance States library" 
(perflib). If this field is empty, a bogus entry is passed to the _PDC
method so that the default (io) access is returned again. This patch
is partly based on David Moore's patch to
arch/i386/kernel/cpu/cpufreq/acpi.c, sent to the cpufreq mailing list on
June 24th, 2003.

and the ACPI Processor P-States driver.

from Dominik Brodowski

drivers/acpi/processor.c -- it's the same for all lowlevel drivers.

By doing so, the lowlevel drivers no longer need
to have access to struct acpi_processor.

from Dominik Brodowski

  so that it can be used by various low-level drivers
  (centrino, acpi-io, powernow-k{7,8}, ...)
  from Dominik Brodowski

  http://bugzilla.kernel.org/show_bug.cgi?id=1766

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.