From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Chase Douglas <chase.douglas@canonical.com>
Cc: linux-acpi@vger.kernel.org
Subject: Re: Quirking acpi_enforce_resources
Date: Mon, 1 Mar 2010 22:22:02 +0000 [thread overview]
Message-ID: <20100301222202.GA25116@srcf.ucam.org> (raw)
In-Reply-To: <1267481726.22999.13.camel@cndougla-ubuntu>
On Mon, Mar 01, 2010 at 05:15:26PM -0500, Chase Douglas wrote:
> I understand your points, but from the user's perspective they had
> something that worked perfectly fine before, and now it doesn't. Have
> there been any reports of anyone's hardware being adversely affected by
> doubly acquiring the acpi region? Beyond that, have there been any
> reports of any adverse affects of any kind?
I really don't understand your position here. Like I said, the
probability of a collision between ACPI and the OS is low. On the other
hand, the potential outcome of such a collision is hardware damage. This
isn't even close to being something that should be considered.
> I'm not advocating for enabling acpi_enforce_resources=lax across the
> board. That would be foolish, especially since there is an existing acpi
> driver that would be harmed. However, a whitelist of known-working
> hardware would allow us to cater to users needs while still being fairly
> careful.
How are you defining "known-working"? You've verified that the system
management code on the hardware in question makes no accesses to the
smbus?
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2010-03-01 22:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-01 21:01 Quirking acpi_enforce_resources Chase Douglas
2010-03-01 22:04 ` Matthew Garrett
2010-03-01 22:15 ` Chase Douglas
2010-03-01 22:22 ` Matthew Garrett [this message]
2010-03-01 22:35 ` Chase Douglas
2010-03-01 22:45 ` Matthew Garrett
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=20100301222202.GA25116@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=chase.douglas@canonical.com \
--cc=linux-acpi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.