From: Len Brown <lenb@kernel.org>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: linux-acpi@vger.kernel.org, Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
Date: Thu, 17 Jan 2008 15:04:26 -0500 [thread overview]
Message-ID: <200801171504.26361.lenb@kernel.org> (raw)
In-Reply-To: <20080117122832.GB32133@srcf.ucam.org>
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
next prev parent reply other threads:[~2008-01-17 20:04 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 10:24 [PATCH 0/5] improved knobs to deal with OSI(Linux) Len Brown
2008-01-17 10:24 ` [PATCH 1/5] DMI: move dmi_available declaration to linux/dmi.h Len Brown
2008-01-17 10:24 ` [PATCH 2/5] DMI: create dmi_dump_entries() Len Brown
2008-01-17 10:24 ` [PATCH 3/5] ACPI: use dmi_dump_entries() instead of requesting dmidecode output Len Brown
2008-01-17 10:24 ` [PATCH 4/5] ACPI: OSI(Linux) cmdline and DMI BIOS workarounds Len Brown
2008-01-17 10:24 ` [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61 Len Brown
2008-01-17 12:28 ` Matthew Garrett
2008-01-17 14:46 ` Henrique de Moraes Holschuh
2008-01-17 20:04 ` Len Brown [this message]
2008-01-17 21:31 ` Theodore Tso
2008-01-19 7:40 ` Len Brown
2008-01-19 12:08 ` Henrique de Moraes Holschuh
2008-01-19 14:17 ` Theodore Tso
2008-01-19 15:33 ` Henrique de Moraes Holschuh
2008-01-19 15:43 ` Matthew Garrett
2008-01-19 23:19 ` Theodore Tso
2008-01-20 4:13 ` Len Brown
2008-01-20 11:16 ` Rafael J. Wysocki
2008-01-20 12:03 ` Tomas Carnecky
2008-01-20 18:31 ` Len Brown
2008-01-20 19:21 ` Tomas Carnecky
2008-01-21 1:52 ` Theodore Tso
2008-01-21 9:50 ` Matthew Garrett
2008-01-21 19:00 ` Theodore Tso
2008-01-21 19:37 ` Matthew Garrett
2008-01-22 5:37 ` Len Brown
2008-01-20 19:49 ` Henrique de Moraes Holschuh
2008-02-18 16:58 ` Thomas Renninger
2008-02-18 19:17 ` Henrique de Moraes Holschuh
2008-02-19 0:00 ` Thomas Renninger
2008-02-19 0:26 ` Theodore Tso
2008-02-19 6:34 ` Thomas Renninger
2008-02-19 13:24 ` Henrique de Moraes Holschuh
2008-02-19 10:26 ` Thomas Renninger
2008-02-19 14:24 ` Henrique de Moraes Holschuh
2008-02-20 1:43 ` Thomas Renninger
2008-02-20 2:47 ` Henrique de Moraes Holschuh
2008-01-19 7:50 ` [PATCH 6/5] ACPI: DMI blacklist for OSI(Linux) Len Brown
2008-01-19 8:16 ` Andi Kleen
2008-01-20 4:18 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801171504.26361.lenb@kernel.org \
--to=lenb@kernel.org \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).