From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Andy Lutomirski" <luto@amacapital.net>,
"Andy Lutomirski" <luto@kernel.org>,
"Jean Delvare" <jdelvare@suse.com>,
"Wolfram Sang" <wsa@the-dreams.de>,
"Jarkko Nikula" <jarkko.nikula@linux.intel.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"Linux ACPI" <linux-acpi@vger.kernel.org>,
"Pali Rohár" <pali.rohar@gmail.com>,
"Mario Limonciello" <mario_limonciello@dell.com>
Subject: Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR
Date: Tue, 3 May 2016 11:53:07 +0300 [thread overview]
Message-ID: <20160503085307.GD1717@lahna.fi.intel.com> (raw)
In-Reply-To: <CAJZ5v0hS4O2eAUrAK4xC=s8OHtiTpj-bKjzry_GoKk2m5NktnA@mail.gmail.com>
On Mon, May 02, 2016 at 11:29:01PM +0200, Rafael J. Wysocki wrote:
> It doesn't look like trying to make it safe for both the driver and
> AML to use the same range of addresses is a realistic goal. At least
> the benefit will not outweigh the resulting complexity if the opregion
> is actually never used by AML in practice.
>
> So, why don't we have a flag that will make i801_access() return an
> error on every invocation when set (the callers of it should be able
> to cope with that or they are broken IMO) and why don't we set it when
> AML accesses the opregion first time?
Yeah, that occured to me also yesterday evening :)
> Yes, that will prevent the driver from actually working *when* AML
> turns out to use the opregion, but IMO that's a bit more friendly than
> preventing the driver from loading at all.
I agree. If nobody objects, I'm going to create v2 of the patch that
prevents further driver access if AML touches the OpRegion.
next prev parent reply other threads:[~2016-05-03 8:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 10:23 [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR Mika Westerberg
2016-04-28 18:34 ` Andy Lutomirski
2016-04-29 8:56 ` Mika Westerberg
2016-04-30 1:13 ` Andy Lutomirski
2016-05-02 10:12 ` Mika Westerberg
2016-05-02 11:42 ` Rafael J. Wysocki
2016-05-02 12:40 ` Mika Westerberg
2016-05-02 15:29 ` Andy Lutomirski
2016-05-02 15:50 ` Mika Westerberg
2016-05-02 15:53 ` Andy Lutomirski
2016-05-02 21:29 ` Rafael J. Wysocki
2016-05-03 8:53 ` Mika Westerberg [this message]
2016-04-29 9:03 ` Pali Rohár
2016-04-29 18:10 ` Andy Lutomirski
2016-04-29 21:00 ` Pali Rohár
2016-04-29 21:42 ` Andy Lutomirski
2016-04-30 0:56 ` Andy Lutomirski
2016-04-30 8:12 ` Pali Rohár
2016-05-05 8:27 ` Pali Rohár
[not found] ` <CALCETrW3i7QkVNRo4RQkRViPBo8dSn=4mKDZiA=Ar3v7=dgz1A@mail.gmail.com>
2016-05-07 14:11 ` Pali Rohár
2016-05-07 15:06 ` Jean Delvare
2016-04-29 20:21 ` Rafael J. Wysocki
2016-05-02 10:21 ` Mika Westerberg
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=20160503085307.GD1717@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=jarkko.nikula@linux.intel.com \
--cc=jdelvare@suse.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mario_limonciello@dell.com \
--cc=pali.rohar@gmail.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=wsa@the-dreams.de \
/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).