kernel/git/stable/linux.git/drivers/acpi, branch linux-2.6.31.y

ACPI: Be in TS_POLLING state during mwait based C-state entry

2010-04-01T22:55:53+00:00

commit d306ebc28649b89877a22158fe0076f06cc46f60 upstream. ACPI deep C-state entry had a long standing bug/missing feature, wherein we were sending resched IPIs when an idle CPU is in mwait based deep C-state. Only mwait based C1 was using the write to the monitored address to wake up mwait'ing CPU. This patch changes the code to retain TS_POLLING bit if we are entering an mwait based deep C-state. The patch has been verified to reduce the number of resched IPIs in general and also improves the performance/power on workloads with low system utilization (i.e., when mwait based deep C-states are being used). Fixes "netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f" http://marc.info/?l=linux-kernel&m=126441481427331&w=4 Reported-by: Lin Ming Tested-by: Alex Shi Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: DMI init_set_sci_en_on_resume for HP-Compaq C700

2010-01-18T18:28:54+00:00

commit 87c687be055e67bc04189ce476690be73d16063e upstream. ...else ACPI thermal controls fail after resume. http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown Cc: Stefan Bader Signed-off-by: Greg Kroah-Hartman

ACPI: sleep: another HP/Compaq DMI entries for init_set_sci_en_on_resume

2010-01-18T18:28:54+00:00

commit 2839d396e3ae0891c1fdd87aa1cea218e6f5c4df upstream. http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown Cc: Stefan Bader Signed-off-by: Greg Kroah-Hartman

ACPI: add DMI entry for SCI_EN resume quirk on HP dv4

2010-01-18T18:28:53+00:00

commit 8a1cbf64977f89e9e9bc1d80dd01503337424f96 upstream. Fixes the missing battery on sleep problem for yet another HP laptop ("HP Pavilion dv4"). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13449 Signed-off-by: Gustavo Maciel Dias Vieira Signed-off-by: Len Brown Cc: Stefan Bader Signed-off-by: Greg Kroah-Hartman

ACPI: sleep: another HP DMI entry for init_set_sci_en_on_resume

2010-01-18T18:28:53+00:00

commit eb0ca849863ecdc593ba7faa95fda5695af891c8 upstream. DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dv3 Notebook PC") http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown Cc: Stefan Bader Signed-off-by: Greg Kroah-Hartman

Revert "ACPI: Attach the ACPI device to the ACPI handle as early as possible"

2009-11-10T00:22:49+00:00

commit f61f925859c57f6175082aeeee17743c68558a6e upstream. This reverts commit eab4b645769fa2f8703f5a3cb0cc4ac090d347af. http://bugzilla.kernel.org/show_bug.cgi?id=13002 Signed-off-by: Len Brown Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2)

2009-11-10T00:22:48+00:00

commit 497fb54f578efd2b479727bc88d5ef942c0a1e2d upstream. acpi_get_pci_dev() may be called for a non-PCI device, in which case it should return NULL. However, it assumes that every handle it finds in the ACPI CA name space, between given device handle and the PCI root bridge handle, corresponds to a PCI-to-PCI bridge with an existing secondary bus. For this reason, when it finds a struct pci_dev object corresponding to one of them, it doesn't check if its 'subordinate' field is a valid pointer. This obviously leads to a NULL pointer dereference if acpi_get_pci_dev() is called for a non-PCI device with a PCI parent which is not a bridge. To fix this issue make acpi_get_pci_dev() check if pdev->subordinate is not NULL for every device it finds on the path between the root bridge and the device it's supposed to get to and return NULL if the "target" device cannot be found. http://bugzilla.kernel.org/show_bug.cgi?id=14129 (worked in 2.6.30, regression in 2.6.31) Signed-off-by: Rafael J. Wysocki Reported-by: Danny Feng Reviewed-by: Alex Chiang Tested-by: chepioq Signed-off-by: Len Brown Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

ACPI: Clarify resource conflict message

2009-10-12T19:40:22+00:00

commit 14f03343ad1080c2fea29ab2c13f05b976c4584e upstream. The message "ACPI: Device needs an ACPI driver" is misleading. The device _may_ need an ACPI driver, if the BIOS implemented a custom API for the device in question (which, AFAIK, can't be checked.) If not, then either a generic ACPI driver may be used (for example "thermal"), or nothing can be done (other than a white list). I propose to reword the message to: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver which I think is more correct. Comments and suggestions welcome. I also added a message warning about possible problems and system instability when users pass acpi_enforce_resources=lax, as suggested by Len. Signed-off-by: Jean Delvare Cc: Thomas Renninger Cc: Alan Jenkins Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: pci_slot.ko wants a 64-bit _SUN

2009-10-05T16:31:35+00:00

commit 7e24bc1ce669b2876ffa475ea1147f2bb9ffdc52 upstream. Similar to commit b6adc195 (PCI hotplug: acpiphp wants a 64-bit _SUN), pci_slot.ko reads and creates sysfs directories based on the _SUN method. Certain HP platforms return 64 bits in _SUN. This change to pci_slot.ko allows us to see the correct sysfs directories. Reported-by: Chad Smith Signed-off-by: Alex Chiang Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: don't free non-existent backlight in acpi video module

2009-08-28T19:17:07+00:00

acpi_video_put_one_device was attempting to remove sysfs entries and unregister a backlight device without first checking that said backlight device structure had been created. Signed-off-by: Keith Packard Acked-by: Zhang Rui Signed-off-by: Andrew Morton Signed-off-by: Len Brown