From 68b92b567c0c5e6f4d0b264d438f97ee5ccbdccc Mon Sep 17 00:00:00 2001 From: Mark Langsdorf Date: Tue, 11 Aug 2009 15:15:42 -0500 Subject: ACPI: add AC/DC notifier Add an ACPI event notifier for AC/DC connect/disconnect events. Signed-off-by: Mark Langsdorf Signed-off-by: Len Brown --- drivers/acpi/ac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c index 98b9690b015..b6ed60b57b0 100644 --- a/drivers/acpi/ac.c +++ b/drivers/acpi/ac.c @@ -245,6 +245,7 @@ static void acpi_ac_notify(struct acpi_device *device, u32 event) acpi_bus_generate_netlink_event(device->pnp.device_class, dev_name(&device->dev), event, (u32) ac->state); + acpi_notifier_call_chain(device, event, (u32) ac->state); #ifdef CONFIG_ACPI_SYSFS_POWER kobject_uevent(&ac->charger.dev->kobj, KOBJ_CHANGE); #endif -- cgit v1.2.3 From c4c4e2a58996d774429ded2fe386e88b47a10e98 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Fri, 9 Oct 2009 15:53:24 +0200 Subject: ACPI: Kconfig, fix proc aggregator text Fix two typos in the Kconfig text about ACPI_PROCESSOR_AGGREGATOR. Signed-off-by: Jiri Slaby Signed-off-by: Len Brown --- drivers/acpi/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 0ed42d8870c..93d2c7971df 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -218,10 +218,10 @@ config ACPI_PROCESSOR_AGGREGATOR depends on X86 help ACPI 4.0 defines processor Aggregator, which enables OS to perform - specfic processor configuration and control that applies to all + specific processor configuration and control that applies to all processors in the platform. Currently only logical processor idling is defined, which is to reduce power consumption. This driver - support the new device. + supports the new device. config ACPI_THERMAL tristate "Thermal Zone" -- cgit v1.2.3 From 2906206350b7e13e2047467cc29a0a2d78d71cb2 Mon Sep 17 00:00:00 2001 From: Jonathan Woithe Date: Thu, 8 Oct 2009 13:19:12 +0930 Subject: fujitsu-laptop: address missed led-class ifdef fixup A follow-up 2.6.32-rc1's 1e384cb0f9a940f2a431d1708f963987e61d71e3 "fujitsu-laptop: support led-class as module" It's a trivial fix for one of the CONFIG_LEDS_CLASS ifdefs which was somehow missed in the original patch. Signed-off-by: Jonathan Woithe Signed-off-by: Len Brown --- drivers/platform/x86/fujitsu-laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c index f35aee5c214..bcd4ba8be7d 100644 --- a/drivers/platform/x86/fujitsu-laptop.c +++ b/drivers/platform/x86/fujitsu-laptop.c @@ -944,7 +944,7 @@ static int acpi_fujitsu_hotkey_remove(struct acpi_device *device, int type) struct fujitsu_hotkey_t *fujitsu_hotkey = acpi_driver_data(device); struct input_dev *input = fujitsu_hotkey->input; -#ifdef CONFIG_LEDS_CLASS +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) if (fujitsu_hotkey->logolamp_registered) led_classdev_unregister(&logolamp_led); -- cgit v1.2.3 From 497fb54f578efd2b479727bc88d5ef942c0a1e2d Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 13 Oct 2009 01:01:57 +0200 Subject: ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2) 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 --- drivers/acpi/pci_root.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c index 31122214e0e..1af808171d4 100644 --- a/drivers/acpi/pci_root.c +++ b/drivers/acpi/pci_root.c @@ -389,6 +389,17 @@ struct pci_dev *acpi_get_pci_dev(acpi_handle handle) pbus = pdev->subordinate; pci_dev_put(pdev); + + /* + * This function may be called for a non-PCI device that has a + * PCI parent (eg. a disk under a PCI SATA controller). In that + * case pdev->subordinate will be NULL for the parent. + */ + if (!pbus) { + dev_dbg(&pdev->dev, "Not a PCI-to-PCI bridge\n"); + pdev = NULL; + break; + } } out: list_for_each_entry_safe(node, tmp, &device_list, node) -- cgit v1.2.3 From dcb73eed70575c68f1389f7fac7cbd0feaeb50f3 Mon Sep 17 00:00:00 2001 From: Rakib Mullick Date: Tue, 13 Oct 2009 00:13:32 +0200 Subject: eeepc-laptop: Properly annote eeepc_enable_camera(). Currently the annotation for function eeepc_enable_camera() is __init, and refers to a function eeepc_hotk_add() which is non-init. Use __devinit for both functions which is more appropriate and fixes a section mismatch warning. We were warned by the following warning: LD drivers/platform/x86/built-in.o WARNING: drivers/platform/x86/built-in.o(.text+0x12e1): Section mismatch in reference from the function eeepc_hotk_add() to the function .init.text:eeepc_enable_camera() The function eeepc_hotk_add() references the function __init eeepc_enable_camera(). This is often because eeepc_hotk_add lacks a __init annotation or the annotation of eeepc_enable_camera is wrong. Signed-off-by: Rakib Mullick Signed-off-by: Corentin Chary Signed-off-by: Len Brown --- drivers/platform/x86/eeepc-laptop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c index 749e2102b2b..789d6ae003f 100644 --- a/drivers/platform/x86/eeepc-laptop.c +++ b/drivers/platform/x86/eeepc-laptop.c @@ -350,7 +350,7 @@ static const struct rfkill_ops eeepc_rfkill_ops = { .set_block = eeepc_rfkill_set, }; -static void __init eeepc_enable_camera(void) +static void __devinit eeepc_enable_camera(void) { /* * If the following call to set_acpi() fails, it's because there's no @@ -1189,7 +1189,7 @@ static int eeepc_input_init(struct device *dev) return 0; } -static int eeepc_hotk_add(struct acpi_device *device) +static int __devinit eeepc_hotk_add(struct acpi_device *device) { struct device *dev; int result; -- cgit v1.2.3 From b56ab33d68638e6aafdbfc694025e8354a628f49 Mon Sep 17 00:00:00 2001 From: Darren Salt Date: Tue, 13 Oct 2009 00:13:33 +0200 Subject: eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated This works around what I think is actually a bug in rt2860sta which is triggered when the hardware "disappears" from beneath the driver, i.e. when wireless is toggled off via ACPI. It does so by ensuring that the rfkill soft-block flag is set before the hardware is disabled. I do not know whether this patch is required if rt2800pci is in use instead of rt2860sta; at the time of submission of this patch, I've not been able to test this. (Ref. http://bugzilla.kernel.org/show_bug.cgi?id=13390) Signed-off-by: Darren Salt Signed-off-by: Len Brown --- drivers/platform/x86/eeepc-laptop.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c index 789d6ae003f..d379e74a05d 100644 --- a/drivers/platform/x86/eeepc-laptop.c +++ b/drivers/platform/x86/eeepc-laptop.c @@ -150,6 +150,8 @@ struct eeepc_hotk { /* The actual device the driver binds to */ static struct eeepc_hotk *ehotk; +static void eeepc_rfkill_hotplug(bool real); + /* Platform device/driver */ static int eeepc_hotk_thaw(struct device *device); static int eeepc_hotk_restore(struct device *device); @@ -343,7 +345,16 @@ static bool eeepc_wlan_rfkill_blocked(void) static int eeepc_rfkill_set(void *data, bool blocked) { unsigned long asl = (unsigned long)data; - return set_acpi(asl, !blocked); + int ret; + + if (asl != CM_ASL_WLAN) + return set_acpi(asl, !blocked); + + /* hack to avoid panic with rt2860sta */ + if (blocked) + eeepc_rfkill_hotplug(false); + ret = set_acpi(asl, !blocked); + return ret; } static const struct rfkill_ops eeepc_rfkill_ops = { @@ -643,13 +654,13 @@ static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot, return 0; } -static void eeepc_rfkill_hotplug(void) +static void eeepc_rfkill_hotplug(bool real) { struct pci_dev *dev; struct pci_bus *bus; - bool blocked = eeepc_wlan_rfkill_blocked(); + bool blocked = real ? eeepc_wlan_rfkill_blocked() : true; - if (ehotk->wlan_rfkill) + if (real && ehotk->wlan_rfkill) rfkill_set_sw_state(ehotk->wlan_rfkill, blocked); mutex_lock(&ehotk->hotplug_lock); @@ -692,7 +703,7 @@ static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data) if (event != ACPI_NOTIFY_BUS_CHECK) return; - eeepc_rfkill_hotplug(); + eeepc_rfkill_hotplug(true); } static void eeepc_hotk_notify(struct acpi_device *device, u32 event) @@ -850,7 +861,7 @@ static int eeepc_hotk_restore(struct device *device) { /* Refresh both wlan rfkill state and pci hotplug */ if (ehotk->wlan_rfkill) - eeepc_rfkill_hotplug(); + eeepc_rfkill_hotplug(true); if (ehotk->bluetooth_rfkill) rfkill_set_sw_state(ehotk->bluetooth_rfkill, @@ -993,7 +1004,7 @@ static void eeepc_rfkill_exit(void) * Refresh pci hotplug in case the rfkill state was changed after * eeepc_unregister_rfkill_notifier() */ - eeepc_rfkill_hotplug(); + eeepc_rfkill_hotplug(true); if (ehotk->hotplug_slot) pci_hp_deregister(ehotk->hotplug_slot); @@ -1109,7 +1120,7 @@ static int eeepc_rfkill_init(struct device *dev) * Refresh pci hotplug in case the rfkill state was changed during * setup. */ - eeepc_rfkill_hotplug(); + eeepc_rfkill_hotplug(true); exit: if (result && result != -ENODEV) -- cgit v1.2.3 From 3a1151e3f124fd1a2c54b8153f510f1a7c715369 Mon Sep 17 00:00:00 2001 From: Stefan Bader Date: Fri, 21 Aug 2009 11:03:05 +0200 Subject: ACPI: video: Loosen strictness of video bus detection code BugLink: http://bugs.launchpad.net/bugs/333386 Currently a video bus device must (beside other criteria) define _DOD and _DOS methods to be considered a video device. Some broken BIOSes prevented working backlight control by only defining both for one (non-existing bus) and only _DOD for the rest. With this patch in place the other bus definitions were considered too and backlight control started to work again. Signed-off-by: Stefan Bader Acked-by: Zhang Rui Signed-off-by: Len Brown --- drivers/acpi/video.c | 7 ++++++- drivers/acpi/video_detect.c | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index f6e54bf8dd9..64e3c581b7a 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -1109,7 +1109,12 @@ static int acpi_video_bus_check(struct acpi_video_bus *video) */ /* Does this device support video switching? */ - if (video->cap._DOS) { + if (video->cap._DOS || video->cap._DOD) { + if (!video->cap._DOS) { + printk(KERN_WARNING FW_BUG + "ACPI(%s) defines _DOD but not _DOS\n", + acpi_device_bid(video->device)); + } video->flags.multihead = 1; status = 0; } diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 7032f25da9b..575593a8b4e 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -84,7 +84,7 @@ long acpi_is_video_device(struct acpi_device *device) return 0; /* Does this device able to support video switching ? */ - if (ACPI_SUCCESS(acpi_get_handle(device->handle, "_DOD", &h_dummy)) && + if (ACPI_SUCCESS(acpi_get_handle(device->handle, "_DOD", &h_dummy)) || ACPI_SUCCESS(acpi_get_handle(device->handle, "_DOS", &h_dummy))) video_caps |= ACPI_VIDEO_OUTPUT_SWITCHING; -- cgit v1.2.3 From 2c907b72db4dd4e8af6dccb6e0ac122d78627b8d Mon Sep 17 00:00:00 2001 From: Jesse Barnes Date: Wed, 7 Oct 2009 14:39:46 -0700 Subject: ACPI button: don't try to use a non-existent lid device If a call comes in to check the lid state but there's no lid device present, we should return -ENODEV. Signed-off-by: Jesse Barnes Signed-off-by: Len Brown --- drivers/acpi/button.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c index 9335b87c517..0c9c6a9a002 100644 --- a/drivers/acpi/button.c +++ b/drivers/acpi/button.c @@ -251,6 +251,9 @@ int acpi_lid_open(void) acpi_status status; unsigned long long state; + if (!lid_device) + return -ENODEV; + status = acpi_evaluate_integer(lid_device->handle, "_LID", NULL, &state); if (ACPI_FAILURE(status)) -- cgit v1.2.3