From: Feng Tang <feng.tang@intel.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Wim Van Sebroeck <wim@iguana.be>, Len Brown <len.brown@intel.com>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Aaron Sierra <asierra@xes-inc.com>,
Bob Moore <robert.moore@intel.com>,
Samuel Ortiz <sameo@linux.intel.com>,
Guenter Roeck <linux@roeck-us.net>,
rui.zhang@intel.com
Subject: Re: [PATCH] lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt driver
Date: Thu, 23 Aug 2012 13:08:14 +0800 [thread overview]
Message-ID: <20120823130814.6ba359e9@feng-i7> (raw)
In-Reply-To: <20120822215543.GA1954@srcf.ucam.org>
On Wed, 22 Aug 2012 22:55:43 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Wed, Aug 22, 2012 at 09:55:12PM +0200, Wim Van Sebroeck wrote:
>
> > Any idea why the acpi_check_resource_conflict() check gives a conflict?
>
> Because the resource range is declared in ACPI and we assume that that
> means the firmware wants to scribble on it. We'd need the output of
> acpidump to work out whether that's safe or not.
Good point, I checked the conflict for iTCO_wdt, the conflict exists on
almost all the machines I have.
According to ICH (7/8/9 etc)spec, the TCO watchdog has a 32 bytes long IO
space resource, and the bit 9 of TCO1_STS register is "DMISCI_STS", which
indicates whether a SCI happens, and will be cleared by writing 1
to it. Most of DSDT table will claim a TCO op region only for one bit:
"DMISCI_STS" , as some method may need to access that bit.
I think there is some risk, but it's quite safe as the DMISCI_STS bit has
nothing to do with TCO driver itself, and TCO driver never access it, also
this TCO driver has been there for years, and this resource conflict also
exists for many generations hardware.
Thanks,
Feng
next prev parent reply other threads:[~2012-08-23 5:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 15:56 [PATCH] lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt driver Feng Tang
2012-08-22 19:55 ` Wim Van Sebroeck
2012-08-22 21:55 ` Matthew Garrett
2012-08-23 5:08 ` Feng Tang [this message]
2012-08-23 17:13 ` Samuel Ortiz
2012-08-23 15:28 ` Guenter Roeck
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=20120823130814.6ba359e9@feng-i7 \
--to=feng.tang@intel.com \
--cc=asierra@xes-inc.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mjg59@srcf.ucam.org \
--cc=robert.moore@intel.com \
--cc=rui.zhang@intel.com \
--cc=sameo@linux.intel.com \
--cc=wim@iguana.be \
/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).