ACPI patches for 2.6.28-rc6

ACPI patches for 2.6.28-rc6

[Len Brown]

This batch is queued for upstream now.
Please speak up if you see any issues with them,
or if somethign is missing.

thanks,
-Len

[PATCH 01/11] ACPI: EC: count interrupts only if called from interrupt handler.

[Len Brown]

From: Alexey Starikovskiy <astarikovskiy@suse.de>

fix 2.6.28 EC interrupt storm regression

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/ec.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index cf41f9f..30f3ef2 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -219,7 +219,8 @@ static void gpe_transaction(struct acpi_ec *ec, u8 status)
 	goto unlock;
 err:
 	/* false interrupt, state didn't change */
-	++ec->curr->irq_count;
+	if (in_interrupt())
+		++ec->curr->irq_count;
 unlock:
 	spin_unlock_irqrestore(&ec->curr_lock, flags);
 }
-- 
1.5.6.5

[PATCH 02/11] ACPI: battery: Convert discharge energy rate to current properly

[Len Brown]

From: Alexey Starikovskiy <aystarik@gmail.com>

ACPI battery interface reports its state either in mW or in mA, and
discharge rate in your case is reported in mW. power_supply interface
does not have such a parameter, so current_now parameter is used
for all cases. But in case of mW, reported discharge should
be converted into mA.

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Ferenc Wagner <wferi@niif.hu>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/battery.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 1423b0c..a0a178d 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -174,6 +174,15 @@ static int acpi_battery_get_property(struct power_supply *psy,
 		break;
 	case POWER_SUPPLY_PROP_CURRENT_NOW:
 		val->intval = battery->current_now * 1000;
+		/* if power units are mW, convert to mA by
+		   dividing by current voltage (mV/1000) */
+		if (!battery->power_unit) {
+			if (battery->voltage_now) {
+				val->intval /= battery->voltage_now;
+				val->intval *= 1000;
+			} else
+				val->intval = -1;
+		}
 		break;
 	case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
 	case POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN:
-- 
1.5.6.5

[PATCH 03/11] ACPI: scheduling in atomic via acpi_evaluate_integer ()

[Len Brown]

From: Pavel Machek <pavel@suse.cz>

Now I know why I had strange "scheduling in atomic" problems:
acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC
: GFP_KERNEL)... which is (of course) broken.

There's no way to reliably tell if we need GFP_ATOMIC or not from
code, this one for example fails to detect spinlocks held.

Fortunately, allocation seems small enough to be done on stack.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Acked-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/utils.c |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index e827be3..f844941 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -259,34 +259,26 @@ acpi_evaluate_integer(acpi_handle handle,
 		      struct acpi_object_list *arguments, unsigned long long *data)
 {
 	acpi_status status = AE_OK;
-	union acpi_object *element;
+	union acpi_object element;
 	struct acpi_buffer buffer = { 0, NULL };
 
-
 	if (!data)
 		return AE_BAD_PARAMETER;
 
-	element = kzalloc(sizeof(union acpi_object), irqs_disabled() ? GFP_ATOMIC: GFP_KERNEL);
-	if (!element)
-		return AE_NO_MEMORY;
-
 	buffer.length = sizeof(union acpi_object);
-	buffer.pointer = element;
+	buffer.pointer = &element;
 	status = acpi_evaluate_object(handle, pathname, arguments, &buffer);
 	if (ACPI_FAILURE(status)) {
 		acpi_util_eval_error(handle, pathname, status);
-		kfree(element);
 		return status;
 	}
 
-	if (element->type != ACPI_TYPE_INTEGER) {
+	if (element.type != ACPI_TYPE_INTEGER) {
 		acpi_util_eval_error(handle, pathname, AE_BAD_DATA);
-		kfree(element);
 		return AE_BAD_DATA;
 	}
 
-	*data = element->integer.value;
-	kfree(element);
+	*data = element.integer.value;
 
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Return value [%llu]\n", *data));
 
-- 
1.5.6.5

[PATCH 04/11] ACPI suspend: Blacklist boxes that require us to set SCI_EN directly on resume

[Len Brown]

From: Rafael J. Wysocki <rjw@sisk.pl>

Some Apple boxes evidently require us to set SCI_EN on resume
directly, because if we don't do that, they hung somewhere in the
resume code path.  Moreover, on these boxes it is not sufficient to
use acpi_enable() to turn ACPI on during resume.  All of this is
against the ACPI specification which states that (1) the BIOS is
supposed to return from the S3 sleep state with ACPI enabled
(SCI_EN set) and (2) the SCI_EN bit is owned by the hardware and we
are not supposed to change it.

For this reason, blacklist the affected systems so that the SCI_EN
bit is set during resume on them.

[NOTE: Unconditional setting SCI_EN for all system on resume doesn't
 work, because it makes some other systems crash (that's to be
 expected).  Also, it is not entirely clear right now if all of the
 Apple boxes require this workaround.]

This patch fixes the recent regression tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12038

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Tested-by: Tino Keitel <tino.keitel@gmx.de>
Tested-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/sleep/main.c |   40 +++++++++++++++++++++++++++++++++++++++-
 1 files changed, 39 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 80c0868..28a691c 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -90,6 +90,18 @@ void __init acpi_old_suspend_ordering(void)
 	old_suspend_ordering = true;
 }
 
+/*
+ * According to the ACPI specification the BIOS should make sure that ACPI is
+ * enabled and SCI_EN bit is set on wake-up from S1 - S3 sleep states.  Still,
+ * some BIOSes don't do that and therefore we use acpi_enable() to enable ACPI
+ * on such systems during resume.  Unfortunately that doesn't help in
+ * particularly pathological cases in which SCI_EN has to be set directly on
+ * resume, although the specification states very clearly that this flag is
+ * owned by the hardware.  The set_sci_en_on_resume variable will be set in such
+ * cases.
+ */
+static bool set_sci_en_on_resume;
+
 /**
  *	acpi_pm_disable_gpes - Disable the GPEs.
  */
@@ -235,7 +247,11 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
 	}
 
 	/* If ACPI is not enabled by the BIOS, we need to enable it here. */
-	acpi_enable();
+	if (set_sci_en_on_resume)
+		acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1);
+	else
+		acpi_enable();
+
 	/* Reprogram control registers and execute _BFS */
 	acpi_leave_sleep_state_prep(acpi_state);
 
@@ -323,6 +339,12 @@ static int __init init_old_suspend_ordering(const struct dmi_system_id *d)
 	return 0;
 }
 
+static int __init init_set_sci_en_on_resume(const struct dmi_system_id *d)
+{
+	set_sci_en_on_resume = true;
+	return 0;
+}
+
 static struct dmi_system_id __initdata acpisleep_dmi_table[] = {
 	{
 	.callback = init_old_suspend_ordering,
@@ -340,6 +362,22 @@ static struct dmi_system_id __initdata acpisleep_dmi_table[] = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "HP xw4600 Workstation"),
 		},
 	},
+	{
+	.callback = init_set_sci_en_on_resume,
+	.ident = "Apple MacBook 1,1",
+	.matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		DMI_MATCH(DMI_PRODUCT_NAME, "MacBook1,1"),
+		},
+	},
+	{
+	.callback = init_set_sci_en_on_resume,
+	.ident = "Apple MacMini 1,1",
+	.matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Macmini1,1"),
+		},
+	},
 	{},
 };
 #endif /* CONFIG_SUSPEND */
-- 
1.5.6.5

[PATCH 05/11] Revert "ACPI: don't enable control method power button as wakeup device when Fixed Power button is used"

[Len Brown]

From: Len Brown <len.brown@intel.com>

This reverts commit faee816b1502385dc9bc5abf2960d1cc645844d1.

http://bugzilla.kernel.org/show_bug.cgi?id=12091

Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/scan.c |   10 ----------
 1 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index bd5253e..39b7233 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -751,16 +751,6 @@ static int acpi_bus_get_wakeup_device_flags(struct acpi_device *device)
 	if (!acpi_match_device_ids(device, button_device_ids))
 		device->wakeup.flags.run_wake = 1;
 
-	/*
-	 * Don't set Power button GPE as run_wake
-	 * if Fixed Power button is used
-	 */
-	if (!strcmp(device->pnp.hardware_id, "PNP0C0C") &&
-		!(acpi_gbl_FADT.flags & ACPI_FADT_POWER_BUTTON)) {
-		device->wakeup.flags.run_wake = 0;
-		device->wakeup.flags.valid = 0;
-	}
-
       end:
 	if (ACPI_FAILURE(status))
 		device->flags.wake_capable = 0;
-- 
1.5.6.5

[PATCH 06/11] sony-laptop: brightness regression fix

[Len Brown]

From: Alessandro Guido <ag@alessandroguido.name>

After commit 540b8bb9c33935183ceb5bed466a42ad72b2af56:

  sony-laptop: fingers off backlight if video.ko is serving this functionality

I can't set brightness on my sony laptop (nothing in /sys/class/backlight).
dmesg says "sony-laptop: Sony: Brightness ignored, must be controlled by ACPI
video driver".

The function acpi_video_backlight_support returns 0 if we should use the
vendor-specific backlight support, while non-0 if the ACPI generic should
be used. Because of this, the check introduced by the said commit appears
reversed.

Signed-off-by: Alessandro Guido <ag@alessandroguido.name>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/misc/sony-laptop.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index 7bcb810..2a613d4 100644
--- a/drivers/misc/sony-laptop.c
+++ b/drivers/misc/sony-laptop.c
@@ -1038,7 +1038,7 @@ static int sony_nc_add(struct acpi_device *device)
 		goto outinput;
 	}
 
-	if (!acpi_video_backlight_support()) {
+	if (acpi_video_backlight_support()) {
 		printk(KERN_INFO DRV_PFX "Sony: Brightness ignored, must be "
 		       "controlled by ACPI video driver\n");
 	} else if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "GBRT",
-- 
1.5.6.5

[PATCH 07/11] sony-laptop: printk tweak

[Len Brown]

From: Alessandro Guido <ag@alessandroguido.name>

There's no need to print "Sony: " just after "sony-laptop: " (DRV_PFX).

Signed-off-by: Alessandro Guido <ag@alessandroguido.name>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/misc/sony-laptop.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index 2a613d4..571b211 100644
--- a/drivers/misc/sony-laptop.c
+++ b/drivers/misc/sony-laptop.c
@@ -1039,7 +1039,7 @@ static int sony_nc_add(struct acpi_device *device)
 	}
 
 	if (acpi_video_backlight_support()) {
-		printk(KERN_INFO DRV_PFX "Sony: Brightness ignored, must be "
+		printk(KERN_INFO DRV_PFX "brightness ignored, must be "
 		       "controlled by ACPI video driver\n");
 	} else if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "GBRT",
 						&handle))) {
-- 
1.5.6.5

[PATCH 08/11] ACPI: thinkpad-acpi: fix fan sleep/resume path

[Len Brown]

From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

This fixes a regression from v2.6.27, caused by commit
5814f737e1cd2cfa2893badd62189acae3e1e1fd, "ACPI: thinkpad-acpi:
attempt to preserve fan state on resume".

It is possible for fan_suspend() to fail to properly initialize
fan_control_desired_level as required by fan_resume(), resulting on
the fan always being set to level 7 on resume if the user didn't
touch the fan controller.

In order to get fan sleep/resume handling to work right:

1. Fix the fan_suspend handling of the T43 firmware quirk. If it is
still undefined, we didn't touch the fan yet and that means we have no
business doing it on resume.

2. Store the fan level on its own variable to avoid any possible
issues with hijacking fan_control_desired_level (which isn't supposed
to have anything other than 0-7 in it, anyway).

3. Change the fan_resume code to me more straightforward to understand
(although we DO optimize the boolean logic there, otherwise it looks
disgusting).

4. Add comments to help understand what the code is supposed to be
doing.

5. Change fan_set_level to be less strict about how auto and
full-speed modes are requested.

http://bugzilla.kernel.org/show_bug.cgi?id=11982

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: Tino Keitel <tino.keitel@tikei.de>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/misc/thinkpad_acpi.c |   57 +++++++++++++++++++++++++++++++++---------
 1 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 7a4a26b..899766e 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -5318,6 +5318,7 @@ static enum fan_control_commands fan_control_commands;
 
 static u8 fan_control_initial_status;
 static u8 fan_control_desired_level;
+static u8 fan_control_resume_level;
 static int fan_watchdog_maxinterval;
 
 static struct mutex fan_mutex;
@@ -5440,8 +5441,8 @@ static int fan_set_level(int level)
 
 	case TPACPI_FAN_WR_ACPI_FANS:
 	case TPACPI_FAN_WR_TPEC:
-		if ((level != TP_EC_FAN_AUTO) &&
-		    (level != TP_EC_FAN_FULLSPEED) &&
+		if (!(level & TP_EC_FAN_AUTO) &&
+		    !(level & TP_EC_FAN_FULLSPEED) &&
 		    ((level < 0) || (level > 7)))
 			return -EINVAL;
 
@@ -6005,38 +6006,67 @@ static void fan_exit(void)
 
 static void fan_suspend(pm_message_t state)
 {
+	int rc;
+
 	if (!fan_control_allowed)
 		return;
 
 	/* Store fan status in cache */
-	fan_get_status_safe(NULL);
+	fan_control_resume_level = 0;
+	rc = fan_get_status_safe(&fan_control_resume_level);
+	if (rc < 0)
+		printk(TPACPI_NOTICE
+			"failed to read fan level for later "
+			"restore during resume: %d\n", rc);
+
+	/* if it is undefined, don't attempt to restore it.
+	 * KEEP THIS LAST */
 	if (tp_features.fan_ctrl_status_undef)
-		fan_control_desired_level = TP_EC_FAN_AUTO;
+		fan_control_resume_level = 0;
 }
 
 static void fan_resume(void)
 {
-	u8 saved_fan_level;
 	u8 current_level = 7;
 	bool do_set = false;
+	int rc;
 
 	/* DSDT *always* updates status on resume */
 	tp_features.fan_ctrl_status_undef = 0;
 
-	saved_fan_level = fan_control_desired_level;
 	if (!fan_control_allowed ||
+	    !fan_control_resume_level ||
 	    (fan_get_status_safe(&current_level) < 0))
 		return;
 
 	switch (fan_control_access_mode) {
 	case TPACPI_FAN_WR_ACPI_SFAN:
-		do_set = (saved_fan_level > current_level);
+		/* never decrease fan level */
+		do_set = (fan_control_resume_level > current_level);
 		break;
 	case TPACPI_FAN_WR_ACPI_FANS:
 	case TPACPI_FAN_WR_TPEC:
-		do_set = ((saved_fan_level & TP_EC_FAN_FULLSPEED) ||
-			  (saved_fan_level == 7 &&
-			   !(current_level & TP_EC_FAN_FULLSPEED)));
+		/* never decrease fan level, scale is:
+		 * TP_EC_FAN_FULLSPEED > 7 >= TP_EC_FAN_AUTO
+		 *
+		 * We expect the firmware to set either 7 or AUTO, but we
+		 * handle FULLSPEED out of paranoia.
+		 *
+		 * So, we can safely only restore FULLSPEED or 7, anything
+		 * else could slow the fan.  Restoring AUTO is useless, at
+		 * best that's exactly what the DSDT already set (it is the
+		 * slower it uses).
+		 *
+		 * Always keep in mind that the DSDT *will* have set the
+		 * fans to what the vendor supposes is the best level.  We
+		 * muck with it only to speed the fan up.
+		 */
+		if (fan_control_resume_level != 7 &&
+		    !(fan_control_resume_level & TP_EC_FAN_FULLSPEED))
+			return;
+		else
+			do_set = !(current_level & TP_EC_FAN_FULLSPEED) &&
+				 (current_level != fan_control_resume_level);
 		break;
 	default:
 		return;
@@ -6044,8 +6074,11 @@ static void fan_resume(void)
 	if (do_set) {
 		printk(TPACPI_NOTICE
 			"restoring fan level to 0x%02x\n",
-			saved_fan_level);
-		fan_set_level_safe(saved_fan_level);
+			fan_control_resume_level);
+		rc = fan_set_level_safe(fan_control_resume_level);
+		if (rc < 0)
+			printk(TPACPI_NOTICE
+				"failed to restore fan level: %d\n", rc);
 	}
 }
 
-- 
1.5.6.5

[PATCH 09/11] ACPICA: Allow _WAK method to return an Integer

[Len Brown]

From: Bob Moore <robert.moore@intel.com>

This can happen if the _WAK method returns nothing (as per ACPI
1.0) but does return an integer if the implicit return mechanism
is enabled.  This is the only method that has this problem,
since it is also defined to return a package of two integers
(ACPI 1.0b+). In all other cases, if a method returns an object
when one was not expected, no warning is issued.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 include/acpi/acpredef.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/acpi/acpredef.h b/include/acpi/acpredef.h
index 619fb75..e6452db 100644
--- a/include/acpi/acpredef.h
+++ b/include/acpi/acpredef.h
@@ -346,7 +346,7 @@ static const union acpi_predefined_info predefined_names[] = {
 
 	/* Acpi 1.0 defined _WAK with no return value. Later, it was changed to return a package */
 
-	{.info = {"_WAK", 1, ACPI_RTYPE_NONE | ACPI_RTYPE_PACKAGE}},
+	{.info = {"_WAK", 1, ACPI_RTYPE_NONE | ACPI_RTYPE_INTEGER | ACPI_RTYPE_PACKAGE}},
 	{.ret_info = {ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 2, 0, 0, 0}},	/* fixed (2 Int), but is optional */
 	{.ret_info = {0, 0, 0, 0, 0, 0}}	/* Table terminator */
 };
-- 
1.5.6.5

[PATCH 10/11] ACPI: delete OSI(Linux) DMI dmesg spam

[Len Brown]

From: Len Brown <len.brown@intel.com>

Linux will continue to ignore OSI(Linux),
except for a white-list containing a few systems.

So delete the black-list,
and stop soliciting user-feedback on the console.

Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/blacklist.c |  401 +---------------------------------------------
 drivers/acpi/osl.c       |  104 +++---------
 2 files changed, 30 insertions(+), 475 deletions(-)

diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index ea92bac..09c6980 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -176,16 +176,6 @@ static int __init dmi_enable_osi_linux(const struct dmi_system_id *d)
 	acpi_dmi_osi_linux(1, d);	/* enable */
 	return 0;
 }
-static int __init dmi_disable_osi_linux(const struct dmi_system_id *d)
-{
-	acpi_dmi_osi_linux(0, d);	/* disable */
-	return 0;
-}
-static int __init dmi_unknown_osi_linux(const struct dmi_system_id *d)
-{
-	acpi_dmi_osi_linux(-1, d);	/* unknown */
-	return 0;
-}
 static int __init dmi_disable_osi_vista(const struct dmi_system_id *d)
 {
 	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
@@ -193,295 +183,21 @@ static int __init dmi_disable_osi_vista(const struct dmi_system_id *d)
 	return 0;
 }
 
-/*
- * Most BIOS that invoke OSI(Linux) do nothing with it.
- * But some cause Linux to break.
- * Only a couple use it to make Linux run better.
- *
- * Thus, Linux should continue to disable OSI(Linux) by default,
- * should continue to discourage BIOS writers from using it, and
- * should whitelist the few existing systems that require it.
- *
- * If it appears clear a vendor isn't using OSI(Linux)
- * for anything constructive, blacklist them by name to disable
- * unnecessary dmesg warnings on all of their products.
- */
-
 static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
-	/*
-	 * Disable OSI(Linux) warnings on all "Acer, inc."
-	 *
-	 * _OSI(Linux) disables the latest Windows BIOS code:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 3100"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5050"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5100"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5580"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 3010"),
-	 * _OSI(Linux) effect unknown:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Ferrari 5000"),
-	 */
-	/*
-	 * note that dmi_check_system() uses strstr()
-	 * to match sub-strings rather than !strcmp(),
-	 * so "Acer" below matches "Acer, inc." above.
-	 */
-	/*
-	 * Disable OSI(Linux) warnings on all "Acer"
-	 *
-	 * _OSI(Linux) effect unknown:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5610"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720Z"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5520"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 6460"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 7510"),
-	 *
-	 * _OSI(Linux) is a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5315"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5220"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Acer",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "Apple Computer, Inc."
-	 * Disable OSI(Linux) warnings on all "Apple Inc."
-	 *
-	 * _OSI(Linux) confirmed to be a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "MacBook1,1"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "MacBook2,1"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro2,2"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro3,1"),
-	 * _OSI(Linux) effect unknown:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "MacPro2,1"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro1,1"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Apple",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Apple"),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "BenQ"
-	 *
-	 * _OSI(Linux) confirmed to be a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Joybook S31"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "BenQ",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "BenQ"),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "Clevo Co."
-	 *
-	 * _OSI(Linux) confirmed to be a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "M570RU"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Clevo",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Clevo Co."),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "COMPAL"
-	 *
-	 * _OSI(Linux) confirmed to be a NOP:
-	 * DMI_MATCH(DMI_BOARD_NAME, "HEL8X"),
-	 * _OSI(Linux) unknown effect:
-	 * DMI_MATCH(DMI_BOARD_NAME, "IFL91"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Compal",
-	.matches = {
-		     DMI_MATCH(DMI_BIOS_VENDOR, "COMPAL"),
-		},
-	},
-	{ /* OSI(Linux) touches USB, unknown side-effect */
-	.callback = dmi_disable_osi_linux,
-	.ident = "Dell Dimension 5150",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Dell DM051"),
-		},
-	},
-	{ /* OSI(Linux) is a NOP */
-	.callback = dmi_disable_osi_linux,
-	.ident = "Dell i1501",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 1501"),
-		},
-	},
-	{ /* OSI(Linux) effect unknown */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell Latitude D830",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D830"),
-		},
-	},
-	{ /* OSI(Linux) effect unknown */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell OptiPlex GX620",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex GX620"),
-		},
-	},
-	{ /* OSI(Linux) causes some USB initialization to not run */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell OptiPlex 755",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 755"),
-		},
-	},
-	{ /* OSI(Linux) effect unknown */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell PE 1900",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 1900"),
-		},
-	},
-	{ /* OSI(Linux) is a NOP */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell PE 1950",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 1950"),
-		},
-	},
-	{ /* OSI(Linux) is a NOP */
-	.callback = dmi_disable_osi_linux,
-	.ident = "Dell PE R200",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge R200"),
-		},
-	},
-	{ /* OSI(Linux) touches USB */
-	.callback = dmi_disable_osi_linux,
-	.ident = "Dell PR 390",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation 390"),
-		},
-	},
-	{ /* OSI(Linux) touches USB */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell PR 390",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation 690"),
-		},
-	},
-	{ /* OSI(Linux) unknown - ASL looks benign, but may effect dock/SMM */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell PR M4300",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Precision M4300"),
-		},
-	},
-	{ /* OSI(Linux) is a NOP */
-	.callback = dmi_disable_osi_linux,
-	.ident = "Dell Vostro 1000",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Vostro   1000"),
-		},
-	},
-	{ /* OSI(Linux) effect unknown */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dell PE SC440",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge SC440"),
-		},
-	},
-	{ /* OSI(Linux) effect unknown */
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Dialogue Flybook V5",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Dialogue Technology Corporation"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Flybook V5"),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "FUJITSU SIEMENS"
-	 *
-	 * _OSI(Linux) disables latest Windows BIOS code:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pa 2510"),
-	 * _OSI(Linux) confirmed to be a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pi 1536"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pi 1556"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Xi 1546"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Mobile V5505"),
-	 * _OSI(Linux) unknown effect:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Amilo M1425"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Amilo Si 1520"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Fujitsu Siemens",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
-		},
-	},
 	{
 	.callback = dmi_disable_osi_vista,
 	.ident = "Fujitsu Siemens",
 	.matches = {
 		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
-	 	     DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Mobile V5505"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Mobile V5505"),
 		},
 	},
+
 	/*
-	 * Disable OSI(Linux) warnings on all "Hewlett-Packard"
-	 *
-	 * _OSI(Linux) confirmed to be a NOP:
-	 * .ident = "HP Pavilion tx 1000"
-	 * DMI_MATCH(DMI_BOARD_NAME, "30BF"),
-	 * .ident = "HP Pavilion dv2000"
-	 * DMI_MATCH(DMI_BOARD_NAME, "30B5"),
-	 * .ident = "HP Pavilion dv5000",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30A7"),
-	 * .ident = "HP Pavilion dv6300 30BC",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30BC"),
-	 * .ident = "HP Pavilion dv6000",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30B7"),
-	 * DMI_MATCH(DMI_BOARD_NAME, "30B8"),
-	 * .ident = "HP Pavilion dv9000",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30B9"),
-	 * .ident = "HP Pavilion dv9500",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30CB"),
-	 * .ident = "HP/Compaq Presario C500",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30C6"),
-	 * .ident = "HP/Compaq Presario F500",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30D3"),
-	 * _OSI(Linux) unknown effect:
-	 * .ident = "HP Pavilion dv6500",
-	 * DMI_MATCH(DMI_BOARD_NAME, "30D0"),
+	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
+	 * Linux ignores it, except for the machines enumerated below.
 	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Hewlett-Packard",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
-		},
-	},
+
 	/*
 	 * Lenovo has a mix of systems OSI(Linux) situations
 	 * and thus we can not wildcard the vendor.
@@ -519,113 +235,6 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X61"),
 		},
 	},
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Lenovo 3000 V100",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-		     DMI_MATCH(DMI_PRODUCT_VERSION, "LENOVO3000 V100"),
-		},
-	},
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Lenovo 3000 N100",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-		     DMI_MATCH(DMI_PRODUCT_VERSION, "3000 N100"),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "LG Electronics"
-	 *
-	 * _OSI(Linux) confirmed to be a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "P1-J150B"),
-	 * with DMI_MATCH(DMI_BOARD_NAME, "ROCKY"),
-	 *
-	 * unknown:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "S1-MDGDG"),
-	 * with DMI_MATCH(DMI_BOARD_NAME, "ROCKY"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "LG",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
-		},
-	},
-	/* NEC - OSI(Linux) effect unknown */
-	{
-	.callback = dmi_unknown_osi_linux,
-	.ident = "NEC VERSA M360",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "NEC Computers SAS"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "NEC VERSA M360"),
-		},
-	},
-	/* Panasonic */
-	{
-	.callback = dmi_unknown_osi_linux,
-	.ident = "Panasonic",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Matsushita"),
-			/* Toughbook CF-52 */
-		     DMI_MATCH(DMI_PRODUCT_NAME, "CF-52CCABVBG"),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "Samsung Electronics"
-	 *
-	 * OSI(Linux) disables PNP0C32 and other BIOS code for Windows:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "R40P/R41P"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "R59P/R60P/R61P"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Samsung",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "Sony Corporation"
-	 *
-	 * _OSI(Linux) is a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "VGN-NR11S_S"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "VGN-SZ38GP_C"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "VGN-SZ650N"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "VGN-TZ21MN_N"),
-	 * _OSI(Linux) unknown effect:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "VGN-FZ11M"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Sony",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
-		},
-	},
-	/*
-	 * Disable OSI(Linux) warnings on all "TOSHIBA"
-	 *
-	 * _OSI(Linux) breaks sound (bugzilla 7787):
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P100"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P105"),
-	 * _OSI(Linux) is a NOP:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A100"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A210"),
-	 * _OSI(Linux) unknown effect:
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A135"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A200"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P205"),
-	 * DMI_MATCH(DMI_PRODUCT_NAME, "Satellite U305"),
-	 */
-	{
-	.callback = dmi_disable_osi_linux,
-	.ident = "Toshiba",
-	.matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
-		},
-	},
 	{}
 };
 
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 4be2521..c811142 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -35,7 +35,6 @@
 #include <linux/interrupt.h>
 #include <linux/kmod.h>
 #include <linux/delay.h>
-#include <linux/dmi.h>
 #include <linux/workqueue.h>
 #include <linux/nmi.h>
 #include <linux/acpi.h>
@@ -97,54 +96,44 @@ static DEFINE_SPINLOCK(acpi_res_lock);
 static char osi_additional_string[OSI_STRING_LENGTH_MAX];
 
 /*
- * "Ode to _OSI(Linux)"
+ * The story of _OSI(Linux)
  *
- * osi_linux -- Control response to BIOS _OSI(Linux) query.
+ * From pre-history through Linux-2.6.22,
+ * Linux responded TRUE upon a BIOS OSI(Linux) query.
  *
- * As Linux evolves, the features that it supports change.
- * So an OSI string such as "Linux" is not specific enough
- * to be useful across multiple versions of Linux.  It
- * doesn't identify any particular feature, interface,
- * or even any particular version of Linux...
+ * Unfortunately, reference BIOS writers got wind of this
+ * and put OSI(Linux) in their example code, quickly exposing
+ * this string as ill-conceived and opening the door to
+ * an un-bounded number of BIOS incompatibilities.
  *
- * Unfortunately, Linux-2.6.22 and earlier responded "yes"
- * to a BIOS _OSI(Linux) query.  When
- * a reference mobile BIOS started using it, its use
- * started to spread to many vendor platforms.
- * As it is not supportable, we need to halt that spread.
+ * For example, OSI(Linux) was used on resume to re-POST a
+ * video card on one system, because Linux at that time
+ * could not do a speedy restore in its native driver.
+ * But then upon gaining quick native restore capability,
+ * Linux has no way to tell the BIOS to skip the time-consuming
+ * POST -- putting Linux at a permanent performance disadvantage.
+ * On another system, the BIOS writer used OSI(Linux)
+ * to infer native OS support for IPMI!  On other systems,
+ * OSI(Linux) simply got in the way of Linux claiming to
+ * be compatible with other operating systems, exposing
+ * BIOS issues such as skipped device initialization.
  *
- * Today, most BIOS references to _OSI(Linux) are noise --
- * they have no functional effect and are just dead code
- * carried over from the reference BIOS.
- *
- * The next most common case is that _OSI(Linux) harms Linux,
- * usually by causing the BIOS to follow paths that are
- * not tested during Windows validation.
- *
- * Finally, there is a short list of platforms
- * where OSI(Linux) benefits Linux.
- *
- * In Linux-2.6.23, OSI(Linux) is first disabled by default.
- * DMI is used to disable the dmesg warning about OSI(Linux)
- * on platforms where it is known to have no effect.
- * But a dmesg warning remains for systems where
- * we do not know if OSI(Linux) is good or bad for the system.
- * DMI is also used to enable OSI(Linux) for the machines
- * that are known to need it.
+ * So "Linux" turned out to be a really poor chose of
+ * OSI string, and from Linux-2.6.23 onward we respond FALSE.
  *
  * BIOS writers should NOT query _OSI(Linux) on future systems.
- * It will be ignored by default, and to get Linux to
- * not ignore it will require a kernel source update to
- * add a DMI entry, or a boot-time "acpi_osi=Linux" invocation.
+ * Linux will complain on the console when it sees it, and return FALSE.
+ * To get Linux to return TRUE for your system  will require
+ * a kernel source update to add a DMI entry,
+ * or boot with "acpi_osi=Linux"
  */
-#define OSI_LINUX_ENABLE 0
 
 static struct osi_linux {
 	unsigned int	enable:1;
 	unsigned int	dmi:1;
 	unsigned int	cmdline:1;
 	unsigned int	known:1;
-} osi_linux = { OSI_LINUX_ENABLE, 0, 0, 0};
+} osi_linux = { 0, 0, 0, 0};
 
 static void __init acpi_request_region (struct acpi_generic_address *addr,
 	unsigned int length, char *desc)
@@ -1296,34 +1285,6 @@ acpi_status acpi_os_release_object(acpi_cache_t * cache, void *object)
 	return (AE_OK);
 }
 
-/**
- *	acpi_dmi_dump - dump DMI slots needed for blacklist entry
- *
- *	Returns 0 on success
- */
-static int acpi_dmi_dump(void)
-{
-
-	if (!dmi_available)
-		return -1;
-
-	printk(KERN_NOTICE PREFIX "DMI System Vendor: %s\n",
-		dmi_get_system_info(DMI_SYS_VENDOR));
-	printk(KERN_NOTICE PREFIX "DMI Product Name: %s\n",
-		dmi_get_system_info(DMI_PRODUCT_NAME));
-	printk(KERN_NOTICE PREFIX "DMI Product Version: %s\n",
-		dmi_get_system_info(DMI_PRODUCT_VERSION));
-	printk(KERN_NOTICE PREFIX "DMI Board Name: %s\n",
-		dmi_get_system_info(DMI_BOARD_NAME));
-	printk(KERN_NOTICE PREFIX "DMI BIOS Vendor: %s\n",
-		dmi_get_system_info(DMI_BIOS_VENDOR));
-	printk(KERN_NOTICE PREFIX "DMI BIOS Date: %s\n",
-		dmi_get_system_info(DMI_BIOS_DATE));
-
-	return 0;
-}
-
-
 /******************************************************************************
  *
  * FUNCTION:    acpi_os_validate_interface
@@ -1350,21 +1311,6 @@ acpi_os_validate_interface (char *interface)
 			osi_linux.cmdline ? " via cmdline" :
 			osi_linux.dmi ? " via DMI" : "");
 
-		if (!osi_linux.dmi) {
-			if (acpi_dmi_dump())
-				printk(KERN_NOTICE PREFIX
-					"[please extract dmidecode output]\n");
-			printk(KERN_NOTICE PREFIX
-				"Please send DMI info above to "
-				"linux-acpi@vger.kernel.org\n");
-		}
-		if (!osi_linux.known && !osi_linux.cmdline) {
-			printk(KERN_NOTICE PREFIX
-				"If \"acpi_osi=%sLinux\" works better, "
-				"please notify linux-acpi@vger.kernel.org\n",
-				osi_linux.enable ? "!" : "");
-		}
-
 		if (osi_linux.enable)
 			return AE_OK;
 	}
-- 
1.5.6.5

[PATCH 11/11] ACPICA: disable _BIF warning

[Len Brown]

From: Lin Ming <ming.m.lin@intel.com>

A generic work-around from ACPICA is in the queue,
but since Linux has a work-around in its battery
driver, we can disable this warning now.

Allow _BIF method to return an Package with Buffer elements

http://bugzilla.kernel.org/show_bug.cgi?id=11822

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 include/acpi/acpredef.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/acpi/acpredef.h b/include/acpi/acpredef.h
index e6452db..16a9ca9 100644
--- a/include/acpi/acpredef.h
+++ b/include/acpi/acpredef.h
@@ -167,7 +167,7 @@ static const union acpi_predefined_info predefined_names[] = {
 	{.info = {"_BFS", 1, 0}},
 	{.info = {"_BIF", 0, ACPI_RTYPE_PACKAGE}}, {.ret_info = {ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER,
 					  9,
-					  ACPI_RTYPE_STRING, 4, 0}},	/* fixed (9 Int),(4 Str) */
+					  ACPI_RTYPE_STRING | ACPI_RTYPE_BUFFER, 4, 0}},	/* fixed (9 Int),(4 Str) */
 	{.info = {"_BLT", 3, 0}},
 	{.info = {"_BMC", 1, 0}},
 	{.info = {"_BMD", 0, ACPI_RTYPE_PACKAGE}}, {.ret_info = {ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 5, 0, 0, 0}},	/* fixed (5 Int) */
-- 
1.5.6.5

Re: [PATCH 01/11] ACPI: EC: count interrupts only if called from interrupt handler.

[Alan Jenkins]

On 11/27/08, Len Brown <lenb@kernel.org> wrote:
> From: Alexey Starikovskiy <astarikovskiy@suse.de>
>
> fix 2.6.28 EC interrupt storm regression
>
> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---

Yay, this means my EeePC no longer reports interrupt storms.

The patch looks obviously correct.  What about -stable?  -stable has
all the previous EC fixes, so I assume it's affected by this
regression.

The patch solves a bug I was about to report.  In storm avoidance
mode, the polling is still not 100% robust against the flaky EC.

1) If I hold down brightness up/down and then remove the power cable,
the EC stops working immediately.

2) I had an odd one-off occasion with the familiar "out of sync
hotkeys" & eventual EC death.

Thanks
Alan

>  drivers/acpi/ec.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index cf41f9f..30f3ef2 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -219,7 +219,8 @@ static void gpe_transaction(struct acpi_ec *ec, u8
> status)
>  	goto unlock;
>  err:
>  	/* false interrupt, state didn't change */
> -	++ec->curr->irq_count;
> +	if (in_interrupt())
> +		++ec->curr->irq_count;
>  unlock:
>  	spin_unlock_irqrestore(&ec->curr_lock, flags);
>  }
> --
> 1.5.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 01/11] ACPI: EC: count interrupts only if called from interrupt handler.

[Alexey Starikovskiy]

Alan Jenkins wrote:
> On 11/27/08, Len Brown <lenb@kernel.org> wrote:
>   
>> From: Alexey Starikovskiy <astarikovskiy@suse.de>
>>
>> fix 2.6.28 EC interrupt storm regression
>>
>> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
>> Signed-off-by: Len Brown <len.brown@intel.com>
>> ---
>>     
>
> Yay, this means my EeePC no longer reports interrupt storms.
>
>   
Great!
> The patch looks obviously correct.  What about -stable?  -stable has
> all the previous EC fixes, so I assume it's affected by this
> regression.
>   
IMHO, Rafael already marked it for stable.

> The patch solves a bug I was about to report.  In storm avoidance
> mode, the polling is still not 100% robust against the flaky EC.
>
>   
My current understanding is that firmware for this controller is not 
written as a state machine,
and breaks if more than one timed action occurs.
I've found a contact with eeePC project manager and asked him about the 
whole "interrupt storm" issue,
but did not get any reply yet...
> 1) If I hold down brightness up/down and then remove the power cable,
> the EC stops working immediately.
>   
Probably, may be, you don't supposed to do it? :)
> 2) I had an odd one-off occasion with the familiar "out of sync
> hotkeys" & eventual EC death.
>
> Thanks
> Alan
>
>   
>>  drivers/acpi/ec.c |    3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> index cf41f9f..30f3ef2 100644
>> --- a/drivers/acpi/ec.c
>> +++ b/drivers/acpi/ec.c
>> @@ -219,7 +219,8 @@ static void gpe_transaction(struct acpi_ec *ec, u8
>> status)
>>  	goto unlock;
>>  err:
>>  	/* false interrupt, state didn't change */
>> -	++ec->curr->irq_count;
>> +	if (in_interrupt())
>> +		++ec->curr->irq_count;
>>  unlock:
>>  	spin_unlock_irqrestore(&ec->curr_lock, flags);
>>  }
>> --
>> 1.5.6.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>     
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>