From af1d486c18bad7820b0ca52b413458914231102c Mon Sep 17 00:00:00 2001 From: "lan,Tianyu" Date: Tue, 28 May 2013 02:25:33 +0000 Subject: [PATCH 1/9] 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/9] 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/9] 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 8673b83bf2f013379453b4779047bf3c6ae387e4 Mon Sep 17 00:00:00 2001 From: Ross Lagerwall Date: Fri, 31 May 2013 20:45:17 +0100 Subject: [PATCH 4/9] acpi-cpufreq: set current frequency based on target P-State Commit 4b31e774 (Always set P-state on initialization) fixed bug #4634 and caused the driver to always set the target P-State at least once since the initial P-State may not be the desired one. Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur) caused a regression in this behavior. This fixes the regression by setting policy->cur based on the CPU's target frequency rather than the CPU's current reported frequency (which may be different). This means that the P-State will be set initially if the CPU's target frequency is different from the governor's target frequency. This fixes an issue where setting the default governor to performance wouldn't correctly enable turbo mode on all cores. Signed-off-by: Ross Lagerwall Reviewed-by: Len Brown Acked-by: Viresh Kumar Cc: 3.8+ Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/acpi-cpufreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 11b8b4b54ceb..edc089e9d0c4 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -347,11 +347,11 @@ static u32 get_cur_val(const struct cpumask *mask) switch (per_cpu(acfreq_data, cpumask_first(mask))->cpu_feature) { case SYSTEM_INTEL_MSR_CAPABLE: cmd.type = SYSTEM_INTEL_MSR_CAPABLE; - cmd.addr.msr.reg = MSR_IA32_PERF_STATUS; + cmd.addr.msr.reg = MSR_IA32_PERF_CTL; break; case SYSTEM_AMD_MSR_CAPABLE: cmd.type = SYSTEM_AMD_MSR_CAPABLE; - cmd.addr.msr.reg = MSR_AMD_PERF_STATUS; + cmd.addr.msr.reg = MSR_AMD_PERF_CTL; break; case SYSTEM_IO_CAPABLE: cmd.type = SYSTEM_IO_CAPABLE; From a98d4f64a20b2b88697e7e08c871144a7e3f0ec4 Mon Sep 17 00:00:00 2001 From: Wei Yongjun Date: Mon, 3 Jun 2013 02:08:39 +0000 Subject: [PATCH 5/9] 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 6/9] 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 2f7021a815f20f3481c10884fe9735ce2a56db35 Mon Sep 17 00:00:00 2001 From: Michael Wang Date: Wed, 5 Jun 2013 08:49:37 +0000 Subject: [PATCH 7/9] cpufreq: protect 'policy->cpus' from offlining during __gov_queue_work() Jiri Kosina and Borislav Petkov reported the warning: [ 51.616759] ------------[ cut here ]------------ [ 51.621460] WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule+0x58/0x60() [ 51.629638] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode [ 51.675581] CPU: 0 PID: 244 Comm: kworker/1:1 Tainted: G W 3.10.0-rc1+ #10 [ 51.683407] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08 01/24/2013 [ 51.690901] Workqueue: events od_dbs_timer [ 51.695069] 0000000000000009 ffff88043a2f5b68 ffffffff8161441c ffff88043a2f5ba8 [ 51.702602] ffffffff8103e540 0000000000000033 0000000000000001 ffff88043d5f8000 [ 51.710136] 00000000ffff0ce1 0000000000000001 ffff88044fc4fc08 ffff88043a2f5bb8 [ 51.717691] Call Trace: [ 51.720191] [] dump_stack+0x19/0x1b [ 51.725396] [] warn_slowpath_common+0x70/0xa0 [ 51.731473] [] warn_slowpath_null+0x1a/0x20 [ 51.737378] [] native_smp_send_reschedule+0x58/0x60 [ 51.744013] [] wake_up_nohz_cpu+0x2d/0xa0 [ 51.749745] [] add_timer_on+0x8f/0x110 [ 51.755214] [] __queue_delayed_work+0x16e/0x1a0 [ 51.761470] [] ? try_to_grab_pending+0xd1/0x1a0 [ 51.767724] [] mod_delayed_work_on+0x5a/0xa0 [ 51.773719] [] gov_queue_work+0x4d/0xc0 [ 51.779271] [] od_dbs_timer+0xcb/0x170 [ 51.784734] [] process_one_work+0x1fd/0x540 [ 51.790634] [] ? process_one_work+0x192/0x540 [ 51.796711] [] worker_thread+0x122/0x380 [ 51.802350] [] ? rescuer_thread+0x320/0x320 [ 51.808264] [] kthread+0xea/0xf0 [ 51.813200] [] ? flush_kthread_worker+0x150/0x150 [ 51.819644] [] ret_from_fork+0x7c/0xb0 [ 51.918165] nouveau E[ DRM] GPU lockup - switching to software fbcon [ 51.930505] [] ? flush_kthread_worker+0x150/0x150 [ 51.936994] ---[ end trace f419538ada83b5c5 ]--- It was caused by the policy->cpus changed during the process of __gov_queue_work(), in other word, cpu offline happened. Use get/put_online_cpus() to prevent the offline from happening while __gov_queue_work() is running. [rjw: The problem has been present since recent commit 031299b (cpufreq: governors: Avoid unnecessary per cpu timer interrupts)] References: https://lkml.org/lkml/2013/6/5/88 Reported-by: Borislav Petkov Reported-and-tested-by: Jiri Kosina Signed-off-by: Michael Wang Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/cpufreq_governor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 5af40ad82d23..dc9b72e25c1a 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -26,6 +26,7 @@ #include #include #include +#include #include "cpufreq_governor.h" @@ -180,8 +181,10 @@ void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy, if (!all_cpus) { __gov_queue_work(smp_processor_id(), dbs_data, delay); } else { + get_online_cpus(); for_each_cpu(i, policy->cpus) __gov_queue_work(i, dbs_data, delay); + put_online_cpus(); } } EXPORT_SYMBOL_GPL(gov_queue_work); From 0ca684365547cd5f214b5739568dae3df5d6cec9 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Mon, 25 Feb 2013 18:22:37 +0100 Subject: [PATCH 8/9] cpufreq: cpufreq-cpu0: use the exact frequency for clk_set_rate() clk_set_rate() isn't supposed to accept approximate frequencies, instead a supported frequency should be obtained from clk_round_rate() and then used to set the clock. Signed-off-by: Guennadi Liakhovetski Acked-by: Shawn Guo Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/cpufreq-cpu0.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index a64eb8b70444..ad1fde277661 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -45,7 +45,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy, struct cpufreq_freqs freqs; struct opp *opp; unsigned long volt = 0, volt_old = 0, tol = 0; - long freq_Hz; + long freq_Hz, freq_exact; unsigned int index; int ret; @@ -60,6 +60,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy, freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency * 1000); if (freq_Hz < 0) freq_Hz = freq_table[index].frequency * 1000; + freq_exact = freq_Hz; freqs.new = freq_Hz / 1000; freqs.old = clk_get_rate(cpu_clk) / 1000; @@ -98,7 +99,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy, } } - ret = clk_set_rate(cpu_clk, freqs.new * 1000); + ret = clk_set_rate(cpu_clk, freq_exact); if (ret) { pr_err("failed to set clock rate: %d\n", ret); if (cpu_reg) From 7cd8407d53ef5fb0280fcbe34f42311472f90feb Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 5 Jun 2013 14:01:19 +0200 Subject: [PATCH 9/9] 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;