From: Samuel Ortiz <sameo@linux.intel.com>
To: Feng Tang <feng.tang@intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
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>,
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 19:13:15 +0200 [thread overview]
Message-ID: <20120823171315.GD9889@sortiz-mobl> (raw)
In-Reply-To: <20120823130814.6ba359e9@feng-i7>
Hi Feng,
On Thu, Aug 23, 2012 at 01:08:14PM +0800, Feng Tang wrote:
> 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.
Makes sense to me.
I'm queueing this one to my for-linus branch, I'll send a pull request soon.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
next prev parent reply other threads:[~2012-08-23 17:13 UTC|newest]
Thread overview: 7+ 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
2012-08-23 5:08 ` Feng Tang
2012-08-23 17:13 ` Samuel Ortiz [this message]
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=20120823171315.GD9889@sortiz-mobl \
--to=sameo@linux.intel.com \
--cc=asierra@xes-inc.com \
--cc=feng.tang@intel.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=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 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.