From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: 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 <linux-i2c@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR
Date: Mon, 2 May 2016 13:21:57 +0300 [thread overview]
Message-ID: <20160502102157.GO32610@lahna.fi.intel.com> (raw)
In-Reply-To: <CAJZ5v0irGCpV1xXroQyPk5yYbLyAY3R8HtMKiq76C4ZBA=AKgw@mail.gmail.com>
On Fri, Apr 29, 2016 at 10:21:29PM +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 28, 2016 at 12:23 PM, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> > Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
> > PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:
> >
> > Device (SBUS)
> > {
> > OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
> > Field (SMBI, ByteAcc, NoLock, Preserve)
> > {
> > HSTS, 8,
> > Offset (0x02),
> > HCON, 8,
> > HCOM, 8,
> > TXSA, 8,
> > DAT0, 8,
> > DAT1, 8,
> > HBDR, 8,
> > PECR, 8,
> > RXSA, 8,
> > SDAT, 16
> > }
> >
> > There are also bunch of ASL methods that that the BIOS can use to access
> > these fields. Most of the systems in question ASL methods accessing the
> > SMBI OpRegion are never used.
> >
> > Now, because of this SMBI OpRegion many systems fail to load the SMBus
> > driver with an error looking like one below:
> >
> > ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
> > conflicts with OpRegion 0x0000000000003040-0x000000000000304F
> > (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
> > ACPI: If an ACPI driver is available for this device, you should use
> > it instead of the native driver
> >
> > The reason is that this SMBI OpRegion conflicts with the PCI BAR used by
> > the SMBus driver.
> >
> > It turns out that we can install a custom SystemIO address space handler
> > for the SMBus device to intercept all accesses through that OpRegion. This
> > allows us to share the PCI BAR with the ASL code if it for some reason is
> > using it. We do not expect that this OpRegion handler will ever be called
> > but if it is we print a warning and execute the read/write operation under
> > a lock which prevents ASL and OS from messing each other.
> >
> > Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Thanks!
> If it addresses any public BZ bugs, it would be good to add Link: tags
> for those and maybe Reported-by: for the reporters?
Good point. I can add those.
However, after reading ACPI 6.1 spec again, I'm having second thoughts
about this patch. See my other email to Andy on this thread.
prev parent reply other threads:[~2016-05-02 10:22 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
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 [this message]
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=20160502102157.GO32610@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@kernel.org \
--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).