ACPI related patches for 2.6.32-rc4
Subsystems (5)
Len Brown
reviewera couple of patches for upstream...
Len Brown
reviewerPATCH 1/8 ACPI: add AC/DC notifier
From: Mark Langsdorf <[email protected]>
Add an ACPI event notifier for AC/DC connect/disconnect events.
--- drivers/acpi/ac.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/acpi/ac.c +1 -0
@@ -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
Signature · 1 line
1.6.0.6
Len Brown
reviewerPATCH 2/8 ACPI: Kconfig, fix proc aggregator text
In reply to Len BrownFrom: Jiri Slaby <[email protected]>
Fix two typos in the Kconfig text about ACPI_PROCESSOR_AGGREGATOR.
--- drivers/acpi/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
drivers/acpi/Kconfig +2 -2
@@ -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"
Signature · 1 line
1.6.0.6
Len Brown
reviewerPATCH 3/8 fujitsu-laptop: address missed led-class ifdef fixup
In reply to Len BrownFrom: Jonathan Woithe <[email protected]>
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.
--- drivers/platform/x86/fujitsu-laptop.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/platform/x86/fujitsu-laptop.c +1 -1
@@ -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);
Signature · 1 line
1.6.0.6
Len Brown
reviewerPATCH 4/8 ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2)
In reply to Len BrownFrom: Rafael J. Wysocki <[email protected]>
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)
--- drivers/acpi/pci_root.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
drivers/acpi/pci_root.c +11 -0
@@ -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)
Signature · 1 line
1.6.0.6
Len Brown
reviewerPATCH 5/8 eeepc-laptop: Properly annote eeepc_enable_camera().
In reply to Len BrownFrom: Rakib Mullick <[email protected]>
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.
--- drivers/platform/x86/eeepc-laptop.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
drivers/platform/x86/eeepc-laptop.c +2 -2
@@ -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;
Signature · 1 line
1.6.0.6
Len Brown
reviewerPATCH 6/8 eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated
In reply to Len BrownFrom: Darren Salt <[email protected]>
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)
--- drivers/platform/x86/eeepc-laptop.c | 27 +++++++++++++++++++-------- 1 files changed, 19 insertions(+), 8 deletions(-)
drivers/platform/x86/eeepc-laptop.c +19 -8
@@ -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 )
Signature · 1 line
1.6.0.6
Corentin Chary
maintainerRe: [PATCH 6/8] eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated
Quoted 106 lines · Len Brown
From: Darren Salt <[email protected]>
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 <[email protected]>Signed-off-by Len Brown <[email protected]>---
drivers/platform/x86/eeepc-laptop.c | 27 +++++++++++++++++++--------1 files changed, 19 insertions(+), 8 deletions(-)drivers/platform/x86/eeepc-laptop.c +19
-8@@ -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)
--
1.6.0.6
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Len,
I sent you a revert request 2 days ago for this patch, Darren reported some problems with it.
You may have missed it, it can be found at:
http://marc.info/?l=linux-acpi&m=125542258501548&w=2 .
Is it still time to revert ?
Thanks,
Signature · 6 lines
Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated
I demand that Corentin Chary may or may not have written...
Quoted 7 lines · Len Brown
Quoted 6 lines
From: Darren Salt <[email protected]>
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.
[snip patch]
Quoted 5 lines
I sent you a revert request 2 days ago for this patch, Darren reported some problems with it.
You may have missed it, it can be found at:
http://marc.info/?l=linux-acpi&m=125542258501548&w=2 .
Is it still time to revert?
I certainly hope that there's still time – a much better patch for this (which fixes the problem directly in rt2860sta) arrived in Greg KH's staging.current queue late yesterday.
Signature · 9 lines
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army | Let's keep the pound sterling Established technology tends to persist in spite of new technology. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerPATCH 7/8 ACPI: video: Loosen strictness of video bus detection code
In reply to Len BrownFrom: Stefan Bader <[email protected]>
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.
--- drivers/acpi/video.c | 7 ++++++- drivers/acpi/video_detect.c | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/acpi/video.c +6 -1
@@ -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 ; }
drivers/acpi/video_detect.c +1 -1
@@ -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 ;
Signature · 1 line
1.6.0.6
Len Brown
reviewerPATCH 8/8 ACPI button: don't try to use a non-existent lid device
In reply to Len BrownFrom: Jesse Barnes <[email protected]>
If a call comes in to check the lid state but there's no lid device present, we should return -ENODEV.
--- drivers/acpi/button.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
drivers/acpi/button.c +3 -0
@@ -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))
Signature · 1 line
1.6.0.6