public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: linux-pm <linux-pm@lists.linux-foundation.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Mairo <rety@poczta.onet.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	lenb <lenb@kernel.org>
Subject: Re: ACPI locks hardware devices when it doesn't detect vista
Date: Sat, 29 Aug 2009 21:50:41 +0300	[thread overview]
Message-ID: <1251571841.10321.1.camel@maxim-laptop> (raw)
In-Reply-To: <1251506453.28828.0.camel@maxim-laptop>

What do you think to do in this case:

On Sat, 2009-08-29 at 03:40 +0300, Maxim Levitsky wrote:
> Oh, and cc linux-acpi....
> 
> On Sat, 2009-08-29 at 02:53 +0300, Maxim Levitsky wrote:
> > On Sat, 2009-08-22 at 15:48 +0300, Maxim Levitsky wrote:
> > > Hi,
> > > 
> > > <joke>
> > > This should be brought to a Microsoft antitrust case...
> > > </joke>
> > > 
> > > 
> > > Today many notebooks ship with a embedded infrared receiver.
> > > In Vista there is new subsystem that decodes these signals.
> > > (of course it works only with Microsoft Certificated Remotes (TM)...)
> > > 
> > > The receiver is usually presented to system as a pnp device 
> > > (using acpi tables)
> > > 
> > > It turns out that some bioses actually use the OSI, ACPI feature of the
> > > operation system to detect if running inside Vista. If not they disable
> > > the infrared receiver.
> > > 
> > >             Device (MIR)
> > >             {
> > >                 Name (_HID, EisaId ("ENE0100"))
> > >                 Method (_STA, 0, NotSerialized)
> > >                 {
> > >                     If (LAnd (MCIR, LEqual (OSYS, 0x07D6)))
> > >                     {
> > >                         Return (0x0F)
> > >                     }
> > >                     Else
> > >                     {
> > >                         Store (Zero, ^^LPCB.IOR2)
> > >                         Return (Zero)
> > >                     }
> > >                 }
> > > 
> > > 	.......
> > > 
> > 
> > >     Scope (_SB)
> > >     {
> > >         Method (_INI, 0, NotSerialized)
> > >         {
> > 		....
> > 
> > >             If (CondRefOf (_OSI, Local0))
> > >             {
> > >                 If (_OSI ("Linux"))
> > >                 {
> > >                     Store (One, LINX)
> > >                     Store (Zero, ECDY)
> > >                 }
> > 
> >                   ..........
> > > 
> > 
> > >                 If (_OSI ("Windows 2006"))
> > >                 {
> > >                     Store (0x07D6, OSYS)
> > >                 }
> >                   .......
> > 
> > 
> > I have finally managed to find root case of this problem.
> > 
> > Indeed the _STA method of infrared receiver is called before the _INI of
> > _SB.
> > 
> > The problem lies in acpi_bus_init()
> > 	/*
> > 	 * ACPI 2.0 requires the EC driver to be loaded and work before
> > 	 * the EC device is found in the namespace (i.e. before acpi_initialize_objects()
> > 	 * is called).
> > 	 *
> > 	 * This is accomplished by looking for the ECDT table, and getting
> > 	 * the EC parameters out of that.
> > 	 */
> > 
> > 	status = acpi_ec_ecdt_probe();
> > 	/* Ignore result. Not having an ECDT is not fatal. */
> > 
> > 	status = acpi_initialize_objects(ACPI_FULL_INITIALIZATION);
> > 	if (ACPI_FAILURE(status)) {
> > 		printk(KERN_ERR PREFIX "Unable to initialize ACPI objects\n");
> > 		goto error1;
> > 	}
> >         .......
> > 
> > 
> > on Mairo's system (just as well as on mine) there is no ECDT.
> > Thus, acpi_ec_ecdt_probe() triggers a acpi namespace walk, 
> > which in turn triggers invocation on _STA (which is supposed to be
> > harmless, but the <beep>, the bios developers produce doesn't seem to
> > meet this criteria....).
> > 
> > And this is done before running _INI methods, which are run just later,
> > in acpi_initialize_objects.
> > 
> > I suspect that many systems use _SB._INI to test the OS version, thus
> > this behavior needs to be revised.
> > 
> > The fact that this (as usual) works in windows suggest that it might  be
> > good to look up the ECDT table before acpi_initialize_objects, but if
> > not found, look up the EC later.
> > 
> > On my system, although I have tried to reproduce this bug, I couldn't,
> > and I know now why: It just so happens that on my system CIR device is
> > listed in acpi tables after the EC, but on Mairo's system EC is just
> > first device.
> > 
> > Maybe we can add a 'walk only' function, that walks the namespace, but
> > doesn't touch the _STA, and use it to find the EC there?
> > 
> > Looking for comments,
> > 	Best regards,
> > 		Maxim Levitsky
> > 
> 

  reply	other threads:[~2009-08-29 18:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1250945310.14167.150.camel@maxim-laptop>
2009-08-22 21:41 ` ACPI locks hardware devices when it doesn't detect vista Rafael J. Wysocki
2009-08-22 22:02   ` Maxim Levitsky
2009-08-22 22:36     ` Maxim Levitsky
2009-08-23  0:02       ` Maxim Levitsky
2009-08-24 16:17         ` Maxim Levitsky
2009-08-24 18:47           ` Mario
     [not found] ` <1251503638.17451.14.camel@maxim-laptop>
2009-08-29  0:40   ` Maxim Levitsky
2009-08-29 18:50     ` Maxim Levitsky [this message]
2009-08-29 19:40   ` Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista) Rafael J. Wysocki
2009-08-29 19:51     ` Maxim Levitsky
2009-08-29 21:05       ` Mario
2009-08-29 22:37         ` Rafael J. Wysocki
2009-08-29 23:30           ` Maxim Levitsky
2009-08-30  6:59             ` Mario
2009-08-30 13:20               ` Rafael J. Wysocki

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=1251571841.10321.1.camel@maxim-laptop \
    --to=maximlevitsky@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rety@poczta.onet.pl \
    /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