public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Matthew Garrett <mjg@redhat.com>,
	"Zhao, Yakui" <yakui.zhao@intel.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH]: ACPI: Add the dmi check to make acpi_enforce_resources strict
Date: Thu, 02 Apr 2009 17:18:58 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.0904021706520.4660@localhost.localdomain> (raw)
In-Reply-To: <1236738885.2820.168.camel@rzhang-dt>



On Wed, 11 Mar 2009, Zhang Rui wrote:

> On Tue, 2009-03-10 at 20:39 +0800, Matthew Garrett wrote:
> > On Tue, Mar 10, 2009 at 08:24:33PM +0800, yakui_zhao wrote:
> > > Subject: ACPI: Add the dmi check to make acpi_enforce_resources strict
> > > From: Zhao Yakui <yakui.zhao@intel.com>
> > > 
> > >    On some boxes the SMBus PCI controller is not hidden. The SMbus I/O port
> > > will be accessed in AML code. If the i2c driver is still loaded for the SMbus
> > > PCI device, there is no synchronization between OS and BIOS. And the conflict
> > > will happen.
> > >    So the dmi check is added so that the acpi_enforce_resources is strict when
> > > the box falls into the dmi check table. In such case the i2c driver won't be
> > > loaded for the SMbus pci device.
> > 
> > I think the only safe behaviour here is to default to strict on all 
> > hardware.
> > 
> we've discussed this with Len,
> he thinks that we should first generate a DMI patch to fix the eeepc901
> regression, which can be shipped upstream soon.
> then we'll cook up another patch, to set acpi_enforce_resources=strict
> by default, which should be shipped to len's test tree first, and see if
> there are any objections from the SMBus driver side.
> 
> Yakui will send the second patch out soon.

I agree with Matthew.

What I asked for what the DMI patch first -- something we could
send to .29 and .stable w/ minimum risk.

Then (later) on top of that...
a patch to make the DMI unnecessary and switch the 
default -- something we can revert upstream if it turns into a disaster.

at this point, "later" is "now":-)

So I'm going to dump the DMI patch and apply Luca's patch for 2.6.30.

for 2.6.29 we can either go low risk (dmi patch) or change the default
after it cooks in 2.6.30 for a bit.

thanks,
-Len


  reply	other threads:[~2009-04-02 21:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1236687873.7060.31.camel@localhost.localdomain>
2009-03-10 12:39 ` [PATCH]: ACPI: Add the dmi check to make acpi_enforce_resources strict Matthew Garrett
2009-03-11  2:34   ` Zhang Rui
2009-04-02 21:18     ` Len Brown [this message]
2009-03-10  3:34 yakui_zhao

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=alpine.LFD.2.00.0904021706520.4660@localhost.localdomain \
    --to=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mjg@redhat.com \
    --cc=rui.zhang@intel.com \
    --cc=yakui.zhao@intel.com \
    /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