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

[Len Brown <lenb@kernel.org>]

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.