From af1d486c18bad7820b0ca52b413458914231102c Mon Sep 17 00:00:00 2001 From: "lan,Tianyu" Date: Tue, 28 May 2013 02:25:33 +0000 Subject: [PATCH 1/6] x86 / platform / hp_wmi: Fix bluetooth_rfkill misuse in hp_wmi_rfkill_setup() HP wmi platform driver fails to initialize GPS and causes poweroff failure in HP Elitebook 6930p. Call Trace: [] hp_wmi_bios_setup+0x25a/0x3a0 [hp_wmi] [] platform_drv_probe+0x3c/0x70 [] ? driver_sysfs_add+0x7a/0xb0 [] driver_probe_device+0x87/0x3a0 [] __driver_attach+0x93/0xa0 [] ? __device_attach+0x40/0x40 [] bus_for_each_dev+0x63/0xa0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1f8/0x2b0 [] driver_register+0x71/0x150 [] platform_driver_register+0x46/0x50 [] platform_driver_probe+0x1b/0xa0 [] hp_wmi_init+0x1be/0x1fb [hp_wmi] [] ? hp_wmi_bios_setup+0x3a0/0x3a0 [hp_wmi] [] do_one_initcall+0x10a/0x160 [] load_module+0x1b46/0x2640 [] ? ddebug_proc_write+0xf0/0xf0 [] sys_init_module+0xa2/0xf0 [] system_call_fastpath+0x1a/0x1f Code: 48 ff ff ff 80 7b 24 00 74 d2 41 83 e5 01 45 38 ec 74 c9 48 8d bb a0 03 00 00 e8 ed fb aa e0 5b 41 5c 41 5d 44 89 f0 41 5e 5d c3 <0f> 0b 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 RIP [] rfkill_set_hw_state+0x9f/0xb0 [rfkill] RSP Check code and find this error is caused by misusing variable bluetooth_rfkill where gps_rfkill should be. Reported-and-tested-by: Iru Cai References: https://bugzilla.kernel.org/show_bug.cgi?id=58401 Cc: All Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki --- drivers/platform/x86/hp-wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c index 8df0c5a21be2..d111c8687f9b 100644 --- a/drivers/platform/x86/hp-wmi.c +++ b/drivers/platform/x86/hp-wmi.c @@ -703,7 +703,7 @@ static int hp_wmi_rfkill_setup(struct platform_device *device) } rfkill_init_sw_state(gps_rfkill, hp_wmi_get_sw_state(HPWMI_GPS)); - rfkill_set_hw_state(bluetooth_rfkill, + rfkill_set_hw_state(gps_rfkill, hp_wmi_get_hw_state(HPWMI_GPS)); err = rfkill_register(gps_rfkill); if (err) From fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c Mon Sep 17 00:00:00 2001 From: Alex Hung Date: Tue, 28 May 2013 02:05:09 +0000 Subject: [PATCH 2/6] ACPI / video: ignore BIOS initial backlight value for HP m4 On HP m4 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References: https://bugs.launchpad.net/bugs/1184501 Cc: All Signed-off-by: Alex Hung Signed-off-by: Rafael J. Wysocki --- drivers/acpi/video.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 5b32e15a65ce..d0937ab3fb6d 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -464,6 +464,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "HP 1000 Notebook PC"), }, }, + { + .callback = video_ignore_initial_backlight, + .ident = "HP Pavilion m4", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion m4 Notebook PC"), + }, + }, {} }; From 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 Mon Sep 17 00:00:00 2001 From: Ash Willis Date: Wed, 29 May 2013 01:27:59 +0000 Subject: [PATCH 3/6] ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6 This patch addresses kernel bug 56661. BIOS reports an incorrect backlight value, causing the driver to switch off the backlight completely during startup. This patch ignores the incorrect value from BIOS. References: https://bugzilla.kernel.org/show_bug.cgi?id=56661 Signed-off-by: Ash Willis Cc: All Signed-off-by: Rafael J. Wysocki --- drivers/acpi/video.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index d0937ab3fb6d..5d7075d25700 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -456,6 +456,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dm4 Notebook PC"), }, }, + { + .callback = video_ignore_initial_backlight, + .ident = "HP Pavilion g6 Notebook PC", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion g6 Notebook PC"), + }, + }, { .callback = video_ignore_initial_backlight, .ident = "HP 1000 Notebook PC", From a98d4f64a20b2b88697e7e08c871144a7e3f0ec4 Mon Sep 17 00:00:00 2001 From: Wei Yongjun Date: Mon, 3 Jun 2013 02:08:39 +0000 Subject: [PATCH 4/6] ACPI / APEI: fix error return code in ghes_probe() Fix to return a negative error code in the acpi_gsi_to_irq() and request_irq() error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun Reviewed-by: Huang Ying Signed-off-by: Rafael J. Wysocki --- drivers/acpi/apei/ghes.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index d668a8ae602b..ea750ed7c264 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -917,13 +917,14 @@ static int ghes_probe(struct platform_device *ghes_dev) break; case ACPI_HEST_NOTIFY_EXTERNAL: /* External interrupt vector is GSI */ - if (acpi_gsi_to_irq(generic->notify.vector, &ghes->irq)) { + rc = acpi_gsi_to_irq(generic->notify.vector, &ghes->irq); + if (rc) { pr_err(GHES_PFX "Failed to map GSI to IRQ for generic hardware error source: %d\n", generic->header.source_id); goto err_edac_unreg; } - if (request_irq(ghes->irq, ghes_irq_func, - 0, "GHES IRQ", ghes)) { + rc = request_irq(ghes->irq, ghes_irq_func, 0, "GHES IRQ", ghes); + if (rc) { pr_err(GHES_PFX "Failed to register IRQ for generic hardware error source: %d\n", generic->header.source_id); goto err_edac_unreg; From 9f29ab11ddbfc12db54df5a66dab22b39ad94e8e Mon Sep 17 00:00:00 2001 From: Aaron Lu Date: Tue, 4 Jun 2013 23:02:58 +0200 Subject: [PATCH 5/6] ACPI / scan: do not match drivers against objects having scan handlers With the introduction of ACPI scan handlers, an ACPI device object with an ACPI scan handler attached to it must not be bound to an ACPI driver any more. Therefore it doesn't make sense to match those ACPI device objects against a newly registered ACPI driver in acpi_bus_match(), so make that function return 0 if the device object passed to it has an ACPI scan handler attached. This also addresses a regression related to a broken ACPI table in the BIOS, where it has defined a _ROM method under the PCI root bridge object. This causes the video module to treat that object as a display controller device (since only display devices are supposed to have a _ROM method defined according to the ACPI spec). As a result, the ACPI video driver binds to the PCI root bridge object and overwrites the previously assigned driver_data field of it, causing subsequent calls to acpi_get_pci_dev() to fail. [rjw: Subject and changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Reported-by: Jason Cassell Reported-and-bisected-by: Dmitry S. Demin Cc: 3.9+ Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki --- drivers/acpi/scan.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 44225cb15f3a..90c5759e1355 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -740,6 +740,10 @@ static int acpi_bus_match(struct device *dev, struct device_driver *drv) struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = to_acpi_driver(drv); + /* Skip ACPI device objects with scan handlers attached. */ + if (acpi_dev->handler) + return 0; + return acpi_dev->flags.match_driver && !acpi_match_device_ids(acpi_dev, acpi_drv->ids); } From 7cd8407d53ef5fb0280fcbe34f42311472f90feb Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 5 Jun 2013 14:01:19 +0200 Subject: [PATCH 6/6] ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization Commit b378549 (ACPI / PM: Do not power manage devices in unknown initial states) added code to force devices without _PSC, but having _PS0 defined in the ACPI namespace, into ACPI power state D0 by executing _PS0 for them. That turned out to break Toshiba P870-303, however, so revert that code. References: https://bugzilla.kernel.org/show_bug.cgi?id=58201 Reported-and-tested-by: Jerome Cantenot Tracked-down-by: Lan Tianyu Cc: 3.9+ Signed-off-by: Rafael J. Wysocki --- drivers/acpi/device_pm.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index bc493aa3af19..318fa32a141e 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -278,11 +278,13 @@ int acpi_bus_init_power(struct acpi_device *device) if (result) return result; } else if (state == ACPI_STATE_UNKNOWN) { - /* No power resources and missing _PSC? Try to force D0. */ + /* + * No power resources and missing _PSC? Cross fingers and make + * it D0 in hope that this is what the BIOS put the device into. + * [We tried to force D0 here by executing _PS0, but that broke + * Toshiba P870-303 in a nasty way.] + */ state = ACPI_STATE_D0; - result = acpi_dev_pm_explicit_set(device, state); - if (result) - return result; } device->power.state = state; return 0;