[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070302224155.143b8643.khali@linux-fr.org>
Date: Fri, 2 Mar 2007 22:41:55 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: Pavel Machek <pavel@....cz>, Chuck Ebbert <cebbert@...hat.com>,
Rudolf Marek <r.marek@...embler.cz>,
linux-acpi@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
lm-sensors@...sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
Hi Matthew,
On Fri, 2 Mar 2007 14:57:09 +0000, Matthew Garrett wrote:
> How about this? It's informational only, but ought to result in
> complaints whenever ACPI tries to touch something that other hardware
> has reserved. We can't fail these accesses, but in theory we could
> consider some sort of locking layer that made it possible to interact
> anyway. I haven't even checked if this builds, but I think the concept
> is reasonable.
I like the patch, after adding some casts to the printf args it
compiles fine. However you print warnings each time a resource has been
reserved... without checking if it hasn't been reserved by ACPI itself!
My machine looks like this:
1000-107f : 0000:00:1f.0
1000-1003 : ACPI PM1a_EVT_BLK
1004-1005 : ACPI PM1a_CNT_BLK
1008-100b : ACPI PM_TMR
1010-1015 : ACPI CPU throttle
1020-1020 : ACPI PM2_CNT_BLK
1028-102b : ACPI GPE0_BLK
102c-102f : ACPI GPE1_BLK
Given that these ports were reserved by ACPI it is perfectly legitimate
that ACPI accesses it, so we must not print a warning in this case. We
need to exclude from the test the regions those "name" starts with
"ACPI", but I'm not sure how we can do that.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists