improved knobs to deal with OSI(Linux)

I've tested this patch series on a T61.
I need to harvest the dmidecode's sent to the list and append them to this patch series.

From: Len Brown <[email protected]>

---
 drivers/firmware/dmi-id.c |    2 --
 include/linux/dmi.h       |    2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

index bc132d8..313c99c 100644
@@ -173,8 +173,6 @@ static struct device *dmi_dev;
 	if (dmi_get_system_info(_field)) \
 		sys_dmi_attributes[i++] = &sys_dmi_##_name##_attr.dev_attr.attr;
 
-extern int dmi_available;
-
 /* In a separate function to keep gcc 3.2 happy - do NOT merge this in
    dmi_id_init! */
 static void __init dmi_id_init_attr_table(void)

index 00fc7a9..b1251b2 100644
@@ -78,6 +78,7 @@ extern const struct dmi_device * dmi_find_device(int type, const char *name,
 extern void dmi_scan_machine(void);
 extern int dmi_get_year(int field);
 extern int dmi_name_in_vendors(const char *str);
+extern int dmi_available;
 
 #else
 

@@ -87,6 +88,7 @@ static inline const struct dmi_device * dmi_find_device(int type, const char *na
 	const struct dmi_device *from) { return NULL; }
 static inline int dmi_get_year(int year) { return 0; }
 static inline int dmi_name_in_vendors(const char *s) { return 0; }
+#define dmi_available 0
 
 #endif
 

1.5.4.rc3.14.g44397

From: Len Brown <[email protected]>

Create a routine to dump the requested DMI entries to the console.

---
 drivers/firmware/dmi_scan.c |   19 +++++++++++++++++++
 include/linux/dmi.h         |    2 ++
 2 files changed, 21 insertions(+), 0 deletions(-)

index 0cdadea..11e475d 100644
@@ -470,3 +470,22 @@ int dmi_get_year(int field)
 	return year;
 }
 
+/**
+ *	dmi_dump_entries - print DMI entries to console
+ *	@entries:	bit-mask specifying dmi_field(s)
+ *
+ *	Returns 0 on success
+ */
+int dmi_dump_entries(int entries)
+{
+	int index;
+
+	if (!dmi_available)
+		return -1;
+
+	for (index = 0; index < DMI_STRING_MAX; ++index) {
+		if (entries & (1 << index))
+			printk(KERN_INFO "%d. %s\n", index, dmi_ident[index]);
+	}
+	return 0;
+}

index b1251b2..61469f6 100644
@@ -79,6 +79,7 @@ extern void dmi_scan_machine(void);
 extern int dmi_get_year(int field);
 extern int dmi_name_in_vendors(const char *str);
 extern int dmi_available;
+extern int dmi_dump_entries(int entries);
 
 #else
 

@@ -89,6 +90,7 @@ static inline const struct dmi_device * dmi_find_device(int type, const char *na
 static inline int dmi_get_year(int year) { return 0; }
 static inline int dmi_name_in_vendors(const char *s) { return 0; }
 #define dmi_available 0
+static inline int dmi_dump_entries(int entries) { return -1; }
 
 #endif
 

1.5.4.rc3.14.g44397

From: Len Brown <[email protected]>

Dump DMI data to console instead of asking users to run dmidecode.

---
 drivers/acpi/osl.c |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)

index e3a673a..3c767e7 100644
@@ -1141,6 +1141,18 @@ acpi_status acpi_os_release_object(acpi_cache_t * cache, void *object)
 	return (AE_OK);
 }
 
+/*
+ * The DMI entries to dump to the screeen
+ * for easy DMI blacklist creation from dmesg.
+ */
+#define DMI_INTERESTING_ENTRIES (\
+	(1 << DMI_BIOS_VENDOR) | \
+	(1 << DMI_BIOS_DATE) | \
+	(1 << DMI_SYS_VENDOR) | \
+	(1 << DMI_PRODUCT_NAME) | \
+	(1 << DMI_PRODUCT_VERSION) | \
+	(1 << DMI_BOARD_NAME))
+
 /******************************************************************************
  *
  * FUNCTION:    acpi_os_validate_interface

@@ -1162,10 +1174,13 @@ acpi_os_validate_interface (char *interface)
 	if (!strcmp("Linux", interface)) {
 		printk(KERN_WARNING PREFIX
 			"System BIOS is requesting _OSI(Linux)\n");
+		if (dmi_dump_entries(DMI_INTERESTING_ENTRIES))
+			printk(KERN_WARNING
+			"[please extract dmidecode output]\n");
 		printk(KERN_WARNING PREFIX
 			"If \"acpi_osi=Linux\" works better,\n"
-			"Please send dmidecode "
-			"to [email protected]\n");
+			"Please send DMI info above to "
+			"[email protected]\n");
 		if(osi_linux)
 			return AE_OK;
 	}

1.5.4.rc3.14.g44397

From: Len Brown <[email protected]>

Allow "acpi_osi=Linux" and "acpi_osi=!Linux" cmdline to override DMI.

If DMI for the system known already, don't ask for it again.

If DMI known, but proper default not known, request just test results.

---
 drivers/acpi/osl.c |  136 +++++++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 114 insertions(+), 22 deletions(-)

index 3c767e7..5204731 100644
@@ -77,7 +77,37 @@ static struct workqueue_struct *kacpi_notify_wq;
 #define	OSI_STRING_LENGTH_MAX 64	/* arbitrary */
 static char osi_additional_string[OSI_STRING_LENGTH_MAX];
 
-static int osi_linux;		/* disable _OSI(Linux) by default */
+/*
+ * osi_linux -- Control response to BIOS _OSI(Linux) query.
+ *
+ * The OS Interface string "Linux" is ill-defined,
+ * as it specifies no particuar feature, and the
+ * features of Linux evolve from release to release.
+ *
+ * It was an error when Linux-2.6.22 and earlier
+ * responded "yes" to a BIOS _OSI(Linux) query.
+ * A reference BIOS started using it and opened Pandora's box:
+ *
+ * OSI(Linux) may:
+ * 1. help
+ * 2. hurt
+ * 3. be a NOP
+ * and only DMI can tell which is which...
+ *
+ * Today, there seems to be more exposure for "hurt" and "NOP"
+ * than "help".  So starting with Linux-2.6.23, OSI(Linux)
+ * is disablbed by default.  #define OSI_LINUX_ENABLE 1 to enable it.
+ *
+ * BIOS writers are asked to NOT query _OSI(Linux) going forward.
+ */
+#define OSI_LINUX_ENABLE 0
+
+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};
 
 #ifdef CONFIG_DMI
 static struct __initdata dmi_system_id acpi_osl_dmi_table[];

@@ -964,13 +994,39 @@ static int __init acpi_os_name_setup(char *str)
 
 __setup("acpi_os_name=", acpi_os_name_setup);
 
-static void enable_osi_linux(int enable) {
+static void set_osi_linux(unsigned int enable)
+{
+	if (osi_linux.enable != enable) {
+		osi_linux.enable = enable;
+		printk(KERN_INFO PREFIX "%sed _OSI(Linux)\n",
+			enable ? "Add": "Delet");
+	}
+	return;
+}
 
-	if (osi_linux != enable)
-		printk(KERN_INFO PREFIX "%sabled _OSI(Linux)\n",
-			enable ? "En": "Dis");
+static void cmdline_osi_linux(unsigned int enable)
+{
+	osi_linux.cmdline = 1;	/* cmdline set the default */
+	set_osi_linux(enable);
+
+	return;
+}
+
+static void dmi_osi_linux(int enable, const struct dmi_system_id *d)
+{
+	osi_linux.dmi = 1;	/* DMI knows that this box asks OSI(Linux) */
+
+	printk(KERN_NOTICE PREFIX "%s detected\n", d->ident);
+
+	if (enable == -1)
+		return;
+
+	osi_linux.known = 1;	/* DMI knows hich OSI(Linux) default needed */
+
+	/* Set default via DMI only if no cmdline override */
+	if (!osi_linux.cmdline)
+		set_osi_linux(enable);
 
-	osi_linux = enable;
 	return;
 }
 

@@ -987,12 +1043,12 @@ static int __init acpi_osi_setup(char *str)
 		printk(KERN_INFO PREFIX "_OSI method disabled\n");
 		acpi_gbl_create_osi_method = FALSE;
 	} else if (!strcmp("!Linux", str)) {
-		enable_osi_linux(0);
+		cmdline_osi_linux(0);	/* !enable */
 	} else if (*str == '!') {
 		if (acpi_osi_invalidate(++str) == AE_OK)
 			printk(KERN_INFO PREFIX "Deleted _OSI(%s)\n", str);
 	} else if (!strcmp("Linux", str)) {
-		enable_osi_linux(1);
+		cmdline_osi_linux(1);	/* enable */
 	} else if (*osi_additional_string == '\0') {
 		strncpy(osi_additional_string, str, OSI_STRING_LENGTH_MAX);
 		printk(KERN_INFO PREFIX "Added _OSI(%s)\n", str);

@@ -1172,16 +1228,32 @@ acpi_os_validate_interface (char *interface)
 	if (!strncmp(osi_additional_string, interface, OSI_STRING_LENGTH_MAX))
 		return AE_OK;
 	if (!strcmp("Linux", interface)) {
-		printk(KERN_WARNING PREFIX
-			"System BIOS is requesting _OSI(Linux)\n");
-		if (dmi_dump_entries(DMI_INTERESTING_ENTRIES))
-			printk(KERN_WARNING
-			"[please extract dmidecode output]\n");
-		printk(KERN_WARNING PREFIX
-			"If \"acpi_osi=Linux\" works better,\n"
-			"Please send DMI info above to "
-			"[email protected]\n");
-		if(osi_linux)
+
+		if (!osi_linux.dmi) {
+			printk(KERN_WARNING PREFIX
+				"_OSI(Linux) requested "
+				"by unknown system BIOS\n");
+			if (dmi_dump_entries(DMI_INTERESTING_ENTRIES))
+				printk(KERN_WARNING
+					"[please extract dmidecode output]\n");
+			printk(KERN_WARNING PREFIX
+				"Please send DMI info above to "
+				"[email protected]\n");
+		} else {
+			printk(KERN_WARNING PREFIX
+				"_OSI(Linux) %sabled %s\n",
+				osi_linux.enable ? "En" : "Dis",
+				osi_linux.cmdline ? "via cmdline" :
+					"for known system BIOS");
+		}
+		if (!osi_linux.known) {
+			printk(KERN_WARNING PREFIX
+				"If \"acpi_osi=%sLinux\" works better,"
+				"please notify [email protected]\n",
+				osi_linux.enable ? "!" : "");
+		}
+
+		if (osi_linux.enable)
 			return AE_OK;
 	}
 	return AE_SUPPORT;

@@ -1214,25 +1286,45 @@ acpi_os_validate_address (
 }
 
 #ifdef CONFIG_DMI
-static int dmi_osi_linux(const struct dmi_system_id *d)
+
+static int dmi_enable_osi_linux(const struct dmi_system_id *d)
+{
+	dmi_osi_linux(1, d);	/* enable */
+	return 0;
+}
+#ifdef	ACPI_FUTURE_USAGE
+static int dmi_disable_osi_linux(const struct dmi_system_id *d)
 {
-	printk(KERN_NOTICE "%s detected: enabling _OSI(Linux)\n", d->ident);
-	enable_osi_linux(1);
+	dmi_osi_linux(0, d);	/* disable */
 	return 0;
 }
+static int dmi_unknown_osi_linux(const struct dmi_system_id *d)
+{
+	dmi_osi_linux(-1, d);	/* unknown */
+	return 0;
+}
+#endif
 
 static struct dmi_system_id acpi_osl_dmi_table[] __initdata = {
 	/*
 	 * Boxes that need _OSI(Linux)
 	 */
 	{
-	 .callback = dmi_osi_linux,
+	 .callback = dmi_enable_osi_linux,
 	 .ident = "Intel Napa CRB",
 	 .matches = {
 		     DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
 		     DMI_MATCH(DMI_BOARD_NAME, "MPAD-MSAE Customer Reference Boards"),
 		     },
 	 },
+
+	/*
+	 * Boxes that need _OSI(Linux) NOT set
+	 */
+
+	/*
+	 * Boxes that request _OSI(Linux), but proper default is unknown
+	 */
 	{}
 };
 #endif /* CONFIG_DMI */

1.5.4.rc3.14.g44397

From: Len Brown <[email protected]>

---
 drivers/acpi/osl.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

index 5204731..0bfebda 100644
@@ -1317,6 +1317,15 @@ static struct dmi_system_id acpi_osl_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_BOARD_NAME, "MPAD-MSAE Customer Reference Boards"),
 		     },
 	 },
+	{
+	.callback = dmi_enable_osi_linux,
+	.ident = "Lenovo ThinkPad T61",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"),
+		},
+	},
+
 
 	/*
 	 * Boxes that need _OSI(Linux) NOT set

1.5.4.rc3.14.g44397

There is interesting data for you about the T61 and X61 in the linux-thinkpad ML (also available through gmane).

The T61 *latest BIOS* (this can well make a difference):

without OSI(Linux)
* Mutes in firmware (but nobody knows HOW or WHAT it mutes)
* Doesn't propagate the MUTE event through ACPI or Keyboard
* Mute can be detected throgh NVRAM (probably)
* Uses Volume UP/DOWN press to unmute in firmware

* Propagates volume up/down through the keyboard
* does not change volume up/down in firmware

with OSI(Linux)
* Does not mute in firmware
* Propagates MUTE even through keyboard
* Propagates volume up/down through the keyboard
* does not change volume up/down in firmware

And I hear the T61 has some weirdness in the HDA mixer too, but I don't know what ALSA is doing. One should also test if the missing ALSA registers are available with/without OSI(Linux), and do it using a *proper* full alsa client, like amixer, because the GUI ones can't deal with stuff like two mute controls in one single channel, etc. And look at the ALSA code to see if they are not special-casing the thinkpad in some way that is actually hurting instead of helping (depending on OSI(Linux) state).

Nobody managed to find how the firmware was muting the sound yet. Maybe Lenovo just dumbed down the extra mixer to a mute/unmute thing (it has full volume control in older thinkpads), instead of just removing it entirely.

The X61 seems to be nearly the same as the T61.

I really, really prefer the old firmware that just *always worked* in the volume control. Now Lenovo switched tactics for one reason or another, and IMHO, the only sane way forward is to try to get to the least surprising behaviour (which happens to be the one we get with OSI(Linux).

I suggest that any "experiments" be carried out in the open in the linux-thinkpad mailinglist, requesting input from other people.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

When the new product comes out and they
try Linux on it, OSI(Linux) will return FALSE unless somebody (later) adds the new product to the white-list.

So if a vendor really cares about Linux, they'll know during development that they can't count on OSI(Linux) returning TRUE.

I agree that white-lists are horrible.
And I blame myself for not deleting OSI(Linux) before 2.6.23. For pandora's box has been opened and when OSI(Linux) went into a reference BIOS, and it will be difficult to close it to get back on the "Windows compatible" track that makes the most sense for Linux.

Happily, most of the cases I've seen are simply NOP code inherited from a reference BIOS, but in some cases the OEM really did test with (some version of) Linux and made firmware changes to make their product function properly.
I think there are just a few of these cases, and
I think it is actually more common to see systems
where OSI(Linux) causes random BIOS behaviour.
The later case is the one we need to fear, and
why we need to be dilligent about stamping out OSI(Linux)=TRUE. But at the same time, I think we really need a whilte-list to make some products ship. I believe that we'll
see an example from Dell shortly on S3 video restore.
I may not have been noticed yet b/c they're running pre-2.6.23.

I expect most of the "white-list" entries will actually just document the casese where OSI(Linux) is presnet, but has no effect. The white-list action in that case is simply to disable the warnings and request for testing.

-Len

Maye the whitelist should use very specific BIOS version numbers as part of the DMI_MATCH, and we encourage the vendors to remove the OSI(Linux) specific hacks moving forward? After all, the workarounds are only needed for the very latest BIOS versions, and if we can manage to convince vendors to make them go away, then maybe after some particular BIOS version, we won't need to do anything special.

Perhaps if there was a well documented, "this is what we want" from the Linux community, which can then get communicated to Lenovo, HP, Dell, etc.? This document could include a request that Laptop vendors document how various things work when they do vendor-specific things, and also documenting what Linux is doing today because we believe it's what is the Windows-compatible behaviour.

- Ted

I don't really want to get bogged down on individual BIOS Versions. I don't expect vendors would want to change mid-course anyway -- and if they did, nobody updates their bios anyway.

vendors who care about Linux run this:

http://linuxfirmwarekit.org/

So I think if shout there, then it we'll be heard.

thanks,
-Len

Actually, that only depends on us. If you drop support for people using known-bad BIOS versions that give you greif, they have no choice but to go away, or to upgrade. And so far, I have never had anyone complain that they had to update their thinkpad BIOS and just go away.

Of course, I am terribly nice about it when I ask someone to upgrade their BIOS, but still...

On the thinkpad-specific case, I don't actually mind tracking down the last-known-sane BIOS version for every thinkpad model and bitching like a madman on thinkpad-acpi telling people to update because it is known buggy and unsupported if their BIOS is too old. We already sort of track every important BIOS version of every model anyway in ThinkWiki...

I can easily see the T61 and X61 as prime candidates for a "upgrade the BIOS before reporting any bugs" printk.

Indeed. But are we allowed to drop support on any BIOS that fails those checks as soon as there is a new version of that BIOS that doesn't?

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

More importantly, what worries me is exactly the issue which Len raised; what if OSI(Linux) enables some things that we desperately want, and at the same time, enables some things that we don't want? Maybe it's OK for now to have lots of model specific workarounds regarding whether we throw the Big Binary Switch of OSIL(Linux), but what if in the future that's not enough.

It may be hard to make vendors change designs mid-course, yes, but it may be even harder in the future, and even more of a disaster. Maybe the answer is we don't use OSI(Linux) in the future, but we use a series of OS compatibility OSI switches. Even then, we'll need to know when we should use OSI(Linux), and when we don't, which means we'll have to track BIOS versions. I almost wonder if we're better not putting any model-specific versions at all, and then work really hard to influence the vendors, as opposed to a "half-way pregnant" approach where we whitelist individual models, but not BIOS versions....

Tradeoffs either way!

Sure --- do we have the right language in linuxfirmwarekit.org to talk about issues such as Windows- and Linux- specific behaviours and how to handle OSI(<foo>) issues?

- Ted

That worries me as well. On the ThinkPad case, that means we need to move *fast* and reach an agreement with Lenovo, while they are still actively developing the current crop of BIOSes.

Which means we need to agree among ourselves on a course of action, *document it* properly, check with Lenovo and any other vendor which is reasonably Linux-friendly if it is something they can agree to use, and get it into the firmware kit.

Yes. This is no easy problem asking for a quick hack as a solution. It is not impossible to solve, but it will definately require more than hacks on our side to get it done properly.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

The only way to get it done properly is to ensure that we're compatible with Windows, and to get vendors to tell us when we're not. Offering them any mechanism that allows them to special-case Linux will just lead to them doing so and ignoring the problem, which will probably then trip up other systems that don't special-case Linux. Let's not go down this path. The fact that we're even having to have this conversation should indicate that it's not a good idea.

Matthew Garrett | [email protected]

Sure, and that means they have to *tell* *us* what they are doing so we can be compatible with Windows. The concern is that they may be doing stuff that isn't in the standard ACPI spec, but which needs to be a certain way in order to be compatible with their proprietary Windows drivers.

The real problem comes when they decide to do things in a rush. That is, Dell deciding they want to make their laptops compatible with an already existing Ubuntu kernel, or Lenovo deciding they want to make their laptops compatible with an already existing SUSE kernel. And, so they decide to do a quick and dirty firmware release rather than negotiating with the distribution to do an Errata kernel. If we don't agressive move to nip this in the bud, even if a particular Thinkpad kernel isn't in the whitelist, I can see them simply documenting a workaround of setting acpi_osi=Linux in the boot command line, because it's easier than getting a distro to release a new kernel with a patch needed to support some new laptop....

- Ted

Ted, Henrique, Matthew,

Thank you for your wise words.

Here is my plan.

1. notify Intel mobile BIOS group that Linux will STOP answering "yes" to OSI(Linux), that they should STOP using OSI(Linux) in their BIOS, and that Linux will complain about them when they do.

I believe this team is the "upstream" cause of the majority of OSI(Linux) in the field today.

I did this last year -- and they were not happy about it. The laptops vendors were not happy either.

However, as it is unsupportable in the long run, I assert we have no choice.

Yes, we need a mitigation plan, for Linux tries to be Windows compatible, but the reality is that we use the platform differently in many areas. Graphics and platform specific drivers top the list,
and a long list of platform workarounds fill it out.

I am okay with defining OSI strings for the benefit of BIOS vendors that need to know about Linux capabilities. But the string must identify that specific capability (or lack of a capability).

The first on the list would be a way to tell the BIOS that it should restore video on S3 resume. This is off on Windows b/c it is faster for a native driver to do it. But Linux doesn't yet have native drivers that can do this. So we need to be able to ask the BIOS to do this for us until we do -- and then we need to be able to _stop_ asking the BIOS when we have native graphics driver support in place. (This is an example of why "Linux" is a poor choice for a capability string -- once you use it, when can you _stop_ using it?)

2. Transition Linux from OSI(Linux) to !OSI(Linux)

Linux-2.6.21 was the last kernel with OSI(Linux) by default w/o complaint. Linux-2.6.22 was the last kernel with OSI(Linux) by default, but it complains. Linux-2.6.23 was the first kernel with !OSI(Linux) by default, and it still complains.

3. Clean up any wreckage

That is where we are now. The goal is to identify the products that really do need OSI(Linux) and help them keep shipping.

There are 3 types of OSI(Linux) users:

1) most laptops with OSI(Linux) inherited it from the refernece code and don't actually use it for anything.

Linux will complain about these, until we get their DMI and tell Linux to stop complaining. But with or without DMI, OSI(Linux) is off for these systems.

2) laptops where OSI(Linux) causes a failure.
This is the case I'm most worried about, because it is just like the _OS=Linux issue in the old days, which means it has unbounded risk of failure in the field.

As the default in 2.6.23 and later is to disable OSI(Linux) these systems work by default going forward,
and we just need their DMI to quiet them up,
like we did for case #1. I do actually use an
OSI-disable DMI hook for these rather than an OSI-ignore DMI, in case somebody wants to build the kernel with it enabled by default.

3) OSI(Linux) added by the vendor that actually makes a Linux SKU work. The good/bad news is that there are very few real laptop Linux SKUs, so indentifying them and dealing with them is finite.

As OSI(Linux) is disabled by default today, any vendor
that wants it to be enabled for their product will have
to get a change into Linux, whether it be a bootparam
or a white-list entry. I think having this barrier to entry is good, in that it is motivation to avoid doing the wrong thing.

thanks,
-Len

ps. I say laptops above. I've seen OSI(Linux) on a few Dell desktops,
but otherwise I've only seen it spread to laptops.

Hi,

The plan sounds good to me, FWIW.

Thanks,
Rafael

Is there a chance this will be added to future ACPI specs, or have it standardized in one way or another? I think that would be not only good for Linux, but all other UNIX-like operating systems as well (and maybe Windows as well).

Not that I care, really, but for me as an outsider to the whole ACPI domain, it seems _OSI() isn't a well thought out interface. Checking for an OS name rather than individual capabilities may not matter as much under Windows, but for Linux, with its rather short release cycle, it certainly does.

tom

Originally, there was _OS="<insert your OS name>" to identify the OS to the BIOS. We proudly answered _OS="Linux" and broke every BIOS on Earth
that assumed that the only two choices for _OS
which corresponded to Win98 and WinNT.
That is why _OS="Microsoft Windows NT" is hardwired
into Linux and any other OS that is concerned about
following what has proven to be the only tested
path through the BIOS.

So naming the OS turned out to be a failure (for everybody, not just for Linux -- consider that XP and Vista claim they are NT according to _OS or they hit the same BIOS bugs we do...)

_OSI is supposed to tell the BIOS what interfaces the OS supports, for example "Extended Address Space Descriptor".

However, it is being mis-used to identify the
version of the OS, which is why you see this:

static char *acpi_interfaces_supported[] = {
        /* Operating System Vendor Strings */

        "Windows 2000",         /* Windows 2000 */
        "Windows 2001",         /* Windows XP */
        "Windows 2001 SP1",     /* Windows XP SP1 */
        "Windows 2001 SP2",     /* Windows XP SP2 */
        "Windows 2001.1",       /* Windows Server 2003 */
        "Windows 2001.1 SP1",   /* Windows Server 2003 SP1 - Added 03/2006 */
        "Windows 2006",         /* Windows Vista - Added 03/2006 */

ie. basically the OS name is a proxy for all the interfaces that OS supports. Taken another way, OS-version-specific quirks and workarounds are included in the definition of that interface...

We could do the same with Linux, except that
1. the string "Linux" is even more poorly defined than those above, as it has no version information.
2. the presence of the string "Linux" tends to break as many BIOS' implementations as it fixes -- because it isn't universally tested.

So if new strings come up in the ACPI spec, we can use standard strings. But I don't think the ACPI spec is necessary to address Linux' problem-at-hand.

We as the Linux community can define "Needs BIOS S3 video restore" as a string and ship it in our kernel, telling BIOS writers about it.
However, we'd reserve the right to _stop_ answering YES to a query on that string when we no longer need it.

cheers,
-Len

So _OSI _is_ a good interface, it's just being misused. Thanks for the explanation.

Who came up with the idea to use "Linux"? After what you described above, this seems even worse choice then what Windows does - they at least have some information about the version in it.

After what you explained above, I don't think either, the ACPI spec is ok.

Still, it would be nice to have these strings somehow standardized. Maybe Intel and other vendors or BIOS developers come up with something and document it properly, include some of the most important strings in the ACPI spec? Because if Linux starts using some strings and Windows or BSD different strings, there will surely be a mess - again.

tom

Maybe we should define the S3 video strong right away, along with whatever else Lenovo was trying to use OSI(Linux) for, and then get the distro's to ship Errata kernels that answer yes for those questions ASAP. Then we can work with Laptop vendors to release new BIOS's that use the new OSI strings instead of Linux, since they can just tell people that they need to upgrade to the latest Ubuntu/SLES kernel.

Hopefully, this would allow us to recover from this mess as quickly as possible.

- Ted

I'd prefer to figure out what they're actually doing with it, since clearly Windows doesn't need this. I'm not especially comfortable with the S3 video stuff, but it seems safer - I just strongly suspect that giving vendors a "Please reinitialise video when exiting S3" option will be abused as a general "Linux" indicator.

Matthew Garrett | [email protected]

Well, unless until Video card vendors give us their secret interfaves to reinitialize their cards, we're never going to figure it out, right? At least for vendors like Lenovo, where some laptops will be shipping with Intel cards where we will eventually be able do our own video reinit after suspend, and some with Nvidia chipsets where it doesn't seem terribly likely until someone at Nvidia has a change of heart, the BIOS won't be able to use the "please reinit video" as a general "Linux" indicator, since they will need to support laptops with Good as well as Evil graphics chipsets. :-)

- Ted

There's (not yet mainline) code to do this on Intel, and it looks like AtomBios based ATIs (some r400s, all r500s and later) should be trivial. The work the Nouveau people have been doing is also very promising, and I suspect we can do cold boot there before too long. I was going to do some work on this this week, but my ATI machine got stolen...

The problem is that we don't inherently know if we can support reinitialising video natively until the video driver is loaded, and there's a high probability that that's going to come from a module. We're already executing ACPI by then, so the firmware's had the opportunity to stash an incorrect value and can blow everything up later on. If vendors want their laptops to work on Linux, then the best thing they can do is help us get our drivers working properly.

Another disadvantage is that there's no real chance that Linux will be tested in the "No, really, I can handle my graphics myself" case. Relying on their firmware guys to get this right is inviting the fuckup fairy to come and start nesting - Lenovo have already shown us what happens when we let vendors try to be clever.

Now, stuff like a standardised entrypoint into ACPI that reinitialises the video - that would be helpful, since we could choose whether to call it or not which means whether or not something gets screwed up is determined by us and not the vendor.

Matthew Garrett | [email protected]

Right, if we go down this path, we'd have to do it as a boot parameter in order to enable/disable the hook before any platform AML gets a chance to see it.

note that acpi_osi=string and acpi_osi=!string are available starting in 2.6.23. You get to add up to 1 string, and you get to remove as many pre-existing strings as you like.

of course, this trick would require the distro installer to know tha a native-video driver were present, and modify the bootparms accordingly.

True. For Intel graphics, Intel/OTC is working on getting this fixed. It has not been a quick fix -- the pipeline is long...

Maybe the quick fix is to enhance the workarounds in s2ram and simply deal with it that way until native video drivers are available?

Even if we (Linux) proposed this and it got added to the spec, it wouldn't have any real effect b/c windows doesn't need it, so most machines wouldn't implement it. Smarter native video drivers is clearly the preferred path.

-Len

Or to be compatible with both Windows XP and Vista ACPI subsystems, *and* the Windows XP and Vista versions of their proprietary drivers. This is probably where half the weirdness in Lenovo ThinkPads come from, IMHO.

Well, in defense of Lenovo, at least they seem to be quite open to changing future BIOSes if we are really clear on what we request *and* we provide a solution that won't cause total breakage on the kernels already in the Wild.

But asking any hardware vendor to do something that will work right with the next version of Linux but will break hideously what distros have been shipping already just won't fly. Anything we do has to work well on both past and current kernels, unfortunately.

Now, the real test will be if we ask for something that would require changing their Windows drivers. I sure hope they would do it, but...

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Hi,

The problem is that OSI is used by Windows to pass the exact Windows (not OS) version they are running, this function should be called WOSI. We of course want to run on the latest fix-ups here and should pass "Windows 2006" (or whatever latest string there exists).

IMO we need the same for Linux.
We even have the advantage, that the string in LOSI(String) makes some sense, e.g. 2.6.24, so why not use LOSI(int, int, int)
How the exact interface might look like I am not sure, just an idea.

I disagree.
AML is a whole language, you can add stuff like:
if (losi < 2.6.24)
Store (0x1, ecxy)
else if (losi > 2.6.25)
Store (0x3, ecxy)

A)
Vendors *must* have a flag for Linux to be able to provide proper support for multiple kernels and to be able to provide easy and riskless fixes for Linux at all.

B)
ACPI interpreter patches are mostly very intrusive and distros cannot backport them. E.g. you don't want to add an EC fix which fixes all ASUS machines, but possibly breaks some others..., you don't want to backport suspend reordering, or a simple sizeOf (part of AML) enhancement which fixes some machines, might break some very other specific ones. You should nearly never ever backport an AML fix, better let vendors do kernel specific workarounds if they are willing to.

I expect we now have this problem because nobody (including myself) never dreamed of that it could ever happen that a vendor adds Linux specific AML code.

But now that it happens we should react quickly and come up with a robust interface for the future...

Yep nobody would ever do this.
But it's no problem for vendors at all to add a hotfix like that to their BIOS:
if (linux)
..
else if (windows)
..

Thomas

Looks quite a bad idea IMO. 2.6.24 means what? SuSE's? Mainline's? Debian's? At what patch level? With which user patches tacked on top? And at what level of userspace support (X.org can make a LOT of difference here)?

No, if you are going to go about that, use OSI to ask about specific support you need, like Len said. Yes, this might mean a lot of OSI strings.

You need it to be more fine-grained than that, a LOT more fine-grained.

Then WTF did we start shipping an OSI(Linux) string in the first place? Don't tell me it was done just for the heck of it.

Len already explained what is needed, and I added how to do it in a way that it would be accepted from my experience with vendors.

Basically, it needs to be fine-grained and function-specific, AND it must be allow for near-perfect backward and forward compatibility or it will be a lot more difficult to see it get any use.

I have some doubts about the "nobody", but you'd have to present a heck of a good case.

BTW, I am perfectly happy with OSI(Linux) being used to disable crap that is only relevant to work around *bugs* in windows drivers. But that's not how most vendors use it.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Every distribution is based on a specific kernel, right?

Most stuff that gets fixed by these workarounds would make no sense to backport, because backports are much too intrusive, e.g.:
- AML interpreter workarounds
- suspend to ram (s3bios or kernel graphics driver support)
- suspend order
- FSC V5505 does not like a specific EC write done with

    Osi="Windows 2006" -> easy to workaround for the vendor, they
    already implement "Linux" as Osi string
    http://bugzilla.kernel.org/show_bug.cgi?id=9939

- Lenovo brightness (Internal Intel graphics card needs kernel graphics driver supported for their BQC, BCL, BCM implementation) This will never ever be possible to backport
- Dozens more...

Not for us, we can just pass the kernel version and check for greater/less.

No you need not. It would be fine, but it's better than nothing.

Right..., it's invoked by BIOS and the kernel can return true on multiple strings.
It's a good idea, not perfect yet. Removing it with the dmi white/black list..., puhhhh, IMO not a good idea.

Len wants to get rid of it after BIOS vendors finally started to use it, I got that now. And what should be the replacement?
This whole dmi white/black listing to use osi(linux) or not cannot be
the final solution?
I didn't really realize what is going on, I did a short double delete on most osi=linux mails of the past weeks..., what was your way that you think gets accepted by vendors?

Vendors need a knob for their BIOS fixes, that should be proven since so many are using osi=linux for some time now (since some came up with pre-loads I expect...).

?!?
It simply must be knob which vendors can use to place AML code in for which they can be sure that it's only processed on Linux. That would vendors already help a lot to release a BIOS fix (for which everybody
screams: those broken BIOS'es AML code does not get fixed up by the vendors...).
This will reduce the QA vendors have to do: Only need to test one OS when releasing a BIOS fix.
Or for most it's an argument to do a fix for Linux *at all*. I wouldn't risk any line of code for an OS that runs on 5% of my sold machines..., maybe if it's "if(linux)" embedded. And fact is, there are not much laptop models sold on which Windows is not the most common used Operation System (Macs maybe...).
So either you get them a reasonable possibility to fix their BIOSes or you end up blacklisting forever.

This is what we do for years, right?
We do it that way, because Windows is doing it on that machine..., it breaks some others... then better do the middle of it, or better dmi blacklist the one and the other machine...
Sorry, but this:
"ACPI: add DMI to enable OSI(Linux) on ThinkPad T61" cannot be the solution. A blacklist for Linux specific BIOS workarounds...

Why not moving these very machine specific workarounds into the BIOS, this is what we always wanted, get it fixed in the BIOS?
Or even better, the vendors already do some QA on it and make sure that the machine works perfectly with the latest kernel xy.

I am already perfectly happy to disable crap that just makes the machine work perfectly with the latest kernels and this is what these guys are doing.

Maybe I just missed it, but there is no replacement for osi=linux vendor workarounds decided/discussed yet?

Thomas

-
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

Many of the workarounds really aren't that hard to backport, and the reality is after the distro locks down their kernel version in stone, and people start complaining about buggy support for the X300 laptop, or some such, the temptation will be *very* high to put in special hacks in the thinkpad_acpi driver for some bleeding edge new laptop by backporting code from a newer kernel, or grabbing a patch which is being discussed on the linux-thinkpad list, etc.

So I don't think it's a good idea to assume that a single kernel version string such as 2.6.25 will have any reliability whatsoever about identifying what sort of driver workarounds might or might not be present given a particular distribution or custom kernel compiled by a user. (I normally pull in the acpi test tree into my kernels, so often my "2.6.25" kernel will have stuff that might not show up until 2.6.26.)

Regards,

- Ted

It's not about how hard, it is about the risk.
And you never want to backport e.g. AML fixes in the very heart of the interpreter. Even Intel run it through all their verification suites it will break the one or other certified machine.

If instead a small junk of AML code can be written and the vendor embeds it, in a for him safe "if(linux)" environment... that would be cool. For the vendor and for the distributions, not needing another quirk/blacklist whatever ugly hack.

This is about support, right? The thing Len is always propagating which is so important for distributions...

The ThinkPad drivers backports are huge.
I didn't take the backports because of this.
The thinkpad driver is not that important..., newer models should work and it only affects the thinkpad driver, the some thousand line changes will break some machines for sure and regressions is the worst thing to have after a product came out.
But maybe this is even doable for e.g. 10.3.
A backport of AML fixes affecting every machine is impossible to do in an update for RedHat or SUSE Enterprise products or whatever really stable release is impossible to do.

Next point:
E.g. evaluation of whether to take 7 or 15 brightness levels is a dirty hack. In fact most of the Thinkpad driver is a dirty hack. Now that vendors care about supporting the systems, why not moving dirty hacks into the BIOS?

A vendor sells a machine pre-loaded with a specific product which is bound to a specific kernel!

Do you pay money if your kernel breaks machines at least for regressions?
Ok you at least take customer calls or better mails :)
...

Thomas

-
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

Agreed.

Not only that, but one of the corrent things that OSI(Linux) changes in a certain vendor platform in the real world is actually something we will want to modify depending on the *X.org* server evolution (and, if we ever get around to it, our in-kernel framebuffer capabilities, too).

That's a clean-cut, real-world example of something that any sort of "kernel version" OSI(Linux) solution would not help with.

IMO, we got ourselves into this mess for taking a shortcut ("hello AML, I am Linux"), instead of doing the full job in the first place and pushing for it ("hello AML, I need you to always post the video adapter when resuming"). Let's not make that mistake *again*.

Unlike Windows, we are a very fast moving target and we have very long-lived hardware users. We can't take half measures on forward and backwards compatibility information to the hardware and firmware without it causing painful issues down the road.

That is not even temptation, that's exactly what happens, and IMHO that's *how it is supposed to work* in the first place...

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

So you think on next Lenovo pre-load we should compile a "SLED10 SP2" into our kernel and let Lenovo BIOS fixups use it? E.g. we could use the default BCM/BQC/BCL brightness interface easily then, just a small if(SLED10_SP2) in the BIOS. A one-liner, it can only effect the very specific Lenovo models that are effected. This is much more appropriate then adding a backport, better say "most dirty hack of the month" (That's not your fault Henrique and by no means meant as an offence..., we both know about the ugliness of these BIOS workarounds) of ibm_acpi to 2.6.16! guessing brightness levels which has high risk to break other ThinkPads and even if not, you move all the QA (not much to do if embedded into such Linux/SUSE/kern_ver condition), and dirty hacks to the vendor...).

Please let us not end up with hacks like "SLED10 SP2", "FEISTY" or whatever weirdness and this will come if we ignore osi=linux or do not provide something else.
We should make up something more robust and more Linux kernel appropriate and propagate it to the vendors.

Thomas

-
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

Huh?! No, I don't. I would walk away in disgust if we did it. OSI(SLED10 SP2) would be even worse than OSI(Linux) plus a OS<whatever>(2.6.24), I think I can safely assume that we *all* agree on THAT one.

AFAIK, there is no problem with the *ACPI* brightness firmware on ThinkPads. At all. Its only quirk is that you want to call _BCL at least once at driver load.

Anyway, the whole backlight brightness stink is our (as in Linux kernel people, userspace people, distro people) doing. The laptop vendors, for once, had nothing to do with it. Also, for once, the ACPI 3.0 specification (when correctly implemented in the AML *and* ACPI OSI) does give us all we need to have it work properly in any way we see fit.

Since the brightness issues have *nothing* to do with OSI(anything), let's leave it for another thread.

We all agree on that, Thomas.

I am actually arguing for something *even* more fine-grained than a kernel version, but at the same time completely independent of kernel versions, so that if we backport something, or our userspace improves, we can stop (or start) advertising it through OSI() without messing with anything else.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

No it's not that it's:
- you call BCLL, a totally undefined AML function, found out by DSDT examination..., Lenovo is allowed to and will change the name this function at some time, they even could for a BIOS update
- It is that we have to use the ibm_acpi driver quirks for an interface that is specified and which nearly every Vista compatible machine is providing.
You need special handling for Lenovos. You need to blacklist them to not use the well defined interface, but use the ibm_acpi quirks.

I really like to ask Lenovo to add a (on Intel graphics cards):
if (linux)
call _BCM/BQC/BCL this way
else
 call _BCM/BQC/BCL the other way
All this should be only some simple AML lines...
and simply use the video driver for Lenovo backlight switching...

Puhhh... good. So I have missed the one or other suggestion or there are no suggestions yet?

IMO kernel version is enough and the right thing, everything else is over-designed (please provide an example, I cannot imagine anything useful/generic but only osi=linux or better osi=linux + kernel version).

I start a new thread/discussion now. I was quite late with reading up the list and this is important and should get some more attention also by others who might not have read into this thread.

Thomas

-
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

That's gone in my devel tree, already. A first incarnation of it is even out on the latest thinkpad-acpi devel snapshot (it works, but it has a lot
of thinkos, so I changed it a lot). thinkpad-acpi only calls _BCL now.

And that's hardly Lenovo's fault, *I* chose to call BCLL, their standard ACPI interface works just fine. The reason I switched from _BCL to BCLL was that you warned me that _BCL had "side-effects". Unfortunately, it took me this long to realise the side-effects were desired ones.

It is the other way around. thinkpad-acpi detects that ACPI generic brightness control exists, and refuses to load its own interface to avoid races with video.c and ACPI.

And if you need thinkpad-acpi's interface instead of the one provided by video.c in a Lenovo ThinkPad, it is likely due to bugs in video.c. Or it is because X.org is making sure you have to use RandR backlight control.

**** DO NOT DO THIS! ****

Please, if you ever find yourself in a position to ask anything of the sort from Lenovo, CC me. And, preferably, we should talk about it first so we can reach an agreement and present a single position to Lenovo.

As far as I know, there is *nothing* wrong with the Lenovo-provided _BCM/BQC/BCL handlers. If thinkpad-acpi gave you *any* ideas about asking Lenovo to change their DSDTs, please run them by me first, it is likely something I should change in thinkpad-acpi.

And we have to get the X.org people in the loop *as* *well*. X.org wants to do the backlight switching directly in some drivers, because it is safer (no SMIs! Anything that avoids an SMI is a Good Thing), faster (no ACPI calls, no context switches, no SMI traps!), and it often gives you even more control and levels than what is available through ACPI, for example.

We have to give userspace a sane way to tell the kernel to block access to any backlight interfaces dealing with a given video device. Again, this has nothing to do with Lenovo. We don't have any decent way to know what video device a backlight is tied to, either. That's something else that needs to be fixed.

We have a buggy drivers/acpi/video.c. It is being fixed, look at the git logs and bugzilla...

We have userspace fighting itself over how to handle KEY_BRIGHTNESS_*. It has to be fixed, too. Fortunately, it won't have to ALSO fight video.c anymore, the patch to stop that is already in mainline, although we might want to modify how that is done a bit to make life easier for the console warriors ;-)

Nothing in the my-goodness-this-is-fucked-up list of troubles plaguing brightness control on ThinkPads relates to Lenovo's _BCM/BQC/BCL handlers, AFAIK.

I did. X.org userspace video device POST on resume. It is a real-world example. Others have given you other reasons why a kernel version is not a perfect solution, too.

That I agree with fully :-)

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Subject: ACPI: Fill in DMI blacklist for OSI(Linux)
From: Len Brown <[email protected]>

move the existing list to blacklist.c from osl.c and fill it in with all known systems that query OSI(Linux).

dmi_unknown_osi_linux() is invoked to disable
the request for DMI info (as, by definition, we already have it) but to keep the request for acpi_osi= test results
so we can instead invoke it with dmi_enable_osi_linux() or dmi_disable_osi_linux() as appropriate.

---
 blacklist.c |  577 ++++++++++++++++++++++++++++++++++++++++
 osl.c       |   57 ---
 2 files changed, 579 insertions(+), 55 deletions(-)

index 7c24a8d..85bbc53 100644
@@ -1,6 +1,8 @@
 /*
  *  blacklist.c
  *
+ *  X86 specific ACPI blacklists.
+ *
  *  Check to see if the given machine has a known bad ACPI BIOS
  *  or if the BIOS is too old.
  *

@@ -165,3 +167,578 @@ int __init acpi_blacklisted(void)
 
 	return blacklisted;
 }
+#ifdef CONFIG_DMI
+extern void dmi_osi_linux(int enable, const struct dmi_system_id *d);
+
+static int dmi_enable_osi_linux(const struct dmi_system_id *d)
+{
+	dmi_osi_linux(1, d);	/* enable */
+	return 0;
+}
+static int dmi_disable_osi_linux(const struct dmi_system_id *d)
+{
+	dmi_osi_linux(0, d);	/* disable */
+	return 0;
+}
+static int dmi_unknown_osi_linux(const struct dmi_system_id *d)
+{
+	dmi_osi_linux(-1, d);	/* unknown */
+	return 0;
+}
+
+struct dmi_system_id acpi_osl_dmi_table[] __initdata = {
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer Aspire 5050",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer, inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5050"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer Aspire 5100",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5100"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer Aspire 5580",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer, inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5580"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer Aspire 5610",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5610"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer Aspire 7720Z",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720Z"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer TravelMate 5520",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5520"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer TravelMate 6460",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 6460"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer TravelMate 7510",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 7510"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer Extensa 5220",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5220"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Acer  Ferrari 5000",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Acer, inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Ferrari 5000"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Apple MacBook 1.1",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "MacBook1,1"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Apple MacBook 2.1",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "MacBook2,1"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Apple MacBookPro 1.1",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro1,1"),
+		},
+	},
+	{ /* OSI(Linux) is a NOP */
+	.callback = dmi_disable_osi_linux,
+	.ident = "Apple MacBookPro 2.2",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro2,2"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Apple MacBookPro 3.1",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro3,1"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Apple MacPro 2.1",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "MacPro2,1"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "BenQ",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "BenQ"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Joybook S31"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Clevo M570RU",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Clevo Co."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "M570RU"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Compal IFL91",
+	.matches = {
+		     DMI_MATCH(DMI_BIOS_VENDOR, "COMPAL"),
+		     DMI_MATCH(DMI_BOARD_NAME, "IFL91"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Compal HEL8X",
+	.matches = {
+		     DMI_MATCH(DMI_BIOS_VENDOR, "COMPAL"),
+		     DMI_MATCH(DMI_BOARD_NAME, "HEL8X"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Compal HEL8X",
+	.matches = {
+		     DMI_MATCH(DMI_BIOS_VENDOR, "COMPAL"),
+		     DMI_MATCH(DMI_BOARD_NAME, "HEL8X"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Dell Dimension 5150",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Dell DM051"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Dell",
+	.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",
+	.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",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex GX620"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Dell",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 1900"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Dell",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation 390"),
+		},
+	},
+	{ /* 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",
+	.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"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Fujitsu Siemens Amilo Si 1520",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Amilo M1425"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Fujitsu Siemens Amilo Si 1520",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Amilo Si 1520"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Fujitsu Siemens AMILO Pa 2510",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pa 2510"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Fujitsu Siemens AMILO Pi 1536",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pi 1536"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Fujitsu Siemens AMILO Pi 1556",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pi 1556"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Fujitsu Siemens AMILO Xi 1546",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Xi 1546"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Fujitsu Siemens Esprimo Mobile V5505",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Mobile V5505"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "HP Pavilion tx1000",
+	.matches = {
+		     DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30BF"),
+		},
+	},
+	{ /* OSI(Linux) is a NOP */
+	.callback = dmi_disable_osi_linux,
+	.ident = "HP Pavilion dv2000",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30B5"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "HP Pavilion dv5000",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30A7"),
+		},
+	},
+	{ /* OSI(Linux) breaks hibernate */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "HP Pavilion dv6000 30B7",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30B7"),
+		},
+	},
+	{ /* OSI(Linux) breaks hibernate */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "HP Pavilion dv6000",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30B8"),
+		},
+	},
+	{ /* OSI(Linux) breaks hibernate */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "HP Pavilion dv6300 30BC",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30BC"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "HP Pavilion dv6500",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30D0"),
+		},
+	},
+	{ /* OSI(Linux) is a NOP */
+	.callback = dmi_disable_osi_linux,
+	.ident = "HP Pavilion dv9000",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30B9"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "HP Pavilion dv9500",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30CB"),
+		},
+	},
+	{ /* OSI(Linux) is a NOP */
+	.callback = dmi_disable_osi_linux,
+	.ident = "HP/Compaq Presario C500",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30C6"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_disable_osi_linux,
+	.ident = "HP/Compaq Presario F500",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		     DMI_MATCH(DMI_BOARD_NAME, "30D3"),
+		},
+	},
+	{ /* OSI(Linux) assumed enabled by CRB BIOS developers */
+	 .callback = dmi_enable_osi_linux,
+	 .ident = "Intel Napa CRB",
+	 .matches = {
+		     DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
+		     DMI_MATCH(DMI_BOARD_NAME, "MPAD-MSAE Customer Reference Boards"),
+		     },
+	 },
+	{ /* OSI(Linux) helps sound */
+	.callback = dmi_enable_osi_linux,
+	.ident = "Lenovo ThinkPad R61",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad R61"),
+		},
+	},
+	{ /* OSI(Linux) helps sound */
+	.callback = dmi_enable_osi_linux,
+	.ident = "Lenovo ThinkPad T61",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Lenovo 3000 V100",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "LENOVO3000 V100"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Lenovo 3000 N100",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "3000 N100"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "LG P1 PRO Express Dual 150B",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "P1-J150B"),
+		},
+	},
+	{ /* 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"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Samsung R40P/R41P",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "R40P/R41P"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Samsung R59P/R60P/R61P",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "R59P/R60P/R61P"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Sony Vaio VGN-FZ11M",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "VGN-FZ11M"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Sony Vaio VGN-SZ650N",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "VGN-SZ650N"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Sony Vaio VGN-SZ38GP_C",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "VGN-SZ38GP_C"),
+		},
+	},
+	{ /* OSI(Linux) is a NOP */
+	.callback = dmi_disable_osi_linux,
+	.ident = "Sony Vaio TZ21MN",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "VGN-TZ21MN_N"),
+		},
+	},
+	{ /* OSI(Linux) is a NOP */
+	.callback = dmi_disable_osi_linux,
+	.ident = "Toshiba Satellite A100",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A100"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Toshiba Satellite A135",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A135"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Toshiba Satellite A200",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A200"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Toshiba Satellite A210",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite A210"),
+		},
+	},
+	{ /* OSI(Linux) breaks sound (bugzilla 7787) */
+	.callback = dmi_disable_osi_linux,
+	.ident = "Toshiba Satellite P100",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P100"),
+		},
+	},
+	{ /* OSI(Linux) breaks sound */
+	.callback = dmi_disable_osi_linux,
+	.ident = "Toshiba Satellite P105",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P105"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Toshiba Satellite P205",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P205"),
+		},
+	},
+	{ /* OSI(Linux) effect unknown */
+	.callback = dmi_unknown_osi_linux,
+	.ident = "Toshiba Satellite U305",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "Toshiba"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite U305"),
+		},
+	},
+	{}
+};
+#endif /* CONFIG_DMI */

drivers/acpi/Makefile causes blacklist.c to be X86 specific.

obj-$(CONFIG_X86) += blacklist.o

that is what I wanted (and IA64 can add their own blacklist if they need one). but if IA64 defines CONFIG_DMI,
then I just broke their build b/c acpi_osl_dmi_table will be undefined...

yes.

thanks,
-Len