ACPI and power management fixes for 3.11-rc5

- ACPI-based memory hotplug stopped working after a recent change,
  because it's not possible to associate sufficiently many "physical"
  devices with one ACPI device object due to an artificial limit.
  Fix from Rafael J Wysocki removes that limit and makes memory
  hotplug work again.

- A change made in 3.9 uncovered a bug in the ACPI processor driver
  preventing NUMA nodes from being put offline due to an ordering
  issue.  Fix from Yasuaki Ishimatsu changes the ordering to make
  things work again.

- One of the recent ACPI video commits (that hasn't been reverted
  so far) uncovered a bug in the code handling quirky BIOSes that
  caused some Asus machines to boot with backlight completely off
  which made it quite difficult to use them afterward.  Fix from
  Felipe Contreras improves the quirk to cover this particular
  case correctly.

- A cpufreq user space interface change made in 3.10 inadvertently
  renamed the ignore_nice_load sysfs attribute to ignore_nice which
  resulted in some confusion.  Fix from Viresh Kumar changes the name
  back to ignore_nice_load.

- An initialization ordering change made in 3.9 broke cpufreq on
  loongson2 boards.  Fix from Aaro Koskinen restores the correct
  initialization ordering there.

- Fix breakage resulting from a mistake made in 3.9 and causing the
  detection of some graphics adapters (that were detected correctly
  before) to fail.  There are two objects representing the same PCIe
  port in the affected systems' ACPI tables and both appear as
  "enabled" and we are expected to guess which one to use.  We used
  to choose the right one before by pure luck, but when we tried to
  address another similar corner case, the luck went away.  This time
  we try to make our guessing a bit more educated which is reported
  to work on those systems.

- The /proc/acpi/wakeup interface code is missing some locking
  which may lead to breakage if that file is written or read during
  hotplug of wakeup devices.  That should be rare but still possible,
  so it's better to start using the appropriate locking there.

/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAABAgAGBQJSBQJtAAoJEKhOf7ml8uNs9FQP/1dhuih2SxwGG07//58AdQg8
lIktdutgAxO8NvhYwP8SWH+SasBywkn2I6LSK2Ys8UMfUrfCMI/8jK1JMRmj+IfN
tcd/13CdxV/sFDnnoQf1N/FCoskn8nNfbSw030lR3vHcBSc6CpqGHnQc8A78FNuC
HohtV4xhHU3SCHOOiCP0HeVC3F3JMAlfRMbm/du1U9lrRpKXvU65J0JGvVG/9jn/
HNd3OVvvJ7l7kbNy7D99MO2QbX8O21qgKnd26Rk2gdERygSdrrBG4uCL1TMH1+Kn
Q4tKvUR6Ja/b7f8lyWjPApjhCsGYmzeYfSJtEFZunZwcHShmgliiofD1E3lLhnY+
ZhUTgaalIETdcZy2GhzX42hi9YfqGUSeLccvqBEAC2eWCHhvKGw6A7kyBf6F9Sre
eQpnnmOeKMNFwqEniYEcABWoG+XEtKWzxgIn9sX2aW/qkWLa/8i6PYOWe6Aze1Mr
8DduFy6HuU9LSALdlPKhl8zlD1y3vY5UDNFN3X2Vpzx33NYv5Ft2aykFSxWpzgb9
hVzWaYLS25SrxPncTgJZL8eR+/u7eY2B/OMczpfP+PmTztyCSTdPa0t6zn5xr5vq
vLgfCh9lPXEaMz85Jlw5PZ+ZBAQ5PfjmIVB7ac0yM/G/J9N+h7q/J/BzbQEJDQI0
qovn9XAIW6wpG9MiMJs3
=0u8M
-----END PGP SIGNATURE-----