[PATCH 0/5] improved knobs to deal with OSI(Linux)

[PATCH 0/5] improved knobs to deal with OSI(Linux)

[Len Brown]

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.

[PATCH 1/5] DMI: move dmi_available declaration to linux/dmi.h

[Len Brown]

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

Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/firmware/dmi-id.c |    2 --
 include/linux/dmi.h       |    2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
index bc132d8..313c99c 100644
--- a/drivers/firmware/dmi-id.c
+++ b/drivers/firmware/dmi-id.c
@@ -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)
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index 00fc7a9..b1251b2 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -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

[PATCH 2/5] DMI: create dmi_dump_entries()

[Len Brown]

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

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

Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/firmware/dmi_scan.c |   19 +++++++++++++++++++
 include/linux/dmi.h         |    2 ++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 0cdadea..11e475d 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -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;
+}
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index b1251b2..61469f6 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -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

[PATCH 3/5] ACPI: use dmi_dump_entries() instead of requesting dmidecode output

[Len Brown]

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

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

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

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index e3a673a..3c767e7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -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 linux-acpi@vger.kernel.org\n");
+			"Please send DMI info above to "
+			"linux-acpi@vger.kernel.org\n");
 		if(osi_linux)
 			return AE_OK;
 	}
-- 
1.5.4.rc3.14.g44397

[PATCH 4/5] ACPI: OSI(Linux) cmdline and DMI BIOS workarounds

[Len Brown]

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

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.

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

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3c767e7..5204731 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -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 "
-			"linux-acpi@vger.kernel.org\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 "
+				"linux-acpi@vger.kernel.org\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 linux-acpi@vger.kernel.org\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

[PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Len Brown]

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

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

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 5204731..0bfebda 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Matthew Garrett]

On Thu, Jan 17, 2008 at 05:24:50AM -0500, Len Brown wrote:

> +	{
> +	.callback = dmi_enable_osi_linux,
> +	.ident = "Lenovo ThinkPad T61",
> +	.matches = {
> +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"),
> +		},
> +	},
> +

If we add it for specific devices, aren't vendors going to assume that 
future versions of that device will also be able to rely on this 
behaviour? I'm very reluctant to add whitelisting - I suspect it makes 
more sense for us to just be compatible with Windows. My experiments 
with the T61 suggested that it was possible to get everything working 
without this, but I'll need to go back and check what the behaviour 
actually was to be sure.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Thu, 17 Jan 2008, Matthew Garrett wrote:
> On Thu, Jan 17, 2008 at 05:24:50AM -0500, Len Brown wrote:
> 
> > +	{
> > +	.callback = dmi_enable_osi_linux,
> > +	.ident = "Lenovo ThinkPad T61",
> > +	.matches = {
> > +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"),
> > +		},
> > +	},
> > +
> 
> If we add it for specific devices, aren't vendors going to assume that 
> future versions of that device will also be able to rely on this 
> behaviour? I'm very reluctant to add whitelisting - I suspect it makes 
> more sense for us to just be compatible with Windows. My experiments 
> with the T61 suggested that it was possible to get everything working 
> without this, but I'll need to go back and check what the behaviour 
> actually was to be sure.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Len Brown]

On Thursday 17 January 2008 07:28, Matthew Garrett wrote:
> On Thu, Jan 17, 2008 at 05:24:50AM -0500, Len Brown wrote:
> 
> > +	{
> > +	.callback = dmi_enable_osi_linux,
> > +	.ident = "Lenovo ThinkPad T61",
> > +	.matches = {
> > +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"),
> > +		},
> > +	},
> > +
> 
> If we add it for specific devices, aren't vendors going to assume that 
> future versions of that device will also be able to rely on this 
> behaviour?

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'm very reluctant to add whitelisting - I suspect it makes  
> more sense for us to just be compatible with Windows. My experiments 
> with the T61 suggested that it was possible to get everything working 
> without this, but I'll need to go back and check what the behaviour 
> actually was to be sure.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Theodore Tso]

On Thu, Jan 17, 2008 at 03:04:26PM -0500, Len Brown wrote:
> On Thursday 17 January 2008 07:28, Matthew Garrett wrote:
> > On Thu, Jan 17, 2008 at 05:24:50AM -0500, Len Brown wrote:
> > 
> > > +	{
> > > +	.callback = dmi_enable_osi_linux,
> > > +	.ident = "Lenovo ThinkPad T61",
> > > +	.matches = {
> > > +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > > +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"),
> > > +		},
> > > +	},
> > > +
> > 
> > If we add it for specific devices, aren't vendors going to assume that 
> > future versions of that device will also be able to rely on this 
> > behaviour?
> 
> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Len Brown]

On Thursday 17 January 2008 16:31, Theodore Tso wrote:
> On Thu, Jan 17, 2008 at 03:04:26PM -0500, Len Brown wrote:
> > On Thursday 17 January 2008 07:28, Matthew Garrett wrote:
> > > On Thu, Jan 17, 2008 at 05:24:50AM -0500, Len Brown wrote:
> > > 
> > > > +	{
> > > > +	.callback = dmi_enable_osi_linux,
> > > > +	.ident = "Lenovo ThinkPad T61",
> > > > +	.matches = {
> > > > +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > > > +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"),
> > > > +		},
> > > > +	},
> > > > +
> > > 
> > > If we add it for specific devices, aren't vendors going to assume that 
> > > future versions of that device will also be able to rely on this 
> > > behaviour?
> > 
> > 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.
> 
> 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.

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.

> 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.

vendors who care about Linux run this:

http://linuxfirmwarekit.org/

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

thanks,
-Len

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Sat, 19 Jan 2008, Len Brown wrote:
> and if they did, nobody updates their bios anyway.

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.

> > 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.
> 
> vendors who care about Linux run this:
> 
> http://linuxfirmwarekit.org/
> 
> So I think if shout there, then it we'll be heard.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Theodore Tso]

On Sat, Jan 19, 2008 at 10:08:30AM -0200, Henrique de Moraes Holschuh wrote:
> 
> 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...

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!

> > vendors who care about Linux run this:
> > 
> > http://linuxfirmwarekit.org/
> > 
> > So I think if shout there, then it we'll be heard.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Sat, 19 Jan 2008, Theodore Tso wrote:
> On Sat, Jan 19, 2008 at 10:08:30AM -0200, Henrique de Moraes Holschuh wrote:
> > 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...
> 
> 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?

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.

> Tradeoffs either way!

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Matthew Garrett]

On Sat, Jan 19, 2008 at 01:33:04PM -0200, Henrique de Moraes Holschuh wrote:

> 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.

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 | mjg59@srcf.ucam.org

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Theodore Tso]

On Sat, Jan 19, 2008 at 03:43:28PM +0000, Matthew Garrett wrote:
> 
> 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.
> 

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Len Brown]

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.

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Rafael J. Wysocki]

Hi,

On Sunday, 20 of January 2008, Len Brown wrote:
> 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.

The plan sounds good to me, FWIW.

Thanks,
Rafael

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Tomas Carnecky]

Len Brown wrote:
>    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).

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Len Brown]

On Sunday 20 January 2008 07:03, Tomas Carnecky wrote:
> Len Brown wrote:
> >    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).
> 
> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Tomas Carnecky]

Len Brown wrote:
> On Sunday 20 January 2008 07:03, Tomas Carnecky wrote:
>> Len Brown wrote:
>>>    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).
>> 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.
> 
> 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...

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

> 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.

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.

> 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.

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

> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Theodore Tso]

On Sun, Jan 20, 2008 at 01:31:59PM -0500, Len Brown wrote:
> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Matthew Garrett]

On Sun, Jan 20, 2008 at 08:52:38PM -0500, Theodore Tso wrote:

> 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.  

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 | mjg59@srcf.ucam.org

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Theodore Tso]

On Mon, Jan 21, 2008 at 09:50:00AM +0000, Matthew Garrett wrote:
> > 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.  
> 
> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Matthew Garrett]

On Mon, Jan 21, 2008 at 02:00:41PM -0500, Theodore Tso wrote:

> Well, unless until Video card vendors give us their secret interfaves
> to reinitialize their cards, we're never going to figure it out,
> right?  

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...

> 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.  :-)
 
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 | mjg59@srcf.ucam.org

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Len Brown]

On Monday 21 January 2008 14:37, Matthew Garrett wrote:
> On Mon, Jan 21, 2008 at 02:00:41PM -0500, Theodore Tso wrote:
> 
> > Well, unless until Video card vendors give us their secret interfaves
> > to reinitialize their cards, we're never going to figure it out,
> > right?  
> 
> 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...
> 
> > 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.  :-)
>  
> 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. 

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.

> If vendors want their laptops to work on Linux, then the best thing  
> they can do is help us get our drivers working properly.

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?

> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Sat, 19 Jan 2008, Theodore Tso wrote:
> 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.  

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.

> 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....

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Thomas Renninger]

Hi,

On Sun, 2008-01-20 at 17:49 -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 19 Jan 2008, Theodore Tso wrote:
> > 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.  
> 
> 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.

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.

> > 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....
> 
> 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.
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...

> 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...
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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Mon, 18 Feb 2008, Thomas Renninger wrote:
> 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.

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.

> 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.

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

> 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.

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.

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

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.

> > 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...
> Yep nobody would ever do this.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Thomas Renninger]

On Mon, 2008-02-18 at 16:17 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 18 Feb 2008, Thomas Renninger wrote:
> > 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.
> 
> 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)?
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...

> 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.
Not for us, we can just pass the kernel version and check for
greater/less.

> > 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.
> 
> You need it to be more fine-grained than that, a LOT more fine-grained.
No you need not. It would be fine, but it's better than nothing.

> > 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.
> 
> 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.
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.

> > But now that it happens we should react quickly and come up with a
> > robust interface for the future...
> 
> 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.
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...).

> 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.
?!?
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.

> > > 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...
> > Yep nobody would ever do this.
> 
> 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.
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Theodore Tso]

On Tue, Feb 19, 2008 at 01:00:59AM +0100, Thomas Renninger wrote:
> 
> Most stuff that gets fixed by these workarounds would make no sense to
> backport, because backports are much too intrusive, e.g.:

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Thomas Renninger]

On Mon, 2008-02-18 at 19:26 -0500, Theodore Tso wrote:
> On Tue, Feb 19, 2008 at 01:00:59AM +0100, Thomas Renninger wrote:
> > 
> > Most stuff that gets fixed by these workarounds would make no sense to
> > backport, because backports are much too intrusive, e.g.:
> 
> Many of the workarounds really aren't that hard to backport,
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.
>  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.
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?

> 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.)
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Mon, 18 Feb 2008, Theodore Tso wrote:
> On Tue, Feb 19, 2008 at 01:00:59AM +0100, Thomas Renninger wrote:
> > Most stuff that gets fixed by these workarounds would make no sense to
> > backport, because backports are much too intrusive, e.g.:
> 
> Many of the workarounds really aren't that hard to backport, and the

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.

> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Thomas Renninger]

On Mon, 2008-02-18 at 16:17 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 18 Feb 2008, Thomas Renninger wrote:
> > 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.
> 
> 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)?

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Tue, 19 Feb 2008, Thomas Renninger wrote:
> > 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)?
> 
> So you think on next Lenovo pre-load we should compile a "SLED10 SP2"

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.

> 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

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.

> 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.

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

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Thomas Renninger]

On Tue, 2008-02-19 at 11:24 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 19 Feb 2008, Thomas Renninger wrote:
> > > 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)?
> > 
> > So you think on next Lenovo pre-load we should compile a "SLED10 SP2"
> 
> 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.
> 
> > 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
> 
> 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.
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...

> 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.
> 
> > 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.
> 
> We all agree on that, Thomas.
Puhhh... good. So I have missed the one or other suggestion or there are
no suggestions yet?

> 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.

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Thomas Renninger wrote:
> > 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.
> 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

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 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.

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.

> 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...

**** 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 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.
> 
> 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 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.

> 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.

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

[PATCH 6/5] ACPI: DMI blacklist for OSI(Linux)

[Len Brown]

Subject: ACPI: Fill in DMI blacklist for OSI(Linux)
From: Len Brown <len.brown@intel.com>

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.

Signed-off-by: Len Brown <len.brown@intel.com>
---
 blacklist.c |  577 ++++++++++++++++++++++++++++++++++++++++
 osl.c       |   57 ---
 2 files changed, 579 insertions(+), 55 deletions(-)

diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 7c24a8d..85bbc53 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -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 */
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index ee1a630..78bdddc 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -110,7 +110,7 @@ struct osi_linux {
 } osi_linux = { OSI_LINUX_ENABLE, 0, 0, 0};
 
 #ifdef CONFIG_DMI
-static struct __initdata dmi_system_id acpi_osl_dmi_table[];
+extern struct __initdata dmi_system_id acpi_osl_dmi_table[];
 #endif
 
 static void __init acpi_request_region (struct acpi_generic_address *addr,
@@ -973,7 +973,7 @@ static void cmdline_osi_linux(unsigned int enable)
 	return;
 }
 
-static void dmi_osi_linux(int enable, const struct dmi_system_id *d)
+void dmi_osi_linux(int enable, const struct dmi_system_id *d)
 {
 	osi_linux.dmi = 1;	/* DMI knows that this box asks OSI(Linux) */
 
@@ -1246,57 +1246,4 @@ acpi_os_validate_address (
     return AE_OK;
 }
 
-#ifdef CONFIG_DMI
-
-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)
-{
-	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_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"),
-		     },
-	 },
-	{
-	.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
-	 */
-
-	/*
-	 * Boxes that request _OSI(Linux), but proper default is unknown
-	 */
-	{}
-};
-#endif /* CONFIG_DMI */
-
 #endif

Re: [PATCH 6/5] ACPI: DMI blacklist for OSI(Linux)

[Andi Kleen]

Len Brown <lenb@kernel.org> writes:
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -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

IA64 sets CONFIG_DMI too. So it won't be x86 specific as written.
Probably shoud check for CONFIG_X86 too.

> +extern void dmi_osi_linux(int enable, const struct dmi_system_id *d);

That should be in some include, shouldn't it?

-Andi

Re: [PATCH 6/5] ACPI: DMI blacklist for OSI(Linux)

[Len Brown]

On Saturday 19 January 2008 03:16, Andi Kleen wrote:
> Len Brown <lenb@kernel.org> writes:
> > --- a/drivers/acpi/blacklist.c
> > +++ b/drivers/acpi/blacklist.c
> > @@ -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
> 
> IA64 sets CONFIG_DMI too. So it won't be x86 specific as written.
> Probably shoud check for CONFIG_X86 too.

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...

> > +extern void dmi_osi_linux(int enable, const struct dmi_system_id *d);
> 
> That should be in some include, shouldn't it?

yes.

thanks,
-Len